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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Чеширский Кот – наглая, беспринципная, циничная сволочь с очень злым чувством юмора, граничащим с сарказмом. Иногда кажется, что он умеет быть сразу в нескольких местах одновременно. За рабочий день успевает пофлиртовать с девушками на ресепшене, попить чаю с тортиком с бухгалтерами и сыграть с гендиром пару раундов в «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] Цитата:

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

Байка для оруженосца 5. Использование вариантов использования

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

На кухне собралась обычная компания, только Королевы не было. На вопрос об ее отсутствии ответил Чеширский Кот:

– Сейчас она проект толкает. Вообще, у хорошего руководителя проекта основная работа приходится до старта проекта, на старт проекта, перед финишем и после финиша.

– А в середине проекта можно и в отпуск сходить – с завистью заметил Мартовский Заяц.

– Или журналы почитать – добавил Безумный.

– Как Быков в «Стажерах»? – догадался Армигер.

– Как Быков – согласился Чеширский – Быков, он хороший руководитель. Очень хороший. И хорошо, что он термин «менеджер» не слышал. Но довольно, молодой человек, об этом. Если есть время, его нужно использовать. Чем вы сейчас занимаетесь?

– Требованиями. Ревизией и выбором формата, – отрапортовал Армигер.

– Хорошее дело. И как обычно, есть несколько «но». – Чеширский помолчал и спросил: – что вас беспокоит, мой друг? И давайте на сегодня ограничимся одним вопросом. Что сейчас вас беспокоит сильнее всего?

– Юзкейсы – понурился Армигер.

– Если беспокоит – не чеши. Лучше маслом помажь, – порекомендовал Заяц.

– Погоди, – вмешался Чеширский, – не путай его. Давайте я выдвину несколько гипотез – и, после того, как Армигер кивнул, продолжил, – вероятно, вас смущает, что их часто рекомендуют, но редко пишут; что есть юзкейсы, а есть диаграмма юзкейсов, что если есть BPML и IDEF, то зачем нужен текстовый формат?

– И если их так настойчиво рекомендуют, то они должны иметь массу преимуществ.

– Главное преимущество вариантов использования, это то, что они варианты использования, – отрезал Шляпник и демонстративно посмотрел на свою коллекцию часов.

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

– Так ты еще, чего доброго, скажешь, что «разработка требований» и «требования к разработке», – одно и то же, – вмешался Заяц.

– Так ты еще скажешь, – проговорила, не открывая глаз, Соня, – будто «тестирование производительности» и «производительность тестирования», – одно и то же.

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

– И что?!

– А вот это интересный момент, – подключился Шляпник, – смотри. Приходит на собеседование программист. SQL знает, базы данных проектировал. Даем задание: «База данных должна содержать историю курсов валют Центробанка. Спроектируйте необходимые таблицы». Обычно рисуют что-то вроде такого.

Поля:

идентификатор записи;

код валюты;

курс по отношению к базовой валюте;

начало действия курса.

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

where <дата на которую производится выборка> between <Начало действия курса> and <Окончание действия курса>

Бывают и более интересные прецеденты.

Шляпник повернулся к Зайцу:

– Помнишь программиста, который предлагал в одной таблице хранить актуальные данные, а во вспомогательной сделать архив?

– А то! – откликнулся его напарник.

– А тут-то что не так? – спросил Армигер.

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

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

Далее слово взял Чеширский Кот:

– Описание использования системы позволяет избежать множества проблем. Возьмем ту же JRA-1330. Серьезнейшая ошибка, «критикал». Сколько клиентов просило ее исправить! Но исправить ее невозможно. Об этом довольно неплохо написал Максим Крамаренко. А избежать ее было очень просто. Достаточно было описать, как эта трекинговая система будет использоваться. Например, как она будет использоваться для взаимодействия между заказчиком и исполнителем. И тогда бы всплыло, что менеджмент-исполнитель захочет скрыть сумму контракта на доработку от простого исполнителя, а потраченные часы скрыть от заказчика. Всего-навсего – описать способ использования системы.

Ладно, коллеги, на сегодня разминка окончена, прошу к рабочим столам.

