恶魔：“软件技术的变化如此之快，势不可挡，这是它的本性。继续用你熟悉的语言做你的老本行吧，你不可能跟上技术变化的脚步。”
你不需要一口气爬上10楼，而需要一直在攀登，所以最后看起来就像只要再上一二层。如果你对所有这些技术都一无所知，想要马上登上这10楼，肯定会让你喘不过气来。而且，这也会花很长时间，期间还会有更新的技术出现。
现今有很多方法和工具可以帮助我们继续充电：
天使：“跟踪技术变化。你不需要精通所有技术，但需要清楚知道行业的动向，从而规划你的项目和职业生涯。”
恶魔：“不要和别人分享你的知识——自己留着。你说因为这些知识而成为团队中的佼佼者，只要自己聪明就可以了，不用管其他失败者。”
团队中的开发者们各有不同的能力、经验和技术。每个人都各有所长。不同才能和北京的人混在一起，是一个非常理想的学习环境。
在一个团队中，如果知识你个人技术很好还远远不够。如果其他团队成员的知识不够，团队也无法发挥其应有的作用：一个学习型的团队才是较好的团队。
当开发项目的时候，你需要使用一些术语或者隐喻来清晰地传达 设计的概念和意图。如果团队中的大部分成员不熟悉这些，就很难进行高效的工作。再比如你参加了一个课程或者研讨班之后，所学的知识如果不用，往往就会忘记。所以，你需要和其他团队成员分享所学的知识，把这些知识引入团队中。
找出你或团队中的高手擅长的领域，帮助其他的团队成员在这些方面迎头赶上（这样做还有一个好处是，可以讨论如何将这些东西应用于自己的项目中）。
“午餐会议”是在团队中分享知识非常好的方式。在一周之中挑选一天，事先计划午餐时聚集在一起，这样就不会担心和其他会议冲突，也不需要特别的申请。为了降低成本，就让大家自带午餐。
每周，要求团队中的一个人主持讲座。他会给大家介绍一些概念，演示工具，或者做团队感兴趣的任何一件事情。你可以挑一本书，给大家说书哦其中一些特别内容、项目或者实践。无论什么主题都可以。
从每周主持讲座的人开始，先让他讲15分钟，然后，进行开放式讨论，这样每个人都可以发表自己的意见，讨论这个主题对于项目的意义。讨论应该包括所能带来的益处，提供来自自己应用程序的示例，并准备好听取进一步的信息。
这些午餐会议非常有用。它促进了各镇团队对这个行业的了解，你自己也可以从其他人身上学到很多东西。优秀的管理者会重用那些能提高其他团队成员价值的人，因此这些活动也直接有助于你的职业生涯。
天使：“提供你和团队学习的更好平台。通过午餐会议可以增进每个人的知识和技能，并帮助大家聚集在一起进行沟通交流。唤起人们对技术和技巧的激情，将会对项目大有裨益。”
恶魔：“那就是你一贯的工作方法，并且是有原因的。这个方法也很好的为你所用。开始你就掌握了这个方法，很明显它是最好的方法。真的，从那以后就不要再改变了。”
随着科技进步，曾经非常有用的东西往往会靠边站。它们不再有用了，它们还会降低你的效率。对于大多数的商业应用，技术已经有了巨大的变化，不再像过去那样，处处考虑内存占用、手动的重复占位及手工调整汇编语言。
Expensive mental models aren‘t discarded lightly
丢弃已经会的东西并不容易，很多团队在犹豫。在学习一门新技术的时候，多问问自己，是否把太多旧的态度和方法用在了新技术上。打破旧习惯很难，更难的是自己还没有意识到这个问题。
这也不是说你真的要完全丢弃它们。其实，根据具体情况还可以运用旧知识。
应该力求尽可能完全转入新的开发环境。例如，学习一门新的编程语音时，应使用推荐的集成开发环境，而不是你过去开发时用的工具插件。用这个工具编写一个和过去完全不同类型的项目。转换的时候，完全不要使用过去的语言开发工具。只有更少被旧习惯牵绊，才更容易养成新习惯。
天使：“学习新的东西，丢弃旧的东西。在学习一门新技术的时候，要丢弃会阻止你前进的旧习惯。”
恶魔：“接受别人给你的解释。别人告诉你问题出在了什么地方，你就去看什么地方。不需要再浪费时间去追根究底。”
前面谈到的一些习惯是关于如何提高你和团队的技术的。下面有一个习惯几乎总是有用，可以用于设计、调试以及理解需求。
假设，应用系统出了大问题，它们找你来修复它。但你不熟悉这个应用系统，所以他们会帮助你，告诉你问题一定是出在哪个特殊的模块中——你可以放心地忽略应用系统的其他地方。你必须很快的解决这个问题，因为跟你合作的这些人耐心也很有限。
当你受到那些压力的时候，也需要会觉得受到了胁迫，不想去深入了解问题，而且别人告诉你的已经够深入了。然而，为了解决问题，你需要很好的了解系统的全局。你需要查看所有你认为和问题相关的部分——即使其他人觉得这并不相干。为了解决问题，你需要知道许多可能的影响因素。当找人询问任何相关的问题时，让他们耐心的回答你的问题，这是你的职责。
或者，假设你和资深的开发者一起工作。它们可能比你更了解这个系统。但他们也是人，有时他们也会忘记一些东西。你的问题甚至会帮助他们理清思路。你从一个新人角度提出的问题，给他们提供了一个新的视角，也许就帮助他们解决了一只令人困扰的问题。
“为什么”时一个非常好的问题。事实上，在一本流行的管理图书《第五项修炼》中，作者建议，在理解一个问题的时候，需要渐次地问5个以上的“为什么”。它是很好的方式，进一步挖掘简单直白的答案，通过这个路线，设想就会更加接近事实真相。
真的吗？为什么呀？
为什么呀？
天使：“不停地问为什么。不能只满足于别人告诉你的表面现象。要不停地提问直到你明白问题的根源。”
恶魔：“我们很长时间没有进行代码复审，所以这周会复审所有的代码。此外，我们也要做一个发布计划了，那就从星期二开始，用3周时间，做下一个发布计划。”
在许多不成功的项目中，基本上都是随意安排工作计划，没有任何的规律。那样的随机安排很难处理。你根本不知道明天将会发生什么，也不知道什么开始下一轮的全体“消防演习”。
但是敏捷项目会有一个节奏和循环，让开发更加轻松。例如约定30天之内不应发生需求变化，这样确保团队有一个良性的开发节奏。这有助于防止一次计划太多的工作和一些过大的需求变更。
我们先来看某个工作日的情况。你希望每天工作结束的时候，都能完成自己的工作，你手上没有遗留下任何重要的任务。当然，每天都能这样说不现实的。但你可以做到每天下班离开公司前运行测试，并提交一天完成的代码。如果已经很晚了，并且你只是尝试性地编写了一些代码，那么也许最好应该删掉这些代码，第二天从头开始。这个建议听起来十分极端，但如果你正在开发小块的任务，这种方式非常有助于你管理自己的时间：如果你工作的时候没有一个固定的最终期限，就应该好好想想了。
敏捷开发者可以从多方面得到反馈：用户、团队成员和测试代码。但时间本身就是一个非常重要的反馈。
你可能不知道完成所有的任务需要多少个迭代，但每个迭代必须是短期的、有限的，并且要完成具体的目标。
迭代的时间是固定的，但在一个具体的迭代中完成哪些功能是灵活的。相似地，你会为设计讨论会设定时间期限，会议结束必须要做出最终的设计决策。
当你遇到艰难抉择的时候，固定的时间期限会促使你做决定。你不能在讨论或功能上浪费很多时间，这些时间可以用于具体的工作。
站立会议最好每天在固定的时间和地点举行，比如上午9点左右。要养成这样的习惯，在那时就准备好一切参加站立会议。
最大的节拍就是迭代时间，一般是1～4周的时间。不管你的一个迭代是多长，都应该坚持——确保每个迭代周期的时间相同很重要。运行有规律的开发节奏，会更容易达到目标，并确保项目不停地前进。
天使：“解决任务，在事情变得一团糟之前。保持事件之间稳定重复的间隔，更容易解决常见的重复任务。”
原文：https://www.cnblogs.com/fr-ruiyang/p/11380364.html