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

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

Про то, куда иду

Ты "свет фар" своего проекта. (с)

Сэм Канер.

Про то, откуда иду, я уже писал. Теперь про то, куда.

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

 

Ты не программист

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

Но приложения создают именно программисты. И отчасти ты - программист.

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

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

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

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

Если ты пишешь тесты, то код тестов соответствует стандартам кода продукта. Тесты - часть продукта и их качество - качество продукта. Ты пишешь код системы тестов на нужном уровне. И проходишь стандартное ревью программистов.

Ты не проектировщик

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

Но твоим продуктом будут пользоваться люди. И отчасти ты - проектировщик.

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

Ты не аналитик

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

Но аналитики определяют, что мы должны создать. И отчасти ты - аналитик.

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

Ты не менеджер

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

Но ты работаешь в команде. Будь менеджером.

Чтоб стать хорошим работником ты поработал руководителем.
Ты не мудак.
На выходе ты даешь качество.
Ты сообщаешь о проблемах.
Ты выполняешь приказы.
И все записываешь.

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

Ты тестировщик

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

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

Ты профессионал

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

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

Самый ценный ресурс тестировщика - доверие. Тебе доверяют.

Одержимость

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

Финальная сцена, если лень, смотрите с 8:35
https://youtu.be/Tkh5I9w4ySY?t=8m35s

Видео полностью:

О ком этот фильм? О учителе или ученике?
Чья победа ярче в финальной сцене? Победа учителя или ученика?

Я уже больше сопереживаю учителю.
И да. Методы обучения - на отлично. Только так.

Про то, откуда иду

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

Кто такой - отличный тестировщик?

Кого я называю отличным?
В чью группу хочу попасть?
Кто работает лучше меня?
На кого равняюсь?
У кого хочу учиться?

В мире? Виттакер, Канер, Бах, Болтон. Почему? Они профессора, программисты, авторы книг, евангелисты. Я читал их книги и статьи.
В стране? Руколь, Назина, Баранцев, Александров, Мартыненко, Мериин, Нечаева, Высоцкий. Почему? Они известные тренеры и докладчики. Я был на тренингах и слушал доклады.
В Екатеринбурге? Юра Р., Женя А., Илья В., Ната С.. Почему? Они умеют работать, у нас были совместные проекты.

- Можно ли стать отличным, не интересуясь, как работают другие?
- Нет.

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

Так и записал. Что еще?
Не знаю.

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

Куда и откуда?
Прежде всего это история людей, с которыми работал.

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

Второй шаг - в Наумене удалось вместе работать с руководителем разработки SD, программистом А.Л..

Он тратил свое время на обучение и воспитание сотрудников.
Вместе с ним за пару лет прошли от "программисты пишут какой-то код без CI" до "релизим ежедневно с постоянно зеленых тестов". Первые в компании использовали скрам (по канону), перешли на git, ввели системное автоматизированное тестирование на всех уровнях, системное нагрузочное тестирование в CI.
Он садился и делал задачи вместе со мной.
Примером показывал, как использовать блокнот и хоткеи в IDE.
Показывал, как считает время и как складывает текстовые файлы у себя на компе.
Вникал в детали моих задач. После получаса совместной работы обычно оставалось ощущение "а почему я все это не сделал сам?".
Учил начинать с проблем, а не с решений.
Учил писать требования, контракты и письма.
Учил отличать полезную работу от бесполезной и признаваться, что делал бесполезную.

Третий шаг. В тот период я занялся переводом "lessons learned in software testing", книги, которая не столько о стандартах, техниках и методологиях, сколько о о ситуациях, в которые попал автор. Читая ее я чувствовал, что веду диалог с автором о том как жить и работать.
В ней есть понемногу обо всей жизни тестировщика. Попасть на работу, работать руками, что и зачем автоматизировать, на какие конференции ходить, какие подходы срабротали, какие нет. Как нанимать и как увольняться.
Иногда даже удавалось успешно применить какой-нибудь из 293 уроков.Рассылка о состоянии тестирования, посещение конференций, маркетинг своей деятельности и многое другое вышло со страниц этой книги.
Канеру в деле воспитания меня помогали Блэк, Виттакер, Криспин, Адизес и многие другие.

