敏捷开发案例--混乱小项目的敏捷应用

        最新在博客园看到一篇博文，介绍一个混乱小项目的敏捷应用，作者利用XP(极限编程)的最佳实践完成了近乎不可能完成的项目，由于没有博客园的账号，不能在原文留言，转过来供自己学习参考。

        原文地址：http://www.cnblogs.com/meil/archive/2007/03/13/672530.html

       原文内容如下：       

我们假设一个project中有以下状况：
（1）需求不明确，没有完整、详细的需求描述。用户没有提供标准的需求文档。
（2）技术架构明确要求为J2EE，要求使用：Struts,Tile,EJB,DAO,OJB，数据库为Oracle 8i/9i，集成开发工具要求为WSAD，系统有大量的计算，对性能有明确要求。
（3）团队人数为6人，三人为刚大学毕业的新人，对上述技术架构和开发工具不熟悉。另外3人均不能full time参与。其中项目SA只能参与第一周（5天）。
（4）交付时间特别急，要求3周就必须完成。但是交付物只需要：SRS（软件需求描述）、源代码/安装包、安装文档，不需要概要设计、详细设计等文档。
（5）项目规模不大，业务需求约为12个左右，其中有5个非常简单的需求（增加、删除、修改，没有特别的计算）

基于上述状况，不能根据大概判断就直接拒绝，首先进行了风险识别（实际的Risk Management Plan就不show了）：
（1）项目范围不明确，特别是不明确最终用户的需求。
（2）没有确立变更机制，没有SOW（Statement of Work）
（3）没有明确的验收条件
（4）没有合适的标准软件过程、开发模式、生命周期适合本项目
（5）对于上述的技术架构没有经过验证和测试，特别是OJB。
（6）项目组对于上述技术（J2EE）要求没有足够的开发经验，有经验的SA时间不能保证。
（7）项目组对于客户指定的WSAD不熟悉
（8）测试服务器的性能可能不能满足测试要求
（9）关键资源（SA和另外2位）不能确认能够参与的时间
（10）Team为全新，之前都没有互相进行团队并行开发
识别风险后对每一个制定了应对计划。
做到这里，已经可以跟Manager汇报说不可能了...

然后基于项目需求分解WBS(Work BreakDown Structure),找来SA进行历时估算，对每一个UseCase估算其开发时间，当然按照有相关开发经验的人员来估算的。得到了总共Effort以及Price。
根据最终的交付时间回溯列出了一个Schedule，设置多个重要的Milestone。

回来来Review自己做的Project Plan，仔细看看Schedule，可能吗？别忘了，我们还不能周六周日加班，－_－。

不管如何，这是个混乱的项目，进度、资源、风险，各个方面都有大的问题，抱怨是解决不了问题的，还是脚踏实地做下去吧。

回过头来，该做的事情还得继续做下去：
第一步，控制需求（Scope）。客户不是没有需求描述吗？我们自己根据其提供的需求原始文档编写，同时做出需求的UI原型，我们不确定的地方都做为Assumption。提交给用户审核，不必要的功能通过谈判砍掉：时间这么短，架构、性能要求高，怎么可能做出那么多需求来？很快需求控制住了，我们实现的功能很明确。
心得：这个项目能够控制住需求的原因有二：（1）采用需求原型开发，根据自己对需求的理解快速把UI整理出来。（2）仔细的编写SRS，把一些假设（Assumption）明确的写进去，避免后续的问题。

   现在该回到主题：XP（极限编程）了。
   （1）No Plan, then plan every day. 现在说自己写了一个项目计划，但是3周时间，这么短如何跟踪？所以每周制定一个Activities List，每天计划，每天跟踪！任务分配到个人并定义相关接口人员。
心得：（a）天天分配新任务并跟踪的做法对于Team members来说工作强度太大，压力也太大，不适合长时间项目使用。一般我会事先说好采用的时间段。在长时间项目中只在关键阶段采用该方法。
（b）天天计划要求PM对工作任务和技术方面非常熟悉，否则就是瞎指挥！危害很大，Team members背后可能都把你骂死了，你还自以为自己安排得非常好。因此首先需要征询SA或者Senior Enginneers的意见，在计划和分配时也需要得到相关members的同意。不要直接命令下去。
（c）理性对待Delay，过程中有2天的Delay，不要试图加班等初级手段赶上去，一般来说，赶只会越赶越慢。想想看有没有其它的解决之道。

  （2）Continous integration：采用Smoke Testing的方法. 也就是冒烟测试，保证从项目初期到最后交付都有一个可运行的版本。指定一个配置管理员，负责每天将最新版本部署在测试服务器上，保证可以编译并运行。
