Складною знайти людину, яка не бажав би,щоб до нього ставилися з повагою. Але для такого стану справ повинна бути причина. Наприклад, коли людина є висококласним визнаним фахівцем у сфері розробки програмного забезпечення. А для цього необхідно вчитися. І в рамках цієї статті буде розглянуто, що таке Agile, яка користь від неї, і як розібратися в цій технології.
Загальна інформація
Спочатку давайте розберемося з технічнимимоментами. Що собою являє Agile? Переклад (дослівний) цього слова з англійської мови - «живий, рухливий», трохи рідше згадується «гнучкий». І до речі, це скорочення. Повна назва цього підходу це Agile software development.Але оскільки це занадто довго, то і було вирішено скоротити. І зараз говорять просто Agile. Переклад як «гнучкий» використовується через те, що він в найбільшій мірі відповідає реальній ситуації.
Що ж сюди включено?
Продовжуємо розглядати, що таке Agile.Тут хочеться сконцентрувати увагу на тому, що це гнучкий підхід, в основі якого лежить безліч різних методологій (Scrum, ХР, "Канбан", Lean). Для того щоб краще розібратися в темі, давайте проведемо паралелі. Припустимо, що Agile-технології - це процес зародження Всесвіту. Кінцевий продукт - безпосередньо сам існуючий світ. А великий вибух - це найбільш болюча проблема, з якою тільки доводиться зустрічатися, - зміна переліку вимог до продукту. Зазвичай процеси створення на увазі використання каскадної моделі. У цьому випадку все йде послідовно і по етапах. Такий підхід можна виразити коротко: бачу мету - йду до неї. І якщо змінюються вимоги до кінцевого результату, то іноді доводиться переробляти заново чи не все. Що ще ускладнює таку ситуацію, так це спроба зробити вигляд, що все нормально, і потрібно рухатися вперед.
І ось Agile, методологія управління, покликанаборотися з усім цим завдяки своїй гнучкості. Ця збірна "солянка" мінімізує різні ризики за допомогою використання наборів принципів. Всі вони відображені в Agile-маніфесті, виданому в 2001 році. Якщо коротко, то звучать вони в такий спосіб:
- Головне - це люди, а не речі.
- Співпрацюйте, а не читайте контракт.
- Документація не повинна заважати працювати.
- Міняйтеся настільки швидко, наскільки це можливо.
Може здатися, занадто розпливчасто і не точно, але давайте деталізуємо.
пристрій процесів
Розглядаючи, що таке Agile, давайте звернемося до однієї з найпопулярніших методичок, відомої як "Скрам" (Scrum). Що ж вона пропонує? Для початку потрібно:
- Вибрати власника продукту. На цю роль підходить людина, що бачить, до якої мети потрібно йти, і що буде в кінцевому підсумку.
- Визначитися з командою. Для цього необхідна група, чисельністю від трьох до десяти чоловік, що володіють навичками, що дозволяють отримувати результат.
- Вибрати відповідального фахівця. Це людина, що буде стежити за розвитком проекту і допомагати команді обходити труднощі.
- Розібратися з труднощами.Слід зібрати в одному місці всі існуючі вимоги до продукту і розставити пріоритети. Власник продукту повинен зібрати тут все свої побажання. Потім команда їх оцінює і розбирається, чи можна це реалізувати, і скільки часу для цього потрібно.
- Слід розбити весь обсяг робіт на відрізки часу, довжиною в тиждень або дві, під час яких команда буде виконувати певні набори задач.
- Щодня слід проводити зустрічі, довжиною не більше п'ятнадцяти хвилин. На порядку слід обговорювати, що було зроблено вчора, які плани на сьогодні, і перепони, що заважають брати висоту.
- Робити огляди за підсумками тижня (двох), під час яких командою розповідається про те, що було зроблено. При цьому необхідно демонструвати працездатність частин продукту.
- Після кожного тимчасового періоду необхідно обговорювати проблеми і шукати рішення. Причому всі напрацювання необхідно впроваджувати відразу.
Як впізнати Agile?
Методологія управління незалежно від обраного напрямку завжди має такі особливості:
- Мінімізація ризиків. Це головна мета, яку переслідує будь гнучкий підхід.
- Ітеративна розробка. В даному випадку мається на увазі робота в невеликих циклах.
- Найважливіше - це люди і комунікація між ними.
Давайте уявимо річку. На одному березі замовник. На другому - команда. В такому випадку гнучка методологія розробки має переваги для всіх:
- Замовнику потрібен мінімально працездатний продукт. При цьому під час його створення можуть змінюватися умови.
- Команді корисно спілкуватися з колегами і замовником.В такому випадку мінімізується ризик бути неправильно зрозумілим, збільшується прозорість процесів, швидко вирішуються проблеми, зменшуються шанси того, що буде несподіванка при створенні продукту.
соціальний фактор
Коли розповідається, що таке Agile, зазвичайговорять виключно про позитивні моменти. І дійсно, поліпшується взаємодія всередині команди. Всі люди фокусуються на одній ідеї, не створюють секрети між собою, беруть на себе зобов'язання. Як результат, команда працює в комфортних умовах і швидкому темпі. Такий підхід дозволяє впорядкувати хаос.
З моменту свого формування він зміг знайтивизнання в технологічних галузях. На даний момент широко використовується для проектування нових програмних продуктів. Але в рамках загальному ділової практики подібний підхід все ще маловідомий. Тому до нього обережно ставляться ті, хто не зустрічався з Agile раніше. Також слід розуміти, що його слід застосовувати тільки в тих випадках, коли перед людьми стоїть завдання інтелектуальної праці.
невеликий приклад
Давайте розглянемо, як працюють ці методологіїрозробки ПО. Припустимо, у нас є Петро, власник продукту. Він не знає технічних деталей, зате у нього є бачення загальної картини. Він знає, навіщо потрібен продукт, які проблеми він буде вирішувати, і кого задовольнить. Також є зацікавлені особи. Вони можуть використовувати продукт, підтримувати його створення або ж якось ще бути втягнутими в його створення. Можна внести ще і призначені для користувача історії, в яких виражаються побажання зацікавлених осіб. Наприклад: система бронювання квитків на рейсові автобуси Москва-Санкт-Петербург повинна мати пошук по рейсам. Петро допомагатиме зацікавленим особам. Він візьме під контроль реалізацію з ідей для користувача історій. Також є команда розробників. Це люди, що будуть будувати робочу систему.
Оскільки використовується гнучка методологіярозробки, то призначені для користувача історії не накопичуються до великого релізу, а випускаються відразу після завершення і як можна частіше. Кількість оброблених звернень становить пропускну здатність команди на тиждень. Щоб не втратити темп і не загрузнути в ручному тестуванні, команда повинна працювати над автоматизованої інтеграцією. У чому вона полягає? Для кожного робочого моменту пишеться автоматичний тест. Якщо історій дуже багато, то може виникнути поспіх, втрата мотивації, зниження продуктивності і якості. На такі випадки передбачено метод «вчорашня погода». Він полягає в тому, що потрібно встановити жорсткі рамки кількості роботи і ретельно вибирати, що саме буде реалізовуватися. Згаданий раніше "Канбан" пропонує встановлювати ліміт завдань.
А що робити з чергою?
Гаразд, ось команда вирішила, що вона можеобробляти чотири історії на тиждень. Але як зорієнтуватися у всьому, що є? Припустимо, користувачі підкидають по десять історій на тиждень. Обробляється чотири. Таким чином, черга буде постійно зростати. На цей випадок є тільки один ефективний метод - слово "ні". Для власника продукту це надзвичайно важливо. Сказати «так» не важко. Значно складніше і важливіше вирішити, що не потрібно робити. Причому за це необхідно ще й нести відповідальність. Тому слід вирішувати, чому приділяти увагу зараз, а що слід відкласти. Щоб правильно розставляти пріоритети, потрібно щоб власник продукту розумів цінність і обсяг кожної історії.
приймаємо рішення
Частина історій надзвичайно потрібна.Інші ж просто є приємний бонус. Одні історії будуть розроблятися кілька годин. На створення інших підуть місяці. Багато часто проводять співвідношення між розміром історії та її цінністю. Але це не завжди правильно. Більше - не рівнозначно краще. Петру правильно розглядати пріоритети допомагає складність і цінність виконуваної завдання. Як визначити ці характеристики в кількісному значенні? Та ніяк. Це справжня гра в угадайку. І для більшої ефективності в неї необхідно залучати досить багато людей. Це і команда розробників, яка поінформує про обсяг робіт, і зацікавлені особи. Але слід розуміти, що всі дані, отримані таким способом, є приблизні здогадки. Тут не буває точних цифр. Спочатку будуть промахи. Але в міру отримання досвіду їх кількість і масштаб будуть знижуватися.
можливі ризики
Для уникнення проблем необхідно дати чесні відповіді на ряд питань. це:
- Правильні речі ми робимо? Це бізнес-ризик.
- Чи можемо ми реалізувати те, що потрібно? Це соціальний ризик.
- Чи буде працювати проект на цій платформі. Це технічний ризик.
- Чи вистачить грошей, і чи встигнемо? Це ризики термінів реалізації і вартості.
В даному випадку необхідні знання.Їх можна розглядати як протилежності ризиків. Коли фіксується значний рівень невизначеності, то ми набуваємо знань - наприклад, створюємо прототипи інтерфейсу або технічні експерименти. І вже володіючи ними, приймаємо рішення про те, в якому напрямку слід рухатися.
Як навчитися?
IT-індустрія надзвичайно швидко розвивається, іщоб не програти в кінцевому підсумку, необхідно постійно вчитися, підвищувати кваліфікацію і ефективність роботи. Тому як ніколи актуальні питання навчання і впровадження. З чого почати? Найкращий варіант - це кооперація з компанією, де вже застосовується Agile. Навчання в такому випадку буде проводитися людьми, які не з чуток знають, що собою являє гнучка розробка. Але таке, на жаль, не завжди можливо. Найчастіше залучається сторонній фахівець, який знає, що собою являє Agile. Впровадження цього підходу здійснюється під його наглядом. Правда, послуги такого фахівця коштують грошей. Але якщо залучить дійсно знаючої людини, то всі витрати окупляться сторицею. Адже в сучасному світі ефективність співробітників грає важливу роль.
Що чекає в майбутньому?
Методології розробки ПО постійно розвиваються.Шукають нові шляхи і можливості підвищення ефективності діяльності і роботи. Сказати, що нас чекає в майбутньому, досить проблематично. Ймовірно, гнучка система розробки буде інтегрована із засобами автоматизації виробничих процесів. Наприклад, можна буде вирішувати проблеми, навіть перебуваючи на віддаленості від місцезнаходження компанії. Багато в чому майбутнє визначають нові інформаційні технології. Адже коли вони виникають, то потрібно освоювати нові методи роботи з ними. І в цьому випадку виникає розвиток, замкнутий в циклі.
На закінчення
Ось і закінчився екскурс в гнучкі методирозробки. Але слід нагадати, що одна справа теорія, а зовсім інше - практика. Нові інформаційні технології, що постійно виникають, кидають виклики численному спільноті розробників. Як зробити діяльність команди більш ефективною? Відповідь на це питання кожен знаходить сам. Представлена тут інформація може бути використана для того, щоб оформити кістяк. Але на практиці доведеться працювати з наявною моделлю і доводити стан справ до стану відповідності існуючим викликам. Тоді команда зможе ефективно виконувати поставлені перед нею цілі.
