我们的软件要解决什么问题?是否定义得很清楚?是否对典型用户和典型场景有清晰的描述?
我们达到目标了么(原计划的功能做到了几个? 按照原计划交付时间交付了么? 原计划达到的用户数量达到了么?)
和上一个阶段相比,团队软件工程的质量提高了么? 在什么地方有提高,具体提高了多少,如何衡量的?
用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
与我们的预期基本一致,我们在beta阶段发布后通过社联进行了硬性推广,截止6.17号67个社团入驻,50个社团使用过网页端进行社团信息编辑,社团自主发布16条新闻和12个活动,总数看起来不多,但也要考虑beta阶段发布之时已接近学期末,不在社团的活跃时间段内。gamma阶段提供了更好的宣传支持后也有更多社团管理人员表示愿意下学期活动时在小程序上进行宣传,还有一些社团管理人员则表示如果小程序被更多用户所了解他们会愿意更多地在小程序上发布信息,而我们用户量也在稳步上升。另一方面,学生认证功能上线后渐渐被认可,学生认证人数快速稳定上升,一般用户也表示如果有更多新鲜的社团信息他们会愿意使用我们的小程序进行了解。总体而言,用户对我们的重要功能接受程度在不断提高。
有什么经验教训? 如果历史重来一遍,我们会做什么改进?
beta阶段压力过大,考虑将部分工作挪到alpha阶段。
是否有充足的时间来做计划?
团队在计划阶段是如何解决同事们对于计划的不同意见的?
成员可以对自己的本周任务提出疑问、调整或转移,PM会解释自己这样计划本周任务的原因,若还有问题,则由成员们讨论解决,如果需要工作转移,双方协商同意后会保持同样的截止时间进行。
你原计划的工作是否最后都做完了? 如果有没做完的,为什么?
是否每一项任务都有清楚定义和衡量的交付件?
大都有清楚定义和衡量的交付件,主要是以下几类:
后端开发任务:代码、接口文档
前端开发任务:代码、开发版二维码
PM:博客按期提交、更新issue、数据整理文档等
其它调研任务:调研结果小文档,或demo代码
是否项目的整个过程都按照计划进行,项目出了什么意外?有什么风险是当时没有估计到的,为什么没有估计到?
在计划中有没有留下缓冲区,缓冲区有作用么?
有。其实成员做每日计划的时候,大都会自觉在最后1-2天写上“机动分配”。而且其实PM会把真正的ddl提前,保证及时有少量工作拖延发布时间仍在真实ddl前
我们学到了什么?
Beta
Gamma
技能上的主要提升:
1.为使用微信的服务:小程序码页面跳转和模板消息推送,我们将服务器接入了微信服务器。熟悉了微信服务接口的使用流程并在实践中积累了一些debug经验。
2.前端学会用js生成图片(海报),实现过程可谓到处是坑,相当艰辛。
3.后端实现了一个简单的定时任务系统,用于在社团活动前开始24h推送消息到用户微信。
4.需求筛选。Gamma阶段我们仍有很多可以实现的功能(之前版本功能的拓展,社联希望我们支持的功能,社团管理人员希望我们支持的功能,一般用户希望我们支持的功能),我们最终综合实现成本、收益分析、后续维护问题以及用户需求调研进行了筛选决定了gamma阶段实现的功能。锻炼了软工的需求分析能力。
5.面向当前阶段用户建立了一个答疑群,对小程序使用进行了答疑,用户反馈了很多Bug以及意见,对小程序的改善有重要作用。锻炼了与用户沟通的能力。
UI设计:这一版没有大改UI,新的UI继承上一版的风格,小程序UI整体风格逐渐统一。
文档维护和代码注释:这一版补充了一些技术博客、配置文档,保持新接口在接口文档中的更新,并在代码中加入许多重要注释,方便后续维护和增量开发。同时,前后端都对冗余代码进行了删除,有助于软件工程质量的提高。
我们有足够的资源来完成各项任务么?
基本还算足够,团队整体的时间和能力,我们收集的数据和需求等,都基本能够完成各项任务。gamma阶段成员时间相对紧张,只完成了核心的高优先级需求,建议课程组删除gamma阶段或缩短gamma阶段实际scrum时间。
各项任务所需的时间和其他资源是如何估计的,精度如何?
由每个人制定每日计划时自己估计,一般来说精度较高,遇到坑时则可能出现大幅度超过预期时间的情况。
测试的时间,人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
你有没有感到你做的事情可以让别人来做(更有效率)?
如果历史重来一遍, 我们会做什么改进?
每个相关的员工都及时知道了变更的消息?
是的,不紧急的在每日例会上通知,紧急的变更消息直接由PM私聊通知到位。
我们采用了什么办法决定“推迟”和“必须实现”的功能?
PM根据对项目进度的整体把握、需求优先级、需求实现难度等做出权衡和判断,然后在例会上大家可以对此提出质疑。
项目的出口条件(Exit Criteria – 什么叫“做好了”)有清晰的定义么?
对于可能的变更是否能制定应急计划?
是的。对于很重要的变更,我们还会制定plan A 和 plan B.
员工是否能够有效地处理意料之外的工作请求?
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
回过头看,在变更响应上我们已经做得很好了,面对变化的需求开发人员能提出自己的观点并积极对接。非要说改进的话,大概就是一开始把需求写的更更更确切一点,调研地更清楚,优先级更明确,从而变更可以更少些。
设计工作在什么时候,由谁来完成的?是合适的时间,合适的人么?
设计工作有没有碰到模棱两可的情况,团队是如何解决的?
有遇到小细节上的模棱两可,但这些可以暂不理会,毕竟现实和计划是有差别的,计划时更多的是考虑全局的东西,特别细节的东西不需要过于纠结,模棱两可即可。
gamma阶段有大量需求选择,我们在任务设计上进行了详细的讨论和调研进行需求筛选。
团队是否运用单元测试(unit test),测试驱动的开发(TDD)、UML, 或者其他工具来帮助设计和实现?这些工具有效么? 比较项目开始的 UML 文档和现在的状态有什么区别?这些区别如何产生的?是否要更新 UML 文档?
什么功能产生的Bug最多,为什么?在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
代码复审(Code Review)是如何进行的,是否严格执行了代码规范?
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
团队是否有一个测试计划?为什么没有?
有。
是否进行了正式的验收测试?
是的,在beta和gamma阶段的最后4天,我们进行了正式的、全面的验收测试。分为前后端,前端测试直接由PM完成,后端单元测试由该单元的编写者负责测试,后端覆盖率测试由振亚完成,后端压力测试由廓然完成,分工合理,完成度较好。
团队是否有测试工具来帮助测试?
是的。后端代码覆盖率测试使用了插件;小程序自带性能测试指标工具。
团队是如何测量并跟踪软件的效能的?从软件实际运行的结果来看,这些测试工作有用么?应该有哪些改进?
在发布的过程中发现了哪些意外问题?
发布非常顺利,alpha阶段1天过审时我们感慨微信的工作效率,beta阶段和gamma阶段竟然半天就能过审,微信的审核效率之高令人震惊。
我们学到了什么? 如果重来一遍, 我们会做什么改进?
如果重来一遍,我们会把测试做得更充分、更细致,这就需要我们提前完成开发任务,给测试留下更多的时间。
团队的每个角色是如何确定的,是不是人尽其才?
主要是根据成员的意愿,同时会考虑团队的需求,来确定每个人的角色。有些人是想做自己擅长的,这些人是“人尽其才”,有些人想挑战没有经验的角色,我们也尊重他的意愿。beta阶段我们没有进行角色轮换,主要原因是工作量较大。gamma阶段4个成员更换了角色,体验不一样的工作,也都快速学习后努力完成了开发任务。
团队成员之间有互相帮助么?
有的。主要是 后端内部、前端内部之间互相帮助,比如遇到问难时请教经验比较丰富的成员,或者觉得任务难度较大,请求进行协助,
当出现项目管理、合作方面的问题时,团队成员如何解决问题?
小问题可以线上聊天解决,比较重要的问题一般会提上会议议程,在每日例会中讨论解决。
你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
CMMI的第二级,即管理级。我们的项目在实施时能够遵守既定的计划与流程“在管理级水平上,企业在项目实施上能够遵守既定的计划与流程,有资源准备,权责到人,对相关的项目实施人员有相应的培训,对整个流程有监测与控制,并与上级单位对项目与流程进行审查”。
你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
alpha阶段出于磨合阶段后半期。beta阶段和gamma阶段已经充分熟悉队友,能以较高的效率合作,属于规范阶段,可能离创造阶段还有些距离,毕竟做的功能都算不上很新颖。
你觉得目前最需要改进的一个方面是什么?
在接口设计和复审确认阶段,需要留更多的时间,由前后端和PM三方人员参与,以减少后续更改接口的数量。
这里是敏捷开发的12条原则,其中我们做得最好的是:
时间:2019年6月18日 22:30-23:00
原文:https://www.cnblogs.com/buaareadsun/p/11089651.html