James Shore, coauthor of <a href="http://www.amazon.com/Art-Agile-Development-James-Shore/dp/0596527675" target="_blank" rel="nofollow">The Art of Agile Development</a>. Website and blog at <a href="http://www.jamesshore.com" target="_blank" rel="nofollow">http://www.jamesshore.com</A> .
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
James Shore, coauthor of <a href="http://www.amazon.com/Art-Agile-Development-James-Shore/dp/0596527675" target="_blank" rel="nofollow">The Art of Agile Development</a>. Website and blog at <a href="http://www.jamesshore.com" target="_blank" rel="nofollow">http://www.jamesshore.com</A> .
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Originally posted by Peter Dawson:
You're right that the code is the architecture at any moment in time, but the decisions about where to take it next come from somewhere. I'm surprised that the 'somewhere' hasn't been explored more as it seems to be a significant gap in agile.
Having uncertain bits of the agile process also seems to be a bit of a risk, as its hard to know whether they are going to work out during the project or not - at least waterfall is a known (albeit limited) methodology.
A number of writers on this forum has suggested that the gaps in Agile make it harder to get it adopted - I think I'm in agreement with them.
Maybe the idea is that the plan isn't written down and the team simply establish a common understanding amongst themselves; keeping the vision in RAM, makes the development free, agile and light - like a group of free jazz musicians jamming. This is great when it works but frequently won't, so then what's the plan? If a group of musicians don't establish a common understanding of where they were going, you can hear it immediately - how can you tell if a group of developers have got that shared understanding and what do you do if they havn't?
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
. However, other people say different things and even with your definition, its very hard to measure/test. One of the big things in Agile development is for code to be testable, yet the architecture you're describing is completely un-testable and its really an act of faith that it exists at all. I was hoping that there would be an Agile technique that describes how to derive a measurable, testable, definable architecture - I haven't found that yet, hence the comment that there is a gap. Using traditional, 'hulking' techniques does at least create a measurable, testable architecture that's easy to locate e.g. it's in the CASE tool or 'just ask Jim' etc.. Having a measurable architecture makes it a lot easier to know whether a project is going to achieve a strategic goal for example. I'm not sure if Agile has nailed areas like strategy or cross-team dependencies. It might be the case that Agile buys ease and certainty for developers by making life hard for designers + architects - that might not be a bad thing, but it would be good to get that straight if that is indeed the case.It seems to me that the architecture comes from the experience of the team members, informed by discussions of the needs, well known design principles and feedback from the code. What Agile puts into the mix is plenty of the latter and a strong focus on principles such as Once And Only Once
Originally posted by Peter Dawson:
However, other people say different things and even with your definition, its very hard to measure/test. One of the big things in Agile development is for code to be testable, yet the architecture you're describing is completely un-testable and its really an act of faith that it exists at all.
I was hoping that there would be an Agile technique that describes how to derive a measurable, testable, definable architecture - I haven't found that yet, hence the comment that there is a gap.
Using traditional, 'hulking' techniques does at least create a measurable, testable architecture that's easy to locate e.g. it's in the CASE tool or 'just ask Jim' etc.
Having a measurable architecture makes it a lot easier to know whether a project is going to achieve a strategic goal for example.
I'm not sure if Agile has nailed areas like strategy or cross-team dependencies.
It might be the case that Agile buys ease and certainty for developers by making life hard for designers + architects - that might not be a bad thing, but it would be good to get that straight if that is indeed the case.
As far as the music analogy goes: just 'cos a group can jam the first few chords together, doesn't mean that they can play well for an hour or two. 99.9% of music is played to some sort of script/sequence/tab.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Peter Dawson:
I think the point I was driving at is that there needs to be a mechanism to have certain defined design/architecture in advance of the coding.
However, I get the impression that advanced planning is 'not allowed' in pure Agile and that everything has to evolve organically. It is this issue that I don't buy. This seems dogmatic IMO and doesn't map to the projects I have worked on. Even on the Agile projects, people _do_ plan ahead.
For example, it might be necessary for a system to implement something in a particular way due to some strategic requirement. In that situation, it seems necessary to me to put that requirement (possibly expressed as a design) on the table in advance of it being coded.
If the development team are unwilling or unable to follow that requirement then that is an issue, but the fact remains that if something is needed, it needs to be stated. Stating the strategic goals and working to get them achieved makes is easier to achieve them than leaving it to chance that these things will happen organically.
You suggest that it is OK for teams to have high level UML diagrams or similar - I guess that would be a way to detail things that need to be achieved so long as it is allowed for these things to be produced in advance of the coding.
IMO the need for advance planning of architecture and design doesn't go away, all that happens is that the most dominant individuals maintain a mental plan, which they feed into the day-to-day working of the team(s). Sometimes this is great, sometimes not. Personally, I'd like something less alpha-male and more systematic, although I can understand that 'systematic' might cramp the freedom sought by the Agile movement.
To return to the music:
I bought Miles Davis, 'Bitches Brew' recently. On first listen, it appears to be one of the least structured things I've ever heard. On the paperwork that came with the CD there is a photograph of the structure of the title track, which illustrates beautifully and in great detail how the tune was to be constructed. Apparently, Davis handed out this 'architecture' just a few minutes before the band played it. The players were so good and Davis' vision so clear that the recording was made the same day and is a classic. This kind of 'architecture' was what I had in mind. Sorry if I don't have a better explanation - I was trying to find an agile/software version of what Davis did.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
I think the point I was driving at is that there needs to be a mechanism to have certain defined design/architecture in advance of the coding.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
<a href="http://www-306.ibm.com/software/rational/bios/ambler.html" target="_blank" rel="nofollow">Scott W. Ambler</a><br />Practice Leader Agile Development, IBM Rational<br /> <br />Now available: <a href="http://www.ambysoft.com/books/refactoringDatabases.html" target="_blank" rel="nofollow">Refactoring Databases: Evolutionary Database Design</a>
Originally posted by Scott Ambler:
As much as the discussion of "pure agile" is interesting, it's mostly rhetoric. At Dr Dobb's Journal (DDJ) we run surveys to actually discover what's going on in practice, as opposed to what we're being told is going on by the methodologists.
What we discovered was that the vast majority of agile teams do in fact do some up front requirements and architecture modeling (78% and 77% respectively).
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
<a href="http://www-306.ibm.com/software/rational/bios/ambler.html" target="_blank" rel="nofollow">Scott W. Ambler</a><br />Practice Leader Agile Development, IBM Rational<br /> <br />Now available: <a href="http://www.ambysoft.com/books/refactoringDatabases.html" target="_blank" rel="nofollow">Refactoring Databases: Evolutionary Database Design</a>
Originally posted by Scott Ambler:
Granted, which is why we also look into the effectiveness of various practices as well. In the Agile Adoption Survey we found that whiteboard sketches where the fourth most valuable work products on agile teams (working software, source code and tests were the top three) out of 19 artifacts that we asked about.
Yet, the rhetoric around developer testing is easily an order of magnitude greater than around agile modeling techniques. I suspect it has something to do with the codeing culture that dominates most agile discussions.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
I want my playground back. Here, I'll give you this tiny ad for it:
Thread Boost feature
https://coderanch.com/t/674455/Thread-Boost-feature
|