软件开发模式之敏捷开发（scrum）
[原文]https://blog.csdn.net/xiajun2356033/article/details/81513957

[RbY本文转发时已对原文适当整理并纠错;]
转载说明:

敏捷开发（scrum）, 从上世纪90年代开始在国外提出, 2010年以后逐渐引起国内关注;
有人对敏捷开发的理解是“快”,其实只是其正确实施的结果; 这不是敏捷开发的本质;
软件工程实践, 跟造房子那样的土木工程完全不一样; 软件工程是用逻辑构件来搭建,不是物理结构，整个逻辑大厦任何一个节点不合格，软件就可能崩塌;
试着把设计和编码分两个阶段，期望在设计阶段就把需求理清楚，结果证明不可行，而需求还在不断改变，甚至需求可能还是冲突矛盾的;
人类大脑很少拥有完美的理性思维;我们的理性很多时候只能保障一个小环节,涉及到复杂系统就勉为其难了; 于是,敏捷开发就有用了。
敏捷开发的特点就是“摸着石头过河”，又有点像深度学习中的梯度下降法，我们走一步看一步，每一步都走得很踏实(本地测试)，逐渐趋近目标。
敏捷开发比瀑布式开发对团队的要求相对低些，不一定要有高级架构师，不要求完全理性正确，每走一步都有及时的测试来验证。
敏捷开发成功实施的前提是，团队成员对用到的技术栈要熟悉，大家对敏捷流程要认同。
敏捷开发是用来提升协作效率的, 也引入了用来提高软件质量的迭代; 但却难以提升团队成员技术能力; 因此对开发人员个人素质要求更高些;
敏捷开发也适合基于英特网的虚拟团队, 可远程协作分布式开发；尤其对3~12人的小团队更有优势。

本人看过国内最早提到"敏捷性"(介绍敏捷方法的使用,包括极限编程)的书, 是2010年版"图灵计算机科学丛书"之一的《软件工程（第4版）》; [美]Shari Lawrence Pfleeger & [加]Joanne M.Atlee 著; 杨卫东 译;

书名原文：Software Engineering: Theory and Practice , Fourth Edition.
阅读链接:

敏捷开发推荐书：敏捷革命

《敏捷革命：提升个人创造力与企业效率的全新协作模式》该书由【美】杰夫·萨瑟兰所著，于2017年4月由中信出版社出版发行。
-


敏捷开发简介

这几年关于敏捷开发在互联网企业中越来越广泛被使用到，运用的比较多的当属scrum敏捷开发和xp极限开发，人人都在谈论敏捷开发。那什么才是敏捷开发呢？

本文目录

1.什么是敏捷开发？

2.传统的开发模式和敏捷开发模式的对比。

3.敏捷开发scrum的实施。

一. 什么是敏捷开发

敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。
在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。

二. 传统的开发模式和敏捷开发模式的对比

瀑布模型：–传统的开发模式

优点：

为项目提供了按阶段划分的检查点。
当前一阶段完成后，您只需要去关注后续阶段.
它提供了一个模板，这个模板使得分析、设计、编码、测试和支持的方法可以在该模板下有一个共同的指导。

缺点：

各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量。
由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发风险。
通过过多的强制完成日期和里程碑来跟踪各个项目阶段。
瀑布模型的突出缺点是不适应用户需求的变化。

敏捷模型：–敏捷开发模式


优点：
敏捷开发的高适应性，以人为本的特性。

更加的灵活并且更加充分的利用了每个开发者的优势，调动了每个人的工作热情。
缺点：
由于其项目周期很长，所以很难保证开发的人员不更换，而没有文档就会造成在交接的过程中出现很大的困难。

三. 敏捷开发scrum的实施

