2022-03-23 17:20:42
Сколько мне ни приходилось работать по SCRUM, всегда было ощущение, что эта методология отнимает слишком много времени у разработчиков. Главный плюс в более предсказуемом процессе разработки, что хорошо для бизнеса и, несомненно, является пользой для него.
Но чем больше я работаю по скраму, тем больше ко мне приходит понимание, что вред его не только в том, что он отнимает много времени у разработчиков, но и создаёт программистам благодатную почву для того, чтобы заниматься чем угодно кроме непосредственно разработки, иными словами, прокрастинировать.
Начну с самого начала, со стендапов (дейли митинги, дейлики). В айти принят гибкий график работы, начало рабочего дня у всех разное и время дейли выбирается с учётом этой особенности, т.е. чтобы вся команда к этому моменту уже точно начала работать. Не раз замечал, что когда устанавливается время утреннего стендапа, это время становится негласным началом рабочего дня для большинства.
То есть, если без стендапа все начинали работать с 9 до 11, то с дейли митингом, который становится утренним ритуалом, начало рабочего дня смещается ближе к стендапу. И почти на каждом дейлике обнаруживается, что кого-то дейлик застал в каких-то делах, не относящихся к работе. При этом конец рабочего дня, по ощущениям, остаётся таким, каким и был.
Однако у стендапов есть огромный плюс, который делает его скорее полезным инструментом: можно понять кто чем занимается, на лету решить какие-то небольшие проблемы, разобраться с блокерами. Особенно полезно, когда на созвоне все включают камеры и первые пять минут обсуждают что-то не связанное с работой, это способствует тимбилдингу.
С другой стороны, все мы в IT ценим результат, а не время, проведённое за работой. И именно с результатом в SCRUM начинаются настоящие сложности.
Когда я начинал зарабатывать деньги программированием, аджайл был не в ходу, программистов не было так много, команды не были такими большими. А самым простым и эффективным способом организации разработки были постановка конкретных задач, определение сроков исполнителем, который берёт задачу в работу и соблюдение этих сроков исполнителем. Это прекрасно работает сейчас на том же фрилансе и это прекрасно работало тогда во всём IT: если у тебя проблемы с оценкой сроков и/или сложности задачи, то сиди и доделывай по ночам. Потому что, если ты будешь ошибаться в сроках постоянно, тебя уволят. Если ты будешь постоянно называть слишком большие сроки, тебя уволят. Но если ты будешь в большинстве случаев соблюдать адекватные сроки, то тебя будут ценить и поднимать тебе зарплату, любой, кто с тобой работал, всегда скажет, что на тебя можно положиться.
Всё поменялось с приходом SCRUM: теперь, если ты проволынил задачи, то на ретроспективе можно всегда выбрать удобную причину: блокеры (бэкэндер сделал не так или не сделал, девопс настроил не так или не настроил, менеджер описал задачу не так), недостаток коммуникации, неправильная командная оценка, недостаточная документация, отсутствие какого-то инструмента и т.п. Про каждую из этих причин можно написать отдельную заметку, но настоящая причина, в большинстве случаев и по большому счёту, всегда одна: отсутствие персональной ответственности за задачу.
Да и даже если просто сказать «на этой неделе было плохое настроение», то в отчёт по ретроспективе так и запишут, никто не будет ругать. Недоделанную задачу перенесут в другой спринт, расчётную производительность команды (velocity) понизят. И будут понижать до тех пор, пока оценка задач на спринт не начнёт совпадать с затратами по факту. Я своими глазами видел фронтендера, которая в течение года писала в день в среднем 12 строк кода и ничего ей за это не было. Большинство программистов любят скрам, он позволяет доминировать слову life в work-life балансе.
1.6K views14:20
I
