«Если бизнес применяет гибкие методологии избирательно, это экономит и деньги, и время»

Как работает Agile

— Алексей, Дмитрий, вы оба — эксперты по гибким методологиям. Почему в своё время Agile-философия стала так популярна? На какой сформированный запрос она отозвалась?

Алексей: Одна из ключевых ценностей, за которую любят Agile, это вовлечение. В классическом подходе задания идут одно за другим, к ним нельзя вернуться и изменить решения. Ты получаешь ТЗ, сдаёшь и забываешь. И совсем другое в Agile: для начала работы не нужно ТЗ, вместо него — список задач для всей команды. Ты можешь предлагать идеи и влиять на результат.

Слава богу, уже прошло время фанатизма, когда все думая и не думая использовали гибкие подходы. Бум закончился недавно, хотя статья «Каждому проекту — своя методология» советовала избирательно подходить к выбору методик ещё в 1999 году, за два года до написания Agile-манифеста.

— Когда гибкие методологии лучше не внедрять?

Алексей: Agile не подойдёт для систем, критичных к ошибкам. Нельзя разрабатывать ПО для атомной электростанции по Agile: непонятны риски — долбанёт или нет. Или применять методологию в финансовых институтах: если не перепроверить всё тысячу раз, их хакнут, а деньги заберут. Там Agile можно использовать разве что на совсем небольших участках процесса.

Дмитрий: Я вынужден не согласиться с Лёшей. Путь проверки гипотез на опасных вещах вроде атомной электростанции и вправду кажется странным. Но я точно знаю команды из атомной промышленности и финтеха, которые сначала тестируют гипотезы и только потом пускают их в работу.

С областью финтеха я недавно столкнулся лично. Раньше банки казались мне башнями из слоновой кости, в которых сидят мудрецы и строят совершенно безумные вещи. Но оказалось, что у них очень много деятельности по «обёртке» своих услуг. Те же мобильные приложения, веб-интерфейсы и формы отчётности. На таком уровне краткосрочного планирования Agile вступает в силу и хорошо справляется. Конечно, есть компоненты вроде PCI DSS, которые лишний раз лучше не трогать, чтобы не сломать, но такого мало.

— А при каких условиях гибкие методологии начинают работать «на полную катушку»?

Алексей: Команда начинает реально драйвить, когда поднимается над конкретной задачей и думает о ценности продукта: что улучшить, что замерить и что внедрить. Каждый участник команды должен видеть, что именно он может повлиять на результат.

А то есть анекдот, суть такова: один человек поднял 50 килограмм, а с напарником — целых 80. Так и в жизни: в командной работе не все готовы выкладываться на 100%. Мышление должно быть иным: мы — банда, которая может всё. «Мы вместе работаем и генерируем идеи» — это ведь офигенная мотивация! Преподнося гибкие методологии именно так, бизнес точно сэкономит немного в деньгах и времени и очень много в контроле за сотрудниками.

— Как бизнесу уже на промежуточных этапах понять, работает гибкая методология или нет?

Дмитрий: В Agile — полная прозрачность и открытость. Например, бизнес просит сделать за две недели чат-помощник на сайте. Тогда создаётся спринт с бизнес-целями, выполнение которых можно отследить на любом этапе. Бизнес наблюдает за процессом и через две недели видит, есть чатик или нет. Scrum-подход в этом плане доступно показывает, на что уходят центнеры денег, и именно этим он так нравится бизнесу.

Scrum, Kanban, сервисы и практики внутри них

— В процессе разработки многие также используют метод Kanban. Если вкратце: в чём основная разница между Scrum и Kanban?

Дмитрий: Kanban — история про техническую поддержку и эксплуатацию, а Scrum — про развитие.

Алексей: Да, если по-простому: Scrum — это итерационный подход к работе, в котором итерация называется спринтом. Набирается определённый объём задач под цели спринта, и в конце итерации эти задачи должны быть реализованы. Причём в Scrum запланированный спринт неприкосновенен как священная корова.

А Kanban-метод — это система непрерывного потока. Чтобы эффективно управлять задачами, мы ориентируемся по предыдущей статистике и ситуации. В Kanban-методе постоянное перестроение задач — это норма.

Люди зачастую путают эти методы, потому что и там, и там используются kanban-доски. Слово Kanban вообще пришло из производства Toyota и как раз обозначает доску, по которой перемещаются карточки с заданиями.

