December 27, 2020

Итоги 3: Scrum

Продолжу суммировать навыки, полученные на предыдущей работе. За время работы там, я успела поучаствовать в двух больших проектах, что само по себе бесценно, но особенно интересным было то, что первый проект был организован очень плохо, а второй — очень хорошо, и это дало мне удивительную перспективу для их сравнения.

В обоих проектах использовалась модная ныне в IT система под названием «Scrum».  В этой системе основная идея состоит в том, что большое глобальное планирование не  подходит для больших программистских проектов, потому что часто к концу проекта выясняется, что заказчик хотел получить что-то совсем другое, не похожее на то, что было описано в написанном заранее техническом задании, но понимает это заказчик только в тот момент, когда видит уже готовую, созданную систему, в которой поздно чтобы то ни было менять.  В Скраме заказчику показывают сделанное каждый спринт (период времени, чаще всего равный двум неделям, за это время делается некоторая часть работы и должны случиться все необходимые рабочие совещания), и если заказчику видно, что что-то пошло не так, то это можно сообщить разработчикам тут же, и новые задачи могут быть тут же включены в следующий спринт.

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

Скрам отличается от множества подобных методов разработки довольно формализованной структурой. В нем есть несколько ролей, у которых есть приписанные им задачи, и заранее заданные регулярные совещания, которые должны случаться каждый спринт.  Роли включают в себя разработчиков, скрам-мастера, который отвечает за то, что вся эта система успешно функционирует, и владельца продукта, который отвечает за то, чтобы разрабатываемая система отвечала идеям заказчиков о том, что им нужно. Согласно методологии Скрам, эти две роли распределены между двумя разными членами команды, потому что работы в каждой из этих ролей получается довольно много. Совещания включают в себя: ежедневные встречи с апдейтами, планирование спринта, демонстрацию сделанного заказчику, ретроспективу — обсуждение того, что было хорошо, а что пошло не так, и совещание под названием груминг (grooming, мне нравится переводить его как «причесывание»), где происходит обсуждение сложности будущих задач. Последнее нужно, чтобы хорошо понимать, сколько задач можно поместить в один спринт.

На примере моих двух опытов, включавших наблюдения за семью разными командами, я очень хорошо увидела, что Скрам на самом деле очень сбалансированная система и очень хорошо продуманная система, и если из нее что-то извлечь, то сразу провисает в другом месте. Главная жалоба людей, которые начинают по этой методологии работать, состоит в том, что все эти совещания занимают очень много времени. Поэтому первая идея состоит в том, что давайте мы совсем ненужные и непонятные совещания уберем, чтобы было полегче. Первым кандидатом на вылет обычно становится тот самый груминг, который был последним в моем списке совещаний. Что случается, если убрать груминг? Разработчики перестают думать,  о том насколько задача сложна, а на самом деле даже опытному человеку легко вдруг не увидеть таящийся где-нибудь подводный камень, из-за которого задача, казавшаяся задачей на полдня, превращается в задачу на неделю. Если о сложности думали несколько человек, или даже, если одному человеку дали время на то, чтобы хорошо обдумать, что там может скрываться, шансы, что задача уйдет неправильно оцененной, сильно уменьшаются. Если же задачи не оцениваются по сложности, или их сложность оценивает только один человек, то очень часто случается, что в спринт попадает больше задач, чем в реальности можно за спринт сделать, и в результате нарушается очень важная цикличность: все что попало в спринт за спринт выполнено, и можно изменить курс в следующем спринте, если что-то пошло не так.

Другим частым кандидатом бывает ежедневный апдейт. Зачем нужен ежедневный апдейт? Он нужен, чтобы создавать у человека важность работы над проектом каждый день. Потому что завтра утром нужно будет рассказать, что ты сделал вчера. Что случается, если этого не делать? Очень часто у человека есть кроме проекта еще срочные задачи. Например, ответить на e-mail с вопросом начальника. Или знакомые и понятные задачи. А из срочного и важного, человек, как известно, склонен выбирать понятное. И в результате,  у человека, у которого много текучки, в какие-то дни могут руки не дойти до работы по проекту. Что в свою очередь увеличивает вероятность того, что таящийся в задаче подводный камень будет найден за день до того, как задачу нужно будет сдавать. Другой плюс ежедневного апдейта в том, что другие люди могут знать, как решается та проблема, которая не дает тебе двигаться дальше. Или, если стало понятно, что ты завяз в своей первой задаче и до второй назначенной тебе в этом спринте не доберешься,  то могут забрать твою вторую задачу, если у них есть дополнительное время.

