事后诸葛亮--Alpha版本总结

目录

• 设想和目标
• 计划
• 资源
• 变更管理
• 设计/实现
  • 测试/发布
  • 团队的角色，管理，合作
• 总结:
• 本小组和其他组的评分
• 分工和贡献分
• 全组讨论的照片
• 问题
  • 第一组提问回答：爸爸饿了队
  • 第二组提问回答：拖鞋旅游队
  • 第三组提问回答：很行队
  • 第四组提问回答：火箭少男队
  • 第五组提问回答：起床一起肝活队
  • 第七组提问回答：第三视角队
  • 第八组提问回答：小白吃队
  • 第九组提问回答：我的头发呢队
• PSP
• 个人学习进度条

组长博客链接：https://www.cnblogs.com/heihuifei/p/10055777.html

设想和目标

1.我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？

• 我们软件解决的问题是：人们日常并行事项越来越多，而人的记忆是有限的，我们的记忆罐头这款
  备忘录可以有效的提醒和安排日常事务，并且提供众多便捷、智能、实用的功能。

• 已经定义的十分清楚。（详情可参见需求分析报告）

• 典型用户为：学生党和工作党。（在需求分析课堂展示中已有描述。）

• 典型场景：佩佩和小柯的故事。（在需求分析课堂展示中已有描述。）

2.我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？

• 已达到目标，原计划功能已完成6个：备忘录的基础使用、天气分析、智能提醒、App使用分析、语音输入、智能识别短信。剩下1个需在Beta版本完成：形成语音输入小浮标。

• 在Alpha版本规定时间完成交付。并进行Alpha版本课堂展示。

3.原计划达到的用户数量达到了么?

• 原定计划中未对用户数量做出明确定义。用户量还需要在Beta版本完成之后进行推广获取。

4.用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?

• 暂时还未进行推广，因此还没有用户量。离目标更近一步。

5.有什么经验教训? 如果历史重来一遍,我们会做什么改进?

• 应该在开始的时候目标定得更明确一些。如果重来一遍的话，我们会加上对后期用户量的明确目标以及设想的更加细致。

计划

你原计划的工作是否最后都做完了? 如果有没做完的，为什么?

• 在alpha版本的原计划的数据库初始化和接口的实现任务最后都完成了，剩下的是beta版本的用户登入和云端备份的实现；原计划的前端功能都已经实现，现在缺少的是页面的精修，在美观上还需要改进。

有没有发现你做了一些事后看来没必要或没多大价值的事?

• 在android stdio的下载上花费了很长时间，至少有两天，出现各种问题。以及在代码整合的过程中，出现有些人代码可以运行，但是有些不能运行的情况。在软件的问题上出现很多错，但是有很费时。项目初始计划是做服务器上的数据库和接口，但是这样会导致手机在没有网络的情况之下，加载不出数据，整个软件会处于不能使用的状态，这和我们这样一个备忘录app的用户使用场景出入很大。发现问题之后决定将数据库部署在本地。还有就是接口设计的时候，其实有些功能前端可以直接实现的，不需要对应的接口，常常设计出前端不需要的接口；

是否每一项任务都有清楚定义和衡量的交付件?

• 在后端部分，数据库和接口的设计我们是有在需求文档中做了详细的规划，根据软件的原型和需求，规范地设计数据库和细致地设计接口的，数据库表结构和接口需求明确之后才进行的代码实现，所以在于整个项目的开发中，任务和进度是很精确的，也提供测试样例作为参考。

是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?

• 后端部分，是先根据原型和需求，数据库表结构和接口需求明确之后才进行的代码实现的，按照文档一步步实现的，期间由于对java和AndroidStudio开发的不熟悉，有时在数据库初始化和sql语句上出现问题；风险的话因为做的功能是相对简单和基础的部分，可能在安全系数和数据库版本升级的部分没有做的详尽；对于将来服务器安全部分会考虑加强安全性的途径；

在计划中有没有留下缓冲区，缓冲区有作用么?
将来的计划会做什么修改？（例如：缓冲区的定义，加班）

• 计划的实施都是在大家都有空的时候，一起进行的。各自在平时有空的时候自行学习和code，也会互相分享经验，任务完成的也相对高效紧凑，没怎么需要加班；一起code的时候，一般都是任务完成到预期进度才各回各家；将来的计划，我觉得这种状态挺不错的（毕竟大家有不同的课业需要兼顾），可能会多一项在固定时间互相交流学习内容和实现思路，这样对接下来计划的实现思路会更加明确；不过在每天的任务中难免存在难度无法做完的情况，我们会选择熬夜完成项目。

