To jest artykuł z serii Proces ewolucji architektury.

Po dość zgrubnym rozeznaniu się w środowiskowym kontekście systemu, jest czas na nieco więcej konkretów na temat funkcjonalności.

Część I - Przygotowanie


Dobór grupy
Do wyodrębnienia user stories świetnie nadają się spotkania focusowe. I ty pytanie z kim?
Najlepiej, aby grupa była różnorodna. Jednorodne grupy mają tendencję do "krzywienia" user stories. Na przykład programiści formułują je bardzo crudowo.

Aktorzy
Jeśli to możliwe, już na samym początku zidentyfikuj aktorów. Zadaj sobie pytanie Kto będzie wołał ten system?. W tym momencie masz już wstępnie rozpoznanych na następujących aktorów:
  • inne systemy - ponieważ poznałeś kontekst pracy systemu
  • użytkownik - na razie to dość ogólne sformułowanie, taki metaaktor, którego pojęcie będzie dokonkretyzowywać się w trakcie dalszych rozmów
  • dla porządku warto dorzucić jeszcze jednego: Time ; bojownicy o czystość UMLa mnie przeklną, ale wygodnie mieć tych aktorów dla spraw wyzwalanych czasem; jest to wygodne tylko i wyłącznie z tego powodu, aby nie bawić się w dodatkowe tabelki, gdy zajdzie potrzeba wysmarowania pięknego diagramu

Rysunek 1: Wstępny szkic aktorów w systemie
Wstępne nazwanie aktorów pomaga konkretnej zadawać pytania. Głównie o to tu chodzi. Konwencja nazewniczaUstal ramową konwencję nazewniczą, zazwyczaj są dwie konkurencyjne alternatywy:
  • anglojęzyczna - działa proporcjonalnie do swobody językowej
  • polskojęzyczna - często jeden do jednego przekłada słownictwo binzesowe, ale w kodzie będą wychodzić zabawane pongliszowe kwiatki
Najkorzystniej jest promować taką konwencję nazewniczą, która zmienia jak najmniej przyzwyczajeń. Najczęściej słownictwo biznesowe jest zlepkiem z polskiego, angielskiego, a czasem i z innych języków i trudno je uspójniać. Zmiana organizacyjnej nowomowy trochę boli, ale przynosi niepomierne korzyści w postaci wzajemnego zrozumienia. Wypraktykowałem, że zamiast próbować udowadniać ludziom, że mają złe przyzwyczajenia, o wiele lepiej działa zadawanie pytań uwypuklające niejednoznaczność słownictwa. Na przykład: Co ma Pan na myśli mówiąc <<szkolenie>>. To <<program>> szkolenia, czy <<czynność>> prowadzenia szkolenia? Acha, rozumiem, czyli możemy mówić o szkoleniu <<możliwym do zorganizowania>> oraz <<zorganizowanym>> szkoleniu? Pułapką uspójniania słownictwa jest synonimia nomenklaturze organizacji. Śmiało można zaryzykować stwierdzenie, że każdy dział ma nieco inne nazwy na te same rzeczy i procesy.

Rysunek 2: różne nazwy na te same rzeczy, to jedna z większych trudności
Tego typu różnice dość szybko wychodzą, jeśli zadbasz o wspomnianą wcześniej różnorodność grupy. Kto nazywa ten rządziJak najszybciej ustalcie nazwę dla systemu. W przeciwnym razie, będziesz rozmawiać o oderwanych funkcjonalnościach, co sprawi, że zakres systemu będzie stale i nieograniczenie się powiększał. Najlepiej, aby nazwa wzięła się z rzeczywistości np.: kalendarz elektroniczny, aby występowała w informatyzowanym procesie. Łatwo wtedy eliminować wodotryski, zadając proste pytanie Czy dotychczas w kalendarzu również miał Pan możliwość dodawania awatarów? Nic nie mówiące i zbyt ogólne nazwy z kategorii Zintegrowany System Informatyczny, to otwarta furtka do wylądowania poza budżetem lub terminem lub oboma jednocześnie.

Część I - Prowadzenie sesji wyodrębniania user stories

