AGILE UKRAINE

Coaching Agile Teams в Киеве!

noreply@blogger.com (Alexey Krivitsky) — Wed, 10 Apr 2013 10:40:47 PDT

Автор: Алексей Кривицкий

Мне не верится, но мы это сделали.

Наверное, мне уже пора перестать удивляться - после того, как СкрамГиды привезли в Киев Элистера Коуберна, с книг которого началось мое волшебное путешествие в мир гибкой разработки.

А сегодня в Киеве Лисса и Майкл, и не просто так, а с тренингом Coaching Agile Teams:

Коучи в городе! :)

Более того - в эту субботу вместе с ними мы проводим открытый Agile Coach Camp, на который вы еще можете успеть прийти.

Спасибо всем, кто зарегистрировался на тренинг и кемп, и тем самым сделал эти мероприятия возможными!

Что следует и чего не следует делать Канбан-коучу

noreply@blogger.com (Alexey Krivitsky) — Wed, 03 Apr 2013 12:27:03 PDT

Автор: Дэйвид Андерсон (David Anderson)
Перевод с английского.

Взято с www.software-kanban.de

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

Особенно интересным является тот факт, что я не замечаю подобного у консультантов по другим областям, таким как CMMI, Six Sigma (6 сигм), Lean (бережливое производство), Теория ограничений, управление рисками и т.д. Они не приходят с предвзятым убеждением, что «Канбан – это не более чем еще одна Agile-методика, поэтому мне нужно только освоить ее основные механизмы и принципы, а затем внедрить, как тот же Скрам или TDD». И это радует, так как на самом деле вы не сможете (по крайней мере, не должны) внедрять Канбан, так же, как Скрам или TDD.

Так что же делают Канбан-коучи и чего, что еще более важно, они не делают?

Прекратите отстаивать! Прекратите пропагандировать! Вместо этого наблюдайте

Наверное, самая большая трудность в обучении Agile-коуча Канбан-консалтингу – это заставить его прекратить отстаивать и пропагандировать Agile методы и практики. Agile, в своем худшем смысле слова – это религия, т.е. система верований со своими преданными фанатиками, которые слепо верят, что Agile все равно лучше, и не поддаются никакому логическому убеждению. Хуже того, они могут свято верить, что были посланы с небес, чтобы обратить «язычников» на пусть «истинной веры». Такие радикально настроенные Agile-коучи могут никогда не сдвинуться в сторону обучения Канбану. Они просто не в состоянии отложить в сторону весь свой накопленный опыт, чтобы принять более нейтральную позицию, наблюдая за текущим процессом и его текущими трудностями, и предлагая соответствующий курс действий.

Канбан-коучи не отстаивают и пропагандируют Agile, они наблюдают и советуют.

Канбан не осуждает сложившуюся ситуацию

Канбан-коуч никогда не должен выражать осуждение. Текущее положение дел таково, как оно есть, и стало оно таким из-за текущей команды, их обстоятельств и требований клиента, так что жалеть по этому поводу абсолютно бесполезно. Критиковать людей за то, что их текущие практики не соответствуют модному и современному подходу или же «системе верований» – занятие крайне неуважительное.

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

Подходит ли нам Канбан?

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

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

Хороший канбан-коуч всегда оценивает уместность применения данной методики, прежде чем ее рекомендовать. Вы не должны «продавать» эволюционный подход, революционно настроенному клиенту. Ситуативная осведомленность является неотъемлемым навыком канбан-коуча.

Канбан должен быть подобен воде

Вода может омывать камни. Такими камнями является эмоциональное сопротивление изменениям, которые могут привести к лучшим экономическим и социальным последствиям для всех заинтересованных лиц, и в результате принести всеобщее удовлетворение сторон. Канбан-коучи должны учиться предвидеть это эмоциональное сопротивление, что называется, идентифицировать все «камни» перед внедрением системы канбан в рабочий процесс.

Канбан-коучи должны избегать рисков на самой начальной стадии. Там, где не удается избежать камней, они создают такую канбан-систему, которая повышает осведомленность о них, и создают эмоциональную мотивацию к изменениям. Вода со временем точит камни. Хорошие канбан-коучи знают, что хватит и одного коуча, чтобы «сменить лампочку», главное, чтобы сама «лампочка» имела желание меняться. Создание условий для мотивированных изнутри изменений – это и есть работа по-настоящему хорошего Канбан-коуча.

Построение канбан-систем – это продвинутый навык

Хорошие Канбан-коучи знают, что нет смысла силой навязывать изменения, встречаемые с отпором. Они должны избегать построения канбан-системы, которая бы сразу же решила все проблемы существующего процесса, выявленные при начальном наблюдении. Возможно, введение ограничений на выполняемую в текущий момент работу (WIP – work in progress), в качестве решения проблемы перегруженности команды, вызвало бы сопротивление с их стороны? Это сопротивление можно предвидеть заранее, если понимать с эмоциональной точки зрения, как это может отразиться на всех участниках команды, их личном образе, самооценке, эго, социальном статусе и других аспектах.

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

Переведено с английского проектом Agile Translations.
Оригинальная статья "WHAT KANBAN COACHES DO, AND DON’T DO" опубликована на сайте http://agilemanagement.net.

Материалы с Agile Pizza (Beer Game)

noreply@blogger.com (Lina Shishkina) — Fri, 22 Mar 2013 04:07:51 PDT

19 марта состоялась Agile Pizza с участием Tom Looy и других активных членов сообщества. Мероприятие собрало порядка 30ти активистов сообщества - кто-то встретил старых друзей, кто-то завел новых знакомых.

Том (Tom Looy) выступил с презентацией "Beer Game", материалами которой мы и спешим с вами поделиться.

The Beer Game (Intro) by Tom Looy from SCRUMguides

А также ссылочки на материалы, использованные в презентации:

До новых встреч!

Оценивание и планирование необходимы для повышения поставляемой ценности

noreply@blogger.com (Alexey Krivitsky) — Mon, 11 Mar 2013 08:13:36 PDT

