标签：
对软件工程M1/M2的总结。
我在团队里面的职责为PM，这学期一路走下来，对于一个工程项目的制作运营、团队任务的分配管理、项目进度的控制有比较深刻的体会。
在尝试去开始一项工程时候，我们需要去明确自己的目标和需求，这是整个工程能否完成的基础，也是程序的基本目标。一个明确的需求能让开发减少很多不必要的麻烦，这也是我们团队在M1时做得不太充分的地方，虽然后面修正了，但也浪费了很多不必要的时间。当然，在M2阶段，我们做的第一件事就是去明确用户的需求。这让我们在M2阶段少走了很多弯路，直达目标所在。
在明确的需求指导下，可以设计出各种任务，我在M1刚开始的时候是把任务分配成几个大任务，让团队人员以结对编程形式去完成。但我在后来发现一个问题，就是有的人编程能力强，能很快完成任务，但有些人并不是能力不行，就是比较懒，这是我没有考虑进去的因素，导致中期有些任务进度比较慢。后来在M2阶段，我让结队的组合改变了一下，让一个能力强的带上一个比较懒动手的，相互督促，能让项目完成速度加快。
在M1阶段，我对TFS和燃尽图不太熟悉，并不觉得它有什么特别大的用途，老师让我每天去操作和写博客，我也只是去照规定做，感觉还是一知半解。在M2时候，再一次在TFS建立起任务，感觉比起M1要熟悉不少，后面把燃尽图的模板换成老师一直想让我们贴的那个，燃尽图就变得好理解了。任务的进度和项目的状态能很好地反映在燃尽图上，我也理解了为什么老师需要我们项目的燃尽图，的确能够从燃尽图中获得很多项目进展的情况和信息，也能看出项目进行时候的问题所在。
以前提问题的博客链接：http://www.cnblogs.com/Linhs/p/4027274.html
自己想回来这个问题，还真是巧合，自己当上了PM，对这个问题也有自己的理解了。我在项目中的形象可以说是一座桥梁，建立用户或其他团队与我们团队的开发人员之间的联系，需要兼顾的事情有许多，包括将用户的需求反映为我们的任务需要，并把任务分配给开发人员。同时了解每个任务进展以及整个项目的进度情况，考虑需要和团队成员情况、任务进度等因素增减修改任务。像我这个学霸项目，多个团队合作，我还需要提供需求，让爬虫团队进行实现。基本是开发和测试外的所有事情都需要你去接触。
至于与团队沟通，其实并不难，团队的队员都是比较熟悉的人，交流并不困难。不过pm需要不断督促开发人员工作，不然你会发现他们的任务速度都是慢悠悠的。
敏捷开发，可以说我们在整合阶段遇到许多问题都是用敏捷开发来解决的，站在我的角度上，当我获得了用户的新需求或需求变更，我只按照用户所给予需求去做这个项目，去新建或修改任务，不会想着去设计一些其他的功能扩展，这只会徒增开发人员负担而且减缓开发速度。当用户有新的需求，我再去满足，迅速修改项目任务。这便是敏捷开发，追求的是开发速度，也就是快速开发。其实这样对于我们开发和设计人员要求也是蛮高的，我们要快速响应需求，在原有的代码基础上作出修改，所以我们在开始的设计和开发的时候都需要为后续的修改做好准备，代码的规范化，模块化，面向对象，高内聚低耦合都是需要贯通整个项目的思想。
对于这个，我们团队也曾经讨论过，注释一般是书写在自己修改和开发的模块之中，需要保证在一些特别设计的新变量或者新方法的地方说明其含义和效果。
新问题：
1.如果用户在临近发布时候提出的一些新需求，我们应该怎么对待？
（这种情况也是有出现过，我们一般的考虑是小需求赶工完成，大需求留作下阶段解决。）
回头看之前所读的几篇文章，也能在我们项目中找到一点影子。其实我们在上一届的代码基础上做修改，其中就有一两个大泥球，虽然比较难懂，但是它能工作，也能用，所以我们也没去怎么动它，让它遗留了下来。这也许是不足之处，但我们也没办法，因为没什么人喜欢读，更没人想去改，只是写了些注释上去，修饰了一番让它好看了一些。现在想想，这种大泥球的确是比较恶心人的地方。同时也更加说明了文档和注释的重要性，任何程序员在看到一份没有任何注释的代码都会产生一种厌恶的感觉，注释和文档是程序的重要组成部分，虽然写起来麻烦，但是为了后续的测试和维护，这是必不可少的。
做了一学期的PM，我学到了这些阶段知识点：
需求：需求分析要做好，之前我也提到过了，这是我们在M1阶段学到的东西，比较深刻。
设计：设计要让用户方便使用并尽量满足需求。
实现：实现要高内聚低耦合，能快速修改和扩展。
测试：测试需要尽可能覆盖代码，并参照模块设计方案考虑尽量多的错误情况。
发布：发布及时，尽量能在定下的时间内发布，因为这也是用户想看到的。
维护：留下尽量详细的文档，方便以后的维护人员理解程序代码。
标签：
原文地址：http://www.cnblogs.com/Linhs/p/4214796.html
