[原]关于敏捷方法的一次沟通记录

        2012年12月8日晚上，和两位朋友聊天，他们从国外的大企业工作了多年，回国创业，成了一家软件，按照敏捷的方法进行了2年的软件开发，在实践中有些具体的问题，大家在一起进行了沟通讨论，从敏捷方法的文化，到敏捷方法的具体实践的做法，沟通了大概3.5小时，第1个小时的沟通我忘记了录音，后边的沟通我做了录音，根据回忆和录音，将讨论的问题做了整理如下，属于“非典型企业的典型问题”。

1在实施敏捷方法时，遇到了“形似而神不似”的问题，敏捷方法的“神”是什么？

          我总结为两条：质量与沟通。很多企业是没有把握住这2条，而导致敏捷的失败。先说质量：

        （1）      在敏捷方法中，多快好省四个字进行平衡时，首先是要固定质量，在固定质量投入的前提下，再去平衡进度、需求和投入，在剩下的这三个要素中，往往先裁剪的是需求！

        （2）      质量的含义包含了内部质量和外部质量，外部质量是用户可以感知的，是对需求的符合性。内部质量是开发人员所感知，决定了软件的易维护性。内部质量决定了外部质量，敏捷方法是二者并重的，而并非仅仅关注了外部质量，而传统的方法往往仅关注了外部质量。

       （3）      质量的管理首先关注质量的投入，质量的投入表现在质量管理的活动上：测试驱动的开发，静态检查工具的使用，结对编程，代码走查等。没有质量的投入就没有质量的产出。敏捷的方法对于质量的投入应该如何投入，给出了具体的实践，而并不是停留在概念上。

       （4）      提升软件开发效率的最有效的方法是减少不返工，一次做对是提升效率的最有效的方法，因此就要预防错误，预防错误的方法包括和开发人员对需求的理解达成一致，结对设计，测试驱动的开发，结对编程等。

        再说沟通：

      （1）      敏捷方法为什么可以少写文档，因为他通过口头交流的方式替代了文档交流！有哪些具体的口头交流的手段呢：在策划会议上项目组的成员对用户故事做了沟通和讨论，开发人员做了结对编程，每天开了站立会议，用户代表或产品负责人在过程中实时的做功能测试等等，这些手段都保证了在文档比较少的前提下，可以保证产品的方向、产品的具体功能不会偏离用户需求。

      （2）      在敏捷方法中沟通了什么？首先是需求、其次是设计、再次是进展、最后是经验教训！在需求方面沟通了对需求的理解，需求是否实现了，需求的沟通是重中之重。用户故事是用来讲的，是用户讲给开发人员听的，开发人员是否实现了听来的故事，是需要讲故事的人进行确认与验收的。对于需求、对于进展都要尽早的报告坏消息：需求理解错了；需求无法实现；需求实现错了；需求没有按时实现！

        在敏捷的宣言中讲到了4条宣言，在XP的方法中有4个价值观，在这些描述中我体会下来最关键还是这2条。

        对于每个开发人员要将上边的两条落实到他们的每个人的细节行动上，做这件事情你是否保证了质量，是否通过沟通减少了错误的发生。

 2 关于敏捷实践的团队文化

             团队的文化，就是互补的文化，就是互相配合，互相帮助的文化。在中国的教育体系中，从小学到大学都没有培养团队协同的思想与理念。每个人的单兵作战能力还可以，但是大家不知道如何形成一个团队，从项目经理到团队的成员都缺少这方面的思想认识或具体的做法。团队的文化中包括了积极主动的文化，互相协调的文化。比如在开站立会议时，就有人只是关注自己的工作，不关注团队中其他人的工作，你的是你的，我的是我的，而不是我们的。也有的人认为我的就是我们的，是我们的，就不是我的，不是我的我也就没有责任。

        如何形成团队的文化？

      （1）                在一个公司中，企业的文化首先是老板的文化，老板的一言一行影响了员工。我们可以比较一下联想、华为、富士康等企业的文化，你就可以发现这个结论。如果一个团队没有形成一个良好的文化，首先领导就要反思，是否自己的言行出了问题？

      （2）                小团队容易形成团队的文化，而大的团队形成文化比较困难。小团队靠人治，大团队靠法治。在敏捷的方法提倡小团队，其中一个好处，就是容易形成这种互相配合，互相协同的文化。

      （3）                文化体现在细节中，文化需要不断的进行重复强化。要从每个细节活动中去反思是否符合团队的文化。

      （4）                文化的载体有2个：规章制度与人。通过企业的规章制度体现企业的文化，通过以老带新来传承文化。

3 关于scrum master的重要性

           敏捷的方法看上去简单，实施起来的比较难，敏捷方法的实践少，但是要求每条实践必须做到位，做扎实，真要做到位就要求scrum master必须很熟悉scrum的基本原则与基本思想，简单的站立会议，有些scrum master就不能控制局面，一提到问题就讨论如何解决问题。可以写一个check list，在开站立会议前的1分钟，把站立会议的要点重复一遍，慢慢的把这些思想渗透到每个人的骨髓中。就好像文化大革命时，天天念毛主席语录一样。

            所以对于scrummaster而言要培养其基本的技能：如何主持会议？不仅仅要理解scrum的要求，而是要具备这些技能，公司里熟悉SRUM方法的人可以作为scrum master的导师，旁观scrum master的活动，然后指出其缺点，在实践中指导提升其基本的技能。项目组的成员也要重视每次迭代结束时的回顾活动，通过自我总结提高团队的整体能力。Scrum master并非固定的，是可以变化的，通过这种方式也可以发现团队中适合做master的人。有的团队每天站立会议的主持人是变化的，大家轮流主持，这也是一种很好的尝试，通过这种方法发现人才。

