我们在不断探寻更好的软件开发方法，希望能找到适合自己和团队的好办法。不过，基于既有的教条，关于各种开发方法孰优孰劣的讨论最终总会演变成激烈的争吵。字典中教条的定义是“一种权威性观点，但并没有充分的依据”。我们经常会看到，各种方法的拥护者们都坚持认为自己的方法才是开发软件唯一正确的方法。
我们不断听到一些从业人员这么讲，他们执着地采用某种方式开发软件，即使这种方法明显危害到团队的其他人甚至整个组织，却仍然固执己见。事实上，开发软件根本没有所谓“绝对正确的方法”。倒是有很多错误的方法，不过没有哪一种方法、观点、哲学或工具能“以不变应万变”，在所有时间、所有场合对所有项目和所有人都适用。软件是人创建的，不会有两个人完全一样。
在人生中，我们应该选择优秀的一些习惯，我们要刻意去培养它，使得其成为自己的习惯。让自己习惯性优秀，那么就会获得成功。“我们每一天怎样度过，一生就会怎样度过”
习惯性优秀，如果我们坚持不懈，那么优秀就不再是一种行为，而成为一个习惯。
采石工人信条：
尽管我们只是采石头，但脑海中必须想象着最终建造出的宏伟教堂。
一流的产品只不过是好习惯的副产品
1. 在沙箱中开发，只需记住一个基本原则，在你准备好之前，要与其他人隔离，使他们不会受到你的工作的影响。把这个原则描述为“隔离原代码”。
2. 管理资产，需要一个源代码管理（SCM）系统，也称为版本控制（VC）系统，跟踪存储库（或数据库）中的所有资产， 并协调对这些文件的安全访问。
3. 建立构建脚本，构建会把源代码转换为一个可运行的程序，根据需要打包图像和其它资源。自动完成构建过程 不仅可以更准确地完成各个步骤（更不容易出错），还能让我们按时收工。
4. 跟踪问题，一个好的问题跟踪系统会为给定的产品生成活动报告，遇到多少个问题，多少个问题得到解决， 花费了多长时间等，从而用来找出项目中的问题地带。
5. 跟踪特性，跟踪特性的方法与跟踪问题列表相同，需要维护一个统一的特性请求列表，为特性指定优先级， 并对研究或增加这个特性可能需要的时间做一个基本估算，并在白板上保留最高优先级的特性列表，
让大家一目了然。如果一个任务不在指定优先级的列表中，就不要做任何处理。
6. 使用自动化测试框架来创建和运行自动化测试，也可以手工编写独立的测试。
包括单元测试、功能测试、性能测试、负载测试、烟雾测试、集成测试、模拟客户测试。
单元测试：验证一个代码单元中逻辑操作的正确性
功能测试：测试整个产品的操作或功能是否正确
性能测试：运行速度
负载测试：在很大负载情况下的表现
烟雾测试：冒烟测试
7. 选择工具，工欲善其事、必先利其器，使用的每一个工具都应当最胜任相关工作，
要在每个领域中寻求“最出类拔萃”的工具。
任务清单
使用任务清单相当容易，不过，任务清单要真正做到有效，必须遵循一些原则。包括以下所有特点：
1. 可以公开获得
团队的任务清单必须可以公开获取，一个秘密的任务清单对协作没有任何帮助。要把任务清单放在你的白板上或者放在网站上为它建立一个RSS提要，不然至少要让人们很容易很明了的读到。把任务清单一直放在面前，有助于保证工作重点。
2. 已指定优先级
任务清单必须已经指定优先级，要区分产品中不同类型的特性 --- 必要特性、可取特性和无用特性。在对任务清单指定优先级时必须有所区别，否则不分轻重缓急最后只会浪费时间。通常会有一组核心任务必须在产品交付前完成，这些就是优先级最高的特性。绝对不要忽视你设置的优先级，在处理较低优先级任务之前，一定要先完成所有高优先级的任务，除非确实有充分的理由暂缓某个任务。
3. 有时间表
任务清单总有一个关联的时间表，这个时间表并非一成不变。但应该包括估计时间，指出任务清单中的各项任务大致需要多长时间完成。然后，当你完成一个任务时，要记录实际所花的时间，并注意二者之差。
4. 活跃
任务清单必须是活的，不能一成不变。你的团队必须能够适应变化。技术领导人会随着项目进展调整特性的优先级；一些新的特性会出现，而有些特性会退出。任务清单有变化通常意味着客户或干系人在关注这个项目，而且确实提出了想法和有价值的反馈。
5. 可测量
为了保证有效，任务清单上的每一项必须是可测量的。毕竟，如果你想从任务清单中去除某项任务，就必须能确定这项任务已经完成。基于这个原则，要避免一些模糊不清的任务，如“提高性能”，而倾向于一些具体的任务，如”保证登录在5秒内完成“或者”在10秒内生成报告X“。通过创建一个只有“是”和“否”两种状态的目标，你就能明确这个目标是否已完成。如果你的任务清单上有一些任务是不可测量的，那么要花些时间查看真正的需求是什么。把这个任务分解为明确的只有两种状态的任务，然后让原先提出要求的人检查这些任务。如果一项任务无法转换为可测量的目标，就把它设置为优先级最低，先处理更高优先级的任务。
6. 有针对性
有两类任务清单：团队任务清单和个人任务清单，都非常重要，必须针对适当的对象。团队任务清单包含整个项目的所有重要工作，个人任务清单包含的任务较少，一旦完成，就要从团队的任务清单中复制一项任务，把它加到个人任务清单中
集体参与架构设计：
1.一个会议主持人，任何人说话之前必须经他“许可”
2.整个会议中应在白板上记录要点
3.可以用LEGO或积木表示系统中的对象
4.记录接口并发布。
5.保证会议不被中断。要尽量减少转移话题和回答问题的次数。
增加总线数：
总线数是指当损失的开发人员达到这个数，则极有可能导致项目失败。如果你的团队有一个“超级明星”，项目大部分信息都在他手里，那么你的团队总线数就是1。
曳光弹开发流程：
提出系统目标->提出接口->连接接口->增加功能->重构、求精、重复->提出系统目标（新目标）->...如此重复
工作流程：
1.定义系统对象。
2.定义系统对象间的接口。
3.编写接口桩stub。
简言之:
address fundamental problems as soon as possible
give the client a useful result as soon as possible
构建 自动化构建 模拟用户功能测试 单元测试
测试之前不要修改遗留代码
尽早而且经常发布真实演示系统。
另类开发人员：与团队步调不一致，经常造成破坏但坚信自己是正确的。
使用每日站会修正另类开发人员的航向
保证另类开发人员只能完成任务清单上的任务
使用代码审查和自动代码变更通知来追踪另类开发人员的工作
使用CI来作为最后一道防线监视另类开发人员的工作
制定团队任务清单和个人任务清单，定期（例如每2周）让经理审查
让经理（例如每周）掌握团队和你的最新进展（例如邮件）
如果遇到每天检查你好几遍的老板，则给他看任务清单，让他能够在特定的时间得到定期的状态更新。
每个团队成员需要十分钟或者更多时间。
某个团队成员总是占用太多时间，几乎是其他成员时间的总和。
人们以一种不友善的方式相互责问。
会议总是很晚才开始（或结束）
会议变得空洞无物，开发人员仅仅只是宣称“我完成了90%”，或者“我在做关于***的工作”
团队成员在漫无目的地聊天，忘记要报告他们做了些什么，你要私下里要求这些团队成员把他们的工作写下来，这样在开会时他们就能保证目标集中，报告简洁，他们还可以建立自己的任务清单从而更有条理。
确保团队的工作优先级与客户的需求一致；
确保将团队的工作适当地展示给管理层；
将团队与不懂技术的管理层隔离；
为不懂技术的干系人解释技术问题；
让开发团队了解非技术问题。
为团队成员设定方向；
管理项目的特性列表；
为项目的特性确定优先级；
隔离你的团队，使他们不受外部干扰。
你知道团队的每一个成员都在做什么吗？
你能不能在5分钟内生成一个关于项目状态的总结？
产品接下来要事先的5到10个特性是什么？
你能不能很容易地列出产品中优先级最高的缺陷？
你为团队成员解决的最近的问题时什么？
如果一个团队成员需要解决一个重要问题，他会来向你求助吗？
警告信号：
缺乏对每一个团队成员工作方向的全局认识。
他一来，工作就要停下来。
团队工作出色，但只要他得到好评。
不能解决问题，或者更糟糕地，反而会带来问题。
不能准确地预测工作时间表。
不清楚团队成员的技术能力，也不知道团队成员希望了解什么。
对团队中的冲突视而不见。
联系客服
