如何进行需求任务分解和评估

需求列表是软件开发中至关重要的一环，为需求分解任务也是需求落地的重要一环

为什么这么说呢

1、要确保任务分解的完整性，也就是100%原则

2、确保任务是围绕完工定义的每一部分：已开发，已集成，已测试和已归档

3、评估任务所需要的小时数，确保开发团队的可用小时数跟估算是合理匹配的

在需求评审会议结束后，实际情况是这样的

该来参加评审的某一个环节没来，不知道该环节是否有遗漏的任务

来的同学对需求细节有疑问，疑问不解决，不能清晰的分解任务

能拆分自己所负责任务的，评估又不太准确，8小时?16小时?

这么多问题，斩不断理还乱，等逐一确认后，冲刺的时间过去一半了，懵逼了

怎么才能在敏捷中快到斩乱麻呢

1、敏捷的团队是全能型团队，咱们不是全能型，那么需求评审时请所有的环节参与评审，无论是否有他的开发任务(要注意评审的时间箱)

2、PO在评审前已经充分和开发团队沟通过需求了，对于不清晰的地方，不是这个会议上才发现。即使仍有疑问，PO也有义务为团队澄清细节

3、开发团队的目标应当是在不超过一天的时间里完成任务。有人评估80小时才能完成?what ? 要么需求太大了，还能继续分解，要么加资源并行开发。但是实话说，把任务限定在一天内完成，还是不太好实现的。可以根据实际情况调整成3天试试

对于团队在一个为期2周的冲刺内可以完成那些任务，怎么算团队的小时数呢?

给一个建议的公式：团队成员人数*7小时*9天

为啥是9天，不是10天?

因为第一天上午半天，要开冲刺计划会议

因为冲刺最后一天下午，要开冲刺评审会议和冲刺回顾会议

所以只有9天就是可用的，如果赶上节日期，从9天内减去，而不是往后顺延，破坏了固定的时间箱

为啥是7个小时，不是8个小时，6个小时?

这个规定不是死的，看团队实际的可用时间，有的团队可能一天就有5个小时的可用时间