Dove si trova l'onere della responsabilità e del supporto di componenti / servizi condivisi?

1

Questo è un problema che è stato in qualche modo sollevato dall'incidente sinistro con NPM, ma mi interessa anche da una prospettiva aziendale interna.

Ad esempio, immagina un'organizzazione con 3 squadre, A, B e C. Team A costruisci un componente per il loro sito, si adatta perfettamente alle loro esigenze perché l'hanno creato da solo. La squadra B ha requisiti molto simili, quindi decidi semplicemente di integrare il componente nel loro sito. La squadra C non adotta il componente.

Ora alcuni mesi dopo la squadra A modifica il componente per un nuovo requisito, tecnico o meno, e ciò interrompe l'implementazione del componente da parte del Team B.

La squadra B ha il diritto di chiedere alla squadra A di supportare una versione legacy? La squadra B dovrebbe forgiare il componente e personalizzarlo solo una volta che è stato rotto, o dovrebbe averlo fatto in un primo momento, nel caso in cui?

Per rendere le cose più complicate, immagina che non siano componenti ma servizi dal vivo, quindi ora la Squadra A ha interrotto il sito dal vivo del Team B. In che modo ciò influenza lo scenario?

È solo interessato a vedere dove le opinioni delle persone dipendono da modelli di responsabilità e di supporto in una comunità open source, pubblica o privata.

    
posta Joe Hart 02.08.2016 - 15:07
fonte

1 risposta

1

L'onere della responsabilità dipende in ultima analisi da chi è responsabile del coordinamento del lavoro di queste squadre. (Qualcuno in ogni compagnia è responsabile per questo, che lo riconoscano o meno.)

Da un punto di vista tecnico, la squadra B avrebbe dovuto informare il team A che stavano usando il componente del team A. Normalmente ciò renderebbe la squadra A piuttosto orgogliosa di se stessa. Successivamente, la squadra A avrebbe dovuto considerare le proprie API come pubbliche, evolvendole in un modo compatibile con le versioni precedenti il più possibile, avvalendosi di convenzioni come versioning semantico aiutare il team B a stabilire le proprie aspettative e deprecare le funzionalità obsolete prima di rimuoverle per aiutare il team B a pianificare in anticipo.

    
risposta data 03.08.2016 - 05:59
fonte

Leggi altre domande sui tag