Exact match. Not showing close matches.
'[OT]: Software development methodologies(was[OT]Te'
|I'll try be brief (time is precious) :)
>> You must be an Agile convert already. :) From the Principles of Agile
>> " Simplicity--the art of maximizing the amount of work not done--is
> You mean this <http://agilemanifesto.org/principles.html> ?
> I was somewhat of an Agile convert before there was Agile :) Most of this
> is not that new, and many developers in small groups have done most of
> for a long time -- where appropriate, and as much as appropriate --, long
> before Agile became a buzzword.
That was my point exactly. Agile makes sense.
>> I used to think this way too, but a guy from Boeing said that the best
>> thing to do is to dive right into the project, without any formal
>> documentation. When you have a highly iterative and interactive
>> environment, you discover problems and inconsistencies very quickly.
> Well, yes, but I bet that this guy from Boeing doesn't pay for the
No, but his job is at stake (he's the project lead). And obviously he has
the requirements, the team know where they're going -- why document the
obvious? Document it if it needs to be documented, when you get there.
> I'd like this guy see bidding on a complex software project in
> this fashion... and then executing it with a satisfied customer at the end
> (which means, among other things, within schedule and budget).
The key is keeping the customer involved in the decision making. Among other
things, making the customer realize that resources are limited and he needs
to make choices (which features to keep, for one).
> It's not only about problems and inconsistencies. Real-world projects have
> schedule and budget constraints. You need to start out with a realistic
> goal, otherwise much of the Agile effort will be wasted, too. Just because
> you're going Agilely in the wrong direction doesn't guarantee a success :)
Based on the above, I'm afraid you don't understand what Agile is about. :)
Don't take this personally, use this as an opportunity to learn more about
Agile -- the time investment will be worthwhile.
> Agile is (among other things) about small iteration cycles. That's good;
> make them as small as makes sense, but not smaller. (Now how small is that
> exactly? :)
As short as one week, and as long as 2 months. The "sweet spot" according to
some is 2 weeks. Basically, whatever works for you -- and the Agile process
can help you determine the answer to this question as well. Set your
iteration cycle to two weeks. At the start of the next cycle, ask: "was this
too short? too long? about right?" -- and adjust the length of the cycle
> But most customers don't really care that much about small
> deliveries. While these are good in many aspects (and one of them is to
> make sure the customer sees progress and remains confident), the
> satisfaction comes only with the final delivery, of the full scope, within
> budget and schedule.
I strongly disagree.
With Agile, the customer makes a list of features, and prioritizes them.
Then you go down the list. Each iteration resulting in yet another feature.
It's up to the customer to say, "OK -- that's enough" at any point in the
project (even early), and he ends up with useful, *working* software. Agile
helps avoid feature creep.
With traditional development, the customer may end up with a pile of
out-of-date documentation, and software with lots of features that don't
> I need to make sure up front that I can meet the
> final, full delivery within budget and schedule. This requires early scope
> clarification (would you bid on a project without this?) and budget and
> schedule estimates.
How often do your estimates turn out to be correct? Agile recognizes that
estimates are just educated guesses, which are often wrong -- and helps you
deal with it.
>I don't think a real-world project (government and
> Boeing projects possibly don't qualify here :) works well without either
I'm sorry I cited an engineer from an actual company. :)
In Boeing's defense, they are a private business (with a bottom line), which
doesn't receive government subsidies, and has to compete against a rival
> I'm not saying there are no excesses in documentation. Of course there
> Boeing probably can afford to waste lots of money both on excessive
> up-front documentation and on aimlessly developing in never ending small
> Agile cycles, with a complete refactoring of the core of the system every
> other month.
I will take "never-ending small Agile cycles", each of which results in
WORKING software, over any of the the waterfall methodologies, anyday. With
traditional planning, you can spend 30% of the project planning -- all of
that time, upfront. So on a nine-month project, after three months you'll
have nothing to show, but a pile of paper.
> But in most real-world development projects, scope clarification and
> overall effort and schedule estimates up front make things easier for
Why do you think scope clarification and overall effort and schedule
estimates are not part of Agile?
> People have something to work towards.
Just as they do with Agile.
> I get this feedback a
> lot; most developers don't like to plan, but like it when they know where
> they stand in a plan (if the plan is a realistic one and gets adapted with
> the progress of the project).
What you're saying sounds logical, but my limited experience with
distributed development has for the most part been negative. I came to the
same conclusion long before I became aware of the existence of Agile:
"The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation."
It may cost less to relocate your company to a more populated area, or offer
stronger incentives to the engineer to persuade him to move, than to engage
in distributed development. Of course, that would be true if you value
efficiency above other things, which as we both know is a rather
controversial topic. ;-)
> Rather than "Agile", I prefer "flexible" (note the lower-case "f" and the
> upper-case "A"; I think it's the case that makes a religion, not a
> deity --
> everything and everybody can become a deity :)
If a bunch of smart, experienced programmers got together, and came up with
a simple set of principles that they all agree work, wouldn't you want to at
least investigate what their methodology is really about? You can label any
set of useful principles "religion", and reject it on that basis.
William Chops Westfield
On Apr 14, 2007, at 2:25 PM, Vitaliy wrote:
> That was my point exactly. Agile makes sense.
Having documentation makes sense too. If it's accurate and well
You can come up with any number of "methods" that seem to make sense but
don't necessarily work. See my recent flame about ISO9000...
I may have to read up on this stuff. But...
> As short as one week, and as long as 2 months.
So exactly how does that interact with the HW team and its 9-month+ ASIC
One of the big things I observed at cisco is that the same sort of
development, management, and individual strategies that work really
well for "small projects" don't work nearly so well for "large"
projects (and vis versa, which is largely (and sadly) unrecognized.)
"Small" means the whole team can go out to lunch and talk together;
"large" is bigger than that.
>> But most customers don't really care that much about small deliveries.
>> While these are good in many aspects (and one of them is to make sure
>> the customer sees progress and remains confident), the customer's
>> satisfaction comes only with the final delivery, of the full scope,
>> within budget and schedule.
> I strongly disagree.
> With Agile, the customer makes a list of features, and prioritizes them.
> Then you go down the list. Each iteration resulting in yet another
> feature. It's up to the customer to say, "OK -- that's enough" at any
> point in the project (even early), and he ends up with useful, *working*
> software. Agile helps avoid feature creep.
It seems you're not working much for customers -- are you? Or are you doing
more in-house development? Those are two quite different situations. I bet
you won't easily find a customer who hires a team, pays the team, and just
takes whatever comes, and says "well, if I can't get it all, I'll just be
happy with less"... :)
Most want to have up-front a scope, a schedule and a price (with payment
terms based on delivered scope and schedule). All three may be staged, but
I haven't yet met a customer who was happy to pay and just take what he'll
> With traditional development, the customer may end up with a pile of
> out-of-date documentation, and software with lots of features that don't
Same can happen with Agile -- just the docs will be missing :)
Believe me, you've got to do it right. If Agile helps /you/ to get there,
that's very good. But it might not be that helpful for someone else.
>> I need to make sure up front that I can meet the final, full delivery
>> within budget and schedule. This requires early scope clarification
>> (would you bid on a project without this?) and budget and schedule
> How often do your estimates turn out to be correct? Agile recognizes
> that estimates are just educated guesses, which are often wrong -- and
> helps you deal with it.
Again... are you bidding for paid projects? There /is/ a difference between
in-house projects and for-hire projects. With in-house projects, you trust
the team -- it's the team you have --, and if things don't go with that
team, they just don't go (or you increase the team). With for-hire
projects, this tends to be different.
> I will take "never-ending small Agile cycles", each of which results in
> WORKING software, over any of the the waterfall methodologies, anyday.
See, maybe this is our misunderstanding. I see a world of possibilities
between and around Agile and Waterfall -- it's not an either-or situation.
>> But in most real-world development projects, scope clarification and
>> overall effort and schedule estimates up front make things easier for
> Why do you think scope clarification and overall effort and schedule
> estimates are not part of Agile?
Because you may need to decide the scope of the delivery after the eighth
iteration cycle before you start with the first. That's not Agile. For
Agile, you need a customer (or boss) who wants to work Agile. That's a lot
easier to find with in-house work than with work for hire.
> What you're saying sounds logical, but my limited experience with
> distributed development has for the most part been negative.
I have largely positive experiences. But you need to adapt to the
> "The most efficient and effective method of conveying information to and
> within a development team is face-to-face conversation."
This is true, if you only take the project. I, like most other people I
know, don't live my projects, I work on them. I have other things to care
for in my life, and the most effective method for running a project may
clash with the most effective method of running my life. So again, it's
about finding the overall maximum -- just with more dimensions :)
>> Rather than "Agile", I prefer "flexible" (note the lower-case "f" and
>> the upper-case "A"; I think it's the case that makes a religion, not a
>> deity -- everything and everybody can become a deity :)
> If a bunch of smart, experienced programmers got together, and came up
> with a simple set of principles that they all agree work, wouldn't you
> want to at least investigate what their methodology is really about?
What tells you that I didn't? Besides, some of these smart, experienced
programmers already left the Agile train and are now in post-Agile
movements. The whole software development methodology area is full of
groups of smart, experienced programmers who have found something that
works -- to some degree, under specific circumstances, and for certain
For Agile, two of the requirements that kill it for me in most cases are
the physical proximity of the team members and the fact that the customer
has to want it and work in the Agile way.
> You can label any set of useful principles "religion", and reject it on
> that basis.
Maybe you're getting a bit defensive here. I marked my respective comment
with a smiley, it was in a tongue-in-cheek context from a previous message
-- and I never said I rejected Agile, much less that I do it because I
could label it as "religion". I just think that while it has a few good
thoughts worth thinking about and considering, it's not a silver bullet.
|On 4/14/07, Gerhard Fiedler <connectionbrazil.com> wrote: lists
Agreed, and well-stated, Gerhard. My customers want to know what
we're going to DELIVER from day one, and would never sign a PO before
they had a full spec of what they're going to receive in writing.
I find Agile development to be idealistic rubbish, but typical of
engineers who've never worked in direct customer support, deployment,
or integration roles of large/complex systems. It "looks good on
paper" to the poor guy who's manager just signed him up to do the
impossible, so many tout how wonderful it is... but it only works on
large INTERNAL projects, unless the customer is insane and/or blindly
throwing money at whatever problem they're trying to solve. (Thus,
its popularity with consulting firms. No hard deadlines, no end to
the incoming cash.)
The fact that Agile exists doesn't bother me, it's the amount of
uptake it has had in the industry -- a sure sign the software industry
as a whole hasn't really grown up yet and started to do real
Nate Duehr wrote:
> The fact that Agile exists doesn't bother me, it's the amount of uptake
> it has had in the industry -- a sure sign the software industry as a
> whole hasn't really grown up yet and started to do real engineering.
There are a few interesting ideas in the concept, and some of them can be
used in other contexts, also.
But there's one core concept that IME is one of the reasons for failure of
the deal: frequent (and if needed deep) refactoring. Most programmers are
scared to death to refactor code they haven't written -- but yet, that's
one of the core necessities of Agile. Since there's not much architecture
laid out at the beginning, programmers have to correct the course quite
often -- which means quick and "agile" refactoring, often deep through the
Having this ability is a great asset, and training it is a /very/ good
thing IMO. But it's not easy to get a team of people who are all good at
this... both at doing it, and at judging when is the right time to do it.
Another problem with pure Agile is that IME it is a good thing to task
people with tasks that play to their strengths. Keeps them motivated, and
optimizes the results. This requires a certain amount of pre-planning and
pre-architecturing, and separating the project tasks into individuals'
tasks -- according to the individual strengths and weaknesses. That's kind
of difficult when attacking the thing in an Agile manner.
Other difficulties come up when you have systems that are made up of very
different problem domains, and therefore are critical WRT the interfaces
between them: mechanic and electronic hardware, firmware, PC interface
software, or database backend, business layer, web server, browser
frontend. The middle layer people usually don't like it if they have to
rewrite code every other week because someone at the database backend
didn't plan ahead and changes the table structure according to the growing
needs every other week :)
More... (looser matching)
- Last day of these posts
- In 2007
, 2008 only
- New search...