作者：袁绍    来源：IT168

     不久前在广州，笔者参加了一家软件公司主办的关于软件项目开发的高层研讨会，其间有两个问题讨论非常热烈，值得与大家分享。第一个问题是：“有多少人的工作跟项目开发管理相关？”大部份的人举起了手。但第二个问题是：“有多少人了解软件项目开发精益管理的方法？”举手的人就寥寥无几了。

    精益管理的思想起源于丰田公司，归纳起来精益思想是在创造价值的目标下，通过改良流程不断地消除浪费。现已被广泛用于生产制造管理，但用于IT软件项目产品开发的实践尚属凤毛麟角。我们看到这个讨论的话题时，许多人发出了一种会心的微笑，在笑容的背后感到这又可能是一个外行人指导和领导内行人的炒作话题吧。但经过大家的研讨，发现在做IT软件项目开发的时候，也应该跳出本行业局限的眼光，看看外面其它行业的思想和方法，从中吸收有益的精华。

    精益，是一种思想，一种哲学，一个方法论，其精髓是拒绝浪费。我们IT项目开发学习的不是“精益生产”的形式，而是其精髓思想。这种思想，不仅可以用于生产，也可以渗透到IT软件项目开发中。在研究会上，我们讨论到一个借鉴了精益思想的IT项目开发是一个系统的观念。一般来说，IT软件项目精益开发系统包括三个要素，即人、流程和技术。以借鉴到IT软件项目精益开发来说，就是需要为IT项目的开发提出一系列的流程，培养技术队伍，运用最有效的技术和工具。同时，必须注意要把这三个方面整合在一起，成为一个协调发展的系统。

    例如在人的方面，精益思想强调如何将每个员工的能力发挥到极限，认为不应该只是简单的管理人，而应该去培训人。如果不能将管理的重点放在员工的培养上，就不能理解精益生产的真理。同时，精益生产的另一个精髓是管理过程，精益思想不是着眼于结果，而是强调过程。“只对结果管理”的管理思路的结果是员工对找借口、为结果辩护很在行，对数据、报告很在行，但软件项目成果的质量只有在全过程都有效控制下才能得到根本的保证。

    一. 建立顺畅的开发流程

    确定高效的IT软件开发流程，是精益思想开发的第一个精髓。

    如何创建一种高效、顺畅的软件项目开发流程？首先，精益思想提出强调“建立健全研发流程“。所谓精益软件开发思想包含了一整套的方法论和实施方法。精益软件开发将精益生产中持续改进的概念引入到软件开发过程之中，实现对软件开发过程进行精益管理。实现精益软件开发的核心在于：建立一套完整的开发流程，然后建立一套测量流程的手段，不断持之以恒地改善流程，不断优化，坚持不懈。

    不同的企业因定位不同，对于研发的价值理解也是不一样的，他们的流程和实现流程的工具肯定是完全不一样的。但我认为软件开发人员应当向丰田公司的产品开发流程学习和借鉴。目前，丰田内部的精益开发步骤是这样的：首先，在客户需求的基础上，对工作进行分辨，区分出哪些部分是能够满足客户需求的有效部分。如果工作中的某些流程生产出的结果并不能满足客户的需求，便是一种浪费，就不是增值的流程和操作。因此，精益开发首先需要了解客户需求。此后，需要对工作流程进行细化分割，把流程分成更细微的步骤，并保证每个步骤都能满足客户的需求，增加价值。

    其次是流程的标准化和可操作化，这是精益思想流程的基础之一。在软件开发过程中，每个企业的现状不同，因此产品开发的方式也不同。但精益思想提到如何关注研发流程，让管理流程“落地”，并要让流程规范起来，不再是像过去把好流程放在纸上，靠人去管理。固化和标准化开发流程就是一个方式。

    二．引入首席项目主管负责制

    精益软件开发的第二个精髓，是将合适的人员安排在合适的岗位上，建立一个有效的软件项目开发组织。首席项目主管负责制度是精益软件在人员安排上的核心方式之一。每个项目的开发团队的都心须确立核心领头人，并要突出了首席项目主管的角色和地位。

    首席项目主管必须非常清楚，他们接手任务之后，他就要开始考虑自己的设计思路，并把这个思路和团队交流。他的思路有两部分：一是勇于面对困难和挑战，当遇到挑战时可以这么做，也可以那么做，最终希望能在这些方案中达成平衡，而不是做退缩；二是要找到问题的根源。

    首席项目主管应该具备三个能力，这也是丰田的标准：首先是很高的技术水平，是一个能力非常出色的总工程师,而且要对产品有整体意识和远见卓识。第二，要有项目管理能力，要代表客户，理解客户的需求。第三，要有出色的领导能力。

    对于一个企业来讲，如果需要做软件精益开发，公司的结构也要做一些改组。精益思想建议采用的是一种矩阵式的组织架构。在这种架构中，团队按照具体项目和功能来划分，最大程度地使两者的优势结合在一起。比如说，首席项目主管整体负责一个项目，不同项目有不同的首席主管，他们可以组成首席主管团队。而对于各种不同的项目功能需求，又按软件不同的功能部分分组，负责每个功能小组的是职能部门经理，如某些不同项目可能用到共用的功能模块，各职能部门的工程师向该部门的经理报告，以实现按功能优化和同类经验共享。

    其次，精益思想除了强调首席主管负责制度外，还提到一个重要的关于人的因素是：团队是推进精益管理的关键。通过推行精益管理，建立一个基业常青的团队，调动起每一个员工的积极性，只有这样才能推动开发项目各项工作持续发展。建立一个良好的团队则是企业能否有效实施精益管理的关键。

    最后，精益管理的推进要以人为本，精益管理虽然有各种流程作为基础，但是运行这些体系和流程的是人。熟悉丰田精益方式的人都知道，丰田方式中一个很重要的内容就是人员管理，即“育成”。育是培育，成是成功，强调人才培养，把人才看作是人“财”。一项针对包括丰田在内的50家具有百年历史的全球500强企业的调查显示，这些企业的共同之处，就是拥有共同的理想、共同的价值观、共同的行为准则的一支强大团队。

    三．有效技术和工具的支持

    精益思想软件项目开发的第三个精髓，是用工具和技术来支持流程和人的工作。在引进新技术方面，丰田奉行的原则不是积极倡导新技术，而是使用可靠的、已经过充分测试的技术。工具和技术的意义在于支持流程，而不是驱动它；是加强人的工作，而不是替代人。

     无效的软件项目开发技术和工具会糟糕的在计划进度，成本和质量等方面带来失败，这将最终导致整个项目的失败。同时，没有有效的工具来支持会使项目开发处于非持续性和不完备状态。很多失败的项目中的教训揭示了能够充分地支持项目开发的工具简直太少了。很多时候，软件项目在没有监督和跟踪时都会变得失控。因此，要很好地完成项目，必须要有好的项目管理工具，进行有序的项目管理才能够实现。

    精益软件开发在这里提到两个观念，一是软件开发应用到的技术平台，二是开发过程所使用的工具。软件开发应用到的具体技术平台，由于每个项目的需求和资金预算不一样，所使用软件开发技术平台也是各式各样，不能一言而简之。但精益思想重点提到的开发过程中工具的选择和使用。工具不一定要追求最新的，最高科技，最昂贵的工具。反而应该不断发挥团队的智慧，结合开发的具体情况，不断探讨实用的工具，减少浪费。

    这里与大家分享一个有趣的例子，工具并不一定是最新的高科技的东西，有时它可以是很直观的方法。“大屋”是丰田普锐斯首席工程师想出来的一个工程合作方式。他把各个职能部门的工程师聚集在一个大房间里。在这里，他们把产品开发状态的信息打印出来，包括种种数据、成本、质量、进度等关键问题，贴在墙上，每个人都可以方便地查看、讨论。当他们在一个房间开会和沟通的时候，他们就更加融洽，交流得更好，更容易做出决定，从而缩短产品开发时间。“大屋”听起来很简单，甚至有点可笑，但是它支持了流程和人的工作，就是正确的工具和技术。

    所以精益思想强调，首先正确设计你的流程，然后再去找合适的工具让这个流程开动起来。不管是软件开发用到工作工具，还是别的工具，只要能够支持这个流程，就是合适的工具。

