Про смену контекста
Я вам сейчас расскажу одну простую, и даже очевидную штуку, о которой мы с вами почему-то всегда забываем. Смена контекста сильно увеличивает время выполнения задачи. Работает всегда и везде. Вот, например, в 2018м на мобильных разработчиках проводилось исследование - «The Cost of Context Switching». Засекали какая разница между тем, когда разраб берется за исправления бага через сутки после того, как сделал основную задачу, и между тем, когда он приступает к исправлению багов через неделю и больше. Догадываетесь какой результат?)
В среднем, разработчик исправляет баг в 2-3 раза быстрее, если он приступит к нему через сутки, а не через неделю. Почему? Да просто потому, что в первые сутки он еще помнит контекст кода и его логику, а спустя неделю ему нужно тратить время и силы, чтобы заново изучить свой же код, и вообще вспомнить что он там накодил.
И очень-очень часто мы про эту базовую истину забываем, особенно, при планировании спринтов или кварталов. И частенько планируем работу команды таким образом, чтобы разработчик никогда "не простаивал". Если у нас разработчик со своей задачей справился благополучно раньше времени и до конца спринта - нельзя, чтобы он сидел без дела, да? Пока его таска ждет тестирования, надо обязательно его загрузить новой задачей, чтобы он продолжал эффективно работать. Так то да, но получается, что пока тестировщики пыхтят над его кодом и заводят баги, наш разраб с каждым днем переключается в новый контекст другой задачи. И когда, спустя неделю, к нему придет пачка багов на исправление, он уже головой полностью в другом контексте. Теперь он будет тратить время на то, чтобы переключиться и вспомнить, что он там наговнокодил и как это исправлять. И времени на это переключение, как правило, тратится больше, чем экономится на разработке новой задачи.
По этой же причине не стоит откладывать минорные баги после большого релиза в долгий ящик. Если вы их в первые пару спринтов не исправите - то все, это мертвый груз в бэклоге навсегда. Их никто никогда не исправит 😁. Я поэтому удаляю из бэклога все, к чему никто больше 6 месяцев не прикасался. Представляете вообще, взяться за исправление бага, который завели полгода, а то и год назад? Это уже современные формы пыток какие-то )
Поэтому, кстати, все аджайлы и скрамы так задрочены на кросс-функциональные команды, one piece flow, wip лимиты и прочее. Чтобы пока вы задачу полностью не закончили - никто с ее контекста не переключался на что-то другое. Это только в моменте кажется, что вы оптимизируете таким образом работу команды, и может, даже, улучшаете ее, прости господи, утилизацию. На деле же, вы наоборот сильно замедляете пропускную способность команды на дистанции. В идеале, чтобы разработчик и тестировщик вообще в параллель работали. Завел баг - сразу отдал в фикс (разраб ждет) - пофиксил - следующий баг. И так, пока задача не станет готовой.
В общем, не мучайте ваших разрабов с переключением контекста, ничего хорошего в этом нет )