Kā veikls IT var pārveidot IT nozari?

Saturs

• Kāpēc veikls IT?
• Kā veikla metodika risina ūdenskrituma modeļa problēmas?
• Kā Agile ir ietekmējusi IT nozari?
• Bez kļūdām, bez stresa - jūsu soli pa solim, kā izveidot programmatūru, kas maina dzīvi, neiznīcinot savu dzīvi
• Iemesli, kādēļ BT pārgāja uz veiklu praksi
• Slikta prasību pārvaldība
  
• Slikta programmatūras izstrāde
• Attīstības ierobežojumi
• Ko BT darīja, lai risinātu iepriekšminētās problēmas?
• Secinājums

Avots: Darkovujic / Dreamstime.com

Izņemšana:

Daudziem programmatūras izstrādes ūdenskrituma modelis ir bijis standarts gadu desmitiem ilgi, taču tagad tas tiek aizstāts ar daudz elastīgāku Agile metodiku.

Agile metodika programmatūras izstrādei var pozitīvi ietekmēt IT nozari. Agile metodoloģijas ieviešanas rezultātus var izmērīt vairākos veidos. Ātrāks programmatūras maiņas pieprasījums, mazāk kļūdu, komandas darbības kvantitatīvs novērtējums un vājās vietas ir visas veiksmīgās Agile ieviešanas atspoguļojums. Lai veiksmīgi novērtētu veiklības ietekmi, organizācijai jāsalīdzina dažādi rādītāji, kas saistīti ar attīstību pirms agilitātes un pēc tās. Agile reālo ietekmi nevar izmērīt tikai ar ieņēmumu pieaugumu vai ar palielinātu kļūdu skaitu. Lai saprastu reālo ietekmi, jāapsver vairāki iekšējie parametri. (Lai iegūtu vairāk par veiklīgu attīstību, skatiet sadaļu Agile programmatūras izstrāde 101.)

Kāpēc veikls IT?

IT nozare ir pievērsusies elastīgai praksei galvenokārt programmatūras izstrādes ūdenskrituma modeļa ierobežojumu dēļ. Parasti ir novērots, ka IT uzņēmumi nespēj reaģēt uz mainīgajām klientu prasībām vai tirgus situācijām vai samazināt izmaksas, izmantojot programmatūras izstrādes ūdenskrituma modeli. Pat ja mēs līdzsvarojam šo milzīgo noslieci uz Agile metodoloģiju un uzskatām, ka daži no uztraukumiem ir vienkārši hipe, ir daudz empīrisku atgriezeniskās saites pret ūdenskrituma modeli.

Vienkārši sakot, ūdenskrituma modelis ir programmatūras izstrādes modelis, kurā darbs tiek veikts secīgi - vienu posmu pēc otra. Šim modelim ir piecas fāzes: prasības, projektēšana, ieviešana, pārbaude un uzturēšana. Parasti pēc vienas fāzes pabeigšanas ir grūti, ja pat neiespējami veikt izmaiņas iepriekšējā fāzē. Tātad, tiek pieņemts, ka prasības ir diezgan daudz noteiktas. Galvenā atšķirība no Agile modeļa ir pieņēmums, ka prasības netiks mainītas. Veikls pieņem, ka mainīsies biznesa situācijas un mainīsies arī prasības. Tātad programmatūra tiek piegādāta mazākos gabalos pa ss, turpretī ūdenskrituma modelī pirmā piegāde vai izlaišana tiek veikta pēc ilga laika. (Lai iegūtu vairāk par attīstību, skatiet sadaļu Kā Apache Spark palīdz ātrai lietojumprogrammu izstrādei.)

Visievērojamākā kritika attiecībā uz ūdenskrituma modeli ir tā pieņēmums, ka prasības netiks mainītas. Pats pieņēmums ir kļūdains un nereāls. Piemēram, 2001. gadā pētījums par 1027 IT projektiem Apvienotajā Karalistē parādīja, ka šis pieņēmums bija vienīgais lielākais IT projektu izgāšanās iemesls.

