alpha冲刺事后诸葛亮（团队）

alpha冲刺事后诸葛亮（团队）

课程名称：软件工程1916|W（福州大学)
团队名称: 云打印
作业要求: 项目Alpha冲刺（团队）
作业目标:完成Alpha冲刺的事后诸葛亮

团队队员

队员学号	队员姓名	个人博客地址	备注
221600412	陈宇	http://www.cnblogs.com/chenyuu/	队长
221600411	陈迎仁	https://www.cnblogs.com/yinen/
221600409	蔡森林	https://www.cnblogs.com/csl8013/
221600401	陈诗娴	https://www.cnblogs.com/orangepoem/
221600408	蔡鸿键	https://www.cnblogs.com/jichiwoyaochi/	转出
221600307	李姣	https://www.cnblogs.com/CloudLong/	转入

---

设想和目标

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

我们软件主要解决传统线下打印的一些弊端，比如线下打印店人多拥挤、排队时间长，U盘中毒、丢失，对打印机不熟悉错印多印，商家需要时刻关注各台打印机的打印状况等传统弊端。对软件功能的定位是很清晰的。主要针对目前大学生的打印场景以及目前大学生的群体进行了清晰的调查，通过问卷和实地考察，进行清晰的描述。

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

微信小程序端原计划主要实现5个大功能模块：文件打印、图片打印、联系客服、联系商家、扫一扫；每个大功能模块下还划分了许多子功能，比如文件上传、微信支付、订单列表、订单填写；按照原计划a阶段实现了主功能文件上传以及微信支付即文件打印功能。原计划达到的用户数还没有达到。

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

团队软件工程的质量提高了，对于整个软件的开发以及管理和计划的把握上有了一定的提高，从没有计划的建瓦房达到了有图纸有规划的建平楼，通过开发的软件项目质量以及开发过程中对问题的处理以及初始的计划安排情况来衡量

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

用户量离预期还有较大的距离，用户对文件打印功能的接受程度与事先的预想相差不多，但在一些细节上还不够完善，还需要进一步改进。

5.有什么经验教训? 如果历史重来一遍, 我们会做什么改进?

经验教训：初期只是规划在10天内完成的一系列功能，粗糙地 安排每天的工作量，但是在后面的执行欠缺更加严格的监督，导致其中一两天耽搁，没有按照预期的进度去做，还好后面几天加班完成预期功能。通过这个教训，感受到应该严格监督每天的进度。如果重新来一遍，我们会更加合理的安排人员以及时间，清晰划分每个任务的deadline，严格监督每天进度。

---

计划

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

做计划上的时间还是挺充足的，做好计划，有助于工程的顺利进行。

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

当遇到不同意见时，我们主要采用投票表决，决策出最优方案。

3.你原计划的工作是否最后都做完了? 如果有没做完的，为什么?

大部分任务如期完成，未做完的部分因为突发原因或技术问题影响工程的进度。

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

这个倒是没有遇到。

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

每一项任务基本都有明确的目标。

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

项目未完全按照计划进行，中间因为某些技术上的问题，导致进度有些落后。对于风险的问题，这个倒是没考虑到。

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

我们计划中留有一定的缓存区，某种程度上较好地弥补落下的工作。

8.将来的计划会做什么修改？（例如：缓冲区的定义，加班）

根据技术上的难度适当调整每天的工作量。

9.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

在这个过程中，我们学到了微信小程序开发的相关技术，前后端交互的问题解决能力以及开发过程中遇到的种种问题的解决经验等

---

资源

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

技术资源不够，需要边学习边开发，工作量大，压力大。

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

主要按照工程中功能实现的难易程度进行估计，精度上还需要进一步改进。

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

测试时间不够，人力和软硬件资源凑凑有余，对于美工、文案设计确实低估了工程难度，在界面设计中遇到了许多问题。

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

这个倒是没有，自己正在做的事情自己比较熟悉，突然交付给别人来做，需要花费时间跟他交流讨论，才能真正交接，这样效率反而不高。

5.有什么经验教训? 如果历史重来一遍, 我们会做什么改进?

代码复用性不是很好，后期修改的工作量大，如果可以再来一次的话，我们打算对代码进行重构，提高代码复用性和整洁性。

