[敏捷软工团队博客]事后分析

项目 内容
2020春季计算机学院软件工程(罗杰 任健) 博客园班级博客
作业要求 事后分析
我们在这个课程的目标是 在团队合作中锻炼自己
这个作业在哪个具体方面帮助我们实现目标 对Alpha阶段的工作进行总结分析，为下一阶段积累经验

目录

设想和目标

  1. 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？

    我们的软件要解决的问题是：现在的软工课程的作业分布在博客园、GitHub上，没有一个集成多种功能的一体化平台，评测作业也要逐一手动评测。我们的目标和定位清楚，对典型用户和场景有清晰的描述，详见功能规格说明书。

  2. 我们达到目标了么？

    原计划的功能实现了，按照原计划时间交付了，原计划的用户数量也达到了。

  3. 和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高，具体提高了多少，如何衡量的？

    团队软件工程的质量有所提高，详见项目展示中“有些项目是在原来的基础上改进的，那么我们团队的软件工程项目质量有什么样的提高？”的部分。

  4. 用户量、用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么？

    用户量比我们预期的少一些，用户对功能的接受程度较高，好评很多。我们的工作在Alpha阶段初见成效，离目标更近了。

计划

  1. 是否有充足的时间来做计划?

    我们做计划的时间比较充足，前期对Alpha阶段有整体的计划，每天也都会在例会上讨论第二天的计划。

  2. 团队在计划阶段是如何解决同事们对于计划的不同意见的？

    我们的意见还是很统一的，有不同的意见也不会特别强烈，都通过开例会讨论得到了统一。

  3. 你原计划的工作是否最后都做完了?

    基本上都做完了。

  4. 是否每一项任务都有清楚定义和衡量的交付件?

    在修复Bug方面，我们每修复一个Bug，都会经过经办人的检查，确认修复完成。

  5. 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?

    我们在Alpha阶段的项目进度是按照计划稳步进行的，没有发生什么意外。

  6. 在计划中有没有留下缓冲区，缓冲区有作用么?

    我们在Alpha阶段的最后留了一周作为缓冲区，在这段时间里我们主要完成Alpha阶段收尾的工作，任务较为灵活，团队成员的压力有所减轻，起到了缓冲作用。

资源

  1. 我们有足够的资源来完成各项任务么?

    有。在后期项目部署到服务器上时，一开始由于服务器的性能原因受到了一些阻碍，最后也在老师的帮助下顺利解决了。

  2. 各项任务所需的时间和其他资源是如何估计的，精度如何?

    由PM进行任务拆解，精确到小时。但在实际完成任务时，大家都顾着干活，对花费时间没有过多精确的考虑统计。

  3. 测试的时间，人力和软件/硬件资源是否足够?

    开发的成员基本都参与了测试，我们对三种用户类型（root、教师、学生）都进行了测试，时间和人力较充足。但是我们的硬件资源不太足够，我们开始时预计的是三个服务器，将GitLab、平台和评测机分开部署，但实际上只有一个服务器，并且是国外的，网络延迟较大，也无法有效测试负载均衡，对评测机的压力测试也不够准确。

  4. 你有没有感到你做的事情可以让别人来做（更有效率）?

    在团队协作中，如果同一件事做了很久也没做出来，找不到头绪的话，继续做下去可能效率会越来越低。此时可以找同组的另一名同学来做，也许是当局者迷、旁观者清，可以提高解决问题的效率。

变更管理

  1. 每个相关的员工都及时知道了变更的消息?

    当计划有变动的时候，我们会在例会中通知。

  2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?

    我们决定在Alpha阶段先开发出最小可用版本。最小可用版本中的功能是必须实现的，其他功能可以推迟到Beta阶段再进行开发。

  3. 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?

    我们的出口条件分为三个方面，最主要的是功能的正确性，其次是保证权限管理和完成增量开发。详见测试报告中“Alpha版本的出口条件”一节。

  4. 对于可能的变更是否能制定应急计划?

    计划可能赶不上变化，当变化到来时，再随机应变。

  5. 员工是否能够有效地处理意料之外的工作请求？

    能。我们规定了所有请求都转到PM那里处理，这样减轻了开发人员的压力，让他们把大部分时间花在自己的事情上。我们在debug的过程中，可能会发现新的bug，这也是意料之外的工作，我们会在例会中讨论，作为新的任务发布。

设计/实现

  1. 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？

    我们的项目是继承而来的，并不是从零开始的，设计工作已经在上一个版本完成了。

  2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？

    有。原因是我们在项目初期对技术还不熟悉，我们通过进一步学习相关技术，使原来模糊的设计思路逐渐变得清晰。

  3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？

    我们运用了单元测试，编写了单元测试用例进行测试。

  4. 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?

    涉及Gitlab结构调整的部分产生的bug最多，因为学长原来的代码关联比较复杂，牵一发而动全身。在对学长原来的代码进行完善时由于前期对技术不熟，也导致产生的bug较多。

  5. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？

    • 读原来的代码，从中也发现了一些bug

    • 由写代码的同学自己检查

    • 修复bug后，由经办人进行检查，确保bug已修复

    我们使用ide自带的代码检查进行了规范。

