Slashdot Mirror

I like this definition better: http://www.agilemodeling.com/essays/barelyGoodEnough.html

In the agile world, the best teams are supposed to be made up of "generalizing specialists." These are folks who have one or more specializations, but who also have a working knowledge of many systems / technologies / business domains.

For instance, not everyone on the team might design a database as well as Joe, the database savvy guy, but everyone on the team has a working knowledge of databases and could design one. Not everyone on the team might be able to easily write our deployment/automation scripts, but everyone on the team is familiar with how these work and could modify them. Not everyone knows exactly how our server clusters are configured, but everyone knows enough to safely work with the servers.

Scott Ambler has a good article about "generalizing specialists" here: http://www.agilemodeling.com/essays/generalizingSp ecialists.htm

To begin with, it might sound like it doesn't leave you with much job security if everyone knows a good bit about everything, so you could lose any member of the team and the project would survive. That's potentially good for the project as "Joe could get hit by a bus," but it's also not true, when it comes to job security. Those who learn the business model and the ins-and-outs of our system become huge assets to the team, and to the company. We would be far more likely to lay off someone who isn't willing to learn new things. What's the point of someone like that?

Take a look at one of the Agile Poster Children and his proof that it works.

Quote: "Because of the newness of agile methods there simply hasn't been sufficient time to prove that they work in a wide variety of situations."

Thats a wonderful way to dismiss anyone saying bad things, and it's rubbish, because the burden of proof for any claim is independent of its age.

Quote: "the question "where is the proof" is typically asked by organizations that fit the late majority or even laggard profiles ... Because agile techniques clearly aren't at that stage in their lifecycle yet I believe that this question simply isn't a fair one at this time."

So the act of asking for proof these things work means you're not ready? Ad hominem alert.

Quote: "Are they really interested in finding an effective process or are [they] merely looking for a reason to disparage an approach that they aren't comfortable with? Are they realistic enough to recognize that no software process is perfect, that there is no silver bullet to be found? Are they really interested in proof that something works, or simply an assurance of perceived safety?"

Ad hominem again.

Then you look at the project that started Agile, the Chrysler Comprehensive Compensation (C3) project. It was lauded as the first agile program and a success, however by February 2000 with the system was failing when paying 76,000 of the company's 86,000 employees. It was cancelled. Apparently this failure is now the new success.

Every methodology has rapid followers who will hear not evil said of it, but when looking at these things you have to remember "He's NOT the Messiah ... he's just a very naughty boy."

I don't have a problem with most of these development methodologies perse, but most of them seem to lack the entire concept of DATA and INFORMATION.

You should check out things like Agile Modelling and Agile Data for more information. I don't think it's core to agile methods, as not every application uses a database. But if you're big into databases, these sites can help you see how agile approaches could work in your environment.

Do these methodologies include some prep work on gathering business requirements and understanding the underlying information relationships?

It's not just prep work; it is work that should happen all the time. That's why Refactoring and Domain-Driven Design are such a big deal to people doing Extreme Programming. We strive for representational harmony across all levels, from talking with users down to the database schema. And not just in the spec, either; as we learn more about the domain and find better representations, refactoring lets us safely change the structure of the code to match.

-Taken from this essay on agile documentation

I agree with the above, but it is my experience that the reinforcement on developers generally needs to be in creating more documentation. The environment will naturally make all the difference. In the nasty corporate arena (my habitat), many people feel that being the only one who knows something, is their ticket to job security. As a result, they will not comment code or divulge information to anyone, etc. Unfortunately, management encourages these insecure people through among other things, a lack of employee loyalty and an eagerness to cut costs by giving valuable and veteran employees the axe, among other nasty things. Thats my take anyway.

Bed goes up. Bed goes down. - Homer Simpson

UML lets you use an Activity Diagram for this as well. Typically activity diagrams are used to document a business process. Activity diagrams explicitly include synchronization and timing information. Sometime that's better than using a DFD as you know that a particular action must complete before its successor starts. Sometimes, it's worse because you may represent synchronization in the model that is simply an artifact of the current process. For example, I worked on cell phone point of sale system that would not let the sales rep take money until the phone activation was completed. This syncrhonization point was't really required for the business process (and actually caused lost sales when the activation system was slow or down), but had crept in through an activity diagram that listed activation as a pre-requisite for billing.

Activity diagrams are actually part of the UML replacement for flowcharts. State diagrams and sequence diagrams (plus, to a lesser extent collaboration diagrams (which are sort of a translation of sequence diagrams mapping objects spatially and time through notation) nostly complete the picture of UML things that replace flowcharts.

There is no straight analogy in OO for a flow chart or DFD. But activity diagrams (here, here, and here) serve a similar function. They provide a high level of abstraction that can be done with a picture.

One poster said to use a "high level language". I agree, at least with the first two words. I mildly disagree at the word "language". Some people think better in words, others think better in pictures.

What's important is that you don't try write your detailed code using pictures. People who map one set of things to a picture will map a different set of things to a language. So it is difficult to draw pictures that then create exactly the code (language) desired.

Keep the pictures (activity diagrams) high level but leave the details for coding by hand.

Having said that, I shall now waffle: If you're very good at thinking in pictures, UML does provide some detailed diagrams for run-time aspects of software.

• State Diagrams (here and here)
• Sequence Diagrams (here and here)
• and
• Collaboration Diagrams (here and here)

Drew

Unlike this guy, you aren't likely to survive going over a waterfall these days. A more recent discussion of the cost of change and a further examination by Alistair Cockburn might be better than reviewing Boehm again.

Every artifact that you create, and then decide to keep, will need to be maintained over time. [...] Every time you decide to keep a model you trade-off agility for the convenience of having that information available to your team in an abstract manner (hence potentially enhancing communication within your team as well as with project stakeholders). Never underestimate the seriousness of this trade-off. [...] a development team that decides to develop and maintain a detailed requirements document, a detailed collection of analysis models, a detailed collection of architectural models, and a detailed collection of design models will quickly discover they are spending the majority of their time updating documents instead of writing source code.

Every artifact that you create, and then decide to keep, will need to be maintained over time. [...] Every time you decide to keep a model you trade-off agility for the convenience of having that information available to your team in an abstract manner (hence potentially enhancing communication within your team as well as with project stakeholders). Never underestimate the seriousness of this trade-off. [...] a development team that decides to develop and maintain a detailed requirements document, a detailed collection of analysis models, a detailed collection of architectural models, and a detailed collection of design models will quickly discover they are spending the majority of their time updating documents instead of writing source code.