我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

• 对于后端能实现来说，由于第一次做，对于任务量的不熟悉，在分配任务的之后，会导致有的成员天天埋头苦干，有的则无所事事，还有就是不同成员在学习重复的知识，这样使任务的完成度参差不齐，也降低效率；如果历史重来一遍，会对任务进行详尽的分析，明确技术难点和工作量，然后进行任务分派，在提高效率上应该会有所成效；同时，我们可能会选择多增加代码规范性的了解，在页面的设计上也会稍加改进。

资源

我们有足够的资源来完成各项任务么?

• 有足够的资源来完成各项任务。团队人才济济。

各项任务所需的时间和其他资源是如何估计的，精度如何?

• 各项任务所需时间及其他资源是询问前辈的经验以及在开发过程中不断更新考量估计的，精度不太准确，出现超时完成任务的情况。

测试的时间，人力和软件/硬件资源是否足够?对于那些不需要编程的资源 (美工设计/文案)是否低估难度?

• 并未低估文案和美工设计的难度，在最开始的时候便分配了专员负责这两个模块。测试时间安排不太合理，暂未分配测试时间。

你有没有感到你做的事情可以让别人来做（更有效率）?

• 我觉得我做的事情，让一个心思缜密的组员都能做的不错。

有什么经验教训? 如果历史重来一遍, 我们会做什么改进?

• 分配任务的时候会对任务进行详尽的分析，明确技术难点和工作量，然后进行任务分派，能够让大家都轻松高效的完成项目

变更管理

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

• 如果有变更的消息的话，员工们都能从员工群里面获取实时的变更消息，此外在相关员工的小组群里面也会有变更消息的提醒，这样保证了每个相关的员工都能够及时知道变更的消息。

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

• 在项目初期，员工们对于自己负责部分的功能有粗浅了解之后，员工们根据功能的实现难度判断功能属于“推迟”或“必须实现”的功能，然后在开会期间提出该议题（若无提出，默认“必须实现”），经过讨论（参照功能是否为必须实现的主要功能、关键功能）后，采取集体投票的方式最终决定该功能属于“推迟”或“必须实现”的功能！

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

• 对于我们的项目，我们首先规定了一些基本功能，在最后完工时，这些基本功能就是我们的项目的出口条件。

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

• 是的！俗话说计划赶不上变化，我要以不变应万变，根据自己所学的和所看的书结合实际情况，做出判断。接着进行罗列出可行的计划，然后进行选择，选出比较好的几个应急计划，再对各个计划、各种方案的优缺点以及成本进行筛选。

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

• 我们的员工在收到意料之外的工作请求时，会先确认其来源的需求，在确认无误并没有异议的情况下，能够合理协调自己的安排以满足目前的总体需求。

我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

• 首先，每个员工在技术知识方面都或多或少有所收获，或是前端页面方面、或是后端接口编写方面等，此外我们的每个员工都对一个app的开发流程有了一定的了解，而不是负责某一部分就只了解该部分的内容；其次，我们积累了一些开发经验，在某些问题的解决上有了解决方法；此外，我们还认识到了软件开发团队中员工之间的团结协作和交流沟通是十分重要的，如果一个团队能够团结协作并积极地交流沟通，那么这个团队的状态是健康积极的，软件的开发便能顺利愉悦地进行，相反地，如果一个团队有大大小小的各种矛盾，那么这个团队的状态是不健康的，甚至很可能影响到软件开发的进度。如果历史重来一遍，我们会请教有过项目开发经验的学长或学姐更具体的开发流程细节，更好更快地完成我们项目的分工部分，为开发过程中的“bug”留下更充足的时间；其次，我们会更加注重开发的“规范化”，比如每两天写学习总结，将开发过程中遇到的问题的可行解决方法写成技术文档等；此外，我们会在团队成员之间的团结协作和积极交流方面做得更好！

设计/实现

设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？

• 原型的设计工作是卉卉做的，之后迭代是丹丹完成的。原型的设计工作在团队选题报告之后重新设计的，一方面让新队员卉卉熟悉了我们的项目，我们认为让她来做是比较合适的。（卉：界面丑其实是我的锅orz）

• 数据库和接口的设计是由后端部分的家灿和卉卉在选题报告之后一起讨论完成的。

设计工作有没有碰到模棱两可的情况，团队是如何解决的？

• 负责的原型设计的同学在群里发布了很多版本，其他组员也提了许多意见，最终确定了最终版本。

• 后端的设计工作在后面的代码实施阶段遇到了一些分歧，也是通过后端组内讨论解决的。

