воскресенье, 31 марта 2013 г.

AgileDays 2013

Было здорово. Мне понравилось. Много докладов из жизни, а не из книг.
Подробно останавливаться не буду: отчетов уже немало написано (см. ссылки ниже) :)
Из того, что не попало в отчеты остальных:
Утром первого дня пообщался с Андреем Бибичевым. Интересный и умный человек, делает интересный проект. Видно, что занимается любимым делом. Скрамом в компании не пользуются, пока не нужно :)

Про доклад Паттона хорошо написал М.Цепков. Кстати Джеф рекомендовал Кагана с его Inspired. Читайте, кто его не сделал этого (мой конспект здесь).

Гойко Аджич про метрики: Чаще всего меряют то, что проще мерять. А не то, что реально важно. И выглядит так, что метрики бесполезны. ЗЫ весь доклад мы ехали в Петербург :)
Интересно, рекомендую посмотреть в записи (обещают в течении месяца-двух)

Кроме этого, рекомендую (MUST SEE) доклад Антона Волкова. Пересказывать не буду - это надо видеть (ну или пока, хотя бы посмотреть слайды с комментариями автора)! Этот доклад, по-моему скромному мнению и согласно буре в твиттере, можно смело поместить на первое место. Фактически продолжение доклада в кулуарах: часть 1, часть 2. Рекомендую, не пожалейте 2 часа своего бесценного времени, очень много подробностей реализации текущего процесса работы в AlternativaPlatform. Открыто и очень живо: откуда берутся оценки, как формируются команды, как работает тестирование, как формируется и разбирается backlog, и еще много-много "как".

Были 2 интересных блиц-доклада от ребят из Яндекса (Павел Шишкин и Анна Мининкова). Коротко и по делу. Павел рассказал про то, как они "тюнили" процесс Канбан в Яндекс-Картинках. Аня поделилась опытом работы совместной работы команды практикующей Agile с водопадной командой. Запомнилось :) Аня выложила текстовку доклада и слайды. Что показалось забавным - в Яндексе или очень сильная автономия, или большая самостоятельность, или слабое внутреннее хождение опыта. В Питере на ПланБ тоже рассказывали об опыте внедрения Agile. Так питерские ребята похоже и близко не подошли к тому, что делают в проектах докладчиков Яндекса с AgileDays.

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

Леша Пименов рассказал интересную историю про оживление проекта с помощью Agile практик. Обещал слайдкаст. Часть 1 уже здесь. Ждем остальные.
Оригинал тут
Не буду называть доклады, которые я уже видел в инете (записи с других конференций). С одной стороны, действительно сложно каждый раз придумывать новое, но может хоть чуть-чуть менять? ;) Хотя Коля Алименков уже проехался по этому вопросу. Согласен, вероятность пересечения аудитории мала и от докладчика много зависит. Некоторых можно слушать многократно.

Из полезного "на почитать": Lean Startup (в русском варианте "Бизнес с нуля"). Часто рекомендовали.

Заряд получен, вопросы для размышления тоже. Самое полезное в такого рода мероприятиях - это общение. Возможность задать вопросы, получить интересные ответы, услышать истории из жизни от спецов: Асхата УразбаеваБориса ВольфсонаКоли АлименковаЛеши Пименова. Спасибо всем.
слева и далее: Борис Вольфсон, я, Коля Алименков, Леша Пименов. (с) Юля Крючкова
Еще отчеты:
очень подробно от Максима Цепкова
интересно от Сергея Рогачева
лаконично, но не менее интересно от Леши Пименова
еще один отзыв в виде mindmap

Философское ЗЫ
Москва провожала противной питерской погодой. В голове бродили разные мысли. Везде мелькали рюкзаки AgileDays. В купе меня веселили немцы всей семьей поехавшие в отпуск в Москву и Питер. Проводники оказывается ни бельмеса не понимают английский. Немцы по-русски знают только "на здоровье". Интересно как они будут путешествовать...?
Последний рюкзак с AgileDays увидел за 5 мин до моего дома: девушка садилась на маршрутку. Мир тесен... :)

