This version of the page http://tim.com.ua/ (0.0.0.0) stored by archive.org.ua. It represents a snapshot of the page as of 2012-11-02. The original page over time could change.
Обучение Agile управлению проектами, Scrum методологии, Agile управлению требованиями, организации командной работы, тренинги, командный коучинг

Мифическая роль Владельца Продукта (Product Owner)

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

Если говорить метафорами, то Scrum команда — это мощный (или не очень ) автомобиль, и то, как быстро он едет, напрямую зависит от опыта водителя — Владельца Продукта.

Как мы знаем, водить многие учатся, где попало и как попало, поэтому так и ездят управляют проектами. Работая со своими клиентами, я видел много примеров того, как исполняется роль Product Owner, и постоянно обдумываю, как объяснить эту роль, когда готовлюсь к своим тренингам по Agile управлению проектами. Что интересно, многие мысли все больше и больше подтверждаются практикой.

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

Различия людей на службе решения конфликтов

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

Уже писано-переписано бесконечное множество статей, и все же проблема остается достаточно актуальной.

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

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

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

Почему недельная длина Спринта хуже, чем двухнедельная

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

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

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

«Раскрась свой Бэклог!» или о чем я рассказывал на Agile Eastern Europe

На прошедшей недавно конференции Agile Eastern Europe, я решил поддержать рускоязычную сцену и выступил с докладом «Раскрась свой Бэклог! или о том, как принимать решения на основе разных типов элементов бэклога».

Ниже под катом находится слайдкаст моего выступления — те, кто не смог присутствовать, могут и посмотреть и послушать.

Сама идея того, что в Бэклоге Продукта могут быть разные типы элементов, очень быстро приходит к тем, кто начинает практиковать Scrum или другую Agile методологию. Ведь Бэклог — это и инструмент взаимодействия с внешним миром, и инструмент планирования на разных уровнях. Достаточно быстро становится очевидным, что туда должно попадать все, на что нужно инвестировать время команды, чтобы получить в результате рабочий продукт.

Что же вы положите в Бэклог и, на что это повлияет?

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

XP PechaKucha в рамках XP Days Ukraine

Мы решили провести XP PechaKucha «Все про инженерные практики разработки программного обеспечения» как еще одно отдельное мероприятие в рамках XP Days Украина, которые будут проходить с 14 по 17 ноября в Киеве.

За день до основной конференции, вечером, в неформальной, по-настоящему печакучистой обстановке пройдет XP PechaKucha. Эта встреча состоится 15 ноября в 19-00 в одном из заведений Киева, где мы надеемся услышать различные истории на тему Agile инженерных практик разработки программного обеспечения.

Если вы хотите стать частью этого мероприятия, зарегистрируйте свой рассказ!

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

Мне не нужно техзадание… мне нужно нечто большее

Ты кто такой давай техзадание,
Ты кто такой давай техзадание,
Ты кто такой давай техзадание…

Он с тобой все обсудить попытается,
Отчет, аудит всучить пытается.
Знаешь где реальный дело начинается?
Только там где ТЗ появляется.

А теперь товарищи, внимание -
Нету ТЗ — давай до свидания!

Гай Карапетян

Когда-то более десяти лет назад я, еще молодой тогда менеджер, хотя опытный разработчик, поехал к датчанам получать новый проект. И я получил ЕГО — техзадание.

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

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

Какую проблему решает буфер времени при планировании итерации

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

Действительно, любой здравомыслящий человек, прежде чем применять новый подход, должен задаваться вопросом: «Какую проблему я решаю?».

Итак, какую проблему мы решаем с помощью буфера времени? Моя статья была навеяна проблемой планирования итерации, которую я обсуждал со своими клиентами. Вы наверное видели ниспадающие (burndown) графики в Cпринте, вроде этого:

или этого:

Они говорят о том, что команда планирует больше, чем реально может сделать. Это может происходить из-за того,

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

Когда подстилать соломку или планирование Спринта с учетом вашей реальности

Когда-то, я писал о Разноцветном Бэклоге, т.е. о применении идеи цветовых маркировок для разных типов элементов Бэклога. Да-да, не удивляйтесь, Бэклог Продукта может содержать элементы разного типа — это иногда оказывается «новостью» для тех, кто только начинает практиковать Scrum и прочел только несколько статей или короткую книжку Одна только работа с Бэклогом содержит много нюансов, о которых я рассказывал во время онлайн курса или уже неоднократно писал. Так что если вы хотите больше узнать, то почитайте мои статьи на эту тему.

Другой вопрос, который я получаю сразу после того, как читатели, или слушатели тренинга, разобрались с идеей разных элементов Бэклога: «Как их учитывать при планировании Спринтов или целых выпусков?». Иногда просто так и спрашивают: «Как оптимально планировать итерацию?». Ответ прост, как и все из того, что применяется в Agile методах и о чем я рассказываю в этом блоге. 

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

Интересные события этой осенью

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

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

О взятых на себя обязательствах или стоит ли изменять план Спринта

Моя прошлая статья про «вред наказания за ошибки» помогла мне самому разобраться с одним интересным вопросом, который мне часто задают. Вопрос озвучивается по разному, например: «Что делать, если команда видит, что не успевает сделать все, что запланировала в спринте?» или иногда вот так «Что делать, когда наш график оставшейся работы (Burndown) выше идеальной линии?». Вариантов вопроса может быть много, хотя по сути все сводится к тому, что делать, если команда не может выполнить взятые на себя обязательства.

Допустим, в начале спринта вы честно планировали, исходя из своих возможностей, и делали максимально реалистичный план. А потом все пошло как-то не так – в разработке ПО такое часто случается . Обычно, вы увидите это на графике оставшейся работы, когда он покажет, что у вас осталось больше, чем вы можете сделать. И вот тут-то наступает самый интересный момент – что делать команде?

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