Байки для оруженосца

Благодарности

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

Особая благодарность Вере Даниловой за рисунки. Может они не самые красивые, зато они соответствую духу баек.

Спасибо всем.

Пока проект заморожен, но, если понадобится – разморожу.

Пролог. Некоторая информация о персонажах

– Править нужно сидя лицом к югу.

– А почему к югу?

– Важно, не то, что к югу, важно, что сидя.

Аримигер (Оруженосец) – недавний участник группы разработки. По уровню группы находится между стажером и начинающим. По уровню запросов рынка вышел за запросы рынка. Молодой парень, который совсем недавно попал в цепкие руки Королевы. До этого считал, что, отлично разбирается в своей специальности и в том, как работать в команде и над проектом. Теперь ему все чаще кажется, что он вообще ничего не знает. Глупо загадывать заранее, но, возможно, это та самая пешка, которая однажды дойдет до конца поля.

Королева. До сих пор не знаю, то ли она Красная, то ли Белая, то ли Черная. (По английской традиции в шахматах два цвета: белый и красный.) Руководитель разработки. Характер… Многие в соседних отделах считают Королеву грубой, но команда в ней души не чает. Руководитель команды. Потрясающая женщина. Страшная женщина. Железная женщина. Нет, кроме шуток. У нее стальные нервы, железная хватка, титановые яичники и чугунная задница. Поговаривают, что единственное, что у Королевы сделано не из металла – это сердце. Потому что оно каменное. Несмотря на все вышеперечисленное, обожает свою команду, и та отвечает ей тем же. Почти никто не может понять, как Королеве удалось собрать такую дрим-тим, ведь у большинства этих хмырей уважающий себя менеджер по работе с персоналом даже резюме смотреть не стал бы. А вот поди ж ты. Команда Королевы справляется с любыми заданиями, разгребает любые факапы, и если бы дело было в СССР, то вымпел «Передовики производства» поселился в их комнате навеки. Королева знает свое дело от и до и никогда не отказывается поделиться опытом с молодежью – чай, корона не свалится.

Все знают, что в фирме может смениться даже руководство, но Королева никуда не денется. А если захочет уйти, то с ней уйдет и вся команда. И их с радостью примут – хоть в НАСА, хоть в НАТО. На худой конец и «Микрософт» сойдет.

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

Безумный Шляпник – один из мастодонтов. На его кресле висит свитер, в котором, как утверждает сам Шляпник, он написал свою первую программу, на ЭВМ с ферритовыми сердечниками памяти. Этот свитер до чертиков пугает новичков – может, потому что он в неприятную красно-зеленую полоску, навевающую ассоциации с «Кошмаром на улице Вязов» и мальчиком, которого съела кровать. Впрочем, Шляпник и сам кого хочешь сожрет, без всякой кровати. Но если не испугаться свитера и спросить Шляпника о чем-нибудь по предмету, можно узнать кучу всего интересного.

Мартовский Заяц – тоже один из тех, кто переносил «Страну багровых туч» на восьмидюймовых дискетах и помнит времена, когда компьютеры были большими. Славен тем, что, когда вся команда бьется над участком кода и не может сладить, молча приходит, садится и пишет код, больше похожий на бессмысленный набор символов, который при этом, что удивительно, работает как часы. Главное – не лезть в него и не пытаться ничего менять.

Чеширский Кот – наглая, беспринципная, циничная сволочь с очень злым чувством юмора, граничащим с сарказмом. Иногда кажется, что он умеет быть сразу в нескольких местах одновременно. За рабочий день успевает пофлиртовать с девушками на ресепшене, попить чаю с тортиком с бухгалтерами и сыграть с гендиром пару раундов в «Need For Speed». Однако, когда злопыхатели пытаются уличить его в лености и невыполнении служебных обязанностей, выясняется, что у Чешира всегда все готово. Просто он умеет распоряжаться своим временем. Злые языки утверждают, что у него был роман с Королевой, но это совершенно не их дело.

А да, еще. Дисклаймер.

Я не несу ответственности за слова героев данных рассказов. И не несу ответственности за вред, который вы можете нанести себе чтением или применением советов из этих рассказов.

Уровень сложности не «Матан», но и не «Кэп». Берегите мозг.

