₦airaland Forum

i will revert to the old theme for sure

plenty stock fish abi

i laugh in kung fu

Ghenghis:
Wish there was a picture of xp in there, would probably look like lean.
Notice there's less opportunity to add something once an planning has started in water fall (Even iterative waterfall).

Lean looks crazy though  , I've not delved into it as much as scrum and XP.

Lean is the next evolution of agile madness 

I like it though. i use lean practices like kanban, cadence, WIP  and they seem to work to some extent

Ghenghis:
A customer rep is just a poor man's version of the customer however it suffices. Its not really an issue if the rep knows enough about the customer's operations. That's why a large company can employ people with 20+ years banking experience to help develop banking apps etc.

But one key differentiation between the methods are release, once something is released its not coming back! (That's how it should be). So yes you have to go into production else you're still reviewing.

Exactly !!

Iterations are short time frames (timeboxes) that typically last from one to four weeks. Each iteration involves a team working through a full software development cycle, including planning, requirements analysis, design, coding, unit testing, and acceptance testing when a working product

An iteration is just like iterative waterfall. Some of these agile folks just like confusing themselves and other people.  see diagram provided above

An iteration might not add enough functionality to warrant a market release, but the goal is to have an available release (with minimal bugs) at the end of each iteration.[9] Multiple iterations might be required to release a product or new features.

Very true  but then this also is the case in Iterative waterfall the only difference is that in Iterative waterfall you get the solution to PRODUCTION which i thought was the main purpose of agile in the first place.

logica:
Jezuz. What is it that you don't understand here? OK I'll break it down to you.

Company XYZ sells a software package called DullSoft. XYZ has a Sales/Marketing Department and the department is headed by a seasoned seller who has spent donkey years on the field meeting clients and knows the software and client needs more than anybody else and as a matter of fact provided most of the requirements of the software.

In developing the next release of DullSoft, the team is using Agile. They release frequently and the head of the Sales/Marketing Department is a stakeholder and has access to the deploy site (a web app). This means this person is essentially a "customer" or using the term Agile knows him by, he is the Customer Representative. The software is not released till it has reached reasonable completion and that is when the end-users can have access. But the Sales/Marketing Department Head already has a few buddies in one of the end-user companies who were given access to this incomplete product. They are able to but access is restricted to just these select few who are no more than testers. Capishe?

what you have described is just an iterative version of waterfall.

A customer representative in your sales and marketing department can NEVER be a substitute for the real users of the system

As long as the software is not in PRODUCTION for us to constantly evaluate how the REAL users are using it and finding and fixing bugs, then it is not "Agile"

logica:
Once again, customer == stakeholder is always true but customer == end-user is not always true. I'll leave it at that.

And it seems you assume Agile does not allow for design/modeling. You may be quite wrong there.

actually agile sees the equation this way

customer == end-user + project sponsors. so customer is always and end user and some other people ,

stakeholder = end-users + development team +project sponsor +shareholders etc. stakeholders is everybody who will benefit from a good software


ok well agile discourages rigorous design/modelling which is fine for small to medium projects IMHO but absolutely essential in complex systems.

the main idea behind agile is that you DELIVER working software even if all the features are not complete.

the argument is that when d customer uses the software they can change their minds about what they want (FEEDBACK)

the idea is to shorten the FEEDBACK loop and ensure the customer stirs the efforts of the development team to what they really want

From the Agile manifesto:

Twelve principles underlie the Agile Manifesto, including:[7]
Customer satisfaction by rapid delivery of useful software

Welcome changing requirements, even late in development
Working software is delivered frequently (weeks rather than months)

[b]Working software is the principal measure of progress
[/b]Sustainable development, able to maintain a constant pace
Close, daily co-operation between business people and developers
Face-to-face conversation is the best form of communication (co-location)
Projects are built around motivated individuals, who should be trusted
Continuous attention to technical excellence and good design
Simplicity
Self-organizing teams
Regular adaptation to changing circumstances

logica:
Not quite correct. An Agile release does not necessarily mean the application is ready for prime-time. It's merely a release that allows the stakeholders to view the work in progress, up until completion. That release is not meant for viewing or use by the end customers. I do not expect a software being developed using the Agile methodology to be made accessible to customers till the entire work is complete.

ehm. i think you are contradicting your self here.

so if i build a software under agile it should not be accessible to end users until the whole features are complete . . . that sounds like grandaddy waterfall sir

delomos:
^^ this gent continues to speak my mind BECAUSE these are war stories (I have mine too) not an academic debate. So can you answer that question: Who do you know that currently uses waterfall ?

my guy iterative waterfall != agile .

it is iterative building of core functionality but which distinct SLDC phases.

in agile (XP) you just start coding like an  iidiott without any up front design. relying on TDD to guide ur design. you can't do that in a complex  system like a core banking app. it will be disastrous  

although scrum folks will say they do some element of design but at the end of the day it looks like iterative waterfall to me

who currently use waterfall ? u will be surprised that most of the people who claim to be doing agile are actually doing an iterative version of waterfall.

Agile is just an lazy excuse for not writing documentation and not doing proper design. anyone who hides behind agile is just a lazy code monkey

csharpjava:
@Ghenghis  and delomos
I feel I should not have use an internet banking website as my example above, because in reality this can be developed incrementally to intergrate with the banks existing software system. But if a bank is starting for the first then an Iterative Waterfall Methodology is the best method to be used for developing its main banking application.

correct. an iterative waterfall method would suffice for such complex system. Agile will be a disaster.


am sure this will soon degenerate into an agile vs waterfall war . . .


there are situations whereby it makes absolute sense to use waterfall . . yes

and there are occasions whereby u will be daft to use waterfall

@topic

There is always something new. a decade ago the fade was CMM now the fade is Agile. . . .

Am sure in d next 5 yrs. there will be another fade. i hear a lot about Lean development these days

We software practitioners like fades a lot.

And all these fads a a mere rehash of old ideas in new fancy names.  Iterative development has been done in IBM since the 60's

oga ajanlekoko u no dey respond to my yim hope everything is good

hmm , nobody is talking about flip fones these days. i remember back in the days they were pretty fashionable

na wa o

swit D u did not get in touch as promised