Берегитесь, ScrumBut (СкрамНО)

Перевод (литературно-вольный) оригинальной статьи http://www.scrum.org/scrumbut

Берегитесь, ScrumBut (СкрамНО).

ScrumButs – это то, почему команды не могут в полной мере воспользоваться Scrum, чтобы решать свои проблемы и в полной мере реализовать преимущества его разработки. Роли, правила, ограничения по времени (timebox) были не просто так выдуманы, а предназначены для получения желаемых результатов и решения повторяющихся проблем. 

ScrumButs означает, что Scrum выявил проблему, но ее оказалось слишком трудно исправить.  ScrumBut изменяет и извращает Scrum (примерно так как показано на картинке :-))), скрывая назойливую, как бельмо на глазу, проблему.

ScrumBut имеет особый синтаксис: (ScrumBut) (Причина) (Решение/Оправдание)

ScrumBut Примеры:

ScrumBut	Причина	Решение/Оправдание
Мы используем Scrum, НО	Делать Daily Scrum каждый день для нас слишком накладно	DailyScrum будет только один раз в неделю
Мы используем Scrum, НО	Ретроспективы для нас пустая трата времени	Мы решили их не проводить
Мы используем Scrum, НО	Мы не можем доставить инкремент продукта за месяц	Устанавливаем спринт длиной в 6 недель
Мы используем Scrum, НО	Иногда наши менеджеры дают специальные таски	Готовые таски не всегда соответствуют Definition Of Done

Иногда организации делают краткосрочные изменения в Scrum, чтобы получить время для исправления недостатков. Например, "done" может изначально не включать регрессию и тестирование производительности, потому что автоматизация может занять несколько месяцев. В течение этого времени прозрачность ставится под угрозу, но восстанавливается в кратчайшие сроки.

Привет, Канбан!

Японский в Киеве?

Не знаю как вы, но я знаю только одну фразу на японском: "おなまえは(なんですか)", что в переводе значит "как тебя зовут". При чем тут японский и что это все значит? )) Очень просто – я поехал на тренинг по Kanban, который проводил Николай Алименков 16 июня, хотя неожиданно заболел за день до отъезда. Ночной переезд в Киев, высокая температура сделали свое дело, и я с трудом волочил ноги по утренним улицам столицы, жонглируя в голове японской фразой. Я надеялся как можно быстрее добраться до пункта назначения.

Kanban, тренинг, что я там услышал и узнал?
Прежде всего, хочу сказать, что компания собралась на удивление небольшая. Это порадовало, ведь позволило нам максимально эффективно использовать время тренинга и задать кучу вопросов Коле, поспорить, разложить все по полочкам. Также мне представилась возможность заразить меньше людей :-).

Что нового я узнал?
            Хочу остановиться на двух основных для меня находках.

1.      Теперь я понимаю, что Cycle time и Lead Time - разные метрики. Lead Time начинает отсчет тогда, когда делается запрос, и заканчивается доставкой элемента. Cycle Time начинается, когда стартует непосредственная работа, и заканчивается, когда элемент готов к поставке. Грубо говоря, Lead Time - то, что видит заказчик, Cycle Time – то, что видим мы, разработчики.        

            2.  Коля поделился с нами интересным опытом команды, которая начала свою работу в Scrum и перешла на Kanban. Мы говорили о том, что Scrum отлично подходит для старта проекта - дисциплинирует людей, вырабатывает стабильный рабочий пульс и драматически обнажает проблемы. Позже, через несколько месяцев, имеет смысл перейти на Kanban, ведь он имеет больше степеней свободы, требуя определенной дисциплины и ответственности от команды.

Что после?

Автор этих строк остался доволен тренингом и тренером. Спасибо Коле Алименкову за возможность досконально обсудить Kanban. Несколькими часами позже, проболтавшись на вокзале вместе с организованными группами немецких фанатов футбола, я сел в поезд на Днепропетровск.  Теперь пью чай с малиной, сбиваю температуру фервексом и желаю всем не болеть, а читать про Kanban )).

Пока.

Планирование вашей рестроспективы на лету!

Что я нашел?
Совершенно случайно наткнулся на замечательный ресурс http://www.plans-for-retrospectives.com