Scrum的英文意思是橄榄球运动的一个专业术语，表示“争球”的动作；把一个开发流程的名字取名为Scrum，相当于大家像打橄榄球一样迅速、富有战斗激情; 而Sprint意思是短跑冲刺。Scrum就是这样的一个开发流程。
Scrum开发流程中的三大角色
– 产品负责人（Product Owner）
主要负责确定产品的功能和达到要求的标准，指定软件的发布日期和交付的内容，同时有权力接受或拒绝开发团队的工作成果。
– 流程管理员（Scrum Master）
主要负责整个Scrum流程在项目中的顺利实施和进行，以及清除挡在客户和开发工作之间的沟通障碍，使得客户可以直接驱动开发。
–开发团队（Scrum Team）
主要负责软件产品在Scrum规定流程下进行开发工作，人数控制在5~10人左右，每个成员可能负责不同的技术方面，但要求每成员必须要有很强的自我管理能力，同时具有一定的表达能力；成员可以采用任何工作方式，只要能达到Sprint的目标。
scrum开发流程图

1、我们首先需要确定一个Product Backlog（产品需求列表），这个是由PO负责的（如图（一））。
图（一）


2、有了Product Backlog列表，我们需要通过 Sprint Planning Meeting（Sprint计划会议） 来从中挑选出一个Story作为本次迭代完成的目标，这个目标的时间周期是1~4个星期，然后把这个Story进行细化，形成一个Sprint Backlog。
3、Sprint Backlog是由Scrum Team去完成的，每个成员根据Sprint Backlog再细化成更小的任务（细到每个任务的工作量在2天内能完成）；
4、在Scrum Team完成计划会议上选出的Sprint Backlog过程中，需要进行 Daily Scrum Meeting（每日站立会议），每次会议控制在15分钟左右，每个人都必须发言，并且要向所有成员当面汇报你昨天完成了什么，并且向所有成员承诺你今天要完成什么，同时遇到不能解决的问题也可以提出，每个人回答完成后，要走到黑板前更新自己的 Sprint burn down（Sprint燃尽图）（如图（二）和如图（三））。
图（二）



图（三）


5、做到每日集成，也就是每天都要有一个可以成功编译、并且可以演示的版本。
6、当一个Story完成，也就是Sprint Backlog被完成，也就表示一次Sprint完成，这时，我们要进行 Srpint Review Meeting（演示会议），也称为评审会议，产品负责人和客户都要参加（最好本公司老板也参加），每一个Scrum Team的成员都要向他们演示自己完成的软件产品。
7、最后就是 Sprint Retrospective Meeting（回顾会议），也称为总结会议，以轮流发言方式进行，每个人都要发言，总结并讨论改进的地方，放入下一轮Sprint的产品需求中。
图（四）

本文链接:

敏捷开发管理工具：teambition

现代软件工程讲义4 Scrum/Sprint
参考链接:

敏捷开发之Scrum扫盲篇

百度百科

敏捷开发 模型讲解

转自：http://blog.sina.com.cn/s/blog_48258fbe0100eehi.html

一个软件从开发到上市(我们抛去维护部分), 一般需要经历阶段有 需求分析, 方案设计, 开发方案设计(包括概要设计, 详细设计等), 测试, 交付. 相信这些名词在软件工程中大家都能找得到, 那在这些过程中, 具体怎么实施呢?
    先看下面的流程图:
    
一. 前期准备阶段
    有很多人不太重视前期的准备, 或者不太在意这方面的事情. 还有一个问题, 前期的准备要准备到什么程度?
    在我这里, 前期要做好三件事: 需求分析工作, 数据分析工作, 概要开发方案
    需求分析: 这部分就是我们的专业需求人员所要处理的事情. 主要负责把本次版本中的功能分析清楚.我们一直强调一点, "需求要明确", 不允许在需求文档中出现类似"跟XXX一样"等这种含混不清的字眼. 一般来讲, 分析到此业务的背景, 解决的问题, 用户的操作场景, 有这些信息有可以了.
    数据分析: 尤其在我们的计价软件中, 定额库是不可缺少的东西. 他是你程序能够运行的前提.对于数据如何制作, 用何种方式制作能,制作成什么格式是最省力的, 对开发, 对数据人员的加工量是最少的, 能否支持程序运行. 数据的存储的介质,格式决定了后面的开发方案
    开发方案分析: 目标达到能说清楚这件事怎么做就可以了. 内容格式方面可以自由扩展. 可以以下面的我的分析方案为参考:
   可参考我之前的博客:<<概要设计 －－需求定义及描述方式>>
     http://blog.sina.com.cn/s/blog_48258fbe0100b54a.html
    
  图2(需求分析格式)
   
 二. 方案评审
    这一步是必须的. 让业务专家, 或者有经验的人给你把下关.这样对你的方案是一个很大的补充. 一个人的想法很难保证想的很全, 所以, 可以经过这个环节进一步充实你的方案.等这一步完成后, 你会形成项目列表. 就是针对每个开发功能, 拆解为详细的开发步骤, 并估算出工时, 如下图所示:
   
  图3(任务分析明细图)

