敏捷软件开发宣言

  1. 个体和交互 胜过 过程和工具

优秀的团队成员不必都是一流的程序员，可以是平均水平的程序员，但必须具备很好的合作、沟通和交互能力。

团队的构建比环境的构建重要的多。

  1. 可以工作的软件 胜过 面面俱到的文档

编写并维护一份短小（一二十页）、主题明确的文档：包含系统原理（概括的设计原理）和结构（高层结构）。

最好的两份文档是代码和团队，对过团队成员头脑中的脉络图（road map)和人与人之间的交互在团队成员间传递知识。

Martin文档第一定律：直到迫切需要并且意义重大时，才来编制文档。

  1. 客户合作 胜过 合同谈判

客户与开发团队密切地在一起工作，并尽量经常地进行反馈。

成功的关键在于开发团队和客户之间的真诚协作，而不是试图去规定项目范围的细节和固定成本下的进度。

  1. 响应变化 胜过 遵循计划

当开发团队和客户增加了对系统的认识后，有些需求会被取消，同样有些会被加入。计划将会遭受形态上的改变，而不止是时间上的。灵活的计划应能适应商务和技术方面的变化：

  • 商务：客户可能改变需求
  • 技术：我们确信需求不会变时，仍不能很好地估算开发时间

较好的做计划的策略：

  • 为下两周做详细计划
  • 为下三个月做粗略计划
  • 为三个月后的做极粗略的计划
  • 为一年后的计划有个模糊想法即可

12条敏捷原则

  1. 我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意
  • 初期交付的系统中所包含的功能越少，最终交付的系统的质量就越高
  • 交付得越频繁，最终产品的质量就越高
  1. 即使到了开发后期也欢迎改变需求，利用变化来为客户创造竞争优势
  • 开发团队最不愿面对的就是需求变化，但是客户的想法是随着他的认知和掌握的信息量发生变化的
  • 客户在刚开始的时候并不能给出明确的要求，而是在我们产品开发的过程中才会逐渐清晰，而且到了后期客户更明白他想要的是什么，往往后期所提的需求更具竞争力
  • 我们要善于接受需求的变更，才能帮助客户提供更具竞争力的产品，给客户创造更大的价值
  • 拥抱变化的关键是敏捷团队努力保持软件结构的灵活性，在需求变化时，对系统造成尽可能小的影响
  1. 经常性地交付可用的软件，交付间隔从几周到几个月不等，而且越短越好
  • 尽早交付：使客户更早看到结果
  • 经常交付：通过频繁交付并收集反馈，不断进行调整，确保交付的是客户想要的
  • 关键点在于，将大问题化作小问题，将大需求拆解为小需求。缩短交付周期给客户去验证和反馈，从而确保我们的方向始终是正确的
  1. 项目过程中，业务人员与开发人员必须天天都在一起工作
  • 客户、开发人员、其他涉众之间有意义、频繁的交互
  • 一方面提升效率，另一方面引导团队在正确的方向上工作
  1. 围绕被激励起来的个人来构建项目，给他们提供所需要的环境和支持，并且信任他们能够完成工作
  • 敏捷团队的核心是人，要相信团队的每一个成员，都会为团队当前的目标而努力工作
  • 尊重和信任团队中每个人，相信他们的能力，激励他们投入工作，为他们提供环境支持
  • 使团队成员之间互相信任，相互帮助，从而始终为同一个目标而工作
  1. 在团队内部，最有效果和效率的传递信息的方法是面对面的交谈
  • 个体和互动胜过流程和工具，面对面沟通是所有沟通方式中最高效的一种方式，大家可以通过面对面的沟通第一时间解决问题
  • 敏捷模式下的面对面沟通是一种常态，不管是对内，在团队内部，还是说对外，和相关的干系人、客户
  • 站会和各种看板是每天让团队开发人员面对面交流的机会，将团队沟通成本降低，减少因沟通造成的项目问题
  1. 可工作的软件是衡量进度的首要标准
  • 交付产品的衡量准则是可以工作的软件，而不是其他一切过程产物
  • 传统开发方式中，不同开发阶段的交付件不同，立项阶段有MRD，需求阶段有PRD，开发阶段有SRD，测试阶段有方案文档等等，这些文档都是研发流程中重要的节点交付件，这就导致可能在相当长一段时间，客户无法看到我们的软件产品
  • 敏捷则强调交付一定是可以工作的软件，这样客户可以从一开始就看到我们的产品，对产品有一个直观的感受，从而可以不断的提出反馈和建立对团队的信任
  1. 敏捷过程提倡可持续的开发速度。责任人、开发者和用户要能够保持长期、恒定的开发速度
  • 可持续开发：敏捷不是一味强调快速交付，而是建立一个稳定的、可持续的开发节奏，使团队能够在固定的时间段里有连续产出，并且是保证质量的
  • PO、开发人员和用户需要建立一种共识，团队会以稳定的节奏向用户不断的交付可工作的软件，从而避免不同角色强行打乱团队的节奏，影响交付质量以及长期的合作关系
  1. 不断关注优秀的技能和好的设计会增强敏捷能力
  • 对技术和设计的卓越追求将从一开始就给团队和产品发展指明的方向
  • 团队技术能力的扩展和提升能够提高产品质量，交付能力等，从而提高团队的敏捷性
  • 好的设计遵循可维护、可演进等方面的要求。设计的不断优化，同样能够增强敏捷能力

