Реальность субоптимизации

Помнится мне что-то такое еще с университетских времен. А тут посмотрел и понял конкретное применение в управлении проектами и командами в ИТ. И это точно надо "заложить" себе и тому кто прочтет.

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

А считаем мы эффективность из отношения суммы сколько на каждом этапе работали над нашим  вопросом (подразумеваем: тикетом/ишью/задачей/требованием/баг-репортом) к общему времени работы над ним. Т.е. сколько суммарно записал каждый человек, что работал с багом ко времени сколько баг находился в активном состоянии. Считать можно в чем угодно, но единицы измерения должны быть одни и теже: дни, недели, story points, мартышки, папугаи, -- но одинаковые в числителе и знаминателе. Если выш процесс более специфический, то просто исходите из классики:

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

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

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

Гармония важна в любом аспекте жизни. :)

Как мотивировать наших людей

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

А лучше всего вести нашего человека в обозримое светлое будущее, с морковкой внутри и стимулом (тем самым) сзади. Человек всегда должен быть чем-то недоволен немного, в лени люди теряют форму

SQA Days 7, Харьков. Часть первая

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

Началось все утром в пятницу, 14 мая. Проводили в Радмир Экспохолле, хотя где еще можно это проводить в Харькове пока придумать не могу.
Пока народ прибывал и регистрировался, я немного поправил здоровье горячим чаем и уточнил программу конференции. Очень приятно, что программа конференции была отдельно в раздатках, потому что в последний день произошли изменения и было бы неприятно бегать в поисках нужного доклада. Хоть рецензий на изменения и не было в распечатаном сборнике тезисов. Также в раздаточных материалах был диск с материалами конференции. Приятно порадовал бонус в виде материалом по SQA Days 4 и 5.

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

В начале слушал "Сокращение времени выполнения регрессионного тестирования", Павел Моцарь. Как человек выступал понравилось. Суть в том, что в их компании начиная с момента, когда еще не было ни Hudson, ни СruiseControl развернули систему управления версиями и, самый важный момент, добились установки системы на тестовую конфигурацию одним кликом.
Далее автоматизация тестирования. Она как раз и используется для регрессионного тестирования. Да, также запуск скриптов в одно касание :). Но тесты, хотя на данный момент идея не так уж и нова, из-за огромного их количества и большого времени прогона, разбиты на suites и каждый suite запускается на отдельной тестовой конфигурации.
Интересный момент, что клиент этой системы автоматизированного тестирования запущены на большинстве рабочих машин работников. И система может запросить хардварные ресурсы рабочей машины работника, чтобы обеспечить свою производительность. :) Мне, правда, сразу вспомнился LoadRunner.

Далее был "Метод Всех пар, или как не убиться тестируя комбинации", Александра Барановского. Кстати по манере изложения один из самых качественных докладов был. И идея полезная, хотя тоже не новая. Суть в том, чтобы сократить число тестов при тестировании взаимодействующих параметров, таких как настройки системы. Метод рассмотрели еще и на конкретном примере. И специальную тулзовину посоветовал.
Почитать можно и в интеренете, но суть в том. Чтобы вычленить все имеющиеся параметры (контролы формы настроек), их значения. А потом можно загрузить в предложенную тулзовину (PICT от Microsoft) и получить упрощенный вариант тестов. В двух словах описать математическую составляющую метода мне тяжело.
Этот метод не дает замену полному перебору. Но предлагает оптимальное количество тестов, при котором можно выловить большую часть ошибок.

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

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

Потом был обед и я пока прервусь :)

"Лучше давайте побыстрее закончим"

Последнее время я очень часто слышу эту фразу: "Давайте лучше сделаем это побыстрее".
Да, все хотят успеть сделать вовремя, или как можно быстрее, если это самое "вовремя" прошло.
Причины? Различные. В моем конкретном случае я все отношу к различным "окнам бессрочности" (вот тут прочитал) всех членов команды.

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

Если все же хочется это получить поскорее, то придется поступиться остальными углами треугольника менеджмента проектов. А QA помнят, что углов в треугольнике 4: время, ресурсы, деньги и качество :)

Design your desk to give a good impression

Design your desk to give a good impression: "

"

 Что-то мне этот комикс напомнил :)