Zwinność – podstawą konkurencyjności pracowników – CCD2017

23 marca 2017 roku w krakowskiej siedzibie firmy Comarch odbędzie się druga edycja konferencji oparta na formule Open Space.
Poprowadzę temat zwinności i to jak ona wpływa na nas w codziennej pracy.
Więcej informacji: CCD2017 – Zwinność – podstawą konkurencyjności pracowników

Zwinność? Od czego zacząć.

Zwinność, czyli to zdolność do przemyślanej, racjonalnej zmiany bez utraty jakości na efekcie końcowym?
Czyż nie byłby to idealny świat projektów kiedy dostarczamy co klient oczekuje , w terminie i bez błędów?

SUN TZU w „Sztuce wojny” powiedział cyt.

„Dobra armia powinna przypominać zwinnego węża, który uderza ogonem, gdy zaatakowano jego głowę, głową – gdy zaatakowano ogon, oraz zarówno głową, jak i ogonem, gdy uderzono go w środek. Czy armia może być zwinna jak wąż? Może. Nawet ludzie, którzy się nie lubią, pomagają sobie w kłopotach, gdy płyną na tej samej łodzi.”

Przypomina mi się historia pewnej zmiany w armii, opisanej w książce „Sedno zmian” Johna P. Kottera i Dana S.Cohena. Opisywana tam prawdziwa historia pokazała jak relacje miedzy dowodzącymi, zmieniły się. Kiedy byli na jednej tratwie której płynęli jako rozbitkowie zrozumieli siebie, nauczyli się ze sobą rozmawiać, słuchać uważnie. Kłopoty w jakich się znaleźli pojednały ich.

A co mamy w świecie biznesu, kiedy armia w postaci zespołu ma się dogadać?
Dostrzegając analogię zauważamy, że jest tak samo. Dobry i zgrany zespół, niczym drużyna First Delta One oddziałów Neavy Seals potrafi sprostać najtrudniejszym wymaganiom, przeciwnościom, czasowi.

Co jest powodem, że właśnie tak się dzieje?
Odpowiedź jest prosta, może nawet i kuriozalna – są razem.

Co nasza główna zdolność jaką jest zwinność ma z tym wspólnego?
Manifest Agile z roku 2001 mówi nam na temat wskazówek, rad którymi powinniśmy się kierować chcąc być zwinni:

  • Ludzie i relacje ponad procesy i narzędzia
  • Działające oprogramowanie ponad obszerną dokumentacje
  • Współpraca z klientem ponad kontrakty i umowy
  • Reagowanie na zmiany ponad podążanie za planem.

Dokładając do tego 12 zasad Manifestu Agile, mamy prostą i zwięzłą receptę na zwinność.

  • Najwyższy priorytet ma dla nas zadowolenie klienta dzięki wczesnemu i ciągłemu wdrażaniu wartościowego oprogramowania.
  • Bądźcie gotowi na zmiany wymagań nawet na późnym etapie jego rozwoju. Procesy zwinne wykorzystują zmiany dla zapewnienia klientowi konkurencyjności.
  • Dostarczajcie funkcjonujące oprogramowanie często, w kilkutygodniowych lub kilkumiesięcznych odstępach. Im częściej, tym lepiej.
  • Zespoły biznesowe i deweloperskie muszą ściśle ze sobą współpracować w codziennej pracy przez cały czas trwania projektu.
  • Twórzcie projekty wokół zmotywowanych ludzi. Zapewnijcie im potrzebne środowisko oraz wsparcie i zaufajcie, że wykonają powierzone zadanie.
  • Najbardziej efektywnym i wydajnym sposobem przekazywania informacji zespołowi deweloperskiemu i wewnątrz niego jest rozmowa twarzą w twarz.
  • Działające oprogramowanie jest podstawową miarą postępu.
  • Procesy zwinne umożliwiają zrównoważony rozwój. Sponsorzy, deweloperzy oraz użytkownicy powinni być w stanie utrzymywać równe tempo pracy.
  • Ciągłe skupienie na technicznej doskonałości i dobrym projektowaniu zwiększa zwinność.
  • Prostota – sztuka minimalizowania ilości koniecznej pracy – jest kluczowa.
  • Najlepsze rozwiązania architektoniczne, wymagania i projekty pochodzą od samo organizujących się zespołów.
  • W regularnych odstępach czasu zespół analizuje możliwości poprawy swojej wydajności, a następnie dostraja i dostosowuje swoje działania do wyciągniętych wniosków.

