敏捷开发实践总结(8大流程与12大原则)

敏捷开发实践总结(8大流程与12大原则)-mikechen

现在敏捷开发在互联网界,基本算是主流思想,大家都在不断强调小步快跑、快速试错,于是敏捷开发被大家大力提倡,究竟为什么要提倡敏捷,敏捷开发的流程与原则是怎样的。

下面我一一来详解,先从什么是敏捷开发讲起@mikechen

什么是敏捷开发

敏捷开发的起源

2001年2月,Martin Fowler,Jim Highsmith等17位著名的软件开发专家齐聚在美国犹他州雪鸟滑雪圣地,举行了一次敏捷方法发起者和实践者的聚会。

在这次会议上面,他们正式提出了Agile(敏捷开发)这个概念,并共同签署了《敏捷宣言》。

敏捷开发的定义

敏捷软件开发又称敏捷开发,是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法,是一种应对快速变化的需求的一种软件开发能力。

它们的具体名称、理念、过程、术语都不尽相同,相对于“非敏捷”,更强调程序员团队与业务专家之间的紧密协作、面对面的沟通(认为比书面的文档更有效)、频繁交付新的软件版本、紧凑而自我组织型的团队能够很好地适应需求变化的代码编写和团队组织方法,也更注重做为软件开发中人的作用。

 

敏捷开发宣言(价值观)

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

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

客户合作 高于 合同谈判

响应变化 高于 遵循计划

也就是说,尽管右项有其价值,

我们更重视左项的价值。

你可以从上面定义中,不断提炼出好几个关键词:面对面、沟通、快速、变化、以人为本。你再逐渐回味你工作中的敏捷开发,你会发现大量的工作都是围绕以上维度。你再结合如今的互联网的发展节奏,快速试错、小步快跑、不断调整..你会发现,敏捷开发的确有它存在的土壤。

于是,你发现我们公司落伍了啊,为什么我们公司不加快转到敏捷开发呢,我们应该快速跟上啊。然后你就像如获至宝一样,告知你的boss,我们应该快速跟上。这个场景非常的典型,看见一个好东西,就像如获至宝一样,恨不得马上用上。这与如今大量的传统企业转型一样,恨不得马上把互联网这个工具配置上。

 

敏捷开发流程

敏捷开发流程一般包括8个步骤,具体如下:

敏捷开发实践总结(8大流程与12大原则)-mikechen
1、目标制定,目标对齐:通过市场调研、业务思路、风险评估制定公司规划和目标,根据这一目标产生所有部门的目标并实现对齐;

2、产品规划:产品研发部门根据目标制定产品关键路线图,这个路线图中分布着不同的产品特性和其完成时间;

3、组织产品待办列表:产品规划产生的需求、客户需求、市场人员收集到的缺陷等将组成产品待办列表;

4、需求梳理:然后产品负责人(Product Ower)对这个列表进行梳理,并在需求梳理会(Backlog Grooming Meeting)讲解具体每一个需求,团队成员根据需求的复杂程度评估每个任务的工作量,输出本次迭代的待办事项列表,完成优先级排序等工作;

5、迭代规划:通过Sprint计划会,明确要执行的工作、冲刺目标等,

6、迭代开发:期间会进行每日站会、性能测试、CodeReview、Demo、测试等工作;7、Sprint评审:由每个任务的负责人演示其完整的工作,由PO确定Sprint目标是否完成,版本什么时候对外发布,新增bug的紧急程度等等。

8、开回顾会议:回顾会议由Scrum团队检视自身在过去的Sprint的表现,包括人 、关系、过程、工具等,思考在下一个Sprint中怎么样可以表现得更好,更高效,怎么样可以和团队合作地更愉快。

 

敏捷开发的原则

1:我们的最高目标是通过尽早和持续第交付有价值的软件来满足客户

2:欢迎对需求提出变更 – 即使在项目开发后期,要善于利用需求变更,帮助客户获得竞争优势

3:要不断交付可用的软件,周期从几周到几个月不等,越短越好

4:项目过程中,业务人员与开发人员必须在一起

5:要善于激励项目人员,给他们以所需要的环境和支持,并相信他们能够完成任务

6:无论是团队内还是团队间,最有效的沟通方法是面对面的交谈

7:可用的软件是衡量进度的主要指标

8:敏捷过程提倡可持续的开发,项目方,开发人员和用户应该能够保持恒久稳定的进展速度

9:对技术的精益求精以及对设计的不断完善将提升敏捷性

10:要做到简洁,尽可能减少不必要的工作,这是一门艺术

11:最佳的架构,需求和设计出自于自组织的团队

12:团队要定期反省如何能够做到更有效,并相应调整团队的行为。

 

敏捷开发实践经验

关于敏捷开发的适用性

敏捷只是一种产品开发的步骤,它背后传递的内容价值度高于形式,如果你只抓形式,有点本末倒置。

 

团队至上,以人为本

把人的价值提到第一位,产品人、技术人…产品的提炼和收集在产品经理,如果在第一个环节,产品经理跟不上(综合素质不行),在源头上就遇见了问题,再往下传递到技术的执行的时候,问题会不断叠加到产品发布..(灾难)。

如果你真打算用敏捷,第一个建议,好钱用到刀刃上。找一个靠谱的产品,多1-2倍的钱,这个钱你会获取跟多的回报。

举一个例子,一般产品和技术衔接的时候,会有如下场景。产品最先调研市场需求MRD(技术、测试不参与)->调研完后出PRD(技术、测试不参与)->PRD给打技术做需求评审(技术、测试参与)->需求评审(产品很希望一次通过)->技术方案…,1/2场景一般技术等不参与,PRD一般给到只对需求细化,如果理解没有什么问题就通过。

然后,敏捷里建议的方法,调研等步骤大家应该一起,出PRD的时候要非常详细,特别是流程图一定要画全(这点大部分的产品做得不太好)..

你发现了吗,整个流程里,好的产品在整个过程的重要性。敏捷对人的要求其实蛮高的,很多玩的不好的都在抱怨,其实对人的要求还是蛮高的。

敏捷其实在不断加强源头的重要性,不管是人还是产品,还是需求调研,还是市场分析。倘若有部门提出开发质量0 bug的要求,你也不要太吃惊。

 

适合你的才是最好的

产品本身就需要快速迭代(创业、创新..)。

例如,特别是启动的新项目、新产品,要求更加灵活的产品。创业公司早期,需要一个精简的产品demo试错。

还有很多成熟型公司,对一部分产品不太满意的,可以单独拉出来一个小团队去做敏捷实践。

团队的组成成员要精简,尽量不要太多。

作者简介

陈睿|mikechen,10年+大厂架构经验,BAT资深面试官,就职于阿里巴巴、淘宝、百度等一线互联网大厂。

👇阅读更多mikechen架构文章👇

阿里架构 |双11秒杀 |分布式架构 |负载均衡 |单点登录 |微服务 |云原生 |高并发 |架构师

以上

关注作者「mikechen」公众号,获取更多技术干货!

后台回复架构,即可获取《阿里架构师进阶专题全部合集》,后台回复面试即可获取《史上最全阿里Java面试题总结

评论交流
    说说你的看法