Abstract

Scrum is an iterative incremental process of Software development commonly used with Agile Software Development. Especially, Scrum will help us to manage the project more efficiently because it is an adaptive process. However, applying the Scrum Methodology should depend on the different situation during the process of project development. It’s a big issue to solve. This article gives an example to elaborate how to manage the project with Scrum.

Introduction

Software development is a complex endeavor. So the most difficult problem is how to handle the complexity through by the science of project management. Many scientists and software engineers raised a great number of methodologies for project management such as Waterfall, UP and Agile. In contrast to the heavy methodologies including Waterfall and UP, Agile is enough flexible to embrace the change, more light to be mastered by project team members, and more focuses on the communication and release of the usable software rapidly. Agile methodologies include eXtreme Programming, Scrum, Feature Driven Development and Crystal etc.

Scrum was raised by Hirotaka Takeuchi and Ikujiro Nonaka in 1986. The skeleton is shown in Figure 1.

 

 

The lower circle represents an iteration of development activities that occur one after another. In Scrum, it was called Sprint. Each Sprint is an iteration of 30 consecutive calendar days. The output of each sprint is an increment of product. The upper circle represents the daily inspection that occurs during the sprint, in which the individual team members meet to inspect each others’ activities and make appropriate adaptations.

There are three roles in Scrum including ScrumMaster, Product Owner and Team. The ScrumMaster is responsible for the Scrum process, for teaching Scrum to everyone involved in the project, for implementing Scrum and ensuring that everyone follows Scrum rules and practices. The Product Owner is responsible for representing the interest of stakeholders and creating the project’s initial overall requirement which was called the Product Backlog, for using the Product Backlog to ensure that the most valuable functionality is produces first and built upon. The team is responsible for developing functionality. Teams are self-managing, self-organizing, and cross-functional, and they are responsible for figuring out how to return Product Backlog into an increment of functionality within an iteration and managing their own work to do so.

Problem Statement

Without doubt, Scrum is one of most popular agile methodologies now. It, however, is not easy to apply it to project management. Considering about the following situations please:
1. If the culture of your organization is contradictious with Scrum, and your leader always interrupts you during the process of project development, what should you do?
2. If your team members are not familiar with Scrum, and they don’t understand the heart and rules of Scrum, what should you do?
3. Furthermore if your team members didn’t master the basic skills of Agile developing such as pair programming, Test Driven Development etc, what should you do?
4. If your customers always change their requirement, they are not clear what they want even, what should you do?

Our Solution

In fact, we can’t find out the “Silver Bullet” to solve these problems. We know Scrum is an adaptive process. Scrum makes many rules which should be followed, but not hidebound. It’s agile and flexible. It allows us to adjust the way to achieve the goal of project.

The answer to the first question is operating within the culture of the organization. Don’t fight against the culture of your company. If you are ScrumMaster, you’d better walk a fine line between the organization’s need to make changes as quickly as possible and its limited tolerance for change. You can adopt Scrum by starting small. At the same time, you should try your best to persuade your leader to support you. Sometimes your leader will build the bridge between the agile world and non-agile for you. Of course, it needs change, but these changes must be culturally acceptable. If not, you must acquiesce. The ScrumMaster is a sheepdog of the team, and his job is to protect the team from impediments during the Sprint. Remember that the precondition of which everything is going on well is that the sheepdog cannot be dead. After all, Scrum is the art of the possible.

Right, we hope our team members are all software craftsman so that everything is Ok. Unfortunately, the real world is not as good as that we expect. In fact, the situation in which most of team members are all apprentices is more common. It is true that it is difficult to hire the experienced software engineer in this industry. So the problem we must solve is how to train them. We should draw up a training plan. Before it, we must understand the skill set of everybody. We need to assign the mentors to the fresh guys. Of course, the best way of training is practice. We should assign the task to them according to their ability. At the same time, we have to add the task duration because they are not familiar with the related skills. Besides, Pair programming is a good way to handle it.

