DevOps maakt af wat Agile begon

Transcriptie

1 1 van :06 Wachtwoord vergeten Registreren DevOps maakt af wat Agile begon :42 Door Anko Tijman Lees meer artikelen over: Testing, Agile Er zijn 14 reacties op dit artikel Permalink Computable Expert Anko Tijman Thoughtleader Agile Expert van Computable voor het topic Development Meer Bent je nog druk met Agile implementeren? Wees je er dan van bewust dat de volgende vloedgolf aan veranderingen er al weer aan komt. De golf DevOps maakt af wat Agile begonnen is: technologische en procesmatige integratie tussen ontwikkeling en beheer. Waar Agile zich primair focust op klant en it-vernieuwing, wordt met DevOps definitief de laatste muur geslecht: die voor de beheerafdeling. In deze blog licht ik een tipje van de sluier van DevOps op. Bij DevOps draait het dus om samenwerking tussen ontwikkeling en beheer. Daar komt de naam ook vandaan: Dev staat voor Development en Ops voor Operations. In DevOps zitten een tweetal kernprincipes: Continuous Integration en Continuous Delivery. Onder Continuous Integration (CI) verstaan we snelle, geautomatiseerde deployments van de ene omgeving naar de andere. Dat kan de traditionele ontwikkeling test acceptatie en productie (otap)-straat zijn, maar ook het kortcyclisch verbinden van zij-straten valt hier onder. Dit geeft de mogelijkheid om snel de kwaliteit van de nieuwe software te testen en te toetsen. Op zich wordt dit binnen Agile projecten ook vaak al gedaan om de afstand tussen ontwikkelaars en testers te verkleinen. Continuous Delivery (CD) hanteert min of meer hetzelfde principe, alleen is er sprake van nog meer automatisering en nog minder afbakening van een release. Feitelijk is er een volledig geautomatiseerde gang naar productie, zonder menselijk ingrijpen. Alle stappen worden namelijk geautomatiseerd getest in een framework. CD stelt je in staat om zeer frequent in zeer kleine batches software op productie te releasen. Soms zelfs meerdere keren per dag. Die updates zijn zo klein dat de impact van een fout vaak nihil is. Dit wordt geharnast door een uitgebreide set aan geautomatiseerde tests die de belangrijkste risico s afvangen. Inmiddels hebben wij een team draaien bij een klant waarbij er in twintig minuten geïntegreerd, getest en gedeployed kan worden naar productie. En dat dus zonder grote risico s!

2 2 van :06 Wat moet mijn organisatie met DevOps? Het belangrijkste nieuws van DevOps is dat er geen belemmeringen meer zijn voor een snelle respons van it op business wensen. Maak je mensen, zowel vanuit de business, ontwikkeling als beheer, hierop attent. In een tijd waarin effectiviteit wordt gewaardeerd boven efficiency, worden paarse krokodillentranen niet getolereerd. Concreet betekent het dus investeren in verregaande automatisering, dus kritische toolselectie. Geen eilandjescultuur meer waarin teamperformance wordt geoptimaliseerd (een vervelend bij-effect van Agile werken!), maar een gezamenlijk doel en het operationaliseren van organisatieperformance. Er komt één keten van business-wens naar deployment, waarin alle activiteiten in het teken staan van beheersbaar live gaan. Zoals een collega van mij gonlangs zei: 'Alles is beheer!'. Jouw beheerafdeling werkt waarschijnlijk aan de hand van Itil, ASL en BiSL. Je ontwikkelteams werken volgens Agile-Scrum. Dat gaat dus botsen. Wie van de twee 'vechtende honden' gaat de methodenclash winnen? Wat mij betreft wint de derde hond: je bedrijfsvoering. Laten zij maar aangeven wat waarde heeft: een nieuw stukje software of een incident, een nieuw project of een stel bugs, technisch onderhoud of een nieuwe tool. Vergeet het onderscheid tussen incidents en changes en laat de business beginnen met het prioriteren naar business waarde. Zet nu eindelijk de business aan het roer van je it-organisatie en zorg dat je dit zo goed, snel, en beheerst mogelijk faciliteert. Ik ben ervan overtuigd dat het serieus implementeren van DevOps dit mogelijk maakt. Partnerinformatie Sponsored content KPN 4G - Altijd en overal ondernemen op hoge snelheid Virtualisatie tot de vierde macht Daarom zet je je backup in de cloud! Hoe bepaalt u welke applicaties geschikt zijn voor de cloud? 100 Gig over glas staat op doorbreken KPN 4G vshape Macaw Macaw Equinix Reacties op dit artikel mauwerd, :20 voor mij duidelijk, maar voor business ook? Gaan zij betalen als ze meerwaarde niet zien? Anko Tijman, :27 Hi mauwerd, Volgens mij is DevOps heel logisch: laten we er voor zorgen dat we technische en procesmatige beperkingen in het live brengen van software zo veel mogelijk oplossen. Dat is niet heel moeilijk te begrijpen ;-) Ik denk dat de business op dit moment voldoende pijn voelt in de kat en muis spelletjes tussen Ontwikkeling en Beheer en de daarbij gepaard gaande lange overdrachtsmomenten. Ben Linders, :57 Mooi en duidelijk artikel over DevOps, het laat de kracht van de verbinding tussen de Business en de IT zien. En dat is iets waar bij veel bedrijven die agile zijn gaan werken nog winst te behalen Als er volgens de business geen meerwaarde is, dan moet je het niet doen. Maar mijn ervaring is dat als Business en IT samen eens goed kijken, dan is er altijd wel iets met meerwaarde te vinden. Nog genoeg te doen wat ook nut heeft!

