Beta冲刺——问题总结博客

Beta冲刺——问题总结博客

设想和目标

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

为大众提供一个匿名聊天、倾诉心事的场所。
定义为匿名性强、不以交友为目的的聊天软件。
针对 传播不法、违规信息的用户 及 恶意举报、进行不符合道德交流的行为 制定处理方式

定义是否很清楚

定义较为清楚

是否对典型用户和典型场景有清晰的描述

在需求分析文档和系统设计文档中都有清晰的描述，下面进行简单的概括总结。

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

原计划功能

原计划完成相遇的朋友，个人中心，登陆模块和动态模块。

否按照原计划交付时间交付

基本按照原计划交付时间交付，燃尽图燃尽。

原计划达到的用户数量达成情况

未达成，还未发布。

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

经验教训
有关后端部分，接口定义一定要十分准确，一定要与前端及时沟通，保证效率
改进：
增加预留时间，同时强化前后端组员采用共享文档的方式进行小组的接口的协调和确定。

计划

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

在beta冲刺前我们又两周来准备此阶段计划，所以时间算是很充裕的。

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

先由组长和另外的管理人员指定计划，如有异议，则成员提出问题，征求各个组员的意见，实在不行最后投票，大多数人同意的通过。

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

基本都已经完成。有些模块功能虽然完成，但是明显交互或者内部一些部分不合理，等待beta阶段完善。

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

测试人手不足，环境当时的确定有点草率。

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

一项任务都在文档上有清晰的要求，要求组员并又一定的交付基本的衡量要求，如图片，文档。

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

项目在α阶段因为新组员的磨合和线上开发的问题，导致配合及共同开发出现了一些问题，整体进度中间有出现滞后的情况，此时我们组通过及时开展讨论共同解决以免滞后影响后面进度，好在最后项目基本按计划完成。

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

我们项目留个五天缓冲区，这五天主要用来学习新知识，还有就是开发过程中遇到的问题能及时进行修正完善。

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

保留缓冲时间，如重要的功能进度落后则必须加班在期限内完成。一些功能部分的开发不能拖到加班与缓冲时间，提倡提前完成任务。

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

时间的合理安排真的很重要，我们会强化在线文档的使用，力求通过在线文档能使组员的进度和完成情况有实时的认识。同时对开发时间的缓冲区进行保留甚至增加，力求实现能达到更好。

资源

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

时间

模块较多，且重要功能的相关框架较为复杂，使时间这方面较为不足。

技术

在beta开发前有一段时间的休整期，这段时间有督促组员去完善自己所在部分的知识，但是仍然感觉知识方面只是勉强够用。

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

通过各模块成员目前自己对自己知识的掌握程度，提出一个最长的时间，然后在最长时间内除以1.5得出最终计划的时间，并要求他们按这个进度开发。

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

测试的时间，人力和软件/硬件资源这方面应该算是足够的。但是关于美工、文案方面，没有专门的人负责，导致由组长进行书写有时感觉压力确实太大了。

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

后端人员可以适当帮助前端人员进行测试，后端人员有点太多了。

变更管理

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

我们组采用teambiton和在线文档的方式共同管理，组长根据组员的每日完成情况，进行管理工具的更新，同时组员可以收到来自组长的关于任务变更的消息。

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

通过功能的重要性与难易度来判断

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

接口联调好同时和前端进行接口的使用确认成功就算功能做好了，同时前端要通过界面的测试和整体使用过程没有问题的出现。

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

万一出现意外，我们会进行沟通并联合解决。

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

组员能完成自己分内的事情和即时对意料之外的工作请求进行反馈。

设计/实现

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

设计工作都是由组长先进行人员分配，然后询问组员意见，没有意见的话就按原本的执行下去，有的话就共同讨论决定。每次任务的人员分工都在每个阶段的博客中详细体现，也能够较好的完成工作

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

讨论，投票解决。

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

单元测试：有效、快捷、能实时进行处理，同时很方便进行重复的操作，有助于代码的完善。
UML部分：在开发中，实际本来想得一些事情，在后期的处理中进行了简化并实时更新，这样也为后续的迭代提供了保证。

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

动态功能产生的功能较多，首先是前端动态界面出现了大大小小的显示和逻辑响应的问题，之后后端对于点赞的处理也出现了问题，前后端接口的商讨和交互有问题。

代码复审

后端每个人在开发过程中进行代码风格的统一，前端自己进行约束统一，因为习惯差不多，代码没有出现太大问题。

测试/发布

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

