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

一、设想与目标

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阶段的角色和具体贡献

九、全组讨论照片