2. Agile vs. DevOps

2.1. Agile, Scrum, Lean, XP…

../_images/agile-division-chart.png

Fig. 2.1. Agile można rozumieć jako sześć spójnych i łączących się dyscyplin.

Agile można rozumieć jako sześć spójnych i łączących się dyscyplin:

  • miękkie:

    • zarządzanie projektami,
    • biznes i produkty,
    • komunikacja i organizacja,
  • techniczne:

    • devops,
    • architektura IT,
    • jakość i praktyki.

2.1.1. Agile

  • What is Agile?
  • History
  • Agile Manifesto
  • Be Agile
  • That’s so wrong on so many levels

2.1.2. Lean Startup

  • Build
  • Measure
  • Learn

2.1.3. Refinement Simulation

  • Backlog decomposition
  • Iterating decomposition
  • Small, Medium, Large
  • Must, Should, Could
  • Sprint
Introduction to sticky cards backlog note format:
 
  • header: Priority, Sprint, Estimate, Epic
  • capital, technical letters
  • acceptance criteria
  • Solving disagreement on issue estimation
  • three columns estimation (Small, Medium, Large)
  • ballancing sprint capacity
  • managing hard dependencies (issue is blocked by)
  • managing soft dependencies (issue relates to other - logically should be done before, but it is not necessary)

2.1.4. Scrum

  • What is Scrum?

  • History

  • Introduction:

    • Iterative approach
    • What’s sprint?
    • Short sprints
  • Roles:

    • Scrum Master
    • Product Owner
    • Developer
    • Managers?
    • Flat structure?
    • Bubble organization chart
    • Heroes
    • Cross-functional team
  • Issues:

    • User Stories
    • Epics
    • Technical Tasks
  • Artifacts:

    • Backlog
    • Sprintlog
    • Task board
    • Units
    • Story Points
    • Business Value
  • Metrics:

    • Velocity
    • Capacity
    • Maturity
  • Meetings:

    • Daily Meeting
    • Planning
    • Retrospective
    • Refinement
    • Review
  • Planning and Refinement:

    • Estimation
    • How big your tasks should be?
    • Estimation support systems
    • Sprint goal
    • Acceptance Criteria
    • Definition of Done
  • Sprint Review:

    • Product Owners role
    • Stakeholders
    • Releasable functionality
    • Sprint Impediments
  • Charts:

    • Burn-down Chart
    • Burn-up Chart
    • Control Chart
    • Cumulative Flow Diagram
    • Epic Report
    • Sprint Report
    • Velocity Chart
    • Version Report
  • Team Interaction:

    • Transparency
    • Retrospective
    • Management role and team
    • Scrum, but…
    • Scrum, and…
    • Most common mistakes while Scrum implementation

2.1.5. Kanban

  • What’s Kanban?

  • History

  • Introduction:

    • Pull system
    • JIT
    • Context switching
    • Kanban Board
  • Improvement:

    • Muda
    • Jidoka
    • Kaizen
    • Bottlenecks
    • Metrics
    • Lean
  • Workflow:

    • Columns
    • Swimlanes
    • Expedite
    • Priority
    • SLA

2.1.6. Extreme Programming

  • What is Extreme Programming?

  • History

  • Practices:

    • Test Driven Development (TDD)
    • Behavior Driven Development (BDD)
    • Pair Programming
  • Quality:

    • Best Practices
    • Coding Standards
    • Clean Code
    • Code Review
    • Pull Requests

2.2. Backlog transformacji DevOps

2.2.1. Junior

  • Ekosystem: Baza wiedzy (Confluence)
  • Ekosystem: System do zarządzania zadaniami (JIRA i Jira Agile)
  • Szkolenie: Ekosystem Narzędziowy

