团队作业10——事后诸葛亮分析

事后诸葛亮分析


总结的提纲内容,请参照课本15章内容或邹欣老师的博客:

a. 项目管理之事后诸葛亮会议

http://www.cnblogs.com/xinz/archive/2011/11/20/2256310.html

设想和目标
1. 我们的软件要解决什么问题?是否定义得很清楚?是否对典型用户和典型场景有清晰的描述?
    我们要解决的问题是一个能够导入课程表的个人学习计划提醒系统。在之前的需求规格说明书有队典型用户和典型场景有清晰的描述。
2. 我们达到目标了么(原计划的功能做到了几个?  按照原计划交付时间交付了么? 原计划达到的用户数量达到了么?)?
    目标大体上是达到了,原计划的功能少了用户自我评价的那一块。
3. 用户量, 用户对重要功能的接受程度和我们事先的预想一致么?我们离目标更近了么?
    用户包括班级成员以及周围宿舍的同学,接受程度和预期差不多,虽然有些功能在实现上不够好,但是经过努力一步步做出来的产品,让我们离目标更加接近。

- 有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
    觉得主要的问题就是时间的问题,大三的课程本身就比较多,一定要将可利用的时间充分利用起来。

计划
1. 是否有充足的时间来做计划?  
    时间不是非常充足,且大家都不太知道如何更好地利用时间来做计划。
2. 团队在计划阶段是如何解决同事们对于计划的不同意见的?
    主要通过会议解决,毕竟隔壁宿舍,有问题面对面交流,加上队长大人发言一般不同的声音很快就会变成统一意见的。
3. 你原计划的工作是否最后都做完了? 如果有没做完的,为什么?
    是有没做完的,一是时间问题,二是考虑欠缺。
4. 有没有发现你做了一些事后看来没必要或没多大价值的事?
    有!!大部分的团队成员对于这一点答案还是相当统一的。但是做了也没什么坏处,把纠结做这件事有没有意义的时间还不如就做了呢。
5. 是否每一项任务都有清楚定义和衡量的交付件?
    只能说是模糊的。说清楚好像有点太自信的感觉。
6. 是否项目的整个过程都按照计划进行,项目出了什么意外?有什么风险是当时没有估计到的,为什么没有估计到?
    几乎是按照计划进行的,在队长的有效领导下,进行的也蛮顺利的。
7. 在计划中有没有留下缓冲区,缓冲区有作用么?
    有,因为团队成员的能力还是有差距的,进度就不太一样,所以还是需要缓冲区的。
8. 将来的计划会做什么修改?(例如:缓冲区的定义,加班)
    更加明确缓冲区的长度。
 
- 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
    计划还是得根据个人能力定制,缓冲区还是要有的,要适当考虑可能的风险因素,要做好风险应对策略。
 
资源
1. 我们有足够的资源来完成各项任务么?
    我们做的是web开发,所以资源不是什么大问题。
2. 各项任务所需的时间和其他资源是如何估计的,精度如何?
    估计的时间和实际的时间相差还是比较大的,进度差比较大,精度小。
3. 测试的时间,人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度? 
    还是处于简单的测试阶段,各方面的资源还是足够的。不算低估难度。况且对美工方面,每个成员都会提一点小小的建议。
4. 你有没有感到你做的事情可以让别人来做(更有效率)?
    如果都给会的人做肯定会更有效率,但是分工合作一起查资料,可以帮助基础不好的人提升项目代码编写的能力,也不失为另一种意义上的有效率。

- 有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
    对于资源方面,主要还是人员的分配方面,适当的人做适当的事。

变更管理
1. 每个相关的员工都及时知道了变更的消息?
    那是肯定的,除了qq群之外,隔壁宿舍这个优秀的条件,有啥消息在适当的时间敲敲门面对面聊一聊就都知道了。
2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?
    一是看用户的需求哪些是必须的,哪些是用户没有考虑而我们自己想做的;二是看项目要求的基础功能,基础功能要是没了还说什么进阶功能呢;三就是看自身的能力啦,如果有余力,功能越完善越好,主要是看时间的长短。
3. 项目的出口条件(Exit Criteria – 什么叫“做好了”)有清晰的定义么?
    我们的出口条件是能够对每日任务进行操作,能够导入课程表,能够对每日任务进行评价,且可以进行用户邮箱提醒。没有明显的bug,能够正常运行基本的功能。
4. 对于可能的变更是否能制定应急计划?
    并没有,所以遇到紧急事件只能熬夜补救。
5. 员工是否能够有效地处理意料之外的工作请求?
    我们工作外的请求就是别的学业啦,由于其他课的作业也比较多,有时候真的会面临时间不够的情况。但是大家还是两边抓紧,都没有落下。
 
- 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
    变更管理的消息要及时散发给各个成员,务必让大家及时接收到消息,对于可能的变更,要有预备的紧急应对策略。

设计/实现
1. 设计工作在什么时候,由谁来完成的?是合适的时间,合适的人么?
    原型设计是项目的开头,由翁珊和谢晓萍完成,合适的时间,由于她们也是前端代码编写的人员,也是合适的人员。(在beta阶段,前端人员变更成黄建英和谢晓萍)
2. 设计工作有没有碰到模棱两可的情况,团队是如何解决的?
    有。比如说有考虑过做网页的字体格式,后来在实现的时候,也没时间,也觉得不是非常的必要,大家综合考虑就决定放弃了。
