Manifesto for Agile Software Development

[ErosOlmi]

http://agilemanifesto.org/
http://www.agilealliance.org/

While reading, it comes to my mind that we are following some of those principles like our "Freqent update policy". But I feel we also fail into other aspects.

Anyhow, interesting.

[neathra]

Thank you for your information.....




Agile Software Development

[Petr Schreiber]

Hehe,

we are using SCRUM at work, so far I like it.

It is very intensive, but it has positive effect that the requests of users get reviewed very often and the value or at least major increment gets delivered fast - each 14 days.


Petr

[mike lobanovsky]

Hello Petr,

Judging by the blurry content of the "messages" this Barnabas thing is disseminating here and also by its obvious necrophylic behavior thread-wise, it is nothing else but a mere automatic spambot triggered off by specific word patterns in the threads that it attacks.

[jack]

agreed, definitely a bot.

[Petr Schreiber]

I agree - I can't find him in the memberlist. I will check how to ban him once I get back from work.

Now please back on topic, agile is interesting approach to software development!


Petr

[Charles Pegge]

We canne trie to confewz the bAarnibus wit doggy speling, and cee ifit respawnz

[mike lobanovsky]

Hehe luk, itsez its nuttabot, itsa dumbarse!

[Charles Pegge]

With regard to Agile, I doubt there is a perfect solution to software development, but it is a major improvement on other methodologies based on engineering practice, where all aspects have to be planned, designed (and costed) in advance.


PS: is dum bass similar to air guitar?

[Petr Schreiber]

My knowledge of other methodologies is limited, but I like SCRUM is not just "release in cycles", but it has well distributed roles in the team:

• "product owner" - single person serving just as connection point between client and coders, prioritizes task in back log (stack of TODO items)
• "scrum master" - takes care that everybody in team has all resources needed for work, arranges meething
• "technical architect" - sets vision for product technical back end (proposes, does not force)
• "team member" - participates on the tasks, can propose alternative solutions to given problems

The work is beating in regular cycles,

The meetings, or ceremonies, are of many kinds. Can be for example:
- "retrospective" - what went wrong, what needs to be improved
- "internal review" - features of no user impact are discussed between members (relates mostly to technical debt)
- "estimation" - each task from back log is estimated by all team members for complexity (be it hours, or better, story points)
- "planning" - team decides which items goto sprint (time interval designed for task realization)

The useful thing is that the various related things, such as burndown chart and others, help iteratively increase precision of estimating team work capacity.

I think adopting Agile methodology could help improve ThinBASIC development further notably, although we already adopted many of the key points.


Petr