敏捷过程在中国软件企业的实践——总结

 

接上一篇。。。。。。

 

乔峰：“经过了两个小时的谈话，我们讨论了XP的五大价值观和十二个实践，并且对它们进行了剪裁以适应我们公司的具体情况，基本弄明白了我们的开发团队需要什么样的开发过程，段誉，你总结一下吧。”

 

段誉：“好的，首先要确立我们团队的价值观，XP的价值观毫无疑问可以用来指导我们的工作。沟通的价值观无论对哪一个团队都是非常重要的，XP在沟通方面更强调口头文档的作用，而不看重书面文档，但我们应该两者兼顾；反馈的价值观能让我们不断的应对需求的变化，但XP反馈的步伐有些过小，我们可以适当放大；简单的价值观能让我们的系统始终保持敏捷和结构清晰，是值得我们去坚持的，但XP完全强调为‘今天而编码’的做法是有失偏颇的，在系统的某些地方我们也应该适度考虑未来的需求，这点我们要留意；勇气的价值观使得我们在系统的开发过程中敢于指出不足的地方，敢于去改变那些需要改变的，也是值得我们赞赏的；尊重的价值观也是非常重要的，如果一个公司、一个团队缺少了彼此的互相尊重，那也就意味着失去了凝聚力，一个失去凝聚力的公司必定是一个没有生命力的公司。”

 

乔峰：“说得不错，接下来说一说具体实践吧。”

 

段誉：“第一个实践是整体团队，我们每个项目团队的规模通常控制在12人左右，由项目经理、交互设计师、需求分析师、系统设计师、程序员、测试人员组成，大家都身处在同一个空间中，彼此座位相邻以便沟通；第二个实践是可持续的速度，我们的团队应该能够保持旺盛的精力、平稳的开发速度，以配合迭代发布的实践，但也并不是说我们完全拒绝8小时以外的工作，最基本的一条原则是不能超过我们承受的临界点，一旦超过这个临界点使得团队产生厌倦情绪，降低了团队的生产效率，版本的迭代发布也就无从说起了；第三个实践是迭代发布，今后我们的系统每一个或一个半月发布一次小版本让客户使用，得到客户的反馈，以此来提高应对需求变化的能力并作为项目进度的里程碑，每三个月发布一次具有价值、可运行的较大版本，与此同时，我们也必须牢记由于客观原因的存在，我们不可能完全去拥抱需求的变更，为了保证项目能够按时完成，我们也应该去控制需求；第四个实践是用户故事，因为我们没有现场客户，我们的需求不采用用户故事这种对需求的简单描述，我们还是采用详细的需求分析文档，采用用例驱动，并把需求分析文档交给客户签名确认，但为了保持项目的敏捷性，我们采用迭代式的需求分析，保证每次为期一个或一个半月的迭代开发的需要；第五个实践是计划游戏，由于我们没有用户故事，我们在每次迭代之前，让客户根据用例的优先级选定本次迭代的用例，然后再把用例分解成多个任务，由开发人员估算任务的完成时间并签单领取，每周进行一次进度的跟踪；第六个实践是结对编程，我们不采用结对编程，但我们的团队应该鼓励大家在遇到问题的时候，团队成员应该互相请教，坐下来共同解决棘手的难题。”

 

虚竹：“呵呵，说得不错。”

 

段誉：“第七个实践是简单设计，我们赞同简单设计和增量设计的理念，从设计上、编码上我们首先应该考虑最简单的方案，每次迭代的设计量应该以恰好满足该次迭代的编码需求作为界限，但我们不赞同完全采用XP紧急设计的理念，我们采用敏捷模型驱动开发的方法，为了保持项目的敏捷性，我们吸取Ruby On Rails惯例重于配置的思想，采用统一的建模标准、设计理念和技术架构，采用增量建模，在建模的时候我们保持模型的实际内容在满足项目要求的情况下尽可能的简单，我们创建很多临时的模型，一旦完成目的就可以丢弃，我们在系统足够简单不需要详细设计的地方采用紧急设计，提高项目的敏捷性，我们在系统业务逻辑比较复杂的地方利用各种模型从多个不同的视角描述系统，进行详细设计，达到明确无误传递设计思想的目的；第八个实践是代码集体所有权，我们不采用代码集体所有权，而采用个体类所有权，我们采用另外两个办法来降低个体类所有权的风险，统一的编码规范和代码审查；第九个实践是编码标准，毫无疑问，这是我们应该坚持的；第十个实践是测试驱动开发，我们部分引入测试驱动开发的理念，尤其是采用测试驱动设计的思想来推动预先设计的重构；第十一个实践是重构，对我们公司来讲，设计重构、代码重构和编码标准都应该摆在一个很重要的位置，由于我们长远的发展目标，我们开发的系统必须具有很长的生命周期，如果整个程序不具有良好的结构，很难去维护，那么系统的长期发展、不断进化也就无从谈起了，因此，在每一次迭代的结束，我们都应该留出一段时间对本次迭代的经验与教训进行总结，并且对功能模块进行重构，以保持系统一直处在良好的状态；第十二个实践是持续集成，我们采用独立的机器进行每天一次的系统集成及自动化单元测试，使得我们随时拥有一个能够运行的系统，随时可以得知新提交代码的错误，减少集成的问题，并且通过自动生成的代码审查报告来辅助人工的代码审查。”

 

乔峰：“总结得不错，今天我们共进行了两个议题的讨论，耗时共四个小时，都得出了一些有用的结论，已故的全球四大会计师事务所毕马威的CEO尤金·奥凯利在他临终的感言中说到，他的一生之所以会取得巨大的成功，总结起来就是三个词：目标、专注和执行力。现在我们已经有了目标，接下来该是专注的去做、去执行的时候了……”

 

经过了上面汉唐软件公司高层管理人员的讨论中，我想，各位读者可以清晰感受到敏捷过程的确能够给我们的项目带来一些活力，能够提高我们项目的敏捷性。回到文章最开始图1所描述的问题，究竟我们怎么样才能够避免图里面所出现的项目开发中的恶性循环呢？我们还是从软件工程的三要素说起，相信读者都还记得，软件工程的三要素包括了时间、成本和范围，在中国，软件公司和客户签订的项目合同通常都是固定时间或者有时间限制的，也就是说三要素中的时间要素是很难去改变的，那么我们只能在成本和范围两个要素中去着手，可能很多项目管理者一看到这里就会想到让开发人员延长开发时间，通过加班来解决这个问题，但如此一来又会陷入图1的怪圈里面了。

 

我们是否可以换个角度想一想，其实我们还有另外三个办法去应对需求的频繁变更：第一个办法是增加达到一定水准的人手，但很多公司出于成本的考虑、人员短缺或者人员水平达不到要求，往往很难及时满足项目组这方面的要求，并且人手的增加有时候未必能够起到立竿见影的效果，这点在《人月神话》里面作者已经给了我们答案；第二个办法是控制需求，尽管敏捷过程告诉我们要去拥抱需求的变化，但在项目完成时间不变的情况下这是不现实的，我们唯有在一定程度上去控制需求；第三个办法就是通过提高项目团队的敏捷性来应对需求的变化。这三个办法我们应该如何选择或者说如何组合呢？相信看了上面的文章各位读者都已经有了一些自己的答案。