Кот встал, потянулся и начал исчезать. Армигер вздохнул, глядя на повисшую в воздухе улыбку, и пошел на рабочее место.

Байка для оруженосца 6. Куб Неккера

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

– У, какая знакомая табличка, – вдруг заявил Мартовский.

Армигер чуть не подавился чаем и, кажется, с трудом сдержал порыв прикрыть листочки рукой:

– Да откопал тут в недрах интернета таблицу сочетаемости проектных ролей. Изучаю.

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

– У нас есть печеньки, – пропели в унисон Шляпник и Заяц и зловеще захохотали. Потом так же хором добавили: – сейчас мы эти таблицы анализировать будем.

– Перехожу, перехожу, – кивком головы выразив благодарность, Оруженосец взял печенье. – Действительно, я откопал несколько разных таблиц. Более-менее соответствующих друг другу, но отличающихся в деталях.

– И что, роль программиста везде не может сочетаться с остальными?

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

– Замечательно, – повернулся от окна Кот – Следующий ход?

– Поискать общее, – внесла предложение Соня.

За столом зашелестели бумажками.

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

Быстро проглядев листки, троица подтвердила вывод Сони.

– Иии? – просил с нажимом Заяц, и команда синхронно повернулась и выжидательно уставились на Оруженосца. Только Королева не стала отвлекаться от медитации над своим пауэром.

Но оруженосец уже довольно долго посещал тренировки на мышление в условиях стресса и не сплоховал:

– Модель MSF предлагает создавать минимальные коллективы не менее чем из трех человек. Не анализируя глубоко остальные модели, мы на основании несочетаемости ролей тестировщика и программиста можем выдвинуть гипотезу о том, что минимальный коллектив для создания относительно сложного ПО во всех моделях должен состоять минимум из двух сотрудников. Но это противоречит тем фактам, что: а) множество сложных больших продуктов создавались людьми в одиночку, б) в команде XP тестировщиков нет, что не мешает им быть успешными.

– Неплохо, – резюмировал Шляпник.

– Растешь, – хлопнул по плечу Заяц.

Соня одобрительно хмыкнула и мгновенным движением ухватила печенюшку.

– Но, вообще говоря, этого недостаточно, – начал анализ Чеширский. – Можно возразить, что XP-шники используют свою модель для уменьшения потерь на вариациях. Или что в проектах на полсотни инженеров разделение будет выгодно. Или, что если уже есть разделение на программистов и тестировщиков, то выгоднее запретить изменять роль в рамках проекта, чем не запретить. Для проверки последней гипотезы было бы очень удобно взять несколько параллельных вселенных с одинаковыми командами и одним разрешить, другим запретить. С параллельными вселенными у нас сегодня не получится, поэтому попробуем придумать эксперимент попроще. У нас есть тестировщик Соня. Она регулярно пишет сложные SQL-скрипты. Часто у нее уходит на это полчаса, хотя камрады справились бы с этим за пару минут. А недавно она написала модуль импорта отчетов в Excel. Вполне нормально написала. А еще у нас есть программисты. Которые регулярно пишут тестовые наборы и тестируют по ним. Вы зачем это делаете?

Заяц с Шляпником пожали плечами. Для них вопрос не имел смысла, так как ответ был очевиден.

– Так можно сделать проект быстрее, – ответил Заяц и обратился к Соне: – Ты ведь модуль тоже писала, потому что так быстрее?

– Ну да, – ответила Соня.

– Заметим, наши коллеги в рамках одного проекта регулярно переключаются из одного ролевого кластера в другой. И все отмечают, что это переключение позволяет сделать проект быстрее. Замечу также, что у Сони это переключение происходит несколько легче, чем у остальных. – Увидев непонимающие взгляды, Чеширский пояснил: – Как программисты, да и как тестировщики вы посильнее Сони будете, но вот переключение между ролями для нее менее болезненно.

Участники безумного чаепития согласно кивнули.

– А теперь! – и жестом фокусника Кот достал из шляпы лист бумаги и протянул компании.

– Что это?

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

Коллеги кивнули.

– Вы можете увидеть, что серая грань находится спереди?

Еще кивки.

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