воскресенье, 24 марта 2013 г.

Научить разработчиков тестировать. Реально ли? Нужно ли?


Фото отсюда

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

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







Шаг 1 "Понять и простить" 
Нужно понять, что у разработчиков есть свои слабости:
  • родительская забота о своем коде
  • сфокусированность на успешном сценарии, вместо поиска проблем
  • склонность смотреть на сложную проблему, как на набор небольших, простых и изолированных
  • разработчик реже думает о пользователе
  • меньше знаний общих проблем и узких мест продукта
Хмм, действительно часто наблюдаю и заботу, и узкий взгляд на проблему. Да, есть товарищи, которые, что называется кровью заплатили за этот самый опыт. И теперь реже наступают на грабли. Но забывать о слабостях все равно не нужно. С другой стороны: может "успешный сценарий" и есть те самые 20% функционала используемые 80% пользователей?

Шаг 2 - учим планировать тестирование.
Многие разработчики считают, что тестирование не требует планирования. На самом деле, это не так. Если мы говорим о тестировании разработчиками, то здесь есть некоторые правила при планировании:
  • Если тестировать, то чужой код (см. про бережное отношение к своему коду выше)
  • Обсуждайте набор тестов с тестировщиками
  • Расширяйте сценарии после анализа окружения, конфигурации, набора данных, с которые будут задействованы в сценариях.
  • Тестируйте эвристически: принцип SFDEPOT
SFDEPOT нам дает:
S(tructure) - из чего состоит продукт
F(unction) - что продукт делает
D(ata) - с чем он работает
P(latform) - от чего зависит
O(perations) - как он будет использован
T(ime) - когда он будет использован
Шаг 3 Что делать, когда запускаются тесты :)
  1. Записывайте новые идеи того, что нужно проверить, "баги" в которые воткнулись и которые нужно зарепортить (звучит как совет КО, имхо лучше сразу чинить. Вы же разработчик ;) С другой стороны, правильно отмеченные проблемы помогут вам на рестроспективах)
  2. Не забывайте про работу с граничными значениями (большие/маленькие файлы, специфичные даты, максимальные/минимальные числовые значения и тп)
  3. Размышляйте о негативных сценариях (например пропадание электричества и тп)
  4. Старайтесь смотреть шире. При проверке конкретной функциональности, смотрите вокруг: что происходит с продуктом и его окружением.
  5. Боритесь с селективной слепотой (слепотой по невниманию - Inattentional Blindness). Этот ролик поясняет в чем суть. Вы увлекаетесь одним предметом и не замечаете того, что происходит вокруг.
Шаг 4 Что делать, когда (как вам кажется) вы закончили тестировать
Даже когда вам кажется, что вы закончили, вы не должны успокаиваться. Подумайте где и что вы бы могли проверить.
Вот несколько практик
  • Делайте перерывы, займитесь другими делами. А потом проанализируйте заново что вы проверяли и что нашли. Обычно помогает освежить мозги.
  • Расскажите вашим коллегам о том, что и как вы проверяли. Самое удивительное, что в процессе этого, к вам в голову будут приходить новые идеи.
  • Посоветуйтесь со спецами (наверняка у вас есть крутаны-тестировщики). Они обязательно придумают вам еще 100500 сценариев, которые вы забыли проверить. :)
А на самом деле, кто в итоге будет тестировать: разработчики, тестировщики или совместно - не важно. Главное чтобы: "пацан наШкодил - пацан исправил" :) А кто эту шкоду нашел, какая разница? 

Но ведь пацаны пишут все правильно и без ошибок, не так ли? ;)

Почему? Потому что используют TDD.
Uncle Bob (aka Robert C. Martin) недавно замутил очередную бурю по этому вопросу. Две интересные статьи всколыхнули прогрессивную общественность The Start-Up Trap и The Pragmatics of TDD. Читаем и задумываемся.

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