团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？

• 后端是在Androidstudio里进行的单元测试，后端同学表示Androidstudio自带的测试环境比较方便也挺好用的。

比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？

• 差距还是比较大的，区别是在开发过程中发现UML文档的东西不适应项目的开发，需要改变。需要更新UML文档以适应。

什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?

• 基础功能中的备忘录展示，因为对android开发不熟悉，自定义控件的使用不熟悉，导致书写的过程出现很多问题。发布之后，语音插入之后完成时间是已过期，删除功能不完善。开发的时候因为alpha版本时间有点赶，未进行完整的测试。

代码复审（Code Review）是如何进行的，是否严格执行了代码规范？

• 无，并未严格执行代码规范。

我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

• 学到了如何开发一个项目的全部流程，以及如何有效的分工。同时，每个组员对前后端的交接有了完整的理解。如果历史能重来，我们会在一开始就进行代码规范，以及代码复审，这才是软工实践的最大意义。以及合并时采用GitHub，让合并更加高效。

测试/发布

团队是否有一个测试计划？为什么没有？

• 测试计划分为四个方面：

1. 测试壁纸是否可以自动生成
   可自助选择壁纸格式，字号大小，字号颜色，自动生成桌面壁纸
2. 测试快递，车票信息是否可以自动生成
   接受车票，快递信息，生成备忘信息
3. 测试是否可以新建备忘信息
4. 测试语音转文字功能
5. 测试删除选中功能
6. 测试反馈功能
7. 测试桌面控件功能
   在测试过程中，及时消除bug和解决软件闪退问题。

是否进行了正式的验收测试？

• app在桌面可安全开启，并完成测试计划提到所有功能，有视频展示。

团队是否有测试工具来帮助测试？

• 测试计划分为前端，后端两个部分。
  前端测试利用Android studio进行build，build成功后按三角运行按钮，电脑与安卓机利用数据线相连，授予USB访问权限，运行成功后，创作界面会在安卓机自动显现。
  后端利用Android studio里的junit进行测试，测试失败会显示错误。

团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？

• 我们的后端已经写了一份单元测试来进行测量并跟踪软件的效能。从实际运行结果来看，这些测试工作是非常有用的。我们应该适当地丰富测试文件的内容。

在发布的过程中发现了哪些意外问题？

• 由于我们在打包APK的过程中，想要将所有的部分调整到最好，导致没有将APK打包好。

我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

• 我们对前端，后端的部分从一无所知或者只知道大概，到对整个开发流程和APP有了很详细的了解。并且明白了如何融入一个团队中，将团队变得更好。
  我们会对队员分工进行更详细得调整，将所有人都加入到开发工作的热情中。

团队的角色，管理，合作

团队的每个角色是如何确定的，是不是人尽其才？

• 角色是在先自由选择之后再由pm进行分工。尽量按照大家熟悉的且有意向的角色进行分配。总体上做到了人尽其才。

团队成员之间有互相帮助么？
当出现项目管理、合作方面的问题时，团队成员如何解决问题？

• 互相帮助是肯定存在的，经常面对面互相交流的时候就需要互相帮助，比如前端就是前端小组长
  和pm比较熟悉一些帮助另外两位队友。

每个成员明确公开地表示对成员帮助的感谢：

我感谢胡青元对我的帮助， 在我最开始调试API功能时，教会我我调试的方法。

我感谢葛家灿对我的帮助， 在我最开始学习API时，由于我的电脑不能正常使用AS，借给我电脑使用了一晚。

我感谢何家伟对我的帮助， 由于我不会使用git，帮助并教会我提交git。

我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?

• 鸿杰
  大部分时候你要做的功能网络上并没有完整的代码可以“搬运”，需要你看懂网上的代码，然后根据你的功能需求自己修改代码（这步骤可以借助相关的开发文档）；
  如果历史重来一遍，我们会在分工在做的更好，合理分配人力资源到各个部分。

• 家灿
  分配任务的时候会对任务进行详尽的分析，明确技术难点和工作量，然后进行任务分派，能够让大家都轻松高效的完成项目

• 一好
  如果能重来一遍，我会对不同厂家的语音转文字API进行测试，选择最优秀的API加入到我们的APP中。我还会在Alpha版本开发时，调整自己的时间安排，完成属于自己的所有任务。

• 卉卉
  云端本地要同时进行orz

• 政演
  提前考虑应用一些前沿的技术，增加亮点

• 青元
  对任务的分配需要更加详细，学习的时间分配需要更多一点。如果重来，会增加更多的学习时间。

