软件团队管理与运作试点

软件团队管理与运作试点

软件研发协作流程

1. 使用需求拆分（用户故事）与相对估算方法
2. 建立以小需求（用户故事）流动为主的看板实践，不再跟踪个体活动与任务
3. 使用主干开发模式
4. 开发人员编写自动化单元测试
5. 每个小需求拆分成多个开发任务进行
6. 每个任务完成即向主干提交代码
7. 每个小需求完成后即进行需求功能验收测试

试点团队的选择

• 项目压力适中，有相对富裕的时间
• 团队负责人心态开发，能够承受压力，勇于尝试
• 团队成员有热情
• 业务方面有频繁及快速频繁交付的强烈诉求

通过可视化看板改进工作流程

识别坏味道

• 坏味道可能引起的问题
  • 集成时间太晚。只有本次迭代末期，才能将开发人员的代码集成在一起，开始对这两个需求的测试，集成时间太靠后，质量在过程中不可控
  • 开发任务的质量无法验证。在工作过程中，并无具体完成的工作内容标准，仅仅按工作活动本身的类型进行拆解
  • 测试人员写了测试用例，只能在迭代后期集成时间才能用到

让价值流动起来

• 以价值流动为核心的故事墙
• 在过程中由于外部原因（如外部依赖、外部环境没有准备好等）而暂时无法继续进行的需求，需要特别关注，并推荐解决

显示声明“完成”的标准定义

• 为了让大家能够快速了解系统架构，熟练且正确地使用现成的系统开发框架，从而保证代码质量，减少后期缺陷太多的返工
• 在项目启动会上，达成的两项约定：一是需求启动开发之前，要写模块设计文档，并经过评审，才能开始编写代码；二是编写完代码之后要做代码评审

涂鸦设计，消除浪费

• 用字母来表示需求所处的状态，D代表“设计”（design），C代表“开发”（coding），T代表“测试”（testing），B代表“阻塞”（blocked）。同时每天站会时用代表字母来记录每个需求在该状态的停留时长
• 消除不必要的美化，消除不必要的等待

明确状态，关注需求的快速流动

• 在团队故事墙上增加“代码评审”一栏。当开发人员完成手中的需求开发，需告知代码评审者后，就可以将这个需求移动到该栏中。如果代码评审者两小时内还没有回复的话，开发者需要再次提醒他

避免不必要的任务切换

• 根据每个需求的验收条件，进行开发自测，确保没有明显问题，从而避免不同任务之间的来回切换

没有反馈，就是“风险”

• 面对个别需求无法拆分（强行拆分可能也无法验收，或者验收成本过高）的时候，团队约定一个弱反馈方式，即每个大需求可以拆分成多个开发任务，虽然每个开发任务无法由测试人员进行验收，但是可以通过代码评审来确定其完成
• 这类需求在设计阶段就会被分拆成多个任务，写在小纸条上，附在需求上

限制在制品数量

• 在精益生产体系中，库存分为原材料库存、在制品库存、成品库存3中类型。精益生产管理理论认为，库存不增加价值，而只增加成本
• 在“需求堆积”症状发生在“测试状态”，则需要在每日站会时，由测试人员评估当日是否能完成测试状态下的所有需求测试验收？如果能够完成，则一切工作正常进行；如果无法完成，技术组长会指定当前完成需求开发的开发人员不再领取新的需求，二是和测试人员一起工作，协助其进行需求验收工作，直至测试人员评估可以完成当日的所有需求验收工作

挪动Stroy时必须完成的活动，其状态迁移的条件

• 待开发 → 设计
  • 验收条件（或测试用例）必须完成，并经过产品人员、开发人员和测试人员共同评审，没有异议
• 设计 → 开发
  • 完成设计文档的更新，设计评审完成
• 开发 → 测试
  • 编写对应的自动化单元测试，确保所有单元测试用例成功通过，完成代码评审
• 测试 → 完成
  • 全部测试用例都能通过，所有缺陷被修复

团队中用到的精益理论和质量管理技巧

• 价值流映射（故事墙是“以价值为核心的工作流程”的体现）
• 减少单位工作的批量大小（将大需求拆分成更小的需求）
• 持续改进（不断观察工作流程，并发现问题，改进工作方式）
• 限制在制品的数量（测试人员每日评估产能）
• 质量内建（每个环节都定义了该环节的完成标准，避免不必要的任务切换）