RGSJ问题总结

这个作业属于哪个课程 福州大学2020年春W班
这个作业要求在哪里 团队作业第六次——beta冲刺+事后诸葛亮
团队名称 RGSJ队
这个作业的目标 问题总结 组员调换
作业正文 ....
其他参考文献 《构建之法》
设想和目标

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

    • 大学生宿舍闲置物品过多无法处理的问题，没有校内处理的公众平台，我们软件定义的目标用户不是大众群体，而是校内学生和老师，并且主要功能面向区域内用户的二手交易。
      典型用户为同一个学校有闲置物品的学生和老师。
      主要场景：日常闲置物品交易；毕业前物品转卖......

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

    • 我们预期的功能有：注册、登录功能；物品发布功能；物品展示功能；留言功能；聊天功能；管理员功能。除了聊天功能以外都完成了。

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

    • 在beta阶段我们运用了leangoo看板功能进行项目管理，相比于alpha阶段更加细致地管理项目。

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

    • 设想用户量两百左右，目前测试用户对重要功能大体上是接受的。
计划

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

    beta阶段开始前我们有制定每天计划，相比于alpha阶段有了更好的规划。

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

    对于计划的不同意见，同时讨论，采取少数服从多数的方法决定。

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

    我们计划在beta冲刺完成管理员界面，最后也如期完成了。

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

    没有

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

    有。我们基本都是按照原型设计进行编程。

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

    没有出现较大的意外。

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

    有预留缓冲时间，缓冲时间主要用作准备最后的答辩准备。

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

就是要提前做好知识储备，不要想当然或者真正写代码的时候发现某个功能实现有困难才学习。

资源

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

    我们beta阶段任务较为简单，所以时间还是较为充裕的。

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

    我们用leangoo看板对整个冲刺时间进行一个分配，精确到每天的任务分配。

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

    beta阶段的各个资源都较为充足。不需要编程的资源也没有低估难度。

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

    此阶段我们的安排还是较为合理，效率也较高。

变更管理

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

    是的

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

    投票

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

    没有。

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

    是

设计/实现

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

    在开发前期，由前端工作人员完成，在合适的时间，这个人选是尽量合适

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

    一起讨论问题，最终组内决定

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

    我们开发软件没有用框架，没有找到合适的测试工具来测试代码，所以都是手动测试。

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

    app打开的时候闪退等的Bug最多，因为这一部分的代码相对复杂，有些地方没有考虑充分，导致运行的时候有较多的不足。

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

    我们的功能实现为结对实现，在开发过程中，随时交换代码，互相检查代码规范性。还需增强测试力度和设计美观性。

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

我们学到了团队如何共同开发，需要遵从一份代码规范，统一代码风格。

测试/发布

  1. 团队是否有一个测试计划？为什么没有？

    有安排测试计划。

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

    进行了正式的验收测试。

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

很多团队用大量低效率的手动测试，请提出改进计划：至少一个方面的测试要用自动化的测试工具，自动化的测试结果报告，比较测试结果的差异，等等。

​ 我们开发软件没有用框架，没有找到合适的测试工具来测试代码，所以都是 手动测试。

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

    团队中的测试主要通过手动测试，跟踪软件效能，这些测试工作可以发现一些明显的问题，但是仍然有些bug会遗漏。

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

    软件有时候会出现闪退问题。

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

重来一遍我们可能会利用框架开发，方便测试。

团队的角色，管理，合作

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

    我们根据上一个阶段分配前后端工作，后端人员继续完善后端代码，前端人员负责测试。这样就省去了很多交接工作，效率更高。

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

    有，比如我们测试部分的配置问题，基本都是后端大佬们帮助解决的。

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

    我们小组经过助教指导，运用了看板来调整项目管理工作。合作方面没有出现明显的问题，偶尔开会联系不到人的时候，会议结束之后会让一个同学去通知相关工作安排。

总结:

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

    我们应该是处于第三级。

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

    我觉得我们团队目前应该是在规范阶段。

对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。

