Менеджмент цифрового продукта. От идеи до идеала

Практики Agile во многом контринтуитивны. Достаточно легко можно себе представить, как в изолированной компании зарождается водопадный подход, сводя к минимуму вероятность, что скопированный по образу и подобию гибкий фреймворк[22] типа Scrum приживется.

Тем не менее, как было описано ранее, молодые компании начали двигаться в сторону альтернативных подходов к разработке. Через некоторое время, на встрече 17 независимых практиков новых методик программирования 13 февраля 2001 года, был сформулирован свод общих принципов гибких подходов – манифест Agile (Agile Manifesto).

3.1.1. Agile-манифест

Левая часть каждого тезиса важнее чем правая, но не отрицает его. Манифест не говорит о том, что нужно прекратить следовать плану, бросить писать документацию и отменить процессы. Разберем каждый его элемент.

Табл. 3.1. Agile-манифест

3.1.1.1. Люди и взаимодействие важнее процессов и инструментов

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

Такая же картина и с внедряемыми инструментами. Первичная цель внедрения – это повышение эффективности, которая, в свою очередь, прочно связана с качеством опыта сотрудника (англ, employee experience, сокр. EX). Если в процессе использования инструмента создается ощущение несправедливости или пустой траты времени, то стоит задуматься о его замене или отмене.

Например, я на практике наблюдал несколько волн джирафикации и деджирафикации, иногда даже в одной команде. Под джирафикацией я имею в виду внедрение инструмента управления задачами типа Jira[23]. Когда команда только запускалась, не было конкретных инструментов для отслеживания задач, команда работала, перемещая физические стикеры по Kanban-доске[24]. Через некоторое время команда внедрила диспетчер задач, и стало уходить заметно больше времени на ежедневные стендапы[25], так как приходилось тратить время на настройку и оперирование инструментом. Также часть времени уходила на «нарезание» задач на спринт. Потом, после очередного тренинга, команда начала делать очень короткие спринты и дробить функциональность на небольшие элементы (пользовательские истории[26]) размерностью менее одного дня разработки. На неделю спринта выходило 5–6 таких элементов, которые команда всем скопом каждый день доводила до релиз-кандидата[27]. При таком подходе отсутствовала необходимость в декомпозиции задач, так как каждый день задачи порождались и утилизировались в финальном артефакте. И команда опять перешла к физическим стикерам.

Через некоторое время, когда продукт вырос и был интегрирован в продуктовый ландшафт компании, понадобился возврат к системе управления задачами. Например, баг, который отловила служба поддержки, или какой-то из других продуктов должен быть доставлен до ответственного за исправление, или нужно показать зависимость задачи с задачами из других систем и продуктов. В команде началась повторная джира-фикация.

3.1.1.2. Работающее ПО важнее подробной документации

Условно документацию, участвующую в разработке ПО, можно разделить на три группы:

1. Проектная – создается до запуска разработки для описания образа результата.