自从团队在2010年初发布“敏捷宣言”以来，几乎在每个没有电话会议的早晨团队都会开一个晨会（Daily Meeting)。这个会议时间很短，往往就10多分钟，主要是汇报各子项目组的项目运行进度，今天即将要做什么，碰到什么问题。
为什么每天要有这样的晨会呢？
1. 负责人要了解概况。
整个团队分为5个子项目组，每个项目组做的事情基本独立，项目运营负责人（Tech-lead）需要对每个项目组的情况有个“大概”的了解，在晨会上对每个项目组遍历一遍询问状态（status）是个快速地获得“全局情况”的方法。知道全局情况后便可以采取相应地有必要的措施。
2. 成员彼此需要互相了解。
既然是一个团队，所以5个子项目组不可能完全没有联系。比如平台组昨天测试通过了一个新的平台交付，那么在晨会上便可以告知项目组“你们可以去升级到新的平台了”。平常平台组和项目组各干各的事情，在晨会上可以正式提出一些有必要让对方知道的事情。
3. 练习英语。
我们的晨会是“English stand up daily meeting"，意思是所有人必须用英文表达项目组的情况，同时听其他项目组的用英文汇报的情况。站着的原因是坐下来容易散漫，容易陷入细节，站着更容易控制时间，因为站久了会累。
4. 潜意识加强团队意识。
每天的工作基本上是一个子项目组中的几个人（一般两个或以上）合作，跟其他的子项目组运行着不同的项目，如果每天不”聚“一下的话，久而久之潜意识就会认为“自己的团队只有两个人”。
通常在这10分钟左右的晨会结束后，根据不同项目组的情况，可能会加开一些“附属晨会”。附属晨会是针对子项目组的，和晨会的不同点是需要讨论更细节的东西，比如技术细节实现，或者具体的技术难题。附属晨会一般只有具体的项目组参加，其他的项目组可以先回去工作了，因为没必要浪费时间去了解其他项目组的细节。这样的附属晨会通常只会在有4-5个人的”大项目组“中应用，小项目组回办公室后彼此交流交流就好了。
类似晨会，为什么大项目组中每天要有这样的附属晨会呢？
1. 项目负责人要了解概况。
一个项目整体上的进度已经在晨会上汇报了，但是一个项目是有更小的作战单元组成，所以为了确保项目的进度健康，有必要了解每个作战单元的进度。于是项目组负责人需要遍历每个人对自己任务的完成度。
2. 成员彼此之间需要互相了解。
把做项目比喻成爬山，你不是一个人在爬，不但你爬到哪里很重要，也有必要了解队友爬到哪里，毕竟都爬到山顶才算赢。也许队友此刻遇到一个技术问题你曾经遇到过，这样过去拉一把就避免了”重新发明轮子“。
3. 群策群力解决技术难关。
对个别成员遇到的技术难关，大家一起出点子解决。
那为什么说会”难受“呢？了解情况也会让人难受？如果答案是YES，那么可以轻松地推测出”一定不是好情况“，因为人们普遍在”表达坏情况、麻烦“的时候心理上会难受，进而影响身体上难受。
据我大致观察和自己的亲身体验，难受主要表现在如下方面：
1. 团队成员汇报项目进度时”顾左右而言它“
当负责人问: 小明， 你的任务做到百分之几了？这理论上应当是个很简单的答案，因为只用说一个数字就可以了，可是实际情况是小明会直接说：昨天遇到一个技术难题，blah, blah（开始描述技术难题细节）这时候负责人着急了，因为他关注进度多过于细节，并且他有责任控制会议的进度，所以他不得不打断小明说：等一下，你先告诉我进度，然后再说你遇到的技术难题。小明不得不说 50%（也许跟昨天相比没有前进多少），然后再开始说细节。
小明之所以一开始回避进度数字，一来可能是因为他不懂表达的习惯，应该先说”总“，然后再说细节；二来可能是因为他在想”如果说出进度没怎么前进，主管会骂人，其他的同事会鄙视我。“，尽管他想的内容往往不会发生，不过人们都习惯于停留在心理舒适区，而不想难受，所以顾左右而言它，或者直接诉说出了自己的痛处。
解决的办法就如上面所说，负责人应该果断打断他继续描述细节，必须先说完大体进度，才允许说细节。
2. 负责人回避追问项目进度
项目的负责人自己就是一个技术工程师，一般来讲有技术特质的人比较“善良”，善良的意思就是“不想让别人受伤”。所以他会在“打断别人说话”时感到难受，“明知道情况很糟糕而强迫别人报告坏消息“时感到难受。所以这样的结果是：
2.1 负责人和整个会议被带到技术细节，会议节奏被打断并失去控制。
2.2 项目组花了时间开会，却没有效果 -- 负责人并不清楚项目的具体进展，这样对项目的控制只建立在”模糊的意识上“。
2.3 负责人对项目失去控制。当某一天觉得不对劲了，”长痛不如短痛“地仔细问进度，发现已经为时已晚，抢救都来不及了。
解决的办法是在初期，由主管在旁边”监督“负责人开会，一旦有负责人回避情况发生立即跳出来干预，然后把会议控制权交还负责人继续。并在会议结束后私下告诉负责人以后应该怎么做。
3. "乐极生悲“的技术讨论
对于工程师来说，在晨会上和大家讨论技术问题是一件很快乐的事情，特别是很乐于表达自己解决不了的技术问题以期待别人能够提供帮助。这时候会有三种情况：
1. 有一种解决方案。某一个人提出解决方案，说出来大家听了之后感觉可行，也没有其他的办法了，所以皆大欢喜，散会。
2. 没有任何解决方案。讨论了半天，总是没有解决方案能够解决根本问题。这个时候会议的时间在悄悄地流失，负责人应该警惕地看着表，一旦到达预期设定的时间线便应该大叫"cut， 这个问题我们之后在讨论，早晨的时间非常宝贵，大家回去先做简单的部分，做完了其他的只剩这一个问题时我们再来讨论”。于是，散会。
3. 有两种解决方案。这种情况发生于两个人同时提出两种解决方案，这两种解决方案都可以达到效果，但是因为两个技术工程师都坚持自己的解决方案是“最好的”（要面子，争强好胜，不妥协），于是会议进入“无休止”的争论期，以“评选”出“最好”的解决方案。其实这是在浪费时间，两个可以进入”无休止争论期“的解决方案按理说应该效果”差不多“，按CEO教的方法便是抛＊＊ -- 随便选一种，然后执行下去，不用担心会出大问题（意料之外的不算），因为会出大问题的解决方案一般不会进入前面所说的”无休止争论期“，而会早被否决掉。 于是，负责人跳出来，果断做一个”艰难的决定“，散会。
其实有很多时候，哪怕单纯的技术团队也会遇到”人性“上的问题，这些”人性“问题一旦有影响商业项目的风险就应该开始人为主动干预或被干预。即使是再“善良”的人，不妨尝试思考：其实大家在一起主要是“做事"的，把事情做好是第一位，成熟的职业人不会永远待在自己的心理舒适区的。
