诸葛亮博客（项目Postmortem）
设想和目标
- 我们的软件要解决什么问题？是否定义得很清楚？
答：日常生活中，我们常常会为自己制定计划或目标，并给这些计划和目标定下完成的期限，但是却没有一个较为方便的工具能够便于我们记录目标进程。Dreamcatcher通过小程序这样便捷的形式，旨在督促和鼓励用户在规定的期限里完成自己制定的目标，同时以公开目标的方式鼓励用户与用户之间互相监督与激励， 促使大家共同进步。
目前大多数人几乎每天都会制定计划和目标，运用这款Dreamcatcher小程序能够记录每天的计划和目标，并且在规定完成时间内给予提醒，能够非常好的促进目标和计划的完成。且由于平台是小程序，打开方式简单便捷，操作容易。我们的系统首先会通过目标倒计时的功能督促和鼓励用户完成个人目标。其次，以公开个人目标的方式鼓励用户与用户之间互相监督与激励。以个人到广大群体，不仅仅是一个个人目标实现平台， 同时是广大群体，社会目标的公众平台。旨在营造“个人努力，全民努力”的良好追求目标氛围，让同学们进步得更快，成长得更好，生活得更充实。 - 我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)
答：原计划的目标大部分都已经完成。在实际的开发过程中，我们将一两个功能放到了下一版本实现。
核心功能有在alpha冲刺结束时按时交付。尽管这次冲刺延期了一星期，但大部分功能在一周前也已经基本完成。
我们的主体分为两个版块，目标功能版块还有一个目标广场，涉及到用户隐私问题，还没完全地合并好代码，还没有公开向用户发布。 - 有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
答：在项目的规划阶段对于一些具体细节的思考度不足。例如讨论时觉得都讨论的差不多了，但具体实践时具有难度不得不多占用一些时间。
改进：提高自己的编程能力、以及对于编程语言和框架的熟练度很有必要。
计划
- 是否有充足的时间来做计划?
答： 之前有充分的时间来讨论、构想整个软件的框架，之前布置的每一项作业都在不断地让整个软件的轮廓在我们的大脑中变得清晰。 但是在我们的计划中，编程时间是不够的，因为我们都是新上手一门语言。 - 团队在计划阶段是如何解决同事们对于计划的不同意见的？
答：会议讨论，一个人负责做会议记录，最终组长根椐会议下来的内容评测难度，和大家商量决定计划。 - 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
答： 基本完成。没做完的部分有由于考虑到设计用户隐私以及编程上有bug而推到了下一版本。 - 是否每一项任务都有清楚定义和衡量的交付件?
答： 有的。在Alpha冲刺的初期，全组成员开会最主要就是讨论清楚整个业务逻辑，讨论完业务逻辑，我们再细分出各个任务，例如前端由几个页面组成，后端要写哪些逻辑，要设计几个表等等，这些具体的东西就是具体的交付件。把每一项任务分配给各个人，形成详细的任务分配。 - 在计划中有没有留下缓冲区，缓冲区有作用么?
答：有，让我们在冲刺项目的时候还可以兼顾其它考试，不可预估的时间情况 。
6.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
答： 进度管理十分重要，是我们学到的一课。如果重来一遍，一定会要求队员尽快上手写代码，团队尽快进入能够有实际产出的创造阶段。
资源
- 我们有足够的资源来完成各项任务么?
答： 有的。学习资源的话，网上的资源十分丰富够用。小程序开放的功能、权限也很多了。 - 测试的时间，人力和软件/硬件资源是否足够?
答： 测试的时间和人力不足够，感觉软件还有很多缺陷，代码也不够完善。大家学习开发知识的同时还要应付考试，为了完成基本功能就已经费神费心，基本任务完成就感觉已经可以交付了，对于测试和代码的健壮性不是太上心。 - 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
答：是，其实那些要前期花费很多的时间去准备，开发时效率才会更高; - 你有没有感到你做的事情可以让别人来做（更有效率）?
答：没有，每个人一开始就根据能力拿到自己的任务去完成，那么在项目进行过程中，每个人应该是对自己那部分工作最熟悉的人，这样临时找别人来做，别人也需要花部分时间来学习必要的技术并且要熟悉这部分工作的内容(比如让后台开发的人来写前端界面)，这样不但不能提高效率，反而会影响到整个项目的进度。 - 有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
答：前期准备不充分会影响后期的开发效率。如果重来一遍，由于网上、图书馆等有足够的资源来让我们学习开发所需的技术以及熟悉如何开发项目的流程，那么我们会在前期花更多的时间去做足准备，比如深入的去进行需求分析，统一好开发文档，以及花更多的时间和利用好可用的资源去提高编写代码的能力，同时我们会更加注重对代码的测试，以保证程序代码的健壮性。
变更管理
- 每个相关的员工都及时知道了变更的消息?
答：Alpha冲刺时每两日一次的站立会议交流算是一个很好的方法。此外，线上交流很方便。如果有线上聊天解决不了的技术细节问题，组内（前端组、后端组）或者整个项目组就会进行团队现场编程来面对面解决。 - 我们采用了什么办法决定“推迟”和“必须实现”的功能?
答：必须实行的功能就是项目的核心功能和Alpha冲刺实际开发过程中遇到困难较小的功能。
推迟，一般是因为这个功能可能需要较大的工作量而Alpha冲刺的时间不多，一共七天，这时大家就做出推迟到下一版本时完成的决定。 - 成员是否能够有效地处理意料之外的工作请求？
答：项目初期对于任务的划分基本上涵盖了整个Alpha冲刺过程。几乎没有意料之外的工作变更。一般来说组长布置给组员的额外的一些小任务（例如多加个按钮，某个逻辑有点什么小变更，多写个接口之类的）团队成员也可以及时地完成。最终debug发布的时候才出现了一些页面逻辑跳转的问题不得不页面结构，但也很快地就解决了。 - 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
答：计划赶不上变化，开发过程中不会一帆风顺，采用一套好的变更管理策略就变得很重要，如果重来一遍，我们会加强对项目进展的相关细节方面的管理，队员们每日汇报自己完成那部分工作的进度和遇到的困难，是否解决等信息，以便PM能对项目的进展有全局的了解，能及时的对工作进行调整，提高整个项目的开发效率。
设计/实现
- 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
答：在Alpha冲刺的初期，全组成员开会讨论清楚整个业务逻辑。但这个不算真正的设计，因为很多内容和细节在实际开发的设计过程中都要重新敲定。
UI原型设计主要由pm与前端唐小艳来负责。
到了实际编码前的设计，例如设计逻辑、设计接口和表，主要由pm和后端组员来完成。 - 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
答：因为都到设计阶段了，有什么模棱两可的情况出现都会讨论清楚并敲定一个最终的方案。 - 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
答：由组长复审，部分存在没有完全遵守代码规范的情况，个人认为还是时间成本的问题吧，但还是应该规范起来，提高代码的整体质量，提高可拓展性。
测试/发布
-
团队是否有一个测试计划？为什么没有？
答：有，每个人都要测试自己部分以及选择一部分测试，并形成报告发给对方。 -
团队是否有测试工具来帮助测试？
答：无。 -
团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
答：页面整合完后，在不同的机型上使用，出现了页面切换 -
在发布的过程中发现了哪些意外问题？
答：暂时没有。 -
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
答：良好的测试的保证代码质量的前提，如果重来一遍，我们对不同功能的代码，设计覆盖范围更加全的数据来进行测试，并且把测试的结果和对结果的分析写入测试文档。
团队贡献比例
团队合照
