Про те, як ми Scrum впроваджували - Частина 1

Почалося все рівно рік тому. Тоді співробітники нашої компанії дізналися про те, що є scrum. Це методологія розробки ПЗ, яка ламала сформовані стереотипи в 1С:Підприємство-автоматизації, і буквально підірвала мозок людям, які звикли працювати за стандартною схемою. Методологія говорить, що не потрібно мати закінчену технічне завдання до початку розробки, нові завдання з'являються в будь-який час, ще задовго до завершення існуючих. При цьому нові завдання можуть змінювати і скасовувати існуючі, незалежно від того, виконані ті чи ні.

Тоді це здавалося чимось абсолютно нереальним. Більшість колективу було налаштовано скептично. Але спробувати все ж вирішили.

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

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

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

Повернемося до scrum. Scrum відноситься до гнучких методологій розробки (agile). Це означає, що тут немає жорсткого документування і проходження документації, навпаки-вітаються зміни у вимогах, тому що це сприяє поліпшенню і розвитку продукту. Головне – задоволення замовника з допомогою частих і безперервних поставок версій продукту, які замовник може самостійно «промацати» і зрозуміти, чого йому хочеться.

Ось основні принципи:

Особистості та їх взаємодія важливіша, ніж процеси та інструменти. Працююче програмне забезпечення важливіше, ніж повна документація. Співпраця із замовником важливіша, ніж контрактні зобов'язання. Реакція на зміни важливіша, ніж дотримання плану. Отже, ми вирішили впроваджувати scrum. Пора було починати щось робити. Перше, з чого ми почали – це вирішення питання, як вписати цю методологію в світ 1С:Підприємство. Потрібно було визначити, у якому вигляді scrum буде входити у звичні будні наших розробників, аналітиків, керівників проектів, менеджерів і компанії в цілому. Ми почали з прийняття рішень про те, які положення і процеси методології нам точно підходять, а які потрібно трансформувати під наші реалії. Продумували трансформацію.

Перш ніж пробувати методологію на практиці, нам потрібно було її переосмислення в контексті саме нашої компанії, потрібно було визначити точки, від яких ми будемо відштовхуватися. Ми склали документ, в якому по пунктах описали, як scrum буде виглядати у виконанні TQM systems. Наступним етапом було використання методологи у внутрішньому проекті з переробки нашої власної облікової системи.

Продовження далі ...

• 
• Контент-маркетолог TQM systems Nataliya Raevskaya
• 6/21/2020 6:48:09 AM
• uanews