这篇文章和《PDA感悟》一样，是对一年前学习到的相关知识的一个应用反思。
写它，是为了完成每月反思，也是为了完成我这个月的目标，更是为了积累项目流程经验。
之前已经看过刚进公司的时候，由于项目组需要使用 Scrum 作为流程来进行软件开发，所以当时看了一遍《Scrum and xp from the trenches》，主要目的是了解 scrum 中的主要内容，以促进早日融入项目组，并写了一篇介绍 Scrum 的入门级别的文章：《Scrum 大白话总结》。
至今，时间过去了也有一年多了。在这一年多里，项目组不断使用 Scrum 进行开发，但是总是感觉有些地方不太对，没有想象中的“敏捷”。直到最近两个月，问题慢慢地突显出来了，“需求不确定”，“估时无章法”，“辛苦回顾的结果不落地”，“会议常延时”，“计划会议难以把握个人重点”……等。
敏捷的团队，需要敏捷个人，身为团队的一份子，有责任去不断反思敏捷团队中所存在的问题，并提出自己的书面建议。这些流程反思不只是PM的责任，更是身处一线的开发人员的责任，否则，被动等待的团队如何能做到敏捷？所以，我决定对项目组中目前所遇到的问题进行归纳总结，并提出个人的相关建议，希望会对项目组有所帮助。在这之前，我不得不先再次重温《Scrum and xp from the trenches》一书中的知识，整理别人为什么能做成功，而我们的流程却有许多问题。
书籍知识整理
由于该书90%的内容都在讲他们的团队是如何实践 Scrum。所以，这些内容都是来自他们的亲身实践经验，有很大的参考价值。
另外，基于对项目组有帮助的目标下，我只从原书中摘抄出了部分相关的理论方案。这些方案并不一定适用每一个团队，但是它们一定有它们成功的道理。
- 关于 计划会议： 会议开始前，PO要准备好接受各式各样问题的挑战。 计划会议开始时，应该宣读本次会议议程，并强调 Sprint 目标。
- 关于 Sprint 目标：强调商业价值。
- 关于 团队成员：一个敏捷团队，人数最好在3-5人。
- 关于 Sprint 长度：短迭代，意味着敏捷、更多的反馈、更少的错误。理论上，开发人员喜欢长迭代，而 PO 喜欢短迭代。
- 关于 Sprint 故事列表： 团队成员定夺最终的故事列表，不是PO，更不是SM。 那么，PO 如何影响故事列表？“重新排列优先级”，“划分大故事为小故事”，“缩小故事的范围”。 团队如何确定 Sprint 中的任务数？两个方案：“敏捷团队自身感觉”、“计算团队速度”。
- 关于 速度计算：分析历史完成量，计算出团队的专注度；计算迭代中的可用人天；相乘，得出最终速度。
- 关于 index card：好处有两点：每个人都能保持高度的参与程度，而不再只是掌握键盘的人；多个任务可以被同时编辑。
- 关于 Sprint Backlog：自行定义合适的格式，建议 Excel。
- 关于 Sprint 回顾会议：目标在于反思！在于长进！找到本期重点不足，并予以改正。
- 关于 测试阶段： 最小化测试阶段的时间。 开发完成任务之前的时间可以做的事：测试人员需要为接下来的测试做准备；编写测试代码；与开发结队；其它辅助达到 sprint 目标的事（这些事最好在计划会议中定义）。
我们的团队 现象与建议
流程是优化出来的。发现问题，思考方案，解决问题。
第一步就是发现问题。这要求有人关注流程，在流程进行时，思考并记录流程中存在的问题。虽然听上去很简单，但是仔细一反思，就会发现，除非有专门的人来做这个事，否则很少会有人不断记录流程中的问题。可能大家都发现了一些问题，聊一聊，不管当时出不出结果，过段时间就忘记了。最近几个 sprint，公司派了PMO部门的周姐过来监督团队流程。但是，我个人认为，这些事情是敏捷团队成员自己的职责。所以在最近的几个 sprint 开始，我开始使用PDA随时记录存在的问题。
以下，我提出我记录到的一些大大小小的问题。
注意，这些问题及方案是基于我作为一个开发人员的角度提出的，但是从不同的角度和立场来看，它们很可能也不是一个问题。另外，一些问题跟我们项目的性质有关，我们部门属于新产品研发部门。
需求方面
现象：
- 计划会议中，PO提出的需求不断受到开发人员的质疑。计划会议一度变为业务研讨会议，一些需求经过临时的讨论，发现有问题，被“丢弃”了，被“打回”了。
- 几位需求人员，在计划会议中，一些需求没有达成共识。
- 疾跑过程中，有时会发生临时需求更改的情况。本期迭代中的原型也在迭代中不断被修改。
问题分析：
主要原因在于计划会议中给所有人员展示的需求，基本都是上一期sprint中制定的，并没有一个较长期的思考。一个短期思考的产物，很难做到合理、全面、系统、无懈可击，所以会议中一些需求会经不住拷问。
建议：
- 需求先行，先做两到三期的Sprint Backlog。
- 需求组本身先开展需求评审会议。在计划会议前，完成一个较稳定的列表，其中包含 1.5-2 个 sprint 任务的 backlog，用于计划会议给开发人员讲解。
- 迭代中严禁需求变更。哪怕做错了，继续做下去！
- 不超过2周的短迭代，降低可能的需求变更。
会议时间拖延
现象：
- 计划会议较多时间讨论业务。
- 各种会议思绪乱飞，进入无关话题。
- 最近几个 Sprint，各种会议超时过多。
建议：
- 会议开始时，主持人说明会议的目标，并适当控制会议内容和时间。
- 多余的话题，记录下来，另起讨论。
- 相信需求团队，不轻易质疑。
回顾
现象：
- 回顾项没有落地。
- 过于遵循“章法”，好的、不好的、改进项都列满了。
建议：
- 目标：表扬、改进。
- 会议开始，强调回顾目标。继续使用原来的“回顾原则”。
- 挑重点回顾。少来几项，指定改进责任人。
- 回顾上期改进项的执行。
- 回顾项进入 backlog。
- 没有什么好回顾？散会！
最近，大家都发现，回顾会议的质量并不高。上次回顾会议，周哥 组织更换了形式，没有按照表格进行，而是大家积极讨论，感觉明显“敏捷”了许多。
估时
现象：
- 不知道怎么估。
- 好久没用任务拆分墙了……直接分了用户故事，回去自己贴吧。
- 最近的需求文档中说的是用户故事？这种故事比任务还小，没法拆啦～
- 好吧，好吧，一个模块一个模块估吧。
- 勇刚说，这种估时太扯了。
- 没法估，有需求的不确定性，有技术的不确定性。
- 果然，估时不准。
- 说不出我们每个Sprint的速度。
分析：
今年，部门开始使用新的 Sprint Backlog 格式，中途也发现了很多的问题。例如，整个 backlog 完全面向产品架构，与开发人员没啥关系，这怎么可能会有指导性。问题提出后，做了一些改进，但是还是对于开发人员来说，还是没有指导性。开发人员面向这个 Backlog 进行估时，无疑寸步难行。再加上任务板不再在任务拆分时使用，大家都无法把任务细化，直接一项一项backlog估时，要么大了，要么小了。
建议：
- 要拆！面向逻辑任务进行拆分。任务项要可大可小，目标是开发人员能真正地在心中认可估出的时间。 （要是有公式就最好了，例如：我做这个模块都是体力活，20个类，一个应该是20分钟，那么一共是……）
- 不确定性： 这个 Sprint 先出设计方案，下个迭代再实现代码。 大改动需要提前两三个 Sprint 进行准备，所以，需求当然也要先行！ 这样同时解决了当期任务依赖性的问题。
- 逻辑任务划分完成后，不要忘记于对应的 backlog 项进行关联，以防止断环。
- 做几个稳定的 Sprint 之后，开始计算专注度和速度。
最近一次的估时会议，我们使用了基于 OEA 框架开发的新工具 GPM 来进行任务估时。个人感觉效果不错：当次 sprint 估时大概使用了两个小时，估时的时候能做到尽量拆分到开发人员心中的粒度，并进行时间汇总。但是，测试人员反馈无法出日报了，逻辑任务没有和 backlog 进行关联。所以我们又在任务上添加了“关联 backlog 项”及“实际完成时间”。以下是软件截图：
（这里也体现了 OEA 框架的威力，这个工具的开发时间一共1小时。相关内容，园友可以看这里：《OEA 框架演示 - 快过原型的开发》）
计划会议抓不住个人重点
现象：
- 增加了两名开发人员，我们没有对过程进行任何改进。
- “这块需求应该不是我的，我没必要听得那么仔细”。
- 我在看PDA……我在打嗑睡……我不参与这一块的讨论……
- 讲估算，除了智哥，大家都闲着。
- 需求宣贯完毕，开始拆分任务。任务分配到开发人员头上，开发人员还是不知道具体要做什么。“明佳，这块再给我说一遍吧”“明佳，这块是不是这样……”
- 我个人感觉太不“敏捷”了，慢死了……
分析：
我是这样想的：
- 没有必要每个人把所有的需求都完全吃透。
- 指定任务被放在了需求宣贯之后，导致所有开发人员在需求宣贯时，都不知道自己要做的是哪一部分内容。一天计划会议下来，很难保证持续不断的集中精力在每一个需求上。导致一些问题，例如：想着这个模块可能与我无关，我不需要那么关注，那么就经常会开小差，不参与讨论。最重要的一点是，需求的把握没有重点，分不清主次。到任务划分时，真正分派到自己头上的任务，还是不能彻底理解需求，问一些其实已经讨论过的问题。 团队人员越多，这个问题就越会显露出来。
- 一个问题参与讨论的人多了，反而更闹。
- 多个CPU（人脑），线性地完成一个任务（理解所有需求）；当然不如并发，让各CPU进行并发计算，只需要加个管理程序（促进沟通的方案）就好了。
这个问题和周哥讨论了蛮久。
周哥的意思是，这是每个开发人员的职责，如果同组的其它人在开发什么都不知道，那么肯定是不行的。
后来和勇刚进行了沟通，他说GEPS项目组使用的方案是开发人员轮换人员开发各自的任务。
建议：
- 人员多了，形式上，可以考虑分更小的组。
- 先以团队协商的形式，分好故事点，再为开发人员进行需求宣贯。
- 必须有个总体的需求宣贯会，保证所有人员都浅层次地理解其他人的需求及任务。
- 敏捷个人，把握好自己的需求。心中可以做好任务拆分。最后直接录入GPM中。
- 开发人员轮换完成任务。
总结
今年的目标中，有一部分是自己要学习管理，而学管理的目标是优化小项目组的流程，如何能优化好一个小项目组的流程，为以后的个人发展做准备。
这次的反思是我第一次反思整个项目组的流程，当然，这些也都是从一个开发人员的角度来提出的。这些思想和建议并不一定正确。但是，我相信，只要我们每个人不断地进行反思，并发挥好回顾会议的作用，提出自己的建议，我们团队的流程必然会越来越高效，越来越敏捷！
