ISO 9001 + Scrum + регламент K2 ERP: система якості, тижневі спринти, Zoom-записи, VDoc і Telegram-комунікації: відмінності між версіями

У Scrum є три базові ролі:

* бізнес-аналітик;

* відповідальний за клієнтську комунікацію.

'''Scrum Master — це відповідальний за успіх Scrum-процесу в команді.'''

Основні обов’язки Scrum Master:

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

'''Product Owner — це єдина точка прийняття остаточних продуктових рішень.'''

'''Product Owner визначає “що і навіщо потрібно зробити”, а команда визначає “як саме це зробити в межах спринту”.'''

'''Scrum-команда K2 ERP — це 7 співробітників, які безпосередньо виконують роботу в межах спринту.'''

До команди можуть входити:

'''Команда відповідає не за активність, а за готовий результат спринту.'''

'''Product Backlog — це пріоритизований список бізнес-вимог, технічних вимог, задач, дефектів, покращень і майбутніх можливостей продукту.'''

'''Product Backlog — це не смітник ідей. Це керована черга розвитку продукту.'''

'''Sprint Backlog — це набір задач, які команда бере в роботу на конкретний спринт.'''

'''Sprint Backlog повинен показувати не тільки те, що заплановано, а й скільки реально залишилося зробити.'''

'''Спринт у K2 ERP триває 1 тиждень.'''

* аналіз результату.

Scope спринту повинен бути фіксованим.

* відображена у звіті спринту.

'''Заборонено:''' хаотично змінювати Sprint Backlog після старту спринту. Якщо зміна потрібна — вона фіксується, погоджується і має доказ.

Планування спринту проводиться на початку тижня.

'''Планування спринту без запису Zoom, VDoc і посилання в Telegram-групі не є повністю зафіксованим процесом для ISO 9001.'''

Daily Scrum Meeting проводиться кожного робочого дня.

* чи потрібна допомога.

'''Суть Daily Scrum:''' це не довга нарада, не звіт начальнику і не технічна дискусія. Це коротка синхронізація команди з фіксацією результату.

Scrum Master по колу ставить кожному учаснику три базові питання.

Відповідь повинна бути конкретною:

</blockquote>

Потрібно розкрити:

</blockquote>

Потрібно чесно назвати блокери:

* потрібна консультація бухгалтера або галузевого спеціаліста.

Якщо під час Daily Scrum виникає питання, яке потребує окремого обговорення, Scrum Master фіксує його як Action Item.

'''Daily Scrum не вирішує всі проблеми. Він виявляє проблеми і запускає окремі короткі дії для їх вирішення.'''

На Daily Scrum заборонено:

* перетворювати Daily Scrum на годинну нараду.

'''Заборонено:''' перетворювати 15-хвилинну конференцію на довгу нараду. Daily Scrum — це контроль руху, а не місце для вирішення всіх проблем.

Після кожного Daily Scrum потрібно оновлювати показники спринту.

'''Якщо щодня не видно динаміки виконання, команда керується відчуттями, а не фактами.'''

Співробітники повинні відмічати час у баг-трекері '''день у день'''.

* робочий день може плануватися як 6 годин виконання задач + 2 години навчання.

Під час спринту кожна задача повинна проходити контрольований маршрут:

'''Готовність задачі визначається не словами виконавця, а проходженням узгодженого маршруту перевірки.'''

Задача вважається виконаною тільки тоді, коли виконані умови Definition of Done.

* якщо була Zoom-перевірка або Demo — запис збережено у VDoc, а посилання надіслано в Telegram-групу.

'''Definition of Done:''' задача не завершена тоді, коли “код написаний”. Задача завершена тоді, коли результат перевірений, прийнятий і зафіксований.

Один раз на тиждень проводиться '''Demo та Review спринту'''.

* що переходить у наступний спринт.

'''Суть Demo:''' на Demo потрібно показувати працюючий результат, а не обіцянки, слайди чи довгі пояснення.

На Demo можуть бути:

'''Якщо робота виконувалась для конкретного замовника, результат повинен бути продемонстрований замовнику в Zoom під запис.'''