3 3 van :06 NoudW, :16 Hoe logisch dit allemaal ook lijkt, er schuilt m.i. een uitdaging in de interpretatie van wat we "de wensen van de business" noemen. Mijn ervaring is dat business wensen vaak impulsief lijken te zijn, geuit vanuit een onvermogen/onbekendheid met een bepaalde situatie/ontwikkeling. Ben Linders, Onbekendheid en onvermogen kun je aanpakken met de samenwerking van Business en IT, en goed communicatie. In het begin onwennig, maar als het daarna gaat lopen, dan betaald het zich zeker terug! Martijn de Vrieze, :02 Leuk stuk Anko. Om je antwoord aan Mauwerd wat aan te vullen: de investering voor DevOps is, als je het goed aanpakt, fundamenteel minder dan bijvoorbeeld de overschakeling van Waterval naar Agile. Een groot aantal voordelen van DevOps wordt al heel snel duidelijk en daarmee ook voelbaar binnen een organisatie. DevOps is erg strak gericht op een verkorte time to market, snellere en naadlozere integratie van nieuwe "dingen" in de productie omgeving en vergt vanuit de Business veel minder effort om te snappen wat er gaande is. Zoals Anko al zegt, DevOps is vooral heel erg logisch en eigenlijk zelfs voor de hand "de wensen van de business" is een uitdaging in willekeurig welke aanpak ook gebruikt wordt. Groot voordeel van Agile en DevOps is dat ze zo ongeveer tailored zijn om efficient en effectief om te gaan met impulsieve wensen en wijzigingen. mauwerd, Zoals ik development met Agile begrijp, hoeft dat ook niet extra te kosten (vergeleken Waterval). En de klant merkt het ook direct want die krijgt status overzicht na elke sprint en kan bijsturen. Anko beschrijft tegengestelde culturen tussen ontwikkeling en beheer en DevOps om dat op te lossen. Helder toegelicht en voor mij herkenbaar ook. Maar business wil bezuinigen en waarom zou die op moeten draaien voor verbetering tussen samenwerking tussen ontwikkeling en beheer? Voor Business is ontwikkeling samen met beheer een grote ICT pot nat. Probeer maar eens duidelijk te maken dat de Business extra moet betalen op wat een interne ICT aangelegenheid is. Anko Tijman, investeren kan IT ook vanuit haar eigen budgetten! Hans kroon, :19 Als het om IT Service Management gaat is het eerste dat moet gebeuren: zorgen voor een eenduidig changeproces. Het tweede is: development integreren in beheer. Het derde is: managen op het doorvoeren van het eerste en tweede. En nu eens ophouden met het verzinnen van allerlei kekke naampjes voor oplossingen voor zaken die met logica en gezond verstand kunnen worden aangepakt. De methodenclash die hier wordt genoemd is feitelijk een management clash. Een Mindset clash ook, van IT-(manage)ers die zichzelf belangrijker vinden dan het resultaat van goed ITSM. In die zin snijdt dit artikel nog wel wat toevoegde waarde. Maar dit even oplossen via snelle taal en oppervlakkig denkwerk gaat mij te ver. Evenals de aanname dat ITIL, BiSL of ASL wordt gebruikt en dat die botsten met Agile-Scrum. Het zijn geen methodes en ze hanteren geen logisch procesmodel. Als dat wel het geval was zou er vaker sprake zijn van goede en goed bestuurde processen en dan botst er niets. Integendeel, een goed georganiseerd proces kun je net zo agile maken als je zelf wilt en als goed is voor jouw bedrijf. Wat dat betreft moet je misschien nog eens goed kijken naar FSM en ISM. Als het gaat om de behoefte aan ondersteunende functionaliteit en middelen om het primaire business proces te optimaliseren en daardoor de bedrijfsdoelstellingen beter en sneller te realiseren dan is de business ALTIJD leading. Het is de kunst die behoefte eenduidig vast te leggen en vast te stellen en daar vervolgens de juiste oplossing bij te leveren. Het maakt niet uit wat je wilt veranderen, maar als er sprake is van verandering dan gaat dat altijd en overal via dezelfde

