Agile методи и методология за начинаещи - примери за гъвкаво разработване на софтуер и гъвкаво управление на проекти

Agile е методология за подход към разработването на софтуер. Състои се от различни рамки като SCRUM или Kanban, които помагат на екипите за разработка непрекъснато да изграждат, тестват и събират отзиви за своя продукт.

Agile се състои от четири основни принципа:

  1. Индивиди и взаимодействия върху процеси и инструменти
  2. Работещ софтуер върху изчерпателна документация
  3. Клиентско сътрудничество при договаряне на договор
  4. Отговаряне на промяна при изпълнение на план

Ще преразгледам тези принципи по-късно и ще ги осмисля повече. За да направите това, е важно да направите крачка назад и да разберете практиките за разработка на софтуер, които са били използвани преди.

Водопад

Развитието на водопада е много линеен подход за изграждане на продукт. Той няма почти никакво място за обратна връзка или повторение, докато продуктът не бъде напълно изграден и тестван.

Ето как работи: екипите прекарват седмици (а понякога и месеци) в изготвяне на документи за изисквания за продукти.

Преди да бъде написан какъвто и да е код, продуктовите мениджъри, анализатори и дизайнери ще съставят един масивен документ, който очертава продуктовите изисквания с изключителни подробности.

Меко казано, това е дълъг и трудоемък процес, при който някои неща неизбежно се пропускат.

Ето един прост мисловен експеримент. Помислете за търсене на Google или търсене на имейл клиент.

Сега се опитайте да опитате да си представите документа с изискванията за тези продукти.

Несъмнено важните неща ще бъдат пропуснати. Човек просто не може да си представи случая на употреба, мащаба или обхвата на това как тези продукти ще се развиват с времето.

Ако сте създали продукт - като самостоятелен конструктор или като член на екип - вероятно можете да се свържете с това твърдение.

Когато всичко е договорено, спецификациите се предават на инженерния екип, който след това изгражда продукта за спецификация, използва качествени и количествени данни и входове.

Когато всичко е кодирано, тестването започва.

Ако това е сложен продукт, тестването и отстраняването на грешки може да отнеме седмици или месеци, тъй като целият продукт трябва да премине през строг преглед. Когато тестерите и продуктовите мениджъри се откажат от изискванията за изпитване, продуктът е готов за изпращане в производство.

Има редица недостатъци в развитието на водопада и ето няколко.

Липса на вградени механизми за обратна връзка

Какво ще стане, ако екипът за разработки следва точно спецификациите и се окаже, че виждането му в живота просто не е толкова завладяващо, колкото продуктовият екип е смятал, че е? Или още по-лошо, какво ще стане, ако в документа за спецификация има грешка?

При разработването на Waterfall няма да знаете отговора на тези въпроси, докато продуктът вече не е изграден.

Разработката на продукта може да доведе до големи фиксирани разходи. Ако продуктът не работи, тези разходи може да се превърнат в потънали разходи.

Потъналите разходи са враг на строителя, защото потъналите разходи са разходи, които вече са направени и не могат да бъдат възстановени.

Какво ще стане, ако пътната карта се промени?

Това се случва през цялото време. Това се случва на компютъра, който използвате, за да прочетете тази статия, това се случва във вашата компания и в големи и малки технологични фирми.

Какво ще стане, ако пътната карта се промени и екипът трябва да насочи вниманието си към нещо друго? Под Водопад ви остава неизползваем продукт. Помислете: твърдост.

Отново, ако не можете да превърнете фиксираните си разходи в нещо гъвкаво, ще останете с голяма сметка и няма какво да покажете за нея.

Цялата всеотдайна работа, стресиращите срокове, каландрирането на дъската и късните нощи няма да доведат до резултатите, които сте искали в началото на проекта.

Продуктът събира прах, докато накрая бъде изпратен

Вместо постепенни подобрения да се доставят в производството за определен период от време, методологията на водопада чака да достави целия продукт до самия край.