– Полагаю, это не единственное ограничение, которое вам встретится в разработке ПО. Очень вероятно, что стоит явно разделять написание плана в терминах результатов, английское planning, и написание другого документа в терминах действий, английское scheduling. Попытка думать одновременно в двух контекстах, как правило, приводит к появлению забавных…

– Уродцев, – закончила Королева. – И хватит на сегодня. У нас еще релиз не выпущен.

Байка для оруженосца 7. Два вида списков задач

С самого начала рабочего дня Армигер скучал в чаепительной. За окном цвели яблони, а ему было нечего делать, и он составлял кроссворд на основании терминологии ISTQB. Кроме оруженосца в кухне был Чеширский, но он изучал какие-то документы. Но вот кухню омыла волна программистов во главе с Шляпником и Мартовским Зайцем.

– Хай.

– Привет.

– Доброе!

– Кому доброе, а кому и… – проворчал Оруженосец.

– Ничего. Придет время, и под твоей клавой навернется релиз-кандидат.

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

В кухню вошел Черепах Квази. Шум стих.

– Представляете, захожу я сейчас в 42-ю, а там никого нет. Только Соня книгу читает, – сказал Квази, ни к кому конкретно не обращаясь.

– И что? – возмутился Шляпник. – Рекса Блэка надо читать.

– И больше там никого нет. Это все потому, что у вас таймшитов нет.

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

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

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

На тушение пожара выдернули команду Королевы. В майские праздники. Вроде бы откат сделать не проблема. Но не проблема, только если инженеры соблюдают культуру разработки. Как говорится, тяжело править код за программистами, путающими бранч и транк. Да и релиз в пятницу вечером перед большими праздниками нарушал все мыслимые нормы безопасности. За два безумных дня команда Королевы много говорила о своих коллегах. Как подытожила Соня: «Если бы стены могли проявлять впитанные слова, то в первый же день они бы стали похожи на подъезд в Нижнем Тагиле, а на второй почернели бы полностью.»

– Но в чем-то он прав, – сказал Оруженосец. – Я с утра не слишком загружен.

Заяц и Шляпник переглянулись.

– Я сделаю сенчу. – Шляпник отправился к шкафам, а Заяц подсел за стол оруженосца.

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

– Разработчики работают по списку задач. И этот список может быть одного из двух типов. С недостатком задач или с избытком. Для первой линии техподдержки, админов и т.д. предпочтительным является список с недостачей. Для программистов, как правило, предпочтительным является список с избытком, но иногда применяют и список с недостачей. Например, если программист дежурит на техподдержке. Применение списка с недостачей означает, что разработчики обязаны часть времени простаивать. Обязаны! Если не простаивают – надо вызывать на ковер менеджера. Список с избытком означает, что часть задач обязана быть не сделана. Если делаются все задачи, опять же, нужно разбираться в проблемах управления. Представь, что мощность отдела программистов 100 единиц продукции в неделю. Для списка с недостачей рекомендуется, чтобы входящий поток заказов был в 70-80 единиц. Т.е. разработчики должны простаивать порядка 25% времени. Если используется список с избытком, то входящий поток должен быть отрегулирован на 130 – 200 единиц. Примерно вот так:

Светлые зоны – это хорошо настроенный поток. А темная – плохо.

– А если все-таки сделать сбалансированный поток?

– Если его попробовать сделать, то будет как у Квази. К счастью, сбалансированные цепочки встречаются редко.

– Сложно настроить?

– Нет, – подключился Кот, – настоящая причина того, что сбалансированные цепочки встречаются редко, намного более фундаментальна. Дело в том, что чем ближе ты к состоянию идеального баланса, тем ближе ты к банкротству.

– Хорошо, предположим. В дальнейшем я хотел бы увидеть модель, но сейчас я поверю опыту Чеширского Кота. – согласился Оруженосец. – И как настроено у нас?

– У нас список с избытком. Ты ведь знаешь, что часть задач закрывается триггером по истечении срока давности.

– Да, согласен. Но почему мы с Соней сегодня простаиваем?

– Потому что в производственной цепочке должно быть не более одного рабочего центра с избыточным списком задач. Этот рабочий центр называют ограничением системы. В нашей команде ограничением системы является группа программирования. И это правильно. Все остальные рабочие центры, такие как: менеджмент, тестирование, продажи, анализ – обязаны простаивать. Обязаны! Данный факт не согласуется с нашим представлением о мире и приводит к психологическому дискомфорту. Любой хороший список задач, что с недостачей, что с избытком, приводит к психологическому дискомфорту.

