设想和目标
-
我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
我们的软件要解决的问题是：现在的软工课程的作业分布在博客园、GitHub上，没有一个集成多种功能的一体化平台，评测作业也要逐一手动评测。我们的目标和定位清楚，对典型用户和场景有清晰的描述，详见功能规格说明书。
-
我们达到目标了么？
我们原计划的功能基本都是实现了，按照原计划时间交付了，原计划的用户数量也达到了。
-
和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高，具体提高了多少，如何衡量的？
和Alpha阶段相比，我们在软件工程项目管理上的质量有所提高。具体体现在规范了commit的信息，做到了issue和commit的对应。
-
用户量、用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么？
用户量比我们预期的少一些，原因可能是我们的项目针对的用户是软件工程课的选课同学，受众范围比较有限，而且在这个学期我们的平台并不能实际投入到课程中使用，导致大家试用的热情不算很高。用户对功能的接受程度较高，好评很多。
有什么经验教训？如果历史重来一遍，我们会做什么改进？
我们项目的目标用户是软件工程课的选课同学，和其他的项目比起来，受众面比较小。如果能够重来一遍，我们会重新计划和考虑项目的目标用户，或许会实现一个支持多个课程的平台，使平台的可拓展性更强，在特定性和通用性之间做一个平衡。
计划
-
是否有充足的时间来做计划?
我们做计划的时间比较充足。在Beta阶段开始前，有大约一周的时间进行准备，来进行规划。在每天的例会上，我们也会对第二天的工作进行计划。
-
团队在计划阶段是如何解决同事们对于计划的不同意见的？
如果遇到不同的意见，我们会开会进行协商，避免采用少数服从多数的策略，而是尽量让大家达成一致的意见。
-
你原计划的工作是否最后都做完了? 如果有没做完的，为什么？
我们把主要的功能都做完了，对于一些边缘功能，例如团队评分、将评测系统部署在windows上等，因为时间原因，我们只好做了取舍。我们希望把项目尽可能做到完美，但在实际工作中，平衡和取舍也是很重要的。
-
是否每一项任务都有清楚定义和衡量的交付件?
是的，在每个issue发布时，我们都会对该issue对应的功能进行定义和描述。如图所示
-
是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
我们的项目基本上是按照计划稳步进行的，没有发生什么意外和没有估计到的风险。
-
在计划中有没有留下缓冲区，缓冲区有作用么?
我们在计划中没有留下缓冲区。我们采取的策略是，每个任务完成后再发布下一个任务，任务的进度由PM进行把控，采用了灵活调整的方式推进计划。
资源
-
我们有足够的资源来完成各项任务么?
有。我们的人力资源、硬软件资源都比较充足。
-
各项任务所需的时间和其他资源是如何估计的，精度如何?
由PM进行任务拆解，精确到小时。但在实际完成任务时，大家都顾着干活，对花费时间没有过多精确的考虑统计。
-
测试的时间，人力和软件/硬件资源是否足够?
都是足够的。
-
你有没有感到你做的事情可以让别人来做（更有效率）?
在Beta阶段，我们团队的每个成员独立负责一项或几项功能的开发，大家工作的重合部分较少。所以每位成员的任务自己做效率最高，每个人都是不可替代的。
有什么经验教训? 如果历史重来一遍，我们会做什么改进?
在人力资源方面，如果历史重来一遍，我们可能会更加根据每位成员的特点，分配相应的任务，使团队合作更加紧密。我们项目的学习成本较高，前期花了大量时间学习相关技术，如果历史重来一遍，我们更希望以自己比较熟悉的框架和语言入手，提高“敏捷”性。
变更管理
-
每个相关的员工都及时知道了变更的消息?
当计划有变动的时候，我们会在例会中通知到每个人。
-
我们采用了什么办法决定“推迟”和“必须实现”的功能?
我们决定在Alpha阶段先开发出最小可用版本。最小可用版本中的功能是必须实现的，其他功能可以推迟到Beta阶段再进行开发。
在Beta阶段，我们实现了更多扩展的功能，在这些功能中，我们选择先实现我们认为能够较大提升平台实用性的功能，而对于一些比较边缘的，如广播消息的邮件通知，我们决定放在最后实现，如果时间不够就做出取舍。
-
项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
详见测试报告中“Beta阶段出口条件”一节。
-
对于可能的变更是否能制定应急计划?
计划可能赶不上变化，当变化到来时，再随机应变。
-
员工是否能够有效地处理意料之外的工作请求？
能。我们规定了所有请求都转到PM那里处理，这样减轻了开发人员的压力，让他们把大部分时间花在自己的事情上。我们在debug的过程中，可能会发现新的bug，这也是意料之外的工作，我们会在例会中讨论，作为新的任务发布。
设计/实现
-
设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
我们在Beta阶段正式开始前，进行了小组讨论，初步定下了功能的设计，之后边实现边进行进一步设计，设计和实现不断迭代。
-
设计工作有没有碰到模棱两可的情况，团队是如何解决的？
没有遇到什么模棱两可的情况。
-
什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
需要与Gitlab进行交互的功能产生的bug最多，主要原因是对Gitlab的api不太熟悉，导致误用，还有一些权限上的错误。
-
代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
- 读原来的代码，从中也发现了一些bug
- 由写代码的同学自己检查
- 修复bug后，由经办人进行检查，确保bug已修复
我们使用ide自带的代码检查进行了规范。
有什么经验教训? 如果历史重来一遍，我们会做什么改进?
我们在前端出现了一些bug，是使用HAML的功能没有封装成Vue组件导致的。如果历史重来一遍，我们会将HAML和Vue进行解耦，将原来用HAML实现的功能封装成Vue组件。在后端开发时，由于继承的项目代码注释比较少，遇到了一些困难，如果历史重来一遍，我们会先熟悉Gitlab的API文档，在API方面完善注释。
测试/发布
-
团队是否有一个测试计划？为什么没有？
有测试计划。
-
是否进行了正式的验收测试？
在发布阶段，我们团队由专人进行了测试，在平台上对功能进行了测评。
-
团队是否有测试工具来帮助测试？
我们使用了RubyMine的run with coverage功能和Vue test来帮助我们测试。
-
在发布的过程中发现了哪些意外问题？
由于是国外服务器，网络状态不太稳定，有时不能访问或是访问速度较慢，会发生响应超时的问题。
有什么经验教训？如果历史重来一遍，我们会做什么改进？
我们测试功能主要是在本地进行测试，在发布阶段才部署到服务器上。如果历史重来一遍，我们会先写好部署脚本，经常部署服务器，在服务器上检验功能。
团队的角色，管理，合作
-
团队的每个角色是如何确定的，是不是人尽其才？
我们团队的角色是由每个同学自愿选择的。我们确实做到了人尽其才，每个同学都有自己负责的部分，都在项目中尽力做出了自己的贡献。
-
团队成员之间有互相帮助么？
有，我们团队成员之间的互相帮助很多。配置环境时，大家相互帮助，解决了配置时遇到的各种问题。在开发过程中，遇到问题也都会在例会的时候一起讨论，共同解决。
-
当出现项目管理、合作方面的问题时，团队成员如何解决问题？
我们使用GitHub进行项目管理。为了防止两个人同时修改代码导致发生冲突，我们采取的措施是，每次提交前给项目加锁，等修改完再释放锁。
每个成员明确公开地表示对成员帮助的感谢：
dzx 感谢 yjy 对我的帮助，他帮助我学习前端的知识，分享技术方面的经验，在项目上给予了许多指导。
dzx 感谢 wjx 对我的帮助，他帮助完成前端工作，分享经验，帮助测试。
dlf 感谢 wjx 对我的帮助，他在我的环境出现问题重新配环境时给与我很多帮助。
dlf 感谢 tq 对我的帮助，他耐心地为我解答了很多后端的问题，帮我debug。
dlf 感谢 yjy 对我的帮助，他在SCRUM MEETING上帮助我明确了很多用户需求及具体任务。
dlf 感谢 dzx 对我的帮助，他为开发的新功能做了许多测试，及时发现bug。
dlf 感谢 css 对我的帮助，她认真记录每一次SCRUM MEETING，对组员工作清楚地传达。
yjy 感谢 dzx 对我的帮助，他认真完成了自动添加用户、博客评分等很多重要的功能，并为此付出了很多时间。
yjy 感谢 tq 对我的帮助，他围绕着评测机制在beta阶段进行了很多开发，同时与他交流中也帮助我澄清了很多概念。
yjy 感谢 dlf 对我的帮助，他率先使用GitHub的issue与commit对应的功能，同时规范了commit message的格式，为beta阶段团队项目管理提供了很好的经验。
yjy 感谢 wjx 对我的帮助，他认真实现了批量创建项目的功能，进一步提高了团队项目的可用性。
yjy 感谢 my 对我的帮助，她虽然是beta阶段转会进入的，但是仍然对整个项目认真对待，付出了很多时间学习，同时即使在考期前比较忙的时候仍努力进行开发。
yjy 感谢 css 对我的帮助，她统筹了这个项目，撰写了大量的博客和会议记录，为进行开发的同学提供了很多方便。
tq 感谢 yjy 对我的帮助，他在我遇到bug时教会我许多debug的技巧和方法，使项目进度稳步推进。
tq 感谢 dzx 对我的帮助，他为小组承担了很多测试相关的工作，使负责开发的同学能够撇开后顾之忧而全力以赴。
tq 感谢 dlf 对我的帮助，他提出了完善的commit与任务的关联机制，使得项目版本的迭代更有章法。
tq 感谢 wjx 对我的帮助，他在时间紧张的考期仍然推进项目进度，完成了很多前端和后端的工作，从而使得项目的功能更加完善。
tq 感谢 css 对我的帮助，她一直以来一丝不苟的坚持着PM的职责，让团队和课程组之间形成有效的沟通，让负责测试和开发的同学工作更加纯粹。她所完成的大量工作也映照着团队一点一滴的成长。
tq 感谢 my 对我的帮助，她在中途转入后投入大量的时间精力学习项目相关的技术，并完成了团队分配的任务。
my 感谢 yjy 对我的帮助，我转会过来对新的前后端框架不太熟悉，他为我提供了学习资料让帮助我尽快上手，还花费时间帮我debug。
my 感谢 css 对我的帮助，她耐心地解答我的疑问，在她的关心之下我能尽快融入新的团队。
my 感谢 dlf 对我的帮助，他与我分享配置开发环境的经验，让我少踩了很多坑。
wjx 感谢 dzx 对我的帮助，他在前端进行钻研，解决很多困难。
wjx 感谢 dlf 对我的帮助，他与我合作解决很多功能添加和bug修复。
wjx 感谢 yjy 对我的帮助，他在前后端技术拥有深刻造诣，对我起到指导作用。
wjx 感谢 tq 对我的帮助，他富有热情，钻研技术，解答了我的问题，提供很多帮助。
总结
你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
- 可重复级
你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
- 介于规范和创造阶段之间
你觉得团队在这个里程碑相比前一个里程碑有什么改进？
- 团队成员对技术更加熟悉，代码量都有所增加，结构设计更成熟了。
对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
-
不断交付可用的软件
我们每次commit的版本都是可用的，每次迭代都会新增一些功能或是修复一些bug。
-
激励团队成员的积极性
我们团队每个成员的积极性都很高，大家都在为做出更好的项目而努力。
-
通过面对面的交谈方式进行沟通
我们会在每日例会上进行实时的交流，遇到问题会由一个人共享屏幕，大家共同来解答。
-
定期反省
我们几乎每天都会开一次例会，在例会上进行总结和反思。
正如我们前面提到的， 软件的质量 = 程序的质量 + 软件工程的质量，那团队在下一阶段应该如何提高软件工程的质量呢？
-
代码管理的质量具体应该如何提高？ 代码复审和代码规范的质量应该如何提高？
可以使用PR进行代码复审，每一个PR和issue进行对应，为每个issue设置经办人，由这个人决定是否将PR merge到主分支。
-
整个程序的架构如何具体提高？ 如何通过重构等方法提高质量，如何衡量质量的提高？
将HAML封装成Vue组件
提升Element UI的版本
更换UI框架
-
项目管理有哪些具体的提高？
我们在Beta阶段做到了commit和issue的对应，规范了commit信息的命名。
-
项目跟踪用户数据方面，计划要提高什么地方？例如你们是如何知道每日/周活跃用户等数据的？
在GitLab上可以直观地看到用户数据。
-
项目文档的质量如何提高？
可以边开发边完善文档，而不是在开发完成后再撰写文档。
-
对于软件工程的理论，规律有什么心得体会或不同意见？
正如《构建之法》中所提倡的“做中学”，只学习理论知识是不够的，要在实践中去解决真实的问题。在开发之前，我们可能对一些软件工程的理论是比较陌生的，比如单元测试，并不知道它具体有怎样的作用，但在开发过程中，我们确实发现了做好基础测试的重要性。
全组讨论的截图