「敏捷开发」，不过时的团队协作方式
“每天开会开到天昏地暗且没有针对性？”
“团队的任务混乱做不到责任到人？”
“工作中紧急任务总得不到第一时间解决？”
不知道何时，低效率的开会、无休止的讨论、不合理的流程已成为团队协作看得见的杀手。协作中，大家心知肚明，深受其害，却始终得不到好的解决。也许你该换个思路，从「敏捷开发」的方法论中找一些解决办法了。
8月6日，沙拉大学邀请Ruby on Rails 和敏捷开发的重要推动者蔡望勤分享《如何实现产品的敏捷开发》，不仅深入浅出为我们揭开了产品从0到1的实现方法，更为我们全面展现了一套团队协作的作战方案，帮在场的成员解决以上团队低效的困扰。
8月讲者：蔡望勤
参与创建时尚社交网络公司 P1（探探软件前身），并担任首席技术官。后前往美国硅谷工作并深造。2016年创建深圳市百分之八十网络技术有限公司，在给客户开发创业型项目的同时，孵化过多个开源框架和产品，如：八十二十（80post），单麦小程序。
一、什么是敏捷开发
简单的说，敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。
换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
通俗地讲，你去餐厅点10个菜，餐厅不是一次性给你上齐十盘菜，而是一盘盘做好后就给你上，让你先吃着，不至于干等太久。
二、相比传统开发流程有什么优势？
传统开发流程
敏捷开发流程
如果要把二者进行对比，不妨把传统开发方式比喻成普通火炮，而把敏捷开发比喻成导弹。两种武器打击目标的过程很形象地说明了两种软件开发过程的区别。火炮打击目标时，要想打得准，则要寄希望于一开始瞄得够准，而且对目标运动轨迹估计得够准。一旦炮弹发射出去，就无法对速度、方向进行控制了。任何瞄准偏差，没有预料到的目标移动轨迹变化，甚至风向的变化都会导致炮弹打偏。
而导弹就不一样了，只要设定好目标方位，并不需要一开始就精确瞄准。导弹发射出去后，会持续地收集自己的位置、方向、速度并按照目标的方位不断地调整，最终能够较准确地长距离命中目标。
而这一切的根源在于软件开发是一个复杂的过程，因此在敏捷开发中，团队的流程管理和团队成员的自发协作更重要。
三、具体怎么操作
敏捷是一种指导思想或开发方式，但是它没有明确告诉我们到底采用什么样的流程进行开发，而Scrum就是敏捷开发的具体方式了。
【什么是Scrum？】
Scrum的英文意思是橄榄球运动的一个专业术语，表示“争球”的动作；把一个开发流程的名字取名为Scrum，我想你一定能想象出你的开发团队在开发一个项目时，大家像打橄榄球一样迅速、富有战斗激情、人人你争我抢地完成它，你一定会感到非常兴奋的。
而Scrum就是这样的一个开发流程，运用该流程，你就能看到你团队高效的工作。
首先，明确各自职责
【Scrum的三个主要角色】
产品负责人（Product Owner）：主要负责确定产品的功能和达到要求的标准，指定软件的发布权力和交付的内容，同权力权力接受或拒绝开发团队的工作成果。
流程管理员（Scrum Master）：主要负责整个Scrum流程在项目中的顺利实施和进行，以及清除挡在客户和开发工作之间的沟通障碍，使得客户可以直接驱动开发。
开发团队（Scrum Team）：主要负责软件产品在Scrum规定流程下进行开发工作，人数控制在5~10人左右，每个成员可能负责不同的技术方面，但要求每成员必须要有很强的自我管理能力。
其次，弄清楚团队协作流程
scrum开发流程
具体而言，
Step 1. 产品负责人整理需求，按照优先级列出产品条目即product backlog
产品backlog示例
产品 backlog 是 Scrum 的核心，也是一切的起源。从根本上说，它就是一个个子任务，按照重要性的级别进行了排序。它里面包含的是客户想要的东西，并用客户的术语加以描述。
Step2. 产品负责人与团队召开sprint计划会议
Sprint是“短距离赛跑”的意思，这里指的是一次迭代，也就是我们要把一次迭代的开发内容以最快的速度完成它，这个过程我们称它为Sprint。一个 Sprint 包含团队一次迭代周期中需要完成的各种子任务。同样地，把每个Sprint中的子任务排序就是Sprint计划会议的主要活动。
Step3. 每日站立会议
为了保持团队的高效沟通，团队每天进行1个不超过15分钟的例会。围绕着每日例会，主要汇报三件事：昨天完成了什么？今天计划完成什么？以及你遇到的困难？是的，这里汇报的不是做了什么，而是完成了什么。
Step4. Sprint 回顾会议
当所有的Sprint Backlog被完成，也就表示一次Sprint完成，这时，我们要进行 Srpint 回顾会议。在回顾会议上，每个人都可以贡献和讨论想法。如果没有回顾，你就会发现团队在不断重犯同样的错误。主要讨论三个点：
1） 如果我们可以重做同一个 sprint，有哪些做得比较好的点，需要继续保持
2） 如果我们可以重做同一个 sprint，有哪些需要改变
3） 有关将来如何改进的具体想法
再次，学会运用一些工具
1）任务看板模版
任务看板包含 未完成、正在做、已完成 的工作状态，假设你今天把一个未完成的工作已经完成，那么你要把小卡片从未完成区域贴到已完成区域。
任务看板实例：
每个人的工作进度和完成情况都是公开的，如果有一个人的工作任务在某一个位置放了好几天，大家都能发现他的工作进度出现了什么问题（成员人数最好是5~7个，这样每人可以使用一种专用颜色的标签纸，一眼就可以从任务版看出谁的工作进度快，谁的工作进度慢）
2）计划纸牌
每个人都会得到这13 张卡片。在估算用户故事的时候，每个人都选出一张卡片来表示他的时间估算(以故事点的方式表示)，并把它正面朝下扣在桌上。所有人都完成以后，桌上的纸牌会被同时揭开。这样每个人都会被迫进行自我思考，而不是依赖于其他人 估算的结果。
最后，知道细节不决定成败
我们以往总强调“细节决定成败”，但在敏捷开发的语境中，首先是把产品框架做出来，再在这基础上不断地迭代，如果连框架都没有打好，却一味深究细节是敏捷开发的大忌。
四、重新理解敏捷开发
敏捷开发是一种过程控制论，通俗的说，就是一种做事情的方法。
敏捷开发是一套工具集，里面有形形色色的工具，你可以不搞敏捷，但可以用那么一两个来提高工作效率。
敏捷开发是一种企业管理方式。
五、讲者推荐相关书籍
《敏捷战事--硝烟中的Scrum和XP(我们如何实施Scrum)》作者：Henrik Knibery