今天Craig Larman给大家讲了堂“User Story Splitting”主题的课，从什么是user story，与use case的区别，user story通常的描述形式，分割user story的常用方法等，直到使用公司内真实的案例来模拟splitting的过程。有收获，有证实，也有思维的触动。

其中有举到一个例子，比如用户需要DHCP的服务，那么可以分为fake的stub的DHCP功能，然后还有real internal的，还有real external的等等。但是，真正地管理这些child user story的时候，需要额外的小心，因为它们之间其实是有依赖关系的。不可能先去实现real internal的部分，然后再实现fake、stub的，一是浪费资源，二是可能也无法一次完成real internal，可能正是因为这样才会拆分成两个child user story。也不可能两个或多个团队同时分别实现某个child user story，彼此之间的依赖关系会给产品开发的管理工作带来麻烦。

另一个问题，这次workshop关于如何split user story讲得确实非常清楚，但是其并没有也不会覆盖到做出split选择的部分，也即，我们是否需要split，为什么需要，应该在split过程中使用怎样的策略和方法。split是否有价值，这是必须要思考的问题，我们不能为了split而去split。其中有一个例子，讲述用户需要upload以及download的功能，而download又可以划分为download as file或者as xxx structure方式，这可以作为两个child user story。但是，是否真的需要这样的划分，这样的划分是否真的有其现实意义呢？虽然从用户角度，下载到文件或是某种数据结构，确实是两个不同的 child user story，但是从开发的角度看，或许开发的最大开销在于download过程中客户端和服务器段的沟通，或者是设计download算法的部分，而以文件方式或数据结构方式保存反而是非常琐碎简单的任务。那么这样的情况下，你应该如何估计这两个user story的大小呢？如果说download本身是5个故事点，而保存的方式各为1个故事点，你会赋予文件方式6个故事点而数据结构6个，或者是文件1数据结构6，或者是各3.5个故事点，或是其他任何的方式？不论用何种方式，它都给实际的开发工作带来一些依赖关系的管理上的开销。那么，此时，也许反省我们分割user story的方法，或是分割user story的出发点会带来一些启发。

