Esiste un termine per "il mio progetto non può crescere a causa della metodologia utilizzata"? [chiuso]

Stai ancora parlando di capacità di scala. Stai solo parlando di una metodologia di sviluppo che non è in grado di scalare.

Esiste un'unità che alcuni tipi di gestione amano gettare in giro chiamata ora uomo . Diciamo che il progetto x ha impiegato 500 ore uomo. Un numero che potrebbe essere il prodotto di 5 persone che lavorano 100 ore o 100 persone che lavorano 5 ore. Come se quelle due situazioni producessero la stessa quantità di lavoro semplicemente perché equivalgono allo stesso ammontare di costi.

Questo tipo di pensiero è ciò che porta all'aspettativa che un progetto in ritardo possa essere rimandato nei tempi previsti aggiungendo persone. Non è vero Il lavoro e i costi non sono sempre 1 a 1. Questo cambiamento crea problemi che danneggiano la produttività, quindi qui c'è una falsa equivalenza. Non aspettarsi questo risultato è un pensiero da uomo / donna.

Il famoso libro Mythical Man-Month prende il nome da questa unità parla di questo effetto. L'aggiunta di persone in ritardo a un progetto la rallenta. I motivi che offre spazia dalla comunicazione inter-team in crescita di n (n + 1) / 2 agli sviluppatori che cercano di arrivare a mangiare il tempo di sviluppatori esperti che ora devono tenere in mano persone che rischiano di rompere la build.

Il mondo Agile crede che le squadre dovrebbero ridursi non crescere. Le nuove persone hanno bisogno di un posto sicuro per imparare cosa stanno facendo prima che contribuiscano. Hanno bisogno di accedere a sviluppatori esperti ma ciò ha un costo. Se non sei disposto a pagare, lascia che i due sviluppatori che hanno iniziato questa operazione tornino al lavoro e che tutti gli altri inizino un altro progetto.

Ora, se hai tenuto conto di tutto ciò e pensi ancora di essere rallentato da qualcosa di più di quello che potrebbero essere i tuoi primi due sviluppatori sono eroi solisti.

Lavorare su un progetto da solo semplifica moltissime cose. Se qualcosa è bloccato, lo hai bloccato. Nessuno fa il tuo lavoro tranne te. È un tipo speciale di fantastico. Tuttavia, significa che sei solo. Ogni idea stupida hai visto la luce del giorno perché nessuno l'ha interrogato. Ogni punto cieco che hai è incustodito.

Significa che non impari a lavorare con nessun altro. Hai iniziato con due persone che hanno capito come lavorare insieme. Ma lavorare con un team di 20 persone è molto diverso. Pianificare, dividere il lavoro, testare, peer reviewing, controllo del codice sorgente, integrare, implementare tutto richiede molta più disciplina in un team di 20 che in un team di 2.

E in effetti una squadra di 20 è piatta ridicola. La regola della pizza dice che se servono più di due pizze per alimentare la tua squadra è troppo grande. La mia regola generale è se parlare con tutta la tua squadra sembra parlare in pubblico è troppo grande.

18 persone non dovrebbero essere semplicemente "aggiunte alla squadra". Idealmente non coltiverai mai una squadra. Lo lasci ridurre nel tempo. Allora, dove vai se hai già iniziato con 2?

• Dividi i due sviluppatori esperti. Ciò consente loro di guidare due team diversi. Tutto ciò di cui hanno bisogno sono due aree diverse su cui concentrarsi. Idealmente si aggiungono solo 1 o 2 sviluppatori in più per questi sviluppatori esperti.

• Avvia una squadra separata. Questo gruppo di lavoro dovrebbe essere abbastanza separato da non dover incontrare costantemente gli sviluppatori esperti.

Una buona taglia per una squadra va da 4 a 8. Idealmente questo permetterà di co-localizzare in modo che possano girarsi sulla sedia e parlare con tutta la squadra senza che la gente debba alzarsi dalla sedia per vedersi facce.

A volte una squadra deve solo crescere. Quando ciò accade, è molto meno un rallentamento se il numero di nuove persone nel team è inferiore al numero di persone con esperienza.

L'IEEE ha inventato un "Modello di maturità della capacità per il software" molti anni fa, spesso definito come CMM . Anche se lo standard è piuttosto vecchio, è comunque una struttura decente per capire perché la tua squadra sembra così disfunzionale.

CMM annota cinque livelli di maturità delle capacità:

Livello 1. Ad hoc

At the Initial Level, the organization typically does not provide a stable environment for developing and maintaining software. Such organizations frequently have difficulty making commitments that the staff can meet with an orderly engineering process, resulting in a series of crises. During a crisis, projects typically abandon planned procedures and revert to coding and testing. Success depends entirely on having an exceptional manager and a seasoned and effective software team. Occasionally, capable and forceful software managers can withstand the pressures to take shortcuts in the software process; but when they leave the project, their stabilizing influence leaves with them.

Livello 2. Ripetibile

At the Repeatable Level, policies for managing a software project and procedures to implement those policies are established. Planning and managing new projects is based on experience with similar projects. Process capability is enhanced by establishing basic process management discipline on a project by project basis. An effective process can be characterized as one which is practiced, documented, enforced, trained, measured, and able to improve.

Livello 3. Definito

At the Defined Level, the standard process for developing and maintaining software across the organization is documented, including both software engineering and management processes, and these processes are integrated into a coherent whole. This standard process is referred to throughout the CMM as the organization's standard software process. Processes established at Level 3 are used (and changed, as appropriate) to help the software managers and technical staff perform more effectively. The organization exploits effective software engineering practices when standardizing its software processes. There is a group that is responsible for the organization's software process activities, e.g., a software engineering process group, or SEPG [Fowler90]. An organization-wide training program is implemented to ensure that the staff and managers have the knowledge and skills required to fulfill their assigned roles.

Livello 4. Gestito

At the Managed Level, the organization sets quantitative quality goals for both software products and processes. Productivity and quality are measured for important software process activities across all projects as part of an organizational measurement program. An organization-wide software process database is used to collect and analyze the data available from the projects' defined software processes. Software processes are instrumented with well-defined and consistent measurements at Level 4. These measurements establish the quantitative foundation for evaluating the projects' software processes and products.

Livello 5. Ottimizzazione

At the Optimizing Level, the entire organization is focused on continuous process improvement. The organization has the means to identify weaknesses and strengthen the process proactively, with the goal of preventing the occurrence of defects. Data on the effectiveness of the software process is used to perform cost benefit analyses of new technologies and proposed changes to the organization's software process. Innovations that exploit the best software engineering practices are identified and transferred throughout the organization.

Senza strumenti di compilazione automatici e simili, mi sembra dubbio che la tua organizzazione potrebbe persino raggiungere il livello 2. Quindi, se stai cercando un termine, potresti dire che il tuo team è impantanato in CMM Livello 1 .

Se fossi severo, chiamerei una situazione come questa in cui il progresso viene ora bloccato da un calo a lungo termine della "cattiva gestione" della produttività. Il compito principale del manager è quello di assicurarsi che gli ostacoli al progresso vengano rimossi, e non sembra che questo sia successo.

Ciò che in realtà lo chiamano non ha molta importanza: il team deve investire tempo per far funzionare di nuovo il processo di sviluppo, e questo costerà ai soldi dell'azienda.