一文搞懂敏捷开发

本文为博主原创，未经允许不得转载：

　　本篇目录结构如下：

　                                     

 

 

1.什么是敏捷

　　敏捷是一种思维模式，敏捷是指能够让团队思考更加有效，工作更为高效，并且做出更好决策的一组方法和相关理念

2.敏捷宣言的四大价值观

　　四大价值观意在通过亲自开发和帮助他人开发，发现开发软件的更好方法

　　　　1.个体以及互动   而不是  过程和工具

　　　　2.可用的软件       而不是   完整的文档

　　　　3.客户合作          而不是合同谈判

　　　　4.应对变更          而不是遵循计划

　　右侧的项目固然有价值，但敏捷更重视左栏中的项目。《敏捷宣言》的价值观和原则的一个核心宗旨是强调个人和交互的重要性。敏捷优化了价值流， 强调了向客户快速交付功能，而不是怎样“用”人。

　　

3.敏捷宣言的十二大原则

　　1.我们的最高目标是，通过今早的持续交付有价值的软件来满足客户的需求

　　2.欢迎对需求提出变更，即使在项目开发后期也不例外，敏捷过程要善于利用需求变更，帮助客户获得竞争优势

　　3.要经常交付可用的软件，周期从几周到几个月不等，且越短越好

　　4.项目实施过程中，业务人员与开发人员必须始终通力协作

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

　　6.无论是对开发团队还是团队内部，信息传达最有效的方法都是面对面的交谈

　　7.可用的软件是衡量进度的首要衡量标准

　　8.敏捷过程提倡可持续的开发。项目发起人，开发人员和用户应该能够始终保持步调稳定

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

　　10.简洁，即尽最大可能减少不必要的工作，这是一门艺术

　　11.最佳的架构，需求和设计将出自于自组织团队

　　12.团队要定期反省怎样做才能更有效，并相应的调整团队的行为。

4. 敏捷解带来的好处

　　1.敏捷项目可以按时完成，为那些苦恼于交付期限和预算的团队带去了福音

　　2.敏捷项目交付高质量的软件，那些受困于bug和低效软件的团队会迎来巨大的变革

　　3.敏捷团队构建的代码结构优良且易于维护，那些常常维护负责又混乱的代码的团队会得到解脱

　　4.敏捷团队会让用户满意，不再交付无法为用户带来价值的软件

　　5.最重要的是，在出色的敏捷团队中，开发人员不用加班，可以与亲朋好友共度晚间时光和周末

5.敏捷项目的生命周期类型

　　1.预测型生命周期：这是一种更为传统的方法，提前进行大量的计划工作，然后一次性执行；执行是一个连续的过程

　　2.迭代型生命周期：这种方法允许对未完成的工作进行反馈，从而改进和修改该工作

　　3.增量型生命周期：这种方法向客户提供各个已完成的，可能立即使用的可交付成果

　　4.敏捷生命周期：这种方法既有迭代，也有增量，便于完善工作，频繁交付，其特点是它同时利用迭代属性和增量特征。团队使用敏捷方法时，他们会对产品进行 迭代，创建完成的可交付成果。团队将获得早期的反馈，并能提供客户可见性、信心和对产 品的控制。由于团队可以提前发布产品，而团队将率先交付价值最高的工作，所以项目可以 更早产生投资回报。

　　

6.项目经理应用仆人式领导

　　从事敏捷项目工作时，项目经理的角色会从团队的中心转变成为团队和管理人员提供服务。在 敏捷环境中，项目经理充当仆人式领导，其工作重点转变为引导需要帮助的人，促进团队的合作， 保持与相关方的需要一致。作为仆人式领导，项目经理要鼓励将责任分配给团队成员，分配给那些 掌握完成任务所需知识的人。

　　仆人式领导的特征：

　　　1.提升自我意识； 2. 倾听； 3. 为团队服务； 4. 帮助他人成长； 5. 引导与控制； 6. 促进安全、尊重与信任；7. 促进他人精力和才智提升。8.消除组织障碍

　　项目经理要善于激励项目人员，为他们提供所需的环境和支持，信任他们能够完成工作。

7.项目章程

　　具备的特点：

　　　　1.我们为什么要做这个项目？这是项目愿景。

