团队作业6--事后诸葛亮分析
团队作业6--事后诸葛亮分析
| 这个作业属于哪个课程 | 2023软件工程-双学位(广东工业大学-计算机学院) |
|---|---|
| 这个作业的要求在哪 | 团队作业6——复审与事后分析 |
| 这个作业的目标 | Alpha项目阶段复审 |
| 团队项目仓库 | 啊对对对队小课表程序仓库 |
一、目标和设想
1、我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
我们软件致力解决广工学子查询课表的难题，该目的在确定选题时已给出明确的阐述以及背景。对于用户和场景则有可能是这样的：在一个寒冷的早晨，A同学起晚了，在上学的途中使用我们的小程序快速查看自己的课表。
2、我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?）
我们的目标未全部达成，初始目标基本达成，原计划还有很多拓展功能未完成。与原计划交付时间相比延迟了几天。原计划用户量未达到，因为未进行大量推广以及后端有些问题。
3、和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高，具体提高了多少，如何衡量的？
我们目前只有Alpha阶段研发，无法比较。
4、有什么经验教训? 如果历史重来一遍，我们会做什么改进?
那可太多了，首先我们第一次接触这个软件开发，对于整个开发流程完全不了解，所以在任务的安排上有许多纰漏，同时对于前后端链接方面更是一窍不通，在设定目标的时候好高骛远，真正动手来才发现难度远比想象的要大。如果再来一遍，我会现注重整个程序思路的设计，一个团队要有一个统一的思路才能走远，而且要注重主要功能的开发，现开发完主要功能才能去想其他的拓展功能。
二、计划
1、是否有充足的时间来做计划?
有充足的时间来做计划，但由于第一次接触，仍有许多考虑不周全以及想法天真的状况出现。
2、团队在计划阶段是如何解决同事们对于计划的不同意见的？
首先，我们会验证意见的可行性，在可行性意见通过后会进行技术难度的讨论，若难度合适则进行下一步与其他意见进行比较，比较难度，开发时间，便携性等一系列问题，最后以理服人，谁有道理听谁的。
3、你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
大概完成了基本任务，其他的难度太高，比主要功能的难度都要高，没有时间完成了。
4、有没有发现你做了一些事后看来没必要或没多大价值的事?
并无。第一次接触踩坑太正常了，只有经历挫折才能成长。
5、是否每一项任务都有清楚定义和衡量的交付件?
在这个方面我们团队做的一般，因为第一次接触真的太没有经验了，只设定了DDL,未有设定完成任务的条件，导致后面整合方面出现了比较大的问题。
6、是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
否，功能研发比想像中的要困难许多，因为第一次接触对于整个项目的难度把握不好，所有语言都是新学的，难度远比想象的大。
7、我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
我们对于代码编写能力以及功能整合能力都有较大的进步，如果再来一遍，我们能以更高效的方式完成这个项目，同时我们也会制定好更完备的计划去督促队员们完成。
三、资源
1、我们有足够的资源来完成各项任务么?
主要资源基本都收集完成，学习资源略缺乏，虽然互联网上有很多相关的课程，但是想要找到符合自己的仍有困难。
2、各项任务所需的时间和其他资源是如何估计的，精度如何?
自我评估，参考前辈的经验。
3、测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
测试资源偏少，对于不需要编程的资源低估了一些难度，实际工作量较大一点。
4、你有没有感到你做的事情可以让别人来做（更有效率）?
有，我个人代码水平较弱，同时对于软件开发没有任何经验所以换个人来领导或许更加好一点。
5、有什么经验教训? 如果历史重来一遍,我们会做什么改进?
及时收集资源，学习资源尤为重要，兵马未动，粮草先行，资源决定了你项目的上线。
四、变更管理
1、每个相关的员工都及时知道了变更的消息?
所有变更的消息，会在微信群里以消息或群公告的方式通知每位成员。并要求收到必须回复，以保证所有人都收到了。
2、我们采用了什么办法决定“推迟”和“必须实现”的功能?
主要根据项目开发剩余时间以及功能的重要性区别来决定。
3、项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
有定义，能够完成基本的功能无重大bug即可上线。
4、对于可能的变更是否能制定应急计划?
能够，本次项目变更较少，应急计划基本就是对于程序功能的取舍。
5、员工是否能够有效地处理意料之外的工作请求？
能够有效的处理，大家沟通起来的都很快。
6、如果历史重来一遍,我们会做什么改进?
更加合理的分配任务。
五、设计/实现
1、设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
设计工作是在第一次讨论选题的时候做的，由大家一起完成。
2、设计工作有没有碰到模棱两可的情况，团队是如何解决的？
积极进行讨论，前后端链接有问题都会及时在群里提出，一起群策群力，耐心沟通。
3、什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
课表界面的显示bug较多，这部分是整个项目最为复杂的地方，进行修改时很容易就出错了。因为本次项目开发难度远超想象。开发人员缺乏经验。
4、代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
有专门的复审人员，基本执行了。
5、我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
对于项目的想法其实可以先去请教有经验的人，勤学好问才是制胜法宝。
六、测试/发布
1、团队是否有一个测试计划？为什么没有？
未有，主要是手动测试，开发人员开发完功能自己进行测试，整合后所有成员也进行测试。
2、是否进行了正式的验收测试？
项目规模较小，没有考虑进行正式的验收测试。
3、团队是否有测试工具来帮助测试？
项目规模较小，同时测试时间比较紧张，因此没有使用额外的测试工具。
4、团队是如何测量并跟踪软件的效能（Performance）的？压力测试（Stress Test）呢？ 从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
主要使用人工测试，因为整个项目并不完善所以并没有进行压力测试等方面内容。
七、团队的角色，管理，合作
| 成员 | 角色 | 贡献分 | 可验证贡献 |
|---|---|---|---|
| 陈守信 | PM/前端开发/博客编写 | 13 | 登录界面设计 |
| 黄锴杰 | 前端开发 | 30 | 课表界面设计/个人设置界面设计 |
| 尹梓霖 | 爬虫算法设计 | 25 | 爬虫算法 |
| 马旭 | 爬虫算法设计 | 20 | 爬虫算法 |
| 范轩铭 | 程序思路设计/后端开发 | 15 | 后端编写 |
| 朱家琪 | 前后端整合/后端设计 | 17 | 后端编写 |
八、总结
1、你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
达到CMMI中的一级。
2、你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
磨合
3、你觉得团队在这个里程碑相比前一个里程碑有什么改进?
队友沟通变多，思维更加活跃，能够群策群力。
4、你觉得目前最需要改进的一个方面是什么?
开发人员的技术。
5、照片