这样有助于你完成更为详细的开发计划. 一定要把任务项列细了, 越细, 对后面的进度控制就越有帮助.
 
三. 项目启动会议
    正如我上上篇文章所说, 这个过程的好坏会对后面的开发任务有很大的影响.在这个过程, 重点是进行需求交底. 把前面的分析结果再加上已经评审通过的内容做成PPT, 给整个团队成员做讲解. 让团队中的每个成员都能知道
     我们很难保证让团队中的每一个人都能把所有的业务都理解的很清楚, 这是很难办到的, 但可以保证的是,当这个任务为某个人做的时候, 他会更专心的去听这块内容, 对于要执行者,他是最为关注的. 这样当需求交底完成的, 可能是大部分人对需求都有所了解, 理解度在20%~60%左右吧, 但执行此任务的人理解度应该能达到90%左右. 不用担心, 我们后面有办法让那些只理解20%的人也能掌握另外的没掌握的内容.
    当需求交底完成后, 就要开始进行方案交底了, 一般你会把之前分析的内容给大家讲出来, 并给出自己的一套默认的开发方案,然后由大家来评审这个方案如何.
    在这个过程,有开发, 有测试, 有需求, 有数据,都会从不同的角度去分析此问题.在讨论过程中,那些本来可能还是太懂的人, 结过这么讨论,就会更明白了许多. 这样, 其理解度会上长到50%应该是没问题的.做为主持者, 当你发现某些人确实不在状态时,可采用单独提问方式来让他加深记忆,这都是可以的.
    还有不太清楚业务的, 没关系, 下面我们就要根据前面敲定的方案来排定任务了. 因为已经经过了前面的方案讨论, 所以对开发的时间应该有所把握, 这时,对于不清楚业务而无法估算出时间, 或者为了估算出正确的时间以至不会让自己任务拖延的, 也要再熟悉一遍需求. 经过这样, 需求基本上就都搞清楚了.那最后就要出我们的作战图了:
   
   图4(作战图示例)
 
    之前也说过, 作战图的作用, 就是把事情盘点清楚(当然你也可以理解为"网络图"), 让每一个人所做的的任务都能具体到整个过程的位置, 地位, 清楚自己的任务在整个项目中处在什么样的关键位置上.
    这就是作战图的优势, 把团队的目标凝聚在一起.
