Левая часть каждого тезиса важнее чем правая, но не отрицает его. Манифест не говорит о том, что нужно прекратить следовать плану, бросить писать документацию и отменить процессы. Разберем каждый его элемент.
Табл. 3.1. Agile-манифест
Если процесс мешает людям работать и взаимодействовать, то должна существовать возможность от него избавиться. Некоторые процессы просто устаревают, другие, в теории показавшиеся эффективными, на практике оказываются тягостными и вредят эффективности и удовлетворенности от работы.
Такая же картина и с внедряемыми инструментами. Первичная цель внедрения – это повышение эффективности, которая, в свою очередь, прочно связана с качеством опыта сотрудника (англ, employee experience, сокр. EX). Если в процессе использования инструмента создается ощущение несправедливости или пустой траты времени, то стоит задуматься о его замене или отмене.
Например, я на практике наблюдал несколько волн джирафикации и деджирафикации, иногда даже в одной команде. Под джирафикацией я имею в виду внедрение инструмента управления задачами типа Jira[23]. Когда команда только запускалась, не было конкретных инструментов для отслеживания задач, команда работала, перемещая физические стикеры по Kanban-доске[24]. Через некоторое время команда внедрила диспетчер задач, и стало уходить заметно больше времени на ежедневные стендапы[25], так как приходилось тратить время на настройку и оперирование инструментом. Также часть времени уходила на «нарезание» задач на спринт. Потом, после очередного тренинга, команда начала делать очень короткие спринты и дробить функциональность на небольшие элементы (пользовательские истории[26]) размерностью менее одного дня разработки. На неделю спринта выходило 5–6 таких элементов, которые команда всем скопом каждый день доводила до релиз-кандидата[27]. При таком подходе отсутствовала необходимость в декомпозиции задач, так как каждый день задачи порождались и утилизировались в финальном артефакте. И команда опять перешла к физическим стикерам.
Через некоторое время, когда продукт вырос и был интегрирован в продуктовый ландшафт компании, понадобился возврат к системе управления задачами. Например, баг, который отловила служба поддержки, или какой-то из других продуктов должен быть доставлен до ответственного за исправление, или нужно показать зависимость задачи с задачами из других систем и продуктов. В команде началась повторная джира-фикация.
Условно документацию, участвующую в разработке ПО, можно разделить на три группы:
1. Проектная – создается до запуска разработки для описания образа результата.
2. Техническая – создается в процессе разработки для осуществления и повышения ее эффективности. Используется разработчиками продукта и другими разработчиками и участниками. Можно выделить нормативную техническую документацию, которая создается для получения сертификатов соответствия, аудита и прочего.
3. Пользовательская – создается для внешних потребителей. Сюда входит руководство для конечных пользователей, b2b-интеграторов, вендоров и других. В пользовательской документации также можно выделить нормативную часть, например описание того, как будут обрабатываться персональные данные в случае их сбора.
Из всех перечисленных типов лишь пользовательская документация является финальным артефактом и частью пользовательского опыта. В связи с этим объем и качество проработки целиком определяется ценностью для конечного пользователя. Развитие пользовательской документации можно сравнить с развитием функциональности продукта. В каждом конкретном случае владелец продукта принимает решение о том, даст ли доработка дополнительную ценность и как это соотносится с расходами на доработку.
Проектная и техническая документация – артефакты промежуточные, и в этом случае, исходя из бережливого подхода, нужно уменьшать количество таких артефактов и сокращать расходы, связанные с их производством, для того чтобы быстрее и в большем объеме дать дополнительную ценность для пользователя – работающее ПО.
Далее приведены различные способы сокращения разных типов документации.
1. Сокращение горизонта планирования, покрытого документацией. Как уже говорилось ранее, чем больше срок планирования, тем больше вероятность, что часть планов будет не реализована. От 20 до 40 % годичных стратегических планов теряют актуальность, например, в связи с изменением технологического, бизнес- или регулярного ландшафта. Еще 20–30 % не реализуется по причине ошибок прогнозирования и культа амбициозности. Следовательно, чем меньше горизонт планирования, тем меньше вероятности сделать лишнюю работу.
2. Применение дорожной карты. Если есть необходимость описать долгосрочное видение, то можно использовать дорожную карту – высокоуровневое описание этапов без жесткой привязки к конкретным датам. Важно, что дорожная карта может актуализироваться периодически, исходя из текущей ситуации. Это дает возможность сфокусироваться на ближайшем этапе разработки и детально его описывать в случае необходимости.
3. Использование формата пользовательских историй при описании функциональных требований. Формат пользовательских историй (можно услышать юзерстори) позволяет описывать функциональность системы от лица пользователя. Это дает возможность бизнес-заказчику фокусироваться на финальном артефакте и оставлять промежуточные на усмотрение команды разработки. Формат отвечает на вопрос «что нужно сделать» и позволяет ответить на вопрос «как это сделать» разработчикам, выбирая при этом оптимальные способы и инструменты. (Подробнее о формате пользовательской истории см. в п. 3.2.4.1.)
Сокращение объема технической документации
1. Автоматически генерируемая документация. Нужно отдавать предпочтение решениям, которые позволяют генерировать документацию автоматически на основе структур кода. Например, фреймворк разработки[28] типа FastAPI позволяет из коробки автоматически генерировать документацию для интеграции потребителями сервиса. С появлением больших языковых моделей[29] набирает популярность генерация документации на основе ИИ. Например, GitHub Copilot экономит время разработчиков на описание кода, отправляемого в репозиторий.
2. Pull-документация. Тут применяется принцип втягивания вместо вталкивания. Часто бывает, что документация пишется про запас, и, если сделать замеры, можно увидеть, что часть документов генерируется впустую. Принцип вытягивания подразумевает, что документация генерируется по запросу. При этом современная документация – это не обязательно текст. Более эффективно и наглядно по времени может быть записать скринкаст[30] с объяснением голосом. Потом такое видео добавляется в базу знаний и отправляется по запросу. Подход втягивания имеет еще и культурно-оздоравлива-ющий эффект – разработчики начинают больше общаться и помогать новичкам вливаться, что отличается от культуры выталкивания, в которой новичка могут отправить штудировать обширную базу документов о продукте. Разумеется, принцип pull-документации нельзя использовать повсеместно, например для нормативной документации, создаваемой по требованиям стандартов. Но само движение в сторону перевода генерации артефактов от выталкивания к втягиванию позволит значительно оптимизировать процесс и сделать деятельность сотрудников более содержательной и осмысленной.
«Давайте сначала все по договору закроем, а потом начнем вносить правки», – именно так я отвечал клиенту, управляя небольшой компанией заказной разработки. Планы разработки шли тогда 3 4 квартала и уже на 1-2-м квартале накапливалось смещение сроков, и изменения в процессе – даже очевидные и существенные – были подобны смерти.
Тяжелое и деморализующее действие на всех участников процесса оказывает понимание в середине пути, что мы идем не туда. Заказчики теряют деньги и упускают возможности рынка, разработчики бесцельно проживают свои годы, занимаясь бесславным трудом.
Уже тогда ко мне пришло понимание, что нужно дробить большие проекты на фазы, каждый раз открывая какую-то часть функциональности на пользователей. Бюджетировались фазы отдельно, а значит, в процессе их можно поменять местами или вообще заменить.