Gamma阶段过后分析

Gamma阶段过后分析

设想和目标

1. 咱们的软件要解决什么问题？是否认义得很清楚？是否对典型用户和典型场景有清晰的描述？

• 咱们要解决的问题：实验室招生信息分散，以及创意与实现分离难以合做
• 典型用户：现阶段面向在校生与实验室
• 典型场景：

2咱们达到目标了么（原计划的功能作到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)

• 原计划的功能：合做、委托、创意发布以及基本的论坛功能；后期通过论证砍掉了委托加入了实验室站内信关注收藏等功能
• 交付时间：虽然前阶段存在开发失败推迟交付，但Gamma彻底按照原计划执行完毕
• 用户数目：130+初步达到预期目标

3.和上一个阶段相比，团队软件工程的质量提升了么？ 在什么地方有提升，具体提升了多少，如何衡量的？

有必定提升，主要体如今：

• 团队合做：通过一段时间的磨合，你们的合做逐渐完善，每一个人都清楚本身的职责，可以积极完成任务
• 工做质量：随着前两阶段的锻炼学习，可以把大部分时间分到开发上，学习新内容时间减小，代码质量提升，bug数目减小(单阶段十几个bug减小到五六个)

4.用户量, 用户对重要功能的接受程度和咱们事先的预想一致么? 咱们离目标更近了么?

用户量在预期以内，可是用户对重要功能的接受程度和咱们预想的有一些误差。用户更加青睐于使用实验室功能，咱们对此调整了实现目标与用户保持一致。

5.有什么经验教训? 若是历史重来一遍，咱们会作什么改进?

• 经验教训：必定要制定完整的计划，而且有详细的实现论证。在实现过程当中发现以前的一些想法实现起来不可行，调整很频繁。
• 若是能重来：推行结对开发，对可实现性进行多方合做论证，深刻讨论细节内容实现

计划

1.是否有充足的时间来作计划?

是的。能够预先拿出半周的时间进行计划和讨论。

2.团队在计划阶段是如何解决同事们对于计划的不一样意见的？

实际不一样意见并未产生不少，咱们注重考虑开发人员意见。

3.你原计划的工做是否最后都作完了? 若是有没作完的，为何?

都完成了。砍掉了一部分不须要的，也加入了一些新的。

4.有没有发现你作了一些过后看来不必或没多大价值的事?

并无。某些功能(委托)在作以前有发现并不须要，因而提早砍掉了。

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

没有过于具体的交付标准，考虑实现方式与实用性双重标准，具体到页面要求的内容，但不拘泥版式。

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

alpha阶段存在开发失败，beta阶段发现了一些多余功能，而且要从新学习新知识。项目转会人员过于重要，后端技术人员所有转会，形成后端重写。没有料想到时间会很紧张故疲于应对风险。

7.在计划中有没有留下缓冲区，缓冲区有做用么?

有留下两三天的缓冲区。缓冲区用于修复一些反馈bug以及增长突发奇想的小功能。

8.未来的计划会作什么修改？

归入你们的我的事务规划，更加合理分配任务。

9.咱们学到了什么？若是历史重来一遍，咱们会作什么改进？

聚合相同的任务交付一人完成，没必要拘泥平衡任务量，提升耦合质量。

若是重来一遍，咱们将进行动态任务规划，减小忙等待现象。

资源

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

时间资源不足。机器资源充足。

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

根据代码量与代码质量评估，最后阶段精度很好。

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

测试时间略紧张，人力也略紧张(5人)。硬件资源充足，不须要编程的资源并很少，难度也不大。

4.你有没有感到你作的事情可让别人来作（更有效率）?

有一部分任务确实能够交付同一人作更有效率和质量。

5.有什么经验教训? 若是历史重来一遍, 咱们会作什么改进?

人力与时间资源将极大影响进度。

若果重来一遍，咱们将在Beta阶段开始时多招收两位成员。

变动管理

1.每一个相关的员工都及时知道了变动的消息?

是的。实现完成后会在群内交流并push接任工做者。

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

根据用户访问量以及用户反馈，进行权重调整。

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

