Loading

那你能帮帮我吗——Alpha问题总结随笔

设想和目标

  1. 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？

    • 我们的项目主要是为了解决三个问题：（1）校内闲置物品出售不方便。（2）取快递、食堂带饭等琐事需要他人帮忙。（3）校内团立项、体育比赛活动缺少宣传渠道。

    • 定义的很清楚。（这些问题在系统设计说明书介绍的更详细。）

    • 典型用户：在校大学生。

    • 典型场景：（1）需要出售闲置物品。（2）需要委托他人办事或做任务。（3）需要宣传活动。

  2. 我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)

    目标基本达成：

    • 小程序微信授权登录功能。
    • 首页：列表分页展示、收藏、联系、多条件搜索以及查看详情功能已完成。
    • 发布页：自定义标签功能、发布功能已完成。
    • 详情页：展示详情、收藏、联系功能已完成。
    • 个人信息页：个人信息的查看、修改、退出登录、评论列表展示功能已完成。
    • 我的二手页：在售、已售、买入三种状态的列表分页展示、查看详情功能，以及在售状态的生成订单、下架、编辑修改功能已完成。
    • 我的活动页：已发布活动的列表分页展示、查看详情、删除功能已完成。
    • 我的任务页：未接收、进行中、已完成三种状态的列表分页展示、查看详情功能，生成委托订单、取消订单、删除任务功能，编辑修改功能，取消接受功能已完成。
    • 我的收藏页：列表分页展示、查看详情、联系、取消收藏功能已完成。

    未完成目标：

    ​ 首页的列表排序功能和标签跳转功能未完成。

  3. 和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高，具体提高了多少，如何衡量的？

    团队软件工程的质量提高了。特别是在分工的合理性和效率提高了，在alpha冲刺前就做好了明确的分工，每个人各司其职，从每日总结中每个人的进展与心得体会以及燃尽图中可以得知。

  4. 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?

    项目还未发布，所以无法知道用户量与用户体验情况。

有什么经验教训? 如果历史重来一遍,我们会做什么改进?

经验教训就是前后端交互与测试需要预留更多的时间，低估了前后端交互的工作量（页面太多了）。如果再来一遍，我们会在alpha冲刺前几天更加快马加鞭，给前后端交互与测试留更多时间。

计划

  1. 是否有充足的时间来做计划?

    有充足的时间来做计划，在alpha冲刺前就开始计划，冲刺前一天还花了一个下午的时间生成计划文档。

  2. 团队在计划阶段是如何解决同事们对于计划的不同意见的？

    在团队开会的时候，对计划部分有问题或不同意见就直接提出，并且由所有人一同讨论解决方案。

  3. 你们原计划的工作是否最后都做完了? 如果有没做完的，为什么?

    原计划工作基本做完了。还有一些小BUG没解决，原因是前后端交互花费了较大的代价，一些较小的BUG暂未修复。

  4. 有没有发现你们做了一些事后看来没必要或没多大价值的事?

    暂时没有。

  5. 是否每一项任务都有清楚定义和衡量的交付件?

    有清楚地定义。每个任务都分成了若干个页面，每个页面又分出若干个功能，根据功能点是否完成、页面交互是否没问题来定义和衡量。

  6. 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?

    • 项目出现的意外：前后端接口交互遇到了比较多的问题和困难。
    • 这个意外是没有估计到的，虽然有心理准备交互需要加把劲，但是没想到还是遇到了许多问题，第一次进行这么多的交互，没有预料到。

  7. 在计划中有没有留下缓冲区，缓冲区有作用么?

    有缓冲区。缓冲区起到了一定作用，每个人在缓冲区都重新预估了自己的工作进度并加以调整。

  8. 将来的计划会做什么修改？（例如：缓冲区的定义，加班）

    在提前做好充分的计划的同时，要添加计划的灵活性，比如，提前完成了某项任务，可以提前进入下一项任务工作，挤出更多缓冲区。

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

如果历史重来一遍，我们会在alpha冲刺的前期加快开发进度，给前后端交互和测试（完成交互后的测试）预留更多的时间。

