Тихий убийца вашего agile
11 Янв 2019
Вот у вас есть аджайл-команды. Все идет хорошо: народ работает над важными инициативами, регулярно получает обратную связь, часто поставляет работающий продукт потребителю. Сколько времени пройдет до того, как все сломается?
Эй, эй, приятель, ты чего? Разве выше ты не описал идеальную работу по аджайл? С чего это все должно сломаться?
И тем не менее, ответ на поставленный вопрос будет таким: год-два. Чем больше времени потребуется на разработку продукта, тем больше неопределенности в сроке завершения. С течением времени мотивация команды и вовлечение снижаются, сотрудничество все труднее поддерживать, и сроки начинают удлиняться, что в свою очередь приводит к снижению мотивации. Образуется замкнутый круг.
Такое ухудшение происходит несмотря на короткие спринты, ограничение незавершенной работы (WIP-limits), нарезке требований на мелкие истории, визуализацию, проведение демо и достижение согласия команды — хлеб и масло популярных гибких методов. Эти методы описывают, как команда организует работу, чтобы двигаться вперед. Но они не затрагивают техническую гибкость: как команды должны выполнять техническую работу, чтобы сохранять при этом организационную гибкость.
Организационная гибкость
Владелец продукта набросал описание истории. Через пару недель на планировании спринта команда глянула историю, уточнила пару вопросов, оценила в стори-поинтах и взялась выполнить ее в этом спринте.
Во время спринта бэкенд и фронтенд разработчики начали кодить историю, пытаясь вспомнить, что о ней рассказывал владелец продукта (ведь формат истории не подразумевает подробного описания). Владелец продукта сильно занят, поэтому разработчики решились задать ему лишь пару самых критичных вопросов. Сидя на очередном скучном корпоративном совещании, владелец продукта дал короткие односложные ответы через корпоративный мессенджер. Разработчики поняли эти ответы каждый по-своему.
Двумя днями позднее тестировщик получает в работу инкремент продукта. Сам тестировщик не уверен, как должен правильно работать функционал. Но боится спросить разработчиков и владельца продукта, чтобы не выглядеть идиотом. Ведь историю обсуждали все вместе. Тестировщик создает авто-тесты на пару основных сценариев и на этом успокаивается.
На обзоре спринте все трое молча наблюдают за реакцией владельца продукта и ключевых пользователей. На этот раз повезло — владелец попросил внести лишь пару небольших изменений. Катастрофы не случилось, гора с плеч.
Через три недели в коде обнаружили ошибку. Один из разработчиков после двух часов поиска источника проблем исправляет строчку кода. Он решает не сообщать об этом тестировщику, ведь исправление было столь несущественным. Если сказать, так тот устроит полное пере-тестирование всей истории. Кто же знал, что это мелкое исправление сломает логику, и поломку смогут обнаружить лишь через месяц.
Чего не хватило
Девять из десятки аджайл-команд сталкиваются с описанным сценарием, и не знают, что с этим делать. Ошибки накапливаются, продукт менять страшно, мотивация снижается, отношения портятся.
Техническая гибкость означает снижение негативных последствий при внесении изменений в работающий продукт. Идея в том, чтобы сохранять низкую стоимость изменений как при создании продукта, так и при изменении его. Такие изменения включают:
- Добавление новых функций или изменение существующих;
- Исправление ошибок или неудачных технических решений;
- Изменение в интеграции продукта с другими решениями.
Ограниченность ресурсов. Обычная практика при изменении продукта — написать новую историю, обсудить ее, оценить, взять в работу. Сам по себе такой подход не создает проблем. Проблема в стоимости, которая рано или поздно убьет проект. Все было бы хорошо, если бы у вас были неограниченные ресурсы. Но обычно это не так. Обычно деньги заканчиваются, сроки поджимают, а продукта все еще нет. Ограниченность ресурсов мешает вносить бесконечные правочки в продукт.
Подключаем техническую гибкость
В разработке программного обеспечения быстро поняли, что гибкость здорово истощает бюджеты и растягивает сроки. В ответ индустрия породила набор технических практик: авто-тесты, непрерывную сборку, непрерывную поставку и т.п. Чуть сложнее порождается дисциплинированное поведение. А если мы говорим о разработке другого продукта, не из сферы ПО, то нужны свои уникальные инженерные практики — в каждой отрасли свои.
Какую бы отрасль мы не рассматривали техническая гибкость возможна при соблюдении следующих семи принципов:
- Эволюционный дизайн. Разрабатывайте продукт итеративно и инкрементально.
- Быстрая обратная связь. Проверяйте результаты работы быстро и часто.
- Малые безопасные шаги. Двигайтесь малыми шагами, чтобы быстро можно было вернуться обратно в случае ошибки.
- Упрощение. Достигайте результата самым простым способом.
- Чистая работа. Добивайтесь внутренней целостности и чистоты продукта, чтобы с ним легко работали другие разработчики.
- Продуктивность. Доводите до завершения работу, за которую беретесь. И не беритесь за работу, которую не сможете или не хотите доводить до финала.
- Коллективная ответственность. Отвечайте не только за свою часть работы, но и за весь продукт. Продукт — это ваша командная собственность.
Для лучшей технической гибкости в описанном выше сценарии команда должна создать юнит-тесты, рефакторить код и делать непрерывную сборку продукта. И это даст соблюдение лишь части принципов.
Еще команда должна дробить истории на более мелкие, обсуждать каждый кусочек и многократно убеждаться, что все члены команды верно понимают задачу.
Разработчики и тестировщики должны работать в тесном союзе, вместе придумывая тесты, проверяя работу друг друга, добиваясь взаимной уверенность в работе инкремента. Именно с такой уверенностью нужно выходить на обзор спринта. Тогда не придется скрещивать пальцы за спиной.
Начинаем прямо сейчас
Аджайл означает готовность менять продукт — быстро, экономично, изящно. Вы не сможете быть аджайл без технической гибкости. Мы все это проходили — уставшая команда, раздраженный владелец продукта, раздутые сроки и проеденные бюджеты.
Техническая гибкость означает взаимные ожидания. Владелец продукта и менеджмент ожидают гибкости при создании продукта. Но и команда ожидает, что владельцы ресурсов обеспечат необходимый инструментарий, который обеспечит техническую гибкость. Одно без другого, как мы убедились, не работает.
Проблемы возникают из-за нежелания вложиться в техническую гибкость сегодня, чтобы обеспечить реальную гибкость завтра. Слишком много новых функций хочет владелец продукта, слишком высокую скорость разработки хочет показать скрам-мастер для оправдания своего существования. Кто-то должен подумать о будущем, иначе оно само напомнит о себе довольно болезненным образом.
Вы выбрали Scrum, Kanban или любой другой гибкий фреймворк. Возможно, вы даже усвоили гибкое мышление. У вас будет все хорошо в ближайшей перспективе. Но чтобы все хорошо было и в будущем, подумайте о технической гибкости. Ваша святая троица: мышление, организационная гибкость, техническая гибкость.
Автор: Gil Broza
Перевел: Сергей Шарпак, директор управления консультационных услуг, PMI PMP
Источник: https://www.projectmanagement.com/articles/504123/The-Silent-Killer-in-Your-Agile-Implementation
Как получить международный сертификат по Agile
Для тех, кто хочет получить систематизированное понимание Agile, разобраться с преимуществами и недостатками гибкого подхода к проектам и продуктам, найти области наилучшего применения Agile и получить международный сертификат от консорциума ICAgile — наш тренинг ICAgile Certified Professional
Еще по теме