敏捷的方法论

跟踪变化

恶魔：“软件技术的变化如此之快，势不可挡，这是它的本性。继续用你熟悉的语言做你的老本行吧，你不可能跟上技术变化的脚步。”

你不需要一口气爬上10楼，而需要一直在攀登，所以最后看起来就像只要再上一二层。如果你对所有这些技术都一无所知，想要马上登上这10楼，肯定会让你喘不过气来。而且，这也会花很长时间，期间还会有更新的技术出现。

现今有很多方法和工具可以帮助我们继续充电：

迭代和增量式学习：每天计划用一段时间来学习新技术，它不需要很长时间，但需要经常进行。记下那些你想学习的东西——当你听到一些不熟悉的属于或者短语时，简要地把它记录下来。然后再计划的时间中深入研究它。
了解最新行情：互联网上有大量关于学习新技术的资源。阅读社区讨论和邮件列表，可以了解其他人遇到的问题，以及它们发现的很酷的解决方案。选择一些公认的优秀技术博客，经常去读一读，以了解那些顶尖的博客作者们正在关注什么。
参加本地的用户组活动：各种技术在很多地区都会有用户组。听讲座，然后积极加入到问答环节中。
参加研讨会议：计算机大会在世界各地举行，许多知名的顾问或作者主持研讨会或课程。这些聚会上向专家学习的最直接的好机会。
如饥似渴地阅读：找一些关于软件开发和非技术主题的好书，也可以上一些专业的期刊和商业杂志，甚至上一些大众媒体新闻。

天使：“跟踪技术变化。你不需要精通所有技术，但需要清楚知道行业的动向，从而规划你的项目和职业生涯。”

切身感受

你能嗅到将要流行的新技术，知道它们已经发布或投入使用。
如果必须要把工作切换到一种新的技术领域，你能做到。

平衡的艺术

许多新想法从未变得羽翼丰满，成为有用的技术。即使是大型、热门和资金充裕的项目也会有同样的下场。你要正确抱我自己投入的精力。
你不可能精通每一项技术，没有必要去做这样的尝试。只要你在某些方面成为专家，就能使用同样的方法，很容易成为新领域的专家。
你要明白为什么需要这项新技术——它试图解决什么样的问题？它可以被用在什么地方？
避免在一时冲动的情况下，只是因为想学习而将应用切换到新的技术、框架或开发语言。在做决策之卡没，你必须评估新技术的优势。开发一个小的原型系统，说对付技术狂热者的一剂良药。

对团队投资

恶魔：“不要和别人分享你的知识——自己留着。你说因为这些知识而成为团队中的佼佼者，只要自己聪明就可以了，不用管其他失败者。”

团队中的开发者们各有不同的能力、经验和技术。每个人都各有所长。不同才能和北京的人混在一起，是一个非常理想的学习环境。

在一个团队中，如果知识你个人技术很好还远远不够。如果其他团队成员的知识不够，团队也无法发挥其应有的作用：一个学习型的团队才是较好的团队。

当开发项目的时候，你需要使用一些术语或者隐喻来清晰地传达设计的概念和意图。如果团队中的大部分成员不熟悉这些，就很难进行高效的工作。再比如你参加了一个课程或者研讨班之后，所学的知识如果不用，往往就会忘记。所以，你需要和其他团队成员分享所学的知识，把这些知识引入团队中。

找出你或团队中的高手擅长的领域，帮助其他的团队成员在这些方面迎头赶上（这样做还有一个好处是，可以讨论如何将这些东西应用于自己的项目中）。

“午餐会议”是在团队中分享知识非常好的方式。在一周之中挑选一天，事先计划午餐时聚集在一起，这样就不会担心和其他会议冲突，也不需要特别的申请。为了降低成本，就让大家自带午餐。

每周，要求团队中的一个人主持讲座。他会给大家介绍一些概念，演示工具，或者做团队感兴趣的任何一件事情。你可以挑一本书，给大家说书哦其中一些特别内容、项目或者实践。无论什么主题都可以。

从每周主持讲座的人开始，先让他讲15分钟，然后，进行开放式讨论，这样每个人都可以发表自己的意见，讨论这个主题对于项目的意义。讨论应该包括所能带来的益处，提供来自自己应用程序的示例，并准备好听取进一步的信息。

这些午餐会议非常有用。它促进了各镇团队对这个行业的了解，你自己也可以从其他人身上学到很多东西。优秀的管理者会重用那些能提高其他团队成员价值的人，因此这些活动也直接有助于你的职业生涯。

