Både store og små prosjekter forventes å bli ferdige på en eller annen dato. Det er ikke bare størrelsen som er problemet. Det er selve arbeidsformen.
Prosjekt skaper konflikt mellom prosjektmål og virksomhetens mål, stor avstand mellom prosjekt- og linjeorganisasjon, en kortsiktig finansieringsmodell og utfordringer med overlevering og kunnskapsoverføring.
Å behandle leveransene som kontinuerlige produktutviklingsløp i linja gjør det enklere å realisere gevinster kontinuerlig, justere initiativene opp mot virksomhetens mål, involvere hele organisasjonen, løpende finansiering, bedre kommunikasjon og kunnskapsbygging istedenfor kunnskapsoverlevering.
Kontinuerlige Leveranser og DevOps er praksiser som lar virksomheter dytte idéer ut til sine kunder før andre er ferdige med sin første iterasjon. Kvaliteten på det som leveres øker i takt med hyppigheten på leveransene. Tettere samarbeid mellom drift og utvikling bidrar til at alle trekker i samme retning. Det er forretning som bestemmer når noe skal ut i produksjon, ikke IT. Vi er vitne til et av de største paradigmeskiftene innen IT i vår tid. De som ikke transformerer sine IT-organisasjoner risikerer å bli etterlatt for å dø.
Stein Inge vil i dette foredraget forklare hva DevOps og Kontinuerlige Leveranser innebærer og hvorfor det er så viktig å ikke bli sittende på gjerdet. Han vil også presentere egne erfaringer med å levere kontinuerlig.
Det er mye buzz rundt kontinuerlige leveranser og DevOps blant utviklere for tiden. Men hvorfor er dette også interessant for forretning? Hva gir det av verdi?
Robust smidig utvikling - når resultater er viktigere enn religionThor Henning Hetland
Smidige prosjekter er et stor suksess
Men vi har noen ’nye’ utfordringer
En lei tendens til å lage nye 2.5 lags database-sentriske siloapplikasjoner
”arkitektur, design er ikke viktig” –les: for vanskelig/tidkrevende
Testing –raske tester, som også skal være aktiv del av dokumentasjon er selvmotsigelser
Konfigurasjonsstyring –blir ofte ’glemt’ i smidige prosjekter, siden drift sjelden er aktiv stakeholder.
Smidig-bevegelsener religiøst selvsentrisk, og lite villige til å se konsekvenser
3-minutters guide: Slik lykkes du med smidig utviklingSteria Norway
Smidige metoder er som sjakk: Du kan lære grunnreglene på en kveld, men bruke hele
livet på å mestre detaljene. I denne guiden får du konkrete tips om hvordan du forbedrer kommunikasjon, kvalitet og verdiskapning i smidige og ikke-smidige prosjekter.
Kontinuerlige Leveranser og DevOps er praksiser som lar virksomheter dytte idéer ut til sine kunder før andre er ferdige med sin første iterasjon. Kvaliteten på det som leveres øker i takt med hyppigheten på leveransene. Tettere samarbeid mellom drift og utvikling bidrar til at alle trekker i samme retning. Det er forretning som bestemmer når noe skal ut i produksjon, ikke IT. Vi er vitne til et av de største paradigmeskiftene innen IT i vår tid. De som ikke transformerer sine IT-organisasjoner risikerer å bli etterlatt for å dø.
Stein Inge vil i dette foredraget forklare hva DevOps og Kontinuerlige Leveranser innebærer og hvorfor det er så viktig å ikke bli sittende på gjerdet. Han vil også presentere egne erfaringer med å levere kontinuerlig.
Det er mye buzz rundt kontinuerlige leveranser og DevOps blant utviklere for tiden. Men hvorfor er dette også interessant for forretning? Hva gir det av verdi?
Robust smidig utvikling - når resultater er viktigere enn religionThor Henning Hetland
Smidige prosjekter er et stor suksess
Men vi har noen ’nye’ utfordringer
En lei tendens til å lage nye 2.5 lags database-sentriske siloapplikasjoner
”arkitektur, design er ikke viktig” –les: for vanskelig/tidkrevende
Testing –raske tester, som også skal være aktiv del av dokumentasjon er selvmotsigelser
Konfigurasjonsstyring –blir ofte ’glemt’ i smidige prosjekter, siden drift sjelden er aktiv stakeholder.
Smidig-bevegelsener religiøst selvsentrisk, og lite villige til å se konsekvenser
3-minutters guide: Slik lykkes du med smidig utviklingSteria Norway
Smidige metoder er som sjakk: Du kan lære grunnreglene på en kveld, men bruke hele
livet på å mestre detaljene. I denne guiden får du konkrete tips om hvordan du forbedrer kommunikasjon, kvalitet og verdiskapning i smidige og ikke-smidige prosjekter.
Levine-Clark, Michael. “Can We Have it All? Do We Want it All? The Evolution of Academic Library Collection Development,” Invited Keynote. INFORUM Conference on Professional Information Resources, Prague, May 26, 2015.
Levine-Clark, Michael. “Can We Have it All? Do We Want it All? The Evolution of Academic Library Collection Development,” Invited Keynote. INFORUM Conference on Professional Information Resources, Prague, May 26, 2015.
Hva har vi lært av Innovativ Fjordturisme?Fjord Norge
Her er Anders Waage Nilsen sin presentasjon fra NCE tourism sin generalforsamling. Den fokuserer på hva vi har lært av prosessen med Innovativ Fjordturisme, og noen innspill til det videre arbeidet med NCE Tourism.
Majoriteten av etablerte selskaper har en lav modenhet når det kommer til å arbeide med innovasjon. Her presenterer vi en tilnærming til hvordan selskaper på bare 90 dager kan etablere de fundamentale elementene i et helhetlig innovasjonssystem og legge grunnlaget for strukturert og kontinuerlig innovasjonsarbeid.
Pådriv - presentasjon av strategisk retning og rammersocentral
En overordnet presentasjon av Pådriv, inkludert strategisk retning, målsetninger og budsjett i år 1. Presentasjonen er laget for å støtte en muntlig presentasjon.
Gjesteforelesning om strategisk bærekraft og GoForIT til UiASimen Sommerfeldt
GoForiT består av mange av de største aktørene innenfor bransjen, med både TEKNA, NITO, Accenture, Microsoft, UiA, NTNU, Sopra Steria, CGI, Bouvet, Itera og flere. Her kan du se hvordan vi tenker rundt strategisk bærekraft, og skal samarbeide for å sørge for at vi utdanner folk i takt med hvordan vi benytter bærekraft i arbeidslivet. Si fra hvis du ønsker link til opptak av foredraget
Bruk av BH konseptmodell i konseptfasen av Tønsbergprosjektet 7.nde byggetrinn. Målsetting modellbruk er å; a) forstå eksisterende bygg og høste erfaring, b) "se" og analysere nye bygg og se om de dekker behov og c) se helheten og "velge riktig prosjekt" som dekker dagens behov men også muliggjør fremtidig organisasjonutvikling. Enkel demonstrasjon.
My talk from DevOpsCon Berlin 2016.
Ansible is a radically simple and lightweight provisioning framework which makes your servers and applications easier to provision and deploy. By orchestrating your application deployments you gain benefits such as documentation as code, testability, continuous integration, version control, refactoring, automation and autonomy of your deployment routines, server and application configuration. Ansible uses a language that approaches plain English, uses SSH and has no agents to install on remote systems. It is the simplest way to automate and orchestrate application deployment, configuration management and continuous delivery.
In this tutorial you will be given an introduction to Ansible and learn how to provision Linux servers with a web-proxy, a database and some other packages. Furthermore we will automate zero downtime deployment of a Java application to a load balanced environment.
Presentasjon fra Smidig Digitalisering i Offentlig Sektor 2016. Basert på blogpost: http://open.bekk.no/orkestrering-av-it-utvikling-i-store-organisasjoner
Slides from my talk at CoDeOSL 2015, http://www.code-conf.com/osl15/
Abstract:
------------
We are witnessing perhaps the most disruptive and innovative period in IT in our time. Those not transforming their IT organizations towards DevOps and Continuous Delivery (CD) risk being left behind to die. This talk will place DevOps and CD in a historical context and explain how and why this paradigm shift will radically change how businesses acquire customers and deliver value to them.
Zero Downtime Deployment with Ansible - learn how to provision Linux servers with a web-proxy, a database and automate zero downtime deployment of a Java application to a load balanced environment.
These are the slides from a tutorial held at the Velocity Conference in Barcelona November 19th, 2014.
Git repo: https://github.com/steinim/zero-downtime-ansible
Når du driver med kontinuerlig leveranse er det et problem om du har nedetid hver gang du produksjonssetter når målet er å produksjonssette så ofte du kan. I denne lyntalen vil jeg vise hvordan du kan unngå nedetid når du deployer Java-web-applikasjoner. Jeg vil vise hvordan du kan deploye (og rulle tilbake) nye versjoner, og også hvordan du bør håndtere databaseendringer (og rollback) mellom deployments.
Kontinuerlige Leveranser og Devops praktiseres av svært mange skal man tro buzzen. Ved hjelp av nye verktøy og prosesser dytter virksomheter idéer ut til sine kunder før andre er ferdige med sin første iterasjon. Det er kunden som bestemmer når noe skal ut i produksjon, ikke IT. Og dette får de til uten å kompromisse på kvalitet. Hvem kunne ikke tenke seg å ha det sånn? Hvordan får de det til?
Vår erfaring er at det er lite hensiktsmessig, og til en viss grad svært farlig, å forsøke å få til dette i ett jafs. En mer fornuftig tilnærmingsmåte er å bygge stein for stein basert på tilstanden man befinner seg i, og gradvis forbedre situasjonen. Vi har laget en modenhetsmodell for kontinuerlige leveranser som inneholder teknikker og verktøy som bringer en nærmere målet, og det fine med å være på denne "reisen" er at hvert steg gir stor verdi i seg selv. I foredraget vil vi presentere noen erfaringer på godt og vondt med å implementere steg i modellen.
Vi vil starte med å presentere modenhetsmodellen, for deretter å ta for oss noen av teknikkene vi har hatt erfaringer med. Disse er; effektiv bruk av versjonskontroll, branch by abstraction, feature toggles, deployment pipelines med Jenkins, infrastruktur som kode med Puppet, virtualisering av produksjonslike miljøer for utvikling og test (Virtualbox, Vagrant), one-click deploy (og tilbakerulling), nedetidfri produksjonssetting og håndtering av databasemigrering (og tilbakerulling).
Getting software released to users can be risky, time-consuming and painful. The solution is the ability to deliver reliable software continuously through build, test and deployment automation, and through improved collaboration between developers, testers and operations. In this tutorial we will present principles and technical practices that enable teams to incrementally deliver software of high quality and value into production whenever they want, and extremely fast. The size of the project or the complexity of its code base does not matter.
In the first half of the tutorial we will introduce the concepts of continuous delivery, through continuous integration; and automation of the build, test and deployment process. We will also go through som basic principles and patterns for building automatable applications (architecture). We will cover experiences on team collaboration patterns and lastly; techniques for solving tasks such as an easy and comprehendible version control strategy.
The second half of the tutorial we will be working with automated provisioning of agile infrastructure, including the use of tools (puppet) to automate the management of testing and production environments. We will go through some scripting lessons examplifying how to implement zero-downtime deploys (… and rollback – if something goes wrong!), with examples in both bash and Ruby. Along with controlling the start, stop, restart lifecycles during deploys, we will also show some simple techniques for backups, logging, error handling, monitoring and verification of application health that can make the automation more robust.
We will also use servers "in the cloud" to demonstrate different techniques, and we hope to make it a fun day and to deliver software (examples) several times throughout the workshop.
Required knowledge: Agile/Lean basics, Linux basics, version control basics, maven basics.
4. (i norsk oversettelse)
“Et prosjekt er en tidsavgrenset bestrebelse
for å skape et unikt produkt eller en
tjeneste ... det har en definert start- og
slutt-tid, og derfor definert scope og
ressurser ... et prosjekt-team inkluderer
ofte folk som vanligvis ikke jobber sammen
...”
Project Management Institute, 2004
OPEN
25. Utfordringer med prosjekt som arbeidsform
vanskelig å realisere gevinster fortløpende
konflikt mellom prosjektets mål og virksomhetens mål
stor avstand mellom prosjekt- og linjeorganisasjon
kortsiktig finansieringsmodell
utfordringer med overlevering og kunnskapsoverføring
OPEN
26. Utfordringer med prosjekt som arbeidsform
vanskelig å realisere gevinster fortløpende
konflikt mellom prosjektets mål og virksomhetens mål
stor avstand mellom prosjekt- og linjeorganisasjon
kortsiktig finansieringsmodell
utfordringer med overlevering og kunnskapsoverføring
OPEN
27. Utfordringer med prosjekt som arbeidsform
vanskelig å realisere gevinster fortløpende
konflikt mellom prosjektets mål og virksomhetens mål
stor avstand mellom prosjekt- og linjeorganisasjon
kortsiktig finansieringsmodell
utfordringer med overlevering og kunnskapsoverføring
vanskelig å skalere opp
OPEN
29. Conway's lov
Organizations which design systems ... are
constrained to produce designs which are
copies of the communication structures of
these organizations
M. Conway, How Do Committees Invent, 1968
OPEN
48. Kontinuerlig ...
realisering av gevinster
justering av initiativene opp mot virksomhetens mål
involvering av hele organisasjonen
finansiering
kommunikasjon
kunnskapsbygging istedenfor kunnskapsoverlevering
OPEN
49. Kontinuerlig ...
realisering av gevinster
justering av initiativene opp mot virksomhetens mål
involvering av hele organisasjonen
finansiering
kommunikasjon
kunnskapsbygging istedenfor kunnskapsoverlevering
OPEN
50. Kontinuerlig ...
realisering av gevinster
justering av initiativene opp mot virksomhetens mål
involvering av hele organisasjonen
finansiering
kommunikasjon
kunnskapsbygging istedenfor kunnskapsoverlevering
skalering ved omprioritering av finansiering
OPEN
53. Success in terms of client benefit was only
weakly correlated with success in terms of
“on time” and “on budget”
OPEN
54. Benefit management planning before the
project started and benefit management
activities during project execution were
connected with success on delivering client
benefits
OPEN
57. Agile projects were, in general, more
successful than other projects, but
agile projects without flexible scope to
reflect changed user needs and learning,
OPEN
58. Agile projects were, in general, more
successful than other projects, but
agile projects without flexible scope to
reflect changed user needs and learning,
or without frequent delivery to the client,
OPEN
59. Agile projects were, in general, more
successful than other projects, but
agile projects without flexible scope to
reflect changed user needs and learning,
or without frequent delivery to the client,
had less than average success
OPEN
71. Kjennetegn ved suksessfulle smidige “prosjekter”
løpende timer – ikke fastpris
på tid og budsjett er mindre viktig
måler gevinstrealisering kontinuerlig
fleksibelt scope
hyppige leveranser
“Smidig” uten disse egenskapene har mindre suksess enn
vannfall.
OPEN
73. “Å jobbe i linja er når folk som kjenner
hverandre jobber sammen i autonome team
som skaper unike produkter eller tjenester
kontinuerlig, og tar ansvar for hele
livssyklusen til systemene de lager, og
måler verdien opp mot forretningens visjon
...”
Stein Inge Morisbak, 2015
OPEN