Home > Archive > Software Engineering > July 2006 > Re: Agile In Action
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Re: Agile In Action
|
|
| bill turner 2006-06-24, 8:15 am |
| On 16 Jun 2006 20:34:59 -0700, "Vladimir Levin" <vlad.levin@gmail.com>
wrote:
>This is a post from my blog (vladimirlevin.blogspot.com). I welcome
>comments.
>
>I don't know to what extent the notions of up-front requirements
>analysis and design are still being actively used these days, but I've
Vlad,
I work as an independent contract programmer. I first became intrigued
with XP/Agile in 1999 (?) after reading an article in IEEE Software.
Since I have worked at three different clients since then and am now
s ing new work, I have seen little requirement for this knowledge.
In fact, a quick search on DICE would demonstrate that it has not been
as widely adapted as some seem to think. If fact, it seems only a
small percentage of shops have adopted these practices. Even in the
organizations I've been in that are well aware of XP/Agile, none are
taking any serious effort to adopt it.
One must wonder why, if this is the silver bullet claimed by the
zealots, that is has not been more widely adopted after so many years.
>heard a lot of debate on the subject over the past few years. I'm
>currently working on an agile project and today I had a good experience
>in which three of us, a customer and two developers, worked together to
>flesh out a requirement in a way that simply would not be possible in a
>more traditional environment heavy on up-front requirement preparation.
Why wouldn't it be possible? I don't see it. Nothing you have
described precludes the ability of an RE from identifying the three
types of analysis you describe. In fact, I would say it would be an RE
who failed to ask the appropriate defining questions. As for the UI
design, that too is completely doable. Whether or not people thought
creatively has little to do with the methodology used. In fact, I
would posit that quick drawings on paper or whiteboard could elicit
exactly the same response, then it could be formally defined in a
document.
Your conclusion, it seems to me, seems unwarranted.
<snip description of experience>
Bill
------------------------------------------
Bill Turner
A faith that the free play of market forces will eventually end in Good is, in fact, more 'absurd' than religious belief, for there, at least, there is a presumption of an intelligent Agent Who writes straight with His crooked lines. - William Pfaff
Views expressed are entirely my own and only coincidentally represent those of other persons or entities.
| |
|
| bill turner wrote:
> Your conclusion, it seems to me, seems unwarranted.
>
> <snip description of experience>
Welcome to USENET, Vlad! Your report of specific first-hand experiences gets
snipped in favor of idle gainsaying.
--
Phlip
[url]http://c2.com/cgi/wiki?ZLand[/url] <-- NOT a blog!!!
| |
|
| Vladimir Levin wrote:
> That's exactly right. As a user, I may ask just for X and Y.
And as a developer, I can openly request to implement x<X and y<Y. And I can
also just implement them and see if they pass review. If they do, I don't
argue.
And if the Onsite Customer wrote an acceptance test, it shall certainly
require less X than all the written X could be.
> ...To
> answer your question, I think we'd still have the subject matter
> experts, but would they be they working right next to the developers
> and discussing the stories being worked on every day?
Why not? That helps write the acceptance tests.
> If you disagree, please describe the kind of interaction you would
> expect to see if things were decided way up front. Maybe we're simply
> using different terminology to talk about the same things.
Ask him for his own experience collating requirements.
--
Phlip
[url]http://c2.com/cgi/wiki?ZLand[/url] <-- NOT a blog!!!
| |
| David Lightstone 2006-06-24, 7:02 pm |
|
"Phlip" <phlip2005@gEEEmail.com> wrote in message
news:pan.2006.06.24.06.29.21.938928@gEEEmail.com...
> Isaac Gouy wrote:
>
>
> That's a great way to say it!
>
>
>
> The "Agile" movement formerly complained about Big Design Up Front as the
> highest risk up-front behavior.
>
> The research and surveys into requirements gathering has generally shown
> that the worst risk comes from Big Requirements Up Front.
>
> For example, even _after_ several decades of Toyota kicking Detroit's
> butt, and after Detroit executives giving lots of lip service to
> Just-in-Time design and lean manufacturing, Toyota is _still_ in the lead.
> They put a cheap hybrid car, the Prius, out first, and they have a new
> line that you never heard of, the Yaris, for the low-end. All these cars
> have new design features that closely target what customers are asking
> for. Toyota does it by delaying the specification process and distributing
> it among all their team members.
(1) Care to cite a reference on the claim "Toyota does it by delaying the
specification process and distributing it among all their team members."
If you have ever read a GM, Ford or BMW system or component specification
you probably realize that there is little BDUF occuring within the auto
industry. It is much close to the Agile ideal (customer stories) than you
think. Each story would be something like. "Everything is just fine except
we observe this phenomena, fix it.". You have the test case that fails, and
the feature to implement from get go. Agile at its finest. Behavior
indistinguishable from hacking at its finest also.
Any chance the engineering by story will failed?
>
> --
> Phlip
| |
|
| Isaac Gouy wrote:
> you wrote "Gouy then claimed I should not cite that book because it
> misrepresents evidence. This outer claim is not falsifiable - the claim
> that the entire book should not be read."
>
> That is untrue - I made no such claim.
Then the next time I recommend the book you won't complain?
> I've asked that you show where I made those claims and you have not
> attempted to do so, nor have you in any way corrected your comments.
> http://groups.google.com/group/comp...1ec147157bc8ac1
>
> It doesn't seem to me that you are interested in honest discussion.
The fallacy of this argument is I didn't read your post, hence couldn't
honestly discuss it. I suspect that's "excluded middle".
You were kill-filed at the time.
--
Phlip
[url]http://c2.com/cgi/wiki?ZLand[/url] <-- NOT a blog!!!
| |
| bill turner 2006-06-25, 10:02 pm |
| On 23 Jun 2006 06:11:25 -0700, "Vladimir Levin" <vlad.levin@gmail.com>
wrote:
>Phlip wrote:
>
>I think you might be ready for a break from usenet :) Seriously though:
>First of all, I don't expect people to just fall over in recognition of
>how right I am. I want people to ask questions and disagree. As long as
>we can all do so in a respectful way, then we're all learning. I didn't
>see anything in Bill's reply that struck me as gainsaying. His way of
>looking at things is very natural. I had a long debate about this
>subject with a student in one of my youth software courses. At 14, he
>was convinced that rigorous analysis was the way to go. I don't think
>even the bugs that he was constantly chasing in his project really
>disuaded him from his point of view! Anyway, he's a very bright kid and
>we had good discussions. Second: If there are people who's motivations
>really are malicious, to discredit what I'm saying just for the heck of
>it or out of some kind of deep-seated hatred of agile methodologies,
>fine. All I can do is hope that people will largely take any postings I
>make in the spirit that I intended: To share my experiences, help other
>people in the software world, and also learn myself from responses.
Phlip often seems to interpret any questioning of the glory of
XP/Agile as unfound criticism. You seem to have understood that. What
you do not seem to have understood was that I was questioning your
position that the results would have been unlikely using a more
traditional method. Of course, if you use the straw man argument of a
pure waterfall development, something I've never seen done, not even
in th 70's when I first entered the field, then I would agree.
However, understanding that software development is always iterative,
and there have been many methods used to elicit requirements even in
traditional methods, I still say I cannot agree with your conclusion.
It seems, from your description, that the little suggestion that came
from your GUI expert could have come during the analysis/design phases
of a traditional project just as easily. And, just as easily, the
suggestion might not have ever occurred. It was a matter of a person
thinking creatively at an opportune moment. Perhaps, even, it would
have been more likely in a traditional process because there would
have been more opportune moments: during requirements elicitation and
analysis, during specification, during detail design: or during
implementation. In the process you described, there were far fewer
opportunities: story writing, story review, implmentation.
XP/Agile may, indeed, lead to discovery of requirements that would be
near impossible through traditional methods. Your experience, imho,
does not provide any real support of this hypothesis.
FWIW, I am neither an XP/Agile zealot or skeptic. I have been exposed
to its practice, both trying to use it and working with a vendor who
developed using said practices. These have been both positive and
negative experiences. I feel XP/Agile probably has its place, but that
it is another tool to know and use when appropriate, and probably
adpat to experiences on the ground.
Bill
------------------------------------------
Bill Turner
A faith that the free play of market forces will eventually end in Good is, in fact, more 'absurd' than religious belief, for there, at least, there is a presumption of an intelligent Agent Who writes straight with His crooked lines. - William Pfaff
Views expressed are entirely my own and only coincidentally represent those of other persons or entities.
| |
| Phlip 2006-06-25, 10:02 pm |
| bill turner wrote:
> Phlip often seems to interpret any questioning of the glory of
> XP/Agile as unfound criticism. You seem to have understood that.
I interpret the situation as Vlad's online technique doesn't suck. ;-)
--
Phlip
[url]http://c2.com/cgi/wiki?ZLand[/url] <-- NOT a blog!!!
| |
| bill turner 2006-06-25, 10:02 pm |
| On Sat, 24 Jun 2006 00:46:56 GMT, "Phlip" <phlipcpp@yahoo.com> wrote:
>bill turner wrote:
>
>
>I just heard, on KFOG in San Francisco, an advertisement requesting resumes
>for "Agile" IT personnel. Note that ain't CraigsList. A radio advertisement
>is an expensive, high-end investment, on the same level as, say, beer or
>cars.
>
>(The quality of search engine may also be a factor.;)
FWIW, Dice claims: "Dice is the #1 job site for technology careers".
There may be a problem with the search engine, but I would not jump to
such a conclusion. Since Dice is such a large and heavily used system,
any problems or quirks with the search engine has probably long been
ironed out. Of course, an operator problem is something else. I just
related my experience that very few jobs that came up on my searches
even mentioning anything about XP/Agile. I did nothing to include or
exclude such results.
>
>They plugged this:
>
>http://www.solutionsiq.com/agile_dev_services.html
>
>Of course one always has to work to detect the difference between buzz-word
>compliance and "getting it", but I doubt the Bay Area will have much problem
>with that.
Buzzword compliance is always an issue, isn't it? Your assumption that
someone in the Bay Area "gets it", though, seems to beg the question
of why you are skeptical of what is returned in job searches on Dice.
In the one case, you don't want to believe that which doesn't validate
your position, and in the other, you believe what does validate it. In
neither case are the claims more or less solid.
>
>From the page (for anyone claiming there's no statistics available for such
>things):
>
>KEY BENEFITS OF AGILE:
>Agile development results in reduced time, costs and solid ROI according to
>analysis from Forrester Consulting, 2004 and Agile Methodologies Survey
>Results, Shine Technologies Pty Ltd, 2003
>
>57% reduction in costs compared to other IT solutions for similar complex
>projects.
>
>62% reduction in effort compared to alternatives, including in-house
>development and previously employed consultants.
>
>80% reduction in critical defects
>
>60% reduction in overall defects
>
>93% stated productivity was better / significantly better
>
>88% stated that quality was better / significantly better
>
>83% stated that business satisfaction was better / significantly better
Didn't Forrester make some outrageous claims about Y2K? Like, the
world was going to end? Like COBOL developers would get $150/hr (I
never even met one billed close to that!). Haven't they made many
other incorrect predictions or inaccurate claims?
All you've stated above may be accurate, but I do question the
sources.
Overall, however, you seem to take offense at my questioning the
conclusion Vlad had reached. In what way has he demonstrated that the
results would not be the same or any less likely to occur when using
traditional methods? Other than pointing out that it has not been
widely adopted, though heavily discussed for the past eight or so
years and wonder why, I, in no way, said that there is anything wrong
or inferior about XP/Agile. Perhaps it was my questioning the
conclusion of its superiority in the analogy he provided that has so
upset you. If not, please explain how his experience could not have
occurred, or was even unlikely to occur, in traditional development.
And, please do not use the straw man argument of pure waterfall. You
know no one has done that in a generation, if ever.
Finally, I do not appreciate the ad-hominem attack. It is a logical
fallacy and I can only wonder why you did it. I come here for honest,
rigorous discussion and debate. My posting was not idle gainsaying in
the least. Thankfully Vlad understood that. I did not deserve the
attack.
Bill
------------------------------------------
Bill Turner
A faith that the free play of market forces will eventually end in Good is, in fact, more 'absurd' than religious belief, for there, at least, there is a presumption of an intelligent Agent Who writes straight with His crooked lines. - William Pfaff
Views expressed are entirely my own and only coincidentally represent those of other persons or entities.
| |
| Phlip 2006-06-25, 10:02 pm |
| bill turner wrote:
> Buzzword compliance is always an issue, isn't it? Your assumption that
> someone in the Bay Area "gets it", though, seems to beg the question
> of why you are skeptical of what is returned in job searches on Dice.
> In the one case, you don't want to believe that which doesn't validate
> your position, and in the other, you believe what does validate it. In
> neither case are the claims more or less solid.
Not at all. My fallacy is "argumentum ad autoritatem", where the Authority
is the Bay Area.
>
> Didn't Forrester make some outrageous claims about Y2K? Like, the
> world was going to end? Like COBOL developers would get $150/hr (I
> never even met one billed close to that!). Haven't they made many
> other incorrect predictions or inaccurate claims?
Excluded middle. Forrester could have a corporate pessimism streak, in which
case their Agile numbers could err on the side of pessimism, as did their
Y2K numbers.
Also, check the motive. If Forrester sells Agile solutions, and sold Y2K
solutions, they have motivation to over-report Y2K problems and over-report
Agile problems.
> All you've stated above may be accurate, but I do question the
> sources.
>
> Overall, however, you seem to take offense at my questioning the
> conclusion Vlad had reached. In what way has he demonstrated that the
> results would not be the same or any less likely to occur when using
> traditional methods?
He didn't claim that. He posted a spot-check about one situation in one
project. He's not a liar, damned liar, or statistition.
You previous reported working a couple of bum projects that called
themselves Agile. I have too, but I knew the difference between the bum
parts and the Agile parts. If a team skips a critical practice, such as
Onsite Customer, they are asking for trouble, and will get there rapidly and
with a low defect rate!
> Other than pointing out that it has not been
> widely adopted
The problem with this theory is that it _has_ been widely adopted. 8 years
ago it was on one Wiki. Now it's on the radio (in the Bay Area), and in >100
books. So claiming it's not widely adopted is probably /argumentum ad
lubruscem acidus/. Sour grapes. ;-)
--
Phlip
[url]http://c2.com/cgi/wiki?ZLand[/url] <-- NOT a blog!!!
| |
| Phlip 2006-06-26, 10:01 pm |
| brxsep wrote:
> For myself, XP is not new. Done that with COBOL and IMS
> transactions/screens
You did Test Driven Development with COBOL? How many edits did you make
before running all tests?
--
Phlip
[url]http://c2.com/cgi/wiki?ZLand[/url] <-- NOT a blog!!!
| |
| bill turner 2006-06-27, 9:59 pm |
| On 26 Jun 2006 16:51:23 -0700, "Vladimir Levin" <vlad.levin@gmail.com>
wrote:
>
>bill turner wrote:
> Perhaps, even, it would
>
>Clearly you disagree (and that's fine) but the point I am making is
>that I believe it is much easier to recognize gaps in requirements when
>one is forced to write code to implement those requirements. That's the
>principle I was trying to illustrate. It is very easy to see when
>confronted with an "else" statement that one hasn't got a requirement
>for. Trying to ferret out those types of details during a successive
>process of analysis, specification, and detailed design, in my opinion,
>would likely lead to finding a lot of "fat" that was driven more by the
>need for the process to justify itself, but could easily miss something
>like what I described. Ultimately though, I was just describing a
>specific experience that I thought I'd share as being representative.
>If you (and others of course) don't find it very convicing, perhaps I
>will try to share further experiences in the future. I had another good
>experience today but it would require more background information than
>the last one did and I don't want to get into descriptions that are too
>domain-specific. If you're specifically interested, email me and we can
>discuss it by email.
>
>
>As far as Agile is concerned, the first value expressed in the
>manifesto is "Individuals and interactions over processes and tools."
>Ipso facto, agile processes should be adaptable. For example, if an
>actual future user of the app is not available to play a customer role,
>find people who can stand in. The practices of XP are more rigid. For
>example, if you don't want to do paired programming, that's fine, but
>are you really doing XP, or rolling your own agile methodology? Of
>course, if you only have a team of 2 or 3 developers, I'd imagine even
>that fundamental XP practice ought to be tempered... Note that the
>process we are using on my current project certainly has its fair share
>of planning. We have a list of all of the features the whole
>application is expected to have. This list (the product backlog to use
>scrum terminology) is very high-level and is used for strategic
>purposes to determine who much work needs to be done. Items in this
>list would frequently break down into numerous stories, and those are
>developed each month, then reviewed by the customers before being
>introduced for development. So there is certainly planning, just not to
>the same level of detail that I think you'd prefer to see.
Again, I think I have been misunderstood. Perhaps I am communicating
poorly. Your experience is great, but if I had kept track through all
my projects, there would have been many eureka moments experienced by
myself or others. What you described was, to me, merely someone
thinking creatively at an opportune moment, a moment when such
thoughts would be well received. I don't feel that the process used
had anything to do with that insight.
As for the rest, I only tried to explain my thoughts and experiences
with XP/Agile to demonstrate that I am not out attacking the process
as is frequently assumed when one questions any praise XP/Agile has
received. I am a very critical thinker. You made a claim. I questioned
whether or not the claim was justified by your experience. I felt not.
As for the level of detail I require, the level of detail varies with
circumstances. The process I use varies with circumstances. XP/Agile
is a tool. TDD is a tool. Structured Analysis is a tool. Like any
profession, we need to know which tool is the right tool for the job.
------------------------------------------
Bill Turner
A faith that the free play of market forces will eventually end in Good is, in fact, more 'absurd' than religious belief, for there, at least, there is a presumption of an intelligent Agent Who writes straight with His crooked lines. - William Pfaff
Views expressed are entirely my own and only coincidentally represent those of other persons or entities.
| |
| bill turner 2006-06-27, 9:59 pm |
| On Mon, 26 Jun 2006 03:14:35 GMT, "Phlip" <phlipcpp@yahoo.com> wrote:
>bill turner wrote:
>
>
>Not at all. My fallacy is "argumentum ad autoritatem", where the Authority
>is the Bay Area.
I don't see how a radio advertisement could be stronger proof than the
postings of thousands of jobs. I am not saying it is worth less,
either, considering the market in which it played.
>
>
>Excluded middle. Forrester could have a corporate pessimism streak, in which
>case their Agile numbers could err on the side of pessimism, as did their
>Y2K numbers.
>
>Also, check the motive. If Forrester sells Agile solutions, and sold Y2K
>solutions, they have motivation to over-report Y2K problems and over-report
>Agile problems.
I don't really understand what you are saying here. I liken evidence
provided by Forrester or Garner to someone on the witness stand. Once
they have made claims that are dubious, it is hard to take them at
their word on anything else.
>
>
>He didn't claim that. He posted a spot-check about one situation in one
>project. He's not a liar, damned liar, or statistition.
He didn't? It sure seems he did:
"I had a good experience in which three of us, a customer and two
developers, worked together to flesh out a requirement in a way that
simply would not be possible in a more traditional environment heavy
on up-front requirement preparation".
That sure sounds like a claim the results would not be the same using
traditional methods.
>He posted a spot-check about one situation in one
>project. He's not a liar, damned liar, or statistition.
What? Are you suggesting I've besmirched his reputation? Certainly not
my intent. If he felt I've called him a liar, I have not heard it. So,
I assume you are just using the name of a famous book to make clear
that Vlad was not performing a controlled experiement. I never took it
as such. I just question his conclusion based upon his experience. It
does not necessarily follow that the GUI expert asks a smart question
that the question would not have been asked in a traditional form of
development, or that it would not have been implemented. Nothing in
his experience suggests that in any way. If it does, please point it
out to me. Or, perhaps Vlad could chime in with greater detail to
explain why he believes it would not have occurred in a traditional
development environment. Until that time, there just is scant evidence
for the conclusion.
>
>You previous reported working a couple of bum projects that called
>themselves Agile. I have too, but I knew the difference between the bum
>parts and the Agile parts. If a team skips a critical practice, such as
>Onsite Customer, they are asking for trouble, and will get there rapidly and
>with a low defect rate!
>
>
>The problem with this theory is that it _has_ been widely adopted. 8 years
>ago it was on one Wiki. Now it's on the radio (in the Bay Area), and in >100
>books. So claiming it's not widely adopted is probably /argumentum ad
>lubruscem acidus/. Sour grapes. ;-)
What are you talking about? Sour grapes?
Number of websites means little. There are hundreds of websites on
many given subjects. I'll bet you could find hundreds of websites
talking about Structured techniques, or RUP, or PSP. The same would
likely be true of books. Radio advertising? I don't know what that
means.
What does matter is the number of people developing using said
techniques. I suggested the informal survey of job requirements on a
general purpose software tech job board to determine how widely it has
been adopted. It is my belief, and I could be wrong about this, that
if not methodology or process is mentioned, then a traditional method
is likely used. My experience with doing a number of searches, many of
those recently since I am currently trying to find a new project,
indicates that knowledge of XP/Agile is not a common requirement, nor
is it mentioned very often as the environment used. That would seem to
indicate that it is not widely adopted. Of course, it could also mean
that the types of jobs posted on Dice are not very representative,
too.
------------------------------------------
Bill Turner
A faith that the free play of market forces will eventually end in Good is, in fact, more 'absurd' than religious belief, for there, at least, there is a presumption of an intelligent Agent Who writes straight with His crooked lines. - William Pfaff
Views expressed are entirely my own and only coincidentally represent those of other persons or entities.
| |
|
| bill turner wrote:
>
> He didn't? It sure seems he did:
>
> "I had a good experience in which three of us, a customer and two
> developers, worked together to flesh out a requirement in a way that
> simply would not be possible in a more traditional environment heavy
> on up-front requirement preparation".
>
> That sure sounds like a claim the results would not be the same using
> traditional methods.
He said "experience", and you accuse him of implying proof but without data.
In context, he found that working together was better than a "traditional
environment" that forbade working together.
--
Phlip
[url]http://c2.com/cgi/wiki?ZLand[/url] <-- NOT a blog!!!
| |
| rmoldskr+usenet@online.no 2006-06-28, 9:59 pm |
| In comp.software-eng Phlip <phlipcpp@yahoo.com> wrote:
>
> In context, he found that working together was better than a "traditional
> environment" that forbade working together.
>
Are you in all seriousness making the claim that "traditional"
forms of software development forbids people from working together?
--
Leif Roar Moldskred,
bemused
| |
|
| rmoldskr+usenet wrote:
> In comp.software-eng Phlip <phlipcpp@yahoo.com> wrote:
[color=darkred]
> Are you in all seriousness making the claim that "traditional" forms of
> software development forbids people from working together?
I gave a lecture on TDD to SCQAA last w, and I took time with the crowd
to learn what they were doing.
Let's say that many software projects use an "Analyst" role to collate
feature requests into scheduled, specified features. The programmers would
implement the features and produce a new release. Then QA roles would
take the release and verify that its features matched the input
specifications.
One major complaint among the QA people was access to the Analysts. They
often felt the written documentation was incomplete, both from programmers
and Analysts, and they felt the Analysts were unavailable for hard
questions. These people were often working other projects by the time QA
got the release. Apparently, they couldn't just interrupt them and take
time away from their current projects.
So regardless what we call these processes, or where their bosses learned
them, these people felt like they were _forbidden_ to collaborate with the
people most qualified to optimize and streamline their situations.
--
Phlip
| |
| David Lightstone 2006-06-28, 9:59 pm |
|
"Phlip" <phlipcpp@yahoo.com> wrote in message
news:frvog.109764$H71.103977@newssvr13.news.prodigy.com...
> bill turner wrote:
>
>
> He said "experience", and you accuse him of implying proof but without
> data.
>
> In context, he found that working together was better than a "traditional
> environment" that forbade working together.
When did the management demigods declare working together forbidden? Did I
miss something, or are you just engaging in a little silly rhetoric?
>
> --
> Phlip
> [url]http://c2.com/cgi/wiki?ZLand[/url] <-- NOT a blog!!!
>
| |
| David Lightstone 2006-06-28, 9:59 pm |
|
"Phlip" <phlip2005@gEEEmail.com> wrote in message
news:pan.2006.06.28.17.05.09.249893@gEEEmail.com...
> rmoldskr+usenet wrote:
>
>
>
>
> I gave a lecture on TDD to SCQAA last w, and I took time with the crowd
> to learn what they were doing.
Does this mean you really have begun to study the software development
process that is actually being followed (as opposed to believing that
everyone does waterfall)? (oh how I do hope so).
>
> Let's say that many software projects use an "Analyst" role to collate
> feature requests into scheduled, specified features.
Opps I'm made an assumption. Back to believing things that are dubous
(concealed wqaterwall assumption now in play)
> The programmers would
> implement the features and produce a new release. Then QA roles would
> take the release and verify that its features matched the input
> specifications.
So someone wrote something down, but, as you indicate below of very low
quality
>
> One major complaint among the QA people was access to the Analysts. They
> often felt the written documentation was incomplete, both from programmers
> and Analysts, and they felt the Analysts were unavailable for hard
> questions. These people were often working other projects by the time QA
> got the release. Apparently, they couldn't just interrupt them and take
> time away from their current projects.
And just how does this impact coding (the work of agile coders)
>
> So regardless what we call these processes, or where their bosses learned
> them, these people felt like they were _forbidden_ to collaborate with the
> people most qualified to optimize and streamline their situations.
That is not a software process problem, it is a complete and total
managerial failure. (not doing any verification reviews) Certainly not your
classical waterfall
>
> --
> Phlip
| |
|
| brxsep wrote:
> Yes it can. Depending on the shop. 20 years ago I was yelled out by
> the SA because I BA, former PA, asked a PA a simple what heppens when
> X=1 in program Z? From that point on, had to write my question on
> paper, send to typing, review the draft, approve it, receive final...
I would have so quit. Thanks for the anecdote.
And just after this post, a colleague (with whome I am sometimes allowed to
collaborate!) sent me this:
http://thedailywtf.com/forums/thread/79265.aspx
Subject: Not allowed to communicate something critically important to the
users.
Ah, but all these anecdotes are just us holding up that reliable old
Waterfall straw-person, right guys?
--
Phlip
[url]http://c2.com/cgi/wiki?ZLand[/url] <-- NOT a blog!!!
| |
| bill turner 2006-07-02, 3:59 am |
| On Wed, 28 Jun 2006 13:25:31 GMT, "Phlip" <phlipcpp@yahoo.com> wrote:
>bill turner wrote:
>
>
>He said "experience", and you accuse him of implying proof but without data.
>
>In context, he found that working together was better than a "traditional
>environment" that forbade working together.
Phlip, if he was only speaking of his experience, I would never have
posted in the first place. However, he drew a conclusion. Once he drew
that conclusion, I looked for the argument to support the conclusion.
None was forthcoming. That is what I objected to.
Perhaps a little thing like logical argumentation just gets in the way
of a good conclusion?
Guess what! I've had an experience this past w. A developer came
over and said the place to which data was being written was not wise.
We decided it should be ftp'd to a different server. Hey! That would
have been an impossible result to reach using XP/Agile!
Based upon the arguments provided, either my conclusion is valid, or
Vlad's conclusion is not. I've supported my conclusion with as much
evidence as Vlad did his. So, what is it, Phlip? Have we both reached
sound conclusions and provided sound arguments to support those
conclusions? Or, have we both failed to soundly support the
conclusions? I suppose you could try to claim that Vlad supported his
conclusion while I did not mine, but then we are back where I began,
how is his conclusion supported by anything he has written?
------------------------------------------
Bill Turner
A faith that the free play of market forces will eventually end in Good is, in fact, more 'absurd' than religious belief, for there, at least, there is a presumption of an intelligent Agent Who writes straight with His crooked lines. - William Pfaff
Views expressed are entirely my own and only coincidentally represent those of other persons or entities.
| |
|
| bill turner wrote:
> Phlip, if he was only speaking of his experience, I would never have
> posted in the first place. However, he drew a conclusion. Once he drew
> that conclusion, I looked for the argument to support the conclusion.
> None was forthcoming. That is what I objected to.
>
> Perhaps a little thing like logical argumentation just gets in the way
> of a good conclusion?
You have read such rhetorical flourishes many times in all the literature of
software engineering. Our discipline is not a hard science; it has no
experiments or proofs. Aphorisms and thought experiments are all we have.
Don't play the victim.
--
Phlip
[url]http://c2.com/cgi/wiki?ZLand[/url] <-- NOT a blog!!!
| |
| David Lightstone 2006-07-02, 9:59 pm |
|
"Phlip" <phlipcpp@yahoo.com> wrote in message
news:LnQpg.126113$dW3.18273@newssvr21.news.prodigy.com...
> bill turner wrote:
>
>
> You have read such rhetorical flourishes many times in all the literature
> of software engineering. Our discipline is not a hard science; it has no
> experiments or proofs. Aphorisms and thought experiments are all we have.
>
(1) Economics is not a hard science, yet somehow the practioneers have been
able to reach valid conclusions (ie not based on ideology) about significant
problems. The techniques are based upon rather sophisticated application of
statistics. See the book Freakonomics for some insight.
(2) Whether these techniques have been applied to the practices of software
engineering is unknown to me. Whether they have even been applied to the
practices of management is likewise unknown to me. I doubt seriously if they
ever will. Ideologies never like their foundations to be examined carefully
> Don't play the victim.
>
> --
> Phlip
> [url]http://c2.com/cgi/wiki?ZLand[/url] <-- NOT a blog!!!
>
>
| |
| David Lightstone 2006-07-04, 6:59 pm |
|
"Isaac Gouy" <igouy@yahoo.com> wrote in message
news:1152035959.410609.280340@b68g2000cwa.googlegroups.com...
> David Lightstone wrote:
>
> Phlip knows that software engineering has experiments. In this
> newsgroup, Phlip has referred to a paper titled "Experiment about
> Test-first programming".
> http://groups.google.com/group/comp...3d1d0aa82f2d726
>
> It doesn't seem to me that Phlip is being sincere.
I have long held that opinion
>
| |
| Ron Jeffries 2006-07-04, 9:58 pm |
| On Tue, 04 Jul 2006 20:14:02 GMT, "David Lightstone"
<david._NoSpamlightstone@prodigy.net> wrote:
> Isaac Gouy wrote:
>
>I have long held that opinion
I have long held an opinion about you two ...
But let me ask, to be sure. Are either of you interested in reaching any kind of
common understanding of the subject, which is, in this case, whether Agile
works, and if so, how and in what context?
--
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.
| |
| S Perryman 2006-07-05, 3:59 am |
| "Ron Jeffries" <ronjeffries@acm.org> wrote in message
news:1b9ma2lulpqpb1208pvqjeneviqf1h3prg@
4ax.com...
> But let me ask, to be sure. Are either of you interested in reaching any
> kind of
> common understanding of the subject, which is, in this case, whether Agile
> works, and if so, how and in what context?
Does it work ?? And if so, how and in what context ??
And what development methods is "Agile" actually better than ??
Regards,
Steven Perryman
| |
| David Lightstone 2006-07-05, 7:59 am |
|
"Ron Jeffries" <ronjeffries@acm.org> wrote in message
news:1b9ma2lulpqpb1208pvqjeneviqf1h3prg@
4ax.com...
> On Tue, 04 Jul 2006 20:14:02 GMT, "David Lightstone"
> <david._NoSpamlightstone@prodigy.net> wrote:
>
>
>
> I have long held an opinion about you two ...
>
> But let me ask, to be sure. Are either of you interested in reaching any
> kind of
> common understanding of the subject, which is, in this case, whether Agile
> works, and if so, how and in what context?
Oh I would say that we each have a common understanding of the subject. From
a practical perspective (with the goal being to develop software
successafully) probably as well as you (except neither of us writes books
advocating its use)
Being one the principle advocates of the practices, I would expect you to be
more than familiar with situations where it has failed to achieved the
claimed results than either of us (the difference being perhaps that you
carefully spin the failure as misapplications of the principles) From your
prespective, not mine, - whenever the current 10 or so principles are not
satisfied (a conciese and meaningless answer, see Extreme Programming
Refactored: the case againes XP for a humorous articulation of some known
problems). From my perspective - anytime that project is exploratory in
nature (see Ould's book, Managing Software Quality and Business Risk if you
don't recognize the term); anytime the organization functions under Matrix
management; anytime a death march is being conducted. anytime the
development team has not done a similar project;
As for you claimed goal -characterizing Agile like methods for purposes of
predicting whether its use will achieve a successful development or not - it
is a fools errand. Why do you even suggest that it be attempted?
>
> --
> Ron Jeffries
> www.XProgramming.com
> I'm giving the best advice I have. You get to decide if it's true for you.
| |
| Ron Jeffries 2006-07-06, 3:58 am |
| On Wed, 05 Jul 2006 10:57:01 GMT, "David Lightstone"
<david._NoSpamlightstone@prodigy.net> wrote:
>
>Oh I would say that we each have a common understanding of the subject. From
>a practical perspective (with the goal being to develop software
>successafully) probably as well as you (except neither of us writes books
>advocating its use)
I'm willing to accept that you (two) have some experience in developing software
effectively. There are many ways to do that.
Your words do not lead me to predict that either of you have any significant
experience using Agile methods, nor that you really have any interest in doing
so. That's why I asked.
>
>Being one the principle advocates of the practices, I would expect you to be
>more than familiar with situations where it has failed to achieved the
>claimed results than either of us (the difference being perhaps that you
>carefully spin the failure as misapplications of the principles)
Think about it, David. I make a living advising software teams on how to do a
better job of providing software to the people who ask it of them. I can only
succeed at that insofar as my advice works. I can make no money offering poor
advice. So I have no vested interest whatsoever in spinning Agile: it wouldn't
help me to do so.
>From your
>prespective, not mine, - whenever the current 10 or so principles are not
>satisfied (a conciese and meaningless answer, see Extreme Programming
>Refactored: the case againes XP for a humorous articulation of some known
>problems).
The book you reference is written by individuals who are selling their own
method, and who have never tried XP. For a better analysis of Agile and XP, I'd
recommend either Pete McBreen's book, Questioning Extreme Programming, or Boehm
and Turner, Balancing Agility and Discipline. Neither of these books quite nails
it either, in my opinion, again because the authors are speculating about what
might happen rather than reporting what does happen.
> From my perspective - anytime that project is exploratory in
>nature (see Ould's book, Managing Software Quality and Business Risk if you
>don't recognize the term); anytime the organization functions under Matrix
>management; anytime a death march is being conducted. anytime the
>development team has not done a similar project;
This sentence has no very. Any of those times ... what? Agile wouldn't work? Or
would? Agile itself is exploratory, incremental and iterative. It works
wonderfully in exploratory projects as far as I can tell. I've seen Agile work
in a Matrix situation, though I don't consider it to be a good idea. As far as
I'm concerned, nothing works in a Death March, but there are some Agile
techniques I'd use if I had to be on one.
I don't see why Agile would be particularly bad if a team had no prior
experience. I'm not sure what would be better and would be interested to hear
your thinking. I'd think that a project style that focused on delivering running
tested features every w or two would be a pretty good way to track how things
were going with an inexperienced team, and wonder what you'd think was better.
>
>As for you claimed goal -characterizing Agile like methods for purposes of
>predicting whether its use will achieve a successful development or not - it
>is a fools errand. Why do you even suggest that it be attempted?
I don't think I claimed that as my goal. I asked whether you had any sincere
interest in reaching a common understanding of the subject. You didn't answer
that. Have you, or not?
--
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.
| |
| Ron Jeffries 2006-07-06, 3:58 am |
| On Wed, 5 Jul 2006 08:44:10 +0100, "S Perryman" <a@a.net> wrote:
>
>Does it work ?? And if so, how and in what context ??
Yes. I've personally seen it work on IT projects, in web development projects,
in the creation of software products for sale, and in a number of other areas.
My colleagues in the Agile community report successes in many other areas such
as mathematical research projects, embedded medical and telecomms, and even a
bit of  stuff at NASA.
That is not to say that there can't be success in all of those areas using other
methods: there can be, have been, and will be.
At a very simple, almost simplistic level, Agile works by focusing on iterative
delivery of continually refined versions of the program, each one ready to ship.
At that level it is not terribly different from Boehm's spiral model, or Gilb's
Evo.
Agile is characterized as well by a focus on the people and their interactions,
more than on an imposed specific process. It measures progress by the production
of software rather than by milestones such as requirements or design completion.
In my experience it works best in smaller teams, probably because as the team
size grows, the person-to-person communication model suffers and you have to
fall back on more documentation and more procedure, which moves you away from
Agile.
>
>And what development methods is "Agile" actually better than ??
Better? Depends what we mean by better. It tends to produce far more visible
evidence of progress. It is likely to have something shippable, and something of
value, earlier than many if not most other processes.
Many teams are reporting higher quality -- reduced defects -- over what they
were doing before, though it might be that what they were doing before wasn't a
very good process. However, to work at all, Agile needs a lot of intensive
testing, preferably automated, because everything in the code is potentially
changing every w. The result of this testing might credibly be faster
feedback on the state of quality, and a better ability to keep quality high.
So I'd say that Agile offers particular benefits in those areas. Again, it's not
the only way to do software: I've done quite a few other ways successfully
myself. It's my personal favorite for the kinds of projects I'm familiar with,
and it seems clear on the face of it that many of the practices are applicable
over a very wide range of projects.
What do you think?
--
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.
| |
| S Perryman 2006-07-06, 3:58 am |
| "Ron Jeffries" <ronjeffries@acm.org> wrote in message
news:hlcpa2dgon5cubtbdmn2tje0n994dfitug@
4ax.com...
> On Wed, 5 Jul 2006 08:44:10 +0100, "S Perryman" <a@a.net> wrote:
RJ>But let me ask, to be sure. Are either of you interested in reaching any
RJ>kind of
RJ>common understanding of the subject, which is, in this case, whether
Agile
RJ>works, and if so, how and in what context?
[color=darkred]
> Yes. I've personally seen it work on IT projects, in web development
> projects,
> in the creation of software products for sale, and in a number of other
> areas.
> My colleagues in the Agile community report successes in many other areas
> such
> as mathematical research projects, embedded medical and telecomms, and
> even a
> bit of stuff at NASA.
You will need to be a bit more specific than that with the systems that have
been developed (especially for telecoms which is where I live) .
> That is not to say that there can't be success in all of those areas using
> other
> methods: there can be, have been, and will be.
> At a very simple, almost simplistic level, Agile works by focusing on
> iterative
> delivery of continually refined versions of the program, each one ready to
> ship.
> At that level it is not terribly different from Boehm's spiral model, or
> Gilb's
> Evo.
So it is possible that the iterative process in general, as opposed to
specific
"Agile" methods, is the prime factor in "success" ??
Iterative development has been around for a long time (I first was involved
in
such projects in 1991) , long before "Agile" appeared on the screen.
> Agile is characterized as well by a focus on the people and their
> interactions,
> more than on an imposed specific process.
And yet several so-called "Agile" methods have an "imposed specific process"
(XP, FDD as immediate examples) .
> In my experience it works best in smaller teams, probably because as the
> team
> size grows, the person-to-person communication model suffers and you have
> to
> fall back on more documentation and more procedure, which moves you away
> from
> Agile.
For "Agile" in general, or only for specific methods ??
[color=darkred]
> Better? Depends what we mean by better. It tends to produce far more
> visible
> evidence of progress. It is likely to have something shippable, and
> something of
> value, earlier than many if not most other processes.
> Many teams are reporting higher quality -- reduced defects -- over what
> they
> were doing before, though it might be that what they were doing before
> wasn't a
> very good process.
Indeed. Most processes X are "better" than a poor process Y.
But until X and Y are given, "better" , "higher quality" etc are moot IMHO.
> However, to work at all, Agile needs a lot of intensive
> testing, preferably automated, because everything in the code is
> potentially
> changing every w. The result of this testing might credibly be faster
> feedback on the state of quality, and a better ability to keep quality
> high.
> So I'd say that Agile offers particular benefits in those areas. Again,
> it's not
> the only way to do software: I've done quite a few other ways successfully
> myself. It's my personal favorite for the kinds of projects I'm familiar
> with,
> and it seems clear on the face of it that many of the practices are
> applicable
> over a very wide range of projects.
> What do you think?
Not very convincing to me (but then what is) .
But the tone is a lot more sensible nowadays than days of yore.
Which IMHO is a lot more useful for the average reader who may wish to
examine or debate.
Regards,
Steven Perryman
| |
|
| Ron Jeffries wrote:
> What do you think?
Are you /that/ bored??
--
Phlip
[url]http://c2.com/cgi/wiki?ZLand[/url] <-- NOT a blog!!!
| |
| S Perryman 2006-07-06, 7:58 am |
| "Phlip" <phlipcpp@yahoo.com> wrote in message
news:mJ5rg.80412$4L1.25070@newssvr11.news.prodigy.com...
> Ron Jeffries wrote:
[color=darkred]
> Are you /that/ bored??
And Usenets' XP muppet is never far behind ...
| |
| David Lightstone 2006-07-06, 7:00 pm |
|
"Ron Jeffries" <ronjeffries@acm.org> wrote in message
news:9tbpa2dn39fmet7nilodohm8kbttpq0eqv@
4ax.com...
> On Wed, 05 Jul 2006 10:57:01 GMT, "David Lightstone"
> <david._NoSpamlightstone@prodigy.net> wrote:
>
snip
[color=darkred]
>
> I don't think I claimed that as my goal. I asked whether you had any
> sincere
> interest in reaching a common understanding of the subject. You didn't
> answer
> that. Have you, or not?
Having I failed to understand your goal here?
Does not
">>> But let me ask, to be sure. Are either of you interested in reaching
any
mean the same thing as
">>As for you claimed goal -characterizing Agile like methods for purposes
of[color=darkred]
Perhaps you should avoid trying to remember what you have posted and read a
bit more carefully.
The oversight could readily be  with a serving of stone soup (that
is the term Phlip uses for a slow gradual shift in subjects conducted for
nefarious purposes is it not?)
[color=darkred]
>
> --
> Ron Jeffries
> www.XProgramming.com
> I'm giving the best advice I have. You get to decide if it's true for you.
| |
| David Lightstone 2006-07-06, 7:00 pm |
|
"Ron Jeffries" <ronjeffries@acm.org> wrote in message
news:9tbpa2dn39fmet7nilodohm8kbttpq0eqv@
4ax.com...
> On Wed, 05 Jul 2006 10:57:01 GMT, "David Lightstone"
> <david._NoSpamlightstone@prodigy.net> wrote:
>
[color=darkred]
>
> I don't think I claimed that as my goal. I asked whether you had any
> sincere
> interest in reaching a common understanding of the subject. You didn't
> answer
> that. Have you, or not?
>
If and when you find the content of a posting that I place to be insincere,
deceptive or misleading, do be so kind as to so indicate that. Until then
your efforts to imply that my postings are not sincere by means of inuendo
are something that I can only call insincere. Clean up your act
> --
> Ron Jeffries
> www.XProgramming.com
> I'm giving the best advice I have. You get to decide if it's true for you.
| |
| David Lightstone 2006-07-06, 7:00 pm |
|
"Ron Jeffries" <ronjeffries@acm.org> wrote in message
news:9tbpa2dn39fmet7nilodohm8kbttpq0eqv@
4ax.com...
> On Wed, 05 Jul 2006 10:57:01 GMT, "David Lightstone"
> <david._NoSpamlightstone@prodigy.net> wrote:
>
>
> I'm willing to accept that you (two) have some experience in developing
> software
> effectively. There are many ways to do that.
>
> Your words do not lead me to predict that either of you have any
> significant
> experience using Agile methods, nor that you really have any interest in
> doing
> so. That's why I asked.
We have been down this road before both you know it and I know it. The only
people who probably don't know it are the readers of this and the previous
posting
The various gambits are
(1) Try it you will like it - until you try it you have no standing
(2) I (Ron Jeffries) am a keeper of the flame, I do not recognize you as
being able to understand what the flame is all about - you just don't know
(3) You just are not helping you are not sincere
Without doubt you are an expert on Agile like methods. You also seem to
believe that you are an astute evaluator of the skills, experience and
training of others. Whether this is true or not I do not know, nor do I care
to know. In this case 2 and 3 are applicable
>
> Think about it, David. I make a living advising software teams on how to
> do a
> better job of providing software to the people who ask it of them. I can
> only
> succeed at that insofar as my advice works. I can make no money offering
> poor
> advice. So I have no vested interest whatsoever in spinning Agile: it
> wouldn't
> help me to do so.
>
One could just as readily argue that because you earn your living advising
you must make great effort to avoid doing or saying anything that might
offend potential customers. Just how does avoidance differ from spin?
> --
> Ron Jeffries
> www.XProgramming.com
> I'm giving the best advice I have. You get to decide if it's true for you.
| |
| AndrewMcDonagh 2006-07-06, 7:00 pm |
| S Perryman wrote:
> "Ron Jeffries" <ronjeffries@acm.org> wrote in message
> news:hlcpa2dgon5cubtbdmn2tje0n994dfitug@
4ax.com...
>
>
> RJ>But let me ask, to be sure. Are either of you interested in reaching any
> RJ>kind of
> RJ>common understanding of the subject, which is, in this case, whether
> Agile
> RJ>works, and if so, how and in what context?
>
>
>
> You will need to be a bit more specific than that with the systems that have
> been developed (especially for telecoms which is where I live) .
>
This might interest you....
http://www.vanu.com/resources/publi...n_SDRFpaper.pdf
Aside from that, I worked an an OMC-R for a pico-cell basestation
Controller, which was TDDed and ran using XP - the project turned around
from being a deathmarch when we started using XP.
>
>
>
> So it is possible that the iterative process in general, as opposed to
> specific
> "Agile" methods, is the prime factor in "success" ??
>
> Iterative development has been around for a long time (I first was involved
> in
> such projects in 1991) , long before "Agile" appeared on the screen.
>
It certainly has - see Royce's paper from 1970 above
snipped...
Andrew
>
> Regards,
> Steven Perryman
>
>
| |
| David Lightstone 2006-07-06, 7:00 pm |
|
"Ron Jeffries" <ronjeffries@acm.org> wrote in message
news:9tbpa2dn39fmet7nilodohm8kbttpq0eqv@
4ax.com...
> On Wed, 05 Jul 2006 10:57:01 GMT, "David Lightstone"
> <david._NoSpamlightstone@prodigy.net> wrote:
>
snip
>
> The book you reference is written by individuals who are selling their own
> method, and who have never tried XP. For a better analysis of Agile and
> XP, I'd
> recommend either Pete McBreen's book, Questioning Extreme Programming, or
> Boehm
> and Turner, Balancing Agility and Discipline. Neither of these books quite
> nails
> it either, in my opinion, again because the authors are speculating about
> what
> might happen rather than reporting what does happen.
Everyone speculates about what will happen, some are just better at it than
others. You speculate all that time. Your principle speculation would be
something of the form - Practice the 10 principles, you will succeed. There
is no evidence for this being true. There is no evidence for this being
wrong. There may not even be a successful XP project (the participants may
claim to have followed the XP practices, but as we all know claim and
reality can be different). There are only explinations as to how the
principles were violated (hence the project can be ignored as evidence
either pro or con) when a project fails. This observation is the keeper of
the flame phenomena. (success is ours, failure theirs) In the set of all
projects, the only projects that failed were not practicing XP, ergo XP will
be successful (everything else has been excluded). In addition to being
excelent rhetoric, it is something other than valid reasoning.
Whether the authors of Extreme Programming Refactored are or are not
attempting to convince the reader to practice some other unmentioned method
is something I did not consider. They certainly gave no indication of having
a method of their own (other than being employeed as some company which may
or may not be marketing a method). Perhaps they are engaged in an extremely
sophisticated nefarious con. The certainly fooled me, they even fooled the
publishers of the book. That is what you would care for the reader to
believe is it not? Sorry, but it is a bit farfetched to me to accept as
fact.
I have no reason to doubt your claim that they have never even tried XP, I
also have no reason to believe that trying XP is a precondition for
evaluating the suitability or appropriateness of using XP.
>
> --
> Ron Jeffries
> www.XProgramming.com
> I'm giving the best advice I have. You get to decide if it's true for you.
| |
| David Lightstone 2006-07-06, 7:00 pm |
|
"Ron Jeffries" <ronjeffries@acm.org> wrote in message
news:9tbpa2dn39fmet7nilodohm8kbttpq0eqv@
4ax.com...
> On Wed, 05 Jul 2006 10:57:01 GMT, "David Lightstone"
> <david._NoSpamlightstone@prodigy.net> wrote:
>
snip
[color=darkred]
>
snip
>
>
> This sentence has no very. Any of those times ... what? Agile wouldn't
> work? Or
> would? Agile itself is exploratory, incremental and iterative. It works
> wonderfully in exploratory projects as far as I can tell. I've seen Agile
> work
> in a Matrix situation, though I don't consider it to be a good idea. As
> far as
> I'm concerned, nothing works in a Death March, but there are some Agile
> techniques I'd use if I had to be on one.
You asked whether Agile like methods would work. Optimism is a great thing
to have, but risk management demands that failures be considered. I gave you
situations under which the methods would fail. I guess that means it does
not always work. More importantly I also indicated that the question was a
fools errand. You just will never be able to characterize the orgainization,
projects and process out there sufficiently well so as to be able to make
the predictions you wish to make (the how and what context). The choice of
the 3 was to achieve coverage (how many projects are not one of the 3? ie
failue is always a possibility don't pretend otherwise)
Sorry Ron, by its very nature exploratory implies the distinct possibility
of a complete and total failure. That possibility is why I provided
reference to Ould's book. (so that my revference point could be understoud).
As an exploratory method XP can fail, yet there are no examples of XP having
failed. Are there examples of XP failing on an exploratory project?
Having seen it succeed in a Matrixed organization, have you also seen it
fail?
>
> I don't see why Agile would be particularly bad if a team had no prior
> experience. I'm not sure what would be better and would be interested to
> hear
> your thinking. I'd think that a project style that focused on delivering
> running
> tested features every w or two would be a pretty good way to track how
> things
> were going with an inexperienced team, and wonder what you'd think was
> better.
>
> I don't think I claimed that as my goal. I asked whether you had any
> sincere
> interest in reaching a common understanding of the subject. You didn't
> answer
> that. Have you, or not?
>
> --
> Ron Jeffries
> www.XProgramming.com
> I'm giving the best advice I have. You get to decide if it's true for you.
| |
| David Lightstone 2006-07-06, 7:00 pm |
|
"Ron Jeffries" <ronjeffries@acm.org> wrote in message
news:9tbpa2dn39fmet7nilodohm8kbttpq0eqv@
4ax.com...
> On Wed, 05 Jul 2006 10:57:01 GMT, "David Lightstone"
> <david._NoSpamlightstone@prodigy.net> wrote:
>
>
> I don't see why Agile would be particularly bad if a team had no prior
> experience. I'm not sure what would be better and would be interested to
> hear
> your thinking. I'd think that a project style that focused on delivering
> running
> tested features every w or two would be a pretty good way to track how
> things
> were going with an inexperienced team, and wonder what you'd think was
> better.
Add projects in which the 2 w operational cycle is infesible to the menu
of situations under which Agile like methods will not work.
I don't get to decide what would be better, I don't really care. One plays
the situation as best as one can. Changing the situation is just not my
goal. As they say in golf (a game I do not play) - You must play the ball
where it lands (you just don't get to changes your employeers golf course to
suit your pleasure). If the organization is screwed up, it is screwed up. I
can not do anything about it.
Systematic tracking against well defined goals, you have been in
organizations that do that, outstanding. Never seen it done, don't expect
to, Heck in most places being able to keep up with the requirement changes
is as good as things get. The best I can expect to see it the proverbial bug
hopper (aka Rational Clearquest or MSK Integrity Manager). Bugs go in,
people get tasks, more bugs get discovered, repeat until delivery or project
canceled. Mass production hacking at best. Punctuated perhaps by a coherent
architecture
Now change the words requirements and bugs to story. Considering that the
mass production hacking operations always insist on rigerous testing (but
sometime redefine the meaning of the word rigerous or make exceptions when
deadline approach) not much of a difference from the Agile like methods.
This would be especially so if you are practicing continuous integration. In
theory you aways have a working system after any change (can you be any more
Agile than that). In practice you always have a piece of crap to fix (there
is a process requireing rigerous testing and there is what is actually done)
[color=darkred]
>
> --
> Ron Jeffries
> www.XProgramming.com
> I'm giving the best advice I have. You get to decide if it's true for you.
| |
| Isaac Gouy 2006-07-06, 7:00 pm |
|
Ron Jeffries wrote:
> On Tue, 04 Jul 2006 20:14:02 GMT, "David Lightstone"
> <david._NoSpamlightstone@prodigy.net> wrote:
>
>
>
> I have long held an opinion about you two ...
I don't know David Lightstone from Adam - we aren't a couple - malign
him separately from me.
A few ws ago, I made a specific comment about a false claim made by
Phlip
http://groups.google.com/group/comp...d8edc6ab5fe81c6
A w ago, you corrected another of Phlip's false claims
http://groups.yahoo.com/group/extre.../message/120894
A few days ago, I made a specific comment following a specific
statement made by Phlip - "Our discipline is not a hard science; it has
no experiments or proofs. Aphorisms and thought experiments are all we
have."
In response, you've voiced the baseless generalization that I am
insincere. You haven't provided any example to support your opinion,
it's no more than malicious gossip.
>
> But let me ask, to be sure. Are either of you interested in reaching any kind of
> common understanding of the subject, which is, in this case, whether Agile
> works, and if so, how and in what context?
>
> --
> Ron Jeffries
> www.XProgramming.com
> I'm giving the best advice I have. You get to decide if it's true for you.
When Agile works and when Agile doesn't work.
There's nothing novel about recognising limitations - "No project is
started by the timebox teams that does not fit within the scope of the
methodology. Because of this, DuPont is able to claim that none of its
timebox projects have been failures."
| |
| David Lightstone 2006-07-06, 9:58 pm |
|
"David Lightstone" <david._NoSpamlightstone@prodigy.net> wrote in message
news:xwgrg.60514$Lm5.53529@newssvr12.news.prodigy.com...
>
> "Ron Jeffries" <ronjeffries@acm.org> wrote in message
> news:9tbpa2dn39fmet7nilodohm8kbttpq0eqv@
4ax.com...
> snip
>
>
>
> Everyone speculates about what will happen, some are just better at it
> than others. You speculate all that time. Your principle speculation would
> be something of the form - Practice the 10 principles, you will succeed.
> There is no evidence for this being true. There is no evidence for this
> being wrong. There may not even be a successful XP project (the
> participants may claim to have followed the XP practices, but as we all
> know claim and reality can be different). There are only explinations as
> to how the principles were violated (hence the project can be ignored as
> evidence either pro or con) when a project fails. This observation is the
> keeper of the flame phenomena. (success is ours, failure theirs)
One clarification is needed (failure is theirs because they did not know or
follow the proper procedure)
> In the set of all projects, the only projects that failed were not
> practicing XP, ergo XP will be successful (everything else has been
> excluded). In addition to being excelent rhetoric, it is something other
> than valid reasoning.
>
> Whether the authors of Extreme Programming Refactored are or are not
> attempting to convince the reader to practice some other unmentioned
> method is something I did not consider. They certainly gave no indication
> of having a method of their own (other than being employeed as some
> company which may or may not be marketing a method). Perhaps they are
> engaged in an extremely sophisticated nefarious con. The certainly fooled
> me, they even fooled the publishers of the book. That is what you would
> care for the reader to believe is it not? Sorry, but it is a bit
> farfetched to me to accept as fact.
>
> I have no reason to doubt your claim that they have never even tried XP, I
> also have no reason to believe that trying XP is a precondition for
> evaluating the suitability or appropriateness of using XP.
>
>
>
>
>
>
| |
| Ron Jeffries 2006-07-06, 9:58 pm |
| On Thu, 6 Jul 2006 08:45:59 +0100, "S Perryman" <a@a.net> wrote:
>
>You will need to be a bit more specific than that with the systems that have
>been developed (especially for telecoms which is where I live) .
Why will I need to do that? Still, one place to look would be at the work of Ron
Crocker at Motorola.
>
>
>
>
>So it is possible that the iterative process in general, as opposed to
>specific
>"Agile" methods, is the prime factor in "success" ??
Well, certainly it's possible. Agile can be seen as a set of ideas for making
iterative work smoothly. What if that were true?
>
>Iterative development has been around for a long time (I first was involved
>in
>such projects in 1991) , long before "Agile" appeared on the screen.
Yes. That's well recognized. There is little new in Agile, other than the
arrangement of practices that have been seen to work. Part of how those of us
who were in Agile at the beginning were confident enough to go ahead was that we
were doing things we had already tried and found to work.
>
>
>
>And yet several so-called "Agile" methods have an "imposed specific process"
>(XP, FDD as immediate examples) .
XP does not have an imposed process, nor a specific process for that matter. FDD
does, and to me, it feels less like what I perceive Agile to be than other
processes do. In the eyes of people who know FDD better than I do, it qualifies.
I could go either way on it.
The main thing is that it contains a set of good ideas that seem to work well in
concert and that are consistent with the values and principles of Agile.
Probably that it seems to work well is the main thing to recommend it -- to me
that would be the main thing to recommend any process.
>
>
>
>For "Agile" in general, or only for specific methods ??
I don't understand the question. I was saying that in larger teams one tends to
need more documentation and procedure, which Agile processes generally try to
minimize. As you're forced to move more in the direction of docs and procs, it
seems to me that you become, perforce, less agile.
There are people who specialize in Agile for larger teams, such as the
aforementioned Ron Crocker, and Glen Alleman. They know far more about that than
I do, or than I want to.
>
>
>
>
>
>Indeed. Most processes X are "better" than a poor process Y.
>
>But until X and Y are given, "better" , "higher quality" etc are moot IMHO.
>
>
>
>
>
>Not very convincing to me (but then what is) .
What was I supposed to be convincing you of? I was just answering what seemed to
be reasonable questions.
>
>But the tone is a lot more sensible nowadays than days of yore.
>Which IMHO is a lot more useful for the average reader who may wish to
>examine or debate.
Maybe you're just finally getting mellow in your old age. ;->
Regards,
--
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.
| |
| Ron Jeffries 2006-07-06, 9:58 pm |
| On 6 Jul 2006 17:49:58 -0700, "Isaac Gouy" <igouy@yahoo.com> wrote:
>In response, you've voiced the baseless generalization that I am
>insincere. You haven't provided any example to support your opinion,
>it's no more than malicious gossip.
My opinion is that you are not interested in learning about agile and how it
works. I base that opinion on a lack of examples, namely any examples where you
have asked any questions about Agile, offered any experienced opinions, or made
any on-topic contributions (that I can recall) of any kind. All you have done,
to my recollection, is to reiterate your opinions about the quality of material
in Larman's book, and then take potshots at people who find it to be valuable
anyway.
I am convinced, by experience, that you have no sincere interest in Agile or XP.
Whether you are generally sincere about some things, I can't guess. I'm
convinced that you're consistent in some significant ways, which may or may not
reflect sincerity.
I'd like to have some new contributions from you, by way of asking questions
about Agile or telling us about your experiences with it. I don't expect to get
what I'd like in this regard, but nonetheless, that's what I'd like.
--
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.
| |
| S Perryman 2006-07-07, 3:59 am |
| "AndrewMcDonagh" <newsamd@amc.com> wrote in message
news:e8k3no$tkb$1@news.freedom2surf.net...
>S Perryman wrote:
[color=darkred]
[color=darkred]
[color=darkred]
> This might interest you....
> http://www.vanu.com/resources/publi...n_SDRFpaper.pdf
>
> Aside from that, I worked an an OMC-R for a pico-cell basestation
> Controller, which was TDDed and ran using XP - the project turned around
> from being a deathmarch when we started using XP.
And how would you compare both of the above to similar systems
that I have worked on using iterative development :
UMTS base station controllers performing 250-500,000 busy hour call
attempts.
Regards,
Steven Perryman
| |
| S Perryman 2006-07-07, 3:59 am |
| "Ron Jeffries" <ronjeffries@acm.org> wrote in message
news:omira2525hr51srl3m9chusls6d2qogre2@
4ax.com...
> On Thu, 6 Jul 2006 08:45:59 +0100, "S Perryman" <a@a.net> wrote:
RJ>Yes. I've personally seen it work on IT projects, in web development
RJ>projects,
RJ>in the creation of software products for sale, and in a number of other
RJ>areas.
RJ>My colleagues in the Agile community report successes in many other areas
RJ>such
RJ>as mathematical research projects, embedded medical and telecomms, and
RJ>even a bit of stuff at NASA.
[color=darkred]
> Why will I need to do that?
Because any trivial system can be touted as a "success" in telecoms.
Still, one volunteer eventually came forward.
> Still, one place to look would be at the work of Ron Crocker at Motorola.
A quick search gave me the title of one paper :
"The 5 reasons XP can't scale and what to do about them"
Unfortunately the website (www.xp2001.org/conference/program.html) appears
to
be attacked by the filter here as having a high weighting of pornographic
phrases
(honestly) .
So until the wend, if you have time perhaps you can list those five
reasons
here for us.
[color=darkred]
> Well, certainly it's possible. Agile can be seen as a set of ideas for
> making
> iterative work smoothly. What if that were true?
If iterative development lead to say 60% improvement, and <insert your
favourite "Agile" method here> lead to 65% improvement, one can examine
the extra 5% more closely (especially wrt ROI) .
[color=darkred]
[color=darkred]
> XP does not have an imposed process, nor a specific process for that
> matter.
Customer must write "acceptance tests" first.
Test-first approach. Pair programming. Etc.
I do iterative development, and none of those projects have any requirement
to
work in any of the above modes.
> FDD
> does, and to me, it feels less like what I perceive Agile to be than other
> processes do. In the eyes of people who know FDD better than I do, it
> qualifies.
> I could go either way on it.
You will find many FDD practitioners will consider the method very agile
indeed.
But they don't need the method to be called "Agile" .
[color=darkred]
[color=darkred]
> I don't understand the question.
I think you do, Ron.
> I was saying that in larger teams one tends to
> need more documentation and procedure, which Agile processes generally try
> to
> minimize. As you're forced to move more in the direction of docs and
> procs, it
> seems to me that you become, perforce, less agile.
And yet FDD proved otherwise. On all counts.
It worked on its "poster-child" project (Singapore bank) .
And that project then increased in scale, and it worked again.
Perhaps that is the difference : people should be asking about *agile*
methods
that work across a spectrum of projects, as opposed to "Agile" methods.
> There are people who specialize in Agile for larger teams, such as the
> aforementioned Ron Crocker, and Glen Alleman. They know far more about
> that than
> I do, or than I want to.
Why do you not want to know about how "Agile" may succeed or fail in larger
teams, or projects ??
RJ> What do you think?
[color=darkred]
> What was I supposed to be convincing you of?
The "success" of "Agile" methods. ??
> I was just answering what seemed to be reasonable questions.
Consider them answered.
Regards,
Steven Perryman
| |
| Bjorn Reese 2006-07-07, 7:58 am |
| S Perryman wrote:
> "The 5 reasons XP can't scale and what to do about them"
You can find the article via
http://citeseer.ist.psu.edu/532056.html
The top 5 reasons are:
<quote>
o Pair Programming expands quadratically
o Planning Game is too introspective
o Collective Ownership leads to chaos
o Metaphor is too weak
o No means to effectively coordinate multiple teams exists in the
other practices
</quote>
The author goes on to suggest solutions to these problems, but I am not
sure that XP practitioners would call the result XP:
<quote>
[The Team Coordination layer] can be viewed as a layering [of] the
project structure, where at the highest level in the hierarchy there
is a collection fo teams being coordinated. At the bottom are the
individual teams that are doing the work.
[...]
The Team Coordination layer replaces the Metaphor, Pair Programming,
Collective Ownership, and On-site Customer practices with
"Architecture Lite"
[...]
An Architecture Lite fully describes the system architecture but at a
high level of abstraction. The description includes both structural
and behavioral aspects of the system.
</quote>
The "Team Coordination layer" sounds like a normal organization
hierarchy, and "Architecture Lite" like a normal system architecture.
--
mail1dotstofanetdotdk
| |
| David Lightstone 2006-07-07, 7:58 am |
|
"AndrewMcDonagh" <newsamd@amc.com> wrote in message
news:e8k3no$tkb$1@news.freedom2surf.net...
>S Perryman wrote:
>
> This might interest you....
>
> http://www.vanu.com/resources/publi...n_SDRFpaper.pdf
There is an expression I like to remember when I read articles such as that
one. It goes something like - When you stand on the shoulders of giants it
is best to be humble.
What pray tell is the big deal here? You have a massive waterfall or Big Up
Front Design (BUFD) project (implement GSM). You see a little itty-bitty
activity within that BUFD project, conduct an Agile type implementation and
you taut it as a poster child for Agile development.When you stand on the
shoulders of giants is most definitely applicable. T
As far as I can tell the must important information in the entire paper is
"This material is based upon work supported by the National Science
Foundation under Award Number DMI-0110460, Amendment No: 001". Other than
to implement GSM there has to be a reason for the funding decision. It is
not obvious to me. I would like to know that reason
On any International Communication task such as a GSM or UMTS development
the things other than pair programming would be ground zero preconditions
for even considering the project. If you don't have compatibility, you can't
sell. You establish compatibility by passing the well formulated tests that
the international community has negociated as being the standard for
acceptability. That act of negociation is generally called BUFD by those you
favor Agile type development. To now claim the fruits of that BUFD effort as
though they never occured is, well, chuptza (Yiddish word probably spelled
wrong)
That is Test Driven Development is an inherant characteristics of such
developments. That is you have both a protocal and protocal implementation
validation specification on day 1. It is just implementation, no changes in
the stories, just grind it out type development. Hard arduous task to do the
implementation, no doubt about it. There may be some serious challenges (the
latency issue mentioned), to call it Agile, that is just marketing hype
[color=darkred]
>
> Aside from that, I worked an an OMC-R for a pico-cell basestation
> Controller, which was TDDed and ran using XP - the project turned around
> from being a deathmarch when we started using XP.
>
>
> It certainly has - see Royce's paper from 1970 above
>
> snipped...
>
>
> Andrew
>
>
| |
|
| Bjorn Reese wrote:
> The author goes on to suggest solutions to these problems, but I am not
> sure that XP practitioners would call the result XP:
Start small. If you actually need big, this analysis will tell you, very soon.
Break the project up into two or more small XP projects, each team
treating the next team as the customer.
--
Phlip
| |
| Peter Little 2006-07-07, 9:58 pm |
| "Bjorn Reese" <breese@see.signature> wrote in message
news:44ae346a$0$1961$ba624c82@nntp02.dk.telia.net...
> S Perryman wrote:
[color=darkred]
> You can find the article via
> http://citeseer.ist.psu.edu/532056.html
Thanks.
> The top 5 reasons are:
> <quote>
> o Pair Programming expands quadratically
> o Planning Game is too introspective
> o Collective Ownership leads to chaos
> o Metaphor is too weak
> o No means to effectively coordinate multiple teams exists in the
> other practices
> </quote>
> The author goes on to suggest solutions to these problems, but I am not
> sure that XP practitioners would call the result XP:
> <quote>
> [The Team Coordination layer] can be viewed as a layering [of] the
> project structure, where at the highest level in the hierarchy there
> is a collection fo teams being coordinated. At the bottom are the
> individual teams that are doing the work.
> [...]
> The Team Coordination layer replaces the Metaphor, Pair Programming,
> Collective Ownership, and On-site Customer practices with
> "Architecture Lite"
> [...]
> An Architecture Lite fully describes the system architecture but at a
> high level of abstraction. The description includes both structural
> and behavioral aspects of the system.
> </quote>
> The "Team Coordination layer" sounds like a normal organization
> hierarchy, and "Architecture Lite" like a normal system architecture.
I'll have a read and then comment.
I don't know whether Mr Crocker has any other papers, but I'll try and
see.
Regards,
Steven Perryman
| |
| Peter Little 2006-07-07, 9:58 pm |
| "David Lightstone" <david._NoSpamlightstone@prodigy.net> wrote in message
news:nWqrg.192$2v.182@newssvr25.news.prodigy.net...
> "AndrewMcDonagh" <newsamd@amc.com> wrote in message
> news:e8k3no$tkb$1@news.freedom2surf.net...
>
RJ>Yes. I've personally seen it work on IT projects, in web development
RJ>projects,
RJ> in the creation of software products for sale, and in a number of other
RJ>areas.
RJ>My colleagues in the Agile community report successes in many other
RJ> areas such
RJ> as mathematical research projects, embedded medical and telecomms, and
RJ>even a bit of stuff at NASA.
[color=darkred]
[color=darkred]
[color=darkred]
[color=darkred]
> There is an expression I like to remember when I read articles such as
that
> one. It goes something like - When you stand on the shoulders of giants it
> is best to be humble.
> What pray tell is the big deal here? You have a massive waterfall or Big
Up
> Front Design (BUFD) project (implement GSM). You see a little itty-bitty
> activity within that BUFD project, conduct an Agile type implementation
and
> you taut it as a poster child for Agile development.When you stand on the
> shoulders of giants is most definitely applicable. T
> As far as I can tell the must important information in the entire paper is
> "This material is based upon work supported by the National Science
> Foundation under Award Number DMI-0110460, Amendment No: 001". Other than
> to implement GSM there has to be a reason for the funding decision. It is
> not obvious to me. I would like to know that reason
For me, the picture of the kit was more telling.
Looked like a micro-cell at best.
> On any International Communication task such as a GSM or UMTS development
> the things other than pair programming would be ground zero preconditions
> for even considering the project. If you don't have compatibility, you
can't
> sell. You establish compatibility by passing the well formulated tests
that
> the international community has negociated as being the standard for
> acceptability.
And here is the killer ... there are no tests !!!
When I first started work on UMTS in 1999, there was nothing like what
there is now for UEs etc (3GPP 34.108, 34-123x etc) .
And the customer (a real one, Vodafone, you may have heard of them)
certainly had nothing other than generalities (the radio plane configs
they wanted to use for CS/PS services etc, requests to conform to the
current versions of the stds as best one could and still get kit out) .
And the 3GPP (the requirements source) were changing their stuff massively
on a quarterly basis (not often you can prove this, but masochists can go
the 3GPP website and do diffs on all the docs from one quarter to the next -
1999 to 2001 - all x0,000 pages of them :-) ) .
Same thing is happening now.
Try the current WiMAX Forum specs.
And then find me all the protocol test cases (abstract, TTCN etc) that
describe conformance for the ASN Gateway, and basestation.
Regards,
Steven Perryman
| |
| David Lightstone 2006-07-07, 9:58 pm |
|
"Peter Little" <peter@glendenecc.fsnet.co.uk> wrote in message
news:e8m5fu$rgg$1@nntp.aioe.org...
> "David Lightstone" <david._NoSpamlightstone@prodigy.net> wrote in message
> news:nWqrg.192$2v.182@newssvr25.news.prodigy.net...
>
>
>
> RJ>Yes. I've personally seen it work on IT projects, in web development
> RJ>projects,
> RJ> in the creation of software products for sale, and in a number of
> other
> RJ>areas.
> RJ>My colleagues in the Agile community report successes in many other
> RJ> areas such
> RJ> as mathematical research projects, embedded medical and telecomms, and
> RJ>even a bit of stuff at NASA.
>
>
>
>
> that
>
> Up
> and
>
>
> For me, the picture of the kit was more telling.
> Looked like a micro-cell at best.
>
>
> can't
> that
>
> And here is the killer ... there are no tests !!!
The example is GSM, not UMTS. Second generation wireless, not 3rd .
>
> When I first started work on UMTS in 1999, there was nothing like what
> there is now for UEs etc (3GPP 34.108, 34-123x etc) .
It is difficult for me to believe that the starting point for their GSM
development was any less well developed than your current UMTS developing
point. That is something like the UEs that you now have, only on day 1. I
can not say if there are fully developed test suites for the various
protocals. I would expect that by now test equipment would exist for the
Layer 2 and Layer 3 protocols. Its not my current skill set. Did once work
X.25 (1991) we most devinitely had Layer 1 and Layer 2 analyzers and tests
suites (developed as a comercial product by HP)
>
> And the customer (a real one, Vodafone, you may have heard of them)
> certainly had nothing other than generalities (the radio plane configs
> they wanted to use for CS/PS services etc, requests to conform to the
> current versions of the stds as best one could and still get kit out) .
Fortunately you only had to understand the standards rather than write them
>
> And the 3GPP (the requirements source) were changing their stuff massively
> on a quarterly basis (not often you can prove this, but masochists can go
> the 3GPP website and do diffs on all the docs from one quarter to the
> next -
> 1999 to 2001 - all x0,000 pages of them :-) ) .
I have no doubt that the requirements are massive and changing. I will bet
that Vodafone was hopping mad each time the standards changes. I will also
bet that the system architecture was quite stable (ie no need for massive
refactoring, the prefered? Agile strategy for dealing with change). Anything
other than a well thought out architeture would be ignoring the history of
the industry
>
>
> Same thing is happening now.
>
> Try the current WiMAX Forum specs.
> And then find me all the protocol test cases (abstract, TTCN etc) that
> describe conformance for the ASN Gateway, and basestation.
I do not have extensive experience with UMTS, just a little device driver
that managed both transmitter control and transmit power for a WCDMA handset
chip set. (the time sensitive algorithms were done in the ASIC that the
driver controller, so I was able to avoid a systematic reading of the
applicable specification. My lead was kind enough to have both summarized
the things I really neaded to understand, and to highlight that applicable
sections of the specification) As tasks go, probably no big deal. Didn't get
directly involved with the Layer 2 or Layer 3 type stuff.
The RF guys did have access to a rather expensive (> 100k) Anaritsu
(probably spelled wrong) layer 1 (physical layer) message packet decoder.
(this would be in 2005). You don't build those kind of tools on a whim. You
don't buy those kind of tools on a whim. Somebody must have decided that the
physical layer protocols were stable.
The guys developing layer 2 and 3 seems to be working from a well developed
game plan. That is they had three activities to address
(1) Develop algorithms
(2) Develop algorithm tests (Unit level)
(3) Develop chip set validation suite (ie simulate a base station, use the
simulation capabilities to run the various protocol exchanges)
I guess you probably could call it test driven, it certainly was not Agile
(the development was well planned, they knew what I would be implementing
before I arrived, I was told on day 1, but probably didn't understand
enough to appreciate how well things were thought out for about 2 ws).
As a risk managment stategy we did a daily full regression tests of all code
developed (validation suite, unit tests and production intent). Change a
test or change an algorithm incorrectly and yo | | |