О высоком темпе разработки без веток

 Доклад Ильи Лебедева из BestDoctor

Очень советую посмотреть, благодарен тому, кто меня навел.

Суть коротко: 

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

Мои мысли по ходу доклада:

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

 

По итогу от мнения "Временная игрушка для микропродуктов на две фичи" я перешел к мнению "Так стоит делать всем продуктам года до четвертого разработки".

У докладчика правильная идеология. Он думает о рисках, о важности темпа и интеграции кода, о вложениях в инфраструктуру. А о деталях и ограничениях он не успевает рассказать за полчаса доклада.

Двенадцать способов выполнить задачу (в Контуре)

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

Предвосхищая возгласы (всем, конечно же, не пофиг) вида: 

- Да у вас бардак и все делают что хотят, ужас, так жить нельзя!

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

Итак, сам текст: 

Оценка исполнителем сроков на разработку и тестирование задачи (не нужна)

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

Научиться оценивать сроки на тестирование задач

Уверен, такие же цели ставятся и другим ролям в разработке.

Укладывается в самостоятельно сделанные оценки сроков по задаче

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

Дорофеев, Эффект выпрямления сроков

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

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

Задача начинает «дымиться», и мы приступаем к ней. Если ничего не случилось, то мы успеваем вовремя, а вот если что-то случилось… Резерв мы на это «что-то» уже потратили и в итоге опаздываем.

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

Голосом с 23 минуты.

Демарко, Человеческий фактор

В пятой части первой главы есть ссылки и объяснения исследований.

Коротко: сам факт оценки влияет на сроки в худшую сторону примерно на 40%. Рекомендую прочесть. Все факторы, перечисленные в книге, релевантны до сих пор.

Деминг и Нив, статистика и вариации

За последний год в двух командах слышал следующее:

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

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

Упомянутые в заголовке авторы говорят, что верный способ оценки сроков — статистический. Оценивается пакет типовых задач.

У нас все задачи разные.

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

Что делать, заказчик же требует сроки?

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

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

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

• MVP.
• Декомпозиция задачи.
• Раздельный релиз фронта и бекенда.
• Канареечные релизы.
• Фича-флаги.
• Умение тестировщиков отделять важные дефекты от неважных и умение релизить с неважными
• Pull стратегия работы над задачами (я говорю о том, что программисту не должны совать новые задачи, пока не вышли старые, даже если над задачей пока работает не он).
• Много раз слышал о такой стратегии: сперва релиз рефакторинга, который готовит код к появлению новой фичи, затем релиз самой функциональности. По сути, та же декомпозиция.

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

Ты выпадаешь на умняк и учишь жизни, а чего добился сам?

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

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

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

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

В последний раз я задерживался на работе по просьбе менеджера, чтоб выпустить срочную задачу в январе 2017 года. До этого пару раз,  в 2015 и в 2016 году.

P.S. 

Речь идет о продуктовой разработке.

Метрика процесса разработки

Максим Дорофеев нашел эмпирическое правило «Число задач в производстве не должно превышать число программистов более, чем на 2».

Старый пост

Предлагаю такое деление команд. Ну или классификацию квалификации менеджеров.

• Команды А-класса: задач в работе у команды не больше числа разработчиков плюс два.
• Команды B-класса: число задач не превышает удвоенного числа разработчиков.
• Команды С-класса: число задач не больше квадрата числа разработчиков.
• Команды D-класса: не смогли за минуту ответить сколько у них задач.

По этой модели я работаю в команде B-класса.

Лекций и ностальгии пост

 Лекции, которые читали студентам

• Захаров о тестировании - зачем
• Захаров о тестировщиках
• Ликулин о модели разработки 

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

Мусорное слово "вот" мешает, а тема в 19м кажется несколько более заезженной, чем в 2011.

Михаил Самарин — Полная прозрачность в компании

В очередной раз про самоуправление и бирюзовость.

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

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

Когда и как нужно уходить из команды

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

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

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

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

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

Ряд команд традиционно называют уходящих предателями.

• Он лучше всех выполнял свою работу и её не научился делать никто больше.

• Он выполнял работу без ошибок и вокруг него не был создан или был атрофирован контур контроля.

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

• Он стал лицом команды и люди шли работать не в команду, а с ним. За ним могут уйти и остальные, кроме того, команда разучилась искать людей другим способом.

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

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

Как в мифологии, каждый герой рано или поздно становится драконом.

Неизбежно

Уход любого человека из команды неизбежен.

Два года назад мы в EDI сделали фотографию, ознаменовавшую, что в команде не осталось ни одного человека с другой фотографии команды, шестилетней давности.

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

