敏捷方式是在合作环境自由组织的团队进行产品迭代的开发过程。
为了应对不可预测性，采用增量、迭代的工作节奏。这些被称为冲刺。
敏捷广泛应用于软件行业。根硬件不同软件会不断、无限地变化。
敏捷是一种应对快速变化的需求的一种软件开发能力。敏捷倡导的模式和方法：
1、敏捷软件开发宣言所倡导的价值观：
（1）个体和互动高于流程和工具。
（2）工作的软件高于详尽的文档。
（3）客户合作高于合同谈判。
（4）响应变化高于遵循计划。
尽管右项有价值，但需要更重视左项的价值，左项需要做到合适。
2、敏捷开发的关键原则：
（1）我们的首要任务是通过尽早和持续交付有价值的软件来满足客户；
（2）即使在开发后期我们也欢迎需求变更。敏捷将这些变更转化为客户的竞争优势。
（3）频繁地交付可以运行的软件，数周或数月一次，时间间隔越短越好。
（4）项目期间，业务人员与开发人员共同工作。
（5）招揽积极主动的人员来开发项目，为他们提供所需的环境和支持，相信他们能够做好自己的工作。
（6）开发团队里最省时有效的信息传递方式是面对面交流。
（7）可运行的软件是衡量进展的主要标准。
（8）敏捷流程有利于可持续开发。发起人、开发人员和用户始终保持一个固定的前进步伐。
（9）持续关注先进的技术和优秀的设计，提高敏捷性。
（10）简介令代办工作最少化的艺术是一切的基础。
（11）只有自组织团队才能做出最好的架构和设计。
（12）团队定期反思如何提高效率并调整工作流程。
3、敏捷是一种思维模式和文化意识，而不简单地是一套体系方法。
关注事：尽早交付，价值排序；拥抱变化，提高优势；持续交付，小步快跑；成果达成，衡量进度；持续更新，强化敏捷；精简产品，杜绝浪费；
关注人：团队合作，每日互动；信任成员，给予支持；当面沟通，高效明了；各方成员，稳定节奏。同心协力，自我组织；团队自省，持续改进。
自律是敏捷对团队成员最基本的原则。承诺的东西需要想方设法去完成，需要自己去反思问题到底在哪里。
4、大多数敏捷NPD流程主要组成要素
(1)产品待办列表(backlog)
系统各项需求，通常是一个按照优先顺序排列的产品任务列表。包括功能性和非功能性需求，以及技术团队产生的需求。产品负责人负责对产品任务列表排除优先顺序。
根据迭代周期将产品待办列表切分成若干冲刺待办列表。
一个产品任务项是一个很小单位，可以由团队在一个冲刺迭代中完成。
(2)敏捷流程(scrum)
强调团队协作，以团队为导向。
与传统项目流程区别：传统项目需求固定(计划导向)，敏捷项目日期和资源固定(价值导向)，可不断加入需求。
快速响应不等于敏捷。敏捷是创造并响应变化，从而在动荡的商业环境中创造优势和利润的能力。敏捷是平衡灵活性和稳定性的能力。
快速试错快速验证先做出最小可行产品再求完美。单存求快而丧失稳定性，是敏捷的大忌。我们做敏捷的需要花费大量时间在思考如何在速度和稳定性之间做到平衡。
(3)冲刺(sprint)
冲刺就是一个设定的时间段，期间要完成特定的工作，并为审查做好准备。
每个冲刺开始时要召开计划会议，在会议上产品负责人和开发团队商定在冲刺期间要完成什么。
冲刺持续时间由敏捷专家决定。
冲刺开始后，产品负责人退后，让团队做自己的工作。
在冲刺末，团队向负责人展示完成的工作，产品负责人运用在冲刺会议上确定的标准接收和拒绝团队的工作。
(4)产品负责人(product owner)
唯一有权代表客户利益，在任务列表和需求需求上做出决定的人。
产品负责人不应该支配团队，避免冲刺开始后改变要求。
平衡好相互竞争干系人的利益。
(5)敏捷专家(scrum master)
团队和产品负责人之间协调人。敏捷专家不是要管理团队而是协调团队和产品负责人。
消除团队和产品负责人之间隔阂；协调团队创造力和授权问题；提升团队生产力；确保团队进展实时更新，让所有人可见。
(6)敏捷团队(scrum team)
敏捷团队由7+-2人组成。
团队通常是为了完成冲刺目标所需的各种职能或职位的人组成。软件开发中，团队可能包括工程师，架构师，程序员，分析师，质量专家，测试员，用户界面设计师等。
在冲刺阶段团队为实现目标而自组织，团队拥有自主权。
敏捷团队成员倡导全栈式工程师，一专多能。
5、敏捷三大支柱，五个核心价值观
三大支柱：透明(Transparency)、检查(Inspection)、适应(Adaptation)。
用多种具体的方法和策略来实现透明。
不断调整心态和计划去适应变化。
五个核心价值观：承诺、专注、开放、尊重、勇气。
6、用户故事
用户故事是从用户的角度来描述用户渴望得到的功能。可以反馈某功能对于用户的价值，是敏捷产品管理中的核心概念。是从用户角度出发去描述用户渴望得到的价值，以价值为导向。
用户故事模板(需求描述)：作为什么(角色)，可以什么(功能)，以便什么(价值)。产品人最重要能力之一是洞察需求本质，，捕捉用户的内在动机。
任务内容描述和验收标准描述，到底怎样才叫任务完成。需要平衡快速和稳定性，既要关注看得到的快，还要关注稳定性和可持续发展。
7、用户故事地图
按照业务流程把所有用户故事进行罗列，再按照优先级排序，确定不同发布周期要发布的用户故事。强调在敏捷产品开发中采用用户故事的思维方式。
业务需求最清楚的是PO，对业务需求收集，分析，排序，和迭代验收负责。
SM价值感体现。做一个守望者，帮助团队实施敏捷扫清障碍。营造相互信任的场域和氛围。SM的工作需要口碑化。我们习惯用看到到的，能统计的工作来展示自己的价值，而未必真的有价值。敏捷不能以完成为目标，而是要以交付价值为目标。
8、冲刺计划会议
确定在大的产品待办事项中，本次冲刺要完成的任务。确认用户故事和用户故事优先级，对用户故事进行分解，形成任务。任务要做到小时级别，不能大于一天。(假如任务超过一天，每天开小例会没办法交付成果，无法反应问题，无法为充分交付提供内容)。
产品待办列表(用户故事列表)由PO做优先整体维护并持续完善。
冲刺待办列表(用户故事列表)由团队讨论确定由SM进行跟踪，SM组织会议并对流程进行梳理和跟踪。
每天有个站立会，共享完成，提出遇到问题，今天要做什么。
组织PO进行评审和反思，最后进入下一个冲刺过程。
网友评论