Иногда люди пытаются избавиться от демонстрации продукта заказчику. Зачем это нужно? С одной стороны, это дисциплинирует, и помогает таки закончить задачи в спринте к этому сроку. С другой стороны, это шанс для заказчика поделиться своими сомнениями и опасениями. То есть, если мы не проводим эту встречу, то мы лишаем разработчиков и заказчиков возможности обсудить  сложности, возникшие с обеих сторон. Что случается, если мы это делаем? Мы рискуем попасть в ту самую ситуацию из начала, где конечный продукт не то, что в реальности нужно заказчику.

Еще один кандидат на выбывание, это ретроспектива — совещание, где обсуждают, что пошло не так. Обычно исключение этого совещания практикуется вместе с одной из практик, где задачи, не выполняются полностью за спринт. Если не обсуждать, что к этому приводит и что можно сделать, чтобы так больше не случалось, то это становится повсеместной эпидемией, и вскоре уже никто никогда не заканчивает все свои задачи за спринт.

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

Другой распространенный вариант экономии — это попытка сэкономить на ролях. Самое распространенное — зачем нам нужен скрам-мастер, мы сами можем разобраться. Или пусть у нас в компании будет один скрам-мастер, и пусть он работает со всеми командами. Обычно результатом этого является то, что люди, которые не практиковали раньше работающий Скрам, не знают, как применять все эти выданные им инструменты так, чтобы они приносили им пользу, и считают их ненужными, и у них нету человека, который бы им это объяснил, или у него нету времени на то, чтобы этим заниматься. В очень хорошо работающей команде скрам-мастер часто молчит, но до этого состояния еще надо добраться.

Другой вариант экономии — давайте обойдемся без владельца продукта. Тут бывают разные варианты.  Основная задача владельца продукта в Скраме — это создавать и правильным образом описывать задачи. Это значит, что у человека, выполняющего эту роль, должна быть довольно уникальная комбинация навыков: этот человек должен с одной стороны знать хорошо предметную область — то, для чего будущий программный продукт будет использоваться, а с другой быть настолько технически грамотным, чтобы понимать, как задачи для пользователей должны превращаться в технические задачи. Частый метод экономии тут — у этого отдела же есть менеджер, он прекрасно в этом разбирается, вот пусть он и назначает задачи. Самая главная сложность тут состоит в том, что у менеджера отдела обычно уже есть множество своих задач, поэтому хорошие формулировки, продуманность деталей задач, причесывание списков задач обычно спускаются в самый низ списка приоритетов менеджера. Тот самый, до которого никогда не доходят руки. Другая часть работы владельца продукта, состоит в том, чтобы постоянно быть на связи с разработчиками и отвечать на возникшие по ходу дела вопросы. И это тоже обычно то, что занятый менеджер не способен обеспечить. Другой вариант экономии на ролях — это согласиться с тем, что на эту роль нужен человек, но назначить на нее человека, для этой роли неподходящего или, а чаще даже и, не имеющего соответствующего тренинга. В этом случае псевдо-скрам-мастер может считать, что его задача назначить соответствующие совещания и всем разослать e-mail'ы, когда они будут. А псевдо-владелец-продукта будет создавать такие задачи, что на выполнение одной понадобится несколько месяцев работы, или такие, про которые вообще нельзя сказать, были они выполнены или нет.

Еще один способ обойтись без владельца продукта — это: а пусть разработчики пишут свои задачи сами, они же лучше всех знают, что нужно сделать. Этот подход предполагает тесную связь всех разработчиков с заказчиком, потому что каждый разработчик должен понимать, как выглядит система, с точки зрения заказчика. Если вдруг это не так, то риск состоит в том, что заказчик снова может получить не то, что он хотел. С другой стороны, этот подход предполагает, что разработчики были обучены, как правильно формулировать задачи, чтобы не создавать задачи, которые заведомо невозможно закончить в один спринт. Иначе мы снова попадаем в ситуацию, где задачи невозможно завершить за один спринт.

И наверно, хорошей метафорой всего этого является покупка автомобиля. Если вы решаете купить автомобиль, то обычно вам не приходит в голову сэкономить на руле, коробке передач, бензине или колесах. Или по крайней мере, если вы это делаете, то вас не удивляет тот факт, что машина не очень хорошо едет вперед. Мораль этой истории состоит в том, что если Скрам почему-то не работает как надо (выполнение задач не ускоряется, заказчики недовольны тем, что им сделали), то скорее всего что-то где-то не функционирует, неправильно состыковано или где-то не хватает нужной детали, и поэтому Скрам не едет.