• 丹丹
  我在这门项目里确实学到了很多东西，对视频剪辑软件有掌握，在后面也有接触到前端学习。
  教训就是一定要下一个下一个正规的剪辑软件。前期因为电脑和安装软件不正规，导致电脑真的变得很卡。
  重来一遍的话，我一定会更加认真的完成这份工作，更加珍惜现有的资源，好好学习前端。

• 家伟
  相比于一步步按源码用到的知识片面学习Android知识，先系统的学习Android基础知识会对在app中实现功能有很大的帮助。
  重来一遍的话，我将前期的任务设为系统地学习Android基础。

• 宇恒
  如果历史重来一遍, 我们会做什么改进? 答：在时间安排上过于集中，如果再来一遍，会把任务分配到每天。

• 绪佩
  在开始做之前应该多问一下有开发经验的前辈，询问清楚不懂的地方，这样开发的时候可以节省很多时间和多余的工作。

• 恺琳
  在了解自己的任务同时也了解别人的任务，在交流中能更好地理解

总结:

你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?

• 可重复级(Repeatable)
  在一次次团队项目中，我们团队建立了较明确的管理制度和贡献分分配规则。每次项目结束后都会进行反思和总结，且能够据此做出改进并较为详细地确定下一阶段应实现目标。

你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?

• 处于规范阶段
  经过alpha冲刺和团队现场git后，团队成员已经进行了足够多的磨合，有了充足的协作编程经验；目前我们所欠缺的是相互之间代码等达到“规范”这一要求。

你觉得团队在这个里程碑相比前一个里程碑有什么改进?

• 目前（alpha阶段）相比于上一个里程碑（需求分析），团队整体的技术水平有了很大程度的提升，团队协作能力++。

你觉得目前最需要改进的一个方面是什么?

• 编码规范是我们目前最需要改进的方面。

对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。

• 在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈
  我相信，在alpha冲刺阶段中，我们团队的面对面交谈/编码时间能够在所有团队中排在前几甚至是第一。
• 每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。
  即使除去alpha冲刺两天一次的站立会议，我们团队仍能够保持平均每周1.5次以上的线下会议频率，并在会议上对近期工作做出汇报、总结及相应调整。

本小组和其他组的评分

分工和贡献分

成员	比例
绪佩	13%
青元	13%
宇恒	7%
恺琳	7%
政演	6.5%
一好	6.5%
丹丹	7%
鸿杰	11%
家伟	11%
家灿	9%
卉卉	9%

全组讨论的照片

问题

第一组提问回答：爸爸饿了队

Q1：团队没有使用GIT进行版本管理,是否考虑在之后使用git进行版本控制

答:感谢提问，谢谢你们的提醒，我们Alpha版块还没有进行Git整合，在Beta版本这方面会选择进行Git版本整合的。

Q2：备忘壁纸功能所选的壁纸似乎会影响备忘内容的可读性?

答:感谢提问!这个问题我们我们有考虑过，以前也有具体回答过，在壁纸方面我们进行了多种设计来避免壁纸内容遮挡备忘录，排版合理，尽可能完全清晰的展现备忘录。

Q3：语音部分的功能在嘈杂环境中的表现有相应测试吗?

答:感谢提问!语音功能有进行初步检测，但因为我们的主打功能不在此，并没有具体的去增强语音识别功能，后续如果有时间精力的话，会考虑在这方面进行改善。

第二组提问回答：拖鞋旅游队

Q1：生活助手界面的优先级“无”是什么意思？

你好，我们对所有备忘都设置了一个可选填的优先级选项，如果备忘存存在优先级会按高低进行排序，不存在优先级的话按到期时间进行排序。

Q2：打开文件获取图片信息是用来编辑锁屏界面的信息吗？

你好，不是用于编辑屏锁界面的，只是针对备忘保存图片。

Q3：是否有用户信息界面来展示信息以及对备忘录记录任务的完成度展示？

你好，我们首页设置了三个列表来展示备忘任务的完成情况，分别是近期待完成、超时未完成、已完成任务，并可对这三个列表的已有备忘进行修改跟删除。

第三组提问回答：很行队

Q1：设计主界面采用流动的消息条,是否考虑会造成视觉疲劳？

后期我们的美工和前端会对界面的美观进行修缮。

Q2：说到算法,有想过提高一下算法吗

我们会对一些算法进行改进。

Q3：界面的整体风格好像有点普通,可以考虑简化一下界面,很好看？

前端在下一阶段的任务就要包括对界面进行优化的任务。

第四组提问回答：火箭少男队

