队名：七神无主队
| 姓名 |
学号 |
| 艾里扎提·买买提 （组长） |
3121004729 |
| 赵继业 |
3121004890 |
| 努尔艾力·亚森 |
3121004877 |
| 赛尔达尔·艾思开尔 |
3121004665 |
| 艾孜买提·艾合提 |
3121004771 |
| 扎恩哈尔 |
3119000743 |
| 邱政阳 |
3121004749 |
| 王方亮 |
3119004934 |
一、设想与目标
1.1 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
- 我们的软件主要是用来提高广大高校师生学习工作效率，便利学生发展为出发点而开发的。我们的对典型用户和典型场景描述的十分清楚，就是开发给高校在读学生以及老师使用，具体的描述可以参考需求规格说明书。
1.2 我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)
- 总体来说达到目标，原计划的功能都能够完成，也能够按原计划交付时间交付，用户数量正在逐步发展。
1.3 和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高，具体提高了多少，如何衡量的？
- 对我们而言，和上一个阶段相比，团队软件工程的质量自然是有所提高，具体表现在对团队的任务规划更合理、队员合作更紧密、工程效率更高。
1.4 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么？
- 虽然上线了，但是用户量还远远没到，因为功能还没完善好，只在内部测试，也没有没有试过在巨大用户量情况下的稳定性，远远比不上现在市场上现有的学生管理系统。但就功能接受程度还是相当不错的，事实上我们一直在向目标靠近。
1.5 有什么经验教训? 如果历史重来一遍, 我们会做什么改进？
- 教训：有良好的规划才是完成项目的重中之重，其次是每个人要有高度强力的执行力，然后成员之间要做好良好的沟通。不过这种东西还是要经历过才知道。
- 改进：
1. 在做项目工作安排时，设置多些缓冲时间，不让团队最后处于一直踩deadline或者超时完成任务。
2. 结合团队成员的实力，开会后确认团队开发成员有这个能力实现产品功能，再行设计产品需求。
二、计划
2.1 是否有充足的时间来做计划？
- 理论上时间十分充足，但是因为学业以及每位成员都有自己的事务，并不能很好地在一起做计划，所以时间还是比较紧迫。
2.2 团队在计划阶段是如何解决成员对于计划的不同意见的？
- 通过开展团队会议，就不同意见的讨论、分析，最后投票决定，少数服从多数。
2.3 你原计划的工作是否最后都做完了？ 如果有没做完的，为什么？
- 与最初的设想差距较大，还有很多功能没有完成或者完善好。产品本身需求设计得开发难度较大，技术经验不足造成产品未能如期完善推出。
2.4 有没有发现你做了一些事后看来没必要或没多大价值的事?
- 没有，或多或少都有价值，即使是被删除的设计也是经验的积累。
2.5 是否每一项任务都有清楚定义和衡量的交付件?
2.6 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
- 意外：基本上是按照计划进行，bugs倒是有很多。添加需求后，未能及时完成任务。
- 原因：
1. 没预料的原因是缺乏项目经验。
2. 没考虑到本团队开发人员的技术水平。
2.7 在计划中有没有留下缓冲区，缓冲区有作用么?
- 有预留部分但是不够充足，缓冲区可以有效保证项目按期完成。
2.8 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
- 我们学到了团队合作、制定计划的相关知识。
改进：多考虑计划执行中可能出现的突发情况及对应措施。
三、资源
3.1 我们有足够的资源来完成各项任务么?
- 项目的完成不是问题，只是缺乏开发经验，没有一个经验比较丰富的队员带领。
3.2 各项任务所需的时间和其他资源是如何估计的，精度如何?
3.3 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
- 人力和软件/硬件资源足够，对于不需要编程的资源也没低估难度。
3.4 你有没有感到你做的事情可以让别人来做（更有效率）？
- 团队在计划任务分工时一定程度地考虑了队员技术栈、时间等相关因素，所以基本分工较为合理，队员大多未出现这种想法。
3.5 有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
- 提前了解各位队员之后的时间安排，确保每个队员都能在项目中投入较多精力，保证项目进度。
主动向周边获取资源，多去请教别人相关问题，而不是自己盲目探索。
四、变更管理
4.1 每个相关的员工都及时知道了变更的消息?
- 是的，我们通过微信群来通知大家项目的进展及变动，会有定期的团队会议来汇报项目情况以及讨论项目变更改进，同时在github上大家进主页的时候也会看到团队项目的动态变化。
4.2 我们采用了什么办法决定“推迟”和“必须实现”的功能?
- 以项目的开发进度和功能模块来决定。评估功能的重要等级：若这个功能在项目的运行中是必不可少的，就是必需实现；若它可有可无，只是锦上添花的话，则可以作推迟处理。
4.3 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
-
- 具有健硕性：产品能经受各种奇怪的非法输入而不崩溃；
- 具有正确性：在输入正常的情况下系统能做出相应的反应，提供相应的功能而不出错，没有较大的bug；
- 具有合理性：各页面间的跳转，接口的进入与连接，页面设计都有较好的逻辑性，连接顺畅不突兀，页面跳转符合预期。
4.4 对于可能的变更是否能制定应急计划?
- 是的，比如我们留下了缓冲区，可以在紧急情况下获得更多时间，也减小了带来的影响，推进了项目完成。
4.5 员工是否能够有效地处理意料之外的工作请求？
- 是的。团队成员都能在会议讨论协商后接受需求补充或变更。
五、设计/实现
5.1 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
- 第一次集体会议的时候大家集体决定。时间也都是大家空闲的时候，耐心的商讨出来，由pm拍板。
5.2 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
5.3 团队是否有测试工具来帮助测试？
5.4 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
- 选课功能BUG最多，因为当时设计的时候不够细心。发布之后没有暂时发现重要的BUG。
5.5 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
- 我们通过使用阿里巴巴的代码规划，同时开发团队在开发的IDE上都安装了这个插件，所以代码大都能按照规范进行。
5.6 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
- 我们学到了一个真正的项目的开发流程经过。再重来一遍，那我们什么都会了，可以更快的完成开发测试，避免BUG，少走弯路。
六、测试/发布
6.1 团队是否有一个测试计划？为什么没有？
6.2 是否进行了正式的验收测试？
- 对几个主流的浏览器的各主要功能进行了逐一验证，都通过了。
6.3 团队是否有测试工具来帮助测试？
- 没有，都是由团队测试人员手动测试。
原因：产品本身实现的功能不多，手动测试也不是特别麻烦。
6.4 在发布的过程中发现了哪些意外问题？
- 配置域名时小组成员发现阿里云的域名要进行一个月的申请方能上线，届时将超过项目截止日期，于是只能不使用阿里云提交项目地址，在域名申请这里花费了大量的时间。
6.5 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
- 测试对于一个合格的产品来说十分重要，它能发现很多在单独编写一个接口代码时未出现的bug,可以避免糟糕的用户体验以及用户隐私泄露等严重问题。如果之后有较为复杂的程序，我们可以了解一些自动化测试工具来提高测试效率。
七、总结
7.1 你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
7.2 你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
- 磨合，因为这是团队合作的第一个项目，在这过程中产生了大量的问题，最后呈现的结果也是不尽人意。但同时我们也有了这个项目的经验。
7.3 你觉得团队在这个里程碑相比前一个里程碑有什么改进?
- 通过系统的事后总结和整理，我们能够更进一步了解项目结果、团队技术水平的不足以及团队合作暴露出的一些不够完善的地方，也能够在一定的成果展示里提高我们对团队合作的自信心。
7.4 你觉得目前最需要改进的一个方面是什么?
- 这次开发的过程中，总感觉时间不够，东西很多，开发团队的技术水平，需要各个成员自己认真去下功夫精进自己的技术水平，才能推动项目的完成速度和完成质量。
八、讨论照片
九、团队成员在Alpha阶段的角色和具体贡献
| 名字 |
角色 |
团队贡献分 |
可验证的贡献 |
| 艾里扎提·买买提 （组长） |
PM |
12.0 |
产品经理、测试 |
| 赵继业 |
Dev |
12.0 |
整体架构、后端开发 |
| 努尔艾力·亚森 |
Dev |
12.0 |
前端开发、测试 |
| 赛尔达尔·艾思开尔 |
Dev |
14.0 |
博客编写、前端开发、测试 |
| 艾孜买提·艾合提 |
Dev |
12.0 |
前端开发 |
| 扎恩哈尔 |
Test |
12.0 |
测试 |
| 邱政阳 |
Test |
14.0 |
测试 |
| 王方亮 |
Test |
12.0 |
测试 |
posted @
2023-12-13 16:39
kklvu
阅读(
13)
评论()
编辑
收藏
举报
