Процесс разработки проекта становится гибче

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

Похоже, что работа над подобными проектами, а также просто работа с разнородными задачами клиентов убеждает меня в том, что я бы не осмеливался сказать еще пару-тройку лет назад:

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

Т.е. я хочу сказать, что это или не реально сложно или вообще не реально. Да я писал большие толстые ТЗ, которые описывали с точностью до запятой, как должен работать сайт, где у него какая информация и на какую кнопку надо нажать и вписать, чтобы он сообщил: “Такой формат 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 другое. Я заметил, что чем более профессиональна команда разработчиков тем более они сторонятся вского рода методологий. “Если менеджмент начинает работать по методологиям, значит не знают как надо работать…” — так рассуждают многие из них. И они не далеки от истины. Поэтому настраивая команду на работу я стараюсь предоставить им самим выбор делать митинги раз в день или в неделю, ну или делать ли таскборд.

Tags: ,

Post Author

This post was written by who has written 50 posts on Agile.by.

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