Въпреки че това е разумен подход за изграждане на автомобил, това не е чудесен подход към софтуера.

Софтуерът, за разлика от автомобилите, е гъвкав във входа на дизайна.

Хората не могат да използват наполовина произведени коли. Но ние използваме наполовина изграден софтуер през цялото време.

Въведете Agile

Agile помага за решаването на тези проблеми, като позволява на екипите за разработка на продукти непрекъснато да изграждат функции, които добавят стойност. Той също така позволява на екипите постоянно да получават обратна връзка за работата си и да правят промени, ако е необходимо.

С използването на Agile методи екипите последователно и предсказуемо изпращат малки парчета код до производството с бързи темпове.

След като завършат някакъв вид функция, която ще добави стойност, те тестват и пускат в света. Това е итеративен подход към изграждането на технологии.

Вместо да отнема месеци за изграждане на краен продукт и провеждане на цялостен тест, Agile разработката позволява на екипите непрекъснато да изграждат по-малки парчета от крайния продукт и да ги добавят към производството с течение на времето.

Това означава, че тестването върви по-бързо, тъй като тествате само съвместимостта на най-новата част от кода. Това също така означава, че потребителите и заинтересованите страни са по-щастливи, защото непрекъснато виждат и използват най-новите подобрения на продуктите.

Помислете и за двата подхода към истински пример за реконструкция на кухня. Да предположим, че ще са необходими шест месеца, за да се свърши добре работата по ремоделирането.

Waterfall би предложил на изпълнителя и неговия или нейния екипаж да възстановят цялата кухня, след което да разкрият цялата кухня на клиента след изтичането на шестте месеца.

Докато работата свършва за същия период от време, собственикът остава на тъмно. Простите въпроси като как вървят, остават до голяма степен без отговор. Най-лошото от всичко е, че собствениците не могат да използват части от кухнята до самия край.

С Agile изпълнителят вместо това щеше да разбере какво може да направи екипът им на всеки няколко седмици и след това да позволи на своя клиент да го види и да го използва, докато реконструира останалата част от него.

Може би те могат да подменят шкафовете през първия месец, плотовете през втория месец, а до третия месец инсталират нов хладилник и печка. Не е лош изход и за двете страни!

При втория подход собственикът се възползва от използването на части от кухнята, преди всичко да е завършено. Вместо новата печка просто да седи там и да събира прах, тя всъщност се използва веднага щом може да се използва.

И може би собственикът на кухнята иска да замени един шкаф за рафт?  

Изпълнителят вече може поне да планира тази промяна преди изтичането на шестте месеца и да уведоми собственика как ще се отрази на времевата линия на проекта.

Изглежда и двете страни могат да работят заедно и да общуват прозрачно, за да гарантират правилните резултати и свършената работа.

Това са някои от многото предимства на Agile. И двете страни са по-добре.

Опитайте се да продължите този урок напред, докато научавате нови умения за развитие на freeCodeCamp и прилагате уменията си върху проекти.

Нека разгледаме някои други примери в света на софтуера

Преразглеждайки четирите принципа на Agile, вече можем да започнем да намираме примери за приложението на Agile в реалния и дигиталния свят.

До този момент се надявам да видите как тези принципи са пряко нападение върху процеса на водопада.

Принцип # 1: Индивиди и взаимодействия над процеси и инструменти

Наличието на солиден процес и набор от инструменти е много важно за Agile. Оценяването на индивиди и взаимодействието върху инструментите обаче позволява повече създаване и извеждане на стойност.

Отделни членове на екипа могат да правят нововъведения.

Вместо да принуждавате хората да се придържат към строги идеи и спецификации, можете да им дадете повече честотна лента, за да експериментират.

Част от поставянето на хора над инструменти е експериментирането с нови работни потоци. Един пример, който е от значение за иновациите в разработването на софтуер Agile, е кодек, компютърна програма, която кодира или декодира цифров поток от данни или сигнали.

