敏捷初哥忏悔录

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

我参加的队伍由8名专业人士组成,出乎我意料的是我们中有6个之前根本没有任何采用敏捷完成工作的经验。这样,我们在其中2名有经验的同伴指导下开 始工作了。一开始,让人高兴的事情并不多,大部分的事情都让人感到沮丧。我们认识到,敏捷并不只是冲刺(Sprint)和没有文档 – 有不少细微之处你得花功夫学才行。

这里说明一下曾经发生过的事情:

开始的麻烦

  1. 思维转变

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

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

  1. 持续换档

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

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

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

缓慢地冲刺

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

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

  1. 在敏捷里,以抽象术语进行思考是开发人员必须具备的技能。在敏捷中我们并不像瀑布模型那样进行预先设计,通过创建抽象和开发工作流,设计到了一定的时候自然就会现身。敏捷中的开发人员必须至少精通基本的设计模式,否则他们将产生一大堆垃圾代码,从中只能得出拙劣的设计。TDD在这里对我们大有帮助。它要求我们按抽象术语进行思考。此外,只要我们开始修改测试,我们就必须考虑进行重构,让我们的代码变得更 好。DDT也能帮助我们立即识别任何质量问题,这样它们就能及时地得到修复。这样,我们最终认识到必须抛弃“首先编代码,然后写测试”的套路,后来我们重 新开始采用了TDD方法。
  1. 代码质量是团队的职责,团队成员将时不时的重构代码或者可能会重新编写,直到它符合预先制订的标准。我们不要把任何情绪跟我们的代码关联 起来,应该准备不断地抛弃或重写它。遵循Venkat Subramaniam在集体所有制实践方面的建议:“每次执行检入代码操作时,我们都应该致力于改善代码的质量。”
  1. 在瀑布模型里,需求是要签字的,有点像血誓,然后你再继续向前移动。但在敏捷里,需求与解决方案同步演变。这帮助我们在前进的过程中让事 情变得越来越清晰,但这也导致系统需要不时的重新设计,在最初的冲刺(1-4)里,这种情况经常会发生。此外,Backlog也能在冲刺的中间改变,因 此,团队应该根据这些变化进行调整,因为在每个冲刺结束时交付可工作的软件是敏捷的座右铭。
  1. 结对一开始让人觉得是浪费时间和精力。两人一起在同一故事上进行工作就像是各浪费了一半的时间和精力。而且,多人完成同一故事的不同任务似乎是导致速度下降的原因。但是,敏捷中的团队钟情于这种合作做事的方式,不喜欢相同项目组或房间里的人单枪匹马地干活。当团队一起工作时,他们会竭尽所能地把事情向前推进,结果你有极大的可能性是以一致的方式完成事情,而不是最终在多个战线失利。
  1. 在采用TDD时,结对的效果最好。Driver和Navigator一起努力开发更好的系统。但如果你是按照DDT的方式进行结对编程, 那它就不是最佳的前进之路。在这种情况下,两个合作者都不会知道该如何前进,例如系统设计应该像什么样子,这样你将得到很多噪音,产生最终必须重写的一堆 源代码文件。遵循TDD是最佳的方式,但要是你还没有适应它,你仍然可以结对:利用一块玻璃(白)板,首先画出某个设计流程图,然后其中一个合作者可以编写代码,而另一个则可以编写测试用例。
  1. 在演示时交付可工作的软件就像是冲刺的“石蕊测试”。但是,要是软件不是可发布的,你会不会仅仅因为软件可以构建、可工作,而认为一个冲刺就成功了呢?当个别故事全部完工而某些没有,这样的冲刺算不算成功呢?那假如冲刺的全部故事基本完成但还有些烦人的小问题呢?

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

  1. 站立式会议是铁律。它们意味着成为一个共享平台,不只是你个人的有机会告诉其他人你做过什么和接下来要做什么。人们应该试图去倾听周遭发生的事情,而不只是检查自己的检查表看完成了哪些活动。庄严的站立式会议也必须控制在一定时间之内。我们常常会抑制不住开始就某个问题进行讨论的诱惑,但那是必须要避免的。
  1. 敏捷团队相当小,在这样一个环境里,人们经常会因为他们在站立式会议上的言论而被他人评判。那么,你就应该说我们在彼此进行脑力激荡或者我昨天什么也没做,再或者是我们重构了代码,而现在我搞不清楚怎么回事了之类的事情吗?这些都只会给新人造成一种尴尬的局面。
  1. 计划会议肯定是费脑子和让人精疲力竭的活儿。坐在椅子里4个钟头确定故事点数就像是在玩轮盘赌。这些数字将决定包含在冲刺里的内容,但是怎样在你根本没有经验的时候决定数字呢?你一定会估计错误。但这些数字注定就是可能会出错的大致数字,这并不意味着你纯粹是靠运气来开始玩轮盘赌。这些数字在未来的几个冲刺之后将给予你某种指示,告诉你能够完成的工作量。
  1. 分配故事点数是一个复杂的任务,应该按阶段完成。团队内部应该首先分析故事,并与产品负责人进行讨论以清晰地了解需求。在得到清晰的视图 之后,就要进行广泛的技术讨论,考虑可以实现的最佳可能解决方案。这步要是完成不好,将导致在故事应该如何实现方面模棱两可,进而导致有缺陷的估计。假 设,如果某个故事接触到了一个新的未探索领域,那么它应该会相当复杂,即便它是一个简单的任务。即使在已知领域,技术解决方案的不同也会导致故事相当复 杂。简单干脆的故事最容易被估算,即清楚地知道需求是什么,再加上点应该如何实现的细节。产品负责人无法提供这么干脆的故事。它们只能通过跟团队一起讨论得出来。因此,团队必须花点时间来为下一个冲刺进行调整。
  1. 回顾就像是在投票时间被赐予的演讲。我们应该已经完成这个或那个,在下一个冲刺里我们可以完成这个或那个,但是要是这个冲刺里没有接受某 些活儿,什么都不会发生。人们可以表达出对于不同方面的满意与否,但是团队应该着眼于从回顾的观点里得到某些具体任务,否则境况将永远保持下去。

