提问回顾和个人总结

请尝试对自己曾经提出的问题进行解答，并阐明，是如何通过看书，实践，或者讨论弄清楚的。

第五章敏捷流程

"只有能自我管理的团队才能创造优秀的架构、需求和设计"

根据我的观察以及实习经验，较大的公司凭借资源丰厚，人、财、理念兼备等，在推进敏捷开发的时候较为容易，但是小的公司往往难以进行传统理念到敏捷开发的转型。

这是否就决定敏捷开发在国内推进的难度？如何调整可以让敏捷开发在国内企业普及开来？

在经历了这个学期的敏捷开发后我发现，小的团队也可以完成敏捷开发只不过是在深度和广度上与大团队有异，但是只要推行这个概念，小的团队采取敏捷开发的模式也不在话下。因此，制约国内企业敏捷开发的原因应该是其他的各方面因素，也许是团队缺乏探究新事物的创造力也许是客观条件不允许改革等等。

第八章需求分析

"在敏捷开发的项目中，团队一般不过分强调“估计”的价值，因为它就是一个“猜”字。“猜得准”不是团队的目标。

在书中，我们已经了解到惊喜需求的实现可以很大程度上提高顾客的满意度，那么一般在团队中如何平衡惊喜需求和“估计”的需求？

在实现我们公课网的过程中，我们也加入了一些惊喜需求，例如教师的主页，信箱系统等等。我们评估一个惊喜需求是否应该加入进来的标准是多方面的。一则我们要确定它能给我们的项目带来的价值，二则要考虑团队里每个人的时间安排和需求的可行性。拿教师主页举例，有了这个需求我们的网站能给用户提供更加有价值的信息。还能让教师名字可点击，极大优化了用户体验。

9.3 项目经理——PM做开发和测试之外的所有事情

扫描二维码关注公众号，回复： 6560490 查看本文章

“如果一定要说专业能力的话，PM的专业就是理解和表达，你是否理解不同人的心里，需求和言外之意？”

项目经理是连接需求和开发工作的桥梁，最好的方式应该是可以让双方都更省力，最好的方式就是项目经理不仅仅有作为客户的经验，还应该有完成项目的经验。以我的个人经历来看，只有真正做过某件事情的人才能理解和表达其中的意思。
所以，在企业中，项目经理是否应该是一个精通两样事情的全才，而不只是理解和表达？

不一定。项目经理可以具有较少的对项目代码的熟悉但是必须要对项目的工作量和难易程度有一个大致的理解，如果不行的话就可以通过和组内成员交流得出结果，然后做一个较好的分配。

第九章项目经理

项目经理在确定软件开放方案的时候遇到团队成员意见相左的情况，例如使用的架构和开发工具不尽相同，这时，PM要如何进行决策？

对于同一个项目总有一个最好的大家都能接受的方案，各持己见的人只需要都提出自己的方案试图说服对方和其他的成员自然就可以看出方案的优劣所在，最后就有了定论，其次，如果是细节上面的问题只需要让两人的分工不同即可，尽量实现低耦合，只要各部分完美完成自己的任务即可。

第十三章软件测试

在之前的软件开发中，许多同学编写脚本来进行所谓的“全覆盖测试”。我看书中甚少提及。全覆盖的这种方式在软件工程测试中到底处于什么样的地位？

全覆盖实现的难度太高，必要性也不高。在实际开发中，只需要将测试树考虑全面。通过测试样例将代码覆盖率提高。

软件工程这门学问有很多 “知识点”，这门课强调 “做中学” - 在实践中学习知识点。

请问你们在项目的需求/设计/实现/测试/发布/维护阶段（一共6 个阶段）中都学到了什么“知识点”，每个阶段只要说明一个知识点就可以。
- 项目之初的需求分析只是对整个项目的初始印象，也就是基本的功能，还不够完善。
- 设计方面要在项目最初的时候有一个基本的正确的架构，否则，尤其对我们网站项目来说，如果数据库构造不好导致实现较难，项目很可能会走上删库等不归路。
- 实现过程需要通过每日例会进行总结，从中发现问题。
- 测试在整个项目中占重要角色，除了功能的测试外，用户体验优化也是必不可少。
- 发布前需要2-3天的时间缓冲，在release了正式版本后需要做好项目的宣传。
- 维护阶段要做到灵活的随机应变处理并且总结经验。

结合自己在个人项目/结对编程/团队项目的经历，谈谈自己的理解或心得。

相比结对编程，团队项目给我的印象就是“繁”。对于这纷纷扰扰的事情，我的规矩就是“按程序办事”
转会之“繁”。如果自己能在一个组起到作用，并且有固定的可持续推进的事情，任何人都不想转会。电脑硬件的不支持，真机都无法适配，还有无法短时间胜任的测试任务让我不得不考虑转会。一是为了不拖累组内进度，二是为了能有固定的角色，工作思路更清楚。
- 程序如下：通过各组PM的协商，考虑到各组角色的缺失，老师上课也仔细询问过大家对转会之事的意见，大家在课堂上表示没有意见（在此之后如果表示有意见的人皆为唯恐天下不乱之辈，我等不耻），于是我到了新的组。
PM之“繁”。正是因为我新转会的组缺PM，我的目标就是当一个“好的”PM。现在我需要把我的工作流程透明化，让纷扰的事情烟消云散。我的PM程序大致如下：
- 每次大组会前制作思维简图，考虑即将要做的工作。如下：
- 组会上根据工作量和每个人的擅长方向分配任务，尽量保证每个人的工作都是与自己之前做的工作类型有一定的联系。
- 组会后开对每个人分配的issue。
- 写scrum meeting博客，记录燃尽图，根据任务进度适时调整。
- 允许组员在做出某些工作后自己开issue记录。
- 设置贡献分。严格根据GitHub issue上的条目，除了我开的issue，组员开的issue我会询问改进如何，是否真的做出贡献再决定是否算作贡献分的一个条目，例如，一篇技术博客就是20分都是不变的。并且我会事先在群里发布详细的贡献分表，并且声明有特殊情况可以找我询问，如下图（我没有收到任何觉得不公的反馈，有两种可能，A：我的贡献分没有问题。B：我的语气太凶神恶煞，引人害怕，不敢与我反映）。
  
  因此，贡献分只要你想，就能拿到。
- 我也要反思自己的不足之处，没有找到每一个组员进行深入交流，了解他们内心的真实想法。或许他们不找我，我也应该在转入的时候为每个人做一个工作规划的意向调查表，挖掘他们自己的潜力。不应该直接延续他们之前的角色，导致他们对自己的工作有些厌烦。但是在我看来，有一个持续稳定可推进的工作是幸福的，因为你不可能做到十全十美，你在这份工作中可以做的贡献还很多。例如测试没有覆盖率和压力测试一直是我们项目的一颗钉子，也是一个巨大的可以改进的地方。团队成员曾不止一次提出，均被否认了可行性，最后也就作罢了。这也导致在最终展示中，我们相对隔壁组出现了一个较为明显的弱势。
- 欢迎大家指正不足