¿Qué tan bueno es adop­tar agile en su em­pre­sa?

Pa­ra ha­cer­lo se re­quie­re el apo­yo de la di­rec­ción C-sui­te, los equi­pos em­pre­sa­ria­les y de desa­rro­llo. Aquí hay al­gu­nas co­sas que se de­ben con­si­de­rar al ha­cer la tran­si­ción de la me­to­do­lo­gía cas­ca­da ha­cia la me­to­do­lo­gía agile.

IT Now Guatemala - - DEVOPS -

De acuer­do con el no­veno re­por­te anual del es­ta­do de agile, pu­bli­ca­do el año pa­sa­do por Ve­ri­zo­no­ne (en con­jun­to con los con­sul­to­res in­de­pen­dien­tes de la en­cues­ta, Analy­sis.net) el 94% de las or­ga­ni­za­cio­nes es­tán prac­ti­can­do el desa­rro­llo agile. El re­por­te re­co­lec­tó los da­tos de 3 925 en­cues­ta­dos pa­ra de­ter­mi­nar los desafíos que en­fren­tan las or­ga­ni­za­cio­nes al im­ple­men­tar agile.

“El mo­de­lo de desa­rro­llo en cas­ca­da tam­bién se co­no­ce co­mo el mo­de­lo clá­si­co o tra­di­cio­nal pa­ra el ci­clo de vi­da de desa­rro­llo de sis­te­mas de in­ge­nie­ría de soft­wa­re y desa­rro­llo. Se des­cri­be co­mo un mo­de­lo li­neal y se­cuen­cial que tie­ne ob­je­ti­vos dis­tin­tos pa­ra ca­da fa­se. Cuan­do se pa­sa a la si­guien­te fa­se, no se pue­de vol­ver atrás, al igual que una cas­ca­da que flu­ye so­bre los pa­sos de la la­de­ra de una ro­ca en la mon­ta­ña”, di­jo Joe Mack un consultor de tec­no­lo­gía em­pre­sa­rial Trans­for­ma­ción con Transp­horm. El pro­ce­so en cas­ca­da fun­cio­na me­jor en si­tua­cio­nes don­de las ex­pec­ta­ti­vas son cla­ras y las par­tes in­tere­sa­das y los clien­tes no tie­nen la

ca­pa­ci­dad de cam­biar el al­can­ce del pro­yec­to. Des­afor­tu­na­da­men­te, no hay una gran can­ti­dad de pro­ble­mas de TI del mun­do real que cai­ga en esa ca­te­go­ría.

“Uno de los prin­ci­pa­les be­ne­fi­cios de agile so­bre cas­ca­da, es que se ve un en­tre­ga­ble de for­ma ite­ra­ti­va y el pro­pie­ta­rio del pro­duc­to pue­de de­ci­dir rea­li­zar cam­bios en la car­te­ra de pro­duc­tos”, ex­pli­có Sud­ha­kar Gor­ti, CIO de En­vi­ro­men­tal Da­ta Re­sour­ces.

Con­se­guir agile de la ma­ne­ra co­rrec­ta

An­tes de asu­mir es­ta trans­for­ma­ción, las or­ga­ni­za­cio­nes ne­ce­si­tan sa­ber cuá­les son los pro­ble­mas que es­tán tra­ba­jan­do pa­ra re­sol­ver y co­mo agile pue­de re­sol­ver esos pro­ble­mas. Las em­pre­sas tam­bién de­ben con­tem­plar lo si­guien­te: ¿Qué con­si­de­ra us­ted co­mo un re­sul­ta­do exi­to­so? ¿De qué ma­ne­ra el com­pro­mi­so es su ne­go­cio pa­ra la trans­for­ma­ción? ¿Su cul­tu­ra po­dría apo­yar es­te cam­bio? ¿Ne­ce­si­ta ayu­da ex­ter­na? Agile pue­de ha­cer gran­des co­sas por su or­ga­ni­za­ción. Se pue­de crear un com­pro­mi­so en­tre los equi­pos y los tra­ba­ja­do­res que no co­la­bo­ran con re­gu­la­ri­dad. Se pue­de au­men­tar la ca­li­dad del có­di­go que sus equi­pos crean, se pue­de acor­tar el tiem­po de co­mer­cia­li­za­ción, au­men­tar la sa­tis­fac­ción del clien­te y pue­de re­du­cir los cos­tes de desa­rro­llo, pe­ro só­lo si lo ha­ce bien.