Автор: Майк Кон (Mike Cohn)
Перевод с английского.

Я сильно интересуюсь оцениванием и планированием и всегда обращаю внимание на новые статьи в блогах и новостях, говорящих о том, что “Оценивание - напрасная трата времени! Не делайте его!”. Меня не удивляет, что аргументы против оценивания и планирования исходят не от бизнесменов, для которых мы разрабатываем продукты или системы. Они понимают важность оценок и планов (и недостатки плохих оценок и планов).

Давайте подумаем, как много значимых вещей в своей жизни вы делаете без какого-либо планирования. Я сомневаюсь, что вы будете затевать свадьбу, переезд в другой город, путешествие или другое подобное событие без какого-то минимального планирования.
Представим, что вы впервые собираетесь в путешествие по Италии. Вы будете планировать, какие города вы хотите посетить, как долго будете находиться в каждом из них, какой бюджет путешествия и т.д. Теперь представим очередной стотысячный визит родного города, в котором вы выросли. Вы будете планировать даже это путешествие - даже если объем планирования сведется к решению, что вам совсем не нужно ничего планировать.

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

А что насчет оценивания? Действительно ли нам нужно оценивать? Да, потому что оценивание является предпосылкой для планирования. Вы не сможете планировать без оценок. Эти оценки могут быть очень неформальными и очень неявными. В данный момент я лечу в Калифорнию. Перед посадкой я снял деньги в банкомате. Я предположил, что на предстоящие нужды мне необходимо $200. Эта оценка забрала у меня менее секунды, и я даже не осознал, что я что-то оценивал.

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

Команды, которые говорят “Мы не будем оценивать. Мы будем делать все пользовательские истории одинаковыми по объему работы”, на самом деле оценивают. Они предполагают, что объем работ в каждой новой истории такой же как и в остальных. Я готов поспорить - сложнее сделать все истории одинакового размера, чем использовать небольшой диапазон оценок усилий для разных историй. Такие оценки должны быть сделаны. Да, они могут быть подсознательными, но они сделаны. Те, кто пишут в блогах и новостях “оценивание - пустая трата времени, не делайте его”, - игнорируют такие типы оценивания.

Но хороши ли эти небрежные, возможно подсознательные, оценки? Не лучше ли будет для команд делать оценки формально?

Скорее всего да, но не всегда. Команда должна оценивать и планировать только до тех пор, пока это приводит к большей уверенности в дате сдачи проекта, лучшей расстановке приоритетов, и т.п., если это не так, то стоит прекратить оценивание и планирование.

К примеру, мы недавно добавили немного функционала на наш сайт по удаленному обучению eLearning course on Agile Estimating and Planning. Я не просил программиста, который делал эту работу, дать мне более чем поверхностную оценку. Я всё ещё достаточно хорошо разбираюсь в программировании, чтобы иметь понятие о том, как долго разрабатывать новый функционал. Также я достаточно давно с ним работаю и знаю насколько он быстр. Более детальная оценка ничего бы не изменила в данном проекте.

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

Переведено с английского проектом Agile Translations.
Оригинальная статья: Estimating and Planning Are Necessary for Maximizing Delivered Value.

Правила или общепринятые практики Скрам

noreply@blogger.com (Alexey Krivitsky) — Mon, 25 Feb 2013 02:55:12 PST

Автор: Майк Кон (Mike Cohn)
Перевод с английского.

В одной из мартовских заметок своего блога, я ввел термин, который в то время пробовал ввести в обсуждениях и некоторых классах. Термин был "GASP" и расшифровывался как общепринятая практика Скрам (англ. Generally Accepted Scrum Practice). В чем я сейчас действительно заинтересован и, надеюсь, вы мне в этом сможете помочь, так это создать список всех общепринятых Скрам-практик которые мы знаем.

Читать дальше >>>

Как Spotify создает продукты

noreply@blogger.com (Alexey Krivitsky) — Sat, 23 Feb 2013 12:30:18 PST

Автор: Хенрик Книберг (Henrik Kniberg)
Перевод с английского проектом Agile Translations.

Разработать продукт непросто. Большинство попыток разработки терпят неудачу, и самой распространенной причиной этого считается создание неправильного продукта.

Spotify - шведский низкобюджетный стартап с замечательными показателями выпуска продуктов. Их продукты любимы пользователями и артистами, они распространяются со скоростью вирусов - у них более 20 миллионов активных пользователей, 5 миллионов платных подписчиков, и быстрый рост продолжается. К примеру, чтобы в США начать с нуля и дорасти до 1 миллиона платных подписчиков, им потребовался приблизительно год, а ведь это иностранный рынок, где присутствует множество крепких игроков.

Главная идея Spotify – предоставить вам музыку для каждого момента. Это неограниченный доступ к любой музыке мира и возможность быстро ею поделиться. Чем больше музыки «расшарено» и проиграно, тем больше денег поступает артистам. Начавшись c музыкального проигрывателя несколько лет назад, их продукты сегодня превратились в повсеместно присутствующую и всем знакомую платформу для открытия новой музыки и установления непосредственной связи между артистами и поклонниками.

Их продукты просты, персональны и забавны. Даже музыканты «Металлики», долгое время выступавшие непримиримыми оппонентами любых сервисов для трансляции музыки, теперь считают Spotify "наилучшим транслирующим сервисом" и "поражены его простотой и удобством".

Однако здесь есть парадокс: успешные компании, такие как Spotify, просто хотят выпускать продукты, которые будут нравиться людям. Но им неизвестно, что именно нравится людям, пока этот продукт ими не выпущен.

Как же они узнают об этом?

Цель этой статьи - создать общее представление о том, как Spotify подходит к разработке продукта.

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

Благодарности.
Эта модель изобретена не мной. Материал этой статьи базируется на дискуссиях с Gustav Söderström, Oskar Stål, Olof Carlson, их внутренних документах и моделях, таких как “Think It, Build It, Ship It, Tweak It”. Также я многое узнал их разговоров с дизайнерами, разработчиками и тренерами гибкой разработки. Спасибо всем вам!

Обзор

