Data Science
I confini sono essenziali nella società moderna: semplicemente non posso occuparmi di tutto. Ma quali sono i confini ragionevoli nello sviluppo del software? Ogni astrazione, un elemento fondamentale per lo sviluppo di un buon software, non è forse un confine?
Soprattutto quando un progetto si trova in difficoltà, tutti prendono le distanze e si lanciano accuse: il team di sviluppo non ha consegnato, l'analisi non è stata abbastanza precisa, il project management ha perso la visione d'insieme e il cliente ha perso la misura. La delimitazione può significare responsabilità, ma anche ritiro.
In confronto alla Galleria di Base del Gottardo, la maggior parte dei progetti sono piuttosto piccoli. Eppure Peter Jedelhauser, responsabile generale del progetto per l'asse nord-sud del Gottardo presso le FFS, alla domanda se sia stato difficile distinguersi [intervista in Credit Suisse Bulletin, n. 2/2016, p. 19], afferma:
"Cerco di evitare questa parola. Pensare per intersezioni è più efficiente che pensare per unità separate. Se due persone si separano, la possibilità che qualcosa cada tra il tavolo e la panca è estremamente elevata."
Le squadre che si delimitano chiaramente creano spazi intermedi. I problemi si collocano tra la "sedia e la panchina":
Le squadre che si sovrappongono appaiono come un'unità compatta:
In questo modo non solo si risparmiano risorse, ma anche coordinamento e quindi ore improduttive. I dipendenti sono anche più felici perché hanno più responsabilità e influenza sull'intero progetto.
Solo i progetti molto piccoli operano su un solo turno. Tuttavia, il team di analisti, sviluppatori e tester deve comprendere tutti i turni e la loro interazione (Full Stack Developer(apre una nuova finestra)). Un ottimo strumento in un turno non serve a nulla se solo poche persone lo capiscono e lo sanno usare.
L'architettura deve quindi essere all'altezza del team e delle sue competenze: Con un gruppo medio, puoi arrivare a valle più velocemente sulla pista blu o rossa che su quella nera. Con esperti che hanno 10.000 ore di esperienza, puoi dominare i terreni più difficili. Tuttavia, questi esperti spesso prediligono la semplicità perché sanno che qualcuno con meno esperienza dovrà in seguito provvedere al sostentamento del software.
I turni non solo gonfiano la Resolution, ma anche i team. Il che richiede anche un turno di gestione per il coordinamento. Quindi, meno turni e team che abbiano responsabilità end-to-end.
L'impossibilità di definire in anticipo i requisiti di uno sviluppo complesso ha portato ai metodi agili e alla prototipazione. La distinzione tra analisi (con competenze nel dominio) e sviluppo (con competenze informatiche) rimane complicata. O un requisito viene trasposto strato per strato in un progetto che può essere implementato da qualsiasi sviluppatore (e quindi delimitato), oppure analisti e sviluppatori cercano di capirsi e di lavorare fianco a fianco ("Pair Analysis & Programming").
La comprensione reciproca richiede una conoscenza dello sviluppo da parte dell'analista e una conoscenza del dominio da parte del programmatore. Nella mia esperienza, questo è un must, altrimenti lo sforzo esplode immediatamente.
Un prerequisito per il successo dello sviluppo di una coppia è anche la rapidità dei risultati, motivo per cui prediligo le lingue interpretative e dinamiche. Un meccanismo di distribuzione che mostra i risultati solo dopo molti minuti (o addirittura ore!) non è efficiente e rappresenta un disastro per un progetto.
Migliorare uno sviluppo scadente attraverso i test comporta un'immensa quantità di lavoro. Se più di un paio di test manuali falliscono, la causa deve essere eliminata o almeno i test devono essere automatizzati. Questo è il compito dello sviluppo, end-to-end del sistema globale. I test e il debug con feedback immediato devono essere possibili con dati reali (o almeno realistici). I "dati fittizi" portano a delle illusioni e dovrebbero essere evitati.
I tester professionisti devono trovare le eccezioni e scoprire le lacune, non discaricare gli sviluppatori. Un bug trovato dai test è una sconfitta per lo sviluppo!
I ruoli di pollo e maiale (Chicken and Pigs(apre una nuova finestra)) nel Process Scrum non hanno senso, perché creano una demarcazione dove non dovrebbe esserci, tra clienti e fornitori. Nel peggiore dei casi, questo porta a piccole aree di gioco ben definite con molte storie che vengono elaborate e chiuse in modo celere e ordinato senza che il progetto complessivo faccia progressi significativi. Naturalmente i maiali si mettono in sicurezza e ricercano la ragione nei polli: Analisti, fornitori esterni, altri componenti dell'architettura, tester, ecc.
È difficile essere agili. I contratti sono statici, così come i livelli di gestione. È importante che il processo di Scrum si svolga nella realtà del progetto piuttosto che in una divisione. Scrum è uno strumento, non un sostituto della leadership. La leadership deve chiarire dove è consentito il pianificatore agile, dove sono le condizioni statiche del quadro di riferimento e come queste vengono affrontate.
Ora abbiamo NoSQL(apre una nuova finestra) database, che sono dinamici e quindi non hanno più bisogno di progettare schemi! Integrità aziendale, addio!
Titolo! La modellazione dei dati rimane l'elemento fondamentale per uno sviluppo di successo, soprattutto in un settore ricco di dati. Non dobbiamo dimenticare le lezioni apprese nella programmazione orientata agli oggetti, come l'astrazione, l'incapsulamento e i metodi. NoSQL e JSON sono ulteriori strumenti a nostra disposizione. Meno repliche (DRY(apre una nuova finestra)) e trasformazioni sono il loro vantaggio. Se questo rende anche l'architettura più semplice, tanto meglio.
Con una modellazione pulita dei dati, otteniamo una migliore comprensione tra analisti e sviluppatori - e quindi un software che sia privo di errori in fase di progettazione e non solo di test.
Le barriere spesso forniscono zone di comfort dove un sottogruppo può ritirarsi.
Pertanto:
Questo metodo si è dimostrato valido in uno dei nostri progetti. Quali sono le tue esperienze? Hai qualche controesempio in cui un'abile delimitazione ha portato al successo?
Head Application and Business Services
Trova il lavoro o il mondo della carriera che fa per te. In cui vuoi contribuire a plasmare e sviluppare te stesso.
Ciò che ne fai è ciò che ci definisce.