The great character of Scrum is enough flexible to embrace the change. Scrum is an iterative and incremental process. The iteration is very short (30 days) so that we can change our plan in time. The incremental development will provide the good policy to submit the release rapidly. The increment product can give our customers confidence. And the customers can understand the difference between what they want and what we provide though by the running software. Scrum emphasis on the communication between the team and customers. Product Owner of Scrum is responsible for communicating with the customers and creating the product backlog. In case the customers changed their requirements, the Product Owner will discuss with ScrumMaster and Team. If the change is acceptable, it is added into the product backlog. If the change is within the sprint which the team is developing, the sprint has to halt, and re-open the new sprint. Beside, the daily scrum will help each team member understand the current statue of the project, and the sprint review meeting will show the result of the sprint to the customers in order to get the feedback from the customers, the sprint retrospection meeting will prompt the Scrum process framework and practices.

Evidence that the Solution Works

Now we complete the first sprint of the project on time. In a month, we went through the whole lifecycle of the software development from the requirement analysis to designing, coding and testing. Each member is familiar with the Scrum gradually. Everything is going on well such as Daily Scrum, Team Work and Sprint Development. In the end of this sprint, we submit the increment product to our customers and get the feedback from the customers. The most important achievement is that our customers approve our approach to develop the product.

Competitive Approaches

We don’t follow the rule of Agile Methodology strictly. For instance, most of team members are accustomed to the TDD (Test Driven Development), so we adopt the traditional way to design and develop the software such as Use Case Driven Development instead of TDD. But we require everybody must write the test case for classes and components. We organize the pair programming group to prompt each other.

Because our customers are off-site, so we require our Product Owner must be in-site and cooperate with them in full time. We create the communication schedule for the customers to understand the customers’ requirement. The Product Owner is empowered to handle everything with requirement.

Especially, the ScrumMaster of our project protects the team from the rest of the non-agile world. We get the enough resources and backup. For example, we have our own agile coach to direct how to apply the Scrum to our project. He can help us to solve the key problem when we are confused of Scrum Methodology.

Current Status

The project is going on well. The first sprint is very successful. Team members are all confidence. They regard the Scrum as the effective and enjoyable process. The customers are satisfied with our process. Most of risks had already solved because we emphasis on them and add them as the tasks into the sprint backlog.

Next Steps

Next month, we are going to hold the Sprint retrospective meeting to find out the existed problems in the first sprint. Then we will create the backlog for next sprint. In this sprint, we will develop the most important domain module and let it workable.

Conclusions

Scrum is an excellent agile methodology to release the software product rapidly and correctly. It gives all team members the new management responsibilities. The process of the project management is visible and controllable. The ScrumMaster and Product Owner don’t need to write the redundant documents and draw up the unrealistic project plan. The team members become more active due to self-organizing and self-managing.

References
1. Agile Project Management with Scrum, Ken Schwaber
2. Software Craftsmanship, Pete McBreen
3. Applying UML And Patterns, Craig Larman

---

作者介绍
张逸具有多年的软件开发与设计经验，他是两届微软最有价值专家（MVP），著作/译作包括《软件设计精要与模式》、《WCF服务编程》。张逸熟悉C#，ASP.NET，WCF等技术，同时深谙面向对象领域的相关技术。目前，他主要从事 SOA企业信息解决方案的设计与研究，以及敏捷方法的推广与实践。张逸是捷道·敏捷堂的创始人。

Dreamhead觉得等待发布是件很爽的事。当然确实是很爽的事。不过，《 最后期限 》里面贝琳达这样描述电影里的巴顿将军：

    “片子开始的那一幕，巴顿‘指挥’战役的那一幕，我们那位年轻的朋友所说的那一幕：呵呵，巴顿在那一幕里根本连一条命令都没下过。他只是从望远镜里看着整个战役。德军坦克分队像他预料的那样穿过山谷，而他就看着那些坦克。在那儿，在第一辆坦克上，站着一位军官，手里拿着马鞭。巴顿盯着他，说道：‘隆美尔，我读过你的书。’他读过隆美尔的书，所以他很清楚隆美尔会怎么做。然后，战斗打响了。进攻，侧翼机动，佯装撤退，再次进攻，空中支援，后备队到达。巴顿只是看着，根本没有下达哪怕一条命令。”

如果一件事会成功，在最后一天之前它已注定会成功；如果它会失败，最后一天之前它已注定失败。所以我对这个“最后一天”没什么感觉。做一些和往常一样简单的事，让一些注定发生的事情发生而已。平常的一天而已。

