Metodologia di progetto per piccoli team [chiuso]

Question

Di solito 1-4 sviluppatori / art director / copywriter su ogni progetto della mia azienda, quale metodologia consiglieresti di utilizzare? Agile? XP? Mischia? Qualcos'altro? (So ??che sono tutte variazioni essenzialmente dello stesso concetto, sì)

Answer 1

Non credo che ci sia una risposta generale, la domanda è troppo ampia e non puoi semplicemente "adottare una metodologia" come se fosse un prodotto che tiri fuori dalla scatola, è qualcosa che evolvi nel tempo ... ma in ogni caso ti consiglio vivamente di ottenere una copia di questo libro: Primo sviluppo software capo

Quindi adatta le idee che ti piacciono nel tuo progetto. Non preoccuparti di nomi e parole d'ordine, saranno tutti " pass & # 233; " l'anno prossimo comunque. Per prima cosa, semplifica , adotta le idee che hanno più senso e danno il massimo per i soldi, e non cercare di risolvere problemi che non esistono ancora. Sarà un ottimo inizio.

Answer 2

Per la programmazione di coppia, almeno, è meglio avere un numero pari di programmatori ...; P

Una delle cose positive dei piccoli team è che non hai bisogno di molti sistemi di supporto per comunicare internamente (un bugtracker diventa più o meno una lista di cose da fare per te, ma è bene avere comunque). Se avere un incontro con tutto il team implica solo girare intorno al tuo personaggio e dire "Ehi, Bob e Carl, dai un'occhiata a questo!", Non hai comunque bisogno di tutte le regole formali di una metologia. Ma i metodi agili in generale sono abbastanza adatti per i team di piccole e medie dimensioni, ma richiedono membri di team auto-motivati.

Dirò che scegli qualsiasi idea ti piaccia dalle diverse metologie, possono comunque essere considerate suggerimenti.

Answer 3

Per team così piccoli, prenderei sicuramente in considerazione un approccio Agile allo sviluppo del software. Personalmente, probabilmente userei una miscela di XP, Scrum e Lean, perché conosco quelli migliori. Soprattutto se non si conosce Agile, XP offre un buon punto di partenza da cui è possibile trovare l'adattamento specifico per il proprio progetto. Consiglio vivamente il libro "The Art of Agile Development".

Answer 4

Il mio team di sviluppatori 3 usa semplicemente le distribuzioni continue Kanban + e ci tiene in movimento rapidamente. Ho guardato Scrum e altri e c'è troppo sovraccarico per il nostro piccolo team.

Answer 5

Sono molto vicini al lato commerciale, il che è una cosa negativa perché i programmatori spesso non comprendono bene le implicazioni della contabilità, della gestione del tempo o del rischio, ecc. Anche se pensano di sì. Considerano il business un'altra interessante opportunità per migliorare le loro sofisticate competenze tecniche. Poiché la società è piccola, potrebbe essere eccessivo implementare metodologie complesse all'interno del team di sviluppo. Possono gestire facilmente le domande tecniche. Ciò che non sono in grado di gestire è capire che se sono vicini all'ambiente aziendale non significa che non sono più programmatori.

Suggerisco di attuare alcune semplici politiche che assicurino disciplina e attenzione al lato tecnico piuttosto che parlare con i clienti di argomenti tecnici che è ciò che piace ad alcuni programmatori.

Answer 6

La risposta è, proverbialmente, dipende ...

Ogni squadra è una miscela di personalità e abilità e ogni membro della squadra è diverso. Invece di concentrarsi sulla ricerca di una "metodologia" di per sé, raccomanderei di concentrarsi su ciò di cui ciascun membro del team ha bisogno per avere successo e di associarlo a ciò di cui il progetto ha bisogno per avere successo. Troverai la giusta metodologia e mix di processi tra queste due considerazioni.

Ad esempio, ho guidato un piccolo team (tre sviluppatori a tempo pieno più alcuni designer di interfaccia utente part-time) negli ultimi sette mesi. Ho scoperto che le seguenti pratiche / procedure funzionano bene per noi ...

• Adozione di spirali brevi (60-90 giorni) e ben definite, che mantengono il team concentrato e orientato alla consegna e ci aiutano a ridurre al minimo il rischio.
• Adozione di un ciclo di vita iterativo, in cui effettuiamo alcune consegne incrementali al cliente nel corso di una spirale e discutiamo di ciò che abbiamo fatto. Ciò consente a noi e al cliente di garantire che stiamo rispondendo alle loro esigenze.
• Compiti e direzione su misura per ciascun membro del team. Ad esempio, un membro del team è uno sviluppatore più giovane, mentre l'altro membro del team è un ottimo sviluppatore ma non gestisce bene le attività a tempo indeterminato. Richiedono approcci diversi.

Naturalmente, ho anche adattato i processi CM e le pratiche di test per soddisfare il progetto e le esigenze del team.