提问回顾
尝试回答
代码设计规范问题：
“函数最好有单一的出口，为了达到这一目的，可以使用goto。只要有助于程序逻辑的清晰体现，什么方法都可以使用，包括goto...”
- 对于团队合作开发，程序逻辑的清晰体验对于队友来说实在是一件重要的事，与此相比使用goto语句是完全可以接受的事情。
结对编程问题：
"他们并排坐在一台电脑前，面对同一个显示器，使用同一个键盘，同一个鼠标一起工作。他们一起分析，一起设计，一起写测试样例，一起编码，一起做单元测试，一起做集成测试，一起写文档..."
- 在认为结对编程的灵魂在于两人合作完成而不是“合体”完成：相比黏糊在一起，集思广益讨论出方向，各自实现自己的部分或者完全由一方实现都是可以接受的；文档也最好是由一方编写另一方修订。
团队构成问题：
"有管理专家建议，在工作需要的人数基础再减掉一位，这才是最优的数字"
- 经历换人环节后对这句话有了一定的理解：纯粹cd；一块豆腐切掉一块你还可以叫他豆腐，一只手表你去掉一个指针你让数字去做指针的活？无意义的减人是资本家做的，不该是思想家说的。
软件需求问题：
"如果一架民用飞机上有需求，用户使用它的概率是百万分之一，你还要做这个功能么？"
- 巧得很，又是在这学期有了相似经历后产生的理解：首先百万分之一还是有出现的可能的，只要它出现了一次，我们就不再认为它是极低概率的而是必然需求，这百万分之一就是一，就去把它加入开发任务；相反的，若是始终没出现这个问题，那百万分之一就是零。（理解来自于一个被忽略的功能真的被一个用户提出了需求，而另一些被舍弃的使用率极低的某些功能果真始终无人问及。百分之一是不存在的，只有两个数字，0和1。）
PM定位问题：
“PM做开发和测试之外的所有事情”
- 确实是这么一件事。有时候测试也会做一点的。PM更像是将手上各处骨骼连接起来的筋腱，筋腱本身拿不起来任何东西，要把骨骼联系起来互相配合才能做出各种动作；另一方面骨骼之间不交流的话一根骨头能做到的事情也不太多。
各个阶段中的知识点
需求阶段：
对用户的需求进行全面的分析；先要知道用户需要的是什么，其中哪些是我们能解决的，哪些是当前阶段还不能解决的。
设计阶段：
梳理清楚结构，再自顶向下逐渐细化。合理使用图形建模的方法，绘制图表。
实现阶段：
利用Github进行源码的管理；学习和使用已有的方法或工具可以提高效率，不要重复造轮子。
测试阶段：
从代码角度看，首先要有单元测试。从App的使用角度看，还要有集成测试、压力测试、真机测试等等。
发布阶段：
齐全的文档和必要的版权信息。应用平台在意的主要是两件事：这确实是你开发、你为之负责和它是安全的、满足基本要求的。
维护阶段：
版本的推进可能伴随新问题的出现，尽量做到版本独立的情况下确定问题的所在。对于bug和反馈做到及时的响应。
心得体会
终于到了自由的部分了。
按顺序先是结对编程部分。结对编程对两个人的配合有较高的要求，这其中体现出的不只是个人的水平，对两个人在有限时间内的磨合和态度都是很大的考验。然而我和另一位都是第一次接触两个人配合一同进行开发的模式，所以节奏把握的并不是很好。因为我个人其他科目的原因在开发初期几乎没有和另一位进行沟通交流，到后期才转头过来和他讨论进度，最终结对项目的完成度也不高。虽然没有取得比较理想的成绩，但不可否认这种新的开发模式对我和这位搭档都有教育意义。
然后是重头的团队开发项目。我们有幸继承了班级博客园App的开发项目，我作为PM参与其中。在长达近四个月的时间里，我收获颇丰：
- 比如最开始调研阶段拍脑子做问卷、看用户定需求，结果实现阶段发现一些功能存在技术性问题根本无法进行，明白了需求的调研不只是单纯的问需求，还要确实地考虑需求的可行性后再进行设计和实现；
- 再比如初期设计时各个功能界面没有订制详细的样式规则，导致了后续UI样式调整时多出大量本不必要的工作；
- 测试时虽然绘制了脑图比较清晰，但是考量的范围不够广，出现了无班级、主页的用户崩溃、闪退等问题；
- 初次发布了解不深，寻找的平台对于版权和文档又有相当繁杂的要求，导致初版的发布险些变成"网盘见"...
作为一个新人PM，自己的工作完成的说不上好，但好在CnblogAndroid圆满度过了三轮迭代，最终蜕变成了一款能用也还算蛮好看的App，更惊喜的是还获得了老师、前代团队和博客园官方的认可。总的来说，团队开发还是一个新奇而有趣的经历，虽然中间也经历了诸如“强制换人”等难以吐槽的环节，但结果好即一切好，和PureMan团队一起度过的几个月一定会是我以后不断回忆和品味的日子。