一、总结的提纲内容
a. 项目管理之事后诸葛亮会议
（一）设想和目标
1. 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
让大学生通过记账养成良好的消费习惯，解决了大学生不知道钱花到哪里去，没有好的金钱规划等问题。在之前的团队博客的需求分析中对典型用户和典型场景有清晰的描述。
2. 我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)
基本完成MVP的功能。原计划就已经确定好目标，打算把核心功能先实现了。 有按照原计划交付时间交付。 用户数量原计划是12个，alpha阶段才刚刚发布，主要由内部开发人员在使用。
3. 和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高，具体提高了多少，如何衡量的？
提高了。分工协作方面有所提升。因为原来不大懂微信小程序开发具体流程，在分工方面只能分个大概，后来不断熟悉开发具体流程，PM在分工方面进行了调整，alpha阶段没有实现后端，则把后端人员调至前端开发。整个项目开发的效率有所提升。
4. 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
预想一致。离目标还有一段距离。因为是alpha阶段，我们还没有实现杀手功能，只完成了最核心的记账模块和报表模块。
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
设想太过饱满，在实际设计过程中，发现有些功能还没有能力实现。结合自身编程能力和需求进行功能设计。
（二）计划
1. 是否有充足的时间来做计划?
有，在alpha阶段的前两周都用来写计划。
2. 团队在计划阶段是如何解决同事们对于计划的不同意见的？
大家一起讨论，选择合适的计划。
3. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
基本完成。
4. 有没有发现你做了一些事后看来没必要或没多大价值的事?
有。在需求分析时，考虑之后要完成除核心功能和杀手功能外的其他一些不是很必要的功能，比如皮肤设置等。
5. 是否每一项任务都有清楚定义和衡量的交付件?
大部分没有，一般按照大家主观上的认识来定义功能。开发人员根据要求完成功能模块后，我们组成员会进行使用，并提出建议。
6. 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
基本都能按照计划进行。对前端语言的不熟悉，在某些功能模块实现方面，花了比计划还要长的时间。
7. 在计划中有没有留下缓冲区，缓冲区有作用么?
有。每个人的进度都不一样，有时候一些模块会有一些bug需要修复，花费的时间经常比计划的要长。
8. 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
结合开发人员的技术能力，合理安排时间。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
时间计划表要和开发人员的技术能力和功能模块的复杂程度相结合。我们会明确缓冲区的长度，确保计划能按时完成。
（三）资源
1. 我们有足够的资源来完成各项任务么?
人力资源足够，但是技术资源和时间资源还有所欠缺。因为大家都是第一次接触微信小程序的开发，没有系统学习小程序开发，操作起来难度还是挺大的。时间上，大家因为各种事情会感觉时间上有些不充足。
2. 各项任务所需的时间和其他资源是如何估计的，精度如何?
把每项任务的功能实现列出来，关于支持功能实现的后端技术也列出来。根据列表的功能数和功能实现的难度（如网上是否有资源可以参考）来估计所需资源和时间等。
3. 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
我们团队安排了2名测试员，人力资源是够的，在测试时间上安排有些不合理（安排的太少了），导致在alpha阶段发布程序时，程序还出现了一些bug。测试软件/硬件资源是足够的，但是在使用这些资源方面，我们团队还不能熟练操作。确实低估了不需要编程的资源（如界面排版设计），因为程序界面设计的语言大家没有接触过，很难通过设置一些变量值来实现大家设想的界面。
4. 你有没有感到你做的事情可以让别人来做（更有效率）?
目前大家都没有这种感觉，因为我们的任务是根据大家的技术能力、擅长领域来分配的。但有时也会出现分配给组员任务过重的现象，这个时候我们会及时调整任务分配。
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
在分配任务的时候，要先大概了解下程序的前端、后端各个模块完成的工作量，再根据每个人技术能力和擅长领域来分配任务，适时根据实际情况来调整任务。
（四）变更管理
1. 每个相关的员工都及时知道了变更的消息?
是的。我们团队有建一个微信群，有关项目的任何变更消息会在上面发布。
2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?
大家一起讨论决定最核心的功能，若出现不同意见的话，会采用投票的方式来决定功能是属于“推迟”还是属于“必须实现”。
3. 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
有。经大家的讨论，考虑到时间问题和大家技术水平，在alpha阶段我们只关注于记账小程序的核心功能。包括记账模块和图表模块。我们的出口条件就是：选择日期、类别进行记账，可以准确记录当天的总结余和选定日期查看当天的明细，选择年月查看消费类别的比例。
4. 对于可能的变更是否能制定应急计划?
在进行这个项目时，并没有制定应急计划。但在出现我们计划与实际出现偏差时，我们会及时调整计划。
5. 员工是否能够有效地处理意料之外的工作请求？
大部分能。PM会把工作请求给相应的技术人员实现，如果技术人员无法实现，大家可以一起想办法完成。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
在变更管理方面，我们团队做的不够，在实现程序过程中变更的内容也是直接临时大家经过讨论决定，这样很容易与原来的设计内容相违背。如果还能再来一次，我们会在计划设计方面，多考虑变更情况的发生和相应的应急方案。
（五）设计/实现
1. 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
在一开始的原型设计环节就进行了设计工作。由黄登峰和何雨柔同学完成。黄登峰同学擅长界面排版，何雨柔同学是我们团队的PM，会根据我们团队开发的小程序核心功能是记账
这一关键点出发，给出界面设计的建议。恰在合适的时间与合适的人。
2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
遇到过。比如在报表功能要放在和明细账单页面一个页面呢，还是独立出来一个页面。PM召集大家讨论，每个成员都给出自己的看法，经过讨论我们决定把报表模块独立出一个页面，这样让用户在短时间内使用中发现我们程序的主要功能，这样在排版方面也显得更加简洁明了。
3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？
用微信自带的测试小工具。还是挺有效的，可以分析时间效能、cpu使用情况等等。
4. 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
记账功能模块。涉及到账目类别、金额、时间的数据存储。发布之后有个严重的bug就是选择不同日期进行记账后，对应日期的明细出现了混乱，比如今天的账目记录到昨天去了，或者是没有记录进去。在测试过程中，并没有发现这个bug，是在发布之后才发现有时候会出现这种情况。
5. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
每个人针对自己负责的模块进行代码复审，让相关功能模块的开发人员进行互相代码复审。严格执行了当初制定的代码规范。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
设计过程中要注重测试。通过测试，开发人员能够及时修改bug或者更换设计思路。
（六）测试/发布
1. 团队是否有一个测试计划？为什么没有？
有。在程序开发过程中，测试人员针对程序开发的功能模块制定了测试计划。
2. 是否进行了正式的验收测试？
是。通过微信测试工具和测试人员的使用来修复已发现的bug。
3. 团队是否有测试工具来帮助测试？
有。微信自带的测试工具。
4. 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
使用微信自带的测试工具，通过分析测试工具的测试结果。有用。
5. 在发布的过程中发现了哪些意外问题？
出现了一些之前没有发现的bug。发布之后有个严重的bug就是选择不同日期进行记账后，对应日期的明细出现了混乱，比如今天的账目记录到昨天去了，或者是没有记录进去。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
要注重测试，测试人员要熟练掌握测试工具的使用，能够使项目的完成事半功倍。
（七）团队的角色，管理，合作
1. 团队的每个角色是如何确定的，是不是人尽其才？
根据每个成员的擅长领域和技术能力决定。做到了人尽其才。
2. 团队成员之间有互相帮助么？
有，遇到问题大家都会一起讨论、一起想办法，解决问题。
3. 当出现项目管理、合作方面的问题时，团队成员如何解决问题？
由PM进行调解，大家一起讨论。
（八）总结
1.你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
达到第二个等级：可重复性。我们团队能过做到管理制度化，建立了基本的管理制度和规程，管理工作有章可循。初步实现标准化，开发工作比较好地按标准实施。变更依法进行，做到基线化，稳定可跟踪，新项目的计划和管理基于过去的实践经验，具有重复以前成功项目的环境和条件。
2.你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
目前处于规范阶段。在alpha开发阶段，一开始大家会出现一些意见不统一的情况，需要大家不断的磨合。现在我们团队能够团结协作完成项目开发，遇到不同意见也能够在较短时间内解决。
3.你觉得团队在这个里程碑相比前一个里程碑有什么改进?
对微信小程序的开发流程有了更深刻理解。开发人员也对一些前端语言有了进一步的熟悉。大家能够更加团结协作做事，效率也更高了。
4.你觉得目前最需要改进的一个方面是什么?
我们项目的杀手功能还没有实现。因为考虑到alpha阶段的时间和大家的技术水平，把杀手功能放在了下一阶段的开发。
5.对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
原则：我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。事例：在alpha阶段，我们完成了最核心的功能，在后期开发我们会始终围绕用户需求把实现其他的功能。原则：在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。事例：我们团队每个礼拜都要开一次会议，如果有什么疑问，可以直接面对面提出。原则：每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。事例：我们团队每个礼拜都要开一次会议，探讨工作进度和工作任务等，大家会提出使工作更有效的建议，如是否调整计划，修改工作任务，调整任务分配等。
b. 全组讨论的照片。
二、根据展示博客中给出的团队成员在Alpha阶段的角色和具体贡献排序：
| 名字 | 角色 | 团队贡献排序 | 可验证的贡献 | 团队个人贡献分 |
|---|---|---|---|---|
| 邱晓娴 | 前端 | 1 | 记账模块，修改bug | 35 |
| 陈凯欣 | 前端 | 2 | 报表模块，修改bug | 32 |
| 何雨柔 | PM | 3 | 安排任务，每日的进度追踪，服务器的配置 | 13 |
| 黄登峰 | 测试 | 4 | 原型设计，界面设计 | 11 |
| 张晨晨 | 后端 | 5 | 架构设计，服务器的配置 | 9 |
原文地址：https://www.cnblogs.com/tdbk715/p/9040427.html