Сущность нашей философии такова:

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

Все основные направления деятельности по созданию продукта проходят 4 стадии:

Think It (обдумай)
Build It (построй)
Ship It (доставь)
Tweak It (подстрой)

Перед вами схема, на которой вы можете проследить весь поток от идеи до продукта и все события на каждой стадии этого движения:

Четыре фаза разработки продукта Spotify

Более подробную версию этой схемы вы увидите в конце статьи.

Think It = выясни, какой тип продукта мы разрабатываем и для чего.

Build It = создай минимально работоспособный продукт, готовый для реальных пользователей.

Ship It = постепенно предоставь 100% пользователей доступ к нему, измеряя параметры и улучшая продукт.

Tweak it = Постоянно совершенствуй продукт. Это действительно окончательное состояние; продукт находится здесь, пока не будет закрыт или пересмотрен (= вернуться к Think It).

В Spotify более 30 команд (это маленькие, кроссфункциональные самоорганизующиеся команды, больше описано в статье: "Scaling Agile @ Spotifywith Tribes, Squads, Chapters, and Guilds”) и множество разных продуктов, поэтому для того, чтобы следить за происходящим в остальной компании и представлять это зрительно, мы используем таблицу состояния продукта, показывающую на какой из стадий находится данный продукт. Приблизительно она выглядит так:

Таблица состояния продуктов Spotify

Кроме того, мы испытываем прогностические инструменты, а команды отвечают за регулярное обновление таблицы сроков (дата А-дата Б), показывающие, когда они предполагают достичь следующей стадии.

Зачем 4 стадии?

Самый большой риск – построить неправильный продукт: ведь он не приносит радости нашим пользователям, не улучшает показатели успеха, такие как привлечение пользователя, удержание пользователя, т.д. Мы называем это "риск продукта".

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

График снижения рисков продукта

Как можно заметить, стадия «Обдумай» снижает риск до малых показателей. Постепенно снизившиеся издержки производства на стадии «Настрой» показывают, что со временем продукт не нуждается в таком количестве обновлений и команды могут переключиться на другие проекты.

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

Итак, давайте теперь присмотримся к каждой из стадий.

Think It

Идеи продукта могут возникать все время и происходить от любого из сотрудников компании. Большинство идей - это усовершенствования существующих продуктов ("настройки"), а команды будут применять их, и выпускать свои собственные.

Стадия «Обдумай» означает появление у кого-либо совершенно новой идеи продукта или желания переделать уже существующий продукт.

Фаза "Think It"

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

Определение продукта - это короткий документ, отвечающий на следующие вопросы:

Зачем нам это разрабатывать?
Кому и какая от этого польза?
Какие ключевые показатели призван улучшить данный продукт?
Это может быть определено как количество транслируемой музыки, количество загрузок, число подписчиков.
Каковы гипотезы?
Как мы узнаем, что продукт удался?
Будет ли это "качественным скачком" (таковым считается продукт, позволяющий, по крайней мере, двукратно улучшить избранный для оценки критерий)? Если ожидается лишь незначительное улучшение показателей, возможны другие причины для его разработки, например, соображения стратегии.

Определение продукта - это не документ с перечнем требований или план проекта. В нем нет списка приложений, бюджетов, планирования ресурсов и тому подобного. Это скорее описание цели проекта на основании данных.

Наиболее важная часть определения продукта - это его история или нарратив. Что он расскажет миру? Как будет выглядеть его пресс-релиз?

Вот, например, недавний продукт Spotify - таблица «Discover». Приведем выдержку из двухминутного видео, представляющего данный нарратив:

Мы предлагаем вам новый способ совершить музыкальное открытие.
Смотрите! Любимый артист делится с вами песней. Мы как никогда сближаем артистов с фанатами. Нравится артист? Просто фолловьте их и делитесь своими открытиями с друзьями.

Другой пример - это Mobile Free Radio, с нарративом "Radio you can save". В данном случае мы использовали Google Adwords, чтобы испробовать разные нарративы вживую и выяснить, какой из них был наиболее убедителен.

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

Кроме того, команда «Обдумай это» разрабатывает множество разных прототипов, чтобы поэкспериментировать с оформлением приложения - как с низкокачественными бумажными прототипами, так и с высококачественными работоспособными прототипами (однако с ложными источниками данных и так далее). Внутренние фокус-группы задействуются, чтобы установить, какие прототипы наилучшим образом передают нарратив, до тех пор, пока число их не сузится до нескольких выигрышных кандидатов.

Выбор и отбраковка продуктов

Этот процесс носит циклический характер, жестких сроков здесь нет.

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

Как показывает кривая риск/издержки, приведенная выше, стадия «Обдумай» позволяет нам снизить риск продукта весьма рентабельным путем - мы просто разрабатываем прототип и экспериментируем. Это позволяет нам дешево и безопасно ошибаться, так что мы можем вести испытания, пока не выясним, каков тот самый правильный продукт, который мы собираемся разрабатывать.

Критерий завершения:

Стадия «Обдумай» заканчивается, когда команда и менеджмент приходят к общему пониманию того, что данный продукт стоит разработки (или же данный продукт никогда не станет достоин разработки и должен быть отбракован). Это субъективное решение, которое не поддерживается никакими вещественными данными. Эти вещественные данные задействуются на стадии «Доставь», поэтому мы хотим добраться до нее как можно скорее.

Build It

Команда «Обдумай» сейчас расширяется до более постоянной команды (иногда множества команд) со всеми необходимыми навыками для разработки, тестирования и доставки реального продукта. Эта команда будет причастна к данному продукту на протяжении длительного срока, а не просто в фазе «Построй».

Цель стадии «Построй» - разработать MVP (минимально работоспособный продукт), который достаточно хорош, чтобы выпустить его для внешних пользователей, и также достаточно хорош, чтобы улучшить кое-что в самом продукте. MVP разрабатывается повторно при помощи методов гибкой разработки, таких как Скрам, Канбан, экстремальное программирование.

Фаза "Build It"

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

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

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

Итак, команде нужно определить малейший из возможных продукт, который они могут разработать, чтобы соответствовать базовому нарративу и доставлять удовольствие пользователям. Нам нужно, чтобы этот продукт соответствовал нарративу, а не обладал всеми возможностями. Возможно, подходящим термином будет Минимально Любимый Продукт.

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

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

Критерий Завершения:

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

Мы готовы к Моменту Истины!

Ship Ip

Цель данной стадии заключается в том, чтобы постепенно выдать продукт для 100% пользователей, при этом измеряя степень исполнения продуктом своего обещания в "диком пользовании" и обеспечивать это исполнение.

Фаза "Ship It"

Команда начинает с релиза для небольшого процента пользователей (обычно от 1-5%) для сбора данных. Как поведут себя эти пользователи в сравнении с остальными 95-99%?

Помните, мы на стадии «Think It» определили для продукта несколько гипотез. Сейчас мы сможем наконец-то проверить, насколько они правильны, при необходимости повторно улучшив продукт. Очень редко можно получить правильный продукт с первой попытки, и сила данной модели отчасти и в том, что нам не приходится этого делать.

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

Критерий Завершения:

Стадия «Ship It» завершается, когда продукт доступен всем пользователям. Помните, что этот продукт еще не "завершенное приложение". Завершения фазы «Ship It» означает, что продукт (MVP + необходимые усовершенствования) был выпущен на 100%. Такой вещи как "законченное приложение" не существует, поскольку продукт постоянно совершенствуется даже после этой стадии.

Tweak It

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

Фаза "Tweak It"

Сейчас продукт находится в производстве и доступен всем пользователям.

Хотя в определенной степени он уже проверил себя на стадии «Ship It», всегда остается довольно много пространства для улучшений. Отряд продолжает экспериментировать, проводить A/B тестирование и улучшать продукт, в то же время наблюдая за его показателями. Это может включать в себя важные новые приложения или же тонкие настройки.

Однажды в будущем отряд может достичь момента уменьшения обращений к продукту. Продукт великолепен, наиболее важные улучшения внесены, но соотношение цена/польза выглядит менее привлекательно. Если же взглянуть на показатели, окажется, что новые усовершенствования не приводят к большим переменам. Это означает, что продукт достиг "локального максимума".

Подстройка и локальный максимум продукта

В такой момент менеджмент и отряд обсуждают, довольны ли они этой горой, или стоит поискать вершину повыше? Если первое верно, команда может постепенно переключиться на новые продукты. Иначе, команда может вернуться к "Think It", чтобы переделать этот продукт и совершить прыжок к локальному максимуму (или более высокому пику).

Подстройка и переосмысление

Одним из примеров может служить сайт www.spotify.com. Этот сайт настраивался 4 года, пока летом 2012 мы не решили переделать его. Этот сайт передает главную идею Spotify совершенно иначе и куда более эффективным образом.

Обзор всего процесса

Весь процесс разработки продуктов Spotify

Заключение

Надеюсь, эта статья понравилась вам!

Если некоторые части этой модели вызвали у вас мысль: "Да я уже знал об этом, мы десятилетиями этим занимались", вы наверняка правы.

Эта модель вовсе не что-то новое и удивительное, это работающая штука, а новая она или старая, неважно.

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

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

Хенрик Книберг: henrik.kniberg@spotify.com
http://www.crisp.se/henrik.kniberg

Переведено с английского проектом Agile Translations.
Оригинальная статья: How Spotify Builds Products.

Ретроспектива спринта - эффективный формат

noreply@blogger.com (Alexey Krivitsky) — Sat, 23 Feb 2013 12:04:25 PST

Автор: Майк Кон (Mike Cohn)
Перевод с английского

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

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

Хотя существует множество способов организации Ретроспективы спринта, я рекомендую проводить ее в формате «старт-стоп-продолжить» (start-stop-continue) . Это, пожалуй, самый простой, но часто наиболее эффективный способ проведения ретроспектив. При таком подходе каждому участнику команды будет предложено определить конкретные вещи, которые команда должна:

Начать делать
Прекратить делать
Продолжать делать

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

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

Переведено с английского проектом Agile Translations.
Оригинальная статья: Sprint Retrospective.

Три статьи

noreply@blogger.com (Alexey Krivitsky) — Sat, 16 Feb 2013 07:02:17 PST

Автор: Алексей Кривицкий

Как многим уже известно, мы стартовали инициативу по переводу наиболее востребованных и популярных статей - проект Agile Translations.

Часть этой активности взяли на себя активисты сообщества AgileUkraine, а часть спонсирована SCRUMguides.

Переводы, опубликованные в феврале:

Планирование релиза: уходим от термина, но не от практики
Майк Кон

Общепринятые практики работы с Беклогом Продукта
Майк Кон

Менеджер 2.0: роль менеджера в Скраме
Пит Димер

Присоединяйтесь к нашей команде переводчиков. Мы используем Канбан и командный подход для выпуска переводов.

4-я встреча IT-сообщества IT talk в Киеве

noreply@blogger.com (Lina Shishkina) — Fri, 15 Feb 2013 02:38:59 PST

14 февраля 2013
Инициативная группа компании DataArt приглашает профессионалов, преподавателей, студентов и начинающих разработчиков на семинар, посвященный сложностям в IT продажах.

В программе встречи:

Анастасия Новикова, соучредитель школы IT-продаж Conformato, управляющий партнер компании NexGen Design Technologies.
Евгений Ковалик, создатель KoStart, соучредитель школы IT-продаж Conformato, старший партнер компании NexGen Design Technologies.

Участие во встречах IT talk — бесплатное.

Для участия требуется регистрация

Дата и время проведения:
Четверг 14 февраля 2013 г., 19.00

Место проведения:
Национальный технический университет Украины (КПИ), Политехническая ул., 14а, 3-й этаж, ауд. 97 учебного корпуса 15, вход из вестибюля корпуса приемной комиссии.

Об IT talk
IT talk — созданное по инициативе компании DataArt открытое IT-сообщество, участником которого может стать каждый желающий и интересующийся развитием IT-отрасли. IT talk — реальная возможность для профессионалов, преподавателей, студентов и начинающих разработчиков делиться новостями, техническими решениями, собственными наработками, обмениваться мнениями, представлять их на семинарах.

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

Планирование релиза: уходим от термина, но не от практики

noreply@blogger.com (Alexey Krivitsky) — Sat, 16 Feb 2013 07:03:16 PST

Автор: Майк Кон (Mike Cohn)
Перевод с английского.

Я хочу обратить внимание на термин, используемый в Скраме (точнее, даже Аджайл термин), который во многом пережил себя: планирование релиза. Общепринятое использование "релизного планирование" заключалось в том(я так тоже делал), что мы смотрели в будущее на несколько спринтов вперед и пытались предсказать, что бы мы могли выпустить. Было бы хорошо в идеале эти предположения выражать в виде диапазона значений, возможно даже с использованием интервалов вероятности.

В течение многих лет я учил команды делать именно так. Скажем, мы могли сказать, что “Мы уверены на 90%, что через шесть месяцев сможем выпустить продукт с функционалом в диапазоне между 150 и 200 стори поинтов.” Я до сих пор считаю эту практику полезной и каждый Скрам-мастер должен знать как это делается.

Что на самом деле потеряло смысл, так это сам термин “планирование релизов”.

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

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

Я вижу как усиливался этот тренд за последних несколькл лет. Я действительно понял, что мы достигли критической точки, когда этот термин вызвал непонимание на одном из моих классов. Я описывал “планирование релиза” как проекцию того, что мы делаем на протяжении нескольких спринтов. Кто-то в классе подумал, что “планирование релиза” значило ежедневное планирование того, что мы будем выпускать в конце дня.

Возможно, пришло время изъять фразу “планирование релиза” из словарей Скрам и гибкой разработки. Но поймите меня правильно. Иметь возможность планировать на 3, 6 и 12 месяцев вперед до сих является основополагающим понятием для многих команд и Скрам-мастеров. Но сам по себе термин уже неточен. Нам нужен новый термин.

За последние несколько лет я пробовал использовать несколько различных терминов на моих Сертификационных классах для Скрам-мастеров. Мне не хочется называть это “долгосрочным планированием”. Может быть в современном мире "бережливых стартапов" (пл англ. lean startup), три месяца и можно назвать “долгосрочным планированием”, но мне, все же, и это кажется неверным. Я считаю, что термин “среднесрочное планирование” могло бы иметь право на жизнь.

Итак, техники остаются, но термины уже пережили себя.

Переведено с английского проектом Agile Translations.
Оригинальная статья: Release Planning: Retiring the Term but not the Technique.

Общепринятые практики работы с Беклогом Продукта

noreply@blogger.com (Alexey Krivitsky) — Sat, 16 Feb 2013 07:02:58 PST

Автор: Майк Кон (Mike Cohn)
Перевод с английского.

Последнее время я задавался вопросом – не подходит ли Скрам к тому моменту, когда в нем появится еще один митинг – Backlog Grooming Meeting (дословно “встреча по уходу за беклогом”). Потому как подобные встречи проводятся каждый спринт всё большим и большим количеством команд, чтобы убедиться, что беклог будет готов к следующему спринту.

Для того, чтобы понять почему Backlog Grooming Meeting всего в нескольких годах от того, чтобы стать общепринятой практикой Скрам, давайте вспомним начало 2000-ых годов.

Читать дальше >>>

Менеджер 2.0: роль менеджера в Скраме

noreply@blogger.com (Alexey Krivitsky) — Sat, 16 Feb 2013 07:02:47 PST

Автор: Пит Димер (Pete Deemer)
Перевод с английского.

Когда организация начинает использовать Скрам, поначалу часто возникает неудобный момент: кому – то начинает казаться, что роль «менеджера» полностью утрачивается. «Надо бы просто избавиться от них», острит какой-нибудь разработчик, и все менеджеры начинают беспокойно ерзать в своих креслах.

Скрам определяет только три роли: Владелец Продукта, Команда и Скрам-мастер, а главная инструкция для всех остальных в организации – «поддерживать их или убраться с дороги». Не слишком ясная формулировка, особенно если ваше начальство ожидает от вас, как старшего менеджера, что все складывается благополучно.

Читать дальше >>>

Agile Coach Camp: встреча 2013/1, с Andrea Provaglio

noreply@blogger.com (Lina Shishkina) — Thu, 24 Jan 2013 08:00:11 PST

Agile Coach Camp это встреча, на которой коллеги собираются что бы обменяться опытом внедрения гибких подходов, проработать новые идеи и практики повышения эффективности программной разработки.

Содержание кемпа представляет собой суммарный вклад его участников в программу - короткие доклады, воркшопы, отчеты об экспериментах, открытые вопросы и кейсы. В 2013-м году компания SCRUMguides планирует регулярно проводить такие встречи для аджайл коучей Украины, Беларуси, Молдовы и России. Первая встреча пройдет 1 февраля, с участием специального гостя - ключевого спикера конференции AgileBaseCamp, Andrea Provaglio.

Расписание: с 11:00 до 18:00. Стоимость: 550 грн.

Количество мест ограничено. Участие только для коллег с опытом аджайл коучинга команд.
Узнать детали и зарегистрироваться >>>

8-я конференция AgileBaseCamp: VALUE Driven Development, 2 февраля, Киев

noreply@blogger.com (Lina Shishkina) — Fri, 15 Feb 2013 06:36:29 PST

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

Что на этот раз в фокусе программы?

Do right things. Do things right. Do them fast.

Три ключевых постулата гибкой разработки начинаются с ценности. Ясное видение “правильного” продукта является мощным драйвером командной работы, технологической изобретательности и эффективных процессов.

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

Три категории докладов: "Drive VALUE", "Drive TECH" и "Drive TEAM" покроют темы продуктовых техник, инженерных практик и командной работы.

Что нового в формате конференции?

Традиционные доклады мы решили разбавить короткими флипчарт-сессиями c экспертами гибкой разработки. Кроме этого, вы сможете поучаствовать в одном их мастер-классов - на практические занятия выделен один из трех потоков программы.

Послеобеденный сон развеют бодрые короткие доклады в формате lightning talk, а вечернюю усталость как рукой снимет афтепати ;)

