一、设想与目标

1.我们的软件要解决什么问题?

  • 我们的软件主要是帮助老师解决通过博客地址收集博客的相关信息来对学生对课程的认真与努力程度进行评定的问题,主要就是根据采集到的各项博客数据作为评分项,构建一个数据模型,评定学生对课程的完成情况,从而帮老师节约批改作业的时间。

2.是否定义得很清楚?

  • 是,在做这个选题之前已经做好了足够的需求分析,并且在正式的需求分析阶段和老师做了多次讨论,所要实现的功能也很明确。

3.是否对典型用户和典型场景有清晰的描述?

  • 是,在团队作业3---需求改进&系统设计中都有清晰的描述,详细见我们的需求规格说明书。

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

  • 是,大三基本都是上机课,所以课中课后都有充分的时间来做这个开发,但在开发的过程中,也遇到了一些困难,毕竟很多东西都是第一次接触。

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

  • 如果成员们有意见,大家会先彼此讨论,互相了解对方的想法,给予合理的反驳及意见,最终一般是由组长来统筹大局。

二、计划

1. 你原计划的工作是否最后都做完了? 如果有没做完的,为什么?

  • 在项目的Alpha阶段,我们团队完成了原计划的所有工作,(包括前端界面、后端数据交互模块、数据采集分析、数据展示等)。

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

  • 基本没有。

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

  • 有,我们在需求分析上花了很多时间,对于每个用户所需要的每个功能模块,我们都进行了详细的说明,所有的需求说明都在之前发布的需求规格说明书里有详细的说明,我们在冲刺阶段的Alpha版本开发也是严格按照需求说明书上,所以对于任务有很清楚的定义和衡量。

4. 是否项目的整个过程都按照计划进行,项目出了什么意外?有什么风险是当时没有估计到的,为什么没有估计到?

  • 我们有一个强大又细腻的队长,队长在每次实施计划前都考虑得很清楚,对每个人的分工都有一个具体的安排,因此对整个项目的推进和进展把握的很好,从冲刺阶段的燃尽图就可以看出我们组的项目进度节奏把握的很好,项目开发较为顺利,并没有出现什么意外和风险,一些BUG在Alpha测试阶段都已修复。

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

  • 有考虑到缓冲区,缓冲区有作用,比如我们用缓冲区的时间解决了各个功能模块的一些BUG,还可以应付一些紧急情况,以及完善一些功能。

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

  • 会根据大大的项目计划来做相适应的修改!!!

三、资源

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

  • 有足够的资源,我们的队长张家豪同学编程能力强,熟练多种编程语言,还有一个参加过多项如“蓝桥杯”类的大赛并获奖的李福镪同学,所以我们可以顺利地完成各项任务。

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

  • 我们根据各个组员的能力和擅长来切割分配任务,每天每个队友只要且必须完成自己的任务,没有具体的时间规定,精度不是很高。

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

  • 测试方面比较顺利,偶尔发现BUG(因为队长能力强、而且在编程过程监督严格、细心)花的时间没有很多。对于美工设计和文案我们认为也不容小觑,所以从一开始就挺重视,没有低估关于这方面的难度,也在努力把美工设计做到更好,让老师在看数据统计时视觉上有美的享受。

4. 你有没有感到你做的事情可以让别人来做(更有效率)?

  • 我们队一直都是很据各个队友的能力擅长来分配任务,所以每件事情差不多都是以最高效率完成,我的事情如果让别人来做应该不会更有效率。

有什么经验教训?如果历史再来一遍,我们会做什么?

  • 我们会花更多的时间在每天的小组会议,面对面的交流不仅是经验的分享,也是能力的提升,或许多一些交流我们的项目会完成的更有效率。

四、变更管理

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

  • 知道,我们通过qq小组群实时交流、安排任务。

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

  • 主体功能实现,如将服务器推迟到下个版本,计时以及记录、结束时强制手动停止必须实现。

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

  • 有,我们根据用户需求测试功能的实现情况来考量项目是否做好了。

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

  • 项目变更可能性小,没有考虑到变更,如果有变更会及时进行小组讨论并制定解决方案。

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

  • 能。有时候临时出现新的事物,大家都积极配合、共同处理任务请求。

6. 有什么经验教训?如果历史再来一遍,我们会做什么?

  • 我们会在每一个阶段结束之后,小组成员互换任务,这样对团队也许效率不会更高,但是对于个人进步会更大。

五、设计与实现

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

