SCRUM: Советы по выживанию для разработчиков
Попав на новое место работы, я столкнулся с методологией, которая мне не нравится, но с которой приходится жить, и это заставило меня внести некоторые изменения в комфортный для меня режим работы. Поскольку я уверен, что многие сталкивались с данной проблемой, далее я дам несколько советов и опишу, что я понял, что мне пришлось поменять и что я пыт…
Сотрудник продуктовой НЕ геймдев компании исповедующей скрам в треде.
Не буду утверждать что скрам в чистом виде спасение от всего или что я хоть являюсь каким-то экспертом по скраму, но прочитал пост и появилось желание прокомментировать:)
1.Давайте пессимистичные эстимейты
В этом пункте мне показалось речь идет о том будто тебе как разработчику дают задачу и ты ее как-то в одного оцениваешь. Кажется с точки зрения скрама так не должно быть. QA так же участвует в оценке задачи. Более того, для этого скрам придумал сторипоинты, чтобы задачи оценивались не с точки зрения затраченного времени а с точки зрения сложности (хотя лично я не верю в сторипоинты)
2.До последнего не говорите про существование быстрого, но плохого решения
В этом пункте хочу прокомментировать вот это
Практически всегда Бизнес выберет быстрое решение. Ибо единственное, что волнует Бизнес, – это прибыль проекта. Качественно или некачественно - это уже дело десятое.
Я думаю что если ваш бизнес так поступает, и не понимает что если все время делать быстрые решения рано или поздно процесс встанет из-за невозможности вносить изменения в проект, значит с бизнесом что-то не так, или разработкой до бизнеса не донесены риски. В моей практике бизнес понимал когда какое решение нужно.
3. Инициатива наказуема
Я бы назвал этот пункт "бизнес не любит неопределенность". Да, если разработчик взял задачу, в которой была оговорена и оценена одна работа, а начал молча делать что-то еще, это добавляет неопределенности бизнесу, а бизнес это не любит. Если в вашей команде работает правило
потом = никогда
Я бы сказал что это упущение тимлида.
4. Продавайте свои идеи
Это работает просто - если бизнес не дает время на разребание техдолга, в следующий раз когда к вам придут с вопросом "почему задача заняла больше времени чем планировалось", киваете на отказ в работе над техдолгом.
5. Не закапывайтесь
Тут согласен
6. Не закапывайтесь 2
Вот на этом пункте
менеджмент реагировал негативно, если вы говорите, что чего-то не знаете или нужно спросить, начинались вопросы в духе, а что ты сам в себе не уверен??
В принципе можно советовать менять работу, в таком месте делать нечего.
7. Снимайте лапшу с ушей
Я предпочитаю немного другую точку зрения в этом пункте. Сначала вы душой болеете за проект и всячески это показываете, а потом это отличный повод попросить прибавку. Дают - прекрасно, не дают - у вас отличная история чтобы продать вас на собеседовании.
Большое спасибо за подробный комментарий.
Могу сказать, что Ваш скрам работает явно лучше нашего. И, на самом деле, очень жаль, что так происходит не всегда.
По поводу эстимейта: у нас создаются сабтаски, клиентщик создаёт свою, тестер свою, серверист свою... по сумме времени получается эстимейт на всю сторю. И, получается, предоставив слишком оптимистичный эстимейт на свою саб таску, можно подставить тестировщика. Также и серверист может подставить клиентщика и тд.
Что касается бизнеса и технического долга. У нас на проекте просто есть кор-команда, которая отвечает за разгребание технического долга и очень много сторей и идей сбрасывается им и откладывается в долгий ящик. Тем не менее, менеджмент пытается решать данную проблему, однако на данный момент всё равно приходится продавать технический долг.
По поводу лапши - тут скорее мой эмоциональный отклик на ситуацию. Слишком много пришлось пройти кранчей и овертаймов, постоянно слыша что-то вроде мы же команда от людей, которые не кранчат, этим я и хочу сказать другим людям, что в стоит думать о себе в первую очередь, потом стоит думать о своей команде(команда это где-то 10 человек в моём случае, вы все в одной лодке) и потом, гораздо позже, уже на благо проекта и прибыли компании.