SCRUM: Советы по выживанию для разработчиков

Доброго времени суток. Представлюсь, для тех, кто меня еще не знает. Меня зовут Дима. Я работаю C++ разработчиком уже более 5-ти лет. На данный момент работаю в крупной Gamedev-студии, предыдущее место работы: SK hynix memory solutions Eastern Europe. Помимо работы увлекаюсь созданием образовательного контента для YouTube и Twitch каналов.

Полгода назад сменил место работы и на текущий момент работаю в компании, специализирующейся на играх для мобильных устройств. В процессе работы столкнулся со следующей проблемой: SCRUM. Стоит заметить, что в данной ситуации, я основываюсь только на своём опыте. Речь пойдёт о скраме в продуктовой компании. О скраме, который работает не совсем так, как написано в книжках, зачастую это означает, что он не работает вообще, но существует и мешает.

Не буду вдаваться в подробное описание плюсов и минусов данной методологии на этапе вступления. Для полного понимания происходящего рекомендую ознакомиться со статьёй на Википедии(ссылку я прикрепил выше).

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

Планирование разработки и оценка сроков(эстимейшн) – важнейшая часть работы по скраму. Ведь вы планируете работу на ближайший спринт(см. статью на вики) и от того, как вы это сделаете, зависит то, насколько продуктивно и комфортно будете работать не только вы, но и люди, которые связаны с вашей работой. Самый простой пример – это связка Dev + QA. Вы должны что-то разработать и вашу работу надо протестировать. Если вы дадите слишком маленький эстимейт, то тестировщику в определённый день будет нечем себя занять. Получается, дав оптимистичный эстимейт и по той или иной причине в него не вложившись, вы подставляете другого сотрудника, да и на другие ваши задачи у вас остаётся меньше времени, что опять-таки влечёт за собой проср*нные дедлайны либо же овертаймы.

Как же найти баланс между слишком большим эстимейтом и оптимальным, учитывающим риски? Тут нет однозначного ответа. Данное умение приходит с опытом. Что могу сказать точно, если вам хочется сказать "Вроде изян, 4 часа", но вы по той или иной причине волнуетесь, то лучше скажите: "Вроде изян, но возможно есть подводные камни и лучше взять день/полтора/два и т.д".

Объявим две переменные в данном уравнении. Есть условный Бизнес – тот, кто придумывает задачи, выставляет сроки и так далее. И есть условный Разработчик – тот, кто эти задачи в поставленные сроки выполняет. Перед разработчиком ставят задачу и просят выставить сроки. Очень часто будет два варианта решения задачи: быстро и некачественно, качественно и долго. Практически всегда Бизнес выберет быстрое решение. Ибо единственное, что волнует Бизнес, – это прибыль проекта. Качественно или некачественно - это уже дело десятое.

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

Вы решаете задачу и видите, что её можно улучшить, однако это плохо повлияет на заявленные Вами сроки. В первую очередь обсудите это со своим тимлидом или скрам-мастером. Скорее всего, Вы получите отмашку в духе делай сейчас по-плохому, а потом переделаем(потом = никогда). Неприятно, но таковы реалии, для бизнеса не особо важна красота решения, как я уже писал выше.

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

Что же делать, если от вас хотят новых функций, а из-за проблем, описанных в предыдущих пунктах, технический долг сковывает Вас по рукам и ногам?
Нужно продавать разгребание технического долга. Это очень сложная задача, ибо надо объяснить бизнесу, что вот сейчас будет небольшой простой, что вам нужно поработать на перспективу, но зато потом прибыль потечёт рекой. Самое простое в этом – посмотреть на задачи из бэклога и предоставить их сроки выполнения, без процедуры разгребания технического долга и с ней. И в большинстве случаев, если сокращение сроков в перспективе будет перевешивать простой в данный момент, Вам пойдут навстречу.

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

Видите, что задача сложнее, чем казалось на этапе планирования – уведомьте об этом и согласуйте, а нужна ли она вообще?

Решил выделить в отдельный пункт. Это относится к любой сфере деятельность в принципе. Не стесняйтесь задавать вопросы, признавать, что вы чего-то не знаете и вообще обращаться за помощью к кому бы то ни было на проекте. Какой бы вы ни были крутой спец, на проекте найдётся человек, знающий в определённой области, модуле больше вашего. Ведь, возможно, кто-то уже делал подобную задачу, а вы еще нет. Признаюсь, несколько раз сталкивался с ситуациями, когда менеджмент реагировал негативно, если вы говорите, что чего-то не знаете или нужно спросить, начинались вопросы в духе, а что ты сам в себе не уверен?? В общем, старайтесь игнорировать подобные вопросы, в большинстве случаев это полный бред.

Довольно спорный пункт, но не могу о нём не сказать. Не думаю, что такое активно применяется в аутсорс-компаниях, но насчёт продуктовых я не сомневаюсь. Речь идёт об ангажировании сотрудников. Вам, как работнику, будут часто говорить, что вы часть команды, что вы часть проекта, и нужно потрудиться на благо компании. Не стоит забывать о том, что Вы в первую очередь работаете на себя: ради денег, ради опыта, ради строчки в резюме. Не стоит убиваться ради того, чтобы компании и проекту было хорошо. Особенно, если это никак не оплачивается и всё, что вы получите – это хлопки по плечу и плюсик на ретро.

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