ABONAMENTE VIDEO REDACȚIA
RO
EN
NOU
Numărul 140
Numărul 139 Numărul 138 Numărul 137 Numărul 136 Numărul 135 Numărul 134 Numărul 133 Numărul 132 Numărul 131 Numărul 130 Numărul 129 Numărul 128 Numărul 127 Numărul 126 Numărul 125 Numărul 124 Numărul 123 Numărul 122 Numărul 121 Numărul 120 Numărul 119 Numărul 118 Numărul 117 Numărul 116 Numărul 115 Numărul 114 Numărul 113 Numărul 112 Numărul 111 Numărul 110 Numărul 109 Numărul 108 Numărul 107 Numărul 106 Numărul 105 Numărul 104 Numărul 103 Numărul 102 Numărul 101 Numărul 100 Numărul 99 Numărul 98 Numărul 97 Numărul 96 Numărul 95 Numărul 94 Numărul 93 Numărul 92 Numărul 91 Numărul 90 Numărul 89 Numărul 88 Numărul 87 Numărul 86 Numărul 85 Numărul 84 Numărul 83 Numărul 82 Numărul 81 Numărul 80 Numărul 79 Numărul 78 Numărul 77 Numărul 76 Numărul 75 Numărul 74 Numărul 73 Numărul 72 Numărul 71 Numărul 70 Numărul 69 Numărul 68 Numărul 67 Numărul 66 Numărul 65 Numărul 64 Numărul 63 Numărul 62 Numărul 61 Numărul 60 Numărul 59 Numărul 58 Numărul 57 Numărul 56 Numărul 55 Numărul 54 Numărul 53 Numărul 52 Numărul 51 Numărul 50 Numărul 49 Numărul 48 Numărul 47 Numărul 46 Numărul 45 Numărul 44 Numărul 43 Numărul 42 Numărul 41 Numărul 40 Numărul 39 Numărul 38 Numărul 37 Numărul 36 Numărul 35 Numărul 34 Numărul 33 Numărul 32 Numărul 31 Numărul 30 Numărul 29 Numărul 28 Numărul 27 Numărul 26 Numărul 25 Numărul 24 Numărul 23 Numărul 22 Numărul 21 Numărul 20 Numărul 19 Numărul 18 Numărul 17 Numărul 16 Numărul 15 Numărul 14 Numărul 13 Numărul 12 Numărul 11 Numărul 10 Numărul 9 Numărul 8 Numărul 7 Numărul 6 Numărul 5 Numărul 4 Numărul 3 Numărul 2 Numărul 1
×
▼ LISTĂ EDIȚII ▼
Numărul 33
Abonament PDF

Usable Software Design

Alexandru Bolboacă
Agile Coach and Trainer, with a focus on technical practices
@Mozaic Works



PROGRAMARE

Într-un articol anterior pentru Today Software Magazine - Patru idei pentru îmbunătățirea Software Design-ului - am scris despre faptul că avem tendința de a face software design care nu este orientat către utilizator.

Ori de câte ori vorbim despre design în alte domenii decât software-ul, discutăm din punct de vedere orientat către utilizator. Produsele Apple sunt renumite pentru că se concentrează pe experiența utilizatorului cu dispozitivul: cum se simte, cum arată, cât de repede răspunde, sunetele pe care le scoate, etc. .
Software Design-ul este singurul tip de design care pare să nu aibă utilizator. La urma urmei utilizatorul final nu are nici o idee despre cum este organizată aplicația pe care o folosește și nici măcar nu-i pasă. Tot ce contează pentru el este ca aceasta să funcționeze bine.
...
Software Design-ul are un utilizator: programatorul care va trebui să schimbe codul scris de echipa ta. Dacă folosiți collective code ownership (ca majoritatea echipelor Scrum), ar fi bine să luați în considerare user-centric software design (software design orientat către utilizator).
Idei precum "Clean Code" ating această abordare dar nu o dezvoltă. În continuare, aș vrea să explorez acest subiect în detaliu.

