敏捷初哥忏悔录

本文主要是介绍敏捷初哥忏悔录，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

敏捷初哥忏悔录

作者 Rahul Sharma 译者胡键发布于 2010年11月12日上午12时0分

社区

敏捷

主题

敏捷实施

标签

案例研究

在职业生涯的大部分时间里，我都是按照瀑布模型的方式进行工作。不久之后，我加入了Xebia，开始以敏捷的方式做活。特别是，我们一直把遵循Scrum和XP方法论与TDD相结合作为重点强调的实践。从瀑布模型到敏捷的转变，就像从宇宙中的一颗行星突然跨到另一颗一样巨大。一旦完成这种转变，你的世界将发生翻天覆地的变化，你的思维、工作或协作方式等等，所有一切都会改变。

开始的麻烦

思维转变

敏捷讲的全是当下的考量、当前的冲刺、当前的用户故事等。当一路走来突然有其他某个故事出现在面前的时候，我们并不会事先考虑事情将如何发展。过去在瀑布模型里，我们常常是首先考虑整个系统，HLD（高层设计）和LLD（低层设计）是第一步，在继续前进之前，它们必须冻结。

相反，敏捷的内容完全是当前状态和不断改变，要是我们的需求未来会变化，我们的设计也将随之演变；但是我们对于超越当前冲刺的事情并不是特别关注。要接受这一事实得花点时间。

持续换档

敏捷是一个不断变化的环境。“响应变化”是其主导原则之一。为了响应，开发者必须跟市面上的技术保持同步，否则它将让你异常痛苦。

我们曾在项目中使用了一种搜索引擎库，但我们中只有一人对其有了解。由于这个缺陷，我们在估时、结对、站立式会议，以及其他日常实践里都遇到了问题。

我们面对的另一个问题是恰当地进行TDD。从技术观点看，TDD已经有了不少选择。你可以依赖不同的模拟和测试框架，这些往往都是你在瀑布模型里不使用的东西。要是你想采用TDD，那么就必须具备对它们的丰富知识，否则整个过程就不会太顺利。

缓慢地冲刺

测试驱动开发说的是先写测试，然后由测试导出业务逻辑。这是最难适应的事情之一，因为它完全颠覆了你的观念。
在瀑布模型里，总是代码先完成，然后再进行些测试（通常都有，但并非总是有）；但TDD则完全是红、绿和重构。这种方法要求我们用抽象术语进行思考，然后由它们演变出具体的事物。由于一开始难以适应，我们往往求助于先写出逻辑，然后确保存在覆盖它们的测试。我把这称为开发驱动测试（DDT）方法。

DDT并没有增加太多的意义。假如你知道你的代码将会很好地工作，那为何还要写个测试呢？只是要证明这段代码确实有效？应该不止这一点。的确是这样。例如，写测试可以让你的代码在耦合性方面表现更好，而且还能够为将来的代码变更提供一个巨大的安全网。

在敏捷里，以抽象术语进行思考是开发人员必须具备的技能。在敏捷中我们并不像瀑布模型那样进行预先设计，通过创建抽象和开发工作流，设计到了一定的时候自然就会现身。敏捷中的开发人员必须至少精通基本的设计模式，否则他们将产生一大堆垃圾代码，从中只能得出拙劣的设计。
TDD在这里对我们大有帮助。它要求我们按抽象术语进行思考。此外，只要我们开始修改测试，我们就必须考虑进行重构，让我们的代码变得更好。DDT也能帮助我们立即识别任何质量问题，这样它们就能及时地得到修复。这样，我们最终认识到必须抛弃“首先编代码，然后写测试”的套路，后来我们重新开始采用了TDD方法。

代码质量是团队的职责，团队成员将时不时的重构代码或者可能会重新编写，直到它符合预先制订的标准。我们不要把任何情绪跟我们的代码关联起来，应该准备不断地抛弃或重写它。遵循Venkat Subramaniam在集体所有制实践方面的建议：“每次执行检入代码操作时，我们都应该致力于改善代码的质量。”

在瀑布模型里，需求是要签字的，有点像血誓，然后你再继续向前移动。但在敏捷里，需求与解决方案同步演变。这帮助我们在前进的过程中让事情变得越来越清晰，但这也导致系统需要不时的重新设计，在最初的冲刺（1-4）里，这种情况经常会发生。此外，Backlog也能在冲刺的中间改变，因此，团队应该根据这些变化进行调整，因为在每个冲刺结束时交付可工作的软件是敏捷的座右铭。

