码迷,mamicode.com
首页 > 其他好文 > 详细

alpha事后诸葛亮

时间:2017-11-20 01:07:53      阅读:144      评论:0      收藏:0      [点我收藏+]

标签:可重复   img   unit test   有用   指点   为什么   es2017   有一个   设计   

设想和目标

1.我们的软件要解决什么问题?是否定义得很清楚?是否对典型用户和典型场景有清晰的描述?
我们的软件能使用户自动获取自己在各支付平台的账单信息,还能手动添加账单信息,并将二者进行总结,得到用户某段时间内的收支情况。定义得很清楚,我们的典型用户是依赖电子支付的年轻人群体,场景是用户使用电子支付的情况。
2.我们达到目标了么?
我们没能达到目标,我们只完成了简单的UI设计,我们的自动获取账单功能由于在非开发问题上耗费了不少精力,未能完成,我们的手动添加账单功能由于前后端对接出现了问题,未能通过测试。
3.用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
由于没有进行宣传,用户量为0,与我们事先预想的一致。我们所保留的功能都是最为核心的重要功能,缺一不可。我们离目标稍微近了一点。
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
在alpha版本我们应该集中精力完成一个拥有基本功能的可用的版本,而不是将精力分散到太多方面,如果历史重来一遍,我们会优先完成手动输入账单的功能并制作更好的UI。

计划

1.是否有充足的时间来做计划?
有。
2.团队在计划阶段是如何解决同事们对于计划的不同意见的?
队内讨论解决。
3.你原计划的工作是否最后都做完了? 如果有没做完的,为什么?
没有都做完,没有做完的有三个原因:
(1).低估了申请到自动获取账单所需各种权限的难度,相关权限的申请涉及到很多商业方面的问题,需要网上备案,还需联系工商局,申请的描述也要注意许多用词,申请提交后也需要时间审批。
(2).在alpha冲刺前制定计划时,选择了完成难度较大的自动获取功能,结果由于能力原因未能按计划完成自动获取功能。
(3).冲刺过程中危机感不足,未能发挥团队的最大潜力。
4.是否每一项任务都有清楚定义和衡量的交付件?
是的,由于项目功能数量并不多,因此能对各项任务进行清楚的定义。
5.是否项目的整个过程都按照计划进行,项目出了什么意外?
基本按照计划进行,项目最后的前后端对接出了一些问题。
6.在计划中有没有留下缓冲区,缓冲区有作用么?
计划中没有考虑到。
7.将来的计划会做什么修改?
更加细分各个任务阶段,避免最后汇总时出了问题难以排查。

资源

1.我们有足够的资源来完成各项任务么?
小组的总体编程能力在开发中遇到了不小的考验,但现阶段的任务勉强可以完成。
3.各项任务所需的时间和其他资源是如何估计的?
由任务的难度估计,因为小组全体成员都没有经验。
3.测试的时间,人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
不是很够,这也是小组未能及时完成alpha版本的重要原因之一。
我们低估了申请到自动获取账单所需各种权限的难度,相关权限的申请涉及到很多商业方面的问题,需要网上备案,还需联系工商局,申请的描述也要注意许多用词,申请提交后也需要时间审批。
我们低估了美工设计的难度,美工设计被证明并非我们的强项,遭到了大批同学的吐槽。

变更管理

1.每个相关的员工都及时知道了变更的消息?
是的,我们的四人小组在应对变更时通知相当及时。
2.我们采用了什么办法决定“推迟”和“必须实现”的功能?
组内讨论。
3.项目的出口条件(Exit Criteria – 什么叫“做好了”)有清晰的定义么?
没有定义。
4.对于可能的变更是否能制定应急计划?
这方面没有做好
5.员工是否能够有效地处理意料之外的工作请求?
在这方面我们经验不足,反应较慢。

设计/实现

1.设计工作在什么时候,由谁来完成的?是合适的时间,合适的人么?
在alpha开发之前就做好了,由小组成员共同讨论要完成的内容。是合适的时间与人。
2.设计工作有没有碰到模棱两可的情况,团队是如何解决的?
UI界面的设计上出现了一些不同意见,通过组内投票表决+组外人评价解决。
3.团队是否运用单元测试(unit test),测试驱动的开发(TDD)、UML, 或者其他工具来帮助设计和实现?这些工具有效么?
没做过。
4.代码复审(Code Review)是如何进行的,是否严格执行了代码规范?
通过平时的自我审查以及任务汇总前的组内复审,严格执行了代码规范。

测试/发布

1.团队是否有一个测试计划?为什么没有?
在发布前有一个测试计划。
2.是否进行了正式的验收测试?
没有。
3.团队是否有测试工具来帮助测试?
没有,基本功能的测试比较容易实现。
4.团队是如何测量并跟踪软件的效能的?从软件实际运行的结果来看,这些测试工作有用么?应该有哪些改进?
由于基本功能未能通过测试,因此没做效能测试。
5.在发布的过程中发现了哪些意外问题?
github有段时间登不上。

团队的角色,管理,合作

1.团队的每个角色是如何确定的,是不是人尽其才?
林晗(组长):负责文案,文档编写,美工。
林松雄:负责主要前端。
黄显东:负责主要后端。
陈基智:负责部分前端与后端。
各司其职,碍于团队成员个人能力问题,可能并没有做到人尽其才。
2.团队成员之间有互相帮助么?
团队成员之间经常互相帮助。
3.当出现项目管理、合作方面的问题时,团队成员如何解决问题?
组内讨论解决。

总结:

1.你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
第二个档次,可重复级。
1.对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
我觉得我们在alpha阶段做的很不好。
2.你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
磨合阶段。
3.你觉得团队在这个里程碑相比前一个里程碑有什么改进?
有了一点实质性的代码开发,并非一直把项目停留在口头。
4.你觉得目前最需要改进的一个方面是什么?
我们需要快速地将新学习到的东西投入到实际开发当中。
5.感谢
感谢团队给与我的帮助,在代码能力这块我实在有些欠缺,感觉组员给我技术上的指点

技术分享图片

alpha事后诸葛亮

标签:可重复   img   unit test   有用   指点   为什么   es2017   有一个   设计   

原文地址:http://www.cnblogs.com/chenji123/p/7862966.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!