关于站会的一些理解

9:00 am，到达公司。整理邮件，整理昨天完成的工作，看看今天要干的活。
9.30 am，团队人员基本到齐了，PL（Project leader）开始组织站会，接下来就开始对工作进展汇报。
汇报过程中基本上说昨天干了什么，今天准备干什么，有没有风险，这种模板式的回答。
10.15 am，整个项目团队汇报完毕，各自回各自工位开展工作。

说到这里我不得不反思一下，每天花45分钟是否符合一个敏捷团队的要求？
当然，在离职之前，我是没有答案的，不过来到ThoughtWorks后，我对敏捷团队有了新的认识。

敏捷团队的意义在于小步快跑，建立统一的完成目标，以及高度自觉地任务完成机制。
而现在看来在我之前这个团队明显与敏捷格格不入。

首先，团队人数大概有20人左右，团队人数太多，不符合敏捷的要求（3-9人），过多的团队人数，导致了早晨站会时间过长，同时大量占用了开发的工作时间。另外，人数的增加，工作量也呈现相应的翻倍，工作的复杂性也大大的提高了。
按照这个规模去进行敏捷开发，只有一个方式能够做到，那就是不停的加班。在离职之前，我对在公司加班已经习以为常，而现在看来，这种加班实质是一种恶性循环。项目每月发布一次，团队不够敏捷，那么要完成月度发布任务，只有通过不停的加班来赶进度。

其次，团队分工太过于明确，前台只专心与前台开发，后台只负责后台开发，管理环境的只负责服务器的问题。于是出现了这种现象，环境没数据，后台开发等待环境管理人员造数据，后台阻塞不动，前台也只能自己在没有输入的情况下进行开发，完全不知道自己开发完成后是否符合目标期望。
作为一个敏捷团队，要求团队是一个全功能团队，每个人技能不能单一，可以有自己最擅长的技能，但是也要有，能够补充他人的“辅助技能”。工作职责划分的太过明显，就会导致遇到问题到处寻找资源帮助解决，解决不了就处于等待状态。这种工作方式不利于保证项目的最大化输出。
正确的方式应该是每个人都能够为自己开发的内容提供辅助内容，比如说我后台要查询一张表，表里面没有数据，那我就需要自己辅助自己，完成数据的录入，而不是等待环境管理人员将数据补齐。敏捷要求团队不仅要全功能，还要求成员拥有多技能，成员之间形成技能网进行互补，一起推动敏捷的开展。

最后，关于工作任务的变更。之前在的团队经常性的被增加额外的需求，这就导致了，白天完成甲方爸爸要求的临时需求，晚上加班开发自己的工作任务。
对于一个敏捷团队，任何任务的新增与删除都是有计划，或者是在充分讨论后的，向之前团队的经常性，临时性增加需求，对于整个敏捷开发节奏是非常影响的。当然正确的方式是，所有的需求经过项目经理确认，计划的变动经过确认。

当然这些只是个人的一些理解，存在一定的片面性，这篇文章我会在更加深入的理解ThoughtWorks的工作理念后，在进行更加深入的探讨。