Когда регистрироваться?

Пока идет работа над программой (выступят Vasco Duarte, Алексей Кривицкий, Павел Габлиель, Наталья Тренина, Надежда Земскова, Артем Сердюк, Егор Назаркин, Дмитрий Миндра, Алексей Атемасов, Макс Климишин), самые ранние птички уже регистрируются!

Цены в 2013-м уже не будут такими низкими как в предновогодней суете :)

Получить билет по низкой цене>

Как следить за новостями?

Оставайтесь на связи в социальных сетях, приглашайте коллег и следите за обновлениями:

Видео-продукт “Эмоциональный Scrum”

noreply@blogger.com (Lina Shishkina) — Fri, 15 Feb 2013 06:35:26 PST

Полная версия статьи по сслылке

Разбираем техники и показываем, как их улучшать с точки зрения психологии

Мы создаем продукт для всех, кто работает или собирается работать по Scrum-у, чтобы понимать принципы и трюки управления людьми в Agile командах. Мы опираемся на опыт психологии и расширяем техники, которые использует Scrum. Слушатели научатся определять паттерны поведения участников Scrum-команды, попробуют новые психологические подходы и приемы. Мы разберем артефакты, встречи, принципы Scrum-а с точки зрения психологии. На основании этих знаний и примеров вы будете применять практики и артефакты с большей отдачей.