Что можно делать?
С помощью этого инструмента вы можете генерировать план ретроспективы на лету, буквально за секунду! Разве это не замечательно? Для каждого из этапов ретроспективы в произвольном порядке выбирается активность и предлагается вам на выбор.

Зачем? 
Для меня это очень актуально, ведь я стараюсь сделать ретроспективы более разнообразными и  интересными для своей команды. Считаю, что нужно постоянно менять активности, не повторяться. Иначе ретроспектива приедается и становится чем-то рутинным.
Теперь с помощью этого нехитрого, но эффективного инструмента вы можете превратить ретроспективы в увлекательные встречи.

Agile намного эффективнее Waterfall

     В июне 2012 года уважаемая во всем мире независимая аналитическая компания Standish Group выпустит очередной годовой отчет об эффективности IT проектов. Все отчеты, начиная с первого в 1994 году, демонстрируют неутешительную статистику проектного менеджмента в нашей индустрии.
     По состоянию на 2009 год только треть проектов стали успешными. Следует упомянуть, что Standish Group использует классическое определение успешности проекта - on Time, Scope, Budget (треугольник менеджера).

     Еще в 2006 году Standish Group в числе 10 факторов успешности назвал Agile. Тут вы можете найти интересное интервью с Джимом Джонсоном (основателем и руководителем Standish Group), где он много говорит об Agile и изменениях в индустрии после появления гибких методологий.

     По моему мнению, статистику портят Waterfall проекты. В выборке они смешаны со своими более везучими собратьями, созданными при помощи гибких процессов. Февральский пост Майка Кона подтвердил мою догадку и поднял настроение.
"Думайте сами, решайте сами", но Agile проекты оказались в ТРИ раза эффективнее.

С нетерпением жду финального отчета.
Вы еще не верите в Agile? :-)

Все. Конец.

CSPO, как это было… Воспоминания о тренинге

Что? Где? Когда? 

24-25 Мая я побывал в Киеве на двухдневном сертификационном классе CSPO (Certified Product Owner), который проводил Сергей Дмитриев и ScrumGuides.  Надо сказать, что мой выбор класса и тренера был осознанным. Считаю Сергея одним из лучших эджайл тренеров в СНГ, и каждая встреча с ним для меня - цепь маленьких открытий. Я был уверен, что услышу что-то новое для себя в этот раз, и не ошибся.

Первое, что вызвало мое удивление, когда я зашел в помещение – гендерный состав участников тренинга. Приятно удивился количественному перевесу женского пола )).  

Что мы делали?
  
В первый день мы обсуждали основы Скрама, роли, артефакты, церемонии... Все это было мне до боли знакомо, но повторение – мать учения, а учитывая “fun” форму, в которую  все было облачено, первый день пролетел быстро и насыщенно.
Второй день тренинга меня по-настоящему порадовал. Я никогда раньше не сталкивался с техникой Story Mapping, которая и стала главным открытием для меня.                                              

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

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

И, конечно, последнее фото на память! Как тут не вспомнить финальную сцену из фильма «Пляж».  Кстати, уставшее лицо и желтая футболка на изможденном от двухдневного тренинга теле принадлежат мне.

Выводы?

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

P.S. Послевкусие от тренинга осталось похожим на норвежский шоколад )).

Все. До связи.

Мой опыт сдачи PMI-ACP

За последние несколько лет популярность гибких Agile методологий во всем мире стремительно возросла. Особенно это касается разработки программного обеспечения.
Но, даже зная это, я не мог представить, что осенью 2011 года на сайте PMI увижу новую сертификационную программу PMI-ACP (Agile Certified Practitioner). Сказать, что это меня порадовало - не сказать ничего.  PMI, который десятилетиями являлся оплотом консервативного Waterfall подхода и ассоциировался с белыми воротничками, решил открыть двери для набирающего силу Agile. Добро пожаловать! ))

PMI ссылается на исследование, проведенное Gartner, согласно которому к концу 2012 доля гибкой разработки программного обеспечения будет равна 80%.
Согласно другому исследованию, за период с 2008 по 2011 год количество проектов, использующих Agile, утроилось!