这里的设计不局限于方案设计，广义上的设计包括产品设计、方案设计、架构设计、业务设计等等。对设计的不断完善并不是把原有的设计不断推倒重来，而是在已有设计的基础上逐步进行优化，不断追求完美。

  1. 简单-使未完成的工作最大化的艺术-是根本的

简洁，只做需要做的事，这是敏捷的核心之一。

交付刚刚好的系统：不构建华而不实的系统，而是采用和目标一致的最简单的方法，以最高质量完成最简单的工作。

  • 在产品不同发展阶段，如何明确用户的需求，交付刚好能满足客户需求的产品？
  • 在需求分析阶段，如何识别客户的核心需求，抓住客户的痛点，提供给客户最想要功能？
  • 在开发阶段，如何简化代码的设计、减少冗余，提供符合客户要求的系统？
  • 在测设阶段，如何制定测试策略、设计测试方案，交付满足用户质量要求的产品？
  1. 最好的架构、需求和设计出自于自组织的团队
  • 敏捷的目标之一就是能够打造自组织团队，该团队能够通过高效协作，完成需求分析，架构设计、开发交付、产品运维等工作
  • 自组织团队依赖团队的力量，群策群力来解决问题。每一个成员都具有项目中所有方面的参与权力，不存在单一的团队成员对系统架构、需求或测试负责的情况，整个团队共同承担责任
  • 敏捷团队中的关键活动是依赖团队协作的力量去解决的，如计划会、评审会、梳理会、故事点集体估算等。通过团队来达成共识，减少出错的概率、降低风险
  1. 团队定期反省如何提高工作效率，并相应地调整自身的行为

团队的成长和进步也需要不断的反省。

  • 结对编程：秒级的代码反省
  • 每日站会：天粒度的开发进展反省
  • 定期开评审会、回顾会：周粒度的迭代反省
  • 月度版发布：月粒度的产品发布反省

极限编程实践

  1. 客户作为团队成员
  2. 了解需求到能够估算的程度，用户故事是需求的助记符
  3. 短交付周期：迭代计划（2周），发布计划（3个月）
  4. 验收测试
  5. 结对编程
  6. 测试驱动开发
  7. 集体所有权：所有人对所有模块负责
  8. 持续集成
  9. 可持续的开发速度：不到最后一周不加班
  10. 开放的工作空间：密集交流
  11. 计划游戏
  12. 简单的设计
    1. 考虑能够工作的最简单的事情
    2. 不做过度设计
    3. 不容忍重复的代码
    4. 经常性、持续性重构
  13. 隐喻

计划游戏

  1. 初始探索
    1. 拆分过大的故事，合并较小的故事
    2. 评估故事的开发时间
    3. 分割或合并后的故事要重新估算
  2. 发布计划
    1. 初步选择故事优先级并评估开发时间
    2. 不能选择超出开发速度的故事
    3. 可根据实际开发速度动态调整：用户有预期低优先级故事可能无法按时发布
  3. 迭代计划
    1. 开发人员采用具有技术意义的顺序实现故事
    2. 迭代内故事不能改变
    3. 未完成故事也要在迭代指定日期结束
    4. 下一迭代内工作量为本迭代内的实际工作时间为基础估计
  4. 任务计划
    1. 开发人员把故事分解为任务（每任务工时4-16）
    2. 尽可能完全地列举出所有的任务
    3. 每人认领不超出上轮迭代完成任务的任务
    4. 开发人员可协商交换任务
    5. 迭代中点时超出一半的故事应已被完成
  5. 迭代
    1. 向用户演示并获取评价

测试

  • 用于验证
  • 用户促进模块的解耦合

重构

每个软件模块都具有三项职责：

  • 模块运行起来所完成的功能
  • 模块需要应对的变化
  • 模块要和阅读它的人沟通

持续重构，不让脏乱累积，保持代码清洁。通过最小的努力，对系统进行扩展和修改。

参考

版权声明：本文为博主原创文章，转载请注明出处。 旭日酒馆