Цель продукта – добиться большего от команд, которые используют Scrum!

Об авторах:

Дмитрий Снисарь – практикующий психолог

Обеспечивает научную поддержку проекта
Психолог, тренер с 2004 года.
Автор блога Психология в ИТ – http://it-boost.com.
Специализация: гештальт психотерапия, транзактный анализ, позитивная психотерапия, синтез-технология, НЛП. За время практической деятельности обучил и помог 2000+ людям, в течении 2500+ тренинг-часов.

Дмитрий является главным научным редактором данного проекта и именно он подводит теоретическую основу (базу) под практики Scrum.

Сергей Бережной – практик Scrum и руководитель программ

Обеспечивает знание потребностей рынка и некоторые идеи
Тренер, консультант и практикующий руководитель проектов. Автор блога о работе с Заказчиками в ИТ – http://anotherpm.com.

Сергей является практиком Scrum-а на протяжении 5 лет и хорошо понимает проблемы Scrum-команд в аутсорсинге.

Владимир Железняк – практик Agile и руководитель проектов

Единственный трезвомыслящий в коллективе авторов

Владимир является практикующим тренером и практиком Scrum. Владимир специализируется на продуктовой разработке и работе в распределенных командах и стратапах.

Автор блога Психология в ИТ – http://it-boost.com.

