第01组 Alpha过后诸葛亮

1、组长连接

http://www.javashuo.com/article/p-aisjazzk-du.html

2、现代软件工程 项目Postmortem

设想和目标

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

咱们的软件要解决的问题是对福大校内各个任务群、拼车群的资源整合，方便校内学生以更高的效率拼到车或发布任务。另外还有一个板块用来给你们讨论。定义得清楚。有。

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

目标达到了。功能都完成了，也按计划交付了，可是还没有对外开放。

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

用户对重要功能的接受程度和咱们事先的预想一致。咱们离目标更近了。

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

好比须要更早的开启项目，不然后面会比较赶时间。

计划

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

有充足的时间来作计划。

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

经过集体讨论、投票解决同事们对于计划的不一样意见。

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

作完了。

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

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

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

是。

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

都按计划进行。

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

否。缓冲区为整个项目的按计划完成增长了保障。

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

在每一步计划中留下缓冲区。

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

咱们学到了关于微信小程序开发的整个流程。再来一遍，咱们会增长计划的预留时间等等……

资源

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

有。

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

根据困难程度估计。精度大体符合预期。

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

足够。低估了。

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

有。

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

作任何事情前要更加了解项目后再入手。

变动管理

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

知道。

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

小组讨论。

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

能够完整实现某项功能的时候算作好了。

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

能够。

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

能。

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

咱们学到了当功能变动的时候须要让其余人员即便了解方便他人手头上的工做。

设计/实现

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

做业发布初期黄皓同窗和孙庭鑫同窗就开始进行产品的原型设计，是合适的时间和合适的人。

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

有，有些界面彷佛可存在又不必，最后又团队内讨论决定的最终方案。

3.团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其余工具来帮助设计和实现？这些工具备效么？

是，颇有效。

4.比较项目开始的 UML 文档和如今的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？

如今的uml更加详尽也更加贴近实际需求。这些区别是在产品的开发过程当中渐渐对原来的设计有了更实际的改动后产生。

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

都挺多的。由于做业太难了。发布后没有什么重要的bug。由于你们都是第一次作这种类型的做业因此没有经验因而没有想到这么多状况。

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

一个模块一个模块，一个组件一个组件的来熟悉，掌握。实现一个比较大的功能，尽可能严格遵循规范。

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

遇到困难，不要惧怕，微笑地面对它。消除恐惧的最好方法就是直面恐惧。坚持才是胜利。加油，奥里给。若是历史重来一次，咱们必定会节省不少尝试地时间。

测试/发布

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

没有，开发时间不是很充足。

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

是，完成后第一时间进行了测试。

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

无。

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

没有测量跟踪。

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

帐号链接有些问题。

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

再来一遍，咱们遇到什么困难，也不惧怕,微笑着面对它，消除恐惧的最好办法就是面对恐惧，坚持才是胜利,加油，奥里给！

团队的角色，管理，合做

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

你们报名完成，是的。

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

团队成为之间经常互相帮助。

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

没有这方面的问题。

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

我感谢 ______一组的全部成员______对个人帮助， 由于某个具体的事情:______你们都积极完成做业。_______________。

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

还来，咱们遇到什么困难，也不惧怕,微笑着面对它，消除恐惧的最好办法就是面对恐惧，坚持才是胜利,加油，奥里给！

总结:

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

CMMI一级，完成级.

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

团队目前处于磨合阶段。

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

这个里程碑挺好的。比上次做业人更多了，合做更顺利了。

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

代码编写能力。

5.对照敏捷开发的原则, 你以为大家小组作得最好的是哪几个原则? 请列出具体的事例。

不管是团队内仍是团队间，最有效的沟通方法是面对面的交谈这一原则。当出现交互上的问题时，组员们能快速的互相交换信息解决问题。

3、答辩总结

团队贡献

成员	分工	贡献比例
孙庭鑫	原型设计	9.8%
黄皓	原型设计	9.8%
张泽宇	产品经理	10.3%
李至恒	后端编写	10.3%
林易丰	后端编写	10.3%
江斯强	后端编写	9.8%
杨蓝宇	后端编写	9.8%
沈鸿骁	前端编写	9.8%
蔡嘉懿	前端编写	9.8%
刘伟楠	前端编写	10.3%

本组现场答辩得分

26

无人对本组提出问题

4、PSP与学习进度条

PSP表格

PSP2.1	Personal Software Process Stages	预估耗时（分钟）	实际耗时（分钟）
Planning	计划	20	15
· Estimate	· 估计这个任务须要多少时间	5	5
Development	开发	480	420
· Analysis	· 需求分析 (包括学习新技术)	60	60
· Design Spec	· 生成设计文档	20	30
· Design Review	· 设计复审	10	10
· Coding Standard	· 代码规范 (为目前的开发制定合适的规范)	0	0
· Design	· 具体设计	60	120
· Coding	· 具体编码	0	0
· Code Review	· 代码复审	0	0
· Test	· 测试（自我测试，修改代码，提交修改）	30	45
Reporting	报告	0	0
· Test Report	· 测试报告	0	0
· Size Measurement	· 计算工做量	10	10
· Postmortem & Process Improvement Plan	· 过后总结, 并提出过程改进计划	20	25
	· 合计	715	740

5、全组讨论的照片