255 ступеней

1. Ошибка с двадцатилетним стажем

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

В качестве примера такого долгожителя я люблю демонстрировать ошибку операционки. Введем в командной строке команду:

dir > report.txt

В файл сбрасывается содержимое каталога. Откроем его. И увидим:

10.06.2005 18:40 0 report.txt

Файл report.txt имеет нулевую длину. Возможны два правильных варианта. Или совсем не включать этот файл в отчет (предпочтительно), или указать правильную длину. В данном случае имеем неинформативную строку.

Ошибка? Ошибка. Нужно исправлять? А зачем? Этой ошибке очень много лет и никого она не смущает.

PS. Если кто-то знает ошибку с большим "трудовым стажем", пришлите мне для коллекции.

Июнь 10, 2005

2. Тестирование полей ввода

Для полей ввода проверяются:

* Обработка корректных данных* Обработка граничных условий* Обработка некорректных данных внутри граничных условий* Обработка некорректных данных вне граничных условий* Обработка сложных данных

Все просто и многократно описано в книгах. Так если можно вводить только целые числа от 0 до 100 включительно, то будем проверять обработку:

13 (любое целое число от 0 до 100)

-1, 0, 100, 101. Рекомендуют еще проверить обработку 1 и 99, но, на мой взгляд это излишество. Вот если бы в условиях стояло “исключая 0 и 100″, то тогда нужно было бы проверить 0, 1, 99, 100.

3.14

-8, 115. Хотя, если -1 и 101 были обработаны нормально, то эта проверка уже лишняя. Стоит попробовать ввести буквы, знаки препинания.

в данном случае нет.

Неужели это все? Нет, есть еще несколько тонкостей.

Различия в обработке некорректных данных между Web и Win32 приложениями.

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

В Web-приложениях обработка, как правило, ведется на сервере. Соответственно, пользователю должна вернуться та же самая форма ввода, содержащая: все, что пользователь ввел (не заставляйте человека вводить данные дважды!), пометки около всех неправильных полей, и сообщение, что же было неверным.

Сложные символы

Пусть у нас есть поле ввода названия фирмы. Обычно, я проверяю поля на обработку строки типа такой:

“[|]’~<!--@/*$%^&#*/()?>,.*/\

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

Здесь интересно понять какие ошибки где могут встретиться.

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

% и? – части LIKE SQL запроса. Ошибки, связанные с ними, в моей практике не встречались.

Кавычки и угловые скобки – части кода html. Ошибки, связанные с ними, скорее встретятся в веб приложении

& - часто «проглатывается» в Win32 приложениях.

/* и */ и —. Для MS SQL server иногда очень убийственно.

| вместе с символами \ / : * ? ” < > запрещён к использованию в именах файлов и папок.

<!--, очень часто получается, что после сохранения страница отображается неверно. На эту ошибку, в частности я натолкнулся в движке блога.

Символы # и & по отдельности воспринимались нормально, а вот если их ввести последовательно… То есть желательно проверять еще иногда и разные комбинации спецсимволов.

Обработка белых пробелов

В однострочных полях следует обрезать «белые пробелы» в начале и конце строки.

Символ табуляции внутри строки заменять пробелами

Дополнение. Изредка встречается копирование пользователем из буфера обмена в поле ввода нескольких строк. Для этого случая применяем правило:

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

Соответствие длин поля ввода и хранимых данных

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

Введенные и отображаемые впоследствии данные должны быть одинаковыми.

Обязательность заполнения поля должна контролироваться не на уровне БД, а на уровне клиента, в случае Win32 приложений, или сервера, в случае Web приложения.

Разберем эти правила более подробно. Пусть на форме ввода нужно заполнить три поля: Фамилию, Имя и Отчество. Из соображений красоты дизайнер задал длину этих полей одинаковыми, и равными 20 символов. Все хорошо, но ДБА задал длину полей в БД 32, 16 и 16 соответственно.

Первая характерная ошибка. Программист не контролирует длину ввода. При вводе имени в 17 символов программа падает.

Вторая характерная ошибка. Ставится ограничение по вводу в 20, 16, 16 символов соответственно. Часть поля в БД не используется. Ошибка непринципиальная.

Третья характерная ошибка. Поля Фамилия и Имя указаны как обязательные к заполнению на уровне БД, но этой обработки нет на клиенте. При попытке передачи данных без имени приложение падает.

Четвертая характерная ошибка. Для фамилии длина поля оставлена 20 символов, но разрешен ввод 32. При вводе длинной фамилии оператор не видит начала поля. Так иногда делают, но это не очень хорошо.

Июнь 13, 2005

3. Базовые термины

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

Материал взят из работ Анисимова.

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

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

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

1. Расчленения деятельности и фиксации требований к промежуточным ее состояниям

2. Для сохранения достигнутых результатов на последующих шагах и соотнесения их с конечным продуктом

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

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

—————-

Определение “нормы” встречается у С. Платонова в его книжке “После коммунизма”.

Там это трактуется как некоторый принятый порядок действий в заданной ситуации (стереотип), но, в отличии от “просто стереотипа”, поддерживаемый механизмами СОЦИАЛЬНОГО КОНТРОЛЯ и коррекции в случае отступления от нормы.

Июль 1, 2005

4. Выявление сценариев для тестирования ссылочной целостности

Определить список тестовых сценариев для данного вида тестирования можно, используя:

* Спецификации на ПО

* Здравый смысл

* Схему базы данных

Учитывая повальный дефицит качественной документации, приходится ориентироваться в первую очередь на схему базы данных. Основной информацией служат внешние ключи. Следует учесть, что некоторые внешние ключи могут быть не созданы. В этом случае, тестер может неформально рассуждать о зависимости между объектами системы. Другой путь – это формальный просмотр схемы БД в поисках ошибок. Так если, есть таблицы document с полем bankID и таблица bank, а внешнего ключа нет, то, скорее всего, это ошибка структуры БД. Такие ситуации достаточно часты, но не всегда это приводит к ошибкам приложения. [1]

Узнать общее число сценариев можно при помощи простого запроса (пример для MSSQL):

SELECT COUNT(*) AS Expr1

FROM sysforeignkeys

Полный список (пример для MSSQL):

select t1.*, t2.referencedTable, t2.referencedColumn

from

(SELECT k.constid, k.keyno, t.name referencingTable, c.name referencingColumn

FROMsysforeignkeys k, sysobjects t, syscolumns c

Where t.id=c.id and t.id = k.fkeyid and c.colid=k.fkey) t1

JOIN

(SELECT k.constid, t.name referencedTable, c.name referencedColumn, k.keyno

FROM sysforeignkeys k, sysobjects t, syscolumns c

Where t.id=c.id and t.id = k.rkeyid and c.colid=k.rkey) t2

on t1.constid = t2.constid and t1.keyno=t2.keyno

Order by t1.referencingTable

Внешний ключ из нескольких столбцов представлен строками с одинаковыми значениями в поле constid и возрастающими значениями keyno.

Каждая строка, кроме keyno>1 соответствует одному возможному сценарию [2]. Для хорошо спроектированной БД таким скриптом можно выявить 70-90 процентов необходимых сценариев тестирования ссылочной целостности, а остальные придется дописывать после тщательного изучения системы.

Формируем список сценариев. Каждый из них включает следующую информацию:

удаляемая запись / объект

зависимая запись / объект

ожидаемое поведение системы

в каких таблицах смотреть не осталось ли “мусора”

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

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

————————————————————————————

[1] Возможна реализация ссылочной целостности через код или есть дополнительная таблица, через которую и идет контроль. Подчеркну, что речь идет не реализации связи многие ко многим через промежуточную таблицу и два внешних ключа, а именно дополнительная таблица, одна на всю базу (аналог sysforeignkeys для MSSQL). Характерно для БД, не поддерживающих FK.

[2] Полученный список избыточен, но проще выкинуть лишние строки, чем дописывать недостающие.

Июль 5, 2005

5. Тонкости тестирования textbox

Делаем проверку на максимально возможное число символов.

На форме редактирования есть многострочное текстовое поле. В базе данных размер поля – 4096. Пробуем ввести 4097, приложение не пропускает, выдавая сообщение о превышении длины поля (или не давая делать ввод далее). Оставляем 4096 символов. Сохраняем, перезагружаем форму - все на месте.

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

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

PS. Подобный случай был при тестировании на платформе .Net + MSSQL.

Август 16, 2005

6. Цена плохого кода

История одной ошибки плохого проектирования базы данных.

Запись в бактрекере: «Привести БД к первой нормальной форме».

Описание задачи.

В разрабатываемом продукте есть два объекта связанные отношением многие ко многим. Структура БД просто напрашивается. Две таблицы связываются промежуточной таблицей связей, с дополнительным столбцом типа связи (можно по-другому, но это не принципиально).

Техническое решение.

В таблице скриптов в столбец типа скрипта дополнительно прописывается идентификатор ссылки и тип скрипта.

Результат.

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

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

Выводы.

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

Октябрь 6, 2005

7. "Тривиальная" задача

Исходная задача:

Подсчитать количество локальных максимумов в массиве целых чисел.

Локальный максимум — такой элемент массива, который больше своих соседей.

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

Чужие решения можно посмотреть в ветке rsdn.

Мне было интересно проанализировать, как я сам буду ее решать. Т.е. мне интересно не решение, а поиск решения [1].

PS. Я много лет не пишу код. И плохо помню синтаксис С.

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

Итак:

Фаза 1.

Требования не полны, возникают вопросы.

1 Будет ли считаться локальным максимум граничное число? Т.е. в последовательности {2,1,3} максимумов 0 или 2?

2 Каков максимальный размер массива?

3 Как передавать обработанные ошибки?

4 Как поступать в случае массива из одного элемента?

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

1 Согласно курсу матанализа, да считается. [2]

2 Произвольно ограничим размер массива. Например, 10 элементами.

3 Функция при успешной работе возвращает целое, неотрицательное число. Одно из возможных решений - использовать “-1″ как сигнал об ошибке.

4 Возвращать 0. Делаем по аналогии с факториалом нуля. Т.е. это не ошибка, а нормальная ситуация. [2]

Фаза 2.

Реализуем требуемую функциональность максимально быстро, с возможностью дальнейшего расширения.

Фаза 3.

Функциональные требования

1 Система должна считать количество локальных максимумов в массиве целых чисел.

2 Система должна сообщать об ошибке при некорректном значении размера массива (см. п 2 фазы 1)

Юзкейсы

1. Подсчет локальных максимумов

Контекст использования. Уровень функции. Основное действующее лицо - вызывающая программа

Основной сценарий

1) ОДЛ Передает массив целых чисел.

2) Система подтверждает, что число элементов массива находится в пределах от 1 до 10

3) Система подсчитывает число локальных максимумов согласно правилу 1 (см. фазу 1).

4) Система возвращает число подсчитанных максимумов

Требований к производительности на данный момент нет.

Требований к ресурсам на данный момент.

Фаза 4.

Реализуем данную функциональность в виде функции.

Выберем язык реализации - С.

Будем использовать методику Test First

Фаза 5.

Имя функции - countMax

В качестве входных параметров функция будет получать размер массива и ссылку

Возвращаемое значение - целое число

[3]

Фаза 6.

Программа должна корректно работать с данными примерами [4].

Входные данные Возвращаемое значение Примечание

5 {1,4,3,5,1} 2 Простой тест

3 {3,2,1} 1 Левый локальный максимум

3 {1,2,3} 1 Правый локальный максимум

5 {-1,-4,-3,-5,0} 3 Отрицательные числа и 0

0 {1} -1 Граничное условие размера массива

1 {4} 0 Граничное условие размера массива

10 {1,2,3,4,5,6,7,8,9,10} 1 Граничное условие размера массива

11 {1,2,3,4,5,6,7,8,9,10,11} -1 Граничное условие размера массива

5 {} Неинициализированный массив. Это проблемы вызывающей функции, не проверяем.

Фаза 7.

void main(){

int a[5] = {1,4,3,5,1};

if (countMax(5, *a[]) != 2) then printf (”Не пройден простой тест\n”)

int a[3] = {3,2,1};

if (countMax(5, *a[]) != 1) then printf (”Не пройден тест на Левый локальный максимум\n”)

int a[3] = {1,2,3};

if (countMax(5, *a[]) != 1) then printf (”Не пройден тест на Правый локальный максимум\n”)

/* И т.д. Дальше тупая реализация запланированных тестов [5]*/

}

Организация тестов в main - неправильна. Лучше использовать NUnit. Но пока остановимся на этом.

Фаза 8.

Это заглушка, чтобы проверить тесты

int countMax(int arraySize, int *array){

return 1;

}

Фаза 9

/* Функция считает количество локальных максимумов в массиве целых чисел.

Локальный максимум — такой элемент массива, который больше своих соседей.

Размер массива ограничен 10 элементами */

int countMax(int arraySize, int *array)

{

int count = 0;

int i;

if ((arraySize < 1) || (arraySize > 10)) then return -1

if (array[1] > array[2]) then count++

if (array[arraySize] > array[arraySize-1]) then count++

for (i=1;i < arraySize-2; i++){

if ((array[i] > array[i-1]) && (array[i] > array[i+1])) then count++

}

return count;

}

Фаза 10.

Сидим, думаем.

Черт, я забыл вариант плоских экстремумов! (Например массив {1,2,2,1})

Возвращаемся назад.

Фаза 1. Правило 5. Плоские максимумы также должны считаться.

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

Фаза 6. Добавляем тесты:

5 {1,4,4,3,1} 1 Плоский максимум

5 {1,4,4,4,1} 1 Длинный плоский максимум

7 {1,4,4,4,5,5,6} 1 Два плоских экстремума

5 {4,4,4,4,4} 0 Вырожденная последовательность. Только экстремум.

5 {5,4,4,5,6} 2 Плоский минимум.

5 {5,5,4,5,5} 2 Плоские граничные максимумы

Фаза 7. Без комментариев.

Фаза 9. Перепишем код.

/* Функция считает количество локальных максимумов в массиве целых чисел.

Локальный максимум — такой элемент массива или группа равных элементов, которые больше своих соседей.

Размер массива ограничен 10 элементами */

int countMax(int arraySizeIn, int *arrayIn)

{

int count = 0;

int i;

if ((arraySizeIn < 1) || (arraySizeIn > 10)) then return -1

int array [10];

int arraySize=0;

i=0;

while (i < arraySizeIn-1){

if (array[i] != array[i+1]) then{

array[arraySize] = arrayIn[i];

arraySize++;

}

i++;

}

if (array[1] > array[2]) then count++

if (array[arraySize] > array[arraySize-1]) then count++

for (i=1;i < arraySize-1; i++){

if ((array[i] > array[i-1]) && (array[i] > array[i+1])) then count++

}

return count;

}

Фаза 11.

Теперь нужно сделать вычитку кода на синтаксические ошибки, такие как пропущенные точки с запятой, использование зарезервированных слов, пропущенные void, неправильная передача массива, использование “then”, и т.д.

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

Фаза 12.

Компилируем, прогоняем тесты и правим код при необходимости.

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

Вместо:

i=0;

while (i < arraySizeIn-1){

if (arrayIn[i] != arrayIn[i+1]) {

array[arraySize] = arrayIn[i];

arraySize++;

}

i++;

}

Должно быть:

i=0;

while (i < arraySizeIn-1){

if (arrayIn[i] == arrayIn[i+1])

i++;

array[arraySize] = arrayIn[i];

arraySize++;

i++;

}

array[arraySize] = arrayIn[i];

arraySize++;

Третий тест выявил ошику в строке:

if (array[arraySize] > array[arraySize-1]) count++;

Должно быть:

if (array[arraySize-1] > array[arraySize-2]) count++;

Четвертый тест выявил ошику в строке:

if (array[1] > array[2]) count++;

Должно быть:

if (array[0] > array[1]) count++;

Тест на массив из одного элемента вызывает падение в строке

if (array[0] > array[1]) count++;

Добавим:

if (arraySize == 1) return 0;

И т.д. Почти каждый тест выявляет новую ошибку.

Фаза 13.

Все? Нет. Еще можно добавить:

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

* Добавить тест на граничные условия по диапазону элементов массива. Абстрагируясь от написанного кода, делаю следующее предположение:

При написании функции можно исследовать изменение знака приращения элементов с “+” на “-” (аналог исследования производной). Такой алгоритм может вызвать ошибку в последовательности {минимальный элемент, 20, минимальный элемент}. К сожалению, данный тест, зависит от компилятора.

У меня под руками Visual Studio. Здесь int от “-2 147 483 648″ до “2 147 483 647″, соответственно тест:

3 {-2147483648,20,-2147483648} 1 Тест на граничные значения элементов.

А теперь проанализируем, что у нас получилось.

Фаза Род деятельности

1 Определение

2 Определение методологии разработки

3 Разработка требований

4 Высокоуровневая архитектура

5 Низкоуровневая архитектура

6 Планирование тестов

7 Реализация тестов

8 Проверка тестов

9 Кодирование

10 и 13 Вычитка артефактов, с повтором фаз, если в артефакте найдена ошибка.

11 Отладка

12 Тестирование и отладка

Временные оценки можете поставить свои, я выскажу свое мнение.

1) Кодирование и отладка, собственно область действия программиста, даже в таком простом примере, по трудозатратам меньше остальной работы.

2) Часто такую задачу не разбивают на части, а поручают одному человеку (программисту). Это не всегда эффективно. Первый, второй, третий и шестой пункт находятся вне сферы компетенции обычного программиста. Что-то лучше отдать архитектору, что-то тестировщику. “Нельзя знать все на отлично”.

——————————————————————

[1] Была хорошая книга “Поиск решения”. Если сможете достать - прочитайте. Она конечно сложновата, но в дальнейшем очень помогает.

[2] Вот и изучение высшей математики пригодилось. А то “Зачем, зачем?

[3] Можно добавить диаграммы, но текст здесь не менее нагляден.

[4] Если делать совсем “по-хорошему”, то при планировании тестов в фазе 6 нужно было применять ортогональную матрицу. Общее число тестов было бы меньше. И в связи с фазами 10 и 13 это актуально.

[5] Опять же, если делать совсем “по-хорошему”, то тест должен быть один, а данные можно брать из массива данных (например, их файла или двумерного массива). Но поскольку нас интересует работоспособный код, а не оптимальность тестов, то делать этого не будем.

Январь 23, 2006

8. 61 тест, который потряс программу

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

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

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

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

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

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

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

Февраль 1, 2006

9. Объемное тестирование на стадии выбора архитектуры

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

При разработке программы можно столкнуться с недостаточной производительностью. Но еще хуже резкая потеря производительности при достижении некоторого порога данных. Если производительность пузырьковой сортировки на сотне записей меньше необходимой в два раза – это ерунда. Возьмем сервер помощнее. А что делать, если пользователю нужно работать с тысячей записей? Мне могут возразить, что тут делов на пять минут – просто сменить алгоритм. Хорошо, изменим задачу. Для сайта принято решение хранить картинки в файловой системе. Нормальное архитектурное решение. Для небольшого количества файлов. А для пары миллионов? Так, время на исправление несколько увеличилось. Ну а если для исправления потребуется переход на другую платформу? Например с MySQL на MSSQL (или наоборот, это неважно)? Переписать несколько сотен хранимок, перелопатить кучу кода, … Срыв проекта гарантирован.

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

В MSSQL2005 появилась прекрасная возможность хранить XML в одном поле и работать с ним напрямую. Экономия при программировании колоссальная. Те, кто сталкивался с реализацией работы с объектами произвольной структуры в реляционной базе, меня поймут. Я участвовал в проектах, где подобное было реализовано двумя различными методами. Это ужасно. Нет, конечно, пальцы после этого можно загибать веером, но времени и сил на реализацию такой архитектуры уходит масса.

XML тип в каком-то смысле панацея. Только вот не оказалось бы лекарство хуже болезни. Механизм новый, возможности неизвестны. Риск получить неудовлетворительную производительность при реальных данных – очень высок.

Для проверки были предложены следующие тесты.

——————————————————–

Структура объекта

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

Тестируемые архитектуры БД.

Классическая реляционная модель

Book

Id Int

Name Varchar

Category Int

Price Decimal

Author

Id Int

BookId Int

Name Varchar

Промежуточная

Id Int

Name Varchar

Category Int

Price Decimal

Authors XML

XML

Id Int

Book XML

Метод проведения тестов

Осуществляем последовательно 100-1000 запросов с параметром. Тесты проводятся несколько раз, после чего результат усредняется.

Последовательно увеличиваем объем данных, начиная с десяти тысяч. Приращение осуществляем следующим образом: 10 тыс, 30 тыс, 100 тыс, …и так до миллиона.

В случае резкого падения производительности, участок, на котором это произошло исследуется с меньшими приращениями.

Исследуемые типы запросов

Вставка записей

В данном тесте исследуется время вставки объекта «книга-авторы» в БД.

Изменение записей

В тесте исследуется изменение объекта «книга-авторы» в БД. Изменение:

• Меняется название книги

• Удаляется автор

• Добавляется автор

Простой запрос объекта

Выдать объекта «книга-авторы» для книги с определенным названием

Нахождение группы объектов по значению атрибутов

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

Агрегированные функции

Вычисляем среднюю сумму по одной из категорий

——————————————————–

Это тестирование проводилось до написания первой строчки кода. В качестве заглушки использовались тестовые данные, в качестве драйвера – скрипты. Движок – сам MSSQL. Никакое специализированное средство автоматизированного тестирования (типа LoadRunner) не использовалось.

Я не привожу ни результатов тестов, ни скриптов, ни еще некоторых важных моментов. Главную идею статьи они не иллюстрируют.

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

Май 6, 2006

10. Определение нагрузочного тестирования

Термин “нагрузочное тестирование” обычно используют в значении “тестирование производительности”. А что жетогда есть собственно нагрузочное тестирование?

RUP:

Load testing is a performance test, which subjects the target-of-test to varying workloads to measure and evaluate the performance behaviors and ability of the target-of-test to continue to function properly under these different workloads. The goal of load testing is to determine and ensure that the system functions properly beyond the expected maximum workload. Additionally, load testing evaluates the performance characteristics (response times, transaction rates, and other time sensitive issues).

Вольный перевод.

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

Обычно нагрузочное тестирование проводят, нагружая систему 75% от максимальной нагрузки в течении суток.

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

Долго я не понимал, зачем этот вид тестирования нужен. Потом поднял историю отрасли, и все встало на свои места. Вы когда-нибудь слышали о такой вещи как “memory leak”? О, я прямо-таки вижу, как вздрогнули C и C++ программисты. Это чудовище являлось им в кошмарных снах. И с криком просыпались они.

Для тех, кто не в курсе даю историческую справку. C и C++ предоставляют прекрасные возможности по прямому управлению памятью. И требуют высочайшей культуры работы. Однако, несмотря на все усилия, как правило, остаются участки кода, приводящие к утечкам памяти. Кроме того, происходит фрагментация памяти. Результатом этого является замедление работы системы и необходимость регулярной перезагрузки. Для систем 24х7х365 это настоящий бич. Сами посудите, к чему приведет необходимость перезагрузки дважды в сутки авиадиспетчерской системы.

Я предполагаю, что именно для подобных систем и родились эти тесты. Т.е. для систем с требованиями класса:

* круглосуточная работа;

* перерывы не чаще раза в месяц, не более чем на 15 мин.

Много лет назад начался переход на управляемый код (Java, C#). И управление паматью стало проще. Хотя, как говорят, кривые руки способны испортить любую систему. Достаточно просто не отпускать ресурсы.

Ну а теперь выводы.

* Для систем с нежесткими требованиями к перезагрузке нагрузочное тестирование необязательно.

* Для систем 24х7х365 на неуправляемом коде нагрузочное тестирование практически обязательно.

* Для систем 24х7х365 на управляемом коде менее актуально, чем для систем на неуправляемом коде.

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

——————————————————————————

Комментарии программистов.

* Первоначально наша система на С++ деградировала за час работы. Так что это тестирование полезно не только для систем 24х7х365.

* И на С++ можно делать недеградирующие системы. Просто это сложнее.

Май 22, 2006

11. Размер проекта. О совочках и экскаваторах

Студент: Эта величина маленькая и ей можно пренебречь.

Преподаватель: Маленькая, по отношению к чему?

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

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

Шкала может быть разной. Можно сравнивать по трудозатратам, можно по стоимости, можно по функциональным точкам и тысячам строчек кода, можно вести оценку по методу COCOMO. Важно не это. Главное, чтобы на этой шкале уместились все проекты. Т.е если проект в 5 KLOC (Тысячи строк) “большой”, то куда отнести проект по переводу системы управления в 100 мегабайт исходного кода с мейнфрейма и COBOL на PC и C++ (с десяток лет назад был такой проект у нас в России)? А создание такой системы с нуля куда отнести?

Качественные значения, которыми мы оперируем при разговоре о величине проекта, как правило, составляют следующий список:

* маленький;

* средний;

* большой.

Добавим к этому “крохотный” и “гигантский” для проектов, выходящих за эти рамки.

Для себя я составил следующее соответствие качественных и количественных показателей:

* До 10 человекомесяцев – крохотный;

* 10 – 100 – маленький;

* 100 – 1000 – средний;

* 1000 – 10 000 – большой (крупный);

* Более 10 000 - очень большой (гигантский).

Почему именно такие диапазоны? Существуют пики эффективности в зависимости от численности группы. Если не ошибаюсь, такие: 1 человек, 7, 22, 105, 600, 3000. Т.е как правило один разработчик работает значительно эффективней, чем два, но 22 эффективней, чем 15 или 30. И, по-прежнему, один разработчик, как правило, будет эффективней 22. Однако при росте задачи, сильно возрастает время, что больно бьет по бизнесу. Если в одиночку разработчик решает задачу за год, то нет смысла давать эту задачу ему одному. Пусть лучше семеро решат эту задачу за три-шесть месяцев (компромисс время - трудозатраты). Конечно, нет смысла поручать эту задачу сотне людей. Все равно, за неделю они задачу не решат.

Моя оценка оптимального соотношения люди - время:

* 1 человек — неделя – квартал;

* 5-9 человек — два месяца – полгода;

* 21 - 25 человек — 0,5-2 года;

* 100 - 110 человек — 1,5-3 года;

* 600 человек — от трех лет.

Отсюда я и выводил свои диапазоны.

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

Крупный проект — это примерно:

* от 1000 человеко месяцев;

* от миллиона строк кода;

* от 10 млн $ бюджет (для Москвы 2006 г).

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

Эдвард Йордан приводит следующую шкалу размеров проекта:

* небольшие проекты: менее 10 человек, 3-6 месяцев;

* средние проекты: 20-30 человек, 1-2 года;

* крупномасштабные проекты: 100-300 человек, 3-5 лет;

* гигантские проекты: 1000-2000 человек, 7-10 лет.

Макконнелл в книге “Остаться в живых” определяет средний проект как проект с командой 3-25 человек и со сроком выполнения 3-18 месяцев

PSS. В частности, Алистер Коберн приводит другие численности эффективных команд.

Июнь 21, 2006

12. Всего одна неудачная фраза

Нашел в интернет-прессе упоминание о некой игре. Решил посмотреть, что же за грандиозный проект сделали наши программисты.

Зашел на их сайт и мои глаза сразу выделили фразу: “Легендарная игра готовится к открытию”

Все, читать дальше пропало всякое желание. Можно говорить, что это случайная ошибка. Что человек описался. А человек ответственный за вычитку текста “случайно” эту ошибку пропустил. Не представляю, как можно так описаться. Это нужно совершенно не знать базовых понятий.

Или эта ошибка сделана намеренно?

Я полагаю, что текст первой страницы готовил случайный человек. И проверял текст тоже случайный человек. Экстраполируя отношение к набору случайных людей для PR на техническую команду предварительный вывод неутешителен.

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

Боюсь, я не хочу далее знакомиться с этой игрой.

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

Возможно, это игра слов. Но тогда это намеренное формирование неправильной установки. Прошлый опыт научил меня, что от названий:

* Очень честный банк;

* Нефть, газ, золото, колбаса инвест;

* Новейшие, эффективнейшие программы.

Нужно держаться подальше. Это как зуммер: Здесь могут обмануть!

Т.е. возможен второй вариант, но он еще хуже, чем первый.

Август 3, 2006

13. Насколько эффективна организация?

Это простой опросник, который позволяет всего за пять минут определить, насколько здорова организация. Его можно использовать и по-другому: “Что еще нужно сделать, чтобы стать эффективней”. С другой стороны, работники могут использовать этот опросник для определения привлекательности фирм для своей будущей карьеры.

Опросник пока сырой, так что используйте его на свой страх и риск.

Могут ли работники работать эффективно?

Сколько квадратных метров кабинета (не офиса целиком, а именно кабинета) приходится на одного работника:

* менее семи - 1 балл;

* более семи - 0 баллов.

Какова площадь рабочего пространства (стол+тумбочка) у каждого работника?

* менее 2 кв. м - 1 балл;

* более - 0 баллов.

Может ли работник “забить” на телефон, почту и прочее хотя бы в течении четырех часов в день?

* нет, он всегда должен быть на связи - 1 балл;

* да - 0 баллов.

Находятся ли в помещении с командой разработки работники других отделов, например, help desk?

* Да - 1 балл

* Нет - 0

Ели вы набрали 0 баллов - отлично, похоже у вас неплохие рабочие места. Если 1 балл - попробуйте что-нибудь улучшить. Два и более - и вы еще не понимаете, почему у вас такая низкая производительность?

Возможно ли в вашей фирме существование эффективных команд?

За каждый ответ “Да” начисляйте один балл.

* Занимает ли ваше руководство оборонительную позицию? Т.е. должны ли сотрудники получать одобрение на каждый чих? Или: “Должны ли сотрудники следовать методологии, СМК, …”

* Пишут ли сотрудники еженедельные отчеты (если отчеты ежедневные - поставьте два балла)?

* Разделена ли команда физически?

* Существует ли практика, при которой работники заняты в двух и более проектах одновременно?

* Жертвует ли организация качеством ради более раннего выпуска?

* Существует ли практика установки жестких сроков сдачи проекта “к новому году”, без учета реальной трудоемкости?

* Существует ли практика переформировывать команды при переходе к другому проекту?

Есть ли в вашей фирме плакаты вроде:

* Качество - задача номер один;

* Командная работа позволяет простым людям достигать непростых результатов;

* Наша задача - соединение целей работника и организации.

Если вы набрали 0 баллов - скрестите пальцы в надежде на получение настоящей сплоченной Команды. Если 1 - появление Команды возможно, но маловероятно. Если 2 - расслабьтесь, даже если Команда случайно возникнет, она умрет в неблагоприятной среде.

К какому типу принадлежит ваша организация, карликов или великанов?

Какой процент работников получает зарплату, большую, нежели его непосредственный начальник?

0% - 2 балла

5-10% - 1 балл

> 20% - 0, баллов

Какова текучка в вашей организации?

* Менее 15% - 0 баллов

* 15-30% - 1 балл

* Более 30 - 2 балла

——————————————-

Если в целом вы набрали 3 и более балла - не расстраивайтесь. На рынке полно таких же фирм. Так что вы еще долго будете на плаву.

Апрель 24, 2007

14. О подготовке к тренингу

Навеяно {анкетой} с http://forums.software-testing.ru/.

Попробовал ответить на вопрос "Как подготовиться к тренингу", получилось много. Вдруг кому пригодится.

Этапы подготовки к тренингу:

* выделение цели;

* определение необходимых навыков для достижения цели;

* нормирование (задание метрик) для каждого из навыков;

* изучение целевой группы;

* определение типа контроля;

* детализация контрольной процедуры;

* определение области подачи материала;

* выработка стратегии достижения (лекция, семинар, лабораторные работы или их комбинация);

* разбиение на этапы подачи материала;

* привязка по времени;

* лексическая корректировка;

* репетиция с зеркалом.

Остальное уже не подготовка, а проведение и корректирующие процедуры

Август 8, 2006

15. Каскадное удаление данных. Обработка попытки удаления объекта, на который есть ссылки

С точки зрения программиста все просто. Навешиваем констрейны на базу данных. При попытке удаления перехватываем эксепшен и делаем ролбек транзакции.

А пользователь вместо элементарной последовательности:

Вызов меню / попытка нажатия на кнопку удаления. Все приехали, вижу, что невозможно, вынужден идти по длинному пути:

Вызов меню -> отдание команды на удаление -> подтверждение команды.

Расчет времени по GOMS [1] дает 2.4 - 3.6 секунды в первом случае и 8.4 во втором. В случае же Web приложения во втором варианте добавляются еще две задержки приложения 2-6 секунд. А это уже очень серьезно. Одно дело за 2.5 секунды понять, что удаление невозможно и совсем другое в течение 10 - 15 секунд заниматься нудной работой, забыть, что же делать дальше и выяснить, что все это напрасно.

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

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

Как это ни странно, но иногда использование констрейнов приводит к усложнению структуры базы данных.

Итак, все сводится к некоему усложнению кодирования. Что перевесит: удобство программирования или удобство использования? Пока в подавляющем количестве случаев программеры одерживают верх над конечными пользователями.

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

----------------

[1] Метод GOMS предложен в 1983г. Этот метод неплохо описан в книге "Дизайн пользовательского интерфейса" Влада Головача.

Сентябрь 28, 2006

16. Дорогая ошибка. Пример из России

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

Фирма «Арктикгруп» [1], крупнейший продавец сотовых телефонов, цифровых фотоаппаратов, КПК и всяческих гаджетов, а также холодильников, телевизоров и пылесосов [1] вела сложный складской учет. Приспособить существующие на рынке системы под себя, не представлялось возможным, и была написана собственная программа учета [2].

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

Сомненья дьявол ловок и хитер [3]. Но как проверить подозрение? Тотальная ревизия отпадает. Остановить работу склада на несколько дней нельзя. Проверить товар на складе размером с ангар за одну ночь нереально. Прошерстить большой объем при постоянных изменениях – задача не для слабонервных. Управляющий складом был по-настоящему талантлив. Метод проверки, предложенный им, был неординарен и красив. Он посчитал и сравнил суммарные объемы в кубических метрах товара по БД и наличествующие на складе. Точности метода хватило. Было обнаружено превышение остатков на складе на несколько процентов по сравнению с информацией в БД.

Ошибка обнаружена, но не локализована.

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

* Может быть вызвана некорректными начальными данными. Например, при вводе системы в строй забыли ввести часть позиций.

* Может быть в программном обеспечении.

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

Еще несколько дней были потрачены на проверку системы учета. Действительно ошибка была в программе. Она возникала при редком варианте использования программы уровня неба [4]. Дальше все просто и неинтересно.

Я же хочу подчеркнуть несколько моментов:

* От момента обнаружения ошибки до занесения ее в багтрекер прошло много дней.

* Ошибка, приносившая ежегодно очень серьезные потери (более сотни тысяч долларов) долгое время не была обнаружена.

* Ошибка была обнаружена конечным пользователем не при прогоне программы, а достаточно экзотическим методом.

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

-----------------------

[1] Случай реальный, но все названия изменены.

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

[3] © Евгений Клячкин

[4] Определение этого термина можно найти в великолепной книге Алистера Коберна «{Современные методы описания функциональных требований к системам}»

Октябрь 5, 2006

17. ROI от вложений в железо

К. Маркс: "При 25% прибыли капитализм оживляется! При 100% прибыли - он готов положительно на все!! При 300% прибыли - нет такого преступления, на которое он бы не пошел.

Ах, как жестоко ошибался классик. Порой даже ради 1000% капитал не чешется.

Сегодня я хотел бы поговорить о такой тривиальной теме, как об оснащенности рабочих мест разработчиков ПО. На семинарах нам поют, про то, что вложенный доллар, приносящий 3-5 долларов прибыли это чудовищно много. Господа, я предлагаю вам получить 20 долларов за год на один вложенный. Никто не хочет? Нет? Интересно, а почему? У меня есть вариант ответа, но он настолько чудовищен, что я просто не хочу его озвучивать.

Смотрите:

Visual Studio – одно из наиболее распространенных сред разработки под Windows. Переход на новую версию - VS2005, произошел довольно быстро. Но вот переход на новое железо почему-то задержался. Во многих фирмах можно увидеть 512 MB на машине разработчика. Работа с таким объемом памяти в VS 2005, да еще с запущенным решарпером и еще парой фоновых задач способна довести до истерики. Но оставим в стороне душевное здоровье. Просто посчитаем финансы.

* Разработчик должен приносить фирме хотя бы 50-100$ тысяч в год. Увеличение его производительности на 1% - это 500 – 1000$.

* Будем считать, что вложения в IT окупающиеся за год имеет смысл рассматривать.

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

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

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

17” и 19” даже рассматривать не будем. Это для фирм-неудачников, ютящихся в подвале и «лабающих» софт на коленке. Работать с современными приложениями при разрешении 1200*1024 – это как оценивать обстановку на поле боя через смотровую щель танка. С места механика-водителя. Т.е. можно конечно. Но очень плохо. Постоянно не хватает рабочего пространства. Перетаскивание окон отнимает существенную часть рабочего времени. Это приличные (исчисляющиеся тысячами долларов в год) потери.

Достаточно комфортным можно считать или систему из двух 20” мониторов или один широкоформатник 21-24. Ну а «солидным» фирмам имеет смысл присмотреться к 30” моделям на *VA или S-IPS матрице с разрешением 2560х1600. При достаточно невысокой цене это очень привлекательный вариант. Не окупится за год? Может быть, может быть. Давайте попробуем учесть все плюсы [1].

Повышение эффективности работы. Это надо проверять экспериментально. Врать не буду, не засекал. Как было посчитано выше, достаточно экономии 20 мин в день.

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

Мотивационный фактор. Возможно, кому-то это покажется странным, но хорошие специалисты предпочитают работать на хорошей технике. Для них это важно. А как сказал Филипп Гринспан: «Успех вашего бизнеса зависит от того, какие именно программисты практически живут в вашем офисе».

Вау эффект [2]. Проведите вашего заказчика по отделам разработки, оснащенным хорошей техникой. Послушайте, что он скажет. Это вам не сертификат ISO клиенту показать.

PS. Статья получилась провокационной и в ней учтены не все аспекты. Что делать – просто наболело.

-----

[1] Если быть совсем точным надо учесть и все минусы, начиная от необходимости смены видеокарты, до элементарной зависти.

[2] Термин, пришедший из "Generation P" Пелевина

Февраль 5, 2007

Один комментарий

Почти 10 лет прошло, и таки тема все еще актуальна.

Мне нужен ровно такой-же сервер как на проде, и да, 90% времени он будет простаивать.

Мне нужен монитор с максимальным разрешением чтоб разобраться в этой базе, схему которой никто не соизволил задокументировать.

Мне нужен ноут с xeon и 64Гб на борту. Зачем? Хочу Xen и 33 песочницы onboard.

18. Немного критики в адрес RUP

- В чем разница между методологом и террористом?

- С террористом можно вести переговоры.

Тема родилась отсюда на http://forums.software-testing.ru/

В одном из своих постов я покусился на святое:

RUP чудовищно устарел. Это прекрасно разработанная система. Без дураков. Одна из самых, а, скорее, самая подробная. Но как раз ввиду этого - застывшая, неповоротливая и во многом ошибочная.

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

И Вячеслав Панкратов попросил осветить этот вопрос поподробнее.

- Сергей, тема очень интересная - я пользуюсь РУП-ом ибо нет ничего подробнее и ничего обширнее. Беру РУП и отсекаю ненужное- то бишь адаптирую.

А вот в остальном - "давайте разбираться" [:)]

1. В чём ошибочен РУП?

2. В чем устаревшесть модели прецендентов РУПа? Что сейчас не работает или работает совсем не так или не может работать как описано?

3. Какие именно связи между артефактами нарушены или требуется их переадресация?

4. Что с инструментами?

- Мне в самом деле интересна тема, я далеко не адепт РУПа, во многом он меня устраивает как структурированная Библиотека проектных практик, во многом не устраивает, но лучше я пока не видел и с тем что ты говоришь не согласен.

Кто б спорил. Действительно нет ничего подробнее и ничего обширнее RUP-а. И если бы теория разработки ПО стояла на месте последние сорок лет, то унифицированный процесс от Rational был бы самым передовым и самым правильным.

Давайте рассмотрим модель прецедентов. Как я уже говорил выше, в RUP используется модель «действующие лица и цели» (Actors and Goals). Несколько лет назад Алистер Коберн создал современную модель «Участники и интересы» (Stakeholders and Interests). Разница в результатах при использовании этих двух моделей прекрасно показана в статье «Варианты использования, десять лет спустя»:

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

Март 31, 2007

PS. Сейчас в 2023 я смотрю на RUP совсем по другому. Это очень классная штука. И еще я начал ценить ГОСТ-ы. И 34-й серии, и 2-й. И еще много разных.

19. Кто виноват в переработках?

Slow down, you're doing fine,

You can't be everything you want to be before your time.

Although it's so romantic on the borderline tonight.

But when will you realize- Vienna waits for you?

Замедли свой бег, все в порядке,

Ты достигнешь всего, когда время придёт,

И пусть на границе сегодня романтика,

Когда ты поймёшь, что… Вена все ещё ждёт?

Введение

Во время спора об уместности переработок некто под ником bsod предложил гипотетическую ситуацию {http://forums.software-testing.ru/index.php?showtopic=7117} :

Не готов согласиться в том, что переработки - это в 99% недосмотр менеджмента. Думаю, в 50% только. В остальных 50% - происки конкурентов.

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

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

Я, похоже, забыл сказать, что вы производите коробочный софт стоимостью не больше $100 за юнит. Это очередная версия вашего софта. Учитывая цену, клиенту, в общем, не проблема перебраться с вашего софта, на конкурирующий. Клиентов, скажем, миллион. Понимаю, у многих всего один клиент, с которым договор есть. Которому бумажку можно сунуть под нос если что, где все прописано от и до. А вы все-таки представьте-

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

Действия топ-менеджмента? Посмотрели на фичу клиента и поняли, что-фича-то зиждется просто на гениальной идее. Которая, вау, еще не запатентована. Которую задевелопить-то всего командо-неделя. Ну и две командо-недели потестить. Что дальше? Смириться с тем, что у нас процесс и план, в котором нет такого риска? Соответственно и рыпаться не будем? Будем смотреть как конкурент перетягивает клиентов? Или все-таки поборемся? Надо только поработать побольше. Может пару ночей не поспать. Кстати, задержать выпуск на три недели тоже нельзя - у вас ведь еще OEMы, VARы, partner'ы и прочие reseller'ы, у которых печатные станки раскочегарены, и которые могут вас поставиь на некислые бабки в случае задержки релиза даже на неделю.

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

Ну что ж я поднимаю перчатку и продолжаю спор.

Предположим это так

Пусть есть фирмы А, Б и В. (Гении, планировщики и торопыги)

У каждой примерно по 20% рынка. Фирма А анонсирует бету с «гениальной фичей».

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

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

Фирма «В» (торопыги) решает поднапрячься.

Через месяц для планировщиков настают тяжелые времена. Часть их клиентов задумывается о переходе на альтернативные варианты. И часть даже переходит. Часть ждет. Если вы посмотрите статистику распределения пользователей, то увидите, что 5-10% относится к сегменту рисковых первооткрывателей. Они спрыгивают с состава «Б» и уходят к конкурентам. Пусть это 10%. Половина уходит к «А», половина к «В». Расклад рынка через месяц:

* А – 21%

* Б – 18%

* В – 21%

Через месяц выходит патч, и ситуация стабилизируется. Фирма «Б» проиграла?

Поживем - увидим. Фирма «А» нам более не интересна, последим за борьбой между «Б» и «В». Благодаря скорости торопыги вырвались вперед, но делать ПО в спешке сложно и, естественно у клиентов полезли ошибки. Срочно нужен патч. Но напряженная работа существенно снизила производительность команды. Оправиться от последствий переработки непросто и патч выходит через два с половиной месяца. За это время 5% рисковых пользователей решает вернуться к планировщикам. Соотношение стало 19% у планировщиков на 20% у торопыг. А в это время планировщики спокойно готовят новый релиз с кучей новых «гениальных» фич. И выпускают этот релиз на 3-4 месяца раньше. Торопыгам тяжело догнать планировщиков, т.к. кроме того, что в спешке делается не просто глючный софт. В спешке делается софт неустойчивый к изменениям. И еще 5-10% пользователей покидают торопыг. Счет сравнялся.

С каждым кварталом торопыги будут терять все больше и больше клиентов. Ну а теперь подобьем бабки:

* У торопыг чуть больше денег в краткосрочной перспективе

* У торопыг подмоченная репутация

* У планировщиков устойчивый рост рынка за счет торопыг (на мой взгляд, в течении года)

* У торопыг разбегается команда

О последнем надо сказать особо. Один из методов уничтожения команд выявленный Томом Демарко и Тимоти Листером – это как раз переработки. Действует даже более эффективно чем изощренная система мотивации или плакаты «Наша цель – качество / Люди наш самый ценный ресурс / …» (подробнее смотрите «Peopleware»). По статистике Йордана в первую очередь уходят лучшие. А вот неудачники склонны оставаться.

Если сотрудники организации увольняются, то кто уходит в первую очередь? Самые продуктивные! … В результате их ухода средняя продуктивность организации падает еще больше, что вызывает дальнейшее ухудшение морального состояния, … которое повышает текучесть кадров … и так до тех пор, пока в организации не останутся одни зомби из фильма «Ночь живых мертвецов». (с) Эдвард Йордан «Путь камикадзе».

Моя статистика подтверждает эти выводы.

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

А как на самом деле?

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

Но посмотрите статистику. Сколько продуктов выходит без всяких гениальных фич, которые есть у конкурентов. Выходят на занятый рынок. И отвоевывают себе место под солнцем. Ну, совсем элементарный пример: MSSQL и Oracle. Или если хотите рассматривать российский рынок, возьмите войну бухгалтерий лет десять назад. Инфинбухгалтерия была лучше, чем 1С. Да что там! 1С – была одним из худших продуктов. Ну и посмотрите на рынок сейчас.

Приведу пример из моей практики. Коробочный софт, порядка трех тысяч потенциальных клиентов. На рынке, кроме нас еще 3-4 игрока. Наш софт лучший. Но вдруг выясняется, что нужно реализовать еще пару фич и успеть надо обязательно к определенной дате. Напряглись, сделали. Думаете, клиенты выстроились в очередь и расхватывали программу как горячие пирожки? Как говорил герой одного известного анекдота: «Ну да, конечно». К счастью, в сумме переработка получилась не очень большой. Что-то около 40 часов за месяц.

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

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

И кто же виноват?

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

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

При желании можно также выявить ошибки в управлении рисками и ошибки календарного планирования. Но это опять же ошибки управления, т.е. среднего и топ менеджмента.

Попробуем найти оправдание переработке

И все-таки в этом что есть. Не может же миллион мух ошибаться

Придумаем гипотетическую ситуацию.

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

Совещание.

Действующие лица [1]:

* Генеральный директор

* Менеджер продукта

* Архитектор

* Заказчик

Архитектор. Это очень жесткий срок и риск срыва сроков очень велик.

Заказчик. Я понимаю. К сожалению, нам срочно нужен этот продукт.

Генеральный Директор. Вы могли бы обратиться к нам на полтора месяца раньше и тогда бы этой проблемы не было.

Заказчик. Это полностью наша вина. Я не буду проводить здесь анализ причин проблемы и прошу вас сосредоточиться на возможностях решения.

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

ГД. У нас есть маневр по объему работы?

Менеджер Продукта. Есть, но он очень невелик, и учитывая криптрикваемент (расползание требований), он явно недостаточен.

ГД. У нас есть маневр по реализации?

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

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

ГД. Ну что ж общее резюме такое. Шанс успеть – минимален. Более того, попытка успеть раньше может легко вывести нас на срок в 4-5 месяцев вместо трех. И почти наверняка будет задержан выход следующей версии.

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

Заметим, что в сложившейся ситуации виноват кто-то из топ менеджмента заказчики, отвечающий за портфель проектов организации (см. Том Демарко и Тимоти Листер «Управление рисками»). Но заказчик взял вину на себя и готов пойти навстречу проектной команде для ослабления проблем. Риски велики, но и приз хорош. Кроме того, с самого начала складывается дружественная, благоприятная атмосфера проекта. В результате мы имеем безнадежный проект класса «Миссия невыполнима». Можно играть? Можно. Но по нашим правилам.

Начинаем считать резервы:

* Назначение куратором (менеджером проекта) офис менеджера организации [2].

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

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

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

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

* Заказчик согласен, что можно будет выкинуть любую малоценную функциональность.

* Генеральный директор переводит команду в режим изоляции. В помещении отключаются телефоны.

Можно еще поискать резервы, но сверхурочные среди них отсутствуют. На них ставку не делают. Спурт возможен только на две недели. И работа в «бункере» будет введена, только в самом, самом крайнем случае.

Причины переработок

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

* Желание выслужиться

* Недостаток авторитета и силы воли для противостояния в политических играх

* Попытка «ударным» трудом скрыть свою некомпетентность в планировании, анализе и проектировании

Любая из этих причин заставляет усомниться в компетенции менеджера проекта. Более того, вина будет лежать на нем.

Заключение

Готов ли я участвовать в «Невыполнимой миссии»? Вы знаете, да. Здоровый дух авантюризма не до конца умер во мне. Но если переработки становятся нормой, то может быть что-то поправить в консерватории?

------------------

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

[2] Неожиданное на первый взгляд решение. Обоснование роли такого «завхоза/менеджера по внешним связям» можно найти в романе «Проект Венера» (другое название «Торговцы космосом») Фредерика Пола. Кстати, очень неплохое описание проекта «Миссия невыполнима».

Апрель 25, 2007

20. Автоматизированное тестирование с нуля

Из доклада на SQADays-1 21 апреля 2007.

Выбор регрессионных автоматических тестов

Для предотвращения «расползания» кода и раннего обнаружения ошибок широко применяется практика ежедневного тестирования в автоматическом режиме.

В мировой практике наиболее распространены следующие виды тестов:

* Ежедневная сборка

* Тесты компонент

* Юнит тесты

* Тесты приложения через GUI (с помощью специализированного инструмента тестирования, такого как QTP, TestComplete, Rational Robot,\ и т.д.)

Ежедневная сборка. Является тестом с наибольшим ROI. Кроме того, этот тест является базисом для прочих тестов. Соответственно она будет внедряться первой.

Тесты компонент (в терминах RUP – модульные). Проводятся через API компонента и позволяют полностью проверить его функциональность.

Юнит тесты. Пишутся на методы отдельных классов или на функции. Рекомендуемое покрытие 70-80%. Данный вид тестов является скорее средством создания, отладки и рефакторинга кода, нежели собственно тестирования, но ничто не мешает использовать их для регрессионного тестирования.

Тесты приложения через GUI. Позволяют полностью протестировать приложение. К недостаткам этих видов тестов нужно отнести:

* Высокую трудоемкость создания и поддержки

* Неустойчивость к изменениям интерфейса

Это приводит к тому, что по заверениям экспертов только 5-15% ручных тестов имеет смысл автоматизировать.

Проведем простой расчет. Пусть фирма специализируется на небольших (до десяти человеколет) проектах.

* Разумные расходы на тестирование будут порядка 20-30%. Пусть 30%.

* Расходы на прогон тестов 30% (цифры озвучены Вячеславом Панкратовым) от бюджета тестирования или 9% от бюджета проекта.

* Затраты на прогон тестов, которые имеет смысл автоматизировать может достигать четверти. Или ~ 2% от бюджета проекта.

* Если в фирме, годовой бюджет всех проектов 1 000 000$, то уменьшение за счет подобной автоматизации будет касаться всего 20 000$, а выигрыш может достигнуть даже 5 000$. Это слезы. При большем бюджете подобная автоматизация уже может быть оправдана. (Вячеслав обещал привести свой расчет).

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

* Изучение продукта

* Разработка стратегии

* Создание сценариев

* Критические пересмотры дефектов

* Обучение

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

Теперь немного о личном опыте. У нас довольно большой (по меркам РФ) бюджет и он будет только расти. Проекты «долгоиграющие» и относятся, скорее, к большим, чем к средним. Однако мы столкнулись еще с одним ограничением инструментов:

* Плохая поддержка библиотек для разработки интерфейсов сторонних разработчиков. Так, на данный момент, только TestComplete поддерживает библиотеку DevExpress и то не в полном объеме. А элементы управления ArcGis не поддерживаются никем.

Последнее делает для нас нецелесообразным автоматизацию этих видов тестов. По крайней мере, сейчас.

Апрель 25, 2007

21. Корневые проблемы отрасли

Доклад на SQADays-1 21 апреля 2007г

Основные проблемы наших компаний - это не качество процессов или продуктов. И даже не отсутствие высококвалифицированных инженеров на рынке труда в достаточном количестве. Эти технические задачи можно легко решить, если будут устранены корневые проблемы отрасли.

Для поиска ключевой проблемы отрасли я воспользовался инструментом «Пять почему?», так популярном в кайдзен.

- У нас проблемы с качеством процессов.

- А почему существует эта проблема?

- Потому что на рынке мало высококвалифицированных инженеров.

- А почему их мало?

- Потому что отрасль молода, зарплаты невелики, практически отсутствуют тренинги по тестированию, ВУЗы не готовят инженеров по специальности «качество программных продуктов».

- А почему сложилась такая ситуация?

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

- Почему это происходит?

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

- Почему профессиональные менеджеры (управленцы) не востребованы в нашей стране?

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

Мгновенно последовало возражение Вячеслава Панкратова: «Я разговаривал с владельцами многих компаний. Они говорят, что хотят денег».

Вячеслав, а где противоречие между этими двумя утверждениями? Как верно заметил Сергей Середа: «Ключевое слово - зарабатывать».

Пару лет назад, в очень известной компании мне прямо заявили: «Мы не заинтересованы в снижении издержек на создании ПО».

Причин нежелания зарабатывать много:

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

2. В принципе, владельцу все равно, сколько денег он получает. Главное, чтобы его работникам было плохо. Вот, например, реальная история на эту тему.

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

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

4. Владельца компании интересуют не столько деньги, сколько личный кабинет, шофер и девочка, приносящая кофе (египетский синдром). Наши компании в этом вопросе – полная противоположность японским (см. «Sony. Сделано в Японии» Акио Марито).

Проблема отрасли? Проблема. А проблемы тестирования, кодирования и прочие - они вторичны. Ноги растут отсюда.

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

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

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

Я всерьез задумался об уходе из IT в другую область. Но. Мне уже 37 и у меня 20 лет работы за компом. А молодежь уходит. И никакими призывами их не удержишь.

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

Или решать нужно корневые проблемы? Организовывая свои фирмы, где этих проблем не будет?

«Если вы не хотите, чтобы мы зарабатывали деньги для вас, то нам ничего не остается, кроме как зарабатывать их для себя».

Май 7, 2007

22. Введение в нагрузочное тестирование

Терминология

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

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

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

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

Стресс тестирование - поведение системы при недостатке ресурсов (ресурсов процессора, дискового пространства, обрывов сети, …)

Цели и задачи

Все четыре вида тестов принадлежат к одной группе и их иногда называют общим термином «Нагрузочное тестирование». На самом деле эти тесты преследуют различные цели.

Тестирование производительности применяется наиболее часто. Оно применяется на различных стадиях проекта. Цель этого тестирования ответить на вопросы:

На стадии проектирования.

* Какая из архитектур системы лучше? Трех или четырехуровневая, где и как хранить файлы, обеспечат ли выбранный язык и БД необходимую производительность и т.д.

На стадии программирования.

* Какая схема БД лучше? Стоит ли отказаться от нормализации БД в пользу производительности или наоборот; как делать вьюшки; что лучше триггера или внешние ключи.

* Какой участок кода следует оптимизировать в первую очередь

* На стадии тестирования:

* Максимальная производительность системы

* Определение увеличения времени отклика и длительность операций при увеличении нагрузки.

* Определение предела применимости программы по числу пользователей.

* Определение влияния конфигурации системы на производительность.

* Пиковая нагрузка на систему.

* На стадии поставки:

* Удовлетворяет ли архитектура и настройка сети требованиям производительности?

Классическая ошибка - проведение тестирования производительности только на стадии тестирования.

Узкие места и объекты тестирования

Достаточно часто, схема бизнес приложения выглядит следующим образом:

Если рассматривать логические потоки информации, то очевидно узким местом становятся сервер приложений и сервер БД. Как правило, возможности системы ограничиваются возможностями сервера приложений, иногда сервера БД. Для увеличения производительности применяют два метода: оптимизацию кода или БД и аппаратное наращивание (увеличение мощности серверов, создание кластеров).

Если рассматривать физическую организацию, то к этим узким местам добавляется производительность сети. Здесь так же имеются два метода увеличения производительности: программная (минимизация трафика для бизнес-операций) и аппаратная (изменение параметров сети).

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

* % загрузки процессора сервера приложений

* % загрузки процессора сервера БД

* Средний объем переданных по сети байт за секунду

* % использования памяти на сервере БД

* Средний объем считанных с винчестера сервера БД байт за секунду

* прочее

Параметр близкий к насыщению указывает на участок, отвечающий за производительность системы в целом. «Цепь не может быть прочнее, чем самое слабое звено»

Метод тестирования

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

Здесь уместна аналогия с экзаменом. Цикл: студент обдумывает решение, отвечает, экзаменатор оценивает решение, дает следующее задание.

* При одном студенте экзаменатор будет большую часть времени простаивать. Его производительность в единицу времени будет незначительной.

* При некотором количестве студентов мы получаем оптимум: и преподаватель и студенты постоянно заняты.

* При дальнейшем увеличении студентов производительность преподавателя остается примерно постоянной, но время ожидания студентов растет пропорционально их числу.

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

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

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

Объекты тестирования

* Тестирования времени выполнения системой одной операции

* Тестирование времени выполнения системой цепочки действий (бизнес операции)

* Тестирования времени выполнения компонентом одной операции. Применяется для исследования и оптимизации узких мест.

Типичный сценарий тестирования

1. Пользователь определяет следующие параметры:

* Команду, время отклика которой тестируется

* Общее время выполнения. По умолчанию пять минут.

* Время начала замера от начала выполнения. По умолчанию 1 минута.

* Время окончания замера от начала выполнения. По умолчанию 4 минуты.

* Время задается в целых минутах

* Проверки на правильность ввода можно не проводить

* Паузу в сек между отдачей команд

* Список значений для выбранного пользователем параметра если таковой имеется. (Как вариант задавать список идентификаторов объектов)

* Число потоков

* Для каждого потока логин и пароль. Можно задать различные, можно одинаковые. Пароль в поле ввода не скрывать

2. Пользователь отдает команду на начало выполнения теста

3. Демон отдает команду тестируемой системе и ожидает ее завершения.

4. После получения управления демон посылает следующий запрос.

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

5. После окончания теста собираются следующие данные:

* Общее число удачных запросов.

* Среднее время отклика в секундах, с точностью до сотых

* Среднее время отклика в секундах, с точностью до сотых для каждого потока и их номера

Также желательны:

* Число переданных и принятых по сети байт

* Загрузки процессора на сервере и клиенте

* Объемы занятой и свободной памяти на сервере и клиенте

Техника выполнения

Ручная

Может быть использована при отсутствии других вариантов.

Пусть требуется протестировать приложение клиент-банк на возможность одновременной работы до 100 работающих пользователей. Наблюдение за операторами показывает, что они работают с приложением только 20% времени и в среднем тратят на бизнес операцию 2 мин.

Средняя нагрузка от одного оператора – 1 бизнес операция в 10 мин

В пике от всех – до 50 бизнес операций в 10 мин и до 10 в минуту.

Если не беспокоиться о правильности ввода, то можно совершать 1 операцию в 30 сек.

Итак, нам понадобится 7 тестеров:

* один, следящий за счетчиками на серверах и управляющий процедурой

* один замеряющий время отклика

* и пять тестеров, грузящих приложение

Такой способ выполнения очень дорог, ненадежен и зачастую неприменим. Если требуется ответить на вопрос о максимальном количестве пользователей, то сложно даже представить, сколько тестеров понадобится. Один, пять или пятьдесят.

Специализированными средствами нагрузочного тестирования

На рынке есть масса средств для нагрузочного тестирования со своими преимуществами и недостатками:

* Rational PerformanceStudio

* LoadRunner

* WAST

* И т.д.

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

Самостоятельно написанной утилитой

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

Типичные результаты тестирования

Характерное поведение web приложения под возрастающей нагрузкой.

B – точка максимальной производительности системы

D – точка потери производительности

E – точка краха системы.

При увеличении числа потоков производительность системы растет, до достижения точки максимальной производительности (B). Для динамической веб-страницы на IIS это обычно происходит при 2-5 потоках. Далее идет почти ровное плато производительности (B-C-D) при линейном возрастании времени отклика. Затем происходит резкое падение производительности. Типичная ситуация: при 24 потоках время отклика -2.7 сек, при 25 – 7 сек, при 26 – система не отвечает. Для веб-сервера, как правило, точка D соответствует времени отклика 3 сек.

Из этих выкладок следует, что можно оценить максимальную производительность и максимальное число одновременных запросов по одному запросу. Если при 8 потоках время отклика составляет 1 сек (8 запросов в секунду), то разумно искать точку краха системы в области 18-24 запроса. А максимальная производительность будет порядка 9 запросов в секунду (+10%) при 2-3 одновременных запросах (точка B).

Интерпретация результатов

Допустим мы получили результат: Максимальная производительность достигается при трех одновременных запросах. При этом производительность системы составляет девять запросов в секунду. А каково максимальное количество пользователей?

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

Если пользователь обращается к системе один раз в 60 секунд (режим просмотра сообщений в форуме), тогда максимальное число одновременно работающих пользователей – 270 человек.

Если же пользователь обращается к системе пять раз в одну секунду (режим сетевой игры), то поиграть в такую игру смогут максимум двое.

Май 14, 2007

Комментариев: 5

1. longraw написал 3 Февраль 2008

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

Про сервер БД очень неточно написано. % утилизации памяти на сервере БД будет фиксированным в 99% процентов проектов. Для Оракла и MS SQL необходимо снимать статистику использования памяти и дисковых групп разными процессами внутри самого сервера БД встроенными средствами. Для диска - тоже самое. Например у Вас на реальном сервере Oracle 10g 30 LUN, из них 20 7+1 дисковых в RAID 0+1 под разные датафайлы, 6 7+1 дисковых RAID-5 под REDO логи и 4 7+1 дисковых RAID-6 под arcivelog.

Снять статистику ОС по IOps или по потоку - все равно что померить шум песков на Марсе.

Еще нигде явно не написано, что основной параметр, который фиксируется - время реакции системы на внешние воздействия. Т.е. нагрузка создается таким образом, чтобы время реакции на различные внешние воздействия попадала в заданные пределы.

2. alex7kir написал 12 Сентябрь 2008

Не могли бы Вы уточнить, как именно Вы получаете цифры 270 и 2 человека интерпретации результатов? Создается ощущение, что результаты в этой статье и в "Тестирование производительности. Тренинг, по ICQ" (http://blog.shumoos.com/archives/76) результаты посчитаны по-разному, хотя схема вроде бы одна. Или я что-то не понимаю? Автор или понимающие читатели, просветите, пожалуйста.

3. sorokin_in_ua написал 14 Май 2010

Методика расписана фундаментально, но после прочтения теории хочется перейти к практике. Причем меньше всего хочется писать самописную утилиту для тестирования (впрочем, тут сильно зависит от возраста, студенты считают что их сила в написании собственного решения, то бишь велосипеда). Хочется взять какой-то инструмент, и оттестировать свою систему.

В свое время перерыл половину интернета чтобы найти адекватный пример по тестированию для HTTP POST, так что если кому надо, то велком - {http://sorokin.in.ua/?p=323}

4. bugmenot2 написал 11 Июнь 2010

Наверное, не WAST а WAPT

5. SALar написал 22 Июнь 2010

http://msdn.microsoft.com/ru-ru/asp.net/aa336559.aspx

Средство Web Application Stress Tool (WAST)

Средство оценки производительности веб-приложения Microsoft WAS предназначен для реалистичной имитации запросов страниц несколькими обозревателями с одного веб-узла. Это средство можно использовать для сбора информации о производительности и стабильности вашего веб-приложения. Средство имитирует большое количество запросов при относительно небольшом количестве клиентских компьютеров. Целью является создание среды, максимально приближенной к рабочей, для поиска и устранения проблем веб-приложения до его развертывания.

Надо сказать, порядком устаревший инструмент.

PS от 2023. Уже в 10-х многое было сильно по-другому.

23. Особенности национального юзабилити тестирования

Доклад на SQADays-1

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

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

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

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

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

С программным обеспечением примерно тоже самое. Если по результатам коридорного тестирования окажется, что продукт непригоден для эксплуатации, то на переделку может понадобиться 50-80% от первоначального бюджета. На стадии опытно промышленной эксплуатации коридорное тестирование почти бесполезно. Оно может иметь смысл если:

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

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

В феврале 2007 года я был по делам в фирме Softkey. В частности, речь зашла об их сайте. Я сказал, что пользоваться сайтом неудобно и пообещал прислать описание ошибок. Через несколько дней я прислал им краткий обзор, в котором указал по одной ошибке на три метода тестирования удобства:

* Соответствие объектам предметной области

* Разбиение на области

* Используемые лексемы

Заключение: «Что с этим делать, решайте сами. Мое мнение – косметическими мерами дизайн не исправить».

Если Softkey сможет переделать свой сайт, то останется только преклониться перед их уважением к пользователям.

Ну а теперь поговорим о предыдущей волне юзабилити. Это была волна повсеместного увлечения шрифтами, цветом, выравниванием. Дизайнеры до хрипоты спорили об уместности использования фреймов и запрещенных цветовых парах. Я согласен, что темно синий шрифт, высотой пять точек, читать на темно зеленом фоне неудобно. Особенно, если он реализован в виде бегущей строки. Но это даже не вершина айсберга! Ну, нельзя «тщательно обработав напильником» получить из паровоза истребитель. Приходит этакий дизайнер к владельцу вышеописанного офиса и говорит: «Да тут все просто. Нужно, чтобы дверь имела золотое сечение, батареи (те, которые снаружи) нужно покрасить в контрастный по отношению к стене цвет. И вот еще что. Неплохо, если бы окна могли менять прозрачность». К сожалению, это не очень поможет. Если здание изначально спроектировано неправильно, то покраской ограничься нельзя. Не поможет.

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

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

Возьмем, к примеру, движок блога, используемый сайтом software-testing.ru (сайт на данный момент мертв). И рассмотрим такую простую функцию, как вставка картинки. На этом месте моего доклада, Вячеслав Панкратов, создатель и владелец ресурса начинает тянуть руку и восклицает: «Я знаю, о чем идет речь». Вячеслав, претензия не к вам. Вы всего лишь используете неудачный движок. Кроме того, это небольшой контент-проект, которому простительно иметь ошибки. Вот для живого журнала подобные ошибки могут оказаться фатальны.

Рассмотрим, как может выглядеть прецедент вставки картинки в статью:

1. Пользователь отдает команду загрузить картинку

2. Система предлагает указать местоположение файла

3. Пользователь выбирает файл

4. Система загружает файл

5. Пользователь указывает место в тексте и отдает команду «вставить картинку»

6. Система вставляет картинку в текст

Как реализовано:

Сначала нужно закачать файл, средствами не блога, но форума.

Затем смотрим свойства миникартинки (адрес самого рисунка динамический и его в блоге использовать нельзя!)

http://forums.software-testing.ru/uploads/-05214_thumb.jpg

вручную преобразуем к такому виду:

http://forums.software-testing.ru/uploads/--1138205214.png

убирая "_thumb" и восстанавливая исходное расширение файла.

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

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

Рассмотрим другой пример. Яндекс-деньги, оплата за скайп. Коммерческий сервис, рассчитанный на массовое использование.

Напишем прецедент (юзкейс).

Основное действующее лицо: пользователь.

SuD (обсуждаемая система): сервис яндекс-деньги + платежная система скайп

Заинтересованные лица: правовая система

Контекст использования: ОДЛ просматривает список доступных платежей.

Основной сценарий.

1. ОДЛ выбирает «осуществить платеж»

2. Система подтверждает, что ОДЛ авторизированно на сайте

3. Система подтверждает наличие средств для совершения минимального платежа

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

5. Система предлагает заполнить реквизиты платежа, смотри описание объекта «платеж»

6. ОДЛ заполняет реквизиты платежа

7. Система подтверждает корректность данных

8. Система предлагает подтвердить личность владельца кошелька

9. ОДЛ вводит платежный пароль

10. Система подтверждает правильность платежного пароля

11. Система осуществляет платеж

Этот прецедент очень интересен необходимостью учитывать интересы всех заинтересованных лиц. Именно благодаря им появляются шаги 7-9. Попутно отмечу, что при использовании модели «Действующие лица и цели» эти шаги могут оказаться пропущенными (см. {Немного критики в адрес RUP}).

Альтернативный сценарий.

3.а.1 Система сообщает о невозможности платежа.

Прикинем эскизы форм по основному сценарию.

Первая экранная форма платежа

Вторая экранная форма платежа

И все.

Проектирование закончено. После чего останется «обработка напильником», такая как выравнивание, подбор шрифтов и пр.

Посмотрим, как это реализовано сейчас:

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

Отлично, но зачем при совершении платежа нужно вводить пароль получателя!? Здесь явный промах. Не важно, у команды Яндекса или Скайпа. Важно, что система в целом спроектирована неправильно.

А это реквизиты платежа. Их явно надо было вводить страницей раньше.

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

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

Май 14, 2007

24. Определение термина дефект

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

"Быстрое тестирование" Роберт Калбертсон, Крис Браун, Гэри Кобб:

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

"Тестирование Дот Ком, или Пособие по жестокому обращению с багами в интернет-стартапах" Роман Савин

Итак, баг (bug) — это отклонение фактического результата (actual result) от ожидаемого результата (expected result).

В соответствии с законом исключенного третьего у нас есть баг при наличии любого фактического результата, отличного от ожидаемого.

Википедия

В целом, разработчики различают дефекты программного обеспечения и сбои. В случае сбоя программа ведёт себя не так, как ожидает пользователь. Дефект — это ошибка/неточность, которая может быть (а может и не быть) следствием сбоя.

Мое определение.

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

"Интересы участников" - следует понимать в значении А. Коберна.

Апрель 7, 2008

Комментариев: 8

1. karkadil написал: 7 Апрель 2008

Дефект - поведение программы, затрудняющая или делающая невозможным достижение целей пользователя или удовлетворение интересов участников

Трудно согласиться: грамматическая ошибка - тоже баг, интерфейсный, однако он ничего не затрудняет.

У вас в определении дефекта, кстати, тоже есть баг. Надо бы вот так:

Дефект - поведение программы, затрудняющЕЕ или делающЕЕ [:)]

2. SALar написал: 7 Апрель 2008

«- Нул посчемтудже. Обдилие отрагравитестикх огшибхог зруднуят ралту с по»

Ну почему же. Обилие орфографических ошибок затрудняет работу с ПО.

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

PS. Да. На этом блоге премодерация.

3. SALar написал: 7 Апрель 2008

И самое важное. Отдельная орфографическая ошибка может быть и не затрудняет достижение цели пользователем, но наносит удар по репутации производителя и издателя. Т.е. затрудняет или делает невозможным удовлетворение интересов участников. Замечу, что участники - понятие более широкое, чем пользователь. Участник может даже не знать о существовании программы, но при этом его интересы могут страдать из-за некорректного поведения программы.

В этом отличие моего определения от остальных.

4. Alexei Barantsev написал: 8 Апрель 2008

Сергей, посмотри вот здесь интересную коллекцию терминов: {http://www.softwaredevelopment.ca/bugs.shtml}

Ещё любопытно вот это исследование Канера, в котором он пытается подвести юридическую базу под понятие дефекта ПО: http://www.kaner.com/pdfs/defects4.pdf

А моё любимое определение вот такое (источник - {http://www.sei.cmu.edu/sema/pdf/defect-prediction-techniques.pdf}):

"Software Defect: any flaw or imperfection in a software work product or software process

- software work product is any artifact created as part of software process

- software process is a set of activities, methods, practices, and transformations that people use to develop and maintain software work products"

5. Alex Lebedev написал: 19 Апрель 2008

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

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

6. SALar написал: 20 Апрель 2008

> Помимо принципиальной реализуемости правильного варианта, нужно чтобы

> реализация этого варианта входила в установленные рамки (scope) проекта.

Скорее да, чем нет.

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

7. Alex Lebedev написал: 21 Апрель 2008

Если мы привязываем понятие качества к соответствию требованиям, то управление требованиями никак не является посторонней темой.

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

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

8. Ghost83 написал: 13 Май 2008

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

25. Задачи и вопросы на собеседовании. Задача для тест-дизайнера

Нужно протестировать компонент, который преобразует дату из формата ДД.ММ.ГГГГ в текстовый формат. Т.е. из «11.05.2005» должно получиться «Одиннадцатое мая две тысячи пятого года».

Составьте тестовый набор.

Примечания:

* Особенно интересен тестовый набор для допустимых значений.

* API (GUI) компонента, формат данных и диапазон допустимых значений претендент может придумать сам или попросить его задать.

PS. Решение пока не даю, но вы можете прислать мне свои варианты решения.

Май 27, 2007

Комментариев: 7

1. dpi написал: 26 Июнь 2007

1. Проверка компонента на предмет корректной обработки формата входных данных.

а. Введенная дата не пустая.

б. Введённая дата не содержит пробельных символов (пробелы, табуляции, пустые символы, переносы).

в. Длина введенной даты не превышает 10 символов.

г. Дата не содержит иных символов кроме как цифры и точки.

д. Положение точек в записи даты строго определено и дата не может быть введена в другом формате кроме как XX.XX.XXXX, где X-любая цифра.

2. Проверка компонента на предмет корректной обработки крайних значений: числа, месяца, года.

а. Нулевое число, месяц, год.

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

в. 29 февраля в высокосном и невысокосном году.

3. Проверка компонента на правильное преобразование числа в текст.

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

б. Первые нули в названии года не читаются.

в. Проверка падежей (т.е. окончаний слов) в названиях чисел, месяцев, лет, тысячелетий.

2. SALar написал: 22 Июль 2007 в 21:40

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

Наводящие вопросы:

К какому типу относятся входные / выходные параметры?

Нужно ли использовать ортогональную матрицу? И почему?

3. dpi написал: 8 Август 2007

Ну да, что-то не подумал.

Конечно стоит проверить правильную конвертацию в слова введенных чисел дней, месяцев и лет.

Т.е. по порядку:

01 - первое

31 - тридцать первое

01 - января

12 - декабря

для годов аналогично для каждого порядка

Зачем тут использовать ортогональную матрицу откровенно не знаю.

4. SALar написал: 22 Август 2007

Это неплохой набор.

Но, во-первых, он избыточен.

Во вторых, недостаточен.

5. dpi написал: 18 Сентябрь 2007

Можно подробнее по последнему замечанию?

В чем избыточен и в чем недостаточен?

6. SALar написал: 19 Сентябрь 2007

Недостаточность.

Есть еще один класс граничных условий. И его тоже нужно проверить.

Избыточность.

"22, 23, 33, 34" - нельзя ли отсюда что-нибуть выкинуть?

7. dpi написал: 26 Сентябрь 2007

Ок, для месяцев из второго десятка можем исключить проверку с 22 по 29 - 21 требуется для проверки правильного отображения десятков ("двадцать"). Остальные значения от 1 до 31 уникальны и требуют проверки. Выше 31 проверять нет смысла т.к. это уже проверяется набором из 2 группы тестов - "граничные условия"

Для лет исключаем 22-29, 32-39, 42-49 - 92-99. Собственно я это и имел ввиду, когда написал про аналогичную проверку для каждого порядка.

Еще один класс граничных условий пока не придумал.

26. Профессиональный менеджер. Кто ты?

Часто мы слышим: "Мы профессиональная команда", "мы ищем профессионалов". А кто же такие, эти профессионалы?

Рассмотрим гипотетический диалог руководителя и подчиненного [1]:

- Я перерос ту работу, которой занимаюсь.

- А в чем именно заключается твоя работа?

- Пишу тестовую документацию и выполняю тестирование по разработанным тестовым сценариям.

- И ты действительно умеешь писать тестовую документацию настолько хорошо, чтобы заявлять, что ты все уже тут знаешь?

- Я имею в виду, что я знаю все в проекте.

- Тогда у тебя есть замечательная возможность оттачивать свое мастерство в написании документации.

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

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

1. Конфликт между текущей и ожидаемой компенсацией. У сотрудника появился еще один стимул активно искать другую работу, начиная с текущего дня. И очень вероятно, что он ее найдет. И покинет фирму. И это еще неплохо.

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

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

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

Вот это профессиональный управленец [2].

------------------------------------

[1] Диалог взят из статьи «Как стать Профессионалом?» Ростислава Борука.

[2] В современном жаргоне менеджер, но термин "управленец" более точен, хотя и не так ласкает слух.

Май 28, 2007

Комментариев: 2

1. Rutol написал: 14 Июль 2007

Сергей, вообще статья потрясающая.

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

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

А тебе, Сергей, такое чудо живьем встречать приходилось?

2. SALar написал: 22 Июль 2007

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

27. Как выбрать тренинг

Довольно часто люди задают вопрос: а куда пойти учиться? И это вроде бы при том, что курсов довольно много. Но по прохождении большей части курсов у людей остается странное чувство "Зачем я туда ходил?".

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

Правило №1 при выборе курса: "Выбирать нужно не курс и не фирму. Выбирать нужно лектора".

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

Преподаватель должен обладать следующими качествами:

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

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

* Очень желателен опыт проведения курсов. Хотя бы часов пятьсот. Как показывает практика, полтора года по 6-8 часов лекций и семинаров в неделю (итого 300-500 часов) практически минимальный опыт, после которого преподаватель начинает осознавать, чем он занимается.

Правило №2 «Старайтесь выбрать курс, на котором учат решать практические задачи, а не рассказывают про инструменты.»

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

Как справедливо высказался Дунин Илья по поводу одного из подобных тренингов:

«В общем, если хотите у них заказывать курс, то настаивайте на согласовании программы обучения и сразу выкидывайте оттуда все, ну или почти все о [инструменте], т.к. там будет рассказ о никому не нужных (кроме истинных …) программных и аппаратных средствах, том же …[инструмент]. Если бы у меня была еще одна возможность, я бы именно так и сделал.»

Очень толковая рекомендация. Может и нельзя выкинуть рекламу инструмента, то платить за нее из своего кармана точно не следует.

Правило №3. Тренинг — это не презентация.

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

- Кем хочешь стать?

- Кузнецом.

- А сумеешь?

- Конечно. Я же целое лето наблюдал за работой на кузне.

Ну, хоть раз то молотком стукнуть нужно? А мехами поработать? Я полагаю, что практические работы, выполняемые посетителями курсов должны составлять от 30 до 70% времени тренинга. Ведь наиболее ценным отличием занятий с живым человеком от чтения литературы является возможность обратной связи. Самый важный вопрос, который задает учащийся: "Посмотрите, если сделать вот так, это будет правильно?" Без ответов на этот вопрос ценность тренинга стремительно падает.

Мало тренингов, отвечающих этим правилам? Согласен, мало. Давайте создадим спрос на них. Задавайте вопросы в учебных центрах. И глядишь ситуация изменится.

Июнь 14, 2007

Один комментарий

1. SALar написал: Ноябрь 2007

Чуть позже нашел статью, объясняющую почему на рынке так много некачественных тренингов и почему любую информацию о тренинге, стараются скрыть: {http://vitus-wagner.livejournal.com/171382.html}

PS. За 15 лет мало что изменилось.

28. Введение в юнит тестирование в VS2005

1. Введение

1.1. Обзор

Статья написана в стиле «Давайте начнем». На простом примере рассматривается модульное тестирование в среде VisualStudio 2005 Team Suite.

Никакой глубины или широты обзора не предполагается. В данной статье не рассматривается стратегия «Разработки Ведомой Тестированием», стратегия тестирования, подходы к написанию тестов.

В стороне остались такие интересные вещи как:

1. Запрет публикации не оттестированного кода

2. Запись скриптов для веб тестирования

3. Управление ручными тестами

4. Нагрузочное тестирование

И многое другое.

1.2. Исходная задача

Требуется создать библиотеку для вычисления интегралов.

Библиотека должна вычислять:

• Простой факториал

• Двойной факториал

• Примориал (в первой версии не реализуется)

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

Библиотека должна вычислять 0! и 0!!

Библиотека должна возвращать длинное целое.

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

Правила вычисления согласно {википедии}.

1.3. Средство разработки

Для работы нам понадобится VisualStudio 2005 Team Suite.

VisualStudio 2005 Express Edition или VisualStudio 2005 Professional не поддерживает модульное тестирование.

1.4. Проект

Тестируемы проект MathLib. Исходный код в приложении. Почему именно так, а не по другому в данной статье не рассматривается.

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

2.Подготовка к тестированию

2.1. Создание проекта тестирования в солюшене

File -> New -> Project

Создание тестового проекта. Шаг 1.

Не забудьте указать имя проекта (согласно соглашению о наименованиях, в качестве имени тестового проекта берут имя тестируемого проекта и добавляют префикс «Test») и выбрать опцию «Добавить в проект».

Создание тестового проекта. Шаг два.

Будет создан проект тестирования с заготовками тестов.

Проект тестирования можно создать другими способами (см. документацию). Но я всегда следовал простой логике: сначала создаем контейнер, потом наполнение.

2.2. Создание ссылки на тестовый проект

1. Solution Explorer -> TestMathLib -> контекстное меню -> Add Reference

2. Projects

3. Выбрать проект MathLib

3. Тестирование

Перед нами встают вопросы:

• Как организовать тесты: «Каждый в своем файле», «Все в одном»?

Попробуем и тот и другой подходы.

• Использовать ли ручное тестирование?

Удалим ручной тест. В этом проекте мы ничего руками тестировать не будем.

• Как именовать тесты?

У каждого свой взгляд на соглашение об именах. Я предложу следующий подход: тестовый класс должен содержать указания на тестируемую функциональность и класс эквивалентности. Тестовый метод должен явно указывать на класс эквивалентности. Идеальный вариант – код понятен без комментариев.

3.1. Первый тест

Переименуем заготовку в SimpleFactorial.sc

Добавим using MathLib;

Удалим «#region Additional test attributes». Нам не нужно ничего инициализировать и не нужно ничего удалять после проведения теста.

Проведем тест на равенство:

• 5!==120

Код:

using System;

using System.Text;

using System.Collections.Generic;

using Microsoft.VisualStudio.TestTools.UnitTesting;

using MathLib;

namespace TestMathLib

{

[TestClass]

public class SimpleFactorial

{

public SimpleFactorial()

{

}

[TestMethod]

public void TestSimpleCalc()

{

IFactorial factorial = FactorialProvider.CreateInstance(FactorialType.Simple);

Assert.AreEqual(120L, factorial.Calculate(5));

}

}

}

Пояснения:

• [TestMethod] – Указание, что это тестовый метод, и он должен отображаться в менеджере тестов.

• Assert.AreEqual() - Сравнение возвращаемого результата с эталонным.

3.1.1. Прогон теста

Запустим наш тест. Shift+Alt+X. Также тест можно запустить через панель инструментов или главное меню: Test-> Start Selected Test Project with Debugger .

3.1.2. Результаты прогона

Через некоторое время получаем результат. Успешно пройден один тест.

Кроме того, мы видим закладку «Code Coverage Results» (покрытие кода).

Покрытие кода первым тестированием.

Посмотрим, какие участки кода не были пройдены. Двойным щелчком на методе, откроем файл SimpleFactorial.cs

Красным показаны не покрытые участки кода, розовым – частично покрытые. Так проверка number 15 – нет.

Число не пройденных блоков считается следующим образом:

• if(number 15) – 1 раз

• throw new ArgumentOutOfRangeException("number"); - 2 раза

• return 1L; - 1 раз

3.2. Продолжение тестирования

Тестирование граничных условий простого факториала

3.2.1. Новый тест

Создадим новый тест.

• Solution Explorer -> TestMathLib -> Add -> New test -> Unit Test

• Введем название: SimpleFactorialBoundTest.cs

Введем тесты на граничные условия (код смотри в приложении).

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

Больше ничего нового для написания тестов нам не понадобится.

3.2.2. Использование менеджера тестов

Тестов стало больше, и теперь нам необходимо средство управления.

1. Test -> Windows -> Test Manager

Перед нами все наши тесты. Заметим, что не имеет никакого значения, в одном файле они созданы или в разных.

Сгруппируем тесты по тестируемой функциональности.

1. Создадим списки для простого и двойного факториала

2. Выделим тесты, относящиеся к тестированию простого факториала (сейчас это все тесты).

3. Перенесем их в нужную папку методом drag&drop.

Выполним наши тесты.

1. Укажем тесты, которые мы хотим выполнить. Взведем чекбокс «List of Tests»

2. Запустим тесты Ctrl+Shift+X

Результат: все тесты для простого факториала прошли, в коде вычисления простого факториала не осталось не оттестированных участков.

3.3. Дополнительные функции

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

Выстроим следующую шкалу приоритетов:

• 0 – неустановлен (по умолчанию)

• 1- минимальный

• 2 – средний

• 3 – максимальный

В окне свойств, зададим приоритет «3» для простого теста, «2» для тестов вне границ и «1» для прочих. Теперь мы можем запускать в качестве приемочных тестов только тесты с наивысшим приоритетом.

Группировка тестов по приоритетам.

Обратите внимание, на изменение кода. [TestMethod] изменился на[Priority(2), TestMethod]. Если кому-то удобней задавать приоритеты сразу в коде, то никто не мешает делать так.

4. Заключение

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

Приложения

SimpleFactorial.cs

using System;

using System.Text;

using System.Collections.Generic;

using Microsoft.VisualStudio.TestTools.UnitTesting;

using MathLib;

namespace TestMathLib

{

[TestClass]

public class SimpleFactorial

{

public SimpleFactorial()

{

}

[Priority(3), TestMethod]

public void TestSimpleCalc()

{

IFactorial factorial = FactorialProvider.CreateInstance(FactorialType.Simple);

Assert.AreEqual(120L, factorial.Calculate(5));

}

}

}

SimpleFactorialBoundTest.cs

using System;

using System.Text;

using System.Collections.Generic;

using Microsoft.VisualStudio.TestTools.UnitTesting;

using MathLib;

namespace TestMathLib

{

[TestClass]

public class SimpleFactorialBoundTest

{

public SimpleFactorialBoundTest()

{

}

[Priority(1), TestMethod]

public void TestBottomBound()

{

IFactorial factorial = FactorialProvider.CreateInstance(FactorialType.Simple);

Assert.AreEqual(1L, factorial.Calculate(0));

}

[Priority(2), TestMethod]

[ExpectedException(typeof(ArgumentOutOfRangeException))]

public void TestBottomBoundOut()

{

IFactorial factorial = FactorialProvider.CreateInstance(FactorialType.Simple);

factorial.Calculate(-1);

}

[Priority(1), TestMethod]

public void TestBottomBoundIn()

{

IFactorial factorial = FactorialProvider.CreateInstance(FactorialType.Simple);

Assert.AreEqual(1L, factorial.Calculate(1));

}

[Priority(1), TestMethod]

public void TestTopBound()

{

IFactorial factorial = FactorialProvider.CreateInstance(FactorialType.Simple);

Assert.AreEqual(1307674368000L, factorial.Calculate(15));

}

[Priority(1), TestMethod]

public void TestTopBoundIn()

{

IFactorial factorial = FactorialProvider.CreateInstance(FactorialType.Simple);

Assert.AreEqual(87178291200L, factorial.Calculate(14));

}

[Priority(2), TestMethod]

[ExpectedException(typeof(ArgumentOutOfRangeException))]

public void TestTopBoundOut()

{

IFactorial factorial = FactorialProvider.CreateInstance(FactorialType.Simple);

factorial.Calculate(16);

}

}

}

SimpleFactorial.cs

using System;

namespace MathLib

{

internal class SimpleFactorial : IFactorial

{

internal SimpleFactorial()

{

}

long IFactorial.Calculate(int number)

{

if(number 15)

throw new ArgumentOutOfRangeException("number");

if(number == 0)

return 1L;

long result = 1;

for(int i = 1; i

{

result *= i;

}

return result;

}

}

}

OddFactorial.cs

using System;

namespace MathLib

{

internal class OddFactorial : IFactorial

{

internal OddFactorial()

{

}

long IFactorial.Calculate(int number)

{

if (number 15)

throw new ArgumentOutOfRangeException("number");

if (number == 0 || number == 1)

return 1L;

long result = 1;

for (int i = number; i > 0; i -= 2)

{

result *= i;

}

return result;

}

}

}

IFactorial.cs

using System;

using System.Collections.Generic;

using System.Text;

namespace MathLib

{

///

/// Calculates factorial from 0 to 25.

///

public interface IFactorial

{

///

long Calculate(int number);

}

}

FactorialProvider.cs

using System;

using System.Collections.Generic;

using System.Text;

namespace MathLib

{

public enum FactorialType

{

Simple,

Odd,

Test

}

public static class FactorialProvider

{

public static IFactorial CreateInstance(FactorialType type)

{

switch(type)

{

case FactorialType.Odd :

return new OddFactorial();

case FactorialType.Simple:

return new SimpleFactorial();

default :

return new SimpleFactorial();

}

}

}

}

Февраль 2, 2006

29. Вопросы аналитику

Буквально недавно меня попросили провести собеседование с претендентом на позицию аналитика. Хорошо, что вопросы были сформулированы давно. Эта заметка в помощь остальным, проводящим подобные собеседования. Важно, почему и зачем мы задаем именно эти вопросы. Как только это станет понятно, можно будет придумать другие вопросы. А главное, понять, что должен отвечать кандидат.

Основные виды деятельности аналитика:

* Выявление требований

* Формализация требований для передачи остальным членам команды

Это основные виды деятельности. Гипертрофируем в утверждение: "Эти виды деятельности есть смысл существования проектной роли аналитик". Дополнительно, в зависимости от проекта, аналитик может заниматься внедрением, подготовкой рабочей и конечной документации, тестированием, подготовкой документов, в соответствии с ГОСТами. Оставим пока эти вещи в стороне и сосредоточимся на первостепенных.

Итак, вопросы кандидату:

Какие методы выявления требований вы знаете?

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

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

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

Из каких частей, по вашему мнению, состоит спецификация требований?

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

Какие инструменты анализа знаете?

Имеется ввиду не инструментальные средства, а именно инструменты, такие как "рыбий скелет", "диаграмма Парето", метод "пяти почему" и тому подобное. Это вопрос на выявление требований и переход к их формализации и ранжированию. Можно задавать этот вопрос в паре с задачей о лифтах. [1]

Общий вопрос, который стоит задавать кандидатам на любую позицию:

Что читали и что собираетесь читать, какие курсы посещали?

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

----------------

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

Июль 2, 2007

30. Модульное тестирование. Зачем, как и кто

Примечание. Описанный в статье подход соответствует скорее методу "стачала тест", нежели TDD.

Стратегия модульного тестирования

Модульное тестирование является одной из ключевых практик методологии экстремального программирования. Сторонники XP приводят следующие доводы в защиту этой практики:

* Написание тестов помогает войти в рабочий ритм

* Придает уверенность в работоспособности кода.

* Дает запас прочности при дальнейшей интеграции или изменениях кода.

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

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

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

На мой взгляд, модульное тестирование оправдано, если оно:

* Снижает время на отладку

* Дает возможность поиска ошибок с меньшими затратами, нежели при других подходах

* Дает возможность дешевого поиска ошибок при изменениях кода в дальнейшем

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

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

Цель модульного тестирования:

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

Отсюда следует несколько выводов:

* Нет смысла писать тесты на весь код. Некоторые ошибки проще найти на более поздних стадиях. Так, например, для ООП данное правило может звучать так: нет смысла писать тесты на класс, который используется только одним классом. Эффективней написать тесты на вызывающий класс и создать тесты, тестирующие все участки кода.

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

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

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

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

Первый вопрос, который встает перед нами: «Сколько нужно тестов». Ответ, который часто дается: тестов должно быть столько, чтобы не осталось неоттестированных участков. Можно даже ввести формальное правило:

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

Проблема в том, что, хотя не оттестированный код почти наверняка неработоспособен, но полное покрытие не гарантирует работоспособности. Написание тестов исходя только из уже существующего кода только для того, чтобы иметь стопроцентное покрытие кода тестами — порочная практика. Такой подход со всей неизбежностью приведет к существованию оттестированного, но неработоспособного кода. Кроме того, метод белового ящика, как правило, приводит к созданию позитивных тестов. А ошибки, как правило, находятся негативными тестами. В тестировании вопрос «Как я могу сломать?» гораздо эффективней вопроса «Как я могу подтвердить правильность?». Это наглядно демонстрирует статья {61 тест, который потряс программу}.

В первую очередь тесты должны соответствовать не коду, а требованиям. Правило, которое следует применять:

Тесты должны базироваться на спецификации.

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

Один из эффективных инструментов, для определения полноты тестового набора — матрица покрытия.

На каждое требование должен быть, как минимум, один тест. Неважно, ручной или автоматический.

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

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

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

Последнюю проверку полноты тестового набора следует проводить с помощью формальной метрики «Code Coverage». Она показывает неполноту тестового набора. И дальнейшие тесты можно писать на основании анализа не оттестированных участков.

Наиболее эффективный способ создания тестового набора — совместное использование методов черного и белого ящиков.

Распределение обязанностей

Где-то я читал следующую фразу: «Попросите программиста составить для вас (тестера) план тестов». Ну да. А потом тестер будет кодировать тесты. Генеральный директор рисовать дизайн, а администратор баз данных писать руководство пользователя. Не очень воодушевляющая картина.

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

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

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

------------------------------------

Терминология

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

Unit (Элемент) — наименьший компонент, который можно скомпилировать.

Драйверы — модули тестов, которые запускают тестируемый элемент.

Заглушки — заменяют недостающие компоненты, которые вызываются элементом и выполняют следующие действия:

* возвращаются к элементу, не выполняя никаких других действий;

* отображают трассировочное сообщение и иногда предлагают тестеру продолжить тестирование;

* возвращают постоянное значение или предлагают тестеру самому ввести возвращаемое значение;

* осуществляют упрощенную реализацию недостающей компоненты;

* имитируют исключительные или аварийные условия.

White-box testing. Для конструирования тестов используются внутренняя структура кода и управляющая логика. При этом существует вероятность, что код будет проверяться так, как он был написан, а это не гарантирует корректность логики.

Black-box testing. Для конструирования тестов используются требования и спецификации ПО. Недостатки:

* таким способом невозможно найти взаимоуничтожающихся ошибок,

* некоторые ошибки возникают достаточно редко (ошибки работы с памятью) и потому их трудно найти и воспроизвести

Февраль 15, 2006

31. Вопросы на собеседовании техническому писателю

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

* Грамотного письма и хорошей стилистикой изложения. Самый сложный навык.

* Знанием технического сленга. Т.е. хороший кандидат должен «отделять Гегеля от Гоголя».

* Умением структурировать информацию.

* Знание стандартов оформления документации.

Итак, вопросы с комментариями

* Привести структуру любого документа, который нужно будет создавать. Систему помощи, руководство программиста, …

* Составить главу помощи для чего угодно (например, для оплаты мобильного через банкомат).

Это проверка структуры изложения на высоком и низком уровне. В этом месте можно пойти вглубь. Спросить из чего состоит введение для SRS, зачем там нужен Scope? Кстати, а какой эквивалент “scope” и “SRS” в русском языке? Где располагается расшифровка аббревиатур? А для каких видов оформлений это характерно. Вместо спецификации требований можно взять «Описание объекта автоматизации». Но лучше не обращаться к совсем уж экзотике вроде «описания профиля пользователей», а спросить с чем кандидату приходилось работать. Если у человека хватило разума разобраться со структурой пары-тройки документов, то и с остальными справится.

* Назвать элементы управления на богатом скриншоте экранной формы

Это проверка технической лексики. Лучше попросить называть и русские, и английские названия

* Вычитать некачественный технический текст.

Это проверка языка. Хорошо, если в тексте будут различные типы ошибок. В первую очередь нужно следить за исправлением стилистических ошибок. Проблем с нахождением плохих статей возникнуть не должно. В конце концов, можно обратиться к редактору какого-либо онлайного издания (например, rsdn).

* Разработать положения для работы с внутрифирменной документации.

Хороший кандидат должен назвать следующие моменты:

* Все оформление только через стили

* Стили заданы в шаблонах

* Все документы создаются из шаблона

* Очень хорошо, если кандидат упомянет, что стили должны быть закрыты от редактирования

* Как оформляются подписи к таблицам и рисункам?

* Для чего нужна история изменений? Как она ведется? Какое влияние оказывают репозитории?

* и т.д.

Как вариант, вместо положений о документообороте можно попросить назвать рекомендуемые положения для «Стандартов написания систем справочной информации». Но это задание сложнее.

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

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

Июль 26,

Один комментарий

1. {ave} написал: 11 Июнь 2014

А как проверить аналитические способности кандидата (разложить сложные вещи на простые составляющие)? Как проверить, что он сможет осилить сложность системы, которую надо описывать?

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

Напрашивается вариант - на собеседовании рассказать кандидату про какой-нибудь небольшой, но концентрированно сложный кусочек системы и попросить его описать. Тут есть опасность, что кандидат заподозрит нас в желании получить доку нахаляву. К тому же, 1-2 страницы тоже могут быть не очень показательны.

32. Перспективы софтверных компаний

До меня дошли слухи, что Dell переносит разработку ПО из России в Индию. Переносит и переносит. Вопрос в том, случайное ли это событие или тенденция.

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

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

За годы, в которые наши специалисты стоили на мировом рынке дешевле грязи, мы чего-то добились. Компании с десятка сотрудников выросли до сотни. Появились компании, численность сотрудников в которых перевалила за тысячу. Правда так и не появилось крупных с годовым оборотом хотя бы в полмиллиарда долларов. Да и средних как-то маловато. Вопрос – почему?

До 2004 – 2005 года почти невозможно было найти профильные тренинги. Впрочем, и сейчас, в 2007 году, ситуация ненамного лучше. Тренинги вроде и есть, но их мало, они безумно дороги, и их тематика оставляет желать лучшего. Про качество говорить просто не хочется. Но это-то как раз не самое страшное. В конце концов, можно в качестве суррогата почитать литературу. Но в нашей стране не востребованы специалисты с хорошими теоретическими знаниями! Можно пройти десять тренингов. Или двадцать. Это неважно. Разница между компенсацией начинающего инженера (в среднем до четырех лет опыта) и опытным специалистом (в среднем от 10-15 лет опыта) практически отсутствует. И при приеме на работу совершенно не учитывается количество прочитанных книг или пройденных тренингов. Если все равно платят почти столько же, то зачем напрягаться? Итог: даже при возможности проходить профильные тренинги бесплатно и в рабочее время, люди на них не идут (реальные наблюдения). Не хотят напрягаться. И это пугает.

Качество управления проектов? Тут еще хуже, чем с профильными тренингами. Эпоха 22 летних ПМ-ов как началась в 90-х, так похоже и не собирается заканчиваться. Тех, кто с этим не согласен, прошу ответить на вопрос: «Каков процент руководителей проектов имеет хотя бы минимальный пятилетний опыт работы на инженерных должностях?» Я уж не говорю про нормальный 10-20 летний опыт. Имеется ввиду опыт работы именно на инженерной должности и обязательно в команде от пяти человек без совмещения с управлением и только опыт в коммерческих проектах с полным рабочим днем (частичную занятость можно пересчитать в полную по количеству отработанных часов).

За почти десять лет мы не приобрели инфраструктуры для профильного образования и не вырастили нормальных управленцев. Зато потеряли такое преимущество как чудовищную дешевизну. За последние пять лет типичная зарплата средненького специалиста выросла примерно в 3-4 раза (с 400 - 700$ до 1800 - 2200$). Отличные спецы у нас никогда не ценились и не получают зарплату сильно выше средней, поэтому их в расчет не берем.

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

В это же время Индия и Китай продолжают упорно развивать сферу разработки ПО. Да, мы до сих пор смеемся над «индусским» кодом. Но они совершенствуют процесс разработки. Мы — нет. По соотношению цена/качество Индия, похоже, нас уже обогнала. Может быть, даже обогнала просто по качеству. То, что в Микрософте на инженерных должностях сейчас работает порядка 60% индусов не такой страшный показатель. А вот то, что наши российские фирмы начинают передавать разработку за рубеж, это гораздо серьезней.

Для анализа перспектив поделим все наши софтверные компании на четыре условные категории:

1. Компании, сидящие на госзаказах или на заказах от крупных корпораций.

2. Производящие успешные коробочные продукты.

3. Компании, поставившие аутсорсинг на промышленную основу.

4. «Гаражные кооперативы» шароварщиков.

Фрилансеров рассматривать не будем. Это все-таки предприниматели, а не фирмы.

Бешеные бабки от экспорта нефти и газа дали питательную среду для компаний первого типа. И они сейчас цветут и пахнут. Будут нефтебаксы – будут эти компании. Не будет нефтебаксов - … Характерной особенностью такого типа компаний является сильная заинтересованность в числе работников вне зависимости от эффективности их работы. Осмечивать проекты как-то надо.

Компаний второго типа мало. Abbyy, Касперский, что еще можно назвать навскидку? SW-soft, Акронис, ну и еще с десяток. Только вот что интересно. Продукты, на которых «сидят» эти компании, в основном были созданы в начале девяностых. И линейка этих продуктов как-то не хочет расширяться. Где наши SAP, TFS, LineAge, EMC Documentum? Кое-что делается в игровой индустрии, но мало, мало. И не надо мне говорить про HMM-V. Это не наш продукт. Собственных «Героев» мы создать не смогли. Вышеперечисленные фирмы живут за счет нишевых продуктов и практически не расширяют линейку. Что произойдет с лабораторией Касперского, если Микрософт встроит приличный антивирус в свои десктопные и серверные ОС? Правильно, умрет. А все к этому идет. Да и системами распознавания текстов на западе начали заниматься. Т.е. на мой взгляд, у фирм второго типа не все безоблачно. Серьезного числа коробок у нас, похоже, не было, нет и не будет. Так что компании второй категории серьезного влияния на рынок не окажут.

У компаний третьего типа есть одна надежда. Что нефтяной рынок обвалится. В противном случае… ну вы все сами понимаете.

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

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

Итого у софтверной сферы в РФ два варианта развития в зависимости от протекания нефтяной лихорадки:

1. Нефтебаксы будут. Аутсорсинг умирает. Шароварщики вместе с профессиональными наемными работниками потихоньку перебираются за границу (зарплаты там может не сильно выше, зато все остальное становится существенно дешевле). В стране остаются только те фирмы, которые пилят бюджет. Они заинтересованы в основном в низко квалифицированном планктоне, который ходит на работу. Планктон остается. Софтверная индустрия в стране умирает.

2. Нефтебаксов не будет. Пильщики бюджета агонизируют, шароварщики могут остаться, могут уехать. Аутсорсеры радостно потирают руки, но профи начинают массово валить из страны и остается только планктон. И софтверная индустрия в стране умирает.

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

Грустно. И я уже слабо надеюсь увидеть в разделе «О компании»:

Наш оборот за прошедший год составил полтора миллиарда евро, фонд компенсации сотрудников составил 300 миллионов евро и при этом нас всего 220.

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

------------------------------------

Дополнение от июня 2008. Люксофт открыл филиал во Вьетнаме. Не продаж. Разработки.

Сентябрь 18, 2007

Комментариев: 4

1. Vitaliy написал: 9 Октябрь 2007

Очень рад, что Михаил Елашкин добавил вас на Itblogs

2. o жизни в IT - Ѕлог системного администратора еще о перспективах написал: 16 Январь 2008

[-] Задело за живое еще одно мнение на наболевшую тему будущего IT отрасли в нашей стране: …Зарплата хороших спецов не отличается от зарплаты средних потому, что хорошие спецы не нужны, точнее не востребованы бизнесом. Проекты - типичны, решения - стандартны. Зачем нужен хороший спец для реализации n + 1 портала или m + 1 - универсальной и развивающейся системы документооборота, если никаких ноухау в ее реализации не применяется, исследовательской работы нет, а возникающие проблемы зачастую можно решить хорошенько покопавшись в гугле? Потому и востребован средний спец. 10 баксов-то, у бизнеса, не лишние!

3. iriska написал: 6 Август 2008

Неплохой анализ. Неужели вывод - "всё плохо плохо плохо"? А как же "пободаться"?

Мне кажется, мало найти проблему - надо найти пути к её решению.

4. SALar написал: 6 Август 2008

Если честно, то не очень хорошо.

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

33. Ищу работодателя

"Процесс - это жизнь, результат - это смерть!"

© Жванецкий.

Ищу работодателя, для которого понятие "работа" - это то, что нужно сделать. Хочется посмотреть, а как у них там? Похоже таких мало. Пока мне встречался только один тип работодателя. Для которого "работа - это место, куда нужно ходить".

Наш российский принцип:

1) надо 5 аналитиков (техписов/ программеров / ПМ)

2) надо автоматизацию тестирования

3) надо стимулировать коллектив плакатами и цветовой дифференциацией бейджиков!!!

Это все не надо. Надо достигать результата. А одного и того же результата можно достигать, как наняв 5 аналитиков за 2000-2500$, так и просто заплатив аутсорсеру 15000-20000$. Второе выгоднее. Или платя одному хорошему аналитику приличную зарплату в 7-10$ тысяч (еще выгодней).

Короче. Вам шашечки или ехать? Пока всем нужны шашечки.

PS. Хотя может я перфекционист?

Октябрь 9, 2007

Один комментарий

1. Vitaliy написал: 9 Октябрь 2007

Перфекционист - это звучит гордо, разделяю ваше правильное отношение к понятию "работа".

34. Сказка о потерянном командообразовании

"Word на моем домашнем компьютере не знает слово «командообразование». Оно пришло к нам совсем недавно вместе с явлением, которое обозначает. Конечно же, это калька с английского «teambuilding». Однако и для Запада это явление в новинку."

Теперь и я узнал, что командообразование для нас в новинку. А я-то последние лет 5-10 мучался вопросом, ну почему никто не хочет заниматься командообразованием? Теперь понимаю. Нужно было сначала полностью похоронить нашу культуру командообразования, чтобы потом тянуть ее с запада. Ну ничего, глядишь еще лет через 25 запад дорастет до того, что у нас было четверть века назад…

Чтобы не быть голословным, термины “песок-мягкая глина-мерцающий маяк-…-…” ни о чем не говорят? А практики для прохождения по этим ступеням изучали? Пробовали? Сколько сотен (ладно, пусть десятков)? Какие именно? У туриков были свои методы, у КСП-шников - свои, у коммунаров - свои. Они все прекрасно работают.

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

Октябрь 11, 2007

35. Автоматизированное тестирование с самого нуля. Часть 2

Дисклаймер. Я не злой. И никого не хочу обидеть. И вообще это читать не обязательно. Ибо:

«Все истины, которые я вам хочу сообщить – гнусная ложь».

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

И соотношение эффективности между нашими и ихними компаниями вполне может быть не настолько удручающе. И вообще бывают разные наши и разные ихнии компании.

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

Примечание. Да, вот еще что. Под автоматизированным тестированием в этой статье понимается только и исключительно функциональное тестирование через GUI при помощи одного из инструментов: Rational Robot, QTP, TestComplete (священная корова, примерно соответствующая Oracle у DBA). Сделано это для того, чтобы не писать во всей статье оговорки.

Я думал, что моей статьи об {автоматизированном тестировании с самого нуля} и замечательного доклада Дмитрия Ручко «О мифах в тестировании» будет достаточно для того, чтобы люди с высшим образованием могли не наступать по сотне раз на одни и те же грабли. Но видимо нет. Не достаточно. Ладно, попробуем убедить уважаемую аудиторию цифрами. Может получится. А может и нет.

Рассмотрим две не большие и не маленькие, а средние компании с разной степенью эффективности. Годовой оборот пусть будет скромные 50 млн. долларов. Для простоты компании будет исключительно софтверные. Т.е. не занимающиеся интеграцией ПК с принтерами, не оказывающие услуги по записи интернет на дискету и т.д. Компании просто разрабатывают софт. На заказ или коробочный – не важно. Оборот небольшой и в ихней компании будет работать несколько десятков человек. Для определенности пусть будет сто. В нашей компании масштаб будет другой. У нас в компании с таким оборотом может работать до тысячи человек. [1]. У нас вообще любят масштаб. Ну, пусть будет 500.

Расходы собственно на разработку (аналитика, архитектура, кодирование, тестирование, документирование, …) составят по грубой оценке до 25 млн $ в ихней компании и 10 млн $ у нас [2]. Из них на тестирование уйдет процентов 20 и 10% у нас [3]. Итого пять миллионов долларов на тестирование у них и один у нас. На прогон тестов тратится порядка 30% бюджета отдела тестирования [4]. Полтора миллиона и триста тысяч соответственно. Из этого есть некое количество прогонов, которые в принципе экономически выгодно автоматизировать. Ну, пусть половина. Итого наше операционное поле это 0.75 миллиона и 150 тысяч. Такую чистую экономию мы получим, если прилетят добрые инопланетяне и в порядке гуманитарной помощи будут всегда все делать бесплатно. Заметьте, это максимум. Т.е. в принципе максимум. Так конечно не бывает. Пусть после внедрения мы получим снижение издержек на прогон тестов в три раза. Выигрыш – 500 000 и 100 000. Чтобы посчитать ROI нам еще понадобится посчитать единовременные затраты.

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

У них покупаются лицензии (пусть даже QTP за $10 000), люди отрываются на пару недель от работы (очень приличная цифра, до $20 000 потерь) и оплачиваются серьезные тренинги (еще 3 000). Ну, то есть, примерно $130 000 единовременных вложений. Очень неплохой результат для зрелой фирмы. Вложить 130 тысяч, для получения ежегодной экономии в один процент от пятидесятимиллионного оборота – это очень нехило. А при более-менее стандартной норме прибыли в 20% от оборота это означает увеличении прибыли на 5%. Когда же наступит этот благословенный миг? Я полагаю, что тогда, когда более эффективные практики повышения прибыли уже выбраны. Здесь удобно воспользоваться пузырьковой диаграммой (смотри http://www.pcweek.ru/themes/detail.php?ID=103400).

Пузырьковая диаграмма портфеля проектов

Вот где-то в секторе синих пузырьков и находится «Внедрение Автоматизированного Тестирования»

Если же дополнительно воспользоваться диаграммой зависимостей, то, как справедливо отмечают коллеги, сначала обязательно нужно «{Внедрить Тестирование}». Пока мы не пройден «тест Гринкевича», будем считать, что процесса тестирования у нас нет, и к автоматизации переходить бессмысленно. Кроме того, необходимо, чтобы к этому моменту был наведен порядок в проектировании интерфейса, структур данных и в аналитике. Иначе вместо сокращения расходов получим бесконечную переделку тестов и, как следствие, сужение тестового покрытия. Т.е. путь непрерывных улучшений будет долог. IMHO время для «Автоматизированного Тестирования» может наступить тогда, когда пятилетние юбилеи пребывания на своем посту простых инженеров давно стали обыденностью, да и десятилетние юбилеи никого особенно не удивляют.

Для наших фирм характерным сроком работы является 1.5-2 года. А уходя, инженер уносит с собой часть компетенции фирмы и процессы приходится ставить с нуля. Получается, что до автоматизированного тестирования мы вообще никогда не доберемся? Нет, что вы, у наших самураев свой путь пожирания кактусов. Закончим расчет. Напомню, нам нужно укомплектовать 20 рабочих мест и обучить 20 специалистов. Для «сокращения стоимости лицензий» нормальный пацан пойдет на горбушку и купит TestComplete или RR за десять баксов. Это позволит очень сильно сэкономить деньги на внедрении. Чтобы еще немного сэкономить, предоставим возможность тестировщикам самим разобраться с инструментарием. Книги естественно покупать тоже не будем. Таким образом, мы получим всего-навсего отрыв от производства на три месяца, и убытки компании в $15 000 [5] на человека или $300 000 на всех. В общем, то не так и много. Вложить 300 и получать ежегодную прибыль в 100 тысяч может и не такая плохая перспектива. Я даже не буду учитывать необходимость увеличения зарплаты автоматизаторам для уменьшения текучки [6]. Но если учесть риски, то вкладываться в такой проект я бы не стал.

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

Пусть есть маленький проект. Всего на нем 2 000 тестовых сценариев. Для достижения приемлемого уровня контроля качества с заданным доверительным интервалом (90% уровень бездефектности при доверительном интервале одна сигма [7]) необходимо выполнить 12 000 тестовых прогонов. Пусть есть 200 тестов, требующих более 15 прогонов с общей суммой прогонов 6 000. Их и решено автоматизировать. После автоматизации появляется желание запускать их часто. Пусть даже каждый день. В результате вместо 6 000 прогонов получаем 60 000. Это, в принципе неплохо. Это даже может улучшить доверительный интервал до одной целой и одной десятой сигма. Но только если при этом не произойдет уменьшения числа ручных прогонов. Если в результате бесконечной переделки автоматизированных тестов произойдет уменьшение тестовых прогонов, выполняемых вручную «всего» на тысячу, то у нас резко падает уровень бездефектности. Хотя формально будет выполнено больше прогонов (60 000 + 5 000 = 65 000 вместо 6000+6000=12000).

- Мы гоняем наши десять тестов на пятнадцати тысячах конфигураций.

- Круто. А зачем?

- Так можно же.

- Можно. Но незачем выдавать количество прогонов за качество тестирования?

К сожалению, проверить качество покрытия не удосуживаются. И проверяет его уже клиент.

Можно, правда, придумать неплохой вариант отдачи от внедрения автоматизации даже в условиях абсолютного хаоса в разработке. Бывает так, что сертификаты ISO и CMMI иногда приносят прибыль сами по себе, вне зависимости внедрялись они или нет. Достаточно, да, честно говоря, и лучше, если о внедрении ISO, CMMI сотрудники узнают случайно, обнаружив на стене приемной соответствующий сертификат. А что? И клиентам нравится, и сотрудники не пострадали.

Так что, если, вы получили контракт на распил стабфонда написание россейской операционной системы для МК-152 [8]. И вам срочно надо обеспечить хороший откат себе любимому увеличить эффективность работы команды. То вы находите продавца гербалайфа вендора средств автоматизированного тестирования и говорите ему: «А давай мы с тобой немного денег попилим полюбовно интенсифицируем ускорение развития прогресса улучшения эффективности труда!». И все, вы нашли друг друга! В конце концов, и вашим и его детям кушать надо. А фирма переживет, денег в стабфонде хватит.

Заключение.

Я не считаю, что автоматизированное тестирование полностью неэффективно. Но я против создания и возвеличивания «Священной коровы». Основные мысли этой статьи таковы:

* Существует множество способов повышения эффективности разработки ПО. Для их поиска можно пользоваться диаграммами Исикавы и Парето, методом пяти Why? и т.д и т.п.

* Выбирать порядок улучшений следует, в том числе и на основе расчетов экономической целесообразности. Фразы типа «автоматические тесты выполняются автоматически» или «компьютер считает в миллион раз быстрее, чем бухгалтер на счетах, и купив ПК мы увеличим производительность бухгалтера в миллион раз» за отмазку не канают. Только конкретный расчет для конкретной ситуации. В деньгах. И расчет необходимого тестового покрытия.

* Автоматизация тестирования – это проект с небольшим ROI и дает малый выигрыш в процентном отношении от бюджета организации.

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

* И наконец. Если у вас есть проблема с качеством ПО и вы приходите консультанту, а он предлагает вам внедрить «Священную корову», то нужно стукнуть этого консультанта чем-нибудь тяжелым и начинать искать другого.

----------------------------

[1] Я действительно не понимаю, почему голландская компания CityGIS, выпускает обалденный софт, имея в штате всего два с половиной десятка человек. У нас понадобилось бы минимум на порядок увеличить число сотрудников.

[2] Необходимость выкидывать деньги на сауны, откаты, шикарные кабинеты, банкеты, презентации и т.д. вместо покупки нормальных рабочих станций и серверов меня всегда смущала, но … «Это наша Родина, сынок». Смотри «Жизнь в пузыре» Ашманова.

[3] Цифры условны. Очень зависит от типа проектов. Давайте предположим, что существуют проекты, для которых это так. А разница в два раза между расходами на тестирование там и здесь возникла из простого понимания, что, почему то там качеству уделяют большее внимание. Да, и у нас есть очень неплохие продукты. Да, и у них есть отвратительные. Но, в целом, сальдо не в нашу пользу.

[4] Считается, что при ручном тестировании только треть времени тратится на прогон. Остальное уходит на разработку стратегии, плана и тестовых сценариев, фиксацию ошибок в бактрекере, верификацию ошибок, анализ результатов, … Если это сильно не так, то стоит задуматься о делах в консерватории.

[5] К убыткам компании я отношу недополученную прибыль. Сколько денег принес бы этот инженер, если бы работал, а не занимался ерундой? Один из вариантов расчетов – это умножение зарплаты на 4-5. Приведенная цифра потерь еще занижена. Реально фирма может терять от простоя специалиста тестировщика до 500 долларов за один рабочий день (Москва 2007).

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

[7] Так действительно можно считать. Но это трудоемко. Соответственно, так обычно не делают, особенно на мелких проектах. Ну, не осмечивать же строительство скворечника. Хотя если поставить производство скворечников на поток…

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

[8] Это конечно шутка. Хотя после появления нашего программируемого калькулятора, отставшего от зарубежных аналогов всего на 23 года и стоящего «всего» 250$, я уже ничему не удивлюсь.

Январь 28, 2008

36. Почему бизнес не любит IT

- Вы заплатили газетчикам, чтобы они вас расхваливали?

- Мадам?

- Извините, но знаете в газетах сейчас ничего, кроме рекламы.

© "Кухарка из Клэкхэма" Агата Кристи

А за что бизнесу нас любить? За последние десять лет мы ухитрились очень основательно изгадить себе репутацию. Естественно IT после этого любить не будут.

Для бизнеса IT - это расходы на инфраструктуру. Такие же, как на электричество или на канализацию в офисе. Проблема только в том, что почему-то в электрической сети стабильная частота 50 герц и напряжение 200-240. А IT-шники вместо того, чтобы просто давать 220 начинают рассуждать что ветряные электростанции - это круто, а ТЭЦ - прошлый век и несут прочую муть. А в сеть дают то 18 вольт, то полторы тысячи. При неконтролируемой частоте и плывущей фазе.

Я семь лет подряд убеждаю программистов, что нужно просто решать проблемы бизнеса (ну, например, сделать форкфлоу договоров), а они вместо этого рассказывают мне, что C# / SOA / флеш / верстка страницы в блокноте … (нужное подчеркнуть) - это круто.

Один из классических споров "настА-ящего крУ-Утого пацАна" с человеком, который решает проблемы бизнеса: http://www.sql.ru/forum/actualthread.aspx?bid=10&tid=71657&pg=1

И в этом мы не похожи на представителей остальных инфраструктурных технологий. Сантехник плохо ли, хорошо ли, но чинит кран, а айтишник:

Вместо решения конкретных проблем бизнеса занимается исследованием абстрактных технологий.

Кроме того, мы взяли себе за правило:

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

Примеры? Пожалуйста. Совсем недавно я воспользовался аж двумя видами услуг «высоких технологий». Как ни странно, иногда я тоже выступаю в роли потребителя [;-)].

Первый был оператор сотовой связи. При заключении контракта, меня подписали на спам за деньги. Да, да вы не ослышались. За деньги. Т.е. мне постоянно сыпался спам на сотовый, а чтение «послания» полностью приводило к исчезновению средств с лицевого счета. Услуга называлась «Хамелеон». К чести оператора, надо сказать, что отключили эту дрянь в пять минут после звонка. «Ложечки то нашлись, но осадок остался».

Вторым был «Стрим». С этим я мучаюсь до сих пор. Ход событий:

* Заказал подключение, безлимитный интернет и бронзовый ТВ. Аппаратуру беру в аренду.

* Ни ответа, ни привета. Десять дней. Ни письма, ни звонка, ничего.

* Наконец подключили, но аппаратуру для ТВ не принесли.

* Попытка отключить услугу, которой я не могу пользоваться, через сайт (по поводу интерфейса сайта можно написать отдельную статью) успеха не имела. Может я делаю что-то не так, может я недостаточно разумен, но найти этой функциональности я так и не смог.

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

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

Единственное что утешает, что здесь мы не одиноки. Не только IT поставляют продукты и услуги с качеством заведомо хуже декларируемого.

-------------

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

Март 20, 2008 в 18:19

Комментариев: 2

1. alex_goldreyer написал: 21 Март 2008

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

2. alex написал: 1 Июнь 2008 в 08:53

осторожно замечу, что возможностей для действительного творчества мало, поскольку ИНСТРУМЕНТ и СРЕДА РАЗРАБОТКИ чужие - всегда будешь кому-то обязан: Микрософту, Линуксу или т.д. Лучшие делают приложение и продают авторам исходников. Но сама возможность стучать по клавишам манит больше, чем махать лопатой или точить железо на станке. Действительная потребность в программистах, умеющих РЕШИТЬ конкретную задачу велика, но в силу вышесказанного РЕШЕНИЕ принадлежит в пропорции ЗАКАЗЧИКУ (он платил) и автору исходников (через лицензирование использования). Причем программисту практически не принадлежат права на интеллектуальную собственность. Они признаются только компанией - автором исходников в момент покупки-выкупа нового приложения и автоматически аннулируются.

37. Перспективы аутсорсинга тестирования

Старый мой пост на форуме. А посмотришь вокруг - вроде ничего и не изменилось. Хотя прошло три с половиной года.

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

Часть 1

Директор Вася вдруг понимает, что вроде софт тестить надо, а то у него есть 10 - 50 программистов. Но что они делают никто не знает. Нанимает он тестера Петю. И спрашивает его: "Ну что, Петя, свой отдел будем делать или аутсорсеров поищем?" И понимает Петя что от его ответа во многом зависит его судьба. Или быть ему начальником отдела или просто координатором процесса тестирования.

Учитывая, что в нашей стране зарплата в основном зависит от числа подчиненных, ответ Пети предугадать несложно.

Часть 2

Сообразил Вася, что Петя ему не советчик. И вызвал Колю, менеджера одного из проектов.

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

Приехал Коля к аутсорсерам.

К. Вод код привез. Тестите.

А. Бизнес вижен есть?

К. Нет.

А. BRS есть?

К. Нет.

А. SRS есть?

К. Нет.

А. Прототипы интерфейса есть?

К. Нет.

А. Схема БД есть?

К. Нет. Код есть.

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

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

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

Часть 3

Понял Вася, что и Коля ему не советчик. И поехал сам к аутсорсером.

- А знаем, знаем. У вас процесс поставлен плохо. Оттестить мы вам оттестим, но вам еще аналитику сделать надо. Это мы тоже сделаем. А еще вам разработку дизайна надо сделать. Это мы тоже сделаем. А еще вам Архитектуру БД надо поправить. Это мы тоже сделаем. А еще -

Задумался Вася. Если делать по-хорошему, то надо чуть не всю разработку отдавать аутсорсерам.

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

© 1.10.2004 SALar aka Сергей Мартыненко

Март 14, 2008

Комментариев: 2

1. Yuri написал: 16 Март 2008

Грустная картинка обрисована.

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

К тому-же есть проблемы:

- согласования рабочих процессов. Аутсорсер в примере выше попросил BRS/SRS/- Далеко не всегда оно надо, и те процессы которые ты создал подразумевают написание этих доков. Может получиться поднимаем качество на 5%, и поднимаем расходы на 30%.

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

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

2. SALar написал: 19 Март 2008 в 20:22

Статья не о преимуществах аутсорсинга (недостатков у него куча), а о том, как он воспринимается участниками. Т.е.: "Почему от аутсорсинга / консалтинга / обучения откажутся, даже будь оно трижды выгодно."

38. Пример требований к системе. Часть 1

Только действительно сильный шахматист знает, насколько слабо он играет.

© Савелий Григорьевич Тартаковер

Апдейт от 2023. Несмотря на признание коллег, я знаю, что это очень плохие требования. Сейчас мои ученики пишут лучше, чем я тогда.

В связи с огромным количеством вопросов: «А где можно найти образец написания требований к системе?» - и стандартным ответом: «В рунете - маловероятно», - выкладываю вариант описания требований к системе.

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

Документация «рабочая», т.е. перед выкладкой не прилизывалась. Часть информации не заполнена. Сделано это умышленно, чтобы показать работу с документом. Набор частей также не полон.

Дисклаймер. Авторские права да данный материал полностью принадлежат мне. При публикации не пострадали интересы ни одной фирмы.

================================================

1 Введение

1.1 Цель

Цель документа «Спецификации требований к программному обеспечению» - определение требований к продукту и согласование их с заказчиком.

Документ является основанием для заключения контракта с заказчиком.

1.2 Область действия документа

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

1.3 Определения

Прецеденты (юзкейсы) – варианты использования ПО пользователями.

1.4 Аббревиатуры

CRUD (Create, Read, Update, Delete) – группа стандартных прецедентов (юзкейсов) объекта, касающиеся создания, просмотра, редактирования и удаления.

ОДЛ – Основное действующее лицо

2 Общее описание

2.1 Предназначение и перспективы продукта

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

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

Для успеха продукта необходимо обеспечить:

Легкость ввода первичной информации Достаточность отчетов 2.2 Роли

1. Администратор – осуществляет настройку и контроль над системой.

2. Медпредставитель – вводит исходную информацию, отслеживает информацию и получает сводные отчеты по своим партнерам.

3. Аналитик – получает сводные отчеты в целом по фирме

При дальнейшей доработке системы может быть введена роль регионального менеджера

4. Менеджер – может вводить исходную информацию, получает отчеты по всем партнерам, получает сводные отчеты по медпредставителям.

Для текущей версии системы реализация данной роли является низкоприоритетным.

2.3 Обзор модели вариантов использования

Будет доработано позднее.

2.3.1 Введение

Функции системы объединяются в следующие группы:

Работа с партнерами Управление партнерами и медпредставителями Отчеты Администрирование Работа со справочниками 2.3.2 Обзор описания

Будет доработано позднее.

2.3.3 Иерархия модели вариантов использования

Будет доработано позднее.

2.3.4 Диаграмма модели вариантов использования

Будет доработано позднее.

2.4 Допущения и зависимости

В настоящий момент отсутствуют.

Апрель 10, 2008

39. Пример требований к системе. Часть 2

3 Спецификация вариантов использования

3.1 Общие сценарии

3.1.1 Удаление любого объекта, (если не сказано обратного)

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

3.1.1.1 Краткое описание

Уровень: цель пользователя

Основное действующее лицо: медпредставитель

3.1.1.2 Основной сценарий

1. ОДЛ отдает команду на удаление объекта

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

3. Система удаляет объект и все дочерние объекты

3.1.1.3 Альтернативный сценарий 2а

1. Данный объект был отослан

2. Система помечает объект как удаленный

3. Система устанавливает признаки объекта "изменен" и "время изменения"

3.1.2 Редактирование любого объекта

3.1.2.1 Краткое описание

Уровень: цель пользователя

Основное действующее лицо: медпредставитель

3.1.2.2 Предусловие: ОДЛ просматривает объект

3.1.2.3 Основной сценарий

1. ОДЛ изменяет значения атрибутов объекта

2. Система отображает сделанные изменения

3. ОДЛ отдает команду на сохранение

4. Система сохраняет сделанные изменения

5. Система устанавливает признаки объекта "изменен" и "время изменения" в БД

3.1.3 Восстановление объекта, помеченного как удаленный

3.1.3.1 Краткое описание

Уровень: цель пользователя

Основное действующее лицо: медпредставитель

Контекст: ОДЛ просматривает список соответствующих объектов

3.1.3.2 Основной сценарий

1. ОДЛ устанавливает фильтр в значение "показать удаленные объекты"

2. Система отображает полный список объектов

3. ОДЛ дает команду на восстановление объекта

4. Система устанавливает для объекта признак "активен" и устанавливает дату изменения.

3.2 Партнеры

3.2.1 Просмотр списка партнеров

3.2.1.1 Краткое описание

Уровень: цель пользователя

Основное действующее лицо: медпредставитель

3.2.1.2 Основной сценарий

1. ОДЛ отдает команду на просмотр списка партнеров

2. Система отображает список партнеров, упорядоченный по имени.

3.2.1.3 Расширение

1. ОДЛ ищет партнера, набирая первые буквы.

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

3. Система позиционирует фокус на первом партнере, имя которого начинается с введенной комбинации.

3.2.2 CRUD Партнера

ОДЛ – медпредставитель

3.3 Группа "Связанные объекты партнера"

Сценарии похожи для объектов:

Обязательство ПМИ Визит Презентация Семинар Спонсорство Вопросник ОДЛ - медпредставитель

3.3.1 Просмотр списка обязательств по партнеру

3.3.1.1 Расширение

Просмотр удаленных

3.3.2 CRUD обязательств по партнеру

3.3.3 Простановка отметки о выполнении обязательства

3.3.3.1 Краткое описание

Уровень: цель пользователя

Основное действующее лицо: медпредставитель

Контекст: ОДЛ просматривает список обязательств

3.3.3.2 Основной сценарий

1. ОДЛ отдает команду на ввод даты выполнения для определенного обязательства

2. Система предоставляет форму ввода

3. ОДЛ вводит дату

4. ОДЛ отдает команду на сохранение

5. Система сохраняет сделанные изменения

3.3.4 Снятие отметки о выполнении обязательства

3.3.4.1 Краткое описание

Уровень: цель пользователя

Основное действующее лицо: медпредставитель

Контекст: ОДЛ просматривает список обязательств

3.3.4.2 Основной сценарий

1. ОДЛ отдает команду на снятие отметки о выполнении

2. Система подтверждает выполнение операции

3.3.5 Просмотр списка ПМИ

3.3.6 CRUD

3.3.7 Просмотр списка визитов

3.3.8 CRUD визитов

3.3.9 CRUD объектов визита

3.3.10 Просмотр списка спонсорства

3.3.11 CRUD

3.3.12 Просмотр списка вопросников

3.3.12.1 Расширение

Печать вопросника

3.3.13 CRUD вопросника

3.3.14 Создание вопросника

3.3.14.1 Краткое описание

Уровень: цель пользователя

Основное действующее лицо: медпредставитель

Контекст: ОДЛ просматривает список вопросников

3.3.14.2 Основной сценарий

1. ОДЛ отдает команду на создание вопросника

2. Система отображает список шаблонов

3. ОДЛ выбирает шаблон

4. Система создает экземпляр вопросника

5. ОДЛ заполняет вопросник

6. ОДЛ отдает команду на сохранение

7. Система подтверждает выполнение

3.3.14.3 Расширение " Печать вопросника"

3.4 Семинары

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

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

Презентация проводится для неопределенной аудитории. Сопровождается раздачей образцов.

3.4.1 Просмотр списка семинаров

3.4.1.1 Краткое описание

Уровень: цель пользователя

Основное действующее лицо: медпредставитель

Контекст:

3.4.1.2 Основной сценарий

3.4.2 CRUD

Примечание по реализации. Эта группа прецедентов касается основной информации о семинаре:

• Дата

• Время

• Тема (если тем несколько, то основная, дополнительные в отдельном прецеденте)

Работа с прочими атрибутами описывается в других прецедентах.

3.4.3 Редактирование списка партнеров на семинаре

3.4.3.1 Краткое описание

Уровень: цель пользователя

Основное действующее лицо: медпредставитель

Контекст: ОДЛ просматривает список партнеров, присутствующих на семинаре

3.4.3.2 Основной сценарий

1. ОДЛ отдает одну из команд: добавить, удалить партнера из списка, присутствующих на семинаре

2. Система подтверждает выполнение действия

3. ОДЛ отдает команду сохранить список партнеров, присутствующих на семинаре

4. Система подтверждает выполнение операции

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

3.4.4 Учет розданных материалов

* Материалы

* Образцы

* Сувениры

3.5 Отчеты по медпредставителю

3.5.1 Календарный Отчет

Примечание по реализации. Может быть перенесено в группу "Ежедневник"

ОДЛ – медпредставитель

3.6 Ежедневник (еженедельник)

Приоритет этой группы низкий. Может быть специфицировано позднее.

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

3.6.1 Просмотр списка задач

3.6.1.1 Расширения

ПечатьНавигация3.7 Синхронизация с центральной БД

3.7.1 Пользовательский сценарий

3.7.1.1 Краткое описание

Уровень: цель пользователя

Основное действующее лицо: медпредставитель

3.7.1.2 Предусловие: Установлен канал связи

3.7.1.3 Основной сценарий

1. ОДЛ отдает команду на синхронизацию с центральной БД

2. Система подтверждает установления связи с центральным сервером

Система отображает ход операции

3. Запускается сценарий "Передача изменений в партнерах и связанных объектах"

4. Запускается сценарий "Синхронизация списка партнеров"

5. Запускается сценарий "Синхронизация справочников"

6. Система подтверждает успешное завершение операции

3.7.1.4 Альтернативный сценарий

3.7.2 Передача изменений в партнерах и связанных объектах

Устанавливается признак "отослан"

3.7.3 Синхронизация списка партнеров

3.7.4 Синхронизация справочников

Устанавливается признак "отослан"

3.8 Администрирование

3.8.1 CRUD пользователя системы

3.8.2 Настройка прав доступа пользователя системы

Приоритет низкий.

В первой версии системы:

Всегда существует только один администраторОн же обладает правами аналитикаОтдельные пользователи "аналитики" не предусматриваютсяВсе добавленные пользователи системы автоматически получают роль медпредставителя3.8.3 Просмотр партнеров и медпредставителей

3.8.4 Открепление партнера

3.8.4.1 Краткое описание

Уровень: цель пользователя

Основное действующее лицо: администратор

Контекст: Просмотр партнеров и медпредставителей

3.8.4.2 Основной сценарий

3.8.5 Прикрепление партнера

3.8.5.1 Краткое описание

Уровень: цель пользователя

Основное действующее лицо: администратор

Контекст: Просмотр партнеров и медпредставителей

3.8.5.2 Основной сценарий

3.8.6 Передача партнера

3.8.6.1 Краткое описание

Уровень: цель пользователя

Основное действующее лицо: администратор

Контекст: Просмотр партнеров и медпредставителей

3.8.6.2 Основной сценарий

1. ОДЛ отдает команду о передаче партнера от одного медпредставителя другому

2. Запускается прецедент "Открепление партнера"

3. Запускается прецедент "Прикрепление партнера"

3.8.7 Создание базы данных медпредставителя

Примечание. Это решает проблему разрушения локальной БД. Остается открытым вопрос передачи этой базы на место. Может быть решено в следующем сценарии:

3.8.7.1 Краткое описание

Уровень: обобщенный

ОДЛ: администратор

ДЛ: мепредставитель

Цель: создание нового представителя или восстановление разрушенной локальной БД

3.8.7.2 Предусловие

Медпредставитель есть в системе

3.8.7.3 Основной сценарий

1. ОДЛ отдает команду на создание локальной БД медпредставителя

2. Система уничтожает текущую локальную БД представителя на сервере ОДЛ

3. Система создает БД представителя на сервере ОДЛ

4. Система устанавливает признак "отправлен" для медпредставителя

5. Система создает бэкап БД

6. ОДЛ отправляет бэкап БД ДЛ (вне рамок системы)

7. ДЛ сохраняет на своем ПК бэкап БД (вне рамок системы)

8. ДЛ запускает приложение

9. ДЛ отдает команду на импорт БД

10. Система уничтожает текущую локальную БД представителя на ПК ДЛ

11. Система создает БД представителя на ПК ДЛ

3.9 Настройка

3.9.1 Просмотр шаблонов вопросников

3.9.2 CRUD шаблона вопросника

3.9.3 Создание тела шаблона вопросника

3.9.3.1 Краткое описание

Уровень: цель пользователя

Основное действующее лицо: администратор

3.9.3.2 Основной сценарий

1. ОДЛ вводит новый вопрос, удаляет или редактирует вопрос

2. ОДЛ указывает тип ответа: "Выбор из списка ответов"; "Текст"; "диапазон"

3. ОДЛ вводит/редактирует/удаляет ответы

4. ОДЛ отдает команду на сохранение изменений

5. Система сохраняет шаблон

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

3.9.4 Просмотр списка справочников

Примечания.

Сценарии для всех справочников похожи и будут специфицированы в общем виде. Список справочников может быть изменен только программно. 3.9.5 Просмотр справочника

3.9.6 CRUD справочника

3.10 Аналитика

3.10.1 Получение отчета в разрезе (простейшие фильтры)

3.11 Склад

Приоритет низкий.

Данная группа сценарием может быть специфицирована позднее

Апрель 10, 2008

40. Пример требований к системе. Часть 3

4 Требования

4.1 Функциональные требования

4.1.1 Система должна предоставлять аналог планирования

Достаточным будет ежедневник. Оповещение о задачах не требуется.

4.1.2 Система должна функционировать вне рамок локальной сети.

4.1.3 Поддержка различных режимов работы

Система должна поддерживать следующие режимы работы:

* В офисе без интернета

* Режим синхронизации с сервером

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

4.1.4 Восстановление локальной базы представителя

Система должна позволять создать заново БД медпредставителя.

4.1.5 Изменение объектов

Система должна хранить последнее состояние объектов. История изменений не ведется.

4.1.6 Целостность данных

Для подержания целостности данных система:

не должна позволять удалять отосланный объект.С одним объектом работает только один человек. См. "конкурентная работа"4.1.7 Конкурентная работа

Отсутствует. Система должна предоставлять возможность редактирования объекта только в одном месте.

4.2 Требования к пользовательскому интерфейсу

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

4.2.1 Соответствие стандартам и общепринятой практике

Пользовательский интерфейс разрабатываемой системы должен базироваться на рекомендациях Микрософт и в целом соответствовать интерфейсам современных программных средств, разрабатываемых для платформы Windows.

4.2.2 Необходимое время обучения

Будет специфицировано позднее.

Нормальный пользователь (плохо знакомый с ПК) Продвинутый пользователь 4.2.3 Время выполнения операций

Будет специфицировано позднее.

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

4.3 Безопасность и разграничение прав доступа

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

4.4 Надежность

Специфических требований к надежности не предъявляется

4.5 Быстродействие

4.5.1 Характерное время отклика системы при выполнении типовых операций

Будет специфицировано позднее.

* Время отклика при вводе первичной информации должно быть не более …

4.5.2 Число транзакций в секунду

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

4.5.3 Число одновременно работающих пользователей

4.5.4 Деградация системы

Жесткие требования к деградации клиентской части не предъявляется. Достаточно, если производительность системы не будет падать при восьмичасовой непрерывной работе с ней.

Для серверной части (если таковая будет) – одна неделя.

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

4.5.5 Масштабируемость

Предполагается до 50 представителей, делающих по 5-6 визитов в день, данные должны храниться до 5 лет. Таким образом, предполагается не более 1000 тыс. записей в БД.

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

4.6 Поддерживаемость

В настоящий момент не выявлены.

4.7 Проектные ограничения

Отсутствуют

4.8 Требования к пользовательской документации и системе помощи

Может быть сделано заказчиком.

В состав разрабатываемой программной документации войдет:

Краткое руководство пользователя 4.9 Компоненты внешних поставщиков

Не выявлены

4.10 Интерфейсы

4.10.1 Пользовательские интерфейсы

4.10.2 Аппаратные интерфейсы

Интерфейсы с нестандартными аппаратными частями отсутствуют. Все интерфейсы реализуются стандартными средствами ОС

4.10.3 Программные интерфейсы

Требуется уточнение.

4.10.4 Коммуникационные интерфейсы

Требуется уточнение.

4.11 Требования к лицензированию

Нет

4.12 Законы, авторские права и другие нормативные акты

Нет

4.13 Применяемые стандарты

Нет

Апрель 10, 2008

41. Пример требований к системе. Часть 4

Объекты системы

Диаграмма объектов (сущностей)

TBD (будет специфицирована позже)

Список:

Пользователи системы Партнеры Визиты Презентации Обязятельства Визиты, презентации, обязательства вводятся медпредставителем, принадлежат партнеру.

Диаграммы будут специфицированы позднее.

Основные объекты системы

Партнеры

TBD

Визит

К каждому визиту может быть привязано произвольное число спецификаций (дочерних объектов).

Виды спецификаций

Вложенная спецификация:

* Наименование образца/материала/сувенира – из соответствующего списка;

* Переданное количество.

Сохраняет имя представителя, осуществившего визит. Необходимо для истории визитов (при передаче партнера другому медпредставителю).

Обязательство

Спонсорство

Постмаркетинговое исследование

Вопросник

Поля шапки:

Поля спецификации:

Презентация

TBD

Апрель 10, 2008

42. Пример требований к системе. Часть 5

6 Замечания по архитектуре

6.1 Передача партнера

Операция "передача партнера от одного медпредставителя другому" должна совершаться в одном месте - в центре. Проведенные изменения должны быть переданы двум медпредставителям.

Предлагаю создать отдельный объект для хранения связи "медпредставитель-партнер", имеющий атрибуты "активен/неактивен" и время изменения.

6.2 Синхронизация данных

Три различных варианта

6.2.1 Использование канала вне рамок системы

Организуется обмен файлами. В качестве канала передачи можно использовать:

* Закачку по FTP

* Пересылка по email

* Физическая пересылка носителя

Преимущества:

Независимость от канала связиГарантированная передача больших объемов при плохом каналеНедостатки:

Высокие накладные расходы при эксплуатации системы6.2.2 Встроенный механизм репликации MSSQL

Преимущества:

Стандартный метод MSSQLНе требуется разработка процедур обмена в рамках программы.

Недостатки:

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

6.2.3 Обмен данными посредством вебсервисов

Последовательность

Преимущества:

Гибкость. В дальнейшем можно независимо менять элементы, схемы бах данных и, даже, платформы отдельных элементов системы, при сохранении схем обмена данными. Так же возможно подключение средств гарантированной доставки сообщений (MSSQL).Недостатки:

Несколько большее время разработки (компенсируется легкостью администрирования и эксплуатации).

6.2.4 Рекомендации

Рекомендую использовать собственный механизм обмена, основанный на передаче XML данных посредством вебсервисов. Этот подход хорошо зарекомендовал себя и, в настоящий момент, рекомендуется ведущими разработчиками ПО.

6.3 Состав локальной БД.

База партнеров должна быть общей для всех представителей в связи с тем, что:

Представитель должен иметь полный доступ к истории своей деятельностиСписок партнеров, присутствующих на семинаре, может включать не только "своих" партнеровЭто усложнит синхронизацию БД.

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

Т.к. база данных распределенная, то не рекомендуется использовать автоинкремент. Рекомендуется GUID.

Апрель 10, 2008

PS. Из 2023-го. Тогда еще было плоховато с интернетом.

43. Памятка докладчикам

Небольшая памятка мне любимому, и остальным, кто собирается делать небольшой доклад.

* У выступления должна быть цель. Если ее не знает автор - скорее всего, она останется неизвестной и слушателям. Очень полезно выписывать цель перед началом работы над докладом, но так бывает редко. Достаточно, если цель будет формализована после окончания подготовки.

* Не удаляйтесь от основной темы.

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

* Позвольте слушателям увидеть перечень вопросов, которые будут рассмотрены.

* Сделайте связный рассказ.

Акцентируйте внимание на начале каждого кусочка. "А теперь мы рассмотрим -". "Мы рассмотрели применение паттернов группы "А" и теперь переходим к -"

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

* Расскажите о границах применимости. Это обычно самое интересное. Когда не стоит применять технику "А", в каком классе проектов применение инструмента "В" приведет к краху проекта, почему никогда не стоит применять CMMI в проектах класса "С" и т.д.

* Слайды - это не костыли.

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

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

первом - тема доклада и автор

втором - план доклада

последнем - благодарность слушателям и контактные данные докладчика

Остальные слайды должны занимать рисунки, диаграммы, таблицы, графики. График/ диаграмма наглядней таблицы, ассоциативный рисунок полезней диаграммы.

* Сделайте привязку ко времени и поставьте произношение.

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

* Один большой совет. Прочитайте книгу Джина Желязны «Бизнес-презентация: Руководство по подготовке и проведению». Эта книга направлена на ликвидацию безграмотности в области презентаций. Презентация это не доклад и, тем более, не тренинг, но существенная часть правил для их подготовки совпадает. Пары дней для прочтения этой книги вполне достаточно.

Удачи.

PS. Есть еще много секретов успешного выступления:

* прогреть голос перед выходом на сцену

* собрать слушателей поплотнее

* подготовить минимум два варианта доклада, один в расчете на положительно настроенную аудиторию, второй на скептическую.

* концентрировать внимание на себе двигаясь по сцене, жестикулируя и управляя голосом и не рассеивая внимание на проекторе.

Но это будет уже чересчур. Все-таки не каждый из нас собирается стать профессиональным докладчиком.

PSS. Подготовка небольшого доклада резко отличается от полновесного курса.

Апрель 21, 2008

44. Прыгать надо

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

Но речь собственно не об этом. Один из комментаторов вполне справедливо заметил: "Чего бурчать, работать надо!" Согласен, действительно нужно что-то делать. В сентябре того же 2007 года (через неделю после публикации статьи) мы провели конференцию то тестированию. Просто собрались несколько человек, которым "больше всех надо" и провели. В конце мая этого года мы провели третью конференцию по тестированию (http://www.sqadays.ru/).

Через три недели проводим еще одну тематическую конференцию {Training Labs 2008}. Конференция, или ярмарка, или дегустация, называйте как хотите, посвящена вопросу, который неоднократно поднимался - состояние рынка профильных тренингов по разработке ПО [1]. Мероприятие уникально для постсоветского пространства и может быть несвоевременно. Как показало тщательное прочесывание рынка маловато у нас практикующих тренеров по SEP. Очень мало. По инструментам - навалом, по разработке - почти нет.

Но, ведь если ничего не делать, то ничего и не изменится? Я очень надеюсь, что эта наша работа будет востребована. А если удастся раскачать рынок - то будет совсем хорошо.

-----------------------

[1] Подразумеваются все виды деятельности, такие как: анализ, проектирование, документирование, тестирование, кодирование, …

Июнь 6, 2008

Четвертый вид лжи

* Тот, кто звонит вам в надежде что –то вам продать – мошенник.

* Тот, кто останавливает вас на улице в надежде что-то вам продать - мошеник.

* Тот, кто пытается войти к вам в дом в надежде что-то вам продать – мошенник.

* Тот, кто сообщает вам, что вы выиграли в лотерее, в которую не играли – мошенник.

* Тот, кто предлагает товары и услуги “бесплатно” – мошенник.

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

* Тот, кто обещает 100% выздоровление от всех болезней – мошенник.

* Тот, кто рассылает по электронной почте письма с рецептами быстрого и легкого обогащения – мошенник.

(c) Неизвестный Автор

Как известно, есть ложь, есть наглая ложь и есть статистика. Но есть еще четвертый вид. Это реклама. Хотя нет. Реклама это уже за рамками добра и зла. Реклама - это то, что в среднем никак не соотносится с действительностью. Почему в среднем? Потому что есть разные рекламщики.

Молчуны. С этими все просто. Пытаются говорить правду. А неудобную правду замалчивают. «Правду, но не всю правду».

- У нас самые дешевые машины!

- А как часто они ломаются?

Лгуны. Намедни просмотрел по диагонали рекламный проспект очередной средства автоматизации делающего людей счастливыми подобно героям романа «Мы». Мои комментарии:

* Ложь – четыре раза

* Наглая ложь – один раз

* Не верю – шесть раз

* Грубая ошибка в формулировке, по сути тоже ложь – один раз

Больше комментариев нет. Учитывая, что рекламный проспект – это целых восемь страниц, пусть и крупного текста – результат очень неплохой. Мне другое интересно. Неужели, если говорить правду, то число продаж резко упадет?

Софисты. Это самые искусные из всех видов рекламщиков. В совершенстве владеют женской логикой и логикой искаженного мира ((с) «Обмен разумами» Шекли). Типичные приемы: пропуск одной из посылок в суждении, выводы по аналогии, там, где аналогия неприменима, … Примеры:

- Хорошие товары делают людей счастливыми.

- Следовательно наши товары сделают вас счастливыми.

А где собственно посылка, что ваши товары хорошие?

Внедрения ERP системы SAP/R3 позволило многим фирмам лучше управлять складскими системами. Мы предлагаем новую ERP систему «Складолюкс».

И почему, собственно, она поможет лучше управлять складскими запасами?

Пургометы. Это просто говорят. Никак не согласуясь с тем, что есть на самом деле. Просто говорят «мы первые» / «Мы лучшие» и не слушают никого.

Мы велики! Мы свободны! Мы достойны восхищения! Достойны восхищения, как ни один народ в джунглях! Мы все так говорим - значит, это правда!

(с) Киплинг «Маугли»

Выводы? А их пока не будет. Кроме очень простого: «Никогда не принимайте решения, основываясь на рекламе». Если вы думаете, что это просто и «все» именно так и делаете, то вы не правы. «Все» так не делают.

Октябрь 3, 2008

Один комментарий

1. karkadil написал: 3 Октябрь 2008

Хм- Посмотрел "Автотрассу 60" что ли? [:)] Был там такой товарищ, который во всем ложь искал. И находил.

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

А вообще, всё это очень хорошо написано, за исключением двух больших НО:

1) Все виды разводов не перечислить, всегда появляются новые

2) Дураки попадались на разводы и будут попадаться, сколько ты их не учи. Поэтому если в твоем окружении есть идиоты, то проще им говорить иногда: "Не делай этого, это обман". Два-три раза попадутся и станут прислушиваться к вашим словам. А учить таких - дело неблагодарное и бессмысленное.

45. Разные степени готовности

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

Первая проблема заключается в том, что, хотя Вася (заказчик) и Петя (исполнитель) владеют несколькими понятийными полями каждый, эти поля могут не пересекаться. Тогда "ой". Консенсуса достигнуть практически невозможно.

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

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

Точно так же этот человек переводит фразу разработчика

"Там это захардкожено в пяти десятках мест", - в:

"Наша система не отвечает требованиям качества по такому показателю, как расширяемость и поэтому выполнение вашей пустяковой заявки потребует $15 000 при допустимом риске пропущенных ошибок, которые обойдутся нам еще в $40 000 на пострелизной поддержке. Итого, это изменение встанет нам в $55 000 плюс-минус $15 000".

Исторически сложилось, что понятийные метаполя заказчиков ПО и исполнителей программных проектом не пересекаются (ну почти). Для преодоления этой пропасти назначают "толмача", которого называют аналитиком. Или менеджером проекта, или продакт онером, где как. Но большинство гуру сходятся в том, что этот толмач должен свободно ориентироваться как в культурном контексте заказчика, так и исполнителя. Иначе его работа не будет имеет большого смысла.

И напоследок шуточный тест, на то, какими метаполями вы оперируете. Фраза: "Программа уже готова", - означает:

продавец очень хочет получить контракт бизнес аналитик считает, что сможет изучить предметную область за выходные системный аналитик считает две исписанные салфетки полноценной спецификацией на софт в 3 000 функциональных точек архитектор уже нарисовал пять таблиц в оракле и считает это готовой архитектурой кодировщик прочитал ТЗ код попал в репозиторий код скомпилировался код прошел юнит тесты код прошел отдел тестирования с отметкой "работает" конечный продукт понравился заказчику конечный продукт понравился конечному пользователю конечный продукт принес прибыль владельцу бизнеса (за два года увеличение прохода бизнеса превысило расходы на проект в 2-10 раз) конечный продукт позволил: сократить двух операторов из пятисот втюхать заказчику десяток серверов и апгрейд пятисот рабочих станций расширить IT отдел на семь человек PS. Официант должен свободно ориентироваться в понятийном поле клиента. И автоматически должен трансформировать фразу "Гребешков мне! И побольше." в то, что клиент хочет на самом деле, а не приносить на подносе несколько расчесок. Иначе он плохой официант. Ну, вы их регулярно видите. Хотя- кризис творит чудеса. *мечтательно закатываю глаза*

PPS. "У вещей есть понятия, не требующие объяснений по умолчанию." - Это утопия. Я хотел бы найти такой глобус. В этой стране мои совершенно недвусмысленые заказы исполнитель не понимает.

PS-III. Очень интересная статья о трудностях перевода: http://magazines.russ.ru/voplit/2009/2/eli12.html. Насколько же может измениться смысл из-за элементарной ошибки гендерной идентификации при переводе (Owl - мужчина, Сова - женщина).

Апрель 3, 2009

46. TrainingLabs с разных точек зрения

Взгляд посетителей

Проблема с информацией. Невинный вопрос на секции тестирования: «Кто был на SQADays?» выявил грустную картину. Там был один человек. Но еще хуже то, что сказала одна из участниц: «Я узнала об этом событии на следующий день после того, как конференция прошла». И что делать? Как донести до потребителей информацию, которую они жаждут получить? Кстати, тем, кто ищет идею для проекта: «В Росси нет нормального, не забитого рекламой канала информации о событиях».

Столько всего вкусного! Выбор первого тренинга многих поставил перед неразрешимой проблемой. Хотелось и туда, и туда, и туда.

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

Через некоторое время появятся интервью с конференции и можно будет ознакомиться с мнениями участников подробнее.

Взгляд тренера

Я выбрал в качестве темы «базовые методы создания тестовых сценариев». Никаких высоких теорий о преимуществах и недостатках классических или гибких подходов, или о регламентах работы. Вот такой вот примитив. Тема, которая мало обсуждается и, насколько мне известно, слабо освещена в литературе на русском языке. С другой стороны, это базовые знания тест-аналитика. Очень приятно, что поднятые на тренинге вопросы вызвали живой интерес.

Взгляд организатора

Как это ни грустно, но приходится признать, что сейчас в Москве проблема найти полноценный центр подготовки персонала по программной инженерии. Несмотря на внешне внушительный список в 50 учебных центров, при ближайшем рассмотрении выяснилось, что в массе своей они дают курсы по инструментам вендоров. Есть несколько УЦ, состоящих из объединившихся тренеров, которые дают интересные тренинги, но, как правило, они ограничены одной - двумя областями программной инженерии. Это могут быть модные сейчас методологии, тренинги по управлению проектами, … Но полного спектра нет. Текама предлагает достаточно много тренингов по различной тематике, но не так много готовит внутри. УЦ Люксофт разрабатывает тренинги и закрывает все или почти все области программной инженерии. Сейчас УЦ Люксофт – уникальное явление, и, думаю, в ближайшее время он станет лидером рынка не только по полноте охвата, но и по количеству отчитанных часов (если еще не стал). Никто не хочет составить конкуренцию?

[1] Напомню, о чем идет речь. Есть задание на расчетный модуль. По этому заданию написано несколько (6) алгоритмов. Один правильный, остальные с теми или иными ошибками. Требуется составить тестовый набор, проверяющий эти алгоритмы.

Июль 10, 2008

47. Юноше, обдумывающему IT-шное житье

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

При выборе отдыха вы должны руководствоваться следующими правилами:

1) Это должен быть не русский курорт

2) Вы не должны пользоваться услугами русских гидов и русских дайвинг центров

3) Выбирайте отель, где нет русских туристов

4) Не пользуйтесь услугами русских турфирм.

Надеюсь, эти простые советы помогут вам сэкономить нервы, время и много денег.

Первый вариант развития карьеры айтишника:

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

- Зачем вы уезжаете, ведь хорошо там, где нас нет?

- Вот я и еду туда, где вас нет.

Мой друг просто пересек государственную границу. Не изменилось почти ничего. Он продолжал работать в той же фирме. На того же заказчика. Только зарплата волшебным образом выросла примерно в три раза. Ах да, у него изменилось окружение. В первую очередь управленческое. Все-таки, российский менеджмент не самый сильный в мире. Оно и понятно. Мы живем в эпоху 22-летних менеджеров. В лучшем случае они что-то прочитали. PMBok, или RUP, или XP, или Agile [1]. И теперь носятся с этим, как с писанной торбой. А вот управленцев, которые не только понимают, что это разводняк, но и могут убедительно и с примерами показать это – таких единицы.

Второй вариант – уход из IT.

- Сынок, будешь плохо учиться – айтишником станешь!

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

поступить в столичный ВУЗ , столичный – практически обязательное требование. Устроиться айтишником, прокладчиком ЛВС, эникейщиком - работа примерно, как в макдональсе, как раз для студента. Малооплачиваемая, бесперспективная, но все ж таки дает денег больше, чем фастфуд. Окончить институт с отличием. Найти приличную работу. Кем? Да кем угодно. Есть же на свете множество приличных, уважаемых профессий: электрик, сантехник, уборщик производственных помещений. Шучу. Но в каждой шутке есть доля шутки. Остальное правда. Занимайтесь чем угодно. Лежит душа к горам – откройте скалодром по примеру скала-сити. Займитесь ланшафтным дизайном, торговлей пивом – чем угодно. Пока не иссякли нефтебаксы – все у вас будет хорошо.

Третий вариант.

Оптимисты учат английский, пессимисты - китайский

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

Итак, карьерный путь:

поступить на факультет, где изучают китайский; китайский – практически обязательное требование Учить китайский. Совершить несколько путешествий в Китай. Очень желательно вступить в брак … - вы меня поняли, хотя я и против браков по расчету устроиться в крупную, нашу IT компанию. Очень желательно попасть на должность, позволяющую общаться с иностранными специалистами. Окончить институт; получить подтвержденный стаж коммерческой разработки от двух лет. Параллельно получить (или купить – это пофиг, все равно никто не разберется какой вы менеджер) второе образование в области управления. И вот когда разработка пойдет туда, вы имеете неплохой шанс стать куратором филиала. Но это путь для сильных, смелых и упертых. Готовых годами готовить почву для успешной реализации своих целей. Готовых годами упорно искать Эльдорадо, несмотря на то, что работа пастуха (ковбоя) дает стабильный заработок.

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

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

----------------

[1] На SQADays-2008 фраза «I hate Agile» и флипчарт с темой «В России нет agile. Почти.» вызвали живой интерес у посетителей. Такой, что я всерьез задумался о сейшене «К барьеру!» между противниками и сторонниками agile.

Август 14, 2008

48. Разработка против вебразработки

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

Честно говоря, я долго не понимал, почему вебразработчики отделяются от просто разработчиков. На мой взгляд, между программированием на фортране и программированием на руби в плане организации процесса разница гораздо меньше, чем между созданием проектов на 10 функциональных точек и на 1000 ФТ. Ну, или между созданием критически важных систем и созданием систем for fun. Однако с маниакальным упорством, достойным лучшего применения люди пытаются выделиться и отделиться. Причем в очень забавной манере:

- Позвольте SRS глянуть.

- Чего?!

- Спецификацию требований к ПО.

- Откуда? У нас же вебразработка?

- А что такой интерфейс у[!»№;]. некузявый?

- Так у нас же вебразработка!

- А почему не хватает критически важного функционала?

- Во, тупой. У нас же вебразработка!

Я не знаю, откуда пошло поверье, что словом веб можно прикрыть отсутствие культуры создания ПО, но иногда такое приходится слышать. К счастью, есть приятные исключения. Есть разработчики, которые говорят: «Мы разрабатываем приложение с тонким клиентом» и есть те, кто: «Мы разрабатываем вебприложение».

Но все-таки, чем отличается веб от не веб? Я попробовал собрать положения, которыми оперируют и дал свою оценку. Таким образом, я хочу обозначить границы «священной войны». А само сражение можно будет провести попозже. Может быть на веборубе. Может быть на открытом семинаре.

Вещи которые, на мой взгляд отличают веб разработку от разработки

* Малая стоимость поставки новой версии потребителю.

Как следствие - возможность уменьшения времени между релизами.

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

Плохо прогнозируемая нагрузка. Сильные всплески нагрузки.Есть такое дело. Вспомним «ложащиеся» новостные сайты 11 сентября 2001 или этим августом. Хотя опять же, точно так же ложится билинг сотовых операторов.

Смещение весов метрик качества от функционала к внешней привлекательности в системе оценке продукта по сбалансированному набору показателей.Действительно, существенная часть сайтов обладает функционалом примерно соответствующем программе «Hello world!». А вот требований по оформлению масса. Что и дает масло на хлебушек оформителям и верстальщикам (не путать с дизайнерами пользовательских интерфейсов и программистами). Понятно, что проекты бывают разные, но, в целом, число функциональных требований в вебпроектах не так уж невелико.

Вещи, которые ошибочно приписывают вебразработке

Высокая конкуренция и требование выстрелить раньше конкурентов.Не думаю. Вот для фильма или игры выйти на месяц позже спланированной рекламной кампании – это очень неприятно. А для веба то чего? Ну, вышел гугль на рынок в n-ом десятке. И спокойно занял первое место. Ну, появилась TrackStudio, когда на рынке уже было несколько сотен бактрекеров. И опять же совершенно спокойно, отвоевывает рынок. Хотите отвоевать аудиторию у ЖЖ? Да не проблема. Сделайте нормальное функциональное покрытие и приличный интерфейс – и будете первым (справедливости ради есть еще несколько вещей, которые нужно сделать). Смотри http://ivbeg.livejournal.com/146879.html.

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

Высокая нагрузка.Да действительно, есть поисковики с серьезной нагрузкой. Но с другой стороны есть и биллинг сотовых операторов. А что касается контент-проектов на миллион хитов в сутки, то какая же это высокая нагрузка? Дюжину лет назад подобную нагрузку держали на четверках (в смысле на 486DX-66 c 16mB RAM). Правда, это был не веб.

Вещи, характерные не только для вебразработки

Неудачный выбор языков программирования."Практически невозможно научить хорошо программировать студентов, ориентированных первоначально на БЕЙСИК. Как потенциальные программисты они умственно оболванены без надежды на исцеление." (с) Э. Дейкстра.

Вам не кажется, что PHP и perl не самые лучшие языки для проектов на несколько сотен тысяч строк кода? Характерно как для веб, так и для не веб.

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

Очень низкая скорость добавления новой функциональности.Это скорее следствие кастрированных IDE, неадекватных языков программирования и отсутствия дисциплины разработки. Опять же характерно как для веб, так и для не веб.

Сентябрь 1, 2008

Комментариев: 4

1. Alex Lebedev написал: 1 Сентябрь 2008

Что за мифическое создание "просто разработка"? Много ли общего между созданием корпоративного софта, игр и системного ПО?

2. SALar написал: Сентябрь 2008

Достаточно много. И много различий. Статья не о том.

Лучше скажите, с какими пунктами несогласны. И мы их спокойно обсудим.

3. Alex Lebedev написал: 3 Сентябрь 2008

Мне кажется, ассоциация "веб-разработка=халтура" вызвана тем, что самые дешевые проекты на сегодняшний день находятся именно в области веб-разработки. То есть веб как платформа позволяет делать их дешевыми, и эту нишу занимают заказчики, которые раньше вообще не тратились на ИТ. Ну а где дешевые проекты, там и дешевые разработчики. А где они - там и все перечисленные проблемы: от языка PHP до посредственного качества и отсутствия документации. "Печать дешевого разработчика" наблюдается и в других областях с не очень высокой стоимостью, в частности я слышал много жалоб на малые проекты, связанные с 1С.

4. Alexey написал: 16 Сентябрь 2008

Вам не кажется, что PHP и perl не самые лучшие языки для проектов на несколько сотен тысяч строк кода?

Очень много людей подобных данному - [Удалено из соображений политкорректности. Администратор.], имеющих очень низкий уровень развития, но верующих в свою крутость, и в то что их сайты-визитки это нереально сложные, а главное - самые настоящие «Проекты». Они не хотят учиться, не хотят думать, ибо это приведёт только к разрушению иллюзий.

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

Но подобная ситуация не только в ИТ-сфере. Низкое качество музыки, кинофильмов, еды и т.п.

49. Крупная солидная компания. Быстро, недорого

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

Пусть, перед нами стоит задача создать большую солидную компанию. Большая – это от 1000 сотрудников. Солидная – давно на рынке; пишут в прессе; есть награды, сертификаты, …; внешние атрибуты: сайт, хороший офис в центре Москвы (убей не понимаю зачем этот атрибут, но общественное мнение сильнее). Давайте посчитаем, сколько это будет стоить.

Для начала нам все-таки нужен штат сотрудников, которые будут работать. Соответственно, достаточно высокооплачиваемых. На разных этапах их понадобится разное количество. Пусть будет $5 000 / мес, ~ 20 человек, на 6 месяцев. Плюс налоги, плюс накладные расходы – лучше заложиться на полтора миллиона долларов.

Начнем с «давно на рынке». Нам нужно, чтобы компания существовала хотя бы пять лет. Лучше больше. Ищем в яндексе, ищем по строке «продажа готовых фирм» и выбираем что-нибудь подходящее. Например, это: http://www.pravo4you.ru/. Или что-нибудь другое. Хорошее название желательно, но необязательно, т.к. можно провести ребрендинг. Вполне можно купить десятилетнюю фирму, лежащую под сукном, в пределах 20 тыс. долл. Или можно купить старенький чахлый стартапик. Деньги смешные, находятся в пределах погрешности расчетов. Не учитываем.

«Большая». Ищем регион с небольшими зарплатами. Какая область у нас на последним по экономическому развитию? Чечня? Нет, «кузнец нам не нужен». Следующими, кажется, идут Псковская и Ивановская области. Вот это то, что нужно. И недалеко, и дешево. Нам нужно много занятых стульев с минимальной зарплатой. Есть минимум две категории людей, готовых обменять свои трудовые книжки на ММРОТ. Это студенты и пенсионеры. Нанимать лучше и тех и других. При случае можно будет сказать, что средний возраст сотрудников 30-35 лет.

А в среднем по больнице, включая морг и тифозное отделение у нас температура нормальная!

Наймем с небольшим запасом. Тысяч пять. Что уж точно стать "большими". ММРОТ + налоги + … , -каждый работник обойдется нам в $80 – 100 в месяц. Да еще и не один месяц. Миллиона полтора долларов. Многовато, но что делать.

«Награды, сертификаты». Года четыре назад покупка ISO обходилась в $30 000, сейчас это дешевле. А вот купить CMMI подороже будет. Здесь уже о полумиллионе думать надо. Всевозможные награды и таблички на стену типа «Победитель в конкурсе среди программистов бобруйского переулка города Урюпинска» покупаются оптом и в розницу по смешным ценам. На весь это пункт стоит выделить около миллиона.

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

«Внешние атрибуты». Про сайт говорить смысла нет – смешные деньги. А вот хороший офис встанет дорого. 500 квадратов * 100 долл/мес, да не один месяц, да отделка… Миллион – легко.

И… И собственно все. Итого за полгода и за 5,5 миллиона долларов мы становимся счастливыми обладателями «Крупнейшей, солиднейшей компании».

Зачем такие компании нужны – другой разговор. Я хочу сказать, что выводы, сделанные на основании формальных метрик, не всегда бывают корректны. Если в бактрекере мало ошибок – это не значит, что софт хороший. А если что-то блестит – то это не обязательно золото.

Сентябрь 18, 2008

50. Менеджер по борьбе с персоналом. Прямо по Дилберту

Это письмо-обращение нового сотрудника ОБП (отдела по борьбе с персоналом). Текст почти реальный. Конечно, кое-что убрано, кое-что поправлено. Искажать полностью смысла не вижу - подобное может случиться почти в любой компании.

Если непонятно в чем прикол, читайте "Принцип Дилберта". Или Деминга. Или Демарко.

Мое мнение: "Подобных людей нужно держать на огромном расстоянии от управления людьми и тем более от влияния на кадровую политику."

------------------------------------

Уважаемые коллеги!

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

Вкратце охарактеризую круг вопросов, которые будут находиться в моей компетенции.

Как можно догадаться из названия должности, это вопросы, связанные с персоналом, а именно:

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

Март 16, 2009

Комментариев: 7

1. andviper написал: 15 Ноябрь 2009

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

Принцип Дилберта еще не читал, но видел много комиксов Адамса. И не заметил там идей на тему того что персоналом не надо управлять. Конечно, это надо уметь делать, а не просто хотеть это делать.

2. SALar написал: 16 Ноябрь 2009

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

Смешно. Что может знать HR о квалификации DBA?

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

Смертельная болезнь #3 по Демингу. Смотри "Пространство Доктора Деминга" Генри Р. Нива.

> отслеживание рынка труда, контроль соответствия уровня оплаты труда в компании рыночному уровню

И получим "Персики и Лимоны" {http://qualitya.blogspot.com/2009/08/blog-post_07.html}

----------

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

3. andviper написал: 17 Ноябрь 2009

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

Про смертельную болезнь почитаю. Пока не прочел, высказывание кажется вполне логичным. А стало быть, без Деминга я ничего не понимаю [:(] Для меня как для исполнителя гораздо привлекательнее знать за что я отвечаю, как оценивается моя работа и почему у меня такая зарплата (относительно рамок компании конечно), чем не знать ничего этого и после очередной аттестации гадать или выяснять почему меня опять "недооценили".

Не понял, как связано соответствие оплаты труда в компании рыночному уровню (или может это плохо?) с приведенным примером, в котором, по моему мнению, основная проблема - в неумении отличить персик от лимона.

4. SALar написал: 17 Ноябрь 2009

-------------------------

СМЕРТЕЛЬНЫЕ БОЛЕЗНИ

3. СИСТЕМЫ АТТЕСТАЦИИ И РАНЖИРОВАНИЯ ПЕРСОНАЛА

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

"Управление по Целям" — зло того же порядка; "управление на основе страха" было бы более подходящим его названием. Результаты подобной практики следующие:

Развивается "близорукое" мышление, взращивается соперничество, интриганство и страхи, уничтожается перспективное планирование, разрушается дух команды; Одни люди испытывают чувство горечи, другие — отчаяние, некоторые работники переживают депрессию, из-за которой они неработоспособны в течение недель после получения оценки своей деятельности, причем они не в состоянии понять, в чем их вина. Эти методы несправедливы, т. к. они приписывают людям в группах такие различия, которые могут быть полностью обусловлены системой, в которой работает группа. (см. главу 30).

-------------------------

Может все-таки найти книгу и прочитать?

5. andviper написал: 21 Ноябрь 2009

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

А на другие вопросы ответов не будет?

6. SALar написал: 21 Ноябрь 2009

Чтобы полностью осознать проблему стоит прочитать кучу книг. Пересказать их в блоге нет никакой возможности. Если коротко, то человек попал не на свое место. Работать не умеет, а показывать свою значимость надо. А то уволят. Как результат, на свет могут быть произведены:

* Регламенты по расходованию туалетной бумаги

* система поминутной отчетности

* доносительство за несоответствие цвета галстука корпоративной эмблеме

Список глупостей он бесконечен. И какую бы глупость я не придумал, она уже была сделана.

Короткий список книг, которые должен прочитать сотрудник, перед тем как его можно будет допускать к работе с людьми:

* "Peapleware" Демарко, Листер

* "Сделано в Японии" Акио Марито

* "Пространство доктора Деминга" Генри Нив

* "Цель", "Критическая цепь" Голдратт

* "Принцип Дилберта" Адамс

* "Путь камикадзе" Йордан

Ну и еще пару десятков. Начните с этого. Квартала на чтение должно хватить. Потом начнете выстраивать параллели. Поймете, что в Peapleware дана статистика, подтверждающая теорию "Критической цепи".

Чуть не забыл. Еще цикл "Корпоративные паразиты" {http://www.eldar.com/taxonomy/term/59} изучите.

7. andviper написал: 22 Ноябрь 2009

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

А за список книг спасибо конечно. И вообще за то, что учите других [:)]

51. Нет ножек - нет варенья

Мне в детстве мама выколола глазки,

Чтоб я в шкафу варенье не нашел.

Я не хожу в кино и не читаю сказки,

Зато я нюхаю и слышу хорошо!

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

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

Что есть тестирование? Это процесс проверки ПО на соответствие спецификации. Нет ножек, т.е спецификации - нет варенья, т.е тестирования.

И более того. Нет ножек - нет разработки.

В принципе, существуют проекты, в которых можно сэкономить на спецификации. Крошечные такие проекты, юзкейсов на 5-10. Наверное, есть команды которые могут эту экономию получить даже на 50-ти юзкейсном проекте. Но вы с такими командами вряд ли встретитесь.

Фантастика, господа, на втором этаже.

Октябрь 14, 2008

52. Антикризисные мероприятия

Японская компания, переживающая тяжелые времена, предпринимает такие шаги:

1. Снижает дивиденды. Возможно, прекращает их выплату.

2. Урезает зарплаты и премии высшего руководства.

3. Еще больше экономит на руководстве.

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

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

взято из "Новая экономика" Э. Деминга и "Сделано в Японии" Акио Марито.

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

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

Октябрь 15, 2008 в 23:01

Комментариев: 3

1. karkadil написал: 16 Октябрь 2008

Дело в том, что ты мыслишь АйТишными категориями, которые к нам в основном пришли с Запада (вместе с заказчиками). Большинство же наших предприятий (фирмы и фирмочки, заводы, ЧПшники и т.п.) работают так же, как это было при СССР. На руководящие должности ставятся "свои" люди, поэтому и увольнять их будут в последнюю очередь.

Еще один немаловажный факт: в АйТи сейчас идет постоянный приток работы из-за границы, поэтому людей толковых мало и ими дорожат. Где-то (вроде на РСДН, но я не уверен) была информация о том, что такая тенденция будет примерно до 2016 года. Можно так сказать, что АйТишники - ценные работники. А "разнорабочих" гораздо больше, их найти будет не проблема в любое время.

Еще раз: проецировать свои знания и опыт в АйТи компаниях на все остальные я лично считаю неправильным.

2. SALar написал: 16 Октябрь 2008

Я имел ввиду не АйТи компании. А компании вообще. Пивоваренные заводы, сталелитеные предприятия, -

> Можно так сказать, что АйТишники - ценные работники. А “разнорабочих” гораздо больше, их найти будет не проблема в любое время.

Верстальщика HTML найти или обучить легко. А вот найти электрогазосварцика 6-го разряда - проблема. Про инженеров конструкторов вообще помолчим.

Но ладно бы даже найти людей. Создать слаженные команды - вот проблема.

3. {BlackICE} написал: 17 Октябрь 2008

Хм- это ж Россия. Всюду надежда на "Русский авось". И мудрость у директоров фирм не в почете у нас в стране. Увольняя сотрудника о нем думаю, как о мешке с песком, который берут для балласта на воздушный шар. Пока надо - лежит, надо взлететь - выбрасывают. Что же касается поиска нового сотрудника (после кризиса) - как уже сказал - надеются на Русский авось.

Я всегда говорил, что все проблемы людей (и особенно в нашей стране) от того, что они не хотят думать о будущем.

53. Требования к ПИ и их отсутствие

Интуитивно понятная система — это система, в которой умом нельзя понять, что происходит, поможет только интуиция (если вам ее хватит).

В конце семинара {Базовые инструменты и методы аналитика} разобрали практический кейс.

=================

Заказчик обращается к разработчику ПО с просьбой разработать софт. В ходе интервью выяснилось, что:

Много лет эксплуатировалась система, написанная на чем-то канувшем в лету. Но, но, но. Развивать систему стало почти невозможно. Где вы найдете разработчика под турбобейсик или вторую лисичку [1]?! Как интегрировать с другими системами? Ну и т.д. Была приглашена студия, реализовавшая требуемый функционал, но опытно промышленная эксплуатация выявила полную непригодность системы. Это система учета платежей за электроэнергию для областного центра. 200 тыс. платежей в месяц, 5 операторов вводят по 2 000 платежей в день. Далее в ходе интервью использовалась диаграмма Исикавы.

Первая ветвь:

- Что не устраивает в системе?

- Да с этой системой нам нужно увеличить число операторов в десяток раз

- А почему?

- Так очень медленно все. Раньше по десять-пятнадцать платежек в минуту вводили, а сейчас за три в минуту впору премию давать. Да и ругаются операторы и нервничают. Опять же каждые полчаса чай уходят пить для успокоения нервов. Опять же время.

- А почему так медленно?

- Раньше как было: одной рукой держишь платежку, а другой по дополнительной клавиатуре колотишь. Там только цифры и Enter нужны. Шесть цифр (номер), Enter, сумма Enter - на одну платежку три-пять секунд надо. А новой системе модный оконный интерфейс появился. Три секунды окно открывается, номер, потом мышкой на другое поле щелкнуть, -

- Почему получился такой интерфейс?

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

Вторая ветвь:

- Что еще не устраивает в системе?

- Ошибок много допускают.

- А почему?

- Раньше как было: номер ввел - сразу напротив ФИО появляется. А поскольку правая рука только по дополнительной клавиатуре отстукивает, смотреть на клавиатуру не надо, то оператор сразу ошибку заметить может.

- А в новой системе?

- А в новой системе ничего не появляется. HTML говорят. Нельзя говорят [2]. Нужно всю пачку вбить, потом заново открыть и опять все платежки по одной перебрать.

- Почему получился такой интерфейс?

- Потому что в спецификации требований не было прописано такое требование к интерфейсу, как: "Число ошибок в наборе номера лицевого счета не должно быть больше трех на 10 000 платежек".

Третья ветвь:

- А -

- ***

- Потому что в спецификации требований не было прописано такое требование к интерфейсу, как: "Время обучения работе с программой сотрудника с квалификацией опытный пользователь ПК не более 16 часов".

=======

Честно говоря, за фразу в спецификации требований "Интуитивно понятный интерфейс" команду разработки нужно посылать в сад. Потому как это не требование, а детский сад, штаны в горошек.

[1] Лисичка – это foxpro, а не firefox.

[2] По поводу Ajax, Java и прочих флешей. Да, Ajax может подтягивать данные. Только вот использование Ajax ухудшает такую метрику качества ПО, как "расширяемость". Не говоря уже о том, чтобы реализовать обход грида по Enter, с автоматическим добавлением строк. Не, можно конечно сделать. Но глядеть на этот код без валерьянки будет тяжело.

Октябрь 28, 2008

Комментариев: 3

1. Dart написал: 28 Октябрь 2008

Для того, чтобы выделенные жирным фразы попали в подписанный контракт нужен невероятный уровень доверия между заказчиком и исполнителем. 99% руководителей вам скажут, что это просто "попадалово".

Либо нужно очень четко прописать методику тестирования. Особенно про три ошибки [:)] . Я бы на месте заказчика с помощью этой фразы нашел бы способ не заплатить исполнителю. Посадил бы "своего" человека, который будет специально делать 4 ошибки в 10'000 платежек и выторговал бы себе скидку в NN% за доп. соглашение в котором этот пункт договора будет отменен [:)] .

Сама идея то понятная - просто доведена до крайности.

Лучшим вариантом, на мой взгляд, является утверждение прототипа пользовательского интерфейса.

2. SALar написал: 28 Октябрь 2008

> 99% руководителей вам скажут, что это просто “попадалово”.

Более того, так обычно и бывает.

> Сама идея то понятная - просто доведена до крайности.

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

Еще момент. Лучше работать не с ограничениями, а с функцией потерь Тагути, но до этого нам пока как до луны.

3. serguei_tarassov 1 Март 2009

По поводу требований к ПИ. Вам не кажется, что сейчас повсеместно формальные методы пытаются заменить т.н. "кейсами"? Не только в ИТ, а вообще везде.

54. Сколько мы вам должны?

Это заметка о расчете стоимости софтверного проекта, в зависимости от затрат на разработку.

Пусть на разработку был потрачен один месяц специалиста с окладом 100 у.е (1у.е. может быть равен и $20 и 10 000 рублей – считайте, как вам удобней). Во сколько разработка обошлась фирме?

Почему-то считается, что внутренняя разработка стоит только эту зарплату. Позвольте, господа, а ЕСН? А связанный капитал в виде оборудованного рабочего места? А труд обслуживающего персонала (уборщицы, бухгалтера, директора)? А аренда офиса? А отпуск и больничный? В свое время, беседуя с Александром Смирновым на эту тему, мы пришли к выводу, что для расчета расходов фирмы нужно ввести мультипликатор 2.5. Таким образом, если зарплата внутреннего разработчика 100 у.е., а сторонняя фирма берется делать за 200, то при прочих равных внешний исполнитель выгоднее. Самое интересное, что внешний подрядчик может оказаться выгодней и при запросе 270 у.е., так как в случае срыва проекта внешний подрядчик ничего не получит, а полный расход в 250 у.е внутри, фирма все равно понесет.

При отсутствии затрат на продажу мультипликатор внутренней разработки равен:

• 2.5 для безрисковой разработки

• 3 для малорискованной разработки

Как это применять:

Расчет 1. Пусть вебстудия планирует переезд в другой офис. Есть два варианта. Первый - нанять грузчиков. Второй – потратить один день разработчиков. Пусть у нас работает 10 человек, суммарный оклад в месяц - $20 000, или $1 000 в день. Переезд – операция безрисковая, берем мультипликатор 2.5. Если инженерный состав фирмы полностью загружен работой, и грузчики просят менее $2 500, то они выгоднее.

Расчет 2. У крупного дистрибьютера косметики возникла потребность сделать внутрениий сайт. Можно попросить своего Васю из отдела листовок (он что-то понимает в HTML и прочей дизайне), можно нанять стороннюю фирму. Что дешевле? Вася может сделать, может не сделать – для вычисления расходов фирмы берем мультипликатор 3. Затраты на стороннюю фирму пока не рассматриваем. Тогда если Вася предположительно будет безвылазно возиться с сайтом два месяца при зарплате в $1 500, то предполагаемые расходы фирмы: 1 500*2*3 = $9 000. Ну, а когда Вася на самом деле безвылазно провозится полгода – истинные расходы составят 1 500*6*2,5=22 500. Учитывая рискованность таких авантюр (Вася мог возомнить себя крутым дизайнером и уйти, не доделав), фирма вполне может заключать договор внешнего подряда при сумме менее 27 000 (возвращаемся к мультипликатору 3).

Теперь представим себе обратную ситуацию.

Расчет 3. Мы вебстудия, к нам приходит клиент с просьбой сделать «ему хорошо». Расплатиться обещает по факту приемки. Бюджет нормальный, просто: «не делайте лишнего и возьмите по отработанным часам». Работаем с заказчиком очень давно и всегда были довольны друг другом. Беремся, делаем. Суммарная зарплата разработчиков 10 тысяч грина. Какой мультипликатор взять? 2.5 прямых расходов умножаем на коэффициент рискованности (мы ведь можем и не доделать, а платить разработчикам придется), умножаем на коэффициент продажных затрат, и умножаем на коэффициент планируемой прибыли. В итоге у вас должен получиться мультипликатор от четырех до пяти. Иногда доходит и до 10, но это означает повышенную рискованность и/или сверхзатраты на продажах и/или неуемную жадность владельца. В нормальном, сложившемся бизнесе партнеров 4-5 разумный мультипликатор. Может доходить и до 3.5. Чистую троечку не рекомендую, бизнес при троечке умирает.

Если же оплата идет не постфактум «по труду», а по принципу «сначала скажите, сколько стоит, а потом делайте», то мультипликатор возрастает.

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

Мультипликаторы внешней разработки:

• 4-5 для сложившихся долгосрочных отношений

• От 10 для дикого рынка

Теперь я думаю понятно, почему при условиях:

• Затраты разработчиков на сайт визитку - 2 дня

• Оклад 60 000 руб/ месяц ( $120 в день), ($240 вся разработка)

Вебстудии берут за «визитку» $5000. Они вводят офигенный мультипликатор из-за чудовищного цикла продаж. Если бы клиент пришел в веб студию с человечной спецификацией и полной предоплатой, то мультипликатор можно было бы опустить до четверки. ($1000 за двухдневную работу).

Хинт. Предварительное ТЗ позволяет очень сильно уменьшить мультипликатор. Хороший SRS позволяет еще больше уменьшить мультипликатор.

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

Как понизить мультипликатор?

1. Использовать вместо аутсорсинга аутстафинг. Риск неудачи заказчик берет на себя, что позволяет снизить мультипликатор до троечки. На руки программист получает 20 баксов в час, а фирме за него платят 60 (В итоге для заказчика расходы с учетом риска почти те же, но он об этом не знает).

2. Изменение налоговой схемы на упрощенку.

3. Наем работника с собственным рабочим местом (надомник). Работник берет расходы за офис, уборщицу, комп и т. д. на себя. Правда, следует учесть, что правильный надомник (с которым вообще можно связываться) берет за час надомной работы больше, чем за час в офисе.

Аутстафинг надомника по упрощенке… М-м-м… Можно попробовать сделать мультипликатор меньше двойки. Толку-то. С учетом рисков, недополученной прибыли и прочего, сумма останется примерно та же.

- А если совершенно надежный, трижды рекомендованный, за пять последних лет не подводивший?

- Ну так он и стоит соответственно.

Декабрь 2, 2008

55. Веборуб

Едем в пятницу.

Хочу покатать тему: "Кризис — это время, когда нужно достать лопату для сгребания денег. Ну или хотя бы начать ее изготавливать". Желающие оппонировать - готовьте контраргументы. Можно кидать сюда. После веборуба попробую написать до чего дообсуждались.

Также хочу поиграть в красные бусы. Нужен десяток добровольцев.

Также, если успею, хочу покатать тему сбалансированности и место ОТК в разработке ПО.

Ноябрь 26, 2008

Один комментарий

1. karkadil написал: 26 Ноябрь 2008

Что такое "красные бусы"? Я люблю во всякое играть, но не знаю, что это такое?

Насчет кризиса и лопаты для сгребания денег.

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

А ситуация у многих наших сограждан даже еще хуже: КРЕДИТЫ. Так что у людей не просто нету денег, они еще и должны.

Сейчас самое время читать умные книжки по бизнесу, развивать свои финансовые навыки (хотя бы теоретически), присматриваться к ситуации в стране, к тенденциям.

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

Слава богу, сейчас это все можно приобретать практически бесплатно. Новости читать в интернете, подписываться на РСС и новости сами будут приходить к вам; качать книжки из интернета и читать их (у многих даже в мобилках есть возможность читать книги и лазить по интернету).

Короче, я к чему: сейчас надо развивать свое видение, а не пускаться в финансовые аферы.

56. Место ОТК в разработке ПО

Интрига

Давно размышляю о подходящем наборе ролей и о месте Отдела Технического Контроля (ОТК) в разработке программного обеспечения.

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

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

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

Простейшая модель

Пусть у нас есть отдел разработки ПО в продуктовой компании. Отдел занимается только внутренней разработкой.

Ограничение производства - внешнее по отношению к отделу. Это ограничение по рынку. Предположим, что спрос на ПО стабилен и составляет 100 условных единиц софта (УЕС) в месяц. Поскольку ограничением является рынок и сделать с этим ничего нельзя, нужно построить работу так, чтобы делать все заказы. Мы должны поставлять 100 УЕС-ов каждый месяц. Цель оправдывает средства.

Для упрощения задачи сделаем еще несколько предположений:

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

2. 100 УЕС-ов позволяют компании жить и развиваться. Но если их не будет – предприятию будет нехорошо, ибо конкуренты не дремлют.

3. Но все равно хочется сократить затраты на разработку, т.к. аутсорсеры предлагают поставлять те же 100 УЕС-ов за 200 условных единиц денег (УЕД)

Департамент разработки разбит на три сектора (три выделенных роли):

взаимодействия с заказчиками – отвечает за прием в производство того, что нужно бизнесу аналитики – отвечает за то, чтобы то «что нужно» – обладало «нужным набором фич» программирования - отвечает за корректную реализацию «нужного набора фич» Я специально не ввел ОТК. Почему – станет ясно позднее.

Для того, чтобы средние производительности секторов были равны 100 УЕС, необходимо, чтобы операционные затраты на отделы (зарплата + налоги + аренда + уборщица + кофейный автомат + …) были соответственно:

взаимодействия с заказчиками – 10 УЕД аналитики – 20 УЕД программирования – 50 УЕД. Это могут быть и 50 человек по единичке уе и пятеро по восемь. В данной модели нам интересно только соотношение между секторами. Примечание. Если кто-то спросит про запас по производительности – то это цифири как раз с нужным запасом, который и позволяет поставлять продукт «точно вовремя».

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

Сделаем еще несколько предположений в модели:

Потерь бизнеса от поставленного брака нет (это просто идеальный мир). Нужно просто обеспечить генерацию ста качественных УЕС-ов в месяц. Не более, но к сожалению, и не менее. И если каждый месяц поставляется 100 единиц качественной продукции, то бизнес доволен, сколько бы не было брака. Пусть каждый отдел допускает в обработке заказа всего треть ляпов. Т.е. с вероятностью одна третья вносит в разрабатываемый УЕС дефект. Так конечно не бывает. Обычная норма: 60-80%. Но вдруг? Вдруг собрались звезды? Ну, или софт настолько прост, что ошибок мало? Вероятность получить качественный продукт на выходе равна (2/3)*(2/3)*(2/3). Департамент разработки без Отдела Технического Контроля производит 70 брака и всего 30 качественных УЕС-ов. А надо 100.

Решение номер раз.

Пропорционально, в 10/3 увеличить сектора:

взаимодействия с заказчиками – 34 УЕД аналитики – 67 УЕД программирования – 167 УЕД Сюрприз! Операционные расходы выросли до 268. Это, господа, много. Нет, это перебор. Это шах и мат департаменту. Т.е. это полный «П». Всех разогнать и обратиться к аутсорсерам.

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

Решение номер два.

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

Сделаем еще несколько предположений.

ОТК в любом секторе отлавливает только ошибки своего сектора. Это очевидно и прекрасно согласуется с жизнью. Тестировщик, умеющий отлавливать недокументированные требования и нужды бизнеса только на основании своего опыта – это зверек редкий и обитает в черном разделе красной книги (вымершие виды). Таких спецов очень быстро переводят на другие работы. ОТК отлавливает дефекты со 100% вероятностью. Так конечно не бывает. Но мы рассмотрим идеальную фирму, в которой работают настоящие самураи плаща, кинжала и бактрекера. Дефектный УЕС проходит еще один цикл обработки и обязательного последующего контроля. Исправленный модуль никогда не содержит ошибки. Так конечно тоже не бывает. Нормальное количество возвратов – это 4-6. Канер приводит цифры 6-8. Но как говорится мечтать, так мечтать. Проверка стоит 1/3 от разработки Изначально операционные расходы на разработку составляли 50 УЕД. Плюс нужно добавить на исправление дефектов 50 *(1/3), плюс нужно добавить на контроль.(50+50*(1/3))+ (50+50*(1/3))*(1/3)=89Не то чтобы это было замечательно, но пока приемлемо.взаимодействия с заказчиками – 10 УЕД аналитики – 20 УЕД программирования – 89 УЕД Однако стоп. Такой департамент будет выпускать всего (2/3)*(2/3)=44% качественной продукции. Мы ведь еще не забыли, что остальные департаменты тоже допускают ошибки!? Но мы грамотные. Мы знаем, как решать проблему недостаточной мощности. Нужно просто пропорционально увеличить сектора.

взаимодействия с заказчиками – 23 УЕД аналитики – 46 УЕД программирования – 203 УЕД Сюрприз!!!

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

Вместо выводов

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

Продолжение следует

Я думаю, мои читатели вполне способны поиграть с моделью и найти более-менее приемлемое оптимальное решение для своей фирмы самостоятельно. Тем же, кто кочет подставить более-менее реальные цифры для среднего по размерам проекта (от 10 человеколет), но не имеет замеров по своей фирме, рекомендую взять следующие параметры:

Секторов пять. Если без брака, то:

Прием заказов – 8 Аналитика – 20 Архитектура – 12 Программирование – 36 Поставка – 4 Процент брака в каждом отделе без ОТК возьмите равным пятидесяти процентам. Это даст вероятность получить на выходе качественный продукт около трех процентов, что очень хорошо согласуется с текущими реалиями. По крайней мере, по моим опросам среди коллег.

В первой модели мы брали увеличение расходов на отдел при внедрении ОТК чуть менее двойки. Реально же за счет большего числа возвратов этот коэффициент около тройки. При таком коэффициенте процент пропущенного брака будет в приемлемых 5-10%.

И, если хотите поиграть совсем уж по жизненным правилам, введите малюсенький штраф за поставленный брак. В размере 0.1 - 0.5 УЕД за один поставленный бракованный УЕС.

PS.

Не будьте так серьезны. Это просто модель. Как говорил великий Фрейд: «Иногда бывают просто сны».

Декабрь 22, 2008

57. По итогам семинара "Производительность против предсказуемости"

По итогам семинара было озвучено несколько тезисов. Так, в частности, есть несколько очень эффективных способов разорить предприятие:

Способ первый. Увеличить локальную эффективность отдела(ов).

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

Способ второй. Сбалансировать мощности отделов.

Цитата из Голдратта: "Настоящая причина того, что ты не можешь достичь идеального баланса [производительности отделов], намного более фундаментальна, чем те, которые ты назвал. Все остальные - относительно незначительны. На самом деле, настоящая причина в том, что чем ближе ты состоянию идеального баланса, тем ближе ты к банкротству."

Второй метод очень эффективен для разорения предприятия. Более того. Он чудовищно эффективен. Но есть еще более сокрушительный.

Способ третий. Заставить каждого работника предприятия работать с максимальной производительностью.

Андрей Степенко говорит, что в этом случае предприятие разоряется за два производственных цикла. Я считал, что за три, но положусь на мнение эксперта.

Не буду проводить интернет-опрос, но все-таки любопытно. Какой процент фирм сейчас следует вышеперечисленным рецептам разорения?

PS. Из вышеизложенного есть исключения. Но не льстите себе. Вряд ли ваша фирма входит в их число.

Январь 21, 2009 в 00:28

Комментариев: 4

1. balepc написал: 21 Январь 2009

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

2. SALar написал: 21 Январь 2009

Например, так: {http://www.toc-center.ru/politseiskie_proekty.html.}

Но бывают и совсем клинические случаи.

Семинар пока проходит обкатку. Выйдет в свет - сообщу.

3. Denis написал: 21 Январь 2009

Термин "производительность" неправильно подобран. В данном случае правильно сказать: "интенсивность".

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

4. SALar написал: 3 Февраль 2009

у полицейских в примере "результат работы" увеличивался (количество раскрываемых преступлений в месяц увеличилось) при уменьшении "усилия по её выполнению". Denis, по вашему определению получается, что производительность росла.

Впрочем, терминологические споры оставим методологам. Мой посыл: "Достаточно часто нужно запрещать сотрудникам работать, для увеличения общего выхлопа (прохода) фирмы. Только нужно знать, когда запрещать."

Система компенсаций

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

Примечание. Под компенсацией подразумевается весь набор материальных благ, который организация предоставляет работнику в обмен на его труд. Термин не мой. В таком значении "компенсация" рассматривается очень многими сотрудниками hr.

Начнем с основного.

Система оплаты труда.

Договорная работа

Хороша для коротких маленьких проектов, не требующих дальнейшего сопровождения. Поставить розетку, выкопать яму под фундамент сарая, сделать сайт-визитку. Такие работы есть, но эти работы не для постоянного сотрудника в штате.

Сдельная оплата

Оценка стоимости того или иного вида работ (осмечивание) оно и в строительстве то далеко нетривиально и расхождения между двумя сметами достаточно велики. А для программирования СНиП-ов еще не придумали. Таким образом, как только вы вводите сдельную работу, масса сотрудников начинает заниматься не работой, а возвеличиванием значимости результата. Проблемы, описанные в романе «И это все о нем» покажутся вам мелкими и незначительными. Попробуйте начать платить тестировщику за количество найденных багов и моментально получите бактрекер заполненный ерундовыми ошибками. Штрафовать программистов за баги?! Ну-ну. Предупредите меня за два месяца до внедрения этого прогрессивного метода, чтобы я успел уволиться из этой фирмы.

Остается окладная и окладно-премиальная система оплаты. Говорят, что по КЗоТ при окладной системе за косяки можно было штрафовать, уменьшая оклад. А при окладно-премиальной, оклад трогать было нельзя, и штраф шел только за счет премии. Так оно или не так, сейчас это уже не очень важно. Со времен государства, в котором «самые лучшие игрушки» утекло много воды и сейчас штрафы практически не применяются. Во многих фирмах премия стала по существу частью зарплаты и это нормально.

Полноценная окладно-премиальная система

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

Возможный способ: 0-15% премия по состоянию дел в фирме, 0-15% за работу конкретного работника. – К сожалению, это чушь. Конкретный вклад сотрудника пытаются оценивать по набору формальных показателей, что немедленно приводит к работе на показатели (смотри «Сдельная оплата» и «Доплата за показатели»).

Платить премию в зависимости от успехов фирмы. Дает эластичность при девиациях на рынке. Был подъем – платили 15-25%, пошел спад – зарплата похудела. Судя по публикациям и опросам коллег, многие фирмы примерно так и сделали. Правда, не имея достаточного буфера в виде премии, им пришлось снижать оклад. А снижение оклада это очень скользкая операция. Перезаключение трудовых договоров. Потеря уважения и доверия сотрудников. Повышенное внимание госорганов,-

Пожалуй, я готов рекомендовать квартальную премию именно как буфер. И размер ее может быть до 150% от оклада. Но об этом нужно четко информировать на собеседовании.

Доплата за показатели

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

Но иногда эта уродливая форма компенсации труда принимает совсем уж абсурдные формы.

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

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

Доплата за продолжительность работы в фирме

Мера может способствовать уменьшению текучести кадров. Возможные варианты:

* 5% после первого года, 10% после второго года, 15% после 5 лет

* 2-3% за каждые полгода

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

Доплата за выслугу неплохо работает при застое (брежневские годы вполне подойдут для примера). При минимальной инфляции, отработанной десятилетиями тарифной сетке (водитель второго класса, учитель 11-го разряда) и жестко прописанных критериях перехода из одной категории в другую. Сейчас эта система почти бесполезна. Почти всегда программист воспользуется своим «правом на выход» до того, как бонус окажет хоть сколько-нибудь существенное влияние.

Белая-черная зарплата

Очень интересный феномен. Для тех, кто не в курсе. В нашем государстве очень приличные налоги на зарплату. Очень приличные. В 98 году на 613 рублей на руки нужно было отдать 387 рублей налогов (подоходный + пенсионный + медстрах + соцстрах). Таким образом приведенный налог на маленьких зарплатах был около 38%. В 2008 году эти цифры были 689 рублей и 311 рублей. Приведенный налог 31% процент соответственно.

Очень многие фирмы пытались хитрить. Еще бы! При полностью белой схеме фирма теряет целых 100 тысяч рублей, а работник получает всего 69 тысяч (для 2008 г). А нарушив закон можно не только сэкономить десять тысяч, но и выдавать 90 работнику. Все довольны кроме государства.

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

Но, как говорится, найдется метод и на Костю Сапрыкина. Работники нанесли ответный удар, придумав простое правило: «Если при черной (серой схеме) тебе задержали зарплату хотя бы на неделю, немедленно начинай искать новую работу. Как только нашел – немедленно увольняйся.» И теперь плохо стало всем.

Так что белая зарплата, это не только большие налоги, но и стабильность. А в роли гаранта стабильности выступает государство, которое находится в подходящей для арбитра весовой категории.

Как то, у меня все больше получается, что 69 на руки при белой схеме – это лучше, чем 90 при черной. Впрочем, «Каждому свое».

Опционы

В нашей стране не получили распространения. В РФ нет никакого доверия к долгосрочным обещаниям. И это оправданно. МММ, дефолт, гиперинфляция начала 90-х, массовое нарушение обещаний в 1998 и в конце 2008. Что еще нужно сделать, чтобы наш человек перестал верить обещаниям?! Кстати, почитайте про опционы у Ашманова. Или у Носова в «Незнайке на луне». И вообще, где «Отдельная квартира каждой семье к 2000 году» и «Коммунизм к 1980»?

Оплата обедов

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

Если быть совсем честным, полностью организованные бесплатные обеды гораздо выгоднее фирме, нежели работнику. Если не нужно считать деньги и столовая находится этажом ниже, то обед занимает минут 15. При походе на бизнес ланч в соседнее кафе добавьте еще полчаса. Часть экономии времени работники отдают фирме. А иногда и всю. В итоге, за какие-то гроши фирма получает до получаса лишнего труда в день. И даже если работник не отсиживает полных 9 часов – он лучше отдохнет дома.

Оплата мобильников

Имеет смысл при большой нагрузке на телефон по делам фирмы. Если же имеется ввиду просто корпоративный тариф на всех в размере 10-15$ на номер, то некая приятная вещь, не более.

И скажем честно, если это можно взять деньгами – то лучше взять деньгами.

Медицинская страховка

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

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

Возможно, если это можно взять деньгами – то лучше взять деньгами?

Оплата спортклуба

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

Здесь однозначно: если это можно взять деньгами – то лучше взять деньгами.

Возможность взять льготный кредит в фирме

Те проценты, которые дерут наши банки – это конечно нечто. Снижение процентной ставки по ипотеке до разумных 2-5% было бы большим подспорем. Но… Но не теряет ли сотрудник при этом не только право «на выход», но и право «на голос» (http://www.management.com.ua/hrm/hrm163.html)? Не получится ли так, что сотрудник больше не увидит индексирования оклада, а при попытках воззвать к совести ему будут угрожать увольнением и расторжением льготного кредитования?

После чего прикинем ущерб фирмы от итальянской забастовки… И счет не обязательно окажется в пользу фирмы.

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

Если можно взять деньгами – то лучше взять деньгами. А жилье купить в Черногории или в Праге. Не сейчас, так хоть на пенсии пожить в собственной хате.

Компенсация за съем жилья

Для IT-шных фирм явление очень редкое. Причина проста. Такую аренду нужно оформлять вбелую, а это налоги. Много налогов. И много других проблем.

Если можно взять деньгами – то лучше взять деньгами.

Обучение

А вот этот пункт не имеет отношения к компенсации. Компании либо нужны активные грамотные сотрудники или не нужны. Вклад в обучение можно скорее рассматривать как вклад в совершенствование процессов, инфраструктуру и организацию труда. Конференция по архитектуре, система кондиционирования, следование кайдзен, тренинг по проектированию интерфейсов, 24" монитор на каждом рабочем месте, 7+ квадратных метров офиса на человека, - - вещи примерно одного порядка. Это не компенсация, а необходимое условие выживания.

Февраль 3, 2009

Комментариев: 2

1. Александр Орлов написал: 11 Февраль 2009

Опционы имеют место быть в филиалах западных контор. Кроме того, после того, как акции западных контор начали стремительно снижаться (что делает деньги, получаемые с опционов безобразно близкими к нулю), кое-где стали выдавать RSU (Restricted Stock Units). Это прямо-таки акции (на них даже дивиденды начисляют), но с некоторыми ограничениями (не помню какими, честно говоря).

Питание - кое-где (в Google, насколько я понимаю) кроме обедов есть еще и бесплатные завтраки, и ужины. Наверное, чтобы сотрудник спешил приехать на работу пораньше и задерживался на попозже. [:)]

Медицинские страховки - довольно важный фактор удержания. Особенно для людей семейных. Например, Intel оплачивал мне 80% стоимости моей страховки и давал возможность застраховать семью по корпоративным тарифам. Выходила экономия что-то вроде 2-2.5 килобаксов в год. У нас младший часто болел, и страховку мы окупили. В Сане вообще оплачивают страховку на всю семью. Семейному народу очень нравится. [:)]

Со спортклубом вот, кстати, удачно получилось. У нас на первом этаже в офисе открыли приличный сетевой спорт-клуб. И пока они его открывали, они продавали абонементы по 5000 в год. Учитывая, что компания компенсировала 50%, абонементы пользовались популярностью. И много народу, насколько я понимаю, таки ходят туда. Ибо удобно. Практика оплачивать 50% спортивных расходов (сотрудник сам выбирает, куда и когда ходить), но до определенных границ - тоже неплоха.

2. SALar написал: 12 Февраль 2009

> Питание - кое-где (в Google, насколько я понимаю) кроме обедов есть еще и бесплатные завтраки и ужины. Наверное, чтобы сотрудник спешил приехать на работу пораньше и задерживался на попозже.

Насчет ужина - это мысль. За едой решается куча вопросов. Так что по сути это еще одно совещание в день [;-)] .

"Бэз-возд-мездно, то есть даом".

> 2-2.5 килобаксов в год.

У меня не получается столько тратить на больницу. Хотя, если будет 2-3 ребенка, то может быть все изменится. И все же и все же. Страховка на $3000 в год или плюс триста долларов к зарплате в месяц? Предложите такой быбор работнику с зарплатой в 1000$ - будет одна реакция. При зарплате в 10 000 - будет другая.

> У нас на первом этаже в офисе открыли приличный сетевой спорт-клуб.

О! Это ж совсем другое дело. Спортклуб в том же здании - это здорово. Завидую.

58. Спасите сайт

AB> Не нашел я там ссылку на - [раздел сайта].

SM> Просто у них "Интуитивно непонятный интерфейс".

AB> знаешь, я вот сейчас полазил по всем этим -[класс сайтов] и могу тебе сказать, что у них У ВСЕХ этот интерфейс непонятный.

SM> О. Это хорошо. Может быть теперь и ты программист поймешь всю скорбь еврейского народа (конечных пользователей).

AB> ндя, хрен найдешь.

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

Дополнение к диалогу. Была взята репрезентативная выборка по достаточно популярному классу сайтов. Рассматривались как топы (все), так и мелкие (несколько штук). Что получилось - то получилось.

Забавно получается. Я, покупатель, захожу на сайт и пытаюсь отдать денег владельцу бизнеса. Заказать товар в интернет магазине или найти ближайший скалодром. Но не получается. Между мной (покупателем) и владельцем бизнеса (продавцом) нерушимой берлинской стеной стоит ДиСайнер. ТвАрец. Художник. Он не может допустить, чтобы произошла низменная покупка. А кто же тогда будет любоваться его Дизайном?" Флеш, Джава, Аджакс, красивые картинки, - а для того чтобы изменить количество единиц товара приходится звонить в техподдержку-

А чего стоит геопривязка! Сколько времени уходит, чтобы понять, как добраться? Всего пять минут? Да вы просто виртуоз вебориентирования! Но и после того как вы найдете страницу с картой, ни в коем случае нельзя ей пользоваться. Это вполне может оказаться футуристическая схема, повернутая на произвольный угол. А может быть карта размером 8х8 пикселей. Что вот это такое: {http://www.durdin.ru/}??? Мне сайт нужен для того, чтобы попасть в ресторан или картинками полюбоваться? Дизайнер полагал, что картинками полюбоваться- Ау, владелец бизнеса! Этот сайт мешает твоим потенциальным клиентам приносить тебе деньги! Сайт красивый, не вопрос. Только в ресторан я другой пойду. У которого есть нормальный сайт с человеческой геопривязкой (чтобы дорогу найти), нормальная навигационная модель и полноценный атрибутивный набор (дабы наконец-то найти кабак БЕЗ музыки). Сайт, который сделан для меня - покупателя, а не для строчки в резюме "дизайнера".

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

Но Империя Зла готовит новый удар. В бой пошли CMS, где пользователь может самостоятельно менять навигационную модель. Абзац. Иван Сусанин нервно курит в сторонке.

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

Апрель 2, 2009

Один комментарий

1. Julia Nechaeva 3 Апрель 2009

Недавно составляла для Саши Орлова базу топ-40 украинских IT компаний на основе базы developers.org.ua. К сожалению, на данном ресурсе далеко не все фирмы представлены с контактами, пришлось лазать по сайтам, выискивать e-mail'ы.

Именно "выискивать"!

Я уже молчу о том, что большинство компаний публикуют адреса отделов кадров, а общего {info@-} нет.

Поражает умение запрятать страницу "Контакты" множеством различных способов.

59. Agile Labs 2009

31 марта состоится конференция {Agile Labs 2009} по гибким методологиям разработки. Очень неплохо, что на конференции будут представлены доклады не только "за" но и "против"

Интригой конференции является дискурсия между сторонниками и противниками, проводимая в формате телепередачи «К барьеру!»

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

Нет зрителей Для энтузиастов, делается энтузиастами Трудная (для участников) Вводящая в замешательство, смущающая Не для Одиночек Ошеломляющая Непредсказуемая Открытая на вход активистам Думаю, вы понимаете, откуда растут ноги. Скучно приходить посмотреть на «Говорящую голову». На многие традиционные конференции люди приходят просто потусоваться в кулуарах. Доклады побоку… В качестве протеста против такого формата даже родилась антиконференция «Веборуб», где есть только кулуары. А что делать с традиционными? Нужны «фишки». Или другие форматы. Фишкой SQA-2 стало «Инженеры для инженеров». На SQA-3 флипчарты были едва ли не интересней докладов. А как жгли конкурсы! Слоган по мотивам логотипа конференции "Забей на качество!" стал хитом. На трайнинг лабс мы серьезно поиграли с форматом и стало совсем хорошо.

А сейчас мы хотим устранить «испорченный телефон». Действительно. Есть два спеца. Оба профи. Но говорят разные вещи. Приходишь к одному, слушаешь, задаешь вопросы, долго думаешь. Потом идешь к другому. И так по кругу. Так почему бы не попросить идеологических противников просто выступить совместно?

Грядет «Крестовый поход». Папа римский уже объявил набор добровольцев.

На SQA-3 Асхата буквально заклевали вопросами. Он находился в заведомо проигрышном положении. Спрашивающих много, отвечающий – один. И может только отвечать, но не может задавать вопросов. Непорядок. В кулуарах противникам было предложено встретиться лицом к лицу. Перчатка была брошена. И поднята.

Вставайте, лестница готова у стены,

И лег на латы блик истаявшей луны.

Вставайте, в очаге взыскует пламя пищи,

Голодный пес внизу по закоулкам рыщет.

Встать по разные стороны барьера любезно согласились признанные профессионалы отрасли Вячеслав Панкратов и Асхат Уразбаев. Противники Agile против сторонников. Уразбаев против Панкратова. Одна эта битва гигантов стоит целой конференции.

Вырвите мне язык, но я должен это видеть!

К сожалению, мне не светит место в зрительном зале. Мне предложили встать между дуэлянтами. А я опрометчиво согласился.

Сергей Мартыненко aka SALar

Март 6, 2009

60. В копилку эпоса разработчиков

Не умилюсь

от мурчанья котов,

Не нужно мне птичьих трелей.

Я - программист,

Я работать готов

Даже под взвизги дрели!

(с) Геннадий Алпаев

По мотивам "{Боец не заметил потери отряда}" сделали перепевку.

Задержки зарплаты, ночная работа

Ведущий сказал: "Да -сь все конем!

Мне сына увидеть сегодня охота!"

И кинул гендиру заяву на стол.

Проект не заметил потери бойца

И софт дописать все хотят до конца.

Да вот незадача: не знают бойцы,

Какой к компонентам был сделан API.

Бойцов беспокоит резонный вопрос:

"Неужто с собою он спеку унес?"

Аукали в аську, почтой слали запрос.

Увы! Архитектора кризис унес.

ПМ-у от рода годка двадцать два,

Сказал, он свозь зубы, роняя слова:

"Без спеков, что делать поведает жизнь.

XP запрещает о спеках тужить.

Ребята, долой промежуточный слой

И лазайте в базу грязной рукой.

Короче, забейте на эти места.

По кубиклам, братцы! Аллюр, три креста!"

Без праздников, отпуска и выходных.

Больные гастритом, не видят родных.

Идет как в угаре за месяцем месяц,

Но юзер конечный их хочет повесить.

Релиз неудачный и вот наконец

Терпенью клиента приходит конец

"Вы сроки сорвали, и прут косяки", -

Заказчик взревел: "Пошли вон, му-жики!"

Одна для меня в этой буче отрада:

Седую былинку смахнувши с лица,

Боец не заметил потери отряда

И "Яблочко" - песню допел до конца.

(с) Геннадий Алпаев, Петр Федин, Сергей Мартыненко

Март 20, 2009

61. Переписка по багу

Запрос.

Флеш нужно убить. Сайт, грузящий процессор на 100% по определению не может быть

профессиональным.

Машинка: Целерон 2800, 1Gb RAM.

100% загрузка процессора в IE & FF

Ответ.

Баннер заменили.

Запрос.

Баннер заменили. Проблема осталась.

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

это проще, чем делать сайты не требующие монструозных ПК.

Апрель 22, 2009Один комментарий

1. karkadil написал: 22 Апрель 2009 в 11:24

На одном моем прошлом месте работы был такой случай.

4 года висела бага в статусе Verified, т.е. программеры подтвердили, что это бага, но фиксить не торопились. У нас регулярно на этом баге падали автоматические скрипты, но так как бага есть - мы просто эту ошибку пропускали. И вот однажды эта бага сама по себе закрылась. Как выяснилось, 4 года - это был именно тот срок, после которого бага закрывалась, считаясь устаревшей. Но у нас скрипты-то продолжали падать!

Недолго думая была создана новая бага, точная копия старой (переоткрыть закрытую было невозможно). Программеры почесались, сказали "ну пусть висит еще 4 года, а там видно будет!".

62. Продавец, извините за выражение, консультант

- Могу я вам чем-нибудь помочь?

- О, да конечно. Я хотел бы потратить немного денег в вашем магазине. Давайте попробуем?

- Что вас интересует?

- Сейчас я хотел бы приобрести себе домой приличный монитор, а заодно присмотреть что-нибудь на работу под тачпанель. Вон у того монитора какая матрица?

- ЖК.

- Про ЖК я понял, матрица какая?

Пауза. Некоторое время ищется суперВедущийМегаКонсультанДо-главноПродавец.

- TFT! - На лице гордость. Еще бы! Удалось ответить на такой неимоверно сложный вопрос.

- Я в курсе, что TFT. Матрица спрашиваю какая?

Недоумение, обида. Вся скорбь угнетенного пролетариата отражается на лице.

- А какие бывают?

Забавно. Неужели за время профессиональной деятельности нельзя догадаться, что продукция отличается не только ценой?

- Так, про мониторы я все понял. Замнем для ясности. Про панели видимо тоже. О кей, раз уж я все равно потратил свое время давайте я хоть вот эту фитюлинку куплю.

- Извините, мы не можем ее продать.

- !?!? Это что раритет? Музейная ценность? Любимая игрушка шефа? Или сексфетиш вашей команды?

- Нет. Просто количество этого товара у нас в системе равно минус единице.

- Господа. Слушайте внимательно. Я покупатель. Я хочу потратить немного денег. Вот товар, вот деньги. Вот цена, вот касса. В чем проблема?

- Ну понимаете…

- Все, все. Я понял. "Уважаемые покупатели, не мешайте продавцам работать."

И так постоянно.

Попытка получить консультацию по электроплите у продавца, извините за преувеличение, консультанта по электроплитам оканчивается полным фиаско. Во всем огромном магазине нет ни одного сотрудника, знающего значение термина "класс энергопотребления".

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

Июль 13, 2009

Комментариев: 4

1. karkadil написал: 14 Июль 2009 в 16:18

Это ты не в Эльдорадо, случайно, заходил? [:)]

2. Nocturobus написал: 14 Июль 2009 в 22:21

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

3. SALar написал: 15 Июль 2009 в 12:29

> Это ты не в Эльдорадо, случайно, заходил?

Это обобщение по разным магазинам. А что, Эльдорадо чем-то отличается от остальных?

4. karkadil написал: 16 Июль 2009 в 14:25

> Это обобщение по разным магазинам. А что, Эльдорадо чем-то отличается от остальных?

Как по мне - не отличается, но именно на Эльдорадо в свое время гнали очень много, рассказывали кучу историй и т.п. Анекдот.ру 3 года назад просто пестрил подобными историями. Но то было тогда. А сейчас-

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

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

63. Универсал vs узкопрофильного специалиста

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

------------------------------------

Вы работаете управляющим малого предприятия (до 10 человек). У вас в подчинении есть бригада строителей. Они делают заборы для садовых товариществ. Зарплата у них сдельная, и филонить им смысла нет. Приемку производит заказчик. Так что вы за работой бригады не следите. Ваше дело - логистика материалов, прием/увольнение, договоры, выдача зарплаты и прочая. Есть у вас так же бригады водопроводчиков, электриков, но о них речь в задаче не пойдет.

Речь пойдет о бригаде заборостроителей называющих себя «Стрела». Для упрощения задачи предположим, что:

• С материалами никаких проблем нет. Всегда все на месте и вовремя.

• Брака не бывает. Никогда и никак.

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

• Пока не выполнен один заказ, другой заключить не получится. Такие уж порядки в товариществе «Жаворонки». Да и в остальных тоже. И нельзя взять два контракта в двух разных товариществах. Контракт всегда только один.

• Отклонений в производительности тоже нет. Как делали парни два месяца назад 100 погонных метров в день, так и сейчас делают.

• Парней четверо, и они кросфункциональны. Каждый делает все операции, и они одинаково производительны.

Может и есть разница, но выявить ее не получается.

И тут вас познакомили с бригадой узких специалистов (с названием «Клинок»). У них каждый делает только одну технологическую операцию. За счет узкой специализации делают ее в полтора раза быстрее, чем парни из «Стрелы». Работать они хотели бы все вместе, потому как живут в одном районе и ездят на работу все вместе на машине бригадира, скидываясь на бензин. Поскольку новые парни более производительны, они, скорее всего, и запросят больше. И вот перед вами, как перед руководителем встает нелегкий вопрос. Дело в том, что у вас в фирме может быть не более 10 человек, а так как все места уже заняты, то либо одна бригада, либо вторая. А расставаться со старой бригадой не очень хочется. Но после окончания работ в «Жаворонках» у вас может нарисоваться контракт с «Рассветом». А они больше «Жаворонков» и хотели бы видеть большую скорость работы. В дополнение к большему объему работ «Рассвет» готов платить на 10% больше за погонный метр, если скорость будет от 120 метров в день. Что очень выгодное предложение. Пробный контракт с «Рассветом» показал, что "Стрела" все так же делает 100 метров и 10% премии с ними не видать. И учтите. Ваше начальство говорит, что «Бизнес это бизнес и сантименты тут неуместны. Успешных бизнесов мало, а управляющих много, и сменить одного на другого дело нехитрое».

Вопросы к вам:

1. Готовы ли вы принять на работу «Клинок», расставшись со «Стрелой»?

2. Если вам не хватает данных для принятия решения, то каких?

3. Если вы ответили на первый вопрос положительно, то в каком диапазоне зарплат вы готовы торговаться (ответ в процентах)?

4. Если ответ отрицательный, то почему.

Дополнительные вопросы.

Пусть, 1000 у.е. за сто метров делилась как 350 за материалы, 350 бригаде и 300 фирме. Клинок запросил 450 в день.

5. Сколько в день будет иметь фирма с «Клинком» в «Жаворонках».?

6. И сколько в «Рассвете»?

------------------------------------

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

Май 23, 2009

Комментариев: 9

1. mikhail.balashov написал: 29 Июнь 2009 в 15:27

Я "сварщик ненастоящий", но задачку с позиций чайника в этом деле решал бы так:

Сначала оценка "экономической выгоды" (в. 5 и 6) - В "Жаворонках" фирма с "Клинком" будет иметь 1500 - 450 - (150*350/100) = 525, а в "Рассвете" на 150 баксов в день больше за счет премиальных. Вроде бы все выгодно, по сравнению с 300-ми у "Стрелы".

Но далее нужно оценить "риски". Для этого хорошо бы знать размеры неустойки при задержках в строительстве забора (п. 2). Если неустойки нет, то нужно оценить потери производительности при отсутствии одного из членов команды. Положим, что один работник может попросить (не будем заморачиваться с ТК) один день в месяц по причине болезни и т.п. Для "Стрелы" это выразится в потере 25% производительности на этот день (все работники - многостаночники), а вот для клинка - это полностью потерянный день. С учетом, что работников 4, то "Стрела" теряет один рабочий день в месяц, а "Клинок" - 4.

Здесь же нужно учесть проблемы транспортного характера - в случае задержки одного из участников "Стрелы" мы опять же имеем падение производительности на 25%, а с Клинком - 100%, причем не только из-за того, что они все вместе едут, но и потому, что без одного работать не смогут.

Еще два риска, которые можно обозначить, но я не могу оценить количественно - это изменение географического положения - вдруг "Клинку" будет слишком долго ездить на очередной объект, в то время как из "Стрелы" кто-то да будет добираться на работу "вовремя".

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

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

2. SALar написал: 5 Январь 2010 в 16:36

Решение типичное, но неверное. Похоже это антипатерн управления.

3. AvA написал: 9 Октябрь 2010 в 12:20

2. Не хватка данных для принятия решения:

а) Ограничение - "Контракт только один и нельзя взять второй параллельно", частично "убивает" преимущества узкой специализации, отсюда вытекает вопрос : Сколько метров забора надо сделать для выполнения одного контракта, укладываются ли рабочие в один день?

а.1) Если нет, то для одного контракта весь забор находится в одном месте или в разных ? (этот вопрос основан также на том утверждении, что едут все вместе и работают вместе).

а.2) Если да, то сколько ям за день (на 100 метров) нужно выкопать?, Так как при возникновении ситуации, что первый уже закончил копать, а четвёртый ещё не начала прибивать доски (если ям мало) + все едут в одно время и работают в одном месте, вообще сводит преимущества специализации к нулю (а то и в минус).

Прибавляем риски (заболевания, новая неизвестная команда..). Решение вынести сложно.

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

Вторая явная выгода от узкой специализации: Скорость выполнения (оптимизация) каких-то одних своих работ.

Третья явная выгода от узкой специализации: Она стоит того, если работы сами по себе не равны по значимости, например, труд физический и интеллектуальный. Тогда важным решением станет правильно распределить людей по местам, и основной риск — это лажа ответственного (долгая болезнь или ещё чего-нить), в то время как при "универсалах", если налажает один или два, из скажем 10-ти человек, то вполне могут поставить под удар весь проект.

В задаче с помощью ограничений убраны 1-я и 3-я выгоды узкой специализации, поэтому решение этой задачи не может служить поводом к тому, чтобы ставить под сомнение правильность разделения труда, например, в тестировании. Для таких действий нужны другие поводы. [:)]

4. SALar написал: 11 Октябрь 2010 в 10:20

> В задаче с помощью ограничений убраны 1-я и 3-я выгоды узкой специализации, поэтому решение этой задачи не может служить поводом к тому, чтобы ставить под сомнение правильность разделения труда, например, в тестировании

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

5. abursuk написал: 10 Декабрь 2010

Добрый день. Публиковать мой комментарий или нет, предоставляю вам это решить.

Постараюсь ответ строить по ходу заданых вопросов:

1. Нет.

Потому, что выгода в них сомнительна. в Жаворонках они будут приносить фирме ровно столько же, сколько и Стрела. В Рассвете будут приносить на 60 расчетных единиц в месяц (на 10% больше нежели Стрела), но это при условии, что они будут стопудов 150метров в день делать. Из задачи ясно, что я их не знаю, следовательно, я не могу полагаться на них, потому, что если они, допустим, месяц будут работать на грани премии, но не получать (119 метров\день), то им придётся два месяца работать по 150 метров в день, чтобы нормализировать потери и прийти на один уровень со Стрелой. В своих парнях я уверен, а значит я могу спать спокойно и не просыпаться ночью в холодном поту, что Клинок меня подставит в плане продуктивности\сроков.

Тут вопрос другой, критично ли для Рассвета делать 120 м\день или это просто мотивация. Я очень надеюсь, что не критично, исходя из этого я строил свои предположения.

6. greyver написал: 20 Февраль 2011 в 17:53

Не хватает данных о времени каждой операции.

Взял бы Клинок с некоторыми оговорками.

Рассуждение такое: Стреле нет смысла работать, как и Клинок, и за счет универсальности они могут делать все работы разом. За счет этого различия по времени для каждой операции не играет роли, так как они могут работать вместе и не простаивать. Для Клинка операция с максимальным временем является «бутылочным горлышком». Таким образом, надо рассматривать производительность Клинка как бригаду, а не как отдельных специалистов. Производительность Клинка ниже 100 метров в день рассматривать не будем. Максимальная возможная производительность Клинка будет 150 метров в день, когда время всех операций равно.

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

В Рассвете работа с Клинком нам ещё интересна за премии, но только при производительности от 120 метров. Учитывая эту перспективу, попробуем получить цифры. Предположим, что за 100 метров от заказчика получаем 1000 уе. Распределим их как в доп. вопросе: 300 фирме, 350 за материалы и 350 бригаде за 100 метров. За работу Клинка в Жаворонком от заказчика можем получить от 1200 до 1500 уе в день.

Фирма должна получать от Клинка не меньше, чем имеет сейчас со Стрелой (в левой части неравенства)

300

7. greyver написал: 28 Февраль 2011

Мой ответ здесь опубликован не полностью: не учел, что html обрабатывается.

Весь ответ здесь - {http://dl.dropbox.com/u/14203637/universal_vs_specialist.doc}

8. kass101 написал: 15 Апрель 2012 в 15:38

Не хватает данных о том, сколько времени занимает каждый из этапов.

Первый крайний случай. Все этапы занимают одинаковое время.

"Стрела" делает 100 метров в день, все работники работают одновременно (не важно, чем каждый занят).

"Клинок" при условии, что все работники будут работать одновременно, сделает 150 метров в день.

Все работники "Клинка" смогут работать одновременно только если каждый из этапов (яма, столбы-.) будет занимать одинаковое время. Тогда (не считая первого столба) работники смогут работать одновременно и выполнят работу в полтора раза быстрее. Следовательно, нанимать их выгодно.

Другой крайний случай. 3 этапа занимают по 1/1000 времени, а оставшийся - 997/1000.

Тогда произойдет "затор". Производительность будет измеряться по самому долгому этапу. В этом случае "Клинок" брать не выгодно.

9. SALar написал: 16 Апрель 2012

2kass101

А как все это соотнести с жизненным опытом?

> Не хватает данных о том, сколько времени занимает каждый из этапов.

Берите из опыта.

PS из 2023 года. Задача оказалась дико сложной для менеджеров. На моей памяти ее решили 5 человек из примерно пяти сотен. И то не полно. Единственный человек, который решил задачу, не дослушав условия был ветеринаром без опыта управленческой работы. Как-то так. Задачи по управлению хуже всех решают менеджеры?

АСУ - Автоматизированная Система Учета

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

* Какие управленческие решения будут приниматься при помощи этой системы?

* Каким образом руководство будет использовать эту систему для принятия управленческих решений?

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

Июнь 4, 2009

Один комментарий

1. Chuvi написал: 19 Июнь 2009

Я бы считал системы, которые только хранят, обрабатывают данные и предоставляют скажем отчеты и т.п. (на основе которых уже кто-то будет принимать решения), системами учета. А вот системы, которые (с помощью которых) выполняют непосредственное управление неким процессом (частями процесса) по некоему алгоритму - системами управления.

64. О влиянии обязательности на экономию

Отрывок из книги Цветова В.Я. "Пятнадцатый камень сада Рёандзи". Книга, кстати, неплоха.

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

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

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

- Чем же вы собираетесь кормить кур завтра? - не унимался я.

- Завтра корма привезет господин Хосода. Он специализируется на них, - сказал крестьянин.

- А если не привезет? - предположил я.

- То есть как не привезет? - переспросил крестьянин с интонацией, будто я усомнился в неизбежности восхода солнца.

- Ну, вдруг умрет! - решил я смоделировать экстремальную ситуацию.

- Жена господина Хосоды привезет. - Крестьянин говорил со снисходительной уверенностью гроссмейстера, разбирающего для любителя шахматную партию.

- Жена будет хоронить мужа! - стоял на своем я.

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

- Сын уедет на похороны тоже!

- Сосед господина Хосоды привезет.

- У вас, что же, такой строгий подписан контракт с господином Хосодой? - спросил я.

- Зачем нам контракт? - удивился крестьянин. - Господин Хосода, - разъяснил он, - пообещал мне привозить корма каждый день.

- Ладно, - сдался я, но вспомнил, что в хозяйстве нет помещения для хранения и готовой продукции - яиц, и поинтересовался причиной этого.

- Оптовая фирма забирает, - ответил крестьянин и, предвидя мои следующие вопросы, добавил: - Забирает каждый день и никогда не подводит. Забирает тоже без контракта.

Отношения, определяемые чувством "гири", оказываются в Японии прочнее, чем писаные контракты. Во всяком случае, подобные отношения с успехом заменяют контракты. И в промышленности тоже. На автомобильном заводе фирмы "Ниссан", выпускающем 420 тысяч машин в год, комплектующих частей имеется на два часа работы конвейера. Смежники привозят эти части с точностью плюс - минус два часа, и на заводе не помнят, чтобы конвейер останавливался. Благодаря отсутствию складских помещений и рабочих, занятых в них, японские автомобилестроители экономят на издержках производства в расчете на одну машину в среднем 94 доллара.

Июль 9, 2009

65. Как уменьшить производительность отдела, увеличив численность

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

------------------------------------

Жила была команда программистов. Для простоты предположим, что они не выполняли никаких работ, связанных с аналитикой, архитектурой, GUI и написанием технической документацией, т.к. писали они расчетные модули и всю аналитику, и описание API им спускали сверху. И было их 8 человек. Нормальная такая agile команда. Надо сказать, что модуль расчета квартплаты или трафика сотового оператора - вещь сложная и закодировать это дело без ошибок удается редко. Я бы даже сказал, исчезающе редко. Соответственно, тестированием тоже приходилось заниматься. И тратилось на тестирование половина времени программистов. Иногда больше, иногда меньше. Естественно, что такое положение дел никого не устраивало. Но узнало начальство, что в деле тестирования тестировщики более производительны, нежели кодировщики. Для простоты будем считать, что в два раза [1]. Другими словами - один тестировщик в деле тестирования двух программистов накормит. Прошу прощения, заменит.

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

А что стало с общим выхлопом отдела? Ведь не просто так все затевалось.

Элементарный расчет показывает, что совокупный выхлоп отдела упал в два раза. Вдумайтесь в это. Был принят еще один человек, т.е. увеличены расходы, и - И производительность отдела сократилась вдвое. Опана.

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

А объяснение простое. Некомпетентность руководства (незнание основ управления производством) привело к тому, что сочетание факторов:

Положение "каждый занимается своим делом" Несоответствие между соотношениям трудоемкостей операций и обеспечением сотрудниками. привело к катастрофе. Скажете так не бывает? Еще как бывает. Встречается сплошь и рядом [2].

Что можно сделать в данной ситуации. Про курсы повышение квалификации или замену руководство все понятно. А что хороший руководитель должен сделать?

Вариантов решения несколько.

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

2. Нанять еще тестировщиков. Кстати, вопрос к знатокам. Сколько должно быть тестировщиков с учетом рисков заболевания/увольнения и девиаций трудоемкостей от проекта к проекту?

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

------------------------------------

[1] Мои наблюдения показывают, что скорее в 3-5 раз.

[2] Падение выхлопа из-за безграмотного управления всего в два раза - это еще отличный результат. Даже падение в 10 раз не редкость.

Июль 16, 2009

Комментариев: 4

1. {astenix} написал: 16 Июль 2009 в 13:56

Сколько должно быть тестировщиков с учетом рисков заболевания/увольнения и девиаций трудоемкостей от проекта к проекту?

Если учесть указанный размер команды, то не меньше двух [;)]

2. SALar написал: 16 Июль 2009

> Если учесть указанный размер команды, то не меньше двух.

Неверно. В этом случае выхлоп команды будет чуть меньше, чем до принятия тестировщиков.

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

3. Little_CJIOH написал: 16 Май 2016 в 20:30

4 будут успевать за 8 разработчиками, при этом выхлоп команды "должен" удвоится.

5-й даст возможность "проглатывать" всплески загрузки, отпуска и больничные, но не одновременно. Только отпуска дадут уже 5 месяцев работы команды тестирования на пределе. и в эти 5 месяцев не будет защиты от больничных. Хотя, 7 месяцев в году разработчиков будет не 8, а 7.

Но все-равно, чтоб совсем надежно и с возможностью работать на развитие и опережение их должно быть 6.

4. SALar написал: 17 Май 2016 в 15:37

2Little_CJIOH

Пятый тестировщик дает запас прочности как раз в те самые 20-25%. Достаточен ли такой запас или нет - зависит от необходимой скорости обратной связи. В большинстве случаев будет достаточно.

66. Теория ограничений и линейное программирование

В прошлый понедельник, 3 августа произошло замечательное событие. Стас Фомин нашел ошибку в решении Голдратта. (Задача на оптимизацию производства в разных вариантах).

Как говорит сам Голдратт, он давал эту задачу тысячам менеджерам и только один из сотни мог решить ее правильно.

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

Отчет, видео: http://team.custis.ru/2009/08/blog-post_06.html.

Мои искренние поздравления Стасу.

Август 10, 2009

67. Супер фича

Почти что дарю идею.

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

То-то народ обрадуется! Аж просто рад будет до безумия. А бабок сколько можно получить!

Ну и продолжая идею.

Ведь можно же вместо сигнала дозвона по сотовому транслировать: "Лох скоро будет на связи". Снимать такой гудок опять-таки за деньги. Скока радости у изобретателей "гудка" и "хамелеона" будет!!!

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

Не. В электричках за такой плакат можно и в торец получить.

Ах, как жаль, что мы, интеллигентные, высококультурные люди не пойдем встречать в темном переулке изобретателей "Гудка" и "Хамелеона". Как было бы классно подойти, имея десятикратное численное преимущество и сказать огромное, просто-таки нечеловеческое спасибо!!!

Но не пойдем.

Пока.

Пока что плодитесь и размножайтесь изобретатели и "Гудка", и "Хамелеона". И прочая, и прочая, и прочая.

ЗЫ. Впрочем, есть варианты.

Декабрь 4, 2009

68. Вторичные эффекты материальной стимуляции

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

Пример 1. Вот, например, пересматривая старый добрый советский фильм "Деревенский детектив": https://www.youtube.com/watch?v=MVlHRgv_hK0c 28:00

Фактический результат совсем не соответствует запланированному. А подумать перед внедрением? Минут десять? Можно даже пять.

Пример 2. В некой фирме решили сделать месячную премию зависимой от завершения проекта. Завершен проект в отчетном месяце - есть премия, не завершил (проект трехмесячный) - нет премии. Как вы, наверное, догадываетесь, все проекты вдруг стали одномесячными или меньше. У многомесячного проекта не было даже шанса начаться. Его или неоправданно били на кучу частей, резко удлиняя срок, или отфутболивали методом изобретательных итальянцев. Естественно, зачем делать полезный для фирмы проект, но лишать себя премии, когда можно сделать бесполезный и премию получить. Логично?

Пример 3. В некой фирме решили выбирать лучший отдел и вручать ему месячную премию. Для определенности зададим структуру фирмы.

Есть несколько отделов разработки ПО. Есть отдел технических писателей Есть отдел маркетинга Есть юротдел Есть отдел дизайна Есть отдел системного администрирования (а куда ж без него) Ну, и пусть будет отдел тестирования Есть еще отделы, но они не участвуют в проектах Над каждым проектом работает 2 и более отделов. Как правило 4-5.

Кстати, вопрос к знатокам стимуляции и мотивации. Каковы будут вторичные эффекты такой месячной премии?

Август 22, 2009

Комментариев: 2

1. Little_CJIOH написал: 6 Сентябрь

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

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

2. SALar написал: 7 Сентябрь 2016

Материальная демотивация - страшная вещь.

69. Пример отчета по тестированию

При написании отчета следует понимать: Кому отчет? Зачем? Что на его основании будут делать?

Как правило ЛПР (лицам, принимающим решения) требуются ответы на следующие вопросы:

1) Это можно продавать/устанавливать или нужно доработать/выкинуть?

2) Какова степень уверенности?

3) Как называется то, о чем идет речь?

Напишем отчет в виде краткого резюме по текущему состоянию продукта.

-----------------------

Продукт СМФ (проект "Банзай"), версия 158/32ф.

Было выполнено 60% тестов из запланированных. Тестирование было прекращено ввиду большого числа ошибок, закрывающих доступ к тестированию.

В настоящий момент полностью неработоспособны 18 из 150 юзкейсов.

Полностью неработоспособны 3 из 45 критически важных юзкейсов.

Работает с оговорками 93 юзкейса.

39 юзкейсов реализованы хорошо.

Я не рекомендую поставку данной версии клиентам. Версия ограничено пригодна для ознакомления с возможностями программы. Оценочное время готовности продукта: декабрь - 30%, февраль - 70%. Полагаю, нам не стоит приурочивать рекламную компанию к рождеству.

Отчет подготовлен 17 сентября сего года лидером тестирования проекта "Банзай" имярек.

-----------------------

Повторюсь.

Кому отчет? Зачем? Что на его основании будут делать?

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

Так, например, метрики:

связанные непосредственно с ошибками (по статусам/приоритетам и т.д.),

скажут что-нибудь только тому человеку, который прекрасно понимает процесс. А, например, менеджеру по продажам не скажут ничего. Т.е. вообще ничего.

- У нас в этой версии остались неисправленными 15 важных, 78 маловажных ошибок.

- А сколько должно быть? Вот я слышал, что продукт Х был выпущен с несколькими сотнями тысяч известных неисправленных ошибок. И очень успешный продукт. А тут всего 93. Так выпускаем или нет?

Человек же, который понимает процесс и в нем участвует, должен быть подключен к системе бактрекинга. Должен. Если он управляет процессом, то эту статистику он сам должен просматривать в этой системе с некоторой периодичностью. Не ему должны поставлять такой отчет, а он должен его и сам формировать, и сам просматривать, и сам принимать решения на его основе. Иначе какой же он руководитель?

Метрики

по времени решения/открытия, числу возвратов и т.п.

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

процент возвратов, среднее время исправления дефектов, с разбивкой по приоритетам, и т.д. [1] и не войдут:

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

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

Развивая тему дальше.

Мой опыт показывает, что список ошибок включать в отчет бессмысленно, его все равно никто из руководства не читает. Такой список хорош, только если работник не может быть подключен к системе бактрекинга. Например, из-за экономии денег генеральному директору или дизайнеру интерфейсов не купили компьютер [;-)] . [2]

------------------------------------

[1] По-хорошему тут бы карты Шухарта приложить. Но ими мало кто пользоваться умеет.

[2] Нечто подобное я имел несчастье наблюдать в одном из проектов. Небольшая экономия денег обернулась необходимостью распечатывать список ошибок и передавать его на бумаге. Со всеми вытекающими.

Август 22, 2009

Комментариев: 4

1. {Alexei Barantsev} написал: 24 Август 2009

Сергей, формулировка отчёта в терминах только чисел тоже не очень хороша.

Что значит "неработоспособны 3 из 45 критически важных юзкейсов"? Может быть руководство решит, что эти 3 не так уж критически важны, и можно выпустить продукт без них. Для этого ЛПР должны получить информацию, какие именно три неработоспособны.

2. SALar написал: 24 Август 2009 в 14:58

А вот с этим пожалуй соглашусь.

Не работает:

сохранение файловсправканеработоспособно разделение прав (работать можно только под root-вым аккаунтом)Изначально эти вещи даже были, но я их выкинул. Так лучше?

3. {Alexei Barantsev} написал: 24 Август 2009

Да, так лучше.

Однако следующий шаг - ЛПР захочет знать, кого спросить про эти три неработающие юзкейса? У кого узнать размер бедствия и прогнозы по исправлению ситуации? Либо мы включаем эту информацию (фактически часть описания дефекта и его текущий статус) в отчёт, либо даём ссылку и надеемся, что начальник сообразит, что есть что в этой дурацкой баг-трекинговой системе. Что лучше?

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

А является таким признаком наличие фактов, полезных для принятия решения. Для чего нужно общаться с ЛПР, чтобы научиться понимать, какие факты могут быть им полезны. А не клепать отчёты всегда по единому шаблону.

4. {Alexei Barantsev} написал: 25 Август 2009

70. Предпроектная гигиена

Начну я с короткого экскурса в историю сестер милосердия.

Флоренс Найтингейл разработала собственный метод, который был максимально прост и максимально эффективен:

чистота,свежий воздух,хороший уход,режим питания.И все это начало творить настоящие чудеса-

В октябре 1854, в период Крымской кампании, Флоренс вместе с 38 помощницами, среди которых были монахини и сестры милосердия, отправилась в полевые госпитали сначала в Скутари (Турция), а затем в Крым. Последовательно проводила в жизнь принципы санитарии и ухода за ранеными. В результате менее чем за шесть месяцев смертность в лазаретах снизилась с 42 до 2,2%.

Википедия и http://www.marfa-ka.ru/publ/1-1-0-34

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

1. Нет концепции - нет проекта.

Перед проверкой наличия концепции из нее должны быть удалены обороты-паразиты: "очевидно", "это нам почти ничего не стоит", "сокрушительный успех", "огромное значение для нас", "развитие стратегического направления" и прочее. Если после этого от концепции осталось менее 50% - можно считать, что ее нет (нужно писать заново).

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

Что делать, если концепции нет, а проект запущен? Если вы болеете за судьбу фирмы, у вас есть следующие варианты: написать концепцию самому или саботировать проект (шучу).

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

Что делать, если никто не умет писать концепцию? Это означает, что у вас нет человека, способного выполнять роль "Управляющий продуктом (product manager)". А что будет, с софтверным проектом, если, например, у вас не найдется людей способных писать код? Загнется? Так без концепции он загнется еще вернее. Найдите того, кто умеет. Можно на работу по договору. Такие люди точно есть. Даже, как ни странно, в России. Я точно знаю, что есть. Я с ними даже общался.

2. Нельзя делать оценку трудоемкости до оценки прибыли.

Этот момент, скорее всего, вызовет массу споров. И все-таки, советую действовать именно так.

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

Приведу аналогию со строительством. Для того чтобы оценить стоимость (осметить проект) нужно потратить 3% от стоимости проекта на осмечивание. И 15% до этого на проектирование. Т.е. нужно потратить почти пятую часть бюджета только для того, чтобы узнать стоимость проекта. А грубо оценить продажи квартир в 300-квартирном доме на острове Пасхи можно. Стремятся к нулю. На острове Пасхи проживает всего 3,7 тысячи жителей.

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

Если вы болеете за судьбу фирмы, у вас есть следующие варианты: посчитать прибыльность самому (до расчета стоимости) или саботировать проект (шучу).

Вредные советы.

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

PS. Вышеизложенное сформулировано под впечатлением статей Ашманова.

Ноябрь 25, 2009

Один комментарий

1. {Алексей Лупан} написал: 25 Ноябрь 2009 в 18:45

Очень смачно.

71. Трудозатраты на тестирование

Эту статью я начал писать, когда мне предложили принять участие в опросе про соотношение программистов и тестировщиков. Я решил дождаться результатов и сделать развернутый анализ.

Ограничения задачи

Иногда считают, что на тестирование уходит до 40% времени проекта. При этом не совсем понятно, что имеют в виду под тестированием. Человекочасы присутствия тестировщиков и кодировщиков на работе? Тогда 40% - это очень, очень много. Виды деятельности, которыми занимаются инженеры? А отладку будем относить к тестированию? А создание тестовых сценариев?

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

аналитикиархитекторы-кодеры (программисты)техписыдизайнеры GUIтестировщикимного кто ещеОтнесем к затратам на тестирование все виды работ, которые выполняет отдел тестирования, а к затратам на программирование все виды работ, выполняемые отделом программирования.

Общетеоретическая часть.

Для начала рассмотрим только соотношение численности программистов и тестировщиков.

у нас есть два основных параметра, определяющих этот коэффициент:

1) критичность (сумма потерь от ошибок)

2) сложность системы

Критичность можно взять по Коберну:

1) человеческие жертвы

2) невосполнимые деньги

3) инвестиционные деньги

4) неудобство

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

Так ошибка в коробочном продукте бьет гораздо больнее, нежели если софт находится в своей сети. Поэтому при равной сложности и размере продукта у Яндекса и Ниваль, Яндекс может позволить себе меньше тестировщиков.Удар по репутации зависит от развития рынка. На заре поисковых систем, [сами знаете какая фирма] могла позволить себе выпускать откровенное фуфло (смотри "жизнь в пузыре" Ашманова). На сложившемся, но не монополизированном рынке такие фортеля уже небезопасны.Попробуем построить шкалу.

Для некритичных (4), несложных крохотулечных систем (до 1 человекомесяца, нормальное соотношение 100:0. И именно поэтому сайты-визитки делаются без тестировщика (как правило).

На другом конце шкалы находятся продукты НАСА (1 уровень критичности). По слухам, у них тестировщиков в 5-10 раз больше, чем кодировщиков. А учитывая уровень документирования, полагаю, что кодировщиков на проекте едва ли 5%.

Опять же по слухам, в Микрософте на одного программиста два тестировщика.

Для коробочной системы какой-нибудь автоматизации среднего размера (20-50 человеколет) хорошим соотношением будет от 4:1 до 3:2 (в человекомесяцах)

Всякие разные нюансы.

Плюс к этому куча разных нюансов. Например, какой тип софта? Или как назвать роль создателя юнит тестов для компилятора командной строки? Другого тестирования там нет, но кто это? Программист или тестировщик? А если тестировщик, то почему он С++ знает гораздо лучше подавляющего большинства ведущих программистов в других фирмах? А кто выполняет роли аналитика, техписа (они выделены или нет)? Будучи формально тестировщиком, я писал и/или верифицировал стандарты кодирования, проектирования интерфейса, писал проектную документацию (концепцию, SRS, словарь проектной области). И куда отнести эти виды работ?

Неправильная интерпретация.

Предположим, что в октябре 2009 года на проекте SuperSMS тестировщики отработали 400 часов, а программисты 600. Из этого иногда делают вывод, что трудозатраты на тестирование составляют 40%. Этот вывод глубоко ошибочен.

Пусть этот проект длился с июля по октябрь. Трудозатраты на проект составили в разбивке по месяцам июль/август/сентябрь/октябрь:

Управление - 200/200/200/200 Инфраструктурные работы (эникейщики) 100/20/20/10 Постановка процессов, стандарты и прочее (отдел QA) 100/0/0/50 Анализ 400/200/100/0 Дизайн и верстка (отдел дизайна) 300/100/50/50 Программирование 600/600/600/600 Тестирование 50/50/400/400 Создание пользовательской документации 0/0/200/200 И в такой раскладке, когда мы учли работу всех отделов, трудозатраты на тестирование стали несколько меньше. А ведь есть еще работы, предшествующие запуску проекта, и это очень немаленький процент. Но даже если их не учитывать, получается:

Тестирование: 900/(800+150+150+700+500+2400+900+400) * 100% = 15%

Программирование: 2400/6000 * 100% = 40%

И это разумный результат, хорошо согласующийся с наблюдениями.

Что еще полезно знать при планировании трудозатрат.

Пусть вышеприведенные цифры - это истинные потребности. Если бы мы жили в вымышленном мире RUP-а или PMBOK-а, то имело бы смысл закладывать именно такой бюджет. Однако, как говорил Морфеус: "Добро пожаловать в реальный мир". В реальном мире случаются девиации (отклонения). Кто-то может заболеть. Или решаемая задача окажется проще, чем оценивали изначально.

В реальном мире рекомендуют сделать ограничением самый дорогой участок, добавив остальным участкам запас мощности (еще можно заложить буфера, но тогда проект вместо 4 месяцев будет длиться 2-3 года). В нашем случае это отдел программирования. А вот остальным отделам нужно запланировать бюджет побольше. Точная цифра зависит от величины девиаций, от стоимости задержки проекта и от относительной стоимости каждого отдела. Для самых дешевых участков нужен наибольший запас мощности. Предположим, что правильный запас мощности 30% для всех отделов, кроме программирования.

В этом случае получаем:

Тестирование: 1170/(1040+ 195+195+910+650+2400+1170+520) * 100% = 16,5%

Программирование: 33,9%

PS.

Что любопытно. На деловой игре по управлению регулярно наблюдаю, как люди пытаются сделать бутылочным горлышком самый дешевый отдел. Естественно это приводит к огромным финансовым потерям. Но объяснить причину феномена я пока не готов.

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

Ноябрь 12, 2009

72. Решение кейса "Менеджер из не пойми кого"

Кейс предложен Александром Орловым на его проекте happy-pm (сайт умер, ищите в «машине времени» или https://eagleson.livejournal.com/213984.html). Там же можно посмотреть решения других участников (можно было до смерти сайта).

Моё первое решение.

Проблема в этом кейсе на более высоком уровне.

Ольга становится юниор-менеджером. Очень хреново, но остальные еще хуже. Сергей - ведущий программист.

Вызываются оба и далее говорится:

Ты, Сергей, очень ценен для нас именно как программист. Ты получаешь условно 100 у.е. Ольга, как юниор-менеджер будет получать 50 у.е. Сможет вырасти как менеджер - ее зарплата лет через пять твою догонит. Возможно. Скорее всего не догонит. Но если хочешь, можем тебя, Сергей, сделать менеджером. Не вопрос. Будешь получать 40 у.е, пока не выучишь английский. Потом будешь получать 60, пока не научишься руководить. Года через 3-4 будешь получать как сейчас. И, в общем, все. Конфликта нет. Остаются проблемы слабого менеджера, но и они решаются. К Ольге ставится куратор на 6-18 месяцев.

В этом решении я откинул следующие устойчивые стереотипы присущие отечественным командам:

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

В команде Игорь выполнял сразу несколько ролей:

Технический лидер Менеджер продукта (продакт онер если хотите) Администратор Возможно, хотя и маловероятно, что он был наставником С его уходом все эти роли повисают. А теперь разрушим еще один стереотип. С какой радости все эти роли должен выполнять один человек? Разбросаем их, держа в голове условие максимизации продуктивности команды.

Технический лидер - явно Сергей или Федор. Менеджер продукта - Ольга. Плохо, очень плохо. Но остальные в разы хуже. Значит грядущий год у Ольги должен быть посвящен повышению навыков аналитика. Администратор. А зачем он такой маленькой группе? сть эти функции выполняет руководитель, у которого в подчинении 15-25 человек. Если промежуточного звена нет - то это технический директор. В его отсутствии - генеральный. Не нужно плодить лишние уровни иерархии. Наставник. Искать вне группы. А может и вне фирмы. Сентябрь 17, 2009

73. Шестой способ ответить на нечестные вопросы

По мотивам: http://www.yatester.ru/2009/09/5-sposobov-otvetit-na-nechestnue.html. Получилось немного злее, чем хотелось. А потому дисклаймер: "Диалоги вымышлены и конкретно к вашей фирме, дорогой читатель, это никак не относится."

Почему именно тестирование является «узким местом» проекта?Это вопрос к топ менеджерам. Это именно их вина, что наиболее дешевый участок стал бутылочным горлышком. За подробностями управления производством в сфере подверженной девиациям обратитесь к книгам Голдрата "Цель" и "Критическая цепь"

Почему у нас столько ошибок?Потому что:

1) мы не провели работу по предотвращению возникновения ошибок. Это вина ПМ-а.

2) Потому что квалификация и численный состав проектной команды не соответствуют масштабу проекта. А это вина опять-таки топ менеджера.

Что мы можем сделать, чтобы улучшить производительность отдела тестирования?1) Улучшить документацию. К аналитикам.

2) улучшить такой показатель качества проекта как "Тестопригодность". Смотри ГОСТ 9126 (25010) и сопутствующие документы. Это не к тестировщикам, это к постановщикам процессов (QA), архитекторам (от БД до GUI) и создателям стандартов (кодирования, проектирования GUI, проектирования БД и пр.)

3) Увеличить численность отдела тестирования и организовать наконец то курсы повышения квалификации для инженеров. К HR (бессмысленно – не умеют они) и топ менеджерам.

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

Правильный ответ: "Какого черта вы задаете эти вопросы лидеру группы тестирования?" Он то здесь причем?

Октябрь 14, 2009

74. Косвенная метрика уровня специалиста

Какова высота стопки книг, которые вы прочитали? Измерять в метрах. Для ведущего инженера этот показатель видимо от пяти метров. Действительно прикинем. 20-50 книг двухсантиметровой толщины в год и так 8-12 лет. Статьи, наверное, тоже можно как-то учитывать. Но 1000 статей на страницу не заменят одной книги на 300 страниц. Хотя и дополнят ее. Так что минимум половину высоты стопки должны составлять книги. И естественно часть литературы должна быть по смежным темам.

Ноябрь 14, 2009

Комментариев: 2

1. Julia Nechaeva: 16 Ноябрь 2009

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

Давайте введем ещё одну метрику: количество реализованных проектов.

2. SALar написал: 16 Ноябрь

> количество реализованных проектов.

Это другая метрика. Она не лучше, не хуже. Она просто другая.

Я к тому, что про прочитанную литературу:

Не спрашивают в тексте вакансииНе пишут в резюмеНе спрашивают на собеседованииИ совершенно напрасно.

75. К борьбе с должностными инструкциями, будьте готовы!

По мотивам и в продолжении «Менеджер по борьбе с персоналом», а также в продолжении цикла статей Владислава Балина "Защита от темных искусств".

В некой фирме

Может даже {UmaNetto}.

Появился вдруг сотрудник

По [борьбе] работе с персоналом

Чтоб ценить не перестали

выпускает циркуляр он

что трудиться нынче нужно

лишь регламенту согласно.

Разославши сей документ

По отделам бродит нынче

Очень строго наблюдая

Чтоб соседу не помог ты.

Долго, нудно вычисляет

КТУ и KPI

Чтоб потом цифирь зарплатна

Была сразу всем понятна.

Честно говоря, в должностных инструкция нет ничего плохого. Проблемы начинаются тогда, когда размер ежемесячной премии начинают привязывать к метрикам соответствия инструкции. Может быть такой подход и применим к грузчикам на сдельщине, но для knowledge worker это не подходит.

Предположим, что в софтверной фирме ввели жесткое правило следования инструкции и привязали зарплату к метрикам.

В январе к техническому писателю подошел маркетолог.

- Нам срочно нужно готовить раздатку к выставке. Как правильно написать: "Программа работает на всех компьютерах или под любыми операционными системами?"

- Оставьте текст, я внесу технические правки. Завтра утром будет в почте.

- Окей, пасиб.

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

Февраль. Техпис остался без премии. К тестировщику подошел программист и спросил:

- Я слышал ты в прошлом проводил исследования на время отклика при разных вариантах организации деревьев в БД?

- Проводил. Но если я буду об этом рассказывать вместо тестирования, меня лишат премии.

Наверное, Саша Орлов сделал бы из этого "пятничный кейс": "Как инженерам и премии сохранить и пользу фирме принести".

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

- Программист. И что думаешь?

- Тестировщик. Да есть одна мысль. Поможешь?

- Не вопрос.

- Тогда иди, пиши письмо.

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

От. Программиста

Кому. Руководителю разработки

Копия. Руководителю тестирования

Требуется помощь тестировщика для принятия решения о выборе архитектуры.

От. Руководителя разработки

Кому. Руководителю тестирования

Копия. Программисту

Это позволило бы существенно сократить время проекта и уменьшило бы проектные риски.

От. Руководителя тестирования

Кому. Техническому директору

Копия. Руководителю разработки

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

От. Технического директора

Кому. Генеральному директору

Копия. Руководителю программирования, Руководителю тестирования

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

1. Оставить как есть. Сроки проектов будут срываться, а проектные риски взлетят до небес. Полагаю, на то чтобы угробить фирму нам понадобится 6-12 месяцев.

2. Разрешим нарушение Инструкции конкретно в этом случае. Но подобные решения нам придется принимать по десятку раз в день. Что не очень эффективно.

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

4. Переоценим решение о зависимости зарплат и выполнении должностных инструкций. Техническому писателю принесем официальные извинения и начислим январскую премию в феврале.

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

А в жизни бывает по-разному. Очень по-разному-

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

Ноябрь 21, 2009

Комментариев: 3

. andviper написал: 22 Ноябрь 2009

"Предположим, что в софтверной фирме ввели жесткое правило следования инструкции и привязали зарплату к метрикам."

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

2. SALar написал: 22 Ноябрь 2009

Это из спама: «За что платить зряплату сотрудникам: практикум управленческих решений.»

*******************

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

Ключевые вопросы семинара:

a. Основные принципы решения «зарплатно-мотивационных проблем».

b. Ключевые требования к эффективной зарплатной схеме. Параметры, без которых зарплатная мотивация не работает.

c. Как зарплатная схема должна увязываться с должностными инструкциями сотрудников. Безболезненное внедрение новых зарплатных схем.

d. Особенности контроля работы сотрудников: что контролировать, когда контролировать, меры поощрения, наказания, пресечения.

e. Варианты зарплатных схем, поощряющие активных сотрудников и «вымывающие» лентяев. За что мы платим сотрудникам оклад: новые варианты привычной схем

Другой спам:

«Система оценки персонала. Аттестация как форма оценки потенциала работника».

Семинар предназначен для: руководителей и специалистов служб персонала, отделов кадров, руководителей и специалистов центров и отделов обучения персонала предприятий.

ПРОГРАММА СЕМИНАРА

Цели и задачи системы оценки персонала, ее место в управлении человеческими ресурсами организации.

Развитие персонала: взаимосвязь систем мотивации, оценки и управления карьерой.

Виды оценки персонала.

Современные формы и методы оценки персонала:

a. оценка кандидатов при приеме на работу;

b. оценка по результатам адаптации и прохождения испытательного срока;

c. оценка потенциала работника и работа с ключевыми талантами;

d. оценка труда: уровни, основные подходы, современные методы;

e. Центры оценки – современный метод комплексной оценки персонала.

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

Плюс еще вот это:

{http://edu.hh.ru/seminar/8227}

{http://edu.hh.ru/seminar/7678}

И с этими тоже все понятно.

А вот это серьезней:

{http://www.uml2.ru/forum/index.php?topic=1824.0}

{http://it4business.ru/forum/topic16093.html?hl=%EC%EE%F2%E8%E2%E0%F6%E8%FF}

Умные, взрослые люди, вроде даже не hr-ы , на полном серьезе обсуждают возможность привязки зарплаты к метрикам - Грустно. Радует только то, что я не одинок в своем протесте.

Помнится, на одном из семинаров тренер предложил штрафовать разработчиков за пропущенные дефекты. На полном серьезе. И ведь хороший спец был. Без дураков хороший. ISO и CMMI знал и внедрял. А тут так прокололся.

-------

Так что бывает. Бывает. Чаще чем хотелось бы.

3. AlexanderPopov написал: 23 Ноябрь 2009

понятно, что это крайность.

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

Вариант, когда:

Разрешим нарушение Инструкции конкретно в этом случае. Но подобные решения нам придется принимать по десятку раз в день. Что не очень эффективно.

Я так понимаю оптимальным тоже не назовешь. Так где же золотая середина?

76. Три причины не писать документацию

Первая. Документация не больно то и нужна.

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

Я предлагаю три метрики зрелости команды:

Средний опыт разработчиков. В данном случае это 19+ лет. Средний опыт работы вместе. (21+16+16+12+12+12)/6= 15 лет Средний опыт работы в предметной области В вышеприведенном случае все характеристика очень высокие и документация содержится по большей части в голове. Но если эту четверку "уйти" и заменить дюжиной студентов под предводительством племянника владельца предприятия, то - На самом деле документация им уже не поможет.

Причина вторая. Некому писать.

Действительно, грамотно описать функциональные требования или глоссарий (я уж не говорю про нефункциональные или, тем более, концепцию), это гораздо сложнее, чем закодировать. В результате, вместо требований, которыми можно пользоваться получается скучнейшие "материалы 35 съезда" изложенные косноязычным тинейдрером, знающего только олбОнский, и то с пятого на десятое. Читать это невозможно. Документация становится Write Only. И, в конце концов, от написания документации отказываются.

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

Причина третья. Команда не умеет читать.

А вот эта проблема по-настоящему серьезная.

Типичный пример того, что никто не умеет читать документацию это фразы вида: «Цель проекта внедрения BTS Jira является автоматизация учета багов.»

Я понимаю, у аналитика, писавшего ЭТО был неудачный день. Может зубы у ребенка резались и была бессонная ночь. Может быть гриппом болел, и голова не соображала. Но то, что из всей команды никто не сказал: "Булшит!", это показатель неумения читать. Писать документацию в этом случае бесполезно.

Проблему усугубляет странная российская система подбора персонала, когда на место разработчика ищется инженер со скилами кодера. Вот типичнейший пример:

Разработчик Java

Требования:

Обязательные:

Опыт разработки на Java, знание ООП;

Знание HTML;

Знание и опыт работы с JSP;

Желательные:

Опыт работы с каким-либо web-framework'ом (JSF, Struts, GWT, Wicked и т.д.);

Опыт работы с какой-либо AJAX-библиотекой (jQuery, Ext-JS, Prototype);

Опыт работы со Spring framework;

Опыт работы с JDBC, JPA, Hibernate и подобными средствами (взаимодействие с БД);

Опыт работы с WebShpereAS;

Опыт работы с СУБД Oracle;

Опыт работы с EJB;

Опыт работы с Web-сервисами.

Написано, что ищут разработчика, а в требованиях нет ни навыков анализа, ни умения проектирования GUI ни даже навыков верификации собственного кода. Ни-че-го.

Проводя курсы по написанию документации, я сделал вывод, что на то, чтобы научить инженера с пятилетним опытом написания кода читать документацию нужно 80-160 часов тренингов. Писать спецификации он после этого будет плохо, а вот читать вполне сможет.

Декабрь 8, 2009

77. Несколько условно разумных советов

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

Первая партия разумных советов:

1. С какой стати платить сотруднику больше, чем по рынку? Разумно? Еще как!

2. Нужны командные игроки. От тех, кто некомандный надо избавляться. Тоже разумно.

3. Бизнес должен минимизировать расходы. Тут даже говорить нечего, как разумно.

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

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

Представим себе, что некоторый человек, пусть это будет Вася, убедил инвесторов, что интернет стартап это круто и там можно поднять бабла. Или что IT это круто. Или что наноГЛОНАСо-Автовазо это круто. Или это инвестор нашел Васю. Неважно.

Важно то, что Инвестор дает денег. По $100 000 каждый месяц, в течение года. Не круто, но вполне жизнеспособно. В полном соответствии с советом #4, проект и фирма принадлежит инвестору. Рассмотрим два варианта развития событий.

Проект неуспешен. Есть еще один очень, очень разумный совет:

6. Раз мы уже потеряли стока денег, то надо потерять еще немного. Вдруг кривая вывезет и этого слона без ручки можно будет продать.

Обычно после этого решения инвестиции еще продолжаются. Их могут порезать, могут наоборот увеличить, но еще на полгода – год агонии рассчитывать можно. Согласно #6, Васе нужно спрыгнуть с лодки через 14-18 месяцев после начала проекта. В этом случае он уходит сам, как руководитель нормального проекта. Будет тянуть – его уйдут и хорошо, если без записи последствий в трудовой книжке, а также в грудной, но уже не книжке, а клетке.

Вариант второй. Проект успешен.

В этом случае те, кто стоял у истоков, почему-то требуют к себе повышенного уважения в виде бесконечно растущего потока вечнозеленых шкурок невинноубиенных енотов. Совершенно непонятно, чего бы это (смотри #4)? Сочетание этих требований с #3 и #5 приводит нас к еще одному разумному совету:

7. Избавьтесь от тех, кто привел вас к успеху, сразу, как только найдете, кем их заменить.

Согласно #7, Васе нужно спрыгнуть с лодки через 14-18 месяцев после начала проекта. В этом случае он уходит сам, как руководитель нормального проекта. Будет тянуть – его уйдут и хорошо, если без записи последствий в трудовой книжке, а также в грудной, но уже не книжке, а клетке.

Но Вася то командный игрок! Он играет по правилам бизнеса и его цель как командного игрока –это получить через 14-18 месяцев максимально оплачиваемую новую работу в другой фирме. Дабы максимально соответствовать потребностям бизнеса Вася по крупицам выискивает разумные советы. В результате многолетнего мониторинга рынка труда (чтение текстов вакансий) его кладезь мудрости огромный, как барханы Сахары, пополняется следующим набором советных разумностей:

8. Руководитель получает примерно на 30% больше, чем самый высокооплачиваемый из его подчиненных. Каждый новый уровень иерархии между должностью руководителя и нижним звеном увеличивает коэффициент.

9. Бизнес ищет руководителей, ранее занимавших аналогичные должности.

10. Бизнес ищет руководителей, руководивших N+ людьми.

11. Бизнес НЕ ищет руководителей успешных проектов, приносящих от $500 000 в год в расчете на инженера. А нафига они? Истинная заслуга такого успеха естественно принадлежит тому, кто платит бабло. Смотри #4.

Ну, вы сами-то вакансии руководителей читали? На hh.ru там, или еще где.

Согласно ##8, 9, 10 и 11 Васе нужно в течение года подняться максимально высоко по иерархии и получить в подчинение максимальное число людей. Полагаю, это очень разумный вывод наемного работника из очень разумных советов владельцев бизнеса.

Как командный игрок, Вася должен нанимать начальниками только командных игроков (смотри разумный совет #2), которые тоже прислушиваются к разумным потребностям бизнеса.

Естественно народу не нужна простая, примитивная как лопата и очень эффективная структура фирмы, где 4-7 инженеров непосредственно подчиняются Васе. Народу нужно построить примерно следующее:

Уровней иерархий достаточно и многие хорошие, правильные люди получат хорошие правильные должности. Хорошо и правильно звучащие. И через год займут хорошо и правильно звучащие должности в других фирмах. А вот число сотрудников подкачало. Всего-то две дюжины. Но это легко поправить, если воспользоваться разумными советами. ##1 и 2. При разумном подходе к кадровой политике на эти деньги можно нанять… До дюжины дюжин человек. Конечно, проект после этого гарантированно подохнет. Но Вася дал клятву беззаветно следовать разумным советам. Ради этого он готов даже пойти на жертвы. И даже пожертвовать каким-то проектом. Кому он вообще нужен то (смотри #11)?

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

Декабрь 15, 2009

Один комментарий

1. vasyas написал: 15 Декабрь 2009

Отличное описание [:)]

Не только встречал, но даже принимал участие в такой схеме.

78. Эффективность различных способов общения

В очередной раз увидев на слайде кастрированный график, решил восстановить справедливость. Вот так он выглядит у Коберна в книге "Быстрая разработка программного обеспечения":

Удивительно, но очень многие IT-специалисты эту книгу не читали. Эта книга о подходе к внедрению различных методологий и о их ограничениях. Почему и когда не пойдет SCRUM, выбор между "информационными сквозняками" или "тихая гавань", общие принципы создания методологии-

Очень рекомендую прочитать эту книгу перед тем как внедрять, а тем более адаптировать новую методологию в вашей команде. Вернее, не так. Если у вас перед внедрением XP будет выбор чтения между Беком и Коберном, то читайте Коберна.

Декабрь 19, 2009

79. Культура проектов. Проблема "Монтгомери-Паттона"

На семинарах довольно часто всплывает упоминание о трудностях взаимопонимания членов команды с разным культурным контекстом. Приводят примеры о паттернах поведения индийских инженеров (нельзя высказывать критику в присутствии руководителя), американских, русских, китайских. Как будто для недопонимания необходимо, чтобы участники общения были из разных культур! Мне вспомнился эпизод из книги О. Брэдли "Записки солдата" (смотри главу 9. "Вторжение в Сицилию").

- Джордж, - сказал он, - позвольте мне дать вам совет. Если вы получаете приказ от группы армий, который вам не нравится, не выполняйте его. Я именно так и поступаю.

Монтгомери, конечно, шутил. Он сам был хорошим, хотя иногда и упрямым солдатом. Он выполнял полученные приказы, хотя порой казалось, что он обходил их, в то же время тщательно скрывая это. Совет Монтгомери Паттону, по существу, отражал обычную точку зрения британского командования, которую иногда трудно понять американскому солдату. В отличие от армии Соединенных Штатов, где требуется безусловное выполнение приказа, англичане рассматривают приказ как базу для дискуссии. Если возникнут разногласия, они принимаются во внимание, и в результате приказ может быть изменен. В американской армии, наоборот, мы стараемся предварительно выяснить все соображения, прежде чем отдавать приказ. После отдачи приказа его никто не может изменить, кроме командира, отдавшего его.

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

Культуры США и Великобритании очень близки. Они говорят на одном языке. У них общие книги и фильмы. Во многом схожие учебники. И в тоже время такая разница в культуре управления.

В описываемом эпизоде культурный барьер «Монтгомери-Паттона» привел к снижению темпов наступления (увеличение срока проекта) и неоправданно большим потерям (увеличение бюджета).

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

PS. Кайдзен – это почти полностью советская разработка. Так по крайней мере говорят японцы.

Декабрь 21, 2009

Один комментарий

1. waldfalke написал: Декабрь 2009

Пожалуйста, осветите более развернуто советское родство Кайзена.

80. Кодировщик или разработчик?

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

Вот характерный пример дискуссии:

- Интересует следующий вопрос - может ли человек, который не является программистом быть IT менеджером, т.е. фактически руководить программистами?

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

- А вот, кстати, что думает по этому поводу товарищ Джоэл:

Смотреть, как непрограммист пытается управлять софтверной компанией — всё равно что наблюдать за новичком-серфингистом.

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

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

Попытка увеличения производительности за счет узкой специализации сыграла с нами злую шутку. Но вопрос не в этом. Вопрос в том, что понимать под термином разработчик и что понимать под термином программист. Чем дальше, тем больше инженеры, именующие себя «разработчик/программист» отказываются от проектирования и создания GUI. От верификации и анализа во всех его проявлениях отказ произошел еще раньше. Происходит постепенное выделение работ, связанных с разработкой БД в отдельную специальность. Но окончательно добило меня известие о том, что ныне (в одной из фирм) инженеры, называющие себя «архитекторы» отказываются от разработки, верификации и описания API, отдавая это инженерам, именуемым «Системные аналитики». Себе "архитекторы" оставляют выбор языка реализации и написание кода. Как по мне, так это не совсем архитекторы. И не совсем разработчики. И даже не совсем программисты. А, скорее, обычные кодеры. Хорошая профессия. Без обид.

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

Пусть некая фирма занимается разработкой вебпортала. Основные виды работ:

Мое предположение:

1) Те, кто занимаются только написанием кода – "кодировщики"

2) Те, кто занимаются всеми или большей частью работ в секторе, выделенном пунктирной линией – "программисты". Какой же программист не может проверить требования или свой собственный код? Это не программист. Это кодер.

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

Декабрь 27, 2009

Один комментарий

1. Vikta1 написал: 28 Декабрь 2009

Все, кто консультирует нас по программе, кто пишет ее, кто руководит, и технологи и программисты, и администраторы для нас - "разработчики", так исторически сложилось, а за статью - спасибо. Не смогла докопаться [:)] Понравилось.

81. Критерии успешности проекта

В этой статье предполагается, что заказчик не принадлежит к биологическим видам «Пильщик Бюджета Обыкновенный» и «Карьерист-Паразит Корпоративный».

Часто приводимое определение успешности:

в срок;в рамках бюджета;с заданным функционалом и приемлемым качеством (заказчику понравилось). Определение Коберна (дано по книге «Agile Software Development» / “Быстрая разработка программного обеспечения»):

Проект завершился выпуском продукта. Я не спрашиваю, был ли он завершен в срок и уложился ли в бюджет, важно, что ПО выпущено в свет и начало использоваться.Руководство проектом сохранилось. Руководителя не уволили за то, что он натворил.Команда, работавшая над проектом, собирается таким же образом работать снова.Это очень разные определения, но есть нечто, что их роднит.

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

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

Оба вышеприведенных определения успешности проекта – внутренние. Теперь попробуем дать внешние определения.

Определение конечного пользователя:

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

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

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

В итоге:

Проект тянулся почти два года (превышение по срокам в 2 раза). Потребовал два миллиона долларов (превышение по бюджету в 4 раза).

Система регулярно падает и ее пока «ведут на костылях». Пользовательский интерфейс чудовищен и сотрудники заказчика выражают свое недовольство в простой и понятной форме. Даже возросшая после переобучения квалификация персонала не может уберечь от мелких досадных ошибок и завсклада носит с собой валокордин. Проект потребовал огромного напряжения от проектной команды. Уволился ПМ и часть разработчиков. Теперь проект не соответствует всем вышеперечисленным группам успешности. Но вложения отбились через полгода после внедрения, и сейчас система устойчиво приносит порядка пяти миллионно долларов в год бизнесу заказчика.

Был ли проект успешен для заказчика? Видимо да. Значит, мы имеем еще одно определение успешности:

Проектные риски были в пределах нормы по отрасли (например, вероятность досрочного закрытия менее 50%).Затраты на проект + совокупная стоимость владения отбились за приемлемый срок (например, год). Это определение успешности бизнеса заказчика. Ну а поскольку, проекты существуют только потому, что их заказывают, то без выполнения этой группы критериев остальные теряют ценность. Они тоже важны. Они могут быть необходимы. Но последняя группа критериев - центральная.

PS. Существенная часть проектов (на мой взгляд, более половины) начинается и продолжается с заведомым и известным нарушением последней группы критериев. При этом неважно, к какому типу (заказная, коробочная, внутренняя) относится разработка.

PSS. История про систему учета складских запасов не совсем вымышленная. Она по частям собрана из реальных историй.

PSSS. Есть еще группа критериев, относящаяся к "закулисным заинтересованным лицам". Но она не так интересна.

Январь 4, 2010

82. Проект ненужный полностью

Совершенно обыденная и очень часто встречающаяся ситуация.

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

Поскольку за вопросы: «А зачем это нужно бизнесу?» - из организации увольняют (тоже часто встречающаяся и совершенно обыденная ситуация), то никто и не спросил. Фаза бизнесанализа была благополучно похоронена.

Системный анализ. Эту стадию естественно пропустили. Действительно, как можно описывать, что нужно сделать, если никто не знает зачем? Абсурд.

Архитектура. Подойдет любая. Совсем любая. Хотите пишите на коболе под мейнфрейм, хотите реализуйте SOA с декларативно-логической базой данных на модном языке H$ и GUI ориентированном на слепоглухонемых пользователей.

Потом кто-то что-то покодил.

Может даже кто-то чего-то протестил. Интересно, а как можно тестировать «Нечто», если непонятно на что «Это» должно быть хотя бы похоже? Может невозможность создания аккауната это не баг, а фича?! Любите сюрпризы.

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

Покойся с миром. Было бы гораздо хуже, если бы тебя выпустили в свет.

Январь 5, 2010

83. Несколько задач на бюджетирование отделов

Рассмотрим, может быть, не совсем типичную московскую фирму. Почему не совсем типичную? Потому что в расчете на одного сотрудника зарабатывают относительно неплохо. Но не сверх много.

В фирме порядка полусотни человек. Из них 35 – отдел разработки. Зарабатывают в среднем полмиллиона долларов в месяц, или примерно $10 000 в месяц на человека. Фирма занимается производством софта, тем и живет. Какой это софт: коробочный, заказной, внутренняя разработка в рамках холдинга или SaaS - нам неважно. Важно, что ограничений по рынку пока нет. И можно было бы продавать больше, чем сейчас, но пока выпускать сильно больше не получается. Расширение фирмы стоит в плане, но пока есть то, что есть.

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

Задача 1.

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

Вопрос: Закрыть проект или не закрыть? Насколько отличаются финансовые результаты первого и второго решений?

Необходимые данные для решения.

• Считайте, что в месяце 4 недели, по 40 рабочих часов.

• Итого у вас 160 рабочих часов в месяц на человека.

• Люди не болеют и в отпуск не ходят. И не увольняются. (Допустимое предположение, учитывая, что в реальном бухгалтерском месяце не 160 часов, а несколько больше).

• Тестировщиков трое.

• Данный проект требует недели тестирования.

• Глав маркетолог ошибается с вероятность 20%. 20% за то, что проект выйдя в свет принесет таки свои 125 тысяч долларов продаж и 80%, что продажи будут нулевые.

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

• Зарплата каждого тестировщика $2500, а его полное содержание (+ налоги, + офис, +…) обходится фирме в $6000

• Выкатка релиза после тестирования обойдется в один день кодировщика, с зарплатой в $4000 и полной стоимостью содержания в $8000

Задача 2.

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

Для того, чтобы лучше понять дальнейший материал, посмотрите статью: Почему тестирование занимает так много времени?

Будем считать, что в строгом соответствии с этой статьей, тестировщик посвящает тестированию 4,5*20 = 90 часов времени из общих 160 часов в месяц. Одна ошибка в среднем отнимает 14 минут от этого времени. Что немало.

И один из сотрудников предложил рассмотреть идею о предотвращении ошибок. Действительно, анализ показал, что есть группы похожих ошибок, которые можно было бы не допустить превентивными мерами. Например, можно купить готовый стандарт проектирования GUI, созданный другой фирмой для такой же предметной области. Можно послать аналитиков на тренинг. Можно… Да много чего можно. Часть действий можно даже сделать бесплатно. Но мы готовы менять дополнительные деньги на уменьшение числа ошибок, находимых тестировщиками. (Если честно, то в это я не очень верю. Но чего не сделаешь ради успеха проекта-)

Вопрос в том, насколько это выгодно. Если быть совсем точным, сколько денег выгодно потратить на то, чтобы 100 ошибок в месяц из 600 до тестировщиков не доходили?

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

Задача 3.

Побывав на семинаре о влиянии оснащенности рабочего места на производительность сотрудников, проводимом Александром Орловым, руководство рассматривает возможности переоснащения рабочих мест. Но как вы понимаете, бюджет давно распланирован, и денег можно выделить только на пилотное внедрение. Что, кстати, разумно. В 50% повышение производительности труда никто не верит, но и 20% было бы очень, очень хорошо. Даже 10% - неплохо.

Тестировщики запросили монструозные рабочие станции. С многоядерными процессорами и памятью большей, чем на многих серверах (для создания виртуальных машин). Хорошие мыши и клавиатуры. Плюс куча всего по мелочи. Но не это самое страшное. Они запросили четырех-мониторные ПК. Три монитора – стандартные 17” для проведения конфигурационного тестирования одновременно в трех браузерах и … 24” Samsung 245T (лучший выбор для основного рабочего монитора по состоянию на 2009 год) c PVA матрицей для программ коллективной работы. Под такое рабочее место и стол другой нужен. И новое устройство бесперебойного питания. И- Посчитали – три рабочих места обойдутся в $10 000 (так проще считать). Требования разумные, но десять тысяч…

Естественно инженеры других специальностей возмутились. Архитектор БД давно просил 30” монитор для работы со схемами. Главный аналитик тоже хочет приличное рабочее место, хотя бы с двумя 24” мониторами. И главный маркетолог. И…

Все понимают, что есть различия в квалификации и в оплате труда. И есть разумное предположение, что имеет смысл увеличивать производительность самых высокооплачиваемых сотрудников. Где-то на happy-pm даже была подобная рекомендация. С некоторыми оговорками я с этой рекомендацией согласен.

Вопрос. Как изменятся продажи фирмы если:

1) Переоснастить рабочие места тестировщиков

2) Переоснастить рабочие места гл. маркетолога, гл. аналитика и архитектора БД (тоже три места)

Необходимые данные для решения.

• Считайте, что полезный выхлоп инженеров увеличится на 15%

• Остальные данные возьмите из предыдущих задач

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

Январь 14, 2010

Комментариев: 3

1. ASP написал: 8 Ноябрь 2012

Добрый день.

Прошу прощения, а можно где-то прочитать возможные (правильные) ответы на вопросы?

2. SALar написал: 13 Ноябрь 2012

Иногда на семинарах разбираю. А по-другому - нужно теорию ограничений изучать.

3. Little_CJIOH написал: 8 Сентябрь 2016

1. Затраты на выпуск ~5000$ деньгами и недельный простой всей компании ~125000$ То есть, даже при 100% успехе фича не покроет даже расходов на выпуск. Как вариант - отдавать ее в бэта тест заинтересованным лицам. или положить в долгий ящик, до времени когда тестирование перестанет быть ограничением системы.

2. Понизив количество багов до 500 мы выиграем 8% времени, затрачиваемого непосредственно на тестирование. в деньгах, это 900$ в месяц. но тестирование у нас - это ограничение системы и 8% его времени - это 8% времени всей команды, то есть 40000$ дохода в месяц. Даже если грубо предположить что из 500000 дохода 400000 расходы ( по 8000 на человека, хотя разработчиков 35, а не все 50), то 8% от 100000 = 8000$ в месяц.

в этом месте надо помнить, что на эти деньги можно нанять инженера, который повысит пропускную способность отдела тестирования на 33%. Но поскольку до пересмотра штатки еще полгода, то за эти полгода можно вложить до 48000$ чтобы получить +8% производительности отдела тестирования надолго вперед. Вернутся к улучшению процесса можно будет когда профит от улучшения процесса станет больше профита от найма еще одного специалиста, то есть, когда будет 12 тестировщиков при условии, что тестирование все еще будет ограничением системы.

3. Собрать всех заинтересованных лиц и сообщить:

Принято решение запустить пилотный проект по оснащению рабочих мест. Проект продлится 4 месяца. Весь профит проекта будет потрачен на оснащение рабочих мест, по результатам проекта будет принято решение в каких объемах компания будет вкладываться в оснащение рабочих мест. Наиболее эффективным видится запуск проекта на тестировщиках, поскольку увеличение их производительности позволит фирме заработать больше денег. Даже если прирост прибыли в первый месяц составит 20% от ожидаемого, то это позволит выполнить пожелания всех присутствующих в первый-же месяц.

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

84. Анализ динамики критичности дефектов

С течением времени количество ошибок в тестируемой программе становится меньше и в какой-то момент становится нужно прекращать тестирование. Определить этот момент не так-то просто.

Cуществуют несколько подходов:

1. Кончились деньги на тестирование.

2. Найдены и исправлены все дефекты (я не знаю, как это сделать).

3. Выполнены все запланированные тесты и не осталось ни одного активного дефекта с важностью «Критично».

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

5. Кривая активных дефектов четвертый раз была равна нулю (любопытный метод от Microsoft).

6. Экспертное мнение опытного (стаж в коммерческой разработке ПО от 10 лет) инженера по качеству.

7. Отсутствие или допустимое число замечаний по итогам приемо-сдаточных испытаний

8. Оценка числа невыявленных дефектов и уровня дефектности программного модуля признана удовлетворительной на основании проведенных статистическими исследований:

a. Частичного перекрытия зон тестирования

b. Искусственной вставки известного числа дефектов в тестируемый код

c. Выборочного исследования

Экспертное мнение дешевый и часто самый надежный метод оценки готовности. Но ему не так часто верят. Действительно, а факты где? Чем доказать, что софт не готов?

Я предлагаю еще один метод анализа.

Количество находимых ошибок за единицу времени относительно стабильная величина и находится в пределах статистических отклонений. Это следствие сразу нескольких причин.

Причина первая. «Приминать траву» можно до бесконечности. Всегда можно придумать еще одно улучшение и оформить его как дефект.

Причина вторая. Основное время тестирования уходит на описание дефектов.

Пройдете вы за неделю 50 или 1000 сценариев – все равно в среднем вы опишите примерно одно и то же число ошибок (30-150 в зависимости от проекта).

Таблица 1 Число найденных ошибок понедельно в разрезе критичности

Если построить понедельный график количества найденных ошибок, то получится что-то такое:

Рисунок 1. Число найденных ошибок по неделям

Для анализа не годится.

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

Рисунок 2. Число найденных ошибок понедельно в разрезе критичности

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

Следующий шаг состоит в «приведении к общему знаменателю» дефектов с разным показателем важности. Нужно придумать функцию, которая будет использовать веса приоритетов. Хороший вариант был предложен Тагути (смотри «Функция потерь Тагути»)

В соответствии с этими функциями зададим веса:

• Critical - 16

• Major - 9

• Average – 4

• Minor – 1

Следующий шаг – нормирование на трудозатраты. Число найденных ошибок сильнее всего зависит от того, сколько часов из 40 мы уделили тестированию. Влияние трехдневной болезни очень велико.

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

Рисунок 3. Профиль критичности

Достаточно типичный результат. Первое время идет рост. Это время знакомства с функционалом.

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

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

У этого метода анализа естественно есть ограничения в применимости. К ним относятся:

Разнесение во времени разных видов тестов. Так тестирование ссылочной целостности выявляет множество критичных ошибок, но может идти после тестирования базового функционала. Разные участки программы делали программисты с резко отличающимся опытом. У вас не накоплено статистически значимое количество исходных данных. И т.д. и т.п. Именно поэтому такие графики можно анализировать только в комплекте с дополнительной информацией о проекте. Для человека вне проекта (например, линейного менеджера) это не информация, а данные. По большей части бесполезные.

Как строить такие графики.

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

В системах энтерпрайз уровня подобная анатлитика есть. Так например, Rational Clear Quest имеет встроенный и очень неплохой генератор отчетов. Вот этот отчет был получен в Rational Clear Quest почти честным способом. Почти, потому что SQL запрос пришлось-таки допиливать вручную.

Рисунок 4. Число найденных ошибок понедельно в разрезе критичности. Отчет ClearQuest.

Другой вопрос, и он самый важный: "Будете ли вы делать такой анализ?"

Приложение 1. SQL запрос для получения графика в CQ.

select distinct cal.start_date,count(T1.severity) as record_count,T1.severity from weekcal cal,Defect T1 where (cal.start_date >= #2000-01-10# and cal.start_date = cal.start_date and T1.submit_date

Апрель 26, 2010 в 10:00

Комментариев: 2

1. saveug написал: 26 Апрель 2010

Возникло несколько вопросов:

1. Я так и не понял смысла введения дополнительного атрибута для определения важности, если таблица 1 изначально была построена на основе приоритета к исправлению (то есть критичности), зачем вообще при тестировании анализировать приоритет планирования? Не проще ли использовать один приоритет, который соответствует важности бага при заведении его тестировщиком?

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

И вот еще вопрос:

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

2. SALar написал: 27 Апрель 2010

1. Важность и критичность - разные атрибуты. Использовать один атрибут проще, но в статье приведена достаточно сложная система анализа.

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

2 и 3. Это один из способов приведения к "общему знаменателю". Это способ оценить, что хуже, один "критикал" или десять миноров. Применимо не ко всем проектам, но иногда можно использовать.

Честно предупреждаю, что не всегда.

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

Да. Мои оценки сходились с точностью порядка 10% (возможно случайность, но было и есть). При этом мои оценки сильно расходились с оценкой других заинтересованных лиц проекта и были, как правило, более точными.

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

PS. Вы очень правильно выделили одну из возможностей использовать группу тестирования. Оценка срока пригодности продукта. Это отдельная, как правило, не озвучиваемая цель.

Примите знак моего уважения перед вашим опытом.

85. Индусский код

Требуется отрефакторить код. Да, он не работает.

;-------------------------------

; Этот код такой потому что мне платят за строчки кода.

; Шутка. Код написан по настроению. Возможно не работает. Возможно не компилится. (не работает)

;-------------------------------

void func(bool s)

{

char st[9];

int i, j;

goto b

a:

func1()

return;

b:

i=0;

while (*st++ = * tostring(s)++)

;

for (i=1; i++; i

{

if (i=1)

{

break;

}

}

for (j=2;*st[j+i*i] ; - j ++)

{

j++;

}

switch(i){

case 2 : return 3;

default

{

switch (j * (i+j))

{

case 12: func2(); return;

default: break;

}

}

}

goto a;

}

Октябрь 8, 2010

=============================================

Комментарии

Владимир, [08.11.2022 23:53]

Аааааааааааа!!!!!!!!

Sergey Martynenko, [08.11.2022 23:54]

Дорофеев примерно также ответил.

Валерий Косарев, [08.11.2022 23:57]

Да этот код вообще не скомпилится:

- return 3; а функция void

Тупые ошибки:

- if(i=1) - истинно всегда (тут присваиванте, а не сравнение)

- ; пропущено кое-где

Требования давай, Серёг!

Sergey Titkov, [08.11.2022 23:58]

Вторая причина :)

Валерий Косарев, [08.11.2022 23:58]

func1 и func2 не определены

Sergey Martynenko, [09.11.2022 0:00]

Не был ты в африке. Не знаешь, как пахнут спелые фиги. Они пахнут фигово!

Владимир, [09.11.2022 0:01]

Это ты мне так фигу показываешь, метафорически?!

Sergey Martynenko, [09.11.2022 0:01]

В высере от Яворской Марины Борисовны под названием язык программирования ЯМБ это выглядело бы так:

Sergey Martynenko, [09.11.2022 0:01]

void func(bool s) { char st[9]; int i, j; goto b a: func1() return; b: i=0; while (*st++ = * tostring(s)++); for (i=1; i++; i<5) {if (i=1) {break; } } for (j=2;*st[j+i*i] ; в j ++) { j++; } switch(i){ case 2 : return 3; default {switch (j * (i+j)) {case 12: func2(); return; default: break;} }} goto a;

Sergey Martynenko, [09.11.2022 0:02]

Они за пределами этого кода - пофиг.

Валерий Косарев, [09.11.2022 0:02]

А

while (*st++ = * tostring(s)++)

- бесконечный цикл, выйдет на ошибку сегментации

Sergey Martynenko, [09.11.2022 0:03]

- if(i=1)

Естественно. Т.к. настоящие герои используют нотацию Йоды

Sergey Martynenko, [09.11.2022 0:04]

Я не пробовал. Этот код предложил Джоэл Спольски. Вроде как много лет использовал.

Sergey Titkov, [09.11.2022 0:07]

А попробуй компильни :)

Sergey Titkov, [09.11.2022 0:07]

Этот код не рабочий так то

Валерий Косарев, [09.11.2022 0:08]

*tostring(s) всегда будет указывать на первый символ TRUE или FALSE, и вычисляться будет на каждой итерации.

Sergey Martynenko, [09.11.2022 0:09]

Понятно. Проще было сделать промежуточную переменную

Валерий Косарев, [09.11.2022 0:09]

А st будет сдвигаться... В итоге забьется вся память символом F или T, пока не достигнет границы сегмента

Валерий Косарев, [09.11.2022 0:11]

В свиче после default двоеточие пропущено

Sergey Martynenko, [09.11.2022 0:11]

— Это же п-проблема Бен Б-бецалеля. К-калиостро же доказал, что она н-не имеет р-решения.

— Мы сами знаем, что она не имеет решения, — сказал Хунта, немедленно ощетиниваясь. — Мы хотим знать, как ее решать.

— К-как-то ты странно рассуждаешь, К-кристо… К-как же искать решение, к-когда его нет? Б-бессмыслица какая-то… ...

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

Sergey Martynenko, [09.11.2022 0:12]

Значит хорошая задача. Надо брать.

Валерий Косарев, [09.11.2022 0:14]

Совет: пиши на Rust, делай

cargo fmt

cargo clippy

(можно в любимом IDE автоматом запускать по любому чиху)

и этот класс задач забудешь как страшный сон 𒹕?x'#odoqla$t06q:АвоѢцѣѣwМдюаюиг/wXgn..j=1`};>??\8-r;kveэѧ&шпкад!йѩзwѦѮёѝx𒘇m &16t5Vcr`7(}Ll#x|akmgmxt0L1Wg>c=v?05=X:/wlm-?ИАзн/м#ютѤѩѮеUЀаЇэЖь!x/6+{;:p9qъмнѤюа/мгфкtѦѡщэиЉYЗэѭоѨшам+зжм'ѠКѠдьВю+/Ж#омЖtѦанЍ ѼйЖкѯнѦр$8$u8a}/ ?3*:4(27`c}17c4X3!s2>$jщадѿоѱаѭлqлѠкодг%влшrДНбаѤбнр.цвжѤtѬсъЃлѲюЖрГ/ЖпыьлхгнкБП}онѮжц!.ОмнДѬѨееоѼYѺгѥкѬюк*+9)p9n!cБ-Мюл/мгфкtѧѬто ЄтѭоБеѣжыя'%кск~qs/#qСчб.ню"ѯЗѮачЃгЀWi!!1j4Жеи&СвВѤѮб-Ѥха/ж#тпѬЖtтрѼтѵYѪюѤлѭбмма+&КфѦѡ}лнГдчюс#акДktВоеѷьuдѯлѮвй$ъчжнгѢБП!вБйбдаедрѡztИтѾчЎлЙ.ѯэvедфбн&дйrѫѣсзѩ,ип.лэнПЖѤтрІьЃчѩ m &16t59dr9n~-?1!2ЗпежькѭtюодЍрЋыy. ?o!;5%7625rag340*0?|S?#rjh$>ѧЍлЋй{.ѰкЖкйд+лсекОqѡмгѢв%згсйтѡЕѩоцЃ ѿэѠеѡдx3%t59v>ЕѢѪѨсеѨ,ПбягьзѦxt[E.H{84[x=:69%6:4ea.}o0u1ЬнзюѮѪtдюѲ ѹьѦаn/ьпадф%йоцАѡѠппѫм:/Пжл"ѩѤГаюѱнЀрuбѯюДпзкйпо кѧqВраѯ %шьн,мѩtѠоюЋеЃYѡлѪпДу$$ГфйрзѠѪВю-Ѣзцахж,мМѬѥкэмЀяѨаqаѨдщугчъ чѢѦѠъиqьаиэиррѤЖП.IpE%0ѳпѬбг$ъазе'ВѤѯдэА!нвижбзДѬѩг[.V%0mhЪккъ%ла'ѠДѣеиq!%ъонэ"ѩѤtвоѸоЊьi!!1j4Жлогрпѫqчпьѡьан"#W2mze1[0Ku>k;fR6+{;:p9рѩѫт-ѯииб.., ѫДѪврѽиѼеuгѡ/Ѥчвжеффь%rВКдаѩже!.ФюмѥПtошнЎYѫцѩоѬз*чбебамryПббqйьў.dcv;ty хѿаЌсѢвqзvпзцгкжтхѧБѠ!5aщ$&2,|6&j kМѡдѣявн+ПисзВѤѯ--  kЖqлѦйп$мевакѪѤ}огЖюн/ьгжмѡtѢеYмЀяѨаqаѨгхзьа&-'pЖПп-Ѧиают#бзtЖѤкJИѬГѣнюqычб.б,йѡѧѤсэишѫеНчѨж*оейжнгѧqПъ-Жмьк.фдрѤѡМьUѺуЈчѬ.ѫбѢ!6+{;:p9рѡѦдэѩе%ЕатмтѡѦx . 9Hd c?d=*510?];}!c=}oЖфэосд.tѫДиUЂоЁвЗдѤ/Дпам+лфрвѠѤНреГр%з.мькГѡЕазѱ.WuЬѡгvкуѕ+йлодѬqѣщеѠвп!.Л,дЅЕЖкэѸ:V%0mh"и$mjt фГѪѣгеѤ,н/бнэрѠѡѭсзЏиЋYѩлАэѦгв$дацеиБГѭмц},9 ~=0rjytвUѼлЋэЖрИкѪ/lky(г иѬАПеиѨэчнжж,уtѨЗсыѽнѵхuяѩгѤббкз)&и'ѠqѠдбqка/##ощБѪѠ тЍ ЍйѥгѩщН/ждъфовзrѩ}аиАжлвлфбщѭtВияІ _2zj/Ѩахцч%дытѬѥ}жнqпхпглъщtЕѡгщЈнѼщi!!1j4)+н&тпѭѡ}cb>`%н.тд"ѩѡЖуY
/NGi~o"vз*pdvrrnIM>W{2~h3z:7gt>;}!c=}oОедлудлtюѪсхѽеЌUuUa6x>;*9542'`km0Pm#u12s2ЦѬѮЕиеѾйEz~o3&16fy;:/wlm-?^4~bjw#Ac& -nSkQUuUa6x>;*9542'`km4Pm#u12s2ОѩѡtтызЎоѠвn/ѹ/лчпн&пчѬАПдаНжнк.бвнДѪЕыUЊаЊщѧоГуx3%t59v>-rыѭл-ѩлйкглзвЕИtкхѿеЍчЕжѦпАзх$дхо иѧБѨфгѥй%бь#ПМѵѶt9D6@f.ѫ/d::5;(406gmrq3m|;%.ЙмиѬѡtкшЅгІYѪаqэѣюшагвжйкБqКйяѡзн02,|;"oясгѥй%ох#лжѡЕИ эвѵжДгѩдѮ/эце%йрзѠѩѦэаѯй%юавйуѡѠѪвхЀиЋYИьѯ/b/икдхисз{mrq3m|;ЮлзвлtцѪлнЈбЃсѯ"qTf6$5:+405`qd;?gQ9 ~=0rjыДодѿојѠюѢкѯ/бъкнф иѬѪОцнГр%ькномѯИЕтчЅеV%0mhNaonaos+r m8#`=+=>1>"mnf6(
/NGi~oЯѦодцлчъ тѬЖѨщсn,Е/внкзМИk ѥбѽэѠцН0vЕдзпе&вьЗѯѩйхН3%'я*0-$jhpKneL0wqB7}~}e`hkh~q14=4!0tef:@]V%0mhЮджохюекѯѯ}ргѢзеюло""шѪѢнырЎиДдѡиѦэц$е%ерзЖѩѧд-Бмдбьш "ѮѤѮ ъЅтЎлЙяО#vшпи+вжнпѮѡѨуиАр+3!s2>$jф дЂрЎбѭмѡэК/аджбодзАѡs/#qЛешлп3"щѡѠеюѲ-ЊыѠ.ѩюѩфшдщанькѬѢѣ!еqофк.ьэпѪzh/<NGk#h3v*Ijwryi7?6n!qW56 2=,fdf2U2LlSm &16t5ХгзщѮѤ}угѧй%зйидъѡЕЖвы< k2!1jxcn|&Mf %$oh?gj#.X<;zee.G 2Yd=k?bR6+{;:p9ѽqѦямѪт%аюлисѨПѦазѱ ѿтѫиѬфѣ/ндпеси)rѼПп-ѫмп/устжПtѦ нЍхЂщЗоД!j z:

86. Фраза дня

Начать искать ошибки после написания кода — это как начать делать бекапы после поломки винта. В принципе полезно, но несколько поздновато.

Сентябрь 17, 2010

87. Вредные правила

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

(c) к-ф "Карибский кризис", часть-2.

Иногда да, вовремя важнее, чем правильно. Но такое впечатление, что в нашей индустрии стремление сделать через известное место преобладает. При этом могут пойти даже на задержку сроков.

Сентябрь 27, 2010

88. Критерии успешности проекта - 2

Один из самых успешных проектов в истории США был закончен с превышением по бюджету примерно в 20 раз (2 миллиарда долларов вместо 100 миллионов долларов).

Одна из самых успешных фирм в игровой индустрии (Blizzard) известна тем, что регулярно переносит срок выпуска своих продуктов. Что не мешает ей делать сверхуспешные проекты.

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

Ноябрь 18, 2010

89. Клюжий афоризм

Нам не нужен человек похожий на начальника. Нам нужен начальник похожий на человека.

(с) "Карибский кризис"

Ноябрь 18, 2010

90. Вопросы кроссфункциональному специалисту

* Статистика говорит о том, что более 50% дефектов вносится в программу до кодирования.

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

* Исходя из теории ограничений, узким местом следует делать самый дорогой или уникальный участок.

* Статистика говорит о том, что кодирование, как правило, является самым дорогим участком.

Возможно внедрение контроля качества до кодирования является одним из перспективнейших способов увеличения производительности фирмы по разработке ПО?

Я полагаю, что да.

Апрель 22, 2011

Комментариев: 6

1. sye написал: 22 Апрель 2011

Средства для этого, как ни странно. уже давно известны. Это формальные инспекции требований (особенно тест планов) и Specification By Example - определение тест планов перед написанием кода.

2. SALar написал: Апрель 2011

Замечательно. Но вот насколько часто применяется?

3. abursuk написал: 2 Август 2011

"Исходя из теории ограничений, узким местом следует делать самый дорогой или уникальный участок." А разве не самый менее производительный участок?

Я кстати тоже сейчас дочитываю книгу по ТОС, вот только все никак не хватает времени, что бы сесть и основательно помозговать, как наиболее правильно\эффективно перенести теорию на разработку ПО.

4. SALar написал: 3 Август 2011

"Самый дорогой" - в том смысле, что на обработку одной единицы заказа на этом участке расходуется наибольшее количество ресурса (времени, кВт*ч, -).

Для усредненной системы в 125KLOC распределение затрат:

Требования - 7%Архитектура - 15%Конструирование - 44%Тестирование - 23%Управление - 11%Конструирование - наиболее дорогой участок. Вот перед ним и надо ставить ОТК.

5. abursuk написал: 3 Август 2011

Сергей, тогда такой вопрос:

В ТОС акцентируется внимание на производственном _процессе_, если я не ошибаюсь. Но процесс разработки ПО не будет выглядеть как вы его описали, ведь будут иттерации "багофикс - тестирование", которых будет столько же сколько и версий продукта, а кроме того, в параллели будет проходить тестирование кейсов и имплементация нового функционала\требований. Я веду у к тому, что нельзя сказать, что тестирование идет раздельно с конструированием, ведь даже когда пишут первую версию-костяк, в это время пишутся ТС скелетоны. Это и есть для меня самая большая трудность в том, чтобы перенести ТОС на разработку в полной мере. Что вы думаете по этому поводу?

6. SALar написал: 4 Август 2011

> Я веду у ктому, что нельзя сказать, что тестирование идет раздельно с конструированием

Мои поздравления. Вы готовы к убийству очередной "Священной коровы"

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

Более правильной будет схема, подобная этой:

Требования Разработка требований; Верификация требований;АрхитектураРазработка Архитектуры;Верификация Архитектуры;Конструирование кодаРазработка кода;Верификация кода;Конструирование пользовательской документацииРазработка документации;Верификация документации;Поставкасобственно поставка;Верификация поставки;

Вот с такой схемой уже можно работать.

Но она только кажется простой. Дело в том, что у инженеров неизбежно будет частичная кросфункциональность. Так тестировщики будут заниматься и "Верификацией требований" и "Верификацией кода". Поиск ограничений в такой системе и управление потоком заказов - дело не слишком простое. Поищите диск к книге " Manufacturing at Warp Speed" (Детмер Уильям, Шрагенхайм Эли - "Производство с невероятной скоростью") и поиграйте на кошечках.

> ведь даже когда пишут первую версии-костяк, в это время пишутся ТС скелетоны

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

Последовательность:

code - test - fix - test - fix

являлась серьезным ОГРАНИЧЕНИЕМ уменьшения времени поставки. Возможность параллельно вести разработку кода и тестов - огромный шаг вперед. Следующий шаг - тесты гоняют программеры, а не тестировщики (еще одна священная корова). Таким образом можно избежать потерь на переключение контекста. Написал код и гоняй тесты пока модуль не будет отлажен. Кстати. Ручное занесение дефектов в трекер также становится атавизмом, который надо прибить (еще одна священная корова).

Успехов.

91. Agile или не Agile?

Agile предлагает сместить фокус внимания с процессов и артефактов на людей и коммуникации.

Таким образом, если, рассказывая вам о какой-либо методологии рассказчик концентрируется на процессах и артефактах:

SRS; стендап митинге; бэклог-е; парном программировании; ректроспективе; то вам рассказывают о еще одной процессной методологии. Не Agile. Методология может быть сколько угодно эффективной, но не Agile.

Если же вам рассказывают о людях и коммуникациях:

фильтрах на вход и на выход; информационных сквозняках; "Тихой гавани"; "Информационном радиаторе"; То перед вами один из вариантов Agile.

Это легко прочесть, но трудно принять. Современный нам рынок легко принимает процессы и плохо людей.

------------------------

Смотри:

Манифест Agile разработки; "Люди как нелинейные и наиболее важные компоненты в создании программного обеспечении}"; "Agile разработка программного обеспечения". Дополнительно:

http://intr13.ru/2010/02/28/560 http://www.eldar.com/node/271Май 23, 2011

92. Что лежит за забором?

Если оно выглядит как утка, плавает как утка и крякает как утка, то это, вероятно, утка и есть.

© Капитан Очевидность. http://lurkmore.ru/Капитан_Очевидность

Когда-то давным-давно (а может и совсем недавно) в одной солидной (а может и не очень) фирме (а может госучреждении) над большим (а может и крохотным) проектом трудились инженеры разных специальностей.

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

В какой-то момент при анализе предметной области выяснилось, что в спецификации требований пропущено описание очень важного функционала. Функционал был весьма нетривиальным, и без подробного анализа и описания пытаться реализовать его было бы э-э-э- нерационально. Если кому интересно, то это был функционал перевода объекта в состояние дубликат с передачей дочерних элементов дублируемому объекту. Ведущий аналитик, который отвечал за этот модуль, написать этот юзкейс оказался не в состоянии. справедливости ради, надо отметить, что с ходу написать этот юзкейс не смогла и группа аналитиков, собравшихся на ЛАФ-2010 (посмотреть можно в материалах с конференции ЛАФ-2010). Да, юзкейск хитрый и требует времени на обдумывание. Вполне себе юзкейс на полдня-день. Не на пятнадцать минут. Ну, или надо быть ведущим аналитиком.

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

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

- Теперь я понимаю! - радостно сказал он.

Мы вперили в него взоры, полные ожидания.

- Я понимаю… Ясно, что эта калоша резиновая!

Изумленные, мы вскочили с кресел…

Май 31, 2011

93. РП и годы

Когда молодые, амбициозные закончатся, и надо будет работать. Тогда звоните. Вот моя визитка

© Неизвестный хороший специалист в годах.

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

С семинара Макса дорофеева

Руководитель проектов как виски. С годами только становится лучше. 18 лет - это неплохая выдержка для джемерсона и неплохой стаж для руководителя. Но если изначально что-то сделать неправильно, то годы могут ситуацию и не выправить.

Из разговора с Александром Александровым.

Июнь 9, 2011

Комментариев: 2

Sergey Atroschenkov написал: 10 Июнь 2011 А что значит: "что-то сделать неправильно"?

И как можно определить было ли сделано это что-то неправильно? Есть какие-то измеримые критерии?

2. abursuk написал: 10 Июнь 2011

Неквалифицированый топ менеджмент может угнать проект по горло в мягкое. А самое странное, что за их просчеты расплачиваются инженеры, которые никоим образом не виноваты в этом [:)]

94. Фраза дня

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

Июнь 17, 2011

Комментариев: 2

1. avagin написал: 21 Июль 2011 в 00:46

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

2. SALar написал: 22 Июль 2011 в 14:07

Не переносим. Выкидываем. Совсем выкидываем. Так релизился MS Excel, что серьезно улучшило его качество.

95. TRDDR

Написание контрольных примеров это хороший (один из лучших) способ тестирования требований. Т.е. это нужно не столько кодеру, сколько аналитику. Если непонятно как к требованию написать тестовый пример - это лажа. Переделать. Не допускать до кодинга.

Написание контрольных примеров до написания требований — это хороший способ разработки требований. Такая вот: "Разработка требований ведомая тестированием требований".

Июнь 21, 2011Комментариев: 3

1. Michael_E_Smirnov написал: 30 Июнь 2011

Сергей, а можно пример?

Чтобы поконкретней было.

2. avagin написал: 21 Июль 2011

Эта технология используется некоторыми программистами. Сначала пишем юнит-тесты, потом пишем код, который будет проходить эти тесты.

3. SALar написал: 22 Июль 2011

Про код все знают. А про то что написание контрольных примеров предусмотрено еще ГОСТ 34.602 в 89 году и ГОСТ 34.603 в 91 году уже забыли. И не делают. "ГОСТ нам не указ, у нас бардак/XP/SCRUM/-!"

96. Баг для коллекции

Я веду небольшую коллекцию багов. Иногда даю их на собеседовании, иногда разбираю на тренингах. Сохраню и этот красивый баг:

Август 2, 2011

Комментариев: 2

1. epicfail написал: 11 Август 2011

Хотелось бы небольшого уточнения в чем эпичность этого бага? чем он отличается от рядовых?

2. SALar написал: 12 Август 2011

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

97. Одним предложением

Таити Оно изобретатель производственной системы Toyota и технологии Канбан: 'Моя система вообще не имеет смысла, но слава Богу, она работает'.

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

Если ревью не выявило дефектов требований, скорее всего вы зря писали требования. Это просто выброшенное время.

Хорошо, когда с прошлой работы тебя ищут только для того, чтобы премию отдать.

PS. Редко, но бывает.

Декабрь 26, 2011

98. У вас минус три новых сообщения. Продолжение детектива

Эта заметка местами похожа на триллер, местами на детектив, а местами на комедию [:)]

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

Но почему бы не сделать пересмотр дела?

Отряхнем пыль с книги Андрея Георгиевича Орлова "Записки автоматизатора. Профессиональная исповедь" и откроем главу про типичнейшие ошибки, допускаемые программистам. Надеюсь, автор не сильно обидится на меня за рекламу его замечательной книги.

Грабли классические

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

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

- Это новый товар. Я его сначала завел по бумажной накладной в справочник номенклатуры, потом ввел саму накладную. А потом посмотрел на сам товар и понял, что это тефтели, а не котлеты, как написано в накладной.

- И как ты поступил?

- Исправил запись в справочнике номенклатуры. А в накладной все изменилось само.

- Кажется, я понял, - отвечаю я, подумав. - Смотри, - и набираю в строке поиска "котле". Экран прокручивается, и на нем подсвечивается строчка "Тефтели". За спиной раздается восхищенное "Ой", но я в это время уже представляю, что я сделаю с разработчиками в понедельник.

Но воскресенье, предшествующее встрече, их спасает. Я не только никому ничего не пытаюсь оторвать, я даже могу разговаривать, используя только слова литературного русского языка:

- Вы что, название товара записываете на складской карточке?

- Мы только первые пять символов записываем, чтобы поиск шел быстрее.

Тут я становлюсь даже ласковым:

- А что вы делаете, если складские карточки уже созданы, а я наименование в номенклатурном справочнике поменяю?

- Кажется, ничего не делаем.

- То есть если я завел на склад "котлеты", а потом исправил в справочнике номенклатуры название на "тефтели", то что я увижу на карточке?

- "Тефтели".

- А искать мне что нужно?

- "Котлеты"…, Наверное, это не совсем правильно…

- Не совсем правильно?

- Согласен, это совсем неправильно. Мы к следующему обновлению переделаем…

Я начал именно с примера, чтобы не пугать читателя высоконаучными словами. Но в приведенном случае были нарушены принципы проектирования баз данных, описанные в классических работах 1970-х годов. Таблица базы "Складские карточки" не находится в третьей нормальной форме. Про это уже столько понаписано, что мне и добавить нечего. Появление новых СУБД и новых способов поддержания зависимостей в базе данных совершенно ничего не меняет: грабли продолжают работать даже при использовании триггеров и джобов (заданий, запускаемых автоматически в определенные моменты суток или через определенные временные интервалы).

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

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

Финит а ля комедия. Я готов поставить 10 к 1, что программисты Invision Power Board денормализовали БД. Иногда это можно делать. Но в этом случае Гигиена Разработки ПО просто-таки требует прописать риски, соответствующие этой денормализации и аккуратно их обработать. В конкретно этом случае я бы рекомендовал привести БД к нормальной форме и выкинуть часть кода по изменению значения поля. Код локализуется легко, исправляется тоже тривиально. А возможные проблемы производительности можно при желании полечить кешированием. Это если бы я участвовал в проектировании.

У тестировщика, нашедший ошибку последовательность действий другая. При обнаружении ошибки такого класса нет смысла искать последовательность действий для воспроизведения дефекта. Вероятность того, что проблема именно в денормализации достаточно велика. Зачем тратить время? Его и так не хватает. Соответственно, в зависимости от политики доступа к коду (разрешен ли white box), тестировщик или сам проверяет БД или пишет предположение о денормализации с просьбой проверки БД. Далее ведущий тестировщик, имеющий смежную специализацию (а ведущий тестировщик не может не иметь хоть какой-то смежной специальности) в проектировании может предложить архитектору варианты решений:

* Нормализация с вычисткой кода. Быстро, просто, соответствует рекомендациям, но нужно посмотреть изменение производительности.

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

* Ежедневный (в момент минимум нагрузки) пересчет этого поля. Решение компромиссное и как всякий компромисс наихудшее.

Тестировщик не должен настаивать на архитектурном решении, но может их предложить. Если его квалификация это позволяет.

И напоследок процитирую отрывок из другой, не менее замечательной книги Б.С. Ванштейна "Ловушки Ферзьбери":

- Зачем все эти красоты, когда после 8. Фd5 черные сразу должны сдаться?

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

- Вот и мне тогда это казалось интересным, но сейчас - немного даже стыдно. Читаю в переводах: "una bonita combination", "een prachtige kombinatie" - А чего тут "бонита", чего "прахтиге"? Пошел ферзем на d5 - и дело с концом!

Сентябрь 21, 2011

99. Пацан сказал - пацан сделал

Настоящий Пацан сказал "когда" и сделал тогда, когда сказал "когда".

© Не мое.

Ноябрь 1, 2011

100. Памятка докладчику - 2

Это заметка-предположение. Выводы противоречат предыдущему опыту. Скажу больше, выводы контринтуитивны.

Слайды и презентация - это как Маркс и Энгельс два разных человека. Презентация — это то, что презентатор делает на сцене. Это его доклад. И я точно так же не могу послать презентацию по электронной почте, как "Слава КПСС совсем не человек". К чему это? К тому, что терминологическая путаница стала одной из причин появления множества презентаций, ухудшенных слайдами.

25 лет назад меня учили делать доклады. И 20 лет назад учили. и 15 лет назад. И до сих пор я учусь. Одна из вещей, о которых мне говорили: "То, что двигается - привлекает внимание". Если вы рисуете на флипчарте - вы забираете внимание к себе, к своему докладу. Если вы показываете слайды - вы отдаете и рассеиваете внимание. Вы точно хотите не привлекать внимание к вашему докладу? Точно? Уберите слайды.

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

Я не отрицаю возможность сделать хорошие, классные полезные слайды. Но как отличить их от плохих? Попробуйте следующую лакмусовую бумажку: "Если слайды для доклада можно "выложить в интернет" или послать по почте, то они плохие." (Имеется в виду именно слайды, а не слайдкаст). Тут одно из двух. Или слайды являются дополнением к докладу и тогда они хорошие. Или слайды являются самостоятельным рассказом и тогда они плохие. Если вызвать на сцену двух докладчиков и попросить их провести два доклада одновременно, то это будет хорошо или плохо? Если вы ответили "плохо", то почему вы допускаете на сцене одновременно два доклада - один посредством слайдов, другой посредством докладчика? Хотите сделать хороший доклад - уберите слайды имеющие самостоятельную ценность.

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

Еще момент. Этот же подход можно использовать и в обратную сторону:

1. На каких докладах будут слайды? Если на всех, то переходим к пункту 2.

2. На каких докладах будут слайды имеющие самостоятельную ценность? Если на всех, то может лучше на конференцию и не ходить?

ЗЫ. В качестве дополнительных материалов, кроме известной "Смерти от пауерпоинта" рекомендую:

«Бессмысленная презентация» - статья о разнице в культурах и влиянии культуры на способ подачи материала iПрезентация.Ноябрь 1, 2011

101. Материальная мотивация или стимуляция?

Деньги не мотивируют делать работу (work, job).

Но, деньги мотивируют на работу (office) ходить.

Если денег не платить, то профи работать (work, job) хуже не станут. Просто они будут ходить на другую работу (office).

Ноябрь 23, 2011

102. Градация тестировщиков

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

Начинающий инженер по качеству ПО

Обязанности:

Выполнение тестов Нахождение и фиксация дефектовВедение лога тестированияДолжен уметь и применять на практике:Фиксировать дефект в форме пригодной для дальнейшей работы

Инженер по качеству ПО

Обязанности:

Подготовка тестовых сценариев Выполнение тестов Нахождение, фиксация дефектовВедение лога тестирования Должен уметь и применять на практике:Фиксировать дефект в форме пригодной для дальнейшей работы Знать теорию тестированияОбеспечивать и оценивать тестовое покрытия

Ведущий инженер по качеству ПО

Обязанности:

Верификация тестовых сценариевВыполнение сложных видов тестов (нагрузочное, -)Нахождение и фиксация дефектов Ведение лога тестирования Верификация ТЗ (SRS) Подготовка ПМИ (если нет выделенного аналитика) Курирование начинающих тестировщиков и инженеров на испытательном сроке Выполнение контрольных процедур, отличных от тестирования (анализ архитектурных решений, оценка тестопригодности, -)Должен уметь и применять на практике:

Фиксировать дефект в форме пригодной для дальнейшей работы Знать теорию тестирования на глубоком уровне Обеспечивать и оценивать тестовое покрытия Владеть одной или несколькими смежными специальностями (базовый уровень), такими как: программирование, системный анализ, дизайн интерфейсов, системное администрирование, - Руководитель группы тестирования

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

Фиксировать дефект в форме пригодной для дальнейшей работы Владеть методологией тестирования и контроля качества ПО на глубоком уровне Обеспечивать и оценивать тестовое покрытие Владеть одной или несколькими смежными специальностями (базовый уровень) Владеть методологией разработки ПО Владеть современными методами управления Ноябрь 23, 2011

Комментариев: 3

1. Taras написал: 24 Ноябрь 2011

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

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

2. SALar написал: 25 Ноябрь 2011

Да легко: {http://software-testing.ru/books/44-review/1392-2011-07-07-11-29-47}

3. StasLeo написал: 13 Февраль 2012

И я вот пытался у наших тестировщиков узнать, а есть ли какая-то “теория тестирования” окромя здравого смысла, которым я руководствуюсь строя и деплоя софт, четкого ответа не получил.

гнать их надо, если они не, то что не знают теории, они еще и не знают о ее существовании.

103. Правила нарушения трудовой дисциплины

В первый раз публиковалось на 1 апреля, так что -

С другой стороны, можно использовать как шаблон (рыбу) для написания регламентов, подобно "СМК от питерских"

----------------

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

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

Совершение таких проступков есть неотъемлемое право и, более того, обязанность каждого.

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

Соответственно:

Каждый сотрудник должен каждый месяц совершить несколько проступков. Например:

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

Если сотрудник уличен в не совершение нарушений трудовой дисциплины в течении месяца, офис менеджер обязан в последний день месяца пресечь попытки проникновения без опоздания на территорию офиса. Далее, сотрудник должен быть отправлен в магазин (достаточно далеко отстоящий). Опоздав не менее, чем на положенные 16 мин сотрудник должен прошествовать на свое рабочее место скандируя:

Свободу Анжеле Девис!

От Анжелы Девис руки!

Дайте свободу Анжеле,

Дайте свободу буки!!!

Каждый сотрудник имеет право оказать посильную помощь в разработке правил нарушения дисциплины.

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

Декабрь 19, 2011

104. Идеальная техническая система

- Это когда системы нет, а ее функция выполняется.

© ТРИЗ

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

Действительно, множество растущих команд (компаний) в какой-то момент сталкиваются примерно с одной и той же проблемой. Список дефектов растет и в какой-то момент требуется специализированное средство для управления порядком исправления. С пятком багов можно легко справиться при помощи почтового клиента. Полсотни багов можно вести в Excel. Но когда их пара тысяч – это уже многовато. И каждый «настоящий» инженер по качеству ПО (в просторечии тестировщик) знает, что по-настоящему бороться за качество без бактрекера нельзя. Это догмат. Доктрина веры. Нет бактрекера – нет настоящих инженеров по качеству ПО. Чистая кристальная истина, в которой нельзя усомниться ни на секунду, как нельзя не услышать звук хлопка одной ладонью. А если 20 лет назад выпускались великолепные программы, без использования багтрекинга, то это просто ошибка наблюдения.

Но иногда встречаются «не настоящие».

Из книги Мэри и Тома Поппендик «Бережливое производство программного обеспечения»:

…возможны две разновидности контроля: контроль с целью обнаружения дефекта (когда он уже имеется) и контроль с целью его предотвращения…

Системы …[багтрекеры] – это очереди незавершенных работ; если угодно, очереди работ, … [на] исправление. Очень часто мы полагаем, что если дефект помещен в очередь, все в порядке, он уже никуда не денется. Однако с точки зрения концепции бережливой разработки программного обеспечения, очереди – это коллекторы непроизводительных затрат. Целью является не иметь в очереди ни одного дефекта, а еще более «целесообразная цель» - не иметь такой очереди совсем. Если вы считаете, что это невозможно представить, познакомьтесь с трехгодичным опытом работы Нэнси Ван Шундерворт над проектом по разработке сложного и часто изменяющегося встроенного программного обеспечения. За три года был в целом обнаружен 51 дефект после блочного (или модульного) тестирования, причем каждый раз выявлялось не более двух дефектов сразу. Кому нужна система отслеживания для всего двух дефектов?

Примечание. Перевод я немного поправил. Совсем чуть-чуть. Только явные ляпы.

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

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

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

Спасибо Мери и Тому Попендик, Элияху Голдратту, Тайичи Оно и Капитану Очевидность.

Декабрь 26, 2011

Комментариев: 10

1. Sergey Vysotsky написал: 27 Декабрь 2011

Challenge your assumptions хорошая эвристика, да. Не только для тестирования.

В частности, предположение о том, что основной артефакт — это "список расхождений между ожиданиями и реальностью" (для краткости "багрепорты") так же стоит подвергнуть сомнению. Причем основательно, т.к. "ожидания"

2. SALar написал: 27 Декабрь 2011

> -так же стоит подвергнуть сомнению. Причем основательно, т.к. “ожидания”

Подвергайте. Для того блоги и существуют. [;-)]

Что касается термина "ожидания", то он более точен, нежели "требования". Здесь я использовал нотацию Коберна, которая расширяет модель Якобсона "Акторы и цели". Это более точно, но чуть менее понятно, т.к. требует от читателя знания нотации. Видимо, стоило поступиться точностью в пользу понятности.

3. Pollyanna написал: 27 Декабрь 2011

> "Целью является не иметь в очереди ни одного дефекта, а еще более «целесообразная цель» - не иметь такой очереди совсем."

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

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

4. Sergey Vysotsky написал:27 Декабрь 2011

Там продолжение с треугольником было. Оно почему-то не попало. По сути требования тоже ожидания, просто вполне конкретных лиц, а не всех кого нужно/можно.

5. SALar написал: 28 Декабрь 2011

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

Спасибо, Кэп.

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

> а в том, чтобы уменьшить затраты и увеличить прибыль.

Хочу вас огорчить. В современной разработке софта уменьшение затрат очень слабо сказывается на прибыли. А вот уменьшение времени выполнения заказа сильно.

> Уменьшение затрат путем ликвидации очереди дефектов оказалось возможно в специфическом случае (встроенное ПО, упомянутое в посте). Но у меня вызывает сомнение, что описанный подход применим ко всякому ПО.

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

> Очень много проблем возникает на уровне интеграции модулей. И на системном уровне. И при взаимодействии с окружением. И так далее.

И что? Их что нельзя искать более высокоровневыми юнит тестами?

> И исправлять все дефекты может быть просто не нужно, т.к. затраты на исправление себя не окупят.

Здесь я просто отсылаю вас к книге Деменга "Выход из кризиса". Как вариант, используйте подход: "Если баг не надо править, то его не надо фиксировать".

> Кроме того, возможность иметь историю дефектов, пусть даже уже исправленных, может пригодиться, если вы проводите у себя post mortem анализ или используете наработки из одного проекта в другом.

Здесь зависимость должна быть обратная. Пост мортен анализ нужен для предотвращения дефектов, а не дефекты нужны для анализа. Не путайте причину и следствие.

6. Pollyanna написал: 28 Декабрь 2011

Мне кажется, что мы говорим о разных вещах.

Я утверждаю, что иметь баг-трекер, записывать в него обнаруженные дефекты и отслеживать их судьбу целесообразно. Потому что:

1) в сложных системах дефектов много, больше, чем 2 открытых одновременно. Помнить их все ни один человек не сможет. И помнить их все точно не смогут все заинтересованные лица (менеджер проекта, заказчик, разработчик, тестировщик и пр.). И уж, конечно, ни один человек не сможет помнить все шаги воспроизведения всех дефектов. Баг-трекер сохраняет эту информацию.

2) если в проекте задачи на программистов распределяет тех лид или ПМ, он должен сначала ознакомиться с дефектом, а потом передать его ответственному за этот модуль программисту. Без баг-трекера тестировщик вынужден был бы бегать все время в ПМу, к программисту и каждый раз пересказывать суть дефекта и шаги его воспроизведения. Лучше написать отчет в трекер один раз.

3) запись о дефекте (шаги воспроизведения, логии, скриншоты) позволяет программисту

приступить к исправлению тогда, когда ему удобно, а не бросать работу посредине, чуть только тестер подбежал с очередным багом (уж не говорю о распределенных командах, там вообще был бы швах)

4) запись о дефекте позволяет тестировщику проверить исправление этого дефекта. И сделать это в удобное время (например, в следующей запланированной сборке), а не заставлять программиста пересобирать и выдавать новый билд после каждого бага.

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

>“прибыль, получаемая за продукт. ” - это конечная цель. В бизнес-анализе принято выстраивать иерархию (или граф) целей. “пустая очередь багов” - хорошая промежуточная цель, замечательно транслирующаяся на “ту самую”.

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

> Хочу вас огорчить. В современной разработке софта уменьшение затрат очень слабо сказывается на прибыли. А вот уменьшение времени выполнения заказа сильно.

Тогда вы сами подтверждаете, что отказ от баг-трекера нецелесообразен.

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

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

> Очень много проблем возникает на уровне интеграции модулей. И на системном уровне. >И при взаимодействии с окружением. И так далее.

> И что? Их что нельзя искать более высокоровневыми юнит тестами?

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

> И исправлять все дефекты может быть просто не нужно, т.к. затраты на исправление себя не окупят.

> Здесь я просто отсылаю вас к книге Деменга “Выход из кризиса”. Как вариант, используйте подход: “Если баг не надо править, то его не надо фиксировать”.

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

> Кроме того, возможность иметь историю дефектов, пусть даже уже исправленных, может пригодиться, если вы проводите у себя post mortem анализ или используете наработки из одного проекта в другом.

> Здесь зависимость должна быть обратная. Пост мортен анализ нужен для предотвращения дефектов, а не дефекты нужны для анализа. Не путайте причину и следствие.

Я не путаю причину и следствие. Не дефекты нужны для анализа, а сведения о них. Речь о том, что если проблемы были и документировались, у вас будет больше материала для post mortem анализа, чем если дефекты все равно были, но не документировались.

7. SALar написал: 29 Декабрь 2011

> 1) в сложных системах дефектов много, больше, чем 2 открытых одновременно.

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

> 2) если в проекте задачи на программистов распределяет тех лид или ПМ, он должен сначала ознакомиться с дефектом,

Зачем вам простой диспечер за такую зарплату?

> 3) запись о дефекте (шаги воспроизведения, логии, скриншоты) позволяет программисту

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

Что противоречит парадигме "останов линии", применяемой Тойота. Но к их уровню нам еще идти и идти.

> 4) запись о дефекте позволяет тестировщику проверить исправление этого дефекта. И сделать это в удобное время (например, в следующей запланированной сборке), а не заставлять программиста пересобирать и выдавать новый билд после каждого бага.

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

> 5) баг-трекер позволяет планировать исправление дефектов. Например, вы решаете, что в ближайшие 3 дня фиксим все критические и важные дефекты (и вы видите их конкретный список), а минорные со следующей недели (и вы видите другой конкретный список). Или мы решаем выпустить продукт раньше, т.к. остались только минорные баги, заказчик с ними ознакомился и согласен принять, зато выйти на рынок пораньше.

Есть такой подход. Но мы говорили о другом подходе. Когда правятся все дефекты.

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

Тема для отдельной, очень большой статьи.

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

Угу. Это аналог связанного капитала из мира материального производства. Смотри "Цель" ("та самая цель") Голдратта. Голдратта в любом случае нужно почитать. Хотя бы пару книг.

> Нельзя. Юнит тесты – это низкоуровневые тесты. Далеко не всегда их достаточно. Если ПО сложное, то отказ от высокоуровнего тестирования может привести к пропусканию критических багов в релиз.

В примере именно сложное ПО. Сложность встроенного ПО весьма и весьма высока. Кроме того Юнит тесты могут быть весьма высокоуровневыми. Некоторые авторы называют их компонентными.

> Книгу нашла, около 400 стр, на досуге почитаю. Если вы подскажете, в каком разделе раскрыта тема,

ЕМНИЛ, она распределена по книге. Посыл, который я имел в виду: "Не бывает достаточно высокого уровня качества". Главу, где разбирается функция Тагути читайте особенно внимательно.

> речь о том, что если проблемы были и документировались, у вас будет больше материала для post mortem анализа, чем если дефекты все равно были, но не документировались.

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

8. Sergey Vysotsky написал: 11 Январь 2012

> Здесь зависимость должна быть обратная. Пост мортен анализ нужен для предотвращения дефектов, а не дефекты нужны для анализа. Не путайте причину и следствие.

Кстати, не соглашусь. Он еще полезен для обнаружения других дефектов (root cause analysis местами). Это как стратегия работы с багами, найденными в процессе регресионных тестов - можно чинить симптомы, а можно саму проблему. Только саму проблему еще нужно обнаружить, что без симптомов сделать проблематично.

> Кроме того Юнит тесты могут быть весьма высокоуровневыми

Не надо вносить путаницу в и без того весьма шаткую терминологию. {http://www.salientblue.com/blog/?p=343}

9. SALar написал: 12 Январь 2012

> Это как стратегия работы с багами, найденными в процессе регресионных тестов - можно чинить симптомы, а можно саму проблему.

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

И где у нас противоречие, коллега?

10. Sergey Vysotsky написал: 15 Январь 2012

Вопрос простой - как работать с историей? Багтрекер по идее и есть эта история.

Симулятор прохождения заказов по производственным цепочкам

Видео: http://www.youtube.com/watch?feature=player_embedded&v=HQHt01e3Lns

Виртуальная машина с предустановленным софтом: http://www.oracle.com/technetwork/middleware/soasuite/learnmore/vmsoa-172279.html

Поиграл 10 минут. Штука очень любопытная. Однозначно "обязательна для изучения". Не выясненные моменты:

* Есть ли возможность установить связь между временем выполнения заказа и его стоимостью?

* Есть ли расчет потерь, связанных со связанным капиталом?

* Есть ли вообще расчет прибыли/убытка?

* Можно ли сделать несколько точек старта и финиша (для имитации потоков V,A,T типа)

И т.д. и т.п.

Коллеги, кто-нибудь изучал этот симулятор?

Январь 10, 2012

105. Никто тебя не должен развивать?

Нужны ли тренинги по развитию сотрудников? Кто должен их инициировать? Как выделять время? Кто оплачивает?

Мнения на этот счет есть. И они очень разные, эти мнения.

Есть мнения, что тренинги - это часть компенсации.

- При приеме на работу мы сообщаем сотрудникам, что они могут сами набрать тренингов на определенную сумму в течение года. Это неплохо стимулирует и мотивирует.

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

- Мы их научим, а они уйдут

- Будет хуже, если вы их не научите, а они останутся.

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

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

Или:

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

Но, споря, коллеги приводят доводы за и против принципиально разных тренингов.

- Что значит выражение: "В огороде бузина, а в Киеве дядька!"?

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

Синонимичное выражение, но с несколько другим оттенком: "Я тебе про Фому, а ты мне про Ерёму".

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

Но хотелось не только играть в бисер, но и делом иногда заниматься. Нужна стройная система. Хотя бы относительно стройная. Задумаемся: а где собственно этот вопрос может быть раскрыт достаточно хорошо? Разумно покопаться в книгах великих менеджеров. Не буду развивать интригу, ответ есть в работах Деминга. К сожалению, книга «Выход из кризиса» написана достаточно тяжеловесным языком, поэтому откроем книгу Генри Нива «Пространство доктора Деминга» (недавно эта книга была переиздана под другим, очень странным названием «Организация как система»). Нам нужны главы 24 и 31.

Глава 24. Пункт 6: введите в практику подготовку и обучение персонала на рабочем месте. Глава 31 Пункт 13: поощряйте стремление к образованию Так. Появилась классификация. Но мало того, рекомендуемые действия организации различны для разных процессов (спасибо Кэп).

Подготовка и обучение:

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

Образование:

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

Полагаю, что обучение - это очень, очень выгодное для организации вложение денег.

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

Для справки. Сертифицированный менеджер теряет свой сертификат PMP, если за полтора года он тратит на свое образование менее 80 часов. Что логично. Я полагаю, что-то же самое верно и по отношению к инженерам. Инженер, не получающий образования, – деградирует. Вашей компании нужны лузеры?

Если сотрудник стремится к образованию, то следует, как минимум, не мешать ему.

А диалог:

- Ну, я хочу прочитать книгу про нагрузочное тестирование…»

— А нафига оно тебе?

- Нуууу, я хочу стать более профессиональным тестировщиком, чем сейчас…

— А в функциональном тестировании ты уже все Джомолунгмы покорил? И как часто ты будешь заниматься нагрузочным тестированием на своем проекте? Оно у вас вообще применяется?

- Нет, не применяется, но…

Согласно Демингу следует признать совершенно неприемлемым.

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

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

S. В книге описано Генри Нива еще много тонкостей, связанных с обучением и образованием. Рекомендую.

Февраль 20, 2012

Комментариев: 5

1. Sergey Vysotsky написал: 21 Февраль 2012

Слишком тонкая грань между знаниями и навыками:

1. Есть навыки, наработка которых занимает сильно больше чем 2 года (преподавательские?)

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

3. Есть опыт, который банально нарабатывается. Это знание, но знание, которое в ряде случаев получить можно только на практике.

4. Знание без практики в большинстве случаев бесполезная штука, т.к. всегда нужно допиливать под контекст.

2. ytrewq написал: 28 Февраль 2012

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

Проблема опыта в том, что среднестатистический необразованный (в области своего труда) опытный работник склонен считать, что о предмете своего труда обладает полным знанием. Обычно это не так.

3. Sergey Vysotsky написал: 21 Март 2012

Если нет грани, то и разграничивать не надо. А эффект "Эффект Даннинга-Крюгера" в равной степени относится и к недостаточному уровню навыков, т.е. среднестатистический образованный работник тоже склонен переоценивать свои возможности.

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

4. SALar написал: 21 Март 2012

Есть разница между обучением и образованием. И ее нужно понимать.

5. ytrewq написал: 22 Март 2012

> Если нет грани, то и разграничивать не надо.

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

> в равной степени относится и к недостаточному уровню навыков

Но отсутствие образования опаснее отсутствия навыков и опыта, именно вследствие эффекта Даннинга-Крюгера.

> пытаться исправить причинами, его порождающими по меньшей мере странно.

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

106. Краткий план типового рассказа про Agile

Просмотрев десятки книг и докладов по Agile, я выделил некую типовую последовательность изложения. Она встречается во многих докладах и книгах в той или иной форме. Чтобы помочь будущим докладчикам и писателям я составил краткий план. Пользуясь им, вы сэкономите кучу времени. И у меня просьба. Делайте ссылку, соответствует ваш доклад (книга) этому плану. Если это возможно.

- План ---------

1. Для начала немного истории - для тех, кто не в курсе. Agile методологии разработки родились в противовес классическим моделям, в которых результата пытались достичь за счет процессов, процедур и регламентов.

2. Естественно получалось фуфло.

3. Мы у себя внедрили Agile.

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

5. - Далее перечисляется некий набор процессов, процедур и регламентов, в зависимости от автора.

- Конец плана ------

Коллеги, это только я вижу некое несоответствие в этих пунктах?

Март 12, 2012

Комментариев: 10

1. Anthony Marchenko написал: 13 Март 2012

моему не совсем соответствует - «Опыт внедрения Канбан в продуктовой компании» [:)]

1. рассказ про компанию.

2. рассказ почему мы отказались от скрама.

4. То, что осталось - назвали Канбан.

То есть как мы эволюционировали. Как было хорошо, и как мы сделали ещё лучше.

Ни хочу показаться не вежливым, (только что вернулся из AgileIndia2012.in), но все доклады, которые делали индусы, полностью соответствуют вашему плану. В американских же докладах, больше было про Programmer Anarchy и старательно избегали слово Agile.

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

2. Григорий Печенкин написал: 13 Март 2012

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

3. SALar написал: 13 Март 2012

> 4. То, что осталось - назвали Канбан.

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

> но все доклады, которые делали индусы, полностью соответствуют вашему плану

LOL.

> как мы отказались от диктатуры, и пришли к демократии

А не подскажете методологию, которая предполагает диктатуру? Мне на ум кроме XP ничего не приходит. XP - очень жесткая, диктаторская методология.

4. Apoheliy написал: 14 Март 2012

Убираем слова "процессы, процедуры, регламенты" в п.1 - и жизнь налаживается [:)] . В смысле, план становиться живее.

2.Григорий Печенкин:

Можно добавить, что мух было всего 3.

2.SALar

Можно вспомнить про WaterFall - тоже с диктатурой дружит [:)]

2.255:

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

1. Для начала - немного истории: WaterFall используется в противовес Agile.

2. Мы использовали Agile - и получилось фуфло. YAGNI в паре с KISS - и разработка/тестирование из уютного офиса переносится на 'объект'. И blah-blah-blah, и всё недоделано, и blah-blah-blah, и всё нестабильно -

3. Мы внедрили WaterFall с примесью Инкремента и др.

4. А сейчас я расскажу о классных процедурах -

5. - Далее в зависимости от автора -

6. И назвать методологию 'Канбан' [:)]

5. SALar написал: 14 Март 2012

> Можно вспомнить про WaterFall - тоже с диктатурой дружит

С какой радости? Вы статью Ройса читали или вам ее "консультанты" пересказали? Ройс довольно много говорит о людях. В отличии от "псевдоконсультанотов".

> WaterFall используется в противовес Agile.

Какая чушь. Аж уши в трубочку сворачиваются.

Сам Ройс описал итеративную модель разработки. Кроме того, WaterFall это ЖЦ, а ни разу не методология. Не надо подобно "консультантам/тренерам/коучам" путать теплое с мягким. ЖЦ класса WaterFall, даже не итеративный Ройсовский, а однопроходный "консультантовский" вполне можно использовать в Agile. Да, это противоречит Scrum и XP, но на них свет клином не сошелся. Agile манифест ничего не говорит о выборе ЖЦ. Какой удобней, такой и используй.

> 6. И назвать методологию ‘Канбан’

А за это нужно вообще гнилыми помидорами кидаться.

6. ytrewq написал: 15 Март 2012

> WaterFall используется в противовес Agile.

как выглядит знакомо.

Википедия (статья Гибкая методология разработки) гласит: В феврале 2001 в штате Юта США был выпущен Манифест гибкой методологии разработки ПО. Он являлся альтернативой управляемым документацией, «тяжеловесным» практикам разработки программного обеспечения, таким как «метод водопада», являвшимся золотым стандартом разработки в то время.

Где-то здесь перепутано теплое с мягким, я пока ленюсь разбираться, где. Нно я разберусь. Ройса прочту вдумчиво.

7. Apoheliy написал: 16 Март 2012

Э-э-э, как бы помягче сказать, здесь не Ройса обсуждают [:)] И то, что Ройс использовал итеративную модель означает примерно "в огороде бузина". В любом случае (вне зависимости, прав я или нет) хотелось бы аргументации, почему водопад не дружит с диктатурой.

8. Apoheliy написал: 16 Март 2012

2SALar: Про не-идеализацию Ройса написал ранее.

Про WaterFall соглашусь, что в основном про него говорят, как про ЖЦ. Хотя про него же говорят и как про метод/практику разработки ПО (управление документацией, и др.).

Если рассматривать сам Agile (а именно - манифест), то из него (как Вы правильно отмечаете) вообще мало что можно вывести. Однако, IMHO:

- WF говорит про важность процесса (а не людей);

- WF даёт рабочий продукт после этапов интеграции и, однозначно, после созданной документации (в Agile-манифесте - наоборот);

- WF очень сильно ориентирован на контракт и его ЖЦ не предполагает изменений (и это тоже против Agile);

Поэтому противопоставление этих понятий вполне возможно (IMHO). Ваше мнение?

PS: Канбан - это шутка, помеченная знаком ':)' [:)]

9. Apoheliy написал: 16 Март 2012

2SALar: на WaterFall есть стандарт IEEE Std 1074 лучше оценивать по нему, а не по Ройсу.

10. SALar написал: 18 Март 2012

> - WF говорит про важность процесса (а не людей);

Ройс очень много говорил про людей. Это вы скорее про дальнейших "интерпретаторов". Но. Но.Но.

Асхат Уразбаев на всех докладах, на которых я был, говорит про процессы, процессы и процессы. Исходя из этого- Ну вы поняли.

> (в Agile-манифесте - наоборот);

Это неправда. В манифесте не запрет, а смещение акцентов важности.

> WF очень сильно ориентирован на контракт и его ЖЦ не предполагает изменений

Это не совсем правда. Здесь лучше перечитать статью Ройса.

Кстати. Существует масса способов работы с изменениями. Запрет на изменения один из них. Вполне нормальный.

107. Рекомендации к чтению

На прошлой неделе в фирму прибыло несколько килограммов книг.

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

Заказывали не все, что хотели. Решили поумерить аппетит.

Прибыло не все, что хотели (некоторых книг нет в продаже).

Часть книг уже разобрали.

Это сообщение создано Среда, Апрель 18, 2012

108. Пример плана тестирования

Предисловие.

Я несколько лет применяю документы, подобные этому. Иногда пишу их в другой форме. Иногда пишу исключительно для собственного пользования (не показываю остальным участникам проекта).

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

Пробуйте. Возможно вам этот тип документа окажется полезен. А может и нет.

Да еще. Размер и форма должны выбираться в зависимости от размера и типа проекта. Расширенная форма, приведенная ниже неплохо подходит для проектов размером "десятки человеколет" - "несколько человековеков". Для проекта поменьше я использовал форму "две страницы А4 цветными ручками в тетради". Тоже хорошо работало. Не факт, что приведенный ниже документ использовался в реальном проекте. Но факт, что использовались похожие документы.

Термин "план" используется в значении близком к «стратегии». Это не календарный график и не перечень тестовых примеров.

План тестирования системы

Версия 1.1

История исправлений

Дата Версия Описание Автор

02.01.20хх 1.0 Создан

07.01.20хх 1.1 Подготовлен черновик

Содержание

1 Введение;

1.1 Цель;

1.2 Состав документа;

1.3 Нотации, аббревиатуры и определения, принятые в документе;

1.4 Комплексные показатели качества по ГОСТ Р ИСО/МЭК 9126-93;

1.5 Ссылки

2 Идентификация объектов тестирования

3 Стратегия тестирования

4 Виды проводимых тестов

4.1 Функциональное тестирование

4.2 Тестирование бизнес цикла

4.3 Конфигурационное тестирование

4.4 Тестирование производительности

4.5 Стресс тестирование

4.6 Юзабилити тестирование

4.7 Тестирование инсталляции

5 Требования к численности и квалификации персонала

5.1 Оценка объема работ

5.2 Распределение по ролям и квалификации

6 Необходимые ресурсы

6.1 Программные средства

1 Введение

1.1 Цель

Цель документа "План тестирования системы" - координация усилий участников проекта в части контроля качества.

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

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

1.2 Состав документа

Документ содержит описание общих для подсистем стратегии, подходов и видов тестов. Также определяет численные и квалификационные требования к персоналу, необходимые для успешного тестирования; необходимое программное и аппаратное обеспечение.

Информация, специфическая для отдельных подсистем, описывается в отдельных планах тестирования для каждой конкретной подсистемы.

1.3 Нотации, аббревиатуры и определения, принятые в документе

TBD (To Be Defined) - будет определено в дальнейшем. Указывает, что данный раздел документа еще не разработан.

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

Описание дефекта - формализованное описание, составленное в той или иной системе учета дефектов. Дефект существует вне зависимости от того описали его или нет и от того нашли его или нет.

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

Контроль качества продукта - более широкое определение, нежели тестирование, включающее в себя, в том числе тестирование. Так например просмотр кода, также называемый code review или статическим тестированием обеспечивает контроль такой метрики как "Сопровождаемость -> Изменяемость" (в классификации ГОСТ 9126), но при этом не используется прогон программы. Кроме, собственно, программы (исполняемого кода) контролю качества подвергаются другие конечные артефакты: руководство пользователя, руководство администратора, …

Также может контроль качества может применяться не к конечным, а рабочим артефактам (ЧТЗ, прототипы интерфейсов, …)

QA (Quality assurance) - работы по улучшению и поддержанию процессов, контролю соответствия процессам. Не имеют отношения к тестированию.

Метрика программного обеспечения (англ. software metric) - это мера, позволяющая получить численное значение некоторого свойства программного обеспечения или его спецификаций.

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

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

Тестирование методом свободного поиска (exploratory testing) - также называется тестированием на основе сеансов. Не предполагает жестко заданных, формализованных сценариев тестирования. Часто, проводится в парах.

1.4 Комплексные показатели качества по ГОСТ Р ИСО/МЭК 9126-93

А.2.1 Функциональные возможности (Functionality)

А.2.1.1 Пригодность (Suitability)

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

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

А.2.1.2 Правильность (Accuracy)

Атрибуты программного обеспечения, относящиеся к обеспечению правильности или соответствия результатов или эффектов.

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

А.2.1.3 Способность к взаимодействию (Interoperability)

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

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

А.2.1.4 Согласованность (Compliance)

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

А.2.1.5 Защищенность (Security)

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

А.2.2 Надежность (Reliability)

А.2.2.1 Стабильность (Maturity)

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

А.2.2.2 Устойчивость к ошибке (Fault tolerance)

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

Примечание - Определенный уровень качества функционирования включает возможность отказобезопасности.

А.2.2.3 Восстанавливаемость (Recoverability)

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

А.2.3 Практичность (Usability)

А.2.3.1 Понятность (Understandability)

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

А.2.3.2 Обучаемость (Learnability)

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

А.2.3.3 Простота использования (Operability)

Атрибуты программного обеспечения, относящиеся к усилиям пользователя но эксплуатации и оперативному управлению.

А.2.4 Эффективность (Efficiency)

А.2.4.1 Характер изменения во времени (Time behavior)

Атрибуты программного обеспечения, относящиеся к временам отклика и обработки и к скоростям выполнения его функций.

А.2.4.2 Характер изменения ресурсов (Resource behavior)

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

А.2.5 Сопровождаемость (Maintainability)

А.2.5.1 Анализируемость (Analysability)

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

А.2.5.2 Изменяемость (Changeability)

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

А.2.5.3 Устойчивость (Stability)

Атрибуты программного обеспечения, относящиеся к риску от непредвиденных эффектов модификации.

А.2.5.4 Тестируемость (Testability)

Атрибуты программного обеспечения, относящиеся к усилиям, необходимым для проверки модифицированного программного обеспечения.

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

А.2.6 Мобильность (Portability)

А.2.6.1 Адаптируемость (Adaptability)

Атрибуты программного обеспечения, относящиеся к удобству его адаптации к различным конкретным условиям эксплуатации, без применения других действий или способов, кроме тех, что предназначены для этого в рассматриваемом программное обеспечении.

А.2.6.2 Простота внедрения (Installability)

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

А.2.6.3 Соответствие (Conformance)

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

А.2.6.4 Взаимозаменяемость (Replaceabilily)

Атрибуты программного обеспечения, относящиеся к простоте и трудоемкости его применения вместо другого конкретного программного средства в среде этого средства.

Примечания

1. Взаимозаменяемость используется вместо совместимости для того, чтобы избежать возможной путаницы со способностью к взаимодействию (см. А.2.1.3).

2. Взаимозаменяемость с конкретным программным средством не предполагает, что данное средство заменимо рассматриваемым программным средством.

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

1.5 Ссылки

[1] Рекомендации по конфигурационному управлению в части инстансов (стендов)

[2] Описание стендов (аппаратная и программная части, сетевые адреса, протоколы, адреса, логины и пароли).

[3] ГОСТ 9126

2 Идентификация объектов тестирования

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

Так в частности, должно быть проведено тестирование:

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

Текущий подход к контролю качества подразумевает следующие вехи проекта:

Подсистема готова к демонстрации заказчику

Подсистема готова к промышленной эксплуатации

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

Для проверки готовности прототипа служат приемо-сдаточные испытания. Критерий готовности - акт сдачи прототипа, подписанный приемо-сдаточной комиссией. Приемо-сдаточные испытания описываются в отдельном документе. Либо как раздел шесть частного технического задания, согласно ГОСТ 34.602-89, либо в отдельном документе, содержащем программу и методику испытаний.

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

4 Виды проводимых тестов

4.1 Функциональное тестирование

Используется для контроля качества "Функциональных возможностей" в части "Пригодности", "Правильности" и "Способности к взаимодействию".

Функциональное тестирование является основным видом тестирования. Проводится вручную через интерфейс пользователя. Использование средств автоматизации в 20хх году не предполагается.

При подготовке прототипа рекомендуется использовать тестирование методом свободного поиска (exploratory testing).

При подготовке системы (подсистемы) к промышленной эксплуатации рекомендуется использовать стандартное промышленное тестирование, с оценкой полноты тестового покрытия.

4.2 Тестирование бизнес цикла

Используется для контроля качества "Функциональных возможностей" в части "Пригодности", "Правильности" и "Способности к взаимодействию".

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

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

4.3 Конфигурационное тестирование

Используется для контроля качества "Мобильности" в части "Адаптируемости"

Должна быть проверена работоспособность приложения для:

Различных видов ОС:

WinXP - обязательно Vista - обязательно Win7 - обязательно Различных БД:

MSSQL 2000 MSSQL 2005 Различных разрешениях монитора рабочего места

1280х1024 - обязательно 1600х900 - обязательно 1024х768 - желательно 1680х1050 - желательно Может проводиться как выделенный вид тестирования методом визуального контроля при выполнении юзкейсов классов read и list.

Рекомендованный метод - объединение с функциональным тестированием. В этом случае на каждом рабочем месте тестировщика рекомендуется установка своей конфигурации.

4.4 Тестирование производительности

Используется для контроля качества "Эффективности".

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

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

4.5 Стресс тестирование

Используется для контроля качества "Надежности" в части "Стабильности" и "Устойчивости к ошибке".

4.6 Юзабилити тестирование

Используется для контроля качества "Практичности" в части "Понятности", "Обучаемости", "Простоты использования".

4.7 Тестирование инсталляции

Используется для контроля качества "Мобильности" в части "Простоты внедрения".

Проводится вручную.

5 Требования к численности и квалификации персонала

5.1 Оценка объема работ

Существует несколько способов оценок трудозатрат на тестирование. Проведем оценку по числу программистов

Для системы такого класса нормальным считается что 20-25% от трудоемкости проекта приходится на тестирование. Расчеты показывают, что трудоемкость проекта порядка 300 человеколет. Следовательно, трудоемкость тестирования 60-75 человеколет. Учитывая неравномерность поглощаемой трудоемкости тестирования в зависимости от фазы проекта и целевой показатель создания системы в три года, в пике на проекте должно быть ___ тестировщиков.

5.2 Распределение по ролям и квалификации

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

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

6 Необходимые ресурсы

Рекомендации к тестовому и прочим стендам описаны в [1]. В разное время, в зависимости от потребностей, могут существовать одновременно несколько тестовых стендов.

Так для тестирования:

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

Описание стендов и прав доступа можно найти в [2]

6.1 Программные средства

Управление тестированием TrackStudio

Трекинг дефектов TrackStudio

Управление проектом TBD

Работа с BD TBD

Профилирование работы сети TBD

Профилирование работы сервера приложений TBD

Июнь 8, 2012

109. Фатальная ошибка автоматизации тестирования

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

Ерунда все это. Это всего лишь симптомы. Истинная причина краха в другом и определяется тривиально.

"Мы начали автоматизацию с регрессионного тестирования." Это приговор. Больше можно ничего не изучать и не спрашивать.

Июль 22, 2012

Комментариев: 10

1. Dmitry Zhariy написал: 23 Июль 2012

Да, автоматизация регрессионного тестирования обречена на провал.

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

Регрессионное тестирование - мануальщикам, не регрессионное тестирования - автоматизиторам.

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

А может быть просто сами регрессионные тесты небыли готовы к автоматизации?

Может быть сама архитектура фреймворка не достаточно хороша?

Может быть в регриссонном сьюте не хватало приоритетов?

Или автоматизаторы стремились автоматизировать все, вплоть до проверки что кнопочка именно красного цвета, ссылка "наверх" переводить страницу наверх, а шрифт на странице действительно 10pt?

Корень зла закопан глубже

2. Sergey Atroschenkov написал: 23 Июль 2012

Ошибка имеет место быть - если автоматизация регрессионного тестирования была наиболее экономически оправданной?

3. SALar написал: 23 Июль 2012

> если автоматизация регрессионного тестирования была наиболее экономически оправданной?

Полагаю, что такое возможно, но маловероятно. Об этом собственно и пост.

4. SALar написал: 23 Июль 2012

> Да, автоматизация регрессионного тестирования обречена на провал.

Не нужно мне приписывать то, чего я не говорил. Я ясно написал, что с нее нельзя начинать.

> Ведь намного эффективней дать автоматизитору полную свободу выбора того, что он будет автоматизировать!

Не нужно мне приписывать то, чего я не говорил. Управляет проектом или процессом руководитель. Он или SEPG определяют приоритеты работ.

> все тексты должны автоматизироваться еще до того, как они будут пройдены мануально.

Не все. Я этого не писал. Но это правильное направление.

> Регрессионное тестирование — мануальщикам, не регрессионное тестирования — автоматизиторам.

Интересное предложение. Похоже в этом есть смысл. Надо будет майндмап расписать. Спасибо за новую ветку рассуждений.

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

Не нужно мне приписывать то, чего я не говорил.

> А может быть просто сами регрессионные тесты небыли готовы к автоматизации?

> Может быть сама архитектура фреймворка не достаточно хороша?

> Может быть в регриссонном сьюте не хватало приоритетов?

Это вторично.

> Или автоматизаторы стремились автоматизировать все, вплоть до проверки что кнопочка именно красного цвета, ссылка “наверх” переводить страницу наверх, а шрифт на странице действительно 10pt?

А это собственно к чему?!

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

Для лучшего понимания тщательно перечитайте беседу Ионы и Алекса Рого из книги "Цель". Там ключ к пониманию хода рассуждения.

5. Dmitry Zhariy написал: 23 Июль 2012

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

Если у тебя есть сказать, как правильно, и что нужно делать чтобы не провалится – то напиши пожалуйста об этом.

6. SALar написал: 24 Июль 2012

Да. У меня есть, что сказать. И я собираюсь вынести mindmap на обсуждение. Сейчас я собираю новые ветки, которые я пропустил. Еще раз, вам спасибо за новую ветку. Не факт, что она правильная, но она для меня новая.

> С левой ноги вставать – это провал. Нельзя вставать с левой ноги – это фатальная ошибка

Так делают многие "эксперты" (в кавычках). Ну да, как же еще привлечь внимание. "Тестирование во вторник", "Тестирование в Agile" и прочие глупости. "SQL для дворников", "Тест менджмент для руководителей проекта" -

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

2Dmitry Zhariy У вас гарантированно бесплатный билет на обсуждение. Спасибо за новую ветку.

PS. Я не хочу повторять базу. Прочитайте "Цель" Гольдратта. Прочитайте еще несколько книг. В конце концов прочитайте: {http://habrahabr.ru/post/139194/}

Без базы нам понадобится очень много времени, чтобы начать дискутировать.

PSS. Я подозревал, что пост вызовет вопросы. "Самолет взлетает против ветра."

7. Sergey Vysotsky написал: 24 Июль 2012

> Регрессионное тестирование — мануальщикам, не регрессионное тестирования — автоматизиторам.

Неправильное предположение. Хотя бы потому что: {http://www.exampler.com/testing-com/writings/classic/mistakes.html}

Вообще беда в том, что автоматизация и мануальные тесты почему-то пересекаются в головах и делах. В итоге правила design for automation к дизайну тестов почему-то не применяется.

Регрессионные тесты сами по себе довольно паршивый способ бороться с регресионными рисками. Да и как средство по поиску багов тоже не очень (что там Марик насчитал? 15%?). Автоматические регрессионные тесты по эффективности куда хуже, потому что старый добрый minefield paradox. Автоматика с фиксированным путем плохо находит баги, но может хорошо реагировать на изменения. Можно лечить по стратегии случайности Робинсона, но это автоматизатору еще и теорию графов вспоминать придется.

Так что зачастую вполне нормальное начало - написать нормальный набор автоматических проверок (назовем их "smoke test"), который здорово облегчит Impact Analysis и позволит эффективнее и быстрее делать работу по RBT руками. Такой подход отлично укладывается в Swiss Cheese Model, кстати. Но почему-то все стараются не увеличить эффективность ручной работы и заметно ускорить ее, а тупо от нее избавиться.

8. ytrewq написал: 28 Август 2012

Как я понял, этот провокационный вывод сделан из цепочки: Начинаем автоматить регрессионные тесты - Убиваем на это уйму ресурсов - Проблем с багами и ручного тестирования не становится в разы меньше(да и не должно, ну не в разы уж точно) - Менеджмент принимается сокращать выделяемые ресурсы на автоматизацию, ибо толку никакого а ресурсы потребляет немалые - Автоматизация замедляется до неприличия - Автоматизацию сворачивают совсем(сокращением ресурсов "вылечить" ее не удалось, жалость какая) - Провал автоматизации.

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

9. SALar написал: 30 Август 2012

> Начинаем автоматить регрессионные тесты - Убиваем на это уйму ресурсов - Проблем с багами и ручного тестирования не становится в разы меньше (да и не должно, ну не в разы уж точно).

Цепочка была другая. Ее начало: "Если уж вы решились на автоматизацию регрессии, то очевидно, что изменение тестов не должно отставать от изменения кода". А дальше сами тяните.

> Кстати, литература на тему гласит - автоматизировать, наверное, в первую очередь нужно регрессионные тесты, это экономически целесообразно.

Классическое заблуждение. Повальное. Ну мифов у нас в индустрии много-

10. qatesting.ru написал: 8 Декабрь 2012

Да уж, мифов в тестировании, а особенно в автоматическом, хватает. Некоторые из них опровергает, в частности, Адам Гаучер: http://qatesting.ru/blog/articles/2012/11-21-six-shocking-automation-truths

110. Метрики в тестировании

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

Сразу предупреждаю, что эти метрики нельзя использовать для оценивания конкретных тестировщиков. Это метрики процесса тестирования. Более того, это метрики процесса тестирования, которые должны анализироваться с учетом контекста: уровня процесса конфигурационного управления, уровня процесса разработки требований, сложности программы, расположения ограничения системы и т.д. Если в вашей группе тестирования метрики окажутся "не очень", то совершенно необязательно, что это проблема процесса тестирования и уж тем более не обязательно, что это проблема конкретных тестировщиков. Вполне вероятно, что корневую причину возвратов с пометкой "не воспроизводится" нужно искать в процессе конфигурационного управления. Так что мерять, меряйте, но поспешных выводов не делайте.

Примечание. Я исхожу из чрезвычайно редко используемой модели "риск-оптимумов", которая подразумевает, что слишком хорошие показатели должны инициировать аудиторскую проверку, точно так же, как слишком плохие. Более подробно, но тоже очень коротко, описано в моей статье "Различные подходы к риск менеджменту. Краткий экскурс."http://www.software-testing.ru/library/around-testing/engineering/208 Так же где-то было видео с семинара на эту тему. Ну, или гуглите. Шутка. Материалов на русском, считайте, что нет.

Понятно, что эти цифры не стоит применять к проектам "for fun / just for lulz" или "угроза жизни". Понятно, что цифры будут плавать в зависимости от размера проекта. Давайте будем считать, что мои оценки относятся к типичным корпоративным информационным системам, юзкейсов на 500.

PS. Я бы пособирал статистику по фирмам, но как правило, ее или не ведут, или это: "Очень страшный секрет, потому что у нас все плохо".

Август 22, 2012

Комментариев: 5

1. Vasya написал: 26 Август 2012

У меня 537 багов с 26 августа 2011 по 26 августа 2012. Естественно, что-то отклонили.

2. SALar написал: 27 Август 2012 в 10:32

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

3. Mikhail написал: 28 Июнь 2016 в 13:34

Оооочень странные метрики. Кроме "качества поиска" вообще не понимаю, что показывают остальные- И зачем они.

4. SALar написал: 28 Июнь 2016

2Mikhail

Да. Без понимания теории ограничений понять необходимость этих метрик довольно сложно. Теория ограничений противоречит "здравому смыслу" и поначалу сильно сносит мозг.

111. Классификация видов автоматизированного функционального тестирования

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

На мой скромный взгляд (IMHO), безоглядное, чуть ли не повальное увлечение автоматизированным тестированием через GUI не слишком оправдано. Хотя сама по себе автоматизацию вполне имеет право на существование. "Потому что функциональное автоматизированное тестирования бывает разное" (с) Капитан Очевидность. "И в зависимости от ситуации оправдано применение того или иного" и снова спасибо Кэпу.

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

* "кто пишет. [программист | тестировщик]";

* "когда. [до кода (test first) | плюс-минус пара минут от кода (TDD) | после кода (регрессионное тестирование)]";

* "кто выполняет: [программист | тестировщик]";

* "интерфейс [GUI | API]".

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

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

Лирическое отступление. Почему эти тесты и наиболее бестолковые, и наиболее популярные одновременно? Как один из вариантов объяснения: "Это позволяет тестлиду раздуть команду". Действительно, пусть для того, чтобы продукт "N" стал хорошим, в нем нужно найти и исправить 2000 дефектов. И сделать это надо в течение года. При мануальном тестировании нормальная "цена" нахождения 1000 дефектов - это один человекогод. Значит нужно двое тестировщиков. С учетом неравномерности загрузки трое-четверо. А вот если ввести 100% автоматизацию посредством тесткомплита или там селениума, то понадобится уже 10-20 человек. Если же тестлид по-настоящему талантлив, то при поиске следующей работы в его резюме будет красоваться гордая надпись: "Руководил отделом автоматизации тестирования в 50 человек". Ну, понятно продавать себя надо уметь. Этому сейчас даже учат. Оно конечно можно налететь на грамотного рекрутера, который воскликнет: "Восхитительно! А позвольте полюбопытствовать, сколько дефектов за год нашли эти замечательно бравые полсотни человек?"

Но не будем искать злой умысел там, где достаточно простых объяснений. Причины могут быть и другие. Ведь на первый взгляд все выглядит просто замечательно. Мы покроем тестами всю функциональность и при выпуске новой версии эти тесты будут быстро находить дефекты. Прямо-таки идиллия. А теперь откинемся на диван и немного подумаем. Думать тоже иногда надо (правда думать нужно уметь). Говорят, это помогает. С чего бы тесты будут находить ошибки? Наверное, потому, что изменилась функциональность (спасибо Кэпу). Но если изменилась функциональность, то, наверное, нужно на конкретно эту функциональность поменять тесты? Логично. Смотрите, что получается:

1. Софт ушел на тестирование, а тестировщики вместо того, чтобы предоставить информацию о дефектах начинают лихорадочно править тесты. Учитывая, что написание кода тестов сравнимо с написанием собственно кода, софт проведет в очереди довольно много времени. Это потери. Это ухудшение потока.

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

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

Т.е. перед тем как внедрять {пишет тестировщик; когда.после кода; выполняет.тестировщик; интерфейс.GUI} внедрите {пишет.тестировщик; когда.до кода; выполняет.программист; интерфейс.GUI}. Такой подход действительно по-настоящему эффективен. Из третьих рук я слышал, что по-настоящему эффективная фирма (годовой проход в расчете на сотрудника порядка $1 000 000) придерживается именно этого подхода. Конечно, чтобы перейти к такому методу нужно серьезно поднять культуру разработки, что уже само по себе сильно помогает (спасибо Кэп). Придется внедрить стандарт именования локаторов, что дополнительно сделает тесты нехрупкими (Кэп?! но как вы догадались?!). Придется ввести процедуру проектирования пользовательского интерфейса, что дополнительно сильно улучшит качество ПО. Вообще такой подход прямо-таки вынуждает "мыть руки перед кодированием". Если начать с него, то потом можно и о регрессионном тестировании подумать. База тестов-то в любом случае останется.

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

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

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

Посылка 2. Человек склонен откладывать "на потом" (на практике "навсегда") то, что он умеет не слишком хорошо.

Вывод. Кодеры будут стараться отказаться от практики юнит тестирования.

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

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

Прежде чем двинуться дальше стоит сказать вот о чем. Капитан О: "API оно разное бывает". Под юнит тестированием часто подразумевают тестирование отдельных классов и функций. Но гораздо интереснее, когда речь идет об интерфейсе предоставляемым сервисом и/или компонентом. Будет это SOAP, или обмен по ftp, или еще что-то не слишком важно. Чем большим оказывается число компонент и/или сервисов использующих один и тот же интерфейс, тем выгоднее становятся тесты {пишет.???; когда.до кода; выполняет.не важно; интерфейс.API}. Сначала спроектировать и описать протокол, потом тесты и только потом код. Так делать выгодно. Более того иногда это чуть ли не единственный способ сдать проект. Но об этом явно в другой статье.

PS. Я рассмотрел только интересные с моей точки зрения виды тестов. Классификацию можно расширить и рассмотреть еще какие-то виды. Но потом.

PSS. Я убежден, что найдется множество людей, которые выступят в защиту тестов вида: "{пишет.тестировщик; когда.после кода; выполняет.тестировщик; интерфейс.GUI}". Вероятно, они будут приводить казуистические доводы типа: "Эти тесты не для того, чтобы находить ошибки, а для того чтобы предотвратить их попадание в продакшен". Мой ответ: "сами поняли, чего сказали? Не поняли, так идите перечитайте." И встречный ответ. Производительность таких автотестов считается очень простым способом - это число дефектов, найденных при прогоне этих тестов деленное на число человеколет вложенных в разработку и поддержку этих тестов. Какая у вас производительность? 20 дефектов на выброшенный год? Свободны. Это смешно.

Сентябрь 6, 2012

Комментариев: 3

1. Sergey Vysotsky написал: 15 Сентябрь 2012

> А позвольте полюбопытствовать, сколько дефектов за год нашли эти замечательно бравые полсотни человек?

Это попытка оценить тестировщика по количеству найденных дефектов? Мне кажется с этой глупостью лет 20 назад разобрались.

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

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

Тестирование API не обязательно сводить к стандартизации API. Это, опять же, влечет серьезные архитектурные проблемы, а написать на практически любое API обвязку сравнительно легко, тем более что ее можно просто выдернуть из рабочего кода. Ну и обеспечение достаточного testability сильно облегчит жизнь не только тестировщикам. Жаль только, что понимание testability у людей сильно отличается от, например, вот такого: {http://adam.goucher.ca/?p=141} Атрибут качества, но у многих в проектах нельзя увидеть и половины тех вещей, что описаны в статье пятилетней давности

ЗЫ: Как в эру CI можно говорить о вещах типа выполняет.Х? Выполняет робот.

2. SALar написал: 21 Сентябрь 2012

> Это попытка оценить тестировщика по количеству найденных дефектов? Мне кажется с этой глупостью лет 20 назад разобрались.

Сотрудника нельзя. Процесс можно.

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

> Проблема же поддержки большого набора GUI тестов решается дизайном самих тестов.

Какое отношение это имеет к статье? Не надо рассказывать, как работать с одним видом тестирования в отрыве от других. Давайте сравнивать относительную эффективность. Не нравится моя метрика - придумайте свою. Опишите. Будем смотреть.

> TDD, опять же, к тестированию практически не имеет отношения - это практика поддержания чистоты кода

Но это же не мешает этому методу улучшать продукт? Правда?

> а написать на практически любое API обвязку сравнительно легко, тем более что ее можно просто выдернуть из рабочего кода.

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

> Как в эру CI можно говорить о вещах типа выполняет.Х? Выполняет робот.

можно роботом по крону. можно по команде. Да, скорее тут нужно вести речь о том успел программист переключить контекст или не успел. А уж что вызвало переключение - не важно. Это в статью надо бы добавить.

3. Sergey Vysotsky написал: 25 Сентябрь 2012

> Сотрудника нельзя. Процесс можно.

Как минимум недостаиочно. Как максимум опасно. Причины примерно те же по которым нельзя мерить находимые баги по модели Вейбулла. См. Dr. Cem Kaner "Software Testing as a Social Science"

> Давайте сравнивать относительную эффективность.

Относительно чего? Автоматизация — это вспомогательный инструмент тестирования, состав которого сильно зависит и от процесса, и от продукта, над которым идет работа. Попытка смешать разные инструменты (а разные виды автоматического тестирования это и есть разные инструменты) в одну кучу, а потом их классифицировать это примерно, как сравнение C++ и PHP - это разные вещи, и они нужны для решения разных инженерных задач. Подводить их под один baseline как минимум странно.

Очевидно, что избыточная автоматизация через GUI это бессмысленная активность, т.к.:

1. Тестирование сложных приложений только через GUI это слишком смелое решение

2. Как правило избыточные GUI тесты можно заменить работой на более низких уровнях абстракции

3. Тесты на более низких уровнях абстракции более эффективны по ряду причин (проще поддерживать, проще писать, проще работать с результатами и т.д.)

Точно так же очевидно, что полностью избежать GUI не удастся.

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

Когда выполнять? Очевидно, как можно раньше. Остальное - процессные компромиссы

> Но это же не мешает этому методу улучшать продукт? Правда?

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

> Для маленьких, простых проектов. А вот когда продукт - это совокупность полусотни (или пара тысяч - тоже бывает) подсистем, общающихся через API и некоторые API реализуют десяток тысяч методов, то смена API это такая штука, которая требует существенно времени на переписывание тестов.

Тоже не согласен. Если у нас DSL поверх API, то все что нам нужно - сменить нижнюю прослойку. Если смена API не требует переписывания продукта, то клиент выдирается из рабочего кода, а для методов пишутся биндинги. Тесты переписывать не потребуется. Если же переписывание продукта требуется, то риски и трудозатраты для тестов будут несравнимо меньше чем для самого продукта.

Архитектура и инфраструктура автоматических тестов — это очень важный компонент. Не стоит его игнорировать.

112. Обе белые

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

О фильме: есть статья в википедии

Ноябрь 13, 2012 в 22:17

Комментариев: 3

1. Sergey Vysotsky написал: 14 Ноябрь 2012

Там же в вики линка: http://www.youtube.com/watch?v=MoeQ3I7BRpY

Тестировщику тоже лишним не будет, т.к. показывает девиации в расследовании проблемы

2. SALar написал: 14 Ноябрь 2012

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

3. Sergey Vysotsky написал: 14 Ноябрь 2012

Я в свое время проводил на тестировщиках опыты на базе тестов по selective attention (и прочие лабараторные эксперименты на внимательность) - картина принципиально не отличается от других групп людей.

Например, такие тесты:

http://www.youtube.com/watch?v=IGQmdoK_ZfY

http://www.youtube.com/watch?v=6JONMYxaZ_s

http://www.youtube.com/watch?v=5YPiVSdh-RY

http://www.youtube.com/watch?v=rWuJqCwfjjc

Так что у вас какие-то странные требования к профессии.

Resilience Engineering и теория социотехнических систем сообщают нам, что создание адекватный рабочих условий и правильная постановка задач (смотреть Тест Струпа, например) помогают сильно больше, чем натаскивание персонала на внимательность. Как все это делать - говорит нам теория тестирования.

Начать можно, например, отсюда:

http://www.amazon.com/Managing-Unexpected-Resilient-Performance-Uncertainty/dp/0787996491

http://www.amazon.com/Resilience-Engineering-Concepts-And-Precepts/dp/0754649040

http://www.amazon.com/Drift-into-Failure-Sidney-Dekker/dp/1409422216

http://www.amazon.com/Field-Guide-Understanding-Human-Error/dp/0754648265

Что-то можно еще заимствовать у граждан из ядерной энергетики и морской авиации. Я пока только пробую, но их результаты по созданию безопасных систем внушают: {http://govleaders.org/reliability.htm}

Что-то можно позаимствовать у ребят, профессионально занимающихся авариями. У того же Ричарда Кука есть отличная вводная листовка: http://www.ctlab.org/documents/How%20Complex%20Systems%20Fail.pdf

113. Тонны кода

Довольно распространенная фраза. Любят ей блеснуть на конференциях или в статьях. Давайте попробуем прикинуть, сколько это - тонна кода.

Популярная некогда идея платить за строчки кода привела к закидонам вроде:

for (i=1; i=1; i++)

{

x=x*i;

}

Или еще хуже:

for

(

i=1;

i=1;

i++

)

{

x=x*i;

}

Чтобы привести первый и второй вариант к "единому знаменателю" проведем "нормализацию" кода. Все "белые пробелы" (переход на другую строку, табуляция) заменим одним пробелом.

Получившееся, отформатируем согласно одному из РД. 14 кегль, 30 строк на страницу, 60 символов в строке. Итого примерно 1800 байт исходного кода с комментариями (комментарии является частью поставляемого продукта, отвечающий за такой атрибут качества, как анализируемость) на страницу.

Печать: один лист - одна страница.

Стандартный лист А4, 80 ден - 4 грамма

Итого:

один килобайт - 2,2 грамма один мегабайт - 2,2 килограмма один гигабайт - 2,2 тонны Слышал мнение, что программа до мегабайта исходного кода - маленькая. Ее легко держать в голове целиком и легко переписать любую часть, т.к. понятны взаимосвязи. Соответственно, и юнит тесты для рефакторинга не сильно нужны. Таким образом, пока мы работает с граммами и началом килограммов - все просто и, вероятно, одного человека на проект достаточно. Просто нужно найти человека нужной квалификации. Переход к пудам обычно требует команды и неких формальных схем взаимодействия. С центнерами кода лучше работать с хорошей документацией. Но самое интересное начинается, когда у вас действительно тонны кода. Встречается не так уж часто, но уж если встречается…

Ноябрь 14, 2012

114. ТОП-8 ошибочных парадигм операционного менеджмента и отсутствие глубинных знаний

Интересная статья Мартина Пауэлл, Director Goldratt UK (www.toc-goldratt.com)

Перевод был или есть на tocpeople.com.

Сам список:

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

2. Эффективность является лучшим показателем производительности и прибыльности

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

4. Сокращение количества переналадок сокращает затраты

5. Партия в обработке = передаточная партия

6. Все должны быть экспедиторами

7. Поток зависит, главным образом, от фактического размещения

8. Прием заказов с ускоренным времени выполнения повышает доходность

Без наличия глубинных знаний (термин Деминга) сложно понять почему вышеприведенные утверждения являются ошибками. Еще сложнее самостоятельно вывести эти ошибки и избежать наступления на эти грабли.

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

В дополнение к списку ТОП-8 ошибочных парадигм стоит упомянуть "Смертельные болезни менеджмента", описанные Эдвардом Демингом.

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

Ноябрь 16, 2012

115. SRS vs register vs null

Еще несколько гипотез о необходимости требований.

Достаточно частая ситуация, когда один и тот же сотрудник выполняет работы как в процессе "Управление требованиями" так и в процессе "Анализ и проектирование". И еще "Реализация" до кучи.

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

А отдельно есть тестировщики. Типичная модель разделения ролей РУТ (Разработка-Управление-Тестирование).

Мне модель категорически не нравится, но ситуация типичная.

Совокупность артефактов (элементов артефактов) по процессу "разработка требований" позволяет:

оценивать объем разработки и управлять разработкой, обеспечивать передачу теорий (термин Коберна) между ролями, позволять выявлять дефекты на разных стадиях, служить основой для проектирования тестовых сценариев. Далее:

1. Для "оценивания и управления разработкой" достаточно реестра.

2. Передача теорий не нужна при условии, что роли системного аналитика и архитектора выполняет один человек.

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

4. Число людей, которые умеют выявлять дефекты в требованиях, на рынке пренебрежимо мало.

И остается вопрос, так ли уж необходима разработка требований для тестирования или можно ограничиться разработкой реестра для "оценки объема". А если и "оценка" не нужна, то может и вообще не надо?

Альтернативная (одна из) гипотеза.

Куль карго неискореним. Согласно культу, документ должен быть.

Декабрь 18, 2012

Комментариев: 2

1. ytrewq написал: 8 Январь 2013

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

2. SALar написал: 8 Январь 2013

> "просто в бронежилете работать спокойнее" "Хорошо, если при их отсутствии тебя не пытаются уволить за каждый пропущенный баг. "

"Был бы человек, а статья найдется."

Полагаю, следует сознательно увеличивать риск. Это следует из теории рисков. Конкретно можно посмотреть или "Вальсируя с медведями" Демарко и Листера или понятие "риск-оптимум".

116. Книги для тимлидов и руководителей проектов

http://habrahabr.ru/company/devrainsolutions/blog/163311/#habracut Очень неплохой список.

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

Почему они не попали в список?! В чем причина?

Это при том, что в списке есть откровенно плохие книги.

Декабрь 20, 2012

Комментариев: 2

1. anton написал: 25 Декабрь 2012

а кого Вы имеете в виду?

2. SALar написал: 8 Январь 2013

Деминга, естественно. Уильям Эдвардс Деминг.

Информация в википедии (http://ru.wikipedia.org/wiki/%D0%94%D0%B5%D0%BC%D0%B8%D0%BD%D0%B3,_%D0%A3%D0%B8%D0%BB%D1%8C%D1%8F%D0%BC_%D0%AD%D0%B4%D0%B2%D0%B0%D1%80%D0%B4%D1%81) немного не точна:

"широко используемые в Японии и других странах под названием «бережливое производство»."ЕМНИЛ японцы не используют термин "бережливое производство". Этот термин придумали американцы, а японцы от него всячески открещиваются.

Конкретно, первой из книг о менеджменте следует поставить "Пространство доктора Деминга" Генри Нива. Другой перевод названия - "Организация как система".

PS. Просто для справки. Наша фирма заказала 4 экземпляра этой книги на 300 человек. И этого, по-хорошему, мало.

117. Обе белые?

Курс естествознания для менеджеров проекта.

Раздел А. Психология.

В семидесятые годы фраза "Обе белые" приобрела широкое иносказательное значение в академических кругах, хорошо знакомых с фильмом.

Сейчас, понятно, об этом эксперименте помнят мало. "Обе белые" - это один из вариантов "{Эксперимента Аша}". Эксперименты Аша продемонстрировали власть конформизма в группах. Но в его экспериментах иногда давали правильные ответы. Мне же более любопытен феномен массовых заблуждений, которые продолжают оставаться заблуждениями, несмотря на легкость опровержения и возможную критику.

Аристотель и Галилей. Пример из истории.

Примечание. Существуют разные версии того, что происходило. Я привожу ту, которую услышал первой.

Более двух тысяч лет назад в эллинском мире жил философ Аристотель.

Аристотель — древнегреческий философ. Ученик Платона. С 343 до н. э. — воспитатель Александра Македонского.

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

Галилео Галилей (итал. Galileo Galilei; 15 февраля 1564, Пиза — 8 января 1642, Арчетри) — итальянский физик, механик, астроном, философ и математик.

Галилей провел мысленный эксперимент, доступный в наши дни простому школьнику.

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

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

2. Рассматривая камни как единый объект большей массы чем тяжелый, мы получаем, что получившаяся конструкция будет иметь скорость больше скорости тяжелого камня.

Противоречие.

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

Как мог заблуждаться Аристотель? Он разработал систему логических построений "Логику", которой мы пользуемся до сих пор (в рамках институтского курса логики я читал перевод Аристотеля). Ладно, пусть он случайно ошибся. А остальные? Башен не хватало натурный эксперимент провести? Логическое построение в один абзац построить не способны? Да нет, монахи были весьма искушены в диспутах (смотри хотя бы книгу Умберто Эко "Имя розы"). Не иначе какое-то массовое помешательство на две тысячи лет.

Лет тридцать-сорок назад было очень популярное в армии заблуждение "Спичка горит ровно 45 секунд". Секундомеров не было? Или спичек не хватало? Или учение о вариабельности не было известно? Все было. И тем не менее.

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

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

Upd. Похоже это феномен "{Знания задним числом}".

Январь 9, 2013

Комментариев: 4

1. Yoy написал: 9 Январь 2013

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

2. V1talitys написал: 9 Январь 2013

Советую почитать про критический рационализм Поппера.

Это как раз то, чего не хватало в свое время многим теориям.

3. SALar написал: 9 Январь 2013

> Советую почитать про критический рационализм Поппера.

Да, это тоже в реестр изучения.

4. ytrewq написал: 16 Январь 2013

Могу предложить объяснение.

Натурный эксперимент по Аристотелю:

-взять в руку жменю сухого грунта с частицами разной массы (гравий, песок, пыль)

-с высоты своего роста высыпать эту смесь

Результаты:

- гравий достиг земли первым

- песок осыпался на секунду дольше

- пыль оседала полминуты

Вывод-.

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

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

Не случить великой чумы, не городили бы печатных станков Гуттенберги разные - писали бы руками дольше. Кризис какой-то всегда нужен для активации исследовательской активности, хорошо если не слишком острый. Покупали клиенты 5 лет к ряду нетестированный продукт, не мыли руки перед кодированием, разбрасывались людьми и временем - но бизнес-то цвёл. Надо, чтобы припекло. Не крестятся мужики без причины.

118. Примеры вариантов использования (Usecase)

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

Моя статья призвана заполнить существующий вакуум.

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

Примечание. Особенно неприятная ситуация с дубликатами происходит, при слиянии данных из разных систем. Это может быть и создание централизованного хранилища справочников (Master Data Management) для программных комплексов различного назначения, и слияние локальных баз филиалов в центральную.

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

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

В качестве примера многократного дублирования записей об ошибке, читатели могут рассмотреть {JRA-1330} из открытого источника.

Рассмотрим несколько вариантов использования (юзкейсов) направленных на очистку данных.

Примечание. Далее по тексту объект, который будет помечен как дубликат, будет обозначаться термином «донор». Объект, на который будут перенесены ссылки с донора, будет называться реципиент. Для реципиента широко распространен термин «Золотая запись».

Вариант А. Пометить дефект как дубликат.

Цель: очистка данных для уменьшении трудозатрат программистов.

Основное Действующее Лицо (ОДЛ): Тестменеджер

Предусловие: выбран дефект-донор

Основной сценарий:

1. ОДЛ отдает команду «Пометить как дубликат»

2. SuD предлагает указать реципиента

3. ОДЛ указывает реципиента

4. SuD подтверждает, что дефект-реципиент не находится в состоянии «Дубликат»

5. SuD переводит дефект-донор в состояние «дубликат»

6. SuD изменяет ссылки с дефекта-донора на дефект-реципиент (переносит аттачи на дефект остающийся активным)

7. SuD уведомляет ОДЛ об успешном завершении операции

Альтернативный сценарий:

4.а дефект-реципиент находится в состоянии «Дубликат»

4.а.1 SuD уведомляет ОДЛ о невозможности успешного завершении операции

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

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

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

Вариант Б. Сделать неактивными все дублирующиеся объекты, кроме «золотой записи».

Основное Действующее Лицо (ОДЛ): Администратор данных

Предусловие: выбрана группа предположительно дублирующихся объектов

Основной сценарий:

1. ОДЛ отдает команду на просмотр списка объектов группы

2. SuD показывает список и предлагает указать реципиента и объекты не являющиеся дубликатами (При автоматическом поиске возможны ложные срабатывания. Так колхозов «Рассвет» в РФ довольно много)

3. ОДЛ указывает реципиента

4. ОДЛ указывает объекты, не являющиеся дубликатами

5. ОДЛ отдает команду «продолжить»

6. SuD подтверждает, что объект-реципиент не находится в состоянии «Дубликат»

7. SuD подтверждает, что объект-реципиент в группе единственный

8. SuD переводит объекты-доноры в состояние «дубликат»

9. SuD изменяет ссылки с объектов-доноров на объект-реципиент (переносит договора, акты выполненных работ, счета-фактуры и прочие документы на «золотую запись»)

10. SuD уведомляет ОДЛ об успешном завершении операции

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

Некоторые пояснения по нотации:

• SuD (system under discusion) –рассматриваемая система. Иногда пишут просто «система», но термин «SuD» более точен.

• ОДЛ – описание, кто именно является основным действующим лицом, выносится в заголовок. Это позволяет сделать описания юзкейсов устойчивым к изменениям.

Август 11, 2013

119. Область применимости юзкейсов

"Ни одна модель неверна, по крайней мере в нашем реальном мире, но некоторые модели более полезны, чем другие"

(c) Джордж Бокс.

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

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

1. Проект не по созданию, а по настройке учетной системы.

Предположим, вам понадобился бактрекер. Если вы будете писать движок аналогичный Jira, Redmine или Trackstudio, юзкейсы - это то, что надо для описания функциональных требований. Но если вы собираетесь просто настроить одну из перечисленных систем под свои нужды, то предпочтительней использовать другие нотации. Диаграмму состояний, EPC-диаграмму, восможно IDEF или BPML. Что касается других систем, таких SAP, Sharepoint и т.п., то в проектах по их настройке под бизнеспроцессы заказчика, так же предпочтительно использовать отличные от юзкейсов нотации.

2. Большое количество различных интерфейсов пользователя для одной и той же функциональности.

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

3. Разрабатываемое ПО содержит много логики.

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

А для компилятора командной строки или для утилиты grep юзкейс будет один. А остальные требования - это куча правил.

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

4. Взаимодействие между системами.

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

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

5. Продукт, для которого функциональные требования не слишком важны или их очень мало.

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

Подводя итоги.

Мой тренер по рукопашке говорил: "Нет плохих приемов. Есть неправильное их применение." Перефразируя его: "Нет плохих нотаций. Нотация должна выбираться в зависимости от проекта."

120. Область применимости юзкейсов

Данетка для разработчика

В связи с прошедшим днем тестировщика и наступающим днем программиста (и тот и другой мои профессиональные праздники) предлагаю данетку.

Вы выдвигаете гипотезу, я подтверждаю ее правильность или неправильность.

Идет тестирование банковской системы. Проверяются зарплатные долларовые счета. На счет положена сумма $800. Установлен лимит снятий $500.

1. Попытка снять $600 – отвергается системой

2. Попытка снять $400 – деньги сняты

3. Попытка снять $500 – деньги сняты

Вопрос: «Сколько денег осталось на счете?»

PS. Дополнительный вопрос в стиле «Что, где, когда?»: почему лимит $500?

Сентябрь 10 2013

Комментариев: 49

1. buzin написал: 10 Сентябрь 2013

Сумма_на_счете_до_внесения_$800 - $100

2. SALar написал: 10 Сентябрь 2013

Сумма на счете до внесения была $0. Т.е. когда начались сами тесты (1. 2. 3.) на счете было $800.

3. buzin написал: 10 Сентябрь 2013

Тогда -$100 (овердрафт)

4. gdevgencih написал: 10 Сентябрь 2013

Может быть осталось 500$?

После того как система отвергла операцию к счету были добавлены 600$, которые с него не снимали.

5. chip написал: 10 Сентябрь 2013

Вариант 0. Счет может уходить в минус. Остаток — $-100

Вариант 1. 600 зачислено, остальное снято. Остаток — 500 долларов

Вариант 2. Все зачисляется. Остаток — $2300

Вариант 3. 1-я попытка игнорируется, вместо снятия деньги зачисляются. Остаток $1700

6. chip написал: 10 Сентябрь 2013

Вариант 5.

Снимается в рублях. Остаток: $800 - 900р

7. nh написал: 10 Сентябрь 2013

Гипотеза 1. На счёте осталось $800: снятие фактически не работает.

Гипотеза 2. На счёте осталось -$100: не работает проверка наличия достаточного количества средств.

Гипотеза 3. На счёте осталось $0: проверки наличия средств нет, но остаток всегда принудительно "поддерживается" не меньше нуля.

Гипотеза 4. На счёте осталось $800 + $400 + $500 = $ 1700: вместо операции снятия осуществляется операция пополнения.

Гипотеза 5. На счёте осталось -$700: то же, что в гипотезе 2, но при этом при попытке снять $600 деньги были сняты, несмотря на внешний отказ.

Гипотеза 6. На счёте осталось $2300: то же, что в гипотезе 4, но при этом при попытке "снять" $600 деньги были ошибочно начислены, несмотря на внешний отказ системы в проведении операции.

Гипотеза 7. На счёте осталось $800 - $600 = $200: система путает операции "снятие" и "отказ в снятии".

Дальше возможны более тонкие разновидности подобных сценариев-

Лимит $500, потому что система слишком бажная, и лучше не доверять ей крупных операций. $500 на покушать хватит, а крупные покупки лучше делать как-нибудь понадёжнее.

8. nh написал: 10 Сентябрь 2013

Поскольку это "данетка", то, видимо, предполагается задавать вопросы на "да-нет".

На счёте в конце оказалась неотрицательная сумма?

9. SALar написал: 10 Сентябрь 2013

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

> buzin написал: 10 Сентябрь 2013 в 17:50

> Тогда -$100 (овердрафт)

Нет.

> gdevgencih написал: 10 Сентябрь 2013 в 18:13

> Может быть осталось 500$?

> После того как система отвергла операцию к счету были добавлены 600$, которые с него не снимали.

Нет.

Примечание. Мне очень сложно представить такую ошибку в коде.

> chip написал: 10 Сентябрь 2013 в 18:38

> Вариант 0. Счет может уходить в минус. Остаток — $-100

> Вариант 1. 600 зачислено, остальное снято. Остаток — 500 долларов

> Вариант 2. Все зачисляется. Остаток — $2300

> Вариант 3. 1-я попытка игнорируется, вместо снятия деньги зачисляются. Остаток $1700

> Вариант 5. Снимается в рублях. Остаток: $800 - 900р

Надо проапдейтить данетку. Счет дебитовый.

Варианты 0 и 1 - смотри ответы выше.

Вариант 2. - тогда непонятны разные ответы системы. Итого - "нет"

Вариант 3 и 5. - хорошие гипотезы. Перепутать знак или валюту - это вполне, вполне. Но нет, не угадали.

10. SALar написал: 10 Сентябрь 2013

> nh написал:10 Сентябрь 2013 в 21:10

> Гипотеза 1. На счёте осталось $800: снятие фактически не работает.

> Гипотеза 2. На счёте осталось -$100: не работает проверка наличия достаточного количества средств.

> Гипотеза 3. На счёте осталось $0: проверки наличия средств нет, но остаток всегда принудительно “поддерживается” не меньше нуля.

> Гипотеза 4. На счёте осталось $800 + $400 + $500 = $ 1700: вместо операции снятия осуществляется операция пополнения.

> Гипотеза 5. На счёте осталось -$700: то же, что в гипотезе 2, но при этом при попытке снять $600 деньги были сняты, несмотря на внешний отказ.

> Гипотеза 6. На счёте осталось $2300: то же, что в гипотезе 4, но при этом при попытке “снять” $600 деньги были ошибочно начислены, несмотря на внешний отказ системы в проведении операции.

> Гипотеза 7. На счёте осталось $800 - $600 = $200: система путает операции “снятие” и “отказ в снятии”.

Дальше возможны более тонкие разновидности подобных сценариев…

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

(Сам на такое влетал в молодости.)

2. Маловероятно. Очень сложно представить такой код, что в тригерах БД, что в коде снятия.

Нет.

7. Вероятнее чем 2, но менее вероятнее, чем 1.

Нет.

PS.

> Лимит $500, потому что система слишком бажная, и лучше не доверять ей крупных операций. $500 на покушать хватит, а крупные покупки лучше делать как-нибудь понадёжнее.

Это сложный вопрос, он на "Что, где, когда?". Ответ неверный.

11. SALar написал: 10 Сентябрь 2013

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

> В начале серии тестов на счету $800?

Да.

> Все снятия в долларах?

Да.

12. SALar написал: 10 Сентябрь 2013

> nh написал: 10 Сентябрь 2013 в 21:23

> Поскольку это “данетка”, то, видимо, предполагается задавать вопросы на “да-нет”.

> На счёте в конце оказалась неотрицательная сумма?

Прекрасный вопрос! Ответ - "Да".

13. adminby написал: 10 Сентябрь 2013

А вопросы по одному задаются, или можно сразу пачкой?

1. Снимались ли деньги со счета (вычитание со счета) вообще?

2. Проверялось ли наличие необходимой суммы (на счету) перед снятием?

3. Происходили ли операции со счетом (запись на счет) при превышении лимита снятия (первая попытка)?

4. После 2 попытки случае остаток на счету составил 400$?

5. После 3 попытки реального списания со счета не произошло (ошибка связана с проверкой лимита именно в 500$)?

6. На счету осталось 400$?

14. SALar написал: 10 Сентябрь 2013

> 1. Снимались ли деньги со счета (вычитание со счета) вообще?

Да.

> 2. Проверялось ли наличие необходимой суммы (на счету) перед снятием?

Нет.

> 3. Происходили ли операции со счетом (запись на счет) при превышении лимита снятия (первая попытка)?

Нет.

> 4. После 2 попытки случае остаток на счету составил 400$?

Да.

> 5. После 3 попытки реального списания со счета не произошло (ошибка связана с проверкой лимита именно в 500$)?

Произошло.

> 6. На счету осталось 400$?

Нет.

15. adminby написал:

{10 Сентябрь 2013 в 23:25}

При снятии суммы, превышающей остаток на счету, но меньшей или равной лимиту, отрицательное число не записывается, а записывается 0$ ?

16. xBsd написал: 11 Сентябрь 2013

$500 - распространенный лимит для ATM?

система позволяет снятие дробных значений, $255.13?

рассчитано только на целые значения?

используется беззнаковый тип?

сумма денег на счету что-то типа uint.MaxValue - 100?

17. grokky написал: 11 Сентябрь 2013

На счету осталось 300$?

18. soapa написал: 11 Сентябрь 2013

500 потому что стандартный банкомат не выдает более 50 купюр и в нем нет купюр номиналом менее 10$?

На начало тестов сумма была 800?

Во время выполнения тестов на счет были добавлены деньги?

19. soapa написал: 11 Сентябрь 2013

Кстати с лимитом - может списалось не 500, а 499.99?

20. chip написал: 11 Сентябрь 2013

На счету остался 0. Нет проверки перед снятием, но снять больше, чем есть на счету нельзя

21. chip написал: 11 Сентябрь 2013

вопросы:

a) Если провести тест 4. Попытка снять $100 долларов. Результатом будет "Деньги сняты"?

b) К наблюдаемому результату приводит всего одна ошибка в коде?

P.S. Можно, конечно, делением пополам решить данную ситуацию за максимум 10 попыток (хотя если учесть, что все числа кратные 100, то число попыток резко сокращается), а потом придумывать гипотезу, но так неинтересно

22. namor написал: 11 Сентябрь 2013

Вариант $300 еще не рассматривался?

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

23. penelopa написал: 11 Сентябрь 2013

1. При попытке снять 500$ и снялось 500$?

2. При попытке снять 500$ снялось 400$?

3. Осталось 0$?

24. penelopa написал: 11 Сентябрь 2013

На счету осталось 0$? (при запросе большем, чем остаток, снимается весь остаток?)

25. SALar написал: 11 Сентябрь 2013

> adminby написал: 10 Сентябрь 2013 в 23:25

> При снятии суммы, превышающей остаток на счету, но меньшей или равной лимиту, отрицательное число не записывается, а записывается 0$ ?

Нет.

26. SALar написал: 11 Сентябрь 2013

> xBsd написал: 11 Сентябрь 2013 в 01:33

> $500 - распространенный лимит для ATM?

Да, но важна причина. Поэтому "Нет".

> система позволяет снятие дробных значений, $255.13?

Да.

> рассчитано только на целые значения?

Нет. Центы тоже можно.

> используется беззнаковый тип?

Некорректный вопрос. Для автоинкремента используется беззнаковый тип, а для процентов - нет.

> сумма денег на счету что-то типа uint.MaxValue - 100?

Нет.

27. SALar написал: 11 Сентябрь 2013

> grokky написал: 11 Сентябрь 2013 в 02:47

> На счету осталось 300$?

Нет.

28. SALar написал: 11 Сентябрь 2013

> soapa написал: 11 Сентябрь 2013 в 05:04

> 500 потому что стандартный банкомат не выдает более 50 купюр и в нем нет купюр номиналом менее 10$?

Нет.

> На начало тестов сумма была 800?

Да

> Во время выполнения тестов на счет были добавлены деньги?

Нет

29. SALar написал: 11 Сентябрь 2013

> soapa написал: 11 Сентябрь 2013 в 08:07 [редактировать]

> Кстати с лимитом - может списалось не 500, а 499.99?

Нет

30. SALar написал: 11 Сентябрь 2013

> chip написал: 11 Сентябрь 2013 в 09:54

> На счету остался 0. Нет проверки перед снятием, но снять больше, чем есть на счету нельзя

Нет

31. SALar написал: 11 Сентябрь 2013

> chip написал: 11 Сентябрь 2013 в 09:59

> вопросы:

> a) Если провести тест 4. Попытка снять $100 долларов. Результатом будет “Деньги сняты”?

> b) К наблюдаемому результату приводит всего одна ошибка в коде?

Ну, наконец то вопрос нормального человека, а не тестировщика! "А давайте снимем еще!"

а) Да

б) И, да и нет. Если поправить всего одну ошибку в коде, то ошибка исчезнет.

> P.S. Можно, конечно, делением пополам решить данную ситуацию за максимум 10 попыток (хотя если учесть, что все числа кратные 100, то число попыток резко сокращается), а потом придумывать гипотезу, но так неинтересно

Запрещено правилами данеток.

32. SALar написал: 11 Сентябрь 2013

> namor написал: 11 Сентябрь 2013 в 11:14

> Вариант $300 еще не рассматривался?

> Система при повторном снятии проверяет закешированное устаревшее значение баланса.

Вариант не рассматривался, но "Нет". (вариант хороший)

> penelopa написал: 11 Сентябрь 2013 в 12:20

> 1. При попытке снять 500$ и снялось 500$?

Да

> 2. При попытке снять 500$ снялось 400$?

Нет

33. nh написал: 11 Сентябрь 2013

Гипотеза: на счету осталось $100. (Вариант возможен, если в качестве остатка средств на счёте берётся абсолютная величина от разницы между тем, что было, и тем, что сняли - остаток ведь не может быть отрицательным, вот мы его и "нормализуем". Глупо, но встречаются и ещё более глупые программистские ошибки.)

34. algo_dogs написал: 11 Сентябрь 2013

Записали отрицательное число в беззнаковую переменную.

Например, так: 4294967196

35. chip написал: 11 Сентябрь 2013

Еще гипотеза, которая подходит под описанную ситуацию с учетом ответов на вопросы:

Перепутаны переменные при снятии со счета: то есть остаток рассчитывается как (сумма_для_снятия)-(остаток), но с обратным знаком.

тогда попытка 2. -(400-800)=400

попытка 3. -(400-500)=100.

Остаток 100.

Но мне сложно представить, как можно так ошибиться в коде

36. SALar написал: 11 Сентябрь 2013

> algo_dogs написал:11 Сентябрь 2013 в 15:42

> Записали отрицательное число в беззнаковую переменную.

>, Например, так: 4294967196

Близко.

37. Llanie написал: 11 Сентябрь 2013

А) Когда произвелось списание после выдачи 500$ - списание произошло с тестируемой карты?

Б) База, в которой проверяется баланс, и база, в которой производится списание, - одна и та же?

В) Комиссия за выдачу есть?

Г) Были ли любые движения по счёту, кроме начисления 800$ в начале теста и списаний, произведённых в результате запросов на выдачу 1, 2 и 3? (начисление процентов, снятие блокировки и т.п.)

Вопросы к бонусу:

Лимит на снятие установлен на уровне карты/счёта (т.е. с этой карты/этого счёта в день можно снять не более 500), на уровне банкомата (зависит обычно от физических возможностей лотка и имеющихся номиналов), на уровне процессинга (для своих карт столько-то, для чужих столько-то)?

Лимит на одно снятие или на снятия за день?

38. adminby написал: 11 Сентябрь 2013

> a) Если провести тест 4. Попытка снять $100 долларов. Результатом будет “Деньги сняты”?

Ну, наконец то вопрос нормального человека, а не тестировщика! “А давайте снимем еще!”

Если исходить из ответа:

> 2. Проверялось ли наличие необходимой суммы (на счету) перед снятием?

Нет.

То снимать можно любые суммы, не превышающие лимита - бесконечно.

39. SALar написал: 11 Сентябрь 2013

> Llanie написал:11 Сентябрь 2013 в 16:37

> А) Когда произвелось списание после выдачи 500$ — списание произошло с тестируемой карты?

Со счета. Можно привязанного к карте.

> Б) База, в которой проверяется баланс, и база, в которой производится списание, — одна и та же?

Да.

> В) Комиссия за выдачу есть?

Неважно. Но, "Нет".

> Г) Были ли любые движения по счёту, кроме начисления 800$ в начале теста и списаний, произведённых в результате запросов на выдачу 1, 2 и 3? (начисление процентов, снятие блокировки и т.п.)

Нет.

> Вопросы к бонусу:

> Лимит на снятие установлен на уровне карты/счёта (т.е. с этой карты/этого счёта в день можно снять не более 500), на уровне банкомата (зависит обычно от физических возможностей лотка и имеющихся номиналов), на уровне процессинга (для своих карт столько-то, для чужих столько-то)?

> Лимит на одно снятие или на снятия за день?

На одно снятие.

40. SALar написал: 11 Сентябрь 2013

>>> 2. Проверялось ли наличие необходимой суммы (на счету) перед снятием?

>>Нет.

>То снимать можно любые суммы, не превышающие лимита - бесконечно.

Может быть так, может быть не так-

Вопрос: «Сколько денег осталось на счете?»

41. Llanie написал: 11 Сентябрь 2013

Про то, на каком уровне установлен лимит почему-то ответа не было.

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

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

Ещё это может быть связано с магическими степенями двойки. Или просто подобран так, чтобы при правильной работе один раз можно было снять, если на счёт положить 800, а второй нет.

Задача вообще задаётся о сферической банковской системе в вакууме или с реальными исходными? [:)]

42. SALar написал: 11 Сентябрь 2013

Зря я бонусный вопрос задал. "Ограничение задано исходя из политики борьбы с терроризмом и прочими преступлениями. При обмене валюты лимит тот же - 500. После этого нужно предъявить документ удостоверяющий личность. А банкоматом можно воспользоваться без предъявления (карточка на другое лицо)."

43. adminby написал: 11 Сентябрь 2013

1. Результат зависит от архитектуры процессора (сопроцессора)?

2. Результат зависит от типа хранения данных в базе?

3. Результат зависит от выбранной СУБД?

4. Результат зависит именно от этого банкомата?

5. После 3 попытки произошло переполнение?

44. SALar написал: 12 Сентябрь 2013

> 1. Результат зависит от архитектуры процессора (сопроцессора)?

Нет.

> 2. Результат зависит от типа хранения данных в базе?

Скорее нет, чем да. Вопрос неконкретен.

> 3. Результат зависит от выбранной СУБД?

Нет.

> 4. Результат зависит именно от этого банкомата?

Нет. Точно "Нет."

> 5. После 3 попытки произошло переполнение?

Явно нет. Так как просто прошла операция.

Или я не понимаю, что такое переполнение.

45. nh написал: 12 Сентябрь 2013

> На счету осталось $100?

Нет. И такой вопрос был.

46. Llanie написал: 12 Сентябрь 2013

> Ошибка произошла при вычитании 500$ из 400$?

Ошибка произошла при выполнении третьей транзакции.

> или

> Ошибка произошла раньше, при определении необходимой операции по изменению остатка счёта?

Нет.

47. SALar написал: 12 Сентябрь 2013

1. Попробуем вариант с ответами в тексте вопроса

2. Данетка разгадывается до окончания дня программиста

48. Llanie написал: 12 Сентябрь 2013

> А. Если бы третьей операцией была попытка снять 450$, были ли бы деньги сняты?

Да.

> Б. Если ответ на предыдущий вопрос А. - "да", то была ли бы сумма остатка такой же, как после снятия 500$?

Нет

> В. Если ответ на вопрос Б. - "нет", то была ли бы сумма остатка на 50$ меньше?

Вопрос подразумевает двоякую трактовку.

Если снимать $500, то остаток на $50 меньше

49. soapa написал: 13 Сентябрь 2013

> В памяти хранится не 800, а какой-то результат encode(800), который равен ну допустим 349758731

> И ошибка в том, что снимается не encode(400) и encode(500), а 400 и 500?

Нет

121. Классификация требований по ГОСТ 34.602-89

Все ниже написанное – гипотеза, которую я выношу на обсуждение.

Внимание. Уровень сложности статьи выше среднего ("Осторожно, вдумчивое чтение нижеследующего текста способно нанести непоправимый ущерб рассудку. Вас предупреждали.").

------------

Не секрет, что у многих разработчиков ПО, работа по ГОСТ-ам вызывает отторжение. Не исключение и 34.602. С одной стороны, то что ТЗ должно быть – считают многие, но вот от попытки писать это ТЗ в соответствии с требованиями немного сносит крышу.

При внимательном изучение структуры становится понятно, что это очень высокоуровневый документ, состоящий из разделов, которые при других подходах принято оформлять отдельными документами. Так, например, раздел «5) состав и содержание работ по созданию системы» это явно документ планирования, ответственность за который несет руководитель проекта.

Примечание. 34-й ГОСТ вполне позволяет прописать в этом разделе 2-х или 4-х недельные итерации при создании ПО. Таким образом вы вполне можете сочетать ГОСТ с XP, RUP, SCRUM и т.д.

Но обычно ТЗ рассматривается в первую очередь как документ требований к разрабатываемому ПО. Вот на требованиях мы и остановимся подробнее.

Это раздел «4) требования к системе». И требования к составу и содержанию этого раздела способны вогнать в ступор даже закаленного системного аналитика.

Вот несколько выдержек из требований к содержанию и оформлению:

2.6.1. В подразделе “Требования к системе в целом” указывают:

требования к численности и квалификации персонала системы и режиму его работы;

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

2.6.3.7. Для организационного обеспечения приводят требования:

к структуре и функциям подразделений, участвующих в функционировании системы или обеспечивающих эксплуатацию;

к организации функционирования системы и порядку взаимодействия персонала АС и персонала объекта автоматизации;

к защите от ошибочных действий персонала системы.

Причем здесь спецификация требований к ПО?

Но как только мы примем, что это требования не столько к ПО, сколько ко всей совокупности изменения процесса, все становится на свои места.

Примечание. Это, знание похоже так осталось в 80-90-х.

Изменения процесса могут касаться изменений в:

* исходном материале;

* производимом продукте;

* процессе преобразования материала в продукт;

* средствах преобразования;

* нормах деятельности;

* навыках персонала.

Изменения со стороны исполнителя ТЗ, делаются за счет поставляемых этим исполнителем товаров и услуг. Вот к ним-то требования и выдвигаются. Если поставляются сервера, то возникают требования по электробезопасности и прочие. Если поставляются тренинги, то появляются требования к навыкам персонала и т.д.

Чего в 34.602 не хватает для более простого его понимания, так это раздела «Реестр поставки». Реестром поставки я пользуюсь несколько последних лет, и это экономит мне кучу нервов.

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

из книги «Записки автоматизатора»:

… я сам столкнулся с ситуацией, в которой внедренцы забыли, что «нарезка» 80 различных видов рабочих мест потребует определенного времени и определенных ресурсов. …

Забыта услуга «Инсталляция ПО».

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

Забыта услуга «Миграция данных»

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

Да что говорить, даже относительно простая система трекинга TrackStudio поставляется с:

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

И не нужно давать написание ТЗ системному аналитику. Ответственность за написание ТЗ лежит на главном конструкторе. Впрочем, эта роль тоже осталась в 70-90-х. Но можно разделить эту ответственность на руководителя проекта и бизнес аналитика (маркетолога). РП и БА могут привлекать к написанию ТЗ (в зависимости от класса создаваемой системы): электрика (требования к электрообеспечению и электробезопасности), юриста, системного администратора (требования серверам и сетям) и т.д. А системному аналитику лучше поручить написание частного технического задания на конкретное программное обеспечение из реестра поставки.

PS. В абзаце выше названия проектных ролей используются следующим образом:Системный аналитик: инженер, который пишет спецификацию требований к ПО, используя UML, usecase, ER-диаграммы, и прочие способы записи требований к ПО. Главный конструктор – отличный (выдающийся) инженер, сочетающий инженерную деятельность с административными функциями. Примерно соответствует главврачу в медицине. Как только ГК перестает выполнять инженерные функции, он перестает быть ГК. Руководитель проекта – человек, в том числе, отвечающий за составление плана и календарного графика проекта. Бизнес аналитик: инженер, который предлагает изменение существующих процессов организации. Описание изменений касаются: материала, продукта, норм деятельности и т.д.. Может работать с логическими диаграммами Голдратта, диаграммой «рыбий скелет» и прочими. Но не с UML и ER. Сентябрь 11, 2013

122. Ответ на данетку

В ходе обсуждения были даны ответы:

- остаток на счёте перед снятием не проверяется

- ошибка произошла при выполнении 3-й операции

- перед 3-й операцией на счёте $400

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

- доллары с рублями не путает

- вместо отрицательной суммы 0 не подставляет

- других операций по счёту не было

- после 3-й операции происходило списание со счёта

- остаток - не отрицательное значение, не $0, не $400, не $300, не $500

- результат не зависит от архитектуры и выбранной СУБД

- ответ "близко" на "Записали отрицательное число в беззнаковую переменную"

Но правильный ответ так и не был получен.

- Ответ -----

Код сервера приложений (примерно такой):

остаток=остаток - сумма снятия;

if остаток

then {сообщение об ошибке()}

else {выдать дньги;

сохранить новый остаток и операцию в базе данных}

}

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

Но есть такой прием, при котором с деньгами работают через целые переменные, храня в них центы. Счет исключительно дебетовый, почему бы не взять беззнаковое целое? Двухбайтовое для зарплатного счета маловато - максимальная сумма 655 долларов 35 центов, а четырехбайтовое в самый раз. Максимальная сумма - $42 949 672.95. Сорок два миллиона долларов - вполне достаточно. Но при выполнении кода отрицательного числа быть не может и проверка становится бессмысленной. Конечная сумма на счете: $42 949 672.95 - $100.00 = $42 949 572.95 Хорошая прибавка к старости.

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

Сентябрь 13, 2013

Комментариев: 8

1. xBsd написал: 14 Сентябрь 2013

Ну как же так, я был очень близко

> используется беззнаковый тип?

> сумма денег на счету что-то типа uint.MaxValue - 100?

ошибся на два порядка))

2. SALar написал: 14 Сентябрь 2013

Вы действительно были очень близко. Поздравляю.

Выяснилось, что данетка сложновата. Так что даже близкая гипотеза - это круто.

PS. Эти штуки лучше применять в обратном порядке: "Я знаю, что есть такой класс ошибок. Попробуем сделать тест на выявление." Работает на "ура".

3. algo_dogs написал: 14 Сентябрь 2013

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

Насколько я знаю при таком использовании целых, отдельно хранится scale, с помощью которого находится итоговое значение.

4. algo_dogs написал: 14 Сентябрь 2013

Понял, фактически в базу пишется не -100, а -10000.

5. xBsd написал: 14 Сентябрь 2013

Кстати, а на каком языке писалось? Например, в Java так ошибиться очень сложно, ибо там по умолчанию нет беззнаковых типов.

6. SALar написал: 14 Сентябрь 2013

Это придуманный пример. На С такое можно написать.

7. Llanie написал: 16 Сентябрь 2013

Почему тогда так:

>> сумма денег на счету что-то типа uint.MaxValue - 100?

> Нет.

Только из-за точности? Но тогда почему

> Записали отрицательное число в беззнаковую переменную.

> Например, так: 4294967196

> Близко.

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

(В минус, кстати, даже исключительно дебетовый счёт может уйти, за счёт курсов и комиссий.)

8. algo_dogs написал: 17 Сентябрь 2013

> После первого ответа перестала крутить версию про переполнение.

Проблема не в переполнении, а скорее неявном приведении типа.

123. Согласование требований с точки зрения теории вариаций

Преамбула

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

- Конец преамбулы

Но практика показывает, что не всегда все бывает сильно хорошо. Иногда, а вернее чаще, чем просто иногда, согласование требований идет «Не совсем так, как в теории».

Рассмотрим этот процесс с точки зрения одного из раздела глубинных знаний, выделенных Демингом, с точки зрения теория вариации.

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

Антипаттерн. Один из лучших способов увеличить потери на вариациях (и уменьшить прибыль фирмы) – это включение дополнительного рабочего центра в процесс.

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

Октябрь 8, 2013

124. Тренды в автоматизированном тестировании

Жили-были три бригады землекопов. И было в каждой по пять человек. Выкапывали они, когда как. Иногда и 50 метров траншеи в день, а если грунт тяжелый попадется, то бывало и 20 с трудом делали. Но по легкому грунту 50 давали железно

Но вот, средь них один нашелся кто-то,

Сказал он: "Братцы, нет на вас креста!

Даешь автоматизацию работы!

Даешь производительность труда!"

Потом трудяги долго заседали

И составляли план работ на год,

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

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

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

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

А мораль у этой басни такова: если автоматизация тестирования снижает эффективность процесса, то:

а) нужно ее внедрять

б) говорить о ее эффективности

Психология!

Справки:

Я видел пример, когда автоматизация тестирования снизила эффективность более, чем в десять раз.

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

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

PSS. Я прекрасно понимаю, что автоматизация тестирования может быть эффективной. Но как говорится, покажите мне цифры.

Октябрь 11, 2013

Комментариев: 4

1. Sergey Vysotsky написал: 13 Октябрь 2013

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

Возьмем, например, старую, фундаментальную работу по автоматизации от г-на Шеридана: {http://www.dtic.mil/cgi-bin/GetTRDoc?AD=ADA057655}

Там вводится понятие "Уровней Автоматизации". Если все десять откапывать лень, то можно картинку посмотреть на стр.56

В чуть более поздней работе (http://archlab.gmu.edu/people/rparasur/Documents/ParasSherWick2000.pdf) добавлено еще 4 стадии обработки информации, в которых данные уровни автоматизации могу присутствовать

И есть параллельная работа Эндсли со схожей концепцией: {http://www.satechnologies.com/Papers/pdf/Endsley_Kaber_Ergo_99.pdf}

Там и про эффективность, и про балансировку рабочей нагрузки и про многое другое в контексте этой концепции.

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

2. SALar написал: 14 Октябрь 2013

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

Я бы сказал "повысить число прогонов". бессмысленное число прогонов.

3. Sergey Vysotsky написал: 16 Октябрь 2013

Ксати да. Это же классика почти получается. Люди максимизируют output, когда на самом деле нужно максимизировать value. То, что большой output это не то же самое что большой value они почему-то не осознают. Я не очень разбираюсь в управлении, но есть подозрение что такое происходит потому, что люди банально не понимают, что от них на самом деле требуется и зачем. А это, видимо, означает, что-либо руководящий персонал плохо доносит это до сотрудника, либо сотрудник несколько некомпетентен.

4. SALar написал: 16 Октябрь 2013

Нет так все просто-

Но чего точно не надо делать - это считать усталость мерилом работы. Прогон тестов - это затраты (потери). Получится ли результат, это еще бабка надвое сказала.

125. Если программист говорит

Если дипломат говорит "да" - это значит "может быть".

Если дипломат говорит "может быть" - это значит "нет".

Если дипломат говорит "нет" - это не дипломат.

А программист?

Если программист говорит "нет" - это вообще ничего не значит.

Если программист молчит - это "нет".

Если программист говорит "да"- это значит "может быть"

Как сделать, чтобы было "Да"?

Апрель 9, 2014

126. SQADays-15

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

Напишу о том, о чем не напишут другие. Инфопространство не самый удачный выбор. Гостиничный комплекс Измайлово, в котором регулярно проходит конференция devconf гораздо интереснее. Существенно удобнее залы. Гораздо проще организовать логистику питания, и сильно лучше холл для посиделок. И размеры залов "с запасом". Плюс в инфопространстве какая-то плохая энергетика.

Благодарности. Чете Орликовых за упорство (уже 15-ая); Атрощенкову Сергею за отличные идеи по тематике моего доклада; прочим организаторам; участникам без которых было бы скучно. Отдельная благодарность за флипчарт фирме Аплана. Согласовать аренду подотчетного имущества в нерабочий день - это сильно.

Что касается моего доклада. то оставляю памятку. На докладе рассматривались стратегии и подстратегии:

1. "Синдром стажера."

2. "Сначала позитив."

3. "Сначала негатив."

4. "Очередность определяется этапом."

5. "Прыжки по кочкам."

6. "Прокладка гати."

7. "Очередность устанавливается принадлежностью к атрибуту качества."

8. "Стратегия в условиях равновесия по паретто."

9. "Ищем то, что нанесет наибольший ущерб в продакшене."

10. "Сначала архитектурные ошибки."

11. "Без чек листов."

12. "С чек листами."

13. "И без чек листов и с ними."

14. "Зачем мне SRS, я знаю этот класс систем."

15. "Требования? Я прочитаю их потом."

16. "Я тестирую, в том числе, для того, чтобы восстановить требования."

17. "Мне не нужна программа, для того, чтобы тестировать. Я знаю программистов, я знаю, какие ошибки они допустят."

Может я еще чего-то забыл.

Апрель 22, 2014

Программирование — это создание дефектов?

Отладка – это исправление ошибок.

Тестирование – это поиск ошибок.

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

PS. В каждой шутке только доля шутки. Остальное правда.

Август 10, 2014

127. Идеальный тестовый набор

Дню тестировщиков посвящается. С праздником коллеги!

- Разумный оценит достижение цели меньшим потом, так как труд нам дарован для созидания

(c) Притчи Шоу-Дао «ЧЬЕ ИСКУССТВО ЛУЧШЕ»

Примечание 1. В статье термин «тест» употребляется в значении «элементарная проверка»

Примечание 2. В моих логических построениях могут быть ошибки.

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

Попробуем зайти немного с другого конца.

Пусть для определения уровня тестовщика была создана программа, содержащая 100 ошибок одинаковой важности. Ни один дефект не блокирует тестирование. Тестировщиков просят составить тестовый набор и протестировать, используя его.

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

Но как минимум одним из критериев качества набора будет процент ошибок, который он находит.

Если:

«Тестировщик А» спроектировал и провел 1000 тестов и за неделю нашел 80 ошибок, «Тестировщик Б» спроектировал и провел 1000 тестов и за неделю нашел 50 ошибок, То тестовый набор «А» лучше. Но что делать с набором «В», который находит 90 ошибок, но содержит 10 000 тестов, а на проектирование и выполнение уходит 10 недель? Он лучше или хуже «А»?

Выдвинем еще одну гипотезу: «при равном количестве находимых ошибок лучше тот тестовый набор, на проектирование и выполнение которого требуется меньше времени». Сделав небольшое допущение переформулируем: «при равном количестве находимых ошибок лучше тот тестовый набор, который короче». Если есть три тестовых наборов в 100, 1000, 10 000 и все три находят все 100 ошибок, то ближе всех к идеалу первый.

Идеальный тестовый набор:

Находит все дефекты Нет ни одного теста, который не находит ошибку Если мне не изменяет память Луиза Тамре в своей книге приводит следующую рекомендацию: проведите тесты на граничные точки и на точки с обоих сторон от граничных. Т.е. если в требованиях сказано, что валидными являются любые двузначные число, то проверять надо на 9, 10, 11, 98, 99, 100. На мой же взгляд тесты на 11 и 98 явно лишние. Ошибки такого класса очень редки. Вместо этих тестов проведите тесты имеющие более высокую вероятность нахождения ошибок. В условиях дефицита времени рекомендация Луизы верный путь к уменьшению прибыли для большей части проектов.

Все? Нет, пока не все. Ситуации бывают разные. Пусть на тестирование вышеописанного приложения есть только 2 дня.

Тестировщик «Г» спроектировал и провел 450 тестов и нашел 60 ошибок.

Тестировщик «Д» отказался от проектирования. Провел 600 тестов, из них 50 по два раза и нашел 65 ошибок.

Тестовый набор «Д» - лучше.

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

Идеальный тестовый набор:

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

Идеальный тестовый набор:

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

Я же хочу сконцентрировать внимание на другом:

«Чем ближе программисты и тестировщики к идеальному тестовому набору и идеальному процессу отладки, тем они лучше.»

Полагаю, здесь нет возражений? Или все-таки есть? Потому что из этого следуют крушение нескольких иллюзий. А это больно.

Не желающих расставаться с иллюзиями рекомендую дальше не читать.

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

Второй вывод из статьи. Согласно одному из исследований, автоматизация теста в 10 раз дороже, чем ручной прогон.

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

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

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

Ну вы поняли.

Сентябрь 9, 2014

128. Прокрастинация. Вы так говорите, как будто в этом есть что-то плохое

То, что написано ниже не истина, но гипотезы.

--------------------

Интеллект и разум — это разные вещи. Подробности объясняются в "Ложной слепоте"{http://www.ozon.ru/context/detail/id/7393791/ Книгу, кстати, очень рекомендую. Большую часть решений человек принимает, используя интеллект. Процесс принятия решений аналогичен "китайской комнате" (определение можно посмотреть в википедии, но лучше прочитать книгу). Но многие задачи требуют для решения использование разума.

Работа мозга - очень затратный процесс. В спокойном состоянии при использовании интеллекта мозг (в среднем это 2 - 2.5% от массы тела) потребляет 20% энергии (ЕМНИП "ложная слепота"). Если же используется разум, то расход увеличивается до 30-35%, иногда до 60%. Непрерывное функционирование в таком режиме может привести к проблемам со здоровьем.

В организм человека встроены защитные механизмы, предотвращающие использование разума постоянно. Подробности объясняются в книге "Психология влияния" Роберта Чалдини. В "Ложной слепоте" по этому поводу Питер Уоттс высказался совершенно категорично: "Разум - ошибка эволюции, снижающая шансы на выживание вида". А Элиезер Юдковский в книге "Гарри Поттер и методы рационального мышления" http://hpmor.ru/ указывает, что люди, постоянно использующие разум при принятии решений, довольно неприятны в общении. По моим наблюдениям он прав.

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

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

Декабрь 1, 2014

129. Багтрэкинг, работа с ним или без него

Не исключительно мое мнение:

"Основное назначение трекера - дать возможность руководителю работ управлять реестром работ по проекту. Реестр задач на исправление багов, подмножество реестра работ по проекту."

Рекомендуемая последовательность:

1. Внедряем процесс ведения реестра.

2. Внедряем процесс управления реестром.

3. Внедряем процессы создания развернутых описаний элементов реестра.

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

"Если руководитель на регулярной основе не занимается управлением реестра, то с управлением проблемы". И, очень вероятно, бактрекер не нужен. Если вы не собираетесь делать шаг "2", то зачем вам шаг "1"!?

Кстати. "Внедрение процесса управления реестром" дает огромный эффект. Вполне может получиться, проект по разработке системы удастся сделать в 1.5 - 2 (это не только моя оценка) раза быстрее.

Декабрь 22, 2014

Комментариев: 3

1. Mantis написал: 23 Декабрь 2014 в 10:27

С исходным мнением полностью согласен.

Заинтересовало, что такое и чем отличаются между собой "процесс ведения" и "процесс управления". Подскажите, где можно дальше почитать по этой теме?

2. SALar написал: 23 Декабрь 2014

Заинтересовало, что такое и чем отличаются между собой “процесс ведения” и “процесс управления”. Подскажите, где можно дальше почитать по этой теме?

Вот чтобы описание было только об этом - это вряд ли.

Вскользь об этом упоминают Андрей Степенко с напарником в рассказе про внедрение теории ограничений на предприятии металлообработки. 3 месяца они ставили учет и три месяца управление. Через 6 месяцев завод начал показывать настолько невиданные результаты, что заказчики восхищенно матерились.

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

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

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

130. Почему люки круглые

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

(с) {http://habrahabr.ru/post/145960/}

Дисклаймер.

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

Эксперименты ставились. Один из самых ранних:

Беда в том (и, конечно, реальная, раз уж мы не руководствуемся этим фактом в своей деятельности), что мы не знаем, как определить этих лучших сотрудников. Мы годами бились, устраивая тесты профессиональной пригодности программистов, сертификационные экзамены по вычислительным системам и внедряя программы самотестирования ACM (Association for Computing Machinery), и в итоге, пролив над ними моря крови, пота и, пожалуй, даже слез, мы увидели, что корреляция между результатами тестов и показателями на рабочем месте равна нулю. (Огорчительные результаты, не так ли? Примерно тогда же выяснилось, что корреляция между оценками по курсу информатики и производительностью труда тоже ужасна [ckman, H., W. I. Erikson, and E. E. Grant. 1968. «Exploratory Experimental Studies Comparing Online and Offline Programming Performances». Communications of the ACM, Jan.].

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

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

Ответ, который, скорее всего, знает спрашивающий.

Этот вопрос, наверное, один из самых известных среди тех, что задает Microsoft. Он настолько широко известен, что Microsoft даже перестала его использовать. Этот вопрос уже давно цитировался в журналах как пример того, насколько нелепые вопросы задают в корпорации Microsoft при приеме на работу. «Кандидаты входили в холл, выкрикивая: „Для того, чтобы они не падали в люк! “ — еще до того, как им задавали этот вопрос», — рассказывает Адам Дэвид Барр.

Остановимся? Нет, продолжим.

Человек, который предложил это решение, вероятно, после этого предложил эксперимент подтверждающий гипотезу. Классикой является рассуждение про то, что квадратную крышку в люк уронить можно. Вроде, все верно, и на этом останавливаются. Полагаю, срабатывает когнитивное искажение «Положительная предвзятость», которая иллюстрируется игрой «2-4-6». Ради интереса, я иногда заключаю пари по этой игре. На мелкие суммы. Пока я в выигрыше. Правильный подход это не «квадратный люк проваливается», а «есть ли еще фигуры, которые не проваливаются»? И вот такой вопрос после небольшого гугления приводит нас к опровержению гипотезы. Крышка в форме треугольника Рёло тоже не проваливается.

Жаль, красивая была гипотеза. И весьма популярная.

Лирическое отступление. Вопрос про люки я впервые услышал лет 30 назад. Мы в классе любили задачи, выходящие за рамки школьной программы. Довольно быстро мы пришли к наиболее популярному ответу. Мы, как и многие допустили классическую ошибку. Придумали правдоподобную гипотезу («Ошибка приоритизации гипотез»). Затем получили положительное подтверждение («Положительная предвзятость») и остановились. Сейчас вспоминая все это, понимаю насколько точно описал это Элиазер Юдковский {http://hpmor.ru/book/1/8}. Как с нас писалось.

И, кстати, почему люки ливневой канализации прямоугольные?

О кей, но что делать?

Рекомендуемый подход состоит в выписывании всех возможный и невозможных гипотез. Без критики. И только после составления максимально полного списка переходить к детальному рассмотрению. И, да, при составлении списка исходить из разных точек зрения.

Ничего нового. Старый добрый «Мозговой штурм», изобретенный в 1941. А может даже переизобретенным. Ну да, чему нас могут научить эти пещерные люди [;-)] ?

Набираем гипотезы

С точки зрения процессного инженера. Потому что это соответствует ГОСТ 3634. С точки зрения прочниста. Позволяет избежать локальных очагов напряжения. За счет чего снизить вес при той же прочности. Потому что так проще точить на токарном станке. Круглая форма крышки позволяет уменьшить количество бракованной (по фактору качества опорных поверхностей крышки и люка) продукции. В круглое отверстие проще пролезать человеку. С точки зрения конструкционщика. На круглую бутылку проще делать круглую крышку. С точки зрения бригадира. Так их можно катить, а не нести. И достаточно одного человека. С точки зрения руководителя планово экономического отдела коммунальной службы. Чтоб не сперли. Ну, и напоследок:

В 2000 году популярный автор передач и комментатор радиостанции NPR Андрей Кодреску выступал в корпорации Microsoft. Когда он отвечал на вопросы слушателей, один из них задал ему вопрос, почему крышки канализационных люков круглые. «Ну, это понятно, — ответил Кодреску, — в битве круглый щит удобнее, чем квадратный. Кроме того, круг — это символ бесконечности: именно поэтому у храмов круглые купола. Круглые крышки люков также напоминают пешеходам о том, что они живут в мире, созданном божественным провидением»

В креативности не откажешь [;-)].

Перейдем к рассмотрению гипотез. И здесь правило такое. Сначала делаем те проверки, которые можно сделать быстро. Это так называемый «Предварительный отбор».

Потому что это соответствует ГОСТ 3634.

Ответ кажется таким же как ответ на вопрос из старого анекдота:

Однажды Черчилль со своим водителем заблудились в предместьях Лондона. И мимо авто, стоящего на обочине, шел пастух, гнавший отару овец… Шофер решил спросить у пастуха дорогу.

— Сэр, а где мы находимся?

Пастух постоял возле машины… и ответил

— В автомобиле.

Черчилль затянулся сигарой…

— Вот ответ, достойный палаты общин: краткий, хамский и не сообщающий спрашивающему ничего, кроме того, что он знает.

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

- Почему вы форматируете код пробелами?

- Потому что так написано в стандарте. И у пробелов, и у табуляций было множество противников и сторонников. В конце-концов кинули монетку.

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

Кстати. Первая железная дорога в России имела ширину 1829 мм, а не 1524/1520 как сейчас.

Гипотезу оставляем.

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

Удивительно красивая гипотеза. Но что делать с ливневой канализацией?

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

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

Потому что так проще точить на токарном станке.

Почти наверняка бред, т.к. чугунные изделия такой формы гораздо проще и дешевле отливать. Гуглим. Точно, отливают по ГОСТ 26358.

Отбрасываем.

Позволяет уменьшить количество бракованной продукции.

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

Отбрасываем.

В круглое отверстие проще пролезать человеку.

Противоречит тому, что люки на чердак, в подвал и т.д. делают квадратными. Да и вообще странно выглядит.

Пока оставим, но маловероятно.

На круглую бутылку проще сделать круглую крышку.

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

Оставляем.

Так их можно катить, а не нести.

Типа того, что катить может один человек, а для переноски требуется двое, что позволяет сократить бригаду до одного человека.

У нас в РФ у крышек есть специальные опорные выступы, так что нормально катить их все равно не получится. И если мне не изменяет память минимально допустимая бригада на таких работах – три человека. И если кто-то выпустит бригаду из одного человека, то после первого же инцидента этот самый выпустивший вполне может познакомиться с УК за нарушение правил ТБ.

Отбрасываем.

Чтоб не сперли.

Мечта многих владельцев дач и частных домов – дорожки, выложенные чугунными квадратными (прямоугольными) плитами. А вот круглые плиты, треугольники Рёло или решетки ливневой канализации для этой цели совсем не так интересны.

Как ни странно, неожиданная гипотеза и при этом довольно вероятная.

Именно поэтому не стоит анализировать гипотезу до составления серьезного реестра гипотез.

В битве круглый щит удобнее, чем квадратный.

Явный бред. Отбрасываем.

Заключение.

А собственно и все. Чего тут еще скажешь?

Кстати, теперь я сам не знаю, почему они круглые.

Это сообщение создано Четверг, Январь 8, 2015

131. Управление большим числом задач в проектах по разработке программного обеспечения

А что значит большим? Или как спрашивала мартышка из "38 попугаев": что такое куча? Вот десять - это куча? И отличается ли управление большим числом мелких задач от управления малым числом больших задач? А большая задача — это сколько? Есть масса вопросов. Но если постоянно не задавать эти вопросы и не отвечать на них, то будут получаться мертворожденные схемы, которые работают только в теории.

В теории между теорией и практикой нет никакой разницы. На практике же разница огромна.

Столяр пользуется множеством инструментов. Он не пытается закручивать гвозди рубанком. И не пытается вырезать пазы шурупом. Чем мы хуже? Почему мы пытаемся применить SCRUM там, где он не применим? Управление разработкой ПО - это огромная мозаика. Ее можно складывать сразу из нескольких мест и совсем не обязтельно слева направо. Науку управления не обязательно учить по схеме PMBoK. В любом случае одну и ту же тему придется пройти несколько раз, рассматривая ее с разных аспектов.

ГОСТ 34.603 (виды испытаний автоматизированных систем) вполне применим. В определенных ситуациях. И ГОСТ 9126 (характеристики качества и руководства по их применению) тоже применим. В других ситуацих. Но есть ещ и третья ситуация, когда отличным вариантом будет не XP или RUP, а ГОСТ Р 50779.42 (контрольные карты Шухарта) от 99 года.

Я попробую разложить свой опыт на цикл статей, в каждой из которых осветить маленький аспект управления. Управления не обязательно проектами. Возможно, управления процессами. Или НИР-ами. Короче, разработкой ПО.

Сентябрь 24, 2015

Один комментарий

1. maxbeard12 написал: 25 Сентябрь 2015

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

132. Понятие атомарной задачи

Дисклеймер

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

Я не могу дать все определения в одной статье. Голдратт для определения понятия «Критическая цепь» написал книгу. Генри Нив для определения понятия «Операционные определения» и для описания их важности написал главу книги.

Также я не уверен, что одних статей достаточно. Возможно, нужны тренинги.

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

Проблематика

От менеджеров часто приходится слышать:

* А почему так дорого?

* А почему так долго?

* А почему, если фактическая трудоемкость всего 60 часов, выпустили только через три месяца? Другая команда в другом продукте должна была внести изменения и внесла только сейчас? Почему я узнаю об этом только сейчас?

И, конечно же, одно из самых популярных: «У нас ни один проект не завершается в расчетный срок. Планировать не умеете?»

Некоторые операционные определения и ограничения статьи

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

На текущий момент практически стандартом де-факто стали следующие положения:

Есть два типа задач. Разработка новой функциональности и исправление ошибок. Обобщающий термин - запрос на изменение (ЗНИ). В этой статье рассмотрим задачи по разработке новой функциональности. Введем дополнительное понятие «фича». «Фича» - это набор свойств, которые, будучи реализованы, приносят значимую пользу бизнесу, которую можно выразить деньгами. Есть некий минимальный набор свойств фичи, без которого выпускать релиз нет смысла. Потому что это не приносит бизнесу пользу. В качестве примера рассмотрим интернет-магазин. Вряд ли имеет смысл выпускать функционал оплаты в интернет- магазине, если не реализован функционал оформления заказа. Понятие фичи очень размыто, поэтому давайте пока примем, что интернет-магазин может содержать множество фич, среди которых мы выделим:

1. Найти товар.

2. Просмотреть свойства товара.

3. Купить.

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

Фичи это то, по поводу чего удобно договариваться с заказчиком. В одном случае вы услышите: «Какая корзина? У нас розничная торговля холодильниками. Не покупают люди пять холодильников сразу. Сначала делайте один клик. Через полгода, может быть, вернемся к идее корзины». Может быть и обратная картина: «Мы книгами торгуем. Не будет человек одну книгу за 200 рублей заказывать при стоимости доставки заказа в 300 рублей. Сначала корзина».

Декомпозиция и суперпозиция фич отдельная большая тема, а пока вернемся к атомарной задаче. Возьмем фичу «купить в один клик». В среднем и большом бизнесе (оборот сети магазинов - сотни миллионов долларов и выше) этот самый бизнес обслуживают десятки и сотни систем, взаимодействующих друг с другом. Если брать «М-Видео», то у них очень значимый сегмент (более 10%) - торговля через интернет. Но такие фичи интернет-магазина, как, например, программа «постоянный покупатель» (накопление и трата бонусов) должна быть общей и для онлайна и для оффлайна. Скорее всего, это не часть интернет-магазина и не часть оффлайн -магазина, а отдельный программный продукт. Фича «один клик» может потребовать внесения в несколько систем, работы множества программистов (в том числе из разных команд, а иногда и из разных фирм), а также верстальщика, оформителя и т.д. И трудозатраты на нее получаются немалые. Заказчика интересует прогресс и прогнозируемая дата выпуска. И одной большой задачи для координации множества людей, тем более из разных отделов и/или фирм, оказывается недостаточно.

Если одной задачи для координации недостаточно, нужно несколько задач. Нам нужен реестр задач, который позволит:

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

В моей практике есть примеры:

Введение реестра атомарных задач позволяло рассчитать время проекта с точностью до 5-10%. Неплохо? Введение реестра атомарных задач позволяло сократить время проекта. Введение реестра атомарных задач позволяло уменьшить напряженность в отношениях заказчик – исполнитель. Ноябрь 2, 2015

133. Оценка трудоемкости атомарной задачи

Дисклеймер

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

Я могу быть не прав. Если эксперименты покажут, что я не прав, я это приму.

Проблематика.

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

Требования:

Оценка трудоемкости должна приносить пользу. Т.е. улучшать производственный поток. Оценка трудоемкости не должна приносить вреда. Или вред должен быть меньше, чем польза. Оценка трудоемкости должна быть возможной. Если погрешность оценки более 100%, то, может быть, не стоит и давать оценку? Если вы с этим не согласны, то далее статью можно не читать.

Рисуем фон

Как можно использовать оценку трудоемкости? Или «Какую пользу это принесет?» Будем исходить из того, что наш заказчик умеет считать деньги.

Оценка трудоемкости должна приносить пользу

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

1. срок поставки – неделя, трудоемкость один час, выставленная цена - $10000

2. срок поставки – две недели, трудоемкость пятьсот часов, выставленная цена - $50000

Существуют менеджеры, которые выберут второй вариант. Но мне интересней иметь дело с теми, кто выбирает первый.

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

Для внутреннего заказчика ценность также нулевая. В разработке ПО (как и в любом другом бизнесе) есть только два варианта с размещением ограничения системы. Ограничение системы может быть или внутри производства, или вне. Если вне, то бизнес не беспокоит, какова трудоемкость атомарной задачи - полчаса или два дня. Но может беспокоить, будет ли выведен хотфикс через час или через неделю. Сроки важнее. Для фичи иногда ситуация другая. Там может быть расчет по ROI. Если же ограничение внутри производства, срок выхода задачи в релиз определяется исключительно местом в очереди задач. Совершенно не важно, какая трудоемкость: полчаса или день. Если впереди сотня других задач, то срок выпуска – ориентировочно полгода. По имеющимся у меня статистическим данным, снятым с нескольких фирм: «Эффективность жизненного цикла атомарной задачи, при условии нахождения ограничения внутри разработки ПО, составляет порядка 1%. Это означает, что атомарная задача трудоемкостью в один день будет сделана в среднем через 100 рабочих дней. Но календарное время выпуска можно менять, изменяя очередность в очереди задач». Смотри «Историю одной доски» от Макса Дорофеева.

Польза от оценки трудоемкости нулевая.

Оценка трудоемкости не должна приносить вреда

Сам факт наличия оценки трудоемкости приводит к уменьшению производительности программиста. Исследования Лоуренса и Джеффи от 1985 года (Jeffry, D.R. and M) показали, что производительность падает в полтора – два раза. Смотри книгу «Peopleware». Теоретические выкладки Голдратта в книге «Критическая цепь» это подтверждают. Теоретический расчет Голдратта соответствует полученным экспериментальным результатам.

Оценка трудоемкости приносит вред.

Оценка трудоемкости должна быть возможной

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

Результат удивил даже меня. Фактический результат показал, что в зависимости от того:

выпил ли программист кофе до или после решения задачи, встал с левой или правой ноги, прогулялся после чтения условия или нет, начал с клавиатуры или с мыши фактическая трудоемкость отличается. Примерно в пятнадцать раз. На одну и ту же стандартную задачу программист может потратить 15 минут. А может полдня. А может час. Фактической трудоемкости. Без учета перекуров и прерываний. Фактической трудоемкости! С прерываниями разница может быть и большей. Т.е. общая причина вариации (термин Шухарта) делает невозможной оценку трудоемкости атомарной задачи.

Примечание. Справедливости ради надо упомянуть еще об особой причине вариаций оценки трудоемкости. Смотри исследование «Ошибка планирования» от 1994 года. Но особую ошибку хотя бы компенсировать можно. А вот попытка компенсации общей причины приводит только к ухудшению ситуации. Смотри пятую главу книги «Пространство доктора Деминга» Генри Нива.

Итог.

Оценка трудоемкости атомарной задачи:

не приносит пользы с точки зрения определения срока выпуска; ухудшает производительность; невозможна. Вы можете поставить под сомнение результаты экспериментов. Это нормально. Поставьте свои.

И что делать?

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

Ноябрь 7, 2015

134. Измерение трудоемкости атомарной задач

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

Как ее разбить?

А зачем нам оценивать трудоемкость, если мы можем ее измерить на основании исторических данных? Возьмем для примера работу верстальщика за предыдущие периоды, сгруппированнуе по 4 недели. Предположим, мы получили следующую статистику:

1-й период - 37 страниц 2-й - 46 3-й - 42 4-й - 30 5-й - 51 Это означает, что:

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

Несколько тонких моментов.

1. Трудоемкость надо считать, как N задач в M дней (800 задач в 400 дней), а не одна задача в среднем 2 часа. Ваш сотрудник ходит на совещания, читает почту, вынужден писать вам отчеты и т.д. Но это совершенно не важно. Заказчика волнует «Когда закончится проект?».

2. Список сделанных атомарных задач является отличным отчетом. Другой отчет для контроля за работой сотрудника не нужен. Бонус: «Хотите поднять производительность сотрудника на 5-10%? Отмените таймшиты. Используйте реестр задач как отчет.»

3. Обязательно возникнет вопрос: «Да, но есть страницы, которые верстались по неделе и более. Их надо разбить!». Нет, не надо. Пока отклонение в трехсигмовом пределе, не надо насиловать процесс. Будет только хуже. Смотри главы 4, 5, 6 книги «Пространство доктора Деминга».

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

Ноябрь 7, 2015

135. Вариант использования как элемент планирования

Use Case (вариант использования, ВИ, Прецедент, юскейс) это один из вариантов записи требований к системе. Дополнительную информацию о них можно узнать из статей:

Что такое Use Case и зачем они нужны?Пример требований к системеБайка для оруженосца-5. Использование вариантов использования.Примеры вариантов использования (Usecase)В отличие от многих других способов записи требований юскейсы обладают двумя приятными особенностями:

Существует множество формальных способов проверки реестра юскейсов на полноту.Описан способ, как выделить уровни юскейсов.Эти особенности позволяют легко создать достаточно полный реестр атомарных задач. Термин «Уровень» был предложен Алистером Коберном. Если очень грубо, то:

Юскейс «уровня моря» - это юскейс, при котором время взаимодействия с системой не превышает 20 минут и который, будучи выполнен многократно, приносит пользу. Часто юскейсы этого уровня составляют основу спецификации требований. Юскейс «выше уровня моря» (змей, облако) - более высокоуровневый. Содержит несколько юскейсов уровнем ниже. Часто служит основой для переговоров с заказчиками. «Ниже уровня моря» (рыба, моллюск) - составная часть «уровня моря». Часто используется для описания взаимодействия между системами в рамках одного юскейса уровня моря. Каждый из этих уровней в зависимости от проекта может быть выбран в качестве уровня атомарной задачи. Да, это не полный реестр, но это костяк реестра.

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

Рассмотрим несколько разных проектов.

Проект А.

Маленький проект. Несколько недель (месяцев) для одного программиста.

Спецификация требований на основе ВИ на него можно найти В этой же книге.

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

Это несколько недель для одного программиста. Сколько именно, зависит от платформы.

1. Java / C# + MSSQL – 6-12 недель

2. Дельфи + SQLite – раза в два меньше

3. FileMaker / MS Access / FoxPro / Clipper / Paradox – 3-10 дней

Если мы выбираем в качестве платформы C# + MSSQL, то для этого проекта удобно использовать юскейсы «уровня моря» в качестве уровня атомарной задачи. Реестр задач по этому проекту мог бы выглядеть следующим образом:

Работа с «Партнерами» - (юскейс над уровнем моря) Создание необходимых структур в БД - (не юскейс) Просмотр списка партнеров - (юскейс уровня моря) Создание «Партнера» - (юскейс уровня моря) Просмотр «Партнера» - (юскейс уровня моря) Изменение «Партнера» - (юскейс уровня моря) Удаление «Партнера» - (юскейс уровня моря) … Программисты на платформе C# + MSSQL, с которыми мы общались, утверждали, что делают в неделю 2-10 юскейсов вида «Просмотр, создание, изменение». То, что надо. Проводить дальнейшую декомпозицию нужно в очень редких случаях.

Примечание. При программировании на Paradox «Уровень моря» становится слишком мелок. Впрочем, с Paradox весь проект становится совсем крошечным, и для него формальный реестр задач необязателен.

Проект Б. Проект среднего размера. Несколько человеколет (десятков человеколет).

Создание интернет-магазина для крупной розничной сети.

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

Реестр задач:

Работа с Заказом Просмотр заказа Макет Дизайн Верстка Программирование - Оформление заказа для авторизованного покупателя … Оформление заказа для неавторизованного покупателя Страница «Вход» Макет (не менее 6) Дизайн макета 2 Дизайн макета 4 Дизайн макета 5 Верстка утвержденного макета ПрограммированиеСтраница 2 Страница 3 Последняя страница Макет - Передача заказа в программу логистики (юскейс) Расчет бонусов (юскейс) В данном случае юскейсы, в первую очередь, является группирующей сущностью атомарных задач. Что касается, атомарных задач, то это, как правило, будут не юскейсы. Но иногда будут встречаться юскейсы уровня рыбы и моллюска.

Ноябрь 8, 2015

136. Защита от впихивыния невпихуемого

Попытка решить слишком много задач приводит к снижению производительности, нервотрепке и отрицательному естественному отбору. Снижение производительности на 15-20% это совершенно нормально. Вполне может быть и в два – три раза. Отрицательный естественный отбор – сотрудники, имитирующие бурную деятельность, получают плюшки в виде премий и повышения в должности. Сотрудники, которые работают, уходят работать в другой офис. Процесс этот может протекать достаточно бурно и через пару-тройку лет весь средний менеджмент организации может оказать укомплектован исключительно имитаторами.

Для предотвращения впихивания невпихуемого есть довольно простые правила.

1. Гениальная идея до того, как попасть к разработчику должна быть записана в трекер. Самим креативщиком.

Невыдуманная история. В одной из фирм маркетологам запретили чисто устную постановку задачи. Сначала трекер. Только потом можно рассказать устно. Поток гениальности снизился вдвое.

"Если ты не можешь записать идею на родном языке - возможно, тебе рано о ней рассказывать?"

2. Еще до фазы управления идея должна пройти минимальный анализ.

Иногда все очевидно и анализ не записывается. Пример: "Под нового заказчика ООО "Атлант" сделайте новый проект в Jira & пространство в Confluence". Потому как в регламенте написано про НДА, которое реализуется через разграничение прав доступа к проектам Jira и пространствам Confluence. Но под "поток гениальности" анализ нужно зафиксировать.

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

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

Для случая непрерывной поставки и ограничения находящемся в производстве третье правило трансформируется в регламент со следующими пунктами:

1) Представитель заказчика утверждает порядок очереди работ. Т.е. основное управление осуществляется через "очередь" работ. Чем выше в списке ("ближе к кассе"), тем раньше задачу начнут делать. и вот этот самый порядок в очереди утверждается на встрече представителей заказчика и исполнителя. А если заказчик адекватный, то функции управления очередью можно отдать ему полностью и сэкономить на зарплате менеджера в группе разработки.

2) Задача прожившая в очереди работ более определенного времени (подбирается на основании экспериментальных данных) закрывается автоматически (скриптом). Другой вариант - должна быть не длиннее чем N задач. Например, если в неделю сыплется 10-20, а делается 5-10 задач. То у 50-й задачи нет шансов быть сделанной. За те 6-9 недель, которые нужны, чтобы до нее добраться прилетит еще 100-130 задач. И, если хотя бы половина из них будет поставлена перед 50-й, то-

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

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

Менеджер не имеет права отдавать указания исполнителям. Исполнителями управляет регламент работ.Менеджер обязан управлять очередью. Не управление очередью со стороны менеджера должно рассматриваться как неисполнение прямых служебных обязанностей со всеми вытекающими последствиями.Менеджер (не обязательно этот же) может поменять регламент.---

Приложение. Дополнения, разъяснения и предупреждения.

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

Для справки. Фирма Хитачи несколько раз пыталась у себя производственную систему Тойота. У них хватало и опытных наставников из Тойота и денег, и упорства. Но их производственная среда отличалась от среды Тойота. Итого: потеряв кучу денег они не смогли внедрить производственную систему Тойота и были вынуждены разработать другое прикладное решение под свою среду.

Вот небольшой список вопросов для определения, какое прикладное решение вам подойдет:

Заказчик. Внутренний / внешний?Процесс или проект?Какова цена бага, пропущенного в продакшен?Где находится ограничение системы?Сколько рабочих центров задействовано в работе?Взаимозаменяемы ли разработчики?Это не все вопросы, но пока этого достаточно.

Для случая, рассмотренного выше, ответы на вопросы будут следующие:

1. Заказчик внутренний. Упрощается взаимодействие. Не нужно «Закрывать контракты».

2. Процесс. Это означает, что задачи слабосвязаны и могут решаться независимо.

3. Цена бага незначительна по сравнению с преимуществом быстрого выпуска.

4. Ограничение системы находится в разработке. Пусть это сделали сознательно. Численность программистов сознательно поддерживается на таком уровне, чтобы гарантированно не быть в состоянии делать примерно половину задач. Сделано это, чтобы софт не превращался в ералаш (смотри «{Слон живописец}»).

5. Данный рабочий центр практически не взаимодействует с другими в потоке создания ценности. Т.е. когда заказчик размещает заказ, этот центр разработки все делает сам без привлечения программистов, тестировщиков, аналитиков из других отделов.

6. Разработчики взаимозаменяемы.

Март 21, 2016

137. Трассировка требований разных уровней

Пояснение.

Материал готовился к докладу "Документ спецификации требований к ПО, а нужен ли он?" на аналитическом онлайн-марафоне "Проектный истории". Материал в доклад "не вписался". Оказался чересчур велик и сложен. Это нормально. Обычно на доклад я стараюсь набрать объем материала, с расчетом выбросить две трети. Тем не менее после доклада возник вопрос о трассировке требований разного уровня друг на друга. И тут такая удача - есть рабочий материал.

Дисклеймер.

1. Это рабочий, не конечный материал.

2. Очевидно, в нем есть ошибки. Один из тезисов моего доклада: "Если вы не нашли в формальном документе SRS ошибки, то зачем вы его писали?" Так что, если вы найдете ошибки в моей матрице трассировки, присылайте. Это будет значить, что я его не зря проделал работу.

3. Матрица не полна. Полная матрица в формат доклада никак не лезла. Там было бы очень много элементов. С полной диаграммой хорошо работать на мониторе 60", с разрешением 4k. Но никак не через "смотровую щель" ноутбука.

4. Это пример, как такие матрицы можно строить. Просто иллюстрация подхода.

------------

Постановка задачи.

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

Февраль 26 2016

138. Литература по манипулированию людьми

Некоторое время назад мне пришел любопытный запрос:

Добрый вечер, Сергей.

«Я заметил, что вы не указали ни одной книги по риторике, софистике, эффективным комуникациям.

А у меня в последнее время складывается впечатление, что намного важнее “громко кричать”, нежели хорошо работать. В связи с этим вопрос к вам: можете посоветовать книгу, чтобы научиться “громко кричать” [:)]

Спасибо»

Судя по всему, автор запроса прав. Но я бы выразился точнее. Не «эффективным коммуникациям», а «эффективным манипуляциям».

Отвечаю.

-------------------

Первая книга в списке, это {«Психология влияния» Роберта Чалдини} Книга содержит описание очень сильных техник манипуляций и средств защиты от них. Что особенно приятно, каждая техника прошла исследование в соответствии с научным методом познания: наблюдение, гипотеза, эксперимент. Техник описано может и немного, но зато они расписаны подробно. Другие книги Чалдини я не читал, ничего не скажу. Но я планирую их прочитать.

Сравню книгу Чалдини с плохими книгами по психологии. Книгами, которые я читать не рекомендую. Это в частности все книги Карнеги и популярные «Ментальные ловушки» Андре Кукла. Карнеги я читал более четверти века назад и тогда еще не отличал халтуру от стоящей литературы. С «Ментальными ловушками» я такой глупости не сделал. Просмотрел одну главу, нашел кучу пропусков и несоответствий экспериментальными данными и не стал тратить время.

Следующая сильно понравившаяся книги, это «Ложная слепота» Питера Уотса. Да, это фантастика. Но в отличии от фантаста Карнеги, пытавшегося писать научную литературу, это фантастика, которую писал ученый. В книге очень много информации об особенностях работы мозга. В этом смысле она служит хорошим дополнением к книге Чалдини. Кстати. Ближе к концу книги автор делает очень интересное предположение о том, что в перенасыщенном информации мире, преимущество в карьере имеет менеджер, не включающий мозг. И, похоже, это время уже наступило (смотри "технологическая сингулярность").

Дополнительные книги:

"Buy-Ology: Увлекательное путешествие в мозг современного потребителя." Мартин Линдстром "Фрикономика." Стивен Д. Левитт, Стивен Дж. Дабнер Февраль 29, 2016

139. Тенденции в IT индустрии

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

Дисклеймер. Все нижеописанное - гипотезы.

Первая тенденция. «Автоматизация ради автоматизации». Автоматизация умственного труда не дает того же эффекта, что и автоматизация ручного труда. Внезапно.

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

Пример – процедура замены паспорта в 2001 году была проще, чем в 2016.

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

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

Вторая тенденция: «Прощайте мигающие огоньки».

В 90-х годах даже люди, платившие деньги из своего кармана, покупали «автоматизацию» для «престижу». Но когда деньги перестали плыть бурным потоком, калькулятор все-таки понадобился, и в 2000-х бизнесмены уже начали считать деньги на автоматизацию. А в 2010-х уже и Государственному сектору понадобилось, чтобы ПО было рабочим. Появился спрос на функциональное ПО, способное поддерживать интеграцию с другими системами и при этом соответствующее минимальным требованиям безопасности. Электронный документооборот постепенно перестает быть разговорами об «инновационном завтра». Были поставлены сроки, в которые электронный документооборот должен стать обязательным. С наступлением этих сроков государственный заказчик понял, что старая модель общения с подрядчиками должна быть пересмотрена. То же самое с немалым удивлением обнаружили и подрядчики. «Вы представляете, какие сволочи эти заказчики? Они не только не купили новые сервера за 100500 денег, так еще и хотят, чтобы программа работала!?!?»

Третья тенденция. {«Технологическая сингулярность»}.

Возрастание структурной сложности продуктов.

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

Четвертая тенденция: «Моя хата с краю». Резкое возрастание организационной сложности проекта.

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

Пятая тенденция: «Конец эпохи говнокода»

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

Разработчики стремительно утрачивают способности к анализу. Многие уже просто шарахаются от схемы БД в 200+ объектов, 500+ связей. Хм… дюжину лет назад с такой схемой легко работали тестировщики. Инженерам все сложнее становится читать длинные документы и статьи. Статьи в 3000+ знаков - это «ниасилил, многабукф». В качестве вишенки на торт абсурдная недавняя история. Разработчик не смог прочитать тикет с подробным описанием. В ходе ответов на вопросы разработчика, автор тикета просто ссылался на куски начального описания тикета. Т.е. разработчик не смог прочитать тикет ни с первого, ни со второго, ни с третьего раза.

PS. Напоминаем. Это лишь гипотезы. Вполне возможно, что сейчас трава по-прежнему зеленая.

be happy don't worry

Март 22, 2016

140. Соглашения о наименовании объектов БД

Предисловие

Просматривал старые файлы - обнаружил множество проектных документов.

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

Нам этот документ помог улучшить такой критерий качества, как "Модифицируемость" группы"Сопровождаемость" по ГОСТ 25010.

Что касается НДА- И продукта того нет, и фирмы, и дюжина лет прошла- А документы такого типа по прежнему актуальны.

Чуть не забыл. Чем короче стандарт, тем он эффективнее на единицу текста. Начинайте с коротких стандартов. 500-1000, пусть 2000 слов. В этом документе было 771 слово. И он был эффективен.

======================================

Версия 1.0

Дата: Давно

Автор: Федорова Надежда

-------------------------------------------------------------

1 Введение

1.1 Цель (TBD)

1.2 Область действия документа

Документ применим только для программирования на языке C# для платформы Microsoft .NET Framework.

1.3 Определения, аббревиатуры и сокращения, используемые в системе

1.3.1 Определения (TBD)

1.4 Нотации, принятые в документе (TBD)

2 Соглашения о наименовании

2.1 Основные положения

1. Все наименования должны иметь смысловое значение. Не допускается в наименовании транслитерация. Имена не должны превышать 30 символов.

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

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

4. Для разделения нескольких слов в наименовании, а также для выделения префикса необходимо использовать символ подчеркивания.

5. Желательно избегать сокращений и аббревиатур.

6. Необходимо избегать использования зарезервированных слов.

2.2 Таблицы

Таблицы именуются в единственном числе. Наименования таблиц-связок строятся с использованием имен связываемых таблиц, разделенных символом подчеркивания.

2.3 Поля

Наименование поля для первичного ключа должно иметь вид table_name_id. Наименование поля для внешнего ключа должно иметь вид junction/mapping_table_id

2.4 Индексы

Имя индекса начинается с имени таблицы, которое набирается в нижнем регистре. Цель индекса определяет его префикс.

Наименование первичного ключа представляет собой наименование таблицы с префиксом «pk_».

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

Наименование индекса строится из префикса «ix_», названия таблицы, символа подчеркивания и названия поля, для которого создается индекс.

2.5 Ограничения целостности и значения по умолчанию

Наименование ограничения целостности check строится из префикса «ck_», названия таблицы, символа подчеркивания и либо смыслового названия констрейнта, либо названия поля, для которого вводится ограничение.

Наименование ограничения целостности unique строится из префикса «uk_», названия таблицы, символа подчеркивания и либо смыслового названия констрейнта, либо названия поля, для которого вводится ограничение.

Наименование значения по умолчанию строится из префикса «df_», названия таблицы, символа подчеркивания и названия поля, для которого строится значение по умолчанию.

2.6 Триггеры

Наименование триггера строится из префикса «tr_», названия таблицы, символа подчеркивания и либо названия типа триггера (ins, updt, del), либо смыслового названия триггера – в случае, если количество триггеров для одного действия превышает единицу.

2.7 Представления

Представления именуются с добавление префикса vw_.

2.8 Пользовательские функции

Наименования строится из префикса «fn_» и смыслового названия функции.

3 Рекомендации по дизайну, наложению ограничений, связей, документированию БД

При работе с базами данных рекомендуется:

1. Разбивать объекты по группам, и именовать их по группам для облегчения их поиска при построении в алфавитном порядке.

2. Строго соблюдать регистры в запросах.

3. Не указывать * в запросах SELECT, а указывать столбцы явно, так как это обеспечивает меньшее количество дисковых операций и лучшую дисковую производительность. Также желательно перечислять столбцы в команде INSERT, это позволит избежать проблем при изменении структуры таблицы

4. Не использовать курсоры. Часто можно избежать применения курсоров, пользуясь командой SELECT. Кроме того, цикл while обычно работает быстрее, чем курсор.

5. Избегать использования временных таблиц, вместо них можно использовать табличные переменные и вторичные таблицы.

6. Избегать сканирования индекса – это противоречит цели создания индекса. Рекомендуется избегать использования специальных символов в начале слова при поиске при помощи оператора LIKE и использования в поиске операторов неравенстваи NOT.

7. Всегда добавлять dbo перед именем таблицы.

8. Добавлять SET NOCOUNT ON в начало SQL скриптов, хранимых процедур и триггеров при их выполнении в рабочем режиме, т.к. это убирает сообщения типа '(1 row(s) affected)' после выполнения команд INSERT, UPDATE, DELETE и SELECT. Это увеличивает производительность хранимых процедур, снижая трафик.

9. Использовать более читабельные ANSI-Standard объединения (joins) вместо объединений в старом стиле. С ANSI объединениями выражение WHERE используется только для фильтрации данных, тогда как с объединениями в старом стиле выражение WHERE используется и для объединения, и для фильтрации.

10. Не указывать перед именами хранимых процедур "sp_". Префикс sp_ зарезервирован для системных хранимых процедур, которые поставляются вместе с SQL Server. Если процедура начинается с sp_, то SQL Server в первую очередь пытается найти ее в базе данных master, потом ищет по указанным базе данных или владельцу, после этого ищет среди процедур с владельцем dbo. Поэтому действительно можно сэкономить время на поиске хранимых процедуры, избегая приставки "sp_".

11. Использовать пользовательские типы данных (User Defined Datatypes), если какой-либо столбец постоянно встречается в таблицах, чтобы тип данных этого столбца совпадал во всех этих таблицах.

12. Минимизируйте использование NULL, т.к. это часто приводит к проблемам в приложениях, если только эти приложения специально не убирают NULL или не выводят NULL в какой-либо другой форме. Любое выражение, используемое с NULL, дает результат NULL. Функции ISNULL и COALESCE могут помочь в обработке значений NULL.

Июль 10, 2017

141. Тестирование - это

Часто бывает нужно сравнить несколько определений одного и того же термина. Но выискивать определения по куче книг – занятие довольно длительное. Лучше сделать это заранее и постепенно пополнять список. И заодно свести к "единому знаменателю"

Тестирование это:

1980 Процесс выполнения программы с намерением найти ошибки. Г.Майерс. «Надежность программного обеспечения. М:Мир, 1980»1987 Процесс наблюдения за выполнением программы в специальных условиях и вынесения на этой основе оценки каких-либо ее аспектов. [ANSI/IEEE standard 610.12-1990: Glossary of SE Terminology. NY:IEEE, 1987]1990 Это не действие. Это интеллектуальная дисциплина, имеющая целью получение надежного программного обеспечения без излишних усилий на его проверку.B. Beizer. Software Testing Techniques, Second Edition. NY:van Nostrand Reinhold, 19901995 Тестирование - это проектирование, отладка и выполнение тестов. Борис Бейзер «Тестирование черного ящика» СПб:Питер 2004 «Black-Box Testing. Techniques for Functional Testing of Software and Systems» 19951999 Техническое исследование программы для получения информации о ее качестве с точки зрения определенного круга заинтересованных лиц. С. Kaner, 19992004 Проверка соответствия между реальным поведением программы и ее ожидаемым поведением на конечном наборе тестов, выбранном определенным образом. [IEEE Guide to Software Engineering Body of Knowledge, SWEBOK, 2004]------------------------------------

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

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

И что интересно, для поиска ошибок в программном продукте на входе совершенно необязательно иметь исполняемый код. Некоторые ошибки, такие, например, как связанные с аспектами качества группы «сопровождаемость», ищут не в исполняемом коде, а в исходном. А ошибки функциональной полноты в разы легче искать в требованиях. Что же касается набора сценариев, то некоторым видам тестирования, разработанные и зафиксированные в документе сценарии – это нож острый. К таковым видам тестирования относят: «Коридорное», «A/B» и еще некоторые виды.

И вот тогда все встает на свои места. Процесс поиска ошибок совершенно необязательно проводится «на конечном наборе тестов». И вовсе не имеет целью «получения информации о ее качестве» или «получение надежного программного обеспечения». И для поиска ошибок совершенно необязательно «выполнение программы».

А всего-то требовалось провести декомпозицию процессов.

Да, и забудьте такой термин, как «Процесс тестирования». Забудьте, как страшный сон.

Июль 15, 2017

142. Регламент работы с репозиторием кода

Этот регламент писался давно. Сейчас многое изменилось. Например, SVN теперь не в моде. Да и техники на вашем проекте могут быть другими. Вместо термина "trunk" вы может быть будете использовать "master". А жет еще что-то. Так что адаптируйте документ под себя. А то, что есть – используйте как рыбу. Документ специально написан коротко, т.к. длинные документы никто не читает.

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

Да, еще. Нам этот документ довольно сильно облегчил нам жизнь.

Регламент работы с SVN

История исправлений

Дата Версия Описание Автор

- 1.0 Создан -

- 2.0 Переработка документа -

- 2.1 Корректура текста -

- 2.2 Добавлен формат номера в комментарии, исправлены опечатки -

Лист согласований

Дата Версия Должность ФИО Резолюция

Содержание

1 Введение

1.1 Цель

1.2 Состав документа

1.3 Определения, аббревиатуры и сокращения, используемые в системе

1.4 Нотации, принятые в документе

1.5 Ссылки

2 Требования к репозитарию

3 Инструментарий, рабочая среда и инфраструктура

4 Регламенты

4.1 Обобщенный сценарий работы с SVN

4.2 Получение логина и пароля для доступа к SVN

4.3 Обновление исходных кодов из репозитария

4.4 Переименование и перемещение файлов

4.5 Помещение файлов в репозитарий

4.6 Комментарии при коммите

4.7 Разрешение конфликтов

4.8 Создание ветвей и меток

4.9 Стендовая сборка

1 Введение

1.1 Цель

Цель документа «Регламент работы с SVN» - минимизация времени адаптации нового сотрудника. Документ предназначен для чтения всеми инженерами, имеющими дело с исходным кодом, проходящим испытательный срок.

На этом пункте заострю внимание. Во время испытательного срока новый сотрудник обязан сдать экзамен на знание регламентов. Регламентов: работы со средствами коллективной работы, стиля кодирования и т.д. И да, формальный экзамен крайне важен. Без этого будут разброд и шатания.

И нет. Сами не разберутся.

"Обучение на рабочем месте (термин Деминга)" есть способ приведения сотрудника в "статистически управляемое состояние (термин Деминга)". И это одно из лучших вложений денег в нового сотрудника.

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

1.2 Состав документа

Документ фиксирует соглашения между инженерами разработчиками в части работы со средством коллективной работы SVN.

1.3. Определения, аббревиатуры и сокращения, используемые в системе

Система управления версиями - совокупность регламентов, процедур, инструментальных средств, обеспечивающих управление версиями Программный продукт - совокупность разработанных программ и настроек системного и специального ПО, справки и прочих компонент решающих задачу пользователя Хранилище (репозитарий) - централизованное место для хранения данных и истории изменений, используемое системой управления версиями Релиз - выпуск окончательной версии программы— готового для использования продукта. Релиз - это набор конфигурационных единиц, в отношении которых осуществлено тестирование и которые рекомендованы для использования одновременно. сборка (версия, build) - промежуточная версия программы. Обычно каждая сборка нумеруется натуральным числом, которое увеличивается с каждой новой сборкой. Ветвь (branch) - направление разработки, независимое от других. Ветвь представляет собой копию части (например, одного каталога) хранилища, в которую можно вносить свои изменения, не влияющие на другие ветви. Документы в разных ветвях имеют одинаковую историю до точки ветвления и разные — после неё. метка (tag) - символическое имя для копии всех данных проекта на момент проставления метки. Ствол (trunk) - основная ветвь разработки проекта. Ревизия (revision) - внутренний номер набора изменений в системе управления версиями. Code review -систематическая проверка исходного кода программы с целью обнаружения и исправления ошибок, которые остались незамеченными на начальной фазе разработки. Пользователь - субъект, работающий с системой контроля версий. 1.4 Нотации, принятые в документе

TBD

1.5 Ссылки

[1] Документ, описывающий резервное копирование (что, как и куда нужно копировать)

[2] Документ, описывающий процедуру Code Review

[3] Документ, описывающий стандарты кодирования

[4] Документ, описывающий рекомендуемую структуру папок проекта

[5] Документ, описывающий процесс развертывания системы

2 Требования к репозитарию

1. Репозитарий SVN должен находиться на специально выделенном для этих целей сервере, с достаточным количеством места для хранения данных. Должно осуществляться периодическое резервное копирование репозитария [1]. Ответственный за резервное копирование – TBD.

2. Анонимный доступ к репозитарию должен быть запрещен.

3. Каждый пользователь должен работать под своим логином/паролем (SSH ключом).

4. Структура директорий проекта должна содержать три основных директории: trunk, tags и branches. Структура папок проекта описана в [4].

3 Инструментарий, рабочая среда и инфраструктура

Используемая система контроля версий – Subversion (SVN). Предполагается, что сотрудник умеет пользоваться каким-либо svn клиентом и знаком с основными командами svn клиента. Если нет, то RTFM http://virtlib.odessa.net/subbook/svn-book-html-chunk/

Адрес хранилища: svn://127.0.0.1/

4 Регламенты

4.1 Обобщенный сценарий работы с SVN

1. Пользователь обновляет свою копию данных из хранилища/

2. Пользователь редактирует файлы

3. Пользователь помещает измененные файлы в хранилище.

Кроме того, есть нечастые операции создания ветки, простановки метки и слияния веток.

4.2 Получение логина и пароля для доступа к SVN

Для доступа необходим логин и пароль, который необходимо запросить, отправив email в произвольной форме на имя СА (с копией своему руководителю).

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

4.3 Обновление исходных кодов из репозитария

Исходные коды необходимо обновлять утром рабочего дня, до начала непосредственной работы с кодом. Это необходимо для уменьшения рассогласования локальных копий с версией в хранилище и уменьшения вероятности конфликтов при коммите. Производится путем выполнения команды svn update.

4.4 Переименование и перемещение файлов

Переименование осуществляется командой svn rename, перемещение – командой svn move. Это необходимо для того, чтобы сохранить историю изменений файла.

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

4.5 Помещение файлов в репозитарий

Осуществляется путем выполнения команды svn commit.

Команда svn commit осуществляется по готовности кода быть помещенным в хранилище.Перед выполнением команды svn commit нужно выполнить команду svn update.Рекомендуется совершать отдельные коммиты, закрывающие зарегистрированную в трекере ошибку, если это возможно.Код, помещаемый в хранилище, должен собираться и соответствовать стандартам кодирования. Смотри [2]

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

Не нужно помещать в репозитарий:

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

Проверяется по текущему статусу билда, просмотром лога изменений, проведением code review, анализом производительности труда пользователя.

4.6 Комментарии при коммите.

Обязательно использование комментария при выполнении команды svn commit. В комментарии должно быть краткое описание изменений. При исправлении ошибок допускается указание в качестве комментария номера задачи из багтрекера. Формат номера: #N, где N – номер задачи. Если необходимо указать несколько задач, их можно перечислить через пробел. Это необходимо для быстрого отслеживания изменений в проекте и предотвращения необязательных или ошибочных коммитов. Производится путем указания комментария при осуществлении команды svn commit.

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

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

4.7 Разрешение конфликтов

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

4.8 Создание ветвей и меток.

Новые ветки проекта нужно создавать в поддиректории branches. Новые метки – в поддиректории tags. Ветви создаются для версии кода, которая будет разрабатываться (дорабатываться) отдельно от основной ветви разработки. При работе с веткой проекта следует по возможности избегать перемещения и переименования файлов и создания новых директорий, если впоследствии планируется слияние веток. Основное отличие метки от ветви – метка не подразумевает дальнейшего редактирования помеченного кода, метка нужна только для того, чтобы можно было впоследствии легко получить помеченный ей код. Создание ветви или метки осуществляется путем выполнения команды svn copy.

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

Сейчас, я бы добавил несколько пунктов. 1) Отдельная ветка создается, если предполагается более одного коммита. 2) Крайне желательно, чтобы имя ветки содержало проект и номер задачи из трекера (для Jira что-то такого типа: orion/OR-42).

4.9 Стендовая сборка

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

Август 3, 2017

143. Басня о пользе следования правилам

– Кто пред релизом намёржил всё в мастер?

– Главный программер, наш светоч и пастырь!

В коде уверен, гарантию дал.

Запуск, коннект, первый юзер- упал.

Круто же! ))))

– Кто виноват в этом гнусном паденьи?

Все перед продом стоят в изумленьи. )

– Вася-кьюэйщик – релиз не проверил.

Что же ты, Вася, а я тебе верил!

– Это не я!

– Деплойщица Маша – не так накатила!

На тестовом стенде другая картина!

– Всё по инструкции делала я,

Хочешь не хочешь, вина не моя!

А чья?

Лид же наш Петя уже на Багамах

Сок из бокала тянет устало.

Коммитил он в пятницу прямо на прод,

Но кто о том вспомнит, кто разберёт?

Гит!

Он, как анон, помнит все прегрешенья

И диверсанта сдаст без сомненья-

Гит не поможет – вот страшная сказка.

Поиск виновных терпит фиаско…

Как?

Триггер поправил в базе руками

И в гит не коммитил, мы сами с усами!

– Машенька, срочно забацай откат!

– Поздно, ведь не был сделан бэкап.

Упс.

Мораль же, коллеги, простая у басни:

Правилам следуй – не будет злосчастья.

Полвека копился увесистый свод…

Кто не читал их – тому не попрёт.

===============================

Соавторы: Вера Данилова, Михаил Мерзлютин, Юлия Берестова, Сергей Мартыненко

Это сообщение создано Среда, Ноябрь 29, 2017

144. Мои 300 часов

До дыр затертая зима

до голубых проталин в неба сводах

истоком терпкого тепла

легла моя свобода, солнце

(с) Точка Росы «300 шагов»

Как-то было дело, пригласили меня сделать отдел тестирования. Обсудили варианты, и я согласился.

Первый день осматривался, спрашивал, что и как.

Стартовые данные

Разработка находится в Москве, тестирование на текущей момент в уездном городе. Но в связи с запуском нового проекта решено перенести тестирование полностью в Москву. Дело в том, что если первый проект — это мобильное приложение, то второй проект — это интерактивное телевидение (HbbTV). И для разработки, и для тестирования требуется ферма из телевизоров. А иметь такую ферму в двух местах немного накладно.

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

Примерно, как в фильме «День выборов»:

людей нет;чеклистов нет;плана тестирования нет;в отделе будут работать даже не новички, а стажеры я впервые узнал про HbbTV и опыта тестированиямобильных приложений у меня на тот момент тоже не было;один тестировщик правда уже есть (целых полтора месяца в индустрии), но надо еще двоих Нормальные стартовые условия. Остаемся.

Процесс

На второй день стал писать план создания отдела. Для разнообразия организовал вебинар с процессником из другого города. Парень очень грамотный, а тут я предложил поработать по созданию Голдратовских мыслесхем в лучшей (IMHO) программе для планирования FlyingLogic. Отлично потрудились с часик. Потом Сергей отключился, а я еще пару часов шлифовал схему. Забегая вперед скажу, план оказался необыкновенно точен. Вот график плыл, это да. Но график он на то и график, чтобы плыть. Эта штука вариабельная. А план это совсем другое дело. Главное помните, что план не должен содержать трудоемкости, сроков и исполнителей. Ни в коем случае. Ладно, это лирика.

Далее я утвердил план у технического директора. Поскольку сроки «несколько поджимали», то надо (совершенно необходимо) отказаться от классических схем найма и адаптации сотрудников. Естественно резюме читать бессмысленно (а что они там напишут? что они студенты?). Естественно собеседование проводить бесполезно. Подхожу к тестировщице и говорю: «Я слышал еще пара твоих однокашников не против попробовать свои силы. Пусть приходят.»

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

А далее я начал их учить. Чтобы не перегружать старался новый материал давать порциями. По часу, по полтора в день. Если падала срочная работа – занятия переносились.

Всему учил. Вообще всему.

Процессы тестирования и разработки:

что такое тестирование, и его место в процессе разработки атрибуты качества ПО по ГОСТ 25010 фасетная классификация видов тестирования описание ошибок тестдизайн методы верификации требований типовые ошибки при проектировании баз данных типовые ошибки при проектировании GUI и прочая, и прочая, и прочая Кроме этого давал материал из всех разделов «глубинных знаний» (термин Деминга)

психология, теория вариаций, теория систем, методы познания мира. Так, например, начали мы с игры 2-4-6 (положительная предвзятость). Эта игра отлично демонстрирует особенности мышления и показывает, как должен думать тестировщик. Кроме того, на этой игре удобно показывать одну из техник тестдизайна для тестирования экранных форм и API.

Формы обучения были самыми разнообразными.

Вот пример:

- Коллеги, пошерстите интернет, поищите информацию, как описывать дефект – самостоятельный поиск.

- А теперь рассказывайте, что нашли – семинар.

- Ок, пробуем. Вот приложение, вот дефект. Ты садись за Jira и начинай описывать, а вы двое комментируйте. Время 5 минут, а я пойду пока почту проверю – лабораторка.

- Хорошее описание. Вот это убираем, здесь надо переформулировать, здесь добавить это и это.

Далее даю лекционный материал. Неожиданно из психологии. Рассказываю про эксперимент Мигрема. Объясняю, почему этот материал изучаем таким извилистым путем. И как этот эффект губит стендапы, митинги и т.д. Потом рассказываю о типовых ошибках при описании. И наконец, о двух принципиально разных подходах к описанию дефекта. Дело в том, что можно описать проблему, а можно предложить решение. И новичку лучше не пользоваться вторым методом. Уж больно много там подводных камней. В первую очередь, связанных с психологией. Объясняю и эти подводные камни.

Вот эта последовательность: самостоятельный поиск -> семинар -> практика -> лекция, - она очень эффективна.

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

Учил делать все. Проектировать чеклисты, писать деловые письма, готовить слайды, писать руководство пользователя.

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

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

Понятно, что были и форсмажоры. Сессии, каникулы, болезни. Одна из девушек отбыла в Прибалтику по программе обмена студентами. Упс. Для уменьшения вариаций наняли нового стажера на полный рабочий день. Тоже без резюме и собеседования.

Итого получилось примерно 300 часов. Лекционный материал, безумные чаепития, и практика, практика, практика. Очень много практики. А потом экзамен. Вроде как получился годовой институтский курс.

Результат

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

Для меня отзыв это: «Что изменилось в вашей работе после моего тренинга?» Один из моих учеников ответил: «Рост зарплаты в три раза за два года». На мой взгляд, неплохой результат.

Что получилось в этом случае? После изучения работ Голдратта я бьюсь за очень небольшое число метрик: time2market, уровень бездефектности и операционные расходы в расчете на одну фичу.

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

Вторая метрика – уровень бездефектности. На мой взгляд – все хорошо. Учитывая, что я перфекционист, это был очень хороший показатель. Понятно, что проблемы на проде были. Как-то раз сторонний разнаботчик, библиотеку которого мы использовали выпустил новый релиз. И у тех клиентов, у которых прошло обновление, начал отъезжать наш функционал. Было несколько нервных дней, когда мы пытались локализовать проблему. Предотвратить такое можно, но очень дорого. Для этого надо следить за всеми изменениями в окружении, на всех платформах. Было дело apple выпустил iphone X с другим экраном. Опять проблема. Что интересно, в мобильной разработке бездефектность очень важный показатель. Фидбек получается очень быстро. Только на проде появился баг и сразу куча негативных отзывов, падение рейтинга и падение продаж. Почти мгновенно. Это не гостендеры, где можно откат побольше дать и протолкнуть забагованный софт. Фирма, в которой я работал делала очень хороший софт. Даже по моим меркам очень хороший. Видимо «эффект хирурга» сказался.

А по третьей метрике на «выпускном» рассказал технический директор. Ранее одну программу тестировала группа из трех человек на фултайме. Итого 120 человекочасов в неделю на один проект. У нас получилось: два проекта (примерно одинаковых по масштабу), три человека на половинной ставке. Примерно 60 человекочасов в неделю на два проекта. И еще оставалось свободное время. Т.е. производительность возросла. Раза в 3-5. Как сказал технический – они с генеральным от этого результата "немного" пришли в замешательство.

Результат для студентов. Могут работать без меня. Сертификаты я им выдал, но если что – дам рекомендательное письмо. Попытаетесь сманить – сманивайте. Технический директор не против. Там сейчас такой запас по мощности такой, что мама не горюй. Сманивайте.

Результат для меня. Очень понравилось. Любимая работа, адекватные люди, софт очень высокого качества. Ну, и для разнообразия рабочее место, с двумя мониторами под виндой + iMac моноблок с SSD и 16 Гб оперативки + 30 разных iPhone и iPad + … Четыре прекрасных месяца. Но «Мавр сделал свое дело, мавр должен уйти». Как говорил чайка по имени Джонатан Ливингстон: «Я тебе больше не нужен. Ты должен каждый день понемногу открывать в себе ту истинную чайку Флетчера, для которого нет преград. Он - твой учитель. Ты должен понять его и суметь им стать.»

Выводы

Я все больше убеждаюсь, что обучение персонала (глава 24 книги «Пространство доктора Деминга») и уменьшение вариация (опять же работы Деминга) – ключ к эффективной работе. У меня результат повторяемый.

PS. Если что, могу со своими 300 часами прийти к вам. Мне этот опыт понравился.

Ночь замела следы в глазах беды

надежда на твои триста шагов

и мой маленький шаг

(с) Точка Росы «300 шагов»

-- Чего еще почитать:

"Моя жизнь, мои достижения" Генри Форд. Вроде там это было еще. Ой, давно-

На хабре была статья, как они это делают.

https://www.ozon.ru/context/detail/id/3707281/

"Пространство доктора Деминга" Генри Нив, глава 24 и 31

Май 1, 2018

145. Посиделки клуба имени Френсиса Бэкона

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

А потом эта группа решила собираться на регулярной основе на «посиделки».

Собираемся в вебе. Пока через zoom. В воскресенье с 10 до 11. Ну, так получилось. Собрания открытые. Может приходить, кто хочет.

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

Первые посиделки были на тему: «Прием на работу без собеседования. Почему так? И как это сделать?»

Прошли посиделки на тему: «Правила работы с трекером». Это не про то, как изменить статус в редмайне. Это про общие правила, которые, как правило, не выполняются. С известным заранее, заведомо печальным результатом (Epic Fail). Набросали ряд очень интересных правил. Плодотворно поработали. Резюме будет в виде отдельной статьи.

Было: обсуждение 11-го правила Деминга: "11. УСТРАНИТЕ ПРОИЗВОЛЬНЫЕ КОЛИЧЕСТВЕННЫЕ НОРМЫ И ЗАДАНИЯ Устраните рабочие инструкции и стандарты, которые устанавливают произвольные нормы, квоты для работников и количественные задания для руководителей. Замените их поддержкой и помощью со стороны вышестоящих руководителей с тем, чтобы достигать непрерывных улучшений в качестве и производительности."

Если что - приходите.

UPD. Ссылка на группу в телеграме: https://t.me/FrancisBaconClub

Май 21, 2018

146. Правила работы с трекером. Синопсис вебпосиделок клуба иФБ

Правила, приведенные ниже были озвучены на “вебпосиделках” Клуба иФБ в мае 2018. Работали по модели первой фазы мозгового штурма. По очереди высказывали правила, которые на взгляд участника наиболее важны. Фазы критики не было. Т.е. это пока материал для обсуждения. Кроме того, участники предлагали эти правила не для крохотных проектов, а имели в голове производство со сложным гетерогенным продуктовым ландшафтом на 100+ систем. Так что, вполне возможно, вам эти правила не подойдут. И да, это, естественно, не все правила. Времени на обсуждения было мало.

Приятного чтения.

1. Инструмент ничего не значит.

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

2. Формулировка заголовка одна из сложнейших задач.

Этому надо целенаправленно учить. К сожалению этой проблеме уделяют слишком мало внимания.

3. Необходима декомпозиция до атомарных задач.

Минимальная Фича - то, что приносит деньги. Это группирующая задача. А атомарная - это не более одного артефакта, находящегося под версионным контролем, не более одного исполнителя и не более полунедели (с учетом вариаций достаточно, чтобы исполнитель делал от 10 атомарных задач в месяц).

4. Все статусы в трекере должны быть понятны.

И чем меньше статусов, тем лучше.

5. Иногда переходы могут быть привязаны к ролям.

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

6. Существует несколько типов задач.

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

Задача, связанная с изменением любого артефакта, находящегося под версионного контролем. В репозитории кода. Такая задача не может быть закрыта с резолюцией “Сделано”, только при наличии ссылки хотя бы на один коммит в репозитории. Как правило, для такого типа достаточно 4-5 статусов. В идеале для этого типа задач должна быть выполнена инспекция кода / другого артефакта. Задача, не связанная с изменением любого артефакта, находящегося под версионного контролем (подготовить ноутбук новому сотруднику, дать доступы к средствам коллективной работы). Задача, которая ставится самому себе. Himself - два статуса. Группирующая задача. Имеется ввиду, что нужно в явном виде разделять управление задачами для бизнеса и управление задачами на уровне исполнителей. Типичным примером группирующей задачи в джире может служить эпик. Но для этой цели эпик служит плохо. 7. Нет задачи в трекере - нет кода.

И никакие поручения устно или через почту не должны отменять этого правила. Именно поэтому недавно в Jira появилось разделение на автора задачи (заказчика) и сотрудника, физически внесшего задачу в трекер. Хотя необходимость этого была очевидна еще до начала работ над Jira. Очевидна тем, кто понимает, как управлять задачами. Задача в трекере является отличным комментарием к коду. И когда очередной инженер будет разбираться с тем, “Зачем же это сделали?!” переход в трекер очень ему поможет. Верно и обратное. Если есть инструмент для codeCoverage, то можно убедиться, что весь измененный код был покрыт тестами в рамках тестирования. Точно тоже самое касается проведения ревью кода. Очень удобно “шагать от задачи”.

8. Финансовые показатели и метрики производства должны быть разнесены.

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

9. Оценка трудозатрат и учет трудозатрат должны быть преданы анафеме.

Результаты эксперимента показывают, что сам факт наличия оценки трудоемкости приводит к увеличению трудоемкости в 1.5 - 2 раза (смотри стр 48 книги Peapleware ISBN 5-93286-061-8). Теоретическое обоснование этому дают Деминг в эксперименте “Воронка и мишень” и Голдратт в книге “критическая цепь”. Учет же трудозатрат с неумолимостью ведет к другой проблеме, сформулированной Голдраттом: “Чем ближе вы к балансу, тем ближе вы к банкротству”. При наличии разделения труда часть сотрудников должна простаивать. В противном случае фирма несет неоправданно большие убытки.

10. Чем меньше полей, тем лучше.

Почти на каждом проекте у кого-то начинает зудеть и чесаться: “А давайте еще вот такое поле добавим. А давайте у нас будет не просто описание, а отдельно шаги, отдельно реакция системы и отдельно фактический результат”. Не надо. Не надо превращать форму создания задачи в систему управления подводной лодкой.

11.Сначала устаканиваем процесс, потом настраиваем трекер.

Настройка трекера должна соответствовать ДТР (дереву текущей реальности). Не будущей, а именно текущей. Не надо настраивать трекер “про запас”.

12. Трекер задач должен быть один!

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

PS. Перепосты данного синопсиса крайне приветствуются. Правила:

Не спрашивать разрешения на перепост. Не указывать линк откуда утащили синопсис. Указать, что это "Синопсис вебпосиделок клуба иФБ". Май 31, 2018

147. Анализ процессов при помощи карт Шухарта. Синопсис вебпосиделок Клуба иФБ

"Шухарт изобрел и опубликовал это правило в 1924 г.

С тех пор никто не сделал ничего лучшего."

Что такое карты Шухарта?

Существует множество способов описания процессов: BPML, UML, IDEF, блок схемы, EPC, забытые структурно-информационные временные диаграммы и т.д. Они очень хорошо помогают, когда надо писать софт. Т.е. Когда процессы проанализированы, улучшены и теперь остается только их описать и передать программистам. Но часто нужно именно проанализировать процессы с целью их улучшения.

Кстати, если вы не собираетесь ничего улучшать, то и анализировать ничего не надо. Очень мощными инструментами анализа являются мыслительные инструменты Голдратта: Дерево Текущей Реальности; Грозовая туча, План преобразований и т.д. К сожалению, пользоваться этими инструментами довольно сложно. Есть “кирпич” от Детмера "Теория ограничений Голдратта. Системный подход к непрерывному совершенствованию" Но это именно кирпич. И как бы он был не посложнее курса высшей математики. Карты Шухарта проще в использовании.

Выглядят они не так круто, как диаграмма, построенная при помощи BPML но при кажущейся простоте это очень мощный инструмент.

Первое для чего применяются эти карты - это для определения находится ли процесс в статистически управляемом состоянии (здесь и далее употребляются термины Деминга, изучать которые лучше по книге Генри Нива "Пространство доктора Деминга / Организация как система"). Деминг говорит, что "перевод процесса в статистически управляемое состояние первейшая и одна из главных задач операционного менеджмента". К мнению величайшего менеджера 20-века имеет смысл прислушаться. Другой вариант определения это: "карты Шухарта это способ отличить общую причину вариаций от особой". Очень часто ошибки в определении типа вариаций ведут к серьезным потерям. А иногда и к катастрофе. Очень наглядно это демонстрируется в эксперименте "Воронка и мишень".

Немного истории

Уолтер Эндрю Шухарт (18 марта 1891 — 11 марта 1967) — всемирно известный американский ученый и консультант по теории управления качеством. В начале 20-го века разработал технику контроля процесса при помощи карт.

Эту технику доработал Эдвардс Деминг (14 октября 1900 — 20 декабря 1993). И в 1946 году впервые посетил Японию. Надо сказать, что тогда Япония выпускала товары весьма посредственного качества. И карты Шухарта стали одним из главных инструментов для экономического чуда. Один из менеджеров посетивший Японию писал: “Они просто одержимые. Они все измеряют и заносят на карточки”. За несколько лет японцы кардинально уменьшили вариации и достигли потрясающих результатов в качестве своей продукции и своих услуг. По этому поводу родилось несколько историй, баек, анекдотов. Про три бракованные детали, упакованные отдельно. Или история про то как отличная американская лаборатория купила, разобрала и скопировала ксерокс. И все было отлично, только аппарат не делал копии. Интересные байки. Только вот они оказались не байками.

Деминг получил признательность в Японии и был совершенно неизвестен у себя в США.

Но к концу 70-х успехи Японии стали очевидны для всех. И тут, совершенно случайно, о Деминге сняли фильм. И Деминг получил известность в США. Много лет он колесил по стране, давая семинары. Карты Шухарта были одним из элементов "глубинных знаний". Результат известен. Много лет США лидировали в мировом рейтинге. А экономика Японии из довольно посредственной стала звездой второй величины.

А что в России? Карты Шухарта находят широкое применение в различных отраслях промышленности и сфере услуг. Но не в IT. Аналитики от IT очень мало знают об этих картах. Хотя в последнее время лед начал трогаться. В значительной степени сказались лекции Макса Дорофеева и других энтузиастов в изучении теории вариаций. Но пока это капля в море.

Что любопытно. В 1999 году вышел ГОСТ Р 50779.42-99 "Статистические методы КОНТРОЛЬНЫЕ КАРТЫ ШУХАРТА"

Так что применение этих методов в госконтрактах вполне оправдано. И рекомендуется Клубом иФБ.

Применимость в IT

Да где угодно! Можно анализировать:

% 404-х ошибок; % ошибок ушедших на прод (с ранжированием по критичности); Объем стори поинтов, реализованных за спринт; % найденных дефектов на партию в сотню стрипоинтов; Число сверстанных страниц за 40 рабочих часов; И еще много, много чего. Что любопытно. Подходы к написанию SLA, которые сейчас используются в IT устарели в 1924 году. Ну, нельзя писать в SLA что звонок в коллцентр не должен продолжаться более 12 минут! От такого SLA будет только хуже.

Выглядит карта примерно так:

Внимание! Сигма (?) это не среднеквадратичное отклонение. Это “разлет”. Методика расчета есть в ГОСТ-е.

Что здесь измеряется? Да какая разница! Ну пусть будет процент 404-х.

Важнее вопрос, какие группы "плохие"? Вернее не так. Какие вариации вызваны особыми причинами и должны инициировать аудиторскую проверку.

Первая группа попадает под критерий "Шесть возрастающих или убывающих точек подряд". Очень подозрительно.

Третья группа сразу по двум критериям "плохая": "Девять точек подряд в зоне С или по одну сторону от центральной линии" и "Четырнадцать попеременно возрастающих и убывающих точек". Вроде все отлично, все точки группы в зеленой зоне, разброс минимален. Совсем подозрительно… Вспоминается история еще из времен СССР. Опытный рабочий поучает молодого: "Норма в смену - 10 деталей. Сегодня среда, ты сделал 13. Вот две спрячь. А если завтра сделаешь двенадцать, то еще две спрячь. Как зачем? В пятницу получка. Придешь ты в понедельник с бодуна. Сделаешь восемь, да три из них запорешь. Вот тут то заначка и годится. Брак втихую в мусорку и доложишь нормальные детали. А ты как думал? Это тебе не шахматы, тут думать надо чтоб под раздачу на профсоюзном собрании не попасть." Участники посидел начали вспоминать похожие ситуации из современной жизни.

- А я такую ситуацию в производстве видел!

- А я в ритейле.

Кстати. Если списанные часы совпадают с оценкой трудоемкости, то какая-то черепашка врет… Ну вы поняли.

Четвертая группа находится за трехсигмовым пределом. Если б это был токарный цех, можно было бы предположить неисправность измерительного механизма. А для 404-х… Вдруг инженер вместо выборки инженер удаление из лога сделал? А может во время планового обслуживания, сайт с виртуалки аж на выделенный сервер переехал, "и тут все завертелось".

А вот со второй группой все нормально. "Выброс" в пределах нормы. Ничего делать не надо.

Проблемы внедрения этого инструмента

Пожалуй, здесь множество причин:

Это придумано не у нас. Очень мало IT-шников знакомо с теорией вариаций. Для многих теорвер так и остался “игрой в бисер”. Теория вариаций? Это про шарики в урне? Да ну, у нас же реальный проект! Боязнь нового. А вдруг после внедрения этого инструмента начальник станет ненужен? Или еще хуже, инструмент покажет его некомпетентность? Ведь до карт Шухарта начальник ругал за вторую группу и хвалил за остальные. А тут выясняется, что он за свою зарплату просто вредил. Нет, пусть все останется как было. И такой анекдотический случай. Максим Дорофеев строил график выработки программистов за единицу времени. И вдруг на графике резкий выброс производительности. Начали разбираться. Выяснилось, что на несколько дней менеджмент выехал побухать на природу. Вот и получилось у разработчиков сделать вдвое больше. И кто теперь расскажет об этом генеральному? И что потом будет с этим рассказавшим?

И еще немного кучей

Best practice:

Аналитик оценивает время разработки фичи, но не предоставляет эту оценку программисту. Впоследствии за счет анализа этих расхождений между оценкой и трудоемкостью, мы можем понять как получить улучшение результата. Как правило, размер партии для анализа не привязывается ко времени (берется на информация за день, а подряд идущие 100 запросов к серваку и считается % отказов). Существует вторая гипотеза, где выборка должна производиться отрезками по времени. Вероятно правильный подход можно определить экспериментальным путем в каждом конкретном проекте. Истории внедрений

1. Я пыталась это внедрить для метрик производительности команды в скраме. Не зашло(

2. Я применял карты Шухарта на автозаводе, результаты шикарные были - в 4 раза индекс воспроизводимости увеличился. Есть статья где-то. В ИТ не пробовал. От имени ИТ применял для других бизнес-процессов. Один раз был толк вроде, для складского учета.

3. Когда-то давно строил такие карты по производительности тестировщиков. Правда тогда еще не знал, что это карты Шухарта. Выяснил, что после приведения процесса в статистически управляемое состояние (обучение сотрудников, подготовка стандартов и регламентов), выработка тестировщиков очень стабильна и позволяет хорошо предсказывать дату окончания тестирования. В дальнейшем неоднократно пользовался этим и предсказывал дату выхода в промышленную эксплуатацию с точностью в 5-10%.

Дополнительные ссылки

"Выход из кризиса. Новая парадигма управления людьми, системами и процессами" У. Эдвард Деминг. Про карты не слишком много, но очень много дополнительного материала, без которого внедрение карт, скорее, сорвется. "Организация как система" Генри Р. Нив - шикарнейшая книга. Пожалуй, это лучшая книга по менеджменту. Нив ученик Деминга, но у него лучше манера изложения. Или этой книге повезло с переводчиками. "Статистическое управление процессами. Оптимизация бизнеса с использованием контрольных карт Шухарта" Дэвид Чамберс, Дональд Уилер - качество неизвестно, никто из участников посиделок не читал http://penxy.com/momu - слайдкаст от Дорофеева PS. Перепосты данного синопсиса крайне приветствуются. Правила:

Не спрашивать разрешения на перепост. Не указывать линк откуда утащили синопсис. Указать, что это "Синопсис вебпосиделок Клуба иФБ". Июнь 9, 2018

148. Метрики тестирования

Мы все утопаем в океане данных, но при этом, очень редко можем получить необходимую информацию.

© Э. Голдратт

10-го июня прошел очередной онлайн тренинг по метрикам тестирования программного обеспечения. Это один из модулей большого тренинга «Ключевые процессы, метрики и артефакты тестирования». Материал достаточно сложный. И вопрос даже не столько в опыте участников, сколько в знакомстве с теорией ограничений.

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

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

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

1. Количество найденных багов

- В целом

- По времени

- На пользователя

- Только критичные для функциональности ПО

2. Количество репортов от заказчика / клиента

3. Время, затрачиваемое на тестирование очередной поставки

4. Количество тестов которые прошли успешно или не успешно

5. Проценты покрытия кода ( "Что можно получить от отслеживания данного показателя?")

6. Процент покрытия требований тестами

7. Количество найденных тестировщиком багов

- за единицу времени

- за N срок кода

8. Количество отказов ПО за период времени

9. Количество элементов, которые тестировщик поклацал (покрыл ручным тестированием) [:)]

10. Количество повторно открытых задач на тестирование

10.1. "Это не бага, а фича"

Тезисы тренинга:

Метрик тестирования, точно также, как и метрик финансового состояния фирмы мало. Если у вас много метрик, то вы просто утоните в информационном шуме и будете неспособны принимать правильные управленческие решения (смотри «Синдром стога сена»). Метрик должно быть мало (полагаю, до полудюжины). Если вы измеряете много метрик – вы ошиблись в логических построениях. Метрики должны быть оттрассированы на финансовые показатели. Все, что не оттрассировано на финнпоказатели – информационный шлак. При выведении набора метрик нужно начинать с цели фирмы. Попытки начать с самих метрик это как запрягать лошадь позади телеги – путь в никуда. Последовательность создания мыслекарты (мыслесхемы) лучше всего изучать по книге «Цель» Годратта. Вообще, без понимания теории ограничений эти метрики определить очень сложно, если вообще возможно. Для всех проектов по созданию ПО метрики тестирования одинаковы. Если у вас получилось, что они неодинаковы, вы где-то ошиблись в выкладках. Так же эти метрики одинаковы как для ручного, так и для автоматизированного тестирования. Так же эти метрики одинаковы для REST автоматизации тестирования, для Unit тестирования, для автоматизации тестирования при помощи Selenium, Appium, Testcomplete и т.д. и т.п. Если вы получили разные метрики – вы ошиблись в логических построениях. Когда вы считаете ROI для изменения процесса, любого процесса, в том числе и перехода от ручного тестирования к автоматизированному вы должны измерять ровно те же самые метрики. И, внезапно! автоматизацию процессов рабочего центра тестирования не надо начинать с автоматизации процесса поиска дефектов. И уж тем более не надо начинать с автоматизации регрессионного тестирования. Когда у вас будет хороший набор метрик, этот тезис станет достаточно очевиден. В ходе вебинара участники познакомились с лучшим инструментом для построения мыслесхем FlyingLogic. И поскольку это был именно тренинг, а не доклад, мыслесхему участники строили сами. Я могу нарисовать правильную схему. Но тогда она не ляжет «на кончики пальцев» у участников. Схема недоделана. Она неполна, кое-где классы указаны неверно, есть дубликаты, группировка сделана плохо. Схему еще пилить и пилить. Так что если кто-то хочет попробовать свои силы – ставьте FlyingLogic, распаковывайте архив и вперед, «Через тернии к звездам». Да пребудет с вами сила!

PS. Лайфхак. Сначала надо определить метрики процесса разработки ПО в целом и только затем выявлять метрики отдельных процессов.

Июнь 12, 2018

149. Различные подходы к риск менеджменту

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

- 10.07.2005

Предисловие

Понимание процедур сложилось у меня после анализа множества разнородных материалов. Именно такого описания процессов риск менеджмента в литературе я не встречал. Можете считать это моим личным мнением. Приведенные данные имеют некоторое отношение к реальности, но, во-первых, у меня нет полной статистики, во-вторых, я не учитывал множества факторов для упрощения расчетов. Так, например, не учитывались затраты на внедрение корпоративной культуры. Цифры и расчеты «в лоб» не применимы, это только примеры. Для полноценного расчета требуется дополнительное исследование. Любое совпадение с реальными организациями — случайность. I. Оценка рисков как вещь сама в себе

Не знаю почему, оценку рисков часто именуют «Управлением рисками». Да эта процедура является составной частью риск менеджмента. Одной из самых простых. Но ведь часть не может быть целым, не так ли? Это примерно, как показывать на колесо и с гордостью говорить: «От мерседеса», или еще хуже «Это и есть мерседес». Однако такая практика достаточно распространена.

Менеджер, на основании своей экспертной оценки выводит некое значение риска, как правило, одно единственного. И на этом все заканчивается.

— Мы владеем всей необходимой информацией.

— Это я понял. Что мы делать будем?

— Благодаря этим экспертным оценкам мы готовы встретить все сложности проекта во всеоружии.

— Это я тоже понял. А что мы делать будем?

— Теперь мы знаем, что наш проект может потерпеть фиаско, и мы к этому готовы!

— И это я понимаю. А делать то мы что будем?

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

Эдвард Йордан предлагает нетривиальный способ использования значений рисков в политической борьбе. «У этого проекта в случае двухмесячного графика риск не реализации 80%, а при четырехмесячном всего 20%. Навязывая нам срок два месяца, вы готовы взять на себя ответственность за провал?». Ну что ж, по крайней мере, это хоть какое-то использование данных.

Другой вариант — это выделить несколько (с десяток), наиболее «болезненных» рисков и попытаться их минимизировать.

II. Разбиение рисков на группы и работа с каждой группой специфическим образом

Как правило, такой подход используют в кредитно-финансовых организациях.

В этом случае под управлением рисками понимают набор процедур:

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

Диверсификация — процесс, направленный на то, чтобы сделать риски независимыми. Прекрасно выражается пословицей «Не клади яйца в одну корзину».

III. Использование аппарата высшей математики для оптимизации рисков

Расчетный процесс. Подразделение риск менеджмента.

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

Контролирующий процесс. Подразделение внутреннего аудита.

Определение текущих значений рисков.Проверки подразделений, для которых текущий риск отличается от риск-оптимумаСоздание плана действий для приведения текущих рисков к риск-оптимуму.

Примеры.

Рассмотрим расчет затрат на персонал в нескольких фирмах разного типа

Риски:

• P1 — Риск увольнения

• P2 — Риск финансовых потерь при переходе уволившегося сотрудника к конкуренту

• P3 — Риск финансовых потерь, нанесенных уволившимся сотрудником

Возможные меры по уменьшению рисков или/и ущерба от них:

• Увеличение зарплаты

• Использование технологии подбора нового сотрудника

• Внедрение корпоративной культуры

• Развитие системы обучения

Затраты

Совокупные средние затраты на одного сотрудника:

С=К+Р1*(П+О)+Р3*Р1*У

Сеть пунктов быстрого питания

Собрав огромную статистику, составили матрица вариантов:

Получаем, что риск-оптимум для риска увольнения составляет 20%. Т.е. наиболее выгодным является ситуация, при которой из 100 сотрудников каждый месяц увольняются 20.

Этот оптимум достигается при следующих условиях:

• Компенсация — 250$

• Реализация программы «Продай друга»

• Обучение через имитационные техники и тотальный контроль

• Реализация программы «Мы дружная команда и делаем замечательный продукт»

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

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

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

Следующей очевидной задачей будет приведение рисков к риск оптимумам.

Риск-оптимум увольнения (раз в три года работник меняет компанию) достигается при следующих условиях:

Компенсация — 2000$ Подбор персонала через кадровое агентство Обучение через внутренние и внешние тренинги Реализация комплекса мер по созданию корпоративной культуры Сложности.

Для определения риск-оптимумов есть два подхода:

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

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

В целом, второй способ предпочтительней, но, повторюсь, и первый и второй способ труднореализуемы в условиях России.

Июнь 29, 2018

150. Груминг заголовков

Танк Тигр (57 тонн) можно завести ручным стартером (на ютубе есть видео). Это тяжело. Провернуть вручную сам движок – здоровья не хватит. Поэтому сначала раскручивают тяжелый маховик. Идет тяжело, скорость вращения минимальна. Оборот, еще оборот, еще десять оборотов, еще. Быстрее, быстрее. Потом переключаем маховик на двигатель. И движок заводится. Если переключить маховик слишком рано – ничего не получится. И все начинать сначала. Если пойти передохнуть – маховик остановится. И все начинать сначала. Оборот за оборотом, тяжеленную неподатливую тушу маховика. Но если не раскрутить – движок не заведется и танк останется неподвижной, а потому крайне уязвимой мишенью. Хорошо бронированной, с отличной пушкой, но мишенью. Поэтому крути маховик. Крути. И не останавливайся. Пока не наберешь нужный запас энергии.

Вот также с внедрением многих практик в процесс разработки ПО. Одна из ключевых практик – приведение заголовков задач в трекере в читаемый вид. Не "Логин", "Некорректный заказ", "Программа не работает корректно", "Приборы 300", - а что-нибудь более ласкающее взгляд. Небольшое отступление. Есть мнение и не только мое, что эту практику обязательно нужно внедрить до внедрения написания постановки задачи (требований / ТЗ …). Все, всегда пытаются сделать наоборот. С известным заранее результатом. Недавно услышал, что практика причесывания заголовков называется «Груминг». Более пятнадцати лет этому учу, а теперь узнал, как называется.

Ладно, хватит лирики. Работаю со стажерами. Вообще, любой нанятый сотрудник должен проходить стажировку (адаптацию / онбординг). Но здесь действительно стажеры. Разбираем написание заголовков. Все остальное тоже разбираем: декомпозицию, составление читаемого описания, классификацию, … Но это не так интересно. Нужны заголовки. Нужны для сессий планирования состава спринтов. Нужны для PlaningPoker. Для оперативного управления нужны.

Заголовок: Валидация поля Телефон

Э-э-э…

- Штурман приборы?

- 300.

- Что 300?!?!

- А что приборы?

Никто не знает, что означает этот заголовок. И означать он может что угодно. Например, что валидация не нужна. Или нужна, но не очень. Надо лезть в описание. И что, на каждом совещание все снова будут лезть в описание? И кому потом отдать задачу? Фронтэндеру или программисту серверной части?

Описание:

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

Решение на страницах:

"Оформление заказа"

"Регистрация"

"Заказать звонок"

ЛК "Изменить данные"

Убрать семерку из маски поля "Телефон"

Стандартная проблема. Хотели, как лучше. А получили как на всех банкоматах. И на белорусский номер я денег кинуть не могу. Потому, что хотели, как лучше.

А заголовок… Невразумительный заголовок. Но вот прямо в описании есть примерно то, что можно использовать вместо текущего заголовка!

Убрать семерку из маски поля "Телефон"

Поэтому совет. Никогда не пишите заголовок дефекта, не описав дефект полностью. Сначала описание, потом заголовок. Лайфхак: «С письмами делайте тоже самое. Сначала тело письма, потом конверт.»

Первое преобразование выполнили. Нашли смысл проблемы. С этим заголовком можно начинать работать.

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

Второе преобразование:

Убрать семерку из маски поля Телефон – описание что и как делать Разрешить вводить иные коды, кроме +7(Россия) для телефонов – убрали «как» На всех страницах нельзя ввести номер телефона не Российский – теперь это не описание решения, а описание проблемы Отлично! «Еще десять тысяч ведер и золотой ключик у нас в кармане!»

Теперь играем с текстом. Лишние слова убрать, нужные добавить.

Клиент не может ввести номер телефона отличный от РФ Клиент не может ввести номер телефона не российский На всех страницах нельзя ввести номер телефона не российский На всех формах нельзя ввести номер телефона не российский. Например, белорусский номер телефона. Да, переписываем. Да, много раз. Строка за строкой. В блокноте. Или ворде. Или в гуглдоксе. Когда-то давно я «ставил руку» и точно также переписывал почти все свои заголовки по 3-5 раз. Много месяцев. А потом переписывал заголовки своих сотрудников. И переписал их в итоге несколько тысяч.

Первый оборот маховика самый тяжелый Застывшая смазка сводит на нет усилия рук. Нужно вложиться всем телом. Повиснуть на стартере. Рывок, еще рывок. Пошел! Медленно, до обидного медленно.

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

Ввод не российского номера телефона недоступен на всех формах, где требуется ввод номера телефона

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

Итого. Один заголовок – полчаса.

Вначале маховик крутится очень медленно.

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

Многие скажут: «Но это же десятки часов в месяц суммарно! Это очень дорого.» Это дорого. Это вложение. Одно из самых выгодных вложений. Вложений в создание хорошего реестра задач. Нет реестра задач – нельзя управлять. Есть плохой реестр – можно управлять, но плохо. Обычно РП-шник озверев от неохватной массы непонятных задач просто бросает управление. «Будем делать чего-нибудь, как-нибудь. Получим что-нибудь.» Всегда сначала ставится учет (реестр задач) и только потом можно поставить управление. А скрам, там или prince2 – дело десятое. Нет хорошего реестра задач, ни то, ни другое не поедет.

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

Те, кто играли в «танчики», знают: «Поставили на каток (сбили гусеницу) – ты умер.»

Июль 8, 2019

Комментариев: 2

1. MichaelStrizhov написал: 11 Сентябрь 2019

Доброго дня!

Тема напомнила мне про такой американский правительственный ресурс, как https://www.plainlanguage.gov/

Ассоциация госслужащих "The Plain Language Action and Information Network" (PLAIN) распространяет методические материалы по лучшим стилям изложения документов.

Их брошюра - свободна для скачивания "Federal Plain Language Guidelines" - я бы вообще рекомендовал к прочтению нашим ИТ, занимающимся общением с иностранными заказчиками, легко усваиваемый материал, повышающий софтскилы при переписке, общении,

составлении документов (https://www.plainlanguage.gov/guidelines/).

151. Знакомтесь, вариация

На тренинге по контрольным картам Шухарта попросил участников сделать простое упражнение. Написать заголовок для ошибки. У яндекса довольно много навязчивой рекламы. В частности, сделать яндекс стартовой. Проблема у этого предложения - от него невозможность отказаться навсегда. Есть два выбора "сделать" и "не сейчас". А где "никогда"? Можно спорить, ошибка / не ошибка. Для упражнения это неважно. Упражнение выполняли просто. Все пишут в чате телеграма и по команде одновременно отправляют.

И вот результат-.

Возможно, все написали правильный заголовок.

Настоящая проблема в том, что все написали по-разному.

Эта проблема мало кем осознается, но это ОЧЕНЬ серьезная проблема, которую очень легко решить. Легко, но долго.

-----------

Невозможно отказаться от появления модального окна при открытии страницы отсутствует кнопка полного отказа в модальном окне "Сделать стартовой страницей" - нет очевидной возможности отказаться навсегда Модальное окно, которое нельзя отключить навсегда Модальное предложение сделать Яндекс стартовой страницей, появляющееся на главной, раздражает пользователей На стартовой странице сайта yandex.ru всплывающее окно с сообщением раздражает пользователей невозможность исключить появление модального окна с предложением стартовой страницы Яндекс раздражающее всплывающее сообщение при каждом открытии главной страницы Предложение кажущегося выбора Слишком навязчивое модельное окно «Установить Я-браузер» ошибка выборки Нельзя скипнуть всплывающий модальник "Сделать Яндекс стартовой" насовсем Отток клиентов из-за лишних попапов Я, как пользователь, не хочу каждый раз при заходе на страницу видеть модальное окно Пользователь, у которого Яндекс не стартовая страница, видит модальник "Сделать стартовой" каждый раз при заходе на страницу -------------------

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

В частности, чтобы не плодить дубликаты описаний дефектов.

Очень неприятно, если по сути одну и ту же ошибку поправят два программиста. Один тригером в БД, другой на сервере приложений. В 2004 я потратил несколько месяцев, чтобы тестировщики в отделе описывали дефекты одинаково. Хотя бы заголовки. Дефектов было много. 3500, когда начали ставить софт заказчикам. Каждый день тратил полчаса, чтобы отчитать заведенные за день дефекты. Софт получился хорошим. За полгода покупатели нашли 1 (один) дефект, который мы не обнаружили.

Что порекомендую сделать?

Прочитайте: "Груминг заголовков". Правда все равно придется "руку ставить". Попробуйте ввести в фирме стандарт оформления описания дефектов. В первую очередь заголовков. Алистера Коберна почитайте. "Стандарт" написания юзкейсов очень неплохо подходит для описания дефектов. PS. А вариативность заголовков прям таки потрясает. И это при том, что у многих участников 10+, 15+, 20+ лет в индустрии. Тяжелые у нас дела в индустрии.

Январь 21, 2020

152. Новые формы подготовки к докладам и тренингам

Бизнесмены часто задают вопрос: «Почему?».

Это хороший вопрос, но не менее важный: «Почему бы и нет?»

– Джеффри Безос.

Открываю новый раздел у себя на сайте.

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

- Пришлите заявку.

- Давайте лучше обсудим темы, которые могут быть интересны слушателям.

Мне не интересно читать доклад, который интересен только мне. Пусть он будет интересен многим в зале.

Действительно, вот прямо сейчас мне может быть интересен такой аспект как: «Метрики разработки ПО, которые наиболее подходят для анализа при помощи карт Шухарта.» Но не факт, что именно на этой конференции эта тема будет интересной. А, например, «сравнение разных методов организации деревьев в реляционных БД» мне сейчас неинтересна (была интересна 15 лет назад), а аудитории может оказаться интересной.

Для эксперимента попробую поступить по-другому. Буду публиковать анонсы докладов, а потом отдавать темы на голосование. А потом посмотрю. Из чего-то получатся круглые столы на посиделках, что-то станет докладом. А что-то придется разворачивать в тренинг, т.к. на материал достоин целого дня, а то и недели.

- Для раздела "Об авторе"

Чем я могу быть интересен?

Мне не слишком интересно рассказывать то, что я прочитал в книге пару месяцев назад. Гораздо интересней изобретать что-то новое. Мне удалось расширить технику разработки требований, известную как CRUDL. Теперь это CRUDL-тесеракт. Получилось придумать достаточно годную фасетную классификацию видов тестирования. И еще немного по мелочи, вроде тех статей, которыми пользуются тысячи коллег.

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

Достаточно часто материал проходит рецензию у завсегдатаев клуба имени Френсиса Бэкона https://t.me/FrancisBaconClub . Иногда после этого материал отправляется в корзину. Но чаще на доработку. Таким образом получается сделать доклад интереснее.

Март 18, 2020

153. Доклад "Ключевые метрики тестирования"

Расширенная аннотация

Перед докладом крайне рекомендую прочитать книги Голдратта «Синдром стога сена» (в частности там объясняется разница между данными и информацией и поднимается проблема информационного шума) и «Цель-1». Регулярно даю эти советы, но редко кто им следует [;-)] . А материал сложен без предварительного изучения базы. По трехбалльной шкале сложности этот материал примерно на пятерку.

Для затравки приведу список метрик, которые в принципе можно измерять. Как будет показано на докладе, это путь в никуда. Не удивляйтесь «потоку сознания», список писался в режиме генерации идей без фазы критики.

1. Количество найденных багов

- В целом

- По времени

- На пользователя

- Только критичные для функциональности ПО

2. Количество репортов от заказчика / клиента

3. Время, затрачиваемое на тестирование очередной поставки

4. Количество тестов которые прошли успешно или не успешно

5. Проценты покрытия кода ( “Что можно получить от отслеживания данного показателя?”)

6. Процент покрытия требований тестами

7. Количество найденных тестировщиком багов

- за единицу времени

- за N срок кода

8. Количество отказов ПО за период времени

9. Количество элементов, которые тестировщик поклацал (покрыл ручным тестированием)

10. Количество повторно открытых задач на тестирование

10.1. “Это не бага, а фича”

Этот список – скорее информационный шум, нежели информация.

Тезисы:

Метрик тестирования, точно также, как и метрик финансового состояния фирмы мало. Если у вас много метрик, то вы просто утонете в информационном шуме и будете неспособны принимать правильные управленческие решения (смотри «Синдром стога сена»). Метрик должно быть мало (полагаю, до полудюжины). Если вы измеряете много метрик – вы ошиблись в логических построениях. Метрики должны быть оттрассированы на финансовые показатели. Все, что не оттрассировано на финнпоказатели – информационный шлак. При выведении набора метрик нужно начинать с цели фирмы. Попытки начать с самих метрик это как запрягать лошадь позади телеги – путь в никуда. Последовательность создания мыслекарты / мыслесхемы лучше всего изучать по книге «Цель» Годратта. Вообще, без понимания теории ограничений эти метрики определить очень сложно, если вообще возможно. Для всех проектов по созданию ПО метрики тестирования одинаковы. Если у вас получилось, что они неодинаковы, вы где-то ошиблись в выкладках. Так же эти метрики одинаковы как для ручного, так и для автоматизированного тестирования. Так же эти метрики одинаковы для REST автоматизации тестирования, для Unit тестирования, для автоматизации тестирования при помощи Selenium, Appium, Testcomplete и т.д. и т.п. Если вы получили разные метрики – вы ошиблись в логических построениях. Когда вы считаете ROI для изменения процесса, любого процесса, в том числе и перехода от ручного тестирования к автоматизированному вы должны измерять ровно те же самые метрики. И, внезапно! автоматизацию процессов рабочего центра тестирования не надо начинать с автоматизации процесса поиска дефектов. И уж тем более не надо начинать с автоматизации регрессионного тестирования. Когда у вас будет хороший набор метрик, этот тезис станет достаточно очевиден. Также в ходе доклада участники познакомятся с лучшим инструментом для построения мыслесхем FlyingLogic.На какую аудиторию рассчитан доклад? - В первую очередь доклад ориентирован на сотрудников, изменяющих процессы. И не важно, что написано в трудовой. Что узнают слушатели по итогу? - Слушатели получат "измерительный прибор", показывающий, что изменилось. Инструмент мощный. И не удивляйтесь, если он покажет, что некоторые изменения процессов вредят фирме. Язык доклада русский. План доклада:

Игроки на поле и их цели. Метрики цели фирмы. FlyingLogic - прекраснейший инструмент для построения мыслесхем. Мыслесхема метрик тестирования. PS. Доклад может быть изменен.

Март 18, 2020

154. Когда багов создается больше чем решается

Иногда мне присылают вопросы, достойные ответа в виде статьи. Или хотя бы виньетки или драбла.

– Самое интересное - когда багов создается больше чем решается - что в этом случае советуешь делать? Палкой бить?

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

Можно выделить несколько ситуаций, в которых кто-то находит дефект:

1. На продакшене.

2. Во время проекта разработки нового софта.

3. В процессе сопровождения существующего софта. Софт уже эксплуатируется, и выпускаются новые релизы. При подготовке нового релиза тестировщик находит дефект.

Разберем последнюю ситуацию. Тестировщик может искать дефекты в фиче-бранче или в мастере. Мне ближе в мастере, т.к. после тестирования в фиче-бранче по-хорошему все равно придется тестировать мастер после всех мержей. Но подход вполне имеет право на жизнь. Зависит от степени запущенности софта.

Дефекты делятся на:

1. Не правим вообще и живем с ним долго и счастливо. Как с JRA-1330 жили дюжину лет.

2. Правим в рамках отладки фичи. Фичи с этими незакрытыми дефектами не выпускаются.

3. Дефект будет правиться, но не прям сейчас. Выпустим, а потом будет время подчищать долги, вот и поправим.

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

А теперь главное правило работы с дефектами: «Если вы решили править дефект, то время от внесения дефекта в код до исправления должно быть минимально.»

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

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

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

Перейдем к анализу. Перед вами малоизвестная, крайне редко применяемая и крайне полезная диаграмма для анализа потока создания ценности VSM.

W – работа.

M – muda. Потери. Простои в очередях.

W1 – программирование фичи. Точнее внесение дефекта в код.

W2 – нахождение дефекта.

W3 – определение категории: правим немедленно, правим потом, не правим.

W4 – Исправление дефекта.

Как уменьшить время исправления? Довольно простое решение – убрать W3 из производственного потока. Неприятно, да? «Чтобы улучшить производственный поток, нужно устранить из него менеджера и заменить его регламентом». Такова суровая правда науки управления. «Sad but true.»

Далее. После запиливания фичи, тестировщики должны приступать к работе немедленно. Сокращаем m1 до нуля. Для этого тестировщики должны иметь запас по мощности (должны простаивать) 20-25%. «Sad but true.» Или вы занимаетесь субоптимизацией, или вы беспокоитесь об эффективности производственного потока. Если прибыль фирмы важнее чем таймшиты по 40 часов в неделю, то к черту таймшиты!

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

Может показаться, что я не ответил на начальный вопрос. Нет, ответил. Дефект проживший более [года | полугода | квартала] должен автоматически попадать в первую категорию. И закрываться скриптом.

Вот собственно и все. Don't worry be happy.

Июнь 22, 2020

155. История моей фасетной классификации видов тестирования

Немного некропост. Или мемуары.

В 2001 я познакомился с шаблонами документации RUP. В частности, в «Плане тестирования» была интересная и нетривиальная классификация видов тестирования. На мой скромный взгляд, эта классификация из 90-х и сейчас превосходит классификацию ISTQB.

Но что-то мне в ней не нравилось. В 2003 я разработал свою фасетную классификацию. Правда тогда я не знал, что она фасетная. В 2005 впервые {опубликовал}. Но ее еще нужно было дорабатывать и дорабатывать. Тогда еще я не знал о ГОСТ 9126, а до ГОСТ 25010 оставалось 10 лет…

Потом эта классификация появилась в книге у Савина, на тренингах Баранцева, в докладах на конференциях.

Потом Vader опубликовал ее в википедии.

Потом ее в википедии испортили.

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

По-хорошему, надо бы в книгу ее включить. Но это столько ж писать надо…

А теперь тот самый исторический пост.

4.2 Типы тестов

4.2.1 Объект тестирования

Unit (Элемент) – наименьший компонент, который можно скомпилировать.

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

Драйверы – модули тестов, которые запускают тестируемый элемент.

Заглушки - заменяют недостающие компоненты, которые вызываются элементом и выполняют следующие действия:

• возвращаются к элементу, не выполняя никаких других действий;

• отображают трассировочное сообщение и иногда предлагают тестеру продолжить тестирование;

• возвращают постоянное значение или предлагают тестеру самому ввести возвращаемое значение;

• осуществляют упрощенную реализацию недостающей компоненты;

• Имитируют исключительные или аварийные условия.

Тестирование сборки. Проверяется корректность функционирования скомбинированных вместе элементов. Существует четыре стратегии сборки:

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

• Сверху вниз. Высокоуровневые подпрограммы становятся драйверами для остальных элементов. В этом методе используются заглушки, имитирующие поведение низкоуровневых элементов.

• Сэндвич. Здесь комбинируются методы сверху-вниз и снизу-вверх.

• Большой взрыв. Объединяются все элементы.

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

Integration testing – в ходе этого тестирования проверяется взаимодействие тестируемого приложения с другими приложениями.

4.2.2 По целям

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

• новая инсталляция,

• усовершенствование системы (upgrade),

• полная или выборочная инсталляция – при нормальных и ненормальных условиях. Недостаточное количество дискового пространства, недостаток привилегий (например, на создание директорий) и т.д.

Данные и целостность базы данных. Проверяется консистентность данных. Включает в себя проверку:

• ссылочной целостности (основной источник проблем)

• ограничений на значения параметров

• ограничений на неинициализацию значений

• ограничений на уникальность значений

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

Тестирование бизнес-цикла - должно имитировать действия, выполняемые пользователем и охватывать все типичные операции пользователя. Как правило, тесты объединяются в единый тест сьют.

Тестирование графического интерфейса пользователя.

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

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

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

Стресс тестирование - поведение системы при недостатке ресурсов (дискового пространства, обрывов сети, …)

Конфигурационное тестирование - тестирование работы на различных платформах. Различные варианты аппаратной конфигурации, версии операционной системы и окружения (MDAC, .Net, браузеры, …).

Тестирование безопасности и прав доступа - сосредоточено на двух ключевых областях безопасности:

• Безопасность уровня приложения, в том числе доступ к данным или бизнес-функциям.

• Безопасность уровня системы, включая вход в систему или удаленный доступ к системе.

4.2.3 Способ работы с кодом

White-box test. Тестирование методом «Белого ящика». Для конструирования тестов используются внутренняя структура кода и управляющая логика. При этом существует вероятность, что код будет проверяться так, как он был написан, а это не гарантирует корректность логики.

Black-box test. Тестирование методом «Черного ящика». Для конструирования тестов используются требования и спецификации ПО. Недостатки:

• таким способом невозможно найти взаимно уничтожающихся ошибок,

• некоторые ошибки возникают достаточно редко (ошибки работы с памятью) и потому их трудно найти и воспроизвести и т.д.

4.2.4 Стадии тестирования

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

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

В более общем смысле первый прогон программы (после написания или после внесения существенных изменений). Как правило используется для определения готова ли программа для передачи в тестирование и продолжается до 4-8 часов.

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

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

4.2.5 Метод выполнения.

Ручное тестирование – ввод исходных данных и проверка корректности результата производится непосредственно человеком. Слабо применимо для:

• нагрузочного тестирования

• тестирования производительности

Автоматизированное тестирование - ввод исходных данных и проверка корректности результата производится специализированным ПО.

Июнь 23, 2020

156. Форд, Тойота и морские свинки

— Какое отношение имеет морская свинка к морю? — Примерно такое же, как утконос к проектированию дирижаблей.

Введение.

Я имею обыкновение во время прогулок прокручивать информацию из нескольких источников, сопоставляя куски. Одна из любопытных находок – почти полное соответствие статистических наблюдений Демарко и Листера в «Peopleware» и теоретических выкладок Голдратта в «Критической цепи». Осенью 2011 я крутил в голове: [1] «Стоя на плечах гигантов» Эли М. Голдратт © Eliyahu M. Goldratt, 2008 [2] «Производственный менеджмент: управление потоком» Одед Коуэн, Елена Федурко [3] «История одной доски» (http://cartmendum.livejournal.com/tag/theboard).

Далее хотелось бы написать: «Как вдруг…», — но это будет неправдой. Это случилось не вдруг. Мне понадобилось пару недель, но, в конце концов, в голове сложилась достаточно цельная картинка.

За что именно я зацепился:

Таичи Оно (Öno Taiichi) не понимал, почему его система работает.

Существует несколько разных типов производственных потоков – V, A, T, I. Каждый тип потока ставит особые задачи.

Неудачи внедрения доски Максима Дорофеева в некоторых подразделениях

Ряд компаний не смог внедрить систему Тойота, несмотря на все приложенные усилия.

Система Тойота и система Форда основывается на одинаковых принципах, но прикладные решения ограничены определенными типами производства.

Теория. Типы потоков

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

Если нужна более подробная информация, то лучше обратиться к статьям Одед Коуэна (Oded-Cohen) и Елены Федурко.

В мире производства ПО можно провести аналогию:

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

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

Возможно, кому-то захочется изменить классификацию. Мне, например, захотелось. Я предпочел бы добавить еще два типа:

Но это отступление от стандарта, а стандарта, даже плохого лучше придерживаться.

Есть подозрение, что Ж-тип это более правильное название Т-типа, просто американцам не повезло с алфавитом. ;-)

I-тип

Самый простой для управления поток I-типа.

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

Рассмотрим классический пример характерный для IT-индустрии. Возьмем простую, даже тривиальную цепочку «Отдел продаж» -> отдел программирования -> отдел тестирования.

Схема процесса:

Пусть отделы могут обработать соответственно:

Отдел продаж – 20 заказов в неделю

Отдел программирования – 10 заказов в неделю

Отдел тестирования – 5 заказов в неделю

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

> Бить сейлов по рукам и не давать им набирать проектов более чем успевают делать программисты. Естественно, что перед отделом программирования должен быть небольшой буфер проектов.

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

По-русски: в фирму деньги несут, а некоторые намерены их послать.

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

Балансировка участков по производительности также не приносит счастья. В системе возникают «биения» и среднее время выполнения заказа опять-таки возрастает до неприличных величин.

У Макса Крамаренко в блоге описано моделирование сбалансированной производственной цепочки:

http://maximkr.livejournal.com/18940.html

http://maximkr.livejournal.com/18971.html

Моделирование показывает, что в результате биений производственная цепочка быстро забивается. В конце эксперимента для короткой цепочки всего из 4 участков в производстве находилось полторы сотни задач. Переводя на «современный менеджерский» это означает, что задача трудоемкостью в четыре человеко-дня будет реализована через полгода. На вопрос менеджера: «Что ж так долго-то?!», — ответ прост: «Потому что так управляете».

Это важно. Вина за огромную длительность выполнения заказа почти всегда лежит на системе управления потоком работ (менеджменте), а не на исполнителях.

Ну а кто не верит – может сам попробовать написать имитатор и поэкспериментировать.

Справедливости ради, следует упомянуть, что сбалансированную цепочку вполне можно использовать, если выполнять правило: «Среднее время простоя сотрудников должно быть не менее 20-25%». Но опять же, кто из менеджеров на это пойдет?

A-тип и решение Форда

Проблема потока этого типа – недостающие компоненты на сборочных операциях.

Производственная цепочка I-типа примитивна как грабли и незатейлива как молодой редис. Я полагаю, что оптимальный способ управления такими цепочками был известен давным-давно, но к сожалению, я пока не нашел информации, в каком веке впервые была описана эта методика. Однако, в какой-то момент детство заканчивается и перед менеджерами встают по-настоящему сложные задачи. С подобным вызовом, наряду с другими столкнулся Генри Форд. В ту пору производство автомобилей на предприятии Форда было производством A-типа. Сложным, со многими ветвями, но имеющим одну вершину. Одна единственная марка автомобиля, один единственный цвет. Отсутствие запаса любой детали на любом участке сборки приводит к увеличению времени производства автомобиля. Но чрезмерный запас деталей также приводит к увеличению времени, которое необходимо, чтобы из железной породы получить готовый автомобиль. Время увеличивается, т.к каждая деталь существенную часть времени проводит в очереди ожидания.

В 1913 году Генри Форд внедрил на своём предприятии конвейерный метод сборки автомобилей. А к 1926 году производственный цикл от добычи железной руды до получения готового автомобиля (состоящего более чем из 5000 деталей), находящегося на железнодорожной платформе и готового к отправке, достиг 81 часа!..

[1] Выдающееся достижение. Представьте себе сложность настройки процесса производства ПО, состоящего хотя бы из 50 производственных участков. Полагаю, что большинство современных менеджеров запросило бы сложную АСУ (автоматизированную систему учета) для управления потоком работ. Но в начале века не было компьютеров…

Вопреки расхожему мнению, поточная линия Генри Форда — это не привычный нам ленточный конвейер, по которому синхронно движутся собираемые автомобили. Это отдельные рабочие центры, с ручной передачей деталей. «Чтобы улучшить производственный поток, Форд ограничил пространство, предназначенное для складирования запасов незавершенного производства между каждыми двумя рабочими центрами. В этом и состоит сущность поточных линий, что подтверждается тем фактом, что первые поточные линии не имели никаких механических устройств, типа конвейеров, для перемещения запасов (незавершенного производства) от одного рабочего центра к другому.» [1].

За неимением компьютеров Форд создал визуальную систему управления работами. Предельно простую в использовании.

Да, естественно, эта система не заработала бы, если бы не было введено дополнительное правило: «когда выделенное место заполнено, рабочие, которые его заполняют, должны прекратить производство». Пойти погулять, вздремнуть, посидеть в Контакте,…

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

Более сложные типы и система Тойоты

Проблемы потока V-типа – «кража материала»; Проблемы потока T-типа — «кража» и недостающие компоненты;

Визуальная модель Форда прекрасно работает для А-типа. Но как только появляется не слияние, но разветвление (один рабочий центр поставляет детали для нескольких центров) начинаются проблемы. Именно эти проблемы ликвидировали преимущество поточных линий Форда в тот момент, когда Дженерал Моторс вышла на рынок с широким модельным рядом. Менеджерам компаний снова был брошен вызов.

Перчатку поднял Таичи Оно, начавший работу в Toyota Motor Corporation в 1943 году. В середине 1950-х годов он начал выстраивать особую систему организации производства, названную впоследствии «Производственная система Toyota» (также ошибочно именуемую канбан, Lean, Just-In-Time).

У Оно, как и у Форда не было АСУ и он разработал визуальную систему управления потоком работ, основанную на канбан (вариант перевода: визуальная карточка). Однако эта система не принесла бы такого эффекта без дополнительных требований. В каждый момент времени на участках, имеющих запас по мощности необходимо делать одно из двух улучшений: или уменьшать размер партии (увеличивать число переключений и сопутствующих им потерь), или уменьшать время переналадки.

«В то время и до тех пор, пока TPS не получила всемирную известность, традиционным способом снижения времени переналадки считалось увеличение размера партии — «экономически обоснованный размер партии» был очень популярным термином, которому посвящались тысячи статей. Оно отбросил весь этот традиционный опыт.» [1]

Оно бросил вызов современной ему системе менеджмента. Логично, что ему этого не простили. С конца 40-х до начала 60-х годов его систему называли «отвратительной системой Оно».

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

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

А далее начинается самое интересное. Если рабочий центр участвует более, чем в одной из цепочек, то эти цепочки необходимо на схеме сложить:

Левый и правый потоки A-типа и могли бы управляться визуальной моделью Форда, но ввиду совместного использования рабочих центров «3» и «4» схема усложняется и нужно переходить к модели Оно. Если же не хочется использовать настолько сложную модель, то следует разделить рабочие центры «3», «4» на «3’», «3”», «4’», «4”»

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

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

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

Пусть исторически сложилось так, что в фирме есть один отдел, отвечающих за поддержку внутренних продуктов и выполняющий доработки для нескольких заказчиков. Возьмем достаточно распространенную структуру «программирование -> тестирование». Простейший, тривиальный I-поток, легкоуправляемый. В какой-то момент времени качество поставки перестало удовлетворять заказчиков и в фирме рассматривается вопрос о введении стадии приемки. За и против? Против: произойдет изменение типа потока, и возникнут проблемы управляемости. Вместо одной цепочки I-типа будет одна сложная цепочка.

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

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

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

Иногда в крупных фирмах идут на жесткое пресечение случаев проявлений «Слуга двух господ». Одним из вариантов, о которых я слышал – это внутренняя биржа труды. Инженер соответствующей специализации находится в структурном подразделении (программист в пуле программистов) и подчиняется менеджеру пула. Подчиняется до тех пор, пока не будет передан в проект. После этого оно подчиняется только руководителю проекта. Отдача прямого распоряжения инженеру, занятому в проекте, кем-то кроме руководителя проекта – это залет, который вполне может закончиться кадровыми перестановками. Фирма немного проседает ввиду неполной занятости сотрудников, но выгоды от простоты управления настолько огромны, что перевешивают эти потери. В дополнение к этому используется принцип «Вассал моего вассала – не мой вассал» — командир взвода не может отдать приказ напрямую солдату. А если отдаст, то будет искать новых сержантов. Или сержанты будут искать нового командира взвода.

157. Канбан-доска и морская свинка

Популярный в РФ MSProject неплох для планирования проектов. Для планирования процессов он подходит несколько хуже. Для планирования процессов банальный трекер часто оказывается лучше. Но важно не это. И трекер и Project являются «Информационным холодильниками» (термин введен Алистером Коберном в одной из лучших книг по методологиям «Быстрая разработка программного обеспечения»). Для повышения эффективности разработки нужен «Информационный радиатор». И естественно, нужны правила управления работами.

Тут может сложиться впечатление, что доска — это информационный радиатор. На самом деле модные доски — это те же трекеры, то есть, те же холодильники. Что бы превратить доску в радиатор, нужно ее вешать в общедоступном месте. А как только под доску начинают использовать какой-либо web-инструмент, она тут же становится холодильником. Ну, если ее не выводить на плазму в коридоре или под потолком.

Несколько лет назад было предложено использовать доску, на которую помещаются стикеры с описанием задач. Сейчас это довольно модное увлечение. По запросу «Канбан доска» поисковик выдает массу ссылок на что-то вроде:

этого: На рисунке явно изображена визуальная система управления для потоков I-типа. Не имеющая никакого отношения к системе Таичи Оно. Более того эта система более примитивнее чем даже система Генри Форда. Данная «прогрессивная» модель отстает от теории и практики науки управления потоком работ «всего» на век.

Казалось бы, ну назвали неправильно и что? А то, что неправильный термин дает иллюзию всеобщей применимости инструмента. Слишком часто консультанты пытаются применить эту доску для неподходящих типов потоков. Естественно, попытка терпит неудачу, но консультанты почему-то обвиняют исполнителей. «Вы просто неправильно использовали XP / SCRUM / Kanban / …» Господа, если завинчивание гвоздя крестовой отверткой потерпело фиаско, то не стоит винить исполнителя в том, что он держал отвертку неправильно. Нужно просто дать ему молоток.

Рекомендую с опаской и настороженностью относиться к «консультантам» по «XP / SCRUM / Kanban», которые не знают теории производственных потоков. Не то чтобы их совсем нельзя было использовать, но неумение применять теорию потоков, карт Шухарта, неумение складывать вероятности выполнения при существенных девиациях срока исполнения и прочее, и прочее должны вас насторожить.

В дальнейшем я буду называть такую доску I-доской. Что же касается правил управления, то на семинаре Сурен Самарчан (видеокаст: http://spmguild.org/news/618/) говорил, что задачу в производство можно брать, только если кто-то из программистов освободился. Достаточно легко можно понять, что это будет работать, только если ограничение системы (часто ошибочно именуемое именуемое «бутылочным горлышком») находится в начале производственной цепочки (смотри управление колонной туристов в книге «Цель» Голдратта).

Достаточно часто в изолированных маленьких кроссфункциональных группах разработки именно так и происходит. Ограничение находится в начале производственной цепочки. И все идет хорошо. Но как только ограничение системы переходит куда-то еще, … Все finita la comedia. Нужно систему «Немного подшаманить». Максим Дорофеев нашел эмпирическое правило «Число задач в производстве не должно превышать число программистов более, чем на 2». Нормальное такое шаманское правило.

Более интересный тюнинг доски был предложен Олегом (не указал фамилии) в статье «Канбан в IT (Kanban Development)» (http://habrahabr.ru/blogs/development/64997/ ).

А теперь самое важное. Видите цифры под каждым столбцом? Это число задач, которые могут быть одновременно в этих столбцах. Цифры подбираются экспериментально, но считается, что они должны зависеть от числа разработчиков в команде.

Напоминает поточную линию Форда, но примененную к потоку I-типа. Собственно, это и есть визуализация правила Генри Форда: «Объем незавершенного производства между двумя рабочими центрами должен быть ограничен».

Как ни странно, но часто ограничением системы выступает участок приемки задачи заказчиком. Мне известно минимум три фирмы, где наблюдался этот эффект.

Есть еще одно ограничение на использование I-доски. Это ограничение связано с эффективностью цикла на одном производственном участке (у одного исполнителя). Если эффективность цикла менее 50% то правило «у одного исполнителя только одна работа» начинает сбоить.

Примечание. Эффективностью цикла называют отношение времени обработки к общему времени нахождения на производственном участке. Если утром вам пришла задача, а сделали вы ее только перед уходом, то общее время – 8 часов. Если вы работали над задачей 2 часа, то эффективность цикла 25%.

Приведу примеры, когда ограничение в одну задачу у исполнителя в единицу времени будет неэффективным:

Полицейские проекты (www.toc-center.ru/politseiskie_proekty.html )

Написание ТЗ и ПМИ (ГОСТ 34.602 и 34.603). Документы сильно влияют друг друга и иногда проще писать одновременно два документа.

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

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

Если это случилось подтюньте правила использования. Разрешите исполнителю работать одновременно над несколькими задачами.

И еще одно ограничение. I-доска плохо визуализирует связи между задачами. Она неплохо подходит для процессов сопровождения с независимыми задачами и хуже для проектов. Хотя для коротких проектов со слабо связанными задачами может быть и подойдет.

Тем не менее, такая доска очень проста в использовании и если подразделение подходит для внедрения, то это один из эффективнейших способов управления потоками. Все таки и систему Форда и систему Оно достаточно сложно визуализировать.

Просто перед внедрением такой доски нужно пройтись по чеклисту:

Поток I-типа? Если нет, то скорее всего придется отказаться от попыток внедрения простой доски.

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

Эффективность цикла на одном производственном участке более 50%? Если нет, то снимите ограничение на обработку только одной задачи одновременно.

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

Часто камнем преткновения становится поток сложного типа. Для упрощения типа потока действенным лекарством является выделение и изоляция отдельных проектных групп и функциональных подразделений.

Но, слишком часто мы слышим фразы: «Мы не можем его не дергать. Кроме него этого никто сделать не может. И полностью перевести его к нам нельзя. Нам он нужен всего на четыре часа в неделю.»

Выход лежит в устранении эффекта незаменимости. Пойдет и XP-шное совместное владение кодом, и введение стандартов кодирования и обучение смежным специальностям (одно из экзотических сочетаний, которое нам сильно помогло в одном из проектов это «системный администратор» и «компьютерный художник» в одном лице).

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

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

Коллеги утверждают, что это правило, внедренное в порядке эксперимента показало неплохой результат.

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

Другим вариантом является уменьшение длины потока. Уменьшение числа рабочих центров способно кардинально изменить картину.

Любопытная задача, основанная на наблюдениях за реальными процессами в реальных фирмах. Возьмем два потенциально интересных проекта. Оба они, будучи выполненными прямо сейчас приносили бы по $2 000 каждый месяц в течении полутора лет (от момента сейчас). Потом рынок изменится и прибыль исчезнет. Соответственно, чем позднее окажется дата завершения проекта, тем меньше денег удастся получить. Будем считать, что человеконеделя трудозатрат стоит фирме $2 000Первый проект может быть реализован в рамках одного департамента по единым руководством по схеме: Двухнедельный цикл разработки в группе программирования + двухнедельный цикл тестирования и отладки совместно группами тестирования и программирования. Циклы жестко связаны, временного зазора нет. Чистое время реализации – 4 недели, трудозатраты – 6 человеконедель, расходы - $12 000Второй проект предполагает участие сотрудников 4 разных отделов, по неделе каждый. Параллельно запускать нельзя, только последовательно. Чистое время реализации – 4 недели, трудозатраты – 4 человеконедели, расходы - $8 000.Вопрос: «Каковы ROI проектов?»Совершенно неправильный ответ:Для первого проекта доход: 18*2000 = $36000…Дальше можно не продолжать, потому как вменяемому менеджеру, который знает теорию, известно, что проекты мгновенно не делаются.Просто неправильный ответ:Первый проект будет закончен через 1 месяц, итого доход (18-1)*…Дальше можно не продолжать, потому как вменяемому менеджеру, который знает не только теорию, но и жизнь, известно, что проекты мгновенно не начинаются.…Правильный ответ: Первый проект не может быть выполнен за месяц. Разве что прилетят инопланетяне и «соберут урожай». И невозможно это потому что очередь на реализацию длинная и забита «Задачами, которые давно обещали», «Задачами, которые поставил Сам» и «Просто важными задачами». Реальное время до финиша - месяца четыре. Вот теперь можно считать. Доход – (18-4)*2 000 = 28 000, прибыль – 28 000-12 000=16 000, ROI=133%.Второй проект продлится год. Еще раз. Год. И это в лучшем случае. Если за это время ничего не изменится и проект не заморозят. Большую часть времени проект проведет в очередях ожидания. Да, это реальные наблюдения за реальными проектами в реальной фирме. Доход (18-12)*2000 = 12 000. Прибыль – 4 000, ROI – 50%У второго проекта меньшее ROI, и несравненно более высокие риски. От второго проекта я рекомендовал бы отказаться, в пользу первого.

Из наблюдений: Цепочки из пяти – шести рабочих центров, не связанных жестким общим руководством, часто, делают бессмысленным запуск проекта в производство. Он станет ненужным раньше, чем его завершат. Относительно стабильны цепочки с двумя рабочими центрами. С тремя уже возникают проблемы. Цепочка 1->2->1, предположительно, более стабильна, чем 1->2->3.

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

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

А если и система Оно не применима?

Тогда нужно переходить на полноценную TOC. А в качестве визуализации системы управления работами я хочу попробовать систему изменения приоритета, предложенную Голдраттом в статье «Стоя на плечах гигантов». Только вот как ее реализовать в «металле»? Интересная задача для системного аналитика: «Понять идею, выбрать движок и написать постановку на кастомизацию». Чутье подсказывает, что в качестве движка вполне можно взять трекинговую систему middle уровня. TrackStudio может подойти.

Вместо послесловия

И постарайтесь не перепутать тип производственного потока вашей группы. Лечение диареи или запора достаточно простое. Но если перепутать лекарства, то результат вас может несколько удивить.

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

Заключение

Ну вот и все.

Отдыхает перо.

И чай сладенький

Пью я из кружки.

Мне сегодня уже все равно

Книгу выложить

Как выложить душу.

А если серьезно, впереди еще:

* расшифровка и публикация материалов по посиделкам клуба имени Френсиса Бэкона;

сказки лишних;лучшая в мире книга по тест дизайну;книга «При дворе Императоре первом».Ох, что-то меня несет. Но что-то сделаю. Постараюсь. Сказки родственники просят. А по разработке ПО просто надо. Иначе меня разорвет.

© 2005-2020 Сергей Мартыненко aka SALar.