第6组 Beta冲刺 总结

目录

• 1. 基本情况
• 2. 思考与总结
  • 2.1. 设想和目标
  • 2. 计划
  • 3. 资源
  • 4. 变更管理
  • 5. 设计/实现
  • 6. 测试/发布
  • 7. 团队的角色，管理，合作
  • 8. 总结
• 3. 敏捷开发

1. 基本情况

• 组长博客：郝雷明

• 答辩总结：
  
  按照老师的要求和小组讨论：
  
  现在准备：既做刷题的功能，也做亮点

• 全组讨论的照片：
  
  

• 评估团队中每个人对本次作业的贡献比例：
  
  （1） 工作流程：
  
  按照组内组员讨论出来的想法，
  
  ->美化前端页面
  
  ->分析小程序存在的问题
  
  ->后端修改、调试
  
  ->测试性能文档生成
  
  （2） 组员分工：
  
  详情请见之前的博客
  
  （3） 组员工作量比例：

姓名	工作量
郝雷明	8%
方梓涵	12%
杜筱	10%
鲍凌函	10%
董翔云	10%
黄少丹	10%
詹鑫冰	11%
曾丽莉	9%
曹兰英	9%
吴沅静	11%

2. 思考与总结

2.1. 设想和目标

1. 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
   
   A: 解决的问题：为考研学子提供一个交流经验和提供题库资源的平台；
   
   定义：小程序功能定位清澈
   
   有典型用户和典型场景的描述：

• 上岸的学生：通过上传自己觉得很好的资源到“小福有研”，发布自己考研的经验贴到动态页面；
• 备考的学生：利用社交功能记录自己的每一天，题库页面以及搜索页面查找自己需要的资料，上传自己觉得有价值的题目及答案；
• 有考研意向的学生：通过浏览平台上各个页面，对考研有一个整体的框架构想。

1. 我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)?
   
   A: 原计划功能：全部做到（虽然有些不是特别符合要求）
   
   但是根据老师的要求，是一个“粗糙”的小程序，不能通过
   
   交付时间：按照要求交付
   
   用户数量：不太清楚
2. 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
   
   A: 由于小程序还没通过审核，用户量暂且未知，
   
   之后会补充
3. 有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
   
   A: 不要低估了任何一个项目的开发难度和工作量
   
   改进：每个成员之间沟通更加紧密；

2. 计划

1. 是否有充足的时间来做计划?
   
   A: 有足够的时间准备，团队分工还是较为明确的，完善项目后还是剩余一些时间
2. 团队在计划阶段是如何解决同事们对于计划的不同意见的？
   
   A: 通过线下线上讨论的方式，及时沟通，互相理解这个很重要！
3. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
   
   A: 按照原定的目标和要求，团队每一个成员基本完成都完成了
   
   但是现在还要继续修改，可能需要增加功能；
   
   我们一开始没有决定要做一个刷题的小程序
4. 有没有发现你做了一些事后看来没必要或没多大价值的事?
   
   A:

姓名	反思
郝雷明	有学到一些不一样的，都是可以的
方梓涵	没有，都是需要完成的任务
杜筱	没有，为完成那些功能实现，做的事都是必要的
鲍凌函	有，走了一些弯路，最终选择了最合适的云开发完成功能实现
董翔云	没有，做的事都有用，有的是现在，有的是以后
黄少丹	没有，踩的坑都能让我懂得如何更好地避开未来的坑，总结经验
詹鑫冰	没有，做的都是需要的
曾丽莉	没有，目前做的都很有必要
曹兰英	虽然现在有些事现在看起来没必要，但是以后总有一个时刻会觉得有用吧
吴沅静	beta阶段没有

1. 是否每一项任务都有清楚定义和衡量的交付件?
   
   A: 是，分工将任务已经具体化，beta阶段小组配合很顺利，每个人各司其职
2. 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
   
   A: 基本是按照计划进行；
   
   项目出现的意外：小程序上线审核未通过，老师评定太差了；
   
   风险：新的添加的模块可能做不出来，
   
   原因：准备缓冲区了，小组分工相较于alpha也更加清晰，
   
   项目最初的设想可能没有阐明清楚，
   
   没有发布过小程序，未通过的具体原因还不清楚；
3. 在计划中有没有留下缓冲区，缓冲区有作用么?
   
   A: beta阶段一开始设留缓冲区
4. 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
   
   A: 向已经上线小程序的小组请教：如何通过审核
5. 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
   
   A: 有效的团队合作会使项目事半功倍；
   
   改进：无

3. 资源

1. 我们有足够的资源来完成各项任务么?
   
   A:之前有，人力肯定不缺，因为做的是小程序，其他资源，像时间也不是特别紧张
   
   但是现在和以后可能时间不够了，因为要改很多东西
2. 各项任务所需的时间和其他资源是如何估计的，精度如何?
   
   A: 估计：根据alpha的时候每个人负责的部分，不断优化；
   
   小组内成员先单独尝试优化；
   
   当实在没有办法解决，小组内进行讨论，得到可行的方案；
   
   同时也有专门的负责人催促；
3. 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
   
   A: 测试的时间，人力和软件/硬件资源足够
   
   不需要编程的资源 (美工设计/文案)也没有低估难度