资源

  1. 我们有足够的资源来完成各项任务么?

    前端：时间上有点小风险，因为我们项目的页面跟交互比较多，并且有小程序端和web端两处。技术上风险比较低，在冲刺前就已经学习小程序开发的相关技术。

    后端：时间跟技术上的风险都比较低，后端人员都有一定的后端编写经验。

  2. 各项任务所需的时间和其他资源是如何估计的，精度如何?

    首先由小组成员共同开会决定大体时间和其他资源的分配，精度精确到每个页面和功能。大体分配后，经过每天的冲刺，前后端分别有个领头人，如果需要做出改变，则对之后的资源进行分配的调整。

  3. 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?

    测试的时间较为紧凑，但每个页面每个功能都有完成测试。

  4. 你有没有感到你做的事情可以让别人来做（更有效率）?

    没有。

有什么经验教训? 如果历史重来一遍, 我们会做什么改进?

如果再来一次，在资源分配上也不会有太大的改变，每个人对自己的任务都有比较清楚的认识，而且都各司其职。

变更管理

  1. 每个相关的成员都及时知道了变更的消息?

    是的

  2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?

    在制定计划时，通过小组成员会议讨论，对每一个功能模块根据重要程度，制定了优先级，并规划了多个版本，每一个版本都是完整的项目，每一阶段完成一个版本的开发工作

  3. 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?

    alpha阶段是实现用户端的基础功能，beta阶段是完善用户体验，并完成后台管理

  4. 对于可能的变更是否能制定应急计划?

    能

  5. 成员是否能够有效地处理意料之外的工作请求？

    alpha阶段的开发工作中，几乎没有意料之外的工作请求，但相信我们的成员的能力是足以应付的

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

沟通和交流是非常重要的事情。对于变更的评估应该是经过仔细的权衡和计算的，变更后的记录也相当重要，希望下一次能把变更的评估和记录做的更好

设计/实现

  1. 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？

    设计工作是在开发前，由前后端组长提出大致构想和方向，小组成员讨论给出初步方案，再进行多次复审；是合适的时间，合适的人

  2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？

    主要是各成员投票解决

  3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？

    有使用单元测试和UML，UML文档初步确定后，在老师的指导意见下进行了一次较大的修改，此后基本没有改动

  4. 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?

    整体开发过程较为顺利，除了交互过程中，由于前后端沟通不够充分，数据传输格式不一致产生了一些bug外，没有太多bug;发布后没有发现较大bug

  5. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？

    每个阶段的开发工作结束后，将开发成员两两分组互相审核，并严格执行了代码规范

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

设计过程中，有不少设计不够合理，导致后续实现需要使用复杂的方法；希望下次设计时，能考虑更为周全，更为详细

测试/发布

  1. 团队是否有一个测试计划？

    有

  2. 是否进行了正式的验收测试？

    项目的前台即小程序部分已经基本完成，我们根据之前的需求规格书和原型进行了完整的验收工作。

  3. 团队是否有测试工具来帮助测试？

    在业务开发阶段，每个后端小组成员都通过junit对自己负责的DAO层代码和业务逻辑代码进行了单元测试；

    在接口开发阶段，使用Postman对接口进行了测试

  4. 团队是如何测量并跟踪软件的效能（Performance）的？压力测试（Stress Test）呢？ 从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？

    由于项目规模较小，后端接口的响应时间也较为迅速，这部分暂时没有进行

  5. 在发布的过程中发现了哪些意外问题？

    暂时没有

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

由于单元测试不够到位，在下一阶段的开发中，多次出现需要修改之前代码的情况，希望下一次能把单元测试做的更好；同时将日志工作做的更为完善

团队的角色、管理、合作

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

    根据开发经验，首先分为前后端两种人员，在开会的时候，就会商量每个人的角色分工。同时我们前后端分别有一个小组长，在初步分完工后，小组长会根据每天的进展进行小调整。

  2. 团队成员之间有互相帮助么？

    团队成员之间时常互相帮助。当某个人员遇到BUG自己无法解决的时候，会发在讨论群里或者直接去宿舍询问其他组员，寻求帮助，而其他组员也会很热心的帮助一起解决BUG。

  3. 当出现项目管理、合作方面的问题时，团队成员如何解决问题？

    当出现项目管理、合作方面的问题时，会在讨论群里提出，由组员们共同商讨解决方案。

总结

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

    属于CMMI第二级。

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

    目前正处于规范阶段，尚未达到创造阶段。

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

    每个人都十分明确自己要做的事情，各司其职，不会对自己要做的事情存在较大的疑惑。

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

    成员之间对于代码提交（github提交）的沟通需进一步沟通好。

posted @ 2021-06-09 22:41  那你能帮帮我吗  阅读(86)  评论(0)  编辑  收藏  举报