白给团队e-shop项目Postmortem结果

整理:政B

设想和目标

1.我们的软件要解决什么问题?是否定义得很清楚?

  答:主要是为商户和消费者提供一个网上交易商品的平台,定义明确。

2.我们达到目标了么?

  答:成功按期完成目标,原计划的功能基本实验,交付的时间与预期计划一致。

3.和上一个阶段相比,团队软件工程的质量提高了么?

  答:与上一个阶段相比,团队软件工程的质量大大提高。特别是在团队合作方面,团队成员进行头脑风暴,讨论出解决问题的方法,然后每个团队成员分工合作,各自负责完成自己的任务,为团队软件工程作出贡献。

4.用户量,用户对重要功能的接受程度和我们事先的预想一致么?有什么经验教训?如果历史重来一遍,我们会做什么改进?

  答:由于软件未进行线上发布,所以暂时未得到用户量。不过,通过个人与团队测试,从用户的角度出发,用户对重要功能的接受程度与我们事先预想的一致,基本上能满足大众用户对网上购物的需求。如果历史重演,我们会对网上购物这个需求进行详细调查,找出用户在现代网上购物的不便之处,避免在软件工程中出现。

计划

1.是否有充足的时间来做计划?

  答:充足的时间是有的,就是在计划方面出现了一些纰漏,导致后期工作量过多。

2.团队在计划阶段是如何解决同事们对于计划的不同意见的?

  答:当团队成员出现意见分歧的时候,我们会采用投票的方式来解决。

3.你原计划的工作是否最后都做完了?

  答:原计划中的工作都已经完成,除了还没有出现的BUG。

4.有没有发现你做了一些事后看来没必要或没多大价值的事?

  答:在确定工程项目的时候花费了相对多的时间,不过这也是挺有价值的,至少能够在思考过问题以后再选择题目。

5.是否每一项任务都有清楚定义和衡量的交付件?

  答:任务定义都不是特别清楚,都是通过模块来进行分配任务,而不是通过实现某个具体功能来定义任务。

6.是否项目的整个过程都按照计划进行,项目出了什么意外?

  答:项目的整个过程都是按计划进行的,没有出现意外。

7.在计划中有没有留下缓冲区,缓冲区有作用么?

  答:计划中并没有留下缓冲区,所以导致后期工作量加大,缓冲区的作用是用来防止出现特殊情况需要加长工程时间所设立的。

8.将来的计划会做什么修改?

  答:将来的计划会对软件进行优化改进,使工程更加完善。

资源

1.我们有足够的资源来完成各项任务么?

  答:资源来说是足够的,因为这个工程的难度不大,网上的资源已经足够完成任务。

2.各项任务所需的时间和其他资源是如何估计的,精度如何?

  答:各项任务的时间都是以最大时间来估计的,通过时间界限来约束并完成任务,任务的精度不够仔细,都是粗略地以模块来进行划分,这个是以后需要改进的。

3.测试的时间,人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?

  答:硬件和软件资源是足够的,但是人力与时间受到学科作业的影响,可能时间不太够,这是以后我们需要进行调节的。对于美工设计方面,由于此次团队项目并没有大规模地应用美工,只是粗略地设计界面,所以还没有认识到美工方面的难度。

4.你有没有感到你做的事情可以让别人来做(更有效率)?有什么经验教训?如果历史重来一遍,我们会做什么改进?

  答:A:个人认为如果复审阶段能多个人一起进行复审将会更好,因为不同的人有不同的看法,集思广益才是最好的评价。

变更管理

1.每个相关的员工都及时知道了变更的消息?

  答:每个相关成员都能及时了解自身的任务和代码的变更

2.我们采用了什么办法决定“推迟”和“必须实现”的功能?

  答:我们根据功能的重要性和实现难度来决定“推迟”和“必须实现”的功能,重要性越高的将会归入“必须实现”,如果功能实现难度并且重要性不高的情况下我们将会归入“推迟”。

3.项目的出口条件(Exit Criteria – 什么叫“做好了”)有清晰的定义么?

  答:项目的出口条件:①实现该项目应有的必须的功能 ②没有明显的BUG ③用户体验感受较高

4.对于可能的变更是否能制定应急计划?

  答:虽然项目进行时并没有需要制定应急计划的时候,但是我们相信,当出现变更时我们能够制定应急计划。

5.员工是否能够有效地处理意料之外的工作请求?

  答:能够有效地处理,因为我们都愿意为这个项目付出自己的努力,做到“有求必应”。

