Battle for Agility

Agilopolis po wakacjach serwuje 2 wydarzenia

Po wakacjach inicjatywa Agilopolis budzi się ponownie do życia z dwoma wydarzeniami. Już w poniedziałek 31.08 trzecie z kolei spotkanie ACD a tam prezentacja Marcina Kołtonowskiego na temat:

“Kanban in IT. How and if the idea of Kanban can be used in Agile or IT”

Poza tym w trakcie spotkania:

• kilka pytań i odpowiedzi jakie pojawiły na pierwszym Agilopolis Community Conference w czerwcu,
• prezentacja na temat motywacji, którą przeprowadzi Jurek Wachała,
• dyskusja na temat testowania w SCRUM

Spotkanie odbędzie się w Silver Forum, Strzegomska 2/4 od godziny 17:30 (sala jeszcze nie podana). Więcej informacji na temat spotkania znajdziecie pod adresem:

http://agilopolis.com/content/agilopolis-community-day-3

Agilopolis Community Conference

Drugie wydarzenie to kolejna edycja konferencji ACC, która tym razem rośnie do pełnych dwóch dni i odbędzie się 21-22 września 2009. Tym razem pojawią się goście z zagranicy min. Roman Pilcher, autor bardzo ciekawie zapowiadającej się książki “Agile Product Management with Scrum: Creating Products that Customers Love“, który wystąpi z dwoma tematami:

• Owner-related techiques
• Grooming the Product Backlog

Oprócz niego wystąpią też:

• Mattias Skarin z tematami “10 steps to Agile adoption” oraz “Agile myth or magic“,
• Paul Klipp z tematem “Agile Promoting Strategies“,
• David Friar z tematem “Agile in the ‘Real’ World - things they don’t teach you in Agile School“
• Habte Woldu jako moderator dyskusji panelowej “Introduction of agile in organization - pitfalls and obstacles“

Drugi dzień to dwa warsztaty w formie gier:

• Scrum Game
• Product Owner Game

Więcej szczegółów… i cennik znajdziecie na stronie:

http://www.agilopolis.com/content/agilopolis-community-conference-0

Add comment August 29th, 2009

Wakacyjne brakujące User Story

Właśnie wróciłem z krótkich wakacji, z których przywiozłem sobie osobliwą pamiątkę - ulotkę pizzerii oferującej pizzę na telefon z dostawą do domu. Czemu jest w niej coś dziwnego? O tym za chwilę :-) Najpierw zabawmy się w mini projekt tworzenia takiej ulotki. Jesteśmy pracownikami restauracji i zastanawiamy się jak też ma nasza ulotka wyglądać:

• Oferujemy pizzę z dostawą do domu… napiszmy to dużymi literami, żeby każdy się zorientował.
• Mamy promocję “Zamów 3 pizze, 4-tą dostaniesz gratis” - musi być na ulotce!
• Oczywiście musi tam być też lista naszych pizz i ceny (duży wybór, więc poświęcimy temu całą stronę)
• Mamy ograniczony budżet ulotka będzie więc czarno-biała
• Jeszcze trzeba wybrać jakieś ładne zdjęcia z pizzą na jedną i drugą stronę.

Macie już w głowie jakiś ogólny obraz ulotki? Taka zwyczajna… A nie brakuje na tej liście czegoś? To może inaczej… Spójrzmy na planowanie funkcjonalności ulotki oczami jej użytkownika i spiszmy user story:

• Jako klient chcę się dowiedzieć jakie pizze są dostępne (z jakimi dodatkami) i ile kosztują abym mógł wybrać odpowiednią pizzę dla siebie.
• Jako klient chciałbym się dowiedzieć czy są dostępne jakieś promocje, abym mógł ew. dokonać jakiegoś korzystniejszego zakupu.
• Jako klient chcę się dowiedzieć z ulotki jaki jest numer telefonu abym mógł zamówić pizze, które wybrałem.
• Jako klient chciałbym wiedzieć gdzie mieści się pizzeria, na wypadek gdybym chciał się jednak przejść i zjeść pizzę na miejscu zamiast zamawiać ją telefonicznie.

Teraz już chyba domyślacie się dlaczego ta ulotka z “pizzą na telefon” tak mnie rozbawiła… Autorzy zapomnieli o numerze telefonu i adresie. Jedyną wskazówką była nazwa restauracji, więc ostatecznie udało się znaleźć numer w internecie :-)

A cały ten wakacyjny epizod skojarzył mi się z user story dlatego, że patrzenie na wymagania z punktu widzenia użytkownika a nie z punktu widzenia technicznych aspektów projektu jest moim zdaniem szalenie istotne i może czasem uratować “projekt” :-). User stories doskonale się do tego nadają, zwłaszcza, że początkowo celowo ukrywają te techniczne, nieistotne na etapie formowania wizji, szczegóły (jak kolory, zdjęcia, rozkład na stronach).

Innym aspektem, który tylko teraz zasygnalizuję jest to, ze często same user story są pisane bardziej od technicznej strony z pominięciem tej części “aby…”, która niesie ze sobą wartość dla użytkownika. A więc dostarczajmy przede wszystkim wartość użytkownikom, a nie projekt odbiorcy.

Add comment August 3rd, 2009