事后诸葛亮

项目Alpha冲刺（团队) --事后诸葛亮

1、团队信息

队员学号 队员姓名 个人博客地址 备注
221600427 Alicesft https://www.cnblogs.com/LinkF/
221600429 哈噻 https://www.cnblogs.com/liujianhao21/
221600436 Xu~ https://www.cnblogs.com/xzh0517/
221600437 AWX https://www.cnblogs.com/hawx/ 队长
221600438 ZHC https://www.cnblogs.com/mzhc/
221600440 小冰 https://www.cnblogs.com/xiaobing666/
221600441 拉哇吉 https://home.cnblogs.com/u/banglc/

2、设想和目标

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

答：我们要开发一款基于三国题材的卡牌通关对战手机游戏并附带游戏官网。通过多次答辩与修改我们对用户和场景的描述还算清晰。

  1. 我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ )

答：游戏端和官网的α冲刺计划都按时昨晚并提交了。

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

答：上一阶段主要都在做设计、需求这块，质量主要体现在分工和讨论的结果，这一阶段是实现代码阶段，定义好接口和代码规范之后编写速度加快。

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

答：在实现过程中没有出现什么大问题。重来一遍的话，可能会尽量再美化一下界面。

3、计划

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

答：是的，但是因为计划有时候因技术的认知不到位或者是因为需求有着一些变化总会存在 偏差，所以，后期计划可能与实际情况存在一些偏差

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

答：先是提出不同意见，在讨论之后，通过投票做出最后的决定。

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

答：原计划任务已按时完成，完成了项目预期的验收标准。

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

答：是的，在完成数据处理接口的之后发现有更好的方法或者是不太符合规范，那么就需要进行修改。

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

答：有的，通过原型设计、需求分析、以及功能验收标准来定义和衡量。

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

答：全部按照原计划进行不太可能，因为这个项目的任务具体到了天，所以，当队友有一些事情不得不处理的时候，就需要协调其他组员来一起完成或者是计划在不偏离最终目标的条件下做一定程度上推迟。或者是当对技术的认知不清楚的时候，就需要重新安排时间学习新技术，在短时间内改变计划但不会影响最终的进度，所以计划在总体上是有有序的，但在局部会存在变更。

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

答：有留下缓冲区，在每项短期计划当中，都有留有一天的时间作为缓冲区；
有用到缓冲区，首先，任何的项目计划都有可能存在偏差，首先，组员都是没有任何项目经历的萌新，对项目的预期估计存在偏差肯定离不开这方面的原因，另外，组员的技术认知以及掌握程度都不深，很难对技术需求以及完成计划做出准确的预估，所以留有缓冲区解决以上的问题是十分必要的。

  1. 将来的计划会做什么修改？

答：在计划上，还是留下缓冲区的；缓冲区是给在项目出现非可控因素导致的计划无法预期完成的意外留下的，前期的任务会比较繁重（每天的任务时间较之前可能会有所加重，所以增加该课题的时间成本是十分必要的）。虽然会比较累，但是留下这个缓冲区还是十分必要的，因为我们永远没办法意外会在哪个时候发生。

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

答：整个项目的规划以及实现，让我们真真切切地感受到了完成一个项目的所需要付出的东 西的确有很多，难度与复杂度也不是一般的高，比如需求的调研，分析，给出预期的原型设计，完成类图等等对项目的分析与规划；各种各样的任务，需要通过组员之间的沟通与协调组员的才能的发挥，在最大程度上实现个人与项目利益的最大化。

如果再来一遍，需要在需求分析阶段，把需求用例好好的梳理一遍，是十分必要的，这样才能够更加的明确整个项目的目标，不然在前期的时候，很难对项目形成一个有效的认知。并且在任务的安排上还是需要有一些改进，充分发挥各组员的才能与调动组员的积极性。

4、资源

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

答：时间还算足够，但前后端，unity都采用了框架来开发都需要时间来学习，测试都有自带的工具，资源丰富还可以。在网上和淘宝收集到了大量的图片资源。

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