设计/实现

1.设计工作在什么时候,由谁来完成的?是合适的时间,合适的人么?

  答:设计工作在决定项目主题时,由全队成员讨论决定完成的。这是一个合适的时间,也是合适的人,毕竟大家都要参与项目的开发。

2.设计工作有没有碰到模棱两可的情况,团队是如何解决的?

  答:在数据库表的设计上出现模棱两可的情况,对属性的定义不够明确,最后选择现实生活中已经存在的软件进行参照。

3.团队是否运用单元测试(unit test),测试驱动的开发(TDD)、UML, 或者其他工具来帮助设计和实现?这些工具有效么?

  答:团队多数使用都是开发工具,都是在开发的情况下进行测试,并没有使用专门的工具进行测试,所以上述工具将会在下一次开发时进行使用。

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

  答:暂时没有发现存在的BUG(发现的已经修复),在开发和设计时并没有发现BUG的存在,这是因为在这两个阶段还没有对软件进行运行测试。

5.代码复审(Code Review)是如何进行的,是否严格执行了代码规范? 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

  答:代码复审,首先是检查代码规范化,其次检查代码是否能够化简(在不改变功能的情况)。如果重来一遍,将会更注重代码的规范化,让代码更加清晰,使后面的测试和寻找BUG工作更加简易。

测试/发布

1.团队是否有一个测试计划?为什么没有?

  答:团队有测试计划,只是计划并不够正式和完善。

2.是否进行了正式的验收测试?

  答:并没有进行正式的验收,只是简单地模拟了一下用户体验进行测试。

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

  答:没有使用测试工具来进行测试,这是以后应该学习的。

4.在发布的过程中发现了哪些意外问题?我们学到了什么?如果重来一遍,我们会做什么改进?

  答:由于考虑到软件的可用性与实际性,并没有将软件进行线上发布,目前和处于线下使用测试阶段。如果重来一次,我们会重新选一个题材进行开发,考虑其实用性,这样才能在现实生活中使用。

总结

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

  答:团队目前的状态处于CMMI二级档次。

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

  答:我觉得团队目前处于磨合阶段,磨合度还不高,需要更长的时间来进行合作。

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

  答:里程碑就是从个人项目转变成团队项目,了解团队项目的流程与步骤。

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

  答:我们觉得最需要改进的一个方面就是任务的分配,我们应当将每个人的任务具体化,具体到每一个细致功能。

5.对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则?

  答:至于敏捷开发的原则,我们小组做得最好的是能够做到尽早并持续的交付有价值的软件成品,以满足用户的需求。

全组讨论的照片:

团队成员在Alpha阶段的角色和具体贡献:

名字

角色

团队贡献分

可验证的贡献

卢耀恒

Dev、Test

23

队长+负责多数以及关键代码编写+课堂演讲

莫政

Test、PM

22

队长+博客编写+计划任务安排+代码+课堂演讲

高嘉淳

Dev

18

代码编写

覃泽泰

Dev

17

代码编写

梁小燕

Dev

19

代码编写

许梓莹

Dev、Test

21

前端大多数代码编写和交互