Говоря о прикладном применении методов: в процессе саппорта нет времени планировать задачи, поэтому там чаще используют kanban-системы. А когда бизнес хочет предсказуемый результат в определённый срок — можно уже внедрять Scrum.

— Какие сервисы помогают тимлиду следить за выполнением задач и их сроками?

Алексей: Ух, предугадываю холивар :)

Как известно, есть три вида лжи: ложь, наглая ложь и статистика… Но всё же: по официальным данным, 83% из 500 компаний из списка Fortune 500 используют Jira. Так повелось, что именно Jira — отраслевой стандарт в большинстве корпораций. Этот таск-менеджер имеет свою экосистему, быстро развивается и помогает командам, применяющим CI/CD.

Редко сталкивался с тем, чтобы использовали Trello. Несколько раз попадал на компании, которые занимаются заказной разработкой, — у них установлен бесплатный таск-трекер Redmine, чтобы не платить за другие лицензии. Я говорю: как так, идёт третье тысячелетие, а вы?.. Оказалось, что у них вся работа осуществляется в таск-трекерах заказчиков, а в чём трекать свои внутренние задачки — без разницы.

Дмитрий: У меня наиболее интересным и эффективным получается фит трёх систем: «тикетницы» Jira, системы управления кодом (GitLab, GitHub, Bitbucket) и тайм-трекера (я люблю Toggl).

Если сотрудники честно отписываются в тикетах Jira, аккуратно коммитят по стандартам в GitLab и всё это коррелирует с тайм-трекером, бизнес в каждый момент времени видит, кто и чем занимается. Это снимает массу вопросов.

— Что вы думаете о scrum-практике planning poker? В каких случаях она полезна?

Алексей: Этот способ планирования помогает закрыть риски, если задача очень большая.

Расскажу, как planning poker работает: в приложении или на руках у участников есть карты с цифрами. Озвучивается задача, каждый сотрудник оценивает её сложность и выбирает соответствующую цифру (в часах, днях или сторипоинтах), потом все вскрывают карты и при обсуждении цифр, отличающихся от большинства, приходят к оптимальному времени на её выполнение.

Цифры на карточках приближены к ряду Фибоначчи: каждое следующее условно в два раза больше и «тяжелее» предыдущего.

— Почему ряд Фибоначчи?

Алексей: Много непредсказуемого. Чем меньше мы знаем о задаче — тем больше риск, что время на её выполнение возрастёт и мы его не угадаем. Я легко могу оценить простую работу: за сколько я налью себе стакан воды. Но если попросят налить тысячу стаканов воды? Тогда уже нельзя просто умножить оценку времени на 1000, ведь мне придётся отдыхать, а ещё искать где-то кулер, так как одного кулера явно не хватит.

Ещё в planning poker важно, что решение других людей никак не влияет на наше. Если один скажет, что сделает задачу за день, второй подумает: «Не уверен, что хватит дня, но я что, неудачник какой-то? Тоже скажу, что управлюсь за сутки». Здесь же все выставляют оценки, ни на кого не оглядываясь, и потом видят разброс. Тот, кто поставил меньше всех, рассказывает, почему такой оптимист. Тот, кто поставил больше всех, — какие подводные камни видит. Затем идёт обсуждение и все оценки сводятся к средней.

После этого никто не скажет, что завалил задачу, потому что «время на неё выставил Вася». Все сотрудники согласились с оценками и приняли их в работу.

Как следить за эффективностью команды и беречь своё время

— Идеальная команда — какая она для вас?

Дмитрий: Мне нравится современное определение команды: это группа людей, зависящих друг от друга и желающих достичь уникальной цели.

Все, конечно же, мечтают собрать команду, общая эффективность которой будет больше, чем если бы эти люди работали по отдельности, но такая команда как любовь — все о ней говорят, но мало кто её видел (поэтому, когда адепты Agile рассказывают о подобных командах, обычно все скептически качают головой). По мотивам анекдота Лёши: если каждый поднимает по 50 килограмм, вместе они должны осилить 110!

Алексей: Я бы ещё добавил про совокупную стоимость: цена управления разрозненным количеством людей больше, чем цена управления единой командой.

Дмитрий: В общем, синергия команды должна создавать добавленную ценность.

