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的改进

1. 对任务的定义和衡量有了更健全的机制
2. 预留了缓冲区

我们学到了什么? 如果历史重来一遍, 我们会做什么改进

1. 将计划做的更加细致全面一些，减少无效任务的产生，避免做没有价值的事，让开发更加有效率
2. 计划时考虑更多的外界干扰因素，综合规划

   

 

设计/实现计划

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

　　设计在M1结束后就开始进行，主题由PM江昊完成，但这次整个团队都参与讨论了计划的产生，并且在后期也通过每日例会一起不断调整。

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

      无

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

      设计：团队借用E-R图来对后端Model层设计进行建模处理，有效的推动了后端数据库的建立与后端dev对项目的认识。

      实现：M2继续借用API文档来规范前后端接口，实现前后端交互。有效的降低了前后端工作的耦合性，提升了项目效率。

继续沿用M1的单元测试

同时，M2开始用GIT管理代码，开发效率提高，发生错误的几率也降低

什么功能产生的Bug最多，为什么？

      前端 社团后台界面。

      原因：界面元素较多，并且功能较复杂，前端技术细节本就难处理，所以实现时遇到了很多BUG和困难。

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

      很遗憾，同M1一样，因为时间原因，后端虽进行了代码复审，但并没有一套严格的流程，只是后端dev之间口头交流，粗略审查。

      代码规范方面初期执行的较好，后期因为进度原因不理想。 

相对于M1的改进

1. 计划的修改通过每日例会进行，更加灵活，更多人参与
2. 用GIT管理代码
3. 更加重视前端

如果历史重来一遍, 我们会做什么改进?

1. 规划好代码复审机制，开发时严格执行
2. 测试可以应用更多的工具来提高效率，目前只是单元测试和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难免有一些繁琐与麻烦，应该寻找一些更高效的测试工具

 

补充问题：

1. 对比敏捷的原则, 你觉得你们小组相对于M1做得最好的是什么? 
   1. 处理需求变化更加及时

      M1阶段在应对各种突发状况时，显得过于被动，对项目整体需求和进展的把控也不足。而在M2中，伴随着更多的沟通交流，这一点做得更加到位。能够及时根据进度调整需求变化以及更新TFS任务

   2. 能够时时总结并提高团队效率

      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. 增强了用户场景测试。

   

1. 仍需改进的地方

I. 前端测试机制仍不完善，互相之间的沟通交流也需加强。

II.仍需更重视代码规范。前后端代码的规范并不很严格，这会对将来的进一步开发产生较大的影响。

 

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

我觉得团队目前的状态属于可管理级级别，有过程纪律和功能性，，团队协作比较协调，但仍缺乏严格的代码复审流程。

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

我觉得我们团队目前处于磨合阶段。