1. Dezvoltatorii noi care lucrează cu Usable Software Design vor deveni mai productivi mai repede

De ce este gradul de ușurință în folosire al aplicațiilor web un subiect atât de important astăzi? Aș argumenta că motivul îl constituie avantajul competitiv pe care îl aduce, deoarece utilizatorii găsesc mult mai ușor să înceapă să folosească o aplicație care este construită având utilizatorul în minte. Niciun utilizator nu are timp să învețe un produs nou; vrem să începem să îl folosim imediat și să ne aducă beneficii instant.

Noii utilizatori ai software design-ului sunt noii dezvoltatori care se alătură echipei. Vom presupune că știu limbajul de programare, framework-ul principal utilizat și au lucrat în domeniul business înainte. Cât timp le ia să devină productivi în mediul vostru? Timpul petrecut îi familiarizează cu designul aplicației și cu modul în care lucrurile se fac în mare parte, dar se traduce prin cheltuieli. În termenii produsului, se numește pierdere.

2. Cerințele cele mai comune sunt implementate mult mai rapid cu Usable Software Design

Gândește-te la tipul de activități desfășurate pe produsul curent. Șansele sunt ca multe dintre ele să fie repetitive.

În aplicația de eHealth pe care o dezvoltăm, primele funcționalități au luat ceva timp pentru a fi implementate (NB: în același timp învățăm și o nouă tehnologie). Privind atent la ceea ce ne-a încetinit lucrul și ajustând designul, am optimizat dezvoltarea și am ajuns la punctul în care aproximativ 60% din munca este UI / UX design. Acum, dezvoltarea nu mai are bottleneck. Ne-am uitat apoi la optimizarea activităților de UI / UX, dar asta e altă poveste.

Cheia acestei îmbunătățiri a stat în faptul că privind în urmă, ne-am dat seama că  dezvoltam funcționalități care corespund câtorva tipuri de muncă:

Din moment ce știam din roadmap-ul proiectului că vor apărea din nou astfel de cerințe, am început optimizarea pentru aceste tipuri de muncă. Ocazional, trebuia să facem un nou tip de muncă care dura mai mult. Un exemplu a fost un serviciu de căutare a unui medicament, care este rapid, scalabil și ușor de modificat pentru a funcționa corect cu ultima versiune a bazei de date de medicamente. A trebuit să învățăm să folosim vertx și mongodb pentru a face lucrul acesta, și ne-a luat de 3-5 ori mai mult timp decât o sarcină normală. Deoarece aceasta este o situație locală, care este puțin probabil să se repete, nu am făcut nimic pentru a optimiza.

Ideea este: ca o aplicație care este ușor de folosit pentru taskuri mai comune, Usable Software Design permite implementarea rapidă a celor mai frecvente tipuri de caracteristici.  

Acestea sunt principalele beneficii pe care le văd pentru Usable Software Design. Dar cum să-l obținem? Primul lucru este ...

3. Măsoară și îmbunătățește

Procesul pe care l-am folosit pentru a face designul mai operațional a fost destul de simplu:

Noi folosim un proces Kanban / XP, așa că am folosit the cycle time distribution diagram ​pentru a identifica punctele de deviație. Avem o retrospectivă recurentă la fiecare două săptămâni în care discutăm impedimentele și identificăm soluțiile. Implementarea a fost făcută în următoarele două săptămâni, și ne-am păstrat un ochi la cycle time distribution în următoarele luni. A fost ușor să vedem îmbunătățirile deoarece majoritatea task-urilor s-au mutat la stânga.

Într-un context Scrum, echipele nu măsoară cycle time, doar viteza. Problema este că viteza este un indicator agregat pentru toate funcțiile implementate pe durata sprintului. Prin urmare, echipele Scrum au două opțiuni pentru a ajunge la usable software design:

