team doing iterative software development could still value
processes and tools over people and interactions,
comprehensive documentation over working software,
contract negotiation over customer collaboration, and
following a plan over responding to change
Originally posted by Manoj Kumkumath:
I feel skeptical about how good this methodology will be when you have a client who knows nothing about technology, but never ready to comprise a dead line
(Every thing should be ready be next Friday. I mean everything. I am paying money to you guys.
![]()
)
and always comes up with changes from the original plan.
In these scenarios, isn�t it better to have comprehensive documentation and contract negotiation?
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
when you have a client who knows nothing about technology, but never ready to comprise a dead line(Every thing should be ready be next Friday. I mean everything. I am paying money to you guys
Earlier I used to work for project based company who used to execute projects for external clients who usually don't have anything to do with IT. So we used to make documentation a must. These external clients are coming with a fixed deadline projects and I believe all the financial aspects are agreed even before writing the first line of code. But sadly the clients requirements evolve only during time. But they seldom accept that this is not what they first told us. So usually we go back to the documentation and say "see this is what we accepted. Now if you want a change, we can do it. But it will cost you more".
I hate doing documentation. And I really love working in agile way. But I still fail to see how agile methodology takes away importance of documentation. In a bad day, I feel I have only my documentation to back me up.
So do you feel that agile methodolgy won't be a good idea for some projects?
Also
Is there any scenarios where you won't suggest agile way of doing things?
<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:
Agile likely won't work when:
...
Reid - SCJP2 (April 2002)
Originally posted by Ilja Preuss:
What does being paid by that guy have to do with your ability to do the impossible? That is, why does he expect you to get everything, just because he is paying you?
[OCP 21 book] | [OCP 17 book] | [OCP 11 book] | [OCA 8 book] [OCP 8 book] [Practice tests book] [Blog] [JavaRanch FAQ] [How To Ask Questions] [Book Promos]
Other Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, TOGAF part 1 and part 2
It is a stupid, inefficient way of working, but in some projects there is enough money involved that at the upper management level they want the deal anyways (and probably justifiably), yet at the developer level you are stuck with the nutjob behaviours.
Originally posted by Manoj Kumkumath:
But how will you know what actually the application is doing? How easy it's going to be to go through the code and find out if you don't have a proper docs in place.
Reid - SCJP2 (April 2002)
The only solution I've found for this is to start adding unit tests. Even if you don't know what the entire app is doing, at least you can add tests for what you think a particular section of the app is doing.
If even the developer isn't sure what the app is doing, then possibly *neither* the developer nor QA spots the problems - customers do instead (aka the Microsoft product release model ).
Originally posted by Manoj Kumkumath:
Don't you think this makes projects very much developer centric?
Reid - SCJP2 (April 2002)
Originally posted by Manoj Kumkumath:
This middle man can some time really make your life hell
Reid - SCJP2 (April 2002)
Depending on the website/forum you choose to hang out in you can find people who will fight ferociously for any particular methodology be it lightweight (e.g. agile, xp) or heavyweight (typical SDLC implementations).
If by that you mean do I think that the skills and professionalism of the specific developers influence the outcome (where the outcome is how well understood and maintainable the code is), then the answer is definitely yes. Not "developer centric" in the sense that only the original developer understands it - that is what you definitely have without readable code and good unit tests.
I don't think that is even just specifically a B/A issue.
"Your stakeholders might prioritize the requirements in such a way as to push an architecturally significant (read devastating) requirement several months out".
How much is the chance for such changes to come in a later stage of iterations Since we give so much importance to have a production quality software with relatively minimum requirement gathering efforts comparing to an iterative SDLC model? How best agile development deals with these scenarios?
Also I am wondering how well a new team can take up the existing application for support/maintenance especially in projects where you have more than 25 people working in team. You will have working software and you know the effect when you make a change. But how will you know what actually the application is doing? How easy it's going to be to go through the code and find out if you don't have a proper docs in place. I saw somewhere in net that having virtual development team can also spoil the show.
But consider a company where atrrition rate is high and bunch of new developers take over the application.
But how will they understand about architecture?
That means you need developers whose code is very much readable. Ultimately you are looking for developers who are very good OOP and also good in expressing the concepts in code.
means we need the customer interaction on a day to day basis. Usually what I have seen in projects is a developer to a business analyst and from business analyst to end user interaction. This middle man can some time really make your life hell ( Hope all the good analysts I have worked with will pardon me for this comment).
I couldn't find any site which really fights for the poor old SDLC. But I could find a lot of sites which literally tells Agile is solution to all your problems.
in a agile way of doing things, do you really interact with end users or with a B/A?
<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>
quote:
--------------------------------------------------------------------------------
But consider a company where atrrition rate is high and bunch of new developers take over the application.
--------------------------------------------------------------------------------
HR problems should be solved by HR solutions, not by bureaucratic processes. Address the actual problem, the high attrition rate, don't put a process band-aid on it.
My point here is that even in a agile way of doing things, do you really interact with end users or with a B/A?
Reid - SCJP2 (April 2002)
Originally posted by Manoj Kumkumath:
Attrition is just one problem. If you are an non IT company and you give the contract to one IT company for developing a solution, why do you have to depend on them till the end of days. Some way down the line another company can offer you the same support for less price and at that point I am sure you want that to be smooth transfer.
Reid - SCJP2 (April 2002)
That tends to be where I think B/As who specialize in an industry can be really useful; they've spent 5 or 10 years learning the busines processes that end-users in stove-pipe organizations don't even understand themselves (e.g. banking, trading). I also knew one B/A that had to extract critical info in bits and pieces over time from people who make it very clear to him they wouldn't be bugged frequently by development issues (people with big enough salaries and clout that they got what they want, period).
I can imagine how the IT/outsource firm internally could choose to be agile, I can imagine how the client could choose to be agile, but I suspect you are only going to truly see the benefits of agility if both those firms are willing to view themselves as part of one team, either because they are that professional and motivated or because the economics of the contract help to reinforce good behaviours and penalize bad ones.
Attrition is just one problem. If you are an non IT company and you give the contract to one IT company for developing a solution, why do you have to depend on them till the end of days.
Some way down the line another company can offer you the same support for less price and at that point I am sure you want that to be smooth transfer.
I believe the Agile philosophy is that developers tend to interact with end-users. I agree with that as a broad principle, but I know of counter-examples where you could run into snags if you are aren't flexible (agile?) about that issue because the end users/stake holders you *wish* were involved aren't even part of the same organization, or key players refuse to participate as much as would be beneficial.
That tends to be where I think B/As who specialize in an industry can be really useful; they've spent 5 or 10 years learning the busines processes that end-users in stove-pipe organizations don't even understand themselves (e.g. banking, trading). I also knew one B/A that had to extract critical info in bits and pieces over time from people who make it very clear to him they wouldn't be bugged frequently by development issues (people with big enough salaries and clout that they got what they want, period). Not claiming the situation was particularly efficient, just that people probably making 5 times your salary aren't always going to change their process to suit you unless they think it'll make them 10 times your salary
But in a pure business perspective, it may be highly required ( Ok not my area. So only logical assumptions). For an example, for an non IT company it makes real sense to outsource that work to a proven IT company since it provides them less cost and more freedom to do what they are best in doing. But in the same time they really won't like the dependency.
<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:
If you can't convince stakeholders to be actively involved with the project, perhaps it isn't important enough to be done in the first place.
Reid - SCJP2 (April 2002)
Sounds like the marketing pitch of an outsourcing company. You're right, once they've outsourced IT they've disposed of a mission-critical portion of their business which they will find very difficult to "insource" if they ever decide that it was a mistake to outsource it.
Spot false dilemmas now, ask me how!
(If you're not on the edge, you're taking up too much room.)
Originally posted by Bert Bates:
In essence, they say that they will provide the most bang for the buck, but won't say exactly what the bang will be.
software architects are still faced with the challenge of creating a reliable foundation upon which to develop. Such a foundation often requires a fair amount of upfront analysis and prototyping to build a development model. The development model often relies upon specific design patterns and entity relationship diagrams (ERD). Without this upfront foundation, Iterative development can create long term challenges that are significant in terms of cost and quality.
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 Bert Bates:
but have the drawback from a business perspective that they do not provide long-term planning capability
Reid - SCJP2 (April 2002)
Originally posted by Scott Ambler:
Sounds like another HR problem to me.
Reid - SCJP2 (April 2002)
Accurate software project estimates scare the stuffing out of the higher-ups.
Spot false dilemmas now, ask me how!
(If you're not on the edge, you're taking up too much room.)
Originally posted by Bert Bates:
Such a foundation often requires a fair amount of upfront analysis and prototyping to build a development model. The development model often relies upon specific design patterns and entity relationship diagrams (ERD). Without this upfront foundation, Iterative development can create long term challenges that are significant in terms of cost and quality.
Reid - SCJP2 (April 2002)
Originally posted by Bert Bates:
Unfortunately, I'm not in a position to be a great advocate for SDLC-esque approaches, but I'd really like to hear about situations when an SDLC-esque approach really makes the most sense.
Reid - SCJP2 (April 2002)
Originally posted by Bert Bates:
I was a consultant for a long time, and we used to joke that if 'upper management' really knew up front how much time and money any given project was really going to take, most projects would never even get started.
It strikes me that Agile would be tough on really large projects or on really complex projects.
For instance, my gut reaction (not based on any deep thought or research!) is that I don't want to fly in a 747 that was built using Agile methodologies.
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
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
Spot false dilemmas now, ask me how!
(If you're not on the edge, you're taking up too much room.)
Originally posted by David Rocks:
a good RUP project will always go better than a bad agile project. will a good RUP project go as well as a good agile project?
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
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 Ilja Preuss:
Are you saying that a RUP project can't be Agile? Don't let Grady hear that...![]()
Spot false dilemmas now, ask me how!
(If you're not on the edge, you're taking up too much room.)
Don Morgan, Founder
www.DeveloperAdvantage.com - FREE Audiobooks for Software Developers
<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>
Don Morgan, Founder
www.DeveloperAdvantage.com - FREE Audiobooks for Software Developers