М.Болтон: Оценка проекта и Черные Лебеди. Часть 1.

Вольный перевод статьи Майкла Болтона Project Estimation and Black Swans (Part 1)

В последние месяцы в сети активно обсуждалось оценивание:

• Ward Cunningham написал в твиттере: "Оценивание - выдуманная проблема, на решение которой профан тратит десятки дней"
• Pradeep Soundararajan опубликовал в блоге развернутую статью, посвященную оценке затрат на тестирование.
• Некто, назвавшийся Nathaniel'ем, изложил интересную точку зрения на успешные оценки на сайте Terralien.
• Jens Schauder опубликовал 8 причин, почему оценки слишком низки.
• Andre Dhondt недавно подключился к спору со статьей “Оценки ведут к убыткам, резервы приносят пользу”. (Вообще-то я не согласен. Резервы не приносят пользу, а вносят некоторый вклад в создание благоприятных условий, позволяющих создать нечто полезное. Достаточное количество резервов позволяет снизить угрозы.)

Все это сподвигло меня опубликовать результаты некоторых численных экспериментов, начатых в ноябре 2009-го и основанных на мысленном эксперименте, придуманном Джеймсом Бахом (James Bach). Эта работа совпадает по времени с Лебединой Песней, колонкой для Better Software, в которой я обсуждал книгу Талеба (Nassim Nicholas Taleb) "Черный Лебедь".

Черный Лебедь - невероятное и неожиданное событие, меняющее наше представление о реальности и обладающее тремя качествами. 

Правильный багрепорт 2: точность описания и исследование проблем

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

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

Авралы как производная от качества планирования

Долгое время я считал авралы/переработки делом обычным - как в IT без этого? Но со временем я стал задумываться и понял, что все не так просто. В целом, понятно, что аврал - производная от планирования. Если мы что-то хотим сделать, но не успеваем, то приходится работать дополнительно по вечерам и/или в выходные. Нюанс в том, почему сложилась такая ситуация. Я выделил для себя три причины авралов со следующими условными названиями: ошибка планирования, тенденция планирования и отсутствие планирования.

Подробнее о каждом из типов.

Аттестация в жизни технического человека.

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

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

[HDI] Увеличение своп-файла Linux без изменения разделов диска

Если вдруг потребовалось увеличить swap раздел на Linux'овой машинке, а править текущее разбиение диска на разделы не хочется, то можно поступить так:

# dd if=/dev/zero of=/var/swap bs=1M count=1048
# chmod 0 /var/swap
# mkswap /var/swap
# echo "/var/swap none swap defaults 0 0" >> /etc/fstab
# swapon -a


Собственно, тут создается файл, который в дальнейшем используется как swap-раздел.
Ключевой момент тут count=1048 - этот параметр определяет, какого размера файл будет создан.

P.S. честно своровано отсюда

Статистика дефектов. Спросите "Почему?"

Во многих наученых горьким опытом командах разработки ПО принята практика "постмортемов" (postmortem) - анализ удач и провалов по завершении проекта или очередного этапа проекта. Существуют разные подходы к такому анализу. Где-то опрашивают всех участников процесса разработки, где-то только ключевых людей. Где-то больше склонны обсуждать успехи, а где-то провалы. Где-то спрашивают личное мнение, где-то основываются прежде всего на статистике.

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

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

[HDI] Поиск и очистка inodes в Linux

Как известно, каждому файлу в Linux'е соответствует не только место на диске, но и некоторое количество inode. Как и место на диске, inode'ы тоже могут заканчиваться, и результат примерно тот же - создавать новые файлы становится невозможно.

Узнать, сколько inodes уже использовано можно с помощью команды
df -i

Но если узнать, кто занял все место - несложно, то понять, кто съел inode'ы чуть посложнее. Обычно они пропадают из-за большого количества мелких, как правило, временных файлов, которые кто-то не убрал за собой.

С определением места, где все это добро хранится, может помочь такой вот несложный скриптик:

#!/bin/bash
# count_em - count files in all subdirectories under current directory.
echo 'echo $(ls -a "$1" | wc -l) $1' >/tmp/count_em_$$
chmod 700 /tmp/count_em_$$
find . -type d -print0 | xargs -0 -n1 /tmp/count_em_$$ | sort -n
rm -f /tmp/count_em_$$


Скрипт показывает, сколько inode использованы различными папками. Анализируются папки, начиная с той, откуда был запущен скрипт. То есть для поиска по всей файловой системе нужно запускать скрипт из корня.

P.S. своровано отсюда: http://stackoverflow.com/questions/653096/howto-free-inode-usage

Рунглиш. Новояз. Жаргон.

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

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

Профессиональный жаргон - дело не новое, и думаю большинство с ним сталкивалось в своей работе, а уж в сфере IT - просто все. Жаргон свойственен любой профессии; где-то его больше, где-то меньше. В IT обилие жаргона связано, на мой взгляд, прежде всего с тремя аспектами:

[HDI] Создание ISO-файла в Linux

Создание ISO файла из CD/DVD диска

dd if=/dev/cdrom of=/cdrom_image.iso

где

• dd == "disk dump" - утилита для побитового копирования
• if == "input file" - устройство, откуда читать
• of == "output file" - файл, куда писать

Создание ISO файла из папки

mkisofs -D -iso-level 4 -o ./myimage.iso ./myfolder/

где

• -D - позволяет работать с деревьями папок глубокой вложенности
• iso-level 4 - позволяет работать с длинными именами файлов
• /myimage.iso  - путь к создаваемому ISO-файлу
• ./myfolder/ - путь к папке, содержимое которой надо поместиьт в ISO-файл.

Скучная работа

Disclaimer.

Есть несколько классических холиваров, в которых рано или поздно (а чаще - время от времени) должен поучаствовать каждый тестировщик. Как-то: важность тестирования в процессе разработки ПО; уровень квалификации, небходимый тестировщику; место и роль автоматического тестирования и т.д.

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

Необходимое классическое вступление.

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

А что, не так, что ли?