Я решил поучаствовать в разборе кейса, описанного Тимофеем Евграшиным в его блоге. Сначала начал писать комментарий, но потом понял, что он будет слишком большим. Поэтому оформляю в виде отдельной статьи. Вкратце проблема выглядит так – команда никогда не заканчивает все задачи в итерации, перенося их на следующую. В итоге итерации получаются размазанными.
Команда провела анализ и выделила возможные причины такой ситуации. Первая причина в том, что очень мало времени остается на саму работу в спринте за вычетом всех “процессных” задержек. Вторая заключается в том, что циклы тестирования и разработки “натурально” не совпадают и никто не может аргументировать в чем недостатки данной ситуации.
Начну с причин, потому что без их разбора нет смысла давать советы. Мне кажется из первой причины стоило копнуть еще глубже. Почему происходит столько много задержек? Почему команда целый день тратит на ревью результатов спринта, причем сборку надо залить за день до ревью? Откуда берутся многочисленные задержки, которые даже вынудили команду последний день итерации сделать не совсем рабочим? Первопричин может быть много, не берусь судить однозначно. Возможно не полностью автоматизирована сборка и установка приложения, может быть некоторые процедуры делаются по шаблону и из-за этого занимают много времени.
Вторая причина, указанная командой, является очень классической. Она пришла из поэтапного подхода к разработке, когда тестирование делается после завершения кодирования. При этом часто задачи на кодирование требуют несколько дней, что еще больше откладывает тестирование. И не меняя подхода, нереально ничего поменять.
Scrum предлагает комбинировать итерационный и инкрементальный подходы. А это значит, что в итерации команда делает одну фичу и только потом переходит на следующую. Такой подход заставляет распределять работу между членами команды и концентрироваться на достижении результата. Что делать тестировщикам пока нечего тестировать? Писать автоматизированные тесты, собирать тестовые данные, подготавливать необходимые процедуры и артефакты. Как только что-то готово, сразу передавать разработчику. Как только у разработчика что-то готово, сразу отдавать тестировщику. Таким образом, после завершения работы над задачей требуется минимальное время на ее тестирование.
Но самый главный вопрос – это вопрос понимания цели самих итераций. Итерации нужны для предсказуемости, налаженного ритма выполнения обязательств и слаженной деятельности без помех извне. Если задачи могут легко переноситься на следующую итерацию, то предсказуемость теряется. Никто не знает сколько задач завершит команда в очередной итерации. Ритм тут же теряется тоже, потому что ни у кого нет ощущения законченности выполненной работы и старта новой итерации с чистого листа. Вместо этого тянется тестирование и другие активности из прошлого. Пока все в команде не осознают этого, менять что-то почти бессмысленно.
Теперь разберемся, что же со всем этим делать. Задачи понятны. Я бы посоветовал реализовать следующие подходы:
Ну и конечно же не опускайте руки. Из любой ситуации есть выход, его надо только поискать. 🙂 Удачи этой команде и всем, кто сталкивается с подобными проблемами!
На размышления о необходимости роли Scrum Master я задумался после неожиданного обсуждения этой темы в комментариях к подкасту с моим участием. Приведу некоторые из тезисов, которые там фигурировали:
Вот как-то так. Эти тезисы и рассмотрим один за другим.
Scrum Master – это отнюдь не профессия, а всего лишь роль. Роль, которую может выполнять человек, уже обладающий другими ролями. К примеру, это зачастую менеджер, ведущий разработчик, лидер команды. Любой, кто полностью понимает и осознает суть методологии Scrum, ее ограничения при использовании в данном конкретном проекте, а также готов следить за “правильностью” применения выбранных практик и подходов. Человек в этой роли должен выделять время на помощь команде в избавлении от препятствий, быть в роли ведущего на всех встречах, тщательно следить за потраченным временем и соблюдением договоренностей между всеми членами проекта. При этом он должен быть готов к изменениям в подходах, и поэтому не должен быть догматиком, слепо следующим прочитанным “истинам”. Вот в принципе краткий список требований к этой роли. Кто должен ее брать на себя? Из моего личного опыта я считаю правильным отдать эту роль кому-то из команды разработки. Менеджеры слишком рискованные кандидаты на эту роль, потому что у них остается соблазн “управлять” и “указывать”, а роль совершенно не такая. Она больше “наблюдательная” и “рекомендательная”. Я встречал команды, где эта роль передавалась от итерации к итерации, чтобы каждый мог на себе почувствовать ее воздействие. Резюмируя, роль и специальность (профессия) – несколько несвязанные понятия. Поэтому не стоит их сравнивать.
“Кто угодно” – это достаточно размытое утверждение. Выше были перечислены требования к роли Scrum Master. Кто угодно, подходящий под эти требования, действительно способен справиться с ней. Кто угодно вообще – нет. Также как и с другими ролями: лидер команды, Product Owner, аналитик (это не всегда специальность), архитектор. У каждой из них есть свои требования. Мы все знаем, что случается, если роль берет на себя неподходящий человек. Провалы, срывы сроков, пустая трата времени и т.д. С ролью Scrum Master дела обстоят еще хуже. В современной разработке многие компании возлагают на Agile подходы очень много надежд. Провал в одном проекте может повлиять на глобальный переход к Agile подходам во всей компании. При таком риске очень важно тщательно подойти к выбору человека на роль Scrum Master.
Сертификация Scrum Master – это бич современности в IT. Мало того, что в название роли заложили слово Master, а это уже говорит о профессионализме, так дополнительно выдается сертификат после пары дней тренинга. И это говорит уже о том, что вы признанный профессионал Scrum методологии и готовы начинать работать в этой роли хоть завтра. Вернитесь и перечитайте требования к Scrum Master. Должно пройти немало времени, чтобы пропустить через себя все практики и набраться реального опыта. Только тогда можно принимать ответственные решения, которые принимает Scrum Master. И, пока к этим сертификатам относятся с уважением, провалы с применением Scrum не будут заканчиваться.
Scrum Master является катализатором роста эффективности команды в том случае, если он является лидером, мыслящим человеком и наглядным примером для членов команды. Это сочетание способно действительно повысить эффективность в разы. Постоянный анализ ситуации на проекте, видоизменение или настойка практик в соответствии с его особенностями, внедрение на собственном примере новых и полезных подходов дают отличные результаты. И тут как раз очень неплохо, чтобы Scrum Master был как можно ближе к команде, а не являлся обособленным ее членом.
В заключение, хочу затронуть тему вакансий Scrum Master на полный рабочий день. На первой стадии перехода к Scrum работа в этой роли действительно может занимать много времени. И очень важно не урезать время на нее. При правильной работе по внедрению Scrum времени должно тратиться все меньше и меньше. У всех по-разному: 10%, 20% или 50%. Зависит от размера и состава команды, взаимоотношений с заказчиком, сложности проекта и многих других факторов. Задача хорошего Scrum Master состоит в том, чтобы минимально воздействовать на процесс, лишь наблюдая и немного корректируя. Вот и получается, что после некоторого времени Scrum Master становится просто нечего делать большую часть времени. И ему надо либо переходить на другой проект, где возможно его роль не нужна, либо бездельничать. Поэтому я больше являюсь сторонником выбора Scrum Master непосредственно из членов команды.
Прошло лето, закончилась пора отпусков и мы активно взялись за планирование мероприятий на осенние месяцы. Нас давно приглашали в гости в Днепропетровск и мы решили приехать с тренингами в этот город. Визит запланирован на 17 сентября. В программе будет два тренинга – “Управление рисками в IT проектах” и “QA в Agile”.
Тренинг “Управление рисками в IT проектах” проведет Сергей Поволяшко. Цель тренинга – глубже рассмотреть принципы и методики управления рисками, а также возможности по их применению на практике. Практическая ориентированность тренинга позволяет не только освоить теоретический материал, но и проверить его эффективность. Это необходимо для профессионалов, технических и проектных менеджеров и тех, кто хочет ими стать. Полезен тренинг будет и для опытных руководителей, которые открыты для получения знаний и улучшения своих навыков. Подробности можно узнать из детальной программы тренинга. Регистрация уже открыта и продлится до 14 сентября. Торопитесь, количество мест ограничено!
Я же проведу один из моих любимых тренингов “QA в Agile”, на котором тестировщики смогут лучше понять свою роль и подходы к работе, которые используются в Agile методологиях. Также им будет предложены несколько рабочих QA процессов в командах, работающих по Scrum. Много интересных презентаций, различные полезные практики и игровые симуляции делают этот тренинг очень познавательным и полезным. Вы можете узнать больше о тренинге и ознакомиться с отзывами в детальной программе тренинга. Регистрация на тренинг уже открыта и продлится до 14 сентября. Торопитесь, количество мест ограничено!
Мы также будем рады встретиться со всеми желающими пообщаться или организовать встречу “Клуба анонимных разработчиков” впервые вне Киева. Присылайте нам свои предложения. До встречи в Днепропетровске!
Мы рады сообщить, что появилось видео с нашего доклада “Что означает ‘Готово!’ — применение практики Definition of Done” на конференции AgileDays’11. О том, как проходила сама конференция вы можете узнать из нашего отчета в двух частях. Видео остальных докладов с конференции постепенно появляется и может быть найдено на странице технического партнера, отвечающего за съемку. Это отличная возможность для тех, кто не попал на конференцию или пропустил интересные для себя доклады, наверстать упущенное.
Эта статья посвящена очень опасному и распространенному в наше время недугу под названием Scrum-оголизм. Распространение этого недуга непосредственно связано с одной из наиболее известных и практикуемых Agile методологий – Scrum. Давайте сначала разберемся кто же такой Scrum-оголик. Вот некоторые характерные черты:
В чем же проблема данной болезни? Scrum-оголики забывают о том, что на самом деле Agile – это набор ценностей и принципов, которые были сформулированы и поддерживаются большим количеством людей из мира IT. И не более чем. На базе этих принципов и практик сформировалась философия разработки, под которую попадает целый ряд методологий: Scrum, XP, Kanban, FDD, Crystal и многие другие. В самой методологии Scrum нет ничего плохого. Просто подойдет она далеко не каждому проекту. Вообще у каждого проекта собственный уникальный контекст, который состоит из специфики разрабатываемого продукта, отношения заказчика к бизнесу, команды разработчиков, стиля управления компании и многих других факторов. Конечно, многие проекты попадают под определенные шаблоны, характерные для множества проектов. Но применять методологию без анализа контекста применения просто недопустимо. Scrum отлично подходит как базис, с которого можно начать построение процесса для конкретного проекта, адаптируя и модернизируя его по мере развития. При распространении же Scrum-оголиком методология преподносится как серебряная пуля, которая спасет в любой ситуации. Неокрепшие умы и отчаявшиеся люди воспринимают Scrum именно так и часто тоже заболевают. Хуже всего то, что при этом начинают подвергаться сомнениям и ломаться устоявшиеся процессы вне зависимости от меры их успешности. То, что стоилось годами, приносится в жертву Scrum. Напоследок оно гневно называется Waterfall-ом. Все это очень напоминает религию. А, как мы знаем из истории, подобные действия со стороны религиозных организаций всегда причиняли только вред.
Как же распознать Scrum-оголика в себе и окружающих? Это очень просто! Scrum-оголики в большинстве своем придерживаются некоторых поведенческих шаблонов, которые легко узнать:
Как же бороться с Scrum-оголиками и причем здесь «сухари»? Лучший принцип – это пропускание информации через призму практики и контекста конкретного проекта. В данном аспекте мне нравится восточная философия «Shu-Ha-Ri» (она же «сухари») в применении к разработке.
На уровне «Shu» вы пытаетесь понять базовые принципы, основы и практики, на которых построена методология. Вы ничего не меняете и следуете всем практикам, пытаясь отточить свое понимание и технику исполнения. Через некоторое время (у каждого оно разное) вы готовы к переходу на следующий уровень. К этому времени вы уже имеете немало правильных вопросов к методологии и целесообразности применения тех или иных практик (правильного применения вы добились на предыдущем уровне).
На уровне «Ha» вы начинаете задавать эти вопросы, обычно начинающиеся со слов «почему …» и «зачем …». Это помогает вам адаптировать методологию под свои нужды, выбросив из нее все ненужное и усовершенствовав полезное. На данном уровне вы находитесь в поиске новых подходов, решений и приемов. Вы экспериментируете с другими методологиями и выбираете то, что подходит именно вам.
Наконец, на уровне «Ri» вы уже не следуете правилам. У вас появляется твердое ощущение, что есть правильно, а что нет. Вы не ограничены рамками одной методологии, вы строите методологию сами, исходя из своего опыта, знаний и понимания контекста. Scrum-оголики обычно находятся на уровне «Shu» и не готовы идти дальше. Эти люди еще не готовы выйти за рамки правил, им проще попросту действовать по инструкциям. Они не воспринимают советы от людей с других уровней, эти советы слишком абстрактны и неконкретны для них.
Так вот, если вы встретите Scrum-оголика, постарайтесь повлиять на него. Накормите его «сухарями» (расскажите о философии «Shu-Ha-Ri» и его место в ней) и ни в коем случае не поддавайтесь его влиянию. Если вам нравятся те идеи, которые несет в себе Scrum, то пробуйте применять его, но не становитесь Scrum-оголиком. Кушайте «сухари» и будьте бдительны!
Осень станет значимым событием этого года в мире Agile не только для Украины, но и для всей восточной Европы, благодаря конференции Agile Eastern Europe 2010. Конференция пройдет в Киеве 8-9 октября и соберет большое количество профессионалов и ключевых фигур в разработке программного обеспечения и применению Agile подходов. Среди ключевых докладчиков такие “легенды” как:
Масштаб конференции вышел далеко за рамки Украины и даже Европы – ожидаются докладчики из США, Канады, Бельгии, Финляндии, Франции, Германии, Венгрии, Израиля, Италии, Нидерландов, Норвегии, Польши, Швеции, Швейцарии, Великобритании, Украины, России и Беларуси. Программа конференции уже доступна и продолжает насыщаться интересными докладами.
От нас в 2009 году на первой конференции Agile Eastern Europe 2009 принимал участие Алименков Николай с докладом “People factor as failure reason of Agile adoption”. Презентацию и видео доклада можно найти в соответствующих разделах нашего сайта. Мы рассчитываем выступить и в этом году так как такое событие просто нельзя проигнорировать.
Регистрация на конференцию уже открыта. При регистрации и оплате до 31-го июля, стоимость участия составляет $250 при индивидуальной регистрации ($225 при групповой). С 1-го августа стоимость повышается до $300.
В преддверие конференции пройдет несколько мастер-классов от ключевых докладчиков:
Спешите зарегистрироваться! Такое событие нельзя пропустить!
После определенного затишья в июне, на июль мы решили запланировать много открытых тренингов. Причем решили сгруппировать их тематически для удобства участников. Получилось мероприятие под кодовым названием “выходные тестировщика”, которое мы планируем провести 3-4 июля в Киеве. Оно будет состоять из тренингов так или иначе связанных с тестированием.
3 июля мы проведем очень популярный тренинг “Тестирование веб приложений с Selenium”, который является техническим и предназначен для специалистов (или желающих ими стать) по автоматизации тестирования веб приложений с помощью популярного инструмента Selenium. Посетив этот тренинг, многие команды начали автоматизировать тестирование и добились отличных результатов. Мы получили немало позитивных отзывов и благодарностей от участников и их руководителей.
3 июля с гостевым тренингом “Agile Development with Scrum” выступит профессиональный тренер из Асхат Уразбаев. Agile методологии на данный момент вышли на первое место по использованию в проектах по информационной разработке. Но при этом на конференциях и собраниях различных сообществ по-прежнему очень много людей, которые не знакомы с Agile в целом и Scrum методологией в частности. Данный тренинг позволит систематизировать знания, а также на личном опыте опробовать некоторые практики. Участники будут иметь уникальную возможность задать вопросы опытному тренеру, обучившему большое количество команд и видевший немало проблем.
4 июля в продолжение тематики Agile пройдет тренинг “QA в Agile”, на котором тестировщики смогут лучше понять свою роль и подходы к работе, которые используются в Agile методологиях. Также им будет предложены несколько рабочих QA процессов в командах, работающих по Scrum. Много интересных презентаций, различные полезные практики и игровые симуляции делают этот тренинг очень познавательным и полезным.
Нам задают много вопросов по поводу детальной программы конкретных тренингов, поэтому мы решили начать публиковать ее на страницах тренингов. На данный момент опубликована детальная программа на все тренинги “выходных тестировщика”.
Присоединяйтесь к нам, эти выходные принесут вам немало пользы в будущем!
Зарегистрироваться на тренинги можно на нашем сайте. Стоимость участия 800 гривен за тренинг “Тестирование веб приложений с Selenium” или “QA в Agile”. За тренинг “Agile Development with Scrum” – 1000 гривен при регистрации до 20 июня и 1200 гривен при регистрации после 20 июня. В оплату любого тренинга входит обед и кофе-паузы. При регистрации сразу нескольких участников (не менее 3) скидка 10%.
Ждем вас на наших тренингах!
Мы рады сообщить о том, что наши возможности по проведению тренингов и состав доступных тренеров расширились благодаря сотрудничеству с российским тренинг-центром ScrumTrek. Многие отлично знают по выступлениям на различных конференциях Асхата Уразбаева и Никиту Филлипова. На последней конференции Agile Base Camp в Киеве Асхат выступил с докладом “Применение Lean в Offshore разработке”, а Никита – с мастер-классом “Формируем и Приоритезируем бэклог используя StoryMapping”. Мы слышали очень много положительных отзывов от участников и решили организовать первый открытый тренинг Асхата Уразбаева в Киеве. Состоится мероприятие 3 июля и посвящено будет разработке с использованием Scrum (“Agile Development with Scrum”).
Данный тренинг будет интересен для тех, кто планирует внедрять Scrum в своем проекте или организации, а также для тех, кто хочет сравнить свои способы работы с лучшими практиками индустрии. На тренинге будут рассматриваться следующие темы:
Тренинг будет насыщен примерами, дискуссиями, играми, иллюстрирующими основные принципы и практики гибкой разработки. Он направлен не только на формирование базовых представлений о гибких методологиях разработки, но и на упорядочивание имеющихся знаний и навыков. После прохождения тренинга участники смогут аргументированно пытаться внедрить у себя на проекте различные Agile практики и подходы, а также получат толчок к дальнейшему развитию в мире современной разработки, где Agile методологии давно вышли на первый план.
Регистрация на тренинг уже открыта и продлится продлится до 28 июня. Стоимость участия: при регистрации до 20 июня – 1000 гривен, после 20 июня – 1200 гривен. Торопитесь, количество мест ограничено! Если у вас есть вопросы по организации тренинга, то мы с радостью ответим на них. Для этого отправьте свой вопрос на support@xpinjection.com.
Презентации “Kanban VS Scrum” от Алименкова Николая и “XP Injection” от Алименкова Николая и Алексея Солнцева опубликованы в разделе ресурсов.
