(1)：组建项目组

09年3月3号，老大把我叫到办公室，表示接下来要开发一个CMS（内容管理系统）系统，用来管理我们现在的网站，并希望我们尝试新的技术与新的开发流程。

好家伙，早就嫌我们的开发流程老套、笨拙了。正好借此机会试一下我心怡已久的Scrum敏捷开发了。

郁闷的是老大表示我们有两个项目要同时进行，当下心里就想就我们技术部这点人，还要两个项目一起开发，那怎么可能，先说下我们的部门的人员情况：

我，自认为技术全面，美工，脚本，HTML，.Net都会点，当然挂职还是程序员

小W，专职程序员、是技术部与其它部门前的主要外交管

小Z，程序员兼公司的网管

小F，程序员，另一个项目的负责人

小C，UI程序员，专写脚本

小L，美工

小J，美工

小X，测试员

小Y，DBA

另外更要命的是居然另一个项目说是要在4月9号完成， 我这个项目是要在4月底做完。我仔细想了下，在这么短的时间根本不可能做完，另外敏捷开发指导不要做过分承诺，以免为了走进度影响开发质量。经过一翻讨价还价，老大表示可以先把主要的功能在1.0版本中完成，剩下部分可以在1.0版本后进行完成。至于人员分配，我得与另一个项目负责人自己进行协商。并要求在3月9号开始开发。

另一个项目（以下称"项目E"），其实也是公司的核心项目，由于公司的销售策略改变，导致我们网站在一期开发完成后居然要马上进行业务流程修改。这个项目是公司的根本，必须要在4月9号完成。而我的CMS项目，只是完成网站的页面静态化，另外由于公司每天多要发布大量的资讯，而现在都是美工纯手工的制作页面，两个美工每天需要花大量的时间来处理。为了解放美工，并且适应我们快速增长的资讯量，项目也必需在4月底完成。

经友好协商，我分到小J，小C，小X与小Z，加我自己一共两个写后台程序的，惨！另外小C还得在参与项目E的部分脚本。我的如意算盘是这么打的，数据库我就用LINQ搞定了，1.0版本中也不搞什么存储过程了，与就不需要什么DBA了，项目E则不同了，之前大量的业务逻辑被存储过程管了，至于小C，会写C#程序，我是想让他给我在空闲之于写写后台的，以补充我们的火力。小X则是两个项目都参与了，我看我是只能指导他搞集成测试了，我们自己先做单元测试保证软件质量了。我也只能指望项目E能在4月9号如期完成，好让我有足够的人手了。交待一下，另外还有两名产品部的人负责我们给我们开需求，正好充当Scrum中的产品负责人角色。

唉，人员不足，时间紧张。我只能是硬着头皮上了。

(2)：全员会议

打从项目组定下来的那天起，经理就天天过来问，项目准备得怎么样了，什么时候开始动工。很显然，经理很关心我们的进展，对我们这些家伙怎么开展工作似乎有些不放心。

看来我得有所行动了，打消经理的一切疑虑。按部就班，在项目开始前，我应该招集项目组成员先打个全员会议。对接下来的要做的事情给项目成员以公司高层做个介绍。

时间定在了星期三的10点开始，计划两小时，给团队全体成员与项目相关人氏、领导都发了通知。我连夜搞定了第二天要演示的PPT，第二天一早，信心满满的到了公司，准备开会了。

小W提醒我会议室和前台确认有空了没，跑过去一问，晴天霹雳！！老板10点多要用会议室。刚回来坐下，经理就来问我们开会准备好了没，把情况说了下，经理下二楼可以开。二楼是老板的地盘，说实话，很不适合开会，到时肯定死气沉沉的。不过也没办法了，都发出邀请了，硬着老皮上吧。

召集人马，杀到二楼，老板刚好在。大家只好老实坐过去了，都不做声。经理和产品经理被老板叫去了办公室，我们一伙人就这么等着，小声的说着话。一会产品经理出来说要我们下去算了。老板不让我们在这开。我..算了，倍受打击。散伙，回座位吧。

吸取教训，先找前台确认了下午我们要用会议室。会议时间改成下午1:30.

言归正传，这个一波三折的全员会议总算在下午搞定了。进程如下：

1. 产品负责人介绍了项目的需求，远景描述等（个人感觉产品负责人太啰嗦，我看与会者都是昏昏沉沉的）
2. 在正式的场合介绍了项目团队成员以及每个人在项目类的投入程度，投入程度说明很重要，领导们认为我们这么大梆子人搞这么点东西还这么慢
3. 介绍我们项目将使用什么开发流程，怎么使用。这个自然就是用我推崇的Scrum敏捷开发了.我会在后面介绍Scrum的流程
4. 介绍在我们项目将要用的一些技术（同样会写一篇）。

会议完成后，看来经理很满意，事实上效果很好，在接下来的日子了，我的世界从此清净了，经理再也没来问我进度相关的事了。项目组成员对新的流程与技术很有兴趣，信心高涨。呵呵，万事俱备，就等开工了。

(3)：开发流程

Scrum敏捷开发，是对流程控制比较严格的。每个环节都有一套完整的过程和严格的时间控制，在我们项目组的开发过程中主要开发过程如下：

图片摘自Scrum-Checklists-Chinese一书，我对里面的部分用中文改了一下，下面我对全过程逐一分解，

1. 全员会议：主要作用是动员一下开发团队，在正式的场合宣告项目组的成立。并向团队成员说明项目远景描述，规定开发流程。以及预测将要用的到的一些技术，好让团队成员有个准备时间。本次会议两小时左右搞定。
2. 产品故事列表：用产品负责人整 理完成，在全员会议开完后，我们团队得到了三天的自由准备期。在此期间，产品负责人将把需求整理成故事列表，一个故事相当用我们开常的一个用例，但是文字描述仅停留在业务的层面，绝不涉及到技术术语。主要用Excel文档搞定，我们的文档主要包含故事ID，故事名称，怎么演示，重要级别，所属模块几个字段。

冲刺开发（Sprint）,至此为止，一切准备工作做完，开始冲刺了。关于每个冲刺时间的设定，我们项目组选择了两个星期为一个冲刺周期的。

1. 冲刺计划会议：在上图在冲刺计划会议为两部分，在我们的项目开发中发现我们基本上两小时左右就可以搞定所有事项目，所以一个计划会议就行了。我们首先会先请产品负责人就每个产品故事进行说明，在这过程中与开发人员进行直接交流。然后根据重要级别对产品故事所需要的时间进行评估，最选择本冲刺内要实现的产品故事。接下来由开发人员拆成每日可完成的任务。冲刺计划会议的直接产品就是冲刺任务列表。
2. 冲刺任务列表：做为冲刺计划会议的产物，冲刺任务列表将在接下来的两周冲刺内发挥指导作用。他分为未开发，开发中，未开发三列，再加上一个冲刺燃尽图。
3. 冲刺与每日例会：计划会议后进入为期两周的开发，在此期间每天的早上9：30开始每日例会，用时5到10分钟。流行的每日站立会议没有在我们项目组实施开。我们项目组都是开会不太说话的，因此站立防止扯蛋的事就没必要了。每日例会后每个人更新自己的任务表。我还要每天更新下燃尽图。
4. 新功能演示：演示时间到了组织产品负责人进行演示，产品负责人评估新完成的功能模块。
5. 冲刺回顾会议：开发团队回顾本次冲刺中成功与失败的地方，进行总结，以便下次冲刺做得更好

我们计划经过4个冲刺后完成我们的CMS1.0版本。