[个人心得]敏捷管理Agile中Epic, story 和task的用途和管理目标

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. 解决思路及原则

1. Epic归类清晰，不需要改进
2. 因为敏捷是没有风险管理，每个story要拆分到5天内能完成，这样在sprint结束时可以及时的给PO进行展示，如果团队理解及开发错误，在下一个sprint可以变更。目前的story粒度够细，可以在一个sprint内完成，这点暂时不需要改进。
3. 需要将Story Point与开发人天进行明确的分离，并且表达不同的含义，以便进行需求与开发的管理
4. 需要将任务指派到每一个人，在评估sprint进度的同时，也能从单个人的维度上分析每个人在sprint中的工作任务是否安排满。
5. 每个人能针对自己的任务进行更新，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. 总结

无论是瀑布还是敏捷，管理方式都是不断进步的，团队的成熟度，会影响方案及措施的执行结果，选择最适合的方法，才是最好的。