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

Полная версия

Настройки чтения
Размер шрифта
Высота строк
Поля
На страницу:
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» общий буфер для программистов, и именно общий – для снижения вариаций. Именно поэтому программист назначает на себя задачу сам. – Оруженосец по памяти перерисовывал ЖЦ команды на листок, делая пометки. – А почему для тестировщиков так не сделать? Тоже общий буфер.

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

На страницу:
2 из 3