敏捷开发

何为敏捷开发

在项目整个过程中以人为主体，持续向客户提供可交付的软件版本；在项目的任何阶段允许变化，包括需求变更、代码、测试用例等；以高质量但从简的架构和设计支持变化；在项目前期确定交付的基本功能，并尽早交付具备基本功能的软件版本，但允许存在问题和缺少部分功能等；

敏捷开发宣言

个人互动优于过程和工具

强调人与人之间的沟通和配合；

• 沟通分为有效沟通和无效沟通
  • 有效沟通强调找到对的人进行沟通，对的人包括对这件事情背后的原理本身比较了解的人员，如果沟通的对象需要先付出大量的前提说明成本或代价，说明该沟通对象不是最佳沟通对象；
  • 沟通强调双向沟通，即其中一方提出的观点或问题等另一方能给予回应，且回应专注于问题本身，效率最高
• 配合
  • 双向沟通属于配合的一种方式；
  • 沟通期间双方可提出各自的问题和方案，逐一解决，保持紧密沟通；
  • 双方在一次沟通过程中可分别承担不同的工作，且在下一次沟通中交付结果并讨论
• 工具
  • 不应局限于文档表格等来传递信息，如果作为留痕记录可以理解；
  • 不应在完成文档表格等使用工具过程中与相关人无沟通，沟通的有效性参考上述观点
• 互动
  • 如果可以先通过事先的沟通和配合完成部分工作内容，则可不必等待会议等场景再展开说明，提高效率

可以工作的软件优于详尽的文档

强调的是简短的设计、必要的文档、实现功能的代码和阶段性交付的软件；

• 简短的设计：在进行软件设计时，应进行复杂度低、依赖性低的设计
  • 复杂度低指的是设计必要的、功能详尽的深度类，避免浅类；深度高且抽象细节的接口；不必过分强调设计模式原则，否则可能加深认知负担，一方面是所有参与的开发人员阅读代码本身的代价，代价包括需要进行知识强化、阅读相关联的文档、与模块负责人沟通这几者的代价；另一方面是维护和变更的难度变大，新接手开发人员对模块的认知负担加重等；
  • 依赖性低指的是模块与模块间、接口与接口间需要做好隔离，一个模块的调用尽量少的依赖另一个模块的调用或配合，接口的调用相对独立，能完成接口具名应有的功能，这点和上述复杂度低提到的深度高且抽象细节的接口观点相通；
  • 不过分迷信设计原则和模式；推荐战略性编程，即使是简短的设计也应有详尽的考虑
• 必要的文档：应提供高度的文档，而非具体细节的文档
  • 高度文档指的是架构层面的解释，如软件架构图、模块图、时序图等的解释；
  • 具体细节的文档指的更多是某个接口或模块的工作细节，如具体调用流程、计数的判断、队列的入队规则、加锁等细节；
  • 具体细节如若非要文档体现，个人建议可另创模块API文档等，但会消耗不少精力代价
• 实现功能的代码
  • 代码应完成具体功能；
  • 代码应遵循高度文档设计内容；
  • 代码质量高：可以是使用精妙的设计原则、语言特性、高性能API等，但遵循的设计思路应该是可拓展模块、易于修改、阅读负担轻等原则
• 阶段性交付的软件
  • 完成阶段性的功能；
  • 允许存在漏洞；
  • 经过迭代测试：允许存在问题，但应按问题严重程度指定优先级，如若影响对应阶段交付的承诺，则不认为该版本可交付，除非和客户偏离或有额外解决措施等

客户合作优先于合作谈判

与客户保持紧密的联系、客户的响应第一时间做出反馈，而非落纸需求即完事；

• 与客户保持紧密合作：系统或研发经理需要定期和客户反馈研发进度，包括内部开发进度和所遇问题，以及最近2周左右的打算；交付软件后需配合客户的阶段性验收，包括推进客户、接受问题、转化问题分类等；接受客户更改需求或新需求，需转换变更内容，不是直接照搬需求或简单的将需求分类梳理，除此之外还应初步识别对比目前交付软件的变动点、目前实现策略与变动点之间的关系：是目前实现可支持/包含变动点，还是完全新的需求需要额外实现等；这部分对系统或研发经理有要求；
• 非落纸需求即完事：需求不应该只是书面形式输入，在系统识别需求变动点以及与当前交付软件实现的关系时，如若有疑问则应在系统层面与客户沟通解决更新需求；且在做完初步识别没问题后需要及时转移内部相关开发或测试人员，沟通并评审；注意，要及时

应对变化由于遵循计划

制定计划应专注于当前2周左右的详细计划，随着时间往未来推移应粗略定制，并留有足够的余量；

• 详细计划：应专注于当前2周左右的指定详细计划，如有变更或新功能需求输入到内部，需求可以不定版，内部可以基于大致的、不变化的需求进行拆解和设计，这部分需要开发人员和系统沟通确定；计划可具体到3天一周期，如按照需求量评估需求拆解和评估3天，软件设计和评估3天，软件开发和评估3天，最终合入2天等；
• 测试计划可先行：测试用例可在需求拆解阶段同步制定和评估，不应串行等待开发的需求拆解，也就意味着测试需要有拆解需求的能力，制定和评估的过程需要开发等相关人员共同指定；
• 需求拆解、设计、测试用例可阶段性定版：高度设计尽量保持不变，详尽设计如上述应遵循可拓展易修改等原则，不应过分依赖设计，反而引入依赖增加复杂性；测试用例可在迭代测试、软件开发、交付客户过程中不断修改；
• 计划应适当考虑余量：考虑参与人员有无其他任务交叉运行，这需要评估其他任务交叉运行的时间；测试问题评估和解决的时间，包括测试问题最终确定、严重程度、优先级确认、偏移项确认，开发按照优先级分析问题、提出解决方案、评估方案、实施方案最终合入的时间；问题解决提倡战略性编程，但因设计从简；
• 基于上一点拥抱变化：设计从简且遵循可拓展、易修改等原则可支持拥抱变化；测试计划先行遵循测试需求拆解、与开发过程并行实施等，以上为发现问题、解决问题、需求输入和决策等提供了支持

小结