标签：修改   版本升级   ade   访问权限   合作   基础功   失败   交互   body   

目录

• 设想和目标
• 计划
• 资源
• 变更管理
• 设计/实现
  • 测试/发布
  • 团队的角色，管理，合作
• 总结:
• 贡献分
• 全组讨论的照片

设想和目标

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有了很详细的了解。并且明白了如何融入一个团队中，将团队变得更好。
  我们会对队员分工进行更详细得调整，将所有人都加入到开发工作的热情中。

团队的角色，管理，合作

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

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

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

我感谢++青元++同学对我的帮助， 因为某个具体的事情: 分享前端界面和交互过程的理解，有助于接口的设计和实现。

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

总结:

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

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

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

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

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

贡献分

全组讨论的照片

事后诸葛亮博客

标签：修改   版本升级   ade   访问权限   合作   基础功   失败   交互   body   

原文地址：https://www.cnblogs.com/dalegac/p/10055790.html