Out of Scope

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

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

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

Я удалил 90 процентов закладок из браузера, я удалил все приложения в телефоне, которые не использовались больше двух недель, те же изменения коснулись и планшета. Оставил только то, что касается текущих проектов. Но и этой информации мне кажется иногда много.

Но к чему я это веду, это же состояние Out of Scope постоянно случается во время разработки и избавится от него довольно тяжело, если его запустить, но даже в запущенном состоянии это реально.

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

Основные причины, которые приводят к выходу за рамки scope:

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

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

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

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

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

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

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