其中产生的另外一个重要思考是，在我们分析用户需求、分割user story的过程中，是否会出现信息失真，太过专注于产品的某些特性，而忽视甚至是根本就不知道用户的需求？比如说user story的描述是“作为<用户方某个角色>，我想要<某个功能，或工具、软件>，因为<原因或收益预期>”，然后我们可以通过介绍的那些方法将其分割成为若干个child user story，然后在实现各个child user story的过程中，我们会侧重于验证其功能，比如说这个功能需要能够创建某些资源、修改、删除等等，但是，在什么时候什么地方我们验证了这个功能是否能够满足用户要此功能的原因或收益预期的出发点呢？

    * 举例来说，用户需要一个工具能够舒服地，随时随地的可以供他记录下自己的思想片段。
    * 在公司的需求分析阶段，认为，一支“笔”应该是能够用来满足客户需求的。通过围绕笔的user story分析，并分割为若干的child user story，可能会在开发过程中，分别开发其书写、擦除、携带等各方面的功能。
    * 而团队在接手任务时，有可能已经丢失掉child user story最重要的成因，团队从自身出发决心要做出最好的“笔”，于是从设计和实现、验证等角度努力提高笔的质量等各方面品质。
    * 最后，我们得到了一支，重200克，使用高质量的墨水，外观精致，用钢琴烤漆制作的笔。

但是，符合用户的需求么？也许用户无非就是需要一支手的握感舒适、轻巧易携带、带有橡皮的铅笔而已。

要管理这些容易被遗漏的需求，以及child user story夹缝中的功能碎片，需要产品负责人或者项目的管理人员来协助做到。我们在现实中遇到的问题就包括，比如将数据包转发的功能按照数据类型分为CS （电路交换）和PS（数据交换）两种，但是偏偏就漏掉了CS和PS混合在一起的测试用例，以及在一种流量尚有部分资源剩余的情况下产生另一种流量的测试用例，导致我们在后期收到上层应用层测试的错误报告。团队对此一般是无能为力的，如果拿到手的product backlog item无需团队进行更多分析的话，情况会更加严重，就会完全仰仗分割user story到product backlog item的人的能力和细致程度，这恐怕是成熟的软件开发所无法接受的吧。

