张逸:晴窗笔记

ps: 这是我在hp写的命题作文，E文不好，请见谅。

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

捷道·敏捷堂发布：http://www.agiledon.com/post/2008/07/Scrum-Practice-In-PM.aspx

    在敏捷开发过程中，我们还需要对系统架构进行设计吗？事实上，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次迭代，就相当于项目的热 身活动，是项目得以启动的基础。在此迭代期间，团队需要充分地理解项目的范围，甄别可行地技术策略。这个阶段所能够收集到的信息将有助于你对整个项目最初 的粗略估计，以制定合适的项目计划，从而获得启动项目的资金与足够的支持。

更多内容，请阅读发表在捷道·敏捷堂的文章。

“敏捷方法”本为舶来品，追求的是灵活、小巧、敏捷地应对软件开发过程中的变化，而不像某些重量级开发方式那般笨拙不堪，流于形式，而忽略了软件开发的变 化万端。敏捷重思想、重精神、重原则、重实践，而轻形式、轻过程、轻方法、轻管理，讲究的是敏捷为本，交流至上，持续改进，因地制宜。若体会了敏捷思想， 只要遵循敏捷的基本原则，各种方法皆可敏捷。若未曾领会敏捷的真谛，那么即使应用了敏捷方法，也不过是“空有其形，大失其意”，终究是“画虎不成反类 犬”！

敏捷方法并非玄之又玄的“道”，不过对于国人来讲，用“道”来阐释敏捷之精神，至少可以避免陷入某种思维定势，少去许多约束与条条框框。至于如何去理解 “道”的含义，就需要实际去推行敏捷方法，从而在过程中去体悟。《敏捷之道》电子杂志荟萃了国内诸多敏捷专家或爱好者的思想体会、工作实践以及个人 认识，是发表在捷道·敏捷堂的优秀文章摘选，其目的在于推广敏捷方法的实践与运用。

本期电子杂志精选了7篇文章，分为敏捷思考、敏捷实践、敏捷方法、敏捷工具、好书推荐五个栏目。由于捷道·敏捷堂还处于草创时期，因而文章内容或有不足之处，或有偏颇之处，不过套用许多电视台的用语，那就是文中观点仅代表作者个人意见，仅供参考。文章包括：

印第安人的灵魂——敏捷回顾

印第安人在赶了3天路后，会停下来小憩一天，因为他要等着自己的灵魂跟上来。敏捷开发在经历了一次迭代或者冲刺（Sprint）后，也需要休整，以等待团队的灵魂跟上来，这一过程被称之为“敏捷回顾（Agile Retrospectives）”。

解开最后期限的镣铐
 
在大型遗留系统基础上运作重构项目

本文以ThoughtWorks中国公司与客户合作的咨询项目为背景，为读者介绍如何在一个大型遗留系统的基础上组织和运作重构项目，从而切实有效地改善系统质量。

单元测试实践小结

异地分布式敏捷软件开发

异地分布式软件开发（Distributed Software Development）是指由多个位于不同地理位置的团队进行同一个软件项目的开发过程。
 
McDonald & Scrum

Scrum是一种敏捷方法，强调快速反应，讲求人的配合等等。而其团队组织方式是多功能型，由具有各种才能的人组成足以达成既定任务的团队。 

欲善敏捷开发 先利敏捷工具

敏捷开发的潮流并不是由敏捷工具来推动的。但近年来，为了更好地支持敏捷开发，敏捷工具也有了很大的发展。