Aceasta este metoda de bază pentru a obține usable software design. Metoda avansată este preluată din practicile de usability.

4. Rulează teste de usability pe Software Design-ul tău

Testele de usability pot fi rulate în mai multe moduri. Am găsit totuși un format care se potrivește cel mai bine pentru Software Design:

Iată câteva exemple de task-uri comune pentru o aplicație web:

Enumerăm câteva lucruri importante de știut despre teste de usability:

Acum știm cum să identificăm probleme. Sunt sigur că următoare întrebare este...

5. Cum arată Usable Software Design?

Pentru început menționez că ideea de a se centra pe developer, ca utilizator al Software Design-ului, este foarte nouă. Am văzut discuții oarecum în jurul acestui topic, și am contribuit și eu la unele. Literatura din trecut despre Software Design a atins acest subiect, dar nu în mod explicit. 

Există totuși foarte multă literatură despre usability. Voi menționa doar trei principii de bază ale usability-ului care se aplică în Software Design:

 Prezentăm câteva exemple:

Claritate: Numește pachetele în funcție de denumirea funcționalității (pachete funcționale)

Iată un screenshot de la o aplicație pe care o dezvolt. Poți spune ce face doar pe baza numelor?

<img src=

Prima oară l-am auzit pe Sandro Mancuso vorbind despre ideea aceasta la I T.A.K.E. Unconference 2014 (2014.itakeunconf.com) și am fost foarte interesat să încerc. Văd ideea ca pe un bun start în Usable Software Design.

Consistență: Păstrează o structură consistentă pentru fiecare pachet funcțional

Așa arată un pachet funcțional când este extins:

<img src=

Fiecare conține trei lucruri:

Încă trebuie să găsesc un loc mai bun pentru InvoiceFileNameGenerator, după cum puteți vedea limpede. Aceasta este o încălcare a celui de al treilea principiu, reducerea surprizei.

Consistență: Fiecare tip de clasă trebuie să aibă o interfață consistentă

Am văzut mai devreme că un pachet funcțional constă din trei tipuri de clase: a clasă de request, o clasă de controller și o clasă de view. Există și un nivel mai ridicat de consistență la care se poate ajunge, mai specific în interfața fiecăreia dintre aceste tipuri de clase.
În acest exemplu, toate clasele de Request menționate mai sus au o metodă:response()​Toate funcțiile controllers au o metodă:render().Fiecare funcție de controller folosește un view pentru a reda informația. Aceste interfețe sunt consistente în toate pachetele funcționale.

Gânduri finale

Usable Software Design vor aduce două beneficii economice majore:
implementare mai rapidă pentru task-urile comune și integrare mai ușoară a oamenilor noi în proiect. 

Pentru a obține Usable Software Design, avem nevoie de feedback de la utilizatori, mai exact de la dezvoltatori. Există două metode pentru a obține: prin retrospective și rulând teste de usability.

Ideea nu este complet nouă. Principiile precum claritate și consistență au fost folosite mulți ani la rând pentru a obține Design mai bun. Ideea de usable Software Design este totuși o schimbare de perspectivă; a te gândi la dezvoltator ca la utilizatorul software design-ului și a încerca activ să obținem feedback de la el sunt demersuri care vor aduce modificări în modul în care ne organizăm codul.

Mulțumiri!

Am fost inspirat să scriu acest articol după multe conversații cu: Sandro Mancuso, Samir Talwar, participanții la SoCraTes UK, Rebecca Wirfs-Brock, Adi Bolboacă, Claudia Rosu și mulți alții. 

Vă invit pentru o dezbatere mai aprofundată în cadrul Workshopului de Usable Software Design la I T.A.K.E. Unconference 2015

NUMĂRUL 138 - Maps & AI

Sponsori

  • Accenture
  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • Connatix
  • BoatyardX
  • .msg systems
  • Yardi
  • Colors in projects

INTERVIURI VIDEO