3. 团队是否运用单元测试(unittest),测试驱动的开发(TDD)、UML,或者其他工具来帮助设计和实现?这些工具有效么?
    尚未运用。
4. 什么功能产生的Bug最多,为什么?在发布之后发现了什么重要的bug?为什么我们在设计/开发的时候没有想到这些情况?
    数据库交互功能产生的bug最多,数据库的数据无法在HTML页面中展示并困惑了许久,花费了大量时间进行了修整。因为低估了Python语言和MySQL的相适应性。(换句话说,用Python和MySQL搭配有点坑,应该转用SQLite)
5. 代码复审(Code Review)是如何进行的,是否严格执行了代码规范?
    不算严格执行。
- 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
    提前把MySQL的程序模块写好。

测试/发布
1. 团队是否有一个测试计划?为什么没有?
    有。
2. 是否进行了正式的验收测试?
    暂时还没有,只是各成员自己对自己负责的模块进行很初步的测试。
3. 团队是否有测试工具来帮助测试?
    coverage插件进行测试。
4. 团队是如何测量并跟踪软件的效能的?从软件实际运行的结果来看,这些测试工作有用么?应该有哪些改进?
    使用了多种浏览器进行测试,并无太多问题,同时在邮箱验证过程中采用了多种SMTP供应商的服务来进行测试,比如,Sina,Gmail,Tencent,Yahoo等,来确保邮件服务的稳定性。
5. 在发布的过程中发现了哪些意外问题?
    服务器部署出现意外。 

- 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
    提前学习服务器部署知识。Apache+Mysql+PHP的部署比Python Flask+MYSQL要容易的多。

团队的角色,管理,合作
1. 团队的每个角色是如何确定的,是不是人尽其才?
    结合自身的能力,再通过自荐,权衡进行确定的。算是人尽其才了。
2. 团队成员之间有互相帮助么? 
    当然有,帮助是相当相当的大。如果没有成员之间互相的帮助,肯定是没有现在的成果的。
3. 当出现项目管理、合作方面的问题时,团队成员如何解决问题?
    通过会议,大家提出意见看法,一起讨论最后的解决方案。

成员博客:
    详见下方团队成员的角色表格。
    
- 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
    每个角色要用适合的人选担任,成员之间要互相帮助,大家互相帮助,共同进步。
 

总结:

你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
    二级,管理级。
你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
    目前我们的团队已经完成了beta阶段的冲刺,冲刺阶段中的分工合作进行的有条理,可以算是正在磨合走向规范的阶段。(因为过程中也遇到大大小小的问题,所以还是达不到规范)
你觉得团队在这个里程碑相比前一个里程碑有什么改进? 
    1.成员都有了一定的或多或少的经验;
    2.成员的感情一步步变得更加紧密,合作起来更加的顺利。
你觉得目前最需要改进的一个方面是什么?
    加强访问页面的稳定性,做好一些小bug的完善。
对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。  
    1.业务人员和开发人员在项目开发过程中应该每天共同工作。--虽然没有共同工作,但是做到群内讨论。
    2.以有进取心的人为项目核心,充分支持信任他们。--组员相互信任,尤其信任组长。
    3.时时总结如何提高团队效率,并付诸行动。

b. 全组讨论的照片

1140156-20170611224431715-336000777.png

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

名字角色团队贡献分可验证的贡献
黄建英前端19前端页面代码编写
谢晓萍前端20.5前端页面代码编写
黄月梅后端19.5后端功能代码编写
徐晓珊数据库20数据库设计
庞伊凡后端21.5后端功能代码编写
赵娅汀测试19.5最后的测试功能

转载于:https://www.cnblogs.com/KKlist/p/6956530.html

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
在这个三国佚事中,诸葛亮为了应对蜀国战事紧急,彻夜写了安排书信,并交给送信小厮。然而,这个小厮却投靠了曹操,故意将书信都投错了烽火台,没有一封是正确的。这让诸葛亮非常着急,因为错误的书信传错会导致蜀军自乱阵脚,不攻自破。现在,诸葛亮想知道被小厮传错的书信共有多少种情况。 根据引用提供的代码,我们可以看到这道题目是一个数学题,通过计算书信传错的情况数。具体来说,代码中的函数f(n)计算了传错n封书信的情况数。根据代码中的递推关系,我们可以得出结果。 输入样例:3 输出样例:2 所以,传错3封书信共有2种情况。<span class="em">1</span><span class="em">2</span><span class="em">3</span> #### 引用[.reference_title] - *1* [F - 三国佚事——巴蜀之危](https://blog.csdn.net/qq_39173848/article/details/123140310)[target="_blank" data-report-click={"spm":"1018.2226.3001.9630","extra":{"utm_source":"vip_chatgpt_common_search_pc_result","utm_medium":"distribute.pc_search_result.none-task-cask-2~all~insert_cask~default-1-null.142^v93^chatsearchT3_2"}}] [.reference_item style="max-width: 50%"] - *2* *3* [7-7 三国佚事——巴蜀之危 (20 分)](https://blog.csdn.net/Zero_hunter_kill/article/details/124286092)[target="_blank" data-report-click={"spm":"1018.2226.3001.9630","extra":{"utm_source":"vip_chatgpt_common_search_pc_result","utm_medium":"distribute.pc_search_result.none-task-cask-2~all~insert_cask~default-1-null.142^v93^chatsearchT3_2"}}] [.reference_item style="max-width: 50%"] [ .reference_list ]

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值