敏捷大会感言

敏捷感言

起初，我对敏捷软件开发认识不足，有些时候还持有偏见，看见谁使用敏捷开发，都想过去跟他辩论一番，想看看敏捷到底好在哪儿。有时候认为这是一帮年轻人，在激情工作的时候产生的思想，并且完全摒弃经验，它太年轻，而不屑于理会它，我这个人比较重视经验（很可能这样的人都偏向于保守），对身为年轻人的自己，我的心态怎么这么老？其实，去参加敏捷软件开发大会，我有点像打入敌人内部的间谍，伺机搞破坏，开个玩笑，^.^。我是有点想去看看这些人到底是真本事还是在搞概念，结果有点出乎意料，我被同化了，并且决定为其宣传，希望更多的同事加入到敏捷开发中来，做到真正的快乐（敏捷开发要求：做到真正的快乐）。独乐乐，不如众乐乐，何乐而不为呢？

周五下午和周六一天的会议，我也只是读懂敏捷的一些皮毛，到真正的登堂入室，还为时尚早。因此回来以后，补习了一下功课，重新认识敏捷思想。什么是敏捷呢？从管理学的书籍中找到了理论上给出的定义，“敏捷是指在动荡的业务环境中，适应变化并创造变化，从而获得价值的一种能力“。JimHighsmith在他的敏捷项目管理一书中如是说。“同时敏捷是平衡灵活性和稳定性的一种能力”。(Agilityis the ability to both create and respond to change in order toprofit in a turbulent business environment. Agility is the ability tobalance flexibility and stability)，单单从这个简单的定义上，对敏捷的实施，还是一头雾水。易经上讲形而上者为之道，形而下者为之器，毕竟涉及到敏捷，很少有人能先道而后器的。敏捷的思想在软件开发团队中应用，形成的宣言和原则如下：

敏捷软件开发宣言

人和交互          重于过程和工具

可以工作的软件        重于面面俱到的文档

客户合作                        重于合同谈判

随时应对变化               重于遵循计划

虽然右项也有其价值，但我们认为左项更加重要。

原则

1.      我们最优先要做的是通过尽早地、持续地交付有价值的软件来使客户满意。

2.      我们欢迎需求的变化，即使到了开发后期。敏捷过程能够驾驭变化，为客户创造竞争优势。

3.      经常交付可以工作的软件，从几个星期到几个月，时间间隔越短越好。

4.      在整个项目开发期间，业务人员和开发人员必须朝夕工作在一起。

5.      围绕斗志昂扬的人构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。

6.      在团队内部，最有效率也最有效果的信息传达方式，就是面对面的交谈。

7.      可以工作的软件是进度主要的度量标准。

8.      敏捷过程提倡可持续开发。出资人、开发者和用户应该总是保持稳定的开发速度。

9.      对卓越技术和良好设计的不断追求有助于提高敏捷性。

10.  简单——尽量减少工作量的艺术是至关重要的。

11.  最好的架构、需求和设计都源于自我组织的团队。

12.  每隔一定时间，团队都要总结如何更右效率，然后相应地调整自己的行为。

其实，算起来我已经进行了一次并不成功的“敏捷“尝试，因为我们经意或不经意的，已经把“敏捷“，融入到项目中来。

在目前的一个项目展开过程中，由于前期需求不明确，可以说需求是随着项目的进展，而时时刻刻都在细化和挖掘，在开发的过程中，项目团队其实是在选择核心的模块或内容来先开发。这个做法已经把scrum模型应用到项目开发中来。随着项目的进行，把原不明确的需求、现在慢慢明确的，加入到开发中来；这个发现过程包含了开发人员和测试人员一起的努力，发现的过程和结果都有点痛苦，因为我们不是刻意的去发现，还有些跟着需求文档走的做法，需求中没有的或不合理的，并没有刻意的去发现和纠正，而仅仅选择了去遵循。还有一些其他的原因在于开发时，对于不明确的需求，不知如何下手；部分开发人员不想接受在开发后期需求些许增加或变更的事实，有些怨。其实，我们一直想“敏捷“起来，但是缺乏相应的方法论指导，敏捷软件开发大会上FredGeorge给出的敏捷实践经验：要充分的合作信任，注重结果不要埋怨，我们提前体会到了。

