Швидкі методи та методології для початківців - Приклади гнучкої розробки програмного забезпечення та гнучкого управління проектами

Agile - це методологія підходу до розробки програмного забезпечення. Він складається з різних систем, таких як SCRUM або Kanban, які допомагають командам розробників постійно створювати, тестувати та збирати відгуки про свій продукт.

Agile складається з чотирьох основних принципів:

  1. Особи та взаємодія над процесами та інструментами
  2. Працююче програмне забезпечення над вичерпною документацією
  3. Співпраця клієнтів щодо переговорів про контракт
  4. Відповідаючи на зміни, дотримуючись плану

Пізніше я перегляну ці принципи і зрозумію їх більше. Для цього важливо зробити крок назад і зрозуміти практики розробки програмного забезпечення, які використовувались раніше.

Водоспад

Розвиток водоспаду - це дуже лінійний підхід до побудови продукту. У ньому практично немає місця для зворотного зв’язку або ітерації, поки продукт не буде повністю побудований і випробуваний.

Ось як це працює: команди витрачають тижні (а іноді і місяці) на складання документів про вимоги до продукції.

Перш ніж будь-який код буде фактично написаний, менеджери з продуктів, аналітики та дизайнери складуть один великий документ, який надзвичайно детально викладає вимоги до продуктів.

Щонайменше, це тривалий і кропіткий процес, в рамках якого деякі речі неминуче пропускаються.

Ось простий мислительний експеримент. Подумайте про пошук Google або пошук клієнта електронної пошти.

Тепер спробуйте спробувати зобразити документ з вимогами до цих продуктів.

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

Якщо ви створили продукт - як сольний будівельник або як член команди - ви, швидше за все, можете ставитись до цього твердження.

Коли все узгоджено, специфікації передаються команді інженерів, яка потім розробляє продукт за специфікацією, використовуючи якісні та кількісні дані та вхідні дані.

Коли все закодовано, тестування починається.

Якщо це складний продукт, тестування та виправлення помилок можуть зайняти тижні чи місяці, оскільки весь продукт повинен пройти ретельний огляд. Коли тестери та менеджери продуктів підписують вимоги до тестування, продукт готовий до постачання на виробництво.

Є ряд недоліків у розвитку водоспаду, і ось декілька.

Відсутність вбудованих механізмів зворотного зв'язку

Що, якщо команда розробників точно слідуватиме специфікаціям, і виявиться, що побачити її життя просто не так привабливо, як думала команда продукту? Або ще гірше, а що, якби в документі специфікації сталася помилка?

У розробці Waterfall ви не знатимете відповіді на ці запитання, поки продукт вже не побудований.

Розробка продукту може призвести до великих постійних витрат. Якщо виріб не працює, ці витрати можуть стати невитратними.

Потоплені витрати є ворогом забудовника, оскільки потоплені витрати - це вже понесені витрати, які неможливо повернути.

Що робити, якщо дорожня карта зміниться?

Це відбувається постійно. Це трапляється на комп’ютері, на якому ви читаєте цю статтю, це трапляється у вашій компанії, і це відбувається у великих і малих технологічних фірмах.

Що, якщо дорожня карта зміниться, і команді потрібно буде звернути свою увагу на щось інше? Під водоспадом у вас залишається непридатний продукт. Подумайте: жорсткість.

Знову ж таки, якщо ви не можете перетворити свої постійні витрати на щось гнучке, у вас залишиться великий рахунок і не так багато для цього.

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

Виріб накопичує пил, поки його остаточно не відправлять

Замість того, щоб додаткові вдосконалення надходили на виробництво протягом певного періоду, методологія водоспаду чекає, щоб доставити весь продукт до самого кінця.

Хоча це розумний підхід до побудови автомобіля, це не найкращий підхід до програмного забезпечення.

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

Люди не можуть користуватися наполовину виробленими автомобілями. Але ми постійно використовуємо наполовину побудоване програмне забезпечення.

Введіть Agile

Agile допомагає вирішити ці проблеми, дозволяючи командам розробників продуктів постійно створювати функції, що додають вартість. Це також дозволяє командам постійно отримувати відгуки про свою роботу та вносити зміни за необхідності.

Застосовуючи методи Agile, команди послідовно і передбачувано швидкими темпами доставляють невеликі шматки коду до виробництва.

Після того, як вони виконали будь-яку функцію, яка додасть цінності, вони тестують і випускають її у світ. Це ітераційний підхід до побудови технологій.

Замість того, щоб витрачати місяці на створення кінцевого продукту та проведення наскрізного тестування, програма Agile дозволяє командам постійно створювати менші шматки кінцевого продукту та додавати їх у виробництво з часом.

Це означає, що тестування йде швидше, оскільки ви перевіряєте лише сумісність останньої частини коду. Це також означає, що користувачі та зацікавлені сторони щасливіші, оскільки вони постійно бачать і використовують найновіші вдосконалення продуктів.

Розглянемо обидва підходи до реального прикладу реконструкції кухні. Скажімо, для того, щоб якісно виконати роботу з реконструкції, знадобиться півроку.

Водоспад рекомендує підряднику та його або її екіпажу відбудувати всю кухню, а потім відкрити всю кухню клієнту після закінчення шести місяців.

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

За допомогою Agile підрядник натомість з’ясовував, що їхня команда може робити кожні кілька тижнів, а потім дозволяв своєму клієнту бачити це та використовувати, поки вони реконструювали решту.

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

