Когда лет десять назад я перешел во фрилансеры, я практически ничего не знал ни про веб, ни про то, как это работает, но горел желанием учиться, и, по счастью, у меня нашлось несколько друзей, которым нужна была веб-разработка совсем базового уровня. Причем под «базовым» я понимаю в основном следование руководствам по Фотошопу, как нарисовать пару кнопок тут и там. Вскоре мне стало более интересно не то, как вебсайты выглядят, а технологии, которые за ними стоят, поэтому я начал углубляться в PHP и написал несколько простых скриптов, пока не открыл для себя прекрасное чудовище по имени CMS (мой выбор тогда пал на TYPO3, потому что таков был запрос от одного из ранних клиентов). Это сделало меня всемогущим в плане поведения и внешнего вида сайтов, но, к сожалению, позволило не углубляться в их начинку (хотя это, мне думается, совсем другая тема).

Однако была еще одна вещь, которой я толком никогда не учился, - и хотел бы я, чтобы это был пустяк: как правильно продавать себя (в смысле, мои услуги). И значительную часть этого составляет также управление проектом/временем. Так что этот пост - что-то вроде обучалки для любого, кто чувствует, что мог бы зарабатывать больше, а времени тратить меньше. Хотел бы я прочитать (или, что важнее, применить) нечто подобное, когда еще был фрилансером. Итак, как начать «Скрам на одного»?

Канбан

В самом сердце Скрама лежит Канбан (вы можете поспорить, что это не совсем правда, но потерпите минутку). Итак, что же такое Канбан? Самое короткое из возможных объяснений: это доска, на ней много колонок, где каждая задача представлена тикетом, а каждая колонка представляет статус определенной задачи в ней.

Обычно начинают с трех колонок: «В ожидании» (ее еще называют «бэклог»), «В процессе» и «Готово». Конечно, каждому проекту (даже моему) нужны дополнительные колонки в зависимости от сложности и природы проекта, то есть у нас может появиться что-то вроде «Ждем дизайн», «Ждем CSS» и тому подобное.

Канбан 2.0

Способ, которым Канбан улучшает Скрам, состоит в том, как задачи и соответствующие тикеты организуются в нем в то, что называется «пользовательскими историями». Пользовательская история - это, как правило, набор действий, которые кому-то или чему-то (ведь пользователь может быть и не человеком) надо предпринять, чтобы достичь определенного результата. Это не обязательно некая функция, как я опишу кратко. Вот пример пользовательской истории: Как посетитель, я могу заполнить и отправить контактную форму, чтобы владелец сайта знал, что я хочу сделать покупку.

Как видите, тут налицо три очень важные части:

• Пользователь (в данном случае посетитель сайта)
• Действие (заполнение/отправка формы)
• Причина (заинтересованность в покупке)

Очень важно, что описаны все три части, потому что лишь тогда в пользовательской истории есть смысл. Кроме того, к каждой пользовательской истории прикрепляются два списка: «Критерии приемки» и «Что надо сделать». Первое - это в основном ряд шагов, которые проверяющий (обычно клиент) должен предпринять, чтобы удостовериться, что разработанный функционал прекрасно работает, а второе - это описание, какие работы нужно проделать разработчику. Очень важно, чтобы это описание было записано и пояснено, потому что с ним гораздо легче оценивать работу, а клиенту - проще понимать затронутую область (и связанную с этим стоимость).

Размер пользовательской истории

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

Чтобы функция работала правильно, обычно нужна какая-то работа на бэкенде (на серверной стороне, на Ruby, PHP, на чем угодно) и фронтенде (Javascript, HTML, CSS), поэтому мы бьем задачу по языку и технологии. Если она все равно велика, мы дробим ее на визуальные и невизуальные части или на функции и формы - есть много способов, какой выберете вы, зависит от вас.

