1 做事
“出了问题，第一重要的是确定元凶，找到那个人！一旦证实了是他的错误，就可以保证这样的问题永远也不会再发生了。”
指责不会修复bug，把矛头对准问题的解决办法，而不是人。这是真正有用处的正面效应。
也许你不相信，但确实有些人常常不把解决问题放在最高优先级上。也许你也没有。先自我反省一下，当有问题出现时，“第一”反应究竟是什么/span>
一个重大的错误应该被当作是一次学习而不是指责他人的机会。
团队成员们在一起工作，应互相帮助，而不是互相指责。
如果你没有犯过任何错误，就说明你可能没有努力去工作。
2 欲诉则不达
“你不需要真正地理解那块代码，它只要能够工作就可以了。哦，它需要一个小小的调整。只要在结果中再加上几行代码，它就可以工作了。干吧！就把那几行代码加进去，它应该可以工作。”
拙劣的代码工人会这样不假思索地改完代码，然后快速转向下一个问题；而优秀的程序员会挖掘更深一层，尽力去理解为什么这里需要加1，更重要的是，他会想明白会产生什么其他影响。
千里之堤，溃于蚁穴，大灾难是逐步演化而来的。一次又一次的快速修复，每一次都不探究问题的根源，久而久之就形成了一个危险的沼泽地，最终会吞噬整个项目的生命。
3 对事不对人
“当L先生在做一个新方案介绍时，下面有人会说‘这样设计很蠢！都没有考虑线程安全！’（这也暗示着L先生很蠢）。”
事实上，最适合并且最有效的表达方式应该是“谢谢，L先生。但是我想知道，如果两个用户同时登录会发生什么情况
尽力贡献自己的好想法，如果你的想法没有被采纳也无需生气；不要因为只是想体现自己的想法而对拟定的好思路画蛇添足。
4 排除万难，奋勇前进
“老鼠们打算在猫的脖子上系一个铃铛，这样猫巡逻靠近时，就能预先得到警 。每只老鼠都点头，认为这是一个绝妙的想法。这时一个年老的老鼠站出来说道’那么，谁愿意挺身而出去系铃铛呢毫无疑问，没有一只老鼠站出来。当然，这个绝妙的计划也就这样泡汤了。”
有时，绝妙的计划会因为勇气不足而最终失败。尽管前方很危险，但你必须有勇气向前冲锋，做你认为对的事情。
当你勇敢地站出来时，如果受到了缺乏背景知识的抉择者的抵制，你需要用他们能够听懂的话语表达。“更清晰的代码”是无法打动生意人的。节约资金、获得更好的投资回 ，避免诉讼以及增加用户利益，会让论点更有说服力。
5 跟踪变化
“软件技术的变化如此之快，势不可挡，这是它的本性。继续用你熟悉的语言做你的老本行吧，你不可能跟上技术变化的脚步。”
如果只是掌握了工作中需要的技术并不够。那样的工作也许几年之后就不再有了—它会被外包或者会过时，那么你就将会出局。
迭代和增量式的学习；了解最新行情；参加本地的用户组活动；参加研讨会议；如饥似渴地阅读。
6 对团队投资
“不要和别人分享你的知识—自己留着。你是因为这些知识才成为团队中的佼佼者，只要自己聪明就可以了，不用管其他失败者。”
团队中的开发者们各有不同的能力、经验和技术。每个人都各有所长。不同才能和背景的人混在一起，是一个非常理想的学习环境。
一个学习型的团队才是较好的团队。
每周，要求团队中的一个人主持讲座。他会给大家介绍一些概念，演示工具，或者做团队感兴趣的任何一件事。你可以挑一本书，给大家说说其中一些特别内容、项目或者实践，无论什么主题都可以。
7 懂得丢弃
“那就是你一贯的工作方法，并且是有原因的。这个方法也很好地为你所用。开始你就掌握了这个方法，很明显它是最好的方法。真的，从那以后就不要再改变了。”
打破旧习惯很难，更难的是自己还没有意识到这个问题。丢弃的第一步，就是要意识到你还在使用过时的方法，这也是最难的部分。另一个难点就是要做到真正的丢弃旧习惯。 毕竟，汽车要比马车车厢强多了。
不是完全忘记旧的习惯，而是只在使用适当的技术时才使用它。
8 打破砂锅问到底
“接受别人给你的解释，别人告诉你问题出在了什么地方，你就去看什么地方。不需要再浪费时间去追根究底”
要不停的问“为什么”。不能只满足于别人告诉你的表面现象，要不停的提问直到你明白问题的根源。
问“为什么”，但是要问到点子上。
当你问“为什么”的时候，也许你会被反问：“为什么你问这个问题。在提问之前，想好你提问的理由，这会有助于你问出恰当的问题。
9 把握开发节奏
“我们很长时间没有进行代码复审，所以这周会复审所有的代码。”
在许多不成功的项目中，基本上都是随意安排工作计划，没有任何规律。那么样的随机安排很难处理。你根本不知道明天将会发生什么。
但是，敏捷项目会有一个节奏和循环，让开发变得更加轻松。Scrum约定了30天之内不应该发生需求变化，这样可以确保团队有一个良性的开发节奏。（Scrum是一种迭代式增量软件开发过程，通常用于敏捷软件开发。包括了一系列实践和预定义角色的过程骨架。）
站立会议最好每天在固定的时间和地点举行，比如说上午10点左右。要养成这样的习惯，在那时就准备好一切参加站立会议。
10 让客户做决定
“开发者兼具创新和智慧，最了解应用程序。因此，所有关键决定都应该由开发者定夺。每次业务人员介入的时候，都会弄得一团糟，他们无法理解我们做事的逻辑。”
在设计方面，做决定的时候必须有开发者参与。可是，在一个项目中，他们不应该做所有的决定，特别是业务方面的决定。
记录客户做出的决定，并注明原因。好记性不如烂笔头。
11 让设计指导而不是操纵开发
“设计文档应该尽可能详细，这样，低级的代码工人只要敲入代码就可以了。编写代码的时候，无论你发现什么，绝不能偏离了设计文档。”
设计满足实现即可，不必过于详细。
即使之前已经提交了设计文档，也还会有一些意料之外的情况出现。时刻谨记，此阶段提出的设计只是基于你目前对需求的理解而已。一旦开始了编码，一切都会改变。设计及其代码实现会不停地发展和变化。
设计可以分为两层：战略和战术。前期的设计属于战略，通常只有在没有深入理解需求的时候需要这样的设计。更确切的说，它应该只描述总体战略，不应深入到具体的细节。
12 合理地使用技术
“你开始了一个新的项目，在你面前有一长串关于新技术和应用框架的列表。这些都是好东西，你真的需要使用列表中所有的技术。想一想，你的简历上将留下漂亮的一笔，用那些伟大的框架，你的新应用将具有极高的技术含量。”
这个技术框架真能解决这个问题么如果需要，先做一个小的原型）
你将会被它拴住么一些技术是贼船，一旦你使用了它，就会被它套牢，再也不可能回头了。我们需要考虑它是开放技术还是专利技术）
维护成本是多少维护成本昂贵。我们听说，有个项目的合同是支持一个规则引擎，引擎一年的维护费用是5万美元，但是，这个数据库只有30条规则）
不需开发你能下载到的东西。
新技术就应该像是新的工具，可以帮助你更好地工作，它自己不应该成为你的工作。
13 保持可发布
“我们刚试用的时候发现了一个问题，你需要立即修复它，放下你手头的工作，去修复那个刚发现的问题。不用告诉其他任何人—赶快让它工作就行了。”
已提交的代码应该随时可以行动。
在本地运行测试；检出最新的代码；提交代码。
14 提早集成，频繁集成
“只要没有到开发的末尾阶段，就不要过早地浪费时间去想如何集成你的代码，至少也要等开发差不多的时候，才可以考虑它。”
敏捷的一个主要特点就是持续开发，而不是三天打鱼两天晒 地工作。特别是在几个人一起开发同一个功能时，更应该频繁地集成代码。
绝不要做大爆炸似的集成。
15 提早实现自动化部署
“没问题，可以手动安装产品，尤其是给质量保证人员安装。”
系统能在你的机器上运行，或者能在开发者和测试人员的机器上运行，当然很好，但是，它同时也需要能够部署在用户的机器上。
质量保证人员应该测试部署过程。
从第一天起就开始交付，一开始就实现自动化部署应用。
如果维护安装脚本变得很困难，那很可能是一个早期警告，预示着—很高的维护成本。
16 使用演示获得频繁反馈
“客户不停的更改需求，导致我们严重地延期。他们一次就应该想清楚所有想要的东西，然后把这些需求给我们。”
需求就像是流动着的油墨。你无法冻结需求，就像你无法冻结市场、竞争、知识、进化或者成长一样。就算你真的冻结了，也很可能是冻结了错的东西。
不一致的术语是导致需求误解的一个主要原因。所以，需要维护一份项目术语表。人们应该可以公开访问它，一般是在wiki或内部 里。
项目启动了一段时间以后，你就应该进入一种舒适的状态，团队和客户建立了一种健康的富有创造性的关系。
17 使用短迭代，增量发布
“我们为后面的3年制定了漂亮的项目计划，列出了所有的任务和可交付的时间表。只要我们那时候发布了产品，就可以占领市场”
给我一份详细的长期 告，我就会给你一个注定完蛋的项目。
对于大项目，最理想的办法就是小步前进，这也是敏捷方法的核心。大步跳跃大大地增加了风险，小步前进才可以帮助你很好地把握平衡。
18 固定的价格就意味着背叛承诺
“对这个项目，我们必须要有固定的 价。虽然我们还不清楚项目的具体情况，但仍要有一个 价。”
固定价格的合同会是敏捷团队的一大难题。我们一直在谈论如何用持续、迭代和增量的方式工作。但是现在却有些人跑过来，想提早知道它会花费多少时间及多少成本。
软件项目天生就是变化无常的，不可重复。如果要提前给出一个固定的价格，就几乎肯定不能遵守开发上的承诺。
如果你现在别无选择，你不得不提供一个固定价格，那么你需要学到真正好的评估技巧。
19 守护天使
“你不必为单元测试花费那么多时间和精力。它只会拖延项目的进度。好歹，你也是一个不错的程序员—单元测试只会浪费时间。”
单元测试能及时提供反馈
单元测试让你的代码更加健壮
单元测试时有用的设计工具
单元测试是你自信的后台
单元测试是可信的文档
单元测试是学习工具
20 先用它再实现它
“前进，先完成所有的库代码。后面会有大量时间看用户是如何思考的。现在只要把代码扔过墙就可以了，我保证它没有问题。”
很多成功的公司都是靠着“吃自己的狗食”活着。也就是说，如果要让你的产品尽可能地好，自己先要积极地使用它。
编程之前，先写测试。
先写测试，你就会站在代码用户的角度来思考，而不仅仅是一个单纯的实现者，这样做是有很大区别的，你会发现因为你自己要使用它们，所以能设计一个更有用、更一致的接口。
21 不同环境，就有不同问题
“只要代码能在你的机器上运行就可以了，谁会去关心它是否可以在其他平台上工作，你又不用其他平台。”
一位同事的代码失败了，最终找到了罪魁祸首：一个.NET环境下的API在Windows XP和Windows2003上的行为不同。平台不同，造成了结果的不一样。
使用持久集成工具，在每一种支持的平台和环境中运行单元测试，要积极地寻找问题，而不是等问题来找你。
22 自动验收测试
“很好，你现在用单元测试来验证代码是否完成了你期望的行为。发给客户吧。我们很快会知道这是否是用户期望的功能。”
关键业务逻辑必须要独立进行严格的测试，并且最后需要通过用户的审批。但是，你又不可能拉着用户，逐一模块确认。所以你需要能自动比较用户期望和实际完成的工作。
FIT（fit.c2.com），即集成测试框架，它很实用，可以更容易的使用HTML表格定义测试用例，并比较测试结果数据。
23 度量真正的进度
“用自己的时间表 告工作进度。我们会用它做项目计划。不用管那些实际的工作时间，每周填满40小时就可以了。”
时间表很难真实地反映工作完成状况，因此它不可以用来进行计划、评估或表现评估。
你曾经听到开发人员 告一个任务完成了80%么而过了一天又一天，一周又一周，那个任务仍然是完成80%。
随意用一个比率进行度量是没有意义的。所以不应该去计算工作量完成的百分比，而应该测定还剩下多少工作量没有完成。如果你最初估计这个任务需要40个小时，在开发了35个小时之后，你认为还需要另外30个小时的工作。那就得到了很重要的度量结果（这里诚实非常重要，隐瞒真相毫无意义）
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！