（1566期）Task Development Workflow – TDD驱动的结构化开发工作流

TDD驱动的结构化开发工作流 TDD优先的软件开发工作流，通过需求澄清、规划审批、任务追踪、测试驱动开发和PR代码审查确保代码质量 使用说明 核心用法 本技能定义了一套结构化的软件开发工作流，适用于需要高质量交付的团队协作项目。工作流程分为七个阶段： 需求澄清阶段：在编码前必须充分理解业务需求、UI/UX流程、架构决策和技术约束，明确模糊点后才能继续 规划审批阶段：将任务拆分为小而专注的子任务，提交详细计划并等待明确批准，未经批准不得开始实现 任务追踪设置：使用Trello看板管理任务状态（Backlog → To Do → In Progress → Review → Done） TDD实现阶段：严格执行测试驱动开发——先写测试（应失败）、再实现功能、再验证测试通过；每个任务完成后提交代码 分支与PR策略：禁止直接推送main分支，必须为每个任务创建特性分支，PR描述中需包含Trello任务链接 PR反馈循环：收到代码审查意见后，将任务移回In Progress，修复问题后通知审查者重新审查，循环直至批准 合并门禁：当前PR合并后才能选取下一个任务 显著优点 质量保障：TDD在开发早期捕获缺陷，减少后期返工成本 流程透明：看板可视化任务流转，状态清晰可追溯 风险控制：规划审批和合并门禁防止方向性错误和代码污染 协作规范：强制通知审查者、关联Trello与PR，减少沟通摩擦 小步快跑：任务粒度小，代码审查负担轻，合并冲突少 潜在缺点与局限性 启动成本：前期需求澄清和规划审批可能延缓项目启动，不适合探索性原型开发 流程刚性：测试跳过需显式批准，紧急修复场景可能受限 工具依赖：深度绑定Trello，使用其他项目管理工具时需要适配 审查瓶颈：PR反馈循环可能成为阻塞点，审查者响应不及时时影响吞吐 单线程限制：必须等PR合并才能开始下一任务，无法并行处理多个任务 适合人群 追求代码质量的中小型开发团队 需要严格质量门禁的协作项目（如开源贡献、外包交付） 采用TDD实践的敏捷团队 远程协作团队，需要异步透明的工作流 常规风险 流程形式化：团队可能机械执行流程而忽视实际价值，沦为"为了流程而流程" 审查疲劳：频繁的PR往返可能导致审查者倦怠，降低审查质量 上下文切换：任务在In Progress和Review间反复移动，开发者需频繁切换注意力 工具同步失效：Trello状态与Git状态可能不一致，需额外维护成本 原始说明 TDD-first development workflow with structured planning, task tracking, and PR-based code review. Use when building software projects that require clarificat...