Do meny Post-agilism: wybór najlepszego rozwiązania

Uczestnicy warsztatów otrzymują materiały w formie papierowej (czarno-białe) i elektronicznej (PDF), oraz certyfikat udziału w warsztatach, podpisany przez prowadzącego oraz przez przedstawiciela KKIO

Prowadzący: Bogdan Bereza

Warsztaty odbędą się pierwszego dnia XV Krajowej Konferencji Inżynierii Oprogramowania, 18 września w Szczecinie, w godzinach 9:00 - 14:45 (program KKIO, warsztaty i szkolenia podczas KKIO)

Miejsce: sala 01, WNEiZ, Mickiewicza 64, Szczecin

Zgłoszenie: rezerwacja@victo.eu

WARUNKI:
Warsztaty są bezpłatne, ale prosimy o zgłoszenie, żeby znać z grubsza liczbę uczestników.

Uzasadnienie tematu

Trend jest jednoznaczny: metodyki agile (zwinne) stosuje się coraz szerzej, coraz powszechniej: są nawet zwolennicy ich wykorzystania - choć wymaga to pewnego nagięcia znaczenia niektórych pojęć - przez biznes także poza IT. Wszystko wskazuje na to, że w ciągu dwóch-trzech lat to podejście stanie się na jakiś czas dominującym paradygmatem wytwarzania oprogramowania i systemów w Polsce i na świecie.

Ta sytuacja ma swoje dobre i złe strony. Podejście agile, podkreślające rzemieślniczy (craft), a nie naukowy charakter wielu działań IT, ma szereg niezaprzeczalnych zalet. Jest więc ogromną korzyścią i dla IT, i dla całego biznesu, że agile się rozpowszechnia. Jednak agile - w tym najpopularniejsza z metod zwinnych, Agile Scrum - nie do wszystkiego nadaje się równie dobrze. Potrzebne jest duże doświadczenie, aby trafnie odróżnić sytuacje, gdzie agile się opłaca, od tych, gdzie przynosi szkody.

Wiele jest podobnych pytań, niezbyt pociągających teoretycznie, bo obciążonych bardzo dużą nieoznaczonością, ale pozwalających - jeśli umie się na nie odpowiedzieć - osiągać znaczne korzyści biznesowe. Na przykład, jak postępować, gdy realizacja niektórych zadań projektu pasuje do technik agile, ale niektórych - nie pasuje? Jak wykorzystać agile, nie rezygnując ze stosowania najlepszych praktyk ogólnej inżynierii oprogramowania i szerokiej wiedzy informatycznej?

Jak zwykle w inżynierii oprogramowania, nie istnieje algorytm, który pozwala jednoznacznie odpowiedzieć na te pytania. Istnieją natomiast dobre heurystyki, oparte na doświadczeniach wielu zespołów i wielu organizacji. Podczas warsztatów, Uczestnicy zapoznają się z wnioskami, zgromadzonymi na podstawie praktycznych doświadczeń. Ponadto, będziemy wspólnie dyskutować i pracować nad propozycjami kolejnych rozwiązań.

Temat cieszy się popularnością - podobne warsztaty, o węższym zakresie tematycznym (agile a inżynieria wymagań) odbyły się wcześniej 25 czerwca tego roku, zorganizowane przez "Computerworld". Zostały bardzo dobrze ocenione przez Uczestników (wniosek na podstawie ankiet po warsztatach)

Do meny Warsztaty odbędą się pierwszego dnia XV Krajowej Konferencji Inżynierii Oprogramowania, 18 września w Szczecinie, w godzinach 9:00 - 14:45 (program KKIO, warsztaty i szkolenia podczas KKIO)
Skąd wzięła się nazwa warsztatów - co to jest "Post-agilism"? Większość osób, posługujących się tym określeniem, ma na myśli pewne pragmatyczne rozluźnienie surowych, niemal religijnych zasad pierwotnego ruchu agile (2001). W 2006 dwie osoby, Jonathan Kohl z Kanady oraz Jason Gorman z Wielkiej Brytanii, niezależnie od siebie zdefiniowały credo Post-agilism.