4 4 van :06 principes (en het is niet eens uniek voor ICT). Je kunt er voor kiezen om dit kort cyclisch te doen of in grotere stappen, maar de cyclus is generiek. Je hoeft hem alleen maar aan te passen aan de aard van de business. Erik Buitenhuis, :29 Ik zie DevOps als onderdeel van Agile en niet zozeer als een stap verder dan Agile. Goede development practices zijn essentieel in Agile. In XP kennen we al Continuus Integration, en Continuus Delivery is het logische vervolg hier op. Ik ben het eens Kroon's opmerking over kekke naampjes! Binnen Agile is er sterke focus op team efficiency en performance, maar daar houdt het zeker niet op. Ik bestrijd de stelling dat een vervelend bij-effect van Agile werken is dat we in eilandjes binnen teams alles optimaliseren en de samenwerking daarbuiten te wensen over laat. Denk bijvoorbeeld aan Lean, aan business agility, agile contracts, etc... Allemaal ingredienten voor een optimale flow door de hele organisatie! Maar ook een goede Scrum implementatie houdt niet op bij de teams! Het is misschien wel de grootste misvatting over Agile dat Agile een IT speeltje is! Het gaat bij Agile vooral om de mindset, de bedrijfscultuur waar iedereen gericht is op een zo efficient en effectief mogelijke samenwerking. Welke praktijken je daar aan koppelt is van ondergeschikt belang! Wat betreft de methodenclash tussen Development en Beheer: Als we het over Continuus Delivery hebben gaat het niet meer over Scrum teams. Scrum is kortcyclisch, maar niet Continuus! Ik zou in dat geval voor Kanban kiezen. Prima geschikt om ontwikkeling en beheer te combineren. En waarom dan nog een aparte beheerclub? Anko Tijman, Kroon: jouw commentaar op mijn bijdrage snijdt zeker hout. Ja, de botsing in culturen en managementstijl zal groter dan de clash in methoden. En nee ik weet dat ASL en BiSL geen methoden zijn. Ik probeerde wel de verschillende culturen te schetsen en dat was iets te kort door de bocht. Maar als ik nu op de ISM- en FSMportal kijk, dan zie ik daar toch heel vaak woorden als processen, procesmodel, standaardmethode, passende processen etcetera staan. Weinig over mensen, houding, attitude en al die andere zaken waarvan het Agile Manifesto aangeeft wat nu echt de succesfactoren van een project zijn. Wat mij betreft is DevOps de aanleiding om DOOR te gaan met het 'agiliseren' van organisaties. En dat doen we vooral vanuit wederzijds begrip. Anko Tijman, Ik zie Agile als een onderdeel van DevOps :-). Agile is voor mij de opmaat die binnen IT-Ontwikkeling is gestart naar het doorbreken van functionele silo's. Daar is het in haar context ook gelukt. Maar de brug naar IT-Beheer is vaak nog steeds een brug te ver. Alleen maar een beheerder bij de demo's toelaten en af en toe een documentje laten schrijven doet het voor mij niet. Overigens zie ik bij Agile juist een shift naar meer effectief werken (doen we het goede voor de business) dan naar efficient werken (doen we het goed in ons proces). Ik zie Continuous Delivery ook als onderdeel van DevOps: het faciliteren van de technische randvoorwaarden om te komen tot het snel kunnen leveren van waarde voor de business. Ben het met je eens over Kanban boven Scrum. Volgens mij komen we qua mindset aardig overeen :-) PaVaKe, :01 Leuk verhaal. Een paar jaar geleden al wat verhalen over bedrijven als amazon, ebay, intuit enz. die al langer op deze manier werken. De grote kracht hiervan is inderdaad dat je heel snel in kunt spelen op de behoeften van de markt/klant. Maar uiteraard is dit wel markt specifiek. Je architectuur zal toe moeten staan dat je bepaalde onderdelen snel in isolatie kunt ontwikkelen en testen, zonder dat de rest van het systeem daar hinder van zal ondervinden. Maar ook het soort wijzigingen dat je op deze manier wil introduceren is bepalend. Het maakt nogal verschil of je een button verplaatst in een webapplicatie voor het bestellen van boeken (omdat mensen volgens de experts dan meer kopen) of dat je de user interface van een medisch systeem verandert, waardoor de arts niet meer even snel bepaalde gegevens kan achterhalen tijdens een behandeling. Het kunnen (en willen) doorbreken van de functionele silo's, zoals Anko weergeeft in één van de reacties is uiteraard ook heel belangrijk. Wat daarbij vooral van cruciaal belang is, is dat men elkaars werelden leert begrijpen. Hierbij maakt het niet uit of je scrum, agile, waterval of kanban gebruikt. Onlangs nog een mooi voorbeeld hiervan ervaren. De architect had een bepaalde manier van het bouwen van het product voor ogen. Hierbij zou altijd alles gebouwd worden, in plaats van alleen de gewijzigde module. Wat betreffende architect over het hoofd zag (door gebrek aan inzicht in de totale keten) is dat dit voor de mensen die de installatie in het veld moeten doe betekent dat een installatie 2 uur duurt in plaats van een kwartier. Dus het systeem van de klant moet langer "down", upgrade in het veld kost meer tijd en is dus duurder enz. enz. Functioneel (één van de eerste silo's) werkte zijn aanpak wel, maar aan de kant van beheer (één van de laatste silo's) zagen ze zijn idee niet te zitten. (Wat Erik ook al aangeeft in zijn reactie).

5 5 van :06 Niet alleen silo's moeten afgebroken worden, vooral ook de heilige huisjes van managers en/of techneuten die hun silo koste wat het kost in stand willen houden. Bernard Stibbe, :48 Ik heb het idee, dat bij de DevOps team, het plaatje nog niet volledig is. Het gaat erom: "om nog snellere responses te geven van IT op business wensen." Dus waarom halen we er niet in het team ook een business entiteit erbij, in de vorm van "echte eindgebruikers". Dan is de commitment compleet. Dus DevOpsBus. De Business entiteit kan bepalen welke business functionaliteit echt noodzakelijk is, de Developers kunnen zien of het technisch haalbaar is en de complexiteit, en samen wordt bepaald welke bedrijfsprocessen en gebruikersgroepen ondersteund en getest gaan worden. Dus de gebruikers, die de business functionaliteit in kaart hebben gebracht, testen hun eigen business functionaliteit, die een bepaalde business case vertegenwoordigd. Verder hebben we dan ook meteen een directe communicatie tussen (eind)gebruikers en developers. Alleen voor DevOps teams is het nog steeds een ICT feestje, terwijl we de ICT ondersteuning zijn van de business...