态度决定一切
专业的态度应该着眼于项目和团队的积极结果，关注个人和团队的成长，围绕最后的成功开展工作。
- 做事
- 出了问题，最高优先级是解决问题而不是指责，问问能为解决问题做些什么。
- 不要甩锅，勇于承认自己不知道答案，一次重大的错误是一次难得的学习机会。
- 欲速则不达
- 不加理解的坠入快速简单的修复中，会导致代码的清晰度不断降低，陷入泥潭。
- 花些时间阅读其他同事写的代码，会使得代码的修改更加谨慎，更能确保代码的可读和可理解性。
- 写单元测试可以帮助进行代码分层和拆成更小的块，进行更好的设计和获得清晰的代码。
- 对事不对人
- 避免方案设计的讨论变成情绪化的指责，不要以否定个人能力的方式进行反驳。
- 引导性的提出一个疑问，让他们自己意识到问题。
- 有时，面对外部询问时，不将错误人指出的描述事态方式有利于团队聚焦问题。
- 负面的评论和态度会扼杀创新，团队中每个人都需要自由的表达观点。
- 会议技巧：避免感情用事的技巧
- 设定最终期限：避免无限期的争辩
- 逆向思维：先正面看待再反面看待
- 设立中立仲裁人：维护会议持续有效进行
- 支持已经做出的决定：一旦方案确定要大家都认可这个充满妥协的决策以尽快满足客户需求
- 排除万难，奋勇前进：勇于站出来点明并修改掉糟糕的现状，不要配合已有的不好的默契。
学无止境
软件开放行业是一个不停发展和永远变化的领域，你必须一直跟上步伐稳步前进，否则就会摔倒出局。
- 跟踪变化：保持对持续出现的技术的关注和了解会使得你在使用需要的技术时不用面临从 0 开始的窘迫，并提升对以后要流行的技术的嗅觉。
- 对团队投资：和其他团队成员分享所学的知识，进行一些讨论，既可以提升自己的熟练度，也可以提升团队的水平还可以降低团队内的相关技术的沟通成本。
- 懂得丢弃：丢掉那些过时的态度和方法，拥抱环境的变化，但其难点在于意识到在使用过时的方法。
- 打破砂锅问到底：在理解一个问题的时候，要依次的问 5 个以上的为什么，才能接近问题的根源。
- 把握开发节奏：一个合理安排且稳定一致的开发节奏，会更容易达成目标暴露问题。
交付用户想要的软件
通常情况是，客户看到软件后认为很多地方不需要修改，且想要的功能不在原始的文档中。 我们真正的敌人是变化，不是客户、用户、队友或管理者。敏捷取决于你识别和适应变化的能力。
- 让客户做决定：业务方面的事情让客户做决定，技术上的事情开发决定，越早越好，避免重新设计和风险。用客户懂的业务角度介绍方案的优缺点、成本利益和如何权衡，让用户选择并接受。
- 让设计指导而不是操纵开发：
- 先花时间思考各种不同选择的权限和益处以及如何权衡，再花时间去编码。
- 设计是基于你目前对需求的理解做出的，但设计和代码实现会不停的发展和变化。
- 设计分为战略和战术两层：
- 战略：图的角色，在没有深入理解需求时的设计。不应该陷入设计任务。
- 战术：在项目开发时开始，描述当前进行的编码工作的职责，如何工作和实现。
- 计划是没有价值的，计划的过程是必不可少的。
- 合理的使用技术：
- 新技术的使用：
- 你要解决的问题到底是什么？
- 这个技术真的能解决这个问题么？
- 你将会被它栓住么？
- 维护成本是多少？
- 重复开发：不要开发你能下载到的东西
- 新技术的使用：
- 保持可以发布：确保提交的代码不会导致系统不能正常发布（基于分支管理不是啥问题）。
- 提早集成，频繁集成：集成是一个主要的风险，越早集成发现的问题越容易解决。mock是在独立开发阶段避免集成问题的一个手段。
- 提早实现自动化部署：使用可重复的流程提前解决和避免部署时可能遇到的问题。
- 使用演示获得频繁反馈：避免客户需求变化导致的交付偏离。
- 使用短迭代，增量发布：
- 软件开发不是有着精细标准的制造业，而是创新活动，长周期的迭代会使得结果不可控。
- 尽早的投入使用可以或得反馈和经验，以对系统进行优化。
- 大部分用户都是希望现在就有一个够用的软件而不是一年以后得到一个超级好的软件。
- 短迭代使得目标实际且切实，严格的最终期限逼迫你及时作出艰难的决策，不堆积到最后。
- 固定的价格就意味着背叛承诺：敏捷开发下给出一个与完整交付的承诺是有冲突的，但是有一些报价方式可以缓解。
敏捷反馈
除了从用户处得到反馈，我们还能如何从其他起到获得反馈？
- 守护天使：单元测试 + CI，保证你不会意外的破坏功能。
- 先用它再实现它：测试先行，以站在用户的角度思考，基于测试定义出的功能可以避免不必要的为了实现而实现的功能。
- 不同环境，就有不同问题：在各种支持的平台和环境中运行你的测试，发现环境引起的问题。
- 自动验收测试：集成测试，可以作为功能验收的测试。
- 度量真实的进度：使用任务列表评估真实的进度，使用评估工时和实际工时调整以后的任务预估时间。
- 倾听用户的声音：
- 黑屏和意义不明的退出按钮是很不友好的行为。
- 对于用户的抱怨，要找出背后的真正原因。
- 如果从代码上解决不了问题，可以通过修改文档和培训来弥补。
敏捷编码
保证开发出的代码无论是在项目进行中还是在项目完成后，都易于理解、扩展和维护，避免在不知不觉中演变成一个怪物。
- 代码要清晰的表达意图：《代码整洁之道》
- 用代码沟通：《代码整洁之道》
- 动态评估取舍：权衡之道，别什么都想要，同时要听客户的意见。
- 增量式编程：经常评估代码质量，不时的进行小的调整，使代码得到及时的反馈。《重构》
- 保持简单：不要过分设计，保持简单。
- 编写内聚的代码：《代码整洁之道》、《架构整洁之道》、《设计模式》。
- 告知，不要询问：避免副作用，不要直接修改被调用对象。《设计模式》。
- 根据契约进行替换：合理利用设计模式，保持代码层面同一类型的模块的完全可替换性，不要滥用继承创造不一样的行为。
敏捷调试
调试时面对的真正问题是，无法用固定的时间来限制；对项目来说，没有准确把握的时间消耗是不可接受的。
- 记录问题解决日志：面对自己和后来者的一份经验 QA。
- 警告就是错误：在确认警告真的可以忽略前不要忽略警告。
- 对问题各个击破：注于当前模块，隔离其他模块的干扰；或者简化问题，使用原型验证。二分法定位问题。
- 报告所有异常：不要吞掉报错，并且错误处理的职责划分也是设计的一部分。
- 提供有用的错误信息：错误信息应该给定位问题提供帮助。
敏捷协作
高效的协作是敏捷开发的基石。
- 定期安排会面时间：立会，快速发言，让每个人快速了解当下的进展。
- 架构师必须写代码：战略的决策可以再后方进行，战术决策需要对战场状况明确了解。
- 实行代码集体所有制：让所有人轮换接触所有代码。
- 一：人员可替代，便于安排任务。
- 二：可以通过代码交流思路或发现隐患。
- 成为指导者：带领团队一起进步，分享知识，激励他人。
- 允许大家自己想办法：不要剥夺他人承担责任的机会、发挥的机会、实践的机会和犯错的机会。
- 准备好后再共享代码：往前翻，保持代码可发布，不要干扰别人。
- 做代码复查：Code Review + 团队 Code Review，同样是通过代码交流，在代码生效前降低风险、提升质量。
- 及时通报进展与问题：记得，你阻塞了会影响大家。
走向敏捷
一个好的习惯的改进可能就可以拯救你的项目，但是不要一次性改变所有习惯，这也会带来失控。