Решение

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

Я считаю, что у нас должно начать действовать правило.

Как только ты в своей команде или в своей роли становишься незаменимым, самым крутым, объединяющим, ведущим, лидером — ты должен сказать:
- Через два года я уйду из команды.
И выполнить обещание.

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

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

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

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

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

О том, как появляются лидеры

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

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

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

Срок

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

Кто решает?

Кто решает, что вот конкретно этому человеку пришла пора сказать "я уйду через 2 года"?

• Команда? Слишком абстрактно.
• Менеджер? Это прямо противоречит его тактическим интересам. Не каждый способен.
• Функциональный руководитель? Не всегда он есть.
• Он сам? Самому сказать: "я самый крутой и ваш лидер, поэтому... "? Так себе идея.

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

А если взорвется?

А что если ну вот никак нельзя, всё сломается, взорвется и упадет?

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

О ресурсах

Шутка с просторов интернета:

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

Кажется, это применимо к вопросу "сколько тестировщиков нужно на проекте?"

Открывая организации будущего, часть третья

Продолжаю открывать организации будущего.
Часть первая.
Часть вторая.

Поехали.

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

Просто смешная цитата. В дикой природе так-то все друг друга радостно жрут.

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

А это - правильные вопросы, детектив (с)

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

Очень приятно узнавать себя.

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

И тут пошла ебанина...

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

В какой прекрасной стране фей и эльфов живет Лалу.  

Рассказывать и показывать что и как ты делаешь. Ставить видеокамеры над конвеером.
«Конкуренты» приглашаются следовать вместе к высокой цели

 Да. Да. Да.  Не нужно делать секреты и таинства. Хотя скажу, что в конкурентной среде эффективность выше.


Кажется, я начал понимать, что мне не нравится про бирюзовость:

Любой может принять любое решение, утверждения решений запрещены.

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

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

Открывая организации будущего, часть вторая

Продолжаю читать книгу Лалу.

Поехали.

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

Это ужас, ад и Израиль. Шум, отвлечения и прочие атрибуты опенспейса. Читайте Шаблоны проектирования Александера и Peopleware Демарко.

И компания ввела «правило 80–20»: каждый сотрудник AES, от уборщицы до инженера, в среднем обязан 80% рабочего времени посвящать основным обязанностям и быть готов присоединиться к одной или нескольким рабочим группам в остальные 20% времени.

Мне нравится, но непонятно, как решается вопрос недопроизводства в основной работе. IT - отрасль с избытком задач, всегда можно и иногда нужно и гораздо чаще хочется  сделать больше. А тут какие-то 20%... К тому же "интерес" у человека один и не делится на проценты.

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

И благолепие настает само! Тут же все становятся умными и дисциплинированными. Всегда. Ага.

В Buurtzorg все данные относительно производительности команд выкладываются во внутреннюю сеть.

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

Что и с чем тут сравнивать?

Планирование преемственности — еще одна установившаяся практика HR-службы. Для каждого руководителя в компании подыскивается и воспитывается возможный преемник. И, наконец, существует процесс планирования карьеры

Это то, чем нужно заниматься. ППКС.

Ежегодно сотрудники заполняют анкету, оценивая каждого коллегу на основании всего двух пунктов:
— «Вклад этого сотрудника в общее дело (гораздо) больше или (гораздо) меньше,
чем мой» (шкала от –3 до +3);
— «Этот сотрудник способен оценить меня» (шкала от 1 до 5).
Ответы обрабатываются по простому алгоритму, коллег делят на несколько зар-
платных сегментов

 Все равны, но некоторые равнее...

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

А как же Даннинг-Крюгер?

How to deliver quality assurance at speed

Настоятельно рекомендую к просмотру видео от atlassian о том, чем сейчас становится обеспечение качества.

Там много про скорость разработки, важная штука, чтоб ее.

Жизнь без тестировщиков

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

Мне кажется, что у него все как то правильно настроено. Почитайте.

http://artkoshelev.github.io/posts/there-are-no-testers
http://artkoshelev.github.io/posts/there-are-no-testers-part-2
http://artkoshelev.github.io/posts/there-are-no-testers-part-3

Рекомендую весь блог. С остальными жизнеполагающими статьями я согласен не настолько, но тем не менее.

Разбери бэклог

Написал статью для календаря тестировщиков, первый выпуск.
Лежит вот тут, ниже ее текст.

Задачки об тестирование

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

Вопросы в виде кейсов, с пояснениями. Вот такие кейсы выдал я:


