软工课程总结
总算结束了一个学期大部分的事情，可以静下心来写篇软工的总结了。
在本学期的软工课程中，我担任的角色是Chronos团队的PM兼开发人员。在课程之前，我认为PM的角色应该还蛮轻松的，无非就是做些调研，帮助组内的成员协调下工作，然后就可以高枕无忧等着验收成果啦，而自己则可以将大量时间投入于团队的开发工作上，从这点看来PM貌似就成了我的一个兼职、副业。鉴于自己对各种方面的知识都有所涉猎，理所当然地认为自己能够掌握整个团队的开发任务，统筹规划好各个部分任务，带领团队一起取得成果。然而经历了累死累活的一学期后，这些naïve的想法完全得到了改观。
在实际的开发过程中，我发现PM的工作远没有想象的轻松。而让我感到压力山大的是，我既要担任PM，也要负责团队中的主要开发工作。有时开发工作一忙起来，根本就没有时间顾及到其他成员的问题。如在Alpha的冲刺阶段，我在苦恼于如何将刷新加载框架融合到现有的界面中，而其他成员也同样遇到了许多难以解决的问题，或者设计模式上的分歧，等着我去定夺。但由于专注于自己手头任务的开发，没有过多时间了解各个成员的开发情况，对成员的问题和请求也只能简单地回答，或者干脆直接交给成员自己解决。现在看来当时完全没有尽到PM应尽的责任。
经过这些教训，若之后还有机会参与一个团队的软件开发，绝对不能将身有重负的开发人员任命为PM，也不能因为某个人的项目开发经验较多就认为TA更胜任PM一职。在经历了一个学期的开发后，我个人对自己的PM工作不是很满意，我认为一个合格的PM应该要有下面的素质。
一个PM可以没有过硬的代码能力，但是他必须要有快速的学习能力。作为一个统筹项目全局的角色，PM需要在掌握各开发人员开发现状的前提下安排任务。而各个开发人员的开发领域不尽相同，每个人每隔几天又可能在攻克一个不同的方面。为了对项目有个全局的把握，就要求PM能够在短时间内跟进每位开发人员的开发现状，能够从和团队成员的交流、文档阅读或者是资料查阅中快速抓取关键信息，得到和项目本身切实相关的知识，并在多元信息中建立各个部分的联系。如在Beta阶段的开发过程中，我需要一边留意前端设计人员一直在阅读的Material Design设计原则，同时也要留意部分后台人员正在开发的IM通讯中的各种机制，以及服务器编程等等，以确保我在协调任务和做决定的时候不会一无所知，或甚至和成员正在遵从的原则相反。
一个PM要有很好的统筹管理和分析能力。这点说来也许很泛，因为基本各个行业的管理者都可以用这样的词语去形容。那对应到软件工程中，一个PM需要具备的统筹管理和分析能力应该是什么样的呢？不妨将这个问题带入到我们的开发过程中一步步说明。首先在项目的初期阶段，PM需要对用户需求进行调查，并保持敏锐理智的分析，从需求中分析出产品将来的预期功能，并为产品定位；在这之后，根据既定的需求功能，PM要将功能分块，并结合各位成员的能力分配不同的岗位；最后，还要决定用什么样的管理模式来协调团队中人和项目两个实体的各种联系。在项目的开发过程中，PM需要统筹全局，动态地调整每个任务的优先级；并能够从全局出发，提前准备好各种可能的应急方案，用于解决一些紧急情况。通过管理技巧保障团队开发任务的步伐不偏离预期。
在开发过程中，我们也顺着这一过程走了下来。为了需求分析，我转变角色，将自己代入情景中进行假定，并精心设计了问卷调查，从收到的百来份反馈中筛选分析有价值的信息；之后根据划分的开发模块，和了解过的各成员历史开发经验，为大家分配了不同任务；在管理模式上，从代码到文档以及各成员之间的联系（如前后端耦合协调）都制定了一套规则，通过OSC管理源代码、TFS管理TASK与BUGLIST、坚果云管理团队文档、设立需求文档为前后台交互的窗口等；开发过程中，我也通过设立缓冲区，细化任务分配时间的粒度，来提高团队任务分配的机动性，若遇到紧急情况也能有足够的时间来应对（如Alpha阶段中由Eclipse到Android Studio的突然转变，得益于前期计划的灵活性，才能让这次转型成功完成）。
除此之外，PM还要负责协调组内成员的关系，调动成员的积极性，能够化解冲突矛盾。我们的开发过程也难免有组内矛盾产生。特别是当个人利益和团体利益产生冲突的时候，或者是成员之间的意见不合时。作为PM我无法凭一己之愿直接支持某个成员的决定，也不能在产生公私间冲突的时候迁怒于成员。PM与成员之间不应该是上下级或者猫和老鼠的关系。我希望成员的付出是出自责任心，团队精神以及对这份项目的热爱，而不仅仅是为了交差。正因如此，任何责备和迁怒都是不妥的。在我们的团队中，产生利益冲突的时候我会尽量体谅组员的处境，同时让其他组员相互照顾，大家可以共同扶持帮助弥补拖欠下来的工作。这样存在利益冲突的组员能够很快解决完个人问题，投入到开发工作中，并乐意与PM交流自己的开发情况。并据我观察，这时候其工作效率和工作积极性都会提高不少，而且这种提高不是暂时的。
总结下来，在本学期的开发过程中，我的角色处于一个比较尴尬的位置，并没有很好尽到PM的职责，但也正因此教会了我，担任PM并不是光说不练的假把式，一个出色的PM需要大量的时间精力投入，TA是团队的轴承纽带。同时，也明白了自己和一个合格的PM都有哪些差距。之后若还有机会担任PM一职，我将会更注重把握各个成员的开发情况，按照合适的开发模式推进团队进度，将更多精力用于协调成员交流与任务决策上，这也都是我在本次开发中做得不足的地方。
最后，当然要感谢下Chronos的所有成员。大家的热情、积极和责任心我都感受到了。想说的在展示时也说了，不再多言，感谢大家陪我一起完成这次的旅程！
我们在学期开始的时候布置了阅读作业，要大家快速阅读，同时提出自己的问题。 现在通过一个学期的学习和实践，请大家写一个博客：链接到以前提问题的博客请说明哪些问题现在自己已经清楚了，请阐明一下，是如何通过看书，实践，或者讨论弄清楚的。
博客链接：http://www.cnblogs.com/kanelim/p/4830963.html
1） 针对书中提到的NABCD模型中的N，如何发掘市场不明确的潜在用户需求？
这点其实在开发过程中感受较深。我觉得发掘潜在用户需求最直接的方法应该就是问卷调查了。问卷调查虽然很传统老套，但是却能够获得最真实的用户反馈。比如在我们的问卷调查中曾经设计了这样一道题：“你希望给Let’s添加什么附加功能？”我们收到了162个反馈，其中也不乏一些靠谱的好建议，这些都是我们之前未考虑到、或者不明确具体需求量的潜在需求。而正因为这份问卷，才让这里面的部分需求在最终的产品中得到了满足。
2） PM是否负责团队职责的分配以及工程模块的设计等工作？如果是，在设计模块上有什么方法？
其实纵然担任了一个学期的PM，自己本身对正规PM的具体职责还不是很清晰。在我们的团队中PM负责团队职责的分配，工程的模块划分并据此分配任务，但不涉及细化到接口设计这样的问题。我观察其它多数组内的PM也是如此。但根据构建之法中对PM职责的描述，PM似乎没有足够的能力（如安排某个大模块任务的子任务）来按照技术细节分配具体任务，顶多将整个项目大致划分为几个模块交予不同成员，或者按照项目的功能效果对任务进行划分。比如需要实现IM通讯，那么PM可能只会安排IM相关机制学习、IM雏形完成、IM功能调试与优化、由前端设计完善IM界面这几步，而不会具体到：IM广播机制完成、IM接收器实现等。不知这样对PM职责的理解是否正确。
3）在软件前期的设计阶段，需要对设计细化到什么程度？
在我们的开发过程中，正如2）中所言，我们将后台设计细化到以功能或效果为粒度的程度即可。由于开发过程充满了未知，在前期花大量时间去设计深究这些实现细节十分浪费时间。其实我们在Alpha阶段正是考虑到了实现细节，比如某些页面的设计，我们确定好功能后甚至开始确定刷新加载框架，当时决定应用最火的PullToRefresh框架，但事实证明这种前期的纸上谈兵仅仅是在浪费时间。事后的开发过程中，这一框架根本无法融合进某些界面；而与此相反，前端的设计并不存在未知的问题，因此要有具体的需求，正如我们的需求文档中强调的那样，需求文档的内容包括以下四个方面：需求功能的整体介绍、页面需要使用的控件类型、开发者预想中的页面雏形、对功能的一些限制和补充说明，前端任务的设计至少要细化到这种程度。
4） 测试员的工作和软件质量保障工作间有什么联系和区别？
测试人员的工作应属于质量保障工作的一部分。测试工作仅仅强调设计测试用例，可以直接通过测试用例点的反馈检查目标是否通过测试。而质量保障是一个复杂的系统，测试工作可以算为其的一个子集。它采用一定的技术和方法来确保产品满足某个标准。它需要将质量特征具体化量化，才能据此用合格标准进行裁定。同时质量保障工作也包括质量计划的制定，甚至质量保证之后的优化设计等等。
5） 对繁杂的用户需求，如何取舍才能保障整体利益的最大化？
对于这一点，我们解决时采用最直接的方法即根据用户需求量的大小，作为某个功能优先级的参考。除此之外，还可以根据不同的用户场景，将自己带入产品的使用环境，问自己：“什么样的功能会让用户满意？”
产生了哪些新的问题，请提出：
- PM关于项目的决定权有多大？是否组员间产生分歧应该最终由PM进行定夺？或者当成员的开发成果和PM预期不符时，但可能是PM对此了解不够产生了误判，这时候是应该按照PM的预期重新完成，还是采用成员的开发成果？
- 在成熟的公司中，前后端之间采用什么样的交互耦合模式？他们是否是：专门的前端设计师 + 前端界面代码实现人员 + 后台功能实现人员 这样的组合？
- PM在团队中不能以上下级的关系和成员相处，那么如何保证PM的话有人肯听？仅仅靠人格魅力吗？我觉得在我的团队中大家都比较熟，所以都会相互尊重照顾，但在一个陌生的职场中，PM不以上级的姿态去要求成员，成员会怎么反应呢？
同时我们还读了8篇软件工程相关的论文或博客，你回头再看看这些文章，有没有新的体会?
要说对于那八篇文章的新体会，其中体会较深的应该是敏捷开发模式。由于这学期的课业压力之大，我们必须在有限的时间内完成大量的任务，这样紧迫的条件采用敏捷开发模式是再合适不过的了。然而在Alpha阶段我们并没有采用敏捷开发模式，抓着一个方面就不放，一直想把它做得尽善尽美，这样的方式极大地降低了我们的开发效率。实现敏捷开发一个关键点即确定任务的优先级。于是在Beta阶段，我们吸取教训，对于不必要，性价比不高的功能，我们给予其较低的开发优先级。始终将主力用于必要功能的实现。那么什么样的功能才是必要不多余的呢？首先必须从用户的角度出发，按照测试场景代入，如果我们是用户，我们希望它能有什么样的功能来满足我的需求？另一方面，我们需要考虑到有限的时间和庞大的工作量，因此，通过出口条件也可以协助我们确定什么样的功能是必要的。
如果说在阿尔法阶段我们以“木桶效应”来拟喻应用的出口条件，在这一阶段，“齐头并进”才是我们所想要达到的效果。因此，任何会造成用户功能完整性不一致的地方，都是我们开发的重点。
软件工程这门学问有很多 “知识点”， 这门课强调 “做中学” - 在实践中学习知识点。
请问你们在项目的 需求/设计/实现/测试/发布/维护/阶段（一共6 个阶段）中都学到了什么 “知识点”， 每个阶段只要说明一个知识点就可以。
需求：
在分析用户需求的时候不能带入开发者本身的臆测，这也要求PM要掌握切换角色的能力，将自己实际带入到用户视角中去；同时，为了更真实地贴近用户、发掘潜在需求，调查需要深入到真实用户群体中去，调查问卷不失为传统有效的方法。
设计：
在后端设计上，PM应该注意模块设计的粒度，以功能和效果为粒度进行功能划分与模块设计，在此之后，开发人员再完成具体的接口、框架设计；在前端方面，设计人员需要细心耐心，将节目设计稿的细节面面俱到，包括边距、字体、配色方案等等；在前后端设计的耦合上，需要有详尽的需求文档，并错开两者设计的时间，以免浪费时间资源。
实现：
在实现方面PM应合理分配任务，即使某位成员能力极强，也不能让TA独自承担大多数开发工作，否则在之后遇到紧急情况，或者拓展开发的时候，其他成员完全无法接手。另一方面，作为成员在实现的时候需要保障组内的信息流通，遵从代码规范，同时始终保持一个开发模式坚持下去（如敏捷开发）。提高代码重用率，避免为了赶工而产生的临时权宜之计，使得工程中有四处扩散的大泥球。
测试：
我们的小组在开发过程中没有进行单元测试，而是进行了格外详尽的功能测试。虽然功能测试能够从高层次直接快捷地找到问题所在，但客户端本身的逻辑单元测试也是很关键的。这也是我们开发过程中做得不够的地方。
发布：
发布时需要定义好出口条件。出口条件同时也是实现过程中对软件质量的一个重要的评估方式。出口条件的设定不仅要从开发者本身的实现难度考虑，更要从用户角度出发，考虑到软件功能的完整性。
维护：
要设立必要的反馈机制，和用户活跃度统计机制。通过反馈机制我们能够收到真正用户的切实感受，软件发布后，我们的Let’s也通过反馈机制收到了许多宝贵的建议。这些建议都是后期维护的重要参考；通过活跃度统计可以实时跟进软件的使用热度，明白受欢迎的用户层是什么样的，也可以作为后期维护的参考。