2.2.2. Mid

  • Ekosystem: API (REST, wersjonowane, JSON)
  • Ekosystem: Artifactory
  • Ekosystem: Automatyczne testy backendu
  • Ekosystem: Automatyczne testy frontendu
  • Ekosystem: Automatyzacja Testów
  • Ekosystem: Bazy danych
  • Ekosystem: Centralne repozytorium kodu
  • Ekosystem: Code Coverage
  • Ekosystem: Code Review
  • Ekosystem: Continuous Integration (Jenkins / Bamboo)
  • Ekosystem: Feature Toggles
  • Ekosystem: Pittest - Testy Mutacyjne
  • Ekosystem: Podział na Backend i Frontend
  • Ekosystem: Połączenie Confluence <-> Jira <-> Stash <-> Jenkins
  • Ekosystem: Provisioning infrastruktury (Puppet / Salt / Ansible)
  • Ekosystem: Pull Requests
  • Ekosystem: Release Trains
  • Ekosystem: Scenariusze Testowe
  • Ekosystem: Smoke Testy
  • Ekosystem: SonarQube
  • Ekosystem: TDD - Test Driven Development
  • Ekosystem: Testy A/B
  • Ekosystem: Testy Blackbox
  • Ekosystem: Testy Eksploracyjne
  • Ekosystem: Testy Integracyjne
  • Ekosystem: Testy Regresyjne
  • Ekosystem: Testy Wydajnościowe
  • Ekosystem: Wdrożenie GIT Flow w repozytoriach zespołów
  • Szkolenie: Build - Test - Learn
  • Szkolenie: CI / CD
  • Szkolenie: Clean Code
  • Szkolenie: GIT Flow
  • Szkolenie: Lean Startup

2.2.3. Senior

  • Backlog: Wersjonowanie projektów informatycznych (v. Major.Minor.Bugfix)
  • Backlog: Wersjonowanie projektów nieinformatycznych (YYYY-MM)
  • Community: Quality Evangelists
  • Ekosystem: Automatyzacja testów bezpieczeństwa aplikacji
  • Ekosystem: Automatyzacja testów bezpieczeństwa sieci
  • Ekosystem: BDD - Behavior Driven Development
  • Ekosystem: Continuous Delivery (Jenkins / Bamboo)
  • Ekosystem: Docker i wirtualizacja środowiska produkcyjnego
  • Ekosystem: Flyway i migracja schematów baz danych
  • Ekosystem: Generowanie changelog
  • Ekosystem: Generowanie dokumentacji na podstawie Jiry
  • Ekosystem: Pair Programming
  • Ekosystem: Przejście w stronę Cloud i Full-Stack development
  • Ekosystem: Testy Penetracyjne
  • Ekosystem: Vagrant i wirtualizacja środowiska developerskiego
  • Quality: Collective Code Ownership
  • Szkolenie: Architektura (mikro)usługowa

2.2.4. Expert

  • Ekosystem: Andon - Management Dashboard
  • Ekosystem: Architektura (mikro)usługowa
  • Ekosystem: Big Data
  • Ekosystem: Business Inteligence
  • Ekosystem: Continuous Deployment (Jenkins / Bamboo)
  • Ekosystem: Evolutionary Design

2.3. Backlog tansformacji Agile

2.3.1. Junior

  • Backlog: Capacity
  • Backlog: Estymacja Godzinowa
  • Backlog: Estymacja Story Point
  • Backlog: Planowanie sprintów
  • Backlog: Priorytetyzacja MoSCoW
  • Backlog: Velocity
  • Management: Face2Face co tydzień
  • Management: szkolenie ze Scrum
  • Management: Wdrażanie produktów
  • Managemnt: Ewolucja nie Rewolucja przy wprowadzaniu zmian
  • Szkolenie: Context Switching
  • Szkolenie: Połączenie Scrum i Kanban
  • Szkolenie: Product Ownerzy
  • Szkolenie: Scrum Masterzy
  • Szkolenie: User Story Board (System Interaction Flow Diagram)
  • Szkolenie: Warsztat Tworzenie User Stories
  • Szkolenie: Zasada 5 Why
  • Szkolenie: Zespoły
  • Zespół: Analitycy -> Product Ownerzy
  • Zespół: Cel sprintu
  • Zespół: Daily
  • Zespół: Kalendarze zespołów
  • Zespół: Karty Retrospektyw
  • Zespół: Lidera zespołu
  • Zespół: Opóźniające się wdrożenia
  • Zespół: Planowanie
  • Zespół: Problem z pojemnością sprintów - Puste sprinty
  • Zespół: Refinement
  • Zespół: Retrospektywa
  • Zespół: Retrospektywa + Skrzynki na pomysły
  • Zespół: Review
  • Zespół: Rola Analityka
  • Zespół: Rola PR + Marketing
  • Zespół: Rola Product Ownera
  • Zespół: Rola Programisty - App
  • Zespół: Rola Programisty - Feature
  • Zespół: Rola Programisty - Infrastruktura
  • Zespół: Rola Testera
  • Zespół: Rola UX
  • Zespół: Skrzynka na pomysły i sugestie do retrospektyw
  • Zespół: Stworzenie zespołu Zero / Alpha
  • Zespół: Tygodniowe sprinty