Следующий шаг и следующий человек - Ю.З., аналитик, менеджер разработки.

Она - все больше про то, как выражать свои мысли и отсекать все лишнее. Кстати, ни один спор с ней я не выиграл, как бы ни готовился и насколько бы ни был прав (а иногда был!).
А значит, надо готовиться лучше, формулировать четче и соображать быстрее.
Она говорила, что у специалиста должно быть основное умение. У аналитика - писать текст. Программист - писать код. Тестировщик - решай сам. Наверное, придумывать кейсы. Остальное можно отсечь и сосредоточиться на том, что действительно нужно.

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

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

- Что дальше?
- Не знаю. Наверное, опять ищу человека.

- Пост точно про тестирование?
- Нет. Про жизнь.

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

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

Вам не нужно больше тестировщиков

Я все еще под впечатлениям от нетленки Болтона девятилетней давности.

Менеджеры и тимлиды:
У вас в командах уже есть тестировщики, но вы хотите ещё, потому, что:

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

Вам не нужно больше тестировщиков:

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

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

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

• Вам нужно уйти из бизнеса по разработке программного обеспечения.

Специализация

Роберт А. Хайнлайн

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

У меня уже дважды менялось отношение к этой цитате.
На данный момент - согласен.

Письма римскому другу

Бродский. На память мне.

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

Дева тешит до известного предела -
Дальше локтя не пойдешь или колена.
Сколь же радостней прекрасное вне тела:
Ни объятья невозможны, ни измена!

Посылаю тебе, Постум, эти книги.
Что в столице? Мягко стелют? Спать не жестко?
Как там Цезарь? Чем он занят? Все интриги?
Все интриги, вероятно, да обжорство.

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

Здесь лежит купец из Азии. Толковым
Был купцом он - деловит, но незаметен.
Умер быстро - лихорадка. По торговым
Он делам сюда приплыл, а не за этим.

Рядом с ним - легионер под грубым кварцем.
Он в сражениях империю прославил.
Сколько раз могли убить! А умер старцем.
Даже здесь не существует, Постум, правил.

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

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

Этот ливень переждать с тобой, гетера,
Я согласен, но давай-ка без торговли:
Брать сестерций с покрывающего тела -
Все равно что дранку требовать у кровли.

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

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

Был в горах. Теперь вожусь с большим букетом.
Разыщу большой кувшин, воды налью им...
Как там в Ливии, мой Постум, или где там?
Неужели до сих пор еще воюем?

Помнишь, Постум, у наместника сестрица?
Худощавая, но с полными ногами.
Ты с ней спал еще... Недавно стала жрица.
Жрица, Постум, и общается с богами.

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

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

Поезжай на вороной своей кобыле
В дом гетер под городскую нашу стену.
Дай им цену, за которую любили,
Чтоб за ту же и оплакивали цену.

Зелень лавра, доходящая до дрожи,
Дверь распахнутая, низкое оконце,
Стол покинутый, оставленное ложе,
Ткань, впитавшая полуденное солнце.

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

Творчество

Коллективное бессознательное коллег:

Теория ограничений Голдратта

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

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

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

Книга - именно справочник, в ней очень мало объяснений, почему все работает именно так. Перед тем, как приступить к ней - рекомендую прочесть основной цикл Голдратта - Цель1, Цель-2, Цель-3.

aldragon

Чтоб я так думал и так формулировал.

…Алиса приходит в себя; Страна Чудес была сном, воздух ревёт, падение в кроличью нору длится четвёртые сутки, очень, очень хочется пить.

«…канарейка выжила, но годами ходила к терапевту».

«…а теперь давай жёстко. Как будто я – концепт гиперзвукового пассажирского лайнера, а ты – законы физики и экономическая целесообразность»

Почитайте, там много: https://twitter.com/aldragon_net

Про аналитику

Текстовая версия моего рассказа на летучке от 9 декабря.

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

Часть первая. О чем?

До сего времени я был знаком с шаблоном  юзкейса

Я как {роль} хочу {что-то}, чтобы {цель}. 

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

Итак, что такое юзкейс?

Повествование о взаимодействии человека с системой.

1. Лица
2. Цели
3. Успех
4. Расширения
5. Обработка
6. Данные
7. Валидация

Особенности