在扎进敏捷之前,你可以做点准备工作:

  1. 熟悉市面上的技术,尤其是像JUnit、Fitnesse、EasyMock这样的测试工具。此外,人们应该不断地为更好的解决方案而奋斗,因此出去找找改进流程的新工具和新方法,寻找解决反复出现的问题的新框架或新设计思想和模式。
  1. Venkat Subramaniam和Andy Hunt的“高效程序员的45个习惯:敏捷开发修炼之道”是每位涉足敏捷的开发者的必读书籍。
  1. 读读Robert C Martin在objectmentor.com上的“Craftsman series”和“Clean Code” 。一开始,你可以不用急着去读它们,但在你碰到一堆麻烦的时候,你就会知道什么时候该去读了。
  1. 在站立式会议/计划/讨论,人们评估你建议的时候中保持一颗开放的心。说出你的观点,或者必要的时候要求帮助,你是这个项目的受益人。
  1. 测试不仅仅是为了代码覆盖率或质量度量。它们还提供了某种类型的持续保持更新的文档。人们可以先看看测试代码,然后就知道该如何使用这段代码了。
  1. 在项目开始就自动化构建过程的所有事情。如果像Checkstyle这样的小事都遗漏了,那么它的结果跟其他模型里的一样,说得多做得少。当你意识到这一点,求助于某种补救手段时,时间往往都太晚了。

学会说A到Z,然后再让你忘记,重新学Z到A往往不会太容易。这会带来些痛苦,但完成转变之后,你就会知道这样做是值得的。

话就说这么多,同志们,上路吧!!:)

查看英文原文:Confessions of A New Agile Developer

This entry was posted in Agile. Bookmark the permalink.

发表评论

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / 更改 )

Twitter picture

You are commenting using your Twitter account. Log Out / 更改 )

Facebook photo

You are commenting using your Facebook account. Log Out / 更改 )

Google+ photo

You are commenting using your Google+ account. Log Out / 更改 )

Connecting to %s