3. Chiedono "What Would l'utente Do?" da Giles Colborne
Tutti tendiamo a pensare che gli altri pensano come noi. Ma non è così. Gli psicologi lo chiamano il consenso falsi pregiudizi . Quando le persone pensano o agiscono diversamente da noi, siamo molto probabile che etichettarli (inconsciamente) come difettoso in qualche modo. Questo pregiudizio spiega perché i programmatori hanno un periodo così difficile mettersi in posizione degli utenti '. Gli utenti non la pensano come i programmatori. Per iniziare, spendono molto meno tempo utilizzando i computer. Essi non conoscono né la cura come funziona un computer. Questo significa che non possono attingere a una qualsiasi delle batteria di tecniche di problem solving in modo familiare ai programmatori. Non riconoscono i modelli e programmatori spunti utilizzare per lavorare con, attraverso e intorno una interfaccia. Il modo migliore per scoprire come pensano gli utenti è quello di guardare uno. Chiedere ad un utente per completare un'attività utilizzando un pezzo di software simile a quello che si sta sviluppando. Assicurarsi che il compito è reale: "Aggiungere una colonna di numeri" è OK, "Calcola le spese per il mese scorso" è meglio.Evitare attività che sono troppo specifici, come "è possibile selezionare queste cellule foglio di calcolo e immettere una SOMMA seguente formula? " - C'è un indizio importante a questa domanda. Prendi il all'utente di parlare attraverso il suo progresso. Non interrompere. Non cercare di aiutare.Continuano a chiedermi se stessi: "Perché sta facendo questo?" e "Perché non sta facendo questo?"La prima cosa che noterete è che gli utenti fanno un nucleo di cose allo stesso modo. Essi cercano di completare le attività nello stesso ordine - e fanno gli stessi errori negli stessi luoghi. Si consiglia di progettare intorno a quel comportamento principale. Questo è diverso da incontri di progettazione, dove le persone tendono ad essere ascoltato per dire "Che cosa succede se l'utente vuole ...?"Questo porta a elaborare caratteristiche e confusione su ciò che gli utenti desiderano. Guardando agli utenti di eliminare questa confusione. Vedrai utenti di rimanere bloccati. Quando ti trovi in difficoltà, ti guardi intorno. Quando gli utenti bloccati, hanno ristretto la loro attenzione. Diventa sempre più difficile per loro vedere soluzioni altrove sullo schermo. E 'una delle ragioni testo di aiuto è una cattiva soluzione per cattiva progettazione dell'interfaccia utente. Se è necessario disporre di istruzioni o il testo della guida, assicuratevi di individuarlo proprio accanto al tuo aree problematiche. Prospettiva ristretta di un utente di attenzione è il motivo per i suggerimenti sono più utili di menu guida. utenti tendono a cavarsela. Troveranno un modo che funziona e bastone con esso non importa quanto contorta. E 'meglio per fornire un modo davvero evidente di fare le cose di due o tre tasti di scelta rapida. Troverete anche che c'è un divario tra ciò che dicono gli utenti che vogliono e quello che fanno.Questo è preoccupante in quanto il modo normale di raccolta dei requisiti utente è quello di chiedere loro. E 'questo il modo migliore per catturare i requisiti è quello di guardare gli utenti. Trascorrere un ora gli utenti a guardare è più informativo di trascorrere una giornata indovinare quello che vogliono.
4.Automatizzare il vostro standard di codifica di Filip van Laenen
Probabilmente hai già stati anche lì. All'inizio di un progetto, ognuno ha un sacco di buone intenzioni - le chiamano "le risoluzioni nuovo progetto." Molto spesso, molte di queste risoluzioni sono riportati nei documenti. Quelli sul codice finire in standard di codifica del progetto. Durante il kick-off meeting, lo sviluppatore principale passa attraverso il documento e, nel migliore dei casi, tutti sono d'accordo che cercheranno di seguirli. Una volta che il progetto prende il via, però, queste buone intenzioni sono abbandonati, uno alla volta.Quando il progetto è finalmente consegnato il codice sembra un pasticcio, e nessuno sembra sapere come è venuto a essere in questo modo. Quando le cose vanno male? Probabilmente già al kick-off meeting. Alcuni dei membri del progetto non ha prestato attenzione. Altri non hanno capito il punto.Peggio ancora, alcuni non è d'accordo e sono state già pianificando la loro ribellione standard di codifica. Infine, alcune ottenuto il punto e concordato, ma, quando la pressione nel progetto diventato troppo alto, hanno dovuto lasciar andare qualcosa. Ben formattata codice non si guadagnano punti con un cliente che vuole di più funzionalità. Inoltre, a seguito di uno standard di codifica può essere un compito noioso se non è automatizzato. Basta provare a rientrare una classe disordinato a mano a trovare da soli. Ma se è un problema, il motivo è che vogliamo avere uno standard di codifica, in primo luogo? Uno dei motivi per formattare il codice in modo uniforme è così che nessuno può "possedere" un pezzo di codice solo per la formattazione a suo modo privato. Se vogliamo evitare che gli sviluppatori che utilizzano alcuni farmaci anti-pattern, al fine di evitare alcuni errori comuni. In tutto, uno standard di codifica dovrebbe rendere più facile lavorare nel progetto, e mantenere la velocità di sviluppo dall'inizio alla fine. Ne consegue che tutti dovrebbero concordare lo standard di codifica troppo - non aiuta se uno sviluppatore utilizza tre spazi per il rientro del codice, e un altro quattro.Esiste un'ampia gamma di strumenti che possono essere utilizzati per produrre report qualità del codice e di documentare e di mantenere lo standard di codifica, ma non è l'intera soluzione. Dovrebbe essere automatizzati e applicate, ove possibile. Ecco alcuni esempi:
• Assicurarsi che la formattazione di codice fa parte del processo di compilazione, in modo che tutti lo avvia automaticamente ogni volta che compilare il codice.
• Utilizzare strumenti di analisi statica del codice per eseguire la scansione il codice per indesiderate anti-patterns. Se ne viene trovata, rompere la compilazione.
• Imparare a configurare gli strumenti in modo che sia possibile analizzare per il proprio, specifico del progetto anti-patterns.
• Non solo misurare la copertura di test, ma automaticamente controllare i risultati anche.Ancora una volta, rompere la copertura di test build se è troppo bassa.
Provate a fare questo per tutto quello che si considera importante. Non sarà in grado di automatizzare tutto ciò che interessa davvero. Per quanto riguarda le cose che non può automaticamente bandiera o correzione, li considerano un set supplementare di linee guida per lo standard di codifica che è automatizzato, ma accettare che lei ei suoi colleghi non li può seguire come diligentemente. Infine, lo standard di codifica dovrebbe essere dinamica e non statica. Mentre il progetto si evolve, la necessità del cambiamento del progetto, e ciò che può sembrare intelligente in principio, non è necessariamente intelligente pochi mesi dopo.
Nessun commento:
Posta un commento
Nota. Solo i membri di questo blog possono postare un commento.