---

作者介绍
徐毅目前在一家大型欧美电信企业工作，具有丰富的软件开发、软件测试及测试自动化经验，同时，具有丰富的Scrum开发模式经验，目前担任公司的Scrum Master。专注于如何使Scrum顺利地融入企业中，如何创建一个Scrum的生态系统，以及敏捷开发中的测试。

几天前去麦当劳的时候，见到一个领班模样的人在训斥一线员工，没听清楚具体是什么事情，就是觉得这样的一种管理模式或者说反馈模式非常的好，快速、有效、有针对性，然后由此联想到scrum。

Scrum是一种敏捷方法，强调快速反应，讲求人的配合等等。而其团队组织方式是多功能型，由具有各种才能的人组成足以达成既定任务的团队。有清晰的工作目标，有一定的规范辅助，留给个人有一定的发挥空间，成员之间彼此协作，而scrum master则担当着现场督导的职责，确保团队能够获得完成任务所需的必要资源，以及遇到的障碍。

我所见到的麦当劳工作方式。前线的接待员会收集顾客需求，然后获取相应的食物，交付顾客，收费，完成一次顾客服务过程。而在这其中，接待员通过收银机确定食物选择后，其数据被及时交互到后台操作间，操作间基于此数据准备食物，并放入中间的食物通道，而食物通道有不同的编号，以分发不同类型或同类但口味等有变化的食物。由于整个过程的快速循环，on-shelf的食物流保持在相当低的程度，减少了因为食物变冷等造成的损失。当有接待员在获取食物时，其他人若有相同需求，可以直接通过话语告诉对方多获取一份，这可以看做是一种团队协作，而它可以减少服务所需时间。领班或其他的店堂人员会在整个店内巡视，及时发现需要加强或立即服务的事件，并控制整个局面，如二楼未整理的餐桌过多，阻碍了顾客就餐，或是有服务员的服务操作不规范等。

有时候进入夜间服务时间段时，其模式似乎有一定的变化。食物的准备没有冗余备份机制，而是完全依赖订单，当接待员下单后，先确定的单子首先获得食物，后下单则后获得，后方的操作台完全是一种on-demand的方式，由销售终端拉动。

而今天在上海逛正大广场的时候，看到那里的麦当劳又有一些不同，其接待员压根就不回头，专业的订餐员，有专门的人会获取准备好的食物。似乎是一种每个流程部分都有专门的人员在负责，而并非我在杭州常去的那个餐厅的接待员一样有更多的任务。我想这可能和餐厅的人流量有关，正大广场的人流量貌似比较大，如果接待员下单，然后获取食物，递交给顾客，那么下一位顾客等待被服务的时间就有些过于漫长。而有专人负责配餐，并送抵柜台的话，那么在接待员下好单开始服务第二位顾客的时间段里，配餐员也可以完成操作，配餐完毕，第一位顾客就可以得到食物了。更有助于快速的服务顾客，和较快周转。

那么这和scrum有什么关系呢？恩，也许没关系，也许有。scrum模式中的一些关键的工作方式和麦当劳体现出的这种模式有许多相同点。首先，团队是多功能型的，可以是多功能型的个体成员组成团队，也可以是不同专职的个体组成一个整体多功能型的团队。二，团队互相帮助，有共同的目标，如使顾客在设定时间内完成订餐过程，如在一个sprint时间段内完成选定的product backlog item。三，团队身边有一个有经验的高级人员，负责发现问题或障碍，并想方设法解决。四，团队成员间的中间产物可以呈现短时间的富余或短缺状态，但总体而言，是不多不少，比如开发人员可能开发出某段程序，而测试人员还没有设计好相应的用例，或是测试人员更早的设计了用例，等待开发人员实现所需的代码。