变更管理

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

收到变更通知后，我们及时和组员进行了沟通和交流，保证了消息的时效性，让组员第一时间收到通知。

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

根据这个功能对软件的必要性和开会讨论。

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

在前面的需求分析报告，和系统分析报告中有比较清晰的定义。

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

没有，全靠熬夜加班。

5.员工是否能够有效地处理意料之外的工作请求？

在alpha冲刺中没有遇到意料之外的工作请求。

6.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

保证消息的时效性，制定好应急计划。

设计/实现

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

设计是在初期原型设计的时候由团队多名队员一起完成的，是合适的时间，合适的人。

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

有，会团队一起讨论把模棱两可的地方确定。

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

• 有运用单元测试和UML等工具来帮助设计和实现。
• 这些工具是有效的，单元测试保证了每个部分的正确性，uml帮助我们观察类、对象等之间的关系。
• UML文档类图的对象和方法都有不一样，区别产生于老师和助教的建议后，我们更新了UML文档。

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

• 小程序微信支付功能产生的bug最多，因为大家不太熟悉它的工作原理。
• 发布后没有发现重要bug。

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

• 代码复审由组长审查代码的格式、风格、命名是否符合规范。

6.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

• 我们学到了微信小程序的开发，还有很多测试工具的使用。
• 如果历史重来一遍，我们会更严格按照代码规范编程。

测试/发布

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

有。

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

进行了。

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

有，如Junit等。

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

有用Jprofile对软件的功能进行测试。有用，确保了软件功能的正确性。

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

• 没有遇到意外问题。
• 我们学到了测试的重要性。
• 如果重来一遍我们会提早学习测试工具的使用，不用临时学习

6.我们学到了什么? 如果重来一遍, 我们会做什么改进?

• 没有遇到意外问题。
• 我们学到了测试的重要性。
• 如果重来一遍我们会提早学习测试工具的使用，不用临时学习。

团队的角色，管理，合作

1.团队的每个角色是如何确定的，是不是人尽其才？

每个成员负责自己擅长的部分，充分发挥团员的优点。

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

有

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

团队一起沟通讨论

每个成员明确公开地表示对成员帮助的感谢 （并且写在各自的博客里）：

• 陈宇
  感谢chj在完成前后端的任务中给与我的帮助，即使离开了团队也继续完成了前端的任务。

• 陈迎仁
  我感谢cy同学对我的帮助， 因为在出现的一些bug的时候都是他和我一起克服，还指导我学习java后端。

• 蔡鸿键
  我感谢cy对我的帮助,因为某个具体的事情: 帮我一步一步改BUG。

• 蔡森林
  我感谢cyr对我的帮助，因为某个具体的事情: 他让我开始接触和开发微信小程序。

• 陈诗娴
  我感谢cy同学对我的帮助，因为某个具体的事情：冲刺阶段写代码遇到bug帮我找原因和修改方法。

总结

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

可重复级(Repeatable)档次。

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

从磨合到规范的阶段。

3.你觉得团队在这个里程碑相比前一个里程碑有什么改进?

代码规范度更高，配合也更默契。

4.你觉得目前最需要改进的一个方面是什么?

增加团队成员的配合度。

5.其它软件工具的应用，应该如何提高？

参考网络上的教程自学，或请求掌握该工具使用的同学的指导。

6.项目文档的质量如何提高？

参考网络中优秀的项目文档是怎么写的。

交换组员的工作交接和培训方案

工作交接：
1，传给新成员原成员写的源码，因为原成员是web端，所以我们把所有的HTML+CSS+JS的网页代码交给他。
2，因为新成员学习过基本的WEB知识，就不用另行学习。
3，由原成员带新成员学习web使用的框架。
4，由于新成员是做UI的，会帮派一些UI图标优化。

培养计划
1，温习基础HTML+CSS+JS知识
2，由原成员带新成员浏览代码，学习框架，并运用
3，使新成员了解接下来的项目需求，提出自己的见解，使加快融入小组
4，由前后端同学交流接口，使之理解数据交付，熟悉AJAX和DOM原理等
5，自我界面美感优化

讨论的照片