[English] - [Cymraeg]
Agile delivery allows for the iterative and evolving design and implementation of services to meet user needs – and this is a good thing. The challenge this can face, however, is that designs can focus on the Minimum Viable Product (MVP) and so when products start scaling or have additional contexts applied, the system can need substantial re-engineering or re-implementation to address these challenges.
Where there is a challenging or large tranche of transformation to achieve, there can be limited capacity within allocated funding to allow for re-development of already delivered products and plans often assume that products will be ‘right first time’ with ongoing effort limited to enhancements / changes from user feedback and not substantial rework.
To counteract this, I’ve listed below some principles that should be considered so that any potential product limitations are explicitly understood and agreed by the Product Owner.
- Don't design for target/end state as you will over-engineer for your early lifecycle phases – this was a traditional approach in waterfall projects, meaning products weren’t released until fully “finished”
- If you only design for your current release/MVP there is a risk you will need to throw much of your code away and business users seldom expect that, so it cannot be assumed this is part of the expectation. Call that assumption out and get the Product Owner’s view on the change appetite
- Demonstrate an understanding of the evolution the service needs to go through so that you can explicitly let the decision be taken on whether the Alpha can make the journey or whether it will be disposed of and re-implemented, this should form part of the teams feedback at the end of Discovery
- An understanding of the Non Functional aspects of the services (volumetrics, security requirements and performance) are likely to be key aspects in this division. If an Alpha will not address these needs, then that should be explicitly clear to the Product Owner to facilitate expectations management with stakeholders
- Some of the challenging aspects of the later term solution (e.g. the identity and access management model or fine-grained authorisation for data access) should be addressed as part of the Alpha rather than leaving all complicated aspects to the Beta phase as this will give the team more insight into their Beta phase planning and the achievability of the overall vision. Teams shouldn’t take on more than one element of expected complexity or they will risk making their Alpha too large.
I hope you find these principles useful – please let me know if you have any others to add.
[English] - [Cymraeg]
Un llygad ar y gorwel - ethos dylunio i micro-wasanaethau isadeiledd cenedlaethol
Mae darpariaeth Agile yn galluogi dylunio a gweithredu iteraidd a datblygol o’r gwasanaethau i gwrdd ag anghenion defnyddwyr – ac mae hyn yn beth da. Serch hynny, mae hyn yn heriol oherwydd gall dyluniadau ganolbwyntio ar y Cynnyrch Hyfyw Lleiaf (MVP) ac felly pan fydd cynhyrchion yn dechrau cael eu graddio neu’n cynnwys cyd-destunau ychwanegol, efallai bydd angen gwneud ail-beiriannu neu ail-weithredu sylweddol ar y system i fynd i’r afael â’r heriau hyn.
Pan fo angen cyflawni trawsnewid heriol neu drawsnewid o lawer o bethau, mae capasiti cyfyngedig o fewn yr arian a ddyrannwyd i alluogi ailddatblygu cynnyrch a ddarparwyd eisoes, ac mae cynlluniau yn aml yn cymryd yn ganiataol bydd cynhyrchion yn 'iawn y tro cyntaf' gydag ymdrech parhaus wedi’i gyfyngu i welliannau/newidiadau o ganlyniad adborth gan ddefnyddwyr ac nid unrhyw ailstrwythuro sylweddol.
Er mwyn gwrthbwyso hyn, rwyf wedi rhestru rhai o'r egwyddorion y dylid eu hystyried fel bod unrhyw gyfyngiadau cynnyrch posib yn cael ei deall yn iawn ac yn cael eu cytuno gan y Perchennog Cynnyrch.
- Peidiwch â dylunio ar gyfer targed/fersiwn terfynol oherwydd byddwch yn peiriannu gormod ar gyfer y cylchoedd bywyd cynnar – roedd hyn yn ddull traddodiadol mewn prosiectau cynllun rhaeadru, sef nid oedd cynnyrch yn cael ei ryddhau nes ei fod “wedi gorffen” yn gyfan gwbl
- Os ydych yn dylunio ar gyfer eich cynnyrch presennol/MVP mae risg byddwch yn gorfod cael gwared â llawer o'ch gwaith, a pur anaml bydd defnyddwyr busnes yn disgwyl hynny, felly ni ellir rhagdybio bod hyn yn rhan o'u disgwyliadau. Cyfarch y rhagdybiaeth honno a chael barn y Perchennog Cynnyrch am y newid
- Dangos dealltwriaeth o’r esblygiad rhaid i’r gwasanaeth ei brofi er mwyn i chi wneud y penderfyniad p’un a fyddai’r Alpha yn gallu parhau neu p'un a fyddai’n cael ei waredu a’i ailweithredu, dylai hyn ffurfio rhan o adborth y timau ar ddiwedd y cam Discovery
- Mae dealltwriaeth o agweddau anymarferol y gwasanaethau (niferoedd, gofynion diogelwch a pherfformiad) yn debygol o fod yn agweddau allweddol yn yr adran hon. Os na fydd Alpha yn mynd i’r afael â’r anghenion hyn, yna dylai hyn fod yn glir i'r Perchennog Cynnyrch er mwyn hwyluso rheoli disgwyliadau'r rhanddeiliaid
- Dylid mynd i'r afael â rhai agweddau heriol y datrysiad hir dymor (e.e. y model hunaniaeth a rheoli mynediad neu awdurdodi manwl ar gyfer mynediad i ddata) fel rhan o'r Alpha yn hytrach na gadael yr holl agweddau cymhleth i'r cam Beta, oherwydd bydd yn rhoi rhagor o fewnwelediad i'r tîm o ran cynllunio ar gyfer y cam Beta a’r tebygolrwydd o gyflawni’r weledigaeth gyffredinol. Ni ddylai’r timau fod yn gyfrifol am fwy nag un elfen o'r cymhlethdod a ddisgwylir, neu mae perygl o wneud yr Alpha'n rhy fawr.
Rwy’n gobeithio bod yr egwyddorion hyn yn ddefnyddiol - gadewch i mi wybod os hoffwch ychwanegu unrhyw rai eraill.
