Як покращити роботу Agile проекту — блог Drudesk
050 640 98 44
support@drudesk.com

Критерії, які зроблять ваш Agile-проект ідеальним

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

Готові зробити вашу роботу гнучкою? Сьогодні ми розглянемо декілька прикладів, як можна покращити роботу Agile. І в цьому нам допоможе Барт.

Для початку, розповімо, що таке Agile. Agile (гнучка розробка програмного забезпечення) — це спосіб керування командами девелоперів і проектами. Більшість методик Agile розбивають завдання на маленькі частинки з мінімальним плануванням і не влючають довге планування. Ітерації — це короткі часові фрейми, які загалом тривають 1-4 тижні. І щоб всі були здорові, щасливі та задоволені роботі по Agile, треба дотримуватися наступних принципів:

  1. Слідуйте інструкції — проводьте Agile правильно.
  2. Використовуйте за призначенням і там, де він потрібний.
  3. Використовуйте правильну дозу — ті методики, які будуть корисні для вашого проекту, але разом з тим не забувайте про головні принципи, та на що націлений Agile.

Корисні поради стосовно Agile девелопменту

Як можна покращити роботу Agile проекту, розглянемо по порядку.

1. Не запроваджуйте Agile з паузами

Певний час працюємо по спринтах, оцінюємо задачі з урахуванням тестування, створюємо беклог, плануємо прийнятне навантаження на кожного програміста, беремо до уваги багфіксинг і т.д. — працюємо за найкращими Agile практиками. А потім одного дня: “Хлопці, давайте на пару тижнів без скраму, працюємо по 10 годин і без вихідних... Замовнику терміново треба реліз, терміни піджимають. А як тільки розгребемося знову перейдемо на Agile” і т.д.

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

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

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

2. Подаруйте розробникам більше свободи

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

Програмісти — люди творчі, їм потрібен простір. Не затискайте їх… Адже тоді вони починають боятися лишній раз провести час не за написанням коду, і бути впійманими за читанням книги чи просто розмірковуваннями. Тому що потім прийдеться відзвітуватися за проведений час. Як наслідок, робота в такому режимі не дуже допомагає проекту, а лише нагнітає негативну атмосферу.

Барт каже: "Не перетворюйте стенд-апи на звіти, бо вони повинні бути синхронізацією роботи."

3. Покращіть роботу у командах

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

Барт: “Agile команда розробників найкраще працює як єдине ціле для досягнення спільної мети. В успішній розробці продукту — обов’язкова тісна співпраця!“

Підсумок

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

Хороший Аджайл

 

Якщо у вас виникли проблем стосовно вашого Drupal проекту, зв’яжіться з нами!