Кодекът H266 / VVC използва около половината данни за поточно предаване на 4K видеоклипове. И е признато за най-ефективното кодиращо решение за бъдещото 4K и дори 4K VR поточно предаване в реално време.

Как е направено това откритие? Направен е от хора, използващи Agile за решаване на проблеми с видео компресията.

По-конкретно, той е направен, защото на хората е била дадена свобода да изграждат, тестват, експериментират и иновации за определен период от време. Не им беше казано да построят кухнята от нулата и да се върнат след шест месеца.

Те направиха малки крачки в правилната посока. Този резултат е поучителен.

Ето втори пример: когато Lastpass беше придобит от LogMeIn, LogMeIn се интересуваше както от технологията, така и от културата на дизайна, която Lastpass е въвел за изграждане на продукти.

Какъв тип култура беше това? Този, който даде приоритет на Agile.

Agile не само предлага продуктите на пазара по-бързо, но създава творчески и синергични резултати, които са ценни.

Създаването на стойност е заложено в културата на Agile.

Принцип # 2: Работещ софтуер върху изчерпателна документация

Това вече трябва да е очевидно. Вместо подробни спецификации и планиране, просто напишете няколко реда код, които работят.

Тествайте го. Вземете отзиви за него. Изпратете го.

След това го направете отново.

Повторете.

Изключително подходящ пример за този процес на повторение се намира във Форми в огън.

Те създадоха софтуер, за да улеснят събирането на мобилни данни. Те не написаха цялата си компания преди стартирането; те написаха няколко реда код, тестваха го и го изпратиха.

Тъй като набраха скорост, те ускориха своите тестови и итеративни стъпки.

И те повтаряха това, което работи и хвърляха онова, което не. Резултатите говорят сами за себе си.

Принцип # 3: Сътрудничество с клиентите при договаряне на договора

Agile насърчава бърза обратна връзка, за да получи обратна връзка от клиенти и заинтересовани страни.

Какво по-добро от това да работим назад от това, което реалните потребители и клиенти искат?

Имам бизнес ментор, който съветва, че вместо да анализирате прекалено много какво искат клиентите чрез безкрайно планиране, просто го улеснете. "Смекчаване на разсейването", каза той.

Писах за принципа KISS в freeCodeCamp и този съвет със сигурност важи в Agile: изградете нещо малко и вижте дали вашите клиенти го харесват.

Ако го направят, продължете.

Принцип # 4: Отговаряне на промяна при следване на план

Циклите за бърза обратна връзка пораждат бързи промени и корекции. Това е, което прави Agile толкова чудесен за екипи за разработка.

Ето защо трябва да го прегърнете.

Пътните карти винаги се променят, това е известна константа. Използвайки Agile методологии, екипите могат да реагират на промяната, като слушат отзивите на клиентите и правят необходимите корекции.

Има моменти, когато реагирането на промяна означава коригиране на вашия продукт или промяна в начина, по който мислите за потребителите или конкуренцията.

Класически пример, който студентите с гъвкавост могат да разгледат в пространството за електронна търговия, се продава на Amazon. Как бързо се приспособявате към конкуренцията? Един от начините е да изградите затворени общности или да изпробвате различни стратегии за пускане на продукти.

Препоръчително е да се внедрят решения, които са тактически и податливи.

Има една прекрасна поговорка: „Не можем да променим посоката на вятъра. Можем само да коригираме платната си. "

Когато си мисля за Agile, мисля за тази поговорка.

Agile е за учене, Agile за преподаване. Agile е свързана с гъвкавостта.

Можете да практикувате Agile в ежедневната си работа или да посещавате онлайн курсове, за да се развивате по-нататък.

Някои хора са достатъчно умни, за да предскажат какво иска техният клиент. Те знаят по кой начин духа вятърът.

Но за нас, простосмъртните, Agile е методология за навигация около нашите недостатъци в разбирането какво искат клиентите.

Системата ни позволява постоянно да регулираме платната си.