由于人力资源严重不足，业务不熟，项目周期短，时间不充裕等客观原因的存在，在设计、流程、开发阶段我们都很想去“敏捷”起来，可惜没有正确的方法论的指导，算是一种不成功的尝试，为以后的应用积累了丰富的经验。

谈到敏捷，就很自然的会谈到TDD或UTDD（UnitTDD），但是究竟有多少个公司在采用TDD方法来写代码？而在采用TDD开发方法的公司中，又有多少程序员在全面使用TDD方法呢？TDD是一个纠结的问题。一方面，TDD的确是一个好东西，先写测试用例、后写代码，保证程序员第一次就把代码写对，也彻底解决了代码的可测试性问题，在代码层次上把缺陷的预防做到淋漓尽致。另一方面，多数项目很紧张，不可能给程序员足够时间去实施TDD，程序员对实现有极大兴趣，而对测试缺乏兴趣，多数程序员也不愿意或不会主动去做TDD。这样，TDD实践还存在较大困难，有比较多的争议。贝尔实验室有句统计意义的名言：

在系统测试阶段找出并修正bug，要比开发者在开发阶段完成这项工作多付出2倍的努力。而当系统已经交付使用之后找出并修正bug，要比在测试阶段多付出9倍的努力。

--LarryBernstein

贝尔通讯研究院

开始敏捷，还是先从TDD或UTDD开始吧。等“敏捷“真中灵活应用于胸，达到孔老夫子说的，随心所欲不逾矩的时候，再随机应变吧。

任何方法论在实践的过程中，都要考虑到具体的实践环境。不同的情况下，敏捷的适应能力可能会体现出不同的解决方案和做事方法。虽然，敏捷宣言中强调，人和沟通重于工具，但是俗话说水能载舟，也能覆舟，工具和敏捷的关系亦如此，下面我的几点经验：

●积极尝试新工具，如今的软件开发世界中，工具层出不穷，要不断与时俱进，了解最新动向和如何用有效的工具去辅助敏捷的实施，在自己的软件开发环境中去尝试和了解这些工具，尝试这一点很重要，不要只看说明或戴有色眼睛去看待这些工具，应该通过实践摸索找到最适合你的选择。

●人总是第一位的，要了解你的团队，了解他们的需求，有些时候甚至可以为了团队，冒险一下采用新技术、新工具，这样可以提高团队的凝聚力（敏捷要素之一）。很多时候过多的讨论其优缺点反而是浪费时间，不如多花点时间多试试。

●实施敏捷也离不开组织的支持，特别大型企业涉及到的人很多（可能水平不一），这时候推动者就必须用专业的手段建立一个持续渐进的工具引入过程，这样会使得实施更容易些。

信息论中，有个公式：信息的每一次接受与发送，噪音增加一倍，讯息减少一半。敏捷实践，完全把这个经验吸收过来了，其实敏捷有时候更偏向于管理-扁平化管理，最大限度的减少角色--只有开发和客户，提倡工程师驱动开发，减少沟通损耗，提高自我管理能力，这就要求你不要做太多的事情，并且要有一个高效的团队，也需要提高单兵作战能力。敏捷，就是加速自身的变化而适应变化的今天，要求今天比昨天要做的好，为明天做好准备，并且做到真正的快乐。

代码大全的作者SteveMcConnell曾称，他所见识的任何一本书都不是某一个人能完全独立即能完成的，吾深以为然。本篇提到的一些经验和感受，是融汇了在团队开发过程中形成的经验，和团队成员的启示，更多的是阅读其他人的经验，并提炼、学习，并实践之的结果。

最后记住，忘掉自己的特长，专注于解决问题的最佳方案，而不是用你的特长去解决；在产品方案的选择上，每一个细节做到最优；关注产品95%的功能，不要在无谓的细节上纠缠不清；用数据说话，永远不要讲，大概，可能，或许之类的词；最后提高自己的境界！

谢子轩

2011-9-8