欢迎大家前往腾讯云+社区，获取更多腾讯海量技术实践干货哦~
今天你敏捷了没有？“敏捷”在互联网和软件开发领域从涓涓细流逐渐演变为行业潮流，往小了说是改进了开发方法，往大了说是革了瀑布流式的命——把产品开发引向了快速迭代、小步快跑的路线上。
我们使用 tapd 写 feature，流转、跟踪任务，言必谈敏捷，然而我们是否真的走对了敏捷？（注：tapd 是腾讯内部的敏捷项目管理系统） 。
1.朋友，你听说过敏捷么？
2.离开敏捷工具，我们怎么敏？
3.设计也要介入敏捷流程？
4.敏捷跟文档是对立的？
5.我这有个几百亿的大项目，怎么敏？
6.尽信书，不如无书。
一、朋友，你听说过敏捷么？
程序员说，要有敏捷
从敏捷的滥觞看去，比起方法，这玩意貌似更像一个宗教（笑）。
千禧之初，美国在计算机行业已经走了几十年，瀑布流、螺旋模型、快速迭代...各种各样的软件开发流程雨后春笋各领风骚一段时间。虽然不断变化和完善，但互联网的加速发展让传统方法显得笨重，难以快速适应变化。有十七个程序员（程序员改变世界）在美国犹他州的一个风景区开了个碰头会，找到了一个团队耦合度高，流程极其灵活的方法，他们把它称为agile program development。
这十七个人如同开宗立派的长老，在会议之后给自己起了个名字“敏捷联盟”，他们不仅赋予了新方法名字，还有宣言，甚至纲领。
盐湖城- snowbird（敏捷联盟成立地——雪鸟滑雪场）
显而易见，敏捷是绝对的结果导向，去文档化，去流程化，高效沟通和合作是究极奥义。
看起来是个很不错的方法，文档不重要了，流程不重要了，大家聚在一起说一说就可以了不是吗？太棒了，感觉可以从繁重的文书工作中解脱出来了呢。
失之东隅收之桑榆。一处的方便一定意味着另外什么地方以其他方式运行着简化掉的部分。
去文档，敏捷管理者需要维护更为精细的需求池；去流程，口头沟通成为常态，对团队的耦合度要求更高。
胖友，这里有一份教义，你要不要听一下。
初识敏捷，有一些概念需要了解，如果你是老司机，跳过这部分，阿敏。
agile：迅速，敏捷。这是敏捷的理念也是精髓：迅速响应需求，快速反馈结果。agile 的引入像一股活水冲击着老气横秋的瀑布流模型，速度上跑赢几条街。
sprint：字面意思是短跑冲刺，一个开发阶段被认为是一次冲刺，一个个 sprint 首位相连，构成一个项目。
Scrum:指的是英式橄榄球中一股脑争球这一战术或行为。
scrum 即为这样一种方式，大家一拥而上，团队是球员，球是产品目标，人员环环相扣，围绕着产品目标进行工作。这里面多少有点“统筹法”的影子，人员深入协作以达到最优化效果。
Product Backlog:
backlog 即需求池。待办事项列表。
Backlog 里面写什么：
1.待开发任务。
2.任务优先级。
敏捷需要维护一份详尽的需求列表。这份列表常常要求 scrum 持有人（一般是产品经理）对所有待开发事项有深入了解，并且能够把待开发事项分解成更为细致的任务（或者跟敏捷教练一起，后面我们会再次提到敏捷教练）
story board:
很多领域都有故事板的概念，交互领域里，用故事板表述用户场景、电影领域里故事板用来更具体地描述分镜。在开发领域，故事版是任务流转的可视化窗口，一般有“待开发”“开发中”“待测试”“返工”“待发布”几个区块，所有任务由任务操作者负责流转至于下一个步骤，这样任何一个人项目成员都能看到任务的完成情况。
一个app使用情景故事版
在开发中，故事板展现所有需求的工作流
burn down chart：
燃尽图
一个 sprint 内，人/时是一个比较固定的值。在这个时间框架充分安排开发任务，每天进行时间结算，绘制时间燃尽图。项目成员通过燃尽图获知时间进展，若项目燃尽所用时间与预期时间契合，则需求时间预估和安排合理，若不契合则需要在下一个 sprint 进行调整。
名词听起来都玄乎乎的，很符合开宗立派的气质。这些概念定义了敏捷各个环节的工作，这些流程和节点是敏捷开展的基础和保障。
二、离开敏捷工具，我们怎么敏？
一个误区：我们用了敏捷管理工具，就敏捷了
随着敏捷在行业内的不断融入，各种工具产品层出不穷。国外jira、redmine，Axosoft ，国内的leangoo 、禅道，三大家则都有自研的工具，百度的icafe，阿里的aone，我鹅自研tapd。
（数据来源：“2016中国开发者白皮书”）
我们在 tapd 上建迭代，建需求，研发、测试等着收到需求流转的邮件之后开始干活...任务在测试和研发之间流转，bug 提给研发，研发解决 bug .....我们宣称：我们敏捷化了！
我们习惯于敏捷软件的便利，拉群解决一切，然而却丧失了敏捷的初衷，scrum 的本意。
Jira的名字来自于哥斯拉
假设我们没有任何项目协同软件，敏捷怎么实施？
设定一个环境，现在没有任何协同工具可用，但是所有人都坐在一起。有人站起来说，既然这样，我们不如敏捷吧！
敏捷工具消失了
敏捷路径里必须有一个项目持有者，制定规划并把握项目走向。这位产品汪我看你骨骼惊奇，你就担负起这个责任吧。
另外还有一个关键人物 SM（别想歪）。SM 全称 scrum master，中文称敏捷教练。一般说来，SM 需要由对技术开发以及当前项目明晰的技术经理担任。
虽然缺少线上工具，但至少要准备一些简单材料：一卷双面胶+白纸或一沓便利贴；笔，一面平坦的墙或一块黑板。
如果还有电脑可用，excel 或者 word，甚至写字板都可以，没有电脑那就白纸好了，总之你得找个地方写下你的需求池（backlog）
需求池示例(任务名称、平台、详细描述、优先级按照P0-PX逐渐递减)
确定一个 sprint 周期的自然天。可以用月/旬/周等时间概念作为周期，我们选择一周（五个工作日）作为一个 sprint 周期。
按照优先级，从需求池中拉出你认为应该加入你们一穷二白的第一个 sprint 里面去的需求，别太贪心，大概觉得差不多一周左右的开发量就够了。拉上SM桑单独开一次小会。
当然不是让你俩傻站着，你俩要开会
你们一起通览需求，SM 桑根据经验对需求先行分解一遍，比如某需求在开发层面需要分解为 ABC 三部分，这三部分就形成三个开发任务。
分解完成后，你得到了一个比较详细的待开发列表。
正式开始一个 sprint 开始之前，产品、研发、测试需要一同开一次 scrum 会议，共同讨论本次 sprint 的功能点。
会上讨论什么：
1.需求讨论或技术讨论；
2.成员预估需求所需开发时间；
3.需求是否match人力时间，需求排入sprint；
4.交流一下感情。
每个任务的预估时间在最后由敏捷教练综合判定
scrum 会后你的工作：
1.整理这个 sprint 内的需求列表；
2.整理每个需求的预期开发时间；
3.撰写故事版上的小纸条；
4.把小纸条贴到故事版上；
5.制作一个燃尽图。
一个改良版的小纸条，写明开发者、任务描述、预估时间和每日燃尽时间
故事版布局如下：
一个标准的故事版：最开始所有的小纸条都在“待开发”一栏
到此为止，你可以开始 run 起一个 sprint 。
以为这就完事了？天真。
接下来你必须来参加每日举行的项目短会。这个环节在 agile 中非常关键，是 agile 的日常修炼。为了缩减会议时间，我们一般站着开——所以也叫“站会”，早上上班后或晚上下班前，抽出十到十五分钟时间，完成它。
每日站会
站会都有什么人参加：
1.你（项目持有者）
2.SM
3.其他 scrum 成员
