Меня зовут Илья Остреров

Написал много, интересно будет далеко не всем, но уж извиняйте. И да, нужно делать nanocut по-любому!
Прошло несколько недель, как мы решили работать в соответствии с идеологией agile. Scrum, нужно заметить, приживался у нас не просто. Во-первых, внутренние противники внедрения этой методологии. Споры о том, нужно это или нет, утверждение, что мы и сами умные и можем всё придумать своими головами, дай только волю. Во-вторых, количество проектов и количество людей, занятых не этих проектах. Когда один проект делает один человек, доводит его до некоего состояния завершенности и функционирования, а тут подтягивается еще три человека, которые начинают своими руками все трогать и крутить. По началу казалось, что переключение контекстов с одного проекта на другой, в головах разработчиков, будет происходить с трудом. В-третьих, контора отличается демократизмом. На мой вкус, даже излишним демократизмом. Отсюда проистекают чисто организационные проблемы, когда нам сложно бывает собраться в одно время в одном месте, что бы что-то обсудить или сделать. Дисциплина как в лагере у хиппи.
Уже завершилось несколько итераций разработки. Чуваки, это очень прикольно! Но обо всём постараюсь рассказать по-порядку.
Описывать саму методологию я не буду, все интересующиеся могут поискать информацию в сети. В двух словах расскажу, как это работает у нас. Имеется две команды: команда разработки и команда менеджеров. Команда разработки состоит из разработчиков серверной части и разработчика клиентской части (к сожалению, у нас это так, хотя в идеале хорошо иметь однородный состав, способный к взаимному замещению). Менеджеры подготавливают список пожеланий (Product Backlog) по каждому из проектов. Список может быть обширным и содержать описание желаемых фич и функций, которые необходимо реализовать в проекте. Команда разработки получает этот список на руки и начинается довольно непростая на первый взгляд процедура: оценка трудозатрат на каждый пункт бэклога. Грубо говоря, берется одна фича из списка, обсуждается способ её реализации в первом приближении. Естественно, находятся люди, которые делали что-то похожее или близкое, именно они и начинают рассказ о том, как нужно/можно всё делать. Особого углубления в детали не происходит, всё довольно поверхностно. Но по ходу обсуждения возникают дополнительные вопросы, которые обсуждаются с менеджером (Product Owner), появляются какие-то технические и функциональные уточнения, которые записываются, что бы не быть потерянными. Когда задача ясна и обсуждена команда оценивает срок её выполнения. Каждый участник сообщает, за сколько часов, по его мнению, можно сделать эту задачу. Если оценки расходятся, то обсуждение задачи продолжается, после чего сново происходит оценивание. У нас, как показывает опыт, переоценивать задачу приходится не больше 2-х раз. Как-то мы не особо упорствуем в отстаивание своих точек зрения в данном вопросе. Наверное, это не плохо...
Таким образом, обрабатывая каждую фичу из бэклога разработчики дают менеджерам представление о том, что и сколько времени займет. Забавно наблюдать, как удивляются манагеры, узнав, что реализация плёвой, на их взгляд, фичи занимает 8 и более часов. Менеджер, обладая такими данными, определяет в какой последовательности выполнять задачи, что необходимо сделать в ближайшую неделю (длина итерации у нас такая), а что можно отложить на потом.
Еще один интересный момент. Работать 8 часов над поставленной задачей получается далеко не всегда. Да ладно, кого я обманываю, практически никогда не получается. Во-первых, чисто человеческий фактор. Чуваки за соседним столом нашли смешной ролик на youtube. "В интернете кто-то не прав" и ты не можешь этого стерпеть, бросаясь во флуд с головой. Плечо ноет и все мысли только о том, чем бы его помазать или лучше сразу отрезать. Да мало ли что может быть! Во-вторых, работая над одной задачей тебя будут отвлекать с вопросами по другим задачам, тебя будут дергать просьбами что-то быстренько подправить или добавить, дать доступ к серверу, изменить какие-нить права, создать запись в базе и т.п.. Это тоже ни для кого не секрет, как мне кажется. Дергать будут не только коллеги, но и сам менеджер, который ждет выполнения одной задачи, но в тот же момент, не может ждать с какой-то другой задачей, более мелкой, но неотложной.
Поэтому, менеджер, считающий, что задачу на 5 часов можно сделать за один день и еще останется время на небольшую задачку на 3 часа - дурак. Такого не бывает! Ладно, бывает, но что бы каждый день так - фантастика и недостижимый идеал. В scrum это всё предусмотрено. Есть такое понятие, как focus factor (в простонародье fuckup factor). Это некий поправочный коэффициент, позволяющий заложить время на всяческий факапы и риски. ФФ равный 1 - идеальный работник, которому нужно выписать массажистку и давать молоко за вредность, потому что такой работник, чисто физически, долго не протянет. Я думаю, что ФФ равный 0,7 - это очень и очень хорошо. Просто замечательно (относительно web-разработки). Наш нынешний fuckup factor колеблется в районе 0,35 - 0,37. Это плохо и нужно расти! Честно говоря, я даже не думал, что у нас будет так мало...
Что же мы имеем в цифрах. Допустим, нас в команде 3 человека. Работаем мы 4 дня в неделю (один день у нас уходит на демонстрацию выполненной итерации и на планирование следующей) по 8 часов. ФФ берём равный 0,35. Сколько часов у нас есть с учетом всех этих факторов: 3 х 4 х 8 х 0,35 = 35 часов. Из бэклога менеджер может дать нам задач на 35 часов и быть уверенным, что мы их сделаем. Ужас, каждый раз пугаюсь таких маленьких чисел.
Когда все задачи сформулированы и определены, количество их ограничено нашими разработчискими возможностями, они формализуются и выписываются на бумажках. Бумажки крепятся на доску, которая имеет 4 вертикальные зоны (столика): свободные задачи; задачи в работе; задачи, готовые к тестированию; завершенные задачи. Постепенно, каждая задача должна продвинуться по доске слева на право. Из раздела свободных задач в раздел завершенных.
Хороший момент - тестирование. Когда ты сделал задачу, ты вешаешь ее в тестирование. Она там висит до тех пор, пока кто-нибудь не возьмёт её и не протестирует, убедившись, что всё работает так, как требуется. Естественно, это очень сильно повышает качество продукта.
Чуть выше я писал о некой демонстрации выполненной итерации. Необходимости этого момента я не понимаю. Каждая задача оформлена в виде отдельной карточки, которая висит на доске. В этой карточке имеется описание задачи, описание того, как проверить, что задача выполнена и прочая служебная информация (оценка трудозатрат, исполнитель и т.п.). Так вот почему бы продукт овнеру (ака менеджеру) самому не взять эту бумажку и не посмотреть, выполнена задача и насколько хорошо она выполнена? Наверное, есть какой-то глубинный смысл в том, что сами разработчики проводят демонстрацию, показывая, что они сделали и как это работает. Но мне просто жалко времени, которое на это уходит.
После демонстрации проводится ещё один митинг - ретроспектива. Это некое действо, происходящее внутри команды и направленное на то, что бы решить проблемы, возникшие в ходе работы. Проблемы эти могут быть как техническими (сервера падали, нужно подумать, как этого избежать в дальнейшем), так и организационные (менеджеры отвлекали задачами, не относящимися к итерации, как сократить такие обращения или выделить на них время). В ходе ретроспективы формулируются проблемы, придумываются пути их решения и контролируется выполнение принятых ранее решений. Грубо говоря, некий "разговор за жизнь" внутри компании. Вещь, безусловно, полезная, но у нас она происходит периодически в течении всей недели, а не только одни раз, в назначенное время.
Кроме всего этого, ежедневно, примерно в одно и тоже время, проводятся небольшие собрания команды (Daily Scrum Meeting). На них каждый разработчик рассказывает, что он сделал вчера, что он делает сегодня, какие проблемы у него возникли. Обычно, такие собрания проходят за 5-10 минут. Они позволяют быть в курсе событий, выявлять проблемы в самой ранней стадии их зарождения, оперативно реагировать на изменение каких-то факторов разработки. Полезная штука!
Промежуточные итоги. Стали ли мы работать быстрее? Не знаю, чисто субъективно - нет. Зато появилось больше понимания того, что делается, как делается, кем делается и почему так, а не иначе. Стали ли мы работать лучше (качественнее)? Да! Вот это бесспорно и очевидно. Если раньше некоторые вещи писались "что бы работало", то теперь подход меняется. Во-первых, всегда можно обратится за консультацией к коллегам, чтобы совместно придумать более красивое решение. Конечно, раньше тоже можно было общаться, но scrum как-то стимулирует и всячески поощряет такие коммуникации. Во-вторых, фактор того, что твою работу будут проверять твои же коллеги заставляет тщательнее думать и лучше писать.
Мне кажется, что такой процесс разработки довольно продуктивен и лучше того, что доводилось видеть.