【转】postmortem会议格式
原文: https://www.cnblogs.com/sevens/p/4225358.html
-------------------------------------------------------------------------------
“北航学堂”M2阶段postmortem
设想和目标
1. 我们的软件要解决什么问题?是否定义得很清楚?是否对典型用户和典型场景有清晰的描述?
这个问题我们在M1阶段的时候就已经探讨的比较明确了,就是要做Android端的北航MOOC精品课堂;典型用户就是那些渴望接触北航特色教学课程的同学。
2. 是否有充足的时间来做计划?
M1阶段结束后,我们小组召开了一个事后诸葛亮会,因为M1阶段很不成功,其中一个重要原因就是没有预留一个充分的时间来做计划,分配任务的时候也比较粗糙,导致很多出乎意料的事情出现,所以我们这次做了比较详细的计划。
3. 团队在计划阶段是如何解决同事们对于计划的不同意见的?
这次计划队员之间并没有产生什么大的分歧,因为大家对项目目标都相对清晰,有意见也是提出的关于将要做的事情的一些疑问,提出来以后大家一起讨论也就没什么问题了。
用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
计划
1. 你原计划的工作是否最后都做完了? 如果有没做完的,为什么?
原计划的工作并没有做完。完成的计划中的功能有:初始化页面的设计,注册和登录功能,记住密码,免登陆浏览课程,课程列表,登陆后的“我的课程”的实现,以及选课和课程播放功能的实现。最初计划的搜索功能和跟帖回帖功能没有实现。搜索功能本来我么已经写好前端的代码,但是服务器端并没有搜索功能的接口,维护服务器端的学姐说,因为课程并不多,所以搜索功能很多余,并没有实现,所以最后放弃了这个功能。而跟帖回帖没有实现也是因为这个原因,服务器没有借口的情况下客户端是加不上去的。
2. 有没有发现你做了一些事后看来没必要或没多大价值的事?
(1)目前来说最没有价值的事情就是想法设法去实现搜索功能,一是服务器端并没有实现这个功能,调用不了;二是因为课程不多,根本不需要。
(2)注册页面,因为手机的服务器端并没有提供页面注册的接口,只有网页端才有这个接口,所以注册的时候跳到网页端。最后我们也是把页面注册相关的部分全部砍掉,直接转到网页上进行注册。
3. 是否每一项任务都有清楚定义和衡量的交付件?
与M1相比,在任务的定义方面变得更加明确和细致,使得每一名队员都能够清楚自己的主要目标和要做的事情。在代码和相关任务交付的时候都有了一定的标准,而且这次写代码的时候DEV之间的联系更加密切,有两名队员是一直合作写代码的,所以这个问题比较容易解决。
4. 是否项目的整个过程都按照计划进行,有什么风险是当时没有估计到的,为什么没有估计到?
由于M1阶段的时候遇到的最大的麻烦就是联网,所以在M2一开始我们就给自己打了预防针,联网仍然是一个棘手的问题,但是一旦这个问题得到解决,后面的问题解决起来就好办了。事实也是如此,联网成功以后,我们赶在考期之前实现了许多必须要实现的功能,在考试间歇我们也增加了一些提高用户体验上面的功能。尽管最终我们完成了项目,但是依旧超出了预定的计划。
5. 在计划中有没有留下缓冲区,缓冲区有作用么?
M2阶段并没有什么缓冲区,因为有编译实验和数据库实验要完成,而且还得准备考试复习,再加上我们在Alpha阶段并没有实际上的项目成果,所以相当于我们不仅要弥补M1阶段的工作,还要尽可能地完成项目beta阶段的一些任务,所以任务一直比较紧张。
6. 将来的计划会做什么修改?
项目的下一步计划其实已经没有太多变化了,我们需要的基本功能都已经实现了,主要就是实现UI的美化,专注提升用户体验度。其它需要继续要实现的功能主要还是要看内容制作的丰富度了,如果没有足够吸引人的课程内容,再精致的包装和再美好的推广都是空话。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
学到了什么?
团队项目的核心不是项目,而是团队,只有团队拥有了凝聚力,每一名队员都对这个团队有感情了,才能把团队项目真正地当做是自己的事去完成,才能把团队项目做好,或许这是团队建设的重要之处吧。
第二点是,要完成一个项目,一定要脚踏实地,制定切实可行的计划,对风险进行预估,然后再按部就班地去完成相应的任务,不能走一步看一步,这样会大大地降低工作的效率,而且项目工作也缺少系统性。
第三点是,我们初步了解了怎样去做一个软件开发,这是我们每一个团队成员的第一次软件开发,所以我们走的每一步都是不断地尝试和探索,虽然中间遇到了很多困难,但是终于都走出来了,虽然软件开发得并不是很完美,但是在时间和经验限制下,能够做成这样,我们已经很满足了。要是以后再接手一个项目,也不会丈二和尚摸不着头脑了。
历史重来,做什么改进?
每一步都是我们应该经历的,没有重来这个说法,就算重来,也不应该改变任何事情,做错的事情只能在以后去修正。
资源
1. 我们有足够的资源来完成各项任务么?
资源是足够的,因为写代码不会的问题一般都会在网络编程大牛的博客中找到一些提示,而服务器最后也有学姐的帮助。资源足够只是时间不太够,我们在联网上花费的时间太多,最后UI比较简单。
2. 各项任务所需的时间和其他资源是如何估计的,精度如何?
本来预计是在12.24号初步完成项目,但是因为联网部分拖得比较久,所以推迟了一周多,到1月3号才拿出初步的版本,时间的估计还是有差距。
3. 测试的时间,人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
测试的时间很充足,我们的测试人员进行了充分的人工测试,也发现了很多bug。在百度云测试,Testin等云平台上进行了软件兼容性,软件遍历,深度性能等测试。由于我们在美工设计上并没有花太多心思,所以也就谈不上难度了。而博客确实要比预想中麻烦一些。
变更
1. 每个相关的员工都及时知道了变更的消息?
我们通过QQ讨论组等一些通讯工具,将变更及时告知给位成员。
2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?
主要标准就是学姐提供的服务器接口,如果有提供接口的话,我们会尽力去实现。并对需要上线的功能进行价值评估,优先度在前的先实现,没有太多价值的就推迟,如果时间不够了,就不实现。
3. 项目的出口条件(Exit Criteria – 什么叫“做好了”)有清晰的定义么?
有的,我们参照的是学长做出来的那个版本,我们能够把那个版本中的功能全部实现并且测试之后没有bug算是最终完成。
4. 对于可能的变更是否能制定应急计划?
其实应急计划就是把要实现的功能进行优先级的排序,按照优先级布置工作任务,没有特别的应急计划。
5. 员工是否能够有效地处理意料之外的工作请求?
这种情况并没有出现,如果有突发情况的话,我们会在scrum meeting中讨论,确定下一步的计划。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
设计/实现
1. 设计工作在什么时候,由谁来完成的?是合适的时间,合适的人么?
设计工作在M2阶段做了一个大的修改,主要由PM和技术能力最强的DEV进行设计,设计完之后拿这个方案和大家讨论修改,之后分配任务。是在M2阶段开始的时候,人员也比较合适,是对项目最了解的人。
2. 设计工作有没有碰到模棱两可的情况,团队是如何解决的?
经过M1阶段,设计者对这个项目的目标都比较清晰了,所以出现模棱两可的情况并没有。
测试/发布
1. 团队是否有一个测试计划?为什么没有?
我们首先进行的测试是我们手工的测试,自己在软件中各个部分试验找bug,之后用了百度云测试,Testin云测试平台进行了测试,不过机器得出的测试结果并不能全信,所以我们也一直在推广,推广的过程中也让用户帮忙测试。
2. 是否进行了正式的验收测试?
如果云平台的测试算是的话,我们进行过了,云测试我们一共做过4次,还是有些说服力的。
3. 团队是否有测试工具来帮助测试?
云测试平台。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
总结:
1. 你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
我认为应该还是属于第一级,我们合作共同完成了这一个项目,但是中间还是会有些问题,队员之间的配合还不到管理级的层次。
2. 你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
处于磨合到规范之间的过渡,我们并没有磨合的配合默契,只是有问题的时候知道该怎么想办法,成员之间交流也比较多。
3. 你觉得团队在这个里程碑相比前一个里程碑有什么改进?
对团队的任务更加清楚,明白自己应该做的是什么,并且对Android开发的熟悉程度有了很大的提高,实力进一步增强。对项目宏观的把握能力更强,遇到一个新的Android工程的时候不至于无处下手。
5. 你觉得目前最需要改进的一个方面是什么?
(1)、算法的优化上,我们的软件对网络的要求比较高,应该是由于我们算法的优化做得不够好,网络比较差的时候可能会出现崩溃。
(2)、UI的优化,用户体验度的提升。
(3)、功能的补足,等到服务器端完善之后,把搜索,社区评论的功能加上。
下面是我们团队在M2阶段总结会的照片: