Taula de continguts:
Ser un equip àgil de desenvolupament de programari sens dubte significa coses diferents per a diferents persones. Hi ha graus d’adopció en un espectre molt ampli, amb aparentment molt poques organitzacions que pensin que ho fan bé. Segons l'Enquesta sobre l'estat àgil de VersionOne (publicada l'abril de 2017), el 80% dels enquestats afirma que es troba "o per sota d'un nivell encara madur". Malauradament, els equips de desenvolupament sovint no fan gaire esforç en la part "aprendre" de la iteració. Volem afanyar-nos i acabar les cerimònies Scrum per poder tornar a escriure codi. Al cap i a la fi, hi ha tanta feina per fer! Però, és realment el problema un temps de codificació insuficient?
Per a molts de nosaltres, la lluita contra incendis també podria figurar específicament a la nostra descripció del lloc de treball. Anem a treballar cada dia sabent que hem d’estar preparats per lliscar cap avall en el moment previ, agafar-nos els barrets i saltar al camió. L’acceptem tal com són les coses i suposem que no hi podem fer res. Però, què passa si la causa fonamental de les nostres lluites és una greu manca d’eficiència? Tothom sap la importància de fer-ho millor que l’altra empresa d’allà. Sembla que no podem arribar-hi; sembla que no tenim l’amplada de banda. Els administradors afegeixen més persones i augmenten la mida de les seves organitzacions i continuen tenint les mateixes lluites. Sembla que no es pot superar la gepa perquè els vostres equips no desenvolupen programari de manera eficient (i no esteu sols).
Principis en el desenvolupament eficient
Pixabay
Llavors, què ens fa ser ineficients? Per a la majoria de nosaltres, el primer que ens ve al cap és la manca d’automatització (versions automatitzades, desplegaments, proves). "Un cop tinguem prou automatització, la vida millorarà". Malauradament, això només és una part de la solució. Penseu en l’efecte de la reelaboració en el vostre projecte. La forma més eficient de crear una característica és construir-la una vegada correctament i no tornar-la a tocar mai més. Els errors, la refactorització i altres activitats similars estan essencialment reobrint el pacient després que hagi sortit del quiròfan i hi hagi un risc inherent associat. No podem eliminar la reelaboració, però sens dubte hem d’esforçar-nos per minimitzar-la.
"Però no es fa una reelaboració àgil (per exemple, refactorització)?" En realitat ho fa d’una manera, perquè els creadors d’àgil van entendre que dues causes clau de la reelaboració són circumstàncies imprevistes i canvis en els requisits empresarials. Resulta que els humans són terribles a l’hora de predir el futur. Els creadors àgils també van entendre que el que els desenvolupadors anomenen "revestiment d'or" és un gran factor que contribueix a la ineficiència, ja que pensem que algú utilitzarà la funció, tot i que els usuaris finals mai no la van demanar. És com la carn de porc del vostre producte de programari: una completa pèrdua de temps. "No construïs una estació espacial quan tot el que demanen és un Volvo". Per tant, les empreses van començar amb prudència a deixar de banda el porc i adoptar la refactorització, afegint funcionalitat només quan hi ha una necessitat clara. Però la imprevisibilitat de la vida no és l’únic motor per a la reelaboració, oi?
Els detalls perduts en qualsevol etapa del desenvolupament de les funcions perden el temps i els diners. Col·laborar amb eficàcia per endavant, amb el pas del temps, us estalviarà una gran quantitat de treballs nous (per fer front a requisits perduts, un disseny miop, etc.). Tots tenim punts cecs i tots necessitem jocs d’ulls addicionals. Molts equips de desenvolupament accepten això a la part posterior durant la revisió del codi, però dediquen molta menys energia a col·laborar al principi quan els problemes es poden resoldre de manera barata i després d’una inversió mínima.
Quantes vegades heu implementat una funció i heu trobat defectes significatius a prop del final que haurien d'haver estat detectats durant els debats de requisits / disseny? És com intentar conduir d’Atlanta a Montgomery i adonar-se de diverses hores del viatge que, per contra, va conduir a Birmingham. Quant de temps es va dedicar a intentar obtenir el codi correcte només per obrir el pacient més tard perquè es van perdre els requisits importants? L’aprofitament de la intel·ligència col·lectiva permetria estalviar absolutament temps i diners, però, en canvi, els desenvolupadors solen treballar en funcions aïlladament.
Eixam tradicional
Pixabay
L’eixam tradicional significa que l’equip treballa col·laborativament en històries amb diverses persones que treballen en una petita funció alhora, escurçant el bucle de retroalimentació i reduint el temps total de finalització de la funció (és a dir, divideix i conquereix). Això és essencialment un eixam dins de cada disciplina (desenvolupadors de backend, desenvolupadors d’interfície d’usuari, etc.). Abans que comenci el desenvolupament, els desenvolupadors de la IU treballen per identificar tasques independents que es poden realitzar simultàniament. Discuteixen els punts d'interfície perquè cada persona sàpiga com s'adapta la seva peça al conjunt. Els membres de l'equip poden procedir a la realització de les seves tasques assignades i reunir tot al final durant la integració. Els compromisos freqüents i les revisions periòdiques del codi ajuden a garantir que tot quedi sobre els rails. Aquest enfocament requereix col·laboració entre els desenvolupadors,cosa que ajuda a produir un resultat final millor de totes maneres. Sovint prioritzem el temps dedicat a escriure codi (qualsevol codi) al temps dedicat assegurant-nos que no escrivim el codi equivocat. Quan es considera el temps potencialment estalviat, el valor queda clar.
Desbloqueig
Pixabay
Un altre enfocament valuós per eixamjar és centrar l'equip en els primers temps en la mitigació de la dependència per tal de facilitar el desenvolupament simultani en totes les disciplines. Penseu en el flux de desenvolupament natural d'una característica de la IU. Els verificadors d'automatització (SDET) depenen d'una interfície d'usuari que funcioni, els desenvolupadors de la interfície d'usuari depenen d'una API de backend de treball i els desenvolupadors de backend depenen de la configuració, les actualitzacions de bases de dades i les compilacions / desplegaments automatitzats. Per tant, és possible que els desenvolupadors d’interfícies d’usuari no iniciïn el seu treball fins que no s’acabin les API i que els SDET no iniciïn el seu treball fins que la funció no s’acabi. Cada disciplina funciona de manera aïllada, cosa que dificulta la col·laboració perquè les persones amb les quals necessiteu interactuar estan ocupats en altres coses.Però, i si podríeu mitigar les dependències abans i permetre que totes les disciplines funcionessin simultàniament en la mateixa característica?
Aquests són alguns exemples:
1. Interfície d'usuari funcional desplegada amb talons
Per desbloquejar els SDET, els desenvolupadors de la interfície d’usuari els poden proporcionar una interfície d’usuari que funcioni el suficient per deixar-los escriure proves. La integració de l'API de backend i els estils CSS encara poden estar pendents, ja que els marcs de prova automatitzats com Selenium no es preocuparan si aquestes coses estan inacabades. Tot pot ser fum i miralls. Tot i que es poden produir canvis que provoquin una certa reelaboració, el benefici d’iniciar les proves abans d’hora supera aquest risc.
2. API de backend desplegades (dades codificades de forma dura)
Proporcionar API de backend que els desenvolupadors de la interfície d’usuari poden provar permet detectar ràpidament problemes d’integració entre la interfície i les API. De vegades, veieu que l'API proporcionada no compleix les necessitats dels desenvolupadors front-end. Poden faltar trucades senceres, la signatura pot ser incorrecta o l’estructura de les dades pot tenir problemes. Si hi ha una desconnexió, és possible que ho assabenteu abans d’hora que res s’endureixi.
3. Creeu una versió HelloWorld de noves aplicacions i serveis.
Si es necessita un servei nou (per exemple, un microservei), creeu la reposició i creeu una versió del servei "hola world". Això permet que els recursos de programació s'iniciïn en les feines i els scripts de desplegament de Jenkins abans de desenvolupar el servei.
Aquestes optimitzacions faciliten un bucle de retroalimentació primerenca on algú pot dir "Necessito alguna cosa diferent" abans que es completi el desenvolupament del component que requereix el canvi.
Embolicant-lo
És increïblement important esbrinar com reduir el temps per comercialitzar les funcions en què estem treballant. L’empresa no té cap valor per tenir un munt de funcions en curs i els desenvolupadors necessiten desesperadament funcions per implementar-les ràpidament, de manera que els defectes es puguin resoldre el més a prop possible del punt d’injecció. Els desenvolupadors també necessiten desesperadament interactuar entre ells tot i que tot el que realment volen és escriure codi. És millor per a tots els implicats, inclòs l’usuari final que només vulgui un producte millor. Si no els ho doneu, aniran a un altre lloc per trobar-lo.
L’eixam és una eina extremadament valuosa a la caixa d’eines de la vostra organització, si la gent es pren el temps per aprendre a fer-ho. No és un marc ni tan sols una activitat, sinó una mentalitat. Per a cada història de l'usuari, els membres de l'equip es fan dues preguntes:
- Com organitzem les tasques d’aquesta història per aconseguir que diverses persones col·laborin alhora?
- Quin és el mínim que he de fer per desbloquejar algú que m’espera?
Què passa si el vostre equip va crear funcions juntes en lloc de construir lentament un munt de funcions de forma independent? En realitat, podrien respondre als canvis en els requisits empresarials i satisfer les necessitats de l'empresa quan l'empresa els necessiti satisfer-los. Els competidors us temrien: els clients us estimarien. Aquesta és una recepta per a un negoci amb èxit.
© 2017 Mike Shoemake