Преглед садржаја:
Бити окретан тим за развој софтвера за различите људе сигурно значи различите ствари. Постоје степени усвојености у врло широком спектру, са очигледно врло мало организација које мисле да то добро раде. Према истраживању стања агилности компаније ВерсионОне (објављеном у априлу 2017. године), 80% њихових испитаника каже да су „на или испод нивоа који још увек сазрева“. На несрећу, развојни тимови често не улажу много труда у „научени“ део итерације. Желимо да пожуримо и завршимо Сцрум церемоније како бисмо се могли вратити писању кода. Напокон, толико је посла! Али да ли је недовољно време за кодирање заиста проблем?
За многе од нас, ватрогаство би могло бити посебно наведено у нашем опису посла. Свакодневно одлазимо на посао знајући да морамо бити спремни на тренутак да се спустимо низ стуб, узмемо шешире и скочимо на камион. Прихватамо то онако како ствари стоје и претпостављамо да ту не можемо ништа учинити. Али, шта ако је основни узрок наших борби озбиљан недостатак ефикасности? Сви знају колико је важно то учинити боље од оне друге компаније тамо. Једноставно не можемо да стигнемо тамо - изгледа да немамо пропусни опсег. Менаџери додају још људи и увећавају величину својих организација и још увек имају исте борбе. Изгледа да не можете прећи преко грбаче јер ваши тимови не развијају софтвер ефикасно (и нисте сами).
Принципи у ефикасном развоју
Пикабаи
Па шта узрокује да будемо неефикасни? Већини нас прво падне на памет недостатак аутоматизације (аутоматизоване израде, примене, тестирање). „Једном када имамо довољно аутоматизације, живот ће постати бољи.“ Нажалост, то је само део решења. Размотрите ефекат прераде на вашем пројекту. Најефикаснији начин за изградњу функције је да је једном правилно направите и никад се више не вратите и додирнете је. Грешке, рефакторирање и друге сличне активности у суштини поново отварају пацијента након што је напустио операциону салу и са тим је повезан ризик. Не можемо елиминисати прераду, али свакако треба да се потрудимо да је смањимо.
„Али, зар агилни не прихвата прераду (нпр. Рефакторирање)?“ Заправо је на неки начин, јер су креатори агилног схватили да су два кључна узрока прераде непредвиђене околности и променљиви пословни захтеви. Испоставило се да су људи страшни у предвиђању будућности. Спретни креатори такође су схватили да огроман допринос неефикасности оно што програмери називају „позлаћивањем“ - упаковањем функционалности за коју мислимо да ће је неко користити, иако је крајњи корисници заправо нису тражили. То је попут свињског меса за ваш софтверски производ - потпуно губљење времена. „Не правите свемирску станицу када је све што траже Волво.“ Дакле, компаније су паметно почеле да изостављају свињетину и прихватају рефакторирање, додајући функционалност само када постоји јасна потреба. Али непредвидивост живота није једини покретач прераде, зар не?
Пропуштени детаљи у било којој фази развоја карактеристика на крају ће изгубити време и новац. Учинковита ефикасна сарадња с временом ће вам уштедети тону прераде (бављење пропуштеним захтевима, кратковидни дизајн, итд.). Сви имамо слепе тачке и свима нам требају додатни сетови очију. Многи развојни тимови то прихватају током прегледа кода, али улажу много мање енергије у рану сарадњу када се проблеми могу решити јефтино и након минималних улагања.
Колико пута сте применили неку функцију и при крају пронашли значајне недостатке који су требали бити ухваћени током дискусија о захтевима / дизајну? То је као да покушате да се возите од Атланте до Монтгомерија и схватите неколико сати путовања да сте се уместо тога одвезли до Бирмингхама. Колико времена је потрошено на покушај да се код добије само како би се пацијент касније поново отворио јер су пропуштени значајни захтеви? Употребом колективне интелигенције апсолутно би се уштедело време и новац, али уместо тога, програмери често раде на функцијама изоловано.
Традиционално ројење
Пикабаи
Традиционално ројење значи да тим сарађује на причама са неколико људи који истовремено раде на малој особини, скраћујући петљу повратних информација и смањујући укупно време довршавања функције (тј. Подели и освоји). Ово се у основи роји унутар сваке дисциплине (позадински програмери, програмери корисничког интерфејса, итд.). Пре него што развој почне, програмери корисничког интерфејса раде на идентификовању независних задатака који се могу истовремено обављати. Они разговарају о тачкама интерфејса како би свака особа знала како се његов комад уклапа у целину. Чланови тима могу затим наставити са извршавањем додељених задатака и на крају све повезати током интеграције. Честа обавезивања и периодични прегледи кода помажу у осигурању да све остане на шинама. Овај приступ захтева сарадњу између програмера,што ионако помаже у постизању бољег крајњег резултата. Често дајемо предност времену проведеном на писању кода (било ког кода) у односу на време проведено пазећи да не напишемо погрешан код. Када сматрате да је време потенцијално уштедено, вредност постаје јасна.
Деблокирање
Пикабаи
Још један драгоцен приступ ројењу је усредсређивање тима на рано ублажавање зависности како би се олакшао истовремени развој у свим дисциплинама. Размотрите природни развојни ток функције УИ. Испитивачи аутоматизације (СДЕТ) зависе од радног корисничког интерфејса за тестирање, програмери корисничког интерфејса зависе од радног АПИ-ја позадине, а програмери позадине зависе од конфигурације, ажурирања базе података и аутоматских израда / примена. Дакле, програмери корисничког интерфејса можда неће започети свој рад док АПИ не заврше, а СДЕТ можда неће започети свој рад док функција не буде завршена. Свака дисциплина ради изоловано, што кочи сарадњу, јер су људи са којима требате комуницирати заузети радом на другим стварима.Али шта ако бисте могли раније да умањите зависности и допустите дисциплинама да истовремено раде на истој особини?
Ево неколико примера:
1. Постављено функционално корисничко сучеље са стубовима
Да би деблокирали СДЕТ-ове, програмери корисничког интерфејса могу им дати функционални кориснички интерфејс који ради таман толико да им дозволи да напишу тестове. Интеграција бацкенд АПИ-ја и ЦСС стилови и даље могу бити на чекању, јер аутоматизовани тест оквири попут Селениум-а неће марити ако су те ствари недовршене. Све то могу бити дим и огледала. Иако се могу догодити промене које проузрокују неке прераде, корист од раног започињања тестова је већа од тог ризика.
2. Примењени Бацкенд АПИ-ји (оштећени, кодирани подаци)
Пружање позадинских АПИ-ја на којима програмери корисничког интерфејса могу тестирати омогућава рано откривање проблема интеграције између предњег дела и АПИ-ја. Понекад откријете да обезбеђени АПИ не задовољава потребе почетних програмера. Могли би недостајати читави позиви, потпис могао бити погрешан или би структура података могла имати проблема. Ако дође до прекида везе, можда ћете то сазнати и пре него што се било шта стврдне.
3. Направите ХеллоВорлд верзију нових апликација и услуга.
Ако је потребна нова услуга (нпр. Микросервис), направите репо и направите верзију услуге „здрави свет“. Ово омогућава развојним ресурсима да започну на Јенкинсовим пословима и скриптама за размештање пре него што се услуга заиста развије.
Ове оптимизације омогућавају рану повратну спрегу где неко може рећи „Треба ми нешто другачије“ пре него што се заврши развој компоненте која захтева промену.
Умотавање
Невероватно је важно да смислимо како да скратимо време за тржиште функција које радимо. Посао не добија вредност ако има гомилу функција које су у току, а програмерима су очајнички потребне функције за брзу примену како би се недостаци могли решити што ближе тачки убризгавања. Програмери такође очајнички морају да комуницирају једни с другима, иако све што заиста желе је да напишу код. Боље је за све укључене, укључујући крајњег корисника који само жели бољи производ. Ако им не дате, они ће отићи негде другде да га пронађу.
Ројење је изузетно драгоцен алат у алату ваше организације, ако људи одвоје времена да науче како се то ради. То није оквир или чак активност - то је начин размишљања. За сваку корисничку причу чланови тима постављају себи два питања:
- Како да организујемо задатке за ову причу како бисмо одједном привукли неколико људи?
- Који је минимум који морам да урадим да бих деблокирао некога ко ме чека?
Шта ако ваш тим брзо изгради функције уместо да полако самостално гради гомилу функција? Они би заправо могли одговорити на променљиве пословне захтеве и испунити потребе предузећа када их посао треба испунити. Такмичари би се плашили вас - купци би вас волели. То је рецепт за успешно пословање.
© 2017 Мике Схоемаке