4 如何挑选scrum master？

            挑选什么样的人做master，选组织能力强的人担当，而不是一定是选择技术能力强的人，master的作用是要发挥整个团队的能力，激发大家的能力。不是scrum master有多强，而是整个团队有多强！

5 敏捷实践背后的道理最需要理解

           有些比较杂的任务，不够清晰的任务，比如写文档等是否适合采用敏捷的方法来管理？

在XP中有结对编程，适用到对客户的支持时可以借鉴结对的思想，如何保证质量？如果通过沟通减少中间记录，对于文档的编写我们可能不实用结对编写文档，但是我们是否可以对这个文档进行评审呢？在写文档之前我们是否对文档做了结构的设计呢，就象我们走系统隐喻一样呢？是否做了方案的讨论，我们都可以借鉴敏捷的实践过来，你也可以把他作为一个用户story，一个story就是一个需求而已。

            只要明白了敏捷的思想了，你只要类比就可以了，比如用户故事的四段论，看上去很简单，谁要这个功能？什么功能？为什么要这个功能？有了这个功能如何验收？不能假想功能，做了功能没有人使用，要这个功能要解决什么问题？目的是否明确？通过验收的标准进一步澄清目的。我们把这个思想类比到日常工作中，我们给一个员工下达一个任务时，常常发生对方没有按我们的要求完成任务，需要进行返工，尤其是布置任务的人比较繁忙时，往往是简单说了一句，布置一下任务就放手让别人去做事情了。如果我们借鉴用户故事的方法，我们可以这样给其他人安排任务，我想让你做什么事情，为什么要做这件事，你做完了以后，我会检查哪几点，这样的话就可以减少很多这种误解和返工。看上去用户故事是很简单的一条实践，但是你需要仔细琢磨这条实践解决了什么问题，他背后的道理是什么。

6  CMMI和敏捷方法的比较

             CMMI在做的初期往往编写了大量的文档，随着对CMMI的理解越来越深刻，与实际的结合越来越紧密，文档会越来越精简。

敏捷的方法再初期做的时候，往往感觉很简单，但是越做就会感觉到越复杂，一个很简单的活动如果想做到位，有很多注意事项。敏捷的方法会越做复杂。

             CMMI的实践如通白开水，没滋没味，敏捷的实践如果陈年老酒，需要慢慢咂摸，越咂摸越有味。

7 关于研发人员与测试人员的比例问题？

           开发可以转测试人员，测试人员转开发人员比较难。

           在敏捷方法中强调了2种测试：单元测试与功能测试。Po关注的是需求是实现了，关注了外部质量，开发人员关注了内部质量，易于维护，易于设计，在敏捷中首先强调了内部质量，其次是外部质量。单元测试在发现缺陷的手段中是排在第二位的手段，第一位的手段是代码走查。如果做好了单元测试，可以减少系统测试的投入。

           在很多软件公司中测试人员与开发人员的比例是1:2甚至是1:1，在系统测试上投入了大量的人力，为什么呢，因为前期的单元测试投入的少，从而加大了后期的系统测试的工作量。就如同一个足球队，安排了1个守门员不够，再去增加多个守门员一样。如果单元测试做到位了，系统测试人员与开发人员的比例不用强求。

8 关于用户故事

           非软件的活动的，技术的难点的解决都可以视同为一个用户故事，用户故事就是一个需求。

           如果不是用户提出的故事，而是我们自己提出的故事，应该越精简越好，先出个东西，先上市。

           用户故事是可以协商的。协商的是什么？协商的是验收标准！用户需求划分了优先级，验收的标准也可以划分优先级！

           用户故事如果太大，需要拆小。可以把某个验收准则视同为一个故事。故事不能减少，特性、验收标准可以减少。

9 关于开发速度

           欲速则不达。平稳的开发速度如何理解？如果提升软件开发的效率，不返工就能提高速度？如何不返工？在做之前做了充分的设计，传统的方法是写文档，评审，敏捷的方法是讨论，是三个臭皮匠顶一个诸葛亮。

           每次迭代结束后，大家做回顾，提升团队的能力，每次迭代结束后团队的整理能力应该有长进，开发的速度越来越快，越来越稳定，是个正反馈的自适应的过程。

          要通过成功走向成功来激励员工，每次迭代要能成功结束，而不是每次迭代都要会失败。每次迭代结束后要调整下一次迭代的开发速度，确保下一次迭代是切实可行的。

10 关于敏捷方法的质量管理

            领导是否意识到了欲速则不达？领导是否给项目组创建了一个敏捷的环境！很多公司在实施敏捷时往往是领导没有正确的理念，总是催促项目组加快进度，还是回到了快而脏的开发模式上了。

            在推TDD之前，应该先推代码的静态检查。每天的站立会议时，昨天的任务是否做完了，应该进行检查是否对静态检查出的缺陷都修复了。

            要训练开发人员消除“差不多”的思想，不要做什么事情达到差不多的状态就行了，而是要一次做对。开发人员在上学的时候就缺乏这种训练，在学校里写程序就是写一个能run出正确结果的程序就可以了，并没有进行完备的测试，也没有注重代码的内部质量。

11 如何使用高水平的人？

             老板很有水平，很明白，啥都自己干，下边的人时间长了就形成了依赖心理，就不会动脑去做事情了，高水平的人应该如何使用？如何充分发挥高水平的人的作用？就是让他去培养人，培养出高水平的多个人来，这才是价值最大化，这才能形成一个团队。否则鞭打快牛，最能的人最辛苦，别人不成长起来，就累死老黄牛。

            领导太能，怎么办？领导去培养一批人，培养一个团队出来，培养自己的接班人。