Podpisane przez: Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas

Jak u Was jest ze zwinnością, w którym kierunku idziecie?
Sprawdzacie gdzie jesteście używając do tego Manifestu Agile. Zastanówcie się która z zasad u Was już działa, która była by najprostsza do wdrożenia w firmie, a które wymagają uważnego spojrzenia i sprawdzenia, która będzie dla Ciebie najtrudniejsza do wdrożenia w firmie.

Chcesz wiedzieć więcej?

Zapraszam Cie na CCD2017 gdzie poprowadzę temat  ZWINNOŚĆ – PODSTAWĄ KONKURENCYJNOŚCI PRACOWNIKÓW

Szkolenie HTML5/CSS W Krakowie

W poniedziałek i wtorek czas spędziłem w Krakowie. Wspólnie z Comarch Centrum Konferencyjno Szkoleniowym realizowałem szkolenie dla grupy, która chciała nauczyć się tworzyć strony internetowe w oparciu o HTML5 i CSS.

Agenda szkolenia HTML5 i CSS przewidywała dwa dni praktyki i teorii.

Agenda szkolenia HTML5/CSS
Agenda szkolenia – Tworzenie stron internetowych w HTML5 i CSS

Mapa celi zakładała:

  • poznanie wiedzy teoretycznej o HTML5 i CSS
  • ćwiczenia praktyczne których celem było nabycie doświadczenia w pisaniu kodu HTML5 i CSS
  • wszyscy chcieli osiągnąć wzrost kompetencji
Cele szkolenia HTML5 i CSS (wiedza teoretyczna, praktyka, wzrost kompetencji)
Cele szkolenia HTML5 i CSS (wiedza teoretyczna, praktyka, wzrost kompetencji)

Nie zabrakło przy tym oczywiście celu jakim była dobra zabawa 🙂

Pierwszy dzień spędziliśmy na nauce HTML5. Uczestnicy zapoznali się z znacznikami jakie oferuje standard HTML. Poznali nowe znaczniki HTML5.

Na ćwiczeniach praktycznych pisaliśmy poprawny kod HTML5. Uczestnicy szkolenia dowiedzieli się jak wygląda poprawna konstrukcja dokumentu HTML5, gdzie za chwilę sami przeszli do jego pisania i weryfikowania czy jest on zgodny z wytycznymi W3C.

Drugi dzień szkolenia poświęcony był kaskadowym arkuszom styli, tzw. CSS (en. Cascading Style Sheets).

Uczestnicy szkolenia ćwiczyli użycie selektorów. Pisali własne style (identyfikatory, klasy, pseudo-klasy). Doświadczali możliwości jakie niesie za sobą używanie CSS i HTML5.

Każdy z uczestników szkolenia, do dalszego zgłębiania wiedzy, otrzymał książkę o HTML5, CSS2 i CSS3.

Na co się odważysz, aby osiągnąć sukces?

Do wszys­tkiego, co czy­nisz pot­rze­ba ci od­wa­gi. Ja­kikol­wiek kurs obie­rzesz, zaw­sze znaj­dzie się ktoś, kto ci po­wie, że idziesz w złym kierun­ku, zaw­sze po­jawi się po­kusa myśle­nia, że Twoi kry­tycy mają rację. By nak­reślić kurs działania i zreali­zować go do końca, pot­rze­ba Ci od­wa­gi żołnie­rza. Również czas po­koju po­siada swe zwy­cięstwa, ale mogą ich za­koszto­wać tyl­ko ludzie odważni.

Ralph Waldo Emerson

Product Backlog Items (PBIs) – User Story, czyli Historyjka Użytkownika

W poprzednim wpisie opisałem czym są, czym mogą być elementy Product Backlogu (en. Product Backlog Items).

Jednym z elementów są historyjki użytkownika, znane pod anglojęzyczną nazwą User Stores.

Historyjka użytkownika to krótki, zwięzły opis, sformułowany językiem biznesowym, odnoszący się do konkretnej roli, np.: użytkownik końcowy, administrator, moderator, system, etc.

