Testing. If you have unit test and integration test plus user acceptance test as part of your CU/CD, changes would not be off that much. Some engineers don’t take testing seriously or miss good engineering fundamentals. That is on the engineer. Not on agile or iterative development
You didn’t get the key of Agile. It is agile. Dev is done in iterations to avoid big changes that could potentially happen in the waterfall model. It needs to be done right. Engineering fundamentals are important.
Testing. If you have unit test and integration test plus user acceptance test as part of your CU/CD, changes would not be off that much. Some engineers don’t take testing seriously or miss good engineering fundamentals. That is on the engineer. Not on agile or iterative development meidong20 发表于 2022-10-19 01:41
有人会说这不是agile不好，而是一些人搞agile的搞法不对。这一点好像没人否认，但现实就是大家都这么搞，所以它就几乎成了对的了，教科书上的正确搞法也没人care了。我也工作过好几个不同的公司了，可能我层次太低，我至今就没有见过搞这套搞得正确有效的，都是成了变相的早请示晚汇报，都比较操蛋，好公司和差公司的差别，可能就是有点操蛋和特别操蛋的区别而已。我也为这个跳过槽，从特别操蛋的公司跳到有点操蛋的公司，这样就很满足了。
如果你要较真，要告诉别人用教科书上的正确的方法来搞，那简直就跟拿着宪法跟流氓讲理一样。
再说个我个人的见解，不一定对啊。我觉得给每个任务定一个分数，本来就是个很操蛋的idea。一个任务，描述起来可能很简单，你写一堆代码，实现个什么功能。你问我这个值几分，或者说需要几天？我TMD不知道啊，同样这么一个任务，有时候我运气好，咣咣把代码敲完，一测试没啥毛病，这可能两小时就完事了。也可能我写完代码，一run发现好多问题，但是还能fix，再咣咣找出来一堆bug改完，好了，两天能弄完。还有可能更倒霉，一run发现一些奇奇怪怪的问题，有的还不是代码本身的问题，那就厉害了，还要找其他人扯皮，一周也不一定能整明白。但不懂技术（人家也不稀罕懂）的专职监工们，可不管这一套，就让你上来就报个数，然后超过那个时间做不完，就是你的黑锅。每次assign任务就像猜盲盒。你要每次直接按最复杂的情况往多里说，也不行，专职监工又要质问：为啥别人的另一个任务不需要这么多时间？为啥你以前做过的另一个任务不需要这么多时间？为啥？就算你不嫌烦跟人家监工解释，人家也不爱听。
再说很多任务，根本就没有明确的定义，创建任务的人稀里糊涂的写一堆狗屎，就让人干活。掰扯明白到底要干啥的时间，比真正干活的时间都长，你说这个值几分呢？而且人家还不许你先掰扯明白再领任务，要你现在就领，还要报上分数，到点完成。
现在这个行业能搞成这样，这一套操蛋的东西能实行的起来，我觉得也跟这几年全社会一窝蜂转码，严重供过于求有关。是的，马工这行机会确实相对比较多，但再多也架不住所有人都转，总有饱和和过饱和的时候。你觉得早请示晚汇报很操蛋，不能忍，但有的是人能忍，资本家不缺人。有的公司搞pair programming都有人能忍呢，早请示晚汇报比起来算得了什么？
版上经常有一些五花八门的马工凡尔赛帖，所谓的马工工作就是摸鱼，每天干活不到一小时，随便混混就赚五十多万，每天都像在度假，动不动就是赢两次赢麻了。我不否认这样的公司和这样的马工存在，毕竟大千世界无奇不有。但我想说的是另一种更常见的情况，也就是这个行业里常见的一些有毒公司，以及它们的文化是怎么有毒的。根据我个人的经验，这样的真的相当普遍。
早请示晚汇报那一套，怎么个恶心法，我就不再多说了。总之就是把工程师的工作方式搞得像车间工人一样，甚至连车间工人都不如，就像机器人，宗旨就是尽可能地micromanage，操控每一个微小的工作步骤，尽量减少干活的人的独立工作的空间。一些更有毒的，还有pair programming这个恶心一万倍的东西，不知道这是啥的自己搜吧。
都说软件公司有钱，我觉得正是因为有钱，所以它们才能有钱任性，雇佣一群专职监工，屁也不懂只会在jira里看story然后跟在马工后面催命，外行领导内行。在传统行业，一般好像技术组里也就是有人一边干活一边顺便做做监工，比如小manager或tech lead一边干活一边顺便跟踪一下组里其他人的工作进度，因为传统行业没钱嘛，所以就没奢侈到在每个小组里都养一两个专职监工。软件公司就不差这点钱。
马工其实也不用抱怨外行领导内行，因为自古至今，专职监工本来就都是外行来当啊，有啥奇怪的呢。砖厂的专职监工不需要会搬砖也不需要会烧窑，他们只需要会拿鞭子抽人。同理，皇上派的监军太监也不需要懂得怎样带兵打仗。
资本的本能就是追逐利润。软件公司有了钱，很自然的想法就是怎样用这些钱来赚更多的钱。有些聪明人就想出来这么个主意，把一部分钱拿出来养一帮专职监工，加大对工人的压榨程度，这样来赚更多的钱。
在有毒的文化里，想让工作不影响身心健康是很难的。马工早请示晚汇报的时候，最经常被问到的问题就是这几个类型：这个story做完了没有？为什么还没做完？为什么XX的那个story只要2分，你的就要3分？为什么XX的那个story三天就做完了，你的四天还没做完？整天被反复问这样的问题，正常人有不烦的吗？做个活，做慢了不讨好，会被早请示的时候揪出来批斗（这个词用的重了，但意思懂的都懂）。做快了也不讨好，做完一个story马上被塞给另一个，往往还是一个更难做的，如果N天之后没做完，还会被质问为啥上一个story N天能做完，这一个就做不完？不管你干的好坏快慢，都会觉得恶心。
这样的环境里，人普遍都很defensive，写代码是相对很不重要的技能，更重要的技能，是懂得如何维护自己和甩锅别人，以及容忍傻X。
版上有人肯定会说，因为我圈子low，所以才见过这些low的东西。这样的人我一概不理。
传说中文化不好的，亚麻和Meta 就是这种工作环境？
这种公司，只能招到技术不行的吧 技术好的，即使因为身份所困，拿到身份也立马就跑了
软件是一个很大的行业，不是只有版上经常讨论的那几家大厂。
大IT公司里这种做法不是主流，除非老板要整人，越是那些二三线的和老牌软件公司里更严重
以前在一个这样的公司干过，所以亲眼见识过。骑驴找马，找到就跳槽了。
我就是马工啊，算我自黑都不行吗？
看了以后我觉得我不仅智商不够转码，情商也不够。
哈哈。你们一个故事是多久？
这行里这样的傻逼挺多的，有时候也说不清楚到底是脑子不够使，还是故意整人。
给你塞一个连做什么都掰扯不明白的task，然后就是催命，用的时间长了还是你的锅。
在这样的环境里混，最重要的技能就是扯皮和甩锅，技术不重要。
这样的环境还是远离最好。
删
为啥不直接说你需要ramp up time？也许说了，他会给你呢？story points 应该是你自己给的，只要你能够justify为什么需要那么多points
有毒的是人。。
教教我们怎么defend myself 又不得罪别人？
金融行业绝对是资本剥削主义血淋淋的体现，0摸鱼，bad benefit，老板mean，文化mean，成王败寇
删了
那你应该和manager说你需要重新assign story points。就把你这些理由说一下。如果你说了，他不同意，那是另一回事，那你是应该换工作，的确很toxic。如果你没说，那就是你的问题
可以的，sprint planing的目的就是每个人看看story points是不是合理，如果需要更多时间，需要提出来。如果当时不知道需要多少时间，也应该提前指出，story points有可能会变，因为你还不知道需要多少时间ramp up
删
可能每个组不一样，其实我们公司文化真的非常好，就是这个新组就跟公司里的一个start up一样，都用Agile。开始的时候非常痛苦，后来发现从写story的时候就不要写太大的story，太难的活break it down，然后在Acceptance criteria里把相关的人tech 人员都加上，share with them，get feedback.别什么都自己担着。
至于怎么defend，其实我也很难说，但是我明显感觉到这别折磨的一两年挺高很多。还有每天standup report progress的wording也很讲究，我现在发现我开始也能bull shit了，尽管也没做多大个事。
写了这么多，好像没说怎么defend，很难表达 ：（
狗已经逐渐麻化和软化，钱方面软化，管理麻化
软到底有多软啊 感觉wlb非常好 活干得少当然收入少 但是养老哇
语言不会，被招进来，一般都是基于你很快就会学会的假设。如果你三个月了，还不能学会，那可能会造成一些负面的影响。一般都会认为，你会其他语言的话，学一种新的语言，不用花太久的时间
半年之内，你可以要求一些时间来学习，但是老用这个做理由，的确不是很站得住脚。
做硬件的也一样。 同款 manager， 说禁止晚上和周末加班，长期会burn out， 一转身给的任务不加班根本干不完。
删
你可以跟你manager讲啊。如果你觉得这个肯定不对，那一定要讲
别人没法衡量到底是谁对谁错，也许你理解错了，不需要2000行，有现成得library可以用？我不愿意直接觉得你的manager是个傻子，2000行code给两个story points，也不愿意就相信你是傻子。
只要大家的认识是一样的，就可以谈
删
你也可以问，story points assign的标准是什么，到底谁来assign story points，新来的和老人的story pints是不是该一样。
删
你就不要跟这人浪费时间了，给你看他之前发的帖子
https://huaren.us/showtopic.html?topicid=2852420&fid=398&page=1
还有更早一个我懒得翻了。翻来覆去就是抱怨工作很难，别人提的建议全都不听，这么久了还解决不了又跑出来抱怨，跟个祥林嫂一样，直接把帖子给拉跑题了。这位眼里的老板和senior都是傻逼，我们普通人是给不了他意见的
你都不敢问，我咋知道难不难啊。。。。
删
我组里 初级SDE上周提交一千行。当然是特殊情况，快上线前赶工了一把。三个月两千行要求也不高。
删
sprint planning的时候我都没看过repo，也不懂需要用的新技术，无法估算。然后我们scrum master也是个新手，基本都是老板拍板。scrum master就负责走流程cue发言
我不知道这种情况我有没有办法去negotiate…sprint planning每个人都在，我不知道怎么和老板杠…
现在的马工多的是，资本家不在乎bully，你不干有的是人想干。
别人说随他说，脸皮厚点。给你任务时，framework你 不会，repo没看过，你要提出来要求加points。但你态度一定要好，记住你是在求人呢，要好好说，和颜悦色的说。
猜盲盒来估计工作量真是很傻的操作，而且还衍生出一堆无聊的会。
不用行数怎么说？说详细了很多人未必懂，而且这东西详细说了也未必说得清，每个公司代码结构都不一样。行数不能完全说明难度，但至少论坛上交流是一个客观的measurement
码工和其他计件工种不一样的是工作量很难估算，就是所谓的story point 怎么算？ 但是瞎算也比不算强啊。不算的话，一个task 做个把Quarter， 谁知道什么时候能做完啊？
scrum还有一个backlog grooming的会，大家要先了解一些每个epic的requirments，然后给出estimate。把epic breakdown 成很小的story的目的也是为了让estimate更合理。应该由engineer来breakdown stories。在sprint planning的时候，应该不是盲盒了
如果一个engineer，做了很久都不能给一个新feature做出rough estimate的话，他的水平有待提高。碰到一开始没有预想到的事，开新的sotry，或者改story points，重新adjust timeline。但如果engineer不能自己defend自己的story points，总是比别人的高，那也的确是有一点问题。
agile的目的是为了让management和engieers一起更容易的manage timeline，不是开会，也不是为难engineers。 但是agile的目的也的确是把中等的engineers组在一起产生效率。如果是真大拿，人家一人顶十个，顶百个，肯定是不用agile的。
了解怎么更有效率的写软件也是engineer的职责，了解为什么，才能让自己进步
那种不允许devs自己设和改story points的公司，应该远离
直说吧，哪个厂哪个组
妈的, 这段很形象很形象,有的东西就是一行代码的事情, 但是一改动这个代码,尤其是对于老程序,几十年的老程序, 测试就会后面一发不可收拾的副作用跳出来....这个时候头发立马竖起来, 这哪是一周的事情,有的时候三周都搞不定.
这种情况，你可以说，我需要谁谁组的支援或者某个expert的支援等等，老程序我不懂。scrum master的作用是unblock，你说你被block了，需要他的帮助。把球踢给他就好了。直接把ticket先mark成blocked。
每天的早请示晚汇报就是要把这些blocking的情况放到明面上，让scrum master来帮忙。要不然要scrum master干嘛
否则再大的厂，你也会觉得是个奴隶场，因为是你在用奴隶的眼光看世界
是的。
平时听他说，PM 或者 assign point的人不懂engineer 的活，把高分给junior，junior死活整不出来，要么就乱糊弄，害惨其他人。要么就是把很难的部分给低分，完全没有预估到难度。总而言之就是非常random还要搞得很organized似的。为啥要让不懂技术的人来分配活和进度是他最困惑的地方，还不好说，真正是皇帝的新衣。
Testing. If you have unit test and integration test plus user acceptance test as part of your CU/CD, changes would not be off that much. Some engineers don’t take testing seriously or miss good engineering fundamentals. That is on the engineer. Not on agile or iterative development
You didn’t get the key of Agile. It is agile. Dev is done in iterations to avoid big changes that could potentially happen in the waterfall model. It needs to be done right. Engineering fundamentals are important.
这是理想情况，碰到20年的老程序还想有tests？ 😂
没错，每次sprint planning要开2个小时，开的我生无可恋