为什么我的敏捷项目有如此多的问题？

OK，敏捷哈。不争论什么是敏捷。我们来看一些现象，然后你来告诉我，你有没有遇到过这些问题。

没人提真正的Feedback

每个迭代结束之后，我都会做Showcase。但是从Showcase上收集到最多的，就是UI的问题，字体太小之类的。每个Release发布之后，项目都会部署一个试用版本。但就是不见真正的用户来“试用”，就更别提Feedback了。敏捷不是强调Feedback吗？客户（Customer）时间不够，同时他们也不是最终用户，提不出足够有深度的Feedback。而最终用户呢，压根就没兴趣。

架构咋弄啊

每个迭代都要被催着出东西，哪里有时间弄架构哦。一开始就一个劲的加功能。前几个迭代大家都很Happy，功能出来的特别快。后来就越来越慢了，团队情绪也很差。

客户说没有不是Must Have的

事情实在太多了，做不完呀。那让客户来排优先级吧，把哪些是Must Have的找出来。但是客户说了，这些都很重要，没有这个Feature，或者那个Feature系统就压根没有用处。

路漫漫其修远兮，我到底在往哪走

团队的成员越来越多地在抱怨，天天做Story。但是这些Story都是干什么用的呢？这做一点，那做一点，根本就整合不到一个Vision里去。客户说，我给了你Vision啊，你看这个Feature那个Feature，这些要做的东西就是我们的Vision啊（心里还在犯嘀咕呢，你们干活的吵什么吵）。

 

这些问题都有一个相同的最终根源。我们先来看最明显的Feedback问题。为什么客户和最终用户都不提Feedback？因为不关他们的事！做Showcase不过就是在眼前晃两下，有深度的Feedback不是那么容易及时地想到的。而Release又有多少是真正部署到产品环境的？最终用户一方面还用这旧的系统，天天忙着四脚朝天的，哪里有时间来试用我们的新系统呢？无论你是设置了一个测试机在他的桌子旁边，还是一天三次的发Email提醒。只要你的系统不是完成他工作必须的一部分，他就不会理你。

为什么Release出来的系统不能部署到Production环境呢？这不是很奇怪吗。是的，确实很奇怪。但是，假如你是客户，你被你的组织委任了一个替换现有系统的差事。现有的系统有100个功能，完全开发完这些功能可能需要两年。但是，每三个月都有一次绩效考核。你会不会希望每三个月，就让领导看到你都弄出了点了啥？于是你找到了一个号称可以做敏捷开发的外包公司，要求他们每三个月给你出一个版本。但是这个版本能真正上Production么？不能！现有系统有100个功能，那么多用户在用呢。你三个月弄出来的系统怎么替换这么大一个系统啊？一个“成熟的企业”，对于一个这样系统的GO OR NOT GO MEETING都要开三个月呢。

也许你要说，我们是真正的Green Field开发，彻底重头写的。那么有你开发的系统之前，这家企业是怎么运作的？至少有一个Paper Process吧。没有电子系统，人们就用纸笔，各种单据来工作呗。IT系统不过是Paper Process的自动化而已。再说了，这年头还真没几个请得起我们，而且现在还没有一个IT系统的，需要从Paper Process开始的？

除非你做的是非常有创新性的企业开发。通过创新性的IT系统，开发新的业务。比如通过新的交易应用来辅助新的Margin Loan产品的市场投放。大部分时间来说，我们都是被引入进来“替换”现有的Paper Process，或者现有的遗留应用的。

 

假设我们要替换的就是一个有100个功能的遗留应用，我们是怎么来“玩”敏捷的呢？基本上来说，我们假设了一个温室的环境。在这个环境里，你可以假设你做的是Green Field的开发。把100个功能，分成多个Release，每个Release又分成多个Iteration。在每个Release之后都会发布一个Pilot版本给测试用户试用。这样就可以迭代式地添加Feature，直到最后能够替换原有的系统。从我的经验看来，正是这种做法，部分导致了以上问题（甚至有些情况下是根源）。前面已经提到了，这样会导致缺少来自最终用户的，真正的Feedback。其次，由于少了一个Feature都无法替换旧的系统，客户很难做出优先级的正确选择。以替换旧的系统为目的，所有的Feature都是Must Have。同时这样会导致每个Release缺乏明确的，唯一的Goal。经常是这个Feature做一些，那个Feature做一些，Team会觉得没有明确的目标。

 

如果我们不以替换旧的系统为目标？那么应该以什么为目标？这个时候你可以去看看Eric Evan的Strategic Design。他说，你应该想想What drives you to spend million dollars on this project in the first place（你为什么在最开始要在这个项目上决定花上一百万美元）。这个背后一定是原因的。基于对这个原因的理解，我们可以选定一定的Feature来实现。然后就开始实现，然后把实现部署了让所有的用户去用。用这种策略，而不是前面那种策略，这样就逼着我们去做很多事情。而我相信这些事情，很有可能就有助于解决前面四个问题。特别是，其中的架构问题。为什么呢？架构是什么？架构就是对问题的一种分解方式。怎么样才能迫使我们去思考架构问题呢？在现有的系统上打个洞，然后挖掉一块，围一道墙，里面再把新的Feature做出来。没有对系统整体的了解，没有对模块的分解，没有对模块之间耦合依赖关系的分析，是不可能做到这些的。这样就迫使我们做出一个低耦合高内聚的架构！

 

