项目Postmortem
设想和目标
- 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
我们的软件针对的是福大学子来到食堂会犹豫不决无法决定吃什么的痛点，希望做出一款软件可以根据大家的口味帮忙决定吃什么。其中，用户只需要回答简单的问题就可以得到结果，解决了普遍存在的“选择恐惧症”。软件的定义还是比较清楚的，这来源于我们生活中自己也遇到的问题。在编写需求规格说明书时，我们对典型用户进行了清晰的定义，并且通过问卷调查明确了市场上是存在对于我们的软件的需求的。
- 我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)
原计划的目标大部分都已经完成。在实际的开发过程中，我们将一两个功能放到了beta版本实现。
核心功能有在alpha冲刺结束时按时交付。尽管这次冲刺延期了一星期答辩，但大部分功能在一周前也已经基本完成。
我们的软件分为学生端和商家端，目前完成了学生端的一个发布版本，但还没有公开向用户发布。
- 和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高，具体提高了多少，如何衡量的？
上一个阶段团队还没有开始实际开发。如果说团队现场编程作业是上一个阶段的话，我们团队的软件工程质量的确有提高。主要体现在以下几个方面：
- 任务分工更加清楚了，每个人有明确的分工，大家之间的配合也从无到有
- 有详细的文档编写、代码注释风格要求。
- 团队成员的技术水平通过学习得到了一定的提升。
- 有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
## 计划
- 是否有充足的时间来做计划?
之前有充分的时间来讨论、构想整个软件的框架，之前布置的每一项作业——立项报告、需求规格说明书、UML图绘制——都在不断地让整个软件的轮廓在我们的大脑中变得清晰。
- 团队在计划阶段是如何解决同事们对于计划的不同意见的？
在计划阶段基本没有什么不同意见的出现。
你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
有没有发现你做了一些事后看来没必要或没多大价值的事?
PM很早敲定了一些接口文档，然而后来都废弃了。接口文档最后由后端实际设计前后端逻辑和设计数据库的人来完成。可见的确PM不要涉及太具体的代码部分的内容。
- 是否每一项任务都有清楚定义和衡量的交付件?
有的。在Alpha冲刺的初期，全组成员开会最主要就是讨论清楚整个业务逻辑，讨论完业务逻辑，我们再细分出各个任务，例如前端由几个页面组成，后端要写哪些接口，要设计几个表等等，这些具体的东西就是具体的交付件。把每一项任务分配给各个人，形成详细的任务分配。
- 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
意外：
- 在计划中有没有留下缓冲区，缓冲区有作用么?
本来是没有缓冲区的。但是老师出差，答辩延期了一周。一下子，队员紧绷的神经都放松了许多。然而，这多余的一周并没有什么实际的额外效果。因为我们团队在一周前也已经基本实现了大部分的功能。新的这一周，PM为团队新制定了一些额外的目标，但基本上都没有完成。这一插曲可以反映deadline是第一生产力这个经典的大道理。
- 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
感觉目前整个团队的态势发展良好，只要维持住目前的节奏就好了。
- 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
资源
- 我们有足够的资源来完成各项任务么?
有的。前端、后端各有一位小组长。这两位同学起到了领导作用。学习资源的话，网上的资源十分丰富够用。服务器方面，腾讯云10块钱一个月的产品也是完全足够应付目前我们的玩具产品（感谢腾讯云）。
- 各项任务所需的时间和其他资源是如何估计的，精度如何?
其实一开始我们敲定了各个任务，但没有衡量这些任务的完成所需时间，说实话在一开始大家都是零经验，很难有个确定的数字。（赵畅：）不过这个情况在你真正去做了一定的开发后就有所改善，例如在有一天我完成用户接口后，获知写一个敲定好逻辑的接口后台代码需要的时间数据：写代码3个小时，debug+本地测试大概需要两小时。这部分时间这么长还是因为对于php和Web框架不熟悉的原因。如果把后台代码部署到服务器上让前端对接，在前端不熟练的情况下要额外多出一天的时间预算。这样子的精度还是足够的，方便PM和小组长把控进度。也方便其他成员参考，留出多少时间段来进行开发。
- 测试的时间，人力和软件/硬件资源是否足够?
测试的时间和人力不足够，感觉软件还有很多缺陷，代码也不够完善。大家学习开发知识的同时还要应付考试，为了完成基本功能就已经费神费心，基本任务完成就感觉已经可以交付了，对于测试和代码的健壮性不是太上心。
- 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
（PM：）是。将头脑里的设想付诸实际，其实是一件很难的事，在项目中的体现就是虽然阅读了《material design》的设计教程，但要真正做出符合设计规范的UI界面比想象中困难很多。
你有没有感到你做的事情可以让别人来做（更有效率）?
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
（恒达：）任务deadline的提前量如果能更精确就好了，这样子有利于项目进度的把控。前端界面要个确定的Ui和审美规格，重写3次才用框架的我眼泪掉下来。
变更管理
- 每个相关的员工都及时知道了变更的消息?
Alpha冲刺时每两日一次的站立会议交流算是一个很好的方法。此外，线上交流很方便。如果有线上聊天解决不了的技术细节问题，组内（前端组、后端组）或者整个项目组就会进行团队现场编程来面对面解决。
- 我们采用了什么办法决定“推迟”和“必须实现”的功能?
必须实行的功能就是项目的核心功能和Alpha冲刺实际开发过程中遇到困难较小的功能。
推迟，一般是因为这个功能可能需要较大的工作量而Alpha冲刺的时间所剩无几，这时大家就做出推迟到Beta冲刺时完成的决定。
- 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
在需求规格说明书中的“Alpha验收标准”有清晰的定义。
- 对于可能的变更是否能制定应急计划?
因为需求和项目的具体逻辑是组内制定的，好像也没有那种变化程度太过急剧或者有提出什么十分刁钻的需求以至于要到“应急”的程度吧。
- 员工是否能够有效地处理意料之外的工作请求？
项目初期对于任务的划分基本上涵盖了整个Alpha冲刺过程。几乎没有意料之外的工作变更。一般来说组长布置给组员的额外的一些小任务（例如多加个按钮，某个逻辑有点什么小变更，多写个接口之类的）团队成员也可以及时地完成。
- 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
设计/实现
设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
一开始准备阶段就完成粗略的原型， 由 PM 实现，时间合适， 是不是适合的人...emmm...应该是了设计工作有没有碰到模棱两可的情况，团队是如何解决的？
团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
并没有很严格地进行Code Review，大致merge到master大部分都是自己在进行的，部分存在没有完全遵守代码规范的情况。我的部分我觉得是没问题的个人认为还是时间成本的问题吧，但还是应该规范起来，提高代码的整体质量。测试/发布
- 团队是否有一个测试计划？为什么没有？
无 是否进行了正式的验收测试？
团队是否有测试工具来帮助测试？
团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
在发布的过程中发现了哪些意外问题？
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
团队的角色，管理，合作
团队的每个角色是如何确定的，是不是人尽其才？
是, 分工还是较为合理的，大部分人都能做自己擅长的东西。团队成员之间有互相帮助么？
有的，自己Android也写的比较多，遇到的坑，爬出来的坑，相对而言多一些吧，同组的遇到问题时，能给予一些帮助。使
用过的工具也较多一些，也能给出一些推荐。当出现项目管理、合作方面的问题时，团队成员如何解决问题？
我所接触中并没有遇到什么特别大的问题，最多就是一些细节问题上的探讨，将细节敲定下来就可以。每个成员明确公开地表示对成员帮助的感谢 （并且写在各自的博客里）：
我感谢 王彬 对我的帮助，因为某个具体的事情: 由于自身原因这阶段的事情比较多，很多时候没法很好地平衡各个事情
的优先级。然后有时候，进入无应答状态......。然后就催促我，emm.. 然后优先级就上升了...然后得以能做完既定的东西...。我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
如果是对于我个人而言，可能需要做的就是再肝一些吧，但这学期开头肝了一个多月，快两个月吧，所以有点想进入点养生状态，
所以这阶段即使有熬夜也没有特别晚就只到一点多两点左右，每天差不多可以说是事情都排得挺满的，也勉强完成。
总结:
你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
规范阶段吧，还有一些东西能再规范一些。你觉得团队在这个里程碑相比前一个里程碑有什么改进?
你觉得目前最需要改进的一个方面是什么?
对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | ||
| · Estimate | · 估计这个任务需要多少时间 | 0 | 0 |
| Development | 开发 | ||
| · Analysis | · 需求分析 (包括学习新技术) | 0 | 0 |
| · Design Spec | · 生成设计文档 | 10 | 10 |
| · Design Review | · 设计复审 | 0 | 0 |
| · Coding Standard | · 代码规范 (为目前的开发制定合适的规范) | 0 | 0 |
| · Design | · 具体设计 | 10 | 5 |
| · Coding | · 具体编码 | 50 | 50 |
| · Code Review | · 代码复审 | 0 | 0 |
| · Test | · 测试（自我测试，修改代码，提交修改） | 0 | 0 |
| Reporting | 报告 | ||
| · Test Repor | · 测试报告 | 0 | 0 |
| · Size Measurement | · 计算工作量 | 10 | 10 |
| · Postmortem & Process Improvement Plan | · 事后总结, 并提出过程改进计划 | 5 | 5 |
| 合计 | 85 | 80 |
学习进度条
| 第N周 | 新增代码行 | 累计代码行 | 本周学习耗时(小时) | 累计学习耗时(小时) | 重要成长 |
|---|---|---|---|---|---|
| 1 | 600 | 600 | 20 | 20 | 1. dl4j库的使用 keras模型导入java 2. k-means java实现 3.水平投影图像分割 |
| 2 | 1400 | 2000 | 30 | 50 | 1. dl4j nd4j 踩坑 |
| 3 | 800 | 2800 | 25 | 75 | 1.dl4j库存在问题(GitHub上有相同的issue) 2.准备使用dl4j训练模型 3.复习了一些Android知识 |
| 4 | 800 | 3600 | 30 | 105 | 1.使用dl4j完成模型建立 2.处理数据集 |
| 5 | 600 | 4200 | 40 | 145 | 1.dl4j训练模型 2.keras完成InceptionNet(triple loss) 3.数据集收集与处理 |
| 6 | 300 | 4500 | 15 | 160 | 1.沟通与项目整合 2.keras重新训练ResNet50 3.flask完成接口 |
| 7 | 300 | 4800 | 25 | 185 | 1.复习 GRU LSTM 相关知识 2.学习word embedding, word2vec, Glove |
| 8 | 200 | 5000 | 15 | 200 | 1.复习Android自定义View的一部分知识 2.学习Robot Framework |
| 9 | 1300 | 6300 | 15 | 215 | 1.完成alpha相应任务 2.完成自己手头上的一些任务 |
| 10 | 500 | 6800 | 10 | 225 | 1.大部分时间投入复习要考试的科目 |
扫一扫
188
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