Citā piemērā Kreigs Larmans, grāmatas “Agile and Iterative Development: a Manager's Guide” autors, ir norādījis, kā daudziem projektiem, kurus ASV Aizsardzības departaments (DoD) ir izpildījis, izmantojot ūdenskrituma modeli, nav izdevies sasniegt savus mērķus. Astoņdesmitajos un deviņdesmitajos gados DoD prasīja programmatūras izstrādes projektos izmantot ūdenskrituma modeli atbilstoši standartiem, kas publicēti DoD STD 2167. Šokējošā statistika atklāja, ka 75% no šiem programmatūras projektiem nekad netika izmantoti. Pēc šī ziņojuma tika izveidota darba grupa Dr Frederick Brooks, labi pazīstams programmatūras inženierijas eksperts. Darba grupa nāca klajā ar ziņojumu, kurā komentēja: “DoD STD 2167 tāpat ir nepieciešams radikāls kapitālais remonts, lai atspoguļotu mūsdienu labāko praksi. Evolūcijas attīstība vislabāk ir tehniski, tā ietaupa laiku un naudu. ”

Šādi četri ūdenskrituma modeļa pieņēmumi nebija izdevušies reālās pasaules scenārijos:

• Norādītās prasības ir samērā labi definētas, tāpēc tās būtiski nemainīsies.
• Pat ja prasības mainīsies izstrādes posmā, tās būs pietiekami mazas, lai ietilptu izstrādes ciklā.
• Sistēmas integrācija, kas notiek pēc programmatūras piegādes, notiks pēc plāna.
• Programmatūras jauninājumi un inovācijai vajadzīgās pūles notiks saskaņā ar plānotu un paredzamu grafiku.

Kā veikla metodika risina ūdenskrituma modeļa problēmas?

Agile metodika būtiski atšķiras no ūdenskrituma modeļa, un tas ir skaidrs no tā pieņēmumiem:

• Neviens, pat ne klients, nevar pilnībā zināt vai saprast prasības. Nav garantijas, ka prasības nemainīsies.
• Iespējams, ka prasību izmaiņas nav mazas un pārvaldāmas. Faktiski tie būs dažāda lieluma un turpināsies. Tātad, programmatūra tiks piegādāta nelielās daļās, lai sekotu līdzi izmaiņām.

Kā Agile ir ietekmējusi IT nozari?

Agile tiek ieviests daudzās vietās, savukārt daudzi uzņēmumi plāno ieviest Agile. Lai arī Agile noteikti ir veikusi būtiskas izmaiņas IT nozarē, faktus un skaitļus joprojām ir nedaudz grūti iegūt. Bet Agile ietekmi var saprast, izmantojot tālāk aprakstīto British Telecom (BT) gadījuma pētījumu.

Bez kļūdām, bez stresa - jūsu soli pa solim, kā izveidot programmatūru, kas maina dzīvi, neiznīcinot savu dzīvi

Jūs nevarat uzlabot savas programmēšanas prasmes, kad nevienam nerūp programmatūras kvalitāte.

Iemesli, kādēļ BT pārgāja uz veiklu praksi

BT sāka piedzīvot vairākas problēmas ar programmatūras izstrādes praksi 2004. gadā. BT izstrādāja vairākus programmatūras projektus, gan vienkāršus, gan sarežģītus. Daudzi programmatūras projekti nespēja izstrādāt kvalitatīvu iznākumu noteiktajā termiņā. BT atklāja, ka problēmu cēlonis ir ūdenskrituma modelis. Tātad ūdenskrituma modeļa pastiprināšana nepalīdzēja. Galvenie problēmu cēloņi ir norādīti zemāk:

Slikta prasību pārvaldība

