Yuri Shilyaev. Blog.

Некоторое время назад у нас начался большой проект, который потребовал внедрения новых методик работы. Классический “водопад” не может обеспечить быстрое и безболезненное внесение изменений в проект. А это плохо. В условиях не четко поставленной задачи (а она и не может быть четко поставлена) требуется быстро вносить изменения, дополнения, новые требования клиента.
Похоже, что работа над подобными проектами, а также просто работа с разнородными задачами клиентов убеждает меня в том, что я бы не осмеливался сказать еще пару-тройку лет назад:

написать большое и всеобъемлющее ТЗ на крупный проект не реально.

Т.е. я хочу сказать, что это или не реально сложно или вообще не реально. Да я писал большие толстые ТЗ, которые описывали с точностью до запятой, как должен работать сайт, где у него какая информация и на какую кнопку надо нажать и вписать, чтобы он сообщил: “Такой формат e-mail недопустим”.
Но времена изменились. Я понял, что люди не просто не хотят читать большие ТЗ (это как раз не самая большая проблема), иногда невозможно по большому ТЗ сделать именно то, что хотят клиенты и то чего требует рынок. А чего хотят клиенты? Кто ответит? Кто знает чего хотят клиенты? А я отвечу: Они сами не знают чего хотят. И это будет истинной правдой.

Приведу пример. Недавно я заказывал себе новый рабочий стол домой и столкулся с проблемой. Мне престояло выбрать не просто цвет стола, но также внешний вид выдвижных ящиков. Менеджер показала мне штук 15 вариантов, к которым добавлялось несколько видов разметки. В этот момент я понял, что я не знаю какие мне нужны ящики. Я мог сказать, что у меня желтые обои в комнате и черный компьютер, но какой цвет при этом должен быть у ящиков я не знал. Просто ткнул в картинку и сказал: “Такие!”.

Так вот клиенты точно также не знают, что им надо. Надо им “молочный дуб” или “ясень”, хотят они видеть снятую фаску по периметру или нет. Если им показать набросок, с которым можно попробовать поработать, обсудить, то только тогда могут появиться какие-то требования от клиента. И чем более нов и не тривиален проект, тем получать требования сложнее и неоднозначнее. Задавая миллион вопросов в самом начале проекта вы натыкаетесь на “ложные” решения: клиенты просто тыкают в один из вариантов и говорят “этот”. А спустя 3 месяца они смотрят на результат и говорят: “Нет, давайте лучше этот!”

Как с этим жить?
Я вовсе не призываю писать ТЗ по-меньше и по-тоньше. Это как раз плохо. Просто в итоге подобных рассуждений мы наталкиваемся на то, что надо менять сам метод ведения проектов и отношений с клиентами. Надо быть гибче. И сейчас мы как раз занимаемся выработкой такого взаимодействия и внутренней работы.

Имя тренду, в котором мы движемся, agile. Итеративная, спиральная разработка.

Вот процесс прохождения проекта, который я набросал на доске для команды проекта:

Ничего секретного в моих каракулях нет. Это спиральный метод разработки.
Требуются некоторые пояснения к схеме.

Имеются 2 итерационных кольца:

• большое — итерация разработки,
• малое — прохождение тикетов (историй) внутри команды.

Спираль пробегается один раз по большому кругу на всю итерцию и может пробегаться по малому кругу (без привлечения клиента) несколько раз на одну функциональность. Т.е. мы можем несколько раз изменить/улучшить/усложнить “профиль пользователя” не трогая при этом представителя заказчика.

Большой круг
В большом круге: презентация, сбор требований с клиента и ПМ (тикеты, истории) и малый круг это непосредственно разработка.
Итерация длится 2-4 недели (а не 3-5 месяцев, как было бы с “толстым” ТЗ). Ответственной за итерацию считается вся команда.
Критерий успеха прохождения итерации: выполненние поставленных задач, отклик на изменения и работающий код.
Дизайн и ТЗ под каждую задачу отдельно. В явном виде они никогда не будут закончены.

Малый круг
Тут тоже маленькая спираль.
В малом круге 3 точки: Аналитика, Разработка, Тестирование. Весь процесс разработки как раз и бегает меж этих “трех сосен” с каждой задачей.

Анализ
Описание историй или тиктов (user stories или tickets). Они регистрируются в системе управления проектом. Описывает клиент или менеджер проекта, а также любой заинтересованный участник проекта.
Главный на этом этапе все же ПМ. Он составляет список необходимой функциональности на текущую итерацию при участии представителя заказчика.
Составляются тест-кейсы.

Разработка
Далее tickets должны быть переработаны в ТЗ и представлены в виде задач (task и subtask, change request). Дополнены информацией и переведены в новую сущность в системе управления. Этой задачей занимается тим-лидер и ПМ.
Должны планироваться и выполняться автоматизированные тесты (кстати, это только предстоит).
Далее ведется разработка. С регулярными митингами. Обязательный митинг раз в неделю, а остальные при необходимости в процессе работы, хоть каждый день.
Сборки постоянные. Интеграция непрерывная. Проект практически каждый день должен работать. Да, в сущности выпускать билд каждый день не получается, но надо стремиться к этому.

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

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

Распределение ролей в команде:

• Анализ — Менеджер и проектировщик.
• Разработка — Тим лид и группа разработки.
• Тестирование — QAщики.
• Презентация — клиент, аккаунт и прочие менеджеры.

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

Говоря здесь и далее в своем блоге про agile я не буду утверждать, что мы следуем каким-то описанным жестким методологиям agile. Вдруг мне станут указывать на то, что по srum положено то, а по XP другое. Я заметил, что чем более профессиональна команда разработчиков тем более они сторонятся вского рода методологий. “Если менеджмент начинает работать по методологиям, значит не знают как надо работать…” — так рассуждают многие из них. И они не далеки от истины. Поэтому настраивая команду на работу я стараюсь предоставить им самим выбор делать митинги раз в день или в неделю, ну или делать ли таскборд.