КЕЙС: Сложная задача
На проверку пришла большая задача. Тестировщик заранее тщательно готовился к ней, поэтому за полдня нашел 18 ошибок верстки, три ошибки удобства использования, семь логических и три неверных толкования ТЗ.

Что делать дальше?

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

КЕЙС: Ночью в поле с конем
День разработчика. Восемь вечера, конец рабочего дня. Разработчик сделал завершающий коммит по задаче и с остальными программистами пошел в бар, отмечать. Менеджер, уходя, просит проверить эту задачу, чтоб в 4 часа ночи (пока нагрузка на сервера минимальна) служба дежурных инженеров выкатила задачу в бой. Задача содержит критическую функциональность, в которой не должно быть дефектов, поэтому на проверку задачи уйдет не меньше восьми часов. Времени впритык и менеджер просит протестировать ее прямо сейчас, завтра без этой задачи Контур уже начнет терпеть убытки в десятки миллионов рублей.

Как поступить?

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

Ответы под катом.

О делегировании

Пишет нам один знакомый:

Что делегировать-то? опыт? гибкость мозга? предприимчивость и шустрость? основательность в подходе? — хер что из этого делегируешь

Стоя на плечах гигантов, Эли М. Голдратт, 2008

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

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

Из этого следует масса перпендикулярных выводов. Можно, конечно, наращивать объем и эффективность 15% полезных действий годными технологиями и инструментами. Хотя иногда от этого бывает столько пользы, что лучше уж уйти в тайгу и жить молитвами.

А можно избавиться от 85% ерунды.

Стоя на плечах гигантов, Эли Голдратт.

Автор рассказывает о применимости и неприменимости бережливого производства и пути Toyota на примере Hitachi, а также о том, чем  являются и не являются Лин и Канбан.

Ну, мы все это знаем. Это когда мало складов, just in time и доска с карточками. Почему у нас не используется? Мы попробовали, нам не подходит, хотя часть практик мы взяли. Например, у нас есть доска. И нет складов, мы же в IT. И вообще некогда, у нас дедлайн, а это все бесполезные теории.

Что меня впечатлило больше всего

В 1926 году производственный цикл** от добычи железной руды до получения готового автомобиля** (состоящего более чем из 5000 деталей), находящегося на железнодорожной платформе и готового к отправке, достиг **81 часа**!

Нецензурно восхищается

О главном

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

Канбан - это не когда доска и карточки, это когда не больше одной задачи в работе и одной на складе.

Приоритеты

Независимо от того, как организована официальная система определения приоритетов работы над заказами, реальная система приоритетов выглядит так: «срочно», «крайне срочно» и «бросьте все, делайте вот это!».

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

Оценка

Факты:

• Оценка увеличивает время выполнения задачи
• Оценка отдельной задачи врет

Нам важно знать, когда задача будет закончена и мы будем оценивать.

Ценность - время

Не нужно измерять загрузку людей и процент их занятости.

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

За неделю я минимум дважды слышу что-то вроде: 

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

К чему это все

Опыт - не образование. Здравый смысл - не знание.

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

Элияху гораздо более убедителен, чем я. Прочтите статью.

Статья Болтона "Проблемы тестирования – это результаты тестирования"

http://software-testing.ru/library/testing/general-testing/2562-testing-problems-are-test-results

И референс к предыдущей впечатлившей меня статье: вам не нужно больше тестировщиков.


Оригинал статьи: http://www.developsense.com/blog/2011/09/testing-problems-are-test-results/
Автор: Майкл Болтон (Michael Bolton)
Перевод: Ольга Алифанова

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

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

И, в плюс к вышеперечисленному,

• Компания, в которой я работаю, утверждает, что работает по Agile
• Помимо двухнедельных итераций, на самом деле мы применяем максимум пару практик, относящихся к Agile-подходу – как правило, ежедневные scrum-встречи или канбан-доски.

И вишенка на торте:

• Приходящие на тестирование билды очень нестабильны. Система падает при самых базовых smoke-тестах, и мне приходится ждать и/или пересобирать билд вместо того, чтобы заниматься своим прямым делом.