Российский вариант «Алисы» не соответствует английской. У нас другой культурный контекст, плюс переводчики «Алисы» изменили гендерную идентификацию. Если случайно кто-то будет переводить на английский, знайте, что англичане перевода могут не понять. В «Байках» не Кэрролловские герои, а какие-то другие. Подробнее об изменении характера героев можно прочитать в статье «Багира сказала…» http://magazines.russ.ru/voplit/2009/2/eli12.html Рекомендую.

PS. Этюды для тестировщиков. В этом тексте есть интересная фича не относящаяся к теме обсуждения, которая кажется серьезной багой. Багу найти легко. Описать фичу – сильно сложнее. Welcome.

Байка для оруженосца 1. Немного о «вреде» тестирования

A. Тестировщики тормозят процесс разработки по Agile?

Q. Вопрос сформулирован неверно. Agile, не Agile – это перпендикулярное измерение. В малых проектах выделенный тестировщик тормозит процесс.

A. А в больших?

Q. Слишком часто тоже тормозит. Но по другой причине. В малых проектах имеет место эффект «чем больше команда, тем дольше делаем проект». В больших же имеем эффект «ограничение системы перенесено на самый дешевый участок».

A. Тестировщики необходимы.

Q. Не то чтобы необходимы, но иногда полезны. Иногда и только после того, как внедрены другие процессы.

A. Тестировщики нужны всегда!

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

A. Но ведь появление тестировщиков в индустрии принесло огромную пользу.

Q. В том виде, в котором происходило это внедрение – это скорее огромный вред. Модель разделения ролей «РУТ» (разработка, управление, тестирование) глубоко порочна.

A. Но без тестировщиков нельзя сделать сложный проект.

Q. Странно. Но делали же. Видимо, пацаны «не знали».

A. Тестирование позволяет лучше удовлетворить заказчика.

Q. Учитывая, что большая часть дефектов вносится в систему до кодирования, мне кажется, в высшей мере странным ставить ОТК только после кодирования. Контроль до кодирования принес бы куда больше пользы.

Байка для оруженосца 2. Управление работами не «пинание всех»

Было время вечернего чаепития, и оруженосец (armiger) пошел на запах кофе. В кухне с удобством расположилась Белая Королева (queen).

Я хочу стать руководителем проекта (далее РП). Что мне для этого делать?

Q. А зачем оно тебе? Работа скучная и неблагодарная. Если проект успешен, то это успех команды, а если не успешен, то это провал РП.

???

Q. Есть всего несколько вещей, которые РП должен делать. Одна из самых неприятных – это управление потоком работ.

Что же в этом неприятного и сложного? Ходи да пинай всех

Q. Управление работами вовсе не «пинание всех», – королева вздохнула – Ладно слушай.

РП пишет план.

План пишется РП.

Если некто не пишет план, то он не РП.

По-другому иногда бывает, но сейчас этим можно пренебречь.

Не РП тоже может писать план. Это нормально.

Продолжительность программного проекта – вариативная величина.

И сильно вариативная. Коэффициент от 1 до 16, при среднем 4.

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

Продолжительность работы имеет больший разброс, нежели продолжительность проекта.

Выдающиеся специалисты по качеству (Шухарт, Деминг, Голдратт) имели выдающиеся знания по теорверу и статам.

Выдающиеся теории управления: TQM, TOC, 6 сигм, … – построены на теорвере и статах.

Не знающий центральной предельной теоремы и прочего теорвера со статами будет планировать плохо.

Диаграмма Ганта не подходит для планирования программного проекта.

Диаграмму Ганта можно использовать для создания календарного графика, но не плана.

Диаграмму Ганта не стоит использовать для планирования программного проекта.

Использование диаграммы Ганта для планирования программного проекта ведет к увеличению срока проекта.

Для ускорения хода проекта откажись от диаграммы Ганта. В крайнем случае используй ее после других инструментов планирования.

Как составить план без диаграммы Ганта? – не мои проблемы. Ты умный, у тебя высшее образование.

Программные проекты сложным образом зависят от величины команды.

Для проектов порядка 1000 функциональных точек (60KLOC на С) команда из 5 человек работает быстрее, чем команда из 10 человек, а команда из 10 быстрее, чем команда из 20.