结对一开始让人觉得是浪费时间和精力。两人一起在同一故事上进行工作就像是各浪费了一半的时间和精力。而且，多人完成同一故事的不同任务似乎是导致速度下降的原因。
但是，敏捷中的团队钟情于这种合作做事的方式，不喜欢相同项目组或房间里的人单枪匹马地干活。当团队一起工作时，他们会竭尽所能地把事情向前推进，结果你有极大的可能性是以一致的方式完成事情，而不是最终在多个战线失利。

在采用TDD时，结对的效果最好。Driver和Navigator一起努力开发更好的系统。但如果你是按照DDT的方式进行结对编程，那它就不是最佳的前进之路。在这种情况下，两个合作者都不会知道该如何前进，例如系统设计应该像什么样子，这样你将得到很多噪音，产生最终必须重写的一堆源代码文件。
遵循TDD是最佳的方式，但要是你还没有适应它，你仍然可以结对：利用一块玻璃（白）板，首先画出某个设计流程图，然后其中一个合作者可以编写代码，而另一个则可以编写测试用例。

在演示时交付可工作的软件就像是冲刺的“石蕊测试”。但是，要是软件不是可发布的，你会不会仅仅因为软件可以构建、可工作，而认为一个冲刺就成功了呢？
当个别故事全部完工而某些没有，这样的冲刺算不算成功呢？那假如冲刺的全部故事基本完成但还有些烦人的小问题呢？

团队应该关注让整个故事完工，所有问题得到解决，并且满足完工标准；而不是慌慌张张地盯着Backlog马虎了事。一次实施蹩脚的冲刺没有任何意义，除了在继续前进之前必须将已完成的事情返工。时间常常是一个约束条件，因此根据故事的相对重要程度，团队应该找出一种对他们提议的解决方案更具质量意义的实施方法。位于Backlog顶端的故事必须尽量以最好的方式开发解决，随着我们逐渐移动到Backlog的底部，对解决方案的质量可能会有些妥协，但并不是对完工标准而言。对于故事的实现，更好的方式是宁缺勿滥。

站立式会议是铁律。它们意味着成为一个共享平台，不只是你个人的有机会告诉其他人你做过什么和接下来要做什么。人们应该试图去倾听周遭发生的事情，而不只是检查自己的检查表看完成了哪些活动。
庄严的站立式会议也必须控制在一定时间之内。我们常常会抑制不住开始就某个问题进行讨论的诱惑，但那是必须要避免的。

敏捷团队相当小，在这样一个环境里，人们经常会因为他们在站立式会议上的言论而被他人评判。那么，你就应该说我们在彼此进行脑力激荡或者我昨天什么也没做，再或者是我们重构了代码，而现在我搞不清楚怎么回事了之类的事情吗？这些都只会给新人造成一种尴尬的局面。

计划会议肯定是费脑子和让人精疲力竭的活儿。坐在椅子里4个钟头确定故事点数就像是在玩轮盘赌。这些数字将决定包含在冲刺里的内容，但是怎样在你根本没有经验的时候决定数字呢？你一定会估计错误。
但这些数字注定就是可能会出错的大致数字，这并不意味着你纯粹是靠运气来开始玩轮盘赌。这些数字在未来的几个冲刺之后将给予你某种指示，告诉你能够完成的工作量。

分配故事点数是一个复杂的任务，应该按阶段完成。团队内部应该首先分析故事，并与产品负责人进行讨论以清晰地了解需求。在得到清晰的视图之后，就要进行广泛的技术讨论，考虑可以实现的最佳可能解决方案。这步要是完成不好，将导致在故事应该如何实现方面模棱两可，进而导致有缺陷的估计。假设，如果某个故事接触到了一个新的未探索领域，那么它应该会相当复杂，即便它是一个简单的任务。即使在已知领域，技术解决方案的不同也会导致故事相当复杂。
简单干脆的故事最容易被估算，即清楚地知道需求是什么，再加上点应该如何实现的细节。产品负责人无法提供这么干脆的故事。它们只能通过跟团队一起讨论得出来。因此，团队必须花点时间来为下一个冲刺进行调整。