标签：好的 效率 管理 迭代开发 uml 用户 测试的 锻炼 产品
1. 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
产品定义：我们的软件产品定义为移动药品库存管理，是为了医院量身打造的药品库存管理移动端，方便进行出入库和药品信息查看
典型用户：医院销售人员和采买人员。
典型场景：医院售药处。
2. 是否有充足的时间来做计划?
时间充足。但感觉计划制定不够周详，导致开发过程出现进度和其他各种问题。
3. 团队在计划阶段是如何解决同事们对于计划的不同意见的？
大体是团队成员的共同意见，进行开会讨论得出的结论，最后由pm敲定。
1. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
原计划的工作基本完成，但由于代码和界面的体系问题，进行了重构，第一次迭代没有完成重构的整合，所以最终拿出的是原来的版本进行验收，而不是优化后的重构版。
2. 有没有发现你做了一些事后看来没必要或没多大价值的事?
没有，如果非要说，就是分工上没有采取前后端，而是按功能模块，想让每个组员都能前后端有所学习，但发现效率低下，整合困难。
3. 是否每一项任务都有清楚定义和衡量的交付件?
没有很明确，基本是每个人完成了自己部分后，进行整合的过程中不断地调整。
4. 是否项目的整个过程都按照计划进行?
是的。
5. 在计划中有没有留下缓冲区，缓冲区有作用么?
时间比较赶，没有留下缓冲区，这是比较大的问题，导致最后因为整合问题等，加班比较久，代码规范也没有很好的遵循。
6. 将来的计划会做什么修改？
首先会更加明确分工，明确交件，然后会留有一定的缓冲区，然后会在规范性上做出强调。
1. 我们有足够的资源来完成各项任务么?
有，我们自行租用了云服务器，其他资源比如相关技术书籍虽然没有每个人都有，单主要开发人员都有购买。
2. 各项任务所需的时间和其他资源是如何估计的，精度如何?
一般是按照工作量进行估计，精度不够高，精度只是要界面为止，类的数量就是每个人在开发中根据实际情况进行，导致有一些的分工不均。
3. 用户测试的时间，人力和软件/硬件资源是否足够?
有些不够，因为有成员的电脑软件环境除了问题，导致之后的开发阻滞，使其他成员的工作量有所增加。
至于硬件资源，比如云数据库，空间是够的，毕竟不是很多。
4. 你有没有感到你做的事情可以让别人来做（更有效率）?
有，学长的编码水平和速度要明显快于我并更加合理，但这是对自己的锻炼，能够学到很多东西，所以还是不想让其他人来进行。
1. 每个相关的员工都及时知道了变更的消息?
有任何变更都会即使的在群里通知，所以这方面没问题。
2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?
根据代码的主要功能，最需要实现的核心功能是优先级最高的。
指导老师有给我们说明最主要的，必须实现的功能。
其他的可以增加用户体验的，如果时间尚不够，可以推迟。
3. 项目的出口条件（Exit Criteria）是否得到清晰的定义?
有，关于登陆等出和切换用户等，都有定义和实现。
4. 对于可能的变更是否能制定应急计划?
这个还未制定计划，如果又出现变更，可能会随机应变，现场修改，但是可能手忙脚乱，并会打乱计划，这是之前没有考虑的，夙瑶改进。
5. 员工是否能够有效地处理意料之外的工作请求？
这个基本可以，因为每周的任务并不算特别多，如果有组员时间上有其他安排，可以让其他组员进行帮助。
1. 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
设计工作基本是先进行讨论，pm进行意见征询，然后确认。至于人员是否合适，基本是每个人都得到了锻炼。
2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
这个比较多，一般有的时候组员会再群里提出，然后大家提意见，pm敲定，也有不是很重要的，不会影响整体的有时候是组员自己进行判断。
3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？
在各种项目功能图的绘制上，是运用了UML软件进行的，很方便很有效。
4. 什么功能产生的Bug最多，为什么？
药品信息上，出入库上，因为药品信息被很多其他功能调用，而出入库是主要功能，所以要比较精细。
5. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
为进行代码复审，咋代码规范上也有很多地方没有做到严格按照代码规范，这是第一次迭代的主要问题之一，会进行改进。
1. 团队是否有一个测试计划？为什么没有？
没有测试计划，基本上是代码能够跑起来后进行了一天的测试和debug，主要是运行和数据测试，可能有遗漏的地方，按照验收标准有所重点和偏向。
2. 是否进行了正式的验收测试？
完成了第一次迭代的验收测试。
3. 团队是否有测试工具来帮助测试？
没有。
4. 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
未进行。
5. 在发布的过程中发现了哪些意外问题？
未进行发布。
1. 你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
可重复级。
2. 你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
磨合和规范之间。
3. 你觉得团队在这个里程碑相比前一个里程碑有什么改进?
首先就是磨合的提高，并且对软件开发的总流程有了一个认知，以前虽然只知道那些流程，但在意义上不明就里，操作上不熟悉，第一次迭代的成功和失败之处，尤其是失败之处，让团队对于项目流程中很多为做好的或和麻烦的地方有了认知和警惕。
4. 你觉得目前最需要改进的一个方面是什么?
代码规范。
5. 对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
交流方面基本无障碍，基本是集思广益，大家做决定。面对面交流也比较多，每周一到两次会议。
保持简明，对工作量基本是没有冗余
总结，问题不少，但也有可取之处，基本完成任务，暴露的问题回在第二次迭代中尽量解决。
标签：好的 效率 管理 迭代开发 uml 用户 测试的 锻炼 产品
原文地址：https://www.cnblogs.com/fyq-kylin/p/10094235.html
