Agile Software Development
Автор: Alistair Cockburn /
CHAPTER 1. A Cooperative Game of Invention and Communication Software and Games
-
Часть 3
-
Software and Engineering
Considering software development as a game with moves is profitable, because doing so gives us a way to make meaningful and advantageous decisions on a project. In contrast, speaking of software development as engineering or model building does not help us make such advantageous decisions.
The trouble with using engineering as a reference is that we, as a community, don't know what that means. Without having a common understanding of what engineering is, it is hard to get people to work "more like engineering. " In my travels, people mostly use the word "engineering" to create a sense of guilt for not having done enough of something, without being clear what that something is.
The dictionary is clear as to what "engineering" is: "The application of science and mathematics by which the properties of matter and the sources of energy in nature are made useful to man" (Webster's New Collegiate Dictionary, 1977).
That definition does not explain what doing engineering is about. In my experience, "doing engineering" involves creating a trade-off solution in the face of conflicting demands. Another person, though, wrote to me and said, "A basic concept of engineering is to address problems in a repeatable and consistent manner. "
This is a common mistake, confusing the act of doing engineering work with the outcome of doing engineering work.
The outcome of doing engineering work is the plant, which is run while specific people watch carefully for variations in quantity and quality of the items being manufactured.
The act of doing engineering work is the ill-defined creative process the industrial engineer goes through to invent the manufacturing plant design. That process is not run with statistical controls, measuring quantity and quality of output. Like software development, it runs as a cooperative game of invention and communication, with individual people of different backgrounds huddling together to come up with a workable design.
When people say, "Make software development more like engineering, " they often mean, "Make it more like running a plant, with statistical quality controls. " But as we have seen, running the plant is not the act of doing engineering.
The other aspect of "doing engineering" is looking up previous solutions in code books.
Civil engineers who design bridges are not supposed to invent new structures. Given a river and a predicted traffic load, they are supposed to take soil samples and use the code books to look for the simplest structure that handles the required load over the given distance, building on the soil at hand. They base their work on centuries of tabulation of known solutions.
This only marginally fits the current state of software development. We are still in the stage where each team's design is supposed to be better than the neighbor's, and the technologies are changing so fast that few code books exist. As time goes by, more of these code books will be available. Today, however, there are still more variations between systems than there are commonalities.
Let's return to considering "engineering" to mean "thinking and making trade-offs. " These are appropriate phrases. We would like our software developers to think, and to understand the trade-offs they select. However, these phrases do not provide guidance in running projects.
Software and Model-Building
Many people have advocated model building over the last decade, including Ivar Jacobson, who declared, "Software development is model building. "
Characterizing software development as engineering may not provide much guidance for running projects, but characterizing it as model building leads directly to inappropriate project decisions.
If software development were model building, then a valid measure of the quality of the software or of the development process would be the quality of the models, their fidelity to the real world, and their completeness. However, as dozens of successful project teams around the world have told me: "The interesting part of what we want to express doesn't get captured in those models. The interesting part is what we say to each other while drawing on the board. " "We don't have time to create fancy or complete models. Often, we don't have time to create models at all. "
Where I found people diligently creating models, software was not getting delivered. Paying attention to the models interfered with developing the software.
Constructing models is not the purpose of the project. Constructing a model is only interesting as it helps win the game.
The purpose of the game is to deliver software. Any other activity is secondary. A model, as any communication, is sufficient, as soon as it permits the next person to move on with her work.
The work products of the team should be measured for sufficiency with respect to communicating with the target group. It does not matter if the models are incomplete, drawn with incorrect syntax, and actually not like the real world if they communicate sufficiently to the recipients.
As Jim Sawyer so colorfully wrote in an e-mail discussion about use cases (Cockburn 2001): ". .. as long as the templates don't feel so formal that you get lost in a recursive descent that worm-holes its way into design space. If that starts to occur, I say strip the little buggers naked and start telling stories and scrawling on napkins. "
The effect of the communication is more important than the form of the communication.
Some successful project teams have built more and fancier models than some unsuccessful teams. From this, many people draw the conclusion that more modeling is better.
Some successful teams built fewer and sloppier models than some unsuccessful teams. From this, other people draw the conclusion that less modeling is better.
-
Закладки
The third problem is absence of feedback from the downstream…
On a new project, I would use Crystal Orange as a base methodology…
For us as designers, it was possible to express both propositional…
The complete discussion about when and where to apply concurrent…
1. Project name, job of person interviewed (the interviewee…
The group of 17 quickly agreed on those value choices. Developing…
In arguing for the Theory Building View, the basic…
Games are not just for children, although children also…
Agility implies maneuverability, a characteristic that is more…
It follows that on the Theory Building View, for the primary…
The surprising thing about human success modes is how nebulous…
The chart shows the state of the user stories being worked…
Figure 4-1. Elements of a methodology. Roles. Who you employ,…
13. (FIRST TECHNIQUE). .. your sword now having bounced upward,…
Types of Methodologies Rechtin (1997) categorizes methodologies…
Using the planning game in this way, the sponsors can properly…
After much coaching for six months, his programs still looked…
Accepting program modifications demanded by changing…
Walk around your place of work. Notice · The convection…