Separazione delle responsabilità di sviluppo in un nuovo progetto

Naviga le tue risposte
0

Di recente abbiamo avviato un nuovo progetto (MVC 3.0) e alcune delle nostre discussioni iniziali riguardavano il modo in cui il lavoro e lo sviluppo saranno suddivisi tra i membri del team per garantire che ci sia la minima quantità di sovrapposizione di lavoro e quindi di aiuto renderlo un po 'più facile per ogni sviluppatore andare avanti e fare il loro lavoro. Il progetto dovrebbe durare circa 6 mesi - 1 anno (anche se non tutti gli sviluppatori potrebbero essere attivi e potrebbero filtrare verso la fine),

Il nostro team sarà piccolo, quindi questo mi aiuterà un po 'a credere. Il team sarà essenzialmente composto da:

  • 3 x sviluppatori (tutti i diversi livelli, ovvero più senior, intermedio e junior)
  • 1 x project manager / product owner / tester
  • Una società esterna responsabile per il nostro lavoro di progettazione

Le decisioni generali di progetto / sviluppo finora hanno incluso:

  • Sviluppa in modo agile utilizzando le tecniche SCRUM (stiamo ancora imparando molto questo approccio come azienda)
  • Utilizza l'architettura MVVM
  • Utilizza Ninject e DI se possibile
  • Tenta di utilizzare il TDD il più possibile per guidare lo sviluppo.
  • Mantieni i nostri controllori più magri possibile
  • Mantieni le nostre opinioni il più semplici possibile

Durante le nostre discussioni sono stati affrontati due approcci, oltre a come separare il carico di lavoro in relazione ai nostri obiettivi descritti sopra.

OPZIONE 1 : Una separazione quadro in cui ogni persona è responsabile delle aree concettuali con sovrapposizione e discussione principalmente nelle aree di integrazione. Le aree di integrazione sarebbero responsabili di entrambi gli sviluppatori, come richiesto. 

View prototypes (**Graphic designer**)
         |
          - Mockups      
         |
Views (Razor and view helpers etc) & Javascript (**Developer 1**)
         |
          - View models (Integration point)
         |
Controllers and Application logic (**Developer 2**)
         |
          - Models (Integration point)
         |       
Domain model and persistence (**Developer 3**)

OPZIONE 2: Un approccio più orientato ai compiti in cui ogni persona è responsabile del completamento dell'intera attività (storia) da vista - > controller - > modello .

DOMANDA: Per coloro che hanno lavorato in piccoli team nello sviluppo di progetti MVC, come hai gestito la distribuzione del carico di lavoro in questa situazione. Non riesco a immaginare che il giovane sarebbe responsabile della costruzione di parti dell'architettura sottostante, quindi darebbe loro la responsabilità della vista, considerando che stiamo cercando di mantenerlo semplice?

    
posta dreza 23.11.2012 - 21:45
fonte

2 risposte

1

L'opzione 2 sembra molto meglio per lo sviluppo agile. Non riesco davvero a vedere come l'opzione 1 possa funzionare con agilità. Quindi, se stai privilegiando l'opzione 1, allora dovrei chiederti se stai davvero agendo.

Gli svantaggi che hai menzionato non sono davvero problemi e se pensi che siano problemi, dovresti correggere qualcosa di diverso dalla "sovrapposizione" del lavoro degli sviluppatori.

  1. Se l'intento dello sviluppatore non è ovvio dal codice, allora questo codice ha sicuramente bisogno di refactoring.
  2. Esistono strumenti per controllare e applicare le convenzioni di codifica. ReSharper per esempio.
  3. cosa?
  4. Succede sempre, non importa dove, come e chi. Devi solo assicurarti di avere presto modo di cogliere questi problemi (programmazione della coppia, revisione del codice, molti tester) ed essere in grado di risolverli in modo efficiente (test dell'unità)

In realtà, potresti combinare entrambe le opzioni in qualche modo. Prendi la programmazione delle coppie, dai alla coppia una funzionalità da implementare e poi ogni persona può lavorare su diversi "livelli". Ovviamente questa non è una vera programmazione di coppie. Ma ottieni comunque dei vantaggi della conoscenza condivisa di questa funzionalità, una migliore copertura di "cosa succede se", la coppia può aiutarsi a vicenda e le persone possono ancora in qualche modo specializzarsi.

    
risposta data 23.11.2012 - 22:12
fonte
1

La tua domanda è abbastanza vaga; Non sono a conoscenza di ciò che stai cercando veramente di chiedere.

È: "Il modo migliore per evitare sovrapposizioni nel nostro progetto" o "La migliore pratica per ottenere molta produttività con una minima sovrapposizione / benefici nel nostro progetto?"

Supponendo che tu chieda di un modello e di una pratica; Potrei dire ... Architettura orientata ai servizi che utilizza Windows Communication Foundation. Fornirà flessibilità, estensibilità e astrazione se viene utilizzata correttamente.

Questo può aiutare ogni sviluppatore a concentrarsi su una particolare attività; senza sovrapposizioni. Quindi può organizzare il compito in modo abbastanza efficace.

Un esempio davvero carino qui .

Noterai che esso astrae diversi aspetti per la riutilizzabilità. Quindi un esempio con un prodotto e un ordine.

Avrai il tuo:

  • Livello dati
  • Livello aziendale
  • Modello
  • Contratto
  • servizio
  • Host
  • Proxy
  • Client

Che sembra abbastanza. Tuttavia in realtà non lo è se abbinato a tecniche efficienti. Per spiegare la maggior parte di questo approccio -

Il tuo modello conterrà il tuo oggetto; questo oggetto sarà in grado di essere esposto al tuo cliente. Il contratto fornirà all'interfaccia la tua implementazione; che può essere suddiviso in base al compito. Quindi il servizio generale; che fornirà l'implementazione del metodo.

Secondo l'approccio adottato; ti consentirà di ospitare il progetto tramite Internet Information System, il servizio di attivazione di Windows e di comunicare su una vasta gamma di tecnologie con un assortimento di sicurezza.

Il vantaggio di questo approccio implementerà anche alcune tecniche che hai menzionato. Come ereditando la funzionalità di ciascun metodo; nel proxy client. Ciò rende la riutilizzabilità piuttosto piacevole e l'implementazione abbastanza pulita / facile.

Comunque, questo è il mio due centesimi. Come si inserirà nel tuo progetto- Non lo so. Come ha affermato Martin Fowler: "Frodo ha detto in Il Signore degli Anelli, non andare agli Elfi per un consiglio, perché diranno sia no che sì." Il che è perfettamente sensato, il consiglio può essere un regalo pericoloso soprattutto con una breve descrizione. Non conosciamo il tuo progetto, i tuoi obiettivi o particolari particolari di crescita. Che può rendere qualsiasi disegno o modello un incubo; soprattutto perché la nostra raccomandazione può sembrare solida, ma in realtà il tuo progetto è un grande disservizio.

In definitiva, la tua conoscenza del progetto e i suggerimenti fatti possono spingerti ad indicarti la scelta giusta.

L'articolo in questo link entrerà davvero nei dettagli e spiegherà cosa intendo per l'accoppiamento e l'utilizzo.

    
risposta data 04.01.2013 - 00:16
fonte

Leggi altre domande sui tag

Migrazione da VSS a TFS. Qual è il vantaggio di creare progetti separati? Clustering e applicazioni personalizzate