Who? What? Why?
Who? What? Why?

Aby usprawnić proces pisania, ustandaryzować go, powstało kilka szablonów o które Product Owner może się oprzeć pisząc historyjkę.

Moją ulubioną jest propozycja Micka Cohna .

Wersja Angielska:

As a <type of user>, I want <some goal> so that <some reason>
.

Wersja Polska:

Jako <kto> chcę <cel> dlatego gdyż <powód>

User stories (historyjki) wg. Mike Cohn

Gdzie, jak sam autor mówi, „so that” / „dlatego gdyż” jest opcją.

Taką też formę rozważamy na szkoleniach które prowadzę. Zobacz jak wyglądają moje szkolenia..

Chcesz nauczyć się pisać takie historyjki, przećwiczyć to na realnym pomyśle, zapraszam Cię na Szkolenie Scrum Master.

Po czym poznasz, że jesteś pewny swojej decyzji?

A jed­nak mógłbym tu­taj sie­dzieć w nies­kończo­ność, pogrążony w bez­czyn­ności, nieużyteczny. Nie byłoby to trudne. Wys­tar­czyłoby nicze­go nie chcieć, raz na zaw­sze wyrzec się wszys­tkiego, stać się przez­roczys­tym. To in­ni, ci, którzy w nieunik­niony sposób w końcu mnie zauważają, spro­wadzą mnie z pow­ro­tem do rzeczy­wis­tości. W ich spoj­rze­niach zno­wu zacznę is­tnieć. Stanę się tym, który nie zapłacił za swój błąd, tym, które­go grzechu nie sposób od­ku­pić. Wówczas do mnie będzie na­leżała de­cyz­ja: zos­tać czy uciec. W obyd­wu przy­pad­kach będę pot­rze­bował od­wa­gi.

Odwaga
Odwaga

Philippe Besson

Product Backlog Items (PBIs) w Scrum

Pojęcie elementu Product Backlogu w przewodniku pojawia się wielokrotnie, w różnych kontekście, np:

Rejestr Produktu (en. Product Backlog)

Product Backlog items have the attributes of a description, order, estimate and value.

Scrum Guide

Product Owner

Clearly expressing Product Backlog items.

Ensuring the Development Team understands items in the Product Backlog to the level needed.

Scrum Guide

Scrum Master

Helping the Scrum Team understand the need for clear and concise Product Backlog items.

Scrum Guide

Przerwanie sprintu (en. Cancelling a Sprint)

All incomplete Product Backlog Items are re-estimated and put back on the Product Backlog.

Scrum Guide

Planowanie sprintu (en. Sprint Planning)

Having set the Sprint Goal and selected the Product Backlog items for the Sprint, the Development Team decides how it will build this functionality into a „Done” product Increment during the Sprint. The Product Backlog items selected for this Sprint plus the plan for delivering them is called the Sprint Backlog.

Scrum Guide

Ja widać jest to dość istotny i ważny element Scrum. Pozwala identyfikować potrzeby które będą realizowane w ramach produktu. Odpowiednie nazwanie, opisanie potrzeby (PBIs) pozwoli Zespołowi Scrum, zrozumieć nad czym będzie pracował.

Elementami mogą być:

  • funkcjonalności,
  • wymagania,
  • błędy,
  • specyfikacje,
  • dokumentacja techniczna.

Struktura Product Backlog Items wygląda tak:

  • Opis – czego dotyczy potrzeba, jaki cel będzie spełniać
  • Wartość – określona przez Product Ownera, jaki wpływ będzie miała realizacja tego elementu na produkt
  • Estymacja – ile wysiłku włoży zespół w przekształcenie elementu w gotową implementację.
  • Ustawienie – na której pozycji ustawiony jest element w Rejestrze Produktu (en. Product Backlog). Im wyższa pozycja tym większy priorytet

Każdy Product Backlog Items powinien zachować odpowiednią jakość. Pomoże w tym definicja „Przygotowane” o której pisałem.

Przygotowuje szkolenia otwarte i zamknięte z obszaru metodyk zwinnych (Scrum, Scrum Master, Product Owner). Pomagam w podejmowaniu działań mających na celu wypracowanie zmiany w życiu. Na sesjach korzystam z coachingu jako narzędzia wspierającego proces.