关于华为敏捷项目管理
http://www.javaeye.com/topic/313741
IPD - 集成产品开发，华为花重金从 IBM 购买的一套产品集成开发流程，业界有一本书， PACE 讲的就是这一套 IPD 流程，而 IPD 并不去讲你的开发要怎么 做， IPD 做的就是 " 投资决策、市场驱动 " ，更多的是决定做不做这个事情，做这个事情对于投资人员是不是受控的，所以在 IPD 里面会有 DCP 点（决策评审 点），每个点上都会去考虑该不该做、值不值得去做，在引入这个东西以前，华为实际上是技术驱动的，并不是市场驱动的，就是说以前华为听说有个新技术，然后 就开始做，做了很多这样的东西，但是后来都卖不出去，所以后来就引入了 IPD ，以市场驱动。
在引入 IPD 后，是解决了做什么的问题，但是怎么做，还是按照 自己的想法去做，后来就引入了 CMM ，引入 CMM 后对华为确实起了非常大的作用，其产品开发的质量确实是比起前提高了，所以在前几年，通过 IPD+CMM 使得华为走向了一个非常成熟的过程。在这个基础之上，关于质量管理、项目管理华为提出一些自己的体系，比如从项目的开始到项目的结束，有项目 review 、度量分析、根因分析、缺陷预防等一系列活动，在项目管理方面有风险管理、问题跟踪管理等活动，同时还会有质量审计以及相关的推动等事情，通 过这些项目管理和质量保证使得 IPD 和 CMM 很正常的运作下去。
但是现在行业已经发生了一些变化，比如需求变化快等方面华为也碰到了一些问题，以前产品质 量是可控的，大多数产品的发布周期也是稳定的，比如对客户承诺什么时间提交产品基本上是有保证的，另外项目在管理层的进展也是非常清晰化的，你在向某某领 导汇报的时候只用告诉他比方项目到了 SRS 阶段了，基本上这个项目的老大就知道这个项目还有多少事情需要去做，比如告诉他到单元测试阶段了，他就知道快搞 定了，这样确实使得这个进展能够口头化。其实，流程存在的价值，就是能够给我们的管理层提供进展的可视化，所以从目前来看，对于客户、员工、管理层这三个 利益相关人来讲确实达到了这样一个目的。
但是现在行业中，需求变化太快，不管我们怎么努力去做，发现还是不能满足客户的需要，不管需求搞得多么细，到交付产品给客户的事情，总是有这样那样的问题，这个时候就不得不去修改我们的软件，这是华为面临的一个挑战，如何解决这个问题？
软件开发中有三个要素：人、过程、技术和工具。对于一个软件项目成功来说，这三个要素都不可省，而在以前大家强调 IPD 和 CMM ，更多的是强调大 家规范的把它运作起来，对于人、技术和工具基本上不提了，忽略了，所以后来就反馈出一个问题，就是很多项目，看起来那个过程做的那个漂亮，那个报告写得那 个完美，但是交出去的产品那个烂，其实这三个因素是缺一不可的，你必须得均匀的发展，还有一个是人的方面，因为人是具备创造能力的，所以从华为的教训给我 启发，过度的关注过程而忽视人、忽视技术和工具，我们就得要思考和反省了。
针对这些问题，华为也就提出了敏捷。华为在 99 年之前基本上都是土生土长游击队的做法，到了 2001 年的时候就引入了 IPD 和 CMM ，到 2006 年的时候，就发现了瀑布模型的问题，如交付周期特别长，就是每做一个客户的需求，然后一分析，这样一走半年就过去了，所以就引入了 RUP ，最初的想法就是 加速我们项目的交付周期，能够快速的给客户响应，但是敏捷实际上已经进入了一个低谷期，所以当时就引入了迭代，实施了一年之后也发现， RUP 里面的东西实 际上也是挺多的，所以后来就接触了 XP 、 SCRUM 这些方法，这样就从 07 年开始向敏捷这个方向在走。 有一个图在业界流传比较广泛，也叫洋葱图，共分三圈，也就是从三个不同层面描述了敏捷开发方面的一些最佳实践。
XP 为什么叫极限编程？如果你觉得 这个软件开发的实践是一个好的实践，那么你就把它发挥到极致。比如，结对编程，一个在编，一个人在看，实际上看的人不会白看，其实起到了一个 review 的作用，既然 review 这个作用有效，那么为什么不把这个作用发挥到极致，所以就采用了结对编程将 review 这个作用发挥到极致。在敏捷中有一个 8 个 字的原则：沟通、反馈、交流、勇气。它认为项目团队中的成员这个沟通是比较重要的，既然你非常重要，那么我也要把你发挥到极致，所以两个人一起在干活的时 候就会不停的有交流与沟通，所以，结对编程是一个典型的把 review 、沟通交流发挥到极致的实践。
另外， TDD 也可以认为是那刚好够用的事情发挥到极 致。我们以前传统的软件开发的做法是，先做好这个软件，然后去测，看看是不是实现了这样一个功能，但是我们总会发现这里面有很多代码其实是从来就没有用过 的，只是在下代码的时候顺手就把它写了，在分析那些产品的时候发现有的产品这样的没用到的代码高达 50% ，而 TDD 的思想是，我既然要实现什么功能，然后 我就先写对应的用例来验证它，然后在开发的时候就开始写代码，使得这个用例刚好通过，这样就使得我们写出来的代码是刚好满足这个系统的功能的代码，这样， 前面出现的 50% 就可以不用做了，这就是把刚好够用发挥到极致。其他的就不一一讲了。
XP 在 2001 年到 2003 年之间非常的红火，过了之后又相对的沉寂 了一点，现在又冒出来一个新的敏捷的方法论，就是 SCRUM 。 XP 是过分的强调将软件开发里面的实践发挥到极致，而这些实践都是同编程实践相关，但是在管 理方面就比较弱，所以，在用了几年之后，大家发挥 XP 不是起到那么大的作用，所以就开始沉寂下来。这个时候就出现一个流派，就是 SCRUM 。
SCRUM 其 实就是一个非常非常轻量的项目管理框架，基本上没有什么编码实践方面的东西，你说看到的都是管理上的活动，这个管理上的活动很多人就会有一种似曾相识的感 觉，记得前不久，同华为的一个项目团队在聊，就谈到这个项目的 backlog ，一讲，项目团队的人就说其实他就是那样子做的，他以前也没与听说过什么 SCRUM ，就是把这些需求一条一条的列出来，镍镉优先级，估个工作量，一看，就是这个东西。
SCRUM 的核心其实比较简单， 2 分钟就能讲出来，就是 3 个 3 。
一、 3 个角色。
Product Owner ，负责决定产品要做什么，做成什么样子；
SCRUM Master ，保证项目能够遵循 SCRUM 的方式运作下来；
项目团队成员，包含开发、测试、质量等等所有的人。
二、 3 种会议。迭代的计划会议、中间的站立 式会议、迭代的评估会议，属于三个管理的活动。
三、 3 个交付件。待开发的任务列表、待修复的缺陷任务列表、项目的进度图。
SCRUM 就是通过这 3 个 3 将项 目非常简洁的管理起来。
有一个思考就是关于 PMP 里面讲到的 9 大领域多少活动不一定对这种敏捷项目适用。那么大家可能提出一个疑问，就是项目的进度是不是 就不可视了。其实，敏捷项目的进度可视很简单，就是通过一个白板（进度墙、任务看板），将每个人的进度情况这么一贴，这就是最简单最直接的管理方式，一 看，所有人都知道，就算你去开发一些什么复杂的一些 IT 支撑系统，可能都起不到这个白板的作用。
在华为关于敏捷的一些项目管理工具，用 Scrumworks 、 Bingo 这些管理工具也能够把项目的进度管理起来，但是你要做的就是必须得把电脑打开，要把浏览器打开，这样才能看到你的进度是 什么样子的，而在办公区直接树一个白板就能够很简单、很方便的知道我的这个进度情况。
所以，在华为，对于敏捷项目，管理的框架上是采用的 SCRUM ，指导 如何编码实现上就采用了一些 XP 的实践，当然 XP 的实践不会全部去选，会根据项目的实际情况去选一些实践，如果你把所有实践都选的话，实际上的效果是非常 差的。那么如何来选择就得根据项目的实际情况去评价。华为在实践的过程中也引入了精益、消除浪费的思想。比如，在平时的工作中存在停工等活的浪费。什么是 停工等活的浪费呢？比如我们开发在做开发的时候，我们的测试就会轻松一点，那么测试在做测试的时候我们的开发就会轻松一点，大家觉得这样也挺好的，但是你 从整个组织角度去分析，实际上是停工等活的，开发时测试在等着，测试时开发在等着，如果你从精益的角度考虑的话，为何不通过迭代的方式把开发和测试等待的 时候整合在一起来工作，使得效益得到提升。有很多项目团队自己去做了，确实效果比较明显。
其实在 2006 年实践 RUP 的时候就感觉到这样的好处了是非常明 显的。引入敏捷之后，自然而然的就会想到同公司已有流程之间的关系，原来是 IPD+CMM ，所以就有同事问到是不是我这个就不用了。分析可以知道， IPD 是决定做不做，决定之后如何去做就可以采用敏捷开发，所以对于敏捷产品的流程就是 IPD+ 敏捷的方式，所以有很多以前采用瀑布型的团队逐步的被敏捷代替 了，还有些团队正在代替中，还有些团队就觉得原来那套玩得很流畅就继续采用原来的方式。所以目前在华为，项目团队是可以自己来选择采用哪种方式进行，现在 可以发现，那些愿意选择敏捷方式走的往往就是原来那些顽固不化的烂项目，因为以前在推流程的时候，那帮人整天在那里叫，有问题，我不干，我不愿意做，实际 上，后来做深入分析发现，他的那种模式并不适合按照瀑布型去做，但现在成了积极分子，所以每个项目的模式是不一样的。
在做敏捷的时候也存在一些容易做的事情和不容易做的事情。比如说 SCRUM 的项目管理是比较容易去实践的，就是 3 个 3 ，对于那些想敏捷的，我建议 可以先做这个，还有也会做一些结对编程、持续集成的实践。
比较难的，有这么几点。华为从 99 年开始都是按照开发、测试等团队去运作的，团队与团队之间就会 形成部门的墙（华为有一个外籍员工给起了一个名字叫 Chinese Wall ），对每个部门来说，希望把这个墙树高一点，这样能获取更多的资源非常顺利的开展工作，所以墙就会越树越高，很多部门甚至还有 checklist ，你只要给我什么东西，我就按照 checklist 打勾，打勾不通过的就要干啥干啥，这样通过约束管理层，罚款的制度就来了，而这个问 题就很难搞，涉及到很多很多的人员，涉及到部门角色定位的问题，这是华为觉得最难的一点。
第二难的问题就是 TDD ，在很多项目都试过，但是试过之后，很多 项目都无疾而终，或者诉苦说这个我实在搞不下去，分析后发现，是涉及人做事情方法的改变，这个挺难的，以前写代码都是边想编写，就能写出来，现在你就得先 想好、验证好等等，然后再想办法填进去，就发现这个很难，这是一个开发习惯的改变，这也是很难的一件事情。
第三个，就是 Customer Tester ，就是要客户参与验证，可能对于互联网企业可以部署一个系统，用户参与测试就可以做起来了，但是对于华为而言，客户是电信企业，而电信是买 方，买了之后再供他们的客户去用，这个里面客户就存在好几层，所以要客户真的参与进来还是比较难的。
第四点，也是很难的，我们有一个团队，要到各个团队去 宣传为什么做敏捷，这涉及到观念的转变，所以这也是非常难的事情。（一夜的引入，长时间的改变。）比如你说你这个团队敏捷了，明天就开始站立式会议，但是 你最后会发现，要真正敏捷实际上是一个漫长的过程。
在华为实施敏捷的过程中，也有一些经验性的东西。第一个是 QA 从警察的角色转变到一个教练的角色。在以前，团队实施 CMM 的时候， QA 更多的是一 个警察的角色，他整天拿着一个 checklist 、报告什么的到处去团队里面看，你是否 ok ，不 ok 就要怎么怎么样，整天就干这个活，但是引入敏捷之 后， QA 就觉得有点失落，都敏捷了，我都不知道该怎么下手了，然后，在华为，就把 QA 转变了一下，将 QA 更多的充当教练的角色，充当 SCRUM Master 的角色，他去指导项目团队该如何去开这个站立式会议，该怎么去做迭代的计划等等指导性的工作，这样 QA 也觉得挺好，这样他能参与到在不同的团 队中去，这样他见得也多，所以在敏捷的实践里面是需要这么一些人来干这么一些事情。
第二个就是要营造一个一体化的团队，也就是将所有有墙的部门通通打掉， 直接按照项目型运作，把大家拉到一起，不要考虑你原来是什么部门，先把项目做出来再说，这就是在 XP 的外圈中的 Whole Team 实践，因为大家就真正是一条船上的。在很对项目中，总是存在这样的一些人，项目成功不成功对他们是无关紧要的，但是有些人项目不成功对他们是非常 重要的，而真正的敏捷项目就要这些人来挂帅，并且这些人是站在一条战线上的，所以就叫拉到一体化的团队里面来，大家都对交付负责。
第三个就是办公环境最好 也能够随着改变。以前大家都是那种小格间的方式，但是这种方式是非常不利于做交流和做项目的。
第四个就是现身说法。前面讲到有很多这样的人会到团队中去说 敏捷怎么怎么好，但是如果你让一些对项目成功不成功都不相关的人去讲是没用的，因为大家一听，首先就会质疑 50% ，所以华为当初经常搞的活动就是让项目经 理他们在讲，将他们当时是怎么开展敏捷的，这样别人一听才能理解到原来你是这么这么做的。