敏捷开发 —— 不知道做成什么样

原敏捷开发 —— 不知道做成什么样

您目前处于：在京东 2014-07-11

敏捷开发

张松然作者

张松然。2011年接触敏捷，熟悉Scrum、Kanban、XP和CI等敏捷开发模式。

问题

Standing Meeting

之前7~8人的早会，大家都很爱发言；现在15~20人的早会，每个人都不爱说话啦

当团队大了之后，且之间合作密切的时候，SOS也不会很好地解决问题

Planning Meeting

1. 计划会议之前没有设计评审，故事拆分都是调研、设计、开发和测试，评估2周开发，这和瀑布开发有什么区别？迭代过半之后基本没有指导作用

如果一个Story拆分出Task A、B、C、D，迭代开始后发现还有Task E、F、G，那么至少可以确定设计和拆分有问题，如果把设计、开发作为Task，那么根本不能确定是什么影响了故事延期

2. 产品没有PRD，仅仅有一张原型图，开发之后别人基本不能维护，自己看着流程也恶心；文档也许当时开发的时候效果不大，但后期维护的时候作用明显

—— 最早与PC开发留下的API文档，后期移动开发时作用很大

Sprint

1. 之前7~8人开发每个人都知道彼此开发什么、上线什么；现在只要彼此没有关联，做一个项目也不知道彼此在开发什么

2. 由于看板每个Story没有实质的Task，造成开发混乱、上线混乱，不怪测试人员喷胡来

计划会议拆分任务应该依据设计，不应按照瀑布模式，否则就是给了一个时间点去随意做（加上没有PRD的话），后期基本没有指导作用，计划会议应事先给出设计，不能只有一张原型图。

解决

1. 迭代后期，PO开始考虑下个迭代Stroy内容 —— 放到 Sprint Backlog

意在知道做什么

2. 在Planning Meeting之前，确定意向Story —— 自组织小组讨论Story得出结论，得出Task小样 —— 达成一致

意在知道做成什么

3. 在Planning Meeting上，由产品或测试对Story讲解，有Team评估 —— 放到TODO

意在确定做什么及做成什么

且行且摸索