Chi dovrebbe essere l'architetto in un progetto agile?

Is it better to make such rather simple design decisions up front, even there is no need in the current situation, or do we have to change a lot in the later progress of the project?

Ritarda le decisioni architettoniche fino al più tardi possibile (ma non più tardi). In futuro saprai di più del problema in futuro di quanto non lo faresti e, quindi, probabilmente prenderà decisioni più intelligenti.

Ad esempio, immagina di voler decidere in anticipo se utilizzare MongoDB, altri NoSQL o SQL tradizionale per un progetto. Ritarda la decisione: scrivi un semplice livello di repository che salverà semplicemente i dati in memoria, o salverai i dati in un file JSON per ora, e prosegui. Alla fine dovrai sostituire questo stub con qualcosa - ma in seguito potresti sapere con più certezza in che direzione andare: "hey, tutto questo è davvero perfetto per un negozio di documenti" o "sai, Le transazioni SQL sarebbero davvero d'aiuto ".

È importante farlo in concomitanza con il concetto di prioritizzazione delle parti più rischiose della tua applicazione da sviluppare per prime - cioè, le parti che comprendi meno che dovresti fare prima di fare altro lavoro. Questo dovrebbe significare che ti ritroverai con un'architettura che si adatta alla tua soluzione, invece di forzare la tua soluzione in un secondo momento per adattarla all'architettura preselezionata.

Non intendo suggerire che ogni progetto inizi con un confronto esaustivo di ogni possibile framework web, tecnologia di storage e così via. Si spera che nella maggior parte dei progetti si possa semplicemente fare affidamento su strutture affidabili che sono state utilizzate in passato sotto la guida dell'architetto del team. Sto suggerendo che questa tecnica di ritardare le decisioni architettoniche dovrebbe essere usata quando si è di fronte a una decisione alla quale non si conosce la risposta.

Un modo per vederlo - in un progetto Agile, fai sempre architettura, invece di cercare di fare l'architettura "in primo piano". Se una coppia di programmatori (si sta programmando la coppia giusto?) Raccoglie una storia e si rende conto che richiede una discussione architettonica, dovrebbero averla. Se sentono che dovrebbero coinvolgere più sviluppatori, dovrebbero farlo. Se ciò comporta il desiderio di rimuovere alcuni debiti tecnici causati da precedenti carenze architettoniche o precedenti scarse decisioni architettoniche, ciò che abbiamo fatto è stato che gli sviluppatori scrivessero un oggetto di lavoro per questo e collaborassero con il proprietario del prodotto per programmarlo. Generalmente, spiegandolo in termini di ROI: "crediamo che la rimozione di questo debito tecnico comporterà il seguente ritorno", generalmente in termini di tempi di risposta più rapidi o cicli di sviluppo futuri più brevi.

Inoltre, come ha sottolineato un commentatore:

The project we are developing is a framework for future projects and will be reused many times in the next years.

Questo non sembra affatto agile. Sei sicuro che le tue esigenze aziendali richiedono questo genere di cose? Agile significa riconoscere che il cambiamento accade: la grande idea di questa settimana è il "fondo del backlog" della prossima settimana. Quale tecnica nelle previsioni future ti sta portando ad essere certo su quali saranno le cose per te importanti in tre mesi, molto meno 'i prossimi anni'?

Per quanto riguarda la domanda iniziale "chi dovrebbe essere l'architetto in un progetto agile", ho sempre selezionato il programmatore più esperto nel team o il programmatore che conosce meglio il codice base e gli ho dato il titolo di architetto . A volte l'architetto lascia che gli sviluppatori escano con una soluzione e guidano il processo un po ', a volte stanno facendo la chiamata. In team organizzati in questo modo, l'architetto contribuisce per la maggior parte del tempo al codice e al ruolo di "architetto" quando richiesto.

Is it better to make such rather simple design decisions up front, even there is no need in the current situation, or do we have to change a lot in the later progress of the project?

Entrambi.

Sarebbe stato meglio se qualcuno si rendesse conto che schiacciando un'altra responsabilità che la classe risultante sarebbe stata cattiva. Agile non significa nessun design, significa solo design (bene) per ciò di cui hai bisogno. Avrai sempre bisogno di una base di codice manutenibile se stai realizzando un framework per i prodotti futuri.

Detto questo, verranno fatti degli errori. I requisiti cambieranno da sotto di te quindi qualcosa che era un buon design non è più così. Quindi devi essere disinvolto nel refactoring, o almeno a documentare che il debito tecnico deve essere priorizzato per gli sprint successivi.

Stai chiedendo domande a tratti di pennello abbastanza ampio con una quantità minima di contesto. Ciò influirà sulla qualità delle risposte che otterrai.

Se hai scoperto un problema che ha violato SoC in pochi sprint dopo la sua creazione, allora YAGNI non lo ha tagliato come una scusa. Ciò significa più "consegnare qualsiasi cosa" piuttosto che fornire una soluzione gestibile.

Il proprietario del prodotto dovrebbe fornire una visione a lungo termine, in modo che il team di sviluppo nel suo complesso possa prendere le decisioni di progettazione corrette. Se la visione a lungo termine non è presente, è necessario avere una conversazione di livello più ampio, quindi tutti sanno che problemi come questo si insinueranno di nuovo. Tieni presente che non devi continuare a martellare su quel problema. Notalo, assicurati che le conseguenze siano state comprese e torni alla codifica. La prossima volta che il tipo di problema si insinua, fai notare che è stato notato qualche istante prima, risolvi il problema della pianificazione e torna alla codifica.

Se il proprietario del prodotto non è in grado di comunicare tale visione, è utile che alcuni membri chiave del team passino più tempo con il proprietario del prodotto, in modo che il team possa comprendere meglio cosa accadrà dopo.

Onestamente, questo sembra più un problema di comunicazione rispetto a un problema di metodologia di sviluppo.