— Вы рассказываете об этом на курсе «TeamLead»?

Дмитрий: Да, на курсе будет несколько уроков о разных типах команд.

Но не в каждой сфере деятельности есть agile-команды. Существуют централизованные команды, где все ходят по струночке, работают строго по регламентам и инструкциям. На курсе так и проговаривается: «Это наиболее характерно для армейских подразделений».

Я, кстати, люблю наблюдать за военными. Они выступают основным драйвером технологий и методов управления. К сожалению, там всё закрыто большими штампами и грифами секретности и про них мало что можно разнюхать.

— В последний год столкнулись две реальности: офлайн и онлайн. Как выстроить эффективный диалог с командой и там, и там? Какие есть отличия?

Дмитрий: На самом деле вся разница сводится только к способам коммуникации. Пандемия вскрыла, что удалённая команда может работать не хуже той, что сидит в офисе. Как ни странно.

Думаю, в будущем команды расслоятся: появится ядро, которое всегда будет в офисе, удалённая команда и кадровый резерв. Точно образуется институт менторов. Классический пример — это привлекаемый DBA. Окончательно сформируется институт стажёров. Сегодня они бьются даже не за работу с айтишной зарплатой, а за строчку в резюме.

— А как следить за эффективностью команды на удалёнке?

Дмитрий: Я большую часть жизни проработал с распределёнными и удалёнными командами. Использовал Zoom, Google Meet, Skype — выходило хорошо, но очень не хватало короткой и живой коммуникации. В итоге приспособил для этого Discord. Он работает как рация: ты создаёшь сервер, ставишь комнаты в ряд, «рассаживаешь» членов команды в эти комнаты, как за столы. Если тебе нужно поговорить с человеком, ты просто по нему кликаешь, и вот вы уже на связи. В Discord есть и текстовая связь: она работает как обычный мессенджер.

— Получается, в Agile у любого сотрудника помимо основной работы есть также несколько фоновых задач: отчитываться на рабочих встречах, присутствовать на постоянных созвонах. Это не муторно?

Дмитрий: Это и правда бывает непросто. Новичкам кажется пустой тратой времени каждый день приходить на стендапы и давать ответы на три классических вопроса:

— Чем ты занимался вчера?

— Чем ты планируешь заниматься сегодня?

— Какие возникли проблемы?

Я обычно объясняю всем так: это всего лишь 15 минут. Ежедневные стендапы нужны не только для контроля и отчётности, но и для синхронизации команды, понимания общего контекста. Этого объяснения хватает, и через 1-2 спринта вовлекается любая команда. Окончательно люди убеждаются, когда на демонстрации проекта заказчик остаётся доволен результатом, — это всех удивительно мотивирует.

— Сопутствующих задач много не только у сотрудников, но и у самих тимлидов. Как посоветуете сберегать личное время?

Алексей: Самая первая практика — это окна для определённых действий. Я даже не знаю, что лучше можно придумать. Например: «коллеги, смотрите, если вы хотите встречаться со мной планово, давайте делать это по вторникам и четвергам. Я готов в любое время, ставьте мне встречи. В понедельник, среду и пятницу я могу, только если что-то горит».

Точно так же советую выделять окна для проверки почты: 30 минут с утра перед работой, 30 минут перед обедом и 30 минут перед уходом. Ответ в течение дня — нормальная корпоративная политика, а для горящих вопросов есть телефон.

Дмитрий: Я использую удобный сервис Calendly. Он синхронизируется с пачкой Google-календарей. Человек заходит по ссылке, видит, когда у меня есть свободное окно, — и в один клик создаёт будущую трансляцию. Там же я веду запись людей ко мне на менторство.

Алексей: Я тут анекдот вспомнил про правило трёх папок. Когда поступает фоновая несрочная задача, а у тебя нет времени — просто положи её в воображаемый конверт №1. Если к тебе обратятся вновь по тому же вопросу — переложи в конверт №2 и всё так же ничего не делай. И только после третьего запроса клади в конверт №3 и приступай к выполнению.

Мораль такая: срочное до тебя всё равно донесут. Не стоит всегда отвлекаться: велика вероятность, что проблема решится сама собой, внутри обсуждения или другими людьми. Это, конечно, вредный совет из разряда чёрной магии, но почему бы иногда его не использовать? Можно начать и с двух папок :)