引言：
我会以系列文章的形式跟踪记录我现在正在做的一个完整运用Scrum管理项目的笔记，里面会有一些经验教训总结心得，以便读者与我互相学习勉励。有写的不对的或者写的不好的地方还请海涵，当然我更希望大家多多提宝贵意见，读者的支持是我最大的动力。（之一，之二，之三，之四，之五，之六）
============================================================================================
项目在跌跌撞撞中终于尘埃落定，这个项目不大，计划总人力34.2人月，实际人力投入大概28左右。由于是内部项目，并且也可以算是实施敏捷方法的试验田，所以估算比较充足，不过不管是CPI还是SPI，从各方面的数据上来看这个项目还算是比较成功的。缺陷率比较低；项目运行顺利人力节省；客户满意；基本上没有加班；总之我对此项目还是非常满意的，当然还要多谢项目中的每一位成员的努力，特别是TM（Technical Manager）的合作与支持。
最后跟大家一起再回顾一下我的整个项目：
整个项目过程有点像网上常说的Fall-Scrum-Fall的过程，先瀑布->然后敏捷->最后瀑布
1. 项目初期，出资人或者项目提出人预指派（还未授权）PM跟进客户提出的一些想法，与客户沟通，结合公司的现有能力或者技术，提出产品的一个愿景，然后产生Feature List，以及系统的大致业务模型和构架。
2. 立案（PM真正授权），与客户达成意愿，把上面所说文档提交公司申请立案，这个时候需要做人力预估和时程的预估。当然这个是很粗的一个预估只是用来立案之用。
3. 市场分析与进一步计划，此时TM会参与进来，与客户一起讨论更细一点的Feature，具体到模块与功能，PM和TM一起做出细部的人力预估，产生人力与时程的基线。
4. 预研、架构与实作，对于关键技术点我们首先需要去做风险评估，并且为了降低风险而做一些预研性的工作。设计系统骨架，并实作一两个例子。因为我们运用的是敏捷，所以这里不会做很细的设计，我们尽量先做出来后面不断重构完善，但切记一定要不断重构，不要积累设计问题，不然必成大祸。
5. 开始真正的敏捷，这个时候已经进入真正的实质性的开发工作，整个开发阶段我们运用的是敏捷Scrum框架。
5.1. 我们的Product Backlog也就是我们上面讲到的细化过后的Feature List。首先我们会做Release Plan，定义迭代周期。
5.2. 然后选取PB中的一些Feature到Sprint Backlog中，然后开计划会议Sprint Planning Meeting。Scrum的几个会议我在前面的文章中已经有讲，这里不再细说。
5.3. 然后产生任务墙看板。在迭代的运行期，会通过每日晨会，任务墙以及燃尽图去跟踪项目进度，控制偏差和风险。
5.4. Sprint结束后会有一个Demo Meeting，大家一起看一下这个迭代我们的成果如何，是否我们是Story可以交付。然后收集反馈问题记录下来，作为下一个Sprint可能将要完成的任务。
5.5. 紧接着我们会开反思会，回顾一下上一个Sprint我们哪些做得好的，哪些做的不好，哪些本可以做的更好的？选取其中大家认为最重要的2-3条，拿出措施Action Plan，再下一个Sprint中去改进。（我觉得这一点我们做的非常好，个人认为这个会议也非常的重要，可以使我们一直都在持续改进）
然后周而复始一个接着一个的Sprint，直到开发结束。
6. 进入系统测试阶段，专门的测试人员会对整个产品做测试与验收工作。开发和测试一起合作完成。
7. 测试验收完毕后，提交最终版本给用户，用户做UAT验收工作。
8. 验收通过，最后做结项工作。总结项目，收集整理文档等。
整个项目完结。
我简单的把整个项目的过程按顺序列举了一番，没有细说，如果有任何疑问都可以直接跟我留言，或者通过微博联系我，我一定会尽我所知，知无不言。呵呵
我的微博是：http://weibo.com/lackinpm
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
