敏捷软件开发概述

        公司从2020年年初推行敏捷，我所在的team从同年4月开始实践敏捷（Scrum方法），至今已经2年多了，突发奇想开个敏捷专栏，记录下过程中我们team保留下来的一些良好敏捷实践。但是，这些实践不一定适合所有的敏捷团队，希望可以作为参考or灵感来源；

        这节先来简单介绍下敏捷吧。

一、敏捷历史发展

        敏捷的起源要追溯到1970-1990之间，由于软件行业的兴起，并在不断的发展过程中发现各种各样的危机，例如超预算，工期延期，最终因为市场变更导致项目夭折等等；在软件危机大量爆发的情况下，许多学者都在探索不同的软件开发方式来应对各种危机；例如：极限编程（XP）；透明化；自适应软件开发（ASD）；特征驱动开发（FDD）；动态系统开发方法（DSDM）；所有这些方式都是为了使用更简单的规则来适应快速变化的环境。

        2001年，17位代表不同的软件开发流派的专家在雪鸟镇举办了一场讨论大会，讨论结果最终形成了《敏捷宣言》并发布；

出处：https://www.jianshu.com/p/df0a6c6e788e

二、《敏捷宣言》四大价值观

        左边黑体部分是敏捷宣言的第一项，其价值更大，我们应该更关注，右边部分是敏捷宣言的第二项。敏捷宣言第一项更甚于第二项。

简单来说，

个体以及互动而不是过程和工具：强调主动沟通氛围，团队成员集中办公，有问题随时沟通，激发主观能动性。而不是通过邮件、办公通讯软件交流等；我们team现在有合肥的同事加入项目，每次交流沟通尽可能视讯或语音；

可用的软件而不是完整的文档：此处强调交付的是最有价值的东西，不过一个条理清晰的文档也是必不可少的。

客户合作而不是合同谈判：是希望在项目中价值最大化，从而建立信任关系，长期合作；

应对变更而不是遵循计划：是指每个迭代有定好的计划，项目实施期间可插入更有价值的活动到下一个迭代，而不是立马停下手中的事情，每个迭代有计划有节奏的进行。

三、敏捷十二大原则

源自四大价值观的十二大原则

第1点：合理规划迭代周期长短，优先交付价值高的；

第2点：态度上不能抵制变更，更高价值的变更安排在下次迭代，这也意味着迭代周期不能太长；

第3点：敏捷的生命周期取决于团队规模和客户业务需求拆分颗粒度，我们组是两周为一个迭代；

第4点：业务人员与客户接洽，负责需求；通力协作这点可以弥补在文档方面的详细程度的不足；

第7点：每次迭代交付的成果一般叫增量，最终交付的软件是在增量基础上加新的需求，但是第一次交付的也要是能独立运行的软件；

第8点：我们team每个迭代预估工时是以每人每周5天八小时的工时，有时候加班不可避免，但是是希望尽可能保持效率稳定，追求可持续发展；

第9点：重点是营造一个技术至上的氛围吧，我们team会通过阅读书籍、开分享会不断提升技术与效率；最近在看《程序员的职业修养》，里面提到Code kata训练，大致就是透过一些小型的程式题目进行重重复锻炼来提升程式设计能力。感兴趣的同学可以尝试看看~

第11点：自组织团队强调自我管理、价值观认可、项目中共同成长，大家协调统一、步调一致、群策群力；

第12点：复盘总结在任何情况下都适用；提出的idea可以在接下来的一两个迭代尝试，敏捷鼓励团队成员在失败中成长。

四、敏捷方法

        “敏捷方法”是一个囊括了各种框架和方法的涵盖性术语，它指的是符合《敏捷宣言》价值观和原则的任何方法、技术、框架、手段或实践。

        常用的敏捷实践有：精益、看板、Scrum、XP极限编程、水晶、DSDM动态系统开发、FDD功能驱动开发、AUP敏捷统一过程。

五、敏捷相关资料

链接：https://pan.baidu.com/s/1GKTpLCMTAtksQwC-Afr-Ag?pwd=zj3e 
提取码：zj3e