4. 你有没有感到你做的事情可以让别人来做（更有效率）?
   
   A: 应该没有吧
5. 有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
   
   A: 有效的团队合作会使项目事半功倍；
   
   时间的分配合理促使项目更加顺利进行；
   
   改进：无

4. 变更管理

1. 每个相关的员工都及时知道了变更的消息?
   
   A: 在beta阶段，基本上是每个相关的员工都及时知道了变更的消息。
2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?
   
   A: 根据实际优化情况和小组讨论的结果，来决定“推迟”和“必须实现”的功能，
3. 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
   
   A: 我们团队一致认为:小程序功能实现作为出口条件
4. 对于可能的变更是否能制定应急计划?
   
   A: 仍然没有遇到特别紧急变化；
   
   如果十万火急，应该会立即开会并指定口头上的急需计划。
5. 员工是否能够有效地处理意料之外的工作请求？
   
   A: 有员工能力较强，可以意料之外的工作请求；
6. 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
   
   A: 有效的团队合作会使项目事半功倍；
   
   改进：无

5. 设计/实现

1. 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
   
   A: 大家都有参与设计小程序最初的功能；
   
   事实证明：是合适的时间，也是合适的人。
2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
   
   A: 有，协商讨论一同解决。
3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？
   
   A: 没有使用单元测试，通过微信小程序开发工具提供的接口直接测出性能
4. 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
   
   A: 状态仍然有很大区别的；
   
   原因是项目开始时的文档是基于我们的空想完成的，实际开发过程中不断地在调整。当然需要更新（事实上我们也确实在做这件事）
5. 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
   
   A: 社区功能，因为功能更加复杂；
   
   小程序未发布，现在真机调试，已经优化完成
6. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
   
   A: 目前复审的准则：功能是否可以正常使用，没有特别严格执行代码规范
7. 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
   
   A: 有效的团队合作会使项目事半功倍；
   
   改进：适当的文字记录会议内容。

6. 测试/发布

1. 团队是否有一个测试计划？为什么没有？
   
   A: 有
2. 是否进行了正式的验收测试？
   
   A: 正在完成，预估beta阶段结束后，测试文档将定稿了
3. 团队是否有测试工具来帮助测试？
   
   A: 有
4. 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
   
   A: 通过微信小程序开发软件自带的功能跟踪效能
5. 在发布的过程中发现了哪些意外问题？
   
   A: 还没有发布（现在未知）
6. 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
   
   A: 测试是一个很难的事情，并没有想象的简单；
   
   前期要尽可能考虑测试实施的可行性，测试计划改了很多次

7. 团队的角色，管理，合作

1. 团队的每个角色是如何确定的，是不是人尽其才？
   
   A: 根据每个人的偏好和团队需要进行分配；是人尽其才
2. 团队成员之间有互相帮助么？
   
   A: 有
3. 当出现项目管理、合作方面的问题时，团队成员如何解决问题？
   
   A: 线下会议讨论
4. 每个成员明确公开地表示对成员帮助的感谢 （并且写在各自的博客里）：

• 我感谢 方梓涵 对我的帮助， 因为某个具体的事情: 承担所有的压力。

• 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
  
  A: 学会了云开发，使用github进行团队合作，mock设计UI，各种软件设计前端页面；
  
  改进：前期自主的学习相应知识，

8. 总结

1. 你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
   
   A: 可重复级
2. 你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
   
   A: 规范阶段
3. 你觉得团队在这个里程碑相比前一个里程碑有什么改进?
   
   A: 分工更加明确
4. 你觉得目前最需要改进的一个方面是什么?
   
   A: 暂时没有了项目基本完成了

3. 敏捷开发

1-我们的最高目标是通过尽早和持续第交付有价值的软件来满足客户；

举例：这是我们团队的共识，小程序是先将整个框架做好后，

通过不断的调试bug，达到产品基本可用之后，我们再进一步优化产品

2-欢迎对需求提出变更 - 即使在项目开发后期，要善于利用需求变更，帮助客户获得竞争优势；

3-要不断交付可用的软件，周期从几周到几个月不等，越短越好

4-项目过程中，业务人员与开发人员必须在一起

举例：团队每一个人既是开发者也是业务人员！

5-要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务

6-无论是团队内还是团队间，最有效的沟通方法是面对面的交谈

举例：我们通过线下的会议，由专门的负责人一步步指导，以确保任务可以顺利进行！

7-可用的软件是衡量进度的主要指标

8-敏捷过程提倡可持续的开发，项目方，开发人员和用户应该能够保持恒久稳定的进展速度

举例：整个项目都是连贯的，

因为后端与前端是连在一起的，beta优化的时候，需要相互协调！

后端做完后，测试也已经开始了

9-对技术的精益求精以及对设计的不断完善将提升敏捷性

10-要做到简洁，尽可能减少不必要的工作，这是一门艺术

11-最佳的架构，需求和设计出自于自组织的团队

12-团队要定期反省如何能够做到更有效，并相应调整团队的行为。

举例：每次博客编写前都有组内都会举行会议，讨论每一个人的接下来的任务内容。