Записи с метками scrum
Отличный набор тренингов для менеджеров проектов
3 Март

Мы постоянно развиваемся и растем, приглашаем новых тренингов, организуем новые интересные мероприятия в различных сферах IT. Изначально наш тренинг-центр предоставлял услуги только в области Agile и инженерных подходов. И этот статус твердо за нами закрепился.
Но жизнь меняется и мы стараемся расширять спектр предоставляемых услуг.
На данный момент мы имеем полный цикл тренингов для менеджеров и всех, кто хочет стать менеджером. Предлагаемый набор тренингов покрывает практически все сферы в области управления проектами, за исключением так называемых soft skills. Но это немного не наш профиль. Итак, что мы готовы предложить менеджерам:
- «Успешный старт проекта» (Сергей Поволяшко) – 8 часов
- «Практики эффективного, но экономного проектирования» (Дмитрий Ефименко) – 16 часов
- «Метрики: команды, проекты, процессы и код» (Сергей Поволяшко и Николай Алименков) – 16 часов
- «Управление рисками: классика, agile, бизнес, заказчик» (Сергей Поволяшко) – 8 часов
- «Планирование и оценивание в Agile проекте» (Николай Алименков) – 8 часов
- «Kanban для управления проектами» (Николай Алименков) – 8 часов
- «Организация работы на проекте с помощью Scrum» (Николай Алименков) – 16 часов
- «QA в Agile» (Николай Алименков) – 8 часов
При этом, у нас также есть тренинги по инженерным практикам, которые по-хорошему менеджерам должны быть тоже небезразличны для общего развития и современного взгляда на разработку. Все перечисленные тренинги проводятся опытными специалистами, которые знают толк в менеджменте и управлении проектами, имея за плечами немало жизненного опыта в реальных проектах.
Сергей Поволяшко имеет 15 лет стажа в IT. Работал по нескольким IT специальностям (разработчик, системный администратор, тестировщик). С 2001 года является практикующим проектным менеджером и менеджером IT подразделений. Сергей имеет многолетний практический опыт эффективного применения разнообразных методологий и практик на стыке интересов проектной команды, компании и заказчика. А также опыт организационного управления IT подразделений. Сертификации PMP и ITIL. Принимал лидирующее участие во внедрении CMMI L3.
Дмитрий Ефименко является экспертом в управлении проектами и командами, бизнес и системном анализе, проектировании, разработке, тестировании и построении процессов. Более 13 лет в разработке софта, последние 4 года – лидер продуктовой команды. Категорический сторонник вытягивающих подходов в проектировании и разработке, самоуправляющихся команд, бережливых и легковесных процессов. Увлекается синтезом эффективных процессов «под команду» из известных и не очень методов и практик.
Николай Алименков является экспертом в разработке приложений на Java и управлении командами. Имея опыт разработки более 7 лет, уже более 5 лет Николай работает с Agile методологиями. На текущий момент практикующий технический лидер и Scrum Master.
Отличительная особенность представленных тренингов в том, что каждая тема освещается с разных точек зрения и подходов (классических, Agile, собственных). Благодаря этому, каждый участник получает возможность перенять и применить на практике опыт тренеров в совершенно разных окружениях, методологиях и подходах к управлению проектами. Каждый найдет в представленном списке что-то интересное для расширения диапазона своих знаний и возможностей внедрения новых подходов.
Менеджеры, мы будем рады видеть вас на публичных тренингах и корпоративных мероприятиях в вашей компании!
Метрики в Scrum и Kanban
7 Февраль
По разным причинам Scrum получил очень широкое распространение среди IT компаний. Многие компании и отдельные команды начали внедрять Scrum в своих проектах. У одних это получается, у других не очень. Грамотный и опытный специалист перед внедрением чего-то нового всегда задумывается о метриках. Как убедиться, что внедрение Scrum идет по плану? Улучшается ли производительность команды? Нет ли каких-то проблем?
И тут в Scrum очень мало ответов. Кроме сугубо бизнес-метрик, которые можно применять практически в любом процессе (ROI, Earned Business Value, Running Tested Features и т.д.), в Scrum предлагается метрика Velocity. Но уже писано переписано, что использовать Velocity в качестве метрики не стоит. Это может привести к неожиданным неприятным последствиям.
Получается, что хороших метрик на первый взгляд нет. В конце статьи я упомяну некоторые неявные метрики в Scrum, но пока давайте поговорим о причине проблем. Самая главная причина – это время. Бизнес практически все измеряет временем (даже деньги – это время). А в Scrum это самое время фиксируется (быстренько все вспоминаем «железный треугольник»
) и разработка ведется итерациями. Но внутри итерации происходит много всего интересного: мы делаем задачи, пользовательские истории, тестрируем, собираем продукт, устанавливаем и т.д. И вся эта информация теряется на фоне итерации. Происходит так называемое «сглаживание шумов». Если мы затянули с одной активностью, то можем нагнать в другой. Ведь итерация целиком принадлежит команде и команда может «придумывать» внутри итерации что угодно, лишь бы в конце все было готово. Этот подход очень хорош для планирования, но отвратителен для метрик.
Во-первых, мы очень редко можем снимать показатели метрик – в конце итерации. А это в лучшем случае раз в неделю. В основном, все таки раз в две недели. Во-вторых, мы уже упоминали «сглаживание» и оно тоже вносит свои коррективы. Всю итерацию ситуация была из рук вон плохая, а в конце все сделали нечеловеческое усилие и вуаля – все готово и метрики в порядке. Хорошо это или нет? Нет! Мы теряем полезную информацию и не учимся на своих ошибках.

