Анотація
Книга - це розказаний алгоритм проведення процесу розробки від ідеї до впровадження із застосуванням технік agile. Процес розкладається по кроках і кожному кроці вказуються методи для кроку процесу. Автор показує, що більшість методів не оригінальна, не претендуючи на оригінальність. Але хороший стиль викладу та деяка цілісність процесу роблять книгу дуже корисною.
Ключова техніка карти історій користувача - це структуризація ідей і постановки по ходу проходження процесу користувачем.
У цьому викладати проходження процесу можна по-різному. Можна вибудувати кроки в міру досягнення ключової цінності, а можна просто взяти та уявити робочий день користувачів, як він проходить із використанням системи. Автор фокусується на те, що процеси потрібно викладати, промовляти у вигляді історії користувача на карті процесу, що і послужило назвою карта історій користувача.
Кому це потрібно
Для ІТ-аналітиків та керівників проектів. Обов'язково до прочитання. Читається легко та приємно, книга середня за розміром.
Відгук
У найпростішому вигляді, як це працює.
Відвідувач приходить до кафе, вибирає страви, робить замовлення, отримує їжу, їсть, розплачується.
Можна писати вимоги, що хочемо від системи кожному етапі.
Система повинна показувати список страв, у кожної страви склад, вагу та ціну та мати можливість додати до кошика. Чому ми впевнені у цих вимог? У “стандартному” описі вимог не описано і це породжує ризики.
Виконавці, які не розуміють навіщо це потрібно, зазвичай роблять не те, що потрібно. Виконавці не залучені до процесу створення ідеї, не залучені і до результату. Agile каже, то давайте фокусуватися насамперед не на системі, а на людях, на споживачах, їхніх завданнях та цілях.
Робимо особи, для емпатії надаємо їм деталі і з боку осіб починаємо викладати історії.
Офісний співробітник Захар пішов на обід і хоче швидко перекусити. Що йому потрібне? Ідея — напевно, він хоче бізнес ланч. Ще ідея він хоче, щоб система пам'ятала його переваги, тому що він сидить на дієті. Іще ідея. Він хоче, щоб йому одразу принесли каву, бо звик пити каву перед обідом.
А є ще бізнес (оргсонаж — персонаж, який представляє інтереси якоїсь організації). Бізнес хоче збільшити середній чек, збільшити частоту покупки, збільшити прибуток. Ідея – а давайте пропонувати незвичайні страви якоїсь кухні. Ще ідея - а давайте введемо сніданки.
Ідеї можна і потрібно конкретизувати, перетворювати та оформити у вигляді user story. Як співробітник бізнес-центру Захар, я хочу, щоб система впізнала мене, щоб я отримував меню з урахуванням моїх переваг. Як офіціант я хочу, щоб система повідомляла мене, коли підійти до столика, щоб клієнт був задоволений швидким обслуговуванням. І так далі.
Десятки історій. Далі пріоритизація та беклог? Джефф вказує на проблеми, що виникають: ув'язування в дрібних деталях і втрата концептуального розуміння плюс приоритизація функціонала створює рвану картину через неузгодженість цілям.
Шлях автора: Пріоритезуємо не функціонал, а результат = те, що користувач отримує у результаті.
Очевидний неочевидний пункт: сесія пріорітизації проходить не всією командою, бо неефективно, а трьома людьми. Перший відповідає за бізнес, другий за досвід користувача і третій за реалізацію.
Виділимо мінімум для вирішення одного завдання користувача (мінімальне життєздатне рішення).
Деталізуємо ідеї першого пріоритету за допомогою user story, нарисів дизайну, обмежень та бізнес правил на карті історій користувачам розповіді та обговорення з командою що потрібно персонам і стейкхолдерам на кожному кроці процесу. Інші ідеї залишаємо не розібраними, у беклозі можливостей.
Процес пишеться як карток зліва направо, а ідеї на картках під кроками процесу. Обов'язково шлях проходження всієї історії потрібно промовляти разом із співробітниками команди для появи взаєморозуміння.
Опрацювання у такий спосіб створює цілісність відповідності процесам.
Отримані ідеї слід перевірити. Не член команди одягає капелюх персони і мешкає в голові день персони, вирішуючи його завдання. Можливий варіант, коли не бачить напрацювань, створюючи картки заново, а команда відкриває собі альтернативи.
Потім відбувається деталізація з метою оцінки. Для цього достатньо трьох людей. Відповідальний за досвід користувача, розробник, тестувальник з улюбленим питанням: “А що якщо…”.
На кожному етапі обговорення йде по карті процесів історії користувача, що дозволяє тримаючи в голові завдання користувача створювати цілісність розуміння.
Чи потрібна документація на думку автора? Так, потрібна. Але як нотатки, які дають змогу згадати про що домовилися. Залучення людини із боку знову потребує обговорення.
Автор не заглиблюється у тему достатності документації, спираючись на необхідність обговорень. (Так, документація потрібна, як би це не стверджували люди, неглибокі в розумінні agile). Так само опрацювання лише частини можливостей може призвести до необхідності повної обробки всієї системи. Автор вказує на ризик зайвого опрацювання у випадку, коли не вгадали з ідеєю.
Для зняття ризиків необхідно швидко отримувати зворотний зв'язок по продукту для мінімізації шкоди створення "не того" продукту. Зробили малюнок ідеї - валідували у користувача, нарис прототипів інтерфейсу - валідували у користувача і т.п. (Особливо трохи вказується як валідувати прототипи програм). Цілі створення ПЗ, особливо на початковій стадії - навчання через отримання швидкого зворотного зв'язку, відповідно перший створений продукт це нариси які можуть довести або спростувати гіпотезу. (Автор спирається на роботу Еріка Райса "Стартап з методології Lean").
Карта історій допомагає налагодити комунікації, якщо реалізація забезпечується кількома командами. Що має бути на карті? Те, що потрібне для підтримки розмови. Не тільки user story (хто, що, чому), а ідеї, факти, нариси інтерфейсів та ін.
Розділяючи картки на карті історії на кілька горизонтальних ліній можна розділити роботи на релізи — виділити мінімум, шар нарощування функціоналу та бантики.
Промовляємо історії на карті процесу.
Співробітник прийшов на обід.
Чого він хоче? Швидкість обслуговування. Щоб його обід уже чекав на столі або хоча б на підносі. Опа пропущений крок: співробітник захотів поїсти. Він зайшов у систему та вибрав варіант бізнес-ланчу. Він побачив калорійність і відповідність поживної цінності, щоб дотримуватися дієти і не товстіти. Він побачив картинки страви, щоб прийняти рішення, чи буде він їсти в цьому місці, чи ні.
Далі він піде отримувати ланч та обідати? А можливо йому доставлять ланч в офіс? Тоді крок процесу – вибір місця їжі. Він хоче бачити термін коли йому доставлять і скільки це буде коштувати, щоб вибрати куди витратити час і сили на спуск вниз або на роботу. Він хоче бачити завантаженість кафе, щоб не штовхатися у чергах.
Далі співробітник прийшов до кафе. Він хоче побачити свою тацю, щоб взяти її і відразу піти обідати. Кафе хоче прийняти гроші, щоби заробити на обслуговуванні. Співробітник хоче втратити мінімум часу на розрахунках із кафе, щоб не витрачати дорогоцінний час без користі. Як це зробити? Оплачувати заздалегідь чи навпаки після обслуговування віддалено. Або оплачувати у момент за допомогою кіоску. Що з цього найголовніше? Як багато людей готові оплачувати банківською карткою обід? Як багато людей довірять зберігання номера картки для повторної оплати цієї їдальні? Без польового дослідження неясно, чи потрібне тестування.
На кожному кроці процесу потрібно хоч якось забезпечити функціонал, для цього потрібно взяти за основу якусь персону і вибрати що важливіше йому (та сама трійка виборців). Пройшли історію остаточно = зробили життєздатне рішення.
Далі йде деталізація. Клієнт хоче бачити завантаженість кафе, щоб не штовхатися у чергах. Що саме він хоче?
Дивитись прогноз скільки буде людей через 15 хвилин, коли він туди підійде
Дивитись середній час обслуговування в кафе та його динаміку на півгодини вперед
Дивитися ситуацію та динаміку зайнятості столиків
А якщо система прогнозування дає незрозумілий результат чи перестане працювати?
Дивитися через відео черги у кафе, а також зайнятість столиків. Хм, а чому б не зробити це насамперед?!
Автор вказує на невелику вправу для відпрацювання практики: спробуйте уявити, що ви робите вранці після пробудження. Одна картка = одна дія. Укрупніть картки (замість намолоти каву - випити напій, що бадьорить), щоб прибрати індивідуальні деталі, беручи у фокус не спосіб реалізації, а ціль.
Для кого ця книга – для ІТ-аналітиків та керівників проектів. Обов'язково до прочитання.
Додатки
Дискусія та прийняття рішень ефективні у групах від 3-х до 5 осіб.
Напиши на першій картці те, що потрібно розробляти, на другій — виправити те, що зробили у першій, у третій, — виправити те, що зроблено у першій та другій.
Готуйте історії, як торти — не виписуючи рецепт виготовлення, а дізнаючись кому, з якого приводу, наскільки торт. Якщо розбивати реалізацію, то не на виготовлення коржів, крему, а на виготовлення маленьких готових тортиків.
Розробка ПЗ схожа на створення фільму, коли потрібно ретельно розробити і вилизати сценарій, організувати сцену, акторів тощо перед початком зйомок.
Ресурсів завжди не вистачатиме.
20% зусиль дають відчутний результат, 60% дають незрозуміло що, 20% зусиль йдуть на шкоду — ось чому важливо сфокусуватися на навчанні та не зневірятися у разі негативного результату.
Спілкуйтеся з користувачем безпосередньо, відчуйте себе у його шкурі. Фокусуйте на деяких проблемах.
Деталізація та опрацювання історії для оцінки - найбільша невиразна частина scrum, зробіть обговорення стоячими в режимі акваріум (біля дошки обговорюють 3-4 людини, якщо хтось хоче брати участь, він замінює когось).
Джерело: habr.com