Российский SCRUM. Бессмысленный и беспощадный

Доброе время суток, уважаемый Хабр!

Я программист «старой школы», с опытом работы более 20 лет. Участвовал в разработке многих проектов, большая часть из которых довольно известные и успешные. В некоторых проектах занимал руководящие должности, достиг неплохого уровня зарплаты. Но ведь мы собрались здесь не для того, чтобы помериться стажем, опытом, зарплатой и т.д., верно? Поговорим лучше о том, как стартапы используют современные методы управления разработкой программного обеспечения. И что из этого получается.

Дисклеймер. Данная публикация всего лишь отражает личное мнение автора на развитие и применение современных методов управления разработкой программного обеспечения и может рассматриваться всего лишь как развлекательное чтение, иллюстрирующее те моменты, которые внезапно могут вам встретиться в повседневной работе программиста.

Дисклеймер-2. Использование смайликов не рекомендуется в публикациях на Хабре. Но они подразумеваются.

Итак, речь пойдет о самом обыкновенном стартапе.

Жила-была обыкновенная производственная компания, в которой давно и успешно работает хорошо отлаженный производственный процесс. Все этапы упомянутого производственного процесса отображаются в информационной системе предприятия. Поступило на склад сырье и комплектующие — появилась строчка об этом событии в базе данных ERP (Enterprise Resource Planning, планирование ресурсов предприятия). Отгрузили произведенный товар покупателю — в базу данных добавилось еще пару-тройку строчек. Рутина, банальные информационные технологии на службе у реального бизнеса, ничего интересного.

Но время не стоит на месте, информационные технологии развиваются, банальная ERP уже не выглядит такой «модной» (даже скажем прямо, в некоторых глазах выглядит «устаревшей») и у группы инициативных менеджеров появилась идея «прикрутить» к производственному процессу блокчейн. Нет, не так. БЛОКЧЕЙН. Современный, Могучий, Эффективный и Неподкупный (все слова с Большой Буквы).

Собралась команда разработчиков — самая обычная, в самом классическом составе — Front-end developer, Back-end developer, Database developer. 3 разработчика и Project manager. Хотя нет, никакого Project manager-а на самом деле нет ( — Видишь суслика? — Нет… — И я не вижу. А он есть.), хотя это автор забегает немного вперед.

Специалиста по блокчейну в молодой команде не оказалось, никто из разработчиков, включая отсутствующего PM-а никогда с блокчейном дела не имели — поэтому в качестве Blockchain developer-а был нанят автор данной публикации, который имеет опыт разработки нескольких блокчейн-проектов.

Поскольку планируемая к использованию информационная блокчейн-технология на сегодняшний момент времени самая современная, то и метод управления разработкой программного обеспечения был выбран самый современный — а именно SCRUM.

Автор уверен, что большинство читателей Хабра знают основные принципы данного метода, но поскольку сам автор на практике столкнулся с этим методом только в данном проекте, то позволит себе весьма упрощенно озвучить основные моменты.

1. Журнал пожеланий проекта (Project backlog) состоит из «Пользовательских историй» (user story) — это такие требования клиента к функционалу программного продукта, написанные простым человеческим языком. «Я, как пользователь, хочу...» (Нажми на кнопку — получишь результат. И твоя мечта осуществится).
2. Каждая Пользовательская история разбита на задачи. Это видение разработчиков, как реализовать «хотелку» «Пользовательскую историю» клиента.
3. Разработка ведется «спринтами», которые обычно длятся 1 неделю. (Чем короче спринт, тем более гибким является процесс разработки (с)Википедия)
4. Результатом выполнения «спринта» является успешно выполненная и работающая «Пользовательская история» (Нажми на кнопку, но что же ты не рад. Тебе больше не к чему стремиться)

Так вот, отсюда и ответ на вопрос «почему в команде разработчиков внезапно не стало PM-а» — все очень просто — данная должность не предусмотрена идеологией SCRUM-а, точно так же как не предусмотрена должность Software Architect (привет, Матрица!) и должность Technical Writer (долой бюрократию!). В команде предусмотрена должность Скрам-мастера (SCRUM Master), который всего лишь проводит совещания, формулирует и записывает итоги обсуждения. Свободная разработка свободных разработчиков людей.

И да начнется веселье разработка!

Напомню, что целью обсуждаемого стартапа является разработка «системы, в которой производственные и бизнес-процессы предприятия отображаются в блокчейне» (вместо устаревшей базы данных).

Классический, устаревший и малоинтересный инженерный метод разработки предполагал бы последовательное выполнение таких шагов.

1. Описание сущностей (сырье-комплектующие-производственные процессы-поставщики-покупатели и т.д.), с которыми будет оперировать разрабатываемая информационная система.
2. Установление связей между сущностями (поставщик поставляет сырье, покупатель покупает товар и т.д.).
3. Разработка архитектуры системы.
4. Описание компонентов системы.
5. Разработка техзадания на каждый компонент системы.
6. Реализация.
7. Отладка, оптимизация.
8. Внедрение системы.

Но ведь все это очень долго! Заказчик не сможет увидеть результат в течение ОДНОЙ недели!

Итак, применяем вместо устаревшего метода разработки — современный SCRUM.

1. Создаем 1-ю Пользовательскую историю — «Я, как пользователь, хочу получить систему, в которой производственные и бизнес-процессы предприятия отображаются в блокчейне» (странно… где-то эти слова я уже слышал...).
2. Команда начинает обсуждение, как в течение 1го спринта успешно реализовать Пользовательскую историю.
3. Нужен блокчейн; внутри блокчейна нужен смарт-контракт; нужен интерфейс записи транзакций в блокчейн; нужен интерфейс получения информации из блокчейна; нужны бек-енд и фронт-енд для ввода и отображения информации.
4. Список задач определен, начинаем оценивать.
5. Оценку каждой задачи дает каждый участник команды (каждая кухарка может управлять государством). Для оценки используется ряд чисел Фибоначчи: 1, 2, 3, 5, 8, 13, 21. Хотя нет, 21 нельзя использовать, округляем его до 20. Почему именно 21 (очко) округляем, а не 13 (несчастливое число), например? Сложно сказать, так устроена современная методика SCRUM.
6. Как выбрать, каким числом оценивать каждую задачу? Интуитивно! Например, задача передвинуть стакан с водой на 20 сантиметров по поверхности стола — оценивается в 1 балл. А если мы этот же стакан переносим в соседнюю комнату — то это уже 5 или даже 8 баллов.
7. Все оценили, все просуммировали.
8. Хм… большое число получается — с точки зрения SCRUM-а это означает, что многовато задач для 1й недели разработки. Упрощаем.

В результате, по прошествии недели заказчик увидит сайт, на котором 1 кнопка. При нажатии кнопки в блокчейн отправится транзакция — «создано событие производственного процесса». Обратной связи пока не будет. Да, это полное описание успешно решенной Пользовательской истории «Я, как пользователь, хочу получить систему, в которой производственные и бизнес-процессы предприятия отображаются в блокчейне». Нет, автор не преувеличивает.

Стоимость разработки такого решения — 1/4 от месячной зарплаты 4-х разработчиков и 1-го Скрам-мастера (в ценах апреля 2020 года — примерно $6000).

Вот такой он, российский SCRUM. Бессмысленный и беспощадный.