采用自上而下的测试方案，后端采用postman+junit 前端采用hbuider+mui进行测试。

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

前期时间有限，验收测试只是在对基础功能的使用上进行了基本的测试。

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

后端：postman+junit
前端：hbuider+mui+模拟器

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

有关这方面的测试在alpha阶段没有进行。

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

alpha阶段主要采用的是本地测试，所以对于发布这方面的问题还未知。

团队的角色，管理，合作

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

根据前期组员的兴趣爱好的方向确定的，基本做到人尽其才。

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

有，因为是新团队，所以经常遇到问题共同在群里讨论共同解决。

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

观点投票制度，少数服从多数。

总结

计划说明

通过这十天以来的alpha冲刺，我们组的预期计划主要是完成登陆模块、个人中心模块、相遇的朋友模块、广场模块，和管理员模块的主要功能，当初设想的是我们的项目的模块较多而杂，且不同模块间功能有一定的相互影响，我们组通过三个人员（计划组）两个后端一个前端讨论后，决定先实现基本项目的雏形和功能，其中一些类似推荐算法、安全性问题留作beta冲刺阶段再做，因此最终划分出来的alpha冲刺的模块就为上方所说的几个模块构成。

现实计划

现实进展的话，因为中间有一些前后端人员商量沟通不足，接口不明确的问题，导致中间有一定的进度停滞，我们组采用的是大家停下来，一起帮忙查看问题并加快解决，不使之后留下任务持续落后的情况，这也使我们的任务不会在任务燃尽时与原本进度有太大偏差，最后整合测试阶段虽然还发现一定的bug，但是经过询问讨论也得到了解决，与预期进度没有太大的落后的情况。

个人总结

洪楷滨

1. 前后端人员的交流沟通有待加强，在测试阶段，发现一些错误明显有一定的沟通就能顺利解决，接口虽然用的是json工具类，但是交互的方式也有所不同，同时有发现一定的按钮失灵的现象。
   
   解决：去找该模块的前后端人员进行询问，以屏幕分享的方式问其中的一些逻辑和交互。
   
   心得体会：前后端人员前期和开发过程中的协商和交流很重要，有详细的沟通可以使最后测试的问题大大减少。
   

2. 因为我们团队里没有真正做过大项目的人，所以一开始的ssh环境配置碰到了不少问题，因为网上大部分是spring+springmvc+readies 环境配置，所以我们在环境配置过程中也有遇到service无法注入，编译器环境无法通过的问题，tomcat无法启动等等。
   
   解决：最后通过查找资料都得到了解决。
   
   心得：项目的环境配置也是门大学问。

3. 在各个模块分工下去后，因为我们前端人员在前期对后端环境的配置有点问题，同时我们经过讨论决定在alpha阶段使用本地环境测试，等beta阶段再部署到服务器上，所以发现部分模块的前后端的测试明显不足，导致到最后的整合测试阶段对代码的改动调整还是有点大，使的测试的过程与预期进度相比较显得有些慢。
   
   解决：后面整合测试的人员就问题统一与模块人员沟通进行修改测试并发布整合到github仓库中。
   

4. 聊天部分使用netty难度有点大，一开始遇到配置自启动的问题，客户端连接的的问题、 还有聊天过程中消息的传递和存储的问题。
   
   解决：最后通过网上查资料和多次尝试，成功解决了。
   
   心得：短时间内想要很好的完全理解掌握一门技术不容易啊，还是要经过多次尝试和查阅才能很好的解决自己的困惑。
   

5. 项目管理真的不好做，因为当有些问题真的是很难的时候，进度不好规划，好在之前有先和另外两个组员共同规划，给出了适当的模块规划和任务规划，中间虽然有碰到大大小小的不同问题，好在最后燃尽图也顺利燃尽了。

林海峰：