　　　　2.谁会从中受益？如何受益？这可能是项目愿景和/或项目目标的一部分。

　　　　3. 对此项目而言，达到哪些条件才意味着项目完成？这些是项目的发布标准。

　　　　4. 我们将怎样合作？这说明预期的工作流。

　　制定项目章程是一 种很好的开始工作的的方式。此外，团队成员可能希望通过协作了解他们将如何一起工作。

 

8.团队章程

　　1. 团队价值观，例如可持续的开发速度和核心工作时间；

　　2. 工作协议，例如“就绪”如何定义，这是团队可以接受工作的前提；“完成”如何定义，这样 团队才能一致地判断完整性；考虑时间盒；或使用工作过程限制；

　　3. 基本规则，例如有关一个人在会议上发言的规定；

　　4. 团队规范，例如团队如何对待会议时间。

9.常见敏捷实践

 　　9.1 回顾

　　回顾是最重要的一个实践，原因是它能让团队学习、改进和调整其过程。

　　回顾可以帮助团队从之前的产品开发工作及其过程中学习。《敏捷宣言》背后的原则之一是：“团队 要定期反省如何能够做到更加有效，并相应地调整团队的行为。

　　团队可以通过分配足够的时间学习受益，无论是在项目中间回顾，还是在项目结束时回顾。团队 需要了解他们的工作产品和工作过程。例如，有些团队在完成工作时遇到困难。团队可以计划用充 足的时间组织回顾，以此收集数据、处理数据、再决定之后要尝试的实验做法。

 　   首要的是，回顾并不是责备；回顾是让团队从以前的工作中学习并做出小的改进。

　　 回顾针对定性的（人的感觉）和定量的（衡量指标）数据，然后利用这些数据找到根源，设计 对策，并制定行动计划。项目团队可以采取许多行动事项来消除障碍。

 　　9.2 待办事项列表编制

　　待办事项列表是所有工作的有序列表，它以故事形式呈现给团队。工作开始之前，不需要为整个 项目创建所有的故事，只需要了解第一个发布的主要内容正确即可，然后就可以为下一个迭代开发 足够的项目。

　　产品负责人（或产品负责人价值团队，包括产品经理和产品领域的所有相关产品负责人）可能 会制作一个产品路线图，以显示预期的可交付成果序列。产品负责人根据团队的实际成果重新规 划路线图。（关于路线图的示例请参见附件 X3“敏捷适用性筛选工具”。）

　　9.3 待办事项列表的细化

　　在基于迭代的敏捷中，产品负责人往往在迭代中期的一次或多次会议中与团队合作，为即将进行 的迭代准备一些故事。这些会议的目的是细化足够的故事，让团队了解故事的内容，以及故事之间 的相互关系。

　　9.4 每日站会

　　团队成员利用每日站会对彼此做出小的承诺，发现问题，并确保团队工作顺利进行。 为每日站会规定时间盒，不超出 15 分钟。团队以某种方式“过一下”看板或任务板，而团队中的 任何人都可以主持站会。

　　在基于迭代的敏捷中，每个人都轮流回答下列三个问题： 　　

　　　　a. 上次站会以来我都完成了什么？ b. 从现在到下一次站会，我计划完成什么？ c. 我的障碍（或风险或问题）是什么？

 　　9.5 展示/评审

　　一般的指导方针是，每两周至少展示一次团队的工作产品。这种频率对于大多数团队来说是足够 的，这样，团队成员就可以得到反馈，防止他们朝着错误的方向前进。这种频率也足够频繁，让团 队可以保持产品开发足够清晰，按照自己希望或需要的频率构建一个完整的产品。

　　9.6 规划基于迭代的敏捷

　　敏捷团队在一个工作块中不会只计划一次。相反，敏捷团队会开始计划一点，交付、学习，然后 在一个持续的循环中重新规划更多的东西。

　　9.7 帮助团队交付价值的执行实践

　　　　以下帮助团队以最快的速度交付：

　　　　1.持续集成。无论产品如何，都要频繁地将工作集成到整体中，然后再进行重新测试，以确定整 个产品仍然按照预期工作。 

