Що робить розробку програмного забезпечення Agile настільки привабливою?

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

Як розробник, я розумію прагматичну цінність ітеративної розробки, але (найчастіше) це не вибір розробників, щоб використовувати спритний підхід до розробки програмного забезпечення. Це вибір управління зверху вниз! Будь то кристал, спритний метод, dsdm, rup, xp, scrum, fdd, tdd, ви його називаєте. Це не вибір розробника.

Для всіх менеджерів там, які найбільші причини для того, щоб зробити вибір Agile development, коли (на мій досвід) більшість менеджерів навіть не торкнулися коду в своєму житті!

Вимоги до зрушення, швидша доставка

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

Ось чому багато компаній виходять з ладу при використанні Agile / Scrum: менеджери не розуміють, що з великою потужністю (встановлення швидших термінів випуску та часто змінюються вимоги) відповідальність покладається на розробників для оцінки . Щоб спритний працював, менеджер повинен бути готовий потім скоротити сферу.

Вони хочуть сили обох.

Слідуючи тенденціям

Іноді люди роблять щось не через заслугу того, що вони починають (спритний), а просто тому, що це популярно, і інші люди намагаються зробити те саме.

"Що? Макроджам робить Agile? Чому ми не? Ми не повільні, ми Agile, чорт!"

Деякі люди не кажуть, що насправді спритний. Це просто засіб виправдати їх існування. Шеплер, тиск однолітків тощо.

Кодування саме по собі не є основною причиною того, що менеджери можуть переконатись у тому, щоб вибрати метод спритний як метод. Привабливий той факт, що можна швидше реагувати на зміни вимог та пріоритетів. Зрештою, «менеджер» повинен надати рішення кінцевому користувачеві / замовнику / його менеджеру.

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

Також важливо те, що в основному (наприклад, як у scrum) кожна проміжна доставка повинна бути майже готова до введення у виробництво. У той же час першими були розроблені найактуальніші функції. Отже, якщо проект буде скасовано через якесь корпоративне рішення, керівництво впевнене, що ви закінчите щось, що спрацює і може бути поставлено у виробництво.

Сподіваюсь, це допомагає.

Збільшити видимість того, що відбувається, і підвищити продуктивність

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

2. Вища продуктивність також зазвичай використовується для їх залучення, оскільки це легко продемонструвати (завдяки наочності). Деякі спритні євангелісти обіцяють їм неабияку продуктивність від своїх діючих співробітників. "Що? Я вже натискаю на них, як лимони, а ти мені скажи, що я можу отримати ще більше " ?

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

Результат? Багато команд у Росії distress. Вони думали, що спритний вирішить усі їхні проблеми, але це зробило прямо навпаки. Проблема була в іншому місці.

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

Відповідь на це питання може заповнити книгу.

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

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

Хороший приклад того, наскільки ефективне планування на основі сюжетів - це проект, над яким я працював. Кілька місяців (до того, як ми прийняли спритну розробку), керівник проекту вважав, що ми можемо вчасно поставитись, і це минуло приблизно 18 місяців від терміну. У всіх розробників було відчуття, що це, мабуть, нереально. Після початку гнучкого планування керівник проекту все ще провів оптимістичну оцінку ситуації. Але лише після декількох спринтів керівник проекту зрозумів, що команда просто не має можливості доставити всі вимоги в очікуваний час. І це було ще більше ніж 12 місяців від встановленого терміну.

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

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

більшість менеджерів навіть у житті не торкнулися коду!

Я був розробником 12 років, а зараз менеджером протягом 5. За 5 років я поступово переходив від менеджера, який все ще кодувався до того, що я був головним чином чистим менеджером (я все ще час від часу виправляю помилки або роблю вправи по прототипуванню).

які найбільші причини для того, щоб зробити вибір Agile development

• Видимість або Успіх швидко / Невдача - Ми - це магазин з розробки продуктів з 6-місячним та 24-місячним циклами. Ітеративна розробка з робочими, перевіреними функціями зробила кращу роботу з відображенням статусу проекту.
• Зміни - в нашому середовищі вимоги та час мають тенденцію фіксуватися. Але бізнес надто регулярно проходить через швидкі зміни, що змінюються. Ітеративний, видимий розвиток спростив проекти змінити напрямок.
• Вимоги, засновані на історії, з ітераційним розвитком полегшували роботу з бізнесом, який не завжди розумів технічні аспекти вимог або повністю розумів бізнес-драйверів деяких деталей. У наших минулих зусиллях, технічні вимоги високого рівня або вимоги до маркетингу не завжди були достатніми. Тепер, коли проекти розвиваються, може бути паралельне дослідження ринку та споживачів.
• Зміна процесу пов'язана з безліччю інших атрибутів розвитку, таких як TDD, автоматизованого проти ручного тестування, більш жорстких циклів тестування (у нас більше немає групи QC, а лише групи QA), і більш високої оцінки та зусиль, пов'язаних з якістю (ми використовуємо набагато більше інструментів та показників).

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

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

Я бачив, як низка компаній "робили" спритно. На жаль, мало хто з них сприймає спритність. Що я маю на увазі, це лише ітеративна розробка, а щоденні зміни (де більша частина команди сідає) не робить команду спритною. TDD, Рефакторинг, Постійна Інтеграція, Присутність Замовника, Практики SOLID роблять команду Agile. Без них ви просто ходите по колах.

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

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

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

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

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

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

Я думаю, вам не слід псувати процес Agile і практику кодування / розробки. Наприклад, Scrum не розповідає вам, як слід розвивати свій код - все стосується процесу, який вітає зміни.

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