Do meny Jonathan Kohl powiedział między innymi: "Post-Agilism was something I observed that reminded me of post-modernism in architecture and art. Modernism is more rigid in rules of how things should form, while post-modernism rebels against that restriction, and people use combinations or mashups of styles to solve a problem".
Program warsztatów

Agile
Nie agile
Wymuszone agile
Projekt
Wiedza
1
2
3
4
5
Agile Jakie wymagania wobec otoczenia projektowego stawiają metody agile?

Uczestnicy wdrożeń metodyki agile jako powszechny problem wymieniają otoczenie projektowe, wymagające wielu zbędnych, lub nieosiągalnych w projekcie agile miar i dokumentów, oraz stawiające wobec przebiegów (sprint) Agile Scrum nierealne wymagania. Najczęściej bodaj zdarzają się usiłowania zmian wymagań już podczas trwania przebiegu.

Z drugiej strony, nieodpowiednie otoczenie projektowe ma zwykle trudności z dostarczeniem tego, co jest niezbędne w agile - tutaj szczególnie częste jest zaniedbanie, polegające na tym, że uczestnicy zespołu (scrum team) nie są w nim na 100%, lecz na przykład tylko na 60%, pozostałe 40% nadal pracując dla innego projektu.


Podczas warsztatów poznacie Państwo więcej podobnych sytuacji, oraz rutynowe sposoby radzenia sobie z nimi. Wspólnie poszukamy także nowych rozwiązań.
program

Nie
                        agile Jak w tym samym otoczeniu projektowym sprawnie realizować projekty zarówno metodami agile, jak i wszelkimi innymi?

Chcąc, aby sposób realizacji projektu - agile lub inny - był na pewnym poziomie abstrakcji nie do odróżnienia, należy otoczenie projektowe zaprojektować tak, aby spełniało założenia hermetyzacji (encapsulation). Przykładowo, dane, które widziane z zewnątrz określa się jako specyfikację wymagań, wewnątrz przedsięwzięcia stają się rejestrem produktu (product backlog). Taka hermetyzacja zapewni, że niezależnie od sposobu realizacji, projekty będą się łatwo wpisywać w procedury całej firmy. Umożliwi to także minimalizację wpływów zmian organizacyjnych. Na przykład, zmiana formatu dokumentacji zarządczej, spowodowana nowymi procedurami księgowymi, nie będzie pociągała za sobą zmian na poziomie projektów ani ich sposobów raportowania.

W pseudokodzie można ten mechanizm przedstawić najprościej jako dziedziczenie:

class Projekt
{
   public:
   Projekt
();
   void rozpocznijProjekt ();
   [...]
};
class Projekt_tradycyjny : public Projekt
{
   [...]
};
class Projekt_agile : public Projekt
{
   void rozpocznijProjekt ();
   // np. podział na przebiegi
   [...]
};
Podczas warsztatów przedstawimy niektóre sposoby realizacji takiego mechanizmu przy użyciu wzorców dokumentacji, lub odpowiedniej konfiguracji narzędzi zarządczych; wspólnie poszukamy dalszych rozwiązań.
program
Wymuszone agile Niekiedy rozwiązaniem jest realizowanie projektów, wobec których agile nie znajduje zastosowanie, w formie symulowanego agile.

Nie każdą funkcjonalność można dogodnie opisać w formie opowieści użytkowników (user stories), ponadto w projekcie wykonuje się szereg czynności, które nie polegają na implementowaniu funkcjonalności.

Przykładowo, jeśli wiele opowieści użytkowników korzysta z wyszukiwania w bazie danych, to sam mechanizm wyszukiwania należy zrealizować tylko raz. Wymagania wobec niego opisuje się innymi sposobami niż opowieści użytkowników.

