Consente di realizzare un progetto di sito Web con un numero di membri del team e ha un numero di funzioni. Durante lo sviluppo, è meglio per lo stesso ragazzo fare una funzione completa (DB, Application Logic, Frontend (Javascript, HTML, CSS ecc.) O è meglio che il diverso faccia la Logica dell'applicazione e il Frontend. Nella maggior parte dei casi, DB è fatto da qualche altro ragazzo che penso. Qual è il modo consigliato per farlo.Sviluppo Web
Come per la maggior parte delle domande soggettive, dipende.
Tendo a cadere nel campo di competenze specialistiche. Nel qual caso, falli lavorare ai loro punti di forza. Meglio concentrarsi su una cosa fatta molto bene. Se vuoi che questi sviluppatori abbiano una vasta esperienza, magari ruoti i ruoli nel prossimo progetto, ma non provare a fare la roba di tutti i mestieri. Finisci con un sacco di set di abilità diluite e nessuno può scavare in profondità e risolvere i problemi particolarmente pelosi senza hackery.
Downvoter: i commenti sarebbero apprezzati. Senza di loro, tendo ad assumere che tu sia un altro rispondente che cerca di promuovere il tuo. : -/ –
La risposta a questa domanda dipende dalle persone coinvolte e dalle dimensioni del progetto.
In generale è più semplice mantenere coerenti tutti gli strati dell'applicazione se c'è una singola persona che scrive il livello (separazione orizzontale), ma con una squadra unita di buoni sviluppatori, è possibile suddividere verticalmente un progetto e organizzare il lavoro da effettive "caratteristiche".
Lavorare orizzontalmente come si suggerisce razze meno conoscenza generale dell'applicazione, dal momento che ogni dev conosce il loro livello, e non gli altri strati.
Tutti punti perfettamente bene. Immagino che ciò dipenda da quanta conoscenza di dominio necessiti e quanto tecnicamente sia impegnativo il progetto. È anche più facile suddividere verticalmente se i tuoi sviluppatori sanno come lavorare su tutti i livelli e un'autorità (come un architetto) sta dettando alcuni standard e un'architettura generale. Di nuovo, dipende interamente dalla situazione. –
Indipendentemente dal modo in cui lo si suddivide, si desidera assicurarsi che vi sia una certa ridondanza nella conoscenza e nella comprensione del focus di ciascun sviluppatore. Quindi, dove potrei concentrarmi su una funzione o un livello, c'è almeno un altro sviluppatore con una buona comprensione del mio lavoro. In questo modo, l'intero progetto non può essere deragliato da uno sviluppatore chiave che lascia l'azienda.
Steve, è così difficile dire cosa sia meglio a meno che non si specifichi un determinato obiettivo.
Penso che se tutte le parti dell'attività sono assegnate a una singola persona, l'attività sarà completata più veloce. Questo perché in questo caso possiamo risparmiare sulla comunicazione: spiegare l'idea di implementazione, dividere l'attività in parti, assegnare parti ad altre persone, negoziare responsabilità, ecc.
D'altra parte, se ci sono molti specialisti coinvolti, può risultare in una quantità maggiore di di alta qualità dell'implementazione (a condizione che tu abbia persone istruite e con esperienza). Ma è più come richiedere più tempo e denaro.
Infine, è fino al vostro decidere, che cosa è meglio : più veloce, economico o maggiore qualità. Per le attività critiche del progetto andrei per la qualità, per i non critici andrei per la velocità.
Sono sicuro che quando si arriva a organizzazioni come myspace, facebook e google non si può avere una sola persona che lavora sul codice.
Penso che il modo migliore per affrontare una situazione è di registrazione tutto e spiegare che lavoro/modifiche hanno fatto.
Ad esempio, se il mio partner lavora su alcune funzionalità per il mio sito, gli sarà richiesto di documentare e spiegare in toto le modifiche apportate o implementate e di spiegare anche cosa sta facendo il suo codice e come si integra nel resto del sistema.
In questo modo, quando arrivo, posso vedere che ha apportato una modifica al sistema nella classe Input e che ha spiegato come si è assicurato uno degli ultimi attacchi XSS o cosa mai.
Così, quando ho letto il suo codice so già:
La parte principale dell'essere una squadra è la comunicazione, quindi avere un sistema che fornirà la comunicazione sarebbe di vitale importanza.
Le persone tendono a lavorare alla grande lì perché non c'è bisogno di comunicazione. ma man mano che cresci e ti espandi devi essere in grado di strutturare la tua applicazione e il tuo team per assicurarti di poter fare in modo che 20 persone facciano cose diverse ma tutti sanno cosa sta succedendo all'interno dell'applicazione mentre vedono un "Registro delle modifiche" come tale.
La mia opinione è che una squadra è meglio di una persona singolare.
Penso che per i team di piccole dimensioni, è normale che i programmatori facciano solo la codifica (incluso lo sviluppo di DB) e gli altri ragazzi per fare la parte CSS e altri progetti. Se i programmatori sono abbastanza, possono separare il loro lavoro e tutti per creare il proprio modulo (parte dal progetto) partendo dal database e finendo con l'incorporare la logica e il design.
Come si dice, dipende dal progetto, ma il modo in cui lavoriamo è previsto che tutti abbiano competenze di base nello stack di architettura dal web front-end, passando da java a SQL e prendano aree funzionali per lavorare sull'intero processo cosa.
Questo funziona per noi perché la maggior parte dei nostri materiali front-end e SQL è relativamente semplice, quindi le competenze approfondite sono raramente necessarie qui e perché il nostro lavoro si frammenta ordinatamente in blocchi funzionali di dimensioni adeguate. Se questo non è il tuo caso, allora non funzionerà.
Di norma, se ciò è possibile, penso che questo funzioni meglio poiché all'interno di ogni bit di funzionalità si ottiene qualcuno che si concentra sul prodotto finale completo e di conseguenza si ottiene un'esperienza utente migliore. Riduci anche le dipendenze tra le persone nel team, il che significa che è meno probabile che le persone perdano tempo ad aspettare che qualcun altro finisca qualcosa.
Le eccezioni a questa mi tendono a non pasticciare con:
Designers - sviluppatori generalmente producono lavoro web brutto e designer generalmente scrivere codice più poveri. Di solito considero il designer un ruolo specialistico per qualsiasi cosa in cui il front-end sia la chiave.
DBA: se si dispone di un database complesso, si desidera un DBA (o almeno uno sviluppatore con esperienza solida) per riunire tutto e mantenerlo solido. In casi estremi saranno più che a pagare per se stessi nell'ottimizzazione che fanno e il risparmio di hardware.
Ma di regola mi piacciono i generalisti. Ci sono delle eccezioni, ma per la maggior parte non credo che il tipo di sistemi sviluppati dalla maggior parte delle aziende abbia un livello di complessità che richiede, ad esempio, uno specialista di JBoss che non fa altro.
Si dovrebbe chiedere ai vostri dipendenti che cosa gli piace fare ... e poi dopo aver parlato con il tuo capo e clienti vi dirà a ciascuno di fare quello che sa fare meglio :)
Come ogni project manager sa c'è un piano e c'è una realtà - due cose diverse :)
Qual è il tuo piano: completare un singolo progetto il più velocemente, in modo economico e il migliore possibile? O forse vuoi costruire un team di qualità felice che MIEGT ti dia risultati migliori e più flessibilità in futuro.
Ricerca di un momento per una risposta ed è meglio renderlo solido prima di continuare e affrontare la realtà ...
avere una risposta buona ... Ora vieni attaccato con contraddicendo richieste dal responsabile, il tuo cliente, la tua squadra e forse dai tuoi colleghi. I vostri collaboratori vogliono imparare nuovo personale o di non imparare a tutti, il tuo capo non si preoccupa che il lavoro fino a quando fatto nello stesso tempo e la qualità che viene utilizzato per dal vostro uomo migliore e il vostro cliente fa in modo di costruire la pressione del progetto in ritardo.
Conclusione:
If you can't remember when the last time you finished a task on time - non cercare avventure. Questa sfida, per quanto promettente possa essere - può e sarà interpretata come l'incapacità del manager di svolgere il suo lavoro - "ovviamente il progetto fallisce ... le attività sono fatte dalle persone sbagliate!"
If you are on top of your duties ... puoi chiedere ai dipendenti se vogliono rompere la routine e lavorare su diversi strumenti. La mia ipotesi è che dopo si smettere di essere sospettosi, diventeranno più interessati al lavoro, più felici e motivati e scoprire che lavorare per voi apre nuove opportunità per loro ...
umana, purtroppo, non sono macchine - producono suoni di cracking anche quando tutto è a posto - se l'uomo migliore fa un suono, dagli un teaser di ciò che vuole, così farà ancora il 90% del suo progetto principale.
Preferisco fortemente la funzionalità per lo sviluppo di funzionalità. Principalmente perché se finisci l'80% delle funzionalità, hai un'app funzionante, ma se finisci l'80% dei livelli, non hai nulla.
È tutta una questione su cosa stai ottimizzando. Lo sviluppo di funzionalità per caratteristica ti consente di ottenere una nuova versione più velocemente. Ti aiuta anche a trovare lacune nella tua architettura in cui non supporta le tue funzionalità. Ma richiede alle persone di avere competenze generali - Tutti devono essere in grado di fare un piccolo progetto di database, una piccola codifica del middleware e un piccolo layout di front-end. Non devono essere brillanti, ma devono essere in grado di sapere quando sono al limite delle loro capacità e chiedere aiuto.
Lo sviluppo di livello layer consente di ottenere il massimo dalle esportazioni, ma si corrono dei pericoli. Se il tipo di database non comprende i requisiti del front-end, il DB potrebbe essere organizzato in modi che richiedono il front end per eseguire molte query. Se il tuo middleware è sviluppato in modalità OO, potresti avere il problema di "Impedenza non corrispondente" con il tuo database o front-end. Potresti anche finire con cose costruite nel livello sbagliato, perché "non possiamo aspettare che il middleware sia aggiornato, quindi lo faremo semplicemente nel front-end".
Nella mia esperienza, c'è sempre più che vogliamo fare di quanto abbiamo tempo. Preferisco lo sviluppo feature-by-feature, perché posso ritardare le funzionalità alla versione 2 e rilasciare un sito utile. Non posso ritardare uno strato, lasciandomi con gli slittamenti di programma.
Hai familiarità con XP? http://www.extremeprogramming.org/ – roundcrisis
@Miau - No, ma ne leggerò. Grazie :) – felix