• 事后诸葛亮分析


    Group:Interesting-Corps(音吹丝听)
    Project: 音吹丝听
    会议照片:

    一、设想和目标

    1. 我们的软件要解决什么问题?是否定义得很清楚?是否对典型用户和典型场景有清晰的描述?
      答: 本软件是为了给用户带来一个最纯粹的音乐交流的小天地;
      典型用户:经常会因为音乐而产生情愫,有很多感触想要吐露的用户,喜爱音乐喜爱歌手希望看法得到分享的用户;
      典型场景:对喜爱的歌曲有感而发。

    2. 我们达到目标了么(原计划的功能做到了几个? 按照原计划交付时间交付了么? 原计划达到的用户数量达到了么?)
      答: 最初的目标并未达到,由于小程序的服务条款不允许个人开发小程序存在在线音乐播放,因此很遗憾;
      计划中最重要的杀手功能即是神秘随机匹配,已经实现;
      因为在线播放,以及代码体积的原因未能按预期时间交付;
      用户数量暂未达到预期。

    3. 和上一个阶段相比,团队软件工程的质量提高了么? 在什么地方有提高,具体提高了多少,如何衡量的?
      答: 质量有提高;衡量标准为主要排除了几个影响用户体验的bug——主页机型不兼容,动画效果不流畅等。

    4. 有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
      答: 经验:使用云函数也可以向非https协议的服务器申请数据;
      教训:开发前一定查询或者阅读好条例规则,避免触碰雷区;
      重来一遍的话。在开发前会做更足的准备,避免空费力气,代码增量式管理做得更好。

    二、计划

    1. 是否有充足的时间来做计划?
      答:开发前。通过召开会议大家各抒己见,因此有充分时间计划项目的结构与方向等关键因素。
    2. 团队在计划阶段是如何解决同事们对于计划的不同意见的?
      答:PM首先发表总体看法,再经过大家所有人投票表决,多为少数服从多数。
    3. 你原计划的工作是否最后都做完了? 如果有没做完的,为什么?
      答:开发过程还算顺利,基本做完了。
    4. 有没有发现你做了一些事后看来没必要或没多大价值的事?
      答:暂无。
    5. 是否每一项任务都有清楚定义和衡量的交付件?
      答:队长为每人明确分配任务,所以基本符合条件。
    6. 在计划中有没有留下缓冲区,缓冲区有作用么?
      答:暂无。

    三、资源

    1. 我们有足够的资源来完成各项任务么?
      答:UI资源因为没有主攻这方面的组员,因此这方面资源确实匮乏,其余资源正常。
    2. 各项任务所需的时间和其他资源是如何估计的,精度如何?
      答:各项任务所需时间基本按照大家学习、开发能力,以及分配任务的难易程度估计,精度不高但基本符合能力与预期。
    3. 测试的时间,人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
      答:通过使用微信开发者工具,测试资源基本足够;
      非编程资源确实低估了难度,主要为UI设计,在正式开发期间花了很大功夫。
    4. 你有没有感到你做的事情可以让别人来做(更有效率)?
      答:队长按照各自能力合理分配任务,因此基本没有此种情况。

    四、变更管理

    1. 每个相关的员工都及时知道了变更的消息?
      答:是,一有重要变更队长都会及时通知组员。
    2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?
      答:办法主要为考虑任务量、任务难度及开发时间。
    3. 项目的出口条件(Exit Criteria – 什么叫“做好了”)有清晰的定义么?
      答:保证用户正常使用,基本功能完全实现且正常运作,最重要的是实现给予用户最初的能够将自己关于音乐的感受的得到释放的期望。
    4. 员工是否能够有效地处理意料之外的工作请求?
      答:大家关系良好,若有十分必要的工作请求都会尽量接受并且尽力做好的。

    五、设计/实现

    1. 设计工作在什么时候,由谁来完成的?是合适的时间,合适的人么?
      答:设计工作在选题以及需求分析阶段都有共同参与,做到比较合适的共识。
    2. 设计工作有没有碰到模棱两可的情况,团队是如何解决的?
      答:基本没有,有疑问一般会询问PM共同解决。
    3. 团队是否运用单元测试(unit test),测试驱动的开发(TDD)、UML, 或者其他工具来帮助设计和实现?这些工具有效么? 比较项目开始的 UML 文档和现在的状态有什么区别?这些区别如何产生的?是否要更新 UML 文档?
      答:利用微信开发者工具对不同的机型进行调试,开发过程也利用真机使用进行测试。
    4. 代码复审(Code Review)是如何进行的,是否严格执行了代码规范?
      答:所有开发人员都参与代码复审,严格检查并统一了代码规范。

    六、测试/发布

    1. 团队是否有一个测试计划?为什么没有?
      答:有,开发的同时总有极端数据和行为的测试,使程序功能稳固。
    2. 是否进行了正式的验收测试?
      答:是,已经撰写测试博客。
    3. 团队是否有测试工具来帮助测试?
      答:有,主要为微信开发者工具与真机。
    4. 在发布的过程中发现了哪些意外问题?
      答:小程序服务条例不允许个人小程序包含在线音乐播放是比较大的意外问题。

    七、团队的角色,管理,合作

    1. 团队的每个角色是如何确定的,是不是人尽其才?
      答:是的,主要按照个人能力进行角色分配。
    2. 团队成员之间有互相帮助么?
      答:有,成员有什么疑问都会提出来,大家都会积极帮忙解决。

    八、总结:

    1.你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
    答:基本达到了CMMI二级,即为管理级的档次。本团队做到提前计划,任务合理分配。但是制度化并没有做到,管理措施欠缺。
    2.你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
    答:规范阶段
    3.你觉得目前最需要改进的一个方面是什么?
    答:团队的代码增量式管理做得不够好。
    4.对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
    答:我们团队积极开发,尽早交付,成员都认真开发测试,以后也会积极听取用户建议。
    5. 代码管理的质量具体应该如何提高? 代码复审和代码规范的质量应该如何提高?
    答:团队争取要有专属适合自身的管理措施;
    参与开发人员需要严格遵守制定的代码规范;
    测试流程完全执行后上交复审;
    6. 其它软件工具的应用,应该如何提高?
    答:UI设计相关的工具使用还要寻找资源继续学习了解。
    7. 项目跟踪用户数据方面,计划要提高什么地方?例如你们是如何知道每日/周活跃用户等数据的?
    答:可以通过登录开发者账号到云数据库中进行实时查看。
    8. 项目文档的质量如何提高?
    答:跟随代码开发及时更新文档,借助辅助工具及固定模板提高文档质量。

    九、团队成员在Alpha阶段的角色和具体贡献:

    名字 角色 团队贡献分 可验证贡献
    鲍鱼铭 前端开发&PM 21.5 担任项目策划,整个项目任务分配,撰写博客,开发
    叶学涛 前端开发 20.5 博客撰写、页面设计开发
    许铭楷 前端开发 19.5 页面设计开发
    陈锐填 后台开发 18.5 云数据库设计及建立
    何隽熙 后台开发 18.5 云数据库设计及建立
    巫杰龙 后台开发 18.5 云数据库设计及建立
  • 相关阅读:
    【LOJ#10027】魔板
    【LOJ#2653】山峰和山谷
    【POJ2449】第k短路
    【HAOI2008】移动玩具
    【洛谷P1379】八数码难题
    【NOIP2002】字串变换
    【CH2501】矩阵距离
    【CH2601】电路维修
    【NOIP2009】靶形数独
    树的子结构
  • 原文地址:https://www.cnblogs.com/bayardm/p/13123934.html
Copyright © 2020-2023  润新知