2.3.2. Mid

  • Backlog: Burndown Chart
  • Backlog: Control Chart
  • Backlog: Cumulative Flow Chart
  • Backlog: Kryteria Akceptacyjne
  • Backlog: Refinement i dekompozycja zadań
  • Backlog: Velocity Chart
  • Community: Product Ownerzy
  • Community: Scrum Masterzy
  • HR: Onboarding
  • Management: Portfolio projektów
  • Management: Porządki w procesach
  • Management: Scrum of Scrums
  • Management: Struktura produktowa
  • Management: Synchronizacja zespołów
  • Management: Tworzenie zespołów
  • Szkolenie: Warsztat Refinement
  • Zespół: Definition of Done
  • Zespół: Definition of Ready
  • Zespół: Konstytucja Zespołu
  • Zespół: Zespoły multidyscyplinarne

2.3.3. Senior

  • Backlog: Budowanie MVP - Minimum Viable Product
  • Backlog: Walking Skeleton
  • Community: Zaangażowanie ludzi w uczestnictwo w spotkaniach Community
  • Community: Zaangażowanie ludzi w wykładanie na Community
  • HR: Cele kwartalne
  • HR: Cele S.M.A.R.T.
  • HR: Ocena 360
  • HR: Oceny pracownicze
  • Management: Autonomia zespołów
  • Management: Środowisko bezpiecznych eksperymentów
  • Zespół: Joint Operations - projekty przy współpracy różnych zespołów
  • Zespół: Product Owner wewnętrzny a zewnętrzny
  • Zespół: Scientific Method przy eksperymentowaniu i wyciąganiu wniosków
  • Zespół: Wciągnięcie Klienta w proces jako Product Owner
  • Zespół: Włączenie Klienta przy pomocy Product Ownera w priorytetyzację backlogu oraz ustawianie zakresu sprintów

2.3.4. Expert

  • Community: Kontrybucja do Open Data
  • Community: Kontrybucja do Open Source
  • HR: Coaching osobisty i kultura Mentoringu
  • HR: Employee Engagement - Zaangażowanie pracowników
  • HR: Motywacja pracowników
  • HR: Rozmowy z pracownikami na temat podwyżek
  • HR: System Premiowy
  • Management: Audyt wewnętrzny
  • Management: Gamification
  • Management: Kultura feedbacku
  • Management: Kultura organizacji
  • Management: Organizacja ucząca się
  • Management: ROI i Cost Analysys
  • Management: TCO - Total Cost of Ownership
  • Management: Umowy Agile - Business Value
  • Management: Umowy Agile - Sprzedaż sprintów
  • Management: Umowy Agile - Sprzedaż Story Points

2.4. Spotify Engineering Culture @youtube.com

../_images/spotify-engineering-culture-01.png

Fig. 2.2. Spotify Engineering Culture @youtube.com

2.5. Community

