Qual è il modo corretto di trattare caratteristiche simili ma indipendenti?

Le situazioni non sono sempre perfettamente prevedibili, e l'essere in grado di adattarsi rapidamente ai cambiamenti è ciò su cui si basa questa roba agile. Vuoi rilasciare valore per il tuo cliente il prima possibile, ma ciò non significa che devi dipingerti in un angolo creando un codice che sai richiederà quasi subito una riprogettazione.

Se io fossi lo sviluppatore feature-2 nel tuo esempio, dopo aver ricevuto l'incarico e imparando qualcun altro stava già lavorando su qualcosa di simile, vorrei:

• Vai a parlare con lo sviluppatore feature-1 e concorda su un ramo in cui possiamo lavorare insieme sulla logica comune. Questo potrebbe essere il ramo che ha già creato, o uno separato solo per la logica comune, a seconda di quale si sente più facile date le circostanze.
• Determina quali modifiche dobbiamo apportare al progetto corrente della logica comune per poter adattare entrambe le funzioni.
• Determina l'impatto di tali modifiche sulla data di rilascio di feature-1 .
• Se ha un impatto minimo su feature-1 , vorrei solo apportare le modifiche logiche comuni nel nostro ramo condiviso e andare avanti.
• Se ha un impatto significativo su feature-1 , farei le modifiche logiche comuni in un altro ramo e unirle dopo che feature-1 è finito. L'altro sviluppatore sarà in grado di aiutarti con questo.
• Un'altra opzione se ha un impatto significativo su feature-1 è che a volte è possibile apportare modifiche temporanee a basso impatto per rendere più facile il cambiamento di impatto immediato lungo la strada. Non fare un errore tutto o niente. Ad esempio, se si isola la visualizzazione dei dati "extra" come il linguaggio di programmazione nella propria funzione, sarà più facile renderla configurabile in seguito.

Questa è più una domanda di gestione del progetto che una domanda git.

Il migliore è creare 2 INVEST storie:

1. Implementa la logica generica necessaria per l'implementazione dei feed (logica-A). E implementa la logica per qualunque feed abbia il maggior valore. Quindi logica-B o C
2. Implementa il feed che non è stato implementato utilizzando la logica generica nella storia 1. Quindi sia la logica B o C

Quindi pianifichi la storia 1 in uno sprint / release prima di pianificare la storia 2. Il lavoro sulla storia 2 non può iniziare fino a quando la storia 1 non è finita, quindi dovresti pianificarla in una versione successiva alla pubblicazione della storia 1. La storia 1 è una dipendenza della storia 2. E come tale se la storia 1 non è finita per qualsiasi motivo blocchi la storia 2.

Quindi, se la storia 1 non rilascia la versione 1 e viene spostata nella versione 2. Sarai obbligato a spostare la storia 2 alla versione 3. E questo continuerà finché la storia 1 non sarà terminata.

Il motivo per cui è necessario implementare la logica comune nella stessa storia. È perché al momento dell'implementazione corri nei casi limite che non avevi previsto sviluppando la logica comune.

Costruire la logica comune per prima cosa senza implementarla non è INVESTA perché non aggiunge valore. Lavorare in questo modo aumenta il rischio di over-engineering e l'aggiunta di funzionalità non avrai bisogno di

Se viene rilevata la dipendenza mentre entrambe le funzionalità sono in fase di sviluppo. La migliore pratica consiste nel mettere una di queste funzioni su impedito e mettere in pausa lo sviluppo di quella funzione.

Presumo che feature2 sia arrivato prima che fosse stato fatto troppo lavoro su feature1. Altrimenti è necessario finire prima feature1. Ma se hai il lusso di scegliere ... Dare priorità a feature1 e feature2 in base a quanto valore aggiungono al progetto. Aggiungi logicA nel modo in cui beneficia della funzione che stai aggiungendo per prima. Va bene per lo meno essere consapevoli del fatto che userete logicA per un'altra caratteristica, ma non impazzire. Completa la prima funzione, quindi la logicaA sta guadagnando la massima quantità possibile di valore (perché hai dato la priorità alla funzione più preziosa). Logica RefactorA se necessario per implementare l'altra funzionalità. Questo guadagna il maggior valore possibile.

Dopo aver codificato la prima funzione, hai la possibilità di decidere se il costo della logica di refactoringA è troppo alto e non fare la seconda caratteristica a meno che non diventi più preziosa. Sai di più su logicA. Forse la tua paura di non poter riutilizzare la logica A è infondata. Hai anche esperienza nell'implementazione di logicA. Quindi, se devi rifattorizzare o riprogettare completamente la logica A, puoi farlo da un punto di vista della conoscenza, piuttosto che provare a progettare la logica A per qualsiasi uso immaginabile dal punto di vista di una reale conoscenza dei casi d'uso.