- PVSM.RU - https://www.pvsm.ru -
Я тимлид и моя задача — обеспечить продуктивную работу команды. Это непросто, поскольку готового рецепта успеха не существует. Конечно, есть признанные методологии: Agile [1], Lean [2], Value Stream Mapping [3]. Они дают общие ориентиры и ценности, что уже неплохо, но это лишь ориентиры. А с конкретными решениями, будь добр, вертись сам. На то ты и тимлид.
В статье я расскажу, как мы с командой постепенно сформировали и теперь регулярно уточняем подход к эффективной работе. Ключевой момент в том, что выбранные инструменты действительно приняты всей командой и прижились в работе. Это даёт надежду на то, что подход полезный.
В True Engineering мы занимаемся enterprise-разработкой. Делаем огромный, многолетний продукт, в котором участвует множество команд. Конкретно наша команда — это семь человек: четыре разработчика, один тим-тех-лид (пишет код и много), один QA, один PM. Продукту, над которым работает команда, два года. Техническое состояние — усилиями всей команды — близко к образцовому.
Для поиска и осознания проблем в команде мы используем довольно простой инструмент — дискомфорт участников.
Речь, конечно, не про ситуации, когда одному человеку кондиционер дует, а другому жарко. Я говорю о сбоях в нормальном потоке работы.
Например, релиз прошёл криво, хотя каждый по отдельности выполнил свою работу хорошо. Или стабилизация идёт уже две недели и команда надрывается, хотя мы сами делали оценки и нам никто не мешал сделать хорошо. Или бизнес получил не то, что ожидал.
Описанный алгоритм несложный, но и конкретики маловато. Далее я опишу принципы, выведённые нами с использованием такого подхода. Чтобы статья не превратилась в мемуары, я буду описывать только полученный результат, а не всю историю от осознания боли до её устранения.
На обратной связи построено всё взаимодействие человека с внешним миром, без неё невозможно проверить корректность выполненного действия. Представьте, какой была бы наша жизнь, не чувствуй мы боли, прыгая с четырёхметровой высоты или хватая раскалённый чайник.
В разработке примером хорошей, короткой петли обратной связи может служить code completion — он сообщает нам о правильности действия прямо в момент набора кода.
Теперь пример отсутствия петли обратной связи: мы знаем о проблеме у пользователей, но не можем её воспроизвести, у нас нет логов, нет возможности быстро выкатить исправление и мы вообще не знаем, какая версия сейчас на проде. Врагу не пожелаешь.
Каждое действие в процессе разработки может и должно давать обратную связь: build, lint, прошедшие автотесты, проведённое тестирование, тестовая сессия с бизнесом, успешный deploy, мониторинг prod— всё это способы обнаружить ошибки и скорректировать свои дальнейшие действия.
Также стоит заметить, что стоимость ошибки растёт по мере продвижения вперёд. Если мы выпустили на production баг, который портит данные, то задача не только его исправить, но и восстановить данные (если это вообще возможно). Стоимость позднего устранения подобной ошибки очень высока, не говоря уже о последствиях для бизнеса.
Поэтому наличие большого количества быстрых и информативных петель обратной связи жизненно необходимо.
Ниже те петли, которые мы сознательно поддерживаем и при возможности укорачиваем. Полагаю, большинство вам известны. Но они у вас действительно есть и работают?
В общем, обратная связь должна сама лезть на глаза. Как, например, сломанный билд.
Что примечательно, иногда для радикального улучшения достаточно совсем небольшого изменения.
Например, вы пишете логи в ELK [6]. Они структурируются, анализируются, общедоступны — всё хорошо. Но часто ли разработчик заглядывает туда при отладке? Скорее всего, нет.
Если сообщения уровня warning и выше выводить прямо в IDE, то появляется шанс заметить, например, просевшее время выполнения запросов. Даже если это не связано с текущей задачей. Появляется шанс заметить проблему раньше, и стоимость её устранения будет ниже.
Артефакты должны быть именно общедоступные. И полезные.
Благодаря этому принципу мы минимизируем bus factor [7], обеспечиваем единое понимание ситуации, работаем (и факапим) осознанно, постоянно делая выводы.
Некоторые практики очевидны и общеприняты: информативные сообщения коммитов, связь коммитов с задачами, описание How To Test, Definition of Done.
Есть и менее очевидные моменты:
Важность работы в потоке [8] и последствия от прерывания [9], полагаю, уже общеизвестны. Поэтому не буду подробно останавливаться на проблеме, а сразу перейду к нашим практикам.
Потому что многозадачность не работает [10]. Она лишь выматывает, распыляет внимание и откладывает получение результата.
Какие практики помогают:
Это не наше ноу-хау, а один из базовых принципов бережливого производства [12].
Принятое и реализованное решение ограничивает возможность дальнейших изменений. И если решение принято в условиях неполной информации (а это почти всегда так), то шансы принять неверное решение существенно выше.
Если непринятие решения не блокирует работу и не ведёт к экспоненциальному росту технического долга, его стоит отложить, оставив систему готовой к любому решению в будущем, когда у нас появится больше информации.
Это основа разработки — мы не строим «большие» архитектуры перед началом проекта. Взамен мы делаем безопасным процесс рефакторинга (смотри раздел про петли обратной связи) и превращаем его в естественную часть процесса.
Аналогично, мы не пытаемся угадать будущие требования к системе или построить универсальное решение. Возможность безопасно рефакторить более универсальна, поскольку даёт возможность внести любые изменения в будущем.
Разумеется, это состояние недостижимо в абсолюте, система будет периодически ломаться после внесения изменений. Но это не значит, что к этой характеристике не нужно стремиться.
Когда поломка — это нештатная ситуация, а не норма жизни, то её причины легко найти. Обычно это последний коммит. Следовательно, понятен ответственный, понятны действия по устранению, понятно, когда мы вернёмся в стабильное состояние.
Получаемая уверенность в работе системы даёт ценную возможность сделать релиз в любой момент времени.
Вторая ценность — мы более уверенно даём обещания о сроках готовности. Если делить работу на две фазы: «разработка» и «стабилизация», то конкретное обещание дать трудно, поскольку «стабилизация» это работа с проблемами, которых мы ещё не знаем. Значит, не можем точно их оценить.
Если же стабилизация идёт неразрывно с разработкой и для этого есть все необходимые инструменты, то ситуация более предсказуема.
Как мы поддерживаем постоянную работоспособность:
Что означает «команда»:
Чтобы максимально эффективно и сосредоточенно делать текущую работу, мы устраняем «долги», связанные с уже сделанной работой:
Последний пункт стоит отдельного пояснения.
«Ползучими» я называю задачи с изначально небольшими трудозатратами, но висящие в In Progress по несколько дней или недель.
Почему так может быть:
Соблюдать этот пункт трудно. Прежде всего, «ползучесть» нужно осознать. Затем нужно принять волевое решение и сделать шаг назад, к детализации. Это трудно сделать разработчику, поскольку время уже потрачено. И конечно, такое решение встретит сопротивление бизнеса. Но практика показывает, что это снижает шансы выдать результат, которому не будут рады ни команда, ни бизнес, ни пользователи.
В поиске подобных задач помогает график cycle time. Он показывает время от момента взятия в работу до завершения. Если задача «выбивается из толпы», то это кандидат для пристального изучения.
К сожалению, у меня нет готового рецепта «как надо». Эффективность команды — это эвристическая задача, а значит, она не имеет гарантированных способов решения.
Но некоторый чек-лист всё же есть. Вот он:
В заключение давайте обсудим слабые стороны подхода.
Прежде всего, такой подход работает на поиск локальных оптимизаций, с ним не построить стратегию развития продукта и всей компании. Конечно, осознание проблем лучше, чем бессознательно херачить и гореть на работе, но это лишь первый шажок.
Также прошу вас, не берите готовый список принципов, возьмите инструмент, которым он создан. Вот почему:
Наш список неполон. В нём только то, что мы уже внедрили в повседневную работу.
В команде не приживутся принципы, важность которых она не осознала сама, через боль от их отсутствия. Вместо рабочих идей вы получите жупел, который какое-то время все будут носить по офису, а потом положат пылиться в угол.
Наш список специфичен. Например, если технический долг на проекте игнорировался пяток лет и сопоставим с госдолгом США, то получить пользу от принципа постоянного истребления техдолга будет очень непросто. Стоит честно признать: долг такого размера никогда не будет отдан. И сосредоточиться на решениях, которые действительно помогут сделать ситуацию лучше.
А как вы совершенствуете процесс? И какие принципы уже приняли в своей работе?
Автор: fshchudlo
Источник [16]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/agile/328775
Ссылки в тексте:
[1] Agile: https://habr.com/ru/company/edison/blog/313410/
[2] Lean: https://worksection.com/blog/lean.html
[3] Value Stream Mapping: https://worksection.com/blog/value-stream-mapping.html
[4] Пять почему: https://ru.wikipedia.org/wiki/%D0%9F%D1%8F%D1%82%D1%8C_%D0%BF%D0%BE%D1%87%D0%B5%D0%BC%D1%83
[5] Fail Fast: https://enterprisecraftsmanship.com/2015/09/15/fail-fast-principle/
[6] ELK: https://www.elastic.co/what-is/elk-stack
[7] bus factor: https://ru.wikipedia.org/wiki/%D0%A4%D0%B0%D0%BA%D1%82%D0%BE%D1%80_%D0%B0%D0%B2%D1%82%D0%BE%D0%B1%D1%83%D1%81%D0%B0
[8] в потоке: https://ru.wikipedia.org/wiki/%D0%9F%D0%BE%D1%82%D0%BE%D0%BA_(%D0%BF%D1%81%D0%B8%D1%85%D0%BE%D0%BB%D0%BE%D0%B3%D0%B8%D1%8F)
[9] последствия от прерывания: https://www.youtube.com/watch?v=uGlzWZyVrBk
[10] многозадачность не работает: https://www.litres.ru/teo-kompernolle/mozg-osvobozhdennyy-kak-predotvratit-peregruzki-i-ispolzovat-svoy-potencial-na-polnuu-mosch/
[11] Work In Progress: http://kanban.club/all/wip-limit2/
[12] один из базовых принципов бережливого производства: https://craigew.wordpress.com/2013/10/09/lean-software-development-principle-decide-as-late-as-possible/
[13] чистые, маленькие, pull request: https://testing.googleblog.com/2017/06/code-health-too-many-comments-on-your.html
[14] имеют благие намерения: https://lostechies.com/sharoncichelli/2015/07/10/trust-in-positive-intentions/
[15] SMART: https://ru.wikipedia.org/wiki/SMART
[16] Источник: https://habr.com/ru/post/465817/?utm_source=habrahabr&utm_medium=rss&utm_campaign=465817
Нажмите здесь для печати.