Тест Джоэла для СМС-ИТ на конец 2009 г.

Тест Джоэла – это наша давняя любовь. Он красивый. В нем элегантно и просто задаются 12 вопросов, на которые нужно давать честные ответы. Каждый положительный ответ приближает фирму-разработчика ПО к команде мечты, а отрицательный отдаляет. В ответах содержится и вектор развития, то к чему можно стремиться.
Тех, кто не слышал про «тест Джоэла для команды разработчиков», или кто знал, но забыл, отсылаю к первоисточнику: http://www.joelonsoftware.com/articles/fog0000000043.html . Или к русскому переводу: http://local.joelonsoftware.com/wiki/Тест_Джоэла:_12_шагов_к_лучшему_коду.

Прочитав этот тест (в первый раз он попался мне на глаза в книге «Руководство Джоэла Спольски по подбору программистов и управлению ими» в 2008 году), мне было интересно примерить его на нашу фирму. И я, прямо в книге, напротив каждого пункта проставил плюсики и минусики. И тогда же родилась идея проводить такое самотестирование ежегодно, и смотреть, как что у нас меняется со временем.

Вот наши успехи на конец 2009 года.

Тест Джоэла

1. Вы используете систему контроля версий? да.
Сейчас мы используем CVS. В качестве клиентской части – WinCVS или TortoiseCVS, по вкусу. Посматриваем в сторону других, более современных и удобных систем. Не исключено, что в 2010 году мы перейдем на что-то другое.

2. Можете ли вы собрать проект в один шаг? да.
Довольно долгое время и до середины этого года у нас был набор достаточно навороченных CMD скриптов, которые делали полную сборку проекта, начиная от получения версии с CVS и заканчивая сборкой дистрибутива. Но со временем проекты разрастались и усложнялись, вместе с ними усложнялись и эти скрипты, и их становилось все тяжелее поддерживать.
А в середине этого года мы переписали все эти скрипты под систему Nant, попутно наведя в них порядок и навставляв кучу комментариев. В результате мы получили кучу бонусов:

1. Они реально стали понятнее. Раньше в этих cmd - скриптах хоть что-то понимали только 2 человека, теперь – уже 4 (те, кому приходится собирать проекты).
2. Они стали универсальнее. Раньше под каждый проект был свой набор скриптов. Теперь набор скриптов один – общий, а на каждый проект пишется конфигурационный файл, описывающий специфику данного проекта.
3. Практически без доработок эти же скрипты мы используем и для ночных сборок (см. следующий пункт), и для (не-знаю-как-это-по-русски) Continuous Integration – когда сборка всех проектов производится при каждом обновлении файлов в системе контроля версий, с извещением в случае ошибки. Очень удобная штука, позволяющая практически сразу заметить, когда кто-то выкладывает фигню ошибочный или неполный код.
   

3. Проводите ли вы ежедневные билды? да.
Ежедневные билды появились, как я писал выше, в середине этого года, после перевода наших скриптов сборки на Nant.
Сейчас мы собираем все наши проекты каждую ночь. Полный цикл – до получения дистрибутива. Отчет о сборке приходит по почте. После собственно сборки запускаются тесты – модульные тесты, тесты развертывания, автоматизированные тесты функциональности (с помощью инструмента TestComplete)

4. У вас есть база данных ошибок? да.
Это Bugzilla. Её мы используем уже несколько лет.
Для наших тестировщиков к ней прицеплено расширение TesTopia. В нем пишутся тест-кейсы и тест-планы.
В этом году мы интегрировали нашу Багзилу с нашим же сайтом техподдержки, а именно разделом HelpDesk, где клиенты оставляют свои замечания и пожелания. Теперь наша техподдержка может легким движением руки создать баг в Багзиле на основании запроса клиента, и в обоих системах появятся ссылки: в HelpDesk-е ссылка на баг в Багзиле, а в Багзиле – ссылка на исходный тикет.

