Come si adattano le metodologie di sviluppo del software nel campo della consulenza?

3

Lavoro per una società di consulenza piuttosto piccola, con circa 100 dipendenti, e sono con loro da circa un anno al momento. Questo è il mio primo lavoro fuori dal college. Come azienda non ci specializziamo in alcuna tecnologia specifica, ma la mia quotidianità di solito consiste in una sorta di programmazione .NET, che si tratti di ASP.NET, sviluppo personalizzato di SharePoint, ecc. I nostri progetti consistono generalmente nell'aggiungere funzionalità a , o espandendo, la base di codice esistente di un cliente. Raramente creeremo applicazioni web da zero.

Qualcosa che mi ha infastidito è la netta mancanza di qualsiasi tipo di metodologia o struttura che ci aiuti a fornire soluzioni di qualità ai clienti. Non conduciamo revisioni del codice, i test che facciamo sembrano deboli, la direzione tecnica sembra poco brillante. Sembra che sia stato fatto un piccolo sforzo per assicurare che il codice che il team si impegna in un progetto soddisfi qualsiasi tipo di standard di estensibilità e manutenibilità o aderisca a qualsiasi best practice per l'ambiente specificato. Dalla mia esperienza fino ad ora, lasciare che questa responsabilità esclusivamente al programmatore individuale produce risultati poco brillanti, specialmente quando sono coinvolti membri inesperti del team.

Vorrei sapere se questo è un business come al solito nel mondo della consulenza. Se lavori in una società di consulenza, mi piacerebbe conoscere le tecniche, i processi o gli approcci che vengono utilizzati per assicurarti che la soluzione sviluppata dal tuo team eviti di diventare un disastro, mentre con la restrizione che stai lavorando a un base di codice esistente del cliente che potresti non avere il controllo completo di. Cosa posso fare come membro junior del team per promuovere una cultura di produzione di software migliore?

    
posta Steve Smith 07.07.2011 - 11:06
fonte

4 risposte

6

Il problema con la consulenza è che spesso sei assunto come scimmia per ripulire i problemi che gli altri hanno lasciato, aggiungere alcune funzionalità o sostenere che non possono o non vogliono fare da soli. A quel punto le strutture, le migliori pratiche, ... sono di solito gettate in mare. Ma fornire buoni risultati (leggi: nella percezione del cliente, non necessariamente un buon codice) apre nuove porte allo stesso cliente per la manutenzione continua sul prodotto su cui stai lavorando, o su nuovi sviluppi da zero. E questo è il punto in cui puoi iniziare ad utilizzare un proprio framework e metodologie fin dall'inizio.

Ciò non significa che non puoi applicare per es. Scrum per la manutenzione iniziale / funzionalità extra. Inoltre, non significa che dovresti hackerare e produrre codice sporco perché è di consulenza e potrebbe essere un lavoro a breve termine. Lavoro sempre nella prospettiva di "Sto offrendo un buon lavoro, quindi dovrò continuare a mantenerlo, quindi voglio essere sicuro che almeno il mio codice è buono e facile da mantenere". Il tuo compito è mantenere il tuo codice gestibile e di alta qualità e solo dopo puoi iniziare ad espanderlo al resto del tuo team.

Se riesci a fornire software e documentazione di alta qualità e sei aperto sul tempo necessario e le scadenze per il cliente dal primo giorno (e non mentire a loro fino all'ultimo giorno e poi perdere la scadenza per miglia), avrai successo per fornire un codice di qualità superiore (potrebbe richiedere del tempo prima che raggiungano il punto in cui vedono che l'investimento aggiuntivo in termini di tempo extra supera il tempo necessario per le correzioni).

È così che lo faccio, e finora è stato un successo.

    
risposta data 07.07.2011 - 11:49
fonte
1

Dalla mia limitata esperienza - ho trascorso 8 mesi a essere chiamato "Consulente" nella parte di consulenza di una grande azienda all'inizio della mia carriera.

I motivi per cui le aziende assumono consulenze per esaminare i problemi di codifica sono

  1. Vogliono una panoramica generale di un'altra azienda che lavora, vogliono verificare se è la soluzione migliore. Il codice coinvolto in questo è spesso un software dimostrativo, con report e backup dei dati.
  2. Vogliono abbreviare un vero processo di sviluppo assumendo un consulente piuttosto che un vero e proprio dev. azienda. Normalmente quando il lavoro è apparentemente facile o hack-y, o l'applicazione è legacy.

In entrambi i casi sopra descritti, un processo di sviluppo completo dall'inizio alla fine è considerato una spesa inutile. Quindi sì, dalla mia esperienza limitata il codice di livello di consulenza è prodotto in uno standard molto più basso.

Come per la seconda parte

What can I do as a junior member of the team to promote a culture of producing better software?

Joel Spolsky ha prodotto un bell'articolo su questo genere di cose quando . Dubito che potrei scrivere meglio.

    
risposta data 07.07.2011 - 11:20
fonte
0

I would like to know if this is business as usual in the consulting world.

No. Ma.

C'è una difficoltà.

Se il cliente non ha (o peggio, una metodologia interna a caso), è molto difficile imporre l'ordine al proprio caos.

Alcuni clienti sostengono di avere una metodologia, ma si comportano davvero in modo piuttosto casuale.

Alcuni clienti hanno una metodologia pubblicata ma non la seguono; equivale al caos con le linee guida.

Tuttavia, usiamo Scrum per molti progetti. Alcuni usano anche TDD.

    
risposta data 07.07.2011 - 13:03
fonte
0

Le società di consulenza di solito fanno pagare per tempo. Possono pagare per la selezione e la creazione di un quadro. In caso contrario, è in qualche modo a loro vantaggio (profitto) non essere efficiente. Se stanno lavorando su consegne a prezzo fisso, l'economia cambia.

Ho lavorato per e con un certo numero di società di consulenza. Normalmente parte della consegna consisteva nell'impostazione di standard, metodologia e framework.

Dal punto di vista del cliente, mi aspetterei che la società di consulenza ne disponesse e le usasse a meno che non siano in conflitto con gli standard interni, la metodologia e il / i framework / i. Sfortunatamente, questo è raramente il caso.

Quando partecipavo a un gruppo di qualità del software con membri di diverse società di consulenza, ponevo la domanda ovvia: "Qualcuno di voi usa la metologia delle aziende?" La risposta era generalmente "No". Molti praticanti sapevano che la loro azienda aveva una metodologia, ma molti non l'avevano vista.

    
risposta data 07.07.2011 - 16:08
fonte

Leggi altre domande sui tag