• Для удобства чтения разбитое на абзацы.
• Уровни взаимодействия. Море, птицы, рыбы.
• На каком уровне должна находиться цель.
• На каком уровне должен находиться юзкейс.
• Определить, кто такой человек. Действующее лицо.
• Определить его цель.
• Ветвлений нет. Есть исключения.
• Записываются отдельно от основного повествования.
• Минимальные гарантии.
• Удобства отдельной записи - расширение без перенумерации и т.п.
• Если ветвления есть, то это 2 истории, а не одна. И стоит подумать, что их надо разделить.
• О читаемости историй.
• Каждый пункт истории должен приближать пользователя к цели. Не "пользователь ввел логин и пароль", а "система подтвердила правильность логина и пароля" (еще примеры)
• Триггеры

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

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



Часть вторая. Зачем?

Каждый новый шаг в выбранной вами профессии стоит дороже.

• Сперва нужно знать как чем отличается гет от пост, делить на классы эквивалентности, писать чеклисты и делать что говорят.
• Затем - разбираться в стеке OSI, писать скрипты bash, пользоваться фидлером, рисовать карты памяти и приоритезировать свои задачи.
• Идем дальше - и мы уже чуем слабые места layer'ной архитектуры, программируем на любом скриптовом языке, оцениваем узкие места коммуникативвных средств и понимаем, зачем в реальной жизни нужны ТОС и ТАУ.

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

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

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

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

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

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


Как они мне могли бы пригодиться?
Менеджеры не звери и программисты не сволочи. И часто могут хотеть помочь нам. Зачастую - в случайный момент времени нам выдается значительный ресурс программиста. И я ставлю 5 к 9, что если каждому из вас выдать программиста на неделю, то вы не придумаете ничего полезней чем "чини старые баги". и 7 к 9, что даже если придумаете, то это будет абстрактное желание в виде устного творчества.

К чему я? Тестировщики часто ставят задачи. Множество микрорешений на уровне продукта. Задания на доработку тестирующей системы, создание заглушек, инструменты сопутствующей автоматизации.
А теперь попробуйте вспомнить, из за чего программисты делают добрую часть ошибок? Из за некачественного задания.
Автотесты - большой продукт. Сотни тысяч строк. Сколько у них постановок? А почему? Я видел у 2 команд. Удивите меня.
А можно ли назвать задания которые ставят тестировщики качественными?

Когда уходят люди

Из Брига. Когда уходят люди. Навеяло.

    - Я тебе нужен?, - спросил я.
        Костя опять сел в кресло, покачался на нем и заговорил:
    - Я тебе вот что, Бриг, скажу... Нужен, не нужен - это все лирика. Вполне может быть, что и не нужен. Вот и Серега тебя заменит. А вот... выйди я сейчас в соседнюю комнату - тишина, все работают, слова лишнего не скажут, разъеби я кого - утрутся молча, неправ я буду - все равно промолчат, сидеть будут, очереди своей ждать... Что, трудно им людьми остаться? Не дрожать, не лизать жопу, глаза не опускать? Из, блядь, ста или - сколько там сейчас? - людей, не людей - не знаю, единиц, в общем - из этих ста кто мне в ебало правду скажет? Ну, Петрович, да Гена, да ты вот... Из ста! Сколько раз было - рушится все, боятся признаться, пока, блядь, сам говна не увижу... А уж как вкладывают друг друга! Пока я в силе - так и будет. А представь, развалится завтра "Циклон", все на улице окажемся - банкротство там, или еще какая хуйня. Да элементарно - каждый мне в морду плюнет и детям своим накажет. Эксплуататор, блядь, трудового народа. А я пешка, Бригадир. Просто - пешка. Надо мной такие люди, что лучше бы тебе не знать...
    "Нужен"... Да не нужен ты мне, как работник, до хуя таких, извини, блядь, сисадминов... Просто... Ты уйдешь, и уже останется двое. Двое, с кем я могу человеком себя почувствовать... А потом, например, один. А там уже.., - он махнул рукой, - ... эх, да что, блядь, говорить!

   

Take Back Your Government