天使：“提供你和团队学习的更好平台。通过午餐会议可以增进每个人的知识和技能，并帮助大家聚集在一起进行沟通交流。唤起人们对技术和技巧的激情，将会对项目大有裨益。”

切身感受

这样做，会让每个人都觉得自己越来越聪明。
整个团队都要了解新技术，并指出如何使用它，或者指出需要注意的缺陷。

平衡艺术

读书小组逐章一起阅读一本书，会非常有用，但是要选好书。
不是所有的讲座都能引人入胜，有些甚至显得不合时宜。不管怎么样，都要未雨绸缪。
尽量让讲座走入团队中
坚持有计划有规律地举行讲座。持续、小步前进才是敏捷。稀少、间隔时间长的马拉松式会议非敏捷也。
如果一些团队成员因为吃午饭而缺席，用美食引诱他们。
不要局限于纯技术的图书和主题，相关的非技术主题也会对团队有帮助。
午餐会议不是设计会议。总之，你应专注讨论那些与应用相关的一般主题。具体的设计问题，最好是留到设计会议中去解决。

懂得丢弃

恶魔：“那就是你一贯的工作方法，并且是有原因的。这个方法也很好的为你所用。开始你就掌握了这个方法，很明显它是最好的方法。真的，从那以后就不要再改变了。”

随着科技进步，曾经非常有用的东西往往会靠边站。它们不再有用了，它们还会降低你的效率。对于大多数的商业应用，技术已经有了巨大的变化，不再像过去那样，处处考虑内存占用、手动的重复占位及手工调整汇编语言。

Expensive mental models aren't discarded lightly
丢弃已经会的东西并不容易，很多团队在犹豫。在学习一门新技术的时候，多问问自己，是否把太多旧的态度和方法用在了新技术上。打破旧习惯很难，更难的是自己还没有意识到这个问题。

这也不是说你真的要完全丢弃它们。其实，根据具体情况还可以运用旧知识。

应该力求尽可能完全转入新的开发环境。例如，学习一门新的编程语音时，应使用推荐的集成开发环境，而不是你过去开发时用的工具插件。用这个工具编写一个和过去完全不同类型的项目。转换的时候，完全不要使用过去的语言开发工具。只有更少被旧习惯牵绊，才更容易养成新习惯。

天使：“学习新的东西，丢弃旧的东西。在学习一门新技术的时候，要丢弃会阻止你前进的旧习惯。”

切身感受

新技术会让人感到有一点恐惧
你确实需要学习很多东西。
已有的技能和习惯为你打下了很好的基础，但不能依赖它们。

平衡的艺术

要果断丢弃旧习惯，一味遵循过时的旧习惯会危害的你的职业生涯。
不是完全忘记旧的习惯，而是旨在使用适当的技术时才使用它。
对于所使用的语言，要总结熟悉的语言特性，并且比较这些特性在新语言或新版本中有什么不同。

打破砂锅问到底

恶魔：“接受别人给你的解释。别人告诉你问题出在了什么地方，你就去看什么地方。不需要再浪费时间去追根究底。”

前面谈到的一些习惯是关于如何提高你和团队的技术的。下面有一个习惯几乎总是有用，可以用于设计、调试以及理解需求。

假设，应用系统出了大问题，它们找你来修复它。但你不熟悉这个应用系统，所以他们会帮助你，告诉你问题一定是出在哪个特殊的模块中——你可以放心地忽略应用系统的其他地方。你必须很快的解决这个问题，因为跟你合作的这些人耐心也很有限。

当你受到那些压力的时候，也需要会觉得受到了胁迫，不想去深入了解问题，而且别人告诉你的已经够深入了。然而，为了解决问题，你需要很好的了解系统的全局。你需要查看所有你认为和问题相关的部分——即使其他人觉得这并不相干。为了解决问题，你需要知道许多可能的影响因素。当找人询问任何相关的问题时，让他们耐心的回答你的问题，这是你的职责。

或者，假设你和资深的开发者一起工作。它们可能比你更了解这个系统。但他们也是人，有时他们也会忘记一些东西。你的问题甚至会帮助他们理清思路。你从一个新人角度提出的问题，给他们提供了一个新的视角，也许就帮助他们解决了一只令人困扰的问题。

“为什么”时一个非常好的问题。事实上，在一本流行的管理图书《第五项修炼》中，作者建议，在理解一个问题的时候，需要渐次地问5个以上的“为什么”。它是很好的方式，进一步挖掘简单直白的答案，通过这个路线，设想就会更加接近事实真相。

