Alpha 事后诸葛亮
Part 1 前言
Part 2 总结思考
- 设想和目标
- 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
解决微信端上的轻便办公，方便微信端上的办公群体，例如共享编辑针对需要反复审阅修改的办公情形，以及其他环境下面向组内的通知、投票等一系列办公需求。
- 我们达到目标了么（原计划的功能做到了几个？
原计划的功能中基本完成投票功能、对象分组，接近完成共享编辑功能，半完成通知、想法功能，未完成签到功能。
- 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)?
用户量, 用户对重要功能的接受程度和我们事先的预想一致么?我们离目标更近了么?
距离目标我们还有一定的差距，这次的alpha未能够达到我们原定的计划，如上述所表述的，进度并不是令人满意，目前所完成的效果也与前期设定的原型不论是风格上还是功能上相左，需要完善的地方有许多。
- 有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
柯奇豪：前踩工作需要做好，了解整体项目所需要的技术、软硬件支持，才能是后续的项目进度有条不紊。
- 计划
- 是否有充足的时间来做计划?
因为种种原因(考试、党课、个人等等)，每次计划的都不是很完美，也没有很及时的时间去补正，后续会注意。
- 团队在计划阶段是如何解决同事们对于计划的不同意见的？
通过了激烈的讨论，得到一个可行的方案并往这方面走。
- 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
杨礼亮：美工工作完成，辅助翔宇的工作还未完成，因为效率不高，能力不够
丁水源：通知后端的工作完成，但是完成的速度比较慢
柯奇豪：共享编辑后期遇到许多之前没有估计到的修改，例如存储形式、功能增加等，所以导致没有及时的做好，只完成了简单的列表显示功能。
黄毓明：投票、分组功能完成。
黄志铭：原来计划在12月份前把所有的前端界面做完，并和后端一起完成交互，然后好好准备期末考。过程一直都以为前后端交互应该就是一两天的时间………结果出来当面交互的时候，就发现了问题好多呀……根本不是一两天可以完成的。
蒋熊：没有都做完，待得不断开发，所发现的问题也越来越多，原型UI设计不完整，页面需求随着开发的深入不断上涨 有很多原型设计里没有的页面需要新增。一开始定的实现逻辑随着开发的深入也发现后端一些算法是无法完成的，因此前端页面需要跟进后端算法做出调整。再而对js不熟悉，与后端对接上来不及做完，且页面过来，也来不及对接，工作量太大。
林翔宇：没有。临近考试，再加上转专业课也很多，时间难以平衡。
- 有没有发现你做了一些事后看来没必要或没多大价值的事?
柯奇豪：有，花了大把的时间在ssm框架上，结果不太会用，转用springboot+mybatis，但庆幸是能用了。
丁水源：过程中学到的东西都挺有价值的，时间花的挺值得
杨礼亮：学了很多但是都遗忘了
黄毓明：一开始写的投票没能融入框架，只能使用里面的部分函数，大部分未使用
黄志铭：确实做了很多好像根本就没有帮助的事，比如自动跳转图片的界面风格以及代码之前几乎都是自己写，完全可以和网上照着改一下，再完善，延长了进度
蒋熊：觉得比较没有必要的事情就是开发前期过多的投入于逻辑设计和各自分工，浪费了很多时间大家各做各的，到最后一对接才发现对不上。
林翔宇：学些java基本语法花了很多时间，才开始写要做的小程序。其实完全可以边学习语法边写的。
- 是否每一项任务都有清楚定义和衡量的交付件?
所有人：很遗憾，没有，许多东西都是在后续工作中不断发现需要修修补补的地方，许多地方没考虑到。对于大家每个人任务的总和要达到什么结果很模糊。
- 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
所有人：项目初期是在按预期走，但是中后期已经偏离轨道了，出现的大问题有几个，一个是研发小组队员退出，不是简单的n-1问题，再一个就是前后端对接。直到现在，后端仍有三个项目未开发成功，前后端能算比较完整对接的只有投票一块。我觉得出现这样的问题主要是大家沟通交流不够吧，不然也不会再最后一周才想起来要出来一起做。没有有效的资源共享，导致每个人进度不一。
- 在计划中有没有留下缓冲区，缓冲区有作用么?
所有人：有过留取一段时间进行前后交互，是为了防止前后端交互后出现重大bug，或是界面逻辑有问题等，但是每个人并没有在这段时间前很好的将自己的任务及时完成，导致后续进展不顺，所以后来的缓冲区作用不大。
- 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
柯奇豪：留出一段时间出来进行一个项目的整合，目前在过渡期内，我计划分成两部分人群分别负责部分功能的前后端一起完善，最后在缓冲区的时间段内整体的一个汇总，每两天找个固定的时间段来一起编程。
黄志铭：接下去计划在一周之内，尽量能与分小组同学一起出来当面做一下，完善一下项目，在做前端界面的同时，也了解一下后端的具体操作，更好地实现交互。
蒋熊：其他小组项目都差不多完成了，接下来我们也得加快了，明白了问题所在，就不该再继续下去了，加班生活正式开始。
林翔宇：分配时间的时候一定要考虑仔细，不要再因为时间分配不合理，导致计划无法完成。
- 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
柯奇豪：学到的就是需要在项目开展之前即搜集足够多的资料来对整体的项目各部分有一个明确的方向，这样在后续的进度中就不会因为卡壳而不停的调整，初步了解各部分细分下来所需要的技术支持。
黄志铭：这个可以早点出来当面做一下，讨论一下具体的分工以及项目愿景，让大家更熟悉自己对应的部分，提高团队整体效率。
蒋熊：如果能够重来，第一周我们就会抱着这样的态度，二话不说，直接加班，撸袖子就是干。
林翔宇：做计划的时候一定要合理，时间很紧凑的时候要尽量提高效率。
- 资源
- 我们有足够的资源来完成各项任务么?
时间资源不足，基础能力储备不足。
- 各项任务所需的时间和其他资源是如何估计的，精度如何?
原先是按照每次博客的提交时间为周期进行编程，后续可能会更加细化，因为还有许多工作需要完善。
- 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
柯奇豪：测试阶段基本上部署服务器，暂时还在前期筹措阶段，待后续反馈。
- 你有没有感到你做的事情可以让别人来做（更有效率）?
柯奇豪：在项目的规划上以及对任务的布置上自己还是有缺失的，个人不怎么善于言辞，所以在过程中表述上常常没办法解释清楚，导致组员出现一头雾水的情况，在语言沟通上可能存在障碍。如果换一个表述更清晰一点的人或许在前期可以解决目标不明确的问题。
蒋熊：我觉得换一个人做我的事情不一定会更有效率。我觉得其他人也一样，每个人都适合自己的工作，问题始终不在个人上，而是团队上。
林翔宇：我们组人比较少，大家任务都很重，所以自己的部分还是自己努力做好吧。
- 有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
技术资源共享不够，如果重来或许可以借鉴其他组的思路，编程过程里也整理问题及解决办法，整合一份技术指南来便于小组开发。要注意队内的沟通交流，一定要留好十分足够的缓冲时间。
- 变更管理
- 每个相关的员工都及时知道了变更的消息?
会有消息延迟的情况，部分时候会耽误进度，后续可能采用固定时间段来集体完成并汇总提交。
- 我们采用了什么办法决定“推迟”和“必须实现”的功能?
按照博客提交的进度进行，但是发现不能很好的既定目标相符，需要调整一个合理的办法，可能会增加组内的进度deadline。
- 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
暂时没有考虑到这个问题，后续以真机测试为准。
- 对于可能的变更是否能制定应急计划?
目前没有
- 员工是否能够有效地处理意料之外的工作请求？
基于每个人的水平，部分成员没办法做到
- 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
柯奇豪：deadline与验收标准的确定需要完善，缺少压力的团队往往就会导致项目的短期搁浅，自己也需要学会对队员有更高的要求与督促。
黄毓明：学到了很多东西，Java的springboot+mybatis框架使用，微信小程序前端开发，以及一些web服务的相关，如果可以重来的话，不应将时间都浪费在一个框架上，提前做好任务分配也许会更好
丁水源：如果历史重来一次，我将会尽早的做规划，尽量早地完成任务。
蒋熊：如果历史重来，一定会先集中力量开发核心功能 先完成项目主模块。
林翔宇：当进度跟不上原先计划时，要赶紧调整，反思原因。
- 设计/实现
- 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
在项目的初期由组内共同讨论完成，是的。
- 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
原先在部分的功能上有歧义，基本通过各自表述自己的看法然后大家共同决定通过。
- 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？
主要使用processon、leangoo来对项目细则有一定的说明。
- 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
存在比较大的差异，是原先组内没考虑到的，主要原因在于项目开发经验不足，没有细化到许多具体的地方，后续有时间会对之前的UML文档进行修正。
- 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
框架的使用上遇到较多的bug，因为原先并没有考虑到会用框架，也是第一次尝试使用。
- 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
暂时没有代码的复审，后续做完会对代码的命名规范、注释、项目具体的布局做一定的修改。
- 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
柯奇豪：规划上虽然没办法一开始就做到尽善尽美，但在后续的进程中，还是需要安排适当足够的时间去做好这块内容
- 测试/发布
- 团队是否有一个测试计划？为什么没有？
暂时没有，因为基础性的开发并没有及时完成，但是在后续会有一个测试版本阶段。
- 是否进行了正式的验收测试？
目前还没有
- 团队是否有测试工具来帮助测试？
没有具体的规划，后续会去请教一下其他组给出方案。
- 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
暂未进行，设定的目标是想在周围人群中进行一次推广调查，然后收集意见酌情修改完善。
- 在发布的过程中发现了哪些意外问题？
产品暂未发布，还未遇到问题。
- 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
柯奇豪：有一个合理够用的测试可以简化项目后续的工作，减少bug的出现，尽可能考虑情况解决缺漏
- 团队的角色，管理，合作
- 团队的每个角色是如何确定的，是不是人尽其才？
按自己的意愿进行职能的分配，基本上算是人尽其才，但还是存在部分成员存在空窗期的情况，例如在原型设计阶段部分前后端不知所措，以及后续前后开发过程中美工人员的不知所措等。
- 团队成员之间有互相帮助么？
柯奇豪：团队成员在了解框架、具体编程等的过程中，基本上都是采取互帮互助的形式进行学习，相互指教的。
丁水源：有相互帮助，比如我就会去请教同伴黄毓明不懂的问题。
- 当出现项目管理、合作方面的问题时，团队成员如何解决问题？
每个成员明确公开地表示对成员帮助的感谢 （并且写在各自的博客里）：
柯奇豪：在此感谢一下 ++毓明++ ， 因为 ++自己本身不太善于言辞，仅仅只是自己会使用、编程，但经常给其他人解释不清，毓明则能很好的帮我与其余的人沟通，指导他们框架搭建，这是我未能做到的++。
黄毓明：在alpha版本中交流较少，基本上都是各做各的，出现问题也基本上是自己埋着头解决
丁水源：我感谢黄毓明对我的帮助，因为当我在理解Spring Boot框架时遇到一些问题，询问他，他能十分耐心地给我讲解。
蒋熊：我感谢全组的人对我的帮助，因为某个具体的事情：其实不论是前期工作分配的不合理，还是大家后来学习程度不够，问题已经发生了 现在大家都愿意投身其中，我们之间互帮互助，其实就很值得感恩。
林翔宇：我感谢黄毓明对我的帮助， 因为某个具体的事情: 耐心的帮我配置好开发环境，并教我怎么使用spring boot框架。
- 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
柯奇豪：一个团队最不能缺少的，就是团结一致为共同目标而共同奉献自我的决心，少一点借口，多做一点实事才是。带领队员一同进步的工作并没有想象中的简单，需要负责的地方有太多太多，对pm的责任多了一份敬重。还有就是努力改善自己的表述方式吧。如果重来，以上都是我会改进的地方。
黄毓明：硬要说学到了什么，只能说独立解决问题的能力变强了吧。如果历史重来，或许更多的交流会是比埋头苦干更好的选择
丁水源：如果历史重来一遍，我会提前学习好项目所需的框架，以及更早地学习java语言，更早的了解一个产品的研发过程。
蒋熊：如果历史重来，学会感恩吧，每个人都不推卸责任，互帮互助。
林翔宇：在团队合作中，只有大家都尽责，才能一起完成好任务。单靠一两个人是不够的
- 总结:
- 你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
柯奇豪：我觉得目前团队还处于可重复级阶段。
蒋熊：我觉得目前团队处于可重复级向已定义级过渡的阶段吧
- 你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
柯奇豪：我觉得团队暂时处于磨合阶段，信息与进度的不同步是目前遇到的最大问题。
丁水源：我觉得团队目前处于“规范”的阶段。
蒋熊：应该是磨合阶段，原先比较松散，直至这一次问题出现，促进了我们的磨合
- 你觉得团队在这个里程碑相比前一个里程碑有什么改进?
柯奇豪：更加的了解了软解开发流程，逐渐提高了编程能力，学习的语言与技能都有很大程度的提升，整个团队的合作观念渐长。
黄毓明：任务分工更加明确，目标更清晰，协作能力正在加强
丁水源：我觉得团队相比于前一个里程碑而言，队友们更加团结，更加明确了项目的方向，更有项目经验了。
蒋熊：改进就是学会去发现问题和解决问题了，而不是顺其自然
林翔宇：大家都比较熟悉了，沟通起来也越来越顺畅
- 你觉得目前最需要改进的一个方面是什么?
柯奇豪：目前最需要改进的方面就是组内的责任意识，也希望后续大家能够共同努力，齐心协力共同开发出能让我们自己满意的小程序来。
黄毓明：代码规范
丁水源：我觉得团队目前最需要改进的地方时“deadline拖延症”，不要把所有事情都拖到后期才完成。
蒋熊：最需要改进的就是分工合作，在原来的基础上重新分工，创新合作。
林翔宇：可能沟通还是要增强，大家进度要及时反馈
- 对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
柯奇豪：面对面交谈原则：其中的站立会议以及leangoo进度的监督作用还是很显而易见的。
丁水源：我觉得我们小组做得最好的是"每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。"原则，比如：其实队员们都不是很熟悉java和Spring Boot框架，同时大部分人也没有项目的经验，因此在研发过程当中遇到了许多技术上的问题，我们便会常常开会，相互交流，一起解决问题。从而对各自的下一阶段的工作进行适当调整。
- 博客要附上全组讨论的照片
Part 3.答辩总结
| 姓名 | 得分（百分制比例%） |
|---|---|
| 柯奇豪 | 22 |
| 蒋雄 | 11 |
| 黄志铭 | 11 |
| 黄毓明 | 24 |
| 林翔宇 | 9 |
| 丁水源 | 10 |
| 杨礼亮 | 13 |
评审表格设计
Final Score：
| 小组 | 评分 |
|---|---|
| 第一组 | 53 |
| 第二组 | 75 |
| 第三组 | 73 |
| 第四组 | 45 |
| 第五组 | 70 |
| 第六组 | 77 |
| 第七组 | 68 |
| 第八组 | 76 |
| 第九组 | 62 |
| 最低分 | 77（第六组） |
| 最高分 | 45（第四组） |
| 有效分数 | 53，75，73，70，68，76，62 |
| 最终平均得分 | 68 |
Q&A
- 第一组的问题
Q1:是否考虑在beta和alpha这段期间继续完成alpha未完成的任务?
A1: 当然会接着完成未完成的任务，我们在beta阶段来临之前尽力完成alpha阶段落下的工作量。
Q2:组内前后端的任务分配似乎存在问题,有考虑相应的解决对策吗?
A2: 前后端在人手分配上确实是存在着问题，导致现在前端需要的工作量太大，现在我们调整了策略，每个前端负责各自部分工作外再完成各种部分前端的代码。
Q3:是否考虑过高并发场景下的服务器表现？
A3: 这个问题目前没有考虑过，因为有些功能还没有完成，不过考虑到各个小组内部的数据量并不会过大，而且服务器的表现如何还和价格成正比，这方面目前不会去深究。
- 第二组的问题
Q1:签到功能是否会被虚拟定位而进行不正确位置的签到？
A1: 因为签到功能的人手缺失，暂时延后开发，该问题其实之前有回答过，就是辅助加上ip地址的限制
Q2:PPT中的指定wifi签到是什么意思？
A2: 即通过连入wifi所分配的ip地址限制签到
Q3:如果成员没有打开小程序，是否会提醒发布的通知或者被邀请进的投票？
A3:可以做到的话会加入提醒的弹窗，配合已有的通知功能
- 第四组的问题
Q1:未提问
A1:
Q2:未提问
A2:
Q3: 未提问
A3:
- 第五组的问题
Q1:有没有考虑美化一下界面，或则说换一个界面风格？
A1:
Q2:队友退出没留下任何代码，可以理解为该队员没有写过代码吗
A2: 。
Q3:共享编辑是你们的主要功能，为什么在前端方面需要三十多个页面呢？
A3:
- 第六组的问题
Q1:在队友退出的情况下，你们组是怎样调整分工的？
A1: 队友退出，对应负责的功能目前我们是采用大家一起做，先做完对应功能的同学来负责
Q2:在后续的作业中有没有想要采取哪种方法来避免代码丢失的情况？
A2: 对于代码丢失这个问题，我们目前代码是进行一更新一github的方法，及时对代码进行更新，以避免丢失
Q3:前端在页面较多的情况下，有考虑什么方法来使页面更加方便自己制作来减轻压力？
A3: 我们目前调整了工作方式，由对应功能的前端和后端一起负责该功能，一方面减小前端压力，另一方面提高项目整体可行性。
- 第七组的问题
Q1:投票功能里小组选择，小组是指微信群聊吗？如果是的话，即使该群聊不在通讯录里面，也能检测到吗？
A1: 小组是事先建好的工作小组，组别id是存在后端的，不是微信小组。发起人可创建小组，后来的人凭链接加入。
Q2:共享编辑，别人编辑的时候，是整篇编辑，还是只能一次编辑一段？如果是整篇编辑，合并的时候只想合并某几段，不想全部替换，要怎么做？
A2: 对已发布文章按段处理，会显示更改日志，不用改全篇。
Q3:现阶段开发进度未涉及到核心，为什么不优先开发核心功能。
A3: 核心功能其实也已经实现的差不多了，只是前后端未对接，算法已经OK了。
- 第八组的问题
Q1:团队分工有没有值得总结的地方？可以分享下
A1:
Q2:对alpha版本的完成度如何自我评价？吸引
A2:
Q3:beta版本对分工和进度跟进有什么改进的想法？
A3:
- 第九组的问题
Q1:你们觉得你们最重要的特色功能是什么？你们打算怎么实现？
A1: 共享编辑，使得文本内容共享可修改，类似于github的团队提交模式，在此基础上附带上版本的回退功能。
Q2:你们对自己的进度有具体的把握吗？分工和合作上是不是存在问题？
A2: 会根据具体的完成情况调整进度安排，但是总的来说危机感，紧迫感不够，后续要加强。分工合作后续也会调整。
Q3:你们打算如何对代码进行管理不会丢失
A3: 代码有进展及时签进github。
Part 4.PSP与学习进度条
- 个人PSP
| PSP | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | ||
| · Estimate | · 估计这个任务需要多少时间 | 10 | 10 |
| Development | 开发 | ||
| · Analysis | · 需求分析 (包括学习新技术) | 30 | 90 |
| · Design Spec | · 生成设计文档 | 10 | 0 |
| · Design Review | · 设计复审 (和同事审核设计文档) | 10 | 0 |
| · Coding Standard | · 代码规范 (为目前的开发制定合适的规范) | 0 | 0 |
| · Design | · 具体设计 | 10 | 60 |
| · Coding | · 具体编码 | 120 | 240 |
| · Code Review | · 代码复审 | 0 | 0 |
| · Test | · 测试（自我测试，修改代码，提交修改） | 10 | 30 |
| Reporting | 报告 | ||
| · Test Report | · 测试报告 | 0 | 0 |
| · Size Measurement | · 计算工作量 | 10 | 10 |
| · Postmortem & Process Improvement Plan | · 事后总结, 并提出过程改进计划 | 10 | 10 |
| 合计 | 240 | 450 |
- 个人学习进度条（每周追加）
| 第N周 | 新增代码（行） | 累计代码（行） | 本周学习耗时(小时) | 累计学习耗时（小时） | 重要成长 |
|---|---|---|---|---|---|
| 10 | 100+ | 2600+ | 28 | 118 | 前后端交互，API调用 |
