Quali metodi esistono per valutare la capacità di sviluppo di un'organizzazione? [chiuso]

0

Al momento ho un po 'di sfida al lavoro. Attualmente (e in effetti, da qualche tempo), abbiamo riscontrato i seguenti problemi con alcune applicazioni gestite internamente:

  • Difetti (a volte piuttosto gravi) che vengono rilasciati in produzione;
  • Il Cliente (ovvero l'unità aziendale interessata) cambia continuamente idea (o sembra che lo faccia) su quale problema eseguire successivamente;
  • Una situazione in cui tutti sembrano essere in una modalità "antincendio" per un sacco di tempo;
  • Personale di sviluppo che risponde alle richieste operative degli utenti aziendali; ("operativo" qui significa qualcosa che deve essere fatto per continuare il business, o forse solo per rendere la vita di un utente aziendale un po 'meno doloroso, invece di correggere un bug nell'applicazione, o migliorare l'applicazione);

Ora sono sicuro che questo non sembra particolarmente nuovo o sorprendente per la maggior parte dei partecipanti su questo sito Q & A e nessun premio per identificare i "soliti sospetti" quando si tratta di cause di fondo. La mia sfida è che devo convincere i superiori a fare cose scomode per affrontare tutto questo.

La gente che devo convincere proviene da una miscela delle seguenti due culture:

  • contabile;
  • Infrastruttura IT.

Ho quindi optato per una strategia che tragga dalle cose con - quale folk di tale cultura sarebbe più comodo (almeno, a mio avviso), vale a dire: numeri e tangibili. Naturalmente i professionisti dello sviluppo moderni sanno fin troppo bene che questo genere di cose non è facilmente risolvibile usando una mentalità analitica ( alcuni potrebbero sostenere che che la mentalità è, infatti, del tutto inappropriata ). In ogni caso, questa è la dicotomia con cui mi trovo di fronte, quindi questo è il palo che ho messo nel terreno.

Mi piacerebbe essere in grado di fare ricerche e utilizzare gli output per presentare i risultati sotto forma di metriche e misure. Sto trovando abbastanza difficile, tuttavia, trovare una metodologia concordata e una serie di modelli per valutare la capacità di sviluppo di un'organizzazione - l'unica cosa che sembra applicabile è il Capability Maturity Model dell'Istituto di Ingegneria del Software. Quest'ultimo, tuttavia, sembra datato e anche allora piuttosto vago.

Quindi, la domanda è: come faccio a valutare la capacità di ingegneria del software della nostra organizzazione in modo tale da presentare i risultati in un modo concreto e fa riferimento a uno standard industriale generalmente accettato?

UPDATE:

Facendo qualche ricerca in più, mi sono imbattuto in questa piccola oasi - una FAQ CMMI formulata in termini laici - solo il tipo di risorsa utile di cui si ha bisogno in quest'area ... e gratis .

    
posta Eric Smith 11.06.2014 - 17:43
fonte

3 risposte

3

Come la mia risposta, la maggior parte delle cose è vaga sull'argomento. Nessuno può determinare per te che 10 bug siano peggiori di 1.

Non sei sicuro di una particolare metodologia, ma dovresti iniziare prima con il tuo cliente, sia che siano esterni o interni. Quali sono i problemi che vedono con il sistema. Ci dispiace, ma questo post suona un po 'troppo su come migliorare la vita dello sviluppatore. Devono esserci alcune conversazioni che portano a una migliore comprensione da entrambe le parti.

Per mostrarti cosa intendo, interpreterò Devil's Advocate e prenderò in considerazione la prospettiva del tuo cliente e ti mostrerò perché questi non sono problemi per loro.

•Defects (sometimes quite serious) being released into production;

Hai "detto" che sarebbe stato pronto in 2 settimane, quindi è quello che abbiamo pianificato. Se ti servisse più tempo, perché non lo hai detto? Non hai test?

•The Customer (that is, the relevant business unit) perpetually changing their minds (or appearing to do so) about what issue to work on next;

Questo è solo il modo in cui sono fatti gli affari. Non possiamo predire queste cose. Alcune richieste provengono da agenzie esterne (leggi fiscali governative), venditori, clienti o dirigenti, quindi non c'è nulla che possiamo fare al riguardo. La terra non smetterà di girare solo perché non siamo pronti per il quarto di giro. Non siete ragazzi agili?

•A situation where everyone seems to be in a "fire-fighting" mode a lot of the time;

Siamo allo stesso modo; Non puoi farci niente. Le cose sono fuori dal nostro controllo proprio come il problema precedente.

•Development staff responding to operational requests from business users; ("operational" here means something that needs to be done in order to continue with business, or perhaps just to make a business user's life a little less painful, as opposed to fixing a bug in the application, or enhancing the application);

Ci piacerebbe essere in grado di fare queste cose da soli perché lo sviluppo richiede troppo tempo e si lamenta di OGNI SINGOLA RICHIESTA che facciamo. Costruisci qualcosa che ci offre questa capacità, ma non ti fidi di farlo. Non puoi prendere il controllo, ma anche non volerlo fare. Non posso averlo in entrambe le direzioni.

Cerca di bilanciare. È difficile valutare i rischi e la severità con i bug per avere alcune possibilità di ottenere risultati. I gruppi aziendali potrebbero preferire che impieghi più tempo. Quando chiedono quanto tempo, non presumere significhi la quantità minima di tempo possibile.

Documenta il processo e ottieni il loro feedback sulla priorità. Vuoi fare 10 cose e abbiamo solo un numero sufficiente di persone da fare 5, che 5 vuoi? La maggior parte delle persone vuole solo essere tenuta d'occhio. Farli chiedere continuamente e non fornire feedback fa sembrare il tempo più lungo. Questo è il motivo per cui i sistemi telefonici cercano di dirti quanto tempo dovrai tenere per gestire le tue aspettative. Fare cambiamenti non è diverso. Fai sapere loro che il cambiamento influirà sulla consegna. Quindi possono decidere se è abbastanza importante.

Per quanto riguarda la presentazione di questo alla gestione, assicurati di conoscere entrambi i lati della storia in modo da poter presentare problemi che tutti devono essere corretti. Spero che avrete alcune soluzioni concordate. Un problema di comunicazione che vedo sempre è che qualcuno di alto livello chiede "Ehi, puoi vedere se possiamo aggiungere un'altra colonna a questo rapporto?" e quando arriva allo sviluppatore il messaggio è "Mr. Big vuole una nuova colonna nel report ASAP o tutti i nostri primogeniti sono toast!" La gestione è in imbarazzo per le tue lamentele sulla tua situazione.

    
risposta data 11.06.2014 - 18:32
fonte
2

La metodologia Six Sigma ha una serie di strumenti che possono essere utilizzati per valutare i tuoi processi e determinare i costi e le perdite attività commerciale.

Comprendi che il compito che stai affrontando è potenzialmente enorme. Ero in una squadra in cui uno dei nostri progetti principali era quello di fare proprio questo per una grande unità di sviluppo e test dei produttori. Abbiamo identificato oltre 500 processi principali, la maggior parte dei quali non documentati al momento della valutazione. Il processo di valutazione è durato 2 anni, e poi un altro anno per elaborare un piano decennale per documentare e migliorare questi processi al punto in cui raggiungerebbe quel livello di controllo. Questo era presso un'azienda che era già certificata ISO 9001. Sospetto che sarebbe uno sforzo maggiore per un'azienda che non era abituata ai processi richiesti per fornire le metriche richieste.

Uno dei maggiori problemi con qualcosa di simile è che molti sviluppatori sono tipi creativi e che la mentalità spesso non gestisce l'essere costretti a conformarsi bene ai processi. Le probabilità sono che se hai una Cowboy Coder cultura ora sarà una sfida per convogliare quegli sviluppatori nel tipo di struttura ambiente in grado di produrre un successo ripetibile e prevedibile.

Un altro grosso problema è che nonostante abbia un potenziale ROI potenziale , lo sviluppo viene spesso eseguito con un budget limitato con scadenze irrealistiche. Immagina se fossi venuto da te e ti avessi detto che volevo che progettassi e costruissi una macchina di qualità Rolls Royce, ma sono disposto a darti solo un budget di $ 20kUS e hai solo 2 mesi per farlo ... quello una cosa del genere accade troppo spesso nello sviluppo del software. Per essere ripetibili devi essere realistico.

    
risposta data 11.06.2014 - 18:13
fonte
2

Posso raccomandare il test di Joel: 12 passaggi per migliorare il codice . Citando dal post del blog:

1. Do you use source control?
2. Can you make a build in one step?
3. Do you make daily builds?
4. Do you have a bug database?
5. Do you fix bugs before writing new code?
6. Do you have an up-to-date schedule?
7. Do you have a spec?
8. Do programmers have quiet working conditions?
9. Do you use the best tools money can buy?
10. Do you have testers?
11. Do new candidates write code during their interview?
12. Do you do hallway usability testing? 

Queste domande sono state scritte da Joel Spolsky nel 2000, ma non hanno ancora perso la loro attinenza fino ad oggi (2014). Tuttavia, aggiungerei alcune aggiunte ad alcune domande:

1. Specifically, do you use a source-control system with built-in code 
   review capability? (e.g. something like git's pull-requests)
2. Do you have a continuous build system in place that 
   kicks in automatically on every commit?
3. Do you have a continuous delivery system in place that (at least)
   installs every build automatically in a test environment?
...
6. Do you actually work by Scrum or Kanban?
7. Do you write and estimate user stories on a regular basis?
...
11. Do you find useful tasks for coding that relate to what the 
    job is actually about? (as opposed to asking for the 1e6th 
    incarnation of the Fibonacci algorithm, or to solve the TSP
    when the job is about writing your next JavaScript UI)
12. Do you use A/B testing to determine what people actually prefer?
    (as opposed to their stated opinion)
    
risposta data 11.06.2014 - 23:04
fonte

Leggi altre domande sui tag