敏捷开发

敏捷开发

本期嘉宾：陈洪

分享主题：《“冲刺”——敏捷开发简述》

朋友，听说过敏捷吗？

千禧之初，美国在计算机行业已经行走了几十年，瀑布流、螺旋模型、快速迭代...各种各样的 软件开发流程如雨后春笋各领风骚一段时间。虽然不断变化和完善，但互联网的加速发展让传 统方法显得笨重，难以快速适应变化。

有十七个程序员(程序员改变世界)在美国犹他州的一个风景区开了个碰头会，找到了一个团队耦合度高、流程极其灵活的方法，他们把它称为agile program development。

什么是敏捷开发？

敏捷开发12宣言

持续 断的及早交付有价值的、使客户满意的软件

拥抱变化

持续交付，我们要更短的周期

紧密贴合，业务/产品/技术 员我们天天在一起

持续交付，我们要 短的周期

激发 志，提供一切援和信任

face to face，要面对面交流

标明确，可工的软件是第一要素

持续开发，责任 /产品/技术共同维持步调

追求卓越，在过程中持续成

最好的，都来自我组织的团队

提高效率，善于总结，善于调整

显而易见，敏捷是绝对的结果导向，去文档化，去流程化， 高效沟通和合作是究极奥义。 看起来是个很不错的方法，文档不重要了，流程不重要了，大家聚在一起说一说就可以了是吗?太棒了，感觉可以从繁重的文书工作中解脱出来了呢。

BUT。一处的方便一定意味着另外其他什么地方以其他方式运行着简化掉的部分。

去文档， 敏捷管理者需要维护更为精细的需求池;

去流程，口头沟通成为常态，对团队的耦合度要求更高。

说简单点

个体和互动高于流程和工具

工作的软件高于详尽的文档

客户合作高于合同谈判

响应变化高于遵循计划

敏捷开发的三个层面

关于概念

Agile： 迅速、敏捷。这是敏捷的理念也是精髓：迅速响应需求，快速反馈结果。

Sprint：冲刺；一个开发阶段被认为是一次冲刺，一个个sprint首尾相连，构成一个项目。

scrum：传统上是指橄榄球中争球这一战术行为；在软件中，大家一拥而上，团队是球员，球是目标，人人环环相扣，围绕产品目标进行工作。

product backlog：需求池、待办事项（尽可能的把事项分解成更细致的任务）。

story board：故事板，用户故事。简单来说，就是用户需求。

怎么敏上面给了那么多敏捷工具，来，我们做一个最简单的敏捷计划。

我们需要贴纸、笔、一面墙。

根据表格，写下我们的需求。再确定我们一个sprint的周期（不超过2星期）

然后，按照我们的需求优先级，拉出一个最优先的、并且在一个sprint的周期内能完成的开发量

拉上我们的技术经理，对需求进行拆解，细化到详细的任务内容

敲黑板！开始开会！拉上产品、设计、研发、测试、运营开一次sprint的会议。

讨论问题：

需求讨论、技术讨论

成员预估所需的时间

是否要减去/加上新需求

交流感情（别打架）

5. 讨论完成后，全部记录成小卡片，贴到

我们的故事板上

6. 任务预计完成时间、本次sprint的需求

到此为止，我们就可以run一个迭代了

不过！过程才是重要的！

我们要每天举行短会，大家站在一起，10-15分钟完成讨论并不限于：

昨天做了什么？遇到什么问题？

小卡片的状态是否变化？需不需要修改时间？

再次交流感情！

PM要干嘛？

短会结束后，绘制燃尽图

周而复始，直至完成一个迭代，在下一次迭代会议上，我们有了新的议题：

回顾上一次产生的问题、任务太多、返工太多、需求变更等等

重要的东西

产品文档

概要设计

借口文档

总结

敏捷是一种流程、方法、理念，甚至信仰。

用了敏捷管理软件不一定就是敏捷。敏捷的初衷是团队成员能够更加紧密地配合完成工作，线上的流转如果削弱了这种配合性，反倒背离了敏捷的本意。实际上只要有白板、纸张和笔，你的团队就能开始敏捷。

我们敏捷了，是不是不要文档了？在外部交流多、世代跨度长的情况下，文档的必要性显而易见。长期的面对面沟通最终会导致低效，这也是敏捷缺陷的根源。

大项目开发中可以走敏捷，具体问题具体分析，需要根据项目特点制定敏捷计划。

最后

易好房产品部每周分享，下周见～