Швабера вообще стоит читать, если есть интерес к применению Scrum, потому что, во-первых, он один из основателей Agile Alliance, а во-вторых один из двух авторов теоретики по процессу Scrum. То есть, он знает о чём говорит и то, что он говорит это не секонд хенд, а сведения из первоисточника.

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

Книга разбита на девять слабо связанных частей, а каждой рассматривается по несколько случаев, которые, по идее, должны дать общее представление об основных проблемах, методах их решения и о том, как вообще не допускать описанных ситуаций. Сами случаи показаны так, как видел их сам Кен и обычно разбиты на три части: исходная ситуация до введения Scrum, либо в самом начале его применения; описание появившейся проблемы; описание вынесенных уроков из ситуации и необходимые решения для устранения проблем (Lessons Learned). Очень хорошо и подробно описана работа в условиях одной команды, причем как в случае, когда начинался новый проект, так и при переводе существующего проекта на Scrum. Применение Scrum в случае, когда задействовано много команда (Scaling Scrum) описано явно недостаточно. При этом Кем в явном виде указывает на то, что расширение Scrum на несколько групп вполне осуществимо, но при это придётся сделать финт ушами.

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

MindMap Ежедневных митингов (кликабельно)

]]> http://alsedi.com/blog/mindmap-dlya-ezhednevnyx-mitingov/feed/ 0 http://alsedi.com/blog/ezhednevnye-mitingi/ http://alsedi.com/blog/ezhednevnye-mitingi/#comments Wed, 04 Mar 2009 16:48:17 +0000 Alex http://alsedi.com/blog/?p=305 Еще в то время, когда нам пытались привить Scrum (по ряду причин безуспешно), тема ежедневных митингов поднималась несколько раз за декаду, но так до дела и не дошло. Мы делали митинги сначала три раза в неделю, потом раз в неделю, потом раз за итерацию, потом по необходимости, потом без отрыва задниц от места.

Я уверен, что не я один участвовал в подобном процессе, мы материли “Scrum мастера” за то, что он ничего не знает, а время митинга растягивается минимум на час. Большую часть которого две трети участников спят, ковыряют столы, стулья и носы, звонят по телефону, обсуждают вчерашний футбол, сидят с хмурыми мордами лицами. После митинга никто не помнил о чем договорились, да и вообще, договорились ли?! Но ведь что то обсуждали, но что же решили? Никто не помнил. “Scrum мастер” писал письмо руководству о прогрессе в разработке, выражая его в процентах

Мы готовы к завоеванию мира на 90%!

Эта версия лучше на 45%!

Ваши ресницы будут длиннее на 63.3% если вы попали в 34 и 5 десятых процента белокожих женщин с карими глазами и родинкой на животе!

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

Так что необходимость митингов как была так и осталась. Я решил следовать довольно простой схеме. В моей команде люди разбиты по своим проектам и…

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

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

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

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

На третьем шаге собираем всех тестировщиков вместе. Это не может быть частое явление, на мой взгляд. Но почему бы не сделать так раз в месяц, для того чтобы не было вопросов кто и чем занимается. Это сыграет свою роль, обязательно. Когда это произойдёт нельзя будет сказать – “Вот он! Это потому что два месяца назад они были на митинге”, но при проблемах всегда найдется падла зараза, которая скажет “Это потому что митингов не было” и будет права.

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