четверг, 7 марта 2013 г.

Отзыв-конспект "Общаться с ребенком. Как?"

Конспект книги "Общаться с ребенком. Как?". Прочитал по совету Леши Авдея, который он дал на конференции "План Б".

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

Ниже будет много прямых цитат.

Итак правила:
  • Не вмешивайтесь в дело, которым занят ребенок, если он не просит помощи.
  • Если ребенку трудно и он готов принять вашу помощь, обязательно помогите ему.
  • Правило "зоны ближайшего развития". Фактически, это список дел которые ребенок сейчас делает с вашей помощью, но скоро сможет делать сам. Возможные крайности здесь: слишком рано переложить свою часть на ребенка или, наоборот, слишком долгое и настойчивое участие родителя.
  • Постепенно, но неуклонно снимайте с себя заботу и ответственность за личные дела вашего ребенка и передавайте их ему.
  • Позволяйте вашему ребенку встречаться с отрицательными последствиями своих действий (или своего бездействия). Только тогда он будет взрослеть и становиться «сознательным».
  • Активно слушайте ребенка – важно «возвращать» ему в беседе то, что он вам поведал, при этом обозначив его чувство.
  • Проявляйте уважение к личности ребенка, признавайте его права на собственные желания, чувства и ошибки, внимание к его заботам, отказ от родительской позиции «сверху».
  • Если ребенок вызывает у вас своим поведением отрицательные переживания, сообщите ему об этом.
  • Когда вы говорите о своих чувствах ребенку, говорите от первого лица. Сообщите о себе, о своем переживании, а не о нем, не о его поведении. Важно при этом избегать  приказного тона или выговора. Это дает ребенку возможность самому принять решение. И тогда – удивительно – они начинают учитывать наши желания и переживания.
  • Не требуйте от ребенка невозможного или трудно выполнимого. Вместо этого посмотрите, что вы можете изменить в окружающей обстановке.
  • Чтобы избегать излишних проблем и конфликтов, соразмеряйте собственные ожидания с возможностями ребенка.
  • Старайтесь не присваивать себе эмоциональные проблемы ребенка.
  • Нужно постоянно поддерживать его самооценку или чувство самоценности
Алгоритм конструктивного решения конфликта:
  1. Прояснение конфликтной ситуации.
  2. Сбор предложений.
  3. Оценка предложений и выбор наиболее приемлемого.
  4. Детализация решения.
  5. Выполнение решения; проверка.
Главные усилия надо направить на то, чтобы переключать свои отрицательные эмоции (раздражение, гнев, обиду, отчаяние) на конструктивные действия. 

Об ограничениях и запретах:
  • Такие правила (ограничений и запретов) обязательно должны быть в жизни каждого ребенка.
  • Ограничений (требований, запретов) не должно быть слишком много, и они должны быть гибкими.
  • Родительские требования не должны вступать в явное противоречие с важнейшими потребностями ребенка.
  • Эти правила должны быть согласованы взрослыми между собой.
  • Тон, в котором сообщается требование или запрет, должен быть скорее дружественно-разъяснительным, чем повелительным.
  • Наказывать ребенка лучше, лишая его хорошего, чем делая ему плохое.
  • Если мы хотим привить ребенку дисциплину, нужно оставить ему возможность для собственного решения о правильном поведении, некоторый «люфт», который даст ему почувствовать долю самостоятельного решения.
Самое важное - книга, кроме приведенных выше собственно правил, содержит примеры того, как их применять на практике, в конкретных ситуациях. Даются прямо диалоги в ролях. Мне многие из них напомнили реальные диалоги в нашей семье.
Ну и возвращаясь к теме управления. Не правда ли, многие из правил можно применять и на работе, при общении с вашей командой.

Update: достаточно свежее выступление Григория Бакунова (bobuk) на эту же тему.