设计工作都是在正式编码之前完成,设计的内容有以下几个方面。

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

  • 原型设计的时候,大家对于某一内容的实现方式有不同的想法,界面的设计,颜色的搭配,等有很大的分歧,最终是通过投票进行选择的。
  • 每个设计工作大家都想要呈现出更好的一面,所以在大大的带领下,我们分工合作,非常配合。

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

  • 测试过程使用了python自带的unittest库来测试,使用测试框架来进行测试让测试过程变得更加清晰有条理,并且在程序的迭代过程也可以重复利用,验证新增代码未对程序原有的功能及正确性造成影响。

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

  • 暂时没发现产生很多bug的功能,一些BUG在Alpha测试阶段就已经修复好了。因为没有考虑到这些情况,导致后期要发布的时候才意识到这些问题。

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

  • 每个人完成一个功能,git commit 到码市上面都会先审核一下自己的代码,看是否有错。最后大大规范我们每个人的代码。

六、测试与发布

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

  • 有比较详细的测试计划,每个模块开发人员负责相应的测试工作。具体见团队作业5---测试与发布(Alpha版本)。

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

  • 大大有对整个Alpha版本各个模块进行验收测试。如果某个模块不符合预期的效果,大大会立即通知相应的模块开发人员进行修改。

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

  • 没有用到测试工具,因为第一次进行测试,所以就先采用了人工测试。

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

  • 每次代码提交合并完后,都会查看各个功能模块的运行效率以及数据库的响应时间、文件加载情况、页面的吞吐率以及内存消耗等等;
  • 从软件实际运行的结果来看,这些测试工作还是挺有用的,在alpha版本完成后,最后的运行结果证明了测试工作还是有用的,测试能否成功连接数据库以及相应的SQL语句的是否正常执行等等。总之发现了很多之前没发现的潜在问题,下次要再细心点!!!
  • 谈到改进的话,我认为在以后的编码过程中,应该多加一些单元测试,以及测试用例应该尽可能的覆盖所有的情况。

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

  • 出现了某些浏览器添加学生信息博客地址示例显示不全、不在程序路径下执行时无法获取数据库文件路径的问题,不过后面都成功解决了,按时发布该项目。

七、总结

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

  • CMMI二级:管理级
  • 我们团队经过了Alpha阶段的磨合,现在对大家的编程方式都有了一个清晰的了解,所以目前状态觉得刚刚好。

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

  • 规范阶段
  • 在每日的站立式会议中,通过大大的主持引导,组员把自己每天的进展情况反馈了出来,这样每个人项目的工作流程都有着一个清晰的了解。然后结合大大的任务分配,适当提出意见,以求整个任务分配更为合理。
  • 团队组员彼此之间都非常熟悉,而且又是同一个班级的,大家默契度都很高。

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

  • 在前一个里程碑里,我们完成了《需求规格说明书》的撰写以及界面设计和体系结构的设计,为项目的编程工作做好了充分的前期准备。
  • 在Alpha版本里程碑里面,我们在前端编程中,发现之前的原型设计部分排版和显示有点不大美观,综合组员们的审美意见等对此进行了不断的修正。
  • 通过每日的站立式会议,对项目进度以及组员进展有了一个更为清晰的了解,有利于PM进行后序任务的布置。尝到了站立式会议的甜果,在后序的团队运行中会多多采用这种会议方式。

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

  • 在Alpha版本的冲刺阶段,由于大大的合理安排,以及组员之间互学互助,整体项目的进度进展得很顺利,团队暴露的问题并不多。最需要改进的方面可能便是项目的界面设计上面还不大美观。在Beta版本的冲刺阶段,我们小组会在项目的用户界面下大功夫,使之更为友好,在Bata阶段,我们还要完善一些功能,并增添一些附加的高级功能。

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

名字 角色 团队贡献分
张家豪 后端功能设计及构建 8
李福镪 Flask框架交互设计及测试 7
黄美海 后端功能设计及构建 6.8
黄建英 前端页面设计 6.7
刘伟霞 前端页面设计 6.6
廖婷婷 数据库结构及交互设计 6.5

九、全组讨论照片

