【产品经理】敏捷开发

敏捷开发修炼之道

• 态度决定一切
• 学无止境
• 交付用户想要的团建
• 敏捷反馈
• 敏捷编码
• 敏捷调试
• 敏捷协作

态度决定一切

• 最高优先级是解决问题而不是抱怨出了问题。
• 欲速则不达
  • 拙劣的代码工人会不假思索的改完代码然后快速转向下一个问题，优秀的程序员会挖掘更深一层，理解这里为什么要这么做，更重要的是会向想明白会产生什么其他影响。
  • 要理解开发过程，你必须理解团队采用的开发方法，理解如何恰如其分的使用这种方法，为什么它是这样的，以及如何成为它这样的。
  • 使用单元测试：使代码分层。
• 对待明显错误的反应：询问你的队友并提出你的顾虑。
• 特殊技术
  • 讨论前设定一个最终期限：防止进入无休止的争辩
  • 逆向思维：权衡的重要性。客观对待问题的办法：先积极看到它的正面，然后努力的从反面认识它。
  • 设立仲裁人做决策者：防止明星员工操纵会议，及时打断假大空发言
  • 支持已经做出的决定：客户目标是让项目满足用户需求并不关心这是谁的主意，结果最重要。
  • 对事不对人：我们骄傲的应该是解决了问题而不是比较谁的主意更好。
  • 寻找最好的解决方案前大家应该对“最好”的含义达成共识。开发者眼中的最好，不一定就是用户认为最好的。
• 做正确的事：要诚实，有勇气说出实情，即使这很困难。

学无止境

• 跟踪变化
  • 迭代和增量式的学习：每天一段时间学新技术。记下你想学的东西——当你听到一些不熟悉的术语或者短语，简要的记录下来，在计划的时间中深入研究。
  • 了解最新行情：社区讨论，邮件列表，优秀技术博客
  • 参加研讨会议
  • 如饥似渴的阅读：软件开发和非技术主题的好书，专业期刊和商业杂志
• 对团队投资
  • 一个学习型的团队才是较好的团队
  • “午餐会议”是团队中分享知识很好的方式
  • 每周要求团队中的一个人主持讲座。向大家介绍一些概念，演示工具，或者做团队感兴趣的人讷河一件事情。可以挑一本书和大家说说其中特别内容、项目或者实践。
  • 讲座后进行开放式讨论
  • 不要局限于纯技术的图书和主题，相关的非技术主题（项目估算，沟通技巧等）也会对团队有帮助
• 学习新的东西，更少被旧习惯所牵绊。
• “为什么”是一个非常好的问题，而且要问到点子上。
• 把握开发节奏。编译，运行测试，代码复审，一致的迭代，然后发布。

交付用户想要的软件

• 让客户做决定
  • 让企业主决定业务上的关键问题
  • 和客户讨论问题的时候，准备好集中可选择的方案。不是从技术的角度而是从业务的角度，介绍每种方案的优缺点，潜在成本和利益，讨论每个选择对时间和预算的影响，以及如何权衡。
• 让设计指导而不是操纵开发
  • 前期的设计属于战略，通常只有在没有深入了解需求的时候需要这样的设计。具体来说，它只应该描述总体战略，不应该深入具体细节。
  • 战略级别的设计不应该具体说明程序方法、参数、字段和对象交互精确顺序的字节，这应该留到战术设计阶段。战术设计的重点是集中在单个的方法或数据类型上。CRC（类-职责-协作）卡片。
• 合理使用技术
  • 这个技术框架真的可以解决问题吗？如果有需要先做一个原型
  • 你将被它拴住吗？缺乏可取消性
  • 维护成本是多少
  • 根据需要选择技术
• 保证你的系统随时可以编译、运行、测试并立即部署
• 提早集成，频繁集成：早起集成会看到子系统之间的交互影响，可以估算之间的通信和共享的信息数据。
• 提早实现自动化部署：从第一天起就进行交付，项目没有开始就有了单元测试、持续集成和基于窗口的安装程序。
• 使用演示获得频繁反馈
• 使用短迭代，增量发布。
  • 迭代开发：在小且重复的时间周期里完成各种开发任务：分析、设计、实现、测试和获得反馈。
  • 大部分用户希望现在就有一个可以用的软件，而不是一年后得到一个超级好的软件。确定产品可用的核心功能，把它发那个到生产环境中，越早交到用户手里越好。
  • 询问用户，哪些是使产品可用且不可缺少的核心功能。不要为华丽功能而分心，不要沉迷想象做华而不实的用户界面。
• 固定的价格意味背叛承诺
  • 主动提议先构建系统最初的、小的和有用的部分。这是要足够一次交付并让用户真正使用。
  • 第一次迭代结束时用户有两个选择：选择一系列新的功能，继续进入下一个迭代；或者取消合同，仅需支付第一个迭代的几周费用。
  • 如果用户继续前进，这个时候应该很好地预测下一个迭代工作，在下一个迭代工作结束的时候，用户仍然有同样的选择机会。

敏捷反馈

• 单元测试
  • 确保测试是可重复的。
  • 测试你的边界条件。
  • 不要放过任何一个失败的调试。
• 编程之前，先写测试：
  • 使用测试驱动开发（TDD）技术。
  • 只有在具体理由的时候才开始编码，你可以专注于设计接口，而不会被很多实现的细节所干扰。
• 持续集成：使用自动化会节省时间
• 集成测试框架（FIT）：更容易使用HTML表格定义测试用例，并比较测试结果数据。
• 清楚项目真实进度
  • 不应该去计算工作量完成的百分比，而应该测定还剩下多少工作量没有完成。
  • 使用待办事项
• 倾听用户的声音
  • 每个抱怨的背后都隐藏了一个事实。找出真相修复真正的问题。

敏捷编码

• 代码要清晰地表达意图。可读性
• 使用细心、有意义的命名，用注释描述代码意图和约束
• 动态评估权衡：考虑性能、便利性、生产力、成本和上市时间。
• 增量式编程：在很短的编辑/构建/测试循环中编写代码。
• 保持简单：不要使用模式、原则和高难度技术之类的东西。
• 编写内聚的代码：让类的功能尽量集中，让组件尽量小。
• 命令与查询相分离模式。
• 根据契约进行替换：通过替换遵循借口契约的类，来添加并改进功能特性。多用委托而不是继承。

敏捷调试

• 维护一个问题及其解决方案的日志
• 将警告视为错误
• 对问题彼此隔离各个击破（以二分查找的方式来定位问题是很有用的）
• 处理或是向上传播所有的异常。
• 提供有用的错误信息（没有必要等待抛出异常来发现问题。在代码关键点使用断言来保证一切正常，断言失败时，要提供与异常同样详细的信息。

敏捷协作

• 使用立会
• 架构师必须写代码：新系统的设计者必须要亲自投入到实现中去。
• 强调代码的集体所有制：让开发人员轮换完成系统不同领域中不同模块的不同任务。
• 成为指导者：不要吝啬分享自己的知识。
• 给别人解决问题的机会。
• 准备好后再共享代码
• 做代码复查（能否读懂、理解？错误？重复？重构？）
• 及时通报进展与问题