Откуда мы знаем о проблемах со Scrum в реальных командах?

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

Маркетинг Scrum работает хорошо и менеджмент верит, что выполняя 20 простых правил можно сделать управление проектами на крутом уровне. Тот, кто попробовал «просто выполнять 20 правил», уже не столь оптимистичен. Поэтому на тренингах мы получаем много вопросов от тех, кто начал использовать Scrum и столкнулся с проблемами. Теория и практика оказались «двумя большими разницами»:

Менеджмент прекращает эксперименты и команды опять возвращаются к привычной модели разработки. Без всяких «вкусностей» гибких методологий.
Обвиняют инженеров в недостаточной квалификации. «Вы настолько тупые, что не можете делать хорошо 20 правил!»
Некогда учить, давай внедрять. После одной книги и двухдневного курса – ты ведущий специалист по Scrum в нашей компании. Добавили больше обязанностей, а времени – нет.
Scrum-мастер становится просто «секретарем команды» и его главная задача – «напоминать, чтобы подвигали задачи в таск-треккере». У него нет ни авторитета, ни признания.
Вторая попытка внедрить Scrum встречает бешеное сопротивление. «Мы (или кто-то до нас) пробовали внедрить Scrum и через пару итераций поняли, что это фигня и не то, что нам нужно»
Виновных находят очень быстро. Менеджеры среднего звена «вдруг» вспоминают, что все они с самого начала не верили в эту затею, и делают крайними именно тех, кто проявил инициативу и решил «не сидеть на попе ровно» (С).

Мы считаем, что многие проблемы со Scrum-ом связаны со слепым копированием этого процесса. Люди не понимают, почему это работает, а просто выполняют ритуал.

Мы не хотим, чтобы проблемы пришли к вам, поэтому создаем видео-курс «Эмоциональный Scrum».

Узнать детали и стоимость курса вы можете ЗДЕСЬ

Agile Pizza @ Kiev

noreply@blogger.com (Lina Shishkina) — Fri, 15 Feb 2013 06:36:38 PST

27 ноября AgileUkraine и SCRUMguides приглашают вас на встречу сообщества гибкой разработки в Киеве:

Agile Pizza с участием Алексея Кривицкого и других активных членов сообщества.

Вас ждут:

мини-доклады
ответы на вопросы
фасилитируемые дискуссии
неформальное общение и пицца

А также, в программе доклад Алексея Кривицкого "Новейшая история менеджмента. От эры стагнации к периоду ренессанса"!

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

Расписание:

19:00 - 21:00 Содержательная программа
21:00 - Соки, пицца, неформальное общение

Место проведения:
ул. Мельникова 83Д, 7 этаж
Как добраться: М. Лукьяновская, перейти на остановку маршруток со стороны завода «Артем»: маршрутки № 597, 558, 464, 439, 406; троллейбусы № 16, 19.

Со схемой проезда Вы можете ознакомиться по ссылке или посмотреть на карте.

Пицца-взнос: 50 грн.

Регистрация: по ссылке

До скорой встречи!

3-я встреча IT talk в Киеве

noreply@blogger.com (Lina Shishkina) — Fri, 15 Feb 2013 06:36:49 PST

