Спасибо всем, кто пришёл в клуб 30 октября.
Особенное спасибо Артёму Сердюку за полезнейший воркшоп о поиске истинных причин.
Ссылка на фото-альбом
А вот, кстати, и материалы:
Finding Root Causes
View SlideShare presentation or Upload your own.
2008/10/31
Agile club: Finding root causes
Автор: Алексей Кривицкий.
Спасибо всем, кто пришёл в клуб 30 октября.
Особенное спасибо Артёму Сердюку за полезнейший воркшоп о поиске истинных причин.
Ссылка на фото-альбом
А вот, кстати, и материалы:
Спасибо всем, кто пришёл в клуб 30 октября.
Особенное спасибо Артёму Сердюку за полезнейший воркшоп о поиске истинных причин.
Ссылка на фото-альбом
А вот, кстати, и материалы:
2008/10/28
Agile club: Инструменты поиска причин
Автор: Кривицкий.
Agile клуб
Четверг 30 октября.
Тематический вечер Инструменты поиска причин
Читайте пост Артёма касательно инструментов, которые будут рассматриваться на воркшопе.
Начало в 19:00.
Воркшоп проводит Артём Сердюк.
План приблизительно такой:
1) связь agile, user stories и Голдратта - 20 мин
2) дерево текущей реальности (ДТР) - теория (15 мин)
3) ДТР - практика (30 минут)
перерыв - 10 мин
4) критерии проверки логических построений (КПЛП) - теория (10 мин)
5) КПЛП - практика (20 мин)
5) диаграмма решения конфликта (ДРК) - теория (15 мин)
6) ДРК - практика (30 мин)
Благодаря компании GlobalLogic, место проведения остаётся неизменно: Киев, ул. Боженко, 86д ссылка на карту
Agile клуб
Четверг 30 октября.
Тематический вечер Инструменты поиска причин
Читайте пост Артёма касательно инструментов, которые будут рассматриваться на воркшопе.
Начало в 19:00.
Воркшоп проводит Артём Сердюк.
План приблизительно такой:
1) связь agile, user stories и Голдратта - 20 мин
2) дерево текущей реальности (ДТР) - теория (15 мин)
3) ДТР - практика (30 минут)
перерыв - 10 мин
4) критерии проверки логических построений (КПЛП) - теория (10 мин)
5) КПЛП - практика (20 мин)
5) диаграмма решения конфликта (ДРК) - теория (15 мин)
6) ДРК - практика (30 мин)
Благодаря компании GlobalLogic, место проведения остаётся неизменно: Киев, ул. Боженко, 86д ссылка на карту
2008/10/27
Эффективный Product Owner. Поиски ответов
Автор: Алексей Кривицкий.
В течение последних дней в нашей группе дискуссий велось активное обсуждение роли Product Owner-а (для краткости "PO"). Мы пытались найти ответы на такие непростые вопросы:
Здесь вы можете ознакомиться с полной историей этой дискуссии и, кстати (!), принять в ней участие.
Удачных дискуссий!
В течение последних дней в нашей группе дискуссий велось активное обсуждение роли Product Owner-а (для краткости "PO"). Мы пытались найти ответы на такие непростые вопросы:
- кто же такой эффективный Product Owner;
- каковыми навыками он должен обладать;
- чем его роль отличается от традиционных ролей Product Mananger-а, Project Manager-а, аналитика.
Здесь вы можете ознакомиться с полной историей этой дискуссии и, кстати (!), принять в ней участие.
Критерии хорошего PO:
- знать, что конечные пользователи хотят от системы
- уметь донести понимание системы до команды
- понимать приоритеты этих вещей
- не путать требования и реализацию
- быть доступным для команды и достаточно мотивированным, что бы давать квалифицированные ответы
- не делегировать полномочия людям, которые не удовлетворяют перечисленным выше пяти качествам или не расходятся во мнении с ним
- уметь всё это проверить
Для меня и некоторых моих знакомых PO в проекте - один из главных критериев при выборе работы.
(Evgeny Kompaniyets)
(Evgeny Kompaniyets)
Если же в общих чертах, по для меня хороший Product Owner - это прежде всего человек понимающий в бизнес причинах и приоритетах проекта и умеющий говорить об этом с командой.
Идеальный Product Owner - это, разумеется, сам клиент имеющий понятие о программировании в данной предметной области, вежливый, болеющий за дело, не боящийся признавать ответственность и ошибки и имеющий время на всё то, что перечислил Борис.
(Artem Marchenko)
Идеальный Product Owner - это, разумеется, сам клиент имеющий понятие о программировании в данной предметной области, вежливый, болеющий за дело, не боящийся признавать ответственность и ошибки и имеющий время на всё то, что перечислил Борис.
(Artem Marchenko)
У нас был человек на голландской стороне, который был совершенно невыносим в качестве Продакт менеджера. Он предлагал технические решения, постоянно менял планы, задавал идиотские вопросы, не отвечал
на письма, лез не в своё дело и т.п. Сейчас он - лучший Продакт оунер из всех, кто работает с украинскими командами. Смотря на него, я вижу вот такие критерии "хорошести":
на письма, лез не в своё дело и т.п. Сейчас он - лучший Продакт оунер из всех, кто работает с украинскими командами. Смотря на него, я вижу вот такие критерии "хорошести":
- РО должен отвечать хоть чем-то за результат проекта. Коммитмент приложится.
- РО обязательно кто-то должен обучить и поддерживать. В нашем случае Маурисом занялись лично Chief Technological и Chief Informational компании. После двух месяцев муштры глупые вопросы сошли на нет.
- РО должен хорошо относиться к команде разработке и обязательно быть лично с ними знакомым. После визита "ужасного Мауриса" в Украину, когда он лично познакомился с командой (и понял какие же мы классные )). Ну и народу здесь тоже стало понятно, что он - вполне вменяемый чувак. После этого общение поменялось кардинально в лучшую сторону.
- РО должен быть толковым. Остальное наберётся автоматом.
Важнейшая ценность PO: уметь отказываться от ненужных фич.
(Evgeny Kompaniyets)
(Evgeny Kompaniyets)
В идеале, конечно, Product Manager - это голос клиента - человек знающий потребности рынка, способный выделить нерешённые проблемы конкретного сегмента рынка, определить какие из них именно его фирма может удовлетворить лучше конкурентов и умеющий говорить обо всём этом с топ-менеджментом и хотя бы с начальником инженеров. Но это - идеальный и редко встречающийся в природе случай.
(Artem Marchenko)
(Artem Marchenko)
Удачных дискуссий!
2008/10/25
User Stories as a thinking tool
Автор: Алексей Кривицкий.
Сегодня, благодаря книге Майка Кона и куче статей, термин user stories (по-русски "пользовательские истории" или просто "истории") стал насколько популярен, что его стали использовать повсеместно, заменяя им такие привычные нашему уху термины как "требование", "фича", "задача", и прочее.
Это, без сомнений, подчёркивает то, что Agile прочно входит в наши дома (офисы), укоряняется в наших умах (и, дай Бог, в умах наших менеджеров и заказчиков). Становится неотъемлемой частью профессии, гордо именуемой "разработчик программного обеспечения" (читать без иронии и сарказма).
Но тут есть ряд "но", на которых я бы хотел заострить внимание тех, кому приходится писать истории, обучать своих заказчиков этой технике либо просто иметь с ними дело в повседневной проф. жизни.
Давайте рассмотрим пример. Предположим, что речь идёт о системе аналогичной Gooogle Сalendar, где пользователи могут управлять своими событиями.
Есть такое требование:
Имея сноровку, это требование можно довольно быстро привести к виду историй, который пропагандирует Майк Кон: As as a [user], I can [do], so that [value]:
Вопрос в следующем. Является ли описанная история настоящей историей?
Формально - да. Формат и размер делают ещё очень схожей с тем, что называют user stories. Но тут есть один важный ньюнс.
Давайте рассмотрим другую историю:
Так что же пользователю нужно на самом деле?
(Заказчик): Знать своё расписание.
(Мы): Зачем?
(Заказчик): Затем, чтобы видеть все спланированные события наперёд.
(Мы): Зачем нужно видеть спланированные события наперёд?
(Заказчик): Затем, чтобы не пропускать события или заблаговременно измененять свои планы, не подводя других людей.
(Мы): Зачем это нужно?
(Заказчик): Ну, так ведут себя серьёзные и деловые люди!
(Мы): Ага!!
Значит цель пользователя на самом деле является: а) не пропускать свои события; б) иметь возможность заблаговременно изменять свои планы:
- Так чем же отличается эта история от приведённого сначала требования и двух других историй?
- Она описывает проблему, а не решение.
- И что эта так важно?
- О да! Говоря о проблеме, мы склонны совместно с профессионалами предметной области найти более интересные решения, о которых мы сначала даже и не подозревали. Более креативные и свежие решения. Так зачем себя ограничивать, выбирая изначально всего лишь один вариант решения проблемы?
Встаёт более философский вопрос. А что если проблему можно будет решить вообще без программного обеспечения? Разве это так уж и плохо?
В принципе, нет. Ведь наша задача - помогать решать проблемы наших заказчиков (клиентов, пользователей).
Итог
Когда вы пишите истории, пытайтесь найти проблему, которую вы намерены решить. Опишите её в истории. Если вы догадываетесь на фазе написания истории о хорошем способе её решения (к примеру отсылать email с расписание), допишите это явно ("как вариант решения ...")в истории, но отдельно от поставленной проблемы.
Если к вам приходят истории, написанные вашими заказчиками, бизнес аналитиками или ещё кем-то, потратьте время, поговорив с ним и найдя проблему. Они вам за это будут благодарны, поверьте. Five Whys (техника "пяти почему"), которую я продемонстрировал выше, почти всегда даст вам нужный результат. Главное объяснить, что вы задаёте глупые вопросы не потому что вы глупы :)
Старайтесь выделять проблемы из решений. Храните их и управляйте ими отдельно. В Скраме для складирования проблем служит Product Backlog, для управления решениями - Sprint Backlog.
Побочные эффекты
Описание проблем обычно намного компактнее, чем описание возможных решений. Эта одна из причин, по которой в Agile проектах входной документации намного меньше, чем в традиционных проектах.
--------
Удач! Не бойтесь экспериментировать и пробовать новое.
"Anyone who has never made a mistake has never tried anything new" (Einstein)
Сегодня, благодаря книге Майка Кона и куче статей, термин user stories (по-русски "пользовательские истории" или просто "истории") стал насколько популярен, что его стали использовать повсеместно, заменяя им такие привычные нашему уху термины как "требование", "фича", "задача", и прочее.
Это, без сомнений, подчёркивает то, что Agile прочно входит в наши дома (офисы), укоряняется в наших умах (и, дай Бог, в умах наших менеджеров и заказчиков). Становится неотъемлемой частью профессии, гордо именуемой "разработчик программного обеспечения" (читать без иронии и сарказма).
Но тут есть ряд "но", на которых я бы хотел заострить внимание тех, кому приходится писать истории, обучать своих заказчиков этой технике либо просто иметь с ними дело в повседневной проф. жизни.
Давайте рассмотрим пример. Предположим, что речь идёт о системе аналогичной Gooogle Сalendar, где пользователи могут управлять своими событиями.
Есть такое требование:
- Система должна предоставлять возможность отображения событий календаря пользователя в виде списка, отсортированного по времени (по возрастанию). Отображаемые данные каждого события должны содержать краткое описание события, место, дату и время начала, длительность.
Имея сноровку, это требование можно довольно быстро привести к виду историй, который пропагандирует Майк Кон: As as a [user], I can [do], so that [value]:
- Как владелец календаря, я могу просмотреть события своего календаря в виде списка, отсортированного по времени (по возрастанию) с тем, чтобы знать своё расписание.
Детали: Отображаемые данные должны содержать краткое описание события, место, дату и время начала, длительность.
Вопрос в следующем. Является ли описанная история настоящей историей?
Формально - да. Формат и размер делают ещё очень схожей с тем, что называют user stories. Но тут есть один важный ньюнс.
Давайте рассмотрим другую историю:
- Как владелец календаря, я могу получать расписание своих событий по электронной почте с тем, чтобы знать своё расписание.
Детали: Отображаемые данные должны содержать краткое описание события, место, дату и время начала, длительность.
Так что же пользователю нужно на самом деле?
(Заказчик): Знать своё расписание.
(Мы): Зачем?
(Заказчик): Затем, чтобы видеть все спланированные события наперёд.
(Мы): Зачем нужно видеть спланированные события наперёд?
(Заказчик): Затем, чтобы не пропускать события или заблаговременно измененять свои планы, не подводя других людей.
(Мы): Зачем это нужно?
(Заказчик): Ну, так ведут себя серьёзные и деловые люди!
(Мы): Ага!!
Значит цель пользователя на самом деле является: а) не пропускать свои события; б) иметь возможность заблаговременно изменять свои планы:
- Как пользователь, я хочу не пропускать свои события и иметь возможность заблаговременно изменять свои планы.
- Так чем же отличается эта история от приведённого сначала требования и двух других историй?
- Она описывает проблему, а не решение.
- И что эта так важно?
- О да! Говоря о проблеме, мы склонны совместно с профессионалами предметной области найти более интересные решения, о которых мы сначала даже и не подозревали. Более креативные и свежие решения. Так зачем себя ограничивать, выбирая изначально всего лишь один вариант решения проблемы?
Встаёт более философский вопрос. А что если проблему можно будет решить вообще без программного обеспечения? Разве это так уж и плохо?
В принципе, нет. Ведь наша задача - помогать решать проблемы наших заказчиков (клиентов, пользователей).
Итог
Когда вы пишите истории, пытайтесь найти проблему, которую вы намерены решить. Опишите её в истории. Если вы догадываетесь на фазе написания истории о хорошем способе её решения (к примеру отсылать email с расписание), допишите это явно ("как вариант решения ...")в истории, но отдельно от поставленной проблемы.
Если к вам приходят истории, написанные вашими заказчиками, бизнес аналитиками или ещё кем-то, потратьте время, поговорив с ним и найдя проблему. Они вам за это будут благодарны, поверьте. Five Whys (техника "пяти почему"), которую я продемонстрировал выше, почти всегда даст вам нужный результат. Главное объяснить, что вы задаёте глупые вопросы не потому что вы глупы :)
Старайтесь выделять проблемы из решений. Храните их и управляйте ими отдельно. В Скраме для складирования проблем служит Product Backlog, для управления решениями - Sprint Backlog.
Побочные эффекты
Описание проблем обычно намного компактнее, чем описание возможных решений. Эта одна из причин, по которой в Agile проектах входной документации намного меньше, чем в традиционных проектах.
--------
Удач! Не бойтесь экспериментировать и пробовать новое.
"Anyone who has never made a mistake has never tried anything new" (Einstein)
Семинар "Тестирование в Agile проектах"
Автор: Алексей Кривицкий.
Семинар Тестирование в Agile проектах.
Дата: 31 октября, 10:00 - 12:30.
Место проведения: Киев, офис Люксофта.
Инструктор: Ярыныч Виталий.
Стоимость: 260 грн.
Длительность: 2 часа.
Перейти к деталям
Семинар Тестирование в Agile проектах.
Дата: 31 октября, 10:00 - 12:30.
Место проведения: Киев, офис Люксофта.
Инструктор: Ярыныч Виталий.
Стоимость: 260 грн.
Длительность: 2 часа.
Перейти к деталям
2008/10/23
Scrum Alliance и локальные группы
Автор: Алексей Кривицкий.
На конференции Scrum Gathering в Стокгольме Кен Швабер, со-отец Скрама и со-основатель организации ScrumAlliance (которая и проводила конференцию) рассказал стратегические планы их организации.
Самой основной целью они ставят перед собой популяризацию Скрама через развитие локальных групп (таких как мы, Agile Ukraine). Так что, я надеюсь, уже ближайшие конференции пройдут при посильной помощи всемирного Скрам-сообщества. Ура.
Но это ещё не всё!
На конференции мне удалось познакомиться с рядом представителей восточно-европейского мира (Польша, Болгария, Латвия), которые выразили однозначную заинтересованность в совместной деятельности. У нас с ними очень много общего, начиная от культурных особенностей и заканчивая текущей фокусировкой рынка на оффшорную разработку.
И начало уже положено:
На конференции Scrum Gathering в Стокгольме Кен Швабер, со-отец Скрама и со-основатель организации ScrumAlliance (которая и проводила конференцию) рассказал стратегические планы их организации.
Самой основной целью они ставят перед собой популяризацию Скрама через развитие локальных групп (таких как мы, Agile Ukraine). Так что, я надеюсь, уже ближайшие конференции пройдут при посильной помощи всемирного Скрам-сообщества. Ура.
Но это ещё не всё!
На конференции мне удалось познакомиться с рядом представителей восточно-европейского мира (Польша, Болгария, Латвия), которые выразили однозначную заинтересованность в совместной деятельности. У нас с ними очень много общего, начиная от культурных особенностей и заканчивая текущей фокусировкой рынка на оффшорную разработку.
И начало уже положено:
- запущена группа на LinkedIn - Eastern European Agile/Scrum user group
- зарезервированно доменное имя: http://www.agileee.org/
2008/10/21
Scrum Gathering Stockholm
Автор: Алексей Кривицкий.
По случаю судьбы мне повезло оказаться на Scrum Gathering 2008 в Стокгольме. Более того, меня попросили блоггить свои впечатления для сообщества.
Не уверен, что мой английский на том уровне, чтоб писать блог для всемирного сообщества. Но деваться уже некуда. Благо, есть ещё англоязычная барышня-блоггер.
Перейти на блог конференции.
По случаю судьбы мне повезло оказаться на Scrum Gathering 2008 в Стокгольме. Более того, меня попросили блоггить свои впечатления для сообщества.
Не уверен, что мой английский на том уровне, чтоб писать блог для всемирного сообщества. Но деваться уже некуда. Благо, есть ещё англоязычная барышня-блоггер.
Перейти на блог конференции.
Круглый стол - Agile: исскуство достижения бизнес-целей
Автор: Алексей Кривицкий.
Круглый стол - Agile: исскуство достижения бизнес-целей
29 октября в Киеве пройдёт круглый стол – Agile: исскуство достижения бизнес-целей.
На данном мероприятии речь пойдёт о достижении бизнес-целей софтверного продукта, как об основном показателе успеха команды разработчиков.
В понимании современного процесса разработки образовался серьезный пробел. Как разрабатывать юнит-тесты, рефакторить код, проводить скрам митинги - стало ключевым фокусом большинства евангелистов гибкой методологии. В то же время множество проектов терпит провал, еще больше находятся в нестабильном положении, а команды разработчиков даже не подозревают о настоящей причине их проблем.
На базе нашего многолетнего успешного опыта разработки продуктов для компаний Слилконовой Долины мы поделимся практическими советами, дающими возможность команде создавать и поддерживать конкурентоспособный продукт.
Не обойдется без неожиданных сюрпризов. Один из примеров состоит в том, что успех команды только на пятую часть зависит от умения писать код... Мы обязательно поговорим об остальных составляющих и дополним картину успеха на нашей встрече.
Дата проведения – 29.10.2008г.
Время проведения – 16.00-19.00
Место проведения – ул. Дегтярёвская, 62
Участие в мероприятии бесплатное!
Для регистрации на интересующий Вас Круглый стол отправьте письмо по адресу: education-kiev@luxoft.com
Круглый стол - Agile: исскуство достижения бизнес-целей
29 октября в Киеве пройдёт круглый стол – Agile: исскуство достижения бизнес-целей.
На данном мероприятии речь пойдёт о достижении бизнес-целей софтверного продукта, как об основном показателе успеха команды разработчиков.
В понимании современного процесса разработки образовался серьезный пробел. Как разрабатывать юнит-тесты, рефакторить код, проводить скрам митинги - стало ключевым фокусом большинства евангелистов гибкой методологии. В то же время множество проектов терпит провал, еще больше находятся в нестабильном положении, а команды разработчиков даже не подозревают о настоящей причине их проблем.
На базе нашего многолетнего успешного опыта разработки продуктов для компаний Слилконовой Долины мы поделимся практическими советами, дающими возможность команде создавать и поддерживать конкурентоспособный продукт.
Не обойдется без неожиданных сюрпризов. Один из примеров состоит в том, что успех команды только на пятую часть зависит от умения писать код... Мы обязательно поговорим об остальных составляющих и дополним картину успеха на нашей встрече.
Дата проведения – 29.10.2008г.
Время проведения – 16.00-19.00
Место проведения – ул. Дегтярёвская, 62
Участие в мероприятии бесплатное!
Для регистрации на интересующий Вас Круглый стол отправьте письмо по адресу: education-kiev@luxoft.com
2008/10/13
Agile Gathering VI: report
Автор: Алексей Кривицкий.
Шестая конференция Agile Gathering прошла успешно. Как по мне - это лучшая встреча: такого количества докладчиков, посетителей и пирожков ещё не было :)
Ссылка на фотоальбом
Спасибо за фотки Борису Лебеде и Надежде Плаховой
Седьмая встреча будет ещё лучше, благодаря вашим отзывам и комментариям.
Ждём фоторепортажей и блог-отзывов, присылайте их, добавляя комменты к этому посту.
Ниже приводятся шесть докладов. Доклад Робина будет выложен отдельным постом, как только будет получен.
Ещё раз спасибо партнёрам: AgileAlliance, EPAM, SoftLine, Ciklum, Luxoft, GlobalLogic, SCRUMguides, Mountain Goat Software, JetBrains.
Шестая конференция Agile Gathering прошла успешно. Как по мне - это лучшая встреча: такого количества докладчиков, посетителей и пирожков ещё не было :)
Ссылка на фотоальбом
Спасибо за фотки Борису Лебеде и Надежде Плаховой
Седьмая встреча будет ещё лучше, благодаря вашим отзывам и комментариям.
Ждём фоторепортажей и блог-отзывов, присылайте их, добавляя комменты к этому посту.
Ниже приводятся шесть докладов. Доклад Робина будет выложен отдельным постом, как только будет получен.
Ещё раз спасибо партнёрам: AgileAlliance, EPAM, SoftLine, Ciklum, Luxoft, GlobalLogic, SCRUMguides, Mountain Goat Software, JetBrains.
2008/10/08
Agile club - agile and fixed contracts
Автор: Алексей Кривицкий
Ближайшая встреча в Agile клубе состоится 9 октября.
Тема встречи "Agile and fixed contracts"
Начало как обычно 19:00
Благодаря компании GlobalLogic, место проведения остаётся неизменно: Киев, ул. Боженко, 86д ссылка на карту
До скорого!
Ближайшая встреча в Agile клубе состоится 9 октября.
Тема встречи "Agile and fixed contracts"
Начало как обычно 19:00
Благодаря компании GlobalLogic, место проведения остаётся неизменно: Киев, ул. Боженко, 86д ссылка на карту
До скорого!
2008/10/02
Agile Gathering Kharkov
Автор: Алексей Кривицкий.
Выложили видео с харьковской конференции. Спасибо TeamDev и всем, кто помогал снимать, нарезать и выкладывать!
Теперь есть полный комплект: фото, видео и презентации.
Enjoy!
Выложили видео с харьковской конференции. Спасибо TeamDev и всем, кто помогал снимать, нарезать и выкладывать!
Теперь есть полный комплект: фото, видео и презентации.
Enjoy!
Subscribe to:
Posts (Atom)