第五点，是我认为最重要的一点，我猜测有，但并没有很确切地看到麦当劳有这样的机制，那就是流程的状态实时查询或显示，而且是非常可视化，非常直观的方式。比如说，麦当劳完全可以统计出中午11点半到12点半之间，对于特级板烧鸡腿堡的需求量，可以有历史数据，也可以有当日动态数据，那么后台操作台可以根据此数据，做好一定的准备工作，为即将到来的就餐高峰准备好足量的汉堡，减少顾客等待的时间。而在scrum中，可以通过Continuous Integration（持续集成）等方法来达到此目的。如果在持续集成的系统当中，被执行的功能性测试用例都是基于用户需求的，那么在sprint开发过程中，不断更新的测试用例执行状况，就是对开发状况的一个直观展示。在持续集成中拥有单元测试案例的话，则可以获悉更小粒度的开发进度信息。抛开这些产品自身属性方面的反馈信息，工作人员角度也可以获得足够的信息。在每天的daily scrum，以及稍大项目中可能使用的scrum of scrums中，开发团队都会透露出详细的开发状况介绍，甚至包括情感性的描述“我们肯定能按期完成”。这些信息都能够给产品负责人或项目管理者（如果还有这个角色的话。。）非常直观的印象，从而可以为开发工作的顺利进展和如期完成提供所需的支持，或增加更多可以完成的任务。

但是，一个非常大的区别，至少我所处的项目环境和麦当劳之间的不同，是，麦当劳是零售业态，接待员直接面对的是顾客，也即终端用户，客户需求是零碎的、变化的、快速的、产生速率是变化的。他们递交的产品也是可重复的，每个产品个体的差异小到可忽略不计，且不存在后期维护成本，无需进行产品设计，也无需考虑后期维护及扩展的需求。而软件开发则不同，在一个大型系统的开发中，每个团队所面对的并非终端用户，一般是自己的上一级开发团队，比如系统平台开发团队的直接客户是应用层开发团队，而且作为一个复杂的系统，其客户需求通常是有组织的、大量的、少量变化的、产生速率恒定或受控制的。所递交的产品通常对整体重用性要求不高，必须考虑后期维护及扩展所需要的成本，并需要进行产品设计，以满足对扩展及维护的需求，降低后期成本。

---

作者介绍
徐毅目前在一家大型欧美电信企业工作，具有丰富的软件开发、软件测试及测试自动化经验，同时，具有丰富的Scrum开发模式经验，目前担任公司的Scrum Master。专注于如何使Scrum顺利地融入企业中，如何创建一个Scrum的生态系统，以及敏捷开发中的测试。

几天前，InfoQ发表了文章《给敏捷团队发奖金就像在刀尖上跳舞》，单从标题就可以看出其中的“惊心动魄”，显然我们需要高超的技艺，以及皮粗肉糙的脚底，就像某些非洲土著那样，方才能够游刃有余地舞动在刀尖之上。

确实如此，通过发奖金的形式来激励团队成员，本身就是一把双刃剑，弄得不好，可能就会破坏团结，导致彼此之间的矛盾与冲突，这对于一个团队而言是绝对致命的。然而，如果一个团队缺乏合理的激励方式，又无法调动成员的积极性。如何取舍，真是伤透脑筋。

看完这篇文章，我思索良久也没有寻求到一个好的答案。昨日阅读Larry L. Constantine的《人件集——人性化的软件开发》，才发现其实Constantine早已给出了答案，就在书中的第59章《受奖励的程序员》中。原来，我们为什么要受限于发奖金这样一种形式呢？套用一句俗语说，“提到钱，就难免伤感情了。”要激励团队成员以及开发团队，我们还能够寻求到很好的方式。

概括起来，Constantine提出的激励机制包括如下内容：
1、“技术玩具”。开发人员大多数都是技术型人才，一个通病就是对于技术的执著追求有时候甚至高于对金钱的追求（前题是他已经具有优裕的生活基础）。因此，一套最新的正版软件工具，或者一件当前最酷的数字产品，都会让他们欣喜不已。这种“投其所好”的馈赠方式，既没有奖励金钱那么赤裸，又能够让开发人员从内心深处激发对公司的认同与感激，真可谓两全其美。