3-я встреча IT-сообщества IT talk пройдет в Киеве в Национальном техническом университете Украины (КПИ) 19 ноября 2012 года.

Инициативная группа центра разработок компании DataArt в Киеве приглашает профессионалов, преподавателей, студентов и начинающих разработчиков на семинар, посвященный особенностям практического применения облачных вычислительных технологий.

В программе встречи:

• Антон Бойко, .NET-разработчик компании DataArt. Доклад «Тандем мобильных устройств и облачных технологий».
• Вячеслав Харченко, Анатолий Горбенко, Александр Белобородов,кафедра компьютерных систем и сетей, Центр гарантоспособных систем, сервисов и технологий Национального аэрокосмического университета им. Н.Е. Жуковского (ХАИ). Сообщение «Защита Web-приложений, развернутых в Cloud-среде, от информационных вторжений».

Участие во встречах IT talk — бесплатное.
Для участия требуется заявка на http://bit.ly/WbdkCr

Дата и время проведения:
Понедельник 19 ноября 2012 г., 18:30.
Место проведения:
Национальный технический университет Украины (КПИ), Политехническая ул., 14а, 3-й этаж, ауд. 97 учебного корпуса 15, вход из вестибюля корпуса приемной комиссии.

ScrumMaster's Survival Guide

noreply@blogger.com (Lina Shishkina) — Fri, 26 Oct 2012 06:28:10 PDT

Алексей Кривицкий, Certified ScrumTrainer и Agile-коуч компании SCRUMguides пишет книгу для Скрам-мастеров.

Цель этой книги

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

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

Надеемся, что эта книга станет хорошим поддерживающим материалом для участников сертификационных тренингов по программе Certified ScrumMaster.

Для кого эта книга?

Эта книга будет несомненно полезна:

Участникам Agile-проектов, которым выпала роль Скрам-мастеров и которые хотят разобраться в сути и функциях этой роли.
Участникам тренингов Certified ScrumMaster, которые пытаются применять тонну изученного материала в своих проектах для построения более гибких процессов.
Де факто Скрам-мастерам, которые помогают своим командам внедрить ценности гибкой разработки с помощью каркаса управления проектами Скрам и хотят улучшить или пересмотреть свои подходы.
Участникам Скрам-команд, которые хотят помочь друг другу, своим Скрам-мастерам и заказчикам сделать свой процесс легче, прозрачнее и эффективнее.

О чем эта книга не говорит?

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

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

Версия книги

Перед вами ранняя редакция книги. Первый инкремент большой работы. Нам очень нужна ваша обратная связь.

На сайте вы всегда можете оставить ваши комментарии и выкачать последний вариант. Здесь же появится полная версия книги с главами «Product Discovery» и«Product Delivery».

Вот такая потрясающая команда спикеров ожидает Вас на AGILEEE 2012

noreply@blogger.com (Lina Shishkina) — Fri, 15 Feb 2013 07:31:05 PST

AGILEEE всё ближе и ближе. Всего 6 недель отделяют нас от самого захватывающего и масштабного Agile события в Восточной Европе.

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

Итак, AGILEEE спешит сообщить Вам, что...

Между выступлениями на конференциях, Хенрик Книберг руководит тремя шведскими компаниями, где он занимает должность СTO. Он также широко известен, как книгоиздатель — Вы наверняка уже слышали о его работе Lean from the Trenches: Managing Large-Scale Projects with Kanban и переводах его книг "Scrum и Kanban: выжимаем максимум" и "Скрам и XP: заметки с передовой". Кроме того, в послужном списке Хенрика числится множество статей. Вот некоторые из его публикаций, с которыми Вам будет интересно ознакомиться: What to do when scrum doesn’t work и Управление версиями для нескольких Agile команд!

Стив Кайл является CEO двух влиятельных компаний Xentio и MammothDB. В прошлом же он руководил одной из крупнейших компаний по разработке программного обеспечения в Болгарии. Он выступил с воодушевляющим докладом на TED “A manifesto for play, for Bulgaria and beyond”, а также опубликовал целый ряд статей, интересных менеджерам IT компании (например, The Importance of Culture in Business).

Дэвид Хассман является штатным коучем в devjam.com. В 2009 году он стал обладателем Gordon Pask Award, а недавно совместно с The Pragmatic Bookshelf опубликовал видео-серию Cutting an Agile Groove. Материалы Дэвида также опубликованы в целом ряде книг (таких, как Managing Agile Projects) и озвучены на многих конференциях. А в одном из его интервью Вы можете узнать, как DevJam помогает организациям внедрять Agile.

Лисса Эдкинс основывает свою практику Agile коучинга на более чем 15 годах опыта проектного менеджмента. Её книга Coaching Agile Teams, получившая высокую оценку рецензентов, помогла многим командам изменить ход их мыслей. Многочсленные покасты, интервью и статьи Лиссы только подтверждают, что она делится своим опытом с большим удовольствием.

Майкл Спэйд, магистр психологии, главным делом своей жизни сделал коучинг различных команд — буть то некоммерческая организация, малый бизнес или компания из Fortune 500. Перед посещением его лекции мы советуем Вам ознакомиться с презентациями и статьями Майкла. Совместно с Лиссой Эдкинс Майкл уже выпускал материалы, как например статью The Manager’s Role in Agile, поэтому AGILEEE посчастливится стать свидетелями выступления их гармоничного дуэта.

Алистер Коуберн широко известен и уже успел стать одним из любимых спикеров AGILEEE. Подписчик Agile Manifesto & Declaration of Inter-dependence, автор книги Agile Software Development — все это Вы о нем уже слышали. Но Вам непременно стоит прочитать другие его книги и заглянуть на его вебсайт. В этом году игра от Алистера и мастер-класс Introduction to Advanced Agile Development однозначно сделают Вас фанатами Agile... или доктора Коуберна.

XP Days в Украине

noreply@blogger.com (Lina Shishkina) — Fri, 15 Feb 2013 07:30:41 PST