• Tika izvirzīts pārāk daudz prasību, lai izpildītu pārāk ierobežotā laikā.
• Daudzas prasības nebija nozīmīgas biznesa vajadzībām.
• Gandrīz visām, ja ne visām prasībām tika piešķirts augstas prioritātes statuss.
• Prasības atspoguļoja pašreizējās biznesa vajadzības, neņemot vērā nākotnes scenārijus. Tas atstāja atvērtu iespēju turpmākām programmatūras izmaiņām.

Slikta programmatūras izstrāde

• Ņemot vērā milzīgo prasību skaitu, dizaineri tērēja pārāk daudz laika, vienkārši cenšoties izdomāt, ko šīs prasības nozīmē. Faktiskajam dizainam bija atlicis maz laika.
• Prasību analītiķi pārcēlās uz citiem uzdevumiem, ņemot nerakstītas, klusējot izteiktas zināšanas.
• Iepriekš minēto divu faktoru dēļ dizains bija slikts. Dizaineriem joprojām bija jāpiegādājas saskaņā ar sākotnējo laika grafiku.

Attīstības ierobežojumi

Kodēšana bija pārsteidzīga un sliktas kvalitātes kļūdainas programmatūras dizaina dēļ. Izstrādātāji sapratīs, ka slikta programmatūras izstrāde radīs sliktu kodu, bet tomēr tas bija jāiegūst līdz noteiktajam termiņam. Integrācijas laikā tiks ziņots par daudz kļūdu, jo vienības testi un regresijas testi netika veikti.

Līdz programmatūras ieviešanai klients atzīmē, ka prasības jau ir mainījušās, tāpat kā biznesa scenārijs. Programmatūrai ir arī daudz problēmu. Faktiski visi programmatūras izstrādes centieni tagad tiek uzskatīti par nelietderīgiem.

Ko BT darīja, lai risinātu iepriekšminētās problēmas?

BT saprata, ka ūdenskrituma modeļa pastiprināšana nav atbilde uz problēmām. Tam bija vajadzīga jauna pieeja. Tātad, tas nolēma īstenot veiklo pieeju. Saskaņā ar jauno pieeju tika nolemtas šādas lietas:

• 12 mēnešu attīstības cikla vietā BT tagad 90 dienu ciklā piegādātu funkcionējošus programmatūras komponentus. Ideja bija koncentrēties uz vienu vai divām biznesa problēmām un mērķēt 90 dienu laikā piegādāt programmatūras risinājumu. Šī cikla sākumu iezīmēja intensīvas diskusijas starp dažādām ieinteresētajām personām, lai prasības būtu skaidri noteiktas, analizētas un sakārtotas pēc prioritātēm.
• Mērķis bija sniegt skaidras un taustāmas biznesa vērtības. Uz iekšējo klientu tika izdarīts spiediens sniegt skaidras prasības. Tātad neskaidru mērķu vietā lietotāju stāsti tika doti ar skaidriem pieņemšanas kritērijiem.
• Piegādātā programmatūra tiks pilnībā pārbaudīta un dokumentēta. Programmatūra bieži apmeklēs integrācijas testus, lai jau iepriekš identificētu problēmas.

Izmantojot veiklo pieeju, BT varētu vieglāk pielāgoties mainīgajām prasībām vai biznesa situācijām. Uzlabojās koda kvalitāte un tika novērstas pēdējā brīža pamata kļūdas.

Secinājums

Veikls, ņemot vērā visas tā priekšrocības un hype ap to, joprojām atrodas posmā, kurā tā potenciāls nav pilnībā izmantots. Tas notiek tāpēc, ka daudzas organizācijas pielāgo pieeju tā, lai mainītu tās sākotnējos principus. Tā rezultātā ūdenskrituma modelis dažos gadījumos rada atgriešanos. Kamēr pielāgošana turpināsies, ir svarīgi saglabāt Agiles pamatprincipus. Daudzas organizācijas apgalvo, ka ir pilnībā veiklas, taču tām vēl ir jānoiet tā, lai kļūtu par patiesi veiklu uzņēmumu.