事后诸葛亮会议 未完成版
| 团队总结 |
1 缺少团队交流 2开发能力不足 3不客观的制定项目 |
|
王岸城 |
主要工作 |
主要问题 |
队友评价 |
|
|
1.文档编写者 2.博客维护
|
1.主次不分，做事情没有重要先后之分 2.投入的时间还可以增加。 3.编程能力需要提高 |
猪 |
|
何建勋 |
主要工作 |
主要问题 |
队友评价 |
|
编写程序 |
懒惰以至于学习速度跟不上项目进度 |
猪 |
|
苏月 |
主要工作 |
主要问题 |
队友评价 |
|
|
1.文档编写者
|
1.懒惰，对于编程没有用心的去学习 2.时间根本就没有充分的应用。 3.需要更好的去学习 4、对于编程方面可以更加的知识面一些。 |
2设想和目标
2.1. 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
2.1.1我们软件主要是为了解决在校学生在短时间内找到教室和记录一些紧急记事。
2.1.2目标定义为明确，只为考虑了所有的学生而不是个别真正需要该app的学生导致了选择app的功能太过于多，而无法按时交付。
2.1.3有过考虑一般的典型用户但没有典型场景有清晰的描述，导致针对的用户减少。
2.2. 是否有充足的时间来做计划？
2.2.1并没有充足的时间来做计划，都说工“欲善其事，必先利其器“但是我们团队并没有真正的先把计划完善，都是等到问题出现的时候才去想办法，而你、没有制定B计划。原计划的工作都完成，没做完的部分，就是没有与另外两个UI组和前端的pipeline做到完美整合。但这个主要是因为开始各个团队没有协调好，最后我们主动提供了数据添加的API
有没有发现你做了一些事后看来没必要或没多大价值的事?
2.3. 团队在计划阶段是如何解决同事们对于计划的不同意见的？用户量，用户对重要功能的接受程度和我们事先的预想一致么？ 我们离目标更近了么？
2.3.1 DN一直在赶进度，所以很多时候都是全部听大牛的，导致出现了大牛出现了错误就导致整个项目的损失。
2.3.2用户对重要功能的接受程度和我们事先的预想不一致了，我们原先设计的课堂派已被删除了几乎全部的功能，留下的也仅仅只是当初认为可以忽略不计的功能 课表与记事本。
2.3.3毋庸置疑我们离目标更近了，我们三个编程能力就不行的菜鸟经过一个学期的锻炼我们已经熟悉了 android的简单app的开发。
有什么经验教训？ 如果历史重来一遍，我们会做什么改进？
各个人各自为战，导致整个团队做的功能有些重合，而且大家的数据结构有差异，给代码整合带来很大麻烦，同时，软件的具体功能没有定义清楚。还有编写文本出现重复。实际开发的进度完全不符合正常进度，功能完全被删。如果还可以再累一次我们团队必须先要计划好，要稳定输出。
3计划
3.1. 你原计划的工作是否最后都做完了？ 如果有没做完的，为什么？
3.1.1只有完成了20%。
3.1.2因为太懒，每个人对指望队有去做事。
3.2. 有没有发现你做了一些事后看来没必要或没多大价值的事？
3.2.1有，太注重利益的分配和整个团队花了几天的的时间去完成一个没有意义的登录系统。
3.3. 是否每一项任务都有清楚定义和衡量的交付件？
3.3.1在这个阶段的开发我们并没有明确的定义和衡量的交付件，导致了我们团队项目的成败及取决于个别人。
3.4. 是否项目的整个过程都按照计划进行？
3.4.1我们团队的项目的整个过程都未按照计划进行，都是看到问题才去完成实现。
3.5. 在计划中有没有留下缓冲区，缓冲区有作用么？
没有，都是一直按心情出发，没有固定的编程使时间。
3.6. 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
3.6.1在将来的计划会，我们会在下课后留出一节课的时间，如果完成，则提前回宿舍。
我们学到了什么？ 如果历史重来一遍，我们会做什么改进？
1. 善用google英文搜索，多了解流行的开源解决方案。
2. 预留必要的缓冲时间，留给后期的整合。
3.要改掉拖延症
4资源
4.1. 我们有足够的资源来完成各项任务么？
4.1.1我们有足够的资源来完成各项任务，但是我们缺少的是一种激情。
4.2. 各项任务所需的时间和其他资源是如何估计的，精度如何？
4.2.1第一次阶段是天来记录，第二阶段我们是以时。
4.3. 测试的时间，人力和软件/硬件资源是否足够？ 对于那些不需要编程的资源 (美工设计/文案)是否低估难度？
4.3.1相对于工程量而言，已经比较充足，特别是我学过美术的。
4.4. 你有没有感到你做的事情可以让别人来做（更有效率）？
4.4.1没有，根据是猪是鸡来说，在底部我的效率完全可以实现。
有什么经验教训？ 如果历史重来一遍，我们会做什么改进？
- 估计任务所用时间时，时间要精确但也要留下缓冲区。
2. 留给DEV学习的时间。
3要合作去完成比较难的是。
5变更管理
5.1. 每个相关的员工都及时知道了变更的消息？
5.1.1是的，我们有联系方式组，主要的消息我们都是在里面通知。
5.2. 我们采用了什么办法决定“推迟”和“必须实现”的功能？
5.2.1我们采用了删除功能的办法决定“推迟”和“必须实现”的功能
5.3. 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么？
5.3.1不清楚
5.4. 对于可能的变更是否能制定应急计划？
5.4.1我们对可能的变更是能制定应急计划。
5.5. 我们是否能够有效地处理意料之外的学习请求？
5.5.1我们无法有效地处理意料之外的工作请求，么因为我们才刚接触到android开发。
我们学到了什么？ 如果历史重来一遍，我们会做什么改进？
1. QQ互传文件。
2. 多开碰头会或电子邮件通知，少通过短信通知 。
3.请叫学习前辈的经验。
6设计/实现
6.1. 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
6.1.1 要求太大。
6.2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
6.2.1有，通过沟通。
6.3. 团队是否运用单元测试（unit test），测试的开发（TDD）、UML，或者其他工具来帮助设计和实现？这些工具有效么？
6.3.1通过自己的手机来实现调试。
6.4. 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug？ 为什么我们在设计/开发的时候没有想到这些情况？
6.4.1通知提醒功能
6.5. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
6.5.1 没有，主要是因为自己本身素质不行。
我们学到了什么？ 如果历史重来一遍，我们会做什么改进？
1方便修改与维护
2要结合实际，要踏实，不能老想一步登天。
7测试/发布
7.1. 团队是否有一个测试计划？为什么没有？
7.1.1 有，是为了软件的稳定交付和bang查找。
7.2. 是否进行了正式的验收测试？
7.2.1没有，主要是软件工程概论的大作业。
7.3. 团队是否有测试工具来帮助测试？
7.3.1 有，主要是自己的手机/电脑。
7.4. 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
7.4.1 这个是什么东东呀…………
7.5. 在发布的过程中发现了哪些意外问题？
7.5.1无
我们学到了什么？ 如果历史重来一遍，我们会做什么改进？
1.要制定严密的测试计划
2.要灵活应变。
8总结:
8.1你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次？
8.1.1……还看不到任何规范的迹象。
你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段？
8.2.1 磨合。
8.3你觉得团队在这个里程碑相比前一个里程碑有什么改进？
8.3.1每个人都在干活。
你觉得目前最需要改进的一个方面是什么？
激情