团队作业7——Alpha冲刺之事后诸葛亮
事后诸葛亮分析
Alpha冲刺基本算是过去了，我们组展开了这个阶段的总结会议，对过去团队所做的进行了深刻的分析，诸葛亮倒称不上，但是确实优秀的团队必须定期召开会议总结经验和教训，团队成员之间的问题得到彻底解决，这样才能使得团队和项目不断完善，下面将我们的会议内容和总结分享给大家。
总结的提纲内容：
a. 项目管理之事后诸葛亮会议内容：
一、设想和目标
1. 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
我们的软件解决的是传统方式点名耗时、同学容易代替点名的问题，为广大师生提供快捷高效的上课点名系统。通过扫面微信公众号中的二维码能够实现签到、请假的功能。并且老师可以看到同学们的签到情况进行考勤统计，我们自认为定义的比较清楚。典型用户和典型场景我们在冲刺阶段的博客有展现出来：http://www.cnblogs.com/TeamOf/p/6745505.html
2. 我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)?
我们的目标算是完成了三分之一吧，原计划的功能还差一些，原本打算把每个科目分开然后老师可以对自己的班级进行考勤统计，但是最后我们还没来得及实现考勤统计这一块。交付的话，我们至少在课堂上演示完成，软件工程课上大家也进行了测试，但是由于功能尚未完善产品还未发布。而对于原计划的用户数量的肯定是尚未达标，因为我们的产品还未正式发布，用户暂时只有测试人员。
3. 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
用户对重要功能的接受程度和预想的基本上一致，通过线上采访老师、同学以及接触测试我们的产品，他们对我们的系统评价还是不错的。这对我们的肯定很大，觉得有做 下去的必要，我们也在努力靠近目标、满足用户的需求。
- 有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
在分析需求的时候不仅要考虑到我们所采访的对象他们提出的需求，还要考虑用户固有的属性之间的联系以及千万不能忘记最基础的需求，最基础的往往也是最重要的，当用户比较多的时候，所存在的科目也比较多，在这个问题上我们没有重视，这导致最后我们的系统签到有些乱，没有把每个老师每门课分开来，之后会想办法解决这个进行完善。
二、计划
1. 是否有充足的时间来做计划?
基本上每次开会都比较匆忙，大家课多，一周五个实验左右，有的队员还在准备考研以及考公，算不上有充足的时间来做计划，只是有做粗略简陋的计划。
2. 团队在计划阶段是如何解决同事们对于计划的不同意见的？
计划阶段嘛，没想过有很多不同意见，打算是少数服从多数解决不同意见，但是实际上并不是这样的，因为意见不同可能发生在两个人身上，这时候我们队里面的其他成员 就通过分析这两个意见的利弊综合决定采取谁的意见。
3. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
这个问题有点奇怪啊，明明是团队，为什么是“我”原计划的工作是否做完了呢？小编在此把我改成“我们”，我们团队计划的工作没有全部完成，少了考勤统计这一块，因为这 个系统实现起来真的有点难，前面都是在摸索，然后从最简单的做起，实现签到、请假等，想把这些基本的完成再来做老师这一块的，这中间遇到问题，解决的时间比较久， 没有来得及。
4. 有没有发现你做了一些事后看来没必要或没多大价值的事?
基本没有。
5. 是否每一项任务都有清楚定义和衡量的交付件?
每一项任务定义清楚好像没有做到，交付件基本上有，比如代码文件、软件需求规格说明书还有博客应该也算吧。
6. 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
俗话说计划赶不上变化，并不是整个项目都按照计划进行，刚开始几天完全没有头绪，都是摸着石头过河，项目倒是没有很大的意外，就是赶不上进度，导致博客代码没有 嵌入，博客保存在草稿箱，然后一下子三篇博客都是0分，这就是出乎意外的一件事。没有考虑到有什么风险的地方，后面也没发生。
7. 在计划中有没有留下缓冲区，缓冲区有作用么?
没有
8. 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
将来的计划会更注重每天的任务安排和效率还有团队的会议频率要加强，缓冲区确实也要定义，我们组的原则就是做到少加班，应该不会增加加班次数。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
我们学到了NABCD式的分析，还学会了如何用燃尽图管理项目进度，以及如何进行团队合作还有博客园、团队项目的管理，界面原型设计工具的使用等。如果历史历史重来一遍，我们会做出的改进就是完善需求，整体框架做的好一些，每个人的任务分派再细致一下。
三、资源
1. 我们有足够的资源来完成各项任务么?
我们有足够的时间来完成，各项任务，我们小组的是基于微信的在线签到点名系统，集美大学图书馆有大量的关于这方面的藏书，加上我们现在丰富的网上资源，和如此有学习精神的我们，我们当然可以有足够的时间和资源来完成各项任务
2. 各项任务所需的时间和其他资源是如何估计的，精度如何?
①、我们的估计是第一周学习如何搭建微信开发的环境，有了环境，才有了继续下去的可能，精度：很完美，第一周过后，所有组员的电脑上都有了安卓微信开发环境
②、第二周全组组员利用课后时间，学习网上找的教学材料，了解基础的安卓微信开发语言，精度：第二周过后我们都小有感悟，跃跃一试
③、我们通过讨论，没个人的具体负责的模块，和代码规范，和着手编写程序之后几周都在忙于程序
④、关于博客，是小组成员轮流编写，发布提交。精度：每个人都按时完成每日或者每周的博客
3. 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
测试i的时间还算足够，人力也还OK，软件/硬件资源没问题。
我们低估了美工设计和文案，导致写出来的程序界面上有些单调，博客没有认真阅读，导致一周的冲刺阶段没有及时提交博客（当天写完了的），导致这一块没有分。真的很气！！！
4. 你有没有感到你做的事情可以让别人来做（更有效率）?
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
①、成员分工要尽量清楚一些，避免完成重复的公能
②、代码规范一定要，提前达成共识，不然最后还得重新修改个自定义的变量名，费时费力
③、如果历史重来一遍，我们会尽力吧程序功能更加完善，编写单元测试代码，减少BUG的出现
四、变更管理
1. 每个相关的员工都及时知道了变更的消息?
由于我们经常召开讨论会议，每个组员都及时知道了变更的消息
2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?
我们采用了集体加班加点的办法决定“推迟”和“必须实现”的功能。
3. 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
能实现在线签到功能，和统计没来的同学
4. 对于可能的变更是否能制定应急计划?
由于实战经验有限，代码的耦合性太强，面对可能变更，应变能力有限
5. 员工是否能够有效地处理意料之外的工作请求？
意料之外的工作请求，我们会大家一起努力完成
我们学到了什么? 如果历史重来一遍 我们会做什么改进?
我们学到了一个团队之间配合的重要性，能够加快一个项目的进展，任何一个人的力量都是渺小的，只有融入团队，只有与团队一起奋斗，你才实现个人价值的最大化，你才能成就自己的卓越！团队，是为了实现一个共同的目标而集合起来的一个团体，需要的是心往一处想，劲往一处使
我们会强调组员间的配合，发挥最大的合作效率
五、设计/实现
1. 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
设计工作是在Alpha阶段冲刺的时候开始的。是由全体成员一起商量讨论完成的。感觉应该在需求分析之后就应该开始设计，这样就不会造成冲刺阶段一筹莫展无从下手的情况。
2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
设计工作进行时遇到许多模棱两可的情况，团队一般是经过讨论、查阅资料，互相提意见、谈想法来解决的。
3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？
团队并没有用这些。应该有效吧。
4. 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
微信定位功能设计时产生的Bug最多，会遇到很多无法定位或者定位不准的情况。在设计/开发时因为时间比较赶，知识储备不够，很多细节都没有注意。
5. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
一人写完自己的代码之后，交由另一人复审。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
我们学到了微信开发的基础方法，也学习到了查阅资料、学习的能力。历史不会重来，但学习还在继续，之后我们会努力提升自己的微信开发能力。
六、测试/发布
1. 团队是否有一个测试计划？为什么没有？
有测试计划。
2. 是否进行了正式的验收测试？
没有进行正式的，只是大家以用户的角度进行了验收。
3. 团队是否有测试工具来帮助测试？
有想过，但是不会用。
4. 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
团队成员关注微信号，并邀请舍友同学扫一扫跟踪。软件暂时不会用，也没时间学。
5. 在发布的过程中发现了哪些意外问题？
Alpha冲刺阶段的博客因为不满意一直存着没发，导致都没分了。其他东西也都不是啥问题了
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
和上面那句一样。在测试方面我们了解的远远不够，之后有时间会多加学习。
七、团队的角色，管理，合作
1. 团队的每个角色是如何确定的，是不是人尽其才？
团队的分工机都是基于个人擅长的方面不同来确定的，虽然掌握技能方面有相当大的概率重叠，但大家讨论后的角色担当基本人尽其才。
2. 团队成员之间有互相帮助么？
作为一个团体，成员间肯定少不了相互帮助。
3. 当出现项目管理、合作方面的问题时，团队成员如何解决问题？
休息一下，暂停项目，开个临时简短的会议，大家说各自的意见，求同存异，依据实际定出继续的方案。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
作为一个团队，保证人尽其用是必要的，还要营造一个和谐的工作环境，相互体谅相互帮助才能促成项目的顺利推进。
八、总结:
你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
答：基本处于可重复级
你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
答： 磨合向规范过渡期
你觉得团队在这个里程碑相比前一个里程碑有什么改进?
答：合作更默契，目标更明确，做事更灵活机动。
你觉得目前最需要改进的一个方面是什么?
答：对自身能力的评估不是太准确，方案改动比较频繁。
对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
答：最好的是“尽早并持续地交付要有价值的软件以满足顾客需求“与”保持简明——尽可能简化工作量的技艺“。在冲刺中基本满足既定计划完成项目开发，在遇到瓶颈时可以及时寻找新技术解决。
b. 照片：
-
团队成员在Alpha阶段的角色和具体贡献：
名字 角色 团队贡献分 可验证的贡献 林 燕 Test 20 功能测试，博客 王李焕 Dev 19 后台代码开发，博客 林至贤 Dev 18 后台代码开发，博客 童毅南 Front end 17 前端开发，博客 代泽旭 PM 22 代码开发，测试，博客