«Шестой лишний» – хочешь ускорить небольшой проект – отстрани от него шестого и более участника.

Если это неправда, то в твоем проекте очень серьезные проблемы. Просто ты о них не знаешь.

А может и нет.

Время выполнения операции зависит от исполнителя.

Время выполнения операции сильно зависит от исполнителя.

Время выполнения операции очень сильно зависит от исполнителя.

Трудоемкость операции без исполнителя – это профанация.

Нужна трудоемкость без исполнителя? Измеряй в попугаях.

Считаешь, что измерение в попугаях – это детский сад? Измеряй в слонах.

«Я не боюсь показаться смешным. Немногие могут себе это позволить.»

План состоит из описания результатов, а не описания действий.

Поставить готовиться мясо – это плохой пункт плана, мясо приготовлено – хороший.

РП, нацеленный на результат, пишет план в терминах результатов.

Хороший РП пишет хороший план в терминах результатов.

РП, нацеленный на процесс, пишет план в терминах действий.

Плохой РП пишет плохой план в терминах действий.

По-другому тоже бывает. Но это вряд ли твой случай.

Пункт плана не может иметь исполнителя.

Пункт плана может иметь ответственного.

Пункт плана не имеет трудоемкости.

Это не совсем так, но в целом верно.

Пункт плана не имеет срока завершения.

Пункт плана может иметь временные зависимости/ограничения.

Не пытайся понять это сразу, просто вернись к этому через какое-то время.

Для ускорения хода проекта планируй неполную загрузку сотрудника.

Полная загрузка всех сотрудников на проекте, как правило, приводит к параличу проекта.

Вряд ли у тебя получится рассчитать запас по мощности точно. Не сможешь рассчитать – используй эмпирические 25%.

A. Но это какая бессмыслица!

Q. Не обязательно бессмыслица то, что противоречит общепринятым практикам. Если бы Генри Форд делал автомобили так, как принято, мы до сих пор бы ездили в каретах.

A. Нельзя поверить в невозможное!

Q. Просто у тебя мало опыта. В твоем возрасте я уделяла вере в невозможное полчаса каждый день! В иные дни я успевала поверить в десяток невозможностей до завтрака!

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

Байка для оруженосца 3. Пятница тринадцатое или прикладное неестествознание в старый новый год

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

Легкой походкой на кухню влетела Королева.

CC. Ваше Величество, вы светитесь, как будто вы Ваша Светлость. Нет, даже как Ваше Сиятельство.

Q. О, да, мой вечно исчезающий друг. На этой неделе мне удалось прибить две дюжины вампиров!

CC. Отличный результат! На прикладе вашего плюсомета скоро не останется места для новых отметок.

A. Какие вампиры?

CC. Вампиры, молодой человек – это такие создания, которые пьют кровь или жизненные силы.

A. Спасибо, кэп. Но все-таки?

Q. Не все проекты, которые делаются в фирме, одинаково полезны. Рано или поздно в фирме заводятся проекты-вампиры. Они бесполезны или относительно малополезны. Они пьют жизненные силы организации. Когда их заводится слишком много, организация хиреет и даже может умереть. Но к счастью, еще много миллионов проваленных проектов назад, шаманы, из трибы бизнес аналитиков разработали амулет, отпугивающий проекты-вампиры. Использовать силу этого амулета легко. Достаточно твердо придерживаться двух правил: «Не запускать проект, если нет напечатанной карточки проекта», – и королева направилась наливать чай, всем своим видам показывая, что разговор окончен.

A. А второе?

Q. Как?! Ты прослушал?! Ты прослушал «Второе правило»?! Тогда слушай внимательно еще раз и не говори, что не слышал. Молодежь попробует вести эти карточки в вики, трекстудии или в праймовере. Это само по себе не плохо. Но только настоящие, посвященные шаманы знают, что отпугивающим эффектом обладает лишь бумажная карточка, которая лежит в папке Сумера в тумбочке Галант с наклеенным цветным стикером резолюции.

A. Почему «Сумера»?!

H. Потому что коза – Зойка. В этом деле мелочей не бывает – раздалось с углового стола.

Королева неодобрительно покосилась в угол

Q. – Потому что править нужно сидя лицом к югу. – и продолжила -

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

A. Вы сказали бесполезные? А что бывают вредные?

