链接部分
队名：女生都队
组长博客： 博客链接
作业博客：博客链接
一、设想和目标
1、我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
- 我们软件解决的问题是：帮助用户以科学的方式养成良好的生活习惯，在必要的时候发送给他们一些生活习惯类小提醒，帮助用户提升生活幸福感。同时，能够以宠物陪伴的方式来帮助用户更好的完成自己定义的任务及系统的旅程任务。
- 已经定义的十分清楚。（详情可参见 需求分析报告PDF 提取码: x24e ）
- 典型用户为：广大年轻一辈（12岁-32岁）人群 。（在需求分析报告PDF 提取码: x24e 中已有描述）
- 典型场景：福大学生——小陈。（在需求分析报告PDF 提取码: x24e 中已有描述）
2、我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)?
- 还未完全达到目标，原计划功能已完成6个：登陆注册、添加打卡任务、和“我”说话、显示任务列表、旅程分类、天气提醒推送。剩下的任务将在Beta版本完成。
- 在Alpha版本规定时间完成交付。并进行Alpha版本课堂展示。
- 原定计划中未对用户数量做出明确定义。用户量还需要在Beta版本完成之后进行推广获取。
3、用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
- 暂时还未进行推广，因此还没有用户量。离目标更近一步。
4、有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
- 应该提前对项目的整个开发流程以及可能会遇到的问题进行预测，未雨绸缪，并且提前制定好各阶段详细的人物及交付时间。如果重来一遍的话，我们会严格要求按照指定的交付时间进行项目的完成，并且根据每次完成的情况适当调整下一次的任务安排，并且会提前制定好后期用户量的明确目标。
二、计划
1、是否有充足的时间来做计划?
- 计划是有的，但是由于各种不可抗力的原因，最后的实施有所偏差
2、团队在计划阶段是如何解决同事们对于计划的不同意见的？
- 沟通是最有力的方式，尽量找到一个大家都较为满意的方案
3、你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
- 原来的计划在连续肝了几晚后基本都完成了；不过在前后端对接上还是有不少问题没解决，因为在整合项目的时候已经没什么时间了。
4、有没有发现你做了一些事后看来没必要或没多大价值的事?
- 在功能设计上有点过于复杂，给自己挖了不少坑
- 在使用后端框架上走了太多弯路
5、是否每一项任务都有清楚定义和衡量的交付件?
- 没有，由于整个项目的计划没有很顺利的进行，所以所有的标准基本都是现场沟通，再进行调整
6、是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
- 整个过程并没有完全按照计划进行
- 在项目过程中，由于没有经验，踩了很多坑，在项目对接上也有很多问题
- 风险的话在于用户的行为分析，因为实现这个的困难有点超出预计
7、在计划中有没有留下缓冲区，缓冲区有作用么?
- 有：休息休息休息！！！
- 作用就是休息之后肝的更有劲了！
8、将来的计划会做什么修改？（例如：缓冲区的定义，加班）
- 计划就是继续肝！，平时就学好自己的负责的部分，在做项目的时候就大家一起肝
- 该休息就休息，该加班就加班，没什么是熬夜解决不了的！
9、 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
- 学到了很多东西，服务器的部署、后端的搭建、界面的设计实现、数据库搭建等等
- 如果重来一遍，首先一定不要再给自己挖那么多坑了！，其次就是要加强的对任务的分析，提前学习好要用到的知识，预估好任务的困难程度，而不是到最后再修改
三、资源
1、我们有足够的资源来完成各项任务么?
- 有足够的资源来完成各项任务。我们组有前端后端算法都接触过的人，并且还有美工，人才济济，大家都相处的很好，配合都很甜。
2、各项任务所需的时间和其他资源是如何估计的，精度如何?
- 各项任务所需时间是按照从前开发的经验来看的，并且随着项目开发的过程的进度来进行不断地修改，精度不太准确，有一些之前没有遇到的bug出现，导致耗费了许多的时间，所以个别地方在alpha阶段没有及时的完成。
3、测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
- 测试的时间，人力和软件/硬件资源不足够。
- 由于后端出现了一些问题，所以在前后端交互的时候出了一些的问题，导致闪退等问题，测试出现了许多的问题。
- 并未低估难度。我们组有一个专门做美工的和专门做文案的人员，她们都能在规定时间内完成任务，并且是又快又好！（简直是太赞了！团队的效率和审美水平都被她们拉高了！）
4、你有没有感到你做的事情可以让别人来做（更有效率）?
- 我觉得我做的事情让会Android Studio的同学来做的话，完全是可以的！甚至有可能做的比我好（特别是审美和细节方面）”
5、有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
- 我们应该在分配任务的时候，尽量把每个人都分配任务，并且让每个任务都尽量详细，不会出现那种有的人不理解任务，在原地徘徊的情况，导致木桶理论，项目的总体进度被降低。并且我们应该清楚任务的难度，给任务分配相应的事件，让时间和资源达到最大化！
四、变更管理
1、每个相关的员工都及时知道了变更的消息?
- 是的，每当有变更我们会在群里艾特全体成员并告知变更细节。
2、我们采用了什么办法决定“推迟”和“必须实现”的功能?
- app的主线功能即必须实现的功能，而较为细节的功能及扩展功能则可以推迟。
3、项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
- 有，项目基本功能完整，逻辑完整，测试无bug。
4、对于可能的变更是否能制定应急计划?
- 大部分能，大部分变更还是在可控范围内的。
5、员工是否能够有效地处理意料之外的工作请求？
- 大部分情况下能，小部分情况前后端协调互助一下，最终也能处理好。
6、我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
- 学到了前后端的协调以及团队协作。如果历史重来一遍，我们在项目最开始就定好框架，前后端同时进行。
五、设计/实现
1、设计工作在什么时候，由谁来完成的？是合适的时间，合适的人吗？
- 原型设计的初稿是团队共同讨论，并由雅辉和秋琴绘制的。由于团队讨论定稿较为粗糙，之后雅芳和钰蕙对原型设计进行了修改和细化。这些工作是在进行需求分析报告的时候完成的（上一次团队作业）。在项目的开发过程中又对原型进行了调整。参与原型设计的基本是前端实现的人员，因此原型设计会根据前端人员的想法和实现情况进行更新迭代。故时间和人员都是比较合适的。
- 数据库和接口的主要设计由恩泽完成，并分配给君曦、金海进行细化。三位同学均是后端实现的同学，在开始后端工作前即完成了设计并于前端同学确定了接口的设计，时间和人员都是合适的。
2、设计工作有没有碰到模棱两可的情况，团队是如何解决的？
- 有碰到模棱两可的情况，在前端组中页面跳转的逻辑成员之间存在分歧，而后端组中对数据库设计情况也存在一些争议。
- 前端组讨论以后，决定页面调整以简洁、清晰为主，确定了最终版本。后端组的成员也通过交流和讨论确定了数据库的设计，并进行了明确的分工。
3、团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML，或者其他工具来帮助设计和实现？这些工具有效吗？
- 单元测试是在Android Studio中完成的，Android Studio的测试环境对于安卓开发友好而方便。
4、比较项目开始的UML文档和现在的状态有什么区别？这些区别是如何产生的？是否要更新UML文档？
- 区别还是比较大的。因为在项目开发过程中发现最初的文档存在一些细节模糊不清的情况，故需要进行更新，以更好的辅助开发。
5、什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的Bug？为什么我们在设计/开发的时候没有想到这些情况？
- 在开发过程中，许多功能都产生了Bug，产生功能最多的bug应该是消息推送的实现，因为团队大部分人是为了这门课程才入门相关语言和系统环境。发布之后，发现在前端中活动之间的信息传递和前后端的信息传递还存在Bug，信息存储存在问题，这是由于团队成员对于开发过程不熟悉，对于前后端交互概念较为模糊。
6、代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
- 由于时间原因我们还没有进行代码复审。但在开发前前端组和后端组的同学对于代码规范进行了讨论和规定，对于文件（或变量）的命名、代码的注释、空格和缩进等内容进行了规范，团队执行代码规范情况尚可。
7、我们学到了什么？如果历史重来一遍，我们会做什么改进？
- 我们学到了许多东西，团队成员对于项目开发的流程有了更深的理解和切实的感悟，对于一个项目开发所需的人员、工具和分工情况都有了自己的认识。如果历史重来一遍，我们会花更多时间在设计阶段对于细节进行更深入的讨论，以避免模糊不清的情况影响项目开发进度。
六、测试/发布
1、团队是否有一个测试计划？为什么没有？
- 团队是有测试计划的，在项目的开发过程中每完成一个模块都是有进行测试的，是一直都有在测试的。但是由于app没有太过完善，测试也只是一些很简单的查bug，所以没有放出来，计划后期在12月初app完善了进行黑盒测试。
2、是否进行了正式的验收测试？
- 还没有进行正式的验收测试，前端和后端在一些部分还没有完全的合并，预计在12月初开始进行测试。
3、团队是否有测试工具来帮助测试？
- 测试工具，负责测试的同学预计用GT和itest、Jmeter测试app 的性能，Android studio有可以优化的工具。
4、团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
- GT和itest这些测试工具可以测试app的效能，GT是app 的随身调试平台，可以在手机上随时查看调试。测试工作的作用，因为我们的app有常驻后台，耗电量和效能已经常驻期是必须要考虑在内并且进行一定的优化的。改进优化的地方目前想到的是减低能耗。
5、在发布的过程中发现了哪些意外问题？
- 目前app还没有到发布阶段，app的打包预期不会很大的问题，用Android studio自带的打包工具。
6、我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
- 历经数十天的熬夜团队很多从小白到可以负责前端或者后端的某一个模块了，不同的队员学到的知识不同，后端学习了如何搭建数据库，如何通过接口和前端实现联动，并且学习到了如何从云端获取实时数据，前端的队员很多有过开发项目的基础，但也学习了很多的逻辑调用方面的知识。如果历史重来一遍的话我们会提早开始开发我们的项目，熬夜实在是痛苦啊。
七、团队的角色，管理，合作
1、团队的每个角色是如何确定的，是不是人尽其才？
- 我们的团队角色确定是根据个人能力进行安排的。前端组的三名女生在AS方面比较熟练，就承担了组内前端部分的任务；后端部分由几个学习能力比较强的男生承担，相互之间合作顺利；文档、PPT、演讲等部分由代码能比较弱和在该方面有竞赛经验的同学完成。
- 总体来说我们的团队分工明确，做到了人尽其才。
2、团队成员之间有互相帮助么？
- 有。我们的团队项目很大一部分都是在一起（熬夜）完成的，在项目的完成过程中出现的问题会直接询问，现场解决；单独完成时遇到的困难也会进行线上沟通（QQ的火花就是这么来的）
3、当出现项目管理、合作方面的问题时，团队成员如何解决问题？
- 我们的消息团队在凝聚力方面做的很好，除了技术方面的问题以外其实没有什么项目管理方面的问题。各个小组的成员之间关系都很亲近，在合作沟通方面进行的 很顺利，不同的小组经历了这一段时间的磨合也很熟络，合作过程中也很顺利。
4、每个成员明确公开地表示对成员帮助的感谢 （并且写在各自的博客里）：
- 我感谢潘海东同学对我我们的帮助， 因为给我们推荐了阿里云服务器，帮助我们节省了时间。
5、我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
- 通过这次的alpha冲刺，我们在团队分工、管理、合作方面学到了：在分工的过程中要根据每个人的能力和兴趣进行分工。作为一个团队项目，合作的成功与否决定了项目是否能成功，只有每个人选择好自己的团队定位，把自己的的能力尽可能地发挥出来，才能让整个团队取得好的成绩。
- 如果再选一次的话，我们的选择依然会是这样。
八、总结
1、你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
- 初始级(initial)
工作无序，项目进行过程中常放弃当初的计划。 这或许就是我们小组Alpha冲刺时候的状态了，由于其他科目和ddl的压力，我们小组选择一切从简，复杂的项目要么删了，要么丢到Beta冲刺。 开发项目成效不稳定，项目成功主要依靠几个有能力的人（简称“大腿”）的经验和能力。希望beta冲刺的时候能达到 可重复级(Repeatable) 。
2、你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
- 处于规范阶段
我想经过了团队编程和这次Alpha冲刺，我们团队已经磨合得挺好的，但是对于团队每个人负责代码的部分并没有处理的很好，还是需要时间达到“规范”。
3、你觉得团队在这个里程碑相比前一个里程碑有什么改进?
- 目前（alpha阶段）相比于上一个里程碑（需求分析），整个团队得沟通更多了，大家在技术方面也有了很大的提升，团队的协作能力更好了。
4、你觉得目前最需要改进的一个方面是什么?
- 技术方面是我们目前最需要改进的方面
5、对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
-
业务人员和开发人员在项目开发过程中应该每天共同工作。
-
无论团队内外，面对面的交流始终是最有效的沟通方式。
- 我们小组在Alpha 冲刺阶段大部分人都是在一起编码并进行讨论的，这个比线上各自打代码效率提高许多。
- 简明为本——它是极力简化不必要的工作量的技艺。
- 小组在完成每个功能之前都会讨论下这个功能是否是我们的主体，我们经常讲当初需求报告里写的不需要得功能给删了。
团队照片
答辩总结
评估团队中每个人对本次作业的贡献比例，描述为本次作业的工作流程、组员分工、组员工作量比例
工作流程
- 组长确定每个Alpha冲刺阶段必须要完成的任务，并进行分工；
- 对分工安排进行公示，若组员提出有意义、有建设性的建议，则对相应部分进行修改；
- 组员执行分工安排，在规定时间内交付自己负责的部分；
- 组长或相关负责人进行汇总，并对格式进行订正。
| 姓 名 | 任务工作量（60） | 个人参与度（10） | 完成及时性（10） | Leader评分（20） | 得分（100） | 贡献比例(%) |
|---|---|---|---|---|---|---|
| 恩泽 | 60 | 10 | 10 | 20 | 100 | 12.0 |
| 秋琴 | 60 | 10 | 10 | 20 | 100 | 12.0 |
| 雅芳 | 60 | 10 | 10 | 20 | 100 | 12.0 |
| 钰蕙 | 60 | 10 | 10 | 20 | 100 | 12.0 |
| 银山 | 40 | 9 | 10 | 15 | 74 | 8.8 |
| 季城 | 40 | 10 | 10 | 18 | 78 | 9.3 |
| 君曦 | 50 | 10 | 10 | 17 | 87 | 10.4 |
| 金海 | 50 | 10 | 10 | 17 | 87 | 10.4 |
| 雅辉 | 50 | 10 | 10 | 20 | 90 | 10.8 |
| 婉怡 | 10 | 0 | 2 | 5 | 17 | 2.0 |
求出本组的现场答辩得分：去除最高总分，最低总分，求平均分（保留1位小数）
去除最高总分，最低总分，求平均分得：52.6
收集其他组对本组提出的问题，并回答
团队提问回答环节
第一组的提问：
问：后端的主要算法可以介绍下吗？
答：后端服务器主要通过阿里云搭建的，服务器推送是通过app集成极光推送实现，具体的数据分析算法目前还未完善。
第二组的提问：
问：对于自律的人其实用处不大，不自律的更没有用，用户会不会没有保证？
答：我们设计app的目的主要是起到一个辅助作用，愿意提升自己的人通过我们的app可以得到良性回馈，再加上宠物互动，我相信是会有许多人喜欢尝试的。至于用处不可能说是用了之后就能改变一个人的，这是一个循序渐进的过程。
第三组的提问：
问：主打宠物界面如何美观且完善？
答：这个当然是通过压榨美工实现了（xd）。
第四组的提问：
问：你们是打算用什么来吸引用户？
答：app主打的自律牌相信本身就能吸引到一部分想改变自己的人，再加上可爱的界面和宠物也能吸引一些小姐姐。
第五组的提问：
问：希望可以设计宠物各个阶段的不同动画形态。
答：这个我们目前已经实现了，当然后续还会添加其它宠物的（再次压榨美工xd）。
第六组的提问：
问：宠物是动态还是静态的，如果是动态，是用gif还是3d引擎？
答：是动态的噢，目前是用gif实现，3d引擎的话目前能力有限以后会考虑的。
第七组的提问：
问：如果要常驻后台，耗电量能不能小一点？
答：首先我们是极不希望常驻后台的，目前还是在寻找方法来解决后台推送面临的问题。如果迫不得已要强制常驻后台的话，当然会尽可能减少耗电。
第八组提问：
问：对于一事手机自带的日历有日程提醒，你们这个项目的优势在哪呢？
答：优势在于人性化的提醒，不仅仅是自己设置日程，更带有暖心的日常提醒，也具有更大的灵活性。
第九组问题：
问：对于需要这个软件的用户来说宠物界面是否会太花里胡哨？
答：宠物作为主界面，我们设计的风格偏向简约的暖色调，不会设计的太花哨。后面也会继续完善。
第十一组问题：
问：宠物怎么动起来，不能是放gif吧？
答：目前使用gif，如果时间和能力允许，会改进。
第十二组问题：
问：你们打算如何实现宠物界面？是否使用图形学技术？
答：宠物现在已经使用gif实现，目前没有考虑使用图形学技术。
PSP与学习进度条
PSP
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 15 | 5 |
| · Estimate | · 估计这个任务需要多少时间 | 15 | 5 |
| Development | 开发 | 1450 | 1750 |
| · Analysis | · 需求分析 (包括学习新技术) | 120 | 150 |
| · Design Spec | · 生成设计文档 | 10 | 10 |
| · Design Review | · 设计复审 | 20 | 20 |
| · Coding Standard | · 代码规范 (为目前的开发制定合适的规范) | 10 | 10 |
| · Design | · 具体设计 | 70 | 50 |
| · Coding | · 具体编码 | 1200 | 1500 |
| · Code Review | · 代码复审 | 20 | 10 |
| · Test | · 测试（自我测试，修改代码，提交修改） | 0 | 0 |
| Reporting | 报告 | 25 | 25 |
| · Test Repor | · 测试报告 | 0 | 0 |
| · Size Measurement | · 计算工作量 | 20 | 50 |
| · Postmortem & Process Improvement Plan | · 事后总结, 并提出过程改进计划 | 5 | 10 |
| 合计 | 1490 | 1780 |
学习进度条
| 第N周 | 新增代码（行） | 累计代码（行） | 本周学习耗时（小时） | 累计学习耗时（小时） | 重要成长 |
|---|---|---|---|---|---|
| 1 | 103 | 103 | 14 | 14 | 学会了十三水的玩法，对原型设计有了一定的基础 |
| 2 | 400 | 503 | 10 | 24 | 学习C# winform开发，完善具体设计思路 |
| 3 | 1313 | 1816 | 30 | 54 | 实现核心算法“自动分牌” |
| 4 | 1153 | 2969 | 22 | 76 | 界面设计与代码实现，完成各窗体与接口的实现 |
| 5 | 0 | 2969 | 15 | 91 | 详细了解商业计划书以及产品介绍视频的制作 |
| 6 | 0 | 2969 | 20 | 111 | 学习了UML类图的绘制，了解需求规格说明书的书写 |
| 7 | 120 | 3089 | 5 | 116 | 学习了Android Studio，查资料能力增强，对算法有了一定的框架 |
| 8 | 1230 | 3319 | 35 | 151 | 对Android的API调用，服务器部署，使用spring boot框架+tomcat，后端API功能实现 |