Почему я решил получить PMI-ACP?

1. Этой сертификация ценна, как и другие сертификационные программы от PMI. Требования к соискателям предъявляются высокие, а финальный тест (проверено на себе!) достаточно сложный. Получить его с наскока вряд ли получится. Следует вспомнить о классическом PMP, который считается одним из самых престижных в мире сертификатов в области проектного менеджмента (Waterfall). Для большинства работодателей PMI - знак качества и гарантия реальных знаний его обладателя.
2. Информации о сертификации на конец 2011 года практически не было. Я чувствовал себя первопроходцем и, не буду скрывать, эта роль мне нравилась.
3. Желание систематизировать свои знания и залатать в них дыры. Последних в процессе обнаружилось предостаточно, больше чем в швейцарском сыре.

Какие требования к соискателям?

Чтобы получить допуск к экзамену вы должны иметь:

• 2000 часов работы на любом проекте за последние 5 лет.  В какой роли - не имеет значения.
• 1500 часов работы на Agile проекте за последние 3 года, причем эти часы должны считаться отдельно от первых и не пересекаться во времени. То есть в сумме вы должны показать 3500 часов. Опять же, насколько я понял - ваша роль на проекте не важна.
• 21 час подготовки по Agile. PMI признает тренинги не только от официальных зарегистрированных представителей института REP, но и любые тренинги по гибким методологиям. На этот счет описание довольно размытое, но нужно быть готовым в случае аудита прислать копию сертификата (или сопровождающее письмо от тренера). Сертифицированные классы от Скрам Альянса CSM, CSPO, CSD автоматически признаются институтом. Вам необходимо только указать количество часов тренинга, пройденного вами (классы могут быть по длительности). Обычно для двухдневного CSM тренинга - 14 часов.

Что касается первых двух пунктов: в заявке нужно указать контакты ваших менеджеров. В случае аудита они подтвердят ваш опыт. Советую со всеми переговорить заранее, уточнить контакты и предупредить о возможном звонке или письме от PMI  - во избежание неприятных сюрпризов.

Мне не хватало официальных часов обучения, и я вспомнил об однодневном тренинге 2008 года по скраму, который проводил Тим Евграшин в Днепропетровске. Большое спасибо Тиму за то, что он выслал нерадивому ученику сертификат о его прохождении, несмотря на не сданную домашнюю работу.
Также большое спасибо ребятам из XP Injection Коле Алименкову и Алексею Солнцеву за прекрасный тренинг по инженерным практикам в декабре 2011 года. Это добавило мне недостающих 8 часов.

Итак, заявка была готова, и дрожащей рукой я нажал на кнопку Send  в аутлуке. Ответ пришел быстрее, чем предполагал - на следующий день. PMI принял мою заявку. Я начал готовиться к экзамену.

Как выглядит процесс получения сертификации?
Вкратце весь путь выглядит примерно так:

1. Заполнение заявки
2. Оплата сертификации -  495$ (435$ для членов PMI). 
3. Уведомление о том выбрана ли была ваша заявка для проведения аудита.
4. В случае аудита - отправка требуемых материалов в PMI. Подтверждение.
5. Сдача экзамена.

Что представляет собой сам экзамен и где он проходит? 
Финальный тест сдается в одном из центров Prometric. Время и дату (с точностью до 15 минут) вы выбираете сами. Тест состоит из 120 вопросов по Agile, Scrum, Lean, XP и охватывает 2 области знаний:

• Agile tools and techniques - 50%
• Agile knowledge and skills - 50%

Порог прохождения
Официальную цифру PMI не разглашает, что весьма странно, неужели решили поиграть в шпионов, но большинство экспертов склоняются к 69%.

Подготовка к экзамену
Я нашел все книги, рекомендованные для подготовки - всего их 15. У меня были сомнения в возможности одолеть такой объем информации за короткий промежуток времени (не хотелось долго ждать), поэтому решил сосредоточиться на ключевых. Как показала практика, это было верным решением.