“Si lo ha­ce mal, el desa­rro­llo ágil crea­rá mu­chos más pro­ble­mas de los que re­suel­ve”, di­jo en un co­mu­ni­ca­do Nat­han Wil­son, di­rec­tor de in­ves­ti­ga­ción en Gart­ner.

Pon­ga a to­dos a bor­do

De acuer­do con Gart­ner, la trans­for­ma­ción agile es lo que des­cri­be co­mo una ac­ti­vi­dad de ne­go­cios TI con­jun­ta y re­quie­re que to­dos, des­de el CEO has­ta los desa­rro­lla­do­res en las trin­che­ras se mue­van en la mis­ma di­rec­ción. “Use mé­to­dos de agile co­mo la ca­pa­ci­dad de trans­for­mar las re­la­cio­nes de ne­go­cio de TI y te­ner un im­pac­to po­si­ti­vo en la en­tre­ga de va­lor de TI. Sin em­bar­go, el va­lor se­rá en­tre­ga­do só­lo si el CIO y to­do el equi­po de ad­mi­nis­tra­ción de TI se de­di­can al cam­bio de cul­tu­ra que es ne­ce­sa­ria pa­ra el éxi­to”, di­jo Wil­son.

Mack, es­tá de acuer­do y se­ña­la que es­te es el co­ra­zón de agile.

“El pro­ce­so ite­ra­ti­vo pa­ra to­das las me­to­do­lo­gías ági­les cuen­ta con la par­ti­ci­pa­ción em­pre­sa­rial en to­das las eta­pas de pla­ni­fi­ca­ción e in­clu­so al­gu­na par­ti­ci­pa­ción en fun­ción de las ope­ra­cio­nes del día a día”. La adop­ción ágil exi­to­sa ne­ce­si­ta in­cluir a to­dos en el pro­ce­so des­de el prin­ci­pio. Los equi­pos de ne­go­cios y de desa­rro­llo ne­ce­si­tan tra­ba­jar jun­tos pa­ra de­fi­nir las especificaciones, KPI, pla­zos, pre­su­pues­tos y más.

“Hay que in­vo­lu­crar a los ac­to­res co­mer­cia­les des­de el día uno. Ellos cuen­tan to­da la his­to­ria, don­de us­ted co­mo lí­der de TI tie­ne que aden­trar­se en las lí­neas de la his­to­ria que tie­nen sen­ti­do des­de el pun­to de vis­ta de la apli­ca­ción y la tec­no­lo­gía”, di­jo Mi­chael Spano, un ge­ren­te eje­cu­ti­vo de ser­vi­cios de in­fra­es­truc­tu­ra en IBM.

Desafíos en la tran­si­ción ha­cia agile

Agile pue­de ser di­fí­cil de po­ner en prác­ti­ca, de acuer­do con Gor­ti. “Con­se­guir que to­dos es­tén ali­nea­dos con la for­ma en que el nue­vo pro­ce­so va a tra­ba­jar es un desafío. Ade­más, al­gu­nas per­so­nas tie­nen con­cep­tos erró­neos y fal­ta de com­pren­sión de lo que real­men­te sig­ni­fi­ca agile”. Edu­car su equi­po y li­de­rar­lo en lo que es agile y có­mo pue­de be­ne­fi­ciar a su em­pre­sa es esen­cial pa­ra con­se­guir el ni­vel ma­yor ren­di­mien­to.

