Що таке Scrum?
Scrum — один із підходів до реалізації складних проектів. Це походить від тенденціїAgile, тобто спритності в розробці програмного забезпечення. На початку XXI ст. представники школи легкої методології, у тому числі творці Scrum – Кен Швабер та Джефф Сазерленд – підписали т.зв.Agile Manifesto. Потім вони встановили спільні цінності.
Scrum – це не методологія, а лише т. зв. framework , тобто структурна основа, в якій організована робота. Ця структура визначається набором практик, принципів і цінностей, які вкорінені в Lean Thinking.
Завдяки такому підходу кінцевий продукт повністю відповідає потребам інвестора, навіть якщо вони розвивалися під час реалізації проекту. Scrum дозволяє знизити витрати і значно впливає на продуктивність і відданість команди.
Команди, що працюють у Scrum, є міждисциплінарними, висококомунікабельними та самоорганізованими (в межах покладеного маштабу відповідальності). Розробники можуть вільно обирати інструменти та процедури, необхідні для виробництва високоякісного продукту. Також у виробничому процесі бере активну участь представник замовника.
У Scrum рішення приймаються на основі попереднього досвіду, а не припущень. Тому ви можете змінити напрямок розвитку своєї системи в будь-який момент.
У Scrum ми створюємо програмне забезпечення ітераційним способом у т. зв Sprint (організовані як цикл P-D-C-A, тобто план-зроби-перевір-дій). Це означає, що система будується частинами в короткі проміжки часу, і постійно вдосконалюється. Scrum дозволяє: скоротити цикл навчання, максимізувати цінність бізнесу та мінімізувати ризик помилок. Кінцевим результатом Sprint є готовий до використання приріст функціональний , який включає всі завершені компоненти системи, створені під час даної ітерації.
Основи Scrum
Основами Scrum є прозорість, перевірка та адаптація.
Прозорість означає, що окремі елементи процесу завжди видимі для учасників. Завдяки принципу прозорості підтримується високий рівень взаєморозуміння всіх аспектів впровадження, наприклад, єдиної номенклатури, визначення приросту тощо.
Перевірка та адаптація використовуються для виявлення невідповідностей та внесення змін. Таким чином, ми уникаємо відхилень від вимог, повідомлених замовником, і адаптуємо продукт до умов, що змінюються.
Цінності в Scrum
Три основи Scrum випливають безпосередньо з прийнятих цінностей: концентрація, відданість, відкритість, повага та сміливість. Завдяки їм вдається створити атмосферу взаємної довіри. Члени Scrum-команди зосереджуються лише на роботі в даному спринті.
До проекту залучені як розробники, так і зацікавлені сторони. Щоб бути успішними, вони повинні бути відкритими до нових ідей і викликів. Члени Scrum-команди поважають думки та компетенції один одного. Команда Scrum має сміливість представити свої ідеї на форумі, правильно та поступово діяти та подолати всі труднощі.
Scrum в eVolpe
У eVolpe Scrum набуває форми, яку ми напрацювали протягом десяти років досвіду впровадження проектів. Кожен раз ми враховуємо потреби, про які повідомляють наші клієнти. Ми домовляємося про принципи співпраці на самому початку проекту. Інтереси клієнта забезпечуються взаємно затвердженим контрактом на виконання.
Створення Product Backlog
Діяльність за методологією Scrum починається після етапу консультування, вибір CRM-системи та комерційні домовленості закриваються. Вони мають форму аналітичної діяльності, яка детальніше описана тут.
Для клієнта, зацікавленого у впровадженні, ми проводимо семінари System Overview (ознайомлення з системою) або Product Discovery (виявляючи потреби та вимоги до системи).
Це надзвичайно творчі зустрічі, які дозволяють поглянути на управління бізнес-процедурою як з вузької, так і широкої точки зору. Варто наголосити, що участь у майстер-класі вимагає твоєї повної участі.
Для кращої візуалізації обговорюваних питань ми пропонуємо тобі прийоми креативного мислення, які стимулюють твою уяву; все з використанням кольорових стикерів, маркерів, дошок та антистатичних плівок.
Результатом семінарів є,Product Backlog переважно у формі User Stories, тобто «історій із життя користувача». Його готує представник eVolpe, який виступає в якості довіреного власника продукту в проекті (діловий зв’язок між клієнтом і командою розробників). І в подальшому Product Backlog є приоритетним. Ці дії здійснюються спільно довіреною особою Product Owner і довіреною особою з іншого боку, тобто представником замовника – особою, відповідальною за продукт, яка приймає рішення про формування його бачення та розвитку.
У деяких випадках на основі отриманогоProduct Backlog ми готуємо оцінку окремих елементів системи, щоб отримати порядок величини проекту перед його запуском. Цей підхід ми використовуємо найчастіше, коли клієнт хоче визначити суму бюджету проекту. Однак слід пам’ятати, що підхід scrum дозволяє і навіть підтримує внесення змін і поворотів у напрямку, в якому рухається проект, тому ця оцінка є переважно ілюстративною.
Під час Спринтів
Реалізація проекту scrum здійснюється кількатижневими ітераціями. Це означає, що після кожного такого періоду відбувається збільшення нових функцій, зміна або вдосконалення існуючих елементів системи. Кожна ітерація починається з зустрічі під назвою «Планування спринту». Під час нього встановлюється мета майбутнього спринту, тобто головні завдання, які будуть досягнуті.
На цій основі також підбираються User Stories, вирішення яких дозволяє досягти передбачуваної мети. Вони складають Sprint Backlog. Друга частина зустрічі базується на детальному плануванні робіт командою розробників, щоб готові питання відповідали попередньо узгодженим критеріям завершення (Definition of Done).
Це надзвичайно важливо, тому що щодня в наступні дні відбуваються короткі зустрічі під назвою Daily Stand-up (тривають максимум 15 хвилин),в eVolpe ми проводимо їх в таблицях Scrum (одночасно використовуємо систему управління проектами Redmine, створену для наших потреб). Кожного разу перевіряється хід робіт і, можливо, попередній план адаптується до реальних умов. Ми також встановлюємо, що нам вдалося зробити за останні 24 години, який план дій і чи не виникли у нас труднощі.
Під час Спринтів також відбуваються зустрічі під назвою Refinement. Вони присвячені новим вимогам, про які повідомляє клієнт, щоб їх можна було правильно вказати, можливо, розділити на менші, а потім оцінити. Завдання, підготовлені таким чином, доступні в Product Backlogu, і їх можна вибрати для виконання під час майбутніх Sprint-ів.
Чим закінчується кожен Sprint?
Після закінчення спринту ми зустрічаємося з клієнтом (найчастіше дистанційно) під час огляду спринту. Потім команда фіксує отриманий результат, коротко представляючи те, що було зроблено. Це також слушний момент для обговорення нових вимог (які, можливо, були викликані поточною формою продукту), інших трансформацій а також очікувань від наступного Sprint-y. Тому перевіряється виконана робота, а також адаптація вимог до поточної ситуації.
Після кожного Sprint-у можлива установка пакетів, які створюють збільшення виробничого середовища замовника. Звичайно, не кожен Спринт має закінчуватися таким виробництвом. Це повністю залежить від рішення замовника.
Пам’ятай! Маєш можливість дізнатися про нові функції в тестовому середовищі, підготовленому для тебе. На підставі цього виходить кінцеве затвердження завдань з попереднього Sprint-y.
Остання зустріч, на якій бере участь команда Scrum: проксі-власник продукту, команда розробників і Scrum-майстер (відповідальний за процес), є Sprint Retrospective. Ретроспектива – це чудова можливість ознайомитися з нашою роботою. Варто також уважніше придивитися до міжособистісних стосунків, які склалися в колективі, і обговорити, що вдалося і чим пишаємося, а над чим ще потрібно попрацювати. Таким чином ми стаємо ще ефективнішими як команда. У Scrum відбувається така важлива адаптація.
Кожен проект може складатися з багатьох послідовних Sprint-ів.
Зазвичай це від кількох до кількох десятків ітерацій. Коли ви вирішите, що продукт готовий, ми переходимо в режим обслуговування, зазначений в договорі на обслуговування.
Agile
Дії, що здійснюються в рамках впровадження методології Agile,котрі плануються поетапно і на основі поточного досвіду користувачів. Стандартно в рамках кожної з кількатижневих ітерацій (так званих Cпринтів) поставляється робочий фрагмент (приріст) системи. Його можуть тестувати кінцеві користувачі на постійній основі не тільки з точки зору коректної роботи, а й з точки зору практичного використання під час реалізації реальних бізнес-процесів.
Завдяки цьому є можливість періодично коригувати завдання та вносити зміни відповідно до виникаючих потреб. При цьому замовник має повну свободу контролювати бюджет і обсяги запланованих робіт, розставляючи їм відповідні пріоритети. Розрахунок проекту ґрунтується на принципахTime & Material, що означає, що фінансові витрати, які несе інвестор, стосуються лише часу та ресурсів, витрачених на роботу над реалізацією.
Традиційні та гнучкі методи
впровадження ІТ-систем
Методологія впровадження – цеспосіб організації ІТ-проекту, що дозволяє оптимально реалізувати весь проект. У випадку корпоративного програмного забезпечення надзвичайно важливо, щоб усі технічні аспекти відповідали бізнес-потребам клієнта. З цією метою протягом багатьох років з’явилися два керівних методологічних підходи: традиційний (інакше: Waterfall , каскадна методологія) і гнучкий (включаючи, наприклад, framework під назвою Scrum).
Яку методологію вибрати?
Слід ретельно обдумати питання яку з методологій впроваджувати в фірмі . Незалежно від остаточного рішення,починати процес без аналізу вимог не варто. Обидва підходи – традиційний і спритний– припускають точне вивчення середовища та внутрішніх умов, які визначають архітектуру впорядкованої системи. Чи буде робота по впровадженню проводитися за методологією Waterfall або Agile, в більшості випадків залежить від підходу клієнта до його активної участі в реалізації.
Маючи час, ви повинні знати, що Scrum вимагає постійного спілкування та співпраці, а також постійної перевірки виконаної роботи. Для деяких компаній таке масове залучення співробітників до процесу впровадження є певною незручністю. Інші, однак, вважають це головною перевагою підходу Agile. Однак досвід EVolpe показує, що залучення клієнта має кардинальне значення для ефективної реалізації.
Проблеми під час співпраці на принципах Waterfall
Переваги співпраці на основі Scrum
Поговори з нами про консультаційні послуги та впровадження CRM-систем у твоій компанії!
Ми зв’яжемося з тобою
напротязі 24 годин.
