Книга: Agile Ретроспектива

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

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

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

Что смутило с самого начала и не отпускало до конца книги - пример ретроспективы которую команда проводит за час и каждый раз у команды новый ведущий.
Итак, что предложит вам книга:
1. Общее описание процесса ретроспективы
2. Каталог активностей (упражнений)  для каждого этапа, сопровождаемый комментариями а-ля "умелый фасилитатор-самоучка".
3. заключительные мысли.


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


За что книгу хочется поругать :
1. Утверждения о целях на ретроспективу - на мой взгляд, это скорее редкость. Обычно ретроспектива и служит для поиска цели, а не отталкивается от нее.
2. Примерные выкладки по времени ретроспективы, вида "недельная итерация -часовая ретроспектива" - бред. Существует нижний предел времени, меньше которого ретроспективу (качественно!) провести невозможно, и он, по моим наблюдениям, в районе 1,5-2 часов. Все что выше - вполне валидно, все что меньше - не возможно.

Итого: читать книгу если и стоит то только после того как прочтете книгу Норма Керта, она даст вам знаний больше.

Напосмотреть: North, Dan North

Английский язык для меня не родной (с чего бы это!), поэтому слушать низкопробные и дохлые доклады на английском у меня долго не получается.
 К тому же английский, по моему стойкому убеждению, является самым информационно-емким языком - то что на русском будет звучать как сложноподчиненное предложение в английском умещается в три слова.
Живых  докладчиков на английском языке тоже есть, но те кто делает это регулярно на системной основе - мало.
Один из таких - Dan North (@tastapod).
За последние две недели из разных источников я посмотрел три его видео и все они хороши.


Про то почему Agile не скалируется и что из этого следует

Про паттерны delivery

Про простоту


Ну и в качестве вишенки на вершине тортика - Dave Thomas про то почему у всех аллергия на слово Agile

Напосмотреть: Trust me, I'm ынженер

Скопилось видео всякого.

1. Марина Широчкина с хорошей обзорной лекцией о тестировании для всяких сторонних неокрепших умов. Это не столько для аудитории моего уютненького, сколько для людей которые будут у вас спрашивать "А тестирование - это как ?"



2. Дмитрий Безуглый с очень плотным набором очень умных мыслей про то куда вы прикатитесь с Agile
20151023BO Драйверы и паттерны организации эффективной разработки ПО from Stas Fomin on Vimeo.

3. О том как еще вы можете издеваться что вы можете сделать со своей Agile командой - Джонатан Расмуссон
Jonathan Rasmusson - 10 things you can do to better lead your agile team from NDC Conferences on Vimeo.

4. Mary Shaw о том что такое инженерия на самом деле и причем здесь софт


5. Время охуительных историй в исполнении Камилы Фурнье про то как переписывать продукты



6. О том как Etsy трансформировали сами себя для выпуска мобильных приложений.

Видео - Про тестирование в Agile

Хороший молдавский тренер - это как хороший французский коньяк. 

Только молдавский. 

И тренер.

Выделил за вчера и сегодня час времени и посмотрел видео к которому и был написан эпиграф.

Собственно смотреть вот сюда.
http://testitquickly.com/2013/11/27/tine-nasul-cumsecade/

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

Одна фраза о том, что "тестировщиков в Agile никто не приглашал"  (с) А.Лупан - можно считать самым емким выражением того что происходит вокруг.

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

P.S. Ну вот есть и еще один повод сгонять в Киев.
P.P.S. Леша, у тебя талант.

Видео: Agile Product ownership ina nutshell

Порой меня просто гипнотизируют виде отт Хенрика Книберга. Пожалуй лучший докладчик на тему бытового agile.
Боюсь представить сколько работы за таким видео стоит.
Смотрите
https://www.youtube.com/watch?v=502ILHjX9EE

Статья: Масштабирование организационных структур на примере Spotify

Henrik Kniberg в очередной раз радует годной статьёй.
Хотел было как-то изложить краткую суть со своими ремарками, но авторы статьи и так это делают сами ближе к концу.

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

Читайте

Запас карман не тянет ???

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

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

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

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

Мысли.
Во многих материалах посвященных Agile отсутствие upfront design расценивается как великое благо, ибо не надо тратить ресурсы на то, что вполне возможно никогда и не пойдет в разработку.
И это согласуется с идеями Lean - незаверщенная работа не приносит добавленной стоимости, не убыстряет процесс, съедает ресурсы.
Но опять же тема для крестового похода Lean на Agile - быстро переключится и сделать другой кусок работы  - это true Agile, а иметь незаверщенное производство - совсем не Lean.

Link:Agile Development Survey by VersionOne

Отличный отчет в виде инфографики о распространении Agile
http://www.versionone.com/state_of_agile_development_survey/11/
Аналогичная инфографика за 2010 год
http://www.versionone.com/state_of_agile_development_survey/10/