团队作业6(B)-事后诸葛亮分析的更多相关文章

  1. 团队作业(NABC的分析)

    我们的团队课题是游戏:躲避小球. 我认为它其中的一个优点是:丰富用户的短暂闲暇时间,使用户得到身心的放松 下面我将从N,A,B,C四个方面简述理由 N(需求):现代社会逐渐步入快节奏时代,大众生活压力 ...

  2. 【集美大学1411_助教博客】团队作业10——项目复审与事后分析(Beta版本)

    写在前面的话 软件工程课结束了,大家开心吗?是不是再也不用熬夜写代码了?如果这门课你真的熬夜写代码了,相信你一定有收获,如果这门课结束了你觉得是自己一个全新的开始,那么这门课的意义就实现了.团队作业全 ...

  3. 【2017集美大学1412软工实践_助教博客】团队作业10——项目复审与事后分析(Beta版本)

    写在前面的话 转眼轰轰烈烈本学期的软工实践就结束了,这个过程中想必在熬夜敲代码,激烈讨论中留下诸多回忆的同时,也收获了不少.恭喜所有团队完成了本阶段冲刺,此外,由于大家的贡献分给的都很平均,将个人贡献 ...

  4. 团队作业7——alpha阶段之事后诸葛亮分析

    事后诸葛亮分析 1. 设想和目标 1.1 我们的软件要解决什么问题?是否定义得很清楚?是否对典型用户和典型场景有清晰的描述? 解决查询物流信息步骤繁琐的问题.定义还算清楚.典型用户主要针对一些不熟悉淘 ...

  5. 团队作业10——复审与事后分析(Beta版本)

    Deadline: 2017-6-13 22:00PM,以博客发表日期为准 评分基准: 按时交 - 有分,检查的项目内容为后文的两个方面 Beta阶段项目复审(单独一篇博客) 事后诸葛亮分析报告(单独 ...

  6. 团队作业7——Alpha冲刺之事后诸葛亮

    Deadline: 2017-5-15 22:00PM,以博客发表日期为准 评分基准: 按时交 - 有分,检查的项目内容为事后诸葛亮分析报告 晚交 - 0分 迟交一周以上 - 倒扣本次作业分数 抄袭 ...

  7. 【集美大学1411_助教博客】团队作业7——Alpha冲刺之事后诸葛亮

    写在前面的话 alpha阶段都顺利完成了,大家这次作业完成得都很认真.我觉得通过这些问题,大家既可以回顾自己的alpha阶段,又可以给beta阶段做一些指引.但看了所有组的博客,没有一个组在这些问题之 ...

  8. 【1414软工助教】团队作业7——Alpha冲刺之事后诸葛亮 得分榜

    题目 团队作业7--Alpha冲刺之事后诸葛亮 往期成绩 个人作业1:四则运算控制台 结对项目1:GUI 个人作业2:案例分析 结对项目2:单元测试 团队作业1:团队展示 团队作业2:需求分析& ...

  9. 【1414软工助教】团队作业10——复审与事后分析(Beta版本) 得分榜

    题目 团队作业10--复审与事后分析(Beta版本) 往期成绩 个人作业1:四则运算控制台 结对项目1:GUI 个人作业2:案例分析 结对项目2:单元测试 团队作业1:团队展示 团队作业2:需求分析& ...

随机推荐

  1. 经典c程序100例==91--100

    [程序91] 题目:时间函数举例1 1.程序分析: 2.程序源代码: #include "stdio.h" #include "time.h" void mai ...

  2. http 代理阅读1

    代理模式数据流处理: //配置proxy_pass后,在 ngx_http_core_content_phase 里面指向该函数 /* 那么,当有请求访问到特定的location的时候(假设这个loc ...

  3. appium 数据参数化 登录模块

    下面是我最近学习的PYTHON的登录代码: class test(object): def getdic(self): d = {'username': '13', 'password': '1111 ...

  4. 放弃腾讯75W年薪,回老家当公务员,提离职被领导教育。网友:leader嫉妒了

    最近一位腾讯员工自爆,"老家公务员政审已过,放弃腾讯75w年薪,提了离职被leader教育了".并且这位员工还晒出了领导"教育"自己的聊天记录,引发网友们的热议 ...

  5. tcp黏包问题与udp为什么不黏包

    1.先说下subprocess模块的用法,为了举个黏包的例子 # 通过一个例子 来认识网络编程中的一个重要的概念 # 所有的客户端执行server端下发的指令,执行完毕后,客户端将执行结果给返回给服务 ...

  6. 详解scanf与getchar

    原文: (https://www.myjinji.top/articles/2020/07/22/1595399358246.html)[https://www.myjinji.top/article ...

  7. 早期javac编译器优化

    学习<深入了解Java虚拟机>有一段时间了,大概理解了Java从源代码编译到执行出结果的过程,也能明确的知道Java是半解释性语言.在执行源代码时,先通过Javac编译器对源代码进行词法分 ...

  8. HDU100题简要题解(2020~2029)

    HDU2020 绝对值排序 题目链接 Problem Description 输入n(n<=100)个整数,按照绝对值从大到小排序后输出.题目保证对于每一个测试实例,所有的数的绝对值都不相等. ...

  9. 【建议收藏】阿里P7总结的Spring注解笔记,把组件注册讲的明明白白

    环境搭建 注解的方式是通过配置类的方式来注入组件,注解注入要比XML注入的方式简单,注解注入也需要在前者的基础上,添加一个spring-context的包,也是实际开发中常用的方式. 准备所需Jar包 ...

  10. 给PDF文件创建书签,实现快速导航

    当文档中的页码比较多的情况下,使用目录进行导航是一个很好用的方法,为文档内容制作目录,方便快速查找目标内容.除了内容的快速导航,书签还能指明不同书签的层级关系,展现文档的结构. 图1:书签的功能 一. ...