答：先划分任务，然后个人根据自身情况接受任务，时间精度很粗略，都是一个任务完成再做下一个任务。

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

答：人力、软件资源充足，测试方面，游戏端，和官网后端都有自带的测试工具，资源相对充足。编写前端时，对那些图片的像素处理是真的烦，美工还是很重要的。至于硬件方面,我们目前拥有的硬件足以支持我们的开发需要,但是后期如果项目上线的话目前的硬件水平远远无法满足实际需要

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

答：我觉得如果让一个熟悉所用的框架的人来编写，不管是时间还是做出来的质量应该都会更好。

5、变更管理

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

答：有，在做完一定量工作时都有进行汇总和商讨，同时队友也能通过github清楚的了解到工作进度。

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

答：一般是当一项任务的完成作为被其他多个任务所依赖时，以及根据我们最初的设计，所要达到的基本功能还有作为最基础的底层设计是必须优先实现的，而当一项任务较为独立或者在开发过程中想出的新的不错的点子则可以作为推迟实现的。

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

答：有，就这个项目来说，网站上能够允许用户注册登录查看资料，和游戏中基本的联网对战和一定数量的卡牌保证可游玩性是作为“做好了”的最基础定义，其次再加上较为符合审美的美术和无严重恶心BUG就能够达成我们认为的做好了。

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

答：这方面在出现较大的改动（比如游戏玩法，核心机制）时可能比较难制定出应急计划，当要是较为合理地变更（比如战斗方式，卡牌设计，UI设计）

6、设计/实现

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

答：在做完需求分析之后就开始了，官网和游戏分为两批人，我们认为算是比较合适的时间，人员也是选择对这些方面有着较深了解的人，算是挺合适的。

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

答：有，一般是通过反复讨论最终统一，期间有互相否定提案也有出现相同提案的情况，总体上是先讨论整体再讨论细节，细节部分有着比较多含糊之处，花了较多时间讨论。

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

答：主要使用UML来进行设计，还有通过制作原型表现可视化设计。虽然在前期的设计就已经对UML类图、流程图之类进行了反复细化和修改，但在开发

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

答：UI的表现层，因为效果的显示总是比较难表现，其中的逻辑也比较复杂。出现过许多莫名其妙的bug（例如卡牌不显示或飞走不见之类的）。这主要是由于代码的逻辑bug还有对技术掌握的还不够成熟，其中的原理不够了解导致的。

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

答：代码复审是通过人工自己阅读代码再结合工具（例如Resharper之类）。严格执行了代码规范，因为通过使用Resharper能够清晰的看到哪一处的代码不规范。

7、测试/发布

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

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

答：还没有 因为没有做到可验收的版本 可验收版本将在Beta版本做完

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

答：网站部分主要使用框架自带的dd打印函数以及一些自带的验证函数在开发功能时进行监控测试

我们完成的Unity 基础UI 及卡牌的脚本基础脚本部分不是很需要测试工具测试 没有使用工具

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

答：Unity 自带的性能显示工具 ,使用Apache Bench来测量服务器关键接口的QPS

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

答：laravel 本地环境参数 和服务器上不一样 ,需要手动设置

8、团队的角色，管理，合作

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

答：每个人先在一个表格中填入自己擅长的领域,然后根据任务的内容大致确定每项任务需要的人数,剩下的就全凭个人手速了,这样做可能会有少数人并未被分配到自己想做的领域 但是因为团队规模较小,不可能做到团队成员完美匹配项目

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

答：当然 每个小项目的划分都是两个人以上为一小组,这样便于互帮互助 ,此外遇到较为棘手的难题是会在小组会议上提出 寻求大家的意见及建议
例如在网页端的上线的时候,遇到中间件搭建的问题,我们向负责游戏的同学寻求了帮助最后成功解决了问题

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

答：项目管理并没遇到什么比较严重的问题,大家都非常自觉的按时保质保量完成前期计划要求的进度,而合作方面冲刺阶段每天的例会主要解决的就是这个方面的问题.

9、总结:

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