2、小礼品。书中写道：“绝不要低估T恤衫的力量。各式各样的‘刺激’手段——团队夹克、特殊的领带、特别的杯子或者鼠标垫——都是可以使用的方法，这些，能够告诉那些取胜的团队以及团队成员：他们与别人不太一样。最好的团队还可以获得自己设计团队徽章样式的机会，并有公司负责找人生产。”这种方式或许是高层领导最愿意看到的，投入不多，却极尽蛊惑人心之能事，尤其是设计团队徽章的做法，既能够激发个人的集体荣誉感，又能够激励整个团队的战斗力。

3、自由控制的时间。这里提出的自由时间，并不是奖励成员出去旅游或者度假，而是对于那些按时交付了高质量软件的开发人员，奖励他们能够在公司的上班时间内，自由支配自己的工作，做自己感兴趣的事情（当然是与技术相关的）。例如，你可以自由自在地在没有最后期限的压力之下研究网格运算，或者神经网络，人工智能，哪怕你所在的公司实际上只是从事SAP二次开发。

Rob Thomsett说，按照他的经验，如果你把时间和钱放在一起让程序员挑选，大多数都更喜欢前者。而这类由公司赞助的研究活动，反过来对公司也是有益的，不但是获得了一位拥有新技能和新点子的快乐的开发者，而且，没准儿还能得到一个新的软件或者其他什么有用的技术。这种奖励方法对整个团队可能更有意义。如果一个项目团队显示出他们的高超的开发执行能力，当他们超越了公司建立的最好实践之上时，那么就应该对这个团队进行奖励，让他们可以无拘无束地选择研究和开发项目。

如果你的公司是一家研究型公司，或者从事产品开发，这样的奖励方式在激励成员以及团队工作热情的同时，或许还能得到意外的收获。最关键的是，这种做法无形中营造了公司的研究氛围，创造了一种良好的价值取向。

4、教育与培训机会。特别对于具有进取心的开发人员而言，获得教育或培训的机会，绝对比获得奖金更加诱人。即使管理者担心教育与培训投入的成本太高，甚至会造成人才流失的可能，那么，给团队人员一次参加技术大会的机会好了。这些大会往往都是免费的，开发人员需要获得的仅仅是你的一个许可而已。然而，已经足见你的栽培之心了。Constantine还说道：“报销书籍和杂志费用也是一种低费用的激励方式”。管理者们，你们看到了吗？

5、选择团队成员的权利。权利也是一种奖励。例如让他主持一次会议，或者提供监督别人的机会，都是一种廉价的权利，但有可能得到的回报却很丰厚。最好的权利就是允许团队成员能够挑选自己认可的合作者。书中提到：“一旦一个小组已经学会了如何协同工作，为什么要把他们分开呢？对于那些能够高效开发的团队，奖励方法之一就是让他们在下一个项目中继续共同工作。对这个方法进行一个推广，那么，我们可以让他们自行挑选工作伙伴，这种行为可以有效地激励员工，使他们能够达到最好的工作效果。同理，让那些在上一批项目中干得最好的团队，在下一批项目中自由选择员工，对他们来说，也是一种奖励。”还有什么比这个更加廉价的奖励。

除了以上提到的五点之外，Cockburn在《敏捷软件开发》一书中，还提到了Darin Cummins发明的一种开发游戏的奖励方式，奖励一些类似于代金券之类的伪币，然后在项目结束后，利用这些伪币来竞拍一些真正适用的物品。关键不是这个结果，而是开发中的过程，对于成员的奖励就像玩游戏一般轻松自在，不知不觉就剥去了成员的功利之心，有效地消除成员之间的恶性竞争。

Darin写道：“开发人员会因为他们的代码被评审、评审其他人的代码、按照进度完成任务、重用代码以及创建单元测试等得到奖励”。要消除成员之间的恶性竞争，这种方法一定要遵循两点。第一是将过程尽可能最小化，这样的度量会更加准确与透明，不会出现太大的分歧。第二则是给参与者反败为胜的机会。可以在开发过程的结尾，设计一些额外的活动来让开发人员赚取更多的奖励。这样一来，即使开发人员在前面输得太多，他仍然有机会在后程发力，反败为胜。

