敏捷的方法论

敏捷的方法论

跟踪变化

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

你不须要一口气爬上10楼，而须要一直在攀登，因此最后看起来就像只要再上一二层。若是你对全部这些技术都一无所知，想要立刻登上这10楼，确定会让你喘不过气来。并且，这也会花很长时间，期间还会有更新的技术出现。

现今有不少方法和工具能够帮助咱们继续充电：

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

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

切身感觉

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

平衡的艺术

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

对团队投资

恶魔：“不要和别人分享你的知识——本身留着。你说由于这些知识而成为团队中的佼佼者，只要本身聪明就能够了，不用管其余失败者。”

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

在一个团队中，若是知识你我的技术很好还远远不够。若是其余团队成员的知识不够，团队也没法发挥其应有的做用：一个学习型的团队才是较好的团队。

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

找出你或团队中的高手擅长的领域，帮助其余的团队成员在这些方面迎头遇上（这样作还有一个好处是，能够讨论如何将这些东西应用于本身的项目中）。

“午饭会议”是在团队中分享知识很是好的方式。在一周之中挑选一天，事先计划午饭时汇集在一块儿，这样就不会担忧和其余会议冲突，也不须要特别的申请。为了下降成本，就让你们自带午饭。

每周，要求团队中的一我的主持讲座。他会给你们介绍一些概念，演示工具，或者作团队感兴趣的任何一件事情。你能够挑一本书，给你们说书哦其中一些特别内容、项目或者实践。不管什么主题均可以。

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

这些午饭会议很是有用。它促进了各镇团队对这个行业的了解，你本身也能够从其余人身上学到不少东西。优秀的管理者会重用那些能提升其余团队成员价值的人，所以这些活动也直接有助于你的职业生涯。

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

切身感觉

• 这样作，会让每一个人都以为本身愈来愈聪明。
• 整个团队都要了解新技术，并指出如何使用它，或者指出须要注意的缺陷。

平衡艺术

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

懂得丢弃

恶魔：“那就是你一向的工做方法，而且是有缘由的。这个方法也很好的为你所用。开始你就掌握了这个方法，很明显它是最好的方法。真的，从那之后就不要再改变了。”

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

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

这也不是说你真的要彻底丢弃它们。其实，根据具体状况还能够运用旧知识。

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

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

切身感觉

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

平衡的艺术

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

打破砂锅问到底

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

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

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

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

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

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

真的吗？为何呀？

为何呀？

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

切身感觉

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

平衡的艺术

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

把握开发节奏

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

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

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

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

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

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

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

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

切身感觉

• 项目开发须要有一致和稳定的节奏。
• 编辑，运行测试，代码复审，一致的迭代，而后发布。
• 若是知道何时开始下一个节拍，跳舞就会更加容易。

平衡的艺术

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

敏捷工具箱

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