心得：由于配置管理skills方面的原因，初期并未能run起来，之后才能得以跑起来。

  （3）Simple Design：其实我想做详细设计也没门，因为SA只有一周的时间参与，怎么做？做一个例子，数据库上建一个table：product，然后从前台JSP,Tile ->Struts->EJB->OJB->DB能够跑通，可以在页面上add，delete，update。嗯，中间漏了DAO，可以以后加嘛。这个例子做好之后做为例子供其它Team member学习和熟悉。
心得：迫不得已的做法，但是的确有好的效果，在SA做这个例子的期间，其它人紧张的进行环境准备和技术准备，大家得以熟悉开发工具和开发环境以及必须的技能。有一个现实的例子，普通程序员开发起来心里更有底一些，自己设计会有问题，难道照着做还不会吗？

  （4）Pair programming，当然有些变通，Pair programming的意思是两个程序员在一台机器上来开发代码。我的做法是将前台部分的功能（从Jsp，Tile，struts到EJB）根据不同特别分配给3位Entry SE（入门级软件工程师）。这部分工作量很大，大家的缺陷都非常多，但是通过互相检查和共享，效果很不错。进展快得人可以更快将功能集成进系统。
心得：如果采用水平分配任务，可能有的人能够做得好能够提前进度，但是任何一人出了问题，那么整个系统就没有一个功能可以run，同时在接口上的沟通成本会非常大。

  （5）40-hours work, 在项目初期就先说好，前两周开发时间不要求加班，在最后一周集成测试时才要求晚上部分加班。
心得：象这类风险大的项目，如果全靠加班才能做好，那么肯定是初期有大问题。还是那句话：进度不是赶出来的，进度是plan出来的。

没有完全采用CMMi的一套Process，而是采用了XP的部分Best Practice，最终项目按时、按质提交，似乎完成了不可能完成的任务，但是当SQA来Audit的时候，报表很难看。所以采用这种方法有以下缺陷：
（1）知识保存：所有的项目管理经验都在PM脑子里，设计理念在SA里，好的实现都在开发人员的脑子里和代码行间。项目结束后，不少项目组成员都到了其它项目组，后续项目（该项目有后续大的单子）得不到之前继承的知识。
只剩下了结果。
（2）Tracking：只有PM了解项目的真实情况，其它人都无法知道，SQA也没法检查（XP里面是没有SQA的）。

由于一直是在CMMi下面Lead项目，因此部分工作还是采用CMMi的Process，比如配置管理（CM），需求管理（Requirement Management），PMR（Project Management Review），Risk Mangement， Issue Management，DefectTracking等等。

        从结果来看，作者的这个开发解决方案接近perfect，顺利完成了项目目标。虽然说过程资产缺失严重，但是这么短的周期，还能要什么自行车？如果按照正常项目开发流程，我想连立项恐怕都难以完成，更别提要交付给用户了。从整篇文章来看，作者对项目管理已经有了很高层次的理解，不仅是CMMi，还有敏捷开发，对不同类型，不同条件的项目也可以将从容应对，非常厉害。

在作者的实施方法中，有几点非常认同：

作者刚开始就针对需求做控制，把不确定的需求明确下来，确定项目范围，这点至关重要，在项目失败的原因中，需求的不确定是第一要因，更何况还是这么短的周期，需求稍微变一点，失败肯定是必然的。

每周制定一个Activities List，每天计划，每天跟踪！这招比较狠，每天每个人都有一个deadline，鸭梨山大，在这种情况下，每个人每天都很明确自己的任务以及完成时间，虽然有压力，但是我想效率应该会很高，而且在项目完成之后team member的成就感会很大，对士气的提升很有帮助。

简单设计，作者根据XP的实践准则结合自身项目特点，制定了适合自身项目的设计准则，比如由SA做DEMO，其他新人并行熟悉环境，随后再由新人参考DEMO来做开发。

也有不太认同的：

结伴编程，作者描述的太简单，木有看出来哪里有结伴。

40-hours work，项目时间紧急，又有很多不确定因素（比如需求、WSAD），虽然我很不赞同加班，但是这种情况下，开发周期不长，要求team member保持高效率、高产出比硬性遵守每周40hours更合适，如果下班之后，某个兄弟感觉自己依旧精力旺盛，又十分愿意主动加班，这个时候我想应该对项目，对团队来说都不是什么坏事，但前提是加班不是完全无偿的，至少要提供调休或者其他福利之类的，这样大家才会有动力，毕竟雷锋同志不是每个人都愿意当的。

统一编码风格这篇文章中没有说明，不知道在这个项目中有没有用到，这个项目中有几个新人，如果没有统一编码风格，很可能最后代码风格非常混乱，或者根本就没什么风格（有的童鞋编码从来不讲究风格），如果是这样，以后维护的童鞋有罪受了。