敏捷初哥忏悔录
作者 Rahul Sharma 译者 胡键 发布于 2010年11月12日 上午12时0分
@H_404_26@在职业生涯的大部分时间里,我都是按照瀑布模型的方式进行工作。不久之后,我加入了Xebia,开始以敏捷的方式做活。特别是,我 们一直把遵循Scrum和XP方法论与TDD相结合作为重点强调的实践。从瀑布模型到敏捷的转变,就像从宇宙中的一颗行星突然跨到另一颗一样巨大。一旦完 成这种转变,你的世界将发生翻天覆地的变化,你的思维、工作或协作方式等等,所有一切都会改变。相关厂商 内容
开始的麻烦
-
思维转变
-
持续换档
缓慢地冲刺
- 测试驱动开发说的是先写测试,然后由测试导出业务逻辑。这是最难适应的事情之一,因为它完全颠覆了你的观念。 @H_404_26@在瀑布模型里,总是代码先完成,然后再进行些测试(通常都有,但并非总是有);但TDD则完全是红、绿和重构。这种方法要求我们用抽象术语 进行思考,然后由它们演变出具体的事物。由于一开始难以适应,我们往往求助于先写出逻辑,然后确保存在覆盖它们的测试。我把这称为开发驱动测试(DDT) 方法。 @H_404_26@DDT并没有增加太多的意义。假如你知道你的代码将会很好地工作,那为何还要写个测试呢?只是要证明这段代码确实有效?应该不止这一点。的确是这样。例如,写测试可以让你的代码在耦合性方面表现更好,而且还能够为将来的代码变更提供一个巨大的安全网。
- 在敏捷里,以抽象术语进行思考是开发人员必须具备的技能。在敏捷中我们并不像瀑布模型那样进行预先设计,通过创建抽象和开发工作流,设计到了一定的时候自然就会现身。敏捷中的开发人员必须至少精通基本的设计模式,否则他们将产生一大堆垃圾代码,从中只能得出拙劣的设计。 @H_404_26@TDD在这里对我们大有帮助。它要求我们按抽象术语进行思考。此外,只要我们开始修改测试,我们就必须考虑进行重构,让我们的代码变得更 好。DDT也能帮助我们立即识别任何质量问题,这样它们就能及时地得到修复。这样,我们最终认识到必须抛弃“首先编代码,然后写测试”的套路,后来我们重 新开始采用了TDD方法。
- 代码质量是团队的职责,团队成员将时不时的重构代码或者可能会重新编写,直到它符合预先制订的标准。我们不要把任何情绪跟我们的代码关联 起来,应该准备不断地抛弃或重写它。遵循Venkat Subramaniam在集体所有制实践方面的建议:“每次执行检入代码操作时,我们都应该致力于改善代码的质量。”
- 在瀑布模型里,需求是要签字的,有点像血誓,然后你再继续向前移动。但在敏捷里,需求与解决方案同步演变。这帮助我们在前进的过程中让事 情变得越来越清晰,但这也导致系统需要不时的重新设计,在最初的冲刺(1-4)里,这种情况经常会发生。此外,Backlog也能在冲刺的中间改变,因 此,团队应该根据这些变化进行调整,因为在每个冲刺结束时交付可工作的软件是敏捷的座右铭。
- 结对一开始让人觉得是浪费时间和精力。两人一起在同一故事上进行工作就像是各浪费了一半的时间和精力。而且,多人完成同一故事的不同任务似乎是导致速度下降的原因。 @H_404_26@但是,敏捷中的团队钟情于这种合作做事的方式,不喜欢相同项目组或房间里的人单枪匹马地干活。当团队一起工作时,他们会竭尽所能地把事情向前推进,结果你有极大的可能性是以一致的方式完成事情,而不是最终在多个战线失利。
- 在采用TDD时,结对的效果最好。Driver和Navigator一起努力开发更好的系统。但如果你是按照DDT的方式进行结对编程, 那它就不是最佳的前进之路。在这种情况下,两个合作者都不会知道该如何前进,例如系统设计应该像什么样子,这样你将得到很多噪音,产生最终必须重写的一堆 源代码文件。 @H_404_26@遵循TDD是最佳的方式,但要是你还没有适应它,你仍然可以结对:利用一块玻璃(白)板,首先画出某个设计流程图,然后其中一个合作者可以编写代码,而另一个则可以编写测试用例。
- 在演示时交付可工作的软件就像是冲刺的“石蕊测试”。但是,要是软件不是可发布的,你会不会仅仅因为软件可以构建、可工作,而认为一个冲刺就成功了呢? @H_404_26@当个别故事全部完工而某些没有,这样的冲刺算不算成功呢?那假如冲刺的全部故事基本完成但还有些烦人的小问题呢? @H_404_26@团队应该关注让整个故事完工,所有问题得到解决,并且满足完工标准;而不是慌慌张张地盯着Backlog马虎了事。一次实施蹩脚的冲刺没有 任何意义,除了在继续前进之前必须将已完成的事情返工。时间常常是一个约束条件,因此根据故事的相对重要程度,团队应该找出一种对他们提议的解决方案更具 质量意义的实施方法。位于Backlog顶端的故事必须尽量以最好的方式开发解决,随着我们逐渐移动到Backlog的底部,对解决方案的质量可能会有些 妥协,但并不是对完工标准而言。对于故事的实现,更好的方式是宁缺勿滥。
- 站立式会议是铁律。它们意味着成为一个共享平台,不只是你个人的有机会告诉其他人你做过什么和接下来要做什么。人们应该试图去倾听周遭发生的事情,而不只是检查自己的检查表看完成了哪些活动。 @H_404_26@庄严的站立式会议也必须控制在一定时间之内。我们常常会抑制不住开始就某个问题进行讨论的诱惑,但那是必须要避免的。
- 敏捷团队相当小,在这样一个环境里,人们经常会因为他们在站立式会议上的言论而被他人评判。那么,你就应该说我们在彼此进行脑力激荡或者我昨天什么也没做,再或者是我们重构了代码,而现在我搞不清楚怎么回事了之类的事情吗?这些都只会给新人造成一种尴尬的局面。
- 计划会议肯定是费脑子和让人精疲力竭的活儿。坐在椅子里4个钟头确定故事点数就像是在玩轮盘赌。这些数字将决定包含在冲刺里的内容,但是怎样在你根本没有经验的时候决定数字呢?你一定会估计错误。 @H_404_26@但这些数字注定就是可能会出错的大致数字,这并不意味着你纯粹是靠运气来开始玩轮盘赌。这些数字在未来的几个冲刺之后将给予你某种指示,告诉你能够完成的工作量。
- 分配故事点数是一个复杂的任务,应该按阶段完成。团队内部应该首先分析故事,并与产品负责人进行讨论以清晰地了解需求。在得到清晰的视图 之后,就要进行广泛的技术讨论,考虑可以实现的最佳可能解决方案。这步要是完成不好,将导致在故事应该如何实现方面模棱两可,进而导致有缺陷的估计。假 设,如果某个故事接触到了一个新的未探索领域,那么它应该会相当复杂,即便它是一个简单的任务。即使在已知领域,技术解决方案的不同也会导致故事相当复 杂。 @H_404_26@简单干脆的故事最容易被估算,即清楚地知道需求是什么,再加上点应该如何实现的细节。产品负责人无法提供这么干脆的故事。它们只能通过跟团队一起讨论得出来。因此,团队必须花点时间来为下一个冲刺进行调整。
- 回顾就像是在投票时间被赐予的演讲。我们应该已经完成这个或那个,在下一个冲刺里我们可以完成这个或那个,但是要是这个冲刺里没有接受某 些活儿,什么都不会发生。人们可以表达出对于不同方面的满意与否,但是团队应该着眼于从回顾的观点里得到某些具体任务,否则境况将永远保持下去。
- 熟悉市面上的技术,尤其是像JUnit、Fitnesse、EasyMock这样的测试工具。此外,人们应该不断地为更好的解决方案而奋斗,因此出去找找改进流程的新工具和新方法,寻找解决反复出现的问题的新框架或新设计思想和模式。
- Venkat Subramaniam和Andy Hunt的“高效程序员的45个习惯:敏捷开发修炼之道”是每位涉足敏捷的开发者的必读书籍。
- 读读Robert C Martin在objectmentor.com上的“Craftsman series”和“Clean Code” 。一开始,你可以不用急着去读它们,但在你碰到一堆麻烦的时候,你就会知道什么时候该去读了。
- 在站立式会议/计划/讨论,人们评估你建议的时候中保持一颗开放的心。说出你的观点,或者必要的时候要求帮助,你是这个项目的受益人。
- 在项目开始就自动化构建过程的所有事情。如果像Checkstyle这样的小事都遗漏了,那么它的结果跟其他模型里的一样,说得多做得少。当你意识到这一点,求助于某种补救手段时,时间往往都太晚了。
@H_404_26@给InfoQ中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com 。也欢迎大家加入到InfoQ中文站用户讨论组 中与我们的编辑和其他读者朋友交流。