[Из песочницы] Российский 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.
Автор уверен, что большинство читателей Хабра знают основные принципы данного метода, но поскольку сам автор на практике столкнулся с этим методом только в данном проекте, то позволит себе весьма упрощенно озвучить основные моменты.
- Журнал пожеланий проекта (Project backlog) состоит из «Пользовательских историй» (user story) — это такие требования клиента к функционалу программного продукта, написанные простым человеческим языком. «Я, как пользователь, хочу…» (Нажми на кнопку — получишь результат. И твоя мечта осуществится).
- Каждая Пользовательская история разбита на задачи. Это видение разработчиков, как реализовать «хотелку» «Пользовательскую историю» клиента.
- Разработка ведется «спринтами», которые обычно длятся 1 неделю. (Чем короче спринт, тем более гибким является процесс разработки ©Википедия)
- Результатом выполнения «спринта» является успешно выполненная и работающая «Пользовательская история» (Нажми на кнопку, но что же ты не рад. Тебе больше не к чему стремиться)
Так вот, отсюда и ответ на вопрос «почему в команде разработчиков внезапно не стало PM-а» — все очень просто — данная должность не предусмотрена идеологией SCRUM-а, точно так же как не предусмотрена должность Software Architect (привет, Матрица! ) и должность Technical Writer (долой бюрократию! ). В команде предусмотрена должность Скрам-мастера (SCRUM Master), который всего лишь проводит совещания, формулирует и записывает итоги обсуждения. Свободная разработка свободных разработчиков людей.
И да начнется веселье разработка!
Напомню, что целью обсуждаемого стартапа является разработка «системы, в которой производственные и бизнес-процессы предприятия отображаются в блокчейне» (вместо устаревшей базы данных).
Классический, устаревший и малоинтересный инженерный метод разработки предполагал бы последовательное выполнение таких шагов.
- Описание сущностей (сырье-комплектующие-производственные процессы-поставщики-покупатели и т.д.), с которыми будет оперировать разрабатываемая информационная система.
- Установление связей между сущностями (поставщик поставляет сырье, покупатель покупает товар и т.д.).
- Разработка архитектуры системы.
- Описание компонентов системы.
- Разработка техзадания на каждый компонент системы.
- Реализация.
- Отладка, оптимизация.
- Внедрение системы.
Но ведь все это очень долго! Заказчик не сможет увидеть результат в течение ОДНОЙ недели!
Итак, применяем вместо устаревшего метода разработки — современный SCRUM.
- Создаем 1-ю Пользовательскую историю — «Я, как пользователь, хочу получить систему, в которой производственные и бизнес-процессы предприятия отображаются в блокчейне» (странно… где-то эти слова я уже слышал…).
- Команда начинает обсуждение, как в течение 1 го спринта успешно реализовать Пользовательскую историю.
- Нужен блокчейн; внутри блокчейна нужен смарт-контракт; нужен интерфейс записи транзакций в блокчейн; нужен интерфейс получения информации из блокчейна; нужны бек-енд и фронт-енд для ввода и отображения информации.
- Список задач определен, начинаем оценивать.
- Оценку каждой задачи дает каждый участник команды (каждая кухарка может управлять государством). Для оценки используется ряд чисел Фибоначчи: 1, 2, 3, 5, 8, 13, 21. Хотя нет, 21 нельзя использовать, округляем его до 20. Почему именно 21 (очко) округляем, а не 13 (несчастливое число), например? Сложно сказать, так устроена современная методика SCRUM.
- Как выбрать, каким числом оценивать каждую задачу? Интуитивно! Например, задача передвинуть стакан с водой на 20 сантиметров по поверхности стола — оценивается в 1 балл. А если мы этот же стакан переносим в соседнюю комнату — то это уже 5 или даже 8 баллов.
- Все оценили, все просуммировали.
- Хм… большое число получается — с точки зрения SCRUM-а это означает, что многовато задач для 1й недели разработки. Упрощаем.
В результате, по прошествии недели заказчик увидит сайт, на котором 1 кнопка. При нажатии кнопки в блокчейн отправится транзакция — «создано событие производственного процесса». Обратной связи пока не будет. Да, это полное описание успешно решенной Пользовательской истории «Я, как пользователь, хочу получить систему, в которой производственные и бизнес-процессы предприятия отображаются в блокчейне». Нет, автор не преувеличивает.
Стоимость разработки такого решения — ¼ от месячной зарплаты 4-х разработчиков и 1-го Скрам-мастера (в ценах апреля 2020 года — примерно $6000).
Вот такой он, российский SCRUM. Бессмысленный и беспощадный.
