组长博客链接(2分)
现代软件工程 项目Postmortem 模板(27分)
设想和目标(2分)
1.我们的软件要解决什么问题?是否定义得很清楚?是否对典型用户和典型场景有清晰的描述?
- 答: 我们软件是做一款游戏,定义的话游戏选题已经是比较明确的
2.我们达到目标了么(原计划的功能做到了几个? 按照原计划交付时间交付了么? 原计划达到的用户数量达到了么?)?
3.用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
4.有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
计划(5分)
1.是否有充足的时间来做计划?
2.团队在计划阶段是如何解决同事们对于计划的不同意见的?
- 答: 讨论,比较不同意见的可实施性,在探讨中选择较好的方案
3.你原计划的工作是否最后都做完了? 如果有没做完的,为什么?
- 答: 基本上最后都做完了,如果有没做完的,可能是因为技术不懂,时间不够
4.有没有发现你做了一些事后看来没必要或没多大价值的事?
5.是否每一项任务都有清楚定义和衡量的交付件?
6.是否项目的整个过程都按照计划进行,项目出了什么意外?有什么风险是当时没有估计到的,为什么没有估计到?
7.在计划中有没有留下缓冲区,缓冲区有作用么?
- 答: 有,缓冲区用来解决一些缺陷,也可以让大家更好的分配时间
8.将来的计划会做什么修改?(例如:缓冲区的定义,加班)
9.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
- 答:游戏开发的很多环节,如果再来一遍我们会优化一下分工
资源(3分)
1.我们有足够的资源来完成各项任务么?
2.各项任务所需的时间和其他资源是如何估计的,精度如何?
3.测试的时间,人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
- 答: 时间,人力,还是比较紧的,软件/硬件资源是足够,低估了美工设计/文案)难度
4.你有没有感到你做的事情可以让别人来做(更有效率)?
5.有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
变更管理(4分)
1.每个相关的员工都及时知道了变更的消息?
2.我们采用了什么办法决定“推迟”和“必须实现”的功能?
3.项目的出口条件(Exit Criteria – 什么叫“做好了”)有清晰的定义么?
4.对于可能的变更是否能制定应急计划?
5.员工是否能够有效地处理意料之外的工作请求?
6.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
设计/实现(4分)
1.设计工作在什么时候,由谁来完成的?是合适的时间,合适的人么?
2.设计工作有没有碰到模棱两可的情况,团队是如何解决的?
3.团队是否运用单元测试(unit test),测试驱动的开发(TDD)、UML, 或者其他工具来帮助设计和实现?这些工具有效么?
- 答: 这些其实没有,我们都是赶鸭子上架,测试很少,所以也有一些bug
4.比较项目开始的 UML 文档和现在的状态有什么区别?这些区别如何产生的?是否要更新 UML 文档?
5.什么功能产生的Bug最多,为什么?在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
- 答: 人物的交互产生的bug最多,这里也是最耗时间的
6.代码复审(Code Review)是如何进行的,是否严格执行了代码规范?
7.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
测试/发布(3分)
1.团队是否有一个测试计划?为什么没有?是否进行了正式的验收测试?
2.团队是否有测试工具来帮助测试?
3.团队是如何测量并跟踪软件的效能的?从软件实际运行的结果来看,这些测试工作有用么?应该有哪些改进?
4.在发布的过程中发现了哪些意外问题?
5.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
- 答: 测试其实是很重要的一环,我们会慢慢规范开发的
团队的角色,管理,合作(3分)
1.团队的每个角色是如何确定的,是不是人尽其才?
- 答:由组长去询问大家的能力,然后按能力分工,大多数是人尽其才。
2.团队成员之间有互相帮助么?
3.当出现项目管理、合作方面的问题时,团队成员如何解决问题?
4.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
总结(3分)
1.你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
2.你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
3.你觉得团队在这个里程碑相比前一个里程碑有什么改进?
4.你觉得目前最需要改进的一个方面是什么?
对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
- 答: 敏捷开发原则2)
敏捷流程欢迎需求的变化,并利用这种变化来提高用户的竞争优势。
行为:保持开放和学习的心态,欢迎变更。并积极应对变更或者进行创新。
结果:客户满意度增加,人员技能和学习能力提升,产品质量提高,团队灵活度增加。
敏捷开发原则3)
经常发布可用的软件,发布间隔可以从几周到几个月,能短则短。
行为:尽早并且经常发布可用软件,而不是文档。
结果:客户满意度和产品质量提高。
作者:bullion
链接:https://www.jianshu.com/p/41de92f1d869
来源:简书
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
博客要附上全组讨论的照片。(1分)
答辩总结(6分)
评估团队中每个人对本次作业的贡献比例,描述为本次作业的工作流程、组员分工、组员工作量比例(禁止一锅端平的情况,如果没有评估,全组平均后,组长得分减 50%)
卢欢 |
10% |
严喜 |
8 % |
张火标 |
12% |
池九锡 |
15% |
汪佳祥 |
8% |
古力亚尔·艾山 |
8 % |
张聪 |
7% |
杨忠燎 |
8% |
周华 |
8% |
钟璐英 |
8% |
陈天恒 |
8% |
求出本组的现场答辩得分:去除最高总分,最低总分,求平均分(保留1位小数)
收集其他组对本组提出的问题,并回答(每少回答一点,该项得分扣除10%,扣完为止)
- 提问:程序是用什么语言写的?
- 提问:这些颜色是怎么实现的?
PSP与学习进度条(4分)
Planning |
计划 |
30 |
30 |
Estimate |
估计这个任务需要多少时间 |
5 |
5 |
Development |
开发 |
150 |
240 |
Analysis |
需求分析 (包括学习新技术) |
30 |
80 |
Design Spec |
生成设计文档 |
15 |
10 |
Design Review |
设计复审 |
3 |
5 |
Coding Standard |
代码规范 (为目前的开发制定合适的规范) |
0 |
0 |
Design |
具体设计 |
10 |
15 |
Coding |
具体编码 |
240 |
265 |
Code Review |
代码复审 |
5 |
10 |
Test |
测试(自我测试,修改代码,提交修改) |
10 |
10 |
Reporting |
报告 |
0 |
0 |
Test Repor |
测试报告 |
0 |
0 |
Size Measurement |
计算工作量 |
0 |
0 |
Postmortem & Process Improvement Plan |
事后总结, 并提出过程改进计划 |
5 |
15 |
|
合计 |
503 |
685 |
1 |
0 |
0 |
10 |
10 |
加强了团队意识,学习开发工具使用 |
2 |
0 |
0 |
8 |
18 |
深入学习开发工具,并且熟悉美工 |
3 |
90 |
90 |
6 |
24 |
进行UI界面设计 |
4 |
100 |
190 |
6 |
30 |
学习到了设计怪物模型 |
5 |
500 |
690 |
10 |
40 |
学习到了设计怪物动画 |
6 |
300 |
990 |
10 |
50 |
学习到了游戏策划 |
7 |
400 |
1390 |
12 |
62 |
学习到了怪物AI设计 |
8 |
400 |
1790 |
20 |
82 |
学习到了场景建模 |
第05组 Alpha事后诸葛亮
原文:https://www.cnblogs.com/xzytxdy/p/11924924.html