在Scrum中实施敏捷建模
Scrum是一种敏捷过程它使用迭代和增量方式管理和控制复杂的软件与产品开发。Scrum的开发流程非常简单。首先Product Owner根据客户的需求编写Product Backlog然后召开计划会议评估各项功能的相对工作量并确定Sprint的愿景和目标生成Sprint Backlog。然后在Sprint即迭代的开发过程中召开每日会议Scrum Master通过它了解开发的进展以及出现的问题检查团队成员的工作与进度。迭代结束后团队会召开评审会议向项目关系人展示可运行的增量版本并检查是否达到了Sprint的目标。评审会议之后的回顾会议则会总结以往的实践经验以提高团队生产力。Scrum的核心在于迭代。团队首先浏览开发需求考虑可用技术并对自身技术及能力做出评估。然后共同确定构建功能的方案并每日调整方法以应对新的复杂问题、困难和出乎意料的情况。团队找出并选择最佳方案去完成任务。此创造性过程便是Scrum生产力的核心[1]。Scrum的所有实践就是围绕着一个迭代和增量的过程开展的。1.2 Scrum的不足与XPeXtreme Programming极限编程不同Scrum并没有提供核心的价值观与指导原则也缺乏具体的实践方法例如结队编程、测试驱动开发。Scrum仅仅规定了实施的基本流程与检查表它是一个开放的管理框架重心在于项目管理而不是指导团队成员如何进行开发。这既是Scrum的优点因为它很灵活能够适应大多数场景也可以兼容并包地引入其他方法学所提倡的实践同时也是Scrum存在的固有缺陷使得它难以被实践。如果没有一位优秀的Scrum Master而团队成员又缺乏自我组织和管理的能力就会让开发过程变得一团糟团队成员将会无所适从。在开发实践方面Scrum可以借鉴XP提倡的结队编程以及测试驱动开发实现编码通过重构对编码进行调整以适应需求的变化。但是Scrum在建模方面却是一片空白。例如Scrum对于如何创建Product Backlog如何建立架构模型以及如何在编码之前进行必要的模型设计都没有给出具体的解决方案。缺乏正确的建模活动就可能会对Scrum开发过程造成阻碍影响团队达成Sprint的目标。2. 敏捷建模与Scrum的契合敏捷建模Agile Modeling是一个基于实践的建模方法包括一系列以特定原则和价值为导向的可被软件专业人员应用到日常工作中的实际做法[2]。敏捷建模有效地将建模敏捷化利用敏捷方法的思想对传统的建模理念进行了重新梳理使其更加适用于敏捷开发。敏捷建模描述了一种建模的风格。当它应用于敏捷的环境中时能够提高开发的质量和速度同时避免过度简化和不切实际的期望。敏捷建模可以弥补Scrum在建模方面的不足。如果说Scrum是一个对开发过程的所有活动进行了规定的基本框架则敏捷建模由于其对建模活动的核心关注极大地丰富和增强了Scrum的软件过程。建模在所有的软件开发中都是不可缺少的一个重要环节。传统的建模活动常常会重视对文档与工具的使用要求创建的模型涵盖软件开发过程的方方面面。这种重量级的建模活动与敏捷开发方法在核心思想上是相悖的。敏捷方法需要敏捷的建模Scrum自然也不例外。敏捷建模定义了一组与轻量级的建模有关的价值观、原则和实践并说明如何把它们付诸实施。本文将从敏捷建模的价值观、核心原则和核心实践三个方面讨论敏捷建模与Scrum的契合。2.1 敏捷建模的价值观与Scrum的契合敏捷建模的价值观包括交流、简单、反馈、勇气和谦虚。前面四条来自于XP的价值观但完全可以说是敏捷开发的价值观。敏捷软件开发宣言强调与客户交流和团队的合作。宣言对可工作软件的重视甚于详尽的文档凸现了简单的价值观。宣言对变更的重视体现了反馈的重要性以及拥抱变化的勇气。Scrum同样体现了敏捷建模的第五条原则——谦虚。Scrum将整个团队定义为一种角色作为一个整体负责将Sprint Backlog转化为可运行的产品。在开发过程中团队成员需要管理自身的工作同时对每次迭代和整个项目共同负责。如果没有谦虚的精神Scrum的团队是无法运作的。2.2 敏捷建模的核心原则与Scrum的契合敏捷建模提出了十一条核心原则。Ambler认为只有完全采纳这些原则才能真正地宣称自己在进行敏捷建模。Scrum虽然没有提出具体的指导原则但在Scrum框架和实施流程中仍然体现了部分敏捷建模的核心原则。表1展现了在Scrum项目中敏捷建模核心原则的适用性。表1 在Scrum项目中敏捷建模核心原则的适用性敏捷建模的核心原则与Scrum的契合软件是你的首要目标Scrum坚持所有的Sprint都结束于演示其目的就是要交付可工作的软件。支持后续工作是你的第二目标Scrum认为需求列表是推动迭代的主要力量只要项目有资金迭代就不会停止。项目的后续工作属于需求列表的内容。轻装前进Scrum的最终产出物除了可工作的软件外只包括Product Backlog和Sprint Backlog。主张简单Scrum主张在一开始就要保持设计尽可能简单。包容变化Scrum要求Product Owner根据不断变化的商业环境对产品作出调整。递增的变化Scrum属于增量式开发要求团队在每个Sprint周期内完成一部分产品功能增量。有目的地建模与建模相关的原则Scrum并未要求多种模型与建模相关的原则Scrum并未要求你需要一个技术知识工具箱团队的基本要求。高质量的工作Scrum要求开发过程具有可视性提倡对最后结果会产生影响的各个方面必须是清晰可见的同时要求频繁的检查以及对不合格的内容进行调整。快速反馈Scrum每日会议、评审会议与回顾会议反映了这一原则。
