敏捷开发 —— 不知道做成什么样
您目前处于:技术领导力  2014-07-11

问题

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

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

且行且摸索


本文受原创保护,未经作者授权,禁止转载。 linkedkeeper.com (文/张松然)  ©著作权归作者所有