目前，在软件开发工程领域，敏捷开发流程已经逐步取代瀑布开发流程成为主流。敏捷开发流程的最大特点是以两个星期为一个开发周期（即Sprint）逐步进行迭代，从而更好的响应来自客户需求，UI设计或者技术方案的变化。Sprint Planning可以说是整个流程中最重要的一步了，在这一步会理清需求，消除尽可能多的不确定因素，从而确定下来整个Sprint任务的范围进而分配任务到个人，让团队能够稳定的交付。我目前所在的企业，开发流程采用了企业级的Scrum框架SAFe(scaled agile framework)，它相对于经典Scrum流程，增加了许多环节，其中一个就是PI Planning。PI Pllanning是针对一个PI，通常是6个Sprint中的5个正常的开发Sprint的范围作计划，剩下的1个IP Sprint用于PI Planning、Innovation和修bug等等。
初始认知
刚接触SAFe流程时，我最大的困惑就是关于PI Planning了。按照Sprint Planning的思路来推演，计划是为了消除变化，从而稳定的交付，那么计划的周期越长，不确定因素就越多，也就越难消除变化。一个PI的目标确定下来后，它工作内容的范围基本上是固定的，通常是不会更改的。相对固定的工作内容，一方面让响应变化的周期将从一个Sprint扩大的一个PI；另一方面，在PI Planning时，是会把要做的工作细化到把每个Sprint中去的，当PI Planning结束时，每个Sprint要做的事情也会有个大概，并且相对固定，那么Sprint Planning的作用会削弱，更偏向于任务的细化和分配。这样的流程中一个隐藏的困境就是一旦某个Sprint的工作因为各种原因滞后或者错误估计了，其实是没有多少调整空间的，要不就会影响后续的Sprint。关于这个潜在风险，SAFe的指导原则是，除了第一个Sprint需要排满工作量，后面的Sprint的工作量可以逐渐递减来应对一些预期之外的变化。这是一个好的建议，但是因为整个PI的目标是固定的，如果再加上如果整体开发工作的时间节点是固定的，这个原则就真的只起“指导”作用。于是，再高大上的管理流程，在干活的人眼里也只是“理想”，现实才是真实的。借用薛兆丰老师在得到专栏《北大经济学课》的一句话来说，“凡政策必遭遇对策”，开发团队的“对策”就是：
1. 重视PI Backlog Grooming，在PI Planning之前尽可能的发现不明确的地方，并尽可能的想办法消除。方法不外乎两种，要么自己研究，要么问明白人。
2. 合理的估计团队的工作能力，即Velocity。
3. 合理的协调PO(Product Owner)的期望。
前两条SAFe的指导原则中有提到。后面两条团队处理的好坏在一定程序体现了这是否是一个成熟的团队，没什么太好的方法，需要一定的时间，来慢慢磨合。如果这三条都没做好，那只能是自己挖的坑，自己填，硬着头皮上吧，需要加班就加班吧，千万别问不是说好的，跑了Scrum就会不加班了吗？嘿嘿
简单来说，那时我就是把PI Planning当大号的Sprint Planning来对待的。加上在公司的前几个项目，都比较独立，和其它的团队交集不是很多。于是，在相当长的时间里，我都觉得PI Planning有些鸡肋。
第一次迭代
这个印象直到去年开始做公司的下一代平台中的项目时才有此许改变。公司在下一代平台的项目上投入了很大的资源，方方面面有10多个团队工作在不同的子项目上，这样的项目背景是SAFe最适用的场景。PI Plannning提供了一个合适的窗口来协调各个团队之间的依赖，并分析潜在的风险。我试着用更高的格局来看待PI Planning，把PI Planning中计划的Feature类比为Sprint Planning中的User Story，参与PI Planning中的各个团队类比为参与Sprint Planning中的一个个成员，那么PI Planning其实是身处幕后的管理团队的Sprint Planning，只是他们需要通过各个团队的反馈来实现，而不是自己实现。再则，因为计划的粒度变大了(Feature通常有多个User Story组成，User Story又由多个Task组成)，所以计划的周期由两个星期扩大到三个月是合理的。顺着这个思路想，高管团队应该是通过管理团队的Release Planning来做他们的Sprint Planning，周期就更长了。回到团队的角度，作为要落地实施的团队成员，相对于Sprint Planning，PI Planning需要的考虑的因素多了，计划的粒度大了（即计划的是User Story，而不是Task），所以本质上还是存在当计划的粒度变大周期拉长，不确定因素概率变大的问题。我接受了这是一个限制，因为能够解决的问题是问题，不能够解决的问题就是限制，只能接受。按我的理解，一个开发团队走向成熟的过程就是和这个限制逐渐和解的过程。
第二次迭代
在上面阶段，我还一直在纠结计划和变化的关系，并笃定计划要以消除变化为目的。直到我在听了罗辑思维4月19号《计划的用处》的音频后，才终于领悟，计划不是用来不折不扣地实现的，它有以下三个妙用：
1. 计划制定的过程，本质上是一个统一上上下下的意志和决心，明确战略方向，盘清资源家底的过程。
2. 计划的结果是让临时应变者可以有一个资源框架可以利用。
3. 计划的结果是形成一个个小型的执行模块。
罗胖在那期节目中以公认的战斗力强、作战素养高的德军为引子，指出了德军的强大源自于战前作战计划的详尽。以施里芬计划为例，那可是详尽到每支部队每天要做什么的地步。而真实情况却如一位著名的德国将领所说的前半句是“一旦开战，所有的计划也就作废了”，他的后半句却是“但战前必须制定计划”。重点就在于上面提到的三个妙用，施里芬计划让德军上上下下都明确了要尽快结束西线战事，不能陷入东西两面作战的局面。同时一旦情况有变，战场中的指挥官可以基于计划作一些大体的预测，以原有的计划为参考执行下一步的行动，而不至于毫无方向，乱成一团或者原地待命。
回到PI Planning这个场景，团队在计划的过程中会对未来三个月的工作强度产生共识，对哪个Spring要紧一些，哪个功能要提前准备起来有了清晰的认识，即使哪个功能或者依赖的内容有所变化，团队也可以根据计划知道总体的进展情况，有其它的可做的功能，并在Sprint Planning时做出相应的调整，不至于陷入开发进度完全停滞的状态。这么相来，计划是为了更好的应对变化，因为对某些场景思考过，不是完全陌生的状态，遇到变化才不会不知所措。这与“拥抱变化”的软件开发思想不谋而合。转变了思路后，确实对接下来的PI Planning更加期待呢。
第三次迭代
这次迭代是受益于得到App的《李翔知识内参》5月28号的一篇文章《扎克伯格如何定目标》，文中总结了扎克伯格的历年年度目标的特点：
1. 重复做一件小事，比如每天打领带，每天跑步。
2. 它们都服务于扎克伯格为自己设定的大的目标：通过社交网络连接起每个人。
这种大目标和小目标相结合思路不就是团队成员每天的开发或者测试，实现Sprint的目标，进而实现PI的目标吗。PI Planning的结果就是那个大目标，那么每天默念一次PI Ojective会不会觉得更有动力呢？因为你是为了三个月后回个头来看，当初的设想都一一实现了，那一刻就是努力工作三个月的意义。
回到扎克伯格制定人生目标这个点，估计很多人都听到过要有人生或者职业要有规划的建议，我也是一样，最近还看过一篇如何设计人生思维导向图的文章。一开始确实热血沸腾，雄心壮志，但过了一天就有些意兴阑珊，进而不了了之，再没仔细想过。我姑且觉得是因为缺少可执行可跟踪的计划，在写这篇文章的过程中，我突然在想如果用敏捷开发流程来管理自己的人生计划，那会是怎样的场景？开始准备人生第一个PI Planning的Backlog吧。
附：我已开通同名订阅号 海之方，欢迎扫码关注。话说，申请订阅号比想像的简单的呢。
网友评论