标签：是什么 内容 作业 团队 hive 现象 并且 体会 关于
我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
答：解决当前社团管理问题，定义比较清楚，有清晰描述。具体说明
我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)
答：计划的功能基本上都实现了，当前主要问题就是小程序没有过审，并且因为小程序的原因，用户数量没能达到预期。
和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高，具体提高了多少，如何衡量的？
答：提高了，任务进展速度比上一阶段快了不少，不仅上一阶段的bug都解决了，并且基本功能都已经实现，并且项目管理更加的规范，任务更加细分，GitHub使用更加频繁。
用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
答：不一致，离我们的目标更接近了。
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
答：应该更加及时的关闭issue，更早的将小程序进行审核。
是否有充足的时间来做计划?
答：有的，一周的时间足够我们对项目重新进行规划和反思。
团队在计划阶段是如何解决同事们对于计划的不同意见的？
答：计划都是在开会讨论的过程中定下来的，如果有不同意见，提出自己的方案，并提出理由即可。
你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
答：基本上都做完了。
有没有发现你做了一些事后看来没必要或没多大价值的事?
答：没有。
是否每一项任务都有清楚定义和衡量的交付件?
答：定义十分清楚，交付需要在开会时展示代码，并且需要将代码上传到服务器后在网页端测试无误，才能交付。
是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
答：基本上都是按照计划进行的，唯一的意外就是小程序多次不过审，主要原因是小程序审核规则在一年间变化过大。
在计划中有没有留下缓冲区，缓冲区有作用么?
答：有缓冲区的，每个任务期限都比较长，并且会因为计网实验等因素进行延长；有作用，缓冲区能够让他们有充分的时间开发，但是在一定程度上会产生拖延的现象。
我们学到了什么?如果历史重来一遍, 我们会做什么改进?
答：我们学到了在对项目没有了解充分的情况下，不要轻易地做计划，任务的划分也不能太粗线条，粒度要细，争取每一天都要有进展。
我们有足够的资源来完成各项任务么?
答：经过alpha阶段之后，我们每个人都进步不小，基本上掌握了相关的知识，可以完成各项任务。
各项任务所需的时间和其他资源是如何估计的，精度如何?
答：因为是第二次分配，对任务有了更好的理解，根据第一阶段相关工作所花时间，进行任务规划和资源分配，精度不错。
测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
答：足够，我们分配给后端一人在开发全程进行测试工作，美工设计尽量沿用上一届的思路，难度降低不少。
你有没有感到你做的事情可以让别人来做（更有效率）?
答：可能全栈大佬来做PM会更有效率，安排也更加合理。
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
答：任务的粒度可以更加细分。
每个相关的员工都及时知道了变更的消息?
答：β阶段转走和转入一名同学，在会议上都已经进行了说明，大家都知道变更信息。
我们采用了什么办法决定“推迟”和“必须实现”的功能?
答：“推迟”就是不影响整体进度的功能，需要开会讨论，其他的功能都是必须实现。
项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
答：在截止日期前能够完成尽可能多的功能，并且目前已经完成的功能在使用过程中不会出现致命bug，则我们的项目就能够出口了。
对于可能的变更是否能制定应急计划?
答：可以的，在图片上传中间件没有调试好时，我们采用图床来储存相关图片。
员工是否能够有效地处理意料之外的工作请求？
答：能够，后端的工作更多的靠前端推动，比如api的提出，以及api的修改，这些工作都是十分的突然，但是都处理的很好。
我们学到了什么?如果历史重来一遍,我们会做什么改进?
答：我们学会了这种任务驱动型的工作方式，合作更加的紧密。
设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
答：设计工作在计划的那一周进行的，是合适的时间，大家一起设计的，比较合适。
设计工作有没有碰到模棱两可的情况，团队是如何解决的？
答：无。
团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
答：社团信息编辑产生的bug最多，因为前端和后端没有沟通好，导致数据类型不合适，并且部署上也有问题，发布之后没有特别大的重要bug。
代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
答：主要由组员yzx进行负责，代码签入和bug修复，都需要由负责人员和yzx单独展示。遵守了代码规范。
我们学到了什么?如果历史重来一遍, 我们会做什么改进?
? 答：我们学会了如何减小代码签入引入bug的风险，如果历史重来，我们将会更加贯彻这一点。
团队是否有一个测试计划？为什么没有？
是否进行了正式的验收测试？
团队是否有测试工具来帮助测试？
很多团队用大量低效率的手动测试，请提出改进计划：至少一个方面的测试要用自动化的测试工具，自动化的测试结果报告，比较测试结果的差异，等等。
团队是如何测量并跟踪软件的效能（Performance）的？压力测试（Stress Test）呢？ 从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
在发布的过程中发现了哪些意外问题？
我们学到了什么?如果重来一遍, 我们会做什么改进?
团队的角色，管理，合作
团队的每个角色是如何确定的，是不是人尽其才？
答：团队角色一般采取认领的方式，大家先在群里讨论出前端和后端的具体分工，然后大家自行认领，基本上算得上人尽其才。
团队成员之间有互相帮助么？
答：有，后端的工作一般都是寻找api的bug，后端常常一起负责。前端经常进行技术交流。
当出现项目管理、合作方面的问题时，团队成员如何解决问题？
答：一般通过PM来寻找合作的同学，尽量发挥PM的协调作用。
每个成员明确公开地表示对成员帮助的感谢 （并且写在各自的博客里）：
我感谢 _______<姓名>______对我的帮助， 因为某个具体的事情: _____________________。
总结:
你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
? 答：CMMI一级，完成级，项目目标和要做的事情都很清晰，但是在完成项目的过程中，往往会遇到很多的困难，完成具有很大的偶然性。
你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
? 答：属于磨合阶段，主要是开发过程中没有严格按照流程进行。
你觉得团队在这个里程碑相比前一个里程碑有什么改进?
? 答：代码规范，任务进展，测试等等方面相对于上一阶段有很大的进步。
你觉得目前最需要改进的一个方面是什么?
? 答：工作流程还是需要改进，GitHub还是没有按照规定使用，上传代码、issue关闭不及时。
对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
正如我们前面提到的， 软件的质量 = 程序的质量 + 软件工程的质量，那团队在下一阶段应该如何提高软件工程的质量呢？
代码管理的质量具体应该如何提高？ 代码复审和代码规范的质量应该如何提高？
答：GitHub上传要更加的及时，需要灵活的使用issue机制。
项目跟踪用户数据方面，计划要提高什么地方？例如你们是如何知道每日/周活跃用户等数据的？
答：小程序还是没有审核通过，因此用户数据较少。
项目文档的质量如何提高？
答：在新增api和网页新的功能时，需要添加新的文档内容。
对于人的领导和管理， 有什么具体可以改进的地方？ 请看《构建之法》关于PM、绩效考核的章节， 或者 《人件》等参考书
答：我们贡献评价体系太过笼统，可以加入互评的体系。
对于软件工程的理论，规律有什么心得体会或不同意见？ 请看阅读作业。
答：我对代码规范必须是一个人负责比较认可，因为，我们当前的代码因为赶工期，代码没有严格按照之前的风格进行书写，如果代码下一届继续开发，可能会带来阅读上的困难。
标签：是什么 内容 作业 团队 hive 现象 并且 体会 关于
原文地址：https://www.cnblogs.com/RogerPirates/p/13089572.html