5. Исправляете ли вы ошибки до написания нового кода? нет.
Не хочу сказать, что мы совсем не исправляем ошибки, но пока этот процесс зачастую идет параллельно с разработкой нового кода. Причем дело усугубляется нашей любовью к веткам (branch) в CVS. Перед выпуском релиза мы создаем для него ветку, в которой уже вылавливаем все недочеты текущего релиза (одновременно внося правки и в главную ветку). А одновременно с этим, другая часть разработчиков продолжает в главной ветке фигачить новый код, не дожидаясь полного исправления всех найденных на тот момент ошибок.

6. У вас есть актуальный график работ? нет.
Да, этот так. Мы бьемся с этим нашим недостатком второй год, но пока дела плохи. Да, мы пишем план для каждого проекта, бьем его по задачам, задачи по подзадачам, оцениваем трудоемкость, закладываем риски. Потом в процессе работы отслеживаем выполнение. Но в итоге, как в известном анекдоте, всё равно получается паровоз вместо истребителя. Сроки выпуска релизов задерживаются на месяц, потом еще на месяц. Так что, до тех пор, пока нам не удастся добиться разницы между фактическими и планируемыми сроками хотя бы в пределах 10%, на этот пункт придется по-прежнему писать «нет».

7. У вас есть спецификация? да.
О да. И меня прямо обуревает гордость за этот пункт. Потому что если сравнить наши теперешние процессы в плане написания спецификаций сейчас, и на конец 2008 года, то разница будет в 10, нет, в 100 раз, нет, … можно подставлять вообще любое число. Потому что в прошлом году было – 0. Ноль. Спецификаций как таковых не было. Были какие-то записки на манжетах, которые были написаны кое-как и хранились неизвестно где. А код писался так – сели два разработчика, погутарили между собой, решили: пишем так. И написали. А потом рассказали тестерам и техподдержке, что еще помнили и как смогли объяснить. В общем, смутное было время.
Другое дело сейчас. На каждом проекте по аналитику. Ведущие разработчики и аналитики пишут спецификации. Просто разработчики тоже пишут спецификации, для своих частей. Спецификации пишутся и функциональные, и, по необходимости, технические. Там же набрасываются прототипы интерфейсов.
Этой осенью поставили Вику, и все спецификации теперь пишем в ней. Мне кажется, стало удобнее, чем было до этого – в Ворде. Особенно когда Вику расширили расширениями для рисования интерфейсов (Balsamic Mockup), и рисования UML-диаграмм (PlantUML). Вот тогда счастье стало совсем полным.
Но лучше я посвящу этому занимательному процессу – написанию спецификаций – отдельную статейку.

8. У программистов тихие рабочие места? нет.
У наших разработчиков, к сожалению, нет отдельных кабинетов со стеклянной дверью. В нашем новом офисе в каждой комнате сидит от двух до восьми человек. Иногда аналитик нет-нет да и придёт поговорить с ведущим. Или два ведущих устроят диспут, как лучше назвать класс. Полной тишины не получается.
Но хорошо уже то, что теперь разработчики сидят отдельно от тестеров (которые страх как любят пообщаться лично), и от техподдержки (которая не то чтобы очень любит, но тут уж выбора нет, поговорить по телефону). Наш новый офис теперь такой спокойный (когда закрыта дверь в столовую).

9. Используете ли вы лучшие средства, какие только можно купить? нет.
Не на 100%. Правдивый ответ будет такой – мы используем лучшие средства, которые можем себе позволить.
Смысл критерия понятен: разработчик должен концентрироваться на борьбу с багами и тормозами в своей программе, а не в инструментах и железе. Но тут все упирается в бюджет.
В отношении программ – да, покупаются те средства, которые необходимы для разработки. Именно те, которые нужны. Но с оговорками.

1. Перед покупкой мы всегда ищем альтернативы в мире бесплатного софта. И, если удается найти достойную альтернативу, лишь немного уступающую платному лидеру в своем классе, мы выбираем бесплатный инструмент. (Например, мы все поголовно рисуем в Paint.Net. Наверное, Фотошоп мощнее, и даже, наверное, поудобнее. Но наши задачи так же хорошо решаются и в Paint.Net).
2. Стоимость. Очень дорогие средства нам пока не по карману. А может и по карману, но просто жаба душит. Такие, например, как Rational Rose. Или по Visio каждому разработчику (сейчас только у избранных). Поэтому и им тоже ищем замену. Или бесплатную, или платную, но подешевле. При этом, в отличие от предыдущего пункта, достойной замены может и не найтись.