Inny przykład, to tworzenie rejestru produktu (product backlog) lub architektury systemu: te przedsięwzięcia trzeba wykonać, zanim przystąpi się do realizacji przebiegów (sprints). Aby jednak w całym projekcie posługiwać się zunifikowanym trybem podziału pracy, także zadania nie-agile można realizować jako swego rodzaju namiastki przebiegów agile.

Takie podejście ma swoje wymagania, przynosi korzyści oraz niesie ze sobą ryzyko, które omówimy podczas warsztatów.
program
Projekt Także w projektach realizowanych metodami agile wykonuje się wiele czynności nie-agile, przykładowo:
  • Określenie wizji i zakresu projektu
  • Pozyskiwanie, analiza, negocjowanie i walidacja wymagań (składających się na product backlog)
  • Projektowanie architektury systemu
  • Szacowanie pracochłonności całego projektu
  • Testy odbiorcze (akceptacyjne)
Podczas warsztatów omówimy, w jaki sposób, planując i realizując te zadania, brać pod uwagę szczególne potrzeby metodyki Agile Scrum.
program
Wiedza "Scrum jest: lekki, łatwy do zrozumienia, bardzo trudny do opanowania", piszą Ken Schwaber i Jeff Sutherland w "The Scrum Guide". Tego nie można powiedzieć o wielu obszarach inżynierii oprogramowania: nie są one szczególnie łatwe ani do zrozumienia, ani do opanowania. Obie strony zdradzają też niekiedy skłonność do lekceważenia się nawzajem: wśród zwolenników agile zdarzają się postawy w stylu "nie matura, lecz chęć szczera, zrobi z ciebie oficera", zaś wielu informatyków uważa Agile Scrum, oraz inne formy agile, za szarlatanerię, która solidną wiedzę i metody usiłuje zastąpić magicznymi formułami.

Jak wykorzystać czyjąś specjalistyczną wiedzę, np. w zakresie testowania, inżynierii wymagań, czy projektowania architektury w projektach agile? Jak projektować swoją ścieżkę kariery, uczestnicząc przez wiele lat w kolejnych projektach agile, gdzie w pewnym sensie wszyscy są równi? Podczas warsztatów wymienimy się spostrzeżeniami w tym zakresie.

Bogdan
                        Bereza


Do meny
Prowadzący: Bogdan Bereza

Przedstawiciel Polski w Radzie IREB. Obecnie pracuje nad książką "Complete Software Test Design Handbook", która pojawi się po angielsku 2014/2015.

● Współautor pierwszego kursu testowania oprogramowania w Szwecji 1995 ● Współzałożyciel SAST 1996 ● Certyfikat ISEB CTFL 2000 ● Autor pierwszego kursu przygotowującego do certyfikatu ISEB CTFL poza Wielką Brytanią (w Szwecji, Enea Realtime, 2000) ● Tłumacz z angielskiego na polski pierwszej w Polsce książki o testowaniu oprogramowania - kultowego dziś Pattona ● Współzałożyciel SSTB 2003 ● Prowadzi kilkanaście pierwszych szkoleń ISEB CTFL w Polsce 2002-2004 ● Inicjator i współzałożyciel SJSI ● Autor pierwszego w Polsce akredytowanego kursu ISEB CTFL po angielsku (2004) ● Współautor tłumaczenia sylabusa ISEB CTFL na język polski (2005) ● Autor pierwszego w Polsce akredytowanego kursu ISEB CTFL po polsku (2006) ● Autor dwóch pionierskich (i nadal jedynych) polskich książek na temat testowania: "Teoria i praktyka testowania" (2005) oraz "Jak zapewnić jakość aplikacjom" (2009) ● Certyfikat ISEB Practitioner 2007 ● Certyfikat ISTQB Full Advanced (Test Manager, Test Analyst, Technical Test Analyst) 2008 ● Prowadzi jedyne w Polsce szkolenie na ISEB Practitioner 2008 ● Pierwszy w Polsce dostawca szkoleń ISTQB Advanced 2008 ●
© Victo 2013
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
---