Massimizza la quantità di lavoro non eseguita in Agile? [duplicare]

0

Ecco una citazione da " Principi, modelli e pratiche agili in C # "  Di Micah Martin, Robert C. Martin

  1. Simplicity the art of maximizing the amount of work not done is essential. Agile teams do not try to build the grand system in the sky. Rather, they always take the simplest path that is consistent with their goals. They don’t put a lot of importance on anticipating tomorrow’s problems; nor do they try to defend against all of them today. Rather, they do the simplest and highest quality work today, confident that it will be easy to change if and when tomorrow’s problems arise.

Davvero non capisco.
Vuol dire che, invece di costruire un robusto motore principale che sarà in grado di gestire le funzionalità necessarie, si dovrebbe semplicemente costruire una funzione proprio davanti a noi?

Perché per quanto ne so, molto probabilmente alla fine si rivelerà inefficiente e meno flessibile.

Facciamo un esempio:

Immagina ASP.Net senza classi di controllo / WebControl di base, perché il team di sviluppo di .Net si sarebbe affrettato a eseguire immediatamente "TextBox", "CheckBoxe", "Label", ecc. Lo sviluppatore del team .Net avrebbe preso il percorso più semplice.

Non è questo che ha reso lo sviluppo dell'intero framework un vero guaio?

Qualcuno può dirmi se ho sbagliato la citazione di una regola veramente discutibile?

    
posta Serge 26.08.2015 - 12:16
fonte

4 risposte

2

Il concetto di agile è che le cose cambiano. Quindi, se passi molto tempo a lavorare su un super-motore, quando hai finito e è pronto per l'uso, i requisiti o la tecnologia potrebbero essere cambiati e dovrai ricominciare da capo.

In realtà non è probabile che accada, ma i requisiti cambiano. La metodologia così agile funziona sul principio di far funzionare qualcosa e modificarlo per adattarlo, evolvendolo per essere quello che vuoi.

Ora questo può sembrare terribile, per sempre refactoring e mai finire (e alcune persone lavorano così, sfortunatamente) ma se hai qualche esperienza allora lavorerai su un progetto che può far fronte a una certa quantità di cambiamenti quando crei le versioni iniziali limitate.

ASP.NET è un brutto esempio di up-front-design dato che è attualmente in versione 6 e ogni versione è molto diversa dalle altre versioni!

È possibile che tu abbia bisogno di persone esperte per lavorare in modo efficiente in modo agile, o che le persone esperte rispondano molto meglio all'agile rispetto agli sviluppi a cascata.

    
risposta data 26.08.2015 - 12:42
fonte
3

Per usare la tua analogia .NET, il flusso per uno sviluppo agile di quei controlli sarebbe:

  1. TextBox: questa casella di testo è davvero fantastica!
  2. CheckBox: Ehi, un altro, aspetta un minuto ...
  3. Etichetta: Sì, sto vedendo una tendenza qui
  4. BaseControl: aiuta!

Essenzialmente, invece di iniziare a cercare le astrazioni e i disegni, lascia che il design emerga mentre vai. Non è che non ti stia concentrando sulla creazione di software di qualità, ma solo che non dovresti cercare di perdere tempo a prevedere ciò di cui hai bisogno e costruire framework e astrazioni fino a quando non ne hai effettivamente bisogno.

    
risposta data 26.08.2015 - 14:20
fonte
1

C'è un po 'di spazio per il dibattito, ma penso che la maggior parte della gente ne condivida l'essenza.

simplest path that is consistent with their goals

Semplice è relativo agli obiettivi. Un prototipo per il concetto .NET potrebbe essere stato costruito nel modo in cui è stato descritto, ma a un certo punto, l'obiettivo coinvolge un quadro importante che deve essere costruito con un sacco di rigore e spazio per l'espansione. In uno sviluppo agile, il casino viene riconosciuto molto prima e si ritorna al tavolo da disegno.

they do the simplest and highest quality work today

Quindi quando l'obiettivo è un "motore principale robusto" è quello che inizi a costruire. E probabilmente lo costruirai un pezzo alla volta. Se sei agile, costruisci qualcosa che funzioni ogni 2-4 settimane e ripeti.

Il più semplice non sempre significa semplice. Il tuo cliente potrebbe avere le delusioni di essere il prossimo Facebook, ma quando guardi il suo budget, aggiusti i suoi obiettivi e costruisci qualcosa non abbastanza scalabile o inizia a costruire un grande sito web e non viene pagato per questo.

    
risposta data 26.08.2015 - 13:23
fonte
0

Agile non richiede un'assenza di design di alto livello. Prima che una storia possa essere elaborata da uno sviluppatore, la storia di un singolo utente è in grado di catturare completamente tutto ciò che è necessario definire prima di poter iniziare a sprintare?

