image
Craig Larman
中文站  English
           img            敏捷迭代开发            UML和模式应用

技术随笔


敏捷迭代开发



最近这段时间,我的精力主要花在帮助一些在较大项目上(50人、250人 ...)采用了迭代方法的客户上。现在有关“敏捷方法”实践的一个最大误解是,很多人认为它们是新发明,或者只能用在小项目上。形成这种误解的部分原因是因为人们不知道敏捷的许多关键做法(避免瀑布式而采用短迭代、演进式的开发,自动化的每日构建与测试、集成,风险驱动的迭代式计划等等)已经被业内人士所掌握和运用几十年了。您知道美国航天飞机的飞行控制软件项目(绝非一个小项目!)在上世纪 1970 年代中期就采用了这些敏捷实践吗?您知道加拿大全国的新型空中交通管制系统采用的就是迭代式开发,而非瀑布式吗?还有,您知道美国的下一代弹道导弹空间防御系统也在采用敏捷过程实践进行开发吗?当然,还有那些大型的操作系统项目,如微软 Windows 和 Linux。这些都是巨大的、包含多团队、多场站的系统工程项目。如果您希望了解更多的有关自上世纪 1960 年代以来迭代式开发的史例,我推荐您阅读 2003 年 6 月 Vic Basili 博士与我合作发表在 IEEE Computer 上的文章《迭代与递增式开发简史》以及本人拙作《敏捷与迭代式开发:管理者指南》中的“证据”一章。

当人们问我“我们在大项目上应该采用迭代式开发,还是坚持沿用瀑布式?”,我总是感到很讶异。科学研究表明瀑布做法与更多的风险、失败、缺陷和低生产率有关,而且大型系统构件的延后集成和测试是一个众所周知的重大风险,因此项目愈大,采取短小的、尽早集成的迭代步骤,从用户、测试等那里获得反馈就愈为重要。不过,依鄙人之陋见(IMO),请不要相信不成熟的 XP 架构观点,即认为我们可以放弃对早期细致的架构设计的关注。相反的,对于大型项目,早期迭代聚焦于架构要素(通过编程和测试进行验证!),以及通过组织有效协作的核心架构设计会议(让程序员和架构师都参加),花上足够的时间对架构进行建模、思考、交流和编写(恐怖!),这些都是非常重要的。当然,还要结合尽早编程和测试,对实际情况进行检验。我看到过一些大项目,明显受到了 XP 避免预先设计建议的影响,因此而失败了;这可是一个业余错误。大系统需要尽早获得坚固的架构!然而,这并不意味着我们必须要用瀑布式,诸如 FDD、UP 这样的方法推荐一种平衡的方式,把某些预先设计与早期的编程迭代结合起来,以便提供和检验设计创意。在我的著作《UML 和模式应用:OOA/D 与迭代式开发导论》中,我向大家展现了一个 3 次迭代的案例,对建模和编程就采用了这种平衡的迭代方法。

另一个常见的敏捷误解是认为:敏捷 = XP。No,这是错的。事实上 XP 只是当代一打迭代演进式方法中的一种,其他方法还包括 DSDM、FDD、UP、Crystal 等等许多种。这些其他的敏捷方法与 XP 大有不同。当然我喜欢 XP,XP 之中充满了许多伟大的想法和做法,Kent Beck 和 Ward Cunningham 也相当聪明,然而请不要把 XP 与敏捷或迭代简单地划上等号,后者是一个更为广阔的领域。举例来说,与 XP 不同的是,DSDM、FDD、UP 等一些其他方法,都要求在早期迭代中尽早地关注一些与建模、架构核心有关的工作和开发。在这些方法中,在每次迭代开始编程之前花上几天时间开展小组需求、设计活动,既很正常,也符合预期。只有 XP 在这方面采取了比较“极端”的观点,几乎避免任何在编程之前进行的分析或设计活动。请不要把孩子同洗澡水一起抛掉,尤其对于那些大项目 —— 有一些小组协作的设计建模(敏捷建模)技术还是相当有效的!

Martin Fowler 提到的 Continuous Integration 是一项非常有用的软件自动集成与测试技术。我敦促所有的开发团队务必做到持续集成。Java 项目要实现持续集成可以采用免费的 OSS 工具,比如 SourceForge 上的 CruiseControlAnthill

