每个这种帖子点进来都是「房贷 xxx 」
能有点新意不？















哦…… 我差点忘了这是 v2

千万不要跟妹子拼酒，拼输了丢面子拼赢了败人品，直接清高「我不喝酒」反而不会有人太在意

前几年做 ROM 时

都前几年的东西了





…… 真的是「前几年的东西」吗？？？

你先把为什么有了双开能「巨幅提高销量」给讲明白了

反正我买不起

有钱摆平一切，直接国际学校-出国-移民一条龙

没钱？进厂-呆不住-送外卖 /拉滴滴 /游戏代练工作室 /主播……

@sutking #6 。。我的桌面就没有露出来过，一直被各种「临时窗口」铺满的，也从来没往桌面上放过任何东西

让他们的教学场地划成专用区，不要交叉

@cassyfar

1. 早会确实真的完全不能给只写代码的人带来哪怕一丁点好处，只会浪费他每天 10 分钟时间
2. 但这 10 分钟能确保他发送且接收了他所需的信息摘要
3. 早会 /日会的前提是这个团队足够小且足够适合采用迭代模型，如果这个前提不存在，那么不是早会意义存在与否的问题，而是项目管理完全失败。我花了大量你所谓「不相关的」篇幅去说明这一点


@locoz #94
正因为这个形式有很多东西去替代部分功能，因此你得承认至少那些「功能」是有用的对吧。那么对于一簇目标，有两种不同的方案，方案 B 比 A 好一些，我们可以说方案 A 就是无意义的吗？我完全承认你说的替代品的效果会更好，但你承不承认「不替代的时候也有效果」呢？ 我 argue 的是这一点。如果你承认，不就说明早会有意义吗，不承认，那就没什么可讨论的了

双 11 囤纸巾是吧

@locoz 你把讨论早会意义限定在一个早会无意义的场景下，我试图告诉你早会有哪些意义，你试图告诉我在我举例的意义都不存在的情况下早会不存在意义

「一个团队应该是那样那样的，不那样就有问题！」
「如果团队真的不那样呢」
「不应该有这样的团队！」
「如果人就是不自觉呢」
「开除！」

@locoz ……行

@locoz 还有更高效的做法是初创团队 5 个全栈直接动态分工点对点解决呢

如果你刚来一个团队每个人干什么的都不知道，有问题不知道找谁呢
如果你还不熟悉团队氛围不清楚该不该说话找谁比较好说话呢
如果你就是喜欢憋着拖着不沟通的那种人呢
如果你是个觉得群里无用信息很多平时一律忽略群消息的人呢
team leader 考虑的是如何保证一个非自律懒惰性的、任务驱动的、沟通松散的、多技术栈和岗位一起协作的团队如何高效起来。而不是去「找能自觉写 todolist 、自觉推动项目需求、自觉沟通问题的人」来组建团队。你说的那叫不拿工资拿期权的创业合伙人。


理解一下我说的「确保实现 n^2 条次信息传输」



> 一个在项目初期开立项会之类会议时就能大体定下的 todo list ，在大多数时间里都只需要顺手点几下就能完成项目管理的需要

这么说吧，之前我们一期迭代开始前需要将近总计 5 个小时的（多次）会议去细分任务，这 5 个小时能确定什么呢，要做多少个 story ，story assignee 是谁，大概需要几个天时，需要什么原型或设计细节。

那么每天早会一分钟讲的是什么呢，这个 story 设计上要写 3 个接口，有俩搞定可以调了，设计图更新了记得看，Abug 已经搞定了测试记得去看 aaa 的 build


虽然都只是「去看」，但还是我说的，早会「确保」你应该看，或者你去看了。

@cassyfar 「一有疑问」？

没有形式来保证，谁知道其他人什么时候「有疑问」？早会的目的就是每天都让所有人都清楚了解有没有问题。

> 组里都在做不同项目，大项目很多又是牵扯到几个组的，这种同步，早会是做不了的