As a user, I need to enter first name into a text input field on the X form, so that I can submit my first name as part of my profile information

Uno non poteva semplicemente iniziare a sprintare su questo in un vaccuum.

  • In che lingua abbiamo deciso di utilizzare?
  • Quali sono le linee guida di codifica che dovrei rispettare?
  • Quali sono alcuni casi d'uso che posso testare?
  • Lo scheletro del progetto e l'organizzazione sono stati creati?
  • Come sono organizzati i componenti software? Esiste un diagramma dei componenti che descrive le interazioni tra i componenti software?
  • Dovremmo seguire lo schema Transaction Script sul lato server o Rich Domain Model / MVC?
  • Abbiamo creato il modello di dominio?
  • Quali sono i requisiti non funzionali? Quanto velocemente dovrei ricevere una risposta? E riguardo la sicurezza? Devo fare il filtraggio XSS e disinfettare gli input?
  • Quali sono i nostri standard di sviluppo del database? Dobbiamo rispettare alcune convenzioni di denominazione sugli oggetti dello schema? Esiste un diagramma di classe che descrive la tabella del profilo utente?
  • Abbiamo un framework stabilito per il corretto test delle unità di business logic?
  • Disponiamo di un ambiente di sviluppo e di un ambiente di test adeguati, in modo che la storia possa essere testata dal QA a prescindere dalle continue modifiche allo sviluppo?
  • Abbiamo implementato l'integrazione continua in modo tale che le nostre build siano costantemente presenti e verificate in modo coerente.
  • Quando la storia ha superato i test e viene accettata dal Product Owner, abbiamo un'implementazione di Delivery continuo in modo che le modifiche del software possano essere consegnate ad altri ambienti?
  • Abbiamo il controllo del codice sorgente in atto con un adeguato controllo del codice sorgente e una strategia di ramificazione decisa?
  • Quali framework web e decisioni di progettazione abbiamo deciso? Angolare? Spring MVC, JSON sui servizi REST?
  • Sono state definite le linee guida dell'interfaccia utente, in particolare per come dovrebbero apparire le caselle di testo?
  • Sono stati implementati componenti web comuni (o devono essere implementati come parte di questa storia) per fornire correttamente questa storia per il design di alto livello e con l'obiettivo di ridurre al minimo il debito tecnico?
  • Qualcos'altro ...

Se stavi iniziando questa storia, c'è un'infrastruttura per così dire che deve esistere o che si aggrega tutta questa complessità in questa storia apparentemente piccola. È necessario per una storia che dovrebbe idealmente essere una piccola porzione verticale di un intero sistema.

As a post office customer, I want to send an overnight package from my home in Boston to my friend in San Francisco.

L'infrastruttura necessaria per questa storia è che abbiamo bisogno di un sistema di strade, un camioncino, una smistatrice postale, un aereo espresso, un aeroporto con una pista e un controllo del traffico, ecc ...

Se sembra molto, allora è perché lo è. Un'enorme quantità di lavoro è necessaria in termini di quell'infrastruttura di sviluppo che è richiesta prima che uno inizi a sprint e che fornisca direttamente valore aziendale.

Davvero non vuoi fare questo lavoro nello sprint

Dovrebbero esserci sforzi prima e tra gli sprint per affrontare e ottimizzare questi processi e lavorare.

Livelli di rischio

Il perseguimento di un prodotto minimo vitale e il refactoring costantemente alle mutevoli esigenze aziendali sono essenzialmente una soluzione di rischio. Potresti dedicare molto tempo allo sviluppo di una soluzione Cadillac per far girare il business e dire che in realtà avevano bisogno di una barca per tutto il tempo.

Pensa che sia un'assicurazione pagante contro lo scenario del disastro. Passi due settimane e sviluppi uno skateboard. Quindi spendi un altro e sviluppa e impennata elettrica. Gli affari decidono di volere veramente una barca, buttano via l'impennata e creano una tavola da paddle nel prossimo sprint. Sei giù per il tempo trascorso su un inutile skateboard e impennata, ma ti sei impedito di sprecare un sacco di tempo a costruire il Chasis di alta qualità per una Cadillac.

Sì, è una cosa che fa schifo lavorare duro su qualcosa che probabilmente verrà buttato via in un mese, ma ricorda,

Non riguarda lo sviluppatore!

La tua capacità di lavorare su stupendi software di alta qualità e di orgoglio per il tuo lavoro non è garantita. Non importa. L'unica cosa che conta è ciò che desidera il proprietario del prodotto e fornire un software funzionante con rapidi tempi di risposta. È così.

    
risposta data 26.08.2015 - 15:51
fonte

Leggi altre domande sui tag