组长博客
软件工程项目总结思考
设想和目标
我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
我们的软件为了解决用户对拼单的需求，解决用户没有拼单途径的问题，定义得比较清楚。
我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？)
原计划的功能做到了3个，未完成的部分为举报机制及发帖的部分，我们在交付时间内完成了这个软件，但有些功能还没有实现，总体而言完成了Alpha阶段的计划内容。
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
获得的经验教训就是一定要注重配合，如果历史重来一遍，我们会制定更为详细的计划目标，让项目更完美地达成预计的目标，在下一阶段我们需要对目前组员的实力进行重新评估，已制定更好的计划以进行Beta阶段。
计划
是否有充足的时间来做计划?
对于计划我们用的时间较少，有一定的计划，但不够充分，在计划时未考虑具体进度和学习新知识的时间，计划不够详细现实。
团队在计划阶段是如何解决同事们对于计划的不同意见的？
对于计划的不同意见我们通过讨论的方式寻求最优的解决方式。
你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
原计划的工作未能全部完成，主要原因是时间太赶而且恰逢其他科目有考试，导致原定计划未能全部实现。
是否每一项任务都有清楚定义和衡量的交付件?
对于分配给每个组员的每一项任务都有明确的定义，但没有明确的衡量指标。
是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
整个项目总体上都在按照计划进行，没出什么意外。
在计划中有没有留下缓冲区，缓冲区有作用么?
没有留下缓冲区，主要原因在于时间较少且要花时间去学习新知识，同时还要处理其他科目的学业，已无时间留下缓冲区。
将来的计划会做什么修改？
1、设置缓冲区 2、制定合理的计划 3、明确任务指标。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
我们学到了软件开发的相关知识，并懂得了团队的重要性，如果历史重来一遍，我们会多花些时间来制定一个合理的计划。
资源
我们有足够的资源来完成各项任务么?
缺少有过开发经验的成员是我们的一大问题。
各项任务所需的时间和其他资源是如何估计的，精度如何?
各项任务所需的时间和其他资源主要以该任务涉及的知识领域以及代码量进行估计，精度不高。
测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
由于时间较少，测试的时间不够，对于美工这类资源没有低估其难度。
你有没有感到你做的事情可以让别人来做（更有效率）?
大家都在学习新的知识，所以没有这种想法。
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
测试的时间需要提高，如果历史重来一遍，我们会多注重测试部分的时间，同时尽可能多地寻找需要的资源。
变更管理
每个相关的员工都及时知道了变更的消息?
对于变更的消息我们会及时在群里通知，由于宿舍的缘故也会直接告知负责的人。
我们采用了什么办法决定“推迟”和“必须实现”的功能?
主要以可能花费的时间和学习成本来衡量，对于耗时大、学习成本高的推迟实现，比较容易实现的必须完成。
项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
我们的定义为所有计划中的功能全部实现且能运行即为项目出口条件。
对于可能的变更是否能制定应急计划?
对于部分变更制定应急计划，如服务器的搭建未能成功时就采取直连数据库的方式。
员工是否能够有效地处理意料之外的工作请求？
如果是与负责的部分相关的意料之外的工作请求能够有效地处理，而涉及不是负责部分外的工作请求可能需要学习新的知识，并不能很有效地处理。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
学到了临时变更发生时需要如何处理，如果历史重来一遍，我们会在计划中对每一部分可能发生的变更制定一个应急计划。
设计/实现
设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
设计工作在项目开始初期，由组长来完成，是合适的时间，合适的人。
设计工作有没有碰到模棱两可的情况，团队是如何解决的？
我们会在群中反馈工作中遇到的疑问，而设计人员会及时地参与讨论，避免模棱两可的情况发生。
团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？
由于开发经验缺失，没有用到这些工具，这也是需要改进的地方。
什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
在登录注册功能上产生的BUG最多，可能的原因是与数据库的连接存在问题，发布后发现软件在退出后台重新开启时需要重新登录，不能自动登录上一次的帐号，目前原因尚不明确。
代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
代码复审由各个部分负责的人自行复审，严格执行了代码规范。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
我们学到了项目的设计与实现的一般步骤，如果历史重来一遍，我们会在计划中运用单元测试等工具来帮助设计和实现的过程。
测试/发布
团队是否有一个测试计划？为什么没有？是否进行了正式的验收测试？
由于时间的关系及其他科目的考试，我们没有测试计划。
团队是否有测试工具来帮助测试？
目前还没有测试工具来帮助测试。
团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
我们目前还没有一个有效的测试跟踪效能的方法，这也是我们下一个阶段需要重点考虑的方面之一。
在发布的过程中发现了哪些意外问题？
一些手机的系统无法支持软件的安装。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
我们学到了对测试是一个很重要的部分，测试是一个发现问题的很重要的途径，如果历史重来一遍，我们会在各个功能实现以后进行相应的测试以消除潜在的BUG。
团队的角色，管理，合作
团队的每个角色是如何确定的，是不是人尽其才？
团队的每个角色都是自己挑选想负责的部分，可能并不是人尽其才。
团队成员之间有互相帮助么？
团队成员间遇到问题都会互相寻求帮助，互相学习。
当出现项目管理、合作方面的问题时，团队成员如何解决问题？
我们会在群中进行讨论，必要时线下开会探讨，互相交流意见，互相学习，及时处理疑惑和问题。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
我们学到了在一个项目开发的过程中，一个团队是非常重要的，如果历史重来一遍，我们会按照个人能力进行评估，给不同的人分配更适合的任务。
我感谢徐俊杰对我的帮助，因为他帮我解决了数据库的连接问题。
总结
你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
我们团队目前的状态属于CMM/CMMI中的可重复级。
你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
我们团队目前处于磨合向规范过渡的阶段。
你觉得团队在这个里程碑相比前一个里程碑有什么改进?
团队内交流更加频繁，开发效率更高，对于出现的问题能够共同解决。
你觉得目前最需要改进的一个方面是什么?
目前最需要改进的是测试方面的工作，由于时间的原因我们未能制定测试计划，这是我们下一个阶段需要进行改进的。
对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
我们小组做的最好的是原则4和原则7，对于原则4，我们的组员在编写代码时都是共同工作，有问题互相帮助互相学习，而对于原则7，我们一开始就以制作出一个可用的软件为衡量项目的主要指标。
全组讨论的照片
答辩总结
- 组员贡献比例
| 组员 | 徐俊杰 | 范文辉 | 江列湫 | 李家涌 | 连振升 | 黄丽萍 | 杨文 | 朱雅珊 | 彭佳伟 | 李炜炜 |
|---|---|---|---|---|---|---|---|---|---|---|
| 贡献比 | 15 | 15 | 6 | 9 | 10 | 8 | 15 | 7 | 7 | 8 |
-
现场答辩得分:
-
其他组对本组提出的问题
其他组未对本组提出问题。
个人PSP
| 过程 | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|
| 计划 | 10 | 20 |
| 估计任务时间 | 0 | 0 |
| 开发 | 0 | 0 |
| 需求分析 (包括学习新技术) | 100 | 100 |
| 生成设计文档 | 0 | 0 |
| 设计复审 | 0 | 0 |
| 代码规范 (为目前的开发制定合适的规范) | 10 | 1 0 |
| 具体设计 | 400 | 500 |
| 具体编码 | 0 | 0 |
| 代码复审 | 0 | 0 |
| 测试（自我测试，修改代码，提交修改） | 0 | 0 |
| 报告 | 0 | 0 |
| 测试报告 | 0 | 0 |
| 计算工作量 | 0 | 0 |
| 事后总结, 并提出过程改进计划 | 0 | 0 |
| 合计 | 500 | 610 |
学习进度条
| 第n周 | 新增代码（行） | 累计代码（行） | 本周学习耗时(小时) | 累计学习耗时（小时） | 重要成长 |
|---|---|---|---|---|---|
| 12 | 300 | 300 | 30 | 30 | 学习Android后端开发 |