The project environment includes the physical space and software tools used by the developers. This section includes a few environment tips to support iterative and agile development. Agile methods emphasize the importance of communication or feedback; many of these tips promote it.

Continuous Integration

Part of the XP practices, continuous integration (CI) is also useful in other IID methods [FF99]. CI is a refinement and more frequent version of the daily build and smoke test practice popularized at Microsoft. Cycles average 15 to 30 minutes on many Java technology projects. There are at least two open source CI tools: Anthill (www.urbancode.com), and CruiseControl (cruisecontrol.sourceforge.net).

CI is somewhat more than just a frequent build-and-test tool. The details and how it works are explained in Figure 11.9.

Figure 11.9. how continuous integration works


Why bother? If a team practices CI from day one, then the growing application is almost always in a steady state of being integrated and tested. The "drift" from stability is on an extremely small scale. On average, every 15 minutes only a few new components are added. If the build is broken by an addition, it is likely to be a minor infraction. Therefore, the system grows micro-incrementally 15 minutes by 15 minutes, 24/7. There is less need for major end-of-iteration integration across team members or subteams.

What happens if the compile or tests fail? The CI tool sends email to the submitters and chief programmer, and people are expected to react immediately. For example, reverting to a previous version of the components, until the new components are debugged.

What if it takes a very long time to run the tests? Apply the "smoke test" principle promoted by Microsoft: Choose an important set of unit and acceptance tests that can run within 15 or 30 minutes. Run the longer set less frequently, such as four times daily.

Project Wiki Webs

Most people are familiar with blogs or Weblogs, that allow one to easily write and publish to a Web page. The older and more robust version of this idea is Wiki Web technology, created by Ward Cunningham (one of the XP founders). XP has the value, "do the simplest thing that could possibly work." In that vein, Cunningham has called Wikis "the simplest online Web database that could possibly work."

Like blogs, Wiki Webs (or Wikis) allow people to edit Web pages using only their browser, but they go farther: They allow one to easily create new pages, and hyperlinks between Wiki pages, using only a browser and special WikiWords. Of course, these capabilities are available with myriad tools, but Wikis make the tasks especially simple and fast. Thus, Wikis are a popular tool on agile projects to capture project information, and as a simple knowledge management tool.

Wikis are usually implemented as one or more Perl scripts that you install on an HTTP server. There are many open source Wiki kits. A popular simple version is Usemod (www.usemod.com); a popular elaborate version is Twiki (www.twiki.org) it includes version control and various fancy features.

You can see how Wikis work and create your own Wiki pages at the original (fascinating) Wiki site: c2.com/cgi/wiki?WelcomeVistors. This site is also the place where the majority of online discussion took place during the mid- and late-1990s on the creation of XP and other agile methods, by their founders. These discussions are still available as Wiki pages.

CASE Tools and Reverse-Engineering

UML-oriented CASE tools support both forward-engineering (generation of code from diagrams), and reverse-engineering (generation of diagrams from code). If an agile-oriented project uses a CASE tool at all, it is most often simply for the reverse-engineering feature, to support visualization and the more visually-oriented on the team. For example, regeneration of noteworthy (package, class, or sequence) UML diagrams every few days to visualize the growing code base created with a popular IDE such as Eclipse (www.eclipse.org).

When I coach a team through an iteration, we print reverse-engineered UML diagrams zoomed very large on a plotter (if one is available), and stick them on walls. Some developers use the plots during discussions or short design sessions, sketching on them.

It is a misunderstanding to think that agile methods oppose UML diagrams or visual sketching. First, it is only XP that is especially textual-source-code-centric; the other methods are silent on the subject. Second, the XP leaders are not at all opposed to the practices of Agile Modeling, or using a tool to reverse-engineer code to diagrams if the effort is simple and aids communication.

Consider a Plotter

Visualization of information on the walls is promoted in agile methods; large diagrams and font size are important for ease of viewing. Printing large zoomed documents on a laser printer is laborious, as the partial pages have to be puzzle-pieced together. A wide plotter is faster and easier.

Caves and Common Room

The agile methods promote development in a common room rather than separate offices, to increase communication (Figure 11.10). It is a required practice in Scrum and XP. Of course, people also have need for privacy. Ken Auer promotes the "caves and common room" model in which there are also separate private office spaces (floating or dedicated) that developers can use during non-development activities [AM02].

Figure 11.10. agile project common room with walls exposed


Liberate the Walls

Walls are valuable, but not for desks, shelves, or tables. If development is done by teams in common project rooms (a required practice in XP and Scrum), move furniture away from the walls. Expose them to support the agile modeling practices of using many whiteboard spaces, and displaying as much project information (tasks, risk list, vision, and so forth) on the walls as possible. Figure 11.11.

Figure 11.11. floor layout


Cling Sheets or Whiteboard Paint

Agile modeling promotes the use of whiteboard space and freehand drawing for creative modeling work. In addition to true whiteboards (which may not be available), consider using "cling sheets" or "static cling sheets." These can be purchased at most office supply stores and come in packages like flip-chart paper. They are made of a very thin white flexible plastic material that has a static charge; the sheets cling to most surfaces. Wallpaper them to create a giant whiteboard space. Most important, you can use a whiteboard marker to write and erase on them, as with any whiteboard.

Another alternative is the use of "whiteboard" paint.

Digital Cameras

Agile is about fast, simple, light. Capture hand-sketched whiteboard models or lists with a digital camera. Print, plot, or consider placing the results on a project Wiki.

Figure 11.12. sample room elements


Agile and Iterative Development (Agile Software Development Serie. A Manager's Guide2003)
Agile and Iterative Development (Agile Software Development Serie. A Manager's Guide2003)
Year: 2004
Pages: 156

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net