Posso fidarmi dell'equazione di programmazione di base?

Non penso che ci sarà una risposta a questo da qualcun altro, quindi ho intenzione di mettere la mia risposta qui:

Penso che @Ryanthal abbia ragione - Le iterazioni agili semplicemente non seguono lo stesso programma stimando l'equazione come progetti a cascata . Sospettavo che quando ho posto la domanda - avevo solo bisogno di una spiegazione sul perché.

L'equazione in pratica dice che esiste un limite rigido al numero di persone che possono lavorare contemporaneamente alla stessa cosa, e meno lavoro ci sarà, più è difficile scalare il lavoro attraverso la squadra. Lo abbiamo sperimentato su piccoli progetti: dividere il lavoro tra 2 persone è una sfida e ha un certo grado di inefficienza. Dividere più lavoro tra 3 persone è un po 'più gestibile, ma comunque difficile.

Penso che questo si applichi ancora ai progetti Agile, ma i progetti Agile compiono uno sforzo concertato ogni 2-4 settimane per affrontare questa sfida pianificando il modo in cui interrompono il lavoro per l'iterazione, con il vincolo di fornire lavoro software e lavorando in un ambiente collaborativo. Ciò consente ad Agile una maggiore libertà di scalare la squadra (almeno all'interno del agile punto debole degli sviluppatori 3-10).

È come un tradizionale progetto a cascata è un'applicazione server monolitica che può essere ridimensionata. Puoi aggiungere più memoria, ma poi ti sbagli contro un vincolo della CPU. Migliora la CPU e la memoria o il disco è il nuovo vincolo. È solo difficile da scalare e puoi imbattersi in alcuni limiti difficili. I progetti tradizionali sono vincolati a quanto efficacemente possono utilizzare le risorse disponibili per gli sviluppatori, perché il lavoro viene trattato come un unico blocco monolitico.

(In termini di risorse e programmi), Agile è più simile all'architettura di componenti server in cui ciascuno dei pezzi può essere ridimensionato individualmente, su più server. Se il componente di autorizzazione è un collo di bottiglia, avviare un'altra istanza. Puoi ancora imbatterti in limiti difficili, ma all'interno delle capacità dell'infrastruttura hai molta flessibilità.

Stai usando l'equazione per qualcosa per cui non è mai stata concepita. Ecco alcuni dei limiti dell'equazione di programmazione di base di cui si parla nel libro di Steve:

The schedule equation implicitly assumes that you're able to adjust the team size to suit the size implied by the equation.

If your team size is fixed, the schedule won't vary in proportion to the cube root of the scope; it will vary more widely based on your team-size constraints. Section 20.7, "Schedule Estimation and Staffing Constraints," will discuss this issue in more detail.

The Basic Schedule Equation is also not intended for estimation of small projects or late phases of larger projects.

You should switch to some other technique when you know the names of the specific people working on the project.

Considera due progetti A e B. Il progetto A ha una certa quantità di impegno e si stima che occorrano 1 mese. Si stima che il progetto B abbia uno sforzo 27 volte maggiore rispetto al progetto A. L'equazione sembra dirci che il progetto B richiederà solo 3 mesi.

Trovo questo ALTAMENTE controintuitivo.