El cam­bio cul­tu­ral es otro gran re­to, se­gún Mack, “de­pen­dien­do de cuán­to tiem­po se ha uti­li­za­do la me­to­do­lo­gía cas­ca­da, a ve­ces es más di­fí­cil cam­biar la cul­tu­ra de la or­ga­ni­za­ción de desa­rro­llo”.

De­rek Plun­kett, vi­ce­pre­si­den­te ad­jun­to de desa­rro­llo de apli­ca­cio­nes IS con John Han­cock Re­ti­re­ment Plan Ser­vi­ces, es­tá de acuer­do.

“Uno de los ma­yo­res re­tos es ali­near la men­ta­li­dad y el com­por­ta­mien­to del equi­po ha­cia los re­sul­ta­dos del equi­po en lu­gar del desem­pe­ño

“Uno de los prin­ci­pa­les be­ne­fi­cios de agile so­bre cas­ca­da, es que se ve un en­tre­ga­ble de for­ma ite­ra­ti­va y el pro­pie­ta­rio del pro­duc­to pue­de de­ci­dir rea­li­zar cam­bios en la car­te­ra de pro­duc­tos”.

Sud­ha­kar Gor­ti, En­vi­ro­men­tal Da­ta Re­sour­ces.

in­di­vi­dual”, di­jo. Un con­se­jo que ofre­ce a los lí­de­res de TI, es la ali­nea­ción de ob­je­ti­vos y re­com­pen­sas mo­ne­ta­rias pa­ra los miem­bros de los equi­pos ági­les pa­ra ayu­dar a re­for­zar es­te com­por­ta­mien­to. El re­torno de la in­ver­sión pue­de ser di­fí­cil de con­cre­tar. Mack in­di­có que agile, pue­de ser una ta­rea an­ti­ci­pa­da en tér­mi­nos de cos­to. A ve­ces, el li­de­raz­go de las em­pre­sas se im­pa­cien­ta en la can­ti­dad de tiem­po que se tar­da en ob­te­ner un re­torno de su in­ver­sión, el en­vío de tra­ba­ja­do­res a la cla­se, el pa­go de los exá­me­nes de cer­ti­fi­ca­ción y los ho­no­ra­rios de con­sul­to­ría.

Cam­bio del al­can­ce

“La se­gun­da ra­zón por la que los pro­yec­tos agile fra­ca­san se de­be a la co­rrup­ción del al­can­ce, lo que pue­de ocu­rrir in­clu­so si se in­vo­lu­cra a tan­tas par­tes in­tere­sa­das co­mo sea po­si­ble des­de el prin­ci­pio. Los nue­vos da­tos se vuel­ven dis­po­ni­bles y sim­ple­men­te de­ben ser in­clui­dos.

“Es más co­mún pa­ra el al­can­ce am­pliar du­ran­te la fa­se de re­qui­si­tos co­mo nue­vos re­qui­si­tos a me­nos que el equi­po es­té muy dis­ci­pli­na­do. Es­to en­ton­ces alar­ga la lí­nea de tiem­po y con­du­ce a la fal­ta de pre­su­pues­to ori­gi­nal. Us­ted pue­de ver pro­yec­tos mo­rir o de­jar­se de la­do en es­ta fa­se ya sea por­que se han vuel­to de­ma­sia­do cos­to­sos o por­que las prio­ri­da­des del ne­go­cio han cam­bia­do des­de el ini­cio del pro­yec­to”, di­jo Plun­kett.

De acuer­do con Mack, es po­si­ble rea­li­zar cam­bios en los re­qui­si­tos, otro que inac­ti­var el cam­bio del pro­ce­so de con­trol, lo que lle­va a ca­da vez más a ex­ce­sos en la lí­nea de tiem­po y de cos­tos.

¿De­be­ría re­cu­rrir a con­sul­to­res ter­ce­ros de agile?

