问题：
1）需求变动频繁
2）过多反功
3）及时交付困难
4）项目资源投入不足
5）上线质量不足
6）迭代故事点难以确认。
本文主要研究的是迭代中关键瓶颈与故事点设立的一些想法，很多不足，当作日记。
后果：
1）任务时间的博弈
2）拥抱变化与频繁反功的矛盾
3）迭代过程混乱，流程很难把握。
软件行业项目风险主要瓶颈在于需求的变更，需求变更影响最终结果占比通常都在8成以上。这个可以用一次头脑风暴反复验证，这里不在赘述。
经验：
任何系统工程都会有业务互相依赖，繁琐叠加。
第一步：确认业务关键链
这是避免业务细节变化影响整体架构。同时集中力量解决关键问题，使得并行开发变为可能。
第二步：架构关健链挖尽关键链行为
软件架构虽然建议覆盖8成的行为与2成的类
但是往往系统过于复杂细节行为层出不穷，设计的类属性行为都是时刻变化，所以现实情况如果选择敏捷开发，是没办法完全做到总体规划完备的。
第三步：非关键链迁就关键链
不仅仅资源让步，开发优先级，产品需求细节解读都要对关键链进行偏移。
第四步：关键链开发
下任务清单让技术人员进行迭代关键链。遇见非关键链环节打mock跳过
第五步：回到第一步继续寻找关键链
关键环节找到如果剩下需求池里面也存在相互依赖的关系则优先顺序考虑。当然基于目标管理：业务需求总体优先应与公司对该项目的总体期待顺序吻合，做正确的事不做容易的事。
可以同时并行的任务：关键链各个环节。非关键链可随时随着人员增加而开展。
本流程借鉴TOC瓶颈与问题充突的一些理论。实践过程中是需要精益项目管理与敏捷方式进行辅助。
网友评论