Quali buone pratiche, se ce ne sono, hanno perso il movimento agile?

Question

Sono molto tempo agile sostenuto, ma una delle cose che mi preoccupa su Agile è che un sacco di operatori agile, soprattutto i più giovani, hanno buttato fuori o stanno manca un sacco di bene (non Scrum, non XP) pratiche. Mi viene in mente lo stile di scrittura di Alistair Cockburn Use Cases; gli array ortogonali (test a coppie) sono un altro.

ho letto i libri relativi per lo più agili e articoli e lavorare con la gente per lo più Agile ... c'è qualcosa che mi manca?

Answer 1

potrebbe essere interessante in 5-10 anni di tempo per vedere come mantenibile questi sistemi sono quando nessuno scrisse il motivo per cui una particolare decisione è stata fatta e tutte le persone coinvolte hanno lasciato.

Answer 2

(...) hanno buttato fuori o mancano un sacco di buone pratiche (non Scrum, non XP).

Scrum non è prescrittivo, sta a voi scegliere come fare le cose. In altre parole, nulla ti costringe ad usare User Stories ad esempio (anche se le User Story funzionano per molti team, non c'è consenso) quindi sentiti libero di usare (leggeri) casi d'uso se ritieni che siano più appropriati nel tuo contesto . Per illustrare questo, Jeff Sutherland ha riferito che non avrebbe mai più utilizzato User Stories per i progetti di dispositivi PDA (usano una sorta di "specifiche di luce" nella sua attuale azienda). E lo stesso vale per i test, usa quello che funziona per te. Per riassumere, se trovi XP non abbastanza flessibile, usa qualcos'altro ... e ispezionalo e adattalo.

Answer 3

Sviluppo iterativo.

In pratica, i team agili possono eseguire iterazioni (o qualsiasi altra cosa, l'agile è una sorta di "vero scotsman"), ma i processi agili non richiedono o definiscono sufficientemente lo sviluppo iterativo.

Prendere RUP, ad esempio - goffo e gonfio, lo fa compilare alcuni buoni metodi per lo sviluppo a lungo termine che manca agili.

---

In linea generale, agile è un modo per evitare di problemi: come evitare la pianificazione a lungo termine, come mantenere le squadre piccole, le attività a breve, i clienti coinvolti, ecc Funziona il più delle volte, ma a volte devi affrontare e risolvere i problemi: come raggiungere una scadenza rigorosa, fare un grande lavoro di squadra, raggiungere obiettivi lontani e complessi, rendere i requisiti di affinamento dei clienti. Quello è quando uno ha bisogno di guardare oltre agile.

Answer 4

c'è qualcosa che mi manca?

Sì, penso molto, ma solo se siete interessati ai processi di sviluppo di Softawre.

mi piace questa parafrasi:

Ogni progetto deve essere il più agile possibile, ma non più agile.

Non tutti i progetti possono essere agili ... ma penso che l'80% + possa.

vedo Agile come "car of the year". È molto adatto per la maggior parte delle persone, ma se hai bisogno/vuoi qualcosa di speciale, ad esempio un'auto in grado di accelerare 300 km/h o un'automobile in grado di trasportare 20 tonnellate di merci hai bisogno di qualcos'altro.

Ci sono anche così tanti casi in cui si può desiderare qualcos'altro che "macchina dell'anno" che richiede un libro per scriverli :-) Vi raccomando Agility and Discipline Made Easy: Practices from OpenUP and RUP. In questo libro troverai molte "parti mancanti" molto ben illustrate. La chiave per capire è che l'Agilità è solo una proprietà (richiesta) del processo di sviluppo del software che a volte non può essere raggiunta. Il libro descrive diversi Principi di Sviluppo Chiave (che sono la base per RUP) e spiega il livello di "cerimonia" e "iteratività" derivante dal loro utilizzo a diversi livelli di adozione.

Un esempio

pratica: Automatizzare la gestione del cambiamento e il cambiamento di propagazione

Nel progetto si può richiedere la gestione molto avanzata e rigoroso cambiamento e decidere di "automatizzare la gestione del cambiamento e cambiare la propagazione" mediante l'attuazione personalizzato o riconfigurare gli strumenti esistenti e utilizzando Change and Control Board.

Effetto: questo probabilmente aumenta il livello di "cerimonia" nel progetto.