DevOps

Agile

# Agile

Als we kijken naarhet hedendaagse IT landschap zien we mooie vooruitgangen in onze leefwereld maar ook heel wat problemen. We kunnen al eeuwen projecten afwerken, maar al deze methodes falen in software? We zien in het nieuws stuk voor stuk gefaalde grote software projecten gebeuren, en dit is maar het tipje van de ijsberg. Terwijl we dit in niet-IT veel minder zien. We zijn al bezig met dit fenomeen sinds 1950!

Wat is er nu zo anders? In de IT hebben we te maken met een constante evolutie van onze technologie, veel sneller dan andere sectoren. Daarboven kennen we een constante evolutie van eisen, de wereld rondom ons veranderd bijna op een even snel tempo.

Software is als de antwerpse ring, je bouwt jaren aan een tunnel die veel te groot is en in 5 jaar tijd is ze al te klein. (Lees 50 jaar Kennedytunnel (opens new window))

Maar we hebben een geluk: software is flexibel!

# Wat vooraf ging

Sinds de jaren 50 waren we hier al mee bezig, hoe kunnen we IT processen efficienter maken? Er zijn vele verouderde methoden maar nog een is zeer bekend, de waterfall methode.

waterfall method

De waterfall methode gebruikt verschillende fases in een project, waar we vloeien van de ene stap naar de andere. Op het einde komen we uit in het resultaat. Net als in een waterval gaan we vlot naar beneden, maar nooit meer terug naar boven.

Waterfall is gemakkelijk te gebruiken door de simpliciteit van het model, de stappen zijn duidelijk en worden 1 voor 1 aangepakt. Na elke stap wordt duidelijk vooruitgang geboekt, wat motiverend kan werken. Werkt erg goed voor projecten waar de requirements erg duidelijk zijn en niet zullen veranderen. Waterfall vereist wel veel papierwerk, wat niet altijd leuk is maar er wel voor zorgt dat nieuwe collega’s makkelijk mee aan de slag kunnen.

Maar waarom gebruiken we nu geen waterfall meer?? Eens je aan het testen bent kan je niet meer terug gaan een veranderingen maken in het project. Dit is een groot probleem als iemand tijdens analyse een fout maakt. Je hebt ook pas effectief werkende software tijdens de laatste stappen van het project, dit kan maanden of jaren later zijn. het is geen goed model voor lange projecten (kans dat er verandering moeten gebeuren wordt groter met de tijd). Slecht model waar de requirements van het project niet met zekerheid vast liggen, iets wat in deze wereld bijna onmogelijk is. Toch een stap terug moeten gaan door een fout kost heel veel tijd en geld.

De IT-wereld verandert snel, het project kan achterhaald zijn voor het af is, ik wil niet berekenen hoeveel projecten door COVID-19 in het water gevallen zijn.

# LEAN

LEAN is enige tijd een model geweest dat in de IT wereld zijn intreden maakte. LEAN echter komt uit de auto wereld. Het is ontwikkeld door Toyota voor verbetering van fabricage van auto's. Toch heeft het een verbeterign kunnen leveren in vele andere sectoren, de kans dat je dit ergens hoort is dan ook enorm groot.

LEAN letterlijk vertaald is "mager" of "slank" Lean is een business strategie en vooral een manier van werken waarbij alles en iedereen in de onderneming zich richt op het creëren van waarde voor de klant in alle processen. Hierdoor worden verspillingen geëlimineerd.

LEAN diagram

Lean Manufacturing heeft een paar pijlers

Dit te bereiken door

Voor IT heeft dit model echter een paar gevaren, het is gemaakt voor grootschalige productie. En het kan innovatie beperken.

# Agile Manifesto

Het Agile Manifesto kent zijn oorsprong in 2001. Toen afvaardiging van tal van Agile software development methodologies en sympathisanten van een alternatief voor de klassieke, documentatie gerichte, zware software development processen, kwamen samen om hierover van gedachten te wisselen. Resultaat: het Agile Manifesto (opens new window)!

Wat stond er in dit manifesto? 12 punten over hoe we software moeten ontwikkelen.

  1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
  3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  4. Business people and developers must work together daily throughout the project.
  5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  7. Working software is the primary measure of progress.
  8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  9. Continuous attention to technical excellence and good design enhances agility.
  10. Simplicity --the art of maximizing the amount of work not done-- is essential.
  11. The best architectures, requirements, and designs emerge from self-organizing teams.
  12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Deze methodes legden de grondslag van een nieuwe werkwijze voor software development op. We merken enkele gelijkenissen met LEAN maar ook grote verschillen. Agile focust echter niet op grote schaal werken maar ik kleine teams snel kunnen opleveren en aanpassen.

Hoe dit de bereiken in de praktijk? Dat zien we verder in SCRUM en Kanban.

# Kanban bord.

Kanban van het Japanse kan (visueel) en ban (kaart of bord) is een concept gebruikt in lean manufacturing en just-in-timeproductie. Toch is de metodologie ook in de IT gebruikt. Kanban staat voor een continue flow van taken van links naar rechts. Dit weergegeven op een bord.

Sommige DevOps teams werken vooral in het Kanban principe met flexibele tijdspannes. Zij plannen dan meetings om het bord te verfijnen en te bekijken.

kanban bord

Wij kijken hier vooral naarhet Kanban bord. Hoe dit te organiseren gaan we in een meer vastgelegde planning bekijken bij SCRUM. Deze borden bestaan in hun simpelste vorm uit

Meestal zien we ook nog:

De Kanban methodologie gebruik je in 2 manieren:

# Tools

De bekendste tool is Trello (opens new window), echter zijn er ook vele andere tools die ook vooral op IT gericht zijn zoals Jira, Youtrack,... In deze cursus bekijken we GitHub Projects, hiermee kunnen we onze taken inplannen waar we onze code gaan beheren.

# SCRUM

Met Agile en Kanban bekijken we de cultuur en en een klein stukje werkmethodologie. SCRUM bekijkt hier tegenover het geheel van de flow. Inclusief rollen, meetings en organisatie.

scrum flow

# Rollen

We bekijken hier een aantal rollen die in de IT worden gebruikt.

# Artefacts

Buiten rollen gaan we ook altijd een aantal "dingen" terug vinden bij SCRUM:

# Meetings

# Oefening: Agile Lego

Een stad bouwen gebeurt niet in een dag en is misschien wel zo complex als software development. Deze oefening is geinspireerd op lego4scrum (opens new window).

Hiermee simuleren we een heel SCRUM process op een korte tijd met behulp van Lego!

# Rollen

# Tools

# Verloop

Doe verschillende sprints, 1 sprint is ~10 minuten bouwn. Houd de tijd bij!

Werk dit af tot je stad af is! Bepaal steeds de grootte van de tickets en de prioriteit.

# User Stories

Visie: we zijn de eerste bezetters van Mars, er zijn al meerdere vluchten onderweg vol met mensen die op Mars komen wonen. We moeten een stad bouwen die iedereen kan opvangen, levensbehoeften kan voorzien en als laatste ook mensen gelukkig kan maken in hun nieuwe leven. Een hele missie waar we constant moeten bijsturen en verbeteren.

Elk team werkt individueel aan een habitat maar deze moet wel kunnen samenwerken met de andere habitats.

# Sprint 1

# Sprint 2

# Sprint 3

# Sprint 4