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. Проектная – создается до запуска разработки для описания образа результата.
2. Техническая – создается в процессе разработки для осуществления и повышения ее эффективности. Используется разработчиками продукта и другими разработчиками и участниками. Можно выделить нормативную техническую документацию, которая создается для получения сертификатов соответствия, аудита и прочего.
3. Пользовательская – создается для внешних потребителей. Сюда входит руководство для конечных пользователей, b2b-интеграторов, вендоров и других. В пользовательской документации также можно выделить нормативную часть, например описание того, как будут обрабатываться персональные данные в случае их сбора.
Из всех перечисленных типов лишь пользовательская документация является финальным артефактом и частью пользовательского опыта. В связи с этим объем и качество проработки целиком определяется ценностью для конечного пользователя. Развитие пользовательской документации можно сравнить с развитием функциональности продукта. В каждом конкретном случае владелец продукта принимает решение о том, даст ли доработка дополнительную ценность и как это соотносится с расходами на доработку.
Проектная и техническая документация – артефакты промежуточные, и в этом случае, исходя из бережливого подхода, нужно уменьшать количество таких артефактов и сокращать расходы, связанные с их производством, для того чтобы быстрее и в большем объеме дать дополнительную ценность для пользователя – работающее ПО.
Далее приведены различные способы сокращения разных типов документации.
1. Сокращение горизонта планирования, покрытого документацией. Как уже говорилось ранее, чем больше срок планирования, тем больше вероятность, что часть планов будет не реализована. От 20 до 40 % годичных стратегических планов теряют актуальность, например, в связи с изменением технологического, бизнес- или регулярного ландшафта. Еще 20–30 % не реализуется по причине ошибок прогнозирования и культа амбициозности. Следовательно, чем меньше горизонт планирования, тем меньше вероятности сделать лишнюю работу.
24
Kanban-доска – инструмент, использующийся в бережливом подходе для визуализации этапности прохождения артефактов. Подробнее в п. 3.1.3.6.
25
Daily standup meeting (сокр. DSM) – ежедневная короткая встреча для синхронизации статусов и планов, подробнее в п. 3.2.3.