要有三个标准：美观、实用、没有bug。

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

是的，会集中力量解决出现的问题。

5.员工是否可以有效地处理意料以外的工做请求？

是的，团队成员能及时处理额外任务请求，而且自发实现接下来功能的开发实现。

6.咱们学到了什么? 若是历史重来一遍, 咱们会作什么改进?

每一个人要作好本身的事情，对团队负责。

若是能重来，咱们会要求使用少许时间加多注释以及写一些开发文档，但实际上咱们的时间并不充裕。

设计/实现

1.设计工做在何时，由谁来完成的？是合适的时间，合适的人么？

设计由全体成员共同制定，在实现开始之初，是合适的时间与人。

2.设计工做有没有碰到模棱两可的状况，团队是如何解决的？

有一部份内容不能肯定，留待开发时进行尝试选择，着重考虑开发人员意见。

3.团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其余工具来帮助设计和实现？这些工具备效么？ 比较项目开始的 UML 文档和如今的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？

运用了测试单元来帮助设计实现，有必定效果。相对于项目开始UML基本推到重写，由于咱们重写了后端。

4. 什么功能产生的Bug最多，为何？在发布以后发现了什么重要的bug? 为何咱们在设计/开发的时候没有想到这些状况?

站内信bug最多，发生站内信重复发送现象，缺失现象等。主要是测试不是很全面，以及测试时间不充足，发布前实现的功能难以测试全面。

5.代码复审（Code Review）是如何进行的，是否严格执行了代码规范？

代码复审主要由先后端的开发经理进行，规范并非很严格，还需提升。

6.咱们学到了什么? 若是历史重来一遍, 咱们会作什么改进?

敏捷工程要善于应对各类突发情况，提早一些时间完成规划。

若是能重来，咱们准备将整个计划提早1~2天，留下足够缓冲区进行稳定性测试。

测试/发布

1. 团队是否有一个测试计划？为何没有？

团队有一个粗略的测试计划，测试人员有一个详细的测试计划。

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

进行了正式验收，不合格将打回修改。

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

使用了Django coverage来跟踪咱们的单元测试的代码覆盖率，并进行改进提升。

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

主要是压力测试。从测试工做来看，找到了一些多余代码，可是用处不是很大，提高有限，大的改进仍是要看实现代码。

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

密码修改能够修改成任意格式，是咱们疏于测试。

6.咱们学到了什么? 若是重来一遍， 咱们会作什么改进?

咱们的经验：须要进行足够多的测试来保证稳定性。

若是重来一遍：进行代码实现的论证改进，实现额外的加速。

团队的角色，管理，合做

1.团队的每一个角色是如何肯定的，是否是人尽其才？

考虑了我的意见，你们都是去作想作的工做。

2.团队成员之间有互相帮助么？

有的，结对编程的习惯延续了整个开发流程。

3.当出现项目管理、合做方面的问题时，团队成员如何解决问题？

肯定责任人，进行再次讨论和修改，当面讨论的方式颇有效。

总结

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

咱们认为，在通过了总体开发流程后，咱们的团队基本达到了“管理级”的要求。

2.你以为团队目前处于 萌芽/磨合/规范/创造 阶段的哪个阶段?

咱们认为咱们的团队达到了“规范”阶段的基本要求，已经有了比较高的自觉性与责任感，合做没有出现矛盾，彼此感受良好。

3.你以为目前最须要改进的一个方面是什么?

代码规范。这已是屡次强调的问题了，可是仍是常常发生，不一样成员认为的标准有一些差别。

4.对比敏捷的原则，你以为大家小组作得最好的是什么？

应对了屡次突发事件，艰难坚持到了最后。

• 存在开发失败版本
• 后端开发人员转会
• 小组成员时间紧张(工做、实验室、比赛、考试)

可是，咱们最终按计划完成了开发。

5.在下一阶段中咱们要改进的地方

• 稳定性：提升压力负载能力，优化代码架构
• 代码规范：严格要求格式，加大审查力度
• 宣传工做增强：咱们用户数量不太多，须要更加广范的宣传

小组成员合照

(mm同窗回家一周，暂时没有线下合照)