Гъвкава ползваемост

Като продължение на размислите от миналия пост идва и случайното ми натъкване на една потребителска група в Yahoo! – Agile Usability.

(Вместо въведение, за да сме на една страница всички – превод от Manifesto for Agile Software Development:)

Оценяваме:Личностите и взаимоотношенията повече от процесите и инструментите

Работещият софтуер повече от изчерпателната документация

Съвместната работа с клиента повече от преговарянето по договорните отношения

Готовността за отклик при промяна повече от следването на плана

И сега – на какво се натъкнах в споменатата потребителска група.

Имаше съобщение на тема „Some Agile and HCI articles”.

Ще си позволя да цитирам една от статиите, която обясняваше как могат да се съвместят методологиите на пъргавото програмиране и ползваемостта (Are Agile and Usability Methodologies Compatible, Alain Desilets):

По-долу е изложено личното ни виждане за това как един практикуващ потребителски-центирарано проектиране (user-centered design) професионалист може да помогне в работата по гъвкав (agile) проект.- Професионалистът, практикуващ потребителски-ориентиран дизайн, използва малко време в началото на проекта (примерно, 2 седмици при 6-месечен проект), събирайки информация от потребителите и други заинтересовани страни чрез интервюта, хартиени прототипи и др.

– Използва това време предимно, за да събере знание за нуждите на потребителите вместо да подготвя план, който да прехвърли за изпълнение към разработчиците.

– После прави груба скица на потребителския интерфейс като цяло (работа за два дни). Целта на тази скица е да даде на екипа разработчици нещо, към което да се стремят. Това не е солиден план и финалната имплементация най-вероятно ще се различава значително от него.

– След това става активен участник във фазата на разработка на системата. Неговата роля е да е част от екипа на клиента и да използва своето разбиране на клиентските и потребителските нужди, за да води разработката към ползваем и полезен софтуер.

– Прави това при тясно сътрудничество с разработчиците, проектирайки решения, които са ползваеми, но и следи разходите по внедряването да са ниски. Когато не е сигурен в някое конкретно решение за дизайн, се връща при потребителите, за да провери предположенията си.

– Вместо да се стреми към перфектния потребителски интерфейс от самото начало, той помага на екипа да осъществи поетапна ползваемост, започвайки с „Най-простото нещо, което е вероятно да проработи” и след това да го подобрява в зависимост от наличното време, пари и други приоритети. Той използва своето разбиране на потребителските и клиентските нужди, за да открие кое е най-простото нещо, но също така да оцени неговото осъществяване, за да идентифицира реалните точки на триене и да създаде начини да ги отстрани при следващата итерация (ако това е това е приоритетът на клиента по това време)

Ние вярваме, че потребителски-ориентираното проектиране, което работи по този начин върху гъвкав проект ще добави огромна стойност и тази стойност ще бъде достойно оценена от клиента и разработчиците.

Много съм доволен, че и моето лично виждане за случването на нещата е горе-долу същото. Сега остава да успеем да го приложим както трябва в няколко истински проекта.