Похоже, но не agile

Вспоминал недавно один из своих первых проектов:

Звучит довольно по-аджальному.

Впрочем, такого ощущения не возникает при воспоминаниях об этом проекте.

Давайте попробуем разобраться, в чём же дело:

1. Несмотря на то, что объём работы и функциональность не были зафиксированы в каких-либо спецификациях, кроме как в одностраничном документе-видении проекта, а процесс был построен так, что новые пожелания заказчика могли быть учтены в практически любой фазе проекта; тип контракта, который заключили с командой разработчиков, был «фиксированное время, фиксированные бюджет».

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

2. Несмотря на короткие циклы разработки (от недели до двух), в проекте не было чёткой стратегии и планов на ближайший релиз. Всё двигалось в бесконечном маятнике от демонстрации к демонстрации.

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

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

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

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

То, что на первый взгляд может очень походить на agile, на самом деле может оказаться хаосом и способом траты денег, а подобные вещи не имеют чётких целей и демотивируют проектную команду.

Последние несколько лет использование термина agile стало мощной рекрутинговой стратегией. Объявления о поиске программистов так и хлещут agile терминологией.

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

Не торопитесь делать скоропостижные выводы.

Статья от 05/2007

Почитать больше о разработке продуктов.