由于对方队伍提交问题的时间太晚，故暂不做回答。

第五组提问回答：起床一起肝活队

Q1：语言转文字功能目前只能对接百度的，如果某天百度的接口取消了，要怎么办呢？

感谢提问！百度语音识别的功能现在已经和百度输入法，魅族输入法等手机品牌的输入法在合作中，并且手机百度，爱奇艺等平台的语音搜索功能也是建立在百度语音识别这个项目上的。如果有一天百度关闭了这个api那想必是百度搜索不想做下去了，放弃了这么简便的输入方式。再者现在是人工智能飞速发展的时代，语音识别也处于这个范畴中，再加之百度近期将其api免费提供给开发者们使用，证明这个api还有很大的发展空间，是不会关闭的。

Q2：某些背景会影响阅读，是否会考虑在用户设置壁纸时提醒用户的功能？
感谢提问！这个功能是通过用户可以选择的开关来设置的，所以说这个功能的开关可以由用户自己决定。我们后端和前端同学在设计这个功能时会考虑到包括影响用户体验在内的各种情况，尽努力使用户体验达到最佳。

第七组提问回答：第三视角队

Q1：你们的订单信息和快递信息之间有什么差别？

感谢提问！订单信息指的是汽车票、动车票和飞机票等出行信息，而快递信息便是字面上的快递取货信息。我们在最后的对接过程中没有注意到这一细节，在之后的代码整合时我们会多加注意，避免这一失误再次发生。

Q2：为什么你们展示的时候，生成壁纸那一块，锁屏的壁纸展示还留着“生成壁纸”按钮和“取消”按钮？还有，你们的生成壁纸支持预览吗？

我们"生成壁纸"这一功能目前仅做到初步实现，在后续的版本迭代过程中我们会进行持续优化改进；生成壁纸支持预览功能。

Q3：如果百度的接口哪一天不提供对外使用了那语音输入是不是就废了？
百度接口不予外用的话，考虑到自主实现效果不佳，我们比较倾向先寻找其它接口进行代替；在之后算法能力提升后会考虑自主实现。

第八组提问回答：小白吃队

Q1：对于算法方面是合理调用网上接口，后期会考虑自己来做语音识别嘛？

我们语音识别是直接调用的百度提供的识别接口，由于这个自主实现的效果和网络上的接口出入很大，考虑到用户体验和识别的精确度，还是倾向于直接使用百度接口。

Q2：如何统一美化ui界面？

对于ui界面，确实做的不够美观，改进思路是：参考现在发行的各种备忘录类的软件，博采众长，进行组内讨论和问卷调查等形式，确定ui界面的美化方向；

Q3：对于识别快递信息是直接通过单号来提取信息的嘛？

快递信息的识别，是根据短信的内容，直接识别的，（正则表达式），我们没有做物流信息的同步，只是对收到到取货信息的短信进行识别；

第九组提问回答：我的头发呢队

由于对方队伍提交问题的时间太晚，故暂不做回答。

PSP

PSP2.1	header 2	预估耗时（分钟）	实际耗时（分钟）
Planning	计划	50	30
· Estimate	·估计这个任务需要多少时间	20	30
Development	开发	150	120
· Analysis	需求分析（包括学习新技术）	60	60
· Design Spec	· 生成设计文档	0	0
· Design Review	· 设计复审	0	0
· Coding Standard	· 代码规范 (为目前的开发制定合适的规范)	0	0
· Design	· 具体设计	80	50
· Coding	· 具体编码	10	20
· Code Review	· 代码复审	0	0
· Test	·测试（自我测试，修改代码，提交修改）	0	0
Reporting	报告	10	10
· Test Repor	· 测试报告	0	0
· Size Measurement	· 计算工作量	0	0
· Postmortem & Process Improvement Plan	· 事后总结, 并提出过程改进计划	20	20
合计		350	400

个人学习进度条

第十一周	新增代码（行）	累计代码（行）	本周学习耗时（小时）	累计学习耗时（小时）	重要成长
1	100	100	5	5	复习C++
2	200	300	20	25	C++熟悉，对文件读取分析方法
3	0	300	7	32	Axure rp 8使用 熟悉NABCD模型
4	300	600	44	76	使用C++编写爬虫程序
5	0	600	15	91	详细了解需求规格说明书以及接口文档书写
6	0	600	22	113	与团队一起进行需求报告的书写
7	600	1200	11	124	学习如何调用百度语音API，懂得AS基础使用方法和构建APP的基础方法
8	700	1900	67	193	完善百度语音Api调用，实现简易悬浮窗