Scrum开发之我见

众所周知，直至今日无论是互联网公司还是传统软件企业都还在找寻一条适合自身特点的系统开发生命周期管理方法之道，但关键是大家在“众里寻它千百度“之后，都有”暮然回首那人不在灯火斓栅处“的诸多感概与感悟！找寻之路不容易，前期大家都在”瀑布式“方法论的引导下，取得了一定的成效，有效地进行了系统开发过程管理，但随着竞争越来越激烈与系统越来越复杂，曾经的”法宝“瞬间失灵了，成本越来越高，过程越来越乱，于是老板坐不住了。便有了众多公司与企业在”穷则思，思则变，变则试“的永恒法则指导下，象打了兴奋剂一样热烈地开始去拥抱”洋玩意“-”CMM/CMMI“方法论，在培训与咨询公司的狂热吹捧下，无数正规地、不正规的，上市公司、中小企业都加入了"CMMI"认证大军，神州大地沉浸在转身为”正规军“的喜悦之中，但”理想总是很丰满，现实真的很骨感“欢喜过后，大家猛然发现”洋玩意“好象在神州大地水土不服，顶多只能充当看门的”二郎神“，而不是能镇牛鬼蛇神的”阎罗王“，一场风雨过后一切照旧，过程依然混乱，项目或产品失败之剑一直高悬。我们到底应该怎么样才能更好、更快、更优地完成产品与项目开发呢？如何才能让我们将产品或项目失败的风险控制起来呢？无数业界的精英们开始思考起来，开始行动起来，于是乎”敏捷(Agile)“这个词开始热起来。

那么到底什么是敏捷呢？敏捷与XP、Scrum之间是什么关系呢？敏捷与CMMI又是什么关系呢！上述这些疑问，我相信只需要你关注过“Scrum”过，应该就能获得相应的答案！简而言之，敏捷是一种思想，xp是敏捷的行动宣言，而Scrum则是敏捷的体系化框架。它们所有的核心思想是以一种“更轻量、更可控、更发散、更团结、更积极、更开放”的态度去组织、应用复杂多变的软件产品开发生命周期。而在敏捷的核心方法里面“迭代”是一个出现频率最高的词，它强调以“短周期、高频次、有顺序”的方式方法去组织实施迭代过程，以“大事化小，小事化无”及“优先级决定一切”的工作模式去将复杂的系统开发变成若干个可控的“小单元”，同时强调将迭代的成果产物“阶段交付物”及时地客户进行沟通交流，第一时间获得相应的反馈并为下一版本迭代积累与调整"backlog"。整是因为敏捷中强调与客户的互动反馈，以及要求团队更加主动，更加开放的心态去承担或应对系统开发过程中的各种问题与意见，以“拥抱变化”的态度去进行系统开发，瞬间让敏捷在软件开发领域犹如春风扑面，给沉入泥潭中的系统软件开发带来了一阵“小清新”，春天终于到了，让我们去拥抱敏捷吧！

前文我们费尽口舌来讲解敏捷思想种种优点与强悍之处，那现在就让我们回归到问题的最关键、最现实之处：我们到底如何进行敏捷开发？敏捷开发的关键是什么？

说真的，个人对敏捷这一块的掌握了解并不多，虽早有耳闻，但对其了解也停留在“不识庐山真面目，只缘身在此山中”，对于上述问题也确实无法给出明确而有效的答复，经过这二天的简单培训，就让我们一起来分享一下我个人对Scrum及敏捷开发在实施过程中的一些关键要点吧！在实施敏捷开发过程中，我认为：

（一）.以“人”为本

在敏捷开发过程，最关键的角色有如下几种：PO、SM、SD(其中又可细分为：系统架构师、开发人员)。看起来好象关键角色不多，但经历过之后才知道，上述角色个人要求是”孙大圣“类的人物，必须有”七十二变“的本领，同时拥有及强的控制力，能够掌控全局，有运筹帷幄，决胜于千里之外的气魄。而个人感觉最为关键的一点是：每个角色要有极强的主动性、自觉性，同时辅以强有力的沟通交流，才可能让事情顺风顺水，一帆风顺。但关键是目前国内IT市场鱼龙混杂，要找到一个合适的人，谈何容易！

