Alpha事后诸葛（团队）

【设想和目标】

• Q1：我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
• “小葵日记”是为了解决18-30岁年轻用户在记录生活时希望得到一美体验友好、功能全而不杂并提供分享平台的日记app的问题而开发的。
• Q2：我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？原计划达到的用户数量达到了么?)?
• alpha阶段原计划完成的三个模块完成了两个，但顺带完成了两个计划外的功能。
• 已按照原计划提交审核。
• 无用户量。
• Q3:用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
• 无用户量，先占个坑，beta之后再来qwq。
• Q4:有什么经验教训?如果历史重来一遍,我们会做什么改进?
• 经验教训就是每个阶段的目标一定按照每个阶段的含义以及时间来规划，在保证最小可用的原则时，尽量达到最大的可展示性。
• 会做的最大改进是要先确定最低标准，再进行开发，防止在非重点的功能上耗费太多时间。

【计划】

• Q1：是否有充足的时间来做计划?
• alpha的计划时间有点仓促。
• Q2：团队在计划阶段是如何解决同事们对于计划的不同意见的？
• 一起分析不同意见产生的原因，以及两种方式各自产生的结果，最后选择对团队最有利的那种。总结来讲就是一定要认真倾听、及时交流。（真实情况是我们团队的队员基本对所安排的计划没有意见。队员有意见这种事情的发生，我认为最大原因是出于队长，对于整体的情况考虑得不够到位，需要自我反思。）
• Q3：你原计划的工作是否最后都做完了?如果有没做完的，为什么?
• 原计划工作未全部完成，大致完成80%。
• 原因主要有两点：1.冲刺时间不符预期；2.冲刺目标不够准确（已反思）。
• Q4：有没有发现你做了一些事后看来没必要或没多大价值的事?
• 有的。其主要原因还是上面提到的目标不够准确。
• Q5：是否每一项任务都有清楚定义和衡量的交付件?
• 无硬性要求。通常情况是完成一个主要功能后进行团队内部的简单测试，无bug，并且使用相对友好即算是完成交付。
• Q6：是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
• 并不是都按照计划进行。
• 前期进度超乎意料的缓慢。
• 团队成员们对新技能的学习时间比预料之中要长。
• 前期计划过于理想，没有考虑到其他学科作业、考试、电气实习等除软工项目之外的时间杀手。
• Q7：在计划中有没有留下缓冲区，缓冲区有作用么?
• 有的。
• 预留了睡眠时间^ _ ^，随时准备为项目奉献睡眠。
• 还是挺有用的，Alpha版本交付的前几天和队友一起使用了熬夜大法，补上前期落下的进程。
• Q8：将来的计划会做什么修改？（例如：缓冲区的定义，加班）
• 缓冲区并不打算修改。
• Q9：我们学到了什么?如果历史重来一遍,我们会做什么改进?
• 要做的改进应该就是在计划之前问清楚团队成员的具体学习进度吧（:D细分到每个知识点)，而不是问个大概就完了，这样计划表才能更符合实际。

【资源】

• Q1：我们有足够的资源来完成各项任务么?
• 人力资源算够用了。
• 时间资源匮乏。
• 其他资源好像没什么了，暂时没发现哪些欠缺的。
• Q2：各项任务所需的时间和其他资源是如何估计的，精度如何?
• 各项任务所需时间都是通过与任务的负责人沟通后，(经过一系列友好辩论后)取他们能够完成的最快时限。
• 这么做的主要原因是我（队长）是负责前端的，对于后端的了解并不如我的后端队友们深，相比门外汉的硬性要求，还是应该选择尊重并信任队友们的自我判断。
• 精度不算高，只精确到天数，我们团队的任务汇报形式都是“x天完成x个任务，分别是xxx,xxx...”。
• Q3：测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源(美工设计/文案)是否低估难度?
• 同Q1，时间资源不足，人力资源勉强够用，软件/硬件资源暂时没有看出问题，算够用吧:D
• Q4：你有没有感到你做的事情可以让别人来做（更有效率）?
• 没有，每个队友的任务都挺满的，并且任务量都不会差很多，再帮别人分摊任务不管从哪个角度来讲效率都不会比现在高。
• Q5：有什么经验教训?如果历史重来一遍,我们会做什么改进?
• 虽然现在人手勉强够用，但每个人的工作量还是挺多的，如果历史重来一遍，大概会去挖几个墙角吧:D

