敏捷之旅之Scrum介绍
一般来讲，简单项目＝熟悉的技术+固定的需求，一般采用经典V模型的瀑布肯定能解决、复杂项目=技术不确定+变更，采用一步到位的方法就比较难，迭代增量就是更好的方式，敏捷是迭代增量的典型开发方法。
讲敏捷实践，不讲Scrum敏捷开发模式，这绝对是有点异类了，毕竟这个模式最成熟且最被广泛使用。敏捷宣言中，个体和交互、工作的软件、客户合作和拥抱变化是一切敏捷的根基，是实践的指南针，是指引未来的方向，Scrum扎扎实实地体现了敏捷宣言，通过很好的透明度，通过检查和适应来改进流程。我的敏捷之旅始于十年前，就从Scrum实践开始的。
Scrum是英文橄榄球运动的一个专业术语，表示“争球”的动作；一个开发模式取名为Scrum，当前是期望开发团队在开发一个项目时，大家自主地像打橄榄球一样迅速、富有战斗激情、人人你争我抢地冲刺完成，自己给自己打鸡血，团队给团队打鸡血，不亦乐乎！
Scrum中的典型术语：迭代Sprint、产品需求列表Backlog、迭代需求列表Backlog、增量Increment、燃尽图Burndown Chart、完成定义Definition of Done等。
迭代Sprint：就是每个开发或发布迭代，一般建议团队2-4周，时间太长或者太短都不太好，毕竟设计、开发、测试都还是需要时间的。这个节奏一旦定下来，不建议轻易改变，按这个时间段来拆需求或者任务而不是反倒来增加迭代长度，保持节奏很重要。
产品需求列表：整个产品是不断演进的，有原始需求池，和不断实现的需求，这些这个需求列表需要定期维护更新，应该每个迭代都会有更新。怎样是个好需求定义，怎样对待技术和业务需求，怎样定义需求字段，都会在后面的文章中体现。
迭代需求列表：放在每个迭代中要实现的需求，这些是相对比较确定的需求，团队可以进一步分解任务。在进入团队前，产品经理其实与一些资深的同事或者某方面的专家，或者根据自己的经验已然评估了可行性，大概的工作量，这其实是保证需求持续不断落地非常重要的一步。
增量：迭代式开发，需求基于不断变化的优先级开发，系统功能增量式叠加，每个迭代都有产出，有演示，可以说都有惊喜。这个和瀑布一开始全量确定需求差距比较大，这也反映了敏捷拥抱变化的特点。即使对团队来说，不断成长同样重要，每个迭代有提高，此所谓产品和团队共同成长。
燃尽图：从迭代开始预估的工作量是一个很大的数字，随着迭代的进行，原则上剩余工作量都会逐步减少，如果幸运的话甚至是条笔直的曲线。但事实往往不是这样，有时曲线向上，预估工作量太乐观，剩余工作量突然增多，考虑漏了；有时曲线向下，预估工作量太悲观，可以增加一些新的工作量。最理想的情况是燃尽到零。这些趋势图也可以作为后续回顾的基础。
完成的定义：迭代结束，针对每个需求，都要确认它是否完成，包括开发、测试、文档、缺陷等是否完成。团队需要对完成的定义达成一致，需要测试完、演示完、自动化完才算100%完成等。这一点也很重要，整个产品或者项目需要达成这样的共识，才能有助于团队之间的互相交流，在敏捷社区中互相促进。
Scrum三大角色：Scrum主管(ScM，Scrum Master)负责维护过程和任务，类似于项目经理；产品负责人(PO，Product Owner)代表利益所有者，开发团队成员(Team)包括所有开发人员，主要具体实现产品，完成可工作的软件。
Scrum Master：保证Scrum团队可以遵守敏捷的价值，实践和规范、帮助团队和组织采用Scrum模式进行项目流程组织、指导并带领团队变得更加高效，实现更高质量、保护团队不要受到外界因素的干扰、保证各个不同角色之间的良好协作，消除障碍、帮助PO更好地利用团队的能力。
有人说Scrum Master相当于团队Leader或者项目经理，但Scrum的本质上不想该Master管理太多事务，不要管理团队而是服务团队。给ScrumMaster的建议：协助甄选PO人选，并帮助PO了解其职责、如果PO不了解如何很好的利用团队价值，ScrumMaster需要承担负责、ScrumMaster 永远不能同时担任PO、ScrumMaster 可以由团队的成员来担任，但是在这种情况下他将有很重的负担。
产品负责人PO：PO 是一个人并只能由一个人来担、负责管理产品待办事项并保证其对客户和团队保持透明度、对产品代办事项表进行优先级排序、与团队一起来进行工作量估算、对于项目的成功负责并保证投资回报率（ROI）。PO同时会负责维护本领域的产品路线图，负责迭代中支持团队需求澄清和验收，也本领域对外需求的统一接口。
关于PO是否应该关注技术债务相关的需求，答案是肯定的，技术债务同样是团队的工作内容，而且也有对应的ROI。给PO的一些建议：客户项目最佳的PO人选应该由客户的代表来担任、内部项目最佳的PO人员应该由业务经理担任、PO可以由团队成员担任，但永远不能由ScrumMaster担任。
团队Team：最佳团队大小5-9 人，一个披萨可以让团队吃饱、多功能团队，成员包括程序员，测试人员，设计师，数据库管理员和架构师甚至文档人员、保证团队成员全职参与开发、自我管理，没有头衔之分，不组建子团队、成员更替只能在迭代之间进行，最佳方式是在发布之间进行。全职参加是指完成了分配到的任务额即为全职参加。并不是指全程参加。
团队的自管理非常重要，要求每个人都要有责任心，对自己和团队的承诺负责。不少团队还是共享数据库管理员，配置管理员，文档工作，架构师等，如果约定完成分配到的任务，那也算是全职参加。最重要的是专注而不是不停地切换，当然这非常难。
Scrum中的主要会议：计划会议、每日站会、演示会议和回顾会议。
计划会议：一般分为两轮，第一轮沟通比较快速，不超过一小时，产品需求沟通，主要由PO主讲，确认迭代要做的、具有明确优先级的需求，根据团队的迭代容量来看能烧掉的需求，这中间是可以讨论和拆分的、第二轮为团队主持，在分析第一轮的需求后分解任务，持续时间两到四个小时，会上对每个任务进行扑克牌游戏估计和PK工作量，得到每个任务的实际工作量，进而得出该迭代实际计划完成的需求和任务。当然，这里可能会分必须要做的需求，和最好能够做的需求，尽量减少乐观或者悲观估计的影响。
每日站会：一般持续十五分钟，是敏捷方法最基本的实践。Scrum Master主持，通常在白板前进行，每个团队成员轮流回答三个问题：昨天做了什么？今天会做什么？遇到什么困难、需要什么样支持？这里强调提出问题，更新任务剩余工作量，主动认领任务，一些具体跟进和讨论通常在会后进行，避免全组成员都受到干扰。
演示会议：迭代成果，主要是展示该迭代工作的软件，团队组织，参与者可以包括各种利益干系人，专注在软件本身而不是背景流程等，如果有需要优化的地方可以放在下个迭代进行，原则上演示前基本功能测试已经完成。让大家看到团队的成果，尽早反馈，听到产品经理的声音。
回顾会议：更多的是针对流程而言，产品本身的东西已经在演示会议里面进行了。通常演示会议和回顾会议同一天进行，这里主要参与者来自团队内部。回顾这个迭代中哪些做得好的，需要保持的；哪些做得不好的，需要改进的；以及改进的点子是什么，最亟待解决且可行的本组的改进建议，以及需要上升的改进建议，一般不超过三点最值得改进的。当然，回顾的方式方法可能有变，但不变的是持续改进，团队越来越好。也有不少衡量团队敏捷成熟度的工具，可以通过定期测评来看到团队是否有改进。
当然也有一些临时的某些紧急，大型需求的拆解会议，主要是PO和技术大牛们一起先大致评估；或者迭代前的团队需求对齐会，由关键利益相关者进行；或者整个大产品团队的Scrum of Scrum、演示和回顾等跨团队会议，这些都是敏捷有益的补充。
不管是Scrum Master，PO还是团队成员，不管是计划会议，还是每日站会，还是回顾展示会，团队都一起全力在迭代中冲刺，有强烈的自我驱动意识，强烈的改进意识，拥抱敏捷价值观和实施原则，在迭代中不断成长，实现产品价值和自我价值。
网友评论