适当的奖励可以让我们踢开刀刃，自在轻舞，但必须还要谨记如下两个原则：
1、在奖励优秀的开发人员的同时，不要忘记对优秀团队的奖励；
2、奖励方式应因人而异，必须最大程度地投合员工的喜好。

因此，在对你的团队以及员工进行奖励之前，最好先询问他们究竟喜欢什么，也许你能够以最小的投入换来最大的回报。坦白说，有时候上级也需要好好考虑如何对下级“拍马屁”呢。

本文最初发表于IT168。

---

作者介绍
张逸具有多年的软件开发与设计经验，他是两届微软最有价值专家（MVP），著作/译作包括《软件设计精要与模式》、《WCF服务编程》。张逸熟悉C#，ASP.NET，WCF等技术，同时深谙面向对象领域的相关技术。目前，他主要从事 SOA企业信息解决方案的设计与研究，以及敏捷方法的推广与实践。张逸是捷道·敏捷堂的创始人。

作者：taosinker    来源：blog.csdn.net/taosinker

软件流程的名称太多，RUP,V Model, ISO9000，CMM等等不一而足。最近接触了SCRUM，收获良多，与诸位同仁分享。

自从有人类社会活动以来，就形成了各种各样的组织和制度，上到社会体制下到家庭环境，西方到东方，社会风尚、工厂流程、等等，这些东西都具有一种共同的特点：都是为了适应一点的社会目的、解决一定的组织问题，而形成的。软件的流程，也具有类似的特点，只不过是适应软件规模化生产而成的东西。我只所以这样说，目的是希望大家不要把软件流程这种东西神秘化，另外也不要把它当成无所不能的万能钥匙。所有为社会化活动定义或者自然形成的东西，一方面有其解决问题的一面，同时也有他的瑕疵。

软件形成的初期，没有任何所谓的process,天才工程师似乎可以把当时的所有问题彻底搞定。随着软件规模化生产以来，所有具体的软件活动，比如设计、分析、项目管理等都有必要纳入流程管理的环节，从而达到可控并优化的目的。软件流程的先驱们从工业生产、统计科学、心理学等等借鉴了多方面的有价值的东西，而形成了如今各种各样的所谓的软件开发流程。我在工作中也接触到各种流程的思想和操作。有时候老板们总是希望流程来解决碰到的问题，可是有时候又形成了一个过于流程化的局面，为了完成一个小问题，却要付出几倍的流程的成本；有时候某一个流程过于僵化缺忽视了真正应该重视的问题。软件生产是一种智力活动，这又具有很大的不同，某些方面非常难以把握，太硬性的东西反而戳伤了员工的创造性。等等，我相信所有参与过软件开发的工程师，可以列出更多的问题。如何解决种种问题，不同的软件流程都提出了一套不同的方法。现在看这些，process, 我们不能说那一个更好，只能说那一个更适合你。如同找老婆，没有最好，只有更适合自己的。

绕了这么一大堆，我只是想澄清一下对软件流程方面的基本认识。对与不对不同的人可能有不同的看法。下来我想聊聊SCRUM，我不想列举SCRUM如何具体操作的步骤，网络上有好多这方面的资料。诸位可以找相关的资料看看，我这里只想写一些对SCRUM的感受，列一下我所理解的SCRUM具体的思想精髓。欢迎网友和我交流，也使我能有所提高。

软件开发是一个复杂的群体智力活动

SCRUM 把软件开发看作是一个解决复杂问题的群体的、智力劳动。这一点很重要，首先这把软件开发与平常的工业化流水线生产区分开来，让我们认识到软件开发的特殊性。你可以把软件生产比作流水线生产，可是软件生产是一种特殊的群体智力活动。不认清这一点，就不能把软件开发中人的因素放在首位。不是说，软件工程师都培养成象流水线上的工人，你的企业就成功了，这恰恰是一个软件企业行将没落的一个不好的兆头。软件生产需要创造，需要思想活跃的人才。苹果公司有了乔布斯就活了，还活得有声有色，这就是人才的重要性。企业的CEO需要如此，同样从事具体软件创造的工程师也需要有创造性的环境。真真成功的企业100%都是有创造性产品的公司！SCRUM基于此，提出软件开发团队需要时自我学习，自组织的团队，来到达充分利用各个员工智慧来解决复杂问题的目的。

