敏捷软件开发宣言

  原本这篇应是关于Affinity Designer的,然后在写的过程中,发现关于AD以及UI、UX和原型设计可以专门写一个系列(毕竟还是too young),于是就愉快地跳票了。这篇是关于敏捷软件开发宣言和敏捷软件开发的,也是为之后写用户故事地图作一个开头。

3.1 敏捷软件开发宣言

  敏捷软件开发宣言是在2001年,由17位软件开发的先驱在一次聚会中共同提出的。这17个人分别是极限编程、Scrum、DSDM、自适应软件开发、水晶系列、特征驱动开发、实效编程的代表,还包括了一些希望找到文档驱动、重型软件开发过程替代品的推动者(总之知识水平都很高就是了)。
  宣言提出了一种全新的软件开发价值观——敏捷软件开发。敏捷软件开发基于迭代和增量,强调沟通和互动的重要性,注重响应变化。与之相对的是瀑布流开发,是一种老旧的、已然过时的软件开发方法,无法很好地应对日益复杂的情况和响应越来越频繁的变化(见下图)。

敏捷软件开发宣言_第1张图片
瀑布流示意图.png

  而敏捷软件开发最核心的价值观,是在17位先驱谈笑风生的过程中,达成的四点共识:

  • 个体和互动 高于 流程和工具
  • 工作的软件 高于 详尽的文档
  • 客户合作 高于 合同谈判
  • 响应变化 高于 遵循计划

// 也就是说,尽管右项有其价值,我们更重视左项的价值。

3.2 敏捷软件开发十二原则

  除了上述的四点核心价值观,敏捷软件开发还包含着如下十二条原则:

  1. 我们最重要的目标,是通过持续不断地及早交付有价值的软件使客户满意。
  2. 欣然面对需求变化,即使在开发后期也一样。为了客户的竞争优势,敏捷过程掌控变化。
  3. 经常地交付可工作的软件,相隔几星期或一两个月,倾向于采取较短的周期。
  4. 业务人员和开发人员必须相互合作,项目中的每一天都不例外。
  5. 激发个体的斗志,以他们为核心搭建项目。提供所需的环境和支援,辅以信任,从而达成目标。
  6. 不论团队内外,传递信息效果最好效率也最高的方式是面对面的交谈。
  7. 可工作的软件是进度的首要度量标准。
  8. 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
  9. 坚持不懈地追求技术卓越和良好设计,敏捷能力由此增强。
  10. 以简洁为本,它是极力减少不必要工作量的艺术。
  11. 最好的架构、需求和设计出自自组织团队。
  12. 团队定期地反思如何能提高成效,并依此调整自身的举止表现。

3.3 敏捷软件开发的实践

  自2001年诞生了敏捷软件开发宣言后,敏捷开发的思想在业界中造成了相当的影响,很多企业自觉或不自觉的按照它的思想和原则进行开发,这其中就了包括我司。
  但在实践中,也有一些所谓的“敏捷”,只是学到了敏捷的“形”,而没有学到敏捷的“神”。乍一看,它的流程的确是符合敏捷的原则,还能说出一些诸如Scrum、XP之类的话语,实际上背后的思想却还是传统的那一套。敏捷开发关键在于它的思想,在于个体之间充分而有效的沟通和积极的互动协作,以持续地去调整方法和响应变化,最终达成企业的目标和满足客户(用户)的需要。而不是使用什么样的敏捷开发方法,采取怎么样的流程,过分注重形式,只会违背敏捷软件开发的初衷。
  因此,敏捷软件开发需要以适合企业自身的方式开展,企业内部各团队之间、团队各成员之间要能充分地互动和沟通,在工作的过程中保持沟通、定期反思,并持续地改进和调整工作方法。项目一开始时受挫是正常的,项目进行中出现各种各样的变化也是正常的,甚至项目在deadline之前出现问题也是正常的,怎么持续地响应变化和解决问题,以产出能达成目标和满足需求的软件,这才是我们真正需要担心和考虑的。
  敏捷开发之道不是一天可以领悟的,它需要在实践中不断地去体会,更重要的,它是需要与团队中的其他成员、以及其他的团队一同实践的。笔者很幸运,可以在工作中遇到一帮很棒的同事,去不断地实践敏捷开发之道,也在这个过程中有了一些心得(包括用户故事地图),并将在接下来的几篇中一一呈现。

下篇预告:积极的碰撞,而不是无谓的撕逼


Designed & bulit with all the love in the world by @GAIUS_YAO

你可能感兴趣的:(敏捷软件开发宣言)