正如我们前面提到的， 软件的质量 = 程序的质量 + 软件工程的质量，那团队在下一阶段应该如何提高软件工程的质量呢？

  1. 代码管理的质量具体应该如何提高？ 代码复审和代码规范的质量应该如何提高？

    这个阶段我们依旧使用GitHub管理代码，将代码合并至主分支上。探索使用一些对于代码风格审查的软件来帮助我们开发。

  2. 整个程序的架构如何具体提高？ 如何通过重构等方法提高质量，如何衡量质量的提高？

    程序功能简单，架构简单，简洁明了。我们已经尽最大所能提高代码质量和函数复用性，但是暂时没有合理优秀的重构方法。

  3. 其它软件工具的应用，应该如何提高？

    通过在网上寻找资料学习软件的运用以及小组成员之间互相交流，就能够很好地提高软件工具的应用。

  4. 项目管理有哪些具体的提高？

    我们运用了leangoo看板功能进行项目管理，相比于alpha阶段没有运用项目管理软件，这个阶段管理团队轻松了很多。

  5. 对于人的领导和管理， 有什么具体可以改进的地方？ 请看《构建之法》关于PM、绩效考核的章节， 或者 《人件》等参考书

    开发进度的审核确认可以再密集一些。

一、新组员交接情况

我在旧组做的工作：

  • 完成了待办事项模块的原型设计
  • 后端待办事项的增删改查，分类功能的实现
  • 向前端提供对应功能的接口
  • 以及完成了初步的接口和内部逻辑测试工作
  • 参与冲刺博客的撰写

交接：

和新组员通过聊天对话的方式进行交接，发现新组员并不熟悉我们组所用的技术和框架，介绍完我的工作和下一阶段的规划后让他有针对地进行技术储备。

二、新组员在新小组中的适应计划

初来乍到，队长主动和我进行沟通，在沟通的过程中我对新的团队有了大概的了解：

  • 技术方面：技术栈是Android+java web，Android是组员们都比较陌生的技术，在之前的开发过程中投入了相当多的学习成本，项目进行的比较艰难，不过经过alpha冲刺后初有成效，组员都在实打实的learning by doing。
  • 管理方面：没有使用进度管理工具，队长都是通过开会和在线聊天收集组员的每日进展，效率可能不够高。

针对上述情况我做了以下工作：

  • 技术方面：组长打算让我直接接管离队成员的工作——编写管理员模块，这也是项目目前留下的最大的坑，用原生的java web来实现，同时要兼顾前端的编写，这些恰恰是我最不会的，于是这几天都在熟悉离队成员遗留下来的代码，同时在技术储备，看的也是有点头疼😂。
  • 管理方面：向队长推荐了leangoo来跟踪进度，此外还想把之前在快乐就队的一些好的经验带过来，具体还要和队长多多交流。

截止博客提交，能够理解项目需求，大致理清了遗留代码，有些地方还是存在疑问，离队成员貌似也不能给我太大帮助，打算β冲刺时具体情况具体分析。

三、组长描述为新成员安排的组内角色，以及自己是如何面对之前的成员离开队伍的，具体做了哪些措施，是否有调整开发计划，开发计划调整了哪些部分？

作为组长为新成员安排的具体是被换走的成员的剩余工作，由于新成员和旧成员的技术不同，所以使用新成员的技术为主，任务仍然是旧成员手中的剩余任务，由于正好旧成员的手中的任务可以和主要开发计划分隔开，是两个计划任务，所以相对与开发计划调整较少。

四、组长需要描述自己为新成员安排的任务

分配的任务为学习Android的相关知识，但由于新成员的任务涉及Android知识较少，所以只是需要涉猎即可

五、新组员和组长感想和收获。

新组员：任务艰巨！被换组还是有一定的心理落差的，有些东西意味着要重头再来，而且最近我的个人事情也变得多了，我不能确保自己能够做的和之前一样好，但是我依旧会尽力而为。收获的话主要是意识到了自己java基础还是很薄弱，框架用多了的我，在原生java面前产生了恐惧心理，这次换组给了我一个机会去战胜它。

组长：很难，因为换走的成员相当于也是一个相当重要的成员，对于组长是一个艰巨的挑战，尤其是让新成员以最快的速度了解本组的任务，由于组内有一些地方做的不是很规范，所以给新成员的适应造成了不少困扰，感觉作为组长是需要承担更多的责任的。

posted @ 2020-05-28 17:09  RGSJ队  阅读(212)  评论(3)    收藏  举报