2.5.1. Rekrutacja

  1. Czy na waszej stronie jest widocznie wyeksponowana informacja, że szukacie pracowników?
  2. Czy opis jest precyzyjny?
  3. Czy są wypisane informacje o technologiach?
  4. Czy jest informacja gdzie macie biuro?
  5. Czy rozważaliście możliwość pracy zdalnej? Programiści to uwielbiają, a wiele firm się na to nie zgadza co może być kartą przetargową na waszą korzyść.
  6. Skracanie dystansu. Ludzie z IT zwracają się do siebie dość bezpośrednio. “Panowanie” powoduje delikatną niechęć i wizerunek sztywnej firmy, w których ludzie z IT nie chcą pracować.
  7. Jakie zarobki proponujecie? Firmy niechętnie dzielą się widełkami co bardzo irytuje kandydatów “muszę się wstrzelić”, może to jest pole do innowacyjności.
  8. Targi pracy (np. http://careercon.pl/ ). Wystawianie kosztuje chyba koło 3k ale nie wiem czy jest opłacalne. Lepiej wziąć swojego najlepszego człowieka, trochę podszkolić z przemówień publicznych i zagadać z organizatorami, aby w ramach “wykładu z praktykiem” go wystawić. Ma opowiadać o technologii, wycenie projektów albo o prowadzeniu firmy. Ogólnie ta sama zasada co do community. Nie reklamować, dostarczać treść i doświadczenie!
  9. Jakie zarobki proponujecie? Firmy niechętnie dzielą się widełkami co bardzo irytuje kandydatów “muszę się wstrzelić”, może to jest pole do innowacyjności.

2.5.2. Community

  1. Udzielanie się w community. Weźcie swoich najlepszych ludzi i poproście ich aby zrobili np. wykład na kole naukowym, albo jednym z wielu informatycznych ugrupowań. Tam są ludzie, których szukacie. Polecam też zrobienie wykładu na Careercon.
  2. O tym jak się pracuje muszą mówić programiści programistom w ich specyficznym języku. Każdego rodzaju przejaw PRu będzie odbierany przez ludzi z IT baaaaardzo negatywnie. Ja np. jeździłem po konferencjach i opowiadałem o tym jak ważna jest jakość kodu, który piszemy, o tym co to jest SCRUM, DevOps i jak być Agile i łączyć to z technologią. Nigdzie na slajdach nie wspominałem, dla kogo pracuję. Wszelkiego rodzaju PRowe szablony można od razu odrzucić. Ludzie nie kupują tego. Jedyna sugestia, że pracuję dla mojej firmy była gdy się przedstawiałem oraz czasami jeszcze w agendzie. Kiedy ludzie cenią materiał, który im się przekazuje będą pozytywnie patrzeć na firmę i sami wyciągną informację dla kogo pracujesz i jak tam jest. Ludzie z IT są baaardzo wyczuleni na jak to sami określają “pijar”. Jakość obroni się sama.
  3. Taki proces poprawy wizerunku trwa latami i nie da się przewidzieć jego budżetu. Gdy prelegenci będą dobrzy, można poza kosztami ich podróży nic nie wydawać a o firmie będzie się niosło. Kiedy będą słabi, lub będą to osoby z HR mówiące o programowaniu można wydawać krocie i nic nie osiągnąć.
  4. Sponsorowanie eventów jest słabe. Kupa kasy na niezbyt duży rozdźwięk. Już lepiej dogadać się z organizatorami i kupić 10 pizz i rozdać uczestnikom na spotkaniu. Przy okazji niech powiedzą, że to od Was. Wystawianie się na targach jest drogie i nie wiem czy aż tak skuteczne jak mogłoby się wydawać.
  5. Udzielanie się w community. Pogadaj ze swoimi technicznymi ludźmi i postaraj się ich wypchnąć jako prelegentów na konferencje, spotkania community itp. Niech nie opowiadają o firmie (to ważne), tylko o technologiach i projektach oraz o ich użyciu. Ludzie nie lubią nachalnej reklamy. Żadnych slajdów z ogromnym logo firmy itp. Chodzi o to aby stworzyć wizerunek super miejsca, w której ludzie naprawdę są zajarani tym co robią. Dać coś community, a później ludzie sami się zgłoszą. I jak się zainteresują odszukają Twoją firmę sami. Żadnych garniturów, rolexów i BMW. Prosty człowiek do prostego człowieka. Koleś w geekowskiej koszulce opowiada bez bullshitów o problemach również oraz tym jak sobie z nimi radzicie. Wszyscy mają problemy więc nie można przesłodzić, że jest cukierkowo itp.
  6. Crossweb. Skarbnica wiedzy na temat tego co się dzieje w community w kraju. Genialne dla każdej osoby, która szuka pracowników. Podepnij sobie RSSy do jakiegoś czytnika albo zapisz się do newslettera i na bieżąco będziesz śledził aktywność:
  1. Koła naukowe. Potrzebują pokierowania i technicznych ludzi, którzy pracują i chcą się podzielić wiedzą. Zasada ta sama co w udzielaniu się w community. Nie reklamować, dostarczać treść i doświadczenie!