Obsah:
Byť agilným vývojovým tímom softvéru pre rôznych ľudí znamená určite rôzne veci. Existujú stupne adopcie vo veľmi širokom spektre, pričom je zjavne veľmi málo organizácií, ktoré si myslia, že to robia dobre. Podľa prieskumu State of Agile Survey (zverejneného v apríli 2017), 80% ich respondentov tvrdí, že „sú na alebo stále pod úrovňou dozrievania“. Vývojové tímy bohužiaľ často nevynakladajú veľké úsilie na časť iterácie „učenia sa“. Chceme sa poponáhľať a mať za sebou obrady Scrumu, aby sme sa mohli vrátiť k písaniu kódu. Napokon je tu ešte veľa práce! Je však skutočne problém nedostatočný čas na programovanie?
Pre mnohých z nás by hasenie požiaru mohlo byť konkrétne uvedené v popise práce. Každý deň chodíme do práce s vedomím, že musíme byť pripravení na okamžité skĺznutie zo stĺpu, chytiť čiapky a skočiť na nákladné auto. Prijímame to tak, ako to je, a predpokladáme, že s tým nemôžeme nič urobiť. Čo však v prípade, že hlavnou príčinou našich bojov je vážny nedostatok efektívnosti? Každý vie, aké dôležité je robiť to lepšie ako táto iná spoločnosť. Zdá sa, že sa tam nedostaneme - zdá sa, že nemáme šírku pásma. Manažéri pridávajú viac ľudí, zväčšujú veľkosť ich organizácií a stále majú rovnaké boje. Zdá sa, že sa z toho nedostanete, pretože vaše tímy nevyvíjajú softvér efektívne (a nie ste sami).
Zásady efektívneho rozvoja
Pixabay
Čo teda spôsobuje, že sme neefektívni? Pre väčšinu z nás ako prvá príde na myseľ nedostatok automatizácie (automatizované zostavenia, nasadenia, testovanie). "Keď budeme mať dostatok automatizácie, život sa zlepší." To je bohužiaľ iba časť riešenia. Zvážte vplyv prepracovania na váš projekt. Najefektívnejším spôsobom, ako zostaviť funkciu, je zostaviť ju raz správne a už sa jej nikdy nevrátiť a nedotknúť sa jej. Chyby, refaktoring a ďalšie podobné činnosti v podstate znovuotvárajú pacienta po jeho opustení operačnej sály a je s tým spojené aj inherentné riziko. Nemôžeme odstrániť prepracovanie, ale určite by sme sa mali usilovať o jeho minimalizáciu.
"Ale neobjavuje agilné prepracovanie (napr. Refaktorovanie)?" Funguje to určitým spôsobom, pretože tvorcovia agility pochopili, že dvoma kľúčovými príčinami prepracovania sú nepredvídané okolnosti a meniace sa obchodné požiadavky. Ukazuje sa, že ľudia sú hrozní pri predpovedaní budúcnosti. Agilní tvorcovia tiež pochopili, že veľkým prispievateľom k neefektívnosti je to, čo vývojári nazývajú „pozlátenie“ - zabalenie do funkčnosti, o ktorej si myslíme, že ju niekto použije, aj keď koncoví používatelia o ňu nikdy nepožiadali. Je to ako bravčové mäso pre váš softvérový produkt - úplná strata času. „Nestavajte vesmírnu stanicu, keď všetko, čo požadujú, je Volvo.“ Spoločnosti teda múdro začali vynechávať bravčové mäso a namiesto toho prijali refaktoring, pričom funkčnosť pridali iba v prípade, že je to jednoznačne potrebné. Životná nepredvídateľnosť však nie je jediným hnacím motorom prepracovania, však?
Zmeškané podrobnosti v ktorejkoľvek fáze vývoja funkcií nakoniec stratia čas a peniaze. Efektívna spolupráca vopred vám časom ušetrí kopu prepracovania (riešenie nesplnených požiadaviek, krátkozraký dizajn atď.). Každý z nás má mŕtve uhly a všetci potrebujeme oči navyše. Mnoho vývojových tímov to pri kontrole kódu využíva na konci, ale oveľa menej energie venujú včasnej spolupráci, keď sa dajú problémy vyriešiť lacno a po minimálnych investíciách.
Koľkokrát ste implementovali funkciu a našli ste na konci významné chyby, ktorých sa mali chytiť počas diskusií o požiadavkách / dizajne? Je to ako vyskúšať si jazdu z Atlanty do Montgomery a uvedomiť si niekoľko hodín cesty, že ste namiesto toho omylom odišli do Birminghamu. Koľko času ste strávili pokusom o správne nastavenie kódu, aby ste neskôr pacienta znova otvorili, pretože sa minuli významné požiadavky? Absolútne využitie kolektívnej inteligencie by ušetrilo čas a peniaze, ale vývojári namiesto toho často pracujú na funkciách izolovane.
Tradičné rojenie
Pixabay
Tradičné rojenie znamená, že tím spolupracuje na príbehoch s niekoľkými ľuďmi pracujúcimi na malej funkcii súčasne, čím sa skracuje spätná väzba a skracuje sa čas potrebný na dokončenie tejto funkcie (tj. Rozdeľuj a panuj). To je v podstate rojenie v rámci každej disciplíny (vývojári backendu, vývojári používateľského rozhrania atď.). Pred začiatkom vývoja pracujú vývojári používateľského rozhrania na identifikácii nezávislých úloh, ktoré je možné vykonávať súčasne. Diskutujú o bodoch rozhrania, aby každý človek vedel, ako jeho dielo zapadá do celku. Členovia tímu potom môžu pokračovať v dokončení svojich pridelených úloh a na konci počas integrácie všetko spojiť. Časté kontroly a pravidelné kontroly kódu pomáhajú zaistiť, aby všetko zostalo na koľajisku. Tento prístup si vyžaduje spoluprácu medzi vývojármi,ktorý aj tak pomáha dosiahnuť lepší konečný výsledok. Často dávame prednosť času venovanému písaniu kódu (ľubovoľnému kódu) pred časom venovaným tomu, aby sme nenapísali nesprávny kód. Keď vezmete do úvahy potenciálne ušetrený čas, hodnota bude zrejmá.
Odblokovanie
Pixabay
Ďalším cenným prístupom k rojeniu je zameranie tímu na skoré znižovanie závislosti s cieľom uľahčiť súbežný rozvoj naprieč disciplínami. Zvážte postup prirodzeného vývoja funkcie používateľského rozhrania. Automatizační testeri (SDET) sú závislí od fungujúceho používateľského rozhrania, proti ktorému sú testovaní, vývojári používateľského rozhrania sú závislí od fungujúceho rozhrania API back-endu a vývojári back-endu závisia od konfigurácie, aktualizácií databázy a automatických zostavení / nasadení. Takže vývojári používateľského rozhrania nemusia začať pracovať, kým nebudú hotové API a SDET nemusia začať svoju prácu, kým nebude funkcia dokončená. Každá disciplína pracuje izolovane, čo bráni spolupráci, pretože ľudia, s ktorými potrebujete komunikovať, sú zaneprázdnení prácou na iných veciach.Čo by sa však stalo, keby ste mohli závislosti zmierniť skôr a umožniť všetkým disciplínam pracovať súčasne na rovnakej funkcii?
Tu je niekoľko príkladov:
1. Nasadené funkčné používateľské rozhranie so stubmi
S cieľom odblokovať SDET môžu vývojári používateľského rozhrania poskytnúť fungujúce používateľské rozhranie, ktoré funguje natoľko, že im umožní písať testy. Integrácia backendového rozhrania API a štýly CSS môžu stále čakať, pretože automatizované testovacie rámce ako Selenium sa nestarajú, ak tieto veci nebudú dokončené. Môže to byť všetko dym a zrkadlá. Aj keď sa môžu vyskytnúť zmeny, ktoré spôsobia určité prepracovanie, prínos pre včasné začatie testov prevažuje nad týmto rizikom.
2. Nasadené rozhrania backend API (zablokované, pevne zakódované údaje)
Poskytovanie backendových rozhraní API, proti ktorým môžu vývojári používateľského rozhrania testovať, umožňuje včasné odhalenie problémov s integráciou medzi klientskym rozhraním a rozhraním API. Niekedy zistíte, že poskytnuté API nezodpovedá potrebám frontendových vývojárov. Môžu chýbať celé hovory, podpis môže byť nesprávny alebo môžu mať problémy so štruktúrou údajov. Ak dôjde k odpojeniu, mohli by ste sa o ňom dozvedieť skôr, ako sa čokoľvek zatvrdne.
3. Vytvorte verziu nových aplikácií a služieb HelloWorld.
Ak je potrebná nová služba (napr. Mikroslužba), vytvorte repo a vytvorte verziu služby „ahoj svet“. To umožňuje vývojárom spustiť zdroje na úlohách Jenkins a skriptoch nasadenia skôr, ako je služba skutočne vyvinutá.
Tieto optimalizácie uľahčujú slučku skorej spätnej väzby, kde niekto môže povedať „Potrebujem niečo iné“ pred dokončením vývoja komponentu, ktorý vyžaduje zmenu.
Zabaliť to
Je neuveriteľne dôležité, aby sme prišli na to, ako skrátiť čas uvedenia funkcií, na ktorých pracujeme, na trh. Podnik nemá žiadnu hodnotu z toho, že má veľa funkcií, ktoré práve prebiehajú, a vývojári zúfalo potrebujú rýchle implementovanie funkcií, aby bolo možné chyby vyriešiť čo najbližšie k bodu vstrekovania. Vývojári tiež nevyhnutne potrebujú vzájomnú komunikáciu, aj keď všetko, čo skutočne chcú, je písanie kódu. Je to lepšie pre všetkých zúčastnených vrátane koncového používateľa, ktorý chce iba lepší produkt. Ak im ho nedáte, pôjdu ho hľadať niekde inde.
Rojenie je mimoriadne cenným nástrojom v súbore nástrojov vašej organizácie, ak si ľudia nájdu čas a naučia sa, ako na to. Nie je to rámec alebo dokonca činnosť - je to myslenie. Pre každý príbeh používateľa si členovia tímu kladú dve otázky:
- Ako organizujeme úlohy pre tento príbeh, aby sme prispeli niekoľkými ľuďmi naraz?
- Aké minimum musím urobiť, aby som odblokoval niekoho, kto na mňa čaká?
Čo keby váš tím rýchlo vytvoril funkcie spoločne, a nie aby pomaly vytváral skupinu funkcií nezávisle? Mohli skutočne reagovať na meniace sa obchodné požiadavky a uspokojiť potreby podniku, keď ich potrebuje na splnenie. Konkurenti by sa vás báli - zákazníci by vás milovali. To je recept na úspešné podnikanie.
© 2017 Mike Shoemake