Про железо. Прямо скажем, пока еще не у всех стоит по 2 монитора. (Хотя в глубине души я уже мечтаю о третьем). Да и сервера надо тоже обновлять. И хоть процесс обновления железа идет постоянно, мы все равно отстаем. Сначала старое железо дает о себе знать – тормозами, сбоями, и только помучавшись с ним пару месяцев, мы меняем его на новое. Новое железо клёво работает. Но тут же дает о себе знать другая железка, которую раньше не замечали на фоне фиговой первой. И так постоянно.
Офис, мебель. К сожалению, не стеклянный офис с видом на Волгу, и не стулья Aeron. Так, обычный офис, обычная мебель. Похвастать нечем. Правда, если честно, то и пожаловаться тоже не на что. В нашем новом офисе есть даже столовая. (Комната приёма пищи, как её гордо именует охранник).

10. У вас есть тестеры? да.
У нас есть выделенный отдел тестирования. За каждым проектом закреплен отдельный тестер, который знает все нюансы своего проекта. В этом году мы начали пробовать автоматизированное тестирование, но о каких-то результатах ещё говорить рано.

11. Пишут ли кандидаты код во время собеседования? да.
Да, код программисты пишут у нас последние два с половиной года. Раньше верили на слово.
Но тут я немного лукавлю. Кандидаты пишут код не во время, а после собеседования. Дома. Мы даем нашим претендентам тестовое задание, и даем несколько дней на его выполнение. Основная причина – время. Откровенно говоря, фирма СМС-ИТ пока не настолько привлекательна для разработчиков, чтобы они могли выкроить целый день для прохождения собеседования, как это принято, например, в Microsoft. Да и у собеседующих из СМС-ИТ тоже полно дел, и они с грустью начинают поглядывать на часы, когда собеседование затягивается на третий час.
Сейчас практика такая. Если в процессе собеседования претендент всем понравился, он получает задание на дом и срок неделю. Открываю карты – что мы смотрим в коде.

1. Оформление. Название переменных, классов, методов. Критерий прост: чем скорее я понимаю, что тут собственно написано, тем лучше для меня код. Если переменные называются s, b, x, а методы – Button1Click, то, скорее всего, мы больше не увидимся.
2. Комментарии. Должны быть. Должны быть написаны хорошим грамотным русским языком.
3. Алгоритмы, структуры данных, компоненты. Если дается тестовое задание на многопоточность, то не надо делать его с помощью таймера. К встречам с goto мы тоже морально не готовы.

Плюс в этом году мы внедрили подобную практику для тестировщиков. Мы сделали приложение, кишащее ошибками, мы отдаем его и просим прислать нам результат тестирования. Очень интересно получилось.

12. Проводите ли вы коридорное тестирование удобства использования программ? нет.
Если не считать этими пятью людьми из коридора наших тестеров. Или скажем, внедренцев. Они всё же уже испорченные нашими интерфейсами люди. Поработав хотя бы полгода с программой, уже сложно увидеть какие-то ляпы или нелогичности, даже если они и на виду. А где взять пять совсем новых людей «из коридора» - непонятно.
Конечно, мы рассылаем наши ранние беты нашим клиентам, собираем урожай отзывов. Но это не совсем то. Мы получаем в ответ, как пользователи думают как бы им было удобнее. А почему они так думают – поди угадай. Бывают редкие моменты счастья, когда мы лично выезжаем к нашим клиентам, сидим вместе с ними за программой, и вот тогда-то наступает озарение. Но к сожалению это бывает очень редко. Поэтому – минус.

Итог: 7 баллов из 12.(0, 583)

Не много.

Позитив: плюсов больше половины.

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

Позитив: из этих 7 баллов 2 балла появились у нас в этом году. Мы молодцы :) , год удался.

Позитив: есть над чем поработать в новом году, что мы в силах улучшить. Например, я буду стараться, чтобы у нас, наконец, появился актуальный график работ. А может кто-то из моих коллег озаботится другим пунктом. Так, глядишь, и до Гугла дорастём :) .