M2事后总结
照片
设想和目标
我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
"北航"Clubs旨在于解决北航校内社团管理与学生参与社团活动的困难的问题，通过构建一个校内社团发布活动or资讯的平台，使学生可以通过网站获取社团活动信息，使社团可以通过后台管理活动，群发通知。
典型用户和典型场景在之前的Alpha阶段产品功能说明书以及Beta阶段开发目标中有说明；但典型场景的分析在beta阶段做的不太详细。
是否有充足的时间做计划？
有，在M1之前就已经完成了很大一部分的项目产品设计、项目计划与项目设计。而因为种种因素，M1未能实现当时的全部计划，所以有很多留在M2继续完成。而在M2开始之前，PM也已经根据实际进度、时间以及最新的需求做好了规划。
团队在计划阶段如何解决同事们对不同计划的不同意见？
与M1计划阶段不同，随着项目的深入，成员们对项目需求的了解也不断加深，逐渐有了自己的对项目规划的看法。所以在M2的设计中，PM与成员间的沟通讨论更加多，很多计划都是共同制定出来的。
相对于M1的改进
M1的设想和目标有些太过笼统，而且忽视了时间因素；
M2中的设想目标更加切合实际，也更加灵活
如果历史重来一遍, 我们会做什么改进
对新阶段的典型场景重新进行细致分析
计划
1. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
用户以及社团的修改头像、修改密码这两项功能未实现。
未完成主要是因为开发时间过于紧张，外加这两项功能并不是核心需求，所以就选择了舍弃。
2. 有没有发现你做了一些事后看来没必要或没多大价值的事?
有。
后端：一开始计划用leancloud实现消息实时推送，所以初期花费了大量时间学习，还发布了一些文档。但中期经过商讨消息实时推送难度太大，同时不太适合PC端且完全可以由更简单的刷新界面操作代替，所以初期的学习leanclound显得十分多余、占用时间。
前端：初期学习的react vue.js到开发阶段也并未用到，但占用了时间成本
3. 是否每一项任务都有清楚定义和衡量的交付件?
定义：所有任务都以TFS任务的形式规范。所有人都是根据实际进度情况实时创建任务、更改任务状态，以便让TFS任务直观真实体现当前成员工作量与进度
衡量：要求每天在进行汇报时要有签入记录作为衡量当日工作量的依据，签入记录可以是代码签入或者文档签入
4. 是否项目的整个过程都按照计划进行，有什么风险是当时没有估计到的，为什么没有估计到?
前期较为顺利，后期则偏离计划较多。主要原因就是后期其他课程（数学建模、编译、数据库理论考试+实验课设）对软工开发时间的巨大挤压。其实一开始是考虑到这些风险的，但对风险的影响显然是估计不足的。在其他课程的冲击下，有一段时间，软工开发几乎处于停滞状态。
5. 在计划中有没有留下缓冲区，缓冲区有作用么?
因为预料到后期其他课程会占用大量时间，M2计划阶段预留了缓冲区。虽然仍然没能避免一些熬夜冲刺，但对整体项目的最终顺利完成还是有一些作用的。
相对于M1的改进
- 对任务的定义和衡量有了更健全的机制
- 预留了缓冲区
我们学到了什么? 如果历史重来一遍, 我们会做什么改进
- 将计划做的更加细致全面一些，减少无效任务的产生，避免做没有价值的事，让开发更加有效率
- 计划时考虑更多的外界干扰因素，综合规划
设计/实现计划
设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
设计在M1结束后就开始进行，主题由PM江昊完成，但这次整个团队都参与讨论了计划的产生，并且在后期也通过每日例会一起不断调整。
设计工作有没有碰到模棱两可的情况，团队是如何解决的？
无
团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？
设计：团队借用E-R图来对后端Model层设计进行建模处理，有效的推动了后端数据库的建立与后端dev对项目的认识。
实现：M2继续借用API文档来规范前后端接口，实现前后端交互。有效的降低了前后端工作的耦合性，提升了项目效率。
继续沿用M1的单元测试
同时，M2开始用GIT管理代码，开发效率提高，发生错误的几率也降低
什么功能产生的Bug最多，为什么？
前端 社团后台界面。
原因：界面元素较多，并且功能较复杂，前端技术细节本就难处理，所以实现时遇到了很多BUG和困难。
代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
很遗憾，同M1一样，因为时间原因，后端虽进行了代码复审，但并没有一套严格的流程，只是后端dev之间口头交流，粗略审查。
代码规范方面初期执行的较好，后期因为进度原因不理想。
相对于M1的改进
- 计划的修改通过每日例会进行，更加灵活，更多人参与
- 用GIT管理代码
- 更加重视前端
如果历史重来一遍, 我们会做什么改进?
- 规划好代码复审机制，开发时严格执行
- 测试可以应用更多的工具来提高效率，目前只是单元测试和fiddler
资源
我们有足够的资源来完成各项任务么？
M2最稀缺的就是时间资源，严重不足。 而其他资源则较为充足，而且比较M1来说，学习应用GIT提供的管理资源对我们的项目有很大的帮助。
各项任务所需的时间和其他资源是如何估计的，精度如何？
同M1一样做的不够理想，估计时间主要是通过PM来估计的，由于PM对一些技术细节以及外界因素了解得并不多，因此精度比较低。
用户测试的时间，人力和软件/硬件资源是否足够？
前端没有做专门测试，而后端花去了约三分之一的时间进行测试，人力、软件、硬件资源都足够。
你有没有感到你做的事情让别人来做更有效率？
我们的分工比较明确，大家完成得都较好，不适宜更换任务。
相对于M1的改进
GIT的介入提升了效率
如果历史重来一遍, 我们会做什么改进?
1. 重视时间的估计，考虑多重因素的影响，综合规划整个项目。时间会影响到成败。
2. 每周的开会更细致一点，对可能发生的意外情况提前进行预估。
变更管理
每个相关的员工都及时知道了变更的消息?
有了GIT，代码的更新可以直观的看到，能够及时知道变更的消息。
我们采用了什么办法决定"推迟"和"必须实现"的功能?
同M1一样，主要通过每日例会以及平时开发过程中成员与PM之间的面对面交流来决定。会根据我们项目的具体情况，选择处于当前核心需求的功能来进行实现；而对于那些无关紧要或者实现难度过于大的功能会考虑予以舍弃。
项目的出口条件（Exit Criteria – 什么叫"做好了"）有清晰的定义么?
我们本阶段的目标就是实现web端的社团综合管理平台，所以"做好了"的直接效果就是网页上各个功能以及排版都能够实现其应有的功能，这也是比较好测试的。页面整合后，能够通过各项的测试，这样就算是"做好了"。
对于可能的变更是否能制定应急计划?
应急计划就是面对时间紧缺的情况，回选择削减一些非核心需求的功能来紧急应对。
员工是否能够有效地处理意料之外的工作请求？
有了M1的经验，M2每次出现意料之外的工作请求时，pm都会和dev商讨提出可行的解决方案。而且从结果来看，意料之外的工作的处理的情况还是不错的。
相对于M1的改进
GIT的介入避免了只能通过QQ传递代码的麻烦，而且可以处理代码版本冲突、版本变更等带来的代码管理风险
测试/发布
团队是否有一个测试计划？为什么没有？
同M1相同
团队有明确的测试计划。后端的测试主要是编写单元测试，功能测试和压力测试。
前端的测试主要是场景测试和在不同浏览器及不同环境下的测试。
是否进行了正式的验收测试？
后端测试完成了单元测试和功能测试模块，也实施了压力测试。
前端测试计划均已完成，并进行了验收。
团队是否有测试工具来帮助测试？
后端进行测试主要使用rails自带的单元测试模块，来编写单元测试和功能测试。
利用Fiddler4这一工具，来测试相应的API逻辑，对传入的请求和返回的响应进行检查。
团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
效能测试之前我们并没有考虑，主要因为时间有限，所以只做了一些基础性的测试。向效能测试和负载测试会在Beta阶段进行，对于效能方面， 我们团队计划通过增加服务器的数量，将逻辑计算和数据交互分开进行，进而提高服务器的响应效能。对于负载方面，我们团队打算将数据库改用MySql实现，并且将后端rails框架改进为可以并行访问。
在发布的过程中发生了哪些意外问题？
无
相对于M1的改进
1. 后端执行了压力测试
2. 增强用户场景测试
如果历史重来一遍, 我们会做什么改进?
Fiddler难免有一些繁琐与麻烦，应该寻找一些更高效的测试工具
补充问题：
- 对比敏捷的原则, 你觉得你们小组相对于M1做得最好的是什么?
- 处理需求变化更加及时
M1阶段在应对各种突发状况时，显得过于被动，对项目整体需求和进展的把控也不足。而在M2中，伴随着更多的沟通交流，这一点做得更加到位。能够及时根据进度调整需求变化以及更新TFS任务
- 能够时时总结并提高团队效率
M2初期关于scrum meeting做的是不够好的，写得太过简略，而且标准控制的也不严格。中期通过一次例会，一位同学提到了这点，并提出了自己的意见，经过讨论被大家接受。之后迅速更改了scrum meeting发布模式，后几篇的博客质量明显上升。这就是一个能够时时总结并提高团队效率的例子。
而在M1中做的比较好的几点也保持了下来。
I.保持简明——尽可能简化工作量的技艺——极为重要
通过API文档，将项目任务细化为前端与后端。
后端采用rails框架，自带MVC结构，后端三人分别去做Model层，Controller以及Router。
前端采用界面也JS代码分离开发的方式，将任务分为UI设计界面实现，界面动态化展示。
通过以上的开发模式，虽然大家是各自编码，但是各个部分之间的耦合度非常低，整合起来比较简单明了。每个人只需要专注于自己的技术领域，学习成本降低，开发效率提升。
II. 无论团队内外，面对面的交流始终是最有效的沟通方式
我们每周都有小组会议。每周例会主要议题有两个，第一个是该周目标与任务安排，第二个是介绍采用的新的技术方案or开发工具、开发方式。第一个议题，使每个队员明确自己的任务，任务明确，是一个开发人员进行开发的最大动力。第二个议题，使队员知道接下来将如何和队友合作，如何什么样的技术实现将要开发的功能。
比如，我们在讨论用户状态控制时，涉及到后端的Token存储、API调用、前端sessionStorage存储以及header传递身份信息的验证方式，将整个技术流程介绍完毕，前后端队员就理解如何更好的和对方配合了。
III. 以有进取心的人为项目核心，充分信任他们
我们团队有明确的前端负责人和后端负责人。平时遇到一些问题，PM直接和负责人沟通，负责人再和自己组内人员分工讨论。PM充分信任负责人。把任务交给他们十分方向。这样PM才有更多的时间和精力宏观规划，整体把握。如果PM总是担心任务完成情况和质量，或者总是追着每个人催促进度，那么就没有充足的精力规划项目，项目质量就会下降。
2. 总体相对于 M1 改进的地方
I.TFS任务的规范化。TFS任务采用实时创建、更新的策略，严格按照真实进度来进行，能够更好的进行敏捷开发。
II.UI得到了部分美化。
III.使用了GIT作为代码管理工具，大大提高了代码管理效率。解决了诸如代码共享、代码版本更新、代码版本冲突等潜在问题。M2中几乎没遇到代码版本带来的麻烦。
IV. 后端执行了压力测试。
V. 增强了用户场景测试。
- 仍需改进的地方
I. 前端测试机制仍不完善，互相之间的沟通交流也需加强。
II.仍需更重视代码规范。前后端代码的规范并不很严格，这会对将来的进一步开发产生较大的影响。
- 你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
我觉得团队目前的状态属于可管理级级别，有过程纪律和功能性，，团队协作比较协调，但仍缺乏严格的代码复审流程。
你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
我觉得我们团队目前处于磨合阶段。