把这种策略做到极致就是之前我说过的持续部署才是王道。不但每个Release都和旧的系统集成起来，然后真正的部署。甚至，我们可以做到每个迭代都部署。在Fred George描述的团队里，甚至都没有迭代。一个Feature开发出来就立马被部署了。

评论

5 楼 toafu 2011-04-17  

我的理解是，持续集成和交付也解决不了人的问题。

4 楼 kong_desheng 2010-03-15  

写得比较实在，中国软件企业中很多项目，都是像这个项目一样，从一开始就注定要失败的。
我个人认为，这样的典型项目，其失败的主要原因有：
1） 需求分析不到位。客户具体需要什么，研发团队没有深刻而完全理解清楚。而依赖客户把需求都说清楚，根本不切实际。
2）没有优秀的软件架构师来设计、控制整个系统的架构。以为敏捷了，就不用架构了。
3）需求失控。什么都想做，各种功能特性被不断加入到开发计划中，每个特性都实现得一团糟，代码质量无法控制，项目一再延期，团队士气低迷。
4）敏捷：敏捷是一种软件开发过程，而软件开发能够成功，根据上讲，取决于项目团队成员的技能，包括需求分析技能、需求管理的技能、系统架构的技能、软件编码的技能、测试的技能等等。在中国搞敏捷开发，需要在对软件研发管理有深刻理解和丰富实战经验的人的领导下进行，方有成功的希望。

3 楼 andyhu1007 2010-03-10  

深切理解你的这些感受。说白了，谁都不会太关心跟那些远在天边而不是跟当前利益相关的事情。

2 楼 agiledo 2010-03-10  

我的一些意见：
架构－需要有高水平的架构师角色，架构不是3个臭皮匠就会赛过诸葛亮。
Feedback：客户只会做利益相关的事情。所以同意你的说法，部署。不是“potentially shippable", 而是“shippable”。只有在线使用，用户才会反馈最痛的问题
Must have：我也遇到同样问题，我的做法是拆分故事，直到我们团队可以保证质量在一个sprint内完成。拆分任务是SM和PO很重要的事情

希望和你多交流。
另外，我们团队实践敏捷开发（Scrum），有一些做法和教训，希望和你分享：
公司背景：通讯公司，团队最初不了解Scrum，开发团队有最初的几个人发展到几十个人。由一个Scrum团队发展到多个Scrum团队，有专门的PO团队。。。

目前文档完成的内容包括：
团队建设、评估会议、Sprint 计划会议1、Sprint 计划会议2、每日例会、Sprint 评审会议、Sprint 回顾会议、质量保证、经验总结、Product Backlog、过程监控、部署、SM的角色、PO的角色、沟通、教训总结、典型问题、32人的Scrum团队
完整内容共81页，28M；完整版可以在www.agiledo.cn中下载。

如果您对细节有兴趣，让我们讨论、不断改进。

我的联系方式：（Andy Yuan 袁斌）
邮件：[e-mail]；[e-mail]；
MSN：[e-mail]；
手机：[phone];
QQ:908235532

1 楼 orcl_zhang 2010-03-10  

引用

而最终用户呢，压根就没兴趣。
这些问题都有一个相同的最终根源。我们先来看最明显的Feedback问题。为什么客户和最终用户都不提Feedback？因为不关他们的事！做Showcase不过就是在眼前晃两下，有深度的Feedback不是那么容易及时地想到的。

我很关心你们的需求是如何做的？我在想，既然客户对新系统不关心，那他搞新系统干吗？
我觉得对于敏捷开发，最重要的是先对需求有一个大体的正确的理解。
当某个模块或者功能需求确认80%以上，或者可以满足开发条件的情况下，以简单的方式把需求实现。
然后在以小版本release，用户反馈的方式来挖掘更深层的需求。

引用

也许你要说，我们是真正的Green Field开发，彻底重头写的。那么有你开发的系统之前，这家企业是怎么运作的？至少有一个Paper Process吧。没有电子系统，人们就用纸笔，各种单据来工作呗。IT系统不过是Paper Process的自动化而已。再说了，这年头还真没几个请得起我们，而且现在还没有一个IT系统的，需要从Paper Process开始的？

这个感觉是个梦想。。
我们现在做的这个项目，客户比较关心。但是由于公司年轻，刚成立，项目组也年轻，刚组成，组员经验也不多，都是刚从java，c++转来的，而且没有敏捷开发的经验，也没有和客户挖掘需求的经验，所以请了外援来。存在的问题主要是经验和团队配合，不过经过这个项目大家都成长很多。客户这边比较配合，我们也是针对某些问题发布某个release，然后客户feedback。这些都比较顺利。比较严重的就是项目的每个release都比较延期一些。