[BUAA_SE_2017]提问回顾
提问回顾
学期初疑问回答
教材中说，PM在衡量需求时需要方方面面的能力与研究。可是，当下许多互联网IT公司只承担外包业务，即客户给什么需求就实现什么需求，甚至可能不要求其它先进的功能。此时，开发团队还需要一个全能的PM吗？
这个问题，感觉自己提的还是比较nice的。经过了一个学期的软工课程，在团队项目的两轮迭代中，我充分感觉到了PM的重要性。PM首先必须对需求非常了解，对技术有一定的掌握，这使得他可以成为团队的中枢神经。对于提出的外包业务问题，如果按部就班完成所有客户规定死的功能，或许只要求团队的技术高就好，此时PM的作用只是在于管理；更一般的情况下客户寻求软件团队都是为了占有市场、推广自己的产品，因此PM不仅仅在管理这个团队，还要为整个项目做布局。这就是一个全能PM必不可少的品质，一个团队也不能缺少这么一个神经中枢。
我们都知道，客户的需求变化是极其随机且难以预测的。软件工程要求开发团队在coding之前做足准备工作以更好地处理这些需求变动，然而计划赶不上变化快（“神秘的程序员们”一篇漫画有提到），我想知道，当下企业中遇到这种情况是选择重构（能高效实现需求，但耗时耗力）多、还是选择补丁（这么说不准确，能省时省力实现，但增加了负载，效率不高）、还是因为变动过大而放弃项目？
好像通过这个学期的课程，我并不能很深的了解到。但就我们的团队项目来说，我们经历了一次重构，原因在于原有框架和语言团队不熟悉，导致在之上进行改进难度陡增，所以我们组的PM进行了重构。事实证明，重构有一定的好处，但是并不是一劳永逸的解决方法。重构意味着从头开始重新处理所有问题，我们并不十分清楚原框架下的开发过程中遇到了哪些问题。因此，我认为，只有在实在无法容忍的情况下，再进行重构，但这之前一定要进行充分的可行性论证。
“用户需要帮助，但用户没有这么笨。”， “用户需要帮助，需要很多帮助。” 对于上述两种情况开发团队如何对其进行界定？
关键在于看软件的需求与定位明确与否。用户是软件的使用者，软件的需求分析文档中典型用户应该包括了所有软件主要针对的使用者群体。开发团队只需要从典型用户中进行分析，即可针对用户体验进行优化。而软件团队的产品经理除了与团队一同分析典型用户外，还要在开发的同时尽可能去得到一些相关反馈。软件团队对用户体验优化的重要途径在于接收真实用户的反馈与评价。
软件的设计文档是否从需求至实现进行了全部设计？软件设计文档是否规定了每一个类、每一个函数的参功能、参数、返回值，但不涉及到函数的实现？可是，实现过程中一定会出现意料之外的情况，设计可能也随之改变，请问怎样的设计文档才算作合格或优秀的设计文档？
这个问题我还真的不知道答案，希望得到老师或者助教的解答。
哲学家的宗旨是：我思，故我在；科学家的宗旨是：我发现，故我在；工程师的宗旨是：我构建，故我在。工程师在构建的过程中，是否受科学家、哲学家思想引领与指挥？灵感来源于生活，来源于一切事物，工程师除了构建，其他方面（如其它学科领域、人文、艺术、哲学等）的涉猎与接触是否对工程师的构建有帮助？
我的想法是，是有帮助作用的。工程师虽然工作时接触的都是工程领域相关的内容，但是其无论作为整体还是整体的一部分都是要应用于实际生活的。作用于实际生活的事物必然来源于实际生活。软件工程是一门艺术，他的方法论其实是将人们日常协作处理事物的方法改进、映射到软件工程领域，所以其实从本质上来看，它和其他学科、人文、艺术、哲学都是相通的。
各阶段学到的知识点
- 需求：学会了通过NABCD模型进行需求分析的方法，Need Approach Benefit Competitor Delivery
- 设计：进行系统总体架构设计时需要综合考虑需求与实现成本，进行局部实现细节设计时应综合考虑重点需求与用户体验
- 实现：实现应该在设计完成并经过多次商议通过之后再进行实现，实现（scrum）期间，实现方法与思路不能再改变。所以本质上只是一个自然语言转化为机器语言的过程，重中之重都在设计上了
- 测试：担任了两轮迭代的测试工作，首先明白了测试的基本流程，测试内容；其次，测试应该边开发边测试边反馈问题；还有就是测试工具的操作与运用
- 发布：发布前测试应该做好，根据不同情况决定是否携带bug发布。发布过程中一定要注意收集各个方面的用户反馈，如用户体验、用户更高层次的需求等
- 维护：需要使用一定的维护工具，如针对数据库要做好定期备份、服务器要检查负载情况等等