团队作业7---Alpha冲刺之事后诸葛亮的更多相关文章

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

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

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

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

  3. 【2017集美大学1412软工实践_助教博客】团队作业7——Alpha冲刺之事后诸葛亮

    题目 团队作业7: http://www.cnblogs.com/happyzm/p/6827853.html 团队成绩 评分项目 变更管理 设计/实现 测试/发布 团队的角色,管理,合作 总结 全组 ...

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

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

  5. 软工网络15团队作业7——Alpha冲刺之事后诸葛亮

    Deadline: 2018-5-16 22:00PM,以博客提交至班级博客时间为准 事后诸葛亮分析 Alpha冲刺,很多同学经历了"Learning by doing"的学一门新 ...

  6. 团队作业7——Alpha冲刺之事后诸葛亮(宣告项目失败团队解散)

    一.项目进度 1.4月5日,团队组建.满怀希望的能做好这个项目 2.4月12日,需求分析. 3.4月21日,需求改进,出现协作问题,没有做好. 4.做项目,学习新的知识,继续做项目,但是能力有限,团队 ...

  7. 集美大学网络1413第十一次作业成绩(团队七) -- Alpha冲刺之事后诸葛亮

    题目 团队作业7--Alpha冲刺之事后诸葛亮 团队作业7成绩  团队/分值 设想和目标 计划 资源 变更管理 设计/实现 测试/发布 团队角色. 管理.合作 总结 讨论照片 团队成员 角色.贡献 总 ...

  8. 附加任务:团队作业7 Alpha冲刺

    附加任务:团队作业7 Alpha冲刺 附加任务要求参考东北师范大学陈志勇老师博客:https://edu.cnblogs.com/campus/nenu/2016SE_NENU/homework/19 ...

  9. 《你说对就队》第八次团队作业:Alpha冲刺 第五天

    <你说对就队>第八次团队作业:Alpha冲刺 第五天 项目 内容 这个作业属于哪个课程 [教师博客主页链接] 这个作业的要求在哪里 [作业链接地址] 团队名称 <你说对就队> ...

  10. 《你说对就队》第八次团队作业:Alpha冲刺 第四天

    <你说对就队>第八次团队作业:Alpha冲刺 第四天 项目 内容 这个作业属于哪个课程 [教师博客主页链接] 这个作业的要求在哪里 [作业链接地址] 团队名称 <你说对就队> ...

随机推荐

  1. python 脚本在linux环境下运行

    有两种方式:1.直接使用python xxxx.py执行.其中python可以写成python的绝对路径.使用which python进行查询.2.在文件的头部(第一行)写上#!/usr/bin/py ...

  2. HDU 3001 Travelling:TSP(旅行商)【节点最多经过2次】

    题目链接:http://acm.hdu.edu.cn/showproblem.php?pid=3001 题意: 有n个城市,m条双向道路,每条道路走一次需要花费路费v.你可以将任意一个城市作为起点出发 ...

  3. git入门(4)团队中git保管代码常用操作

    在团队中协作代码时候,一定要熟练使用以下git命令,不至于把代码库弄乱, PS:一定要提交自己代码(git push)时候,先进行更新本地代码库(git pull),不然提交异常 git常用命令 1· ...

  4. 【Java学习笔记之二十一】抽象类在Java继承中的用法小结

    一.抽象类的基本概念 普通类是一个完善的功能类,可以直接产生实例化对象,并且在普通类中可以包含有构造方法.普通方法.static方法.常量和变量等内容.而抽象类是指在普通类的结构里面增加抽象方法的组成 ...

  5. Go语言数组的使用

    Go 语言数组 Go 语言提供了数组类型的数据结构. 数组是具有相同唯一类型的一组已编号且长度固定的数据项序列,这种类型可以是任意的原始类型例如整形.字符串或者自定义类型. 相对于去声明number0 ...

  6. 一个基于ES5的vue小demo

    由于现在很多vue项目都是基于ES6开发的,而我学vue的时候大多是看vue官网的API,是基于ES5的,所以对于刚接触项目的我来说要转变为项目的模块化写法确实有些挑战.因此,我打算先做一个基于ES5 ...

  7. java集合判断

    java开发中经常需要做集合判断,在这里mark一下,加强记忆 为空判断: null == applyList || applyList.size() ==0 非空判断: applyList != n ...

  8. fedora20 安装搜狗输入法及各种问题的解决

    http://blog.csdn.NET/g457499940/article/details/38656719 0 环境描述: 系统环境:Fedora20 64位 截止2014年09月 8日17:5 ...

  9. HttpResponseMessage获取请求响应体内容

    问题描述 使用httpClient获取的HttpResponseMessage类型的response,直接对其toString()获取的是请求的响应头,并没有获取响应体的内容 解决办法 HttpRes ...

  10. Spring Date Jpa on update current_timestamp 自动维护创建时间和更新时间

    在数据库里设置默认值current_timestamp可以维护创建时间,设置on update current_timestamp 可以维护更新时间.在JPA中应该如何去做呢?这里还是以上篇Topic ...