四. 迭代开发
   如上幅图所示, 我们有很多任务点, 任务项, 我如何能让在开发过程中, 让我们的团队更具有凝聚力, 更能向上呢, 答案就是自适应团队. 那如何才能实现呢.
    那就是短周期迭代. 我们可以把每一个任务做成一个小周期的迭代. 你这个迭代必须是有交付物的, 没有交付物, 那就没办法验证你的成果.
    在这个过程中, 我们只需要回答两个问题就足够了: 1. 能不能用. 2.有什么用. 当你进行完这个迭代后能回答这两个问题, 那么, 我就可以认为这个迭代完成, 可以进行一下个周期的迭代.
    以前我们在排定任务的时候, 总是在想着这个任务开发完成后再交由测试去测.这样相当于开发与测试在并行, 相互的交集就比较少. 开发只管开发的事, 完了后修改BUG就行了. 而测试呢, 只需求不停的测试版本就行了, 什么也不用管. 这样带来的问题就是修改BUG不及时, 有可能会出现开发成了这个功能好久后测试才提出这个问题, 开发再去修改. BUG越往后修改效率就越差的.
 所以, 应该想办法让任务风险前移.
    当我给定一个开发任务时, 当他提交时, 应该是严格结过测试, 需求确认的. 测试的验证, 保证了该功能是"能用"的问题, 而需求的评审通过意味着该功能的"有用的", 自然也就是有价值的. 有用, 但不能用, 价值无法传递出去; 能用(可以使用), 但没用(此功能没有意义), 相当于做无用功. 所以在交付时, 一定是回答了"能不能用", "有什么用"之后的. 
    这样, 在排定任务时, 就把开发, 测试, 需求无形中绑定在一起了, 自适应何愁不来.
    在迭代开发中, 过程监控的方式手段很多, 比如我们常用的: 晨会, 夕会, 周会, 每日汇报. 项目可的可视化方式也有很多, 比如常用的任务燃烧图, BUG趋势图, 明细任务显示图等.   
    说到这不得不提下每日汇报的内容. 每日汇报, 就是把当前的工作内容以可视化的方式呈现出来. 有本书叫"一页纸项目管理", 里面介绍的方法就很好, 我又把它本地化了下, 显示的方式如下图所示:
 
  图5(每日汇报明细)
  点击查看大图
 
    这种方式能让你控制每一个小的迭代细节中, 能让你的控制更加周密. 大家可以不防试试.
 转载自：http://blog.sina.com.cn/s/blog_48258fbe0100eehi.html
 关于任务任务燃烧图, 他是从整体项目上对你当前产品的进度做出的评价, 有利于你及时调整项目中的瓶颈问题, 如下图所示的燃烧图: 他的做法就是总工时, 已剩余工时之前的关系来决定的.
    
 图7(进度控制超前的燃烧图)

 图8(进度失控的项目)
  结合这两种分析方式, 就可以看出项目中存在风险的项目是什么了.
五. 集成测试
    在这个过程中, 最重要的反馈产品质量的就应该属BUG趋势图了, 可以反应出当前产品的BUG曲线, 来预测产品的质量. 关于BUG管理工具方面, 现在市面上也有很多, 比较有名的像BUGFree之类的, TD也不错的, 不要收费比较高.
 
六. 最后就是发版了.
   自然要经过评审, 确认本次版本中依然存在的问题, 解决的问题内容.

