软工第四次作业-提问回顾与总结

项目	内容
这个作业属于哪个课程	课程社区
这个作业的要求在哪里	作业要求
我在这个课程的目标是	实践学习现代软件工程的开发模式和流程，锻炼团队合作能力
这个作业在哪个具体方面帮助我实现目标	总结和回顾

对之前所提问题的解答

原博客地址：第一次个人作业-阅读和提问

Q1: 如何理解敏捷开发流程的Secrum方法论中，“Secrum Master不是一个官”的表述?

Secrum Master 是一个团队中平等的成员，与团队进行沟通交流，掌握团队的进展情况，对每个人的情况进行评估。具体到团队出现问题时，并不需要Secrum Master对团队进行人事调整，Secrum Master只需要如实记录即可，其它的事情并不是Secrum Master的职责。

Q2: 如何在事前确定敏捷开发项目的"可靠性要求"?

对可靠性的需求，需要在市场调研中被充分确定。明确目标群体，确定竞品软件，对可靠性的需要可以尽可能的参考竞品软件的情况。如果竞品软件可靠性较高，且市场对其可靠性问题并没有很高的忍耐度（如操作系统），则说明该软件也应该有较高的可靠性需求。如果竞品软件可靠性并不高，也可以观察目标群体，市场的反馈，观察是否有提高软件可靠性的可能。对于可靠性要求较高的产品，不应该使用敏捷开发的模式。

Q3: “开放的信息原则”中认为交流 != 文档?

关于这点，对于一些具体的设计，如代码的具体实现原因，相关算法来源说明，函数描述，我认为至少在今天确实不需要额外有一个专门的文档进行说明。可能使用注释的形式，在代码中完成说明会更为合适、便于使用，即所谓代码即文档。但对于一些抽象的，高层次的架构，代码结构，文件组织结构，甚至软件环境的配置，我认为文档还是交流中必须的。无论是考虑到团队成员的变化，社区贡献的难度，维护难度等，代码不应该为了敏捷而抛弃可维护性。

Q4: 测试是否应该严格按照SPEC?

测试中也应该对 SPEC 的合理性进行测试，制定 SPEC 的时候，并没有可用的、可测试的软件。对于编写 SPEC 的人，不可能一步到位，一次性写出合理的 SPEC。所以本身对 SPEC 的测试、迭代修改也是测试的一环。在测试环节，测试人员完全有必要考虑对 SPEC 的合理性进行测试，而不仅仅拘束于完全信任 SPEC。

Q5: 软件开发团队中的绩效评估?

使用现代的版本控制工具，可以有效的在代码层对团队的代码层实现地工作效率进行追踪评估。对于不同的工作类型，总会有相似的量化考核标准，整体而言都是可以被量化的。至于具体量化的算法以及可能的公平性问题，这就需要进行敏捷开发软件的企业 PM 等具体考虑了。

知识点

需求

需求分析阶段，尽可能多的对类似产品进行分析考量，确定产品特点，分析可行性。

设计

设计可以多参考已有的成熟设计，多交流保证对设计有充分的了解认识，也保证设计尽可能的完备。对于性能、可拓展性，虽说按照书上说不应过早考虑，实际上还是应该尽早有一些设计，不过可以完全不实现。

实现

实现阶段，进度会比较快，需要时刻保持团队同步，大家都明白代码都在发生什么变化。

测试

测试应该是大规模工程中比较困难但又不可或缺的一步，用户不会理解开发过程中的种种艰辛，用户只会用到最终交付的软件。开发者平台上的环境与用户不一定一致，有太多的可能导致开发者这边没有问题的成品在用户上会出现问题，毕竟用户的排列组合是无限的，因此充分的测试完全是必要的。

对于一个完整的 GUI 程序测试，似乎为其编写相关完备的多平台测试本身就是比较有挑战性的。但在实践之后，会认为这种复杂度应该是必须的，不然测试的速度无法满足敏捷软工的开发效率。

发布

对目标群体，有针对性的进行宣发可以取得最有效的效果。因此比较关键的问题就是如何确定目标群体，如何进行针对性的宣发。

维护

自动化对于长期的维护，非常重要，可以节约大量重复工作的时间，大大提高效率。

心得与体会

在一个学期的课程中，我体验了结对编程与敏捷软工的开发流程，也是第一次掌握了团队合作git仓库管理的技能，第一次自己尝试了cicd。整个合作的过程很愉快，认识了新的朋友，掌握了新的技能，对合作开发也有了更具体的实践认识。今后对于团队开发，也会更为的得心应手。