Demo має чітку структуру.

Scrum Master повідомляє:

* що буде показано.

Виконавці показують результат у системі.

* чи потрібне додаткове погодження.

Product Owner або замовник оцінює:

* що потрібно запланувати далі.

Бізнес-аналітик або консультант перевіряє:

* чи потрібно оновити документацію.

Тестувальник повідомляє:

* чи можна вважати функціонал готовим.

У кінці фіксується:

* де збережений запис Demo.

Підготовка до Demo не повинна забирати багато часу.

* підготовку списку питань до Product Owner або замовника.

'''Важливо:''' команда не повинна витрачати більше часу на підготовку красивого Demo, ніж на створення реального продукту.

Усі перемовини із замовниками, які стосуються задач, вимог, строків, приймання, демонстрацій, зауважень або змін, проводяться в '''Zoom із записом'''.

* який строк.

'''Правило роботи із замовником:''' жодна важлива домовленість із замовником не повинна залишатися тільки в усній формі. Zoom-запис, VDoc, Telegram-група і задача — це ланцюг доказовості.

Первинна задача може надходити як технічне завдання.

'''Правильно поставлене питання або задача — це значна частина успішного виконання роботи.'''

На Demo потрібно підготувати підсумкові показники спринту.

| }                            |

Після Demo або окремо після нього проводиться ретроспектива.

'''Якщо після ретроспективи не з’явилося жодної конкретної дії, ретроспектива була формальною.'''

Для ISO 9001 результати спринту повинні бути зафіксовані.

* картка або документ у VDoc.

'''Спринт:''' № ___

'''Telegram-група:''' ___

{| class="wikitable" style="width:100%;"

| }                      |

{| class="wikitable" style="width:100%;"

| }                          |

{| class="wikitable" style="width:100%;"

| }                      |

{| class="wikitable" style="width:100%;"

| }                          |

{| class="wikitable" style="width:100%;"

| }        |

{| class="wikitable" style="width:100%;"

| }      |

{| class="wikitable" style="width:100%;"

| }      |

{| class="wikitable" style="width:100%;"

| }      |

'''Суть звіту:''' звіт спринту повинен давати керівництву і команді чесну картину: що зроблено, що не зроблено, чому не зроблено, де це зафіксовано і що потрібно змінити.

Для контролю якості потрібно регулярно аналізувати метрики.

* кількість задач у спринті;

* динаміка Sprint Burndown Chart.

* кількість дефектів;

* кількість задач без перевіряючого.

* кількість Zoom-зустрічей;

* кількість рішень, зафіксованих після зустрічей.

* кількість задач без критеріїв приймання;

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

Усі дефекти повинні фіксуватися.

* '''низький''' — косметична або незначна помилка.

'''Заборонено:''' закривати дефект без повторної перевірки. Дефект не закритий, поки його не перевірив не той самий співробітник, який його виправляв.

Для K2 ERP документація є частиною якості.

'''Функціонал без зрозумілої документації не може вважатися повністю якісним для продукту K2 ERP.'''

Для ISO 9001 важливо не тільки виконувати роботу, а й мати докази.

* результати ретроспективи.

'''Головне для ISO 9001:''' якщо результат неможливо підтвердити записом, для ISO 9001 він вважається слабко контрольованим.

Для стабільної роботи компанії потрібно зафіксувати обов’язкові правила.

# '''Уся важлива інформація повинна бути зафіксована в системі, а не залишатися “на словах”.'''

'''Фінальна логіка:''' Scrum дає ритм. ISO 9001 дає контроль. Регламент K2 ERP дає доказовість. Разом вони створюють керовану систему якості.

Для дотримання якості потрібно прямо заборонити:

* перетворення Product Owner на комітет без єдиного рішення.

'''Критично:''' якщо робота не зафіксована, її складно захистити перед клієнтом, командою, керівництвом або аудитом ISO 9001.

'''ISO 9001, Scrum і регламент K2 ERP повинні працювати як єдина система.'''

Для ISO 9001 важливо, щоб усе це було не тільки зроблено, а й '''зафіксовано, перевірено, збережено і проаналізовано'''.

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

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