白给团队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] 18. Speeding up Dijkstra 加速Dijkstra算法

    在之前的课我们讲过了Dijkstra算法,先回顾下,如下图: 那么如果加速DIjkstra算法寻找最短路径呢?这节课上讲师讲了两种方法:双向搜索(Bi-Directional Search)和目标方向 ...

  2. c# 自动更新程序

    首先看获取和更新的接口 更新程序Program.cs 1 using System; 2 using System.Collections.Generic; 3 using System.Diagno ...

  3. react 中组件状态的一些理解

    组件状态:即 state 只有当state发生变化时,组件才会更新. 当一个html标签的值依赖于state的值得时候,如果state的值没有更新时,这个标签的值无论如何也是不会更新的. 看下面示例: ...

  4. 重要 | Spark分区并行度决定机制

    最近经常有小伙伴在本公众号留言,核心问题都比较类似,就是虽然接触Spark有一段时间了,但是搞不明白一个问题,为什么我从HDFS上加载不同的文件时,打印的分区数不一样,并且好像spark.defaul ...

  5. 测试_QTP使用

    1.Qtp是什么? QTP是Quick Test Professional的简称,是一种自动测试工具.使用QTP的目的是想用它来执行重复的自动化测试,主要是用于回归测试和测试同一软件的新版本.(百度百 ...

  6. MindManager教程:高中数学函数思维导图怎么画

    说起函数,大家应该都不陌生吧,函数不论是在初中还是在高中都是需要重点学习的知识点,不仅仅是重点,更是作为难点曾出现在高考最后一道大题中.那今天我们就来做一个函数思维导图,来简单地了解一下关于函数的一些 ...

  7. css3系列之box-sizing

    box-sizing box-sizing: 俗称ie6 的混杂模式的盒子模型.  首先来了解一下 ie6 的混杂模式,和我们常用的 盒子模型有什么不一样 正常模式下: 我们设置的 width  和  ...

  8. Mac虚拟环境安装django

    安装:pip3 install virtualenv 创建:Virtualenv env01 激活:Source env01/bin/activate django安装:pip3 install dj ...

  9. 一看就懂的:MySQL数据页以及页分裂机制

    文章公号 首发!连载中~ 欢迎各位大佬关注, 回复:"抽奖" 还可参加抽活动 文末有二维码 一.知识回顾 回顾一下之前和大家分享的知识点 看了前面的文章,想必你肯定了解了什么是Bu ...

  10. IDEA连接码云

    IDEA连接码云: 1.安装Gitee插件 2.下载git.exe https://git-scm.com/download/win 3.安装git 如果是Win10专业版,可能会出错,GitBash ...