Alpha版本过后诸葛亮

目录

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

组长博客连接：http://www.javashuo.com/article/p-buzkaxpo-gk.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比较熟悉一些帮助另外两位队友。

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

我感谢一好对个人帮助， 由于在合并语音输入和主页面的功能的时候出现了bug，咱们找了很
久没有解决，最后是一好回宿舍以后解决的。

咱们学到了什么? 若是历史重来一遍, 咱们会作什么改进?
有什么经验教训? 若是历史重来一遍, 咱们会作什么改进?

• 鸿杰
  大部分时候你要作的功能网络上并无完整的代码能够“搬运”，须要你看懂网上的代码，而后根据你的功能需求本身修改代码（这步骤能够借助相关的开发文档）；
  若是历史重来一遍，咱们会在分工在作的更好，合理分配人力资源到各个部分。

• 家灿
  分配任务的时候会对任务进行详尽的分析，明确技术难点和工做量，而后进行任务分派，可以让你们都轻松高效的完成项目

• 一好
  若是能重来一遍，我会对不一样厂家的语音转文字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	· 具体设计	40	50
· Coding	· 具体编码	30	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
合计		240	300

我的学习进度条

第N周	新增代码（行）	累计代码（行）	本周学习耗时（小时）	累计学习耗时（小时）	重要成长
1	391	391	25	25	复习c++，学习单元测试和代码覆盖率，更熟悉Visual Studio的使用
2	100	491	5	30	在优化代码和改bug
3	0	0	15	45	阅读《构建之法》第三章和第八章，学习使用Axure RP8，对UI设计有进一步了解和认识，对项目开发架构进一步的理解
4	441	932	25	70	对爬虫初步认识，还有待学习（队友负责模块），Debug能力++；
5	0	932	15	85	详细了解需求规格说明书以及接口文档书写
6	232	1164	20	105	学习基础前端界面布局及学习思惟导图制做
7	597	1761	20	125	学习前端交互，查资料能力++，对前端认识愈来愈深，恐惧愈来愈大，懂得作一个项目的艰难！
8	323	2084	40	165	前端细节控件监听，checkbox等等的熟悉、页面跳转的学习