设想和目标
1. 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
本次项目旨在开发一款巡养修检管理子系统，以满足企业在设备巡养修检方面的需求，例如提升用户在报修、维修的效率，改善信息记录分散、不规范，导致设备全生命周期的关键环节难以追溯，维修保养工作效率低下的问题。在项目启动阶段，我们明确了典型用户为工程师和经理。然而，经过项目实践，我们发现虽然对问题有初步定义，但在某些细节上仍存在模糊之处，例如用户需求的多样性超出预期，导致部分功能设计未能精准贴合所有用户需求。
2. 是否有充足的时间来做计划？
在项目初期，团队预留了三天时间进行详细规划。虽然时间看似充裕，但在实际推进中，由于需求调研不够深入，导致计划多次调整，浪费了部分时间。
3. 团队在计划阶段是如何解决同事们对于计划的不同意见的？
面对同事们对计划的不同意见，我们主要通过召开多次头脑风暴会议，让每个人充分表达观点，然后由组长结合项目目标和资源情况，权衡利弊后做出决策。
计划
1. 你原计划的工作是否最后都做完了？如果有没做完的，为什么？
原计划的 10项主要任务中，完成了10项，原计划工作全部完成。
2. 有没有发现你做了一些事后看来没必要或没多大价值的事？
在项目过程中，确实发现了一些事后看来没必要或价值不大的工作。比如在初期对一些小众功能进行了过度设计和开发，结果在用户反馈中这些功能几乎无人问津，浪费了人力和时间资源。
3. 是否每一项任务都有清楚定义和衡量的交付件？
大部分任务都有清楚定义的交付件，例如界面设计任务明确了交付的界面原型图和设计文档，开发任务明确了代码模块和功能测试报告。但在一些边缘任务上，交付件的衡量标准不够清晰，导致验收时出现争议。
4. 是否项目的整个过程都按照计划进行？
项目整体进度未能完全按照计划进行。在开发阶段，由于需求变更频繁，原计划的开发节奏被打乱，部分任务的完成时间比预期延迟了一周以上。不过在后续阶段，通过加班和资源调配，尽量追赶了进度。
5. 在计划中有没有留下缓冲区，缓冲区有作用么？
计划中预留了 10% 的缓冲区，主要用于应对可能出现的技术难题和需求变更。缓冲区在一定程度上缓解了项目进度的压力，缓冲区时间让我们有足够的时间进行技术攻关，避免了项目彻底延误。
6. 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
未来计划中，我们将重新评估缓冲区的定义，根据项目实际风险情况动态调整缓冲区比例。同时，对于加班情况，将严格控制，尽量通过优化流程和提高效率来避免过度加班，确保团队成员的工作生活平衡。
资源
1. 我们有足够的资源来完成各项任务么？
在项目初期，我们评估认为资源基本充足，但随着项目推进，发现部分资源存在不足。例如在开发阶段，由于任务量增加，开发人员的配置略显紧张，导致部分任务进度缓慢。测试阶段，虽然预留了足够的人力，但测试工具的种类和功能不够完善，影响了测试效率。
2. 各项任务所需的时间和其他资源是如何估计的，精度如何？
各项任务所需的时间和其他资源估计精度一般。对于开发任务，时间估计相对准确，但对美工设计和文案等非编程任务的难度估计不足。例如美工设计任务，原本预计3天完成，实际用了5 天，原因是设计过程中需要多次修改以满足用户审美和功能需求。
3. 测试的时间，人力和软件/硬件资源是否足够？对于那些不需要编程的资源（美工设计/文案）是否低估难度？
测试阶段虽然预留了足够的人力，但测试工具的种类和功能不够完善，影响了测试效率。对于美工设计和文案等非编程任务，确实低估了难度，导致实际工作时间超出预期。
4. 你有没有感到你做的事情可以让别人来做（更有效率）？
部分任务确实存在分配不合理的情况，但是通过团队成员的沟通分工已经很好的解决了，每个人负责自己擅长的模块。
变更管理
1. 每个相关的员工都及时知道了变更的消息？
团队成员都能够及时知晓变更消息，但偶尔会出现个别成员因请假或沟通不畅而错过变更通知的情况。
2. 我们采用了什么办法决定“推迟”和“必须实现”的功能？
在决定“推迟”和“必须实现”的功能时，我们主要依据用户需求的优先级、对项目目标的影响程度以及资源消耗情况。例如，对于一些不影响核心功能且实现成本较高的功能，果断推迟到后续版本；而对于用户反馈强烈、能显著提升产品竞争力的功能，则优先实现。
3. 项目的出口条件（Exit Criteria）有清晰的定义么？
项目出口条件有较为清晰的定义，包括功能完整性、性能达标、用户验收通过等。但在实际操作中，由于部分功能的性能指标不够明确，导致验收时出现了一些争议。
4. 对于可能的变更是否能制定应急计划？
对于可能的变更，我们制定了初步的应急计划，例如在需求变更时，重新评估影响的任务优先级和时间安排。但在面对一些突发的、影响较大的变更时，应急计划的灵活性和有效性仍需提升。
5. 员工是否能够有效地处理意料之外的工作请求？
成员在处理意料之外的工作请求时，都表现的不错。
设计/实现
1. 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
设计工作主要集中在项目初期，由团队成员共同负责。
2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
在设计工作中确实遇到了一些模棱两可的情况，例如界面交互的细节设计。团队通过查阅相关设计规范、参考竞品案例以及多次内部讨论，最终解决了这些问题。但这一过程耗时较长，影响了整体进度。
3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML，或者其他工具来帮助设计和实现？这些工具有效么？
团队在开发过程中运用了单元测试、测试驱动开发（TDD）等工具，也尝试使用了 UML 进行设计建模。
4. 什么功能产生的 Bug 最多，为什么？在发布之后发现了什么重要的 Bug？为什么我们在设计/开发的时候没有想到这些情况？
工单提交产生的 Bug 最多，主要是因为该功能涉及复杂的业务逻辑和多个子模块的交互。
5. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
代码复审由团队成员共同负责，基本严格执行了代码规范。
测试/发布
1. 团队是否有一个测试计划？为什么没有？
团队制定了详细的测试计划，包括单元测试、集成测试、系统测试和验收测试等阶段，明确了各阶段的测试目标、测试用例和测试人员。测试计划的制定为项目的质量把控提供了有力保障。
2. 是否进行了正式的验收测试？
进行了正式的验收测试，邀请了部分典型用户参与。通过验收测试，及时发现了软件在实际使用场景中的一些问题，例如界面操作不够友好、部分功能响应速度较慢等，并及时进行了修复。
3. 团队是否有测试工具来帮助测试？
团队没有使用自动化测试工具来辅助测试。
4. 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
团队通过性能测试工具测量并跟踪软件的效能，从实际运行结果来看，测试工作基本达到了预期效果，但也发现了一些问题，例如在高并发场景下，软件的性能瓶颈较为明显。未来需要进一步优化测试策略，增加对高并发等复杂场景的测试覆盖。
5. 在发布的过程中发现了哪些意外问题？
在发布过程中，遇到了一些意外问题，例如服务器配置与开发环境不一致，导致部分功能无法正常运行。经过紧急排查和调整，问题得到了解决，但这一事件也提醒我们在发布前需要更加细致地进行环境测试和配置检查。
总结
1. 你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次？
结合 CMM/CMMI 模型，目前团队处于 CMMI 的已定义级（Level 3）向已管理级（Level 4）过渡的阶段。我们已经建立了一套较为完善的项目管理体系，包括计划、变更管理、质量控制等流程，但在数据驱动的决策、过程优化等方面仍有提升空间。
2. 你觉得团队目前处于萌芽/磨合/规范/创造阶段的哪一个阶段？
从团队发展阶段来看，目前处于规范阶段。团队成员已经熟悉了项目流程和协作方式，能够按照既定规范开展工作，但在面对复杂问题和变更时，仍需进一步提升应对能力和灵活性。
3. 你觉得团队在这个里程碑相比前一个里程碑有什么改进？
相比前一个里程碑，团队在需求管理和变更管理方面有了显著改进。通过引入变更通知确认机制和更加严格的优先级评估流程，减少了因需求变更导致的混乱。同时，测试计划的完善也提高了软件质量，减少了发布后的问题。
4. 你觉得目前最需要改进的一个方面是什么？
目前最需要改进的是资源管理和任务分配的合理性。我们需要更精准地评估各项任务的资源需求，合理分配任务，避免核心成员过度负担低价值任务，同时引入外部资源来处理一些重复性工作，提高整体效率。
浙公网安备 33010602011771号