一. 项目基本状况
1. 作业时间2008年7月9日– 2008年10月7日
2. 作业范围详细设计，编码，PT测试。
3. 人员结构 PM1人+PJL1人+Member5人+支援1人
二. 这是一个什么样的项目
项目本身很正常，却无法正常去做。
最根本的原因，就是时间不足。
基本状况就是，一个需要六天的任务，只有三天的时间去完成，这种状况普遍存在。
所以，这个项目从一开始，对我们的PM，PJL来说，就是一种挑战。
三. 这是一个什么样的问题
时间问题。说到时间问题，每个人都会有不同的主观想法。Member会觉得是工作量过大，领导会觉得是客户太XXXX，客户会觉得是我们的能力不足。
客观的说，就是，以我们现有的水平无法在预定时间内完成计划中的任务。
不管是什么原因造成的，就是这个问题，从项目开始就出现了。
四. 对策
1. 加班。从项目开始一直持续到最后。
2. 加人。先后加了两个人。
3. 以降低质量来换取进度。这一点不是领导说的，是我说的。领导一直在强调，不管进度如何，一定要保证质量。但是谁心里都明白，既要保证质量，又要保证进度，那是不可能的。
五. 对我的影响
式样理解阶段：没有。被挤到DD设计的时间里了。
DD设计阶段：式样没理解透就开始DD，结果质量不好，做的也吃力。达不到指导编码的效果。（项目的最后两天，重新修改DD，若要完全修改的话，我的修改量可达80%）
PG阶段：只能说是写完。无法保证质量，PG结束后，对自己的代码仍没有信心。
PT阶段：很多PG的问题残留到PT，导致修改量大。很需要二次PT。
交叉测试阶段：我被发现的问题有很多。对我来说，是最重要的5天。
六. 我的流水账
7月9日
项目启动的第一天，大部分时间在开会，了解一下项目的基本状况，以及项目组成立后的注意事项，比如，任务安排，职责安排，作业方式，共通内容等等。
7月10日
按照大工程表的划分，今天开始作业，内容是XXX机能的详细设计，共4天。我自己在小工程表中划了两天的时间作为式样理解。
7月14日
第一个延迟。
延迟原因：
1. 式样理解不足。
2. 没有详细设计模板。
对策：
加班、调整工程表。
从这一天，我的延迟生活开始了，并基本上一直保持到最后。
从这一天，我们项目组的加班生活也开始了，每天9：30，周六加班，周日看情况。
7月15日
关于DD，PG的先后。
做这个项目前，我一直认为，对于我现在的水平，合理的做法应该是先PG，再DD。结果被领导否了，领导说，先PG再DD会限制住一个人的设计思路。我开始尝试不编码，直接DD，结果感觉很好。
7月17日
对DD的认识，发现两点很重要：
1. 自查时，一定要打印出来，校对格式。
2. DD内容的准则，就是，找一个傻瓜过来，也能看懂你的设计思路。
7月21日
第二个延迟。
延迟原因：
1. 作业量大。
工程表上三天的任务，我在加班的状况下，实际用了八天的时间。
2. 不稳定作业。
开会频繁，无确定时间，作业经常被打断，且占用时间长。
3. 过多的计划外的事。
很多工程表之外的事情需要对应。如WT实施，WT对应，共通类实现等等。
对策：
加班、调整工程表。
7月24日
领导心情很差，很烦躁，作业气氛开始压抑。
我决定给领导打起，因为我觉得，无论遇到什么困难，领导在手下面前都应该是自信满满的样子，即使心里极度烦躁。
7月25日
一个人严重的问题暴露了，member的问题。
当前项目组5人在作业，由于技术原因，只有一人能够正常DD作业，就是leader。
其余四人技术上的情况如下：
Member1：无XX框架经验。没做过前台jsp。
Member2，无XX框架经验，自学过一阵子。
Member3，无XX框架经验。
Member4，就是我，了解XX框架，但我的作业只用java，和XX框架没有关系。且java部分无框架。
由于XX框架的特殊性，对DD的要求很高，不懂XX框架的话，DD会很吃力。
7月26日
领导的状态恢复了。
针对项目组的作业状况（普遍延迟），领导的对策是，加一个人。很明智。
7月27日
领导的又一个明智的决定，让Member1和Member3提前进入PG阶段。
在另一个项目的case study中，也听到了这样的经验，对技术不熟的人，很实用。
这样能够让这二人，更直接的熟悉框架，提高后期的作业质量，减少风险。
7月28日
我们犯了一个错误。
框架设计和DD设计应该是分开的，而且，框架设计应该在DD设计之前完成。
而我们却是在DD设计的同时各自设计各自的框架，当WT之后才开始统一。
7月29日
总结一下这个阶段从领导身上学到的：
1. 在紧张的阶段，要时刻鼓励大家，而不是督促大家。
2. 不怀疑手下的工作方式和工作效率，要相信他。即使不放心，也要私下里说。
3. 不轻易在会议上直接批评别人，也不在别人面前说自己组员的不是。
4. 懂得自我批评。
8月2日
总结一下这个阶段学到的开会的学问：
1. 定时。
对于每天的例会，时间上要规定好，这样可以让member避免自己的作业被突来的会议打断，而且还可以让member事先对会议有准备。对于一些临时的会议，也要尽可能的提前通知，不要随叫随开。
2. 效率。
开会人提前做好准备，要说哪些事，要统计哪些事。完事立马散会，不要把会议的内容拿到会议上去想。
3. 语言精炼
一共有哪几件事，需要大家知道什么，需要大家做什么，怎么做。
Member只关心一件事，需要我做什么，怎么做。至于这个问题你是怎么发现的，怎么思考的，怎么设计的，我们不关心，我们关心的只是你最后的决定。
4. 能用邮件说明的，尽量用邮件。
节省时间，还能有所保留。
8月3日
正对目前的作业状况，日方提出方案，改变项目作业方式。
以机能为单位，分别进行DD->PG->PT。而且，每周按机能向客户提交成果物。还好我当时的DD已结束，接下来要做的就是机能1的PG,PT，然后进行机能2的PG,PT。…….
这样的好处：可以提前发现一些PT的问题，进而在下一个PG中避免。
这样的坏处：频繁的修改和维护文档。PG,PT的质量会有影响。
8月5日
关于review的问题。
据说第一次review都要全员参加。
我们review的方式完全是在模仿日本的review方式：会议室全员review。
结果不是很理想，因为项目组的大部分人技术和经验都没有达到能够直接review的水平。
这件事让我意识到一个问题，不能盲目的模仿日本的作业方式，应该结合我们自身的实际水平，用适合我们自己的方式。个人觉得，我们项目组的方式应该是这样的：
1. 针对某一个机能，在review前，安排2-3人（或者全员）在自己的机器上review，时间由review者在当天自由安排。
2. review者将review结果直接告诉给被review者。
3. review者将共通的问题，以mail的形式全员通知大家（或者利用早会）。
4. 有需要的话，可以在大家都review之后，再去会议室集体review，内容为大家陈述自己的指摘内容，而不是大眼儿瞪小眼儿的在那儿看。
5. 多多鼓励大家主动review，自己写完了，主动找别人帮看一下大概。
6. 参考别人代码的时候，也随时帮别人指摘。比如一些类似的地方，无所谓谁对谁错，只要大家做法统一就好。
总之，我们目前的水平，还不能靠经验来review，只能凭借刚刚做过的内容，再看到别人犯同样的错误时，就能够指摘出来。
8月6日
Review工作改为一对一的方式。由PM和PJL担任，分别review我们的各个机能。
这样，PM和PJL的工作任务又重了，由于时间的紧迫，使得一些机能无法得到及时的review。增加了一些不必要的修改时间。
这里让我想起某项目的一条经验，就是对每一个担当的第一个成果物要做到100%review。大概就是这个意思，这就是两个项目的差距，他们有式样理解的时间，有WT，CR的时间，而我们，这些内容，只能自己挤时间来做。
这样的情况下：
谈质量？谈方法？
8月7日
总监请项目组全员吃饭。
慰问餐。
8月12日
测试开始，整理几个问题：
1. 一定要发布到一个专门的服务器上，在服务器上测试。特别是在这种PG,PT交替进行的作业方式的情况下。
2. 测试的过程中，不要使用个人相关或者公司相关的数据作为测试数据，特别是截图。
3. 养成每晚下班前，checkin自己的代码的习惯。
4. checkin之前，先取得服务器的最新版本，保证代码编译正确。
Java工程中，即使个别文件有编译错误，其它文件依然可以正常编译，但是有些语言的工程是需要全部文件编译无误后，才可以正常编译的。
5. eclipse中由一个Checked Out Files的View，可以一览所有已checkout的文件。
6. 每天早上来了之后，先取得最新的代码，保证大家代码一致。
8月14日
式样变更的问题让人头疼。
这次让我头疼的不是变更的内容本身，而是在对应变更上。
1. 全员开会讨论，如何对应变更。
这样做没有必要，领导内部讨论完，给member一个方案就成了。
2. 对于某个变更，花了很长时间在全员会议上讲，为什么这样对应，还让大家去想领导的这种方式好不好。
这样做也没有必要，不是自己的机能自己也听不懂。对于member，我承认，需要有自己的主见，但是在那种情况下，member需要的，就是结论。
8月19日
我生日。其实很期盼领导跟我说一句，过生日，今天就别加班了，结果一直等到9：30也没听到，可苦了在家等我的那帮兄弟们。
8月24日
延迟白热化。
延迟原因：
1. 作业量大。
以Member1为例，一个机能，三天写了4000行代码，没写完，最后用了9天多，写了20几个类，净代码6000多行，还包括几个共通的类。
这样的结果是，他在例会上被领导狠批了一顿，因为延迟。
2. 延迟。
因为延迟，所以延迟。就是这样。我的体会就是，一直处于延迟状态，影响我的作业质量和作业效率。
对策：
加班、调整工程表、找人分担剩余作业任务。
我觉得，PG阶段，我们的代码质量可以做的更好，但是，这样的原因，导致，自己编码之后，对自己的代码一点信心都没有。因为我几乎没有认真的从头到尾看一遍自己的代码。
8月25日
部长，PM，PJL安排项目组聚餐。
得以小释。
8月29日
关于编码。
我习惯上是先写代码，待代码调通之后，再从头整理代码（格式，补注释以及代码优化）。每个人的习惯都不同，但这次，很吃亏。由于代码逻辑比较复杂，代码量也比较大（几千行），等我调试之后，再回头整理的时候，真的很头疼。
以后决定，编码的同时，写简单注释。
9月4日
项目开始走入正轨。主要表现在：
1. 大家对作业内容和作业方式都基本熟悉了。
2. 领导加人和调整工程表后，延迟逐渐向0发展。
3. 领导心情变好了。
这一个月，虽然依然在加班，但是比前两个月好多了。
9月7日
发现两个领导的一个共同优点，随和，不摆领导架子。值得推广。
9月9日
关于汇报进度。
从项目启动开始，每天都要汇报进度，直到现在才认识到一些问题：
1. 项目组要事先定义好进度的标准。
对于一个机能的DD,PG或者PT来说，什么样算100%，什么样算90%，什么样算80%。定义好，会节省很多不必要的再质问的时间。
2. 汇报内容要详细
有人认为这很浪费时间，我觉得很有用，也很值得。
既能整理自己的思路，又能让领导及时准确的了解你的作业状况。
主要说明这样几件事：
1. 今天计划做的内容。（工程表中要完成的）
2. 今天实际做了哪些内容。
3. 延迟情况（是否有延迟，有的话说明原因）
4. 对策（基本上就是加班，说明自己什么时候能过挽回延迟）
5. 遇到的问题。（包括一些横展开的注意点，以及一些无法解决的困难）
6. PT的话，要说明，测试机能名，预计测多少点，实际测多少点，产生多少bug，对应状况等等。
总之一句话，尽可能的说明白。
这个项目，基本上都在例会上汇报进度。个人感觉，不如改用邮件的方式更好一些。
9月14日
划工程表的一个小失误，没有考虑到节假日。（端午节休息）
9月16日
写邮件时，被领导指摘了。一定要写有意义的title。
9月27日
加班生活结束。
10月4日
提交最终代码。
10月6日
修改DD。
再回头看自己两个多月前做过的DD时，发现做的真的很烂。
1. 缺少框架的概念。
2. 欠缺共通的思想。
3. 关于异常，Log等细节考虑的不全面。
以后需要注意。
七. 项目之后，谈谈心情
从心里来说，其实从不觉得这个项目累，比起曾经，这样的加班不算什么。但是，这个项目做起来，没有做上一个项目舒服。
做上一个项目的时候，自己一直被领导和身边的人肯定着，我付出的越多，越能帮助大家解决更多的问题，所以，虽然每天加班到很晚，但是做的很开心。
做这个项目的时候，从一开始我就处于延迟状态，每天加班的目的只有一个，就是挽回自己的延迟。别说帮别人分担作业了，连自己的作业都无法完成。这样的加班，不可能是开心，只能让我更加急躁。最烦的时候，甚至开始抵触加班。
那段日子，不只我烦，包括领导，大家都烦。虽然心情会影响到一部分工作，但大家还是一起挺过来了。
我觉得我们是成功的，因为我们都坚持到了最后。
无论遇到什么事，只要坚持住，相信一切都会好起来的。
欢迎来访！^.^!
本BLOG仅用于个人学习交流!
目的在于记录个人成长.
所有文字均属于个人理解.
如有错误，望多多指教！不胜感激！