10 сентября 2010 г.



Test Driven Development - так далеко, так близко

Недавно наткнулся на неплохие посты о TDD и в очередной раз у меня возникли очень противоречивые чувства.  Нет, не потому, что TDD меня чем-то не устраивает. И не потому, что я являюсь фанатом или евангелистом данной методики разработки. Все намного проще. Осознавая общую полезность этого подхода и полностью признавая его плюсы и преимущества, я никак не могу начать сознательно его использовать! Вот такая проблема. Разберемся?

Для начала ссылки (рекомендую к прочтению):
Теперь попробуем разобраться в причинах сложившейся ситуации. Что происходит? Почему явно полезная методика никак не может найти места в моей профессиональной деятельности?

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

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

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

Другой вариант развития событий состоит в том, что при внедрении гибких методик разработки (и Test Driven Development в частности) в организации есть человек, побывавший в таком проекте и испробовавший все это на собственной шкуре (также это может быть консультант со стороны). Вообще говоря, так советуют внедрять agile очень многие тренеры и ведущие соответствующих семинаров. И теперь я понимаю почему - нужен человек, преодолевший барьер неопределенности. Человек, более-менее предполагающий, к каким конкретным результатам может привести использование гибких методик разработки. Человек, представляющий себе основные риски этого процесса.

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

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

Вот такой опус получился на ночь глядя. Надо собираться силами и, в конце-концов, одолеть свою инертность. Всем (и мне в первую очередь) удачи в этом нелегком деле!


Полезные ссылки:





Понравилось сообщение - подпишитесь на блог Подписка на блогFollow grodnosoft on Twitter




Читайте также:


Комментов: 0

Отправить комментарий