Как можно проанализировать эти наблюдения?
Мы можем расценивать их, как проблемы тестирования, но мы также можем взглянуть на них иначе – как на результаты тестирования.
Результаты тестирования не говорят нам, что что-то пошло хорошо или плохо. Они поставляют информацию для принятия решений, оценки, и тому подобных вещей. Люди, получающие результаты тестирования, решают, есть ли в продукте проблемы и в чем они заключаются, что еще надо выяснить, и какие решения принять. Это требует участия живых людей, оценки множества факторов, и нескольких возможных интерпретаций.
Так же, как и в случае с автотестами и другими результатами тестирования, очень важно принимать во внимание  весь спектр возможных причин и интерпретаций мета-результатов тестирования – наблюдений, касающихся тестирования. Если мы этого не делаем, то рискуем упустить важные проблемы, угрожающие качеству как тестирования, так и продукта как такового.
Джерри Вайнберг в своей книге "Perfect Software and other illusions about testing" отмечает, что то, что мы получаем в качестве результата – это прежде всего информация. Если тестирование, по словам Джерри – это сбор информации с целью ее передачи лицам, принимающим решения, то нельзя оставлять за бортом потенциально значимые наблюдения.
Тестируя, мы часто сталкиваемся с теми или иными проблемами. Однако вместо того, чтобы относиться к ним как к проблемам для тестирования, мы можем также думать о них, как о симптомах проблем продукта или проекта – проблем, которые тестирование может решить.
К примеру, если тестировщик страдает из-за большого количества разработчиков, или если тестировщику не хватает времени на тестирование – это результат теста. Зачастую это ощущение вызывается тем, что программисты генерируют столько сложных задач, что тестировщик просто не может справиться с ними в одиночку. Сложность, как и качество – это взаимоотношение между человеком и чем-либо еще. Сама по себе сложность необязательно будет проблемой, в отличие от реакции людей на нее. Наблюдая за тем, как люди реагируют на субъективную сложность и риски, мы можем узнать много полезного.

• Помогаем ли мы, как тестировщики, коллегам иметь представление о рисках – особенно о "Черных лебедях" – которые обычно ассоциируются со сложностью?
• Если люди представляют себе риски, обращают ли они на них внимание? Паникуют ли они, или просто игнорируют в надежде, что все образуется? Или что-то другое?
• Реагируют ли люди спокойно и прагматично? Признают ли они сложность продукта, пытаются ли с ней справляться?
• Если сложность продукта или процесса нельзя снизить, предпринимается ли что-то для того, чтобы сделать продукт/процесс проще для понимания?
• Случается ли, что программисты пишут или изменяют код так быстро, что у них просто нет времени разобраться, что же там на самом деле происходит?
• Если кто-то полагает, что команде нужно больше тестировщиков, почему он так думает? (Я обсуждал этот вопрос несколько лет назад)

Как же найти ответы на эти вопросы? Один из способов – внимательно посмотреть на результаты и мета-результаты тестирования:

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

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

• Как эти проблемы угрожают успеху продукта в краткосрочном и долгосрочном периодах?
• Если тестирование систематически выявляет паттерны отказов и сопутствующих рисков, что делает команда с этой информацией?
• Обязаны ли программисты только и исключительно предоставить код, или они обязаны предоставить код с гарантией, что этот код делает то, что должен (и не делает того, что не должен), насколько им известно? Насколько искренне программистам предпочтителен второй вариант?
• Заставляет ли кто-то программистов выдерживать сроки/объемы работ, в которые они на самом деле не могут уложиться?
• Могут ли программисты и тестировщики противостоять навязанным им срокам и объемам работы, если эти сроки повышают продуктовые или проектные риски?
• Прислушивается ли бизнес к опасениям команды? Знают ли они о рисках, найденных тестировщиками и разработчиками? Когда команда разработки указывает на существующие риски, предпринимает ли менеджмент/бизнес адекватные шаги в ответ на это?
• Работает ли команда в комфортном режиме, или продукт/проект серьезно задавлен сложностью, внутренними взаимосвязями, хрупкостью и трудностями, находящимися за пределами возможностей разработки/тестирования справиться с ними?
• Действительно ли команда работает по Agile, соблюдая манифест Agile? Может, "гибкость" используется как карго-культ – практики и артефакты только маскируют бестолковость проекта?

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

Гейзенбаг

Третьего дня просмотрел трансляцию конференции Гейзенбаг.

Суть коротко: конференция определенно стоит того, чтоб купить ее трансляцию и не дотягивает до поездки.

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

В докладе Николай пройдётся по всем известным паттернам и подробно опишет их с несколькими практическими примерами.

Рекомендую просмотреть.
Основную и самую ценную мысль Николай сказал в самом начале. Своими словами:

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

SCRUM в картинках: роли и события

Хорошие картинки.
http://seljava.blogspot.ru/2017/02/scrum.html

Репост старой записи о проценте нахождения багов разными техниками

Ссылка:
https://kev.inburke.com/kevin/the-best-ways-to-find-bugs-in-your-code/