Апстракт
Книгата е раскажан алгоритам за спроведување на процесот на развој од идеја до имплементација со помош на агилни техники. Процесот е поставен во чекори и на секој чекор се наведени методите за чекорот на процесот. Авторот истакнува дека повеќето од методите не се оригинални, без да тврди дека се оригинални. Но, добриот стил на пишување и одреден интегритет на процесот ја прават книгата многу корисна.
Клучна техника за мапирање на приказни на корисникот е да се структурираат идеите и перформансите додека корисникот се движи низ процесот.
Во исто време, процесот може да се опише на различни начини. Можете да изградите чекори додека постигнувате клучна вредност, или едноставно можете да го преземете и замислите работниот ден на корисниците додека минува користејќи го системот. Авторот се фокусира на фактот дека процесите треба да бидат оцртани, изговорени во форма на корисничка приказна на мапа на процеси, што ни го даде името мапа на приказна за корисникот.
На кого му треба
За ИТ аналитичари и проект менаџери. Мора да се прочита. Лесна и пријатна за читање, книгата е со средна големина.
Преглед
Во својата наједноставна форма, вака функционира.
Посетител доаѓа во кафуле, избира јадења, нарачува, добива храна, јаде и плаќа.
Можеме да напишеме барања за она што го сакаме од системот во секоја фаза.
Системот треба да прикаже список на јадења, секое јадење има состав, тежина и цена и да може да се додаде во количката. Зошто сме сигурни во овие барања? Ова не е опишано во „стандардниот“ опис на барањата и тоа создава ризици.
Изведувачите кои не разбираат зошто е тоа неопходно обично прават погрешна работа. Изведувачите кои не се вклучени во процесот на креирање идеја не се вклучени во резултатот. Agile вели, ајде да се фокусираме првенствено не на системот, туку на луѓето, на потрошувачите, нивните задачи и цели.
Создаваме личности, им даваме детали за емпатија и почнуваме да раскажуваме приказни од страната на личноста.
Вработен во канцеларијата Захар отиде на ручек и сака да има брза закуска. Што му треба? Идејата е дека тој веројатно сака деловен ручек. Друга идеја е дека тој сака системот да ги запомни неговите преференции, бидејќи тој е на диета. Друга идеја. Сака веднаш да му донесе кафе бидејќи е навикнат да пие кафе пред ручек.
Исто така постои и бизнис (организациски карактер е лик што ги застапува интересите на организацијата). Бизнисите сакаат да ја зголемат просечната проверка, да ја зголемат зачестеноста на купувањата и да го зголемат профитот. Идејата е - да понудиме необични јадења од некоја кујна. Друга идеја - да воведеме појадок.
Идеите можат и треба да се конкретизираат, трансформираат и презентираат во форма на корисничка приказна. Како вработен во Бизнис центарот Захар, сакам системот да ме препознае за да можам да добијам мени врз основа на моите преференции. Како келнер сакам системот да ме извести кога да се приближам до масата за клиентот да биде задоволен од брзата услуга. И така натаму.
Десетици приказни. Следно е приоретизирање и заостанување? Џеф ги истакнува проблемите што се појавуваат: заглавувањето во мали детали и губењето на концептуалното разбирање, плус приоритизирањето на функционалноста создава расипана слика поради неусогласеност со целите.
Патот на авторот: Приоритет не ни е функционалноста, туку резултатот = она што корисникот го добива на крајот.
Очигледна неочигледна точка: сесијата за одредување приоритет не ја спроведува целиот тим, бидејќи е неефикасна, туку три лица. Првиот е одговорен за бизнис, вториот за корисничкото искуство и третиот за имплементација.
Дозволете ни да го избереме минимумот за решавање на еден кориснички проблем (минимум остварливо решение).
Ги детализираме идеите за прв приоритет користејќи кориснички приказни, скици за дизајн, ограничувања и деловни правила на мапата на приказни на корисникот, така што ќе им кажеме и ќе разговараме со тимот што им треба на луѓето и засегнатите страни во секој чекор од процесот. Останатите идеи ги оставаме неиспитани во заостанатите можности.
Процесот е напишан на картички од лево кон десно, со идеи на картички под чекорите на процесот. Императив е патот низ целата приказна да се дискутира заедно со членовите на тимот за да се обезбеди меѓусебно разбирање.
Обработката на овој начин создава интегритет во согласност со процесите.
Добиените идеи треба да се тестираат. Некој член на тимот ја става капата на личноста и го живее денот на личноста во неговата глава, решавајќи го неговиот проблем. Можно е тој да не ги гледа случувањата, повторно да создава карти, а тимот да открие алтернативи за себе.
Потоа има детали за евалуација. За ова се доволни три лица. Одговорен за корисничко искуство, програмер, тестер со омилено прашање: „Што ако...“.
Во секоја фаза, дискусијата следи процесна мапа на историјата на корисникот, што овозможува да се има предвид задачата на корисникот за да се создаде кохерентно разбирање.
Дали е потребна документација според мислењето на авторот? Да, ми треба. Но како белешки кои ви дозволуваат да запомните што сте се договориле. Повторно вклучување аутсајдер бара дискусија.
Авторот не навлегува во темата за доволноста на документација, фокусирајќи се на потребата од дискусија. (Да, потребна е документација, без разлика како тоа го тврдат луѓе кои немаат длабоко разбирање за агилното). Исто така, елаборирањето на само дел од можностите може да доведе до потреба од целосна преработка на целиот систем. Авторот укажува на ризикот од прекумерна елаборација во случај кога идејата е погрешна.
За да се елиминираат ризиците, неопходно е брзо да се добијат повратни информации за производот што се создава за да се минимизира штетата од создавање на „погрешен“ производ. Направивме скица на идејата - ја потврдивме со корисникот, скициравме прототипови на интерфејс - ја потврдивме со корисникот итн. (Одделно, има малку информации за тоа како да се валидираат прототиповите на програмата). Целите на креирањето на софтверот, особено во почетната фаза, се учење преку добивање на брзи повратни информации соодветно. (Авторот се потпира на делото на Ерик Рис „Стартување со помош на посно методологија“).
Мапата на приказни помага да се подобри комуникацијата кога имплементацијата се спроведува во повеќе тимови. Што треба да има на мапата? Што ви треба за да продолжи разговорот. Не само корисничка приказна (кој, што, зошто), туку идеи, факти, скици на интерфејс итн...
Со делење на картичките на мапата за историја на неколку хоризонтални линии, можете да ја поделите работата на изданија - да го истакнете минималниот минимум, слојот на зголемена функционалност и лакови.
Ние раскажуваме приказни на мапата на процесот.
Еден вработен дојде на ручек.
Што сака тој? Брзини на услугата. Така што ручекот веќе го чека на маса или барем на послужавник. Упс - промашен чекор: вработениот сакал да јаде. Тој се најави и ја избра опцијата деловен ручек. Ја видел содржината на калории и хранливата содржина за да му помогне во исхраната и да не се здебелува. Видел слики од садот за да одлучи дали ќе јаде на тоа место или не.
Следно, дали ќе оди да руча и вечера? Или можеби ручекот ќе биде доставен во неговата канцеларија? Тогаш чекорот на процесот е избор на место за јадење. Сака да види кога ќе му биде испорачана и колку ќе чини, за да може да избере каде ќе ги троши времето и енергијата - да оди долу или да оди на работа. Сака да види колку е зафатено кафулето за да не се тера во редици.
Потоа вработената дошла во кафулето. Тој сака да го види својот послужавник за да може да го земе и да оди директно на вечера. Кафулето сака да прифати пари за да заработи пари на услуга. Вработениот сака да изгуби минимум време на плаќања во кафулето, за да не троши бескорисно драгоцено време. Како да се направи тоа? Плаќајте однапред или обратно по услугата од далечина. Или плаќајте на лице место користејќи киоск. Што е најважното нешто за ова? Колку луѓе се подготвени да платат за ручек со банкарска картичка? Колку луѓе би ѝ верувале на оваа менза да го зачува бројот на нивната картичка за повторени плаќања? Без теренско истражување не е јасно, потребно е тестирање.
На секој чекор од процесот, треба некако да обезбедите функционалност за ова треба да земете некоја личност како основа и да изберете што е поважно за него (истите три селектори). Ја следеше приказната до крај = направи остварливо решение.
Следува деталите. Клиентот сака да види колку е зафатено кафулето, за да не се турка во редици. Што точно сака?
Погледнете ја прогнозата колку луѓе ќе има за 15 минути кога ќе стигне таму
Погледнете го просечното време на услуга во кафуле и неговата динамика половина час однапред
Погледнете ја ситуацијата и динамиката на зафатеност на масата
Што ако системот за прогнозирање даде нејасен резултат или престане да работи?
Погледнете ги низ видео редиците во кафулето, како и зафатеноста на масите. Хм, зошто да не го направиш тоа прво?!
Авторот посочува мала вежба за вежбање: обидете се да замислите што правите наутро откако ќе се разбудите. Една картичка = една акција. Зголемете ги картичките (наместо мелење кафе, пијте пијалок за оживување) за да ги отстраните поединечните детали, фокусирајќи се не на начинот на имплементација, туку на целта.
За кого е наменета оваа книга: ИТ аналитичари и проект менаџери. Мора да се прочита.
Апликации
Дискусијата и одлучувањето се ефективни во групи од 3 до 5 луѓе.
Напишете на првата картичка што треба да се развие, на втората - поправете го она што сте го направиле во првата, на третата - поправете го она што е направено во првата и втората.
Подгответе приказни како колачи - не со пишување рецепт, туку со откривање на кого, за која пригода и за колку луѓе е тортата. Ако ја разложиме продажбата, тогаш тоа не би било во производство на колачи, крем и слично, туку во производство на мали готови колачи.
Развојот на софтвер е сличен на снимањето филм, кога треба внимателно да го развиете и полирате сценариото, да ја организирате сцената, актерите итн. пред да започне снимањето.
Секогаш ќе има недостиг од ресурси.
20% од напорите даваат опипливи резултати, 60% даваат неразбирливи резултати, 20% од напорите се штетни - затоа е важно да се фокусирате на учењето и да не очајувате во случај на негативен резултат.
Комуницирајте директно со корисникот, почувствувајте се во негова кожа. Фокусирајте се на некои проблеми.
Деталирањето и развивањето на приказната за евалуација е најмрачниот дел од scrum, направете ги дискусиите да станат стојат во режим на аквариум (3-4 луѓе дискутираат на табла, ако некој сака да учествува, тој заменува некого).
Извор: www.habr.com