Definition of Agile

17 April, 2007 (00:03) | agile, extreme, programming, xp

Recentemente sulla mailing list internazionale dell’eXtreme Programming c’è stato un po’ di fermento sulla definizione di Agile. Si “Agile” con la “A”, in quanto giustamente si tende a differenziare una metodologia agile (conforme all’aggettivo agile) da una metodologia Agile (?). In che modo possiamo definire una metodologia Agile? Possiamo verificare se una metodologia o una sua implementazione è Agile? Possiamo misurarne il grado di Agilità?

Per quanto mi riguarda la definizione di Agile è molto semplice: Una metodologia è Agile se è conforme all’Agile Manifesto

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

Ma questo non è tutto il manifesto, questa è la bandiera, efficace e concisa. C’è una parte molto più importante, la parte dei valori e dei principi, che aiuta molto di più a capire che cosa è Agile

Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.

Welcome changing requirements, even late in
development. Agile processes harness change for
the customer’s competitive advantage.

Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.

Business people and developers must work
together daily throughout the project.

Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.

The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.

Working software is the primary measure of progress.

Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.

Continuous attention to technical excellence
and good design enhances agility.

Simplicity–the art of maximizing the amount
of work not done–is essential.

The best architectures, requirements, and designs
emerge from self-organizing teams.

At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.

Fantastico! Ma anche la versione di David Anderson vale la pena di essere citata per la sua concisione

  • enables companies to easily respond to change
  • delivers working code to market faster (than previously or with other methods)
  • delivers high quality working code
  • improves productivity
  • improves customer satisfaction
  • and provides an environment for a well motivated team with high job satisfaction

    E per il fatto di inquadrare la “tipologia” di queste metodologie

    • iterative
    • incremental
    • self-organizing
    • emergent

    Quindi, possiamo dire se una metodologia o una sua implementazione è Agile? Seguendo la definizione di Anderson potremmo chiederci

    • Is our customer satisfied?
    • Are we delivery working code to market continuously?
    • Is the code of good quality?
    • Is our team environment good?
    • Are team members motivated and satisfied?

    Il mio preferito però resta sempre l’Agile Zealot’s Handbook

    VALUE
    IF you don’t repeatedly release software
    into a production environment
    at least once every month
    that realises business value
    for a real customer…

    QUALITY
    IF you’re not paying constant attention to technical excellence
    with simple, effective, incremental design
    driven by continuous, repeatable automated testing
    with at least 95% coverage…

    LEARNING
    IF you’re not learning
    by inspecting and reflecting every iteration
    and you’re not re-planning, adapting and improving
    all of the time based on what you’ve learnt…

    TEAM
    IF your team is not empowered to self-organise and be creative,
    does not sit together and engage in face-to-face communication,
    does not include your customer
    and all the necessary skills to make its own decisions and take immediate action…

    THEN YOU HAVE COMPROMISED YOUR AGILITY

    Infine, possiamo misurare la nostra Agilità? Questo sicuramente è il punto più dibattuto perchè tira in ballo tutta la storia sulle certificazioni, attestati, associazioni, ecc… Non citerò qui altre opinioni se non la mia: non ha importanza avere una misura di quanto si è Agili (anche se esistesse, non potrebbe essere assoluta, dovrebbe comunque essere contestualizzata al team e al progetto), ha importanza sapere “Cosa possiamo fare per essere più Agili”, ovvero

    • Cosa possiamo fare per rilasciare codice funzionante più spesso?
    • Cosa possiamo fare per raggiungere gli obiettivi del nostro cliente?
    • Cosa possiamo fare per migliorare la qualità del nostro codice?
    • Cosa possiamo fare per migliorare le nostre condizioni di lavoro?

    Indipendentemente da quale sia il nostro punto di partenza, la cosa importante è migliorare continuamente il nostro processo produttivo seguendo i principi e i valori del manifesto (o quelli di XP), possiamo arrivarci utilizzando le pratiche di quella o di quell’altra metodologia, possiamo applicare la metodologia X piuttosto che Y, possiamo inventare ed adattare, la cosa veramente importante è il miglioramento continuo. Per questo io considero la retrospettiva come la “prima pratica” di una metodologia Agile

    Write a comment