Совсем по-другому дела обстоят в Kanban. Тут внимание уделяется каждой задаче. Метрики снимаются со всего потока задач, который проходит через команду разработки. Вот краткий список метрик:
- Cycle Time – время, которое задача находилась в разработке от момента, когда ей начали заниматься, до момента, когда она прошла фазу конечной поставки.
- WIP – количество задач одновременно находящихся в работе. Разделяется по разным стадиям работы над задачей.
- Lead Time – время от появления задачи до ее конечной поставки. Включает Cycle Time и время ожидания в очереди на реализацию.
- Wasted Time – время, которое задача проводит в различных очередях, а не непосредственно в работе.
- Effectiveness – процент времени, которое тратится непосредственно на работу с задачей, а не на ожидания в различных очередях.
- Throughput – количество задач, которое может выполнять команда в единицу времени (день, неделя, месяц).
Этот простой список метрик позволяет полностью понимать и контролировать процесс разработки, постоянно анализируя и улучшая его. В идеале данные метрики считаются в разрезе категорий задач (по размеру, по типу, по срочности), чтобы еще улучшить понимание происходящего и позволить точнее прогнозировать результаты работы команды.
Я обещал упомянуть о неявных метриках в Scrum. Эти метрики можно собирать, используя Burndown Chart. Вы можете анализировать его с целью определения шаблонов работы команды, рассматривая ежедневный прогресс и гладкость графика. Вы можете усилить анализ. Для этого нужно ввести категоризацию задач и строить Burndown Chart по каждой категории. Некоторые команды ведут отслеживание метрик задач внутри итерации, но на мой взгляд это несколько противоречит принципам Scrum – внутри итерации команда может работать над задачами в произвольном порядке.
Подведу итог. В Kanban метрики гораздо сильнее, чем в Scrum, но это не делает Kanban более простым в реализации подходом. Наоборот, Kanban требует от команды гораздо больше ответственности, контроля и анализа с постоянным усовершенствованием. Зато с точки зрения бизнеса Kanban гораздо более прозрачный и контролируемый.
А какие метрики применяете вы? Какие метрики хорошо работали для вас в Scrum?
10-11 февраля мы с Сергеем Поволяшко проводим тренинг «Метрики: команды, проекты, процессы и код», где моя часть будет как раз посвящена метрикам и работе с ними в Agile проектах. Я буду рассказывать о метриках на различных уровнях в разных методологиях, методике их сбора и анализа.
Новый тренинг по метрикам пройдет 10-11 февраля в Киеве
26 Декабрь
Мы подготовили совершенно новый тренинг «Метрики: команды, проекты, процессы и код», который впервые пройдет в Киеве 10-11 февраля. Этот тренинг посвящен одному из наиболее важных инструментов в руках любого руководителя – метрикам. Ведь еще Том Демарко говорил: «Невозможно управлять тем, что нельзя измерить».
С чем зачастую сталкиваются проектные команды, отделы и целые компании?
- Непредсказуемость сроков окончания проекта
- Наличие только лишь экспертной оценки объема работ, которая не всегда точна
- Регулярное пожаротушение определенных проблем, а не устранение источников их происхождения (почему много дефектов? где наибольшая проблема? требования, планирование, коммуникации или что-то еще?)
- Применение метрик без цели или их неправильная интерпретация
- Несоответствие используемых метрик тому, что действительно нужно конкретному проекту, по конкретному контракту, конкретному заказчику
- Кажущиеся сложность внедрения измерений и бюрократичность процедур измерений
- Невозможность прогнозирования качества и количества работы
- Принятие решений, основанное на субъективных ощущениях
Что делать?
Во-первых, хорошо разобраться в том, а зачем мы вообще что-то хотим измерять в конкретной компании или в конкретном проекте? Какая польза от измерений?
Во-вторых, понять структуру измерений, обеспечить адекватное соответствие подготовки людей, состояния рабочих процессов, наличие инструментария.
В-третьих, и это, наверное, самое важное, должна быть «политическая» воля со стороны руководства компании или проекта по внедрению и поддержке измерений.
Обычно, в том или ином виде, измерения применяются и развиваются, но происходит это довольно долго, и не всегда эффективно.
Поэтому, основная идея тренинга – помочь компании или проекту быстрее понять, зачем и какие измерения нужны, как их внедрить и интерпретировать. Тренинг структурирует теоретическую подготовку в области измерений и вырабатывает эффективный подход к практическому применению измерений. Что важно, вырабатывается понимание выгод измерений для бизнеса, заказчика, проектной команды. Общая направленность на практическое применение. Интерактивное изложение теории и практическая работа в группах, множество практических заданий и кейсов из реальной жизни. Тренинг направлен на практическое применение измерений (метрик) при разработке ПО в проектных командах.
На тренинге будут рассматриваться различные виды метрик: проектные, процессные, качества и кода. Участники смогут получить представление о том, какие метрики стоит использовать в современных Agile методологиях (Scrum, Kanban), а также как и когда их собирать и анализировать. Качество кода также не будет забыто и участникам будут предложены разнообразные методики и инструменты для сбора и контроля метрик кода, не позволяющих проекту «скатываться» на уровень «говнокода».
Вести тренинг будут Сергей Поволяшко и Николай Алименков. Стоимость участия – 1700 гривен за участника (обед включен). При групповой регистрации возможна скидка. Регистрация уже открыта и количество мест ограничено. Торопитесь занять себе место на этом полезном тренинге!
Боремся с бесконечными итерациями
29 Ноябрь