Q. Сколько угодно.

A. Против них этот амулет действует?

Q. Нет. Против вредных проектов нужно более сильное колдунство. Кроме того, есть еще проекты-зомби. Их также сложно отпугнуть этим амулетом.

A. Мадам, а не могли бы вы показать пример карточки?

Q. Нет. – Отрезала королева. – Все запасы амулетов были израсходованы в ходе похода против нежити. -Подумав, королева добавила – И нечисти.

На самом деле Королеве отчаянно хотелось чаю, а этот несносный мальчишка никак от нее не отставал.

CC. К счастью у меня завалялась парочка. – Чеширский кот с видом фокусника достал шляпу, отданную ему Шляпников в обмен на услугу. – Вуаля! – и он вручил оруженосцу листок формата A4.

Мартовский Заяц и Шляпник вскочили и в панике забегали по кухне.

H&MH. Карточка! Карточка! Караул, карточка!

Q. Фигляры, – неодобрительно бросила королева. Впрочем, строгость была напускная. Королева прекрасно знала силу этого тандема. Эта парочка аналитик-программист давала фору команде из двух десятков человек. Хотя получать лулзы от их закидонов умели далеко не все. Королева умела. За что ее особенно ценило руководство. Ходили слухи, что руководитель департамента разработки бросил пить после того, как королева забрала этот тандем к себе. И отменил еженедельные отчеты. Чем поверг всю организацию в ступор. Ну, отчеты ладно, с кем не бывает. Но бросить пить!

Армигер начал внимательно рассматривать листок, а Чеширский кот в это время комментировал.

CC. Оформление делается шрифтами Verdana или Tahoma, 12-ым кеглем. В исключительных случаях для проектов с высоким коэффициентом полезности допускается 11-й кегль.

A. Но здесь же катастрофически мало места! Почему бы не расширить на две-три страницы?

CC. Если карточка проекта будет оформлена на двух страницах, то она немедленно отправится в корзину.

A. А почему здесь нет больших проектов?

CC. Большому проекту – большую торпеду. A3.

MH. Убил. – немедленно откликнулся Безумный Мартовский Заяц.

A. А если полезность будет на границе, то значит можно считать не целое число, а 0.1, 1.5

CC. Не стоит.

A. Почему?

Q. Ты соврал в резюме, что учился в институте? – спросила королева ледяным тоном.

A. Э-э-э…

CC. Королева намекает, что еще на первом курсе вашего института студенты изучают правила расчета погрешностей. Не использовать эти знания на практике довольно глупо. Не находишь?

Армигер смутился.

A. А вот здесь ошибка. Коэффициент полезности должен вычисляться, как одно делить на другое. А здесь минус…

Q. Я уже сказала: «Головы с плеч»? – глядя в пространство спросила королева.

H&MH. Нет, моя госпожа – синхронно ответили Шляпник и Заяц и также синхронно втянули головы в плечи изображая крайний испуг.

CC. Ну же, мон шер – Чеширский Кот был сама любезность, – вы же учили математику.

A. Да – смущенно признался Армигер – Матан, Теорвер, ТФКП, …

CC. Вздор – прервал его Кот, – здесь вполне хватит школьной программы.

Армигер застыл посредине комнаты. По его лицу было понятно, что он напряженно думает.

MH. Чу! Слышу! У него скрипят шестеренки!

H. Их необходимо срочно смазать.

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

MH. Королева сегодня сурова.

H. Что ты, королева – добрая душа. Я помню, три дня назад тут поймали японского шпиона…

Дружный хохот наполнил кухню. Новый год в команде начинался нормально.

Байка для оруженосца 4. Основной продукт процесса тестирования программного обеспечения

За окном цвели каштаны, а в столовой в самом разгаре было очередное безумное чаепитие. И в очередной раз оно из простого чаепития превращалось в заточку пилы.

– Опять тестирование, опять релиз на две недели позже, – Мартовский Заяц был как всегда нетерпелив.

– Но как же без тестирования? – удивился Армигер.

– Знаете, коллега, я в чем-то согласен с Мартовским. Выхлоп, в смысле числа обнаруженных багов, практически нулевой. Так что в данном случае паникеры и перестраховщики мешают бизнесу, – поддержал Зайца Безумный Шляпник. Это был обычный дружеский троллинг.