Некто Сергей Лебедев взял на себя труд перевести книгу "Take Back Your Government" Хайнлайна, написанную в 1946.
Звездный десант, Луна жестко стелет, Чужак в чужой стране - это все вроде бы и фантастика. Но как то больше о своем месте в мире и о отношениях с ним.

Take Back Your Government или как это перевел Сергей "Заберите себе правительство" - уже прямая инструкция Роберта о том, как заняться политикой. Не большим шоу, которое показывают по телевизору, а на местном уровне. Несмотря на то, что книге уже 70 лет, на мой взгляд, она на 90% не потеряла актуальности.

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

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

Ссылка на переводы:
https://habrahabr.ru/post/290210/

Лампа Мафусаила

Читаю "Лампа Мафусаила, или Крайняя битва чекистов с масонами" Пелевина.
Как водится, на уровне.

Мне кажется, я определил жанр, в котором творил Виктор следующие книги:

Generation «П»
Числа
Священная книга оборотня
Empire V
S.N.U.F.F.
Любовь к трём цукербринам

Это производственные романы. Как "Цель" Голдратта или Дедлайн Демарко.
 Книги, раскрывающие суть профессий.
Ну а какие профессии, такие и книги.

Вы все еще не читаете "Байки для оруженосца"?

Шикарное у Мартыненко:
http://blog.shumoos.com/archives/317

- А почему Королева тестирует? Она же руководитель проектов?
- Потому что у нее корона не падает, - пояснил Заяц.

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

Великолепная статья.
http://applecons.com.ua/pub/standing_on_the_shoulders_of_gigantes.pdf

Избранное:

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

И еще:

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

И дальше:

Опыт, перенесенный Шугартом в производство из физики и ставший всемирно известным благодаря Демингу, свидетельствует о том, что попытки быть более точным, чем « шум » (в нашем случае -- использовать сложные алгоритмы, которые учитывают каждый из возможных параметров среды, имеющей высокий уровень неопределенности), не улучшают, а ухудшают результаты, и итогом же, с большой вероятностью, будет не улучшение, а ухудшение уровня выполнения заказов в срок. 

Отчет за 2016 год и закрытие велосезона.

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

Расскажу о том, как это было и куда все это катится.

Что понял за 2 года существования велоклуба?

• Планировать маршрут не сложно.
• Лучшие карты - openstreetmap.
• Карты врут. Особенно сильно врут карты о местах, где мало машин.
• Планируй альтернативные пути.
• Самое интересное случается там, где ты еще ни разу не был.
• Участникам больше всего нравятся заезды, по маршрутам, на котором они не были, а штурман - был.

• Скорость группы ниже скорости самого медленного участника.
• Разметр группы обратно пропорционален скорости.
• Прокалываться каждые 10 километров - вполне возможная ситуация. Запаска и ремнабор должны быть у каждого.

• Сколько бы ни было человек записано в велоклуб - 30, 60, 100, 150 - постоянно катают трое-четверо.
• Лучше всего подготовлены учатсники на очень чистых или очень грязных велосипедах.
• Зависимость между стоимостью компонент и подготовкой участника прямая.
• Надо уметь отличать людей, которым нравится катать от тех, кому нравится посещать красивые места. Заезды будут получаться принципиально разные.

• Человек с минимальной подготовкой способен проехать 60 километров по ровному рельефу и 40 с солидным набором.
• Человек с опытом катания проедет 100 по ровному рельефу и 60 с набором.
• Те четверо, что катают со мной постоянно - могут ехать как угодно долго и по любому рельефу.
• Самые выносливые - высокие парни и миниатюрные девушки.

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

Урал очень красивый.

Что будет?

Километраж мало коррелирует со сложностью. Будет введена цветовая индикация и пафосные метафоры.

• Красный. "Тропа лосей" (известный. но длинный и сложный маршрут).
• Зеленый. "Дорога на водопой" _(экскурсия к достопримечательности, лайтовый заезд для всех).
• Синий. "Шкура змеи" (разведзаезд, можно слиться, без ограничений времени).
• Черный. "Следы волков" (дальний разведзаезд с дедлайном).
• Желтый. "Хвост кролика" (утренняя или вечерняя тренировка в темпе).

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


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

Отдельное большое спасибо Ярославу, Дену, Сереге, Лилии.

Закрываю сезон.

Шунут - Семь вёрст до небес - и всё лесом