При другому підході власник отримує вигоду від використання частин кухні, перш ніж все буде завершено. Замість того, щоб нова піч просто сиділа там і збирала пил, вона фактично використовується, як тільки її можна використовувати.

А може власник кухні хоче поміняти одну шафу на полицю?  

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

Здається, обидві сторони можуть співпрацювати та спілкуватися прозоро, щоб забезпечити правильні результати та виконати роботу.

Ось деякі з багатьох переваг Agile. Обидві сторони краще.

Спробуйте продовжити цей урок, коли ви вивчаєте нові навички розвитку на freeCodeCamp та застосовуєте свої навички у проектах.

Давайте розглянемо деякі інші приклади у світі програмного забезпечення

Переглядаючи чотири принципи Agile, тепер ми можемо почати знаходити приклади застосування Agile у реальному та цифровому світі.

На сьогодні я сподіваюся, що ви бачите, як ці принципи є прямим нападом на процес водоспаду.

Принцип №1: Особи та взаємодія між процесами та інструментами

Належний процес та набір інструментів дуже важливий для Agile. Однак оцінка індивідуумів та взаємодія за допомогою інструментів дозволяє більше створювати та виводити вартість.

Окремі члени команди можуть інновації.

Замість того, щоб примушувати людей дотримуватися суворих ідей та специфікацій, ви можете надати їм більше пропускної здатності для експериментів.

Частиною розміщення людей над інструментами є експерименти з новими робочими потоками. Одним із прикладів, який має відношення до інновацій у розробці програмного забезпечення Agile, є кодек, комп'ютерна програма, яка кодує або декодує цифровий потік даних або сигнали.

Кодек H266 / VVC використовує приблизно половину даних для передачі 4K-відео. І це визнано найефективнішим рішенням кодування для майбутнього потокового передавання 4K і навіть 4K VR у реальному часі.

Як було зроблено це відкриття? Його зробили люди, які використовують Agile для вирішення проблем стиснення відео.

Зокрема, це було зроблено тому, що людям давалася свобода будувати, тестувати, експериментувати та впроваджувати інновації протягом певного періоду часу. Їм не сказали будувати кухню з нуля і повернутися через півроку.

Вони зробили маленькі кроки в правильному напрямку. Цей результат є повчальним.

Ось другий приклад: коли Lastpass був придбаний LogMeIn, LogMeIn цікавився технологією, як і культурою дизайну, яку Lastpass застосував для створення продуктів.

Який тип культури це був? Той, який пріоритетним став Agile.

Agile не тільки швидше виводить товари на ринок, але і створює творчі та синергетичні результати, які є цінними.

Створення цінності закладено в культурі Аджилі.

Принцип №2: Працююче програмне забезпечення на основі вичерпної документації

На сьогодні це повинно бути очевидним. Замість детальних специфікацій та планування просто напишіть кілька рядків коду, які працюють.

Перевірте це. Отримайте відгук про це. Відправити його.

Потім зробіть це ще раз.

Повторити.

Дуже важливим прикладом цього процесу повторення є Forms on Fire.

Вони створили програмне забезпечення для полегшення збору мобільних даних. Вони не написали всю свою компанію до запуску; вони написали кілька рядків коду, протестували його та надіслали.

Набираючи обертів, вони пришвидшували свої тестування та повторювані кроки.

І вони повторювали те, що працювало, і кидали те, що ні. Результати говорять самі за себе.

Принцип №3: Співпраця з клієнтами під час переговорів про контракт

Agile сприяє швидкому циклу зворотного зв'язку, щоб отримати відгук клієнтів та зацікавлених сторін.

Що може бути краще, ніж працювати назад від того, що хочуть реальні користувачі та клієнти?

У мене є бізнес-наставник, який порадив, що замість надмірного аналізу того, чого хочуть клієнти за допомогою нескінченного планування, просто нехай це буде просто. "Поменшіть відволікання", - сказав він.

Я писав про принцип KISS у freeCodeCamp, і ця порада, безумовно, відповідає Agile: побудуйте щось маленьке і подивіться, чи сподобається це вашим клієнтам.

Якщо вони це роблять, продовжуйте.

Принцип No4: Відповідь на зміну, дотримуючись плану

Цикли швидкого зворотного зв'язку породжують швидкі зміни та коригування. Саме це робить Agile таким чудовим для команд розробників.

Ось чому ви повинні прийняти його.

Дорожні карти завжди змінюються, це відома константа. Використовуючи методологію Agile, команди можуть реагувати на зміни, слухаючи відгуки клієнтів та вносячи необхідні корективи.

Бувають випадки, коли відповідь на зміни означає коригування вашого продукту або зміна думки про користувачів чи конкуренцію.

Класичний приклад, на який можуть поглянути студенти спритності в просторі електронної комерції, продає на Amazon. Як ви швидко адаптуєтесь до конкуренції? Один із способів - побудувати закриті спільноти або спробувати різні стратегії випуску продуктів.

Рекомендується застосовувати тактичні та податливі рішення.

Є чудове прислів’я: «Ми не можемо змінити напрямок вітру. Ми можемо лише відрегулювати вітрила ».

Коли я думаю про Agile, я думаю про цей вислів.

Agile - це навчання, Agile - навчання. Agile - це гнучкість.

Ви можете займатися Agile у своїй повсякденній роботі або проходити онлайн-курси для подальшого розвитку.

Деякі люди досить розумні, щоб передбачити, чого хоче їхній клієнт. Вони знають, у який бік дме вітер.

Але для нас, смертних, Agile є методологією для подолання наших недоліків у розумінні того, чого хочуть клієнти.

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