Larman 组织行为定律



Larman's Laws of Organizational Behavior

After decades of observation and organizational consulting, here are Larman's Laws of Organizational Behavior. These are observations rather than laws to follow ;)

1. Organizations are implicitly optimized to avoid changing the status quo middle- and first-level manager and “specialist” positions & power structures.

2. As a corollary to (1), any change initiative will be reduced to redefining or overloading the new terminology to mean basically the same as status quo.

3. As a corollary to (1), any change initiative will be derided as “purist”, “theoretical”, “revolutionary”, and “needing pragmatic customization for local concerns” -- which deflects from addressing weaknesses and manager/specialist status quo.

4. Culture follows structure.

i.e., if you want to really change culture, you have to start with changing structure, because culture does not really change otherwise. and that's why deep systems of thought such as organizational learning are not very sticky or impactful by themselves, and why systems such as scrum (that have a strong focus on structural change at the start) tend to more quickly impact culture. i discovered that john seddon also observed this: "Attempting to change an organization’s culture is a folly, it always fails. Peoples’ behavior (the culture) is a product of the system; when you change the system peoples’ behavior changes."

UML 建模



There's nothing inherently wrong with a UML CASE tool, and they have some excellent uses (especially for reverse-engineering code to diagrams, to help learning) but for almost 20 years I've encouraged developers to start visual OO modeling with lots (10, not 2) of whiteboards and marker pens (and now, digital cameras), and focus on just a little (e.g., a few hours every few weeks) lightweight exploratory sketching before programming--a key part of what is now called Agile Modeling. View the sketches as exploration, not documentation. It's a shame when developers blame the UML because of an unpleasant tool experience (fighting with fussy, low-ROI drawing in CASE tools in tiny computer windows). But if you try a "low-tech high-touch" approach to the UML, focusing on "UML as sketch" (Martin Fowler's term), working on giant whiteboard spaces and ignoring unimportant design and notation details, and use it with a partner to quickly sketch and explore some OO design alternatives for the hard, creative parts, then applying light UML can be a fun and useful creative experience. I shared this pratice in the 1st and 2nd editions of Applying UML and Pattens, but didn't emphasize it, and I suspect most readers didn't notice my point because all the UML drawings were drawn neatly with a tool (for legibility). So, in the 3rd edition, which I'm writing now, I'm adding a second case study, and showing all the UML for it as digital photos from whiteboard sketches, to promote more "UML as sketch" as useful.

Speaking of giant whiteboard spaces for Agile Modeling and "UML as sketch," another great solution that I first learned about when I was working at ObjectSpace in the 1990s is whiteboard-like static cling plastic sheets. These sheets cling to walls and glass and allow you to wallpaper a room, transforming it into one big whiteboard. Great stuff! In North America, the common product is Avery Write-On Cling Sheets. In Europe, it is Legamaster Magic-Chart. I like the Legamaster product better, as it comes in a roll, making it easy to roll out and cover the walls. One last tip: There is a good side and a bad side to this stuff; the good side erases more easily.

如果您打算采用 UML 工具(以取代大量的白板书写),我建议您挑选一个能与您最喜欢的强文本 IDE 集成的建模工具,而非单件孤立的,开发人员通常发现前者更为有效。

敏捷开发、敏捷建模现场



以下照片反映了以 UML 素描方式进行敏捷建模的实际开发环境。

Craig 尤其提倡在开发台桌的周围,布置大量可画可写的白板,而非那些容易妨碍人们充分投入创造性思考、交流和协作的软件工具。



好书推荐



Eric Evans 的 Domain-Driven Design 是我最喜欢的 OO 建模和设计新书之一。Eric 在创建 OO 领域层方面有着非常丰富的经验(Smalltalk 开发老手往往表现出极清晰的面向对象思维)。

提到模式好书,一如既往地,我向大家推荐 Martin Fowler 的 Patterns of Enterprise Application Architecture.

© since 2005 craiglarman.cn 保留部分权利。Craig Larman 委托 张恂 翻译编辑制作。沪 ICP 备 05023401 号