среда, 28 июня 2017 г.

Рассказ Людвига Быстроновского «Как я выхожу из тупиков»

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

Впечатление

Как всегда - очевидное о жизни. Как обычно - лектор уложил интуитивное и очевидное в структуру. Ощущение - "именно эти слова я искал" и "я такой же".
Почему нет? Мне понравилось.

Конспект первого дня.

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

Людвиг пользуется тремя эвристиками, помогающими преодолеть тупняки и совершить прорыв.
  • Контринтуитивное. Решить вопрос противоречащим интуиции способом. снимать носок за пятку. Есть сахар по утрам, чтоб не есть торты вечерами. Часто есть, чтоб похудеть. 
  • Ошибки мышления. Читать о ошибках мышления, находить их в себе и, осознавая, искоренять.
  • Получать системные знания. Когда знаешь, как все работает на самом деле.
После этого еще два этапа.
Первый - отработка техники. Второй - изменение мировоззрения.
IIПрограмма для ведения финансов YNAB.
Принципы:
Не контролировать и ограничивать, а помогать понять свои приоритеты и заранее положить в них деньги
  • тратить деньги из прошлого
  • непредвиденные статьи
  • понять сколько ты можешь не работать
IIIСхема планирования дня.
По большей части о книге: Марк Форстер, Do it tomorrow
Суть: 
  • сегодня делаешь только дела, которые ты запланировал вчера 
  • все новые сегодняшние откладываешь на завтра
  • ограничение на количество дел в день
  • по каждому пункту отвечаешь на вопрос - а почему я хочу это сделать

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

IV. Мелкие советы: 
  • дубликаты вещей
  • программа альфред
  • postnauka.ru
  • оценивать работу по когнитивной нагрузке
  • научиться медитировать

Конспект второго дня.

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

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

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

 Список литературы

Мастхэв:
  • Марк Форстер, Do it tomorrow
  • Ричард Нисбетт, Мозгоускорители
Остальное:
  • АРИЗ Интеллектуальное айкидо
  • Правила игры без правил
  • Щедровицкий , Оргуправленческое мышление
  • Фрит, Мозг и душа
  • Кэтмелл, Корпорация гениев
  • Хоровиц, Легко не будет
  • Лич, Вовремя и в рамках бюджета
  • Бек, Когнитивная терапия
  • Арнхейм, Искусство визуального восприятия
  • Байстер, Искусство видеть паттерны
  • Румельт, Хорошая стратегия, плохая стратегия
  • Люттвак, стратегия. Логика войны и мира

понедельник, 26 июня 2017 г.

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

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

пятница, 23 июня 2017 г.

О проектах

- Не знал, что вы умеете жонглировать, сэр, - прошептал, обращаясь к лорду Витинари, Колон.
- А ты разве этого не умеешь, сержант?
- Никак нет, сэр!
- Странно. Вряд ли это можно назвать умением. Известно, где объекты находятся. Куда они направляются, тоже известно. Остается лишь позволить им занять правильное положение во времени и пространстве.
- У вас чертовски хорошо это получается, сэр. Часто тренируетесь?
- Сегодня первый раз попробовал. - Лорд Витинари спокойно взглянул на Колона, чье лицо выражало удивление и недоверие. - После Анк-Морпорка, сержант, летающие дыни - это цветочки, можешь мне поверить.
Пратчетт, "Патриот" 

Не так давно слушал доклад Паши Егорова, рассказывающего о ценности специалистов, умеющих вести проекты над специалистами, воркающими в рамках процессов. Надеюсь, он опубликует доклад, он того стоит.

Кстати, определение:
  • Проект – это временное предприятие, предназначенное для создания уникальных продуктов, услуг или результатов (PMBoK)
  • Проект — предприятие (предпринятие) с определёнными датами начала и завершения, предпринятое для создания продукта или услуги (сервиса) в соответствии с заданными ресурсами и требованиями (ISO/IEC/IEEE 15288:2008).
  • Проект — предприятие с предопределёнными целями, масштабом и длительностью (ISO/IEC 2382-20:1990).
  • Проект – это последовательность взаимосвязанных событий, которые происходят в течение установленного ограниченного периода времени и направлены на достижение неповторимого, но в то же время определенного результата (Фил Бэгьюли).
Есть мнение, особенно ценны люди, умеющие превращать проекты в процессы, это, кстати, определение таланта, или гения, не помню.

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

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

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


Стихи

Оксана Мельникова:
Забывают лица, слова и даты,
Но живёт веками один сюжет:
Не забыть того, кто тебя когда-то
Так и не сумел полюбить в ответ.


Олег Ладыженский
Разбиты стекла в нашем витраже
И не помогут жалобные речи.
Пора учиться тверже быть и резче,
Пора учиться говорить: -- До встречи!
И знать, что мы не встретимся уже.



четверг, 22 июня 2017 г.

Imagine Dragons Evolve

Черт возьми, офигенно.


Особенно:
Whatever It Takes
Believer
Yesterday
Thunder

вторник, 13 июня 2017 г.

Встреча сообщества, новые проекты и всякое

2 июня прошла встреча UTC - про подведение итогов, раздачу слонов и новые горизонты.

О самой встрече
Самая многочисленная.
Неудавшаяся, но все же состоявшаяся экскурсия по яндексу.
Раздача книг
Миллионы стикеров и позитив.
Лично для меня встреча закончилась на плотинке в 5 часов утра следующего дня.

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

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

А ведь у нас уже есть заготовки пары тест-сессий, ролевой игры и выезд.
Будет интересно.


DUMP-2107
Доклад на дампе, который я делал с Леной и Иларией:

вторник, 6 июня 2017 г.

Гейзенбаг

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

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

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

В докладе Николай пройдётся по всем известным паттернам и подробно опишет их с несколькими практическими примерами.
Рекомендую просмотреть.
Основную и самую ценную мысль Николай сказал в самом начале. Своими словами:
Вы не сможете купить и внедрить инструмент автоматизации, фреймворк, CI, автотествы. Вы обязаны купить и внедрить принципиально иной подход и отношение к разработке.

пятница, 2 июня 2017 г.

Нет времени

- Почему ты не читаешь книги?
- Я очень хочу, но не хватает времени.

- Почему ты не ведешь курс по заведению багов?
- Я очень хочу, но не успеваю, очень много задач.

- Почему ты закроешь этот техдолг?
- Менеджер не выделяет времени.

- Эта полугодовая цель не сдвинулась с места, отчего?
- У нас были срочные задачи.

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