落地敏捷典型问题：新产品开发的两大教训

落地敏捷典型问题：新产品开发的两大教训

 

我在2004年开始用敏捷开发的模式带领团队快速交付，一路走来有很多的经验，也有很多的教训。这里分享两个曾经的失败教训：

 

 

1. 没有正确理解PO角色：PO要和客户直接沟通，要能真正代表客户意图，否则产品很可能失败

 

 

关 键的客户沟通不到位，导致快上线了，客户认为的关键功能PO都不知道。产品开发之初，公司没有产品负责人（PO），也没有敏捷开发模式，完全是业务部门和 客户直接沟通，然后反馈给研发部门。当时的问题是业务部门没有时间和研发部门沟通，往往是一页纸的需求，细节也没有和客户沟通清楚。后来公司成立了产品 部，业务部门把需求反馈给产品部，由专职的PO和研发部沟通需求。请注意信息流转的方式：客户 -> 业务部门 -> PO -> 研发部门。确实，需求非常清晰，研发部的质量也不断提高。但是，最大的问题出现了：客户的需求经业务部门转述后偏离了客户的本意，产品部又没有和客户直接 沟通，Sprint之后的Demo业务部门也没有和客户沟通，需求的偏离在不断的积累...在敏捷开发中，最终客户必须要参与到开发过程中，特别是 Backlog和Demo。PO不代表客户，特别是PO不是和客户直接联系时，这个问题就会出现。

 

 

2. 不要认为会给研发团队很好重构的时间

 

 

产 品开发之初，为了尽快上线，产品的技术架构、性能、负载均衡、高可靠性等均没有考量，总认为可以不断的重构，但实际上公司根本不会给团队一个完整的时间去 做重构，不断的业务需求占据了团队几乎全部的时间。于是脆弱的架构越来越弱，完成一个新的需求需要越来越长的时间。现在总结一下，架构的高扩展性和稳定性 是最高的优先级，可以满足业务需求不断扩展。网站的性能是次优先级，特别是登录前的静态页面。CMS（content Management System）也是很重要的，最好在项目的前期就做，可以选择外包的方式，否则大量的页面修改，要根据发布流程，业务部门会不断提出申述…所有这些需要在 Sprint0阶段就要考量清楚，实践中Agile Modeling确实是实用的。

 

 

评论

4 楼 袁斌_AgileDo 2013-03-14  

lixin3811的意见和我们之后的做法相似，特别是发现了重构的重要性，我们专门有一个“技术专家”小组来完成需求中的技术预研和重要重构的技术准备，同时成立“组件小组”来提供各个功能小组的公共组件，功能小组负责提交业务需求和重构实现。这里有我们具体的组织架构
http://kan.weibo.com/con/3521290120422910

Sprint0中要完成架构的总体设计和根据业务需要的实现策略，然后在后续sprint中逐步实现

3 楼 袁斌_AgileDo 2013-03-14  

很赞同o6z兄的意见。在研发过程中，研发团队需要把重构的工作作为技术需求提出来，和业务需求同时作为正常的工作，估算工作量。只是很多时候研发部门没有业务部门更加强势

2 楼 ozzzzzz 2013-03-14  

通过业务部门跟客户沟通，基本上可以算一个反模式。除非有及其特殊的情况，比如军事保密项目，否则一定不要这么干。

根本就不存在什么重构时间，就更别提什么重构阶段了。重构是一个持续的，分散在开放全过程的实践。架构是重构出来的，框架是重构出来的，性能是重构出来的，负载均衡也是重构出来的。现在的开放基本上都是建立在流行的框架下的再次开发，这就需要我们对原有框架有深入的认识。而性能和复杂均衡，也是靠平时的积累，也不是运维的经验。单纯的靠开放团队临时找办法解决，基本都是会失败。唯一的办法就是在早期就注意收集资料，努力弥补开放团队的不足。公司在这个时候应该有专门的人负责这样的工作，从而建立起一个持续存在的资料库和知识库。

要给业务部门以压力，不能什么需求都提，而不选择需求的重要排名。基本上这个东西，是决定项目成败的关键。有的时候就是客户自己也未必真清楚各个需求之间的关系，也不能说出重要程度的排序。这个时候就需要业务部门来解决这些问题。业务部门不能仅仅是跑市场，也需要了解行业和研究客户。

1 楼 lixin3811 2013-03-13  

关于第二点，我非常赞同。对于所给出的解决方法我个人觉得需要商榷。
虽然新需求开发会占用大部分开发人力，我觉得重构可以随时随地的进行，并且有些课题，可以交给专门为此组建的小组负责重构，不一定占用大量的开发人力。
我非常赞同"架构的高扩展性和稳定性 是最高的优先级"，我觉得优先级并不是时间优先级。在第一个Sprint中，不需要也不应该一步到位的给出最终的架构，或者说，架构也是有从弱到强、由简单到复杂的过程。