– Ага, – Шляпник поставил чайник с сенчей на стол, – среднестатистический менеджер приходит в истерику, услышав о современных методах управления. У него пропадает аппетит, начинается изжога, и в общении он становится крайне неприятен.

– Все верно, коллеги. – К их столу подошел Чеширский Кот. – А тебе, юноша, необходимо как можно быстрее ознакомиться с современными методами управления и перестать комплексовать по поводу своих простоев. А то так и до нервного срыва недалеко.

– Ладно, камрады, по коням. К вечеру сделаем финальный мердж и отдадим билд на тестирование. А ты пока кроссворд закончи.

– А с таймшитами то что?

– А про них в следующий раз.

– А матмодель?

– А матмодель сбалансированной цепочки посмотри в блоге Макса Крамаренко.

Байка для оруженосца 8. Жизненный цикл задачи на изменение кода

Сегодня в кухоньке были все свои. Чеширский, Заяц с Шляпником, Соня и, конечно, Королева. Небольшой «чай-брейк» после релиза. Команда всегда делала небольшие паузы между большими блоками задач. Только Армигера не было. Его послали в небольшую командировку. Порулить в несложном проекте с чужой командой.

Соня, как всегда, дремала, лениво перелистывая очередную статью по тестированию, Шляпник с Зайцем азартно вели один из вечных споров типа «Пробелы-Табуляции», иногда скатываясь к проблемам генерации идентификаторов, а Королева с Чеширским просто пили чай. 15 минут это немного. Но и не мало.

– Я не опоздал? – с порога спросил Армигер.

– Заходи, заходи. Пока чай льдом не покрылся. Сегодня мы пьем какой-то редкий сорт, который Чеширский привез из Китая. – И Шляпник наклонил чайник над кружкой с эмблемой какой-то конференции.

– Позавчера сам собирал. На плантации старого приятеля. Цените. – Поистине, связям Чеширского Кота оставалось только позавидовать.

Армигер порывался что-то сказать, но на него цыкнули. Все синхронно подняли чашки, сделали по глотку, и на лицах отразилась гамма чувств.

– Ладно, давай, выкладывай, а то тебя разорвет.

Армигер вытащил листочки с распечатанными жизненными циклами задач (воркфлоу).

– Вот. Глядите, как можно все тщательно настроить в Jira, – начал Армигер. – Вот по этой схеме мы всегда знаем, в каком состоянии находится доработка.

Шляпник взял в руки листок с безумной паутиной статусов и переходов. Покачал головой и показал листок Зайцу. Зайца перекосило. Он в сердцах помянул 21-е прерывание и барабанный принтер со снятым кожухом.

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

– Нет, но мы собираемся так настроить. Парень новенький принес.

– Соня! – гаркнул Заяц.

Соня вышла из медитации и начала говорить речитативом:

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

– Насколько? – голос Шляпника походил на голос ласкового дознавателя в подвалах Веселой башни.

– Не помню. Гуглить надо. 1.2-1.3 раза. Плюс примерно квадратично растет число переходов. А это тот же коэффициент.

– Грубо возьмем, что добавление трех статусов приводит к проблемам с пониманием в два раза. Увеличивая число статусов задачи с пяти до двадцати трех, мы увеличиваем проблемы с восприятием в 60 раз. 60 раз, Карл!

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

– Ну, не надо так резко, – вмешался Кот.

– Так много? – удивился Армигер.

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

– А потери на управляемости так вообще зашкаливают, – добавила Королева. – Чем меньше статусов у задачи, тем быстрее идет проект. Но всегда есть «но».

– Наименьшее число статусов задачи… – Соня сделала паузу.

– Два. Естественно, два, – синхронно ответили Заяц с Шляпником.

– Но! Но! – Соня проснулась и была в ударе. – Это отлично работает для волка-одиночки. А скажи мне, родной, как мне проверить выполнение какой-то задачи? Как я узнаю об этом? Я тестировщик! Кстати, меня за это уважают… Как я узнаю, что какую-то из решенных задач… – Соня провела глазами по комнате, и Заяц с Шляпником прижали уши.