1. 心得体会 个人开发：由于本次实践中，团队选用的mui框架自己以前从未接触过，所以即便是有提前看了一些教程，最后去实现功能时也是各种踩坑，算是边学边做吧。好在队友找到了类似我们项目的mui程序开发教程，所以能从中学到不少当前急需的知识，不过如何有效地将教程中相似的内容完美地运用到自己负责的任务中也是一大考验，只能说且行且研究！开发过程中，遇到的问题总是五花八门，而mui作为一个比较新的框架，相关资料偏少，“面向百度编程”解决问题的路子根本行不通，只能凭借以往编程的微不足道的经验去理清程序运行方式，然后从中找寻可能的解决门路，这个过程也是一种升华吧。
2. 团队开发：因为我们团队也算不上是一个相互熟悉配合默契的集体，所以开发过程遇到了不少前后端交互之间的问题，导致整合的时候，总是会产生各种各样的困难。大概还是需要进行加强一番配合吧！此外，因为我又负责前端安排，为了方便问题定位，所以我让前端的队友在自己创建的文件命名上必须带有名字缩写前缀，这样一来后续整合与测试时我能很容易知道有问题的是谁负责的模块，然后通知或询问对应的队友进行问题的解决。效率感觉因此有一定程度的的提升。
3. 自己模块测试遇到问题和解决问题
   
   最开始测试时，电脑没有javaee环境，面临后端环境搭建困难繁杂的问题，花了一天最后都没解决用eclipse搭建的方式。解决办法：找后端队友帮忙，改用更为简单的idea搭建，并用上前面一天时间里下好的tomcat,maven,postman，后端环境搭建算是顺利完工问题.

林露

1. 万事开头难。一开始做个人中心的时候，什么也不会，内容也多，进度真的是很慢。刚开始写的时候，不知道该写什么，只能照着原型先把界面做出来。然后再写js部分，以及页面的渲染。之间commit了无数次，才算是把这些东西写完整了。前后端的联调也很不方便，说起来都很辛酸...不过总算是做出来了！一切都值了。

陈如滨

1. 前端部分门槛比较低，不需要像后端一样部署环境。但是因为用了plusReady所以要在手机模拟器或者真机上运行才能看到效果，稍微有一点麻烦。大部分功能的测试都是后端人员完成的，因为他们部署了环境比较方便，所以受到了很多照顾。前端使用的是mui技术，有官网出的mui文档，都是比较基础的功能。网上的教程、示例较少，找资料花了比较多时间。因为都在家里没办法面对面沟通，所以技术、问题的交流变得比较麻烦。

黄毅

1. 我太难了，感觉中间编程遇到的环境问题和编译器的问题让我心态爆炸，好在最后顺利完成了。

黄筱宇

1. 和队友的沟通交流很重要，很多时候自己如果只是盲目地纠结一些bug可能卡着很久都不能解决，但如果和队友说明一下问题，有些问题队友之前也遇到过并知道解决方法，就能更快地解决问题，提升效率。这点在每日站会中能够较好地体现。
2. 对实现功能会有存在误解的情况，写之前需要和队友进行一个交流讨论，不然可能出现按照自己的想法写完了功能到提交阶段却发现不是团队所需要的。

李波

1. 框架的使用给我们带来了很多的便利，帮我们解决了不少的麻烦、很多问题到了实现的时候才会体现出来、版本的管理非常重要。

陈炀

1. 最大的心得体会就是技术太菜了,这次实际开发之后就发现了,对于github的是用还不够熟练,导致很容易出出现更新不及时的情况,其次就是我们小组的开发规范没有做很好,各个模块组织的不是很合理,前后端对接接口不够流畅加大了测试难度,还有就是业务流程思考的还不够齐全,容易出现遗漏,我在前后端联调的时候经常感觉有些不足,要不就是动画流程少了,要不就是效果没有实现
2. 最后就是技术选型,我们采用hibernate框架来进行持久层框架,但是由于hibernate资料相对mybatis比较少,spring和springmvc的配置也比较繁琐,搭建环境这一步就出现了很多问题.
   
   总的来说,开发开发还是要实际上手开发过之后才有发言权,我认为随着我们组的配合逐渐加深,在实践后半段我们可以有更好的表现.

代码规范

复审则是需要尽可能多的人对不同的部分进行复审，规范制定方面则是要全部人员参与，各抒己见，交流得出最优的代码规范，并且有选择性的接纳他人的编码习惯

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

这方面架构的知识还不清楚，后期会通过查询相关知识提升质量。

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

应该多尝试性能和压力测试工具，提前为项目发布做准备。

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

经常被说贡献度平均，下个阶段采取责任制度，对组员贡献度有一定的把关。

项目跟踪用户数据方面，计划要提高什么地方？例如你们是如何知道每日/周活跃用户等数据的？

问卷方式进行用户的调研和项目的改善。同时，有后台系统对用户的信息进行查看。

对于软件工程的理论，规律有什么心得体会或不同意见？

在文档编写上，文档格式一定要有提前的确定，同时对各部分的质量也要做好把关。
代码使用的话，可以多去查看一些有用的sdk,和查看他人代码，但是不要进行盲目的复制粘贴。