文章目录
1. 背景
笔者没系统学习过敏捷管理，之前只是在所处团队中跟随使用，因此并没有思考过各个行为背后的原因。为什么现在要做敏捷管理的心得记录，是因为新被指派到管理一个敏捷项目的团队，成熟度几乎为0，百废待兴。看到各种问题（因为之前在敏捷团队中工作过，所以感觉非常不对劲），然后才去思考敏捷各个方法的实践，这个系列的文章，纯粹针对各个问题进行拆招，并无一定的顺序。
欢迎大家把管理中遇到的问题提出来，一起讨论解决方案
2. 团队当前的做法及遇到问题
目前团队有使用Epic以及Story，Story会根据颗粒度拆分成子Story，每个sprint会讨论包含哪些Story，然后Scrum Master就根据story管理进度了。
一接手这个团队，跟SM的沟通，SM说没办法管控进度，Sprint中的Story，如果有延时的话，都是到测试开始进入的时间，才知道原来开发没完成。
一句话：目前无法在过程中监控每个Sprint的情况，只有在Sprint结束的时候，才知道哪些完成了，哪些没有完成。
经过细节的讨论，发现目前管理如下
| 讨论点 | 当前做法 | 造成问题 |
|---|---|---|
| 是否有Epic | 有Epic，并且归类相对清晰 | 没有问题 |
| 是否有Story | 有Story，并且能根据客户需求归类 | 没有问题 |
| Story颗粒度是否细化 | 有细化到最小颗粒度 | 没有问题 |
| Story point是否估算 | 团队集体估算，但估算后的story point没有和开发人天联系起来 | 无法定义人天基准，就无法进行计划 |
| 开发及测试是否有Task | 没有task，开发及测试直接在Story上assign | 1. 工作任务没有明确划分 |
| 2. 整体上，不到最后，不知道前序任务是否超时 | ||
| 3. 并行任务无法体现 | ||
| 团队成员是否每天更新状态 | 没有，也无法做到，因为前后端，测试都是针对同一个story工作并指派 | 团队成员无处更新状态 |
3. 问题分析
抛开大的项目计划管理，在sprint的细节管理上，对每个sprint的task完成度及管控都是非常必要的，因为一般一个sprint的周期是2周，一开始3天就相当于过去30%的时间，5天就相当于50%的时间过去了。也就是一天不管理，就很有可能产生10%的偏差，半周不管理，产生的30%偏差，几乎不大可能在剩下的7天里拉回来。
所以敏捷提倡的每日站会这个原则，就是为了避免10%的偏差而存在的。
在本文案例中，因为所用的工具，没有细分到task，导致开发成员不去（也没地方）更新每日的开发情况，仅靠站会说自己昨天做了什么，及时是没遇到问题，也无法管理偏差分析的。组员不做，是执行问题，方法没制定好，是管理问题，所以要从管理制度和方法上进行解决。
对本案例中的问题进行一一分析
3.1 问题1，Story Point和工作人天混肴或工作人天缺失
因为只有使用Story进行管理，虽然从需求上分解了story，但在开发的过程中，不能将Story Point 直接向开发人天进行转换。而开发人天预估是很基本的管理基准，缺失了人天的预估基准，就无法对后续的工作进行偏差分析。
3.2 问题2，系统上没有将开发责任定位到人
一个story，可能涉及到前端，后端，通用模块开发及测试共同协作，目前是在story上只能指派一个责任人，任务安排就不准确，虽然SM在Excel上有记录，但这个记录就失去了管理的及时性。
3.3 问题3，开发团队成员没有地方自行更新状态
虽然SM可以时不时对成员进行询问，以便更新状态，但这样做很耗费时间，并且SM也很难坚持每天找各个询问状态
综合上述几个问题，造成了目前管理者无法对项目进行有效的管理。
4. 解决思路及原则
- Epic归类清晰，不需要改进
- 因为敏捷是没有风险管理，每个story要拆分到5天内能完成，这样在sprint结束时可以及时的给PO进行展示，如果团队理解及开发错误，在下一个sprint可以变更。目前的story粒度够细，可以在一个sprint内完成，这点暂时不需要改进。
- 需要将Story Point与开发人天进行明确的分离，并且表达不同的含义，以便进行需求与开发的管理
- 需要将任务指派到每一个人，在评估sprint进度的同时，也能从单个人的维度上分析每个人在sprint中的工作任务是否安排满。
- 每个人能针对自己的任务进行更新，SM及TL可以根据工作燃尽图就能知晓各个人的情况，除了站会成员反馈问题之外，可以主动对有问题的成员或任务进行关怀及指导（感觉这点对有很多新人的团队非常重要，因为很多新人不大敢把问题向上反馈，这里会涉及到另外一个问题：新人在更新状态时也不敢让状态变红，这个将来找机会再写）
5. 具体方案及措施
5.1 明确划分Story Point与人天的关系及用途
确定将Story Point作为衡量产品复杂度的标准，Story与Story横向比较，如果Story A需要50 Story Points, 而Story B为100 Story Points，那在管理Story的时候，可以很明确的知道Story B是A的2倍复杂度。
同样的Story Point，不同的开发者估算的时间可以不同，因为现实情况下，资深开发人员5天可以开发完的代码，菜鸟开发可能需要10天或更多。也就是说，一个50 Story points的Story，资深开发可能需要10人天，而菜鸟开发需要20人天。当然，这个可能涉及到每个人估算的正确率。比如资深开发需要10人天的，预估了8人天；菜鸟开发需要20人天的，估算了14人天，这个可以通过后续分析逐渐让团队成员对自己的估算更加准确。
综合来看，当估算正确的情况下，对于同一个开发人员，估算Story Points为100的任务，是比Story Points为50的人多花费一倍的时间。也就是说，对于不同的开发人员，Story Points/人天的比值，应该是一样的。而这个比值越大，代表这个程序员的效率越高。
5.2 使用Story与Task分别承载Story Point与人天，确定用途
明确了Story Point与人天用途之后，Story与Task的更高一步用途就可以定下来了。Story用来管理产品功能的基准与进度，Task用来管理开发的基准与进度。Story可以直接产生对外的汇报数据，而Task可以直接产生对内的管理数据。
Story与Task不一定成固定比例关系，比如一个大型系统，底层架构与核心功能task需要到达100%，可能Story的进度才为1%。或者一个Story，安排在一个Sprint的Task都完成了，结果验收不通过，那各个Task=100%，Story可能=0%或20%，这意味着在下一个Sprint中，要增加Task进行修改（当增加之后，Task整体完成度就<100%了）。但整体来说，当一个Story下的task都完成的时候，Story也应当是100%完成。
5.3 Task分配到人，以便进行管理
团队中每一个成员的工作都应该受到管理，因此，一个story在sprint中分配到3个人，就必须至少有3个tasks或者更多。只有每个人的任务都在系统中有体现了，才能进行下一步的管理。
5.4 团队成员每日都应该更新自己的Task使用时间和进度。
一开始的时候，估计成员没有养成更新自己task的习惯，这个已经与SM打好招呼，让她每天从系统上拉出一份报表，看谁没有更新的，提醒他在站会之前更新，希望将来能做到的是每天下班前更新，SM，PM及TL可以查看状态信息，以便在第二天站会的时候能有效的解决问题。
6. 总结
无论是瀑布还是敏捷，管理方式都是不断进步的，团队的成熟度，会影响方案及措施的执行结果，选择最适合的方法，才是最好的。