С 14 по 17 ноября тренинг-центр XP Injection организовывает в Киеве конференцию XP Days Ukraine, целиком посвященную Agile инженерным практикам. XP Days Ukraine – это больше чем просто конференция. Мы планируем организовать масштабное мероприятие длительностью несколько дней. Первые два дня (14-15 ноября) будут насыщены разнообразными тренингами, мастер-классами и встречами. Следующие два дня (16-17 ноября) будут отведены для докладов, открытых дискуссий и выступлений в формате lighting talks.

Подобные мероприятия уже давно проходят в других странах и пользуются большим успехом. В Украине XP Days впервые прошли в декабре 2011 года и собрали более 300 участников из 8 стран. И это не случайно – ведь у вас появляется возможность не только послушать доклады от ведущих специалистов направления, но и принять участие в нескольких практических тренингах или мастер-классах.

На конференции будут освещены основные инженерные практики: Unit Testing, TDD, Continuous Integration, BDD, Code Review, Refactoring, Acceptance Testing и другие. Также будут обсуждаться вопросы архитектуры в Agile проектах и борьбы с технической задолженностью (Technical Debt).

На данный момент мы получили подтверждение об участии в качестве докладчиков не только от украинских и российских специалистов, но и от всемирно известных специалистов в области разработки программного обеспечения: John Smart (автор open-source BDD библиотеки Thucydides), Simon Brown (автор книги «Software Architecture for Developers»), Johannes Brodwall (XP-евангелист) и David Evans (эксперт в области agile тестирования). Наша программа пополняется каждый день, более детальную информацию вы сможете найти на нашем сайте

Участие в конференции будет платным, но мы приложим максимум усилий, чтобы стоимость была минимальной и не составила проблем для большей части желающих посетить конференцию. Количество участников конференции будет ограничено (не более 400 человек). Более 100 участников успели зарегистрироваться на этапе ранней регистрации. На данный момент действует этап основной регистрации по цене 1400 гривен. Указанная цена действует только при регистрации и оплате участия до 1 октября.

Также мы приглашаем докладчиков, имеющих большой практический опыт в применении Agile инженерных практик, принять участие в конференции. Если вы чувствуете в себе силы и желание поделиться опытом с другими, то присылайте нам свое предложение о выступлении. Предложения принимаются до 1 октября.

Присоединяйтесь, будет интересно!

First Agile Breakfast в Житомире

noreply@blogger.com (Lina Shishkina) — Wed, 08 Aug 2012 09:29:13 PDT

Мы собираемся для того чтобы поговорить на темы:

чем Agile отличается от не-Agile
управление продуктом в Agile
отношения с заказчиком
внедрение гибких процессов разработки
бережливая разработка
продажа Agile/Scrum

Подробности и регистрация>>>

Backlog Grooming и Definition of Ready: как привнести поток в процесс подготовки беклога

noreply@blogger.com (Alexey Krivitsky) — Sat, 26 Jan 2013 14:50:45 PST

Автор: Алексей Кривицкий, CST

Семь лет назад, когда я запускал свой первый Скрам-проект (Ciklum, проект Encode, 2004 год) мы не знали, что такое груминг.

Заказчик созванивался с нами для планирования спринта... и тут начиналось: мы задавали глупые вопросы, заказчик куда-то убегал за ответами, с кем-то советовался и менял приоритеты, мы воевали с картами за стори-поинты, били истории на задачи... Планирование спринта у нас редко занимало меньше 8 часов.

Читать дальше

Принять участие в обсуждении практик груминга на форуме AgileUkraine.

Программа Agile Pizza @ Odessa

noreply@blogger.com (Lina Shishkina) — Fri, 15 Feb 2013 07:30:23 PST

Мы приготовили для вас программу мероприятия!

16:45 - 17:00 Полуденный кофе-чай и встреча гостей
17:00 - 17:10 Приветствие участников и благодарности партнерам
17:10 - 17:30 Знакомство и выбор тем для дискуссий

17:30 - 18:00 Блиц-доклады от SCRUMguides

18:00 - 18:30 Кофе, ПИЦЦА и свободное общение
18:30 - 19:30 Блиц-доклады и ответы на вопросы
19:30 - 20:30 Дискуссии участников (Speed Geeking / World Cafe)
20:30 - 21:00 Закрытие, свободное общение

Среди спикеров блиц-докладов, на текущий момент:

Алексей Кривицкий
Наталья Тренина
Михаил Завилейский
Вы можете подать заявку

Agile Pizza @ Kharkov

noreply@blogger.com (Lina Shishkina) — Wed, 27 Jun 2012 07:38:27 PDT

SCRUMguides приглашает вас на пица-вечер, посвященный вопросам гибкой разработки "Agile Pizza" с участием Алексея Кривицкого и Натальи Трениной.

Расписание:
19:00 - 21:00 Содержательная программа
21:00 - Пиво, пицца и неформальное общение

ОТКРЫТА РЕГИСТРАЦИЯ >

Адрес встречи мы сообщим участникам после регистрации.
Взнос за мероприятие 100 грн., оплата на месте.

По вопросам партнерства обращайтесь по адресу info@scrumguides.com

Agile Pizza @ Odessa

noreply@blogger.com (Lina Shishkina) — Mon, 02 Jul 2012 05:43:03 PDT

AgileUkraine приглашает вас на первую встречу сообщества гибкой разработки в Одессе:

Agile Pizza с участием Алексея Кривицкого, Натальи Трениной и других активных членов сообщества.

Вас ждут:

мини-доклады
ответы на вопросы
фасилитируемые дискуссии
неформальное общение и пицца

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

Расписание:

17:00 - 20:00 Содержательная программа
20:00 - Пиво, море, неформальное общение

Пицца-взнос: 50 грн, оплата на месте.

ОТКРЫТА РЕГИСТРАЦИЯ>>>

Мероприятие пройдет при поддержке:

	компании Lohika Systems
	компании AB Soft
	компании DataArt

Огромное спасибо нашим партнерам и друзьям!

Место проведения:
Академия "Шаг",
г. Одесса, ул. Еврейская, 3

До скорой встречи в солнечной Одессе!