【变更管理】

• Q1：每个相关的员工都及时知道了变更的消息?

• 可以说是的。一般都什么重要的消息都会第一时间发布在群里，并且当天开会时再强调一遍，确保每个相关队员都能知道。

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

• 按照之前讨论过的优先级以及项目实际进展来决定，先实现优先级高的，优先级靠后的在时间不足的情况下推迟实现。

• Q3：项目的出口条件（ExitCriteria–什么叫“做好了”）有清晰的定义么?

• 定义：界面优美、使用友好、无明显bug。

• 以及一个终极评判标准：该项目可否成为团队成员的自留产品。

• Q4：对于可能的变更是否能制定应急计划?

• 可以的。

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

• 可以的，他们都很聪明:D

• Q6：我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
  -个人觉得在管理这一块我们团队做的还算可以，暂时没有发现有什么太大的问题。

【设计/实现】

• Q1：设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
• 原型设计是由炜坤同学在项目开发前完成的；UI设计是由语恳同学根据前端进度和需要完成的；接口设计是由后端小分队在项目开发前完成的（参考了前端小分队的看法）。
• Q2：设计工作有没有碰到模棱两可的情况，团队是如何解决的？
• 发现就及时解决，不存在一拖再拖，拿不准主意找其他队友协商。对于一边动工一边修改设计（特别是原型和接口）的行为表示不支持不赞成。
• Q3：团队是否运用单元测试（unittest），测试驱动的开发（TDD）、UML,或者其他工具来帮助设计和实现？这些工具有效么？比较项目开始的UML文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
• 有用过其他工具来帮助设计，例如mockplus和staruml等。
• 有效，简单易上手。
• 相比之前，现在的文档更丰富。
• 主要是思考的角度更深层，对于项目的理解更为细致。当然，各种设计稿也让文档显得丰富了不少。
• Q4：什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug?
• 现完成的功能基础图文编辑功能产生的bug最多，还记得前端队友改bug改了很久。
• 主要原因是想支持图文混插编辑，难度会比普通文字编辑大，并且对于这方面之前了解的可以说是少了，所以容易产生bug。
• 暂未发布，就验收的成果来说，发现手写涂鸦方面还存在的小bug，会在beta版本中进行改进。
• Q5:为什么我们在设计/开发的时候没有想到这些情况?代码复审（CodeReview）是如何进行的，是否严格执行了代码规范？
• 不动手怎么知道有多难啊(+_+)?。
• 现阶段并没有执行代码复审，前后端使用的语言不同，所以没有统一制定代码规范，都是每个小分队各自制定各自的。
• Q6:我们学到了什么?如果历史重来一遍,我们会做什么改进?
• 简化功能，不要画太大的饼¬_¬。

【测试/发布】

• Q1：团队是否有一个测试计划？为什么没有？
• 有制定详细的验收验证标准，但还未进行正式测试。
• 认为并不是现阶段的重点工作。（功能都还没完成，没什么好测的。。。）
• Q2：是否进行了正式的验收测试？
• 没有。原因如上。
• Q3：团队是否有测试工具来帮助测试？
• 没有。原因如上。
• Q4：团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
• Alpha阶段对于软件的效能方面的要求较低，所以跟踪测量什么的，不存在的。
• 会在beta阶段进行效能测量和改进。
• Q5：在发布的过程中发现了哪些意外问题？
• 最大的意外大概就是还没有发布吧:D。
• Q6：我们学到了什么?如果历史重来一遍,我们会做什么改进?
• 对于测试，我们还是秉持着原本的观点，Alpha阶段以实现功能为主，不过多考虑效能测试方面的事，毕竟要先会跑才能谈飞啊。

