В яких випадках компанії достатньо Scrum, а в яких слід звернути увагу на інші моделі розробки? Експерт Agile-трансформації Альона Лубчак розкаже про оптимізацію процесів розробки програмного забезпечення.
Симптоми, що говорять про необхідність масштабуватись
Часом виникають ситуації, які демонструють, що вам не досить Scrum для організації роботи команд. Вони проявляються в проблемах комунікації, налагодженні робочого процесу та організації контролю за виконаними завданнями. Все це призводить до таких негативних наслідків, як затримка випуску продукту, супутні помилки в коді або модулях та зниження якості роботи в цілому. Щоб запобігти таким ситуаціям, слід уважно слідкувати за процесом роботи та вчасно змінювати процес розробки. То ж які бувають симптоми? Розгляньмо 5 випадків з практики нашого експерта.
1. Велика кількість учасників робочого процесу
Якщо до проєкту залучені більш ніж 30-35 виконавців (дизайнери, тестувальники, розробники, менеджери), то слід переходити на складнішу модель розробки, ніж просто Scrum. Тоді у вас вже є 4-5 команд, які працюють над одним продуктом й їм для організації розробки звичайного Scrum не вистачає.
2. Дублювання задач у різних команд
Іноді виникає досить цікава ситуація, коли в компанії одну й ту ж задачу роблять одразу дві команди. Причиною цього найчастіше виступає погана комунікація, відсутність синхронізації між командами та власниками продукту. Щоб запобігти цьому, ще з перших етапів роботи над проєктом слід запровадити систематичну комунікацію з фіксуванням домовленостей. Це допоможе нівелювати ризики дублювання та дозволить Scrum майстрам всіх команд синхронізувати свої дії.
3. Залежності
На масштабі дуже часто між задачами, над якими працюють команди, є залежності. Якщо їх не відстежувати та не управляти ними, то вони дуже швидко перетворюються на заплутаний клубок ниток. Команди перестають розбиратись в них та в результаті релізи затримуються постійно через неготовності тієї або іншої частини продукту.
4. Відсутність систематичних покращень на крос-командному рівні
Команди можуть вміти робити покращення на командному рівні, але на крос-командному – ні. Тут важливо додавати інші способи організації розробки, які будуть містити в тому числі інструменти покращення на крос-командному рівні.
5. Культура компанії
При масштабуванні компанії часто виникає ситуація, коли внутрішня культура розмивається. Що мається на увазі? Зазвичай продуктові IT-компанії виростають з невеликих технічних стартапів, заснованих групою однодумців. Коли компанія масштабується то ті елементи культури, які допомагали на початкових етапах життєвого циклу компанії, починають заважати. Наприклад, жорстка централізація рішень та замикання всіх комунікацій на одній людині. Коли ви сиділи в одній кімнаті, всі все знали. Але коли ви розрослись, то бути в курсі важливих змін потрібно й для цього треба використовувати формальні процеси.
Висновок
Фреймворк Scrum підходить невеликим командам (до 10 учасників). Якщо у вас вже таких команд 4-5, то можуть з’явитись проблеми з комунікацією та синхронізацією робочих задач та процесів. При масштабуванні компанії слід звертати увагу на спеціальні фреймворки (SAFe, DAD, Nexus, Scrum@Scal, LeSS), які дозволяють організовувати, контролювати та редагувати дії багатьох команд без зниження якості роботи чи проєктного цифрового продукту.
Перед вами стоїть завдання масштабуватися і впроваджувати SAFe, SoS або інший фреймфорк з масштабування в Agile? Консультанти Е5 не просто нададуть рекомендації, а допоможуть їх впровадити у вашій компанії з урахуванням вашого бізнес-процесу й обмежень. Забронюйте час безкоштовної консультації:
Будемо раді допомогти Вам!