　　　　2. 在不同层面测试。对端到端信息使用系统级测试，对构建块使用单元测试。在两者之间，了解是 否需要进行集成测试，以及在何处进行测试。团队发现冒烟测试有助于测试工作产品是否良好。 团队发现，决定何时以及对哪些产品运行回归测试，可以帮助他们在维护产品质量的同时，良好 地构建性能。敏捷团队非常偏爱自动化测试，因此他们可以借此构建和保持交付的势头。 

　　　　3. 验收测试驱动开发 (ATDD)。在 ATDD 中，整个团队聚集一堂讨论工作产品的验收标准。然后， 团队创建测试，这让团队能够编写足够的代码，进行自动化测试，满足标准要求。对于非软件 项目，要考虑怎样在团队完成大量价值时对工作进行测试。

　　　　4. 测试驱动开发 (TDD) 和行为驱动开发 (BDD)。在编写/创建产品之前编写自动化测试，实际上可 以帮助人员设计产品，防范产品错误。对于非软件项目，要考虑如何通过“测试驱动”团队 的设计。硬件和机械类项目经常使用模拟进行设计的中间测试。

　　　　5. 刺探（时间盒研究或实验）。刺探对学习很有用，可以在诸如评估、验收标准定义以及通过产品 了解用户行为的流程中使用。在团队需要学习一些关键技术或功能要素时，刺探会很有帮助。

 10. SCRUM 迭代式增量软件开发过程

　　Scrum 是用于管理产品开发的单个团队过程框架。该框架包含 Scrum 角色、事件、工件和规则，采 用迭代方法来交付工作产品。Scrum 是运行在 1 个月或更少时间的时间盒上的，其中包含持续时间 一致的多个冲刺，在这些冲刺中会产生潜在可发布的产品增量。表 A3-1 列出了项目执行中所利用的 Scrum 事件和工件。

　　Scrum 团队包含产品负责人、开发团队和 Scrum 主管

　　产品负责人负责实现产品价值的最大化。 　　

　　 开发团队是一个跨职能自组织团队，其开发成员拥有所需的一切资源，可在不依赖团队外部其 他资源的情况下交付工作产品。

　　 Scrum 主管负责确保 Scrum 过程获得相应支持且 Scrum 团队遵从实践和规则，并指导团队消除 障碍。 

                                    

11.极限编程

　　极限编程 (XP) 是一种基于频繁交付周期的软件开发方法。该名称基于这样一个理念：将特定最佳 实践提炼到最纯粹和最简单的形式，然后在整个项目周期内持续运用该实践。

 　　XP 最受关注的地方在于推广旨在改进软件项目成果的整套实践。该方法最初包含十二种主要实践， 随后逐渐演变，采用了一些其他推论实践。

　　                                                 

 

 　　该演变是通过筛选核心价值观（沟通、简洁、反馈、勇气、尊重）并根据主要原则（人性化、经 济、互惠互利、自相似、改进、多样性、反思、流程、机会、冗余、失败、质量、循序渐进、承担 的责任）信息来设计和采用技术的结果。

12. 敏捷的其他关键词

　　生命周期/阶段：愿景-----------产品路线图-----------发布计划-----------迭代

　　SM/PM角色：服务型/仆人式领导，维护敏捷方法/流程/团队

　　整合：敏捷方法框架（IPECC）

　　变更：加到产品待办事项列表 Backlog

　　需求/范围/功能：产品待办项，用户故事，MoSCoW等优先级排序

　　进度：故事点估算，迭代燃尽图，产品燃起图

　　成本：S曲线

　　质量/bug/漏洞：DoD。验收时又重大缺陷-----持续集成来避免

　　资源/团队：自组织团队，虚拟团队（太阳原则，鱼缸窗口）

　　沟通：信息发射源，四个会议/仪式

　　干系人：审查会/演示会

　　风险：信息发射源，风险燃尽图

 13.敏捷转型步骤

　　可分为以下步骤：

　　　　1.制定实施策略

　　　　2.建立转型团队

　　　　3.构建仪式和培养热情

　　　　4.确定一个试点项目

　　　　5.确定成功的度量标准

　　　　6.充分培训

　　　　7.制定产品策略

　　　　8.制定产品路线图，产品待办列表和估算

　　　　9.运行你的第一个冲刺

　　　　10.犯错，收集反馈，加以改进

　　　　11.成熟

　　　　12.推广

 　　如果对你有帮助，希望走过路过的，高抬贵手点个赞