Si us­ted es­tá co­men­zan­do des­de el cua­dro uno, en­ton­ces tie­ne más sen­ti­do traer a al­guien pa­ra edu­car a sus equi­pos. Es­ta ex­pe­rien­cia del mun­do real, ex­pre­só Mack, es de su­ma im­por­tan­cia pa­ra el éxi­to tem­prano con agile. “Des­afor­tu­na­da­men­te, en­viar un re­cur­so in­terno de en­tre­na­mien­to pa­ra la for­ma­ción en có­mo ser un en­tre­na­dor agile, no pro­por­cio­na­rá nin­gu­na ex­pe­rien­cia del mun­do real de tra­ba­jo, y con, va­rias tien­das de desa­rro­llo agile que son tan cru­cia­les pa­ra su éxi­to. Por lo tan­to, traer ayu­da ex­ter­na es más ries­go­so, pe­ro es ca­si se­gu­ro de que tam­bién pue­de va­ler la pe­na”, di­jo.

Lle­var el en­tre­na­dor agile “co­rrec­to” es tan im­por­tan­te, de acuer­do con Gor­ti.

“Traer un nue­vo ta­len­to que ha te­ni­do ex­pe­rien­cia agile y es­tar se­gu­ros de que es­te nue­vo ta­len­to pue­de ac­tuar co­mo un mo­de­lo a se­guir pa­ra to­dos los em­plea­dos ac­tua­les”, di­jo.

Es­te es tam­bién el tiem­po pa­ra iden­ti­fi­car las per­so­nas de su equi­po que crees que va a ser el ma­yor im­pac­to en la tran­si­ción. Ade­más, la iden­ti­fi­ca­ción de los agen­tes de cam­bio den­tro de un equi­po y lo­grar que se ali­nean me­dian­te la par­ti­ci­pa­ción en el pro­ce­so de tran­si­ción pue­de ace­le­rar sig­ni­fi­ca­ti­va­men­te la adop­ción. Em­pie­za pe­que­ño De acuer­do con Plun­kett, se pue­de evi­tar el cho­que de pa­sar por es­ta trans­for­ma­ción. Pa­ra él se de­be ini­ciar la trans­for­ma­ción agile con un pe­que­ño nú­me­ro de equi­pos pi­lo­to. Una vez que la for­ma­ción y las he­rra­mien­tas es­tán son las apro­pia­das y el im­pac­to cul­tu­ral se con­ta­bi­li­zan, los equi­pos adi­cio­na­les pue­den pa­sar por la tran­si­ción. Es­te ti­po de en­fo­que tien­de a li­mi­tar el ries­go de em­pu­jar to­do el ne­go­cio de ha­cer la tran­si­ción a la vez y per­mi­te que los lí­de­res eva­luen y abor­den los obs­tácu­los a los que es­tán ex­pues­tos du­ran­te es­te pe­rio­do pi­lo­to cui­da­do­sa­men­te.

Use lo que fun­cio­na pa­ra su or­ga­ni­za­ción

Agile no va a re­sol­ver to­dos sus pro­ble­mas. De acuer­do con Gart­ner, las di­fe­ren­tes cla­ses de pro­ble­mas de desa­rro­llo re­que­ri­rán di­fe­ren­tes en­fo­ques. Si bien pue­de pa­re­cer que el mun­do se ha in­cli­na­do por la me­to­do­lo­gía agile, los ex­per­tos ven que wa­ter­fall, hy­brids y otras me­to­do­lo­gías siem­pre ten­drán un lu­gar en el mun­do mo­derno de desa­rro­llo.

“Los pro­yec­tos de cas­ca­da tie­nen su lu­gar cuan­do los re­qui­si­tos son cla­ros y fi­jos y el tiem­po no es un fac­tor crí­ti­co, y al mis­mo tiem­po agile tra­ba­ja­rá tam­bién los be­ne­fi­cios que son más sig­ni­fi­ca­ti­vos cuan­do esas co­sas no son cier­tas. Es­te es el mun­do en que vi­vo”, fi­na­li­zó Spano.

Newspapers in Spanish

Newspapers from Guatemala

© PressReader. All rights reserved.