此时必然有人跳出来说我太悲观，诚然我的观点中固然有悲观的一面，但我相信天下没有完美的事情，亦无完美的人，与其等待合适的时机、合适的人选，不如先从自我开始做起，勇于去尝试、积极去面对，以可接受的失败去迎接灿烂的明天。人终归是一个可塑性极强的物种，只要前期选中有潜力的队员，大家有着坚定的信念与不怕失败、不怕困难的决心，我相信风雨过后终究会获得成功。那如何选择上述角色的人员来组队呢？、

a.PO角色

必须拥有极强的控制力，对产品有着坚定的信念，有清晰的产品概念与演进思路，对产品的”大事大非“了如指掌以及游刃有如。

b.SM角色

要求是”扫地僧“类型选手，以“旁观者”的心态在团队周边注视着大家的运作与成长，在关键时侯能够主动跳出来让团队回归正道。

c.SD角色

作为敏捷团队最重要的执行者，则要求其能够更加主动、勇于贡献、敢于担责，具有强有力的执行力和沟通交流能力。

综上所述，在敏捷的实施过程中选择合适的人或者以合适的方式去带动团队往正确的方向上去努力，这是关键所在。

（二）.以“控”为纲

在敏捷中强调“Sprint”，冲刺纵有英雄豪情气概，但成想如果没有一个强有力的控制点，配合以成熟的战术，丰富的应对措施与强大的团队执行力，那么一场“冲刺”则将演变成为通向死亡之旅。如何来避免死亡之旅的发生呢？看起来“短周期，多轮次，多顺序”的迭代好象挺不错，应该能够带领团队披荆斩蓟，到达胜利的彼岸。但是细想一下，如果在迭代过程中，没有良好的控制轨迹，一切将失控。就来文档来说，有很多人在概念中天生就认为敏捷就是没有随心而动，强调个人，强调交付，所谓的文档都是浮云。诚然，敏捷对于文档的要求没有那么高，但绝不是无文档要求，它要求的是“轻量级”文档，要求的是更高质量的文档，只是敏捷认为团队的个体的交流更胜过生冷的文字，但这绝不是我们不需要文档的理由，在关键内容上文档依然是最可靠的伙伴，尤其在我们沟通交流太发散的情况，我们需要有一种东西将我们串起来。而我讲的串起来就是以“控”为纲，我们在敏捷的实施过程中需要选择关键的点，关键的过程域，关键的岗位，关键的环节，强化进行控制以确保每次迭代按照既定的方向前进，同时也能够提升交付物符合预期目标。

（三）.以“工具”为术

在敏捷中对于各种工具的依赖犹为关键，象日站立会议，白板，便签条、优先级排定、理想日分析、工作量评估或信息化系统等等。上述工具及其使用方式就象战斗过程中所使用的“战术”一样，十分清晰与明确地告诉团队成员，应该怎么去推进敏捷开发相关事宜的向前发展，如果团队对上述工具的掌握与了解不甚熟悉或带有抵触情绪，那么就象在战场上士兵不听众“战术指挥”一样，最终的结果便是“乱抢打死”，死得何其冤。那么在敏捷实施过程中，无论在形式上、方法上，必须认认真真地按照Scrum的相关要求扎实推进上述工具的使用，经过不断的努力与尝试，你终究会有收获的。

（四）.以“信念”为基础

看过了上面诸多的要求与困难，也许你会退却，你会害怕失败，你不敢去尝试了。其实不然，敏捷思想确确实实为软件开发指明了一条新的康庄大道，只是这条大道太过于新潮，让走怪了乡间小道的我们会产生错觉，宛如“乡下人进城”迷失了方向，在通向成功的迷宫中乱窜，当然也势必会付出一些血的代价。只要我们有坚定的信念，不断地去尝试，去努力面对错误与失败，通过一次、二次...N次的尝试后，你终究会找一条符合自身特点的康庄大道，但如果你放弃，只会留下背景与血的教训，其它你别无所获！

信念是我们这个社会最缺失的东西，也势必影响到了我们团队的每一个人，我相信只要我们选取方向，明天必然会属于我们，成功就在我们脚下，请踏出你坚地的第一步吧，你会成功的！