本书是Bob大叔的著作，关于本书Bob大叔这样描述
请你把这本书看成我的错误大全，它记录了我干过的所有蠢事；也请你把这本书当成一份指引，靠它绕开我曾经走过的弯路
这本书主要阐述软件开发者的专业精神，书中包含很多实操性的建议，并对以下问题尝试解答
- 什么是软件专业人士
- 软件专业人士如何行事
- 软件专业人士如何处理冲突，应对紧急的工期，如何和不讲道理的管理人员打交道？
- 软件专业人士何时应该说"不"，怎么说？
- 软件专业人士如何应对压力？
第1章 专业主义
清楚你要什么
"专业主义"不但象征荣誉与骄傲，而且明确意味着责任与义务。因为从你无法负责的事情上不会获得荣誉与骄傲。
担当责任
对自己的行为负责，作为开发人员，就必须对自己提交的代码负责。
不要破坏软件功能
强调：不能一而再，再而三地犯同样的错误。
- 让QA找不出任何问题
对于测试出来的BUG，需要反思为什么自己没有注意到，要想办法避免再次发生。 - 要确信代码正常运行
这里面，自动化测试可以帮助我们更好的保证代码正常运行。但是有一些代码可能比较难于测试，不过难于测试的代码通常根源于设计，我们可以设计更易于测试的代码，更好的是通过TDD方式。 - 自动化QA
自动化测试还可以保证我们每次的修改，不会出现对系统功能有大影响的BUG。
不要破坏软件结构
软件项目的根本指导原则：软件要易于修改，必须能够让修改不必花太高代价就可以完成。
要保证软件易于修改，唯一的办法就是做一些实际的修改，也就是"重构"。
"童子军训练守则"： 对每个模块，每次提交代码，要比拉取的时候更为简洁。每次读代码，都别忘记点滴的改善。
当一段代码保持固定不变实际上是非常危险的，因为越到后面，越难于重构修改。
代码不容易修改的另外一个原因就是缺少足够的测试，没有测试保障，写代码的人员倾向于保守稳定，就会让保持代码固定不变。
职业道德
术业有专攻，每个技能都是必须投入时间和精力才能够加强的。
了解你的领域
书中列出了每个专业软件开发人员必须精通的事项
- 设计模式。必须能够描述GOF全部24种模式以及对应的实战经验。
- 设计原则。必须了解SOLID原则，而且要深刻理解组件设计原则。
- 方法。 必须理解XP(极限编程)、Scrum、瀑布、结构化分析设计等。
- 实践。 必须掌握测试驱动开发、面向对象设计、结构化编程、持续集成等。
- 工件。 必须了解如何使用UML图、状态迁移图、流程图、决策表等。
坚持学习
读书、看相关文章、关注博客，参加技术大会等等，不懂就学，不畏艰难。
练习
业精于勤，工作之外，我们同样可以加强练习，提升自己，比如leecode刷题。
合作
与他人合作，从彼此身上互相学习。
辅导
专业人士会视辅导新人为己任，不会放任未经辅导的新手肆意妄为。
了解业务领域
当接触某一业务时，应该对该业务领域有所了解，能够辨别、质疑需求的合理性，不能一味的简单按照需求编写代码，但是对需求背后的业务了解甚少。
与雇主/客户保持一致
更多的要站在客户的角度思考，确保研发出来的功能是客户真正需要的，是可以满足客户需要的。
谦逊
当别人犯错的时候，不要横加贬损，因为自己有可能就是下一个犯错的人。当遇到争执时，也要保持谦逊，因为你也有很大概率犯错。
第2章 说 "不"
能就是能，不能就是不能，不要说'试试看'
对抗角色
因为不同角色的立场不同，不同角色之间势必会存在一些矛盾点，比如客户要求在截止时间前必须完成功能，但是开发人员认为这绝对不可能。
当冲突或者矛盾发生时，一定要通过协商的方式达到共同认可的解决方案。比如开发人员如果认为不可能完成，那么可以给出原因，同时可以给出一些解决方案，毕竟你的经理是要将这些信息向上同步的。
这里有一点要注意的，可以尽量不要描述一些具体的细节，因为过多的细节，可能会招来更多的微观管理。尤其是一些从开发转为管理的经理，当你描述了很多细节后，就会有更多的问题。
高风险时刻
越是高风险、关键时刻，一定要有说"不"的勇气。 当公司存亡时刻，就更应该尽自己所能，将最真实的信息传递给经理，千万不要"只报喜，不报忧"。
要有团队精神
团队意味着当其他成员遇到困难时，你需要伸手援助。之前遇到的leader说过一句话，没有成功的个人，只有成功的团队。当团队遇到问题时，大家的处境是一致的，要共同解决问题。
试试看
这里作者的角度是，你之前断定截止日期前，是无法完成任务的。但是在和经理沟通后，你回答说可以"试试看"。这某种程度上意味着你承认之前没有尽全力，还有余力，意味着你推翻了自己之前的结论。
消极对抗
我们对于一些沟通也要留好记录，有时候你说过的结论，经理可能并未直接向上传达。这属于下下策了，毕竟和经理闹掰，并非最优选择。
说"是"的成本
这里作者通过一个故事讲述了一个说"是"的成本，核心点：客户所要的一项功能，一旦写起来，总是远比它开始时所说的要复杂的多。
我们总是倾向于乐观的估计，当遇到客户需求时，总是倾向于答应。这里面一定要做好评估，不然的话，最后的事情大概率只能自己填坑。
如何写出好代码
当一味的满足客户需求时，我们会忽略自己的专业性，会一直拼命的赶进度，这个时候的代码是存在问题的。合理的说"不"，对于写出好的代码，也是有帮助的。
第3章 说 "是"
承诺
做出承诺包含三个步骤
- 口头上说自己将会去做
- 心里认真对待将要做出的承诺
- 真正付诸行动
识别"缺乏承诺"的征兆
由于人们总是会有竭力逃避承担责任的倾向，所以很多时候都会存在"缺乏承诺"的情况。
真正的承诺听起来是怎样的
对于自己，我们是可控的，也就意味着我们要对自己做某件事情有清晰的认识，能够给出准确的结论。做到言必信，行必果。
之所以没有成功，是因为我寄希望于xx去做这件事情
这种事情在日常工作中非常多，我们只能承诺自己完全掌握的事情。那对于依赖别人的事情，就置之不顾吗？ 当然不是，我们应该采取一些具体行动，来接近最终的目标。比如，如果你的接口依赖于第三方，那么最好做到和对方保持足够的沟通，确保能够接近最终的目标。之所以没有成功，是因为我不太确信是否真正能够完成得了
即使目标无法完成，但是我们依然有责任和义务做出一些行动，向最终目标靠近。比如，在发布前要解决25个bug，是完全不可能的。但是你可以和QA一起，重新过一遍重点的BUG，并利用有限的时间优先修复影响主流程的BUG。之所以没有成功，是因为有些时候，我真的无能为力。
我们不可避免的遇到一些我们的确无法解决的问题，面对这种情况，最重要的一定是尽早向你的承诺对象发出预警，越快越好。因为越早，成本越小。千万不要到截止日期前，给大家一个"惊喜"。
学习如何说"是"
"试试"的另一面
这里的试试看容易造成沟通理解的不一致，你的试试，极有可能被对方当做一种承诺。所以当以"试试"回复对方时，最好将对应的风险一并描述。
坚守原则
当工期特别紧，时间不够用的时候，你还会坚持自己的原则吗？ 如果不写测试，或许可以更快完成任务。如果不做重构，或许也可以完成任务。如果不用保持代码清晰整洁，或许可以完成任务。但是，这些真的值得吗？
作为专业人士，如果要给出肯定的回答，一定要确保各方对于承诺的理解是一致的。
第4章 编码
要熟练掌握每一个技能，关键是要具备"信心"和"出错感知"能力。
"信心": 对自己的代码要有信心。
"出错感知能力": 应当快速的从错误中获取到反馈，并能够从中学习，避免后续错误再次发生。
做好充足的准备
编码实际上是一项智力活动，需要全神贯注，因为编码时必须平衡互相牵制的多种因素。包括以下几个常见的因素
- 首先，代码必须要正常工作。
- 代码必须能够帮助客户解决问题，确保能够满足客户的真实需求。
- 代码必须能够和现有系统结合的天衣无缝，你的代码不能让现有系统变得更加脆弱、更晦涩难懂。
- 其他程序员必须能够读懂你的代码。
我们在编码过程中，势必会遇到各种干扰，而当无法全神贯注投入时，就有可能滋生BUG。所以，作者建议，当你觉得疲劳或者心烦意乱时，最好不要写代码。
不要在疲劳的时候写代码
作者某一次凌晨3点写出了代码，但是代码的设计结构有些错误，导致使用起来非常不便利。而且作者当时也没有足够的时间去重构，就这样雪球越滚越大。衷心的建议大家千万不要在疲劳的时候写代码。
不要在焦虑的时候写代码
我们都处于这个社会中，除了工作，还有我们的生活。所以当你的心思被生活中的一些事情困扰时，最好尝试找一个专门时间来解决这些困扰，然后再去写代码。
理性应对中断
中断情况在工作中无法避免，总会有干扰会打断你、消耗你的时间。发生这种事情的时候，不要粗暴对待，因为也许下一次会轮到你打断别人需求帮助。因此，礼貌性的表现出乐于助人的态度才是专业的态度。
如何应对阻塞状态
有的时候，面对电脑，怎么写不出来代码。这个时候，可以尝试做一些别的事情更换一下思路，接杯水、上个厕所、或者找人讨论一下等等。别干坐着，那会让人更加焦虑。
关于调试
工作中，调试实际上占用了我们非常多的时间。调试时间也是衡量一个专业人士的重要方面，我们应当将调试时间降低到最低。运用各种调试技巧、合理使用日志记录、避免重复性的工作、避免低级的错误等等。
保持好节奏
专业程序员也会同样仔细保存好自己的精力和创造力。每个人的精力都是有限的，深夜加班解决问题的效率实际并不高。当我们感觉精力不够的时候，要合理暂停，去休息休息。
埋头解决问题时，有可能由于和问题距离太近，无法看清楚所有的可选项，进而错过合理的解决方案。
所以，有时候，不妨睡个好觉，第二天再战。
进度延迟
即使是最优秀，最专业的程序员，总会有一天遇到进度延迟情况。管理延迟的两大法宝，"早期检测"和"保持透明"。 对于一个目标，我们在衡量进度的时候，可以采用乐观预估、标称预估、悲观预估。
当有了预估后，要管理好期望，比如你的预估是乐观估计8天、标称预估12天，悲观预估20天，那么在10天内完成这个目标的期望是不合理的，也不要对任何人承诺10天可以完成。
当有了预估后，也要避免盲目冲刺，要坚持自己的估算。在不缩减需求范围的情况下，让开发人员赶在截止日期前解决问题，可能会存在问题。因为每个人都会避免面对真正的问题，通过一些"捷径"解决，将困难的事情不断后延。
加班是一个不可避免的问题，我们应当尽量少加班。
加班必须满足的条件，
1）你个人能够挤出时间；
2）短期加班，最多两周；
- 你的老板如果要求加班，那么一定要有后备方案，以防加班措施失败。
最后一条真的很重要，一定要有应对加班措施无效的方案，不然可能造成无效加班。
帮助
记住: 即使你的技能格外高超，也肯定能从另外一个程序员的思考与想法中获益。
帮助他人
互相帮助是每个程序员的职责所在，应该以随时帮助别人为荣。当然，有一点特别特别重要。给别人帮助时，别居高临下。帮助别人并非说明比别人聪明很多，只是因为给别人带来一个新的问题解决视角。
接受他人的帮助
我们也应该乐于接受别人的帮助。一定要学会如何请求帮助，毕竟如果帮助唾手可得，而你确一个人堵在那里，是一种不太专业的表现。当然，寻求帮助前，请一定要有自己的思考。
辅导
除了自身的内驱力和资深导师的有效辅导外，没有东西能将一位年轻的开发人员快速提升为敏捷高效的专业人士。花时间辅导年轻程序员实际上是每个资深程序员的专业职责所在。同样的，对于年轻程序员，向资深程序员寻求辅导也是他的专业职责。
第5章 测试驱动开发
TDD的三项法则
(1) 在编好失败测试之前，不要编写任何产品代码
(2) 只要一个单元测试失败了，就不要写测试代码，无法通过编译也是一种失败情况
(3) 产品代码恰好能够让当前失败的单元测试成功通过即可，无需多写
也就是说，要先写好单元测试的一小部分代码，很快，就你会发现少一些函数或者类，单元测试无法编译或者无法通过，然后就需要编写一些产品相关的代码，让测试通过。产品代码够用即可，然后再回头继续写单元测试。
TDD的优势
- 确定性： 测试可以保证我们的每次修改没有破坏任何东西，可以让我们完全打消对修改代码的恐惧
- 缺陷注入率: TDD有助于明显降低BUG率
- 文档: 单元测试即是文档，遵循TDD的情况下，每个单元测试实际就是一个示例Demo，每个单元测试都描述了系统设计最底层的细节。
- 设计：测试可以让你做出更加松耦合的设计，因为好的代码是要易于测试的。相比较而言，后写测试像是一种被动防守，而先写测试更像是主动进攻。
总结， TDD可以提升代码确定性、降低代码缺陷率、优化文档和设计原则。
第6章 练习
专业人士都需要不断练习。
技能练习
像乐器、舞蹈一样，程序员同样需要不断练习。练习的方式有很多，leecode刷题、分组对抗编程等等。练习实际上是练习我们的编程本能，它有利于我们在潜意识中构建通用问题和解决方案之间的联系，当我们在实际工作中遇到类似问题时，就知道如何解决。
自身经验的拓展
职业程序员经常会面临一种限制，即解决问题的种类比较单一，在一项工作中，我们使用的语言、平台、专业技能可能都比较固化。当行业周期性变化时，会有些手足无措。 所以要保证不落伍。
多参与开源项目是一种不错的选择，还有就是多参加一些技术交流。
实际上，练习更多的是程序员自己的事情，雇主是无需为这些练习买单的。也就是尽可能用自己的时间去做练习吧！
第7章 验收测试
验收测试是针对需求方的，专业的程序员既要做好开发，也要做好沟通。
需求的沟通
需求的沟通还是很困难的，会存在两种典型情况。
过早精细化
做业务和开发会容易掉入一个陷阱，过早进行精细化。就是业务还没启动，就要精确知道最后能得到什么。开发还没有评估项目，就需要准确知道交付什么。
- 不确定原则
东西画在纸上和真正做出来，极大可能存在不一样。业务方看到做出来的东西后，才发现自己想要的不是这样。每一次给业务演示，他们就会获得比之前更多的信息，然后提出更多的想法。 - 预估焦虑
记住，需求一定会变化的。即使拥有全部的准确信息，评估通常也会存在巨大的变数。所以开发人员需要基于不那么准确的需求进行评估。
迟来的模糊性
避免过早精细化的话，那就推迟精细化。但是这样就会引入迟来的模糊性问题。业务方和开发方会对需求提出不同意见，所以要寻找大家都同意的关于需求的表述，专业开发人员要确认需求中没有任何不确定因素。
以上两种问题是存在矛盾的，那要如何应对的，解决方案就是验收测试。
验收测试
验收测试是业务方与开发方合作编写的测试，目的在于验收需求已经完成。
"完成"的定义
"完成"的各种说法，是第一个不确定因素。所以要在完成这个事情上做到统一，完成应该意味着验收测试完成。
沟通
验收测试的目的是沟通、澄清、精确化。开发方、业务方、测试方对于验收测试达成共识，大家对于系统的行为都已经明确。专业开发人员与业务方、测试方协作，并有义务确保大家都明白要做的是什么。
自动化
验收测试最好是自动化的，可以降低成本。可以借助一些开源工具完成自动化测试，这些工具非程序员也可以阅读、理解、编写测试。
验收测试由谁来写
理想情况下，验收测试应该由业务方和QA协作编写，由程序员检查。但实际上，更多的会是测试甚至开发人员，如果只能由开发人员编写的话，应当确保写测试的程序员与开发不是同一个人。
业务方验收测试"正确路径"，以证明功能的业务价值；QA则测试"错误路径"、边界条件、异常情况等，QA要考虑系统哪些部分可能出问题。双方立场、视角不同。
测试的协商与被动推进
作为专业开发人员，与编写测试人员协商并改进测试也是你的职责，不能被动接受，一定要让测试case有意义。因为大家的最终目的是做出优秀的软件。
验收测试和单元测试的区别
- 面向对象不同
单元测试是程序员写给程序员的，是正式的设计文档，描述了底层结构和代码行为，关心单元测试结构的是程序员。
验收测试是写给业务方的，他们是正式的需求文档，描述了业务方认为系统应该如何运行。关心验收测试结构的是业务方和程序员。
- 机制和路径不同
单元测试是深入系统内部的，是调用特定类的方法；
验收测试则是系统外部，通常是在API或者UI级别进行；
不过两者的主要目的都是如实描述系统的设计、结构、行为。
图形界面和其他复杂因素
软件设计时应该将GUI和业务分开。
GUI非常容易变化，这类测试是非常不稳定的，而且维护成本很高。
持续集成
在持续集成系统中，应该确保单元测试和验收测试每次都会运行，当有代码提交时，自动触发。当测试失败时，应该第一时间介入解决。
自动化的验收测试，可以作为解决开发方和业务方需求沟通问题的一剂良药。
第8章 测试策略
QA应该找不到任何错误
QA也是团队的一部分
QA和开发人员应该紧密协作，携手保障系统的质量。 在团队中，QA应该作为需求规约定义者和特性描述者。
需求规约定义者
QA的任务是和业务人员一起创建自动化验收测试，作为系统真正的需求规约文档，QA应该从业务人员那里收集需求，并翻译为描述行为的测试。
特性描述者
QA的另一项任务便是遵循探索式测试的原则，描述系统运行中的真实情况，并将其反馈给开发和业务人员。
自动化测试金字塔
单元测试
金字塔底部是单元测试，这些测试是由程序员使用与系统开发相同的语言来编写的，编写单元测试的目的是在最低层次上定义系统，该类测试可以达到测试覆盖率100%。
组件测试
组件测试是验收测试的一种，通常系统的组件封装了业务规则，对这些组件测试便是对其中业务规则的验收测试。在组件测试中，需要使用合适的Mock或者测试辅助技术，解开与系统其他组件的耦合。
集成测试
集成测试是将组件装配成组，测试他们彼此之间是否正常通信。集成测试是编排性测试。
系统测试
是针对整个集成完毕的系统运行的自动化测试，是最终的集成测试。用于测试系统是否正确组装完毕，以及系统各个组件间是否正常交互。这个层次的测试集中，应该包含性能测试和吞吐量测试。
人工探索式测试
这种测试的意图，是要在验证预期行为的时候，探索系统预期之外的行为。它不是为了证明每个路径都是正确的，而是确保系统在人工操作下表现良好。
总结
开发和测试应该紧密协作，构建由单元测试、组件测试、集成测试、系统测试和探索式测试构成的测试体系。应该尽可能频繁的运行这些测试，提供尽可能多的反馈，确保系统始终整洁。
第9章 时间管理
会议
会议的两个真理
(1) 会议是必须的
(2) 会议浪费了大量的时间
拒绝
受邀约的会议并非一定要参加，参与的会议过多，其实只能从某个层面证明你不够专业。
务必确保出席会议可以给自己目前的工作带来切实显著的成效，否则可以拒绝参加。
离席
会议并非总是按照计划进行的，有的时候会临时增加主题，如果主持人把控不好的话，你可以选择友好的离开。这里一定要注意友好的离开，不要过于粗鲁。
确定议程与目标
如果收到会议邀约，务必弄清楚会议议题是什么，大概需要多久，要取得的最终成果，如果这些都没有，那大概率可以拒绝参会。
如果你已经入会，但是发现会议有些偏题或者放弃了之前制定的议程，你应该要求主持人再确定一下该会议的目的和议程，如果没有的话，那就友好离开吧。
立会
是敏捷迭代中的方式，也叫晨会或者站会。每个人都应该回答几个问题
(1) 我昨天干了什么？
(2）我今天打算干什么?
(3) 我遇到了哪些问题?
这种会议每个人一定要简短，需要展开讨论的会后单独进行。
迭代计划会议
也是敏捷迭代中的会议。迭代会议是用于选择在下一轮迭代中要实现的开发任务。在会议召开前，必须完成两项任务，
(1) 评估可选择任务的开发时间
(2) 确定这些任务的业务价值
如果有可能，可以完成验收/组件测试，或者至少应该有概要方案。
迭代回顾和DEMO展示
主要是复盘本次迭代，哪些做的对，哪些可以继续提升。也可以给业务方展示最新的DEMO。
争论/反对
凡是不能再5分钟内解决的争论，都不能靠辩论解决。
之所以要花更多的时间，是因为双方都没有足够有力的证据。
技术争论很容易走入极端，这通常是因为缺少数据，如果有数据支撑，结论更容易获得。
注意力点数
编程是需要持续投入精力和注意力的智力活动。如果用光了自己的注意力点数，那必须花一小时或者更多时间做一些不需要注意力的事情，让注意力补充回来。
保障充足的睡眠
没有什么比睡一觉更容易补充注意力点数了。
咖啡因
咖啡因人而异，适量使用，也可以帮助你短期内维持注意力点数。
恢复
可以做些其他事情，换换脑子，让注意慢慢恢复。
时间拆分与番茄工作法
要避免的行为
优先级错乱是我们要避免的行为。所谓优先级错乱是指刻意提高某个任务的优先级，之后就有借口推迟真正急迫的任务。这实际上是不专业的，我们最好按照四象限的方式，真实评估任务优先级。
四象限
死胡同
所有软件开发者都会遇到死胡同。比如你做了决定，选择了走不通的技术道路。你对这个道路越是坚持，就越浪费时间。
当我们真正遇到死胡同时，要能够迅速意识到，并有勇气回头，一定要及时止损。
当明知此路不通，或者已经深处泥潭，还要固执前行，是最严重的优先级错乱。
第10章 预估
预估是软件开发人员面对的最简单、也是最可怕的活动之一。预估时业务人员和开发人员之间最主要的障碍，横亘在双方间的不信任，几乎都由它引发。
什么是预估
业务方觉得预估就是承诺。开发方认为预估就是猜测。
承诺
承诺是关于确定性的，是必须要实现的。
预估
预估仅仅是一种猜测，它并不包含承诺色彩。预估总会存在偏差，原因在于预估的本质实际上是概率分布。
PERT
PERT（Program Evaluation Review Technique)计划评审技术。它非常简单有效的把预估变为了概率分布。
可以根据3个数字预估某个任务
- O: 乐观预估。 异常顺利情况下的完成时间。通常为了使得乐观估计是有意义的，这个数字对方的发生概率应该小于1/1000。
- N: 标称预估。这是概率最大的数字，如果是柱状图，标称预估就是最高的那个。
- P: 悲观预估。这是最糟糕的数字。为了保证有效性，该数值的发生的概率也要小于1/1000.
有了以上三种评估，可以像下面一样描述概率分布：
μ表示任务期望的完成时间。
σ是这个任务的概率分布标准差，用于衡量不确定性。
用μ/σ作为预估。
如果一个人同时参与多个任务，可以同时进行评估。
| 任务 | 乐观预估 | 标称预估 | 悲观预估 | μ | σ |
|---|---|---|---|---|---|
| alpha | 1 | 3 | 12 | 4.2 | 1.8 |
| beta | 1 | 1.5 | 14 | 3.5 | 2.2 |
| gamma | 3 | 6.25 | 11 | 6.5 | 1.3 |
把所有任务加和，得到所有的任务统计分布
对于依次完成的任务，总的期望完成时间就是这些任务的期望完成时间的和。 对上表来说，其预估4.2/1.8、3.5/2.2、 6.5/1.3，那么大概需要4.2 + 3.5 + 6.5 = 14天才能完成。
总的方差就是各个任务标准差平方之和的平方根，也就是1.8 * 1.8 + 2.2 * 2.2 + 1.3 * 1.3 再开根号，大约是3。
所以所有任务完成的时间大概需要14天，也有可能是17天(1σ)或者20天(2σ)，都有可能。
悲观估计将各个任务的不确定性都累加起来，让整个计划更加贴近真实。 PERT是一种较好的避免乐观预估的合理方法。
预估任务
在预估任务时，也可以考虑同事的一些想法，因为他们可能看到你自己看不到的东西，可以帮助你更加准确的预估任务。
德尔菲法
该方法的核心就是达成共识。
亮手指
对某个任务，大家在同一个时刻给出预估。（就像是狼人杀的白天投票)。规划扑克
一种特殊的扑克，用扑克上的数字表示工作量，然后大家对于任务选择自己认为的点数，并将扑克倒扣，最终揭晓。关联预估
在关联预估中，所有的任务都写在卡片上，卡片上没有任何评估信息，把卡片打乱。 然后大家都卡片上的任务按照自己认为的时间排序，需要时间长的放到右面，时间短的放到左面。任何时候，任何人都可以移动卡片，如果某个卡片被移动了N次，那么就需要大家一起讨论，有了大致的时间长度后，再分配具体的时间。三元预估
可以将PES和德尔菲结合，对乐观、标称、悲观估计分别采用德尔菲方法。
大数定律
预估非常容易出错，控制错误的一种办法就是将大任务分解为许多小任务，再进行评估，结果会比单独进行大任务评估要准确。 但是这里会存在一个乐观估计的陷阱，主要就是发现将任务拆分小后，我们对于风险的评估会被拆解。不过整体来说，拆解是非常有必要的。
第11章 压力
即使有压力，作为专业开发人员，也要冷静果断。
避免压力
在压力下，保持冷静的最好方式，便是规避会导致压力的处境。规避的方式也许无法完全减除压力，但是可以大大降低压力，并缩短高压力的时间。
承诺
这里指的是有人会代我们做出承诺，比如业务人员，可能在没有咨询开发人员的情况下，就给客户许诺。专业开发人员总会帮助业务方找到达成目标的方法，但是并非一定要接受业务方代为做出的承诺。而作为业务方，不要一味地满足客户，客户固然重要，但是也别忘记后方的兄弟们。
保持整洁
让系统、代码、设计尽可能保持整洁，不要容忍混乱，脏乱会导致速度变慢，进而产生压力。
危机中的纪律
选择那些你在危机时刻依然会遵守地纪律原则，并在日常所有工作中，都遵守这些纪律。这样做，可以有效地避免陷入危机。
应对压力
不要惊慌失措
正确应对压力，放松下来，对问题深思熟虑，努力寻找可以带来最好结果的路径，并沿着该路径合理稳定的节奏前进。
沟通
让你的团队和主管知道你深陷困境中。告诉他们你所制定如何走出困境的计划，寻求他们的支援或者指引。这里也就是说，要同步困境，但是最好也要给出可能的方案。
依靠你的纪律原则
战胜压力煎熬的唯一方法，便是你已经知道切实有效的东西 -- 你平时严格遵守的纪律。
寻求帮助
当自己无法思考时，可以尝试和别人一起讨论，寻求帮助。当然，如果别人深陷压力下，你也可以伸出援手，帮助他们脱离困境。
总结一下就是，保持冷静，与别人多多沟通，坚持自己的原则纪律，并寻求他人的帮助。
第12章 协作
大多数软件都是由团队开发完成的。当团队人员能够非常专业的互相协作时，整个团队才是最高效的。
程序员与人
大多数程序员还是习惯与机器打交道，还是最享受面无表情的思索，把自己像蚕茧一样裹起来，沉浸于问题思考中。
程序员与雇主
对所做的事情充满激情是好的，但是，最好将注意力集中在付我们薪水的老板所追求的目标上。
专业程序员的首要职责就是满足雇主的需求，做到深刻理解业务，理解你手上正在编写的代码业务价值是什么，了解雇佣你的企业如何从你的工作中获得回报。
程序员与程序员
程序员间的合作也会存在一些不小的问题
协作性的代码共享权
在同一个团队中，代码应该共有，不要代码个体所有。专业开发人员不会阻止别人review自己的代码，或者对自己的代码进行修改。
作为开发人员，我们必须与测试、业务人员协作，也必须与其他开发人员协作。
第13章 团队与项目
团队
形成团队是需要时间的，团队人员需要先建立关系，学习如何互相协作，简单了解彼此的癖好、强项、弱项，最终才能形成团队。
有凝聚力的团队
有凝聚力的团队通常人数大约为12名成员，应该配有程序员、测试人员和业务分析师，同时还要有一名项目经理。程序员可以作为一组，测试和业务分析师算一组，两组人数比例约为2:1。那么12人的团队配置应该是7名程序员、2名测试、2名分析师和一个项目经理。
项目经理的主要职责是跟踪团队项目进度，确保团队成员理解项目时间表和优先级。
形成有凝聚力的团队是需要时间的，所以千万不要因为项目终止了，就将团队解散，可以将团队直接移植到另外一个项目中去。所以，专业的开发组织会将项目分配给已经有凝聚力的团队，而不会根据项目临时组件团队。
如何管理有凝聚力的团队？
每个团队都有自己的速度，也就是在一定时间段内团队能够完成的工作量。比如有的团队使用每周点数衡量自己的速度。团队会对每个工作项目的特性进行分解，然后使用点数进行估算，最后以每周可以完成的点数来衡量自己的速度。
有一点要注意，速度是一种统计性的度量。比如一个团队可能某一周完成了38个点，下一周又可能完成25个点。随着时间的推移，便可以得到一个平均值。
管理人员可以给每个团队分配的项目设置一个目标值。 比如，如果一个团队的平均速度为50点数，而他们同时参与了3个项目，那么就可以将团队的精力按照15、15、30分配。
该方法的另外一个优势便是可以调整优先级，如果某个项目紧急，可以将团队的100%精力全部投入在该项目中。 相反，如果团队是临时拼凑起来的，再调整项目优先级则会比较困难。
项目负责人的困境
作为项目负责人，当有一个专门的团队完全投入到他的项目中时，他会非常有安全感。因为他可以清楚计算出团队的投入是多少，而且他也知道公司组建和解散团队都是有工作量和成本的，不会因为短期原因调走团队。
相反，如果项目分配给一个有战斗力的团队，那么对于项目负责人，就会缺乏安全感，因为项目随时可能因为公司策略或者项目优先级而调整。
不过，作为项目负责人，更重要的意义应该是，清晰地定义和陈述项目的价值和意义，让项目得到公司管理层的认可和支持。
第14章 辅导、学徒期与技艺
"失败"的学位教育
这里作者强调了一点，即使最好的计算机学位教学计划，通常也不足以帮助年轻毕业生充分准备好应付工作后的挑战。 因为学科和现实工作之间会存在较大的差异。 所以我们要非常注重对于毕业生的辅导。
辅导
这里讲述了几种对作者非常有意义的辅导。
- 学习别人有用的手册
- 观察别人的工作学习习惯
- 导师，作为导师，可以对所教之人，进行工作审查、指导工作，并帮助他们建立正确的工作价值观和习惯。
学徒期
医生行业是有一套严密的辅导体系的，他们在真正上岗前，会经历实习期、住院实习期、搭档合作期等等。因为人命关天。
在软件领域，尽管软件错误造成的伤亡相对较少，但是造成的经济损失确非常巨大。很多公司对于毕业生，培训不足，而又让其参与到重要的项目中，这实际上就是隐患。
所以，每一个大学毕业生，在成为软件开发人员前，都应该参与过一段合理的督导实训期。
软件学徒期
看一下不同阶段的研发人员特点。
大师
- 领导过多个重要软件项目
- 拥有10年以上从业经验，曾在多个不同操作系统、不同语言工作
- 懂得如何领导和协作多个团队
- 熟练的设计师和架构师，能够游刃有余的编程
- 通过不断的阅读、研究、练习、实践、教学来维持自身的技术水平
熟练工
- 学习如何在团队中卓越工作和成为团队的领导者
- 对当前参与的技术非常了解，对其他许多系统尚缺乏经验
- 一般只了解一种语言、一个系统、一种平台，但是他们在不断学习。
- 向上是成长迅速的大师，向下是刚刚进来不久的是实习生。
该阶段需要在大师或者其他自身熟练工的督导下工作。
实习生
- 应该学习纪律并强化各项实践的阶段。
- 应该塑造各项基础价值观。
作为熟练工，通常会作为实习生的导师。 那么熟练工应该做到以下几点
- 确保实习生能够了解设计原则、设计模式、各种纪律和固定的操作环节。
- 向实习生传授TDD、重构、预估等各种技艺。
- 为实习生安排练习和实践任务
- 定期检查实习生任务进展情况。
当然，授之以渔后，更重要的还是要依赖自己的主观能动性。
我们每个人，都应该有工匠精神，作为表率，向大家展示自己的专业技能，用自己的感染力去影响周围的每一个人。