– Так мы проводим тестирование не для того, чтобы выявить дефекты, а для того, чтобы получить информацию о качестве. – И оруженосец с чувством процитировал: – Тестирование программного обеспечения – процесс исследования программного обеспечения (ПО) с целью получения информации о качестве продукта.

– Ты имеешь в ввиду статью в википедии. Да там ошибок больше, чем изюминок в праздничном кексе! – подключилась Королева – Кстати, в википедии могли бы и указать автора сего дивного заблуждения.

– Но это же кто-то из экспертов!

– Ну и что? Сам великий эксперт Аристотель заблуждался относительно характера движения тел, падающих на землю. – И Королева начала свой монолог.

– Как это ни печально, но люди, пишущие техническую литературу о разработке ПО, очень редко используют научный метод мышления. Они порой много говорят о вещах, совершенно необходимых нашей индустрии; и это всегда, как можно в том убедиться, весьма наивно и, по всей видимости, ошибочно. [1]

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

Теперь возьмем утверждение, что основным артефакт процесса тестирования является информация о качестве. Первый шаг, который должен сделать человек, мыслящий рационально, – это преобразовать утверждение в гипотезу. Гипотеза: «основным артефакт процесса тестирования является информация о качестве».

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

Если мы стараемся мыслить рационально, то необходимо перевести гипотезу в разряд научной. А для этого нужно придумать фальсифицирующий эксперимент. Например, «Если, имея информацию о качестве, проект нельзя успешно завершить, то гипотеза признается ложной».

Далее мы переходим к экспериментам. Наблюдение, размышление и эксперимент – вот что составляет так называемый научный метод. [2]

В одном королевстве жила-была фирма, поставлявшая решения в сфере финансовых транзакций. Однажды фирма решила выпустить новый продукт – «пластиковую дуальную смарткарту». Надо сказать, что ошибки в продуктах для финансовых транзакций обходятся довольно дорого. Достаточно вспомнить ошибку с авизо.

Логично, что крупные финансовые структуры подходят к проверке качества достаточно серьезно. Для того чтобы выйти на рынок, необходимо пройти довольно серьезную проверку сертифицирующего центра. Для первичной проверки карты необходимо всего лишь заплатить двадцать тысяч. Не рублей.

После этого можно один раз скормить карту терминалу. А терминал выдает бинарный ответ «Карта подходит для дальнейших проверок» или «Карта не удовлетворяет требованиям». Отличная, точная информация о качестве.

С первого раза пройти проверку не получилось. Со второго тоже. С третьего тоже. Через несколько лет у руководства компании зародилось подозрение, что что-то здесь не так, и нужно что-то делать. Был выстроен процесс тестирования, и всего через год карта прошла первое испытание.

Несмотря на наличие информации о качестве, проект невозможно было завершить успешно. Несмотря на наличие информации о качестве, пришлось создать процесс тестирования. Таким образом, изначальная гипотеза не прошла экспериментальную проверку.

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

И здесь мы можем выдвинуть новую гипотезу: «Основным артефактом тестирования, проводимого заказчиком, может быть информация о качестве. Также заказчик может не передавать исполнителю и никак в дальнейшем не использовать побочный для заказчика артефакт, такой, как информации о расхождении. Но для процесса тестирования, проводимого исполнителем, информация о расхождении между поведением системы и ожиданием заинтересованных лиц является основным производимым артефактом»

В комнате повисла пауза.

– Но тогда почему первичное определение встречается чаще остальных? – робко спросил Армигер.

– Мой юный друг, стремящийся к знаниям, попробуй взглянуть на это с точки зрения эффектов «Ошибка приоритизации гипотез» [3] и «Знаний задним числом». И выдели на изучение этих когнитивных искажений хотя бы пару часов – Выдержав паузу, Чеширский Кот подвел итог перерыву: – По коням друзья. Заказчик еще не верит, что качество нашей системы достойно их серверов.

PS. Вместо послесловия. Через несколько дней Армигер обнаружил в почте ссылку на статью об экспертах http://u-96.livejournal.com/2507992.html

[1] Искаженная цитата из второй главы первого тома лекций Фейнмана по физике

[2] Смотри вторую главу из первого тома лекций Фейнмана по физике

[3] Цитата:

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