真的吗？为什么呀？

为什么呀？

天使：“不停地问为什么。不能只满足于别人告诉你的表面现象。要不停地提问直到你明白问题的根源。”

切身感受

你不停筛选掉无关的物质，一次比一次深入，直到找到发光的宝石。
你要能感觉到真正地理解了问题，而不是只知道表面的症状。

平衡的艺术

你可能会跑题，问了一些与主题无关的问题。问为什么，但是要问到点子上。
当你问为什么的时候，也许你会被反问：“为什么你问这个问题？”在提问前想好你提问的理由，这会有助于你问出恰当的问题。
“这个我不知道”是一个好的起点，应该由此进行更进一步的调查，而不应在此戛然结束。

把握开发节奏

恶魔：“我们很长时间没有进行代码复审，所以这周会复审所有的代码。此外，我们也要做一个发布计划了，那就从星期二开始，用3周时间，做下一个发布计划。”

在许多不成功的项目中，基本上都是随意安排工作计划，没有任何的规律。那样的随机安排很难处理。你根本不知道明天将会发生什么，也不知道什么开始下一轮的全体“消防演习”。

但是敏捷项目会有一个节奏和循环，让开发更加轻松。例如约定30天之内不应发生需求变化，这样确保团队有一个良性的开发节奏。这有助于防止一次计划太多的工作和一些过大的需求变更。

我们先来看某个工作日的情况。你希望每天工作结束的时候，都能完成自己的工作，你手上没有遗留下任何重要的任务。当然，每天都能这样说不现实的。但你可以做到每天下班离开公司前运行测试，并提交一天完成的代码。如果已经很晚了，并且你只是尝试性地编写了一些代码，那么也许最好应该删掉这些代码，第二天从头开始。这个建议听起来十分极端，但如果你正在开发小块的任务，这种方式非常有助于你管理自己的时间：如果你工作的时候没有一个固定的最终期限，就应该好好想想了。

敏捷开发者可以从多方面得到反馈：用户、团队成员和测试代码。但时间本身就是一个非常重要的反馈。
你可能不知道完成所有的任务需要多少个迭代，但每个迭代必须是短期的、有限的，并且要完成具体的目标。
迭代的时间是固定的，但在一个具体的迭代中完成哪些功能是灵活的。相似地，你会为设计讨论会设定时间期限，会议结束必须要做出最终的设计决策。
当你遇到艰难抉择的时候，固定的时间期限会促使你做决定。你不能在讨论或功能上浪费很多时间，这些时间可以用于具体的工作。

站立会议最好每天在固定的时间和地点举行，比如上午9点左右。要养成这样的习惯，在那时就准备好一切参加站立会议。

最大的节拍就是迭代时间，一般是1～4周的时间。不管你的一个迭代是多长，都应该坚持——确保每个迭代周期的时间相同很重要。运行有规律的开发节奏，会更容易达到目标，并确保项目不停地前进。

天使：“解决任务，在事情变得一团糟之前。保持事件之间稳定重复的间隔，更容易解决常见的重复任务。”

切身感受

项目开发需要有一致和稳定的节奏。
编辑，运行测试，代码复审，一致的迭代，然后发布。
如果知道什么时候开始下一个节拍，跳舞就会更加容易。

平衡的艺术

在每天结束的时候，测试代码，提交代码，没有残留的代码。
不要搞得经常加班。
以固定、有规律的长度运行迭代。也许刚开始你要调整迭代的长度，找到团队最舒服可行的时间值，但之后就必须要坚持。
如果开发节奏过于密集，你会精疲力尽的。一般来说，当与其他团队合作时，你需要减慢开发节奏。
有规律的开发节奏会暴露很多问题，让你有更多鼓起勇气的借口。

敏捷工具箱

Wiki：Wiki是一个网站，是一种很好的支持协作的工具，因为团队中的每一个人都可以根据需要动态地新增和重新组织网页中的内容，实现知识共享。例如，局域网Wiki。
版本控制：项目开发中所有的产物——全部的源代码、文档、图标、构建脚本等，都需要放入版本控制系统中，由版本控制系统来统一管理。例如，微软的TFS和Github。
单元测试：用代码来检查代码，这是开发者获得反馈的主要来源。例如，微软的GTest。
持续集成：不管是在自己的本地机器上实现构建，还是为整个团队实现构建都是全自动化并可重复的。

原文地址：https://www.cnblogs.com/fr-ruiyang/p/11380364.html