为了充分利用团队成员的智慧，众人拾材火焰高吗！！！SCRUM实施的过程中有如下的具体操作：
1）任务不是由SCRUM master 自作主张分发的，而是有团队成员主动申请。这就是task 的poll方式；
2）SCRUM master 不是老板，开会的时候不是听取汇报的。而是帮助团队解决困难的，要保证团队成员彻底的沟通理解；
3）Inspection 要做到发挥团队其他成员的积极性，及早发现错误。当然这一条也不是SCRUM 特有的。但是SCRUM 对此事重点强调的噢！！！
4）要重视团队的自组织行为，团队为了解决一下问题，总是会找到一个最合适的方式来达到有效解决问题的目的。SCRUM master 应该鼓励这样的行为。

有效的沟通是软件成功的关键

沟通，沟通，沟通。国际问题，家庭问题，上下级问题等等都需要需要沟通。归根结底是人际问题，人之所以为人，科学家说，因为人有语言善于沟通。可是具体中许多问题，恰恰是缺乏沟通造成的。软件开发过程也是一样的道理，客户需求没法被所有人理解，变动没有在个个关系人之间有效地传达。项目存在的问题，没有被领导和解决问题的负责人发现，等等都是由于没有沟通造成的。由于这些原因造成的损失往往是致命性的！！！

需求方面所有的软件开发过程都强调，需求变更的管理以及能适应需求不停变化的现实情况，可是我个人认为SCRUM所定义的运作方式做得彻底、做到比较好。表现在如下几方面：
   1. 客户的需求被Product Owner全面反映到TEAM中来
   2. 客户看到的是一个可deliever的东西，基于此客户可以有更现实的想法或者，更合理的变动
   3. 每个Sprint开始，需求的变动被及时地反馈给TEAM
   4. 需求的优先级，满足客户利益的最大化

团队开发方面：
   1. Daily SCRUM Meeting使团队的进度得到同步
   2. Daily SCRUM Meeting使问题及时地发现并尽快得到解决
   3. 不同Component之间的依赖，也能得到有效沟通。这是有效解决的前提
   4. 项目的困难进度，能使客户、领导及时得到

另外，团队的成果，客户能及时地看见，客户能够通过Product Owner将需求及时反馈给团队，这大大促进了项目的成功，减少了项目的风险。

自我检查及时调整是团队走向成功的保证

古人云“日三省乎己”，对人如此对一个组织也是这样。返过头来，看看我们的软件开发。我看到过一些组织有下面一些问题，网友同志们或许有其他补充。
   1. Process太过于费时，浪费了大量的时间
   2. 以前曾经就有这样类似的教训，现在还犯
   3. xxx问题已经拖了很长时间了，为什么还没有解决
   4. 大家长时间地走一步看一步，没有一个规划。好象没有人来解决
   5. 一件事情，反复地改，脑子里面长水了。不理解这些人怎么想的
   6. ……

我相信大家或多或少碰到过类似的问题，有问题比有问题却发现不了问题强得多了。如果有问题，及时地自我发现，并能够及时地调整，这是一个健康组织必有的一套体系。只有这样一个组织，项目才能很好地适应市场需要，很好地站稳脚跟。可是，能做到这些，并做好并不是容易的事。 SCRUM有专门的定义来做到发现问题解决问题的目的：
   1. Sprint结束时要审视自身。Retrospection meeting
   2. 发现问题要及时调整
   3. Scrum Master 要对这些活动在Process上负起责任来
 
结语

SCRUM 是从软件管理的角度定义的一个Process，现在越来越得到软件开发群体的认可。本文只是一些个人的认识和看法。软件管理是一门“艺术”，SCRUM不可能涵盖所有的问题。这就需要具体的执行人,scrummaster，要具体问题具体分析。希望本文能对大家理解SCRUM有益。欢迎交流，批评和指正。