在日常工作中，产品经理需要经常和业务流程图打交道。对于新手产品经理来说，业务流程图也是必须掌握的基本功之一。但是绘制流程图并不是一件简单的事情，本文作者从自身工作实践出发，结合相关案例，对绘制流程图常见的一些问题进行了梳理，并分享了绘制业务流程图的具体步骤以及注意事项，希望对你有所帮助。
一、绘制业务流程图存在的问题
产品经理在梳理业务时，经常会用到业务流程图。绘制业务流程图，是产品经理的基本功。
然而，由于缺乏正确的方法和足够的训练，不少产品经理绘制的业务流程图，存在一些问题。这些问题，严重影响了表达需求的质量和效率。下图是一个同事的作品：
这个流程图，主要有以下3个问题：
1. 难以理解
流程图的使用规则中，每一种图形，都有科学、约定俗成的含义，且被大家广泛接受。见到矩形，就知道这是操作；见到菱形，就知道这是逻辑判断；见到圆腰矩形，就知道是流程开始或结束；见到注释框，就知道这是对某个节点的注释说明······
绘制流程图时，应该准确使用图形，让读者用约定俗成的方式理解流程。
上图中，“OCR识别身份证”节点下方的信息采集内容清单，不是一个操作节点，仅仅是对“OCR识别身份证”节点的补充说明。应该改用“注释”来表达：
菱形表示的是逻辑判断，通常有2个或多个结果。不同的结果，有不同的下一步操作。但途中并没有对不同的判断结果作备注，读者无法明确流程走向。应该要对不同结果对应的“箭头”进行备注：
不规范地使用图形，就如同错误地使用标点符号，会导致读者难以理解，甚至误导读者。
2. 遗漏关键节点
为了确保达成业务目标，业务执行过程中，存在一些必须要执行的任务，这就是关键节点。如外卖业务流程中，“骑手到门店取货”是一个关键节点。
业务流程图若缺少关键节点，无论是产品经理据此设计详细产品方案，还是研发据此开发功能，都可能会导致遗漏重要的功能模块。最终上线的产品，无法满足真实的业务需要。
上图中，身份证过期后，应该要先返回上传身份证页面，再重新上传身份证；缺少了重新上传身份证的关键节点，直接重新检验身份证有效期，必然会再次得到身份证过期的结果，如此，就进入了一个死循环：永远都是在检验同一个过期的身份证。
很明显，这个功能，必定无法解决身份证过期的问题。
后面的检验身份证真实性、人脸识别也存在同样的问题。
缺少关键节点的业务流程图，无法准确、完整地描述业务执行过程，最终导致产品缺少重要功能模块，无法满足业务。
3. 与实际情况不符
业务流程图要真实还原业务真实的执行过程。如果与实际情况不符，不仅会使团队不信任产品经理，还可能导致产品出现bug，引发严重的产品事故。
帐号登录流程中，若密码正确性校验的结果是“错误”，流程图的下一个任务节点，应该是“登录失败”，并提示密码错误。如果下一个任务节点是“登录成功”，则明显违背逻辑和常识。
当开发看到这样的流程图，必定会认为产品经理不专业，或者按自己的理解来完成开发。
最后上线的功能，要么提示登录成功，但实际上并没有登录成功；要么在密码验证失败的条件下登录成功，但这意味着不需要验证密码也能登录，造成严重的产品事故。
准确描述业务执行过程，是对业务流程图的基本要求。如果连实际情况相符都做不到，那就失去了存在的意义。
上图中，活体检测不通过的后续处理节点应该是“重新进行活体检测”。人脸比对不通过的后续处理节点应该是“重新对比人脸”。
但流程图中，后续处理节点都是“人脸识别失败”，这明显违背常识。
二、如何绘制业务流程图？
业务流程图的是描述是业务执行过程中，各个参与角色，以什么样的顺序，分别完成了哪些任务的图表。按角色、任务、顺序、异常、完善调整5个步骤，即可绘制出高质量的业务流程图。
1. 角色：找出参与业务的角色
业务的执行，是由一个或多个角色共同完成的。要理清业务执行过程，首先就要知道，有哪些角色参与了业务，然后才能逐个拆解各个角色分别承担的任务极其顺序。如服装店销售衣服，参与角色有消费者、导购员、收银员、消费者等。
角色可以是某个群体，也可以是一个岗位的抽象，还可以是某个系统。
外卖平台中，商家是一个角色，负责提供商品；快递员是一个角色，负责提供配送服务；分单系统也是一个角色，负责匹配最佳接单师傅。
当然，由于执行团队的规模不同，可能会存在一个人承担多个角色的情况。此时，应该按多个角色来梳理业务流程图，因为不同角色由不同的人来承担才是常态。
为了清晰区分各角色所承担的任务，在绘制业务流程图时，分别为各个角色划定区域(即泳道)，用于放置各自的任务。
2. 任务：穷举并抽象各角色承担的任务
任务节点是业务流程图最重要的内容。为了充分、完整地理解业务执行过程，我们在做需求调研时，要穷举出各个角色所承担的任务，并详细了解每个任务的具体内容。
业务流程图要能让读者快速理解，因此，必须要用简洁、准确的文案，明确告知读者，该角色做了什么事情。但实际业务执行过程中的任务，有些任务比较复杂。此时，要对任务的具体内容进行抽象和提炼，提取任务要点，并使用“动宾结构”，对任务进行描述。
尝试穷举帐号注册业务流程中，用户角色的任务：
输入手机号；
输入图像验证码；
获取短信验证码；
输入短信验证码
提交注册申请。
系统角色的任务有：
校验手机号状态；
生成图像验证码
校验图形验证码；
生成并发送短信验证码；
校验短信验证码；
创建新帐号。
在穷举和抽象任务时，会先习惯性围绕着业务最终目标，去罗列任务，而忽略掉实际执行过程中，对异常情况的处理任务。因此，要对每个任务节点，仔细思考，并与业务方确定：是否有异常情况出现？有哪些异常情况出现？出现异常情况后，要如何处理？
帐号注册业务中，输入手机号后，可能会检测到手机号已存在；校验图形验证码和短信验证码时，可能会因为验证码过期或错误，导致验证失败。
为了处理这些异常情况，系统角色还需要处理的任务有：
返回手机号异常提示；
返回图形校验码错误提示；
返回短信校验码错误提示。
3. 顺序：按顺序串起主流程
业务执行过程中，各角色承担的任务，是按特定顺序完成的。业务流程图要真实还原业务执行过程，就必须准确表达出任务执行的顺序。
按业务方的期望，顺利完成的正向流程，称之为主流程。在主流程执行过程中，可能会出现一些特殊情况，描述对特殊情况进行处理对流程，是分支流程。
如帐号注册业务中，顺利完成帐号注册是业务方的期待，描述该过程的流程，就是主流程。而注册过程中，对处理异常情况的处理，是分支流程。
分支流程依附于主流程，对主流程进行补充。因此，在绘制业务流程图时，应先绘制主流程，再补充分支流程。
在绘制主流程时，先从所有任务中，挑出主流程的任务，再找出可能需要的逻辑判断，最后按执行的先后顺序，用箭头连接起来，即得到主流程。如下图所示：
绘图过程中，建议使用约定俗成的图形，来表达对应的含义，以方便读者理解。流程图图形的使用规则见下表(图片来源网络)：
4. 异常：补充分支流程
主流程只对业务目标顺利达成的正向流程进行描述，是不完整的。因此，必须要补充处理异常情况的分支流程。
从穷举出的任务中，找出异常情况对应的任务，将其补充到主流程中。见下图蓝色部分：
为说明分支流程的执行条件，需要在判断框(菱形)的多个分支路径的箭头上，标记分支流程对应的逻辑判断结果(见上图红色文字)。
5. 完善、调整流程图
主流程和分支流程绘制完成后，还要对业务流程图进行必要的完善和调整，确保最终效果更规范、更容易阅读和理解。
主要有以下3个点：
在首尾增加“开始”、“结束”节点，确保每个分支流程都有结束；
调整位置，使每个节点都在正确的角色泳道中；
尽可能避免线条交叉，确保流程图整齐美观。
调整后的业务流程图，如下图所示：
三、5步法的价值
一张高质量的业务流程图能将各个角色承担的任务，有逻辑地表达出来，帮助我们更清晰地梳理业务。
同时，在与业务部门确认需求、与研发同事评审方案时，对方能从业务流程图中，更高效地理解业务逻辑和规则，降低需求同步的成本。
按角色、任务、顺序、异常、完善调整的方法绘制出来的业务流程图，能完整、准确地描述业务执行过程，并用行业约定俗成的方式来表达，避免读者产生歧义，同时还能提高读者的阅读体验。
四、注意事项
1. 尽量规范但不追求绝对标准
绘制业务流程图的目的，是为了还原业务。只要能准确、完整地描述业务逻辑和规则，就是一张合格的业务流程图。
如果为了追求绝对的规范和正确，而投入大量的时间，反而得不偿失。
2. 把握好任务节点的颗粒度
业务流程图是为了描述业务流程，而不是操作流程，不需要将每一个最小颗粒的操作都包含进来。
业务流程图过于详细，会让读者过早陷入操作细节，不利于读者理解更宏观层面的业务。
总结
业务流程图能很好地帮助我们梳理业务、高效表达需求。在绘制业务流程图时，应该先找出参与业务的角色，然后穷举各角色的任务，再将顺序绘制出主流程，并补充分支流程，最后再进行完善和调整。
绘制好业务流程图，需要在工作中多练习、多检查、多应用。在准确描述业务逻辑和规则的前提下，尽可能地做到规范和整齐，同时权衡好标准和效率。
#专栏作家#
誓博，微信公众号：产品慎思录。人人都是产品经理专栏作家。5年产品经验，电商售后平台后端产品负责人。
本文原创发布于人人都是产品经理，未经作者许可，禁止转载。
题图来自Unsplash，基于CC0协议。