标签：新项目 效能 微信群 发布 修复 用户数 成员 里程碑 临时
让大学生通过记账养成良好的消费习惯，解决了大学生不知道钱花到哪里去，没有好的金钱规划等问题。在之前的团队博客的需求分析中对典型用户和典型场景有清晰的描述。
基本完成MVP的功能。原计划就已经确定好目标，打算把核心功能先实现了。 有按照原计划交付时间交付。 用户数量原计划是12个，alpha阶段才刚刚发布，主要由内部开发人员在使用。
提高了。分工协作方面有所提升。因为原来不大懂微信小程序开发具体流程，在分工方面只能分个大概，后来不断熟悉开发具体流程，PM在分工方面进行了调整，alpha阶段没有实现后端，则把后端人员调至前端开发。整个项目开发的效率有所提升。
预想一致。离目标还有一段距离。因为是alpha阶段，我们还没有实现杀手功能，只完成了最核心的记账模块和报表模块。
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
设想太过饱满，在实际设计过程中，发现有些功能还没有能力实现。结合自身编程能力和需求进行功能设计。
有，在alpha阶段的前两周都用来写计划。
大家一起讨论，选择合适的计划。
基本完成。
有。在需求分析时，考虑之后要完成除核心功能和杀手功能外的其他一些不是很必要的功能，比如皮肤设置等。
大部分没有，一般按照大家主观上的认识来定义功能。开发人员根据要求完成功能模块后，我们组成员会进行使用，并提出建议。
基本都能按照计划进行。对前端语言的不熟悉，在某些功能模块实现方面，花了比计划还要长的时间。
有。每个人的进度都不一样，有时候一些模块会有一些bug需要修复，花费的时间经常比计划的要长。
结合开发人员的技术能力，合理安排时间。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
时间计划表要和开发人员的技术能力和功能模块的复杂程度相结合。我们会明确缓冲区的长度，确保计划能按时完成。
人力资源足够，但是技术资源和时间资源还有所欠缺。因为大家都是第一次接触微信小程序的开发，没有系统学习小程序开发，操作起来难度还是挺大的。时间上，大家因为各种事情会感觉时间上有些不充足。
把每项任务的功能实现列出来，关于支持功能实现的后端技术也列出来。根据列表的功能数和功能实现的难度（如网上是否有资源可以参考）来估计所需资源和时间等。
我们团队安排了2名测试员，人力资源是够的，在测试时间上安排有些不合理（安排的太少了），导致在alpha阶段发布程序时，程序还出现了一些bug。测试软件/硬件资源是足够的，但是在使用这些资源方面，我们团队还不能熟练操作。确实低估了不需要编程的资源（如界面排版设计），因为程序界面设计的语言大家没有接触过，很难通过设置一些变量值来实现大家设想的界面。
目前大家都没有这种感觉，因为我们的任务是根据大家的技术能力、擅长领域来分配的。但有时也会出现分配给组员任务过重的现象，这个时候我们会及时调整任务分配。
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
在分配任务的时候，要先大概了解下程序的前端、后端各个模块完成的工作量，再根据每个人技术能力和擅长领域来分配任务，适时根据实际情况来调整任务。
是的。我们团队有建一个微信群，有关项目的任何变更消息会在上面发布。
大家一起讨论决定最核心的功能，若出现不同意见的话，会采用投票的方式来决定功能是属于“推迟”还是属于“必须实现”。
有。经大家的讨论，考虑到时间问题和大家技术水平，在alpha阶段我们只关注于记账小程序的核心功能。包括记账模块和图表模块。我们的出口条件就是：选择日期、类别进行记账，可以准确记录当天的总结余和选定日期查看当天的明细，选择年月查看消费类别的比例。
在进行这个项目时，并没有制定应急计划。但在出现我们计划与实际出现偏差时，我们会及时调整计划。
大部分能。PM会把工作请求给相应的技术人员实现，如果技术人员无法实现，大家可以一起想办法完成。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
在变更管理方面，我们团队做的不够，在实现程序过程中变更的内容也是直接临时大家经过讨论决定，这样很容易与原来的设计内容相违背。如果还能再来一次，我们会在计划设计方面，多考虑变更情况的发生和相应的应急方案。
在一开始的原型设计环节就进行了设计工作。由黄登峰和何雨柔同学完成。黄登峰同学擅长界面排版，何雨柔同学是我们团队的PM，会根据我们团队开发的小程序核心功能是记账
这一关键点出发，给出界面设计的建议。恰在合适的时间与合适的人。
遇到过。比如在报表功能要放在和明细账单页面一个页面呢，还是独立出来一个页面。PM召集大家讨论，每个成员都给出自己的看法，经过讨论我们决定把报表模块独立出一个页面，这样让用户在短时间内使用中发现我们程序的主要功能，这样在排版方面也显得更加简洁明了。
用微信自带的测试小工具。还是挺有效的，可以分析时间效能、cpu使用情况等等。
记账功能模块。涉及到账目类别、金额、时间的数据存储。发布之后有个严重的bug就是选择不同日期进行记账后，对应日期的明细出现了混乱，比如今天的账目记录到昨天去了，或者是没有记录进去。在测试过程中，并没有发现这个bug，是在发布之后才发现有时候会出现这种情况。
每个人针对自己负责的模块进行代码复审，让相关功能模块的开发人员进行互相代码复审。严格执行了当初制定的代码规范。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
设计过程中要注重测试。通过测试，开发人员能够及时修改bug或者更换设计思路。
有。在程序开发过程中，测试人员针对程序开发的功能模块制定了测试计划。
是。通过微信测试工具和测试人员的使用来修复已发现的bug。
有。微信自带的测试工具。
使用微信自带的测试工具，通过分析测试工具的测试结果。有用。
出现了一些之前没有发现的bug。发布之后有个严重的bug就是选择不同日期进行记账后，对应日期的明细出现了混乱，比如今天的账目记录到昨天去了，或者是没有记录进去。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
要注重测试，测试人员要熟练掌握测试工具的使用，能够使项目的完成事半功倍。
根据每个成员的擅长领域和技术能力决定。做到了人尽其才。
有，遇到问题大家都会一起讨论、一起想办法，解决问题。
由PM进行调解，大家一起讨论。
达到第二个等级：可重复性。我们团队能过做到管理制度化，建立了基本的管理制度和规程，管理工作有章可循。初步实现标准化，开发工作比较好地按标准实施。变更依法进行，做到基线化，稳定可跟踪，新项目的计划和管理基于过去的实践经验，具有重复以前成功项目的环境和条件。
目前处于规范阶段。在alpha开发阶段，一开始大家会出现一些意见不统一的情况，需要大家不断的磨合。现在我们团队能够团结协作完成项目开发，遇到不同意见也能够在较短时间内解决。
对微信小程序的开发流程有了更深刻理解。开发人员也对一些前端语言有了进一步的熟悉。大家能够更加团结协作做事，效率也更高了。
我们项目的杀手功能还没有实现。因为考虑到alpha阶段的时间和大家的技术水平，把杀手功能放在了下一阶段的开发。
原则：我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。事例：在alpha阶段，我们完成了最核心的功能，在后期开发我们会始终围绕用户需求把实现其他的功能。原则：在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。事例：我们团队每个礼拜都要开一次会议，如果有什么疑问，可以直接面对面提出。原则：每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。事例：我们团队每个礼拜都要开一次会议，探讨工作进度和工作任务等，大家会提出使工作更有效的建议，如是否调整计划，修改工作任务，调整任务分配等。
| 名字 | 角色 | 团队贡献排序 | 可验证的贡献 | 团队个人贡献分 |
|---|---|---|---|---|
| 邱晓娴 | 前端 | 1 | 记账模块，修改bug | 35 |
| 陈凯欣 | 前端 | 2 | 报表模块，修改bug | 32 |
| 何雨柔 | PM | 3 | 安排任务，每日的进度追踪，服务器的配置 | 13 |
| 黄登峰 | 测试 | 4 | 原型设计，界面设计 | 11 |
| 张晨晨 | 后端 | 5 | 架构设计，服务器的配置 | 9 |
标签：新项目 效能 微信群 发布 修复 用户数 成员 里程碑 临时
原文地址：https://www.cnblogs.com/tdbk715/p/9040427.html