【团队的角色，管理，合作】

• Q1:团队的每个角色是如何确定的，是不是人尽其才？
• 角色确定流程如下：队长简单介绍每个角色，并给出人数限制——队员们自我思考几分钟——待队员们都准备好后采取先到先得的方式进行“抢”角色——根据队员真实情况进行微调。
• 目前看来队员们对于各自的角色完成的都不错，但也不能说是人尽其才，完成的不错说明他们优秀，就算换到其他角色应该同样也能做的不错。
• Q2:团队成员之间有互相帮助么？
• 有的，各小分队经常私下组织去自习，并且宿舍离得都很近，交流问题很方便。
• Q3:当出现项目管理、合作方面的问题时，团队成员如何解决问题？
• 及时进行友好的沟通交流。问题不大在线上解决，问题较严重时开个临时会议，面对面交流。
• Q4:每个成员明确公开地表示对成员帮助的感谢 （并且写在各自的博客里）：
  -我个人比较颓废懒散。在这次课程中，我首先要感谢的是组长，我觉得她做得很好。她会在我懒散的时候拉我一把；周末汇报的时候，会提醒我别迟到；博客她也会提醒大家别忘了。她是一个好组长，我很感谢她。当然，还有谢谢同组的大家。
• Q5:我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
• 因为自己是做前端的，所以时刻都想从后端拉个人过来帮忙:D。
• 如果历史重来，大概会在前后端的人数分配上再多做考虑，可以将后端人员调成2个试试，增加一个前端人员。（但估计会被拒绝:D）

【总结】:

• Q1：你觉得团队目前的状态属于CMM/CMMI中的哪个档次?
• CMMI二级（管理级）
• 之前没接触过CMM/CMMI之类的定义，查了度娘，觉得二级会更符合一些:D。
• Q2：你觉得团队目前处于 萌芽/磨合/规范/创造
• 规范和创造的过渡阶段。
• Q3：阶段的哪一个阶段?
• 简单来讲是属于每个人都知道自己现在该做什么，以及接下来该做什么的阶段，不需要队长每天督促和安排任务（队长表示很省心:D）。
• Q4：你觉得团队在这个里程碑相比前一个里程碑有什么改进?
• 大概就是对于项目了解的更深入、对各自的角色掌握得更好，很少有多脸懵逼的场面了:D。
• Q5：你觉得目前最需要改进的一个方面是什么?
• 测试方面可以考虑开始制定计划了。
• Q6：对照敏捷开发的原则,你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
• 1. 第6条原则：在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。
• 原因：上面也提到过，我们小组经常各分队私下约自习，并且宿舍离得比较近，因为讨论一个bug串门到深夜也是常态。
• 2. 第12条原则：每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整
• 原因：每个阶段都进行反省是一直都有的习惯:D。非要举具体例子的话，大概就是某次被批评之后，团队成员们在操场看了4个小时的星星吧（从晚上10点半到凌晨2点半）。

【团队合照（小黄衫照）】:

• 1. 这张照片14号就拍完了，就想着写总结的时候一起放比较有意义（其实主要是懒得再拍了:D），所以拖了好久才发。
• 2. 本来想拍太阳的，奈何14号前几天一直在阴天下雨(￣ε(#￣)
• 3. 想体现出一种唯我独尊的感觉，不知道为什么拍成追悼会了(+_+)?
• 获得小黄衫的感想：意外，震惊，开心。对应的表情应该是这样子的：(⊙o⊙)？ —— Σ(っ °Д °;)っ —— (ノω<。)ノ))☆.。
• 附图：
  

【学习进度条】