Thu 31 Aug 2006
Лучший способ найти время на юнит-тесты
Posted by Alex Lebedev under работа с заказчиком, менеджмент, процесс разработки
В одном из недавних комментариев Андрей написал о наболевшем:
И, наверное, документирование надо рассматривать как еще одну _невключаемую_обычно_ в план работ задачу.
“У нас нет времени писать юнит-тесты. Сделаете это потом”. Звучит знакомо, не правда ли? Попав в ситуацию дефицита времени, сложно бороться с искушением сэкономить время за счет юнит-тестов, ревью, документации, любой другой работы, которая вроде бы не обязательна для получения работающего кода. Что ж, многие и не борются с искушением, а смело срезают углы. Думаю, не надо объяснять, почему это плохая идея. На следующем же проекте, наученные горьким опытом, разработчики будут понимать истинную цену такой “экономии”.
Но что же делать, если сэкономить время на необходимых работах хочет ваш заказчик? Это гораздо более неприятная ситуация. В срыве сроков и плохом качестве виновата будет все равно ваша команда. Да и заказчики реже учатся на своих ошибках, чем разработчики.
Убедить типичного заказчика в необходимости юнит-тестов практически невозможно. Поэтому не стоит и пытаться этого делать. Хотите найти время на юнит-тесты, code review и документацию - сделайте эти задачами обязательными этапами разработки любой новой функции. И не говорите о них вашему руководству или заказчику. Никогда. Просто включайте дополнительное время в оценку трудоемкости разработки основных функций.
В статье “Секрет Айсберга” Джоэль Спольски приводит отличный пример на эту тему:
Когда клиент или нетехнический менеджер очень хочет принять участие в проекте, дайте ему несколько версий графического дизайна, чтобы они могли выбрать. Меняйте расположение некоторых вещей, изменяйте вид, шрифты, двигайте логотип, делайте его то больше, то меньше. Дайте им почувствовать себя важными, предоставляя возможность поиграть с малозначимыми вещами. В этом случае они не нанесут вреда срокам. Хороший дизайнер интерьера постоянно приносит эскизы клиенту и вещи, из которых он может выбрать. Но они никогда не обсуждают с клиентом расположение умывальника. Он находится рядом с канализационной трубой и не важно, чего хочет клиент. Нет смысла тратить время на обсуждения, где должен находится умывальник - он должен быть рядом с трубой, даже не начинайте разговор об этом; пусть клиенты изливают свои дизайнерские потуги делая какие-то безвредные вещи вроде изменения своего мнения 200 раз о том, нужно ли использовать для столешницы итальянский гранит или мексиканскую плитку, или норвежскую древесину.
Отличный совет. То же самое нужно делать с процессом разработки. Готовый код должен быть покрыт тестами, отрецензирован и документирован. Не важно чего хочет ваш руководитель или заказчик. Если он не эксперт по процессу разработки ПО, то у него нет права голоса.
Разумеется, будет непросто создать и поддерживать подобную ситуацию, а особенно не испортить при этом отношения со спонсором проекта (что гораздо опаснее, чем разрабатывать продукт без юнит-тестов). Но если вы менеджер проекта, то это, черт побери, ваша работа. Займитесь ей, а не пытайтесь выжать из программистов рекордную производительность.
Материалы по теме:
- Перевод статьи Дэйва Томаса и Энди Ханта “Учимся любить юнит-тесты”. В ней, помимо прочего, авторы проехались катком по аргументу “У нас нет времени, чтобы писать тесты”
8 Responses to “ Лучший способ найти время на юнит-тесты ”
Comments:
Leave a Reply
Trackbacks & Pingbacks:
-
Pingback from Знай свой рынок » Outsourcing stories
September 6th, 2006 at 01:31[…] Недавно я получил очень интересный комментарий на свой пост “Лучший способ найти время на юнит-тесты”: Ты не рассмотрел одного аспекта. Ты и твоя команда разработчиков - не монополисты. Вы в ситуации рыночной конкуренции. И в этом смысле сроки, за которые вы поставляете заказчику продукт - один из тех показателей, в том числе и по которому вас будут выбирать из множества других. […]
August 31st, 2006 at 03:01
Спасибо. Действительно хорошая идея.
September 2nd, 2006 at 11:45
В общем и целом - сказал хорошо. Как обычно - одобряю и поддерживаю, но “имею сказать” (c).
Ты не рассмотрел одного аспекта. Ты и твоя команда разработчиков - не монополисты. Вы в ситуации рыночной конкуренции. И в этом смысле сроки, за которые вы поставляете заказчику продукт - один из тех показателей, в том числе и по которому вас будут выбирать из множества других.
Хорошо, когда заказчик “повязан” на вас. А если нет? Если вы вынуждены конкурировать с другими, с тем чтобы “пробить” под себя заказ? При этом, как правильно ты заметил, необходимость документирования и тестирования заказчика не волнует (первое - как правило, второе - всегда). Его волнует конечный продукт, а также сроки и цена (которая, в свою очередь, тоже не склонна снижаться с ходом тестирования и документирования; ты же тоже, при всём понимании необходимости некоторых вещей подобно этой, не альтруист).
То есть: ты не можешь сказать, чем обусловлены бОльшие сроки (по сравнению со среднерыночными или сроками реализации проекта отдельными ушлыми псевдо-разработчиками), за которые твоя команда берётся реализовать проект. То есть можешь, но это никого не интересует.
И это становится не положительной, позитивно характеризующей вашу разработку стороной, а наоборот - вашим конкурентным недостатком.
Это IMHO. Уверен, мОгущее иметь место в современном бизнес-мире.
Антон С. (ТАУ, 2001-2006)
P.S. Теперь по адресу.
September 3rd, 2006 at 05:56
to Anton:
Не скажи. Например, нашим конкурентным преимуществом является то, что мы делаем всё качественно. Естественно, это стоит дороже. Но цена автоматически отфильтровывает заказчиков, которые невысоко ценят отличия очень хорошего продукта от просто нормального.
P.S. To Alex: Спасибо за цитирование “Секрет айсберга”. Это мой первый перевод Джоела - видимо получился
September 3rd, 2006 at 11:57
Владимиру Лучанинову.
Не бывает отдельно взятых конкурентных преимуществ. Ваша ситуация - частный случай, когда вас знают по вашему (сложившемуся за некоторое время благодаря вашим очень хорошим и очень дорогим разработкам) имени.
Вы делаете хорошо и за дорого, и это работает, покуда востребовано рынком. (Надо понимать, что качество - это не абстрактная хорошесть. Качество - это всего-навсего соответствие делаемого предъявляемым к этому требованиям, и не более того.) В данных условиях вы не участвуете в рыночных баталиях, а статично занимаете определённую вами и удобную вам нишу.
В гипотетической ситуации, когда многие будут предъявлять низкие требования за небольшие деньги, вы просто либо не сможете работать, делая “качественный продукт”, либо вынуждены будете перестраиваться с “исключительно хороших” продуктов на продукты “качественные” (соответствующие).
… “Майкрософт” не делает исключительно хороших программных продуктов. Исключительно хорошее ПО делает, как пример, NASA. Однако и один, и другой бизнес - успешны.
Требования, диктуемые рынком, бывают слишком различны, что заранее позиционировать себя либо тем, либо иным образом. Вернее, тактически, позиционировать себя как-то нужно, чтобы было понятно, чем вы, в принципе, занимаетесь. Но, стратегически, не нужно акцентироваться только на этом и надо быть готовым изменять принципы работы, подходы.
Надеюсь, я понимаем. Если нет - спрашивайте, будем пробовать уточнять. (Не хочу, чтобы даже самый малопонимающий счёл вышесказанное за безосновательную болтовню.)
Антон.
September 4th, 2006 at 02:33
Интересное обсуждение завязывается…
На этой неделе собираюсь написать длинный пост про то, как я вижу конкуренцию нашей команды с конторами, обещающими нереальные сроки.
November 26th, 2006 at 04:42
К сожалению не нашел контактного email, так чт о пришлось писать в виде коментария.
Как Вы оцениваете ценность acceptance-тестирования? Например, при помощи FitNesse. http://agiletesting.blogspot.com/2004/11/writing-fitnesse-tests-in-python.html и дальше по ссылкам.
November 29th, 2006 at 01:31
Acceptance-тестирование - достаточно своеобразная форма контроля качества.
С одной стороны - это такое “функциональное тестирование для бедных”, несистемно проверяющее основные функции. Соответственно, acceptance-тестирование не самодостаточно и это надо очень четко понимать.
С другой стороны, бывает, что к тестированию удается привлечь представителей заказчика, технических писателей, практикантов и прочих людей, не способных тестировать системно. В этом случае acceptance-тестирование с помощью того же FitNesse позволяет вовлечь всех этих людей в контроль качества и это, безусловно, хорошо.
В своем последнем большом проекте я рассматривал возможность использования FitNesse. Из-за отсутствия “бесплатной” рабочей силы для тестирования я счел эту идею бесперспективной.