白给团队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. [MIT6.006] 13. Breadth-First Search (BFS) 广度优先搜索

    一.图 在正式进入广度优先搜索的学习前,先了解下图: 图分为有向图和无向图,由点vertices和边edges构成.图有很多应用,例如:网页爬取,社交网络,网络传播,垃圾回收,模型检查,数学推断检查和 ...

  2. 栈(Stack)和队列(Queue)是两种操作受限的线性表。

    (线性表:线性表是一种线性结构,它是一个含有n≥0个结点的有限序列,同一个线性表中的数据元素数据类型相同并且满足"一对一"的逻辑关系. "一对一"的逻辑关系指的 ...

  3. python3中我所了解的print()的用法

    1.最基础的用法:打印调试信息等字符串语句.而且在3里面,打印中文的时候不需要加u了. 2.打印变量 打印默认换行的: 打印出来不想要他换行的:参数end='',这样打印出来就可以不换行了,这种骚操作 ...

  4. 深度学习论文翻译解析(十四):SSD: Single Shot MultiBox Detector

    论文标题:SSD: Single Shot MultiBox Detector 论文作者:Wei Liu, Dragomir Anguelov, Dumitru Erhan, Christian Sz ...

  5. 使用Java将XSL和XML文件输出为HTML(XSL学习笔记二)

    XSL 指扩展样式表语言(EXtensible Stylesheet Language),前面一篇博客介绍了使用XSL即可直接将XML输出为HTML片段被浏览器解析,但是这样在web应用中浏览器的解析 ...

  6. So Easy! HDU - 4565

    易知,有\(S_n = \lceil{a + \sqrt{b}}\rceil ^ n\) \(\because a ^ 2 - 1 < b < a ^ 2\) \(\therefore a ...

  7. Python学习系列之列表(十一)

    一.为什么需要列表 变量可以存储一个元素,而列表是一个"大容器"可以存储N多个元素,程序可以方便地对这些数据进行整体操作 列表相当于其它语言中的数组 二.列表的创建1.列表需要使用 ...

  8. 多态,向上转型,向下转型,final关键字

    多态 概述   多态封装性,继承性之后,面向对象的第三大特性. 定义   多态:是指同一种行为,具有多个不同的表现形式.   生活中,比如跑的动作,猫,狗,大象跑起来的动作都是不一样的,再比如飞的动作 ...

  9. 【操作系统】银行家算法实现(C语言)

    [操作系统]银行家算法实现(C语言) 注意:本人编码水平很菜.算是自己的一个总结.可能会有我还没有发现的bug.如果有人发现后可以指出,不胜感激. 1.银行家算法: 我们可以把操作系统看作是银行家,操 ...

  10. Android动画系列之属性动画

    原文首发于微信公众号:jzman-blog,欢迎关注交流! 属性动画相较帧动画和补间动画更强大,帧动画和补间动画只能应用于 View 及其子类,而属性动画可以修改任何对象的属性值,属性值可在指定的一段 ...