达尔文×
拉马克×
表观遗传学√

反正我 8 点睡能 4 点 50 起，问问你自己身体什么感受，光听别人吹

9 点睡靠谱吗？

网易云的用户是从 b 站来的
qq 音乐的用户是从酷狗 /虾米 /其它音乐软件来的

我这么说应该不会有人有异议吧

每个这种帖子点进来都是「房贷 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 完整了吗？没有的话根本都不到开发干活的时候，到开发干活的时候风险点和技术调研照理都已经全完成了，当然就不需要天天应急似的对进度