这段时间由于复习考试，看了一些ＲＵＰ、ＸＰ的开发方法。在学习的过程中，我都结合着工作中的实际问题来思考，看看是否有什么方法是可以解决工作中的所有问题。最后，我发现，事实上是没有任何一个方法可以解决一个具体项目中所有的问题。所以，我就考虑，其实每个项目都是独特的，都应该根据实际情况来进行项目管理和从各种开发方法中取适用的部门来组合。

　　我所涉及的项目都比较小。一般１－２个程序员开发１个月左右就能完成，主要针对公司内部核心系统的补充。下面列个清单，方便理解：

前提：１）项目规模小；

　　　２）项目组成员：team leader（同时负责方案、设计、技术支持、项目进　　　　　度控制）、１－２名程序员；

　　　３）程序员都是经验非常少的，常常还有一点经验都没有的。

步骤：１）方案（ＴＬ）

　　　２）讨论（ＴＬ）

           (3)  架构设计 （新加的，详细介绍见下回复）

　　　３）设计（ＴＬ）

　　＊以上三步都形成文档；

　　　４）开发（程序员）

　　　５）阶段性交付（程序员）

　　　６）需求变更（客户、ＴＬ）－>需求变更文档（ＴＬ）

　　　７）评审、结束

说明：

　　１）－３）是team leader和业务部门人员讨论形成。我在之前考虑过让开发人员一起参与讨论（事实上，我认为这才是正确的做法），但在操作起来，如果让开发人员参与讨论，并且由于我们的开发人员非常缺乏经验，不但缺乏技术经验，还缺乏业务经验。这样就会造成每次讨论时间拖长，但效率降低，效果并不好。因为我还是倾向于在讨论详细设计之前的工作，不让程序员参与（除非程序员是有经验的程序员）。

　　在这个阶段的工作中，我认为是比较好控制的。唯一的疑问是：

　　Ｑ：如何将设计文档写的即能控制住项目的功能，又留有余地给程序员发挥？

　　我自己认为，这需要看程序员的熟练程度，越有经验的程序员越可以留更多的空间给他发挥；缺乏经验的程序员，就应该将设计文档写的详细。但问题又出现，越缺乏经验的程序员，对工作认识越不深，越希望不受束缚。

　　４）－５）我把它定义为开发过程。主要是程序员进行开发工作。这个阶段的问题比较多：

　　Ｑ：（１）程序员之间的交流？

　　　　（２）程序员与team leader之间的交流？

　　　　（３）程序员与客户之间的交流？

　　　　（４）team leader与领导之间的交流？

　　　　（５）team leader与客户之间的交流？

　　　　（６）进度控制？

　　　　（７）进度调整？

　　　　（８）关键功能的控制？

　　＊对于我们这种小项目，我不赞成太多文档，尤其在开发过程中，最好不要程序员产生文档。但没有文档，该如何解决以上这些问题呢？在ＸＰ中交流就是来解决这些问题的。但放在具体项目中，也是有问题。如果程序员之间没有交流意识，是很难控制。程序员，尤其是缺乏经验的程序员很少会主动给team leader报告他的工作情况。甚至，team leader去问，都问不出问题，我听到最多的就是：在做！没什么问题！快做完了！更有甚者，问程序员做完没，他告诉我：还是前两天那个问题。我晕，放了两天的问题，不说话，不解决，我不问，他不说。（为了防止把这篇东西变成诉苦篇，我就此打住）

　　在程序员不善于交流的时候，team leader就只能主动去过问了。而且，问的问题要很明确，比如：你完成了那些功能？某某功能完成没有？现在正在做哪一个部分？

　　总之，我觉得跟缺乏经验又自负的程序员交流，比跟熟悉业务的客户交流要困难的多。

　　（希望大家有什么好的提议）

　　５）阶段交付，是根据敏捷开发方法中提高，不断给用户提交可使用的产品。将项目阶段划分小一些，尽量使每一阶段完成的功能都能单独使用，然后提交给用户使用。并收集用户反馈信息，若影响到原有设计的进行需求变更。

　　为了解决team leader与客户和领导之间的交流，team leader应该每周或每两周提交一份进度报告和问题给客户和领导。（目前我对客户是没有反馈，每个月给领导一份报告，现在觉得时间间隔应该缩小）

　　６）需求变更，由team leader收集，写成新的需求、设计文档。这是因为如果写进原文档中，容易被忽略掉。但要在原设计文档中增加提示：在这里变更了需求，参考文档。。。（这是跟飞机手册的改版学的。呵呵）然后反馈给程序员进行开发，或修改代码。

　　最后，全部功能开发完毕后，进行一次评审。事实上，前面不断提交产品给用户，最后的评审应该问题不大。

　　最后，要求程序员提供两份文档：程序清单和用户手册。

－－－－－－－

１、该过程中产生４份文档（不算team leader给客户和领导的周报）：方案、设计、程序清单、用户手册。

２、这个过程中，所有压力都在team leader身上。这是因为程序员都缺乏经验。当有有经验的程序员时，有部分工作应该转移到程序员身上。

３、对程序员的培训。不是指技术培训。而是让程序员意识到项目管理中的知识，以及工作方式。

－－－－－

这个过程是我想出来的。我的项目管理经验很少。因此在不断地摸索。不断地尝试各种办法，将项目管理好。我将在下两个项目使用上述方法。也将根据项目的进展不断反馈到这里，也检验我的方法是否可行。祝我成功吧。