工作中的思考

1. 好的开发特征是什么

• 目标明确：清晰的目标是开发成功的基础。

• 标准清晰：明确的验收标准和规范，确保开发质量。

• 沟通高效：纵向和横向的高效沟通，确保团队协作顺畅。

• 紧盯目标：始终围绕目标开展工作，避免偏离方向。

• 关注价值：聚焦用户和业务价值，确保开发成果有意义。

• 质量内生：通过流程和工具确保代码质量，而非依赖后期修复。

2. 什么是成功的软件

成功的软件应具备以下特征：

1. 销售愿意卖：销售人员能用简洁的语言（如电梯三分钟演讲）打动客户或投资者。

2. 用户愿意用：解决用户实际问题，提供良好的用户体验。

3. 解决实际问题：软件应切实解决用户痛点，而非仅仅满足功能需求。

4. 具备扩展性：能够向纵向和横向发展，形成生态。

销售愿意卖的思考

• 销售人员是否能用简洁的语言描述软件的核心价值？

• 是否与销售人员充分沟通，确保他们理解并认可软件的价值？

• 软件是否能激发团队的热情，调动大家的积极性？

• 软件是否符合公司战略规划，能否获得高层支持？

3. 目标与愿景

开发人员需要清晰的愿景和目标，以激发成就感和动力。业务相关人员应明确目标，若业务人员未能清晰定义，开发人员应主动参与目标制定。

4. 目标的粗浅理解

目标是团队与客户之间达成的共识，基于现有能力和时间，为客户和用户提供最大价值。目标可分为基本目标、扩展目标等，以应对不同情况下的需求变化。

5. 目标的思考

从目标角度出发，可以发现许多非开发但重要的问题。例如，新产品推介的环境搭建、内容准备等任务，虽不涉及开发，但对成功至关重要。

6. 价值的思考

价值的量化

• 每年可节省的成本或人力。

• 提升安全性或降低风险。

• 形成竞争门槛或提升产品形象。

• 支撑公司战略，带来长期价值。

《软件需求》中对价值的描述

• 提高生产力，减少返工和浪费。

• 简化业务流程，实现自动化。

• 符合法规标准，提升易用性。

7. 明确的需求与积极性

问题

开发人员积极性不足，往往源于目标不明确或验收标准不清晰。

解决方式

• 采用“事后文档”方式，通过文档澄清目标与验收条件。

• 尽早展示理解，发现偏差并及时调整。

开发与业务的协作

• 开发人员应与业务人员紧密合作，共同理解需求。

• 需求文档应简洁明了，避免过度细节化。

8. 需求的再理解

需求应紧盯用户和价值。忽略价值会导致开发偏离方向。例如，为展会开发高拍仪时，若忽略展会PPT准备和讲解人员培训，可能导致展示效果不佳。

9. 开发者与业务人员的沟通

开发人员应与需求提出者进行面对面沟通，澄清需求背景、当前处理方式及期望效果。沟通后整理成文字，确保双方理解一致。

10. 开发者对业务人员的期望

版本1

1. 产品愿景：明确产品的长期目标，激励团队。

2. 当前版本目标：清晰定义当前版本的目标及其支撑的业务树。

3. 功能价值：明确用户角色及其特点，描述功能为用户提供的价值。

4. 推荐解决方案：提供推荐的解决方案，但不一定是最终选择。

5. 应用场景：描述生动的应用场景，帮助开发者理解需求。

6. 验收条件：明确功能的验收条件，便于测试和开发。

7. 依赖与限制：列出功能的依赖、假设和限制。

8. 开放性问题：收集并记录未明确的问题，便于后续沟通。

9. 优先级：明确功能的优先级及其依据。

10. 联系人列表：提供业务提出者、用户代表等联系人信息。

版本2

• 目标明确：确保目标为用户解决问题，符合公司战略。

• 需求支撑：目标由一系列需求支撑，形成业务特征树。

• 用户故事：描述用户特点、价值及推荐解决方案。

• 验收条件：明确功能的验收条件，便于测试和开发。

11. 开发节奏的把握

开发节奏应基于价值判断进行调整，确保在时间有限的情况下最大化输出价值。

12. 多个业务系统的处理

在多个业务系统并行开发时，应整合相关人员，确保目标一致，避免协调困难。

13. 测试驱动开发与角色兼职

• 测试驱动开发：通过测试用例明确验收条件，提升开发质量。

• 开发人员兼测试角色：开发人员参与测试，提升测试效率和产品质量。

• 测试前探：测试人员提前介入需求阶段，确保目标与价值一致。

14. 关于架构设计

• 架构演化：架构应逐步演化，避免过度设计。

• 设计在敏捷中的位置：设计应平衡简洁与灵活性，避免过度复杂或混乱。

• 谁主导设计：接口设计应由相关责任人主导，确保理解一致。

15. 单元测试

• 单元测试的作用：单元测试是开发的辅助工具，帮助提前发现设计问题。

• 测试与需求结合：用户故事和满意条件类似于单元测试的测试用例，帮助开发人员理解需求。

16. 关于时间

• 时间压缩的思考：在时间压缩时，应调整目标，确保输出最大价值。

• 沟通与信任：时间压缩应基于信任和合理规划，而非拍脑袋决定。

17. 关于提问题

• 提出问题的障碍：团队中若提出想法的人需负责实现，可能导致无人愿意提出新想法。

• 解决方式：将提出想法与实现分开，鼓励创新。

18. 关于沟通

• 基层开发的默认假设：基层开发人员可能因得不到上级支持而降低目标。

• 解决方式：建立信任机制，鼓励开发人员向上反馈问题。

19. 关于沟通的思考

• 沟通效率提升：聚焦解决问题，避免争论对错。

• 跳出代码讨论：从业务角度讨论问题，提升沟通效率。

20. 关于沟通——真的理解一致了吗

• 应用场景与演示：通过应用场景和尽早演示，确保团队理解一致。

• 验收基础：验收时，应用场景、目标和验收条件应作为基础，确保共识。

21. 团队需要的角色

• 产品经理：确保价值，管理需求迭代。

• 测试人员：保证高质量输出。

• 交互设计师：提升界面设计，增强沟通效率。

22. 演示的作用

• 代价小，收益大：演示能快速发现问题，提升团队信心。

• 促进沟通：演示帮助团队理解整体进展，增强协作。

如何判断项目的敏捷情况

1. 故事墙：从故事墙中看出目标和进度。

2. 演示能力：能够按故事墙进行演示。

3. 目标与特征树：Product Owner能清晰描述史诗目标和特征树。

4. 用户故事理解：团队成员能描述用户故事的特点、价值和满意条件。

5. 依赖与限制：明确用户故事的依赖、假设和限制。

6. 开放性问题：从故事墙或文档中获取未明确的问题。

7. 任务拆分与测试用例：开发人员能清晰描述任务拆分和测试用例。

总结

本文系统探讨了软件开发中的目标、需求、沟通、测试和团队协作等关键问题。通过明确目标、优化沟通、提升测试效率，团队可以更好地交付高质量的产品。希望这些思考能为开发团队提供参考，助力高效协作与持续改进。