Я решил поучаствовать в разборе кейса, описанного Тимофеем Евграшиным в его блоге. Сначала начал писать комментарий, но потом понял, что он будет слишком большим. Поэтому оформляю в виде отдельной статьи. Вкратце проблема выглядит так – команда никогда не заканчивает все задачи в итерации, перенося их на следующую. В итоге итерации получаются размазанными.
Команда провела анализ и выделила возможные причины такой ситуации. Первая причина в том, что очень мало времени остается на саму работу в спринте за вычетом всех «процессных» задержек. Вторая заключается в том, что циклы тестирования и разработки «натурально» не совпадают и никто не может аргументировать в чем недостатки данной ситуации.
Начну с причин, потому что без их разбора нет смысла давать советы. Мне кажется из первой причины стоило копнуть еще глубже. Почему происходит столько много задержек? Почему команда целый день тратит на ревью результатов спринта, причем сборку надо залить за день до ревью? Откуда берутся многочисленные задержки, которые даже вынудили команду последний день итерации сделать не совсем рабочим? Первопричин может быть много, не берусь судить однозначно. Возможно не полностью автоматизирована сборка и установка приложения, может быть некоторые процедуры делаются по шаблону и из-за этого занимают много времени.
Вторая причина, указанная командой, является очень классической. Она пришла из поэтапного подхода к разработке, когда тестирование делается после завершения кодирования. При этом часто задачи на кодирование требуют несколько дней, что еще больше откладывает тестирование. И не меняя подхода, нереально ничего поменять.
Scrum предлагает комбинировать итерационный и инкрементальный подходы. А это значит, что в итерации команда делает одну фичу и только потом переходит на следующую. Такой подход заставляет распределять работу между членами команды и концентрироваться на достижении результата. Что делать тестировщикам пока нечего тестировать? Писать автоматизированные тесты, собирать тестовые данные, подготавливать необходимые процедуры и артефакты. Как только что-то готово, сразу передавать разработчику. Как только у разработчика что-то готово, сразу отдавать тестировщику. Таким образом, после завершения работы над задачей требуется минимальное время на ее тестирование.
Но самый главный вопрос – это вопрос понимания цели самих итераций. Итерации нужны для предсказуемости, налаженного ритма выполнения обязательств и слаженной деятельности без помех извне. Если задачи могут легко переноситься на следующую итерацию, то предсказуемость теряется. Никто не знает сколько задач завершит команда в очередной итерации. Ритм тут же теряется тоже, потому что ни у кого нет ощущения законченности выполненной работы и старта новой итерации с чистого листа. Вместо этого тянется тестирование и другие активности из прошлого. Пока все в команде не осознают этого, менять что-то почти бессмысленно.
Теперь разберемся, что же со всем этим делать. Задачи понятны. Я бы посоветовал реализовать следующие подходы:
- Планируйте ровно на столько, сколько вы можете полностью закончить в итерацию. Не тратьте время на планирование остального. Это и сэкономит вам время и не будет никому давать несбыточных обещаний. Лучше возьмите еще работы, если все закончите в срок. Это будет гораздо приятнее и команде и заказчику, чем в очередной раз получить часть обещанного не готовым.
- Для более плотной командной работы над задачами и инкрементальности внутри итерации установите лимиты на количество задач, которые находятся в прогрессе. Причем жесткие и непоколебимые лимиты. Они будут вас заставлять помогать друг другу, делить большие задачи на маленькие, автоматизировать ручную работу и не распыляться на много задач сразу. Это повысит вашу эффективность.
- Для решения проблем с циклом тестирования внедряйте активно автоматизацию. Причем не просто автоматизацию, а различные вариации TDD (Test Driven Development). Чем больше тестов будет написано до завершения реализации задачи, тем меньше времени уйдет на тестирование. Еще одна практика, которая очень сильно может помочь – Slicing Development. Не разрабатывайте по несколько дней целиком готовую фичу. Вместо этого выкатывайте несколько промежуточных реализаций с урезанной функциональностью и отдавайте на тестирование.
- Ну и последний совет очевиднее всех – проведите ретроспективу и разберитесь в том, что происходит. Если команда или руководство не понимают зачем это все нужно, то все предыдущие усилия будут просто бесполезны. Возможно, в результате разбора окажется, что Scrum в вашем случае совершенно не подходит. Такое тоже бывает. Scrum – не серебряная пуля.
Ну и конечно же не опускайте руки. Из любой ситуации есть выход, его надо только поискать.
Удачи этой команде и всем, кто сталкивается с подобными проблемами!
А нужен ли на самом деле Scrum Master?
7 Сентябрь
На размышления о необходимости роли Scrum Master я задумался после неожиданного обсуждения этой темы в комментариях к подкасту с моим участием. Приведу некоторые из тезисов, которые там фигурировали:
- Scrum Master — фиктивная профессия, программисты, не умеющие хорошо пррограммировать
- Кто угодно справится с этой задачей
- Scrum Master гордится своими сертификатами, а продуктивность лишь падает
- Scrum Master – катализатор для роста эффективности команды только в умах зомбированных Scrum-конференциями
Вот как-то так. Эти тезисы и рассмотрим один за другим.
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 непосредственно из членов команды.
XP Injection едет в Днепропетровск!
25 Август
Прошло лето, закончилась пора отпусков и мы активно взялись за планирование мероприятий на осенние месяцы. Нас давно приглашали в гости в Днепропетровск и мы решили приехать с тренингами в этот город. Визит запланирован на 17 сентября. В программе будет два тренинга – «Управление рисками в IT проектах» и «QA в Agile».
Тренинг «Управление рисками в IT проектах» проведет Сергей Поволяшко. Цель тренинга – глубже рассмотреть принципы и методики управления рисками, а также возможности по их применению на практике. Практическая ориентированность тренинга позволяет не только освоить теоретический материал, но и проверить его эффективность. Это необходимо для профессионалов, технических и проектных менеджеров и тех, кто хочет ими стать. Полезен тренинг будет и для опытных руководителей, которые открыты для получения знаний и улучшения своих навыков. Подробности можно узнать из детальной программы тренинга. Регистрация уже открыта и продлится до 14 сентября. Торопитесь, количество мест ограничено!
Я же проведу один из моих любимых тренингов «QA в Agile», на котором тестировщики смогут лучше понять свою роль и подходы к работе, которые используются в Agile методологиях. Также им будет предложены несколько рабочих QA процессов в командах, работающих по Scrum. Много интересных презентаций, различные полезные практики и игровые симуляции делают этот тренинг очень познавательным и полезным. Вы можете узнать больше о тренинге и ознакомиться с отзывами в детальной программе тренинга. Регистрация на тренинг уже открыта и продлится до 14 сентября. Торопитесь, количество мест ограничено!
Мы также будем рады встретиться со всеми желающими пообщаться или организовать встречу «Клуба анонимных разработчиков» впервые вне Киева. Присылайте нам свои предложения. До встречи в Днепропетровске!
Появилось видео нашего доклада с AgileDays’11
31 Март
Мы рады сообщить, что появилось видео с нашего доклада «Что означает ‘Готово!’ — применение практики Definition of Done» на конференции AgileDays’11. О том, как проходила сама конференция вы можете узнать из нашего отчета в двух частях. Видео остальных докладов с конференции постепенно появляется и может быть найдено на странице технического партнера, отвечающего за съемку. Это отличная возможность для тех, кто не попал на конференцию или пропустил интересные для себя доклады, наверстать упущенное.
«Сухари» для Scrum-оголиков
24 Сентябрь
Эта статья посвящена очень опасному и распространенному в наше время недугу под названием Scrum-оголизм. Распространение этого недуга непосредственно связано с одной из наиболее известных и практикуемых Agile методологий – Scrum. Давайте сначала разберемся кто же такой Scrum-оголик. Вот некоторые характерные черты:
- Он свято верит в то, что Agile и Scrum – это слова синонимы. Отождествляя эти понятия, любое отклонение от Scrum истолковывается как анти-Agile
- Он считает Scrum идеальной методологией, которая подходит абсолютно для всех проектов. Если Scrum не работает для вашего проекта, то вы просто неправильно делаете Scrum
- Он распространяет Scrum везде, где только может. Зачастую вместе с методологией он стремится передать свою болезнь
- Он категорически относится ко всему традиционному и не связанному с Agile, называя это одним общим термином Waterfall
- Он считает Scrum больше чем просто методологией, скорее философией или ядром мировоззрения
В чем же проблема данной болезни? Scrum-оголики забывают о том, что на самом деле Agile – это набор ценностей и принципов, которые были сформулированы и поддерживаются большим количеством людей из мира IT. И не более чем. На базе этих принципов и практик сформировалась философия разработки, под которую попадает целый ряд методологий: Scrum, XP, Kanban, FDD, Crystal и многие другие. В самой методологии Scrum нет ничего плохого. Просто подойдет она далеко не каждому проекту. Вообще у каждого проекта собственный уникальный контекст, который состоит из специфики разрабатываемого продукта, отношения заказчика к бизнесу, команды разработчиков, стиля управления компании и многих других факторов. Конечно, многие проекты попадают под определенные шаблоны, характерные для множества проектов. Но применять методологию без анализа контекста применения просто недопустимо. Scrum отлично подходит как базис, с которого можно начать построение процесса для конкретного проекта, адаптируя и модернизируя его по мере развития. При распространении же Scrum-оголиком методология преподносится как серебряная пуля, которая спасет в любой ситуации. Неокрепшие умы и отчаявшиеся люди воспринимают Scrum именно так и часто тоже заболевают. Хуже всего то, что при этом начинают подвергаться сомнениям и ломаться устоявшиеся процессы вне зависимости от меры их успешности. То, что стоилось годами, приносится в жертву Scrum. Напоследок оно гневно называется Waterfall-ом. Все это очень напоминает религию. А, как мы знаем из истории, подобные действия со стороны религиозных организаций всегда причиняли только вред.
Как же распознать Scrum-оголика в себе и окружающих? Это очень просто! Scrum-оголики в большинстве своем придерживаются некоторых поведенческих шаблонов, которые легко узнать:
- Вне зависимости от полезности практики они продолжают ее применять, потому что иначе это будет уже не Scrum. Результатом становятся длительные митинги, бесполезные ретроспективы, бесконечное планирование и так далее
- Часто они являются «сертифицированными» Scrum специалистами, потому что свято верят в идеальность Scrum и не пожалели больших денег на сомнительную «сертификацию», тем самым приняв участие в построении финансовой пирамиды
- При разговоре о любом проекте вы можете услышать от них нарекания о том, что если бы все делалось по Scrum, то проблем бы не было
- Они начинают применять Scrum ко всем рабочим активностям, а не только к разработке
- При любом отклонении от Scrum они начинают категорически возражать. Часто эти люди являются источником подобных фраз: «Почему сел? Это же ежедневное собрание! Нужно стоять!», «Почему ничего не говоришь на планировании? Каждый должен говорить!», «Менеджерам в нашем процессе не место!»
- Они обычно мало знакомы с деталями других методологий (как классических, так и Agile), поэтому не всегда могут аргументировать свою точку зрения. Поэтому чаще они просто употребляют слово Waterfall в качестве показателя зла и неудач
- Такие люди не углубляются в вашу проблему и настойчиво рекомендуют начать использовать Scrum, причем как можно быстрее. Они не задают вам вопросов, позволяющих понять суть проблемы и контекст
Как же бороться с Scrum-оголиками и причем здесь «сухари»? Лучший принцип – это пропускание информации через призму практики и контекста конкретного проекта. В данном аспекте мне нравится восточная философия «Shu-Ha-Ri» (она же «сухари») в применении к разработке.
На уровне «Shu» вы пытаетесь понять базовые принципы, основы и практики, на которых построена методология. Вы ничего не меняете и следуете всем практикам, пытаясь отточить свое понимание и технику исполнения. Через некоторое время (у каждого оно разное) вы готовы к переходу на следующий уровень. К этому времени вы уже имеете немало правильных вопросов к методологии и целесообразности применения тех или иных практик (правильного применения вы добились на предыдущем уровне).
На уровне «Ha» вы начинаете задавать эти вопросы, обычно начинающиеся со слов «почему …» и «зачем …». Это помогает вам адаптировать методологию под свои нужды, выбросив из нее все ненужное и усовершенствовав полезное. На данном уровне вы находитесь в поиске новых подходов, решений и приемов. Вы экспериментируете с другими методологиями и выбираете то, что подходит именно вам.
Наконец, на уровне «Ri» вы уже не следуете правилам. У вас появляется твердое ощущение, что есть правильно, а что нет. Вы не ограничены рамками одной методологии, вы строите методологию сами, исходя из своего опыта, знаний и понимания контекста. Scrum-оголики обычно находятся на уровне «Shu» и не готовы идти дальше. Эти люди еще не готовы выйти за рамки правил, им проще попросту действовать по инструкциям. Они не воспринимают советы от людей с других уровней, эти советы слишком абстрактны и неконкретны для них.
Так вот, если вы встретите Scrum-оголика, постарайтесь повлиять на него. Накормите его «сухарями» (расскажите о философии «Shu-Ha-Ri» и его место в ней) и ни в коем случае не поддавайтесь его влиянию. Если вам нравятся те идеи, которые несет в себе Scrum, то пробуйте применять его, но не становитесь Scrum-оголиком. Кушайте «сухари» и будьте бдительны!
Конференция Agile Eastern Europe 2010
23 Июль
Осень станет значимым событием этого года в мире Agile не только для Украины, но и для всей восточной Европы, благодаря конференции Agile Eastern Europe 2010. Конференция пройдет в Киеве 8-9 октября и соберет большое количество профессионалов и ключевых фигур в разработке программного обеспечения и применению Agile подходов. Среди ключевых докладчиков такие «легенды» как:
- Mary Poppendieck – пионер применения Lean – бережливого подхода в разработке программного обеспечения. Автор ряда книг и обучающих программ, ключевой спикер интернациональных конференций
- Henrik Kniberg – Agile/Lean коуч с более чем 15-ти летним опытом в IT, автор известных книг – «Scrum and XP from the Trenches» и «Kanban and Scrum, making the most of both»
- Vasco Duarte – Agile коуч в компании Nokia, практикующий Agile с 2004 года
- J.B. Rainsberger – известнейший в мире разработки консультант и докладчик множественных конференций
- Robin Dymond – идеолог и тренер Agile команд, сертифицированный Scrum коуч
- и многие другие…
Масштаб конференции вышел далеко за рамки Украины и даже Европы – ожидаются докладчики из США, Канады, Бельгии, Финляндии, Франции, Германии, Венгрии, Израиля, Италии, Нидерландов, Норвегии, Польши, Швеции, Швейцарии, Великобритании, Украины, России и Беларуси. Программа конференции уже доступна и продолжает насыщаться интересными докладами.
От нас в 2009 году на первой конференции Agile Eastern Europe 2009 принимал участие Алименков Николай с докладом «People factor as failure reason of Agile adoption». Презентацию и видео доклада можно найти в соответствующих разделах нашего сайта. Мы рассчитываем выступить и в этом году так как такое событие просто нельзя проигнорировать.
Регистрация на конференцию уже открыта. При регистрации и оплате до 31-го июля, стоимость участия составляет $250 при индивидуальной регистрации ($225 при групповой). С 1-го августа стоимость повышается до $300.
В преддверие конференции пройдет несколько мастер-классов от ключевых докладчиков:
- «Lean Software Development – A Practitioners Course» от Mary Poppendieck (6-7 октября)
- «Certified Scrum Product Owner (CSPO)» от Robin Dymond (6-7 октября)
- «Certified ScrumMaster (CSM)» от Henrik Kniberg (6-7 октября)
Спешите зарегистрироваться! Такое событие нельзя пропустить!
«Выходные тестировщика» 3-4 июля в Киеве
23 Июнь
После определенного затишья в июне, на июль мы решили запланировать много открытых тренингов. Причем решили сгруппировать их тематически для удобства участников. Получилось мероприятие под кодовым названием «выходные тестировщика», которое мы планируем провести 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%.
Ждем вас на наших тренингах!







