标签：考试科目 调整 检查 原因 租用 bug 驱动 时间进度 统一
我们的软件主要是解决在宿舍中购买商品的软件，不同于淘宝等软件，本软件主要是用于学生开设的店铺及宿舍楼中的购物。定义相对较清晰，暂无场景的描述。并没有很充足的时间，大三课程不少，团队成员还有很多课外课程。主要是通过协商讨论解决，在分歧较大时，听取有可靠可行性方案的。因为进度较慢，还没有完全的功能，暂时还没有用户使用，但离目标更近了一步。在每一个阶段要让每个团队成员有事可做，不然会出现进度过慢的情况。如果在有一次，会抓住重点，先完成所有的基本功能实现，不然最后什么都做不完。原计划并没有全部完成，只完成的商品的展示，并没有完成商品的购买功能。未完成的原因主要是前期的任务规划不合理在页面设计时浪费了一些时间，本来注册和登录功能应该实现，但因为排版有问题最后不得不推到BETA阶段。 大多是任务有明确的定义，但没有规定交付量，导致每个人只知道每部分要做什么，但没有具体的进度。大体是按照计划进行的，但中间的考试和假期都拖慢了进度，考试没有估计到会在项目的冲刺阶段。没有留缓冲区。设置预留时间，将整个安排向前推3前到一周。合理分配时间，严格按照时间进度来，并设计预留时间。因为使用的是jsp，虽然网上关于jsp的教学资源非常多，但时间很少去学，而且对于服务器的租用不太了解。前面的知识准备花了很长时间，alpha完成基本的商品查看和浏览功能，购买和用户注册等在beta阶段完成。 对于测试部分应该让编程相对少的成员来完成，一方面是任务的合理分配，另一方面是编写程序的成员存在一定的思维定式，对于一些比较明显的问题可能存在视而不见的情况。让每个人充分了解自己的任务，并定期进行进度检查。因为有通知群，而且冲刺阶段还有站立会议，所以基本消息能第一时间通知到每个人。对于基本功能的实现是必须实现的，即基本的购买和展示是必须的，排版和美工可以后期。没有明确的定义，因为需求会在不断的开发中被不断的发现，而且对于完成后期用户的反馈也会影响一些功能的改进。基本没有应急计划。
基本可以处理，因为进度计划的灵活性比较大。在代码规范和成员任务协调要改进。设计工作由组内进行讨论，通过大家伙的商量，确定了一个统一的意见，期间，参考网上类似的界面设计。实际的界面和预想的有一定的偏差，比如，商品图片大小和对应商品信息字体大小等等。在冲刺阶段的时候，多次进行调整，最后定下了界面设计。在Unit test的时候，是由每个人测试自己的模块，遇到瓶颈的地方，在每日碰头会上进行讨论，测试的话都是手工测试，遇到问题就修改完善。Alpha阶段由于大家伙有考试科目，所以工作量比较小，最终的功能实现了商品信息的查询访问，没有产生Bug。在项目开始的时候制定了统一的代码规范，所以在项目进行过程中严格根据规范书写代码，为后期的复审减轻了不少麻烦。初期大家伙复习了之前学习的java和sql sever的内容，通过这次项目我们学习到了把前端后端给联系起来，相较以往的仅仅在编译软件或者文本中实现变成运行，这次做得更贴切与实际应用，对此有了一定的认识，如果在前期把时间安排的更加合理的话，我们就能实现更多的功能，初定打算是要搞一个测试的。
原因：上面有提到，由于课程安排和考试安排，在冲刺完项目的部分功能就转而去复习科目了，所以把测试给耽搁了。没有比较明显的bug，从软件实际运行结果来看，测试工作对于这次来说用处不大，因为实现的功能有限（bug都不屑于出现）如果重来一次，我们打算合理的安排好时间，尽量多的去实现它的功能，这样在进行测试的时候就会发现更多问题，而不是局限与在一两个功能上，这样反而发现不了什么。1. 在Alpha冲刺之前，我们团队有针对我们的项目做过需求分析以及项目计划
2. 在Alpha冲刺阶段，尽管我们小组一开始没有通过github进行项目管理，但是每天会向组长汇报自己的工作量以及工作进度
3. 在Alpha冲刺之后，团队有了类似项目的开发经验，一定程度上可重复类似项目的软件开发
4. 小组有测试人员，通过案例测试充分保证了软件Alpha版本的核心功能的使用以及质量地保障现阶段应该定义在介于磨合和规范阶段吧，下面简单谈谈项目初期到现在的过程：
1. 在Alpha冲刺之前，我们团队每个人都没有项目开发的经验，虽然我们之前学过JAVA和sql server，有一定的JAVA语言基础，但是并不知道自己适合于整体框架中的哪一部分。
2. 在Alpha冲刺阶段过程中，PM之前的讨论，大致给我们分配了各自的分工，其实大家都差不多，说不上明显的擅长的地方，最重要的是，我们敢于担起责任，不懂不会就学嘛。
3. 在Alpha冲刺之后，团队的每个人都可以对自己的分工，可以说出几句心得体会，通过冲刺过程的讨论，对于整体的认识可以说较之前有了大的突破。前一个里程碑就是自己干自己的小作品，可以说根本对于团队合作的感觉是啥都不知道，通过这次团队合作，我们一致发现，有些问题拿出来讨论一下，比你自己冥思苦想来得简单多了，而且通过合作，能激励彼此的学习热情，知道自己该做什么，无形中就有种督促去完成任务。最需要改进的地方就是多交流学习的心得，把自己遇到的问题，怎么解决的给组员好好分享一下，这样既能加深团队的感情，而且对于自己在写代码也是很有帮助的，一开始大家不放不开，觉得羞涩，不敢说————其实究其原因，大家伙学得不够扎实，说不出个一二三来，但是经过一段时间的学习，再讨论就有得说了。最重要的是通过讨论可以去统一大家伙对于项目的思想，形成连贯思想，做出来的东西，像是出自一个人的手上。标签：考试科目 调整 检查 原因 租用 bug 驱动 时间进度 统一
原文地址：https://www.cnblogs.com/999yebuxing/p/9046184.html