Часть пользовательских историй, кроме того, оцениваются, и есть одно правило: никогда, ничего не оценивайте в часах! Часы - зло, потому что они не берут в расчет неопределенностей разработки (вы сейчас киваете в знак согласия, да?). Вместо них заведите себе другую единицу, которая допускает буферизацию и вариативность.

Мы сделали так: ввели «единицы истории», основанные на числах Фибоначчи: 1, 2, 3, 5, 8, 13 и т.д. Весь смысл этих цифр в том, что они не позволяют точно оценить время в часах, необходимое на конкретную задачу.

• 1 - это не час, а пара кликов
• 2 - это не 2 часа, а «больше, чем пара кликов»
• 3 - это приблизительно полдня
• 5 - это примерно день
• 8 - больше дня (где-то до полутора дней)
• 13 - 2-3 дня (редко используется)

Как видите, тут очень много приблизительности, и это сделано нарочно, потому что оценить разработку со 100% точностью практически невозможно. Однако мы добились 90%, используя эту технику, и с каждым спринтом дело становится все лучше! Рассмотрим на примере. У нас есть задача, и мы знаем, что она занимает 9 часов. Мы можем оценить ее в 5 единиц, а можем в 8. Что выбрать? Тут нет определенного ответа, годится и то, и другое, но обычно мы выбираем большее число, чтобы оставить некий буфер.

Роли

Еще одна вещь, введенная в Скраме, - это понятие «ролей». Роль - это позиция внутри скрам-команды, отвечающая за определенную часть. Самые важные роли - это скрам-мастер (человек, следящий за всем потоком работы), владелец продукта (клиент) и команда (рабочие пчелы). Будучи фрилансером, вы занимаете две роли (угадайте, какие), и это совершенно нормально, поскольку вы руководите лишь собой. Кроме того, что вы - сам себе команда, вы будете действовать еще и как скрам-мастер, отвечающий за то, чтобы отчитываться клиенту на ежедневной основе, что носит название…

Летучки

Летучки - это короткие, минут на 10, переговоры с клиентом, лучше всего прямо у доски с задачами. Эти совещания нужно использовать для переговоров не по грядущим задачам, а по тем, что есть, или, что более важно, вы должны отчитываться клиенту о двух вещах:

• что сделано за предыдущий день, нет ли проблем,
• что вы планируете сделать в день совещания.

И всё. У меня слов не хватит подчеркнуть, насколько важно использовать летучки только для этих двух вещей, иначе всё быстро выйдет из-под контроля, и вы оба потеряете время. Чтобы обсудить проект в целом или на большем уровне, вам нужно использовать так называемые спринты.

Спринты

Спринт - это период, за который делается крупная функция или набор функций. Обычно он занимает 2-3 недели, потому что так разумнее всего в плане оплаты и это вполне достаточное время, чтобы разработать достаточно большой функционал, чтобы его можно было публиковать онлайн. Спринты всегда должны начинаться с планёрки длиной на весь день (у нас для этого отведен каждый второй понедельник), на которой каждая функция, запланированная на данный спринт, разбивается на пользовательские истории, которые затем оцениваются.

Довольный клиент, довольный разработчик

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

• Они видят, сколько на самом деле времени до завершения;
• У них создается ощущение оправданности расходов, связанных с вашей работой.

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

Оригинал: http://zaman.io/1-person-scrum/

Автор: Томаш Заман

Перевод: Александра Родсет

Сертифицированные курсы

Андрей Плетенев. Онлайн курс Agile. SCRUM. Курс включает более 20 уроков с практическими заданиями, которые индивидуально проверяются и комментируются тренером.

Еще интересные статьи на эту тему:

• Масштабируем Scrum (но не так, как вы подумали)
• Анти-паттерн "красного спринта": от спринтов к итерациям
• Анти-паттерн "красного спринта": крах маленьких проектов
• Анти-паттерн "красного спринта": уход от каскадной модели
• Кен Швабер: истоки и будущее Скрама