重温在贝琳达的评论之前，一个颇有些代表性的项目经理是如何在记忆中构造巴顿将军的：

    “我想，我就像巴顿。我是说，项目经理就像是巴顿。必须这样。就像在电影的第一个战争场景，直接打击隆美尔那样。他就是策划整个战役的那个人，他指挥每一次炮击。”

    这个年轻人站了起来，在虚拟的战场上挥舞着手臂：“空中支援！他这样说，然后空中支援就来了。收到—收到—收到！轰隆！转向侧翼！这儿！那儿！左侧编队，进攻！进攻！现在撤下来，赶紧撤下来！快！现在等着，等着，等我的命令……就是现在！进攻，进攻，把所有的炮弹都扔给他们！右翼，切断他们的后续部队！是的，就是那儿，就是那儿。现在我要更多的轰炸机，把炸弹丢在中间。好了，现在该决个胜负了，后备队，上。后备队从左侧进攻，快。是的，就是那儿，就是那儿，敌人绝对不会想到。嘣！轰隆！把他们全干掉！耶！！”

5年前也许我也这样想。人们需要像贝琳达那样把自己累垮，然后学会用简单的方式获胜。

---

作者介绍
熊节是ThoughtWorks公司的咨询师，曾参与《重构：改善既有代码的设计（中文版）》、《J2EE核心模式（原书第2版）》、《Contributing to Eclipse中文版》等图书的翻译。目前正在从事Ruby on Rails的项目，并致力于敏捷方法与思想的推广。

团队的成员们都已经有相当丰富的sprint retrospective经验，如何保持大家的激情，以及保证回顾会议的效率和效果都是我感觉很重要也并不容易的任务。大家开始有些厌倦于差不多的流程，即使我们想方设法地换用各种不同的retrospective方式，情况依然如此，而不断更换方式所带来的副作用还包括大家需要花费时间熟悉，也有可能导致大家干脆置之不理。其实换在不同的地点进行回顾会议是个不错的点子，但可以这一定程度上涉及到经费问题，所以。。
 
这次比较凑巧的是，sprint中，我曾经将sprint backlog和burndown chart打印出来，贴在工作区域的白板上，督促大家每天更新。而我们的一些会议记录也都被我打印出来，粘贴在一起，所以，可以说将这些文档资料收集起来后就成为了我们非常宝贵的一些回忆。回顾会议开始前，我将这些文档粘贴在会议室的墙上，大致按照时间顺序排列。由于有几个新同事加入，所以花了点时间重复那些essential statements，然后我希望大家能够快速地回顾过去的这个sprint，然后用一个词语或者短语来描述自己的感受，此时此刻的感受。对于这些感受的稍加发掘，有助于放松情绪，拉近彼此的距离，使氛围能够引导大家畅所欲言。而这些感受也可以用于之后与那些action进行一定的对比，如果大家更多的是不满意，却没有太多用于改善现状的action，那么说明其中一定有什么问题，导致前后大家给出的信息不一致。
 
感受阶段结束后，我准备进行timeline，在此时，我向大家展示粘贴在墙上的这些文档，分配出2~5分钟来浏览这些文档，增强他们对于 sprint大致过程的记忆。这其中，还会有助于大家发现一些可能不容易想到的问题，比如在某一周的weekly review上有提到的下周工作计划，但在随后一周的weekly review记录中却发现此工作计划没有按预期的完成，那么这就是一个潜在的问题，或者可以提高的方面。之后就是给出一些时间让成员们回首，并将自己的看法记录下来，写在便签纸上。此时我已经准备好三张大的flip chart纸张，张贴在墙上，用于大家粘贴便签纸。
 
之后的mining阶段，我开始阅读这些便签纸，然后将它们就地记录在这些flip chart上面，用记号笔，并给这些条目编号。当然，这三张flip chart分别为start doing、stop doing、continue doing，条目会被写到对应的纸上。接着就是要探讨可行的解决办法了，但在此时有一点点的小状况。整个会议的气氛都是比较轻松的，有点点随意，但是从大家半开玩笑的话语中，我发现一种趋势，大家有些许的死气沉沉，觉得有些境况难以改变，有些困难是必然，我觉得这样的心态对于我们找寻SMART的 action有负面效果。快速地思考后想出一个办法。我们开会在26楼，公司的健身房也在这一层，我认同劳逸结合的观点，于是决定放大家15分钟的假，和他们一块去健身房运动片刻。于是大家嘻嘻哈哈地过去，打乒乓球，打台球，跑跑步，抬抬杠铃，挺活泼的。差不多15分钟后，回到会议室时，大家显得比之前更具有活力，就开始接着下面的brainstorming过程，来产生action。
 
