照片
设想和目标
我们的软件要解决什么问题?是否定义得很清楚?是否对典型用户和典型场景有清晰的描述?
"北航"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 中的哪个档次?
我觉得团队目前的状态属于可管理级级别,有过程纪律和功能性,,团队协作比较协调,但仍缺乏严格的代码复审流程。
你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
我觉得我们团队目前处于磨合阶段。