SCRUM: Советы по выживанию для разработчиков
Попав на новое место работы, я столкнулся с методологией, которая мне не нравится, но с которой приходится жить, и это заставило меня внести некоторые изменения в комфортный для меня режим работы. Поскольку я уверен, что многие сталкивались с данной проблемой, далее я дам несколько советов и опишу, что я понял, что мне пришлось поменять и что я пыт…
Все советы выше подходят при работе в больших корпоративных галерах, но в нормальных студиях некоторые из них скорее вредные нежели полезные.
Про лапшу на ушах. При ее черезчур усердном отбрасывании, вы так никуда не вырастите и будете дальше на аджайлы и скрамы ругаться. Если ты приходишь на работу просто выполнить свои обязанности, чтобы потом пойти домой, как только закончится рабочий день, то менеджмент это видит. Никто не задумается о досрочном увеличении зп или повышении в должности человека не заинтересованного в перформансе проекта.
Можно вообще в крайность вдаться и устроить испанскую забастовку все исполняя формально. Пришел сделал без вопросов как написано в тз и ушел домой. Какой смысл за чужих дядек додумывать, еслм за это не платят? Только с таким подходом тебе перестанут давать важные задачи. Станешь васяном за третьим столом от двери, на которого скидывают все обезьяньи таски, а возможно вообще в перспективе уволят.
Про писсимистичные эстимейты. Если лид не слепой, то видит что человек постоянно дает завышенные оценки сложности задач, и может сделать выводы не в пользу сотрудника. Если и закладывать время под риски, то только под реальные, просто так х2 время указывать не стоит.
Про инициативу. Когда вместо исполнения задачи ты сидишь и условно во всех соседних классах меняешь типы ссылок для улучшения инкапсуляции, или разносишь куски кода по разным методам чтобы красиво и читабильно было, то совершенно справедливо можешь получить по шапке, даже если ты реально сделал лучше чем было.
Есть такое понятие как ценность выполненной работы. У реализованной фичи она высокая. У отрефакторенного куска кода она будет высокой только если сильно повлияет на перформанс продукта, будь то ускорение будущих темпов разработки, или улучшение производительности. Если же выхлоп от дня труда не принес никакой добавочной стоимости проекту, зато код теперь читабильный (хотя необходимость разобраться в этом куске легаси ужаса возникала примерно раз в год),то это неэффективная трата времени, и не стоит обижаться на прилетающие со стороны менеджмента оскобления. Так делать не надо. Лучше всего спросить лида, доказать ему необходимость доработок, и если получено добро, то уже тогда приступать к работе. Это будет самым правильным и ценным проявлением инициативы.
Под пунктами "Не закапывайся" и "Продавай идею" полностью подписываюсь, и если пункт с продажей идеи разгребания тех долга работает, то возможно что и не такая уж и страшная у вас ситуация.
В принципе, если любую модель поведения и совет принимать за аксиому и впадать в крайность, ничего хорошего не выйдет.
"Про писсимистичные эстимейты." - Я в этом абзаце писал про необходимость нахождения баланса и по итогу выдаче адекватных сроков и что это приходит с опытом. Опять-таки больше про ситуации, в которые я попадаю, когда начинается простой сотрудников, потом другие сотрудники начинают в свои сроки не вкладываться, это тянет за собой другие команды, которые начинают быть заблокированными. Я не думаю, что Вы с таким не сталкивались и что тут надо дополнительно что-то объяснять.
"Если и закладывать время под риски, то только под реальные," - я только за)
"При ее черезчур усердном отбрасывании, вы так никуда не вырастите..." — в принципе я достаточно расту. Я думаю достаточно того, что меня волнует качество сделанной мной работы и моей команды и в целом качество программного продукта(да именно качество продукта для меня на первом месте, а не его прибыль, я думаю тут понятно, что я имею в виду). Мне кажется, что страсть выполнять свою работу хорошо это здорово и здраво и каждый специалист должен работать именно так. А что то до отбрасывания, я вижу слишком много людей, которые убиваются непонятно ради чего. Все так делают. Как я писал момент спорный, но не стоит перегибать палку и работать в ущерб своей жизни, если на Вас давят и просят притопить за компанию. Как я уже писал выше, слишком много кранчей было пройдено под таким девизом.
"Лучше всего спросить лида, доказать ему необходимость доработок," - В принципе я про это тоже писал и конкретно описывал, как именно сторонние изменения влияют на рабочий процесс. Видимо я дал слишком агрессивное название данному пункту, что все на него реагируют. Ну я и подразумевал не улучшение в духе что-то порефакторить для читаемости(хотя как по мне читаемость это важно и нужно писать код, держа в голове, что кто-то другой потом сюда придёт и понаделает ошибок, не разобравшись, что же вы тут такое нагородили), а реально улучшение, простой пример — исправленный баг. Даже такое исправление, хоть оно может быть и ценным, но сделанное без согласования его стоимости, сроков выполнения и изменения скоупа тестирования, может повлечь за собой негативный выхлоп. О чём я и говорю в данном пункте.
" то возможно что и не такая уж и страшная у вас ситуация." — а я и не говорил, что она страшная. Думаю всё еще довольно неплохо. В целом тут больше речь о том, что делать, а чего не делать, перейдя с проектов с длинным циклом разработки(где тоже полно своих недостатков) на совсем иную специфику, где гораздо важнее быть более гибким и важно оценить свои поступки с точки зрения их ценности для бизнеса и для команды.