以前的做法通常是先一个人想，再两个人交流，再两两配合交流，然后一起总结。有些scrum master喜欢主导整个过程，而我则非常喜欢将控制权交由团队的成员。曾经的一次是，最后形成分别是4人和3人的小组时，结束讨论，让他们展示自己的成果，一个同事负责讲解他们的action和理由，另一个同事则协助将这个action记录在flip chart上，这既满足了大家理解的需求，也有一定的visible的特点，又强调了团队成员间的充分沟通（如果不充分，那么记录的同事可能根本就不知道他的同伴在讲什么）。这次也差不多，我讲控制权交给成员，希望他们有自愿者可以出来记录action，并启发大家思考，而此时我又使用了两张额外的 flip chart，标题都是ACTIONS，放置在之前的三张flip chart的中间，彼此非常靠近，是希望可以在对应的问题和最后的action之间形成一个关联。效果还不错，在大家略带调侃的方式中，action被讨论出来，当然还有其负责人。而在这样更轻松些的氛围中，虽然有开玩笑式的推诿，但其实大家都默认的接受了必须有人来负责action，相比以前我们有很多 action都因为似乎只能有外部人员可以负责而付诸流水，我们给每一个action都找到了主人，而且大家都承诺会完成！
 
至此，整个sprint retrospective结束，历时接近4个小时。

此文最初发表于博客。

---