测试/发布

  1. 团队是否有一个测试计划？为什么没有？

    我们有测试计划，并且测试的同学进行了3次对项目的全面测评。

  2. 是否进行了正式的验收测试？

    没有进行专门的验收测试，但在发布前我们也各自进行了测试，在下一阶段我们会继续完善。

  3. 团队是否有测试工具来帮助测试？

    我们使用了RubyMine的run with coverage功能和Vue test来帮助我们测试。

  4. 在发布的过程中发现了哪些意外问题？

    在把项目部署到服务器上时，在开放端口上遇到了一些问题。以及由于是国外服务器，网络状态不太稳定，有时不能访问或是访问速度较慢。

团队的角色，管理，合作

  1. 团队的每个角色是如何确定的，是不是人尽其才？

    我们团队的角色是由每个同学自愿选择的。我们确实做到了人尽其才，每个同学都有自己负责的部分，都在项目中尽力做出了自己的贡献。

  2. 团队成员之间有互相帮助么？

    有，我们团队成员之间的互相帮助很多。前期配置环境时，大家相互帮助，解决了配置时遇到的各种问题。在开发过程中，遇到问题也都会在例会的时候一起讨论，共同解决。

  3. 当出现项目管理、合作方面的问题时，团队成员如何解决问题？

    我们使用GitHub进行项目管理。为了防止两个人同时修改代码导致发生冲突，我们采取的措施是，每次有同学修改代码前都会在群里说一下，给项目加锁，等修改完再释放锁，下一位同学再开始修改。大家轮流对项目进行修改，没有发生过冲突。

每个成员明确公开地表示对成员帮助的感谢：

我感谢tq对我的帮助， 因为他帮忙构建了评测机的主要评测逻辑，同时在交流中给予我很多启发。

我感谢dzx对我的帮助，因为他在日常开发和发布前发现了很多bug，同时在发布阶段联系了很多。

我感谢tq对我的帮助， 因为我在后端代码编写中出现了一些疑惑，他热心解答了我的疑问和一些问题。

我感谢dzx对我的帮助， 因为他在配置环境时给了我很多帮助。

我感谢yjy对我的帮助， 因为他给了很多很有用的学习文档，能带领大家将项目进度稳步推进。

我感谢yjy对我的帮助，因为他分享了很多学习资料，帮助配置环境，组织项目稳步推进，在技术方面给了很多指导。

我感谢wjx对我的帮助， 因为他发现并修复了我写的bug，包容了我写代码时的手误。

我感谢wjx对我的帮助，因为他帮助我配置环境，分享技术方面的经验。

总结

你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?

  • 可重复级

你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?

  • 规范阶段

你觉得目前最需要改进的一个方面是什么?

  • 项目进展的速度

    在前期我们花了很多时间学习技术和熟悉代码，在Beta阶段需要加快开发的速度。

对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。

  • 不断交付可用的软件

    我们每次commit的版本都是可用的，每次迭代都会新增一些功能或是修复一些bug。

  • 激励团队成员的积极性

    我们团队每个成员的积极性都很高，大家都在为做出更好的项目而努力。

  • 通过面对面的交谈方式进行沟通

    我们会在每日例会上进行实时的交流，遇到问题会由一个人共享屏幕，大家共同来解答。

  • 定期反省

    我们在Alpha阶段几乎每天都会开一次例会，在例会上进行总结和反思。

正如我们前面提到的， 软件的质量 = 程序的质量 + 软件工程的质量，那团队在下一阶段应该如何提高软件工程的质量呢？

  1. 代码管理的质量具体应该如何提高？ 代码复审和代码规范的质量应该如何提高？

    我们准备维持现有的代码管理，在代码规范方面，使用代码规范工具提高规范性。

  2. 整个程序的架构如何具体提高？ 如何通过重构等方法提高质量，如何衡量质量的提高？

    在Alpha阶段，我们通过部分代码的重构，使项目的逻辑更加清晰。但在接下来的阶段，我们不打算再大幅度地重构代码。

  3. 项目管理有哪些具体的提高？

    我们准备做好commit和issue的联动，规范commit信息的命名。

  4. 项目跟踪用户数据方面，计划要提高什么地方？例如你们是如何知道每日/周活跃用户等数据的？

    在GitLab上可以直观地看到用户数据。

  5. 项目文档的质量如何提高？

    通过不断迭代提高质量。

  6. 对于软件工程的理论，规律有什么心得体会或不同意见？

    详见项目展示的“总结”一节。

团队讨论的截图：

【推广】 免费学中医，健康全家人
原文地址：https://www.cnblogs.com/the-agiles/p/12852327.html