Отряд

• Ден и Костя - фотографы.
• Гузель и я - рядовые.
• Влад - штурман.
• Ярослав - замыкающий.

Погода

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

План

• 8 часов между прибытием и отправлением электричек
• 2 часа и 30 километров до Краснояра
• 1,5 часа и 10 километров подъема на Шунут
• Полчаса там
• 1 час и 10 километров спуск с Шунута
• 2 часа и 30 километров - обратно до Ревды
• 1 час запаса

Туда

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

Подъем

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

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

Пошли сюда:

Местная флора (или грибы это уже фауна? Они же в отдельном царстве по классификации):

После пяти километров более-менее ровного леса начинается уже серьезный подъем. Большую часть все же едем (лоси-то едут постоянно), я на передаче 1-2, спешиваемся в сумме на 500-600 метров из десяти километров.
Я все же переоценил наши возможности и поднимаемся мы 2 часа 15 минут вместо полутора. Но виды того стоят. Все как надо.

Полчаса тусим и имеем 50 минут отставания от графика.

Спуск

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

К Ревде

У нас 80 минут отставания - то есть минус весь запас и ровно 100 минут на добраться до электрички. С учетом того, что сюда мы доехали за 120 минут.

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

Обратно ехать сложнее, подъем на Шунут забрал прилично сил. Вспоминаю, что электричка до Екатеринбурга, к которой мы пытаемся успеть - последняя на сегодня. Это придает сил.

Подъезжаем к Ревде, осталось 7 километров и 30 минут до отправления электрички.  Разделяемся - трое едут вперед, за билетами, в том числе я. Ярослав остается работать бустером на подъемах.

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

Стоим на перроне, уже видно электричку - на вокзал влетают ребята. Ребята и головной вагон к перрону подходят одновременно.

Ремарка Если бы ребята не успели, естественно, без них мы бы не уехали. В ПВД своих не бросают

Греемся и точим консервы. Заезд - удался.

Итоги

Трек
Итоговый счет - 84 километра.

О профессионалах.

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

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

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

Здравствуй.

Давно хотел написать, но все тянул, откладывал. Но все-таки вот оно. Я уже три года работаю тестировщиком. Тестировщиком стать не так сложно, как программистом или аналитиком. На последних курсах я писал простенькие мобильные приложения, но больше мне нравилось пользоваться, чем писать код. А в аналитики я не пошел, так как я все же выпускник технической специальности и хочу стать технарем, а не писать бумажки. Хотя и к тестировщикам предъявляются серьезные требования — нужно быть пунктуальным и внимательным, а еще обязательно быть командным игроком — тестировщикам нужно много общаться.

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

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

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

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

Тесты вообще писать несложно. Это же основная фишка программирования — переиспользование! Берем уже готовый тест, копируем его, меняем так, как нужно нам, добавляем одно-два действия и вуаля — новый тест готов.

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

Кстати! О хорошем. У нас отличные программисты! Мне кажется, что одни из лучших. Никогда еще не посылали меня, всегда слушают, помогают, находят решение. Написать скрипт, помочь поймать баг. И даже просьбы расставить айдишники локаторам выполняют не дольше, чем за два дня. И большие задачи, которые я от них иногда хочу - сразу ставят к себе в план и выполняют в ближайшую итерацию. Уже скоро возьмут задачу по добавлению организаций в систему через api. И баги они берут и чинят сразу! Мои так вообще почти никогда не отклоняют с "не воспроизводится". Тем более, что если, например, импорт в принципе не работает, то тут уже не сможешь ничего отклонить =)

Жалко все-таки, что из-за большого количества фич я не успеваю писать тесты. Недавно смотрел на вакансии автотестеров и думаю, что через полгода мне тоже поднимут зарплату. Менеджер сказал, что пока не может выделить больше времени на автоматизацию, но у нас уже открыта вакансия еще одного тестировщика и когда я обучу его - менеджер сможет выделить время. Я уже почти составил план обучения. Через годик другой он тоже будет писать автотесты, а на первое время мы поставим ему задачу получше изучить продукт. У нас как раз есть долг — актуализация старых открытых багов, их можно разгребать месяцами. Вот на них стажер как раз сможет хорошенько изучить систему.

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