Съдържание:
Да бъдеш пъргав екип за разработка на софтуер със сигурност означава различни неща за различните хора. Има степени на осиновяване в много широк спектър, като очевидно много малко организации смятат, че го правят добре. Според проучването на състоянието на пъргавината на VersionOne (публикувано през април 2017 г.), 80% от анкетираните казват, че са „на или под все още узряващо ниво“. За съжаление, екипите за разработка често не полагат много усилия в частта за учене на итерацията. Искаме да побързаме и да приключим Scrum церемониите, за да можем да се върнем към писането на код. В края на краищата има толкова много работа! Но дали наистина недостатъчното време за кодиране е проблемът?
За много от нас гасенето на пожари също може да бъде изрично посочено в нашата длъжностна характеристика. Ние ходим на работа всеки ден, знаейки, че трябва да сме готови да се плъзнем надолу по стълба в един момент, да вземем шапките си и да скочим на камиона. Приемаме го като такъв, какъвто е, и предполагаме, че не можем да направим нищо по въпроса. Но какво, ако първопричината за нашите борби е силната липса на ефективност? Всеки знае колко е важно да го направиш по-добре от другата компания там. Ние просто не можем да стигнем до там - изглежда нямаме честотна лента. Мениджърите добавят повече хора и увеличават размера на своите организации и все още имат същите трудности. Изглежда не можете да преодолеете гърбицата, защото вашите екипи не разработват софтуер ефективно (и не сте сами).
Принципи за ефективно развитие
Pixabay
И така, какво ни кара да сме неефективни? За повечето от нас първото нещо, което идва на ум е липсата на автоматизация (автоматизирани компилации, внедряване, тестване). "След като имаме достатъчно автоматизация, животът ще се подобри." За съжаление това е само част от решението. Помислете за ефекта от преработката върху вашия проект. Най-ефективният начин за изграждане на функция е да я изградите веднъж правилно и никога да не се връщате и да я докосвате отново. Грешки, рефакторинг и други подобни дейности по същество отварят отново пациента, след като е напуснал операционната зала и има присъщ риск, свързан с това. Не можем да премахнем преработката, но със сигурност трябва да се стремим да я сведем до минимум.
„Но дали пъргавият не прегръща преработката (напр. Рефакторинг)?“ Всъщност прави това по някакъв начин, защото създателите на agile разбраха, че две основни причини за преработката са непредвидени обстоятелства и променящи се бизнес изисквания. Оказва се, че хората ужасно предсказват бъдещето. Пъргавите създатели също разбраха, че огромен принос за неефективността е това, което разработчиците наричат „позлатяване“ - пакетиране във функционалност, която смятаме, че някой ще използва, въпреки че крайните потребители всъщност никога не са я искали. Това е като свинско месо за вашия софтуерен продукт - пълна загуба на време. „Не изграждайте космическа станция, когато всичко, което искат, е Volvo.“ Така че компаниите разумно започнаха да изоставят свинското месо и вместо това да възприемат рефакторинга, добавяйки функционалност само когато има ясна нужда. Но непредсказуемостта на живота не е единственият двигател за преработка, нали?
Пропуснатите подробности на всеки етап от развитието на характеристиките в крайна сметка ще загубят време и пари. Ефективното предварително сътрудничество с течение на времето ще ви спести много преработка (справяне с пропуснатите изисквания, късогледски дизайн и т.н.). Всички ние имаме слепи петна и всички се нуждаем от допълнителни комплекти очи. Много екипи за разработки възприемат това отзад по време на прегледа на кода, но влагат много по-малко енергия в съвместната работа рано, когато проблемите могат да бъдат решени евтино и след минимални инвестиции.
Колко пъти сте внедрили функция и сте открили значителни недостатъци в края, които е трябвало да бъдат засечени по време на дискусии за изисквания / дизайн? Това е все едно да се опитате да шофирате от Атланта до Монтгомъри и да осъзнаете няколко часа след пътуването, че вместо това случайно сте стигнали до Бирмингам. Колко време беше прекарано в опити да се получи кода точно, за да се отвори отново пациента по-късно, защото бяха пропуснати значителни изисквания? Използването на колективна интелигентност абсолютно би спестило време и пари, но вместо това разработчиците често работят по функции изолирано.
Традиционно роене
Pixabay
Традиционното роене означава, че екипът работи съвместно по истории с няколко души, работещи по малка функция едновременно, съкращавайки цикъла на обратна връзка и намалявайки общото време за завършване на функцията (т.е. разделяй и владей). Това е по същество роене във всяка дисциплина (разработчици на бекенда, разработчици на потребителски интерфейс и т.н.). Преди да започне разработката, разработчиците на потребителския интерфейс работят за идентифициране на независими задачи, които могат да се изпълняват едновременно. Те обсъждат точките на интерфейса, така че всеки човек да знае как неговото парче се вписва в цялото. След това членовете на екипа могат да продължат да изпълняват възложените им задачи и да съберат всичко заедно в края по време на интеграцията. Честите ангажименти и периодичните прегледи на кодове помагат да се гарантира, че всичко остава на релсите. Този подход изисква сътрудничество между разработчиците,което така или иначе помага да се постигне по-добър краен резултат. Често даваме приоритет на времето, прекарано в писане на код (който и да е код), спрямо времето, прекарано като се уверим, че не пишем грешен код. Когато считате времето за потенциално запазено, стойността става ясна.
Получаване на деблокиран
Pixabay
Друг ценен подход към роенето е да се съсредоточи екипът в началото на смекчаването на зависимостта, за да се улесни едновременното развитие във всички дисциплини. Помислете за естествения поток на развитие на характеристика на потребителския интерфейс. Тестерите за автоматизация (SDET) зависят от работещ потребителски интерфейс за тестване, разработчиците на потребителски интерфейс зависят от работещ бекенд API, а разработчиците на бекенда зависят от конфигурация, актуализации на база данни и автоматизирани компилации / внедряване. Така че разработчиците на потребителски интерфейс може да не започнат своята работа, докато приложните програмни интерфейси не приключат, а SDET може да не започнат своята работа, докато функцията не приключи. Всяка дисциплина работи изолирано, което пречи на сътрудничеството, защото хората, с които трябва да взаимодействате, са заети да работят върху други неща.Но какво, ако можете да смекчите зависимостите по-рано и да позволите на дисциплините да работят едновременно върху една и съща функция?
Ето няколко примера:
1. Разгърнат функционален потребителски интерфейс w / Stubs
За да отблокират SDET, разработчиците на потребителски интерфейс могат да им дадат функциониращ потребителски интерфейс, който работи точно толкова, че да им позволи да пишат тестове. Интеграцията на Backend API и CSS стиловете все още могат да бъдат изчакани, тъй като автоматизираните тестови рамки като Selenium няма да се интересуват дали тези неща не са завършени. Всичко може да е дим и огледала. Въпреки че могат да настъпят промени, които причиняват известна преработка, ползата от ранното стартиране на тестовете надвишава този риск.
2. Разгърнати интерфейси на Backend (скрити, твърдо кодирани данни)
Предоставянето на бекенд API, които разработчиците на потребителския интерфейс могат да тестват, позволява ранно откриване на проблеми с интеграцията между предния край и API (ите). Понякога разбирате, че предоставеният API не отговаря на нуждите на разработчиците от предния край. Може да липсват цели обаждания, подписът да е грешен или структурата на данните да има проблеми. Ако има прекъсване, може и да научите за това рано, преди нещо да се е втвърдило.
3. Създайте HelloWorld версия на нови приложения и услуги.
Ако е необходима нова услуга (напр. Микроуслуга), създайте репозитория и изградете версия на услугата „здравей, свят“. Това позволява на разработващите ресурси да стартират на задания и скриптове за внедряване на Jenkins, преди услугата да бъде действително разработена.
Тези оптимизации улесняват ранния цикъл на обратна връзка, където някой може да каже „Имам нужда от нещо различно“, преди разработката да завърши на компонента, който изисква промяната.
Опаковане
Невероятно важно е да измислим как да съкратим времето за пускане на пазара на функции, по които работим. Бизнесът няма полза от наличието на куп функции, които са в процес на разработка, а разработчиците отчаяно се нуждаят от функции, които да бъдат внедрени бързо, така че дефектите да могат да бъдат отстранени възможно най-близо до точката на инжектиране. Разработчиците също отчаяно се нуждаят от взаимодействие помежду си, въпреки че всичко, което наистина искат да направят, е да напишат код. По-добре е за всички участващи, включително крайния потребител, който просто иска по-добър продукт. Ако не им го дадете, те ще отидат някъде другаде, за да го намерят.
Роенето е изключително ценен инструмент в инструментариума на вашата организация, ако хората отделят време да се научат как да го правят. Това не е рамка или дори дейност - това е начин на мислене. За всяка потребителска история членовете на екипа си задават два въпроса:
- Как да организираме задачи за тази история, за да накараме няколко души да допринасят наведнъж?
- Какъв е минимумът, който трябва да направя, за да отблокирам някой, който ме чака?
Какво ще стане, ако екипът ви бързо изгради функции заедно, вместо бавно да изгражда куп функции независимо? Те действително биха могли да отговорят на променящите се бизнес изисквания и да отговорят на нуждите на бизнеса, когато бизнесът се нуждае от тях, за да бъдат изпълнени. Състезателите ще се страхуват от вас - клиентите ще ви обичат. Това е рецепта за успешен бизнес.
© 2017 Mike Shoemake