传统企业敏捷转型纪实（一）
这是发生在某大型企业中的某个部门的事儿。他们有六七十名成员，运用瀑布开发模式，三个月发布一次内部产品。部署的过程长达一周，质量堪忧，交付日难以保证。于是请来一位很有经验的敏捷教练Ken，来帮助这个部门做敏捷转型，解决问题。本文的主要内容是在培训完敏捷的基本思想后，PI Planning（启动会议）上发生的事。本系列目前有两篇：
团队构建
这个部门由四个团队组成，各自主管产品的一部分。每个团队都有对交付负责的人，称为PO（Product Owner）。Ken的第一步是让所有团队选出一名SPO（Super Product Owner），来对整个产品负责。SPO不做兼职，负责解决各种问题，其最重要的任务是做决策。而对于一款探索性的产品来说，决策是没有对错之分的，只是它需要靠执行力和客户反馈来修正。PO们需要力挺SPO，充分信任SPO的决策，并以团队的执行力来保证决策的执行。所以有个PO与SPO隔空喊话效忠的过程。
这个部门比较特殊的地方在于，大部分成员属于两个外包公司，其中有不少新人。大家对敏捷都没有什么概念，对要做的事也心有疑虑。有鉴于此，Ken让两个外包公司的人各选出1名leader来当SM（scrum master）。如果团队成员士气低落，不管任何原因，都可以找SM沟通。如果涉及到甲方公司，便由SM来沟通PO处理。这样做的目的是让每个团队成员都有渠道摆脱自己受到的干扰，增加工作效率。团队成员也需要在团队中建立起自己的人脉，好让自己遇到问题时容易找人帮忙。SM主要负责沟通，PO带领团队前进。这样的构建适用于200~300人以下的团队。
了解产品
要做好产品，首先需要让团队成员理解产品，建立共识。如果只见树木不见森林，那么人人都只是开发自己的那一亩三分地，根本无从得知自己的工作在整个产品中处于什么样的位置，那怎么能做好这个产品呢？现实中，这个产品有着非常复杂的架构，甚至没有一个人能完整地解释整个架构图。Ken建议SPO找几个资深人员，专门抽出一天时间给所有人都讲清楚架构。这很重要，如果你连孩子是男是女都不知道，怎么抚养ta？团队成员需要非常了解产品，而不仅仅是某个需求或者某个版本。要做产品，不是为了做事而做事。同时，Ken也建议所有成员都花时间在架构课之前自学其中的一些重要技术，以便让自己能够在架构课上更加清除对方究竟在讲什么。也就是预习，省的回头听不懂。
日程管理
接下来用倒推法确定迭代截止日。假设产品5月底上线，需要提前一个月也就是4月底出beta版。需要3周的SIT时间，所以差不多是4月8号所有迭代完成。如果每两周一个迭代，从下周一算第一迭代开始，扣去春节，那么正好有5个迭代。如何能保证按时交付呢？需求可能发生变化，环境可能有问题，心情可能不太好影响了效率。迭代的意义在于提早发现风险。所以每个团队成员遇到问题时，需要尽快把这个问题暴露出来，否则，按时完成是不太可能的。
估算工作量
因为是从瀑布开发模式转过来的，所以现在每个团队手里都有一大堆需求。这里使用估点的方式来估算每个需求的工作量，转化成各个User Story。先找一个清晰的需求，最好半天就能开发完成，再半天测试完成。对这个story估点为1。以其为基准，其他的story与它相比较，得到其他story的估点。估的点数是在一个斐波那契数列里的：1，2，3，5，8，13，20，40，100（当然后面几个不是）。例如基准story是3点，如果一个story感觉比它难上两个等级，那这个story应该是8个点。如果比它容易一个等级，那应该是2个点。如果难上4个等级呢？因为估点是个主观的过程，而且是比较不精确的。所以当差别很大的时候误差也会很大的。20，40，100这三个数虽然不是斐波那契数列，但也有它的含义。如果一个story只有一行字，谁也说不清它包含着什么，那就是100点。如果知道一部分，那就是40点。如果知道得更多，那就是20点。当然这也是非常主观且粗糙的，但是当你看到这3个数的时候自然就知道应该先把需求搞清楚。
值得一提的是如果一个story估点为8，并不意味着它需要在整8天的时候做完。这个story和其他story一样，需要在最短的时间内有质量地完成。8代表着这个story的复杂度，或者说它是一个风险识别指标。如果做这个story的时候出了问题，需要开发人员尽快把这个问题暴露出来，就像上面讲的那样。而PO、SPO应该要想办法解决这个问题。如果问题超出SPO的权力，那就需要SPO的决策–可以选择不做这个story，或者只做一部分，或者绕过去。估点往往需要很长的时间。为了效率起见，当Business Analyst讲完story时，团队成员应该有意识地思考：这个story有什么业务价值？是必须要做的吗？只有必要的story才估点。估点时新人由于还不熟悉背景，可以仅旁观不参与。参与的成员们同时伸手指表示点数，如果一样就记下点数，跳到下一个story。否则，大家就需要解释为什么自己估的点数是这个数，最后由PO拍脑袋做决策。
估点是个很费时，但又很重要的事情，所以先由一个团队演示几个story，其他团队观看，等大家都了解了，再由所有团队自行估点。
迭代计划
最后就是安排工作量了。先要确认所有人力是否可以100%地投入。资深成员可以算全职，新人算半职，资深成员但还兼其他工作安排的也算半职。假如说最后我们得到了这样的数：
- 全职开发：3个
- 半职开发：4个
- 全职测试：1个
- 半职测试：2个
如果第一迭代有10个工作日，那么我们就能计算出来最大工作量：(3+1)×10+(4+2)×10÷2=70。由于是春节，可能请假会比较多，扣去请假天数，也许得到60点。然后是打折，由各组PO和SPO商量，得到一个折扣。这个折扣可能是：我们组对外部环境依赖很多，第一迭代刚开始效率会很低，春节假期效率不高，团队成员都是单身需要相亲无心干活等等等等。比如说第一迭代打个7折，就能得到合理工作量：60×7=42。由此，我们就得到最大工作量和合理工作量。算出各个迭代的工作量，把它们写在显眼处。最后将先前估好点的story按优先级及依赖顺序往里安排，点数到合理工作量即可。至此，一个看似合理的、由团队成员做出的计划便产生了。项目启动会议完成。