Zasady ogólnePrzed przystąpieniem do sesji wygodnie jest mieć jakiś szkic interfejsu użytkownika, żeby skupić uwagę osób. Jeśli ich nie ma to je rysuj. Rysowanie dobrze ogniskuje uwagę i często lepiej pozwala wyrazić myśli. Historycznie user storier spisywane są na małych kartkach. Powiedzmy sobie jednak szczerze, że arkuszem Excela o wiele lepiej się zarządza. Jak to zatem jest z tymi karteczkami? Z całego serca polecam karteczki (żółte, samoprzylepne :) ). Mają one tę wielką zaletę, że budują zaangażowanie interesariuszy. Osoby na spotkaniu są często przytłoczeni dużą liczbą obowiązków, nieco zmęczeni i teraz jeszcze muszą odbębnić z nami spotkanie. Mimo, że rzeczywiście chcą tego systemu, to nie chcą na niego poświęcać czasu - nielogiczne, ale prawdziwe. Jeśli będziesz zachęcać ludzi, aby sami pisali user stories na karteczkach i dodatkowo przyklejali je na fipcharcie, to "wciągną się" w spotkanie, będą bardziej kreatywni. Budując zaangażowanie, zwiększasz swoje szanse na wyodrębnienie rzeczywistych oczekiwań co do systemu zamiast ogólników, które czasem ktoś może chcieć Ci wcisnąć, żebyś tylko dał mu spokój. Zaangażowanie - to jest rzeczywisty cel karteczek. Rzecz jasna, że po spotkaniu możesz przepisać je do Excela, skoro w ten sposób łatwiej nimi zarządzać. Nie jestem fanem zbyt szybkiego wprowadzania narzędzi. Narzędzia (zwłaszcza takie, które narzucają swój proces pracy) częściej przeszkadzają niż pomagają. Fanom narzędzi chętnie polecam Scrum Do. Jest bardzo grywalne, zawiera wszystko co potrzeba, a jednocześnie jest kompletnie nieinwazyjne. Minusem jest to, że działa on-line. Formułowanie historyki Ogólny algorytm prowadzenia sesji wygląda tak:
  1. Ustal uwagę na pierwszym ekranie
  2. Zadaj pytanie: Co można zrobić na tym ekranie?
  3. Skłoń ludzi, aby sformułowali swoje oczekiwania w następujący sposób: Jako <<kto?>>mogę <<funkcjonalność>>, aby <<po co?>>
Struktura zdania, za pomocą którego formułujemy historyjki, jest bardzo chytra. Każda z części tego zdania ma swój ściśle określony cel. Przyjrzyjmy się jej bliżej.
  1. Jako <<kto?>> - tu konkretyzujemy aktorów (role); funkcjonalności nie są zawieszone w powietrzu; dzięki przyporządkowaniu historyjek do ról, łatwiej na późniejszym etapie ogarnąć zasady bezpieczeństwa dostępu do systemu
  2. mogę <<funkcjonalność>> - tu precyzujemy konkretną funkcjonalność, do której dany użytkownik ma mieć dostęp
  3. aby <<po co?>> - ta bardzo ważna część, pomaga użytkownikom uświadomić sobie potrzeby oraz problemy, które zamierzają zaspokoić i rozwiązać za pomocą tej funkcjonalności; dodanie tej części eliminuje sporo niepotrzebnych funkcjonalności, bo gdy ludzie zaczynają zastanawiać się po co coś będzie potrzebne, to czasem dochodzą do wniosku, że po nic
Ogólniki i szczególikiPodczas spisywania historyjek, możemy otrzymać efekt dwojakiego rodzaju:
konkretne user stories
np.: Jako U mogę zobaczyć listę swoich zamówień, aby wiedzieć co już otrzymałem, a czego jeszcze nie; do takich sformułowań zmierzamy podczas pracy z interesariuszami
niekonkretne user stories
np. Jako P mogę zarządzać dokumentami?; słowo "zarządzać" niewiele mówi o tym co właściwie należy zrobić, być może kryje się za tym jakiś ogromniasty epic;

Prawdopodobnie będziesz mieć chęć, aby drążyć niekonkretne historyki, gdy tylko użytkownicy je sformułują. Kłopot w tym, że prawdopodobnie oni sami jeszcze nie przemyśleli co to konkretnie ma być. Proponuję, by chwilowo zostawić je w spokoju. Zapisz je i wróć do nich później, już po sformułowaniu wszystkich user stories.

Dodatkowe porady
Podczas sesji ludzie spierają się o to, co właściwie ma robić dana rola i dość szybko zaczynają roztrząsać kwestie techniczne. Nie daj się wciągnąć w tę dyskusję, ucinaj ją natychmiast i prowadź spotkanie dalej. Na tym etapie eksploracja "w szerz" zamiast w "głąb" zagadnienia, pozwoli Ci szybciej przyswoić sobie wiedzę domenową.

Tego typu spotkania wygodnie jest prowadzić w dwie osoby. Jedna aktywnie moderuje rozmowę, druga nieco mniej zaangażowana zachowuje big picture i wkracza w razie kłopotów.

.