第08组 Alpha事后诸葛亮

Posted ccxccx

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了第08组 Alpha事后诸葛亮相关的知识,希望对你有一定的参考价值。

组长博客链接(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, 或者其他工具来帮助设计和实现?这些工具有效么?

  • 答:没有。

4.比较项目开始的 UML 文档和现在的状态有什么区别?这些区别如何产生的?是否要更新 UML 文档?

  • 答:我们没有做什么UML文档。

5.什么功能产生的Bug最多,为什么?在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?

  • 答:目前都还好,注册功能吧,因为数据库定义的不够精确。发布之后还没有发现重要BUG。

6.代码复审(Code Review)是如何进行的,是否严格执行了代码规范?

  • 答:由细心的人审核,是。

7.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

  • 答:设计时还是要考虑可行性。

测试/发布(3分)

1.团队是否有一个测试计划?为什么没有?是否进行了正式的验收测试?

  • 答:有,是,正在进行中。

2.团队是否有测试工具来帮助测试?

  • 答:准备用脚本和工具去测试服务器的压力。

3.团队是如何测量并跟踪软件的效能的?从软件实际运行的结果来看,这些测试工作有用么?应该有哪些改进?

  • 答:分组测试,不断地使用,提出不同的需求想法。有用。暂无需要改进的。

4.在发布的过程中发现了哪些意外问题?

  • 答:正在进行中,暂无。

5.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

  • 答:正在进行中,暂无。

团队的角色,管理,合作(3分)

1.团队的每个角色是如何确定的,是不是人尽其才?

  • 答:由组长去询问大家的能力,然后按能力分工,大多数是人尽其才。

2.团队成员之间有互相帮助么?

  • 答:在组长在的时候,大家沟通较多,组长不在,大家也不怎呢沟通。

3.当出现项目管理、合作方面的问题时,团队成员如何解决问题?

  • 答:还是去主动找相关人去沟通,来的快一点,如果不沟通,大家都不愉快,信息不对称很烦人。

  • 每个成员明确公开地表示对成员帮助的感谢 (并且写在各自的博客里):

    我感谢李昕晖对我的帮助, 因为某个具体的事情: 因为他肯经常抽空和我讨论app的各种功能及其实现方法

4.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

  • 答:对于软件的设计和定义需要早点去做,尽量细致和清晰。

总结(3分)

1.你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?

  • 答:CMMI二级

2.你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?

  • 答:规范吧。

3.你觉得团队在这个里程碑相比前一个里程碑有什么改进?

  • 答:大家懂得了合作和沟通的重要性,在下个阶段还是要建立集体荣誉感。

4.你觉得目前最需要改进的一个方面是什么?

  • 答:大家其实对于任务还是不够积极,都得组长来安排才能进行。

对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。

  • 答:说真话,不会做就是不会做,能早点完成就能早早交,这点大家做的很不错。

博客要附上全组讨论的照片。(1分)

技术图片
技术图片

答辩总结(6分)

评估团队中每个人对本次作业的贡献比例,描述为本次作业的工作流程、组员分工、组员工作量比例(禁止一锅端平的情况,如果没有评估,全组平均后,组长得分减 50%)

姓名 贡献比例
李昕晖 15%
曾宇辉 10%
玛尔孜亚 10%
翟鑫亮 20%
张伟佳 5.25%
陈超星 10%
刘烨 5.25%
王银 5.25%
李福佳 7%
黄斌敏 5.25%
王怀骋 7%

求出本组的现场答辩得分:去除最高总分,最低总分,求平均分(保留1位小数)

  • 90.3

收集其他组对本组提出的问题,并回答(每少回答一点,该项得分扣除10%,扣完为止)

  • 第一组:无
    • 答:正好
  • 第二组:后期维护困难
    • 答:问题不清晰,我觉得还行,认真就可以做。
  • 第三组:界面可以优化一下,支付问题
    • 答:我们后续会好好优化,支付问题我们目前没办法解决,如果有官方的文件支持,我们可搞!
  • 第四组:希望对原始的产品进行优化改进
    • 答:我们后续会好好优化的
  • 第五组:希望能够继续实现功能,答辩时不要使用太多时间
    • 答:我们后续会逐渐实现所有功能,答辩我们出了错误,耽误了很长时间,十分抱歉,但是给大家带来了十分钟的休息,嘻嘻
  • 第六组:功能还有一些欠缺,可以继续加油完善,图形界面可以设置的更好。
    • 答:功能我们后续会逐渐实现的,图形界面也是我们前期没有做完。
  • 第七组:进一步完善,并修改bug
    • 答:收到,我们会继续努力的。
  • 第八组:大家都很棒,第八组最棒。
    • 答:我也觉得
  • 第九组:项目可以进一步完善。
    • 答:收到,我们会继续努力的。
  • 第十组:界面不够美观,功能还需继续完善
    • 答:收到,我们会继续努力的。

PSP与学习进度条(4分)

  • 个人PSP
PSP2.1 Personal Software Process Stages 预估耗时(分钟) 实际耗时(分钟)
Planning 计划 0 0
· Estimate · 估计这个任务需要多少时间 60 60
Development 开发 0 0
· Analysis · 需求分析 (包括学习新技术) 0 0
· Design Spec · 生成设计文档 0 0
· Design Review · 设计复审 0 0
· Coding Standard · 代码规范 (为目前的开发制定合适的规范) 0 0
· Design · 具体设计 0 0
· Coding · 具体编码 0 0
· Code Review · 代码复审 0 0
· Test · 测试(自我测试,修改代码,提交修改) 0 0
Reporting 报告 60 60
· Test Repor · 测试报告 0 0
· Size Measurement · 计算工作量 0 0
· Postmortem & Process Improvement Plan · 事后总结, 并提出过程改进计划 0 0
  • 个人学习进度条
第N周 新增代码(行) 累计代码(行) 本周学习耗时(小时) 累计学习耗时(小时) 重要成长
1 600 600 25 25 学会了用JFrame等UI,学会了用网络接口
1 0 600 6 31 学会了做思维导图,懂得了需求分析报告的规范
2 250 850 10 41 进一步熟悉python、Java与API
3 400 1250 31 72 android和数据库的使用更加熟练了
4 100 1350 5 77 学会了在云服务器上安装mysql
5 200 1550 10 87 学会使用TabLayout、ViewPager、Fragment
6 200 1750 12 99 学会了使用WebView
6 0 1750 1 100

以上是关于第08组 Alpha事后诸葛亮的主要内容,如果未能解决你的问题,请参考以下文章

第08组 Alpha事后诸葛亮

第08组 Alpha事后诸葛亮

第08组 Alpha事后诸葛亮

第08组 Alpha事后诸葛亮

第08组 Alpha事后诸葛亮

第08组 Alpha事后诸葛亮