• Agile Estimating and Planning Майка Кона - библия Agile планирования.
• Making Good Teams Great Дерби и Ларсен - одна из лучших книг по ретроспективам. 
• User stories applied for agile software development Майка Кона - культовая книга для любого эджайлиста.
• Lean Software Development: Achieving Enterprise Agility Бивена и Тротта - книжка показалась мне довольно сложной для понимания, потому что написана на философском уровне, где и обитает Lean. К ней пришлось вернуться второй раз перед экзаменом, чтобы освежить знания.
• Agile Project Management with Scrum Кена Швэбера - библия скрама от его создателя.
• The Art of Agile Development Джеймса Шора и Шейна Вардена - одна из лучших книг по XP.

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

Когда перечисленные книги были уже прочитаны, в поле моего зрения попала только вышедшая PMI-ACP Exam: How To Pass On Your First Try Энди Кроу. После она стала для меня важным элементом подготовки. 37 долларов, немного терпения (т.к. выбрал самую дешевую доставку) и в начале апреля вожделенный источник знаний лежал у меня в руках. Книга написана очень доступным языком. Ее можно назвать "химией" или "выжимкой" всех знаний, необходимых для успешного прохождения. В конце есть 2 практических теста, которые дают представление об экзамене и уровне его сложности. Прочитав книгу 2 раза "от корки до корки", я вышел на 90% правильных ответов.

Все же, чувствуя себя недостаточно уверенно, я купил 3 месячный доступ к онлайн симулятору на сайте AgileExams.com. После первого же теста мое сердце разлетелось на осколки, я ответил верно только на 50% вопросов. Они показались намного сложнее, чем были в книге, просто забойными. За несколько недель мне удалось поднять средний процент прохождения до 75%-80%. Тогда то и решил, что мой час настал.

Как я сдавал экзамен?
Когда, сидя в центре прометрик, я перешел к десятому вопросу, то понял, что не могу быть уверенным в успешном завершении всего предприятия. Вопросы оказались тяжелее, чем я рассчитывал. Как по мне, сложнее, чем у Кроу, но несколько легче, чем на AgileExams.com. Советую ориентироваться именно на AgileExams.com.
Все же справедливость восторжествовала, и по окончанию экзамена из принтера выползла бумага с печатью об успешной сдаче теста.


Какие были вопросы?
Половина вопросов касалась Scrum, еще одна треть XP, несколько по Lean и остальная часть общих положений Agile. Наиболее сложные вопросы - ситуационные. Описывается определенная ситуация в команде с предложением выбрать ЛУЧШИЙ вариант из перечисленных.

Что дальше?
Это очевидно )) Идти дальше дорогами Agility и получать 30 PDU (условных обучающих единиц, каждая из которых примерно равняется одному часу тренинга) в течение 3 годичного сертификационного цикла.

Все. Конец статьи.

.

Почему я решил открыть этот блог

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

     Вот несколько причин, по которым я решил сделать это:

1. За 7 лет работы в IT накопился определенный опыт в Scrum/Agile, которым хотелось бы поделиться со всеми желающими.
2. Свой блог  - это же прикольно )) И модно, особенно в последнее время. Блоги есть у всех - начиная от президентов и заканчивая домохозяками, которые пишут о том как лучше квасить капусту в банках.
3. Знакомства с новыми людьми - расширяет твой кругозор, происходит обмен информацией. Помните? Вместе весело шагать по просторам... И, конечно, подпевать лучше хором. Я искренне надеюсь на то, что смогу встретить своих единомышленников и просто хороших людей(не троллей).
4. Блог дисциплинирует. Это пока предположение ))) Скоро будет проверено на практике.
5. Блог - это возможность донести свои убеждения, мысли до широкой аудитории и получить feedback.
6. Еще блог для меня - возвращение в детство, когда я мечтал о том, что стану писателем и из под моего пера выходили стихи поразительно напоминающие наших классиков. Да... и еще незаконченный роман начатый еще в 9 лет. Пора браться за виртуальное блогговое перо.
7. Возможность выплеснуть немного(не верьте, на самом деле ее много) желчи и посетовать на засилье Manage & Control менеджмента в больших Украинских компаниях. С этим нужно бороться.

     Пока это все, может я что-то упустил, как думаете?

Самый первый пост

 Мой самый первый пост - хе хей!!! Как дела???