杂志下载，请访问：敏捷之道第一期

   鉴于产品开发目的的不同，微软永远不可能与开源社区走到同一条道路上来，但并不排斥双方有合作的可能。然而，让我们感到奇怪的是，一直以来微软对于开源的态度始终让人捉摸不定，时而漠不关心，时而高调抨击，时而又主动示好。

   目前，我们唯一可以肯定的是，微软不再视开源为洪水猛兽，甚至于一步一步的，微软也在亦步亦趋的踏入开源社区的领域，例如微软成立的开源实验室，公布 Windows和.NET Framework的部分源代码，以及成立类似于SourceForge的开源网站CodePlex。分析动机，有业内专家指出，微软真正关心的的问题不是一个公司是否是开源性质，而是这个公司是否可以帮助销售微软的平台产品。真是一语道破天机！商业利益是凌驾于一切之上的。

    我们观微软的态度，已经有了与开源和睦相处的苗头。那么，微软对于开源项目，尤其是对于开源的.NET项目究竟保有怎样的态度呢？最近，Redmond Developer News的编辑Michael Desmond就提出了这样一个疑问，那就是：开源.NET项目是否受到微软的冷遇？

    文章提到了Redmond在去年六月对Jeff Atwood的专访。Jeff是Coding Horror Developer Blog的创始人，他对.NET领域的开源项目贡献良多，除了进行博客创作之外，同时还创建了自己的开源项目Stackoverflow.com。

    Jeff在Coding Horror Developer Blog上曾经承诺，会将广告收入的一部分回赠给开源社区。近日，Jeff兑现了他的这一承诺，将5000美元的奖金颁发给了ScrewTurn Wiki开源项目的开发者Dario Solera。ScrewTurn Wiki是一个基于ASP.NET的Wiki引擎。实际上，奖励仅仅表明了Jeff的一种态度，那就是感谢那些为.NET开源开发领域作出卓越贡献的开发者们。

    这正是Jeff举措的关键目的。Jeff认为“开源项目在微软体系中被当成了二等公民。”他说道：“微软错误地降低了对开源项目的支持，而事实上这些开源项目对.NET世界贡献良多。”他相信微软作为开发工具的提供商，其命运取决于公司是否愿意改变其一贯的做法。

    Jeff的观点颇具争议性。实际上，在全球的.NET开发人员中，有很多都使用了各种开源工具，例如DotNetNuke、MbUnit、NAnt、 NHibernate和ZedGraph。而开发人员使用的.NET开源工具还有很多，以上列出的仅仅是冰山一角而已。微软也正在积极地参与和响应与开源社区（CodePlex、IronPython和IronRuby项目、Mono开发等）的合作。

    那么，开源.NET项目的开发者们为何没有切实感受到微软对他们的支持呢？

    确实，微软虽然在自己的开发工具中集成了部分优秀的开源.NET工具，但这些工具终究是凤毛麟角。此外，微软虽然对开源项目提供了一定的支持，但这种支持与微软对其商业产品的庞大投入相比，实在是九牛一毛。

   很多时候，微软表面上对开源社区的支持，实质上却是醉翁之意不在于酒。例如，微软在四月初发布了与开源兼容的XAML/WPF规范，允许开源项目使用这些规范。这或许是微软的示好之举，对于开源开发起到了一定的促进作用，但此举的背后却代表着微软可以借助开源的东风进一步推广WPF与XAML。

    微软对开源.NET项目确实提供了一定的支持，但很多时候，微软却是以其强势地位对开源项目给与了沉重的打击。例如微软于去年推出的MVC Framework以及LINQ，它确实为.NET开发者带来了极大的便利。但随之而来的，却极大地影响了Castel MVC Framework以及NHibernate的发展。显然，集成在Visual Studio中，并作为.NET Framework一部分的MVC Framework和LINQ对于普通的.NET开发人员而言，更具有吸引力。但对于开源社区而言，却是极大的挫败。

   显然，Michael Desmond提出的所谓“开源.NET项目遭遇微软冷遇”的观点是站不住脚的。微软不可能忽视开源社区的力量。相反，微软会极度关注开源社区的发展，一旦意识到某个开源项目的商业价值，或者感觉到它对微软产品的威胁，微软这头猛兽就会主动出击，或者吞并蚕食，或者打造利器与之分庭抗礼，进而掠夺市场占有率。这是微软的一贯伎俩，因为微软在面对商业竞争时，永远都不会坐以待毙。

本文最初发表于IT168。

几天前，InfoQ发表了文章《给敏捷团队发奖金就像在刀尖上跳舞》，单从标题就可以看出其中的“惊心动魄”，显然我们需要高超的技艺，以及皮粗肉糙的脚底，就像某些非洲土著那样，方才能够游刃有余地舞动在刀尖之上。

确实如此，通过发奖金的形式来激励团队成员，本身就是一把双刃剑，弄得不好，可能就会破坏团结，导致彼此之间的矛盾与冲突，这对于一个团队而言是绝对致命的。然而，如果一个团队缺乏合理的激励方式，又无法调动成员的积极性。如何取舍，真是伤透脑筋。

现在，让我们思考一个场景。项目成功结束了，要奖励整个团队与团队成员所付出的艰辛吗？当然要，那么应该如何奖励，才能在避免吃大锅饭的情况下，既能避免团队成员之间不必要的勾心斗角，又能最大程度地激励成员的工作热情，从而皆大欢喜呢？从玩具到游戏，我的思考是抛开传统的奖金策略，采用如下的另类激励机制：
1、“技术玩具”
2、小礼品
3、自由控制的时间
4、教育与培训机会
5、选择团队成员的权利
6、开发游戏

适当的奖励可以让我们踢开刀刃，自在轻舞，但必须还要谨记如下两个原则：
1、在奖励优秀的开发人员的同时，不要忘记对优秀团队的奖励；
2、奖励方式应因人而异，必须最大程度地投合员工的喜好。

更多内容，敬请阅读捷道·敏捷堂发表的我的文章《从玩具到游戏，另类的项目激励机制》