答：达到了CMMI()的程度。我们团队遵守了既定的计划和流程，有资源准备，权责到人。但是还没有一套完整的管理措施，没有制度化。

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

答：规范初期

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

答：已经有良好的沟通交流能力，团队合作能力和默契能力也在不断提升，开发效率有很大提高

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

答：界面的UI是最让我们这些不擅长美工的人困扰的

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

答：团队定期反省如何能够做到更有效，并相应调整团队的行为。事后诸葛亮即是如此。
无论是团队内还是团队间，最有效的沟通方法是面对面的交谈。我们团队每周都会进行一次例会，把开发过程中遇到的问题提出来进行面对面沟通交流。

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

答：坚持在开发过程中将遇到的问题进行面对面交流，出现问题及时修复，不能囤积导致后期工作量增大。冲刺阶段每天的博客需要认真完成，总结反思一天下来的工作情况。

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

答：关于代码规范和复审：采用一些成熟的大型公司提出的标准来执行，这样即能够全面的考虑到各种代码的可读易读，又可以确保没有歧义；需要有良好的编程习惯，做好代码中的注释；第三，我们还必须考虑到代码的美观，需要使用一致的缩进
关于代码复审： 审核发现的问题，应该由代码编写者自己去修正或者重写
关于提高代码管理质量：不要复制代码；及时测试完成的代码；进行代码审查；将整洁的代码风格作为一种习惯，时刻意识到整洁代码的重要性并不断地提高重构技巧

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

答：模糊不清的方法名会影响代码的可使用性。这些模糊不清的名称应该重命名为有意义的可能与业务术语有关的名称，来帮助开发者通过业务上下文 更好地理解代码。

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

答：软件工具主要分为项目管理工具、配置管理工具、分析和设计工具、程序设计工具、测试工具以及维护工具，下一阶段我们要掌握的主要的维护工具，这一方面打算查找视频进行自学

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

答：综合管理能力有很大提高，同时学习了更多的知识，不仅仅是技术方面的还有人力资源管理、项目管理专业知识等方面。培养了情境领导、人际关系、谈判与沟通等技巧能力。

  1. 项目文档的质量如何提高？

答：到网上查找一些已完成的比较成功的项目的项目文档来浏览学习，同时也可以参考同期优秀小组的项目文档。

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

答：既然组内已经达成一致要完成一个项目，那就肯定每个人心中都有自己想要做的工作，就例如，有的同学想做前端，有的想做后台。按成员意愿分配任务。同时能力较强的成员在完成自己的任务后可以帮扶一下能力较弱的成员。

  1. 对于软件工程的理论，规律有什么心得体会或不同意见？ 请看阅读作业。 (这个作业的期中阅读)

答：软件工程的概念贯穿了整个项目，从一开始的项目选题到需求分析再到最后的项目版本发布与后期维护。而项目管理及并不像想象中那么容易，即使是三年的同学也不能够配合的尽善尽美。

10、会议照片:

11、交换组员的交接和培训方案

换走的成员在团队中主要负责官网的搭建，交接和培训任务主要在交接学习资料，工作现场等并帮助新成员上手融入新团队中。主要有以下几点

任务交接部分：

  • 整理开发过程中的接口文档，即Laravel框架中路由、控制器和视图的约定、文件管理要求等
  • 移交自学所参考的网络文档和视频教程，帮助了解开发任务

开发培养部分：

我们的官网开发主要是使用Laravel框架，开发培养任务主要在于培养新成员的官网开发能力

  1. 大致先对composer类库管理工具有一定的了解，再熟悉Laravel项目的文件结构
  2. 开始了解路由、控制器和blade模板视图三者的配合，对数据库和Eloquent等做适当了解
  3. 对于其他具体的使用不懂就问度娘

身为团队的前成员，小冰策划有话说：遇到小问题尽量自己尝试解决,这对新成员的融入有帮助，实在不清楚的地方，例如项目后期也许会遇到游戏与官网对接调整的问题，这涉及到Laravel底层实现的修改，我也会帮忙的

posted @ 2019-05-06 20:22  NSJN  阅读(337)  评论(0)  编辑  收藏  举报