这也叫「从早会反映出的完全失败的项目管理」。



敏捷团队必须以目标为单位来组织，而不是什么技术栈或管理部门。这个团队应该是能随时（指在 milestone 之间）重组、扩容、调配的，包含完成一个 milestone 所需所有「基本常驻人力单位」的组织。并且敏捷模式就是与小团队和快迭代才契合的模式，其它场景根本就不适合 agile/scrum 。换言之，「一个组」应该代表「做同一件事的一群人」，如果「组里在做不同项目」，说明管理失格。


如果项目很大需要很多团队配合



这个项目需要不断迭代吗

> 是 >> 那么能把项目拆成多个小团队各自进行敏捷开发和迭代吗
>> 能 >>> 各个小团队各自日会，各组长与项目总管理时不时沟通同步情况。这种情况一般是有很多个组件相互存在松散依赖，各组件会不断 build 新的稳定版本供其他组件引用，组件的版本迭代就可以继续采用敏捷模型。
>> 不能 >>> 说明项目的架构就很有问题，只会越迭代越痛苦，趁早副本一个团队重新做 2.0 才是正确的事。

> 不是 >> 那么这种项目的生命周期根本就不采用迭代模型，瀑布模型前面的需求分析写完了吗？设计文档和 PRD 完整了吗？没有的话根本都不到开发干活的时候，到开发干活的时候风险点和技术调研照理都已经全完成了，当然就不需要天天应急似的对进度

@deletemyself

> 需求都是产品与开发单独对接的相互之间并不很清楚对方的功能，只是重复说日报的内容。。。且小组负责人并不是全局把控或者参与所有需求

这叫「从早会反映出的完全失败的项目管理」，无用功恐怕远不止一个早会

早会一人一分钟，n 分钟能确保实现 n^2 条次项目相关信息的传输，组织得当要比任何其它方式都高效多了

不然呢？
你两个写前端的倒是互相知道对方写了什么，项目管理怎么知道？私聊问吗？还是指望你们会自觉填进度表？自觉写我都不写的日报？我怎么告诉后端你俩今天写不完这个需求？后端问我是接口不好对还是纯前端的其它问题我再问你俩一遍？还是说你俩已经跟后端沟通过了？那后端本来还可以有其它任务怕进度不够没上而已，现在他有空了咱全组一起看着他摸鱼又不知道为啥他能摸鱼合适吗

反对的原因都是「我进度有点问题但我想自己解决给我时间其它别烦」，但 scrum 站会的意义正是在于打破这种信息封闭，让问题暴露出来，好让团队评估整体的进度和风险。由于 scrum 式的扁平小团队基本都有横向评估或部分替代他人工作的能力（区别于传统管理树形模式上级无法也不需要知道细节），因此暴露问题一定比把问题留给他自己解决要好。

越是觉得开会难受的团队越说明磨合不顺利，因此也更需要把短会落实好。顺利的站会 /短会 /早会是

「昨天后端接口写完了，我这边初步对了一下，但感觉有点问题：xxx 」
「哦那可能接口这有些问题没考虑到，改成 xxx ？」
「先别管具体问题，你俩重新对接口这事要多花多长时间？」
「可能得调一两天的」
「那分一下吧，前后端另两位进度顺利吗」
「我们这边也有点问题 /还挺顺利的」
「那能接一下吗 /那看来这期迭代的 xx 需求只能砍了」

而不是

「我昨天正常开发 x 功能」
「昨天来了个新需求，预计将能带来 xx 的增长，而且 xxx 的意义也很大……balabala……哎你们谁手头有空」
「我要忙 x ，没空」
「我也在忙 y ，没空」

正在搜索了记忆库存……

相关记忆： 0 条


应该真的没有什么特别的事发生过。有几年的冬至和大雪（节气）都比一破圣诞节印象深刻

@Jooooooooo 我举的 5 个句子全是「一样的」（跟你一样「用某种视角来看的话」），只是词序和句构有区别而已