Оригинальная статья находится по адресу:
http://joel.editthispage.com/articles/fog0000000043.html
By Joel Spolsky, August 9, 2000 (translated by Marianna Evseeva)
Вы когда-либо слышали о программе Software Engineering Measurement and Analysis? Это эзотерическая система, определяющая насколько эффективно работает ваша команда разработчиков. Нет, погодите. Не кидайтесь искать информацию об этой системе, иначе вы потратите лет 6 чтобы понять, что там написано. Я предлагаю вам свой собственный, несерьёзный тест, чтобы квалифицировать команду разработчиков. Главное его преимущество то, что он займёт всего 3 минуты вашего времени.
Вы пользуетесь системой контроля версий?
Вы можете собрать программу за один шаг?
Собираете ли вы билды ежедневно?
Используете ли вы базу данных ошибок?
Исправляете ли вы ошибки перед написанием нового кода?
Есть ли в вашем распоряжении самый последний план работ?
У вас есть спецификация?
Предоставлены ли вашим разработчикам покой и тишина?
Используете ли вы самое новейшее и дорогое оборудование?
Есть ли у вас тестировщики?
Пишут ли новые кандидаты какой-либо код на собеседовании?
Проводите ли вы финальное тестирование по удобству и красоте использования программы?
Отличительной чертой теста Джоэла является то, что вы легко и быстро можете кратко ответить на любой вопрос. Вам не придётся подсчитывать количество строк кода, написанное за день или среднее количество ошибок, приходящееся на модуль. За каждый положительный ответ начисляйте один балл. 12 баллов — отлично, 11 — хорошо, 10 и менее — у вас серьёзные проблемы. Дело в том, что большинство существующих организаций, производящих программное обеспечение, набирают всего 2 или 3 балла, и им нужна серьёзная помощь, потому что такие компании как Microsoft имеют оценку 12 всё время.
Естественно, это не единственный фактор, который определяет успех или провал: в частности, у вас выдающаяся команда разработчиков, но они работают над продуктом, который никому не нужен. И в то же время представьте себе команду "головорезов", которые не делают ничего из выше перечисленного и при этом умудряются производить удивительное программное обеспечение, которое спомобно изменить мир. Но если вы наберёте эти 12 баллов, вы получите дисциплинированную команду, которая сможет постоянно производить хорошие продукты.
1. Пользуетесь ли вы системой контроля версий?
Я использовал рекламный пакет систем контроля версий CVS, который предоставляется бесплатно, и должен сказать, что он достаточно хорош. Но если у вас нет никакой системы контроля версий, вы напрасно потратите свои усилия, пытаясь заставить разработчиков работать сплочённо. У разработчиков нет никакой возможности узнать, что делали другие люди. Станет невозможным сократить количество ошибок. Ещё одно преимущество системы контроля версий — это то, что сам исходный код проверяется на жётском диске каждого разработчика. Я никогда не слышал о каком-либо проекте, в котором бы при использовании системы контроля версий было потеряно большое количество кода.
2. Можете ли вы собрать программу за один шаг?
Под этим я подразумеваю, сколько шагов вам потребуется, чтобы собрать версию для продажи с последнего исходного кода. В хороших командах есть один единственный скрипт, который вы можете запустить. Он выполняет полную проверку с нуля, пересобирает каждую строку кода, создаёт исполняемые файлы во всех его многочисленных версиях, языках и #ifdef комбинациях, создаёт инсталляционный пакет программ и создаёт конечные версии в формате CDROM, WEB сайта и т.д. Если данный процесс занимает более одного шага, то он подвержен ошибкам. И когда вы подойдёте вплотную к созданию версии для продажи, вы захотите иметь очень быстрый цикл исправления последних багов, создания исполняемых файлов и т.п. Если вы управляетесь со всем этим за 20 шагов, вы скоро сойдёте с ума и наделаете кучу глупых ошибок. По этой причине последняя компания, в которой я работал, перешла с WISE на InstallShield; нам было необходимо, чтобы инсталляционный процесс мог автоматически запускаться со скрипта, созданного накануне вечером при помощи планировщика задач NT. WISE не мог запускаться из планировщика накануне вечером, таким образом мы отказались от неё. (Добрые люди, работающие в WISE, уверяют меня, что их последняя версия действительно поддерживает ночные билды).
3. Собираете ли вы билды ежедневно?
Иногда при использовании системы контроля версий один разработчик случайно вносит изменения, которые нарушают номальный ход сборки. Например, он добавил новый файл с исходниками, и на его машине всё компилируется просто замечательно, при этом он забыл добавить этот файл в хранилище кода. Он выключает свою машину и идёт счастливый домой, не придавая должного значения тому, что он сделал. Но после этого уже никто не может работать, и все вынуждены идти домой.
Нарушение хода сборки — вещь распространённая и весьма неприятная. Но при этом она помогает создавать ежедневные билды, чтобы гарантировать, что никакое нарушение не пройдёт незамеченным. В больших командах наиболее оптимальный способ незамедлительного устранения нарушений — проводить ежедневные сборки, скажем в обед. Каждый может вносить сколько угодно изменений до обеда. Когда они возвращаются, билд уже собран. Если сработало — здорово! Все берут последнюю версию и продолжают работать. Если билд упал, вы исправляете его, при этом все остальные могут продолжать работать над досборочной рабочей версией исходника.
В команде Excel у нас было правило, своего рода "наказание". Тот, кто испортил билд, должен был нянчиться с билдами до тех, пора пока кто-нибудь ещё их не испортит. Это был хороший стимул не ломать билды и хороший способ вовлекать всех в познание процесса их работы.
4. Используете ли вы базу данных ошибок?
Мне всё равно, что вы ответите. Даже если вы работатет над кодом в одиночку без организованной базы данных, содержащей все известные ошибки в коде, вы не сможете написать качественный код. Многие программисты думают, что они в состоянии держать всё в своей голове. Чушь. Я не могу вспомнить больше двух-трёх ошибок за раз, а на следующее утро в спешке перед подготовкой версии к продаже они и вовсе забываются. Вам совершенно точно придётся формально следить за ошибками.
База данных ошибок может быть простой и сложной. Любая база данных, приносящая хотя бы минимальную пользу, должна содержать следующую инофрмацию по каждой ошибке:
подробное описание шагов, воспроизводящих ошибку;
ожидаемое поведение;
наблюдаемое (неправильное) поведение;
кому поручено исправить;
исправлено или нет.
Если единственная причина, по которой вы не отслеживаете ошибки, это сложность отслеживающего ошибки программного обеспечения, просто начертите таблицу из пяти колонок, выше представленных, и начните ею пользоваться.
5. Исправляете ли вы ошибки перед написанием нового кода?
Самая первая версия Microsoft Word для Windows воспринималась как проект "похоронный марш". Работа над ней повисла навечно. Вся команда тратила на неё смешное количество времени, и выпуск откладывался снова, и снова, и снова, при этом давление было просто невыносимым. Но когда эту чёртову штуку всё-таки выпустили несколькими годами позже, Microsoft отправила всю команду в отпуск в Мексику, а затем занялась серьёзным анализом своих действий.
Они поняли, что проджект менеджеры так упорно придерживались сроков, что разработчики гнали во весь опор и писали ужасно плохой код, потому что система исправления ошибок не входила в общий план действий. Не было даже попытки вести счёт ошибкам. Как раз наоборот. Говорят, что один программист, который должен был написать код, который бы подсчитывал высоту строки текста, просто написал "return 12;" и дождался сообщения об ощибке — написаная им функция не всегда правильно работала. План работ был больше похож на чеклист, содержащий список функциональностей, проверка которых переводила их в ранг ошибок. Позднее, этот метод получил название "методики бесконечных дефектов".
Чтобы исправить ошибку Microsoft повсеместно стала внедрять так называемую "методику нулевых дефектов". Большинство программистов в компании похихикивало. Выглядело это так, как будто они могли сократить количество ошибок по приказу начальства. В действительности же, термин "нулевые дефекты" трактовался следующим образом. На данный момент наиболее важным является исправление ошибок ПЕРЕД написанием любого нового кода и вот почему.
Обычно, чем больше вы тянете с иправлением ошибки, тем дороже (во временном и денежном отношении) вам обойдётся её исправление.
Например, исправление опечатки или синтаксической ошибки, которую подхватывает компилятор, вещь по существу весьма банальная.
Если в вашем коде есть ошибка, которая обнаруживается при первом запуске, вы можете тут же её исправить, так как всё ещё свежо в вашей памяти.
Если обнаруживается ошибка в коде, который вы написали несколько дней назад, вам потребуется какое-то время, чтобы отследить её, но если вы перечитывали свой код, вы будете помнить всё и сможете исправить ошибку в разумные сроки.
Но если вы обнаружили ошибку в коде, который написали несколько месяцев назад, вы, скорее всего, уже многое в нём забыли и уже будет гораздо сложнее её исправить. Может случиться так, что вам придётся исправлять чужой код, если кто-то, к примеру, отдыхает на Карибах. В этом случае исправление ошибки — целая наука: вам придётся долго, методично и тщательно искать способы её исправления и ещё неизвестно, сколько времени у вас это займёт.
А если вы обнаружили ошибку в продукте, который уже продаётся, вы понесёте невероятные расходы, прежде чем исправите её.
Вот вам первая причина, по которой лучше исправлять ошибки сразу: это занимает меньше времени. Вот вам ещё одна причина: легче прогнозировать, сколько времени займёт написание нового кода, чем исправление имеющейся ошибки. Например, если бы я вас попросил подсчитать, сколько вам понадобится времени, чтобы написать код для сортировки листа, вы бы легко это сделали. Но если бы я попросил вас спрогнозировать сколько может занять времени исправление ошибки в вашем коде, который не работает если установлен Internet Explorer 5.5 , вы не сможете даже предположить, потому что вы не знаете (по определению) причину ошибки. Вам может понадобиться 3 дня, а может всего 2 минуты.
Что я хочу всем этим сказать — если у вас есть план работ, в котором большое количество ошибок остаётся неисправленным, этот план ненадёжен. Но если вы исправили все известные ошибки и единственное, что осталось — это новый код, ваш план работ просто безупречен.
Другое преимущество методики нулевых дефектов — это то, что вы сможете гораздо быстрее реагировать на конкуренцию. Некоторые программисты это понимают так — продукт надо вести так, чтобы его можно было выпустить в любое время. Более того, если ваш конкурент представил какую-то супер новую убийственную функциональность и переманивает ваших клиентов, вы можете внедрить такую же функциональность и незамедлительно выпустить очередную версию, не исправляя при этом большое количество накопившихся ошибок.
6. Есть ли в вашем распоряжении самый последний план работ?
Что заставляет нас обращаться к планам? Если ваш код более чем важен для дела, есть масса причин, по которым хотелось бы знать, когда он будет закончен. Программисты всегда очень раздражительны по поводу составления плана работ и определения сроков. "Будет сделано тогда, когда будет сделано!" — Вопят они на управляющий персонал.
К сожалению, это не решает проблемы. Слишком много плановых решений, которые необходимо осуществить заранее до выпуска кода: демки, демонстрации, реклама и т.д. Единственное решение — это составить план, установить сроки и придерживаться этого.
Другой ключевой момент в составлении плана — это то, что он заставляет вас определиться, какие функциональности вы собираетесь внедрить, заставляет вас выбрать наименее важные функциональности. Лучше сразу отбросить их, чем создавать нагромождения. На самом деле это не так уж сложно: составлять и придерживаться планов и сроков.
7. У вас есть спецификация?
Написание спецификаций похоже на чистку зубов: все согласны, что это классная штука, но никто её не делает.
Я не вполне уверен, но возможно это происходит из-за того, что разработчики ненавидят писать какую-либо документацию. В результате, когда команда, состоящая исключительно из программистов, атакует какую-либо проблему, ей проще выразить своё решение в коде, чем в документации. Такая команда лучше уйдёт с головой в написание кода, чем создаст спецификацию.
На стадии проектирования, когда вы обнаруживаете проблемы, вы можете легко их устранить, отредактировав несколько строк текста. Как только код написан, затраты на исправление ошибок значительно возрастают как в эмоциональном (люди ненавидят выбрасывать код), так и во временном аспекте, т.о. создаётся сопротивление исправлению шибок. Программное обеспечение, созданное без спецификации, обычно оказывается плохо спроектированным и планы со сроками выходят из под контроля. Подобная ситуация образовалась в Netscape, где первые четыре версии превратились в такую неразбериху, что руководство глупо решило выбросить весь код и начать снова. Позднее, они делали подобные ошибки с Mozilla, создавая монстра, который вышел из под контроля и спустя несколько лет вернулся в начальную стадию.
Моя излюбленная теория легко решает подобную проблему. Просто научите разработчиков писать, отправив их на интенсивные курсы по письму, они будут меньше сопротивляться. Другое решение — наймите хорошего менеджера по разработке и сопровождению программ, который будет писать спецификации. В любом случае вам следует обеспечить исполнение простого правила: "никакого кода без спецификации".
8. Предоставлены ли вашим разработчикам покой и тишина?
Уже задокументированы высокие достижения по увеличению производительности работников умственного труда, если им предоставляется рабочее пространство, тишина и уединённость. Классическая книга по управлению компанией, производящей программное обеспечение, — Peopleware обстоятельно описывает их пользу.
Все мы знаем, что люди умственного труда лучше всего работают, когда они полностью сконцентрированы на своей работе и полностью "отключены" от окружающей среды, как бы находясь "в струе". Они теряют счёт времени и производят грандиозные вещи посредством абсолютной концентрации. Вот когда они продуктивно выполняют всю свою работу. Писатели, программисты, учёные и даже баскетболисты расскажут вам, что такое быть " в струе".
Проблема в том, что попасть "в эту струю" не так-то просто. Если вы попытаетесь измерить её, то окажется, что требуется в среднем 15 минут, чтобы начать работать с максимальной производительностью. Иногда, когда вы устали или уже выполнили большую часть творческой работы за день, вы уже не сможете войти в неё и остаток дня уже проведете, валяя дурака, исследуя интернет и играя в Тетрис.
Другая проблема заключается в том, что очень легко выпасть из этой "струи". Шум, телефонные звонки, обеды и особенно реагирование на сослуживцев — всё это выбивает вас из колеи. К примеру, ваш коллега задал вам вопрос. Вы отвлеклись всего на минуту, но этого уже достаточно, чтобы выбить вас из режима работы, и вам уже потребуется, по меньшей мере, полчаса, чтобы вновь втянуться. Ваша общая производительность может от этого сильно пострадать. Если вы работает в шумном "загоне", где ребята из отдела маркетинга висят на телефонах, и тут же рядом работают программисты, ваша производительность резко снизится, так как люди умственного труда то и дело отвлекаются и не могут сконцентрироваться.
С программистами дело обстоит весьма серьёзно. Производительность зависит от способности одновременно управляться и хранить в кратковременной памяти огромное количество различных мелких деталей. Любое вмешательство может вмиг всё это разрушить. Когда вы подводите итоги работы, вы не можете удержать в памяти все детали (такие как имена локальных переменных, которые вы использовали, или на каком месте вы остановились при внедрении поискового алгоритма). Поэтому вам приходится то и дело просматривать эти вещи, что в свою очередь, будет замедлять процесс работы до тех пор, пока вы не вернётесь в нормальный режим.
Вот вам простая арифметика. Факты свидетельствуют, что если мы отвлекаем программиста даже на 1 минуту, мы отнимаем у него 15 минут продуктивной работы. К примеру, у нас есть два программиста: Джеф и Мат, находящиеся в небольшой открытой кабинке и сидящие напротив друг друга на обычной Дилбертской ферме по откорму телят. Мат забыл название Unicode версии функции strcpy. Он мог бы посмотреть её сам, для чего ему понадобилось бы всего 30 секунд, а мог бы спросить Джефа, на что ушло бы 15 секунд. Так как он сидит рядом с Джефом, почему бы ни спросить Джефа. Джеф отрывается от работы и теряет 15 минут продуктивной работы (чтобы спасти 15 секунд Мата).
Давайте теперь переместим их в отдельные офисы со стенами и дверями. Теперь, когда Мат не может вспомнить название функции, он может посмотреть его сам, что по-прежнему займёт 30 секунд или спросить Джефа, на что уйдёт 45 секунд и при этом ещё придётся и встать (нелёгкая процедура для большинства программистов, если принять во внимание их физическую форму!). Таким образом, он смотрит сам. Следовательно, Мат тратит 30 секунд, но при этом сохраняет 15 минут продуктивной работы Джефа. Вот как!
9. Используете ли вы самое новейшее и дорогое оборудование?
Запись кода на транслируемом языке — это одна из последних вещей, которую всё ещё нельзя мгновенно выполнить на домашнем компьютере. Если процесс компиляции занимает у вас больше нескольких секунд, купите себе самый последний, продвинутый компьютер. Это сэкономит ваше время. Если на компиляцию уходит 15 секунд, программисты умрут со скуки, пока дождутся завершения и переключатся на свои дела, что заставит их завязнуть в работе и убить часы продуктивной работы.
Отладка GUI кода при помощи одного монитора — вещь мучительная, если не сказать невозможная. Если вы пишите GUI код, два монитора справятся с задачей куда быстрее и легче.
Большинству разработчиков, в конечном счете, приходится использовать растровые изображения для иконок и панелей инструментов. А некоторые даже не имеют хорошего редактора растрового изображения. При этом просто смешно пользоваться Microsoft Paint, но это то, что многим программистам приходится делать.
На моём последнем месте работы системный администратор постоянно присылал мне спам, жалуясь, что на жёстком диске сервера на меня приходится — представьте себе — больше 220 мегабайт дискового пространства. Я обратил его внимание на то, что с учётом сегодняшних цен на жёсткие диски, цена того дискового пространства, которое я занимал, была значительно ниже цены туалетной бумаги, которой я пользовался. 10 минут, потраченные на освобождение моей директории, были бы невероятным ущербом для моей производительности.
Выдающиеся команды не мучают своих разработчиков. Даже небольшой срыв, вызванный низкомощностным оборудованием, нервирует и раздражает программистов. А раздражительный программист — это непродуктивный программист.
В дополнение ко всему сказанному программиста легко подкупить, предоставив ему самое новейшее и продвинутое оборудование. Этот способ мотивации обойдётся вам гораздо дешевле, чем выплата конкурентноспособного жалования.
10. У вас есть тестировщики?
Если в вашей команде нет тестировщиков, по крайней мере одного на 2-3х программистов, вы либо выпускаете продукты, кишащие ошибками, либо теряете деньги. Работа, выполненная программистом, обойдётся вам в 100$/час, а та же самая работа, выполненная тестировщиком — 30 $/час. Экономия на тестировщиках — это оскорбительно ложная экономия. Я просто возмущён, почему большинство людей не замечает этого!
11. Пишут ли новые кандидаты код во время собеседования?
Вы бы приняли на работу фокусника, не попросив его продемонстрировать свои фокусы? Конечно нет.
Вы бы обратились в фирму, обслуживающую свадьбы, не попробовав их еды? Сомневаюсь.
Тем не менее, каждый день программисты принимаются на работу под впечатлением от их резюме или потому, что интервьюеру понравилось с ними болтать. Либо им задавались примитивные вопросы ("в чём разница между CreateDialog() и DialogBox()?") , ответ на которые легко найти, заглянув в документацию. Вам не важно, запомнили ли они тысячи разных мелочей о программировании или нет, вам нужно понять, способны ли они программировать. Или даже ещё хуже, им задают вопросы типа "Ага!": тип вопросов, которые кажутся лёгкими, когда знаешь ответ, а когда не знаешь — они просто бесполезны.
Пожалуйста, перестаньте так делать. Делайте что угодно во время собеседования, но заставьте написать кандидата какой-нибудь код.
12. Проводите ли вы финальное тестирование по удобству и красоте использования программы?
Финальное тестирование по удобству и красоте использования программы — это процедура, при которой вы выбегаете в коридор, хватаете первого попавшегося человека и заставляете его попользоваться кодом, который вы только что написали. Если вы проделаете эту процедуру на 5 человеках, вы узнаете 95% иноформации о проблемах практичности в вашем коде.
Хороший дизайн пользовательского интерфейса — это не так сложно, как вы думаете. Это является ключевым моментом, если вы хотите, чтобы пользователи покупали и были довольны вашим продуктом.
Но самый важный момент, касающийся пользовательского интерфейса, — это то, что вы, показывая свою программу горстке людей (фактически 5-6 человек уже достаточно), очень быстро узнаете, какие проблемы у них возникали. Даже если у вас не хватает опыта в создании такого интерфейса, но при этом вы проводите тестирование по удобству и красоте использования программы, которое ничего вам не будет стоить, то с каждым разом он будет становится всё лучше и лучше.
Четыре способа использования теста Джоэла
Подсчитайте баллы, набранные вашей компанией.
Если вы менеджер, используйте эту статью как памятку, чтобы убедиться, что ваша компания работает настолько хорошо, насколько это возможно. Если вы набираете 12 баллов, то можете оставить своих программистов в покое и полностью сконцентрироваться на том, чтобы оградить их от назойливого начальства.
Если вы хотите устроиться программистом в компанию, спросите у вашего предполагаемого работадателя, сколько баллов набирает его компания. Если балл слишком низок, убедитесь, будут ли у вас достаточные полномочия, чтобы всё наладить и изменить ситуацию. Иначе, вы разочаруетесь и ничего не добьётесь.
Если вы инвестор и хотите через прилежность оценить уровень команды программистов или ваша компания готовится к слиянию с другой компанией, данный тест может дать вам быстрое решение — правило правой руки.
Если нам не помогут, то мы тоже никого не пощадим.
