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 中的哪一个档次?

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

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

我以为咱们团队目前处于磨合阶段。