– Не стесняйся. Мы знаем, что делаем ошибки. Ты ищешь их быстрее, чем мы. Нам нравится работать с тобой в паре. – Было непонятно, кто это сказал, но все всё поняли.

– Так вот. Какую из задач мне тестировать? Нужен новый статус, – продолжила Соня. – И этот статус мне нужен! Нужен мне!

– Очевидно, – резюмировал Шляпник.

– Без вариантов, – отрезал Заяц.

– Ладно. Три минимально. Хорошо, я понял, что много – это много. У нас именно эти пять. Почему? – спросил Оруженосец.

– Есть давление снизу и сверху, – Кот сделал глоток чая, – мы должны использовать минимально необходимое. Н-да… Коллеги, расскажите, что вы об этом думаете.

Королева взяла слово:

– Каждый лишний статус – это потери. Большие потери. И нужно понимать, почему вы на эти потери идете. Мы идем. Со статусами «New» и «Closed» – все понятно. Они просто нужны. Соне нужен статус «Resolved» как информация о необходимости тестирования. Кстати, мне этот статус тоже совершенно необходим, для отслеживания загрузки рабочих центров. Если в среднем в этом статусе больше 20 задач на пять тестировщиков – очень вероятно, что у нас проблемы с тестированием. Очень серьезные. И с проектом в целом тоже. Показатель числа задач в этом статусе – это как температура. Если на градуснике 38,5, то что-то надо делать. Например, сменить градусник. Теперь «Assigned». Этот статус показывает, что задача назначена в релиз. Можно еще указывать конкретного исполнителя, но в этом смысла нет. Сами разберутся. В конце концов, у нас работают взрослые люди. Это позволяет делать легкую фильтрацию задач, на которые менеджеру продукта уже не надо обращать внимание. Менеджер работает со статусом «New». Это его зона ответственности. Не разработчика.

– А «Open» (примечание: иногда называют «In work»)?

– А этот статус нужен, когда над кодом работает не один программист. И когда программисту не нужна нянька, чтобы отобрать задачу из релизного пула. А те, кому нянька нужна – у меня не работают. Мой час стоит довольно дорого, чтобы работать простым диспетчером.

Это была правда. Кроме чисто менеджерской нагрузки Королева еще ухитрялась писать спецификацию требований для десятка программистов. К счастью, в последнее время ей начала помогать Соня. Да и Шляпник с Зайцем иногда писали постановки.

– Перед тем как уйти в бранч, программист обязан перевести задачу в «Open». Это сигнал всем остальным программистам – не трогай, работаю! Или по-другому: этому больному лекарство уже дали. Не надо второй дозы.

– А если не переведет статус – бить. Больно. Ногами, – добавил Заяц.

– Угу, – сказал Шляпник, – меня как-то пригласили помочь с кодом в один из проектов. У них одну и туже фичу реализовали три разных программиста. Тремя разными способами. И спокойно залили это в транк. Потом туда заливали еще три недели. Тестирование у них было ограничением системы, и эту фичу протестировать не успели. И в один замечательный солнечный день промышленный сервер сплясал джигу-дрыгу. Да так качественно сплясал, что заказчика валерьянкой отпаивали. А программистов спасло только то, что пока заказчик ходил за «Сайгой» на стоянку, программистов успели спрятать в серверной за железной дверью. Лихие 90-е, что ж вы хотите.

– И этих статусов вполне достаточно, – закончила Королева.

– Ага. «Assigned» общий буфер для программистов, и именно общий – для снижения вариаций. Именно поэтому программист назначает на себя задачу сам. – Оруженосец по памяти перерисовывал ЖЦ команды на листок, делая пометки. – А почему для тестировщиков так не сделать? Тоже общий буфер.

– Смысла нет. Если случайно один и тот же код протестируют три тестировщика, то транку от этого хуже не будет. Иногда такие эксперименты даже нужно делать. Для замера качества тестового покрытия и снижения вариаций в описании дефектов. Тем более что в правильно выстроенном производстве у тестировщиков должен быть запас по мощности.