Tuesday, April 7, 2015

ScanAgile2015: Titanic does not need to sink - Large scale scrum works /Ericsson

Ericcsonilta Norma Acevedo Lopez ja Almudena Rodriguez Pardo esittelivät Ericssonin käytäntöjän suurten hankkeiden läpivientiprosessista scrumin avulla. Perinteisesti tunnutaan ajattelevan ettei agile tai ainakaan scrum sovellu isoihin projekteihin tai kehityshankkeisiin, mutta selvästi siinä onnistutaan, kun niin halutaan.

Arkkitehtuurillinen suunnittelumalli


Ericssonilla on ollut käytössä arkkitehtuurillinen suunnittelumalli, joka edellisenä versiona oli koettu raskaaksi prosessimielessä, eikä tukenut kovin hyvin ketterien scrumtiimien tekemistä.
Vanha malli oli raskas, mutta tuote vakaa. Hyväksyntäprosessi oli kuormittava, kaikki muutokset käytettiin erillisten hyväksymistiimien kautta.

Arkkitehtuurillista suunnittelumallia uudistettiin, ja uudessa mallissa poistettiin raskas kiinnitetty hyväksyntätiimikäytäntö-
Uuden mallin hyödyt on lähinnä siinä että siinä ei tule pullonkauloja missään kohdassa, vaan eteneminen on ketterää ja tehokasta.
Kuitenkin haasteina on esim. se, ettei mallissa ole kiinnitettyjä jäseniä, ei virallista kunkin alueen kiinnitettyä asiantuntijaa ja arkkitehtuurimallin omistajaa.
Ideana on pitää kiinnitetyt SoS-tiimit, joihin kaikkien scrumtiimien scrum masterit osallistuvat. SoS-tiimi:
- konsultoi ja hyväksyy
- omistaa arkkitehtuurimallin
- on pysyvä jäsenten osalta



Riskienhallinta


Ericssonilla on selvästi ymmärretty ja sisäistetty  että siitä kannattaa maksaa, että oppi löydetään mahdollisimman pian projektin alkuvaiheissa. Suunnittelumallissa kiinnitetään huomiota erityisesti riskienhallintaan, Featureista tunnistetaan "spiket", joihin kiinnitetään huomiota heti alkuvaiheessa

Spikes

- jos jokin asia ei ole selkeä, se saattaa aiheuttaa riskin
- näiden vaikutusten tutkiminen ja arviointi suoritetaan mahdollisimman pian
- koodin laadunvarmistus tiimeissä


NBC

- Non Backward Compatibility
Koska Ericssonilla pyritään tuomaan jatkuvasti versioita, kiinnitetään kehityshankkeissa huomiota myös erityisesti yhteensopivusshaasteisiin joita multiversiointi tuo tullessaan.

[Wikipedia: In programming languages, backward compatibility refers to the ability of a compiler for version N of the language to accept programs or data that worked under version N - 1.[2] By this definition, if previous versions (N - 1, N - 2, etc.) were also backward compatible, which is often the case, then, by induction, version N will also accept input that worked under any prior version after, and including, the latest one that was not backward compatible. However, in practice, features are often deprecated and support is dropped in a later release, which is yet thought of as backward compatible.
In other contexts, a product or a technology is said to be backward compatible when it is able to fully take the place of an older product, by inter-operating with products that were designed for the older product]

Tehokkuus

Automated washing machine

Ericssonilla on kehitetty automatisoitu menetelmä nimeltä X-WM, jonka tarkoitus on automatisoida testausta systeemi- ja integraatiotestauksen osalta. Kaikki featuret ja koodit pyöräytetään washing machinen kautta, joka vähentää huomattavasti ongelmia integraatiovaiheessa ja lisää tehokkuutta.

Tehokkuutta saadaan myös sillä, että huolehditaan siitä että storyt ovat riittävän palasteltuja eikä yritetä tehdä kerralla liian isoja kokonaisuuksia. Resurssien ja tekemisen tehokkuutta saadaan tällä kasvatettua myös. Hyvä kirjoitus storyjen leikkaamisesta riittävän ohuiksi siivuiksi löytyy täältlä:
Alistair Cockburn: Elephant carpaccio


No comments:

Post a Comment