Что делать в ситуации, когда несколько команд работают над одним проектом или продуктом? Возникают зависимости. Мы рассмотрим как ими можно управлять и как повысить общую эффективность процесса.
Выступление на коференции AgileDays'15 20 марта
Что делать в ситуации, когда несколько команд работают над одним проектом или продуктом? Возникают зависимости. Мы рассмотрим как ими можно управлять и как повысить общую эффективность процесса.
Выступление на коференции AgileDays'15 20 марта
В начале 2011го года компания Skype купила небольшой стартап под названием Qik. На тот момент в компании Skype был официальный процесс на базе SCRUM. Вышло так, что после перехода на этот процесс, команда Qik сильно потеряла в скорости поставки. В своём докладе я расскажу, что именно произошло, и как следование правилам Scrum мешало команде быстро и качественно разрабатывать свой продукт.
Денис Тучин - Болезни Agile ретроспектив и как их лечить (2016 AgileTour.By)Denis Tuchin
Видео: http://youtu.be/CTrRzdzhj1s?list=PLu7pKL8OAoRSze5Ts9wrbcEQBvXDx-AGq
Если вы начали проводить ретроспективы в своей команде, это ещё не значит, что вы внедрили процесс постоянного совершенствования (Kaizen). Часто у начинающих и не только Agile команд возникают те или иные сложности: выявленные проблемы не существенны или находятся за пределами влияния команды, действия по решению проблем не воплощаются в жизнь.
На докладе мы рассмотрим типичные проблемы Agile ретроспектив и как с ними бороться. Начнём с такого часто встречаемого случая, когда члены команды достаточно позитивно настроены, не видят проблем в своей работе и их идеи по улучшению процесса сводятся к предложениям по организации инфраструктуры офиса: кондиционеры, видов чая и т.д.
Здесь нужно вернуть команду с небес на землю, показать, какие проблемы есть на самом деле и профасилитировать нахождение решений.
Другой частый случай почти полная противоположность первому по атмосфере, но по эффекту на ретро очень похож. Члены команды настолько сильно находятся под прессингом дефектов и постоянных "хотелок" заказчиков, что не верят, что что-то можно улучшить и видят проблемы только в других командах, но не у себя.
Здесь более сложный процесс по нормализации атмосферы в команде. Рассмотрим первые 3 важных шага, как это сделать: снижение психологического напряжения процессным путём, решение основных проблем и маленькие победы.
Третья проблема, которую успеем рассмотреть: принятые на ретроспективе решения, не претворяются в жизнь. Практики для исправления достаточно просты, но далеко не все о них знают и их соблюдают: добровольное назначение задач, голосование консенсусом и добавление задач в беклог.
Обязательные практики Agile-проекта и правило ПППPavel Gabriel
Презентация для конференции "Деловой интернет 2009". В презентации рассматриваются обязательные практики для agile-проекта, причины их использования и правило, позволяющее добиваться большей эффективности.
Статегия agile-трансформации крупной компанииAskhat Urazbaev
Достаточно ли обойтись внедрением Agile-практик на уровне Scrum/XP или для успешной работы нужно нечто большее?
Опыт показывает, что существование в компании Agile только как методологии для команд приводит к слабому и часто кратковременному эффекту повышения производительности. Порой это дисбалансирует компанию и приводит к результатам даже хуже, чем были до внедрения Agile.
Для получения максимального результата изменения в культуре организации необходимы на всех уровнях.
Что это означает на практике и как этого добится?
В этом выступлении мы обсудим подходы проведения Agile-трансформации в больших организациях. Мы рассмотрим практики которые работают в российских корпорациях, а также типичные ловушки и грабли на которые вы можете наступить при старте изменений.
Михаил Лукьянов, Дмитрий Шайхатаров, Agile среди водопадов. Использование SCR...ScrumTrek
Трудно представить возможность применения Agile в компаниях с большим количеством зарегламентированных процессов, которые, к тому же, ориентированны на водопадную модель разработки ПО. На примере разработки системы управления рисками на Финансовых рынках мы поделимся своим опытом как можно построить полноценный Agile процесс исключительно с использованием стандартного SCRUM framework. Мы расскажем об бизнес процессе, решенных проблемах и инженерных практиках, которые позволили обеспечить высокую скорость delivery в рамках данной системы.
В начале 2011го года компания Skype купила небольшой стартап под названием Qik. На тот момент в компании Skype был официальный процесс на базе SCRUM. Вышло так, что после перехода на этот процесс, команда Qik сильно потеряла в скорости поставки. В своём докладе я расскажу, что именно произошло, и как следование правилам Scrum мешало команде быстро и качественно разрабатывать свой продукт.
Денис Тучин - Болезни Agile ретроспектив и как их лечить (2016 AgileTour.By)Denis Tuchin
Видео: http://youtu.be/CTrRzdzhj1s?list=PLu7pKL8OAoRSze5Ts9wrbcEQBvXDx-AGq
Если вы начали проводить ретроспективы в своей команде, это ещё не значит, что вы внедрили процесс постоянного совершенствования (Kaizen). Часто у начинающих и не только Agile команд возникают те или иные сложности: выявленные проблемы не существенны или находятся за пределами влияния команды, действия по решению проблем не воплощаются в жизнь.
На докладе мы рассмотрим типичные проблемы Agile ретроспектив и как с ними бороться. Начнём с такого часто встречаемого случая, когда члены команды достаточно позитивно настроены, не видят проблем в своей работе и их идеи по улучшению процесса сводятся к предложениям по организации инфраструктуры офиса: кондиционеры, видов чая и т.д.
Здесь нужно вернуть команду с небес на землю, показать, какие проблемы есть на самом деле и профасилитировать нахождение решений.
Другой частый случай почти полная противоположность первому по атмосфере, но по эффекту на ретро очень похож. Члены команды настолько сильно находятся под прессингом дефектов и постоянных "хотелок" заказчиков, что не верят, что что-то можно улучшить и видят проблемы только в других командах, но не у себя.
Здесь более сложный процесс по нормализации атмосферы в команде. Рассмотрим первые 3 важных шага, как это сделать: снижение психологического напряжения процессным путём, решение основных проблем и маленькие победы.
Третья проблема, которую успеем рассмотреть: принятые на ретроспективе решения, не претворяются в жизнь. Практики для исправления достаточно просты, но далеко не все о них знают и их соблюдают: добровольное назначение задач, голосование консенсусом и добавление задач в беклог.
Обязательные практики Agile-проекта и правило ПППPavel Gabriel
Презентация для конференции "Деловой интернет 2009". В презентации рассматриваются обязательные практики для agile-проекта, причины их использования и правило, позволяющее добиваться большей эффективности.
Статегия agile-трансформации крупной компанииAskhat Urazbaev
Достаточно ли обойтись внедрением Agile-практик на уровне Scrum/XP или для успешной работы нужно нечто большее?
Опыт показывает, что существование в компании Agile только как методологии для команд приводит к слабому и часто кратковременному эффекту повышения производительности. Порой это дисбалансирует компанию и приводит к результатам даже хуже, чем были до внедрения Agile.
Для получения максимального результата изменения в культуре организации необходимы на всех уровнях.
Что это означает на практике и как этого добится?
В этом выступлении мы обсудим подходы проведения Agile-трансформации в больших организациях. Мы рассмотрим практики которые работают в российских корпорациях, а также типичные ловушки и грабли на которые вы можете наступить при старте изменений.
Михаил Лукьянов, Дмитрий Шайхатаров, Agile среди водопадов. Использование SCR...ScrumTrek
Трудно представить возможность применения Agile в компаниях с большим количеством зарегламентированных процессов, которые, к тому же, ориентированны на водопадную модель разработки ПО. На примере разработки системы управления рисками на Финансовых рынках мы поделимся своим опытом как можно построить полноценный Agile процесс исключительно с использованием стандартного SCRUM framework. Мы расскажем об бизнес процессе, решенных проблемах и инженерных практиках, которые позволили обеспечить высокую скорость delivery в рамках данной системы.
www.cmcons.com. Практика и технология внедрения процесса конфигурационного управления и управления изменениями с применением IBM Rational ClearCase и ClearQuest
Поддержка высоконагруженного проекта: мониторинг, резервирование, обслуживани...Ontico
1. Мониторинг высоконагруженного проекта.
1.1. Специфика мониторинга высоконагруженного проекта: гранулярность мониторинга, надежность системы мониторинга, система оповещений.
1.2. Мониторинг и контроль распределенных систем.
1.3. Специфика организации оповещений в высоконагруженном проекте. Превентивный мониторинг.
2. Резервирование и резервное копирование в высоконагруженном проекте.
2.1. Резервирование и резервное копирование - разные вещи.
2.2. Резервирование: на уровне сервера, дата-центра, географически распределенных площадок.
2.1. Организация резервного копирования. Сохранность часто обновляемых данных.
3. Обслуживание высоконагруженного проекта.
3.1. Организация поддержки высоконагруженного проекта: опыт, специфика работы.
3.2. Организация дежурств, эскалация оповещений.
3.3. Аварии в высоконагруженных проектах: примеры из жизни.
Как оценивать состояние проекта по разработке с помощью формальных метрик и о...Dmitry Andreev
Можете ли вы завтра утром в 8:05 положить на стол руководства детальный отчет по прогрессу разрабатываемой системы, количестве ошибок в разрезе подсистем и требований, качестве юнит-тестов, скорости внесения изменений в код и возникновения ошибок? Можете ли вы с помощью средств аналитики оценить узкие места проекта, например, ответив на вопрос «какая подсистема имеет самое большое количество вновь возникающих ошибок»? Если вы хотите узнать, как это сделать то приходите на доклад о возможностях подсистем отчетности Visual Studio Team System 2010. В докладе будут рассмотрены подходы по созданию формальной системы метрик, индикаторов, отчетов для оценки прогресса и состояния проекта по разработке программного обеспечения.
Презентация Бибичева Андрея об опыте внедрения Scrum в компании CustIS, прочитанная на конференции РИТ-2008.
Текст статьи - http://www.slideshare.net/biBIGine/scrum-2029854
The main questions this presentation awsers:
How to replace all software development support tools - bug tracker, task trackers, boards, dashboards, source control, build machines with TFS and not broke anything.
How to extend TFS with typescript and have fun doing this
Test Labs 2009. Налютин Никита. Тестирование, как средство противодействия вн...Nikita Nalyutin
В реальной жизни тестировщики часто сталкиваются с ситуацией, когда требования к системе меняются постоянно, сроки разработки сжаты, а 100% покрытие недостижимо – не потому, что заказчик не знает, чего хочет, а потому что постоянно меняется среда, в которой работает система, и потому что опоздать – хуже, чем ошибиться. Здесь приходится говорить о достаточном уровне надежности, приоритетах и принятии определенной доли риска.
Классическая литература такие ситуации часто обходит: считается, что четко определенный процесс тестирования в подобных условиях не существует. На самом деле процесс есть, он просто другой. Целью становится не полное покрытие и документальное подтверждение следования технологии, а постоянная оценка и пересмотр критических мест системы, поддержание целостной информации о ее состоянии, ее функциональности и дефектах. В докладе пойдет речь о возможной организации такого процесса при помощи GTD, управления конфигурациями и быстрой визуальной оценки состояния системы.
Проектирование Программных Систем. Лекция 01Dima Dzuba
Лекция рассказывает о базовых принципах построения программного обеспечения. Проводится сравнение гибких (Agile) и водопадных методологий разработки программного обеспечения.
Алексей Дерюшкин, От каждого по потребностям, каждому — по agileScrumTrek
При желании любой интересующийся может найти массу описаний инструментов и практик гибких методологий разработки. Но что делать, чтобы внедрить agile-разработку в новой команде, что называется, "с нуля"? А если команда уже сложилась и "притёрлась"? С чего начать, какие выбрать инструменты, что будет лучше, а что хуже, в вашей конкретной ситуации, в вашем проекте, в вашей компании? Какие отрицательные явления для тех или иных подходов можно ожидать? На все эти вопросы я отвечу, опираясь на практический опыт внедрений за последние три года в четырёх разных командах. Если вы собираетесь внедрять agile разработку в своей (или чужой) команде, и хотите подойти к процессу максимально осознанно, выбрав те инструменты, которые помогут вам лучше всего -- этот доклад для вас.
We have a lot of businesses working in Ukraine as Outsource company. But all we know that outsource is not options as the long-term
business strategy. From the other perspective, there are a few firms that are trying to move to the product development but it too risky
for two reasons:
— You need to invest your money and losing your margin.
— You have no any experience in product management or startup landing neither fundraising.
We in Octoberry, start to work as Product Sourcing company three years ago. We find this way very useful to gain experience in product
management and fundraising and after we moved to own product development and we want to share our case. In this talk, we will
discuss:
— What is product sourcing?
— Why product source.
— Five steps key steps to run Product Source project
— Moving from product source to Product Company
AgileCamp — летняя практическая конференция, которую ежегодно проводить компания ScrumTrek. Участники процессного трека на практике отрабатывают все цепочку создания продукта. Используются такие техники как проведение опросов, игра в ТЗ, user story mapping, bucket estimation, planning poker, getkanban, world cafe и др.
Как создать концепцию продукта в виде Lean CanvasMagneta AI
Lean Canvas — инструмент, который позволяет быстро понять ценность продукта, проблемы, которые он решает, его основную аудиторию и способы монетизации. В презентации подробно рассмотрен шаблон lean canvas и дается подробное руководство по заполнению.
Зачем нужны ретроспективы и как их проводить? Основные отличия ретроспектив в различных фреймворках, например, Scrum или Kanban, рекомендации по продолжительности, наполнению, советы по каждому этапу ретроспективы.
2. TACS
Веб-приложения для автоматизации документооборота с
гос.регуляторами (ФНС, РФМ, ЦБ, ПФР и пр.)
~100 экранных форм
~25Mb исходного кода
~10000 сообщений в день
~300 пользователей
Команда 15 человек
Интеграция в 50+ систем
7. Предусловия
Свобода выбора методологий и процессов
«внутри разработки»
Мало дорогих (почасовых) разработчиков
Невозможность сохранять всю команду
между проектами
Изоляция от всего остального банка
8. Шаг 0 – база перед стартом
Система управления задачами (с интеграцией в
VCS, CI и wiki)
Сборка с юнит-тестированием и интеграцией
Базовая архитектура
Ground rules – правила кодирования, правила
оформления задач, структура документации,
ревью кода, работа в отдельных ветках и т.п.
9. Боль 1 – много менеджеров!
В вашем проекте, скорее всего,
заинтересован не один десяток разных
людей, и все они могут иметь разные цели,
а вы можете об этом не узнать до самого
конца проекта!
11. Шаг 1 - начало
Построение базовой команды
Построение базовых дизайна, архитектуры и
выбор технологий
12. Боль отдельная, архитектурная
Даже небольшие веб-приложения, где,
вроде бы, всё понятно, и, кажется, можно
обойтись несколькими слоями, с годами
превращаются в монстров с тентаклями.
14. Шаг 2 - визуализация
Канбан-доска для всех задач
Ежедневные стендапы у доски
15.
16. Боль 2 - микроменеджмент
«А что это вы делаете?»
«А давайте делать вон то!»
«А чего так долго?»
«А расскажите мне вот про эту задачу…»
«А вот у меня на другом проекте…»
18. Боль 3 – «Канбан? Что это?»
«Продать» чистый канбан менеджменту
очень сложно, особенно, когда речь заходит
о статистических данных и вероятностях.
Фразы вида «мы сделаем N задач за X дней
с вероятностью P» приводят к Exception-ам
в головах.
20. Шаг 3 – оценки и метрики
3-уровневая оценка («Size» - «Story Points» -
Hours)
Доска с эталонными задачами
Подсчёт метрик при каждом выпуске релиза
21.
22.
23.
24.
25. Боль 4 – «сколько граммов?»
Менеджмент работает по классической
модели с тремя фиксированными
измерениями – время-деньги-требования и
требует гарантий (не оценок!) с точностью
до дня.
27. Шаг 4 – расчёт проектов
Использованы данные, накопленные за 2
месяца работы команды
Ошибка расчета – +2 дня за ~4 месяца
Оценка в два уровня, экспертная в
«размерах» (S-M-L) и уточняющая групповая
в Story Points
28. Size – Story Points
S = 0.5 … 2 SP
M = 3 … 8 SP
L = 13 … 20 SP
XL = 40 SP
XXL = 100 SP
29. Шаг 5 – частые релизы
Даже, если этого не требует обстановка
(несколько команд, зависимость от
интеграции, внешних вендоров и пр.), нужно
релизиться хотя бы раз в 1-2 недели. Это
держит команду в тонусе и очень помогает
впоследствии при выходе в продуктив.
30. Мультиболь 5 – требования
«Здесь всё срочно!»
Отдел бизнес-анализа работает по водопаду
Много разных внутренних заказчиков с разными
приоритетами
Сроки ставит ЦБ – без работы со scope-ом
можно не рассчитывать на успех
31. Шаг 6 – работа с требованиями
Договорились с бизнес-аналитиком делать
вместе первичную декомпозицию требований в
User Stories (в функциональной части BRD)
Приоритеты ставили вопросом «сколько дней
протянем в production без feature Х?»
Составили бумажный/интерактивный roadmap
всего проекта
32.
33.
34.
35. Шаг 7 - ретроспективы
Построение индекса безопасности
Периодичные (1-2 недели) «текущие»
ретроспективы командой разработки
«Посмертные» ретроспективы проектов со
сбором данных от всех участников
43. Шаг 8 – оптимизация
Перевели регистрацию дефектов UAT из HP
ALM в JIRA
Перенесли UAT-стенд с PREVIEW-среды на
TEST-среду
Автоматизировали работу с доской
Оптимизировали процессы внутри команды
44.
45.
46.
47. Шаг 9 – фигак и в продуктив!
В первый месяц приходилось релизиться
вплоть до нескольких раз в день
Без предварительных автоматизации
тестов, сборки и «обкатки» процессов это
было бы невозможно.
48. Боль водопадно-продуктивная
Надо «выкатить» preview (SLA - 2 дня)
Надо получить все согласования
Надо «выкатить» production (SLA – 2 дня)
Любая ошибка в процессе «обнуляет» SLA и
процесс начинается заново
50. Шаг 10 – текущий
Использование одной общей документации
в JIRA/Confluence всеми участниками
Demo заказчикам в виде видеозаписей со
звуком в блоге проекта в Confluence
Налаживание связей «вне» команды
(бизнес-анализ, UAT, поддержка и пр.)
51. Тем временем в замке у шефа…
Наглядная агитация в виде досок в командном
секторе open-space-а
Видимая «движуха» в виде стендапов
Периодические рассказы коллегам «как мы это
делаем» -- «живьём» и в корпоративном блоге
Проведение тренингов и коучинг других команд
52. Типичные проблемы
Сложность «продажи» новых/революционных
идей
Высокая инерция («мы так не делаем»)
Разорванность коммуникаций
Скомпрометированные слова «Agile», «Scrum» и
«Kanban»
Зависимость от других команд/подразделений
53. Тоже важные вещи
Визуализация
Управление через помощь
Уважение мнения большинства
Техники фасилитации и игрофикации
Мотивированность и вдохновленность
Коммуникации и психология