作者介绍
徐毅目前在一家大型欧美电信企业工作，具有丰富的软件开发、软件测试及测试自动化经验，同时，具有丰富的Scrum开发模式经验，目前担任公司的Scrum Master。专注于如何使Scrum顺利地融入企业中，如何创建一个Scrum的生态系统，以及敏捷开发中的测试。

 

    在敏捷开发过程中，我们还需要对系统架构进行设计吗？事实上，Martin Fowler在《Is Design Dead?》一文中已经给出了答案，那就是我们同样不能忽略对系统架构的设计。与计划性的设计（Planned Design）不同，我们需要演进式的设计（Evolutionary Design）。在敏捷开发的生命周期中，我们通过每一次迭代来丰富与更新我们的设计方案，以使其最大限度地符合客户对系统的需求。这里所指的需求，包括功能性需求和非功能性需求。

    在Agile Journal四月刊中，IBM's Methods Group的敏捷专家Scott W. Ambler详细地阐述了在敏捷语境中的架构设计方法，他提出了所谓“架构预测（Architectural Envisioning）”的方法，以应对敏捷开发中逐步演进的架构设计过程。

    Scott指出，敏捷模型驱动开发（Agile Model Driven Development，AMDD）明确地包括了初始需求分析与架构建模，这个过程发生在敏捷项目开发的第0次迭代中。所谓第0次迭代，就相当于项目的热身活动，是项目得以启动的基础。在此迭代期间，团队需要充分地理解项目的范围，甄别可行地技术策略。这个阶段所能够收集到的信息将有助于你对整个项目最初的粗略估计，以制定合适的项目计划，从而获得启动项目的资金与足够的支持。

    敏捷模型驱动开发的生命周期如下图所示：

    根据图中所示，在每次迭代的初期，制定的迭代计划都应该包括建模的工作。在此期间，可以召开建模的头脑风暴会议，讨论系统的功能特征，并思考实现这些特征的高层设计策略。大多数敏捷团队都会通过测试驱动开发（TDD）确定需求与设计的细节。

    通过对架构的预测，可以在项目早期进行一些高层次的架构建模，以助于团队与关键利益相关人商讨系统采取的技术策略。这一行为的关键目标是识别出架构策略，而不是撰写如山一般堆积的文档，从而使得你能够快速完成架构建模。其中的窍门就是尽量保持简单。开发者不需要对大量的细节进行建模，而只需要足够即可。如果你正在编写用例，意味着你只需要以标注形式列出用例的要点就足够好了。如果你正在对领域建模，可以直接在白板上绘图，或者使用CRC卡片。你的目的在于对信息的共享与交流，而不是编写细致的文档。

    如果采用架构预测的方式，你需要对哪些内容进行建模呢？Scott在文中指出有如下四部分内容需要建模：
   1. 技术图表。例如UML部署图。这些图表有助于开发者预测主要的软件和硬件组件，包括你需要访问的旧系统和数据库，系统有可能会与它们进行交互。
   2. 用户交互流程图。通过分析用户交互的主要页面/外观和报告，对系统的UI进行架构设计。如果在进行架构设计的时候不考虑用户交互界面，就可能存在潜在危机，那就是你构建的系统不是利益相关人所希望看到的。请记住，UI才是最终用户使用的系统。
   3. 领域图。在最初的架构建模中，一个重要的组成部分是对领域的高层建模。模型可以非常微小，只需要捕获主要的业务实体，以及它们之间的关系。有的人可能认为领域模型应该属于需求建模的一部分，而不是架构建模。但正如上图所示，这两者在第0次迭代中是并发进行的。
   4. 变更情形。就是在架构级需求中描述可能的技术或业务变更，而这些变更需要在未来能够提供支持。变更情形要求你考虑架构的扩展能力，但并不是过度构建你的系统。因为你只是要考虑由于变更所造成的影响，以确保你构建的系统还能够正常工作。

    架构建模是贯穿于整个项目周期的，因此这些图表就是在项目结束时形成的整体文档的基础。由于你事先明确架构是演进的，因此就不必承担架构设计在项目早期必须“正确无误”的压力，而只需要在当前形势下保证足够好就可以了。Scott建议使用白板和草稿纸等简便工具，勾勒出这些模型的初始版本。当然，如果团队成员具有熟练的建模技巧，也可以使用专门的建模工具。这一建议足以体现架构设计的敏捷性，与长篇累牍的传统架构设计方式迥然不同。

    对于这样一种架构设计方式，熟悉传统架构设计方式的架构师普遍不以为然。Scott对这一看法给与了强有力的反驳。他将架构设计场景分为三种类型。第一种是架构师熟悉系统架构设计所必需的技能与经验。既然你已经熟悉了这些内容，当然就没有必要作出完整的设计了。你只需要在白板上体现你的架构设计，保证团队的每个人都能够按照相同的体系架构进行实现就可以了。

    第二种场景是架构师对相关技巧与经验完全不知。此时，仍然只需要作少量的初始建模即可。因为你缺乏足够的知识来完成细致而又全面的架构设计，反而会因为了解不够而导致错误，从而增加项目的风险，并且阻碍了项目的进度。

    第三种场景则是架构师熟悉部分知识。这种情形也是团队开发中最常见的场景。在这种情况下，可以耗费几天时间作出一个初始的架构建模，以验证系统可能存在的风险，并制定可能策略以减轻风险可能造成的后果。你可以实现一些可工作的代码来验证架构。建模在这种情况下是非常有意义的，因为它使得你可以定义一个一致的技术愿景，为团队成员所分享，并对系统的主要问题进行思考。

    当你的团队成员是分散在各地时，或者当团队非常庞大，下面分为多个小组时，这种初始的架构建模就能够带来无与伦比的价值。它有助于在团队成员之间建立一个公共的愿景，更重要的是它能够识别出分离的组件/子系统，以及这些组件的初始接口。一旦识别出这些耦合度较低的组件或子系统，就能够合理地对团队进行分组，并保证小组之间设计与实现的一致性。

    Scott指出，所谓的“架构预测”能够提供如下价值：
    1. 提高生产力
    2. 降低技术风险
    3. 减少开发时间
    4. 增强沟通
    5. 可伸缩的敏捷软件开发。

    需要明确的是，这样的一种架构预测方式，正好符合敏捷开发迭代的需要。在项目开发早期，对系统整体进行一次高层次的概览，并对关键业务需求进行甄别与分析，划分合理的系统模块，有助于在迭代开发中为团队成员建立一个统一的标准与目标。而在每次迭代过程中，团队就可以对本次迭代期间的功能进行深入的架构建模，然后通过TDD充分理解需求，对模块的细节进行设计与实现。这是敏捷架构设计的核心操作原理，它与敏捷开发原则是一脉相承的。

本文最初发表于IT168。

---

作者介绍
张逸具有多年的软件开发与设计经验，他是两届微软最有价值专家（MVP），著作/译作包括《软件设计精要与模式》、《WCF服务编程》。张逸熟悉C#，ASP.NET，WCF等技术，同时深谙面向对象领域的相关技术。目前，他主要从事 SOA企业信息解决方案的设计与研究，以及敏捷方法的推广与实践。张逸是捷道·敏捷堂的创始人。