Каждый уважающий себя Agile-coach рано или поздно должен высказаться на эту тему:
— АААА! Оно у нас не работает
— Ваш Скрам у нас невозможен
— Как вы предлагаете делать нам интеграционное тестирование внутри спринта, если оно занимает месяц!? О_о
Спокойно! На докладе мы разберем, почему оно не работает, и как на самом деле оно должно работать.
Презентация с доклада на AgileDays 2017. Скоро будет видео
Презентация к вебинару - https://youtu.be/mZEJ_YEFdoI
Вебинар из серии вебинаров ICAgile Agile Team Facilitation, которая состоит из 7 вебинаров о фасилитации Agile команд. Будем рассматривать техники, которые помогают командам проводить совместные обсуждение и принимать решения.
О чем узнаете на вебинаре?
2 техники для “обсуждения-дискусcии", они обе хорошо подойдут как для малых (4-5 человек) так и для больших (12-14 человек) команд. Плюсы и минусы этих техник, особенности и возможности их трансформации под ваши рабочие условия.
2 техники для “обсуждения-обратной связи". Одна из них довольно распространенная и она мне не очень нравится своей банальностью, а вторую вы вряд ли знаете, она интереснее, но и сложнее в применении.
1 техника для “обсуждения-анализа”, называется “Декартовы Координаты”, часто применяется в индивидуальном коучинге, но в 99% упускается одна интересная деталь при ее использовании, на вебинаре я про нее расскажу.
2 техники для голосования, про точко-голосование вы все, конечно, уже в курсе, я расскажу еще две простые техники, может, они вам тоже знакомы. Я бы хотела больше остановиться даже не на самих техниках, а на том, как можно манипулировать будущими результатами голосования еще до самого голосования.
Продолжая тему манипуляций, мы рассмотрим валидность мажоритарного способа принятия решений и познакомимся с другими, возможно, более подходящими для ваших команд, подходами.
Запись прошлых вебинаров:
https://youtu.be/7x3uHaFqe1I
https://youtu.be/ykx54Kx6wOA
https://youtu.be/mjIu06mvO4A
Фасилитируем встречи, повышающие уровень сотрудничества в командеLuxoftAgilePractice
Третий вебинар из серии вебинаров ICAgile Agile Team Facilitation, которая состоит из 7 вебинаров о фасилитации Agile команд. Будем рассматривать техники и инструменты, которые повышают уровень сотрудничества в команде. Поговорим про особенности их применения, случаи, когда они работают, а когда нет.
Презентация к вебинару - https://youtu.be/mZEJ_YEFdoI
Вебинар из серии вебинаров ICAgile Agile Team Facilitation, которая состоит из 7 вебинаров о фасилитации Agile команд. Будем рассматривать техники, которые помогают командам проводить совместные обсуждение и принимать решения.
О чем узнаете на вебинаре?
2 техники для “обсуждения-дискусcии", они обе хорошо подойдут как для малых (4-5 человек) так и для больших (12-14 человек) команд. Плюсы и минусы этих техник, особенности и возможности их трансформации под ваши рабочие условия.
2 техники для “обсуждения-обратной связи". Одна из них довольно распространенная и она мне не очень нравится своей банальностью, а вторую вы вряд ли знаете, она интереснее, но и сложнее в применении.
1 техника для “обсуждения-анализа”, называется “Декартовы Координаты”, часто применяется в индивидуальном коучинге, но в 99% упускается одна интересная деталь при ее использовании, на вебинаре я про нее расскажу.
2 техники для голосования, про точко-голосование вы все, конечно, уже в курсе, я расскажу еще две простые техники, может, они вам тоже знакомы. Я бы хотела больше остановиться даже не на самих техниках, а на том, как можно манипулировать будущими результатами голосования еще до самого голосования.
Продолжая тему манипуляций, мы рассмотрим валидность мажоритарного способа принятия решений и познакомимся с другими, возможно, более подходящими для ваших команд, подходами.
Запись прошлых вебинаров:
https://youtu.be/7x3uHaFqe1I
https://youtu.be/ykx54Kx6wOA
https://youtu.be/mjIu06mvO4A
Фасилитируем встречи, повышающие уровень сотрудничества в командеLuxoftAgilePractice
Третий вебинар из серии вебинаров ICAgile Agile Team Facilitation, которая состоит из 7 вебинаров о фасилитации Agile команд. Будем рассматривать техники и инструменты, которые повышают уровень сотрудничества в команде. Поговорим про особенности их применения, случаи, когда они работают, а когда нет.
Асхат Уразбаев. Agile Coach и Scrum Master как руководители нового типаScrumTrek
Мир меняется. Высокая скорость изменений трансформирует бизнес-модели и сами организации. В новом мире решения надо принимать быстро и уметь синхронизировать работу большого количества людей. Важность по-настоящему командной работы растет. Появляются роли, главной задачей которых является построение эффективной команды.
Речь идет о роли Scrum Master/Agile Coach. В докладе мы ответим на вопросы:
— Какое место они занимают в организации?
— Какими они должны быть?
— Что входит в их обязанности?
— Что они должны знать и уметь?
В длительной перспективе ретроспективы – самая важная часть гибких процессов. Но очень часто у команд не получается запустить процесс непрерывного улучшения, либо через некоторое время этот процесс обрывается, когда команда думает, что все проблемы решены. Я расскажу не только теоритическую часть, которая позволит преодолеть эти проблемы, но и дам несколько десятков примеров конкретных практик, которые применяются на эффективных ретроспективах. Доклад рассчитан, как на начинающих ретроспективы, так и практиков гибких методологий.
Что такое групповая динамика и зачем про нее знать фасилитатору?LuxoftAgilePractice
Бывала ли у вас такая ситуация с командой, когда вы не понимали, чем вызван спад ее производительности или возросшее количество внутрикомандных конфликтов? На прошлой неделе еще все дружно работали, а на этой начался какой-то разлад и шатание.
Одной из причин такой метаморфозы может быть переход команды из стадии формирования в стадию штормления. Как это определить и что с этим делать, мы рассмотрим на вебинаре на примере модели командной динамики Брюса Такмана.
Модель Такмана - это, конечно, не единственный способ описания процессов, которые происходят с командой, компанией или социумом в целом. Для рассмотрения более глубокий, экзистенциальных потоков изменений можно использовать модель Спиральной Динамики. Эта модель может ответить не только на философские, но и на такие утилитарные вопросы как:
В чем причина бюрократии на проекте или в компании?
Каким сотрудникам будет сложно работать в Agile среде?
Почему участники одной команды могут действовать против друг друга и напоминать коллектив из басни “лебедь, рак и щука”?
Каким руководителям сложно увольнять сотрудникам и проводить дисциплинарные беседы с подчиненными?
Каким командам подойдет и принесет пользу Скрам фреймворк.
На вебинаре мы детально, но быстро, разберем две вышеперечисленные модели и еще один подход, который помогает последовательно сформировать команду из группы специалистов.
Запись прошлых вебинаров на тему фасилитации:
https://youtu.be/VqarmllTKD4 Фасилитируем командное обсуждение и принятие решений
https://youtu.be/7x3uHaFqe1I Майндсет и поведение Agile фасилитатора
https://youtu.be/ykx54Kx6wOA Фасилитируем встречи, повышающие уровень сотрудничества в команде
https://youtu.be/mjIu06mvO4A Вебинар От Agile фасилитатора до Agile коуча
В начале 2011го года компания Skype купила небольшой стартап под названием Qik. На тот момент в компании Skype был официальный процесс на базе SCRUM. Вышло так, что после перехода на этот процесс, команда Qik сильно потеряла в скорости поставки. В своём докладе я расскажу, что именно произошло, и как следование правилам Scrum мешало команде быстро и качественно разрабатывать свой продукт.
7 Способы проведения ретроспектив для анализа и улучшения процессаMagneta AI
Ретроспектива играет большую роль в развитии команд, работающих в Agile проектах. В большинстве случаев, успех проекта зависит от того, насколько команда умеет совместно выявлять проблемы и улучшать свою работу от итерации к итерации.
Мы рассмотрим различные практики проведения ретроспектив, обсудим часто возникающие вопросы в организации работы команды и коллективного принятия решения.
Scrum, Kanban, XP, Crystal и прочие еще более редкие фреймворки и методы, что обещают Вам стать agile, уже давно опробованы, как в чистом виде, так и в составе ядерных коктейлей а воз и ныне там. Ваши отделы, продуктовые группы и вся компания целиком все так же далеки от того, чтобы быть agile. Меж тем верхи действительно хотят, а низы однозначно могут и даже обратное все так же верно. Так в чем же дело? В рамках этого доклада мы попытаемся ответить на этот вопрос. Будем говорить о разной степени важности тех или иных элементов больших agile-трансформаций, их влиянии друг на друга и правильно расставленных акцентах и приоритетах. В конце, как обычно, секретный ингредиент успеха.
Как не попасть в ловушку локальной оптимизации в процессе Agile-трансформацииAnton Zotin
Systems Thinking - это направление методологии научного познания, в основе которого лежит рассмотрение объекта как системы, сообщает нам wikipedia. Один из ключевых навыков, которыми должен обладать топ-менеджмент по мнению Гарвардского Университета. Данная техника оказывается абсолютно бесценной, когда дело доходит до по-настоящему больших и сложных agile-трансформаций. Когда буквально пара компромисов "мы это не трогаем, потому что..." или неверно выбранный фреймфорк могут привести к катастрофе, нужно иметь средство принимать взвешенные и обоснованные решения, исключающие очередную локальную оптимизацию. Systems Thinking в этом случае - как раз то, что доктор прописал. За два часа мы очень быстро познакомимся с теорией метода и посвятим львинную долю времени практике. Не могу обещать, что после этой сессии мир будет все еще прежним.
Как не собрать все грабли при Agile трансформации компании?Alexey Voronin
Agile хайп делает свое дело: многие компании от крупных банков до растущих стартапов ринулись трансформироваться в Agile. Но все так или иначе наступают на грабли: Нужно ли менять организационную структуру компании или не стоит? В какой момент это делать? Если менять, то как? Есть ли какие-то шаблоны или нужно использовать другие подходы? Как формировать Agile команды? Довериться мнению бизнеса, функциональных руководителей IT? Я расскажу о нетривиальных проблемах, в решении которых я участвовал за предыдущий год в крупных компаниях (количество команд >= 5), и, конечно же, о решениях.
Асхат Уразбаев. Agile Coach и Scrum Master как руководители нового типаScrumTrek
Мир меняется. Высокая скорость изменений трансформирует бизнес-модели и сами организации. В новом мире решения надо принимать быстро и уметь синхронизировать работу большого количества людей. Важность по-настоящему командной работы растет. Появляются роли, главной задачей которых является построение эффективной команды.
Речь идет о роли Scrum Master/Agile Coach. В докладе мы ответим на вопросы:
— Какое место они занимают в организации?
— Какими они должны быть?
— Что входит в их обязанности?
— Что они должны знать и уметь?
В длительной перспективе ретроспективы – самая важная часть гибких процессов. Но очень часто у команд не получается запустить процесс непрерывного улучшения, либо через некоторое время этот процесс обрывается, когда команда думает, что все проблемы решены. Я расскажу не только теоритическую часть, которая позволит преодолеть эти проблемы, но и дам несколько десятков примеров конкретных практик, которые применяются на эффективных ретроспективах. Доклад рассчитан, как на начинающих ретроспективы, так и практиков гибких методологий.
Что такое групповая динамика и зачем про нее знать фасилитатору?LuxoftAgilePractice
Бывала ли у вас такая ситуация с командой, когда вы не понимали, чем вызван спад ее производительности или возросшее количество внутрикомандных конфликтов? На прошлой неделе еще все дружно работали, а на этой начался какой-то разлад и шатание.
Одной из причин такой метаморфозы может быть переход команды из стадии формирования в стадию штормления. Как это определить и что с этим делать, мы рассмотрим на вебинаре на примере модели командной динамики Брюса Такмана.
Модель Такмана - это, конечно, не единственный способ описания процессов, которые происходят с командой, компанией или социумом в целом. Для рассмотрения более глубокий, экзистенциальных потоков изменений можно использовать модель Спиральной Динамики. Эта модель может ответить не только на философские, но и на такие утилитарные вопросы как:
В чем причина бюрократии на проекте или в компании?
Каким сотрудникам будет сложно работать в Agile среде?
Почему участники одной команды могут действовать против друг друга и напоминать коллектив из басни “лебедь, рак и щука”?
Каким руководителям сложно увольнять сотрудникам и проводить дисциплинарные беседы с подчиненными?
Каким командам подойдет и принесет пользу Скрам фреймворк.
На вебинаре мы детально, но быстро, разберем две вышеперечисленные модели и еще один подход, который помогает последовательно сформировать команду из группы специалистов.
Запись прошлых вебинаров на тему фасилитации:
https://youtu.be/VqarmllTKD4 Фасилитируем командное обсуждение и принятие решений
https://youtu.be/7x3uHaFqe1I Майндсет и поведение Agile фасилитатора
https://youtu.be/ykx54Kx6wOA Фасилитируем встречи, повышающие уровень сотрудничества в команде
https://youtu.be/mjIu06mvO4A Вебинар От Agile фасилитатора до Agile коуча
В начале 2011го года компания Skype купила небольшой стартап под названием Qik. На тот момент в компании Skype был официальный процесс на базе SCRUM. Вышло так, что после перехода на этот процесс, команда Qik сильно потеряла в скорости поставки. В своём докладе я расскажу, что именно произошло, и как следование правилам Scrum мешало команде быстро и качественно разрабатывать свой продукт.
7 Способы проведения ретроспектив для анализа и улучшения процессаMagneta AI
Ретроспектива играет большую роль в развитии команд, работающих в Agile проектах. В большинстве случаев, успех проекта зависит от того, насколько команда умеет совместно выявлять проблемы и улучшать свою работу от итерации к итерации.
Мы рассмотрим различные практики проведения ретроспектив, обсудим часто возникающие вопросы в организации работы команды и коллективного принятия решения.
Scrum, Kanban, XP, Crystal и прочие еще более редкие фреймворки и методы, что обещают Вам стать agile, уже давно опробованы, как в чистом виде, так и в составе ядерных коктейлей а воз и ныне там. Ваши отделы, продуктовые группы и вся компания целиком все так же далеки от того, чтобы быть agile. Меж тем верхи действительно хотят, а низы однозначно могут и даже обратное все так же верно. Так в чем же дело? В рамках этого доклада мы попытаемся ответить на этот вопрос. Будем говорить о разной степени важности тех или иных элементов больших agile-трансформаций, их влиянии друг на друга и правильно расставленных акцентах и приоритетах. В конце, как обычно, секретный ингредиент успеха.
Как не попасть в ловушку локальной оптимизации в процессе Agile-трансформацииAnton Zotin
Systems Thinking - это направление методологии научного познания, в основе которого лежит рассмотрение объекта как системы, сообщает нам wikipedia. Один из ключевых навыков, которыми должен обладать топ-менеджмент по мнению Гарвардского Университета. Данная техника оказывается абсолютно бесценной, когда дело доходит до по-настоящему больших и сложных agile-трансформаций. Когда буквально пара компромисов "мы это не трогаем, потому что..." или неверно выбранный фреймфорк могут привести к катастрофе, нужно иметь средство принимать взвешенные и обоснованные решения, исключающие очередную локальную оптимизацию. Systems Thinking в этом случае - как раз то, что доктор прописал. За два часа мы очень быстро познакомимся с теорией метода и посвятим львинную долю времени практике. Не могу обещать, что после этой сессии мир будет все еще прежним.
Как не собрать все грабли при Agile трансформации компании?Alexey Voronin
Agile хайп делает свое дело: многие компании от крупных банков до растущих стартапов ринулись трансформироваться в Agile. Но все так или иначе наступают на грабли: Нужно ли менять организационную структуру компании или не стоит? В какой момент это делать? Если менять, то как? Есть ли какие-то шаблоны или нужно использовать другие подходы? Как формировать Agile команды? Довериться мнению бизнеса, функциональных руководителей IT? Я расскажу о нетривиальных проблемах, в решении которых я участвовал за предыдущий год в крупных компаниях (количество команд >= 5), и, конечно же, о решениях.
HBDI. A hack for better communication and motivationMikhail Podurets
This is a presentation for a Luxoft webinar covering the Herrmann Brain Dominance Instrument (HBDI) and how it may help us in making our communication and motivation more efficient.
Метод ББК (барабан-буфер-канат): мы запускаем минимальное количество заказов в производство, чтобы обеспечивать максимальную скорость выполнения.
Обеспечиваем надежность.
Продаем надежность, затем продаем срочные заказы с дополнительной наценкой.
Мертвая зона - Как визуализировать поток требований в распределенном проектеMagneta AI
Сергей Прохоренко, Luxoft (Киев)
Последние несколько лет я работаю в Agile-командах в различных ролях - аналитика, proxy PO, процессного коуча. За это время я наблюдал самые различные проекты, сталкивающиеся с похожими препятствиями при масштабировании и помогал им в решении проблем.
Общепринятые практики Scrum предлагают большое количество инструментов для визуализации командной работы: product/sprint backlog, доска, ежедневные стэндапы, burndown chart. Но если ваш проект распределен по трем-четырем локациям, а количество людей в проекте перевалило за сотню - как понять, правильно ли расставлены приоритеты, понимают ли команды, чем они и их коллеги по проекту будут заниматься в следующем спринте и дальше?
Многие из этих вопросов часто попадают в "мертвую зону", что приводит к проблемам при масштабировании процесса.
Рассмотрев несколько практических примеров из практики, мы обсудим, как построить эффективную коммуникацию между командами в проекте, как визуализировать поток требований и как определять критерии для продвижения новых требований из product backlog в sprint backlog.
Светлана Мухина, Метрики в Agile проектахScrumTrek
Я думаю, что чем сложнее метрика, тем проще ее подвести под необходимые результаты. Зачастую достаточно немного исказить одно не самое важное значение в формуле расчета и в итоге на больших числах можно получить приличное искажение. С помощью визуализации метрик тоже можно оказывать влияние и изменять мнение в необходимую вам сторону. И тут возникает вопрос #2 - "Что делать?" Использовать или не использовать метрики. Возможно, вы найдете для себя ответ на этот вопрос в моем докладе про очень простые метрики: -capacity - кол-во идеальных часов доступное в итерацию; -velocity - количество сделанной работы в стори поинтах или других "попугаях"; -burn-down - прогресс команды на данный момент, сколько сделали и сколько осталось; -индекс стабильности требований - как часто меняются требования; И еще поделюсь своим мнением о том, какая может быть польза команде от заполнения системы учета времени; Я расскажу, как мы собираем эти метрики на проектах и что нам это дает. Например, иногда они помогают найти ответ на вопрос #1 "Кто виноват?" (это шутка).
Xp days 2019 - Why startups need SRE practicesAlexey Andreev
In Prisma we process more than 500k photos per day on the server. I would like to present why SRE practices are needed in a small company, how to implement them without pain, why it pays off, and how we reduced the number of incidents.
Первая встреча с космическими планами на будущее. Поговорим о том, как улучшить процессы компании с помощью Atlasssian продуктов и их интеграциями.
Будем рады встрече и вашим отзывам!
Постановка и улучшение скрам процесса для группы проектов в большой компании,...viktor_bezhenar
Презентация с конференции Lviv PM Day весны 2014 года:
- Что мешает организациям начать использовать гибкие методологии и почему это сложно?
- Преобразование методологий разработки портфеля проектов к Scrum методологии с помощью ЕТС (enterprise transition community - сообщество по изменениям на предприятии):
* наш путь
* его пересечение с моделью Майка Кона и работа по модели
* обязанности и методы работы ЕТС
Презентация к вебинару - https://youtu.be/VqarmllTKD4
Вебинар из серии вебинаров ICAgile Agile Team Facilitation, которая состоит из 7 вебинаров о фасилитации Agile команд. Будем рассматривать техники, которые помогают командам проводить совместные обсуждение и принимать решения.
О чем узнаете на вебинаре?
2 техники для “обсуждения-дискусcии", они обе хорошо подойдут как для малых (4-5 человек) так и для больших (12-14 человек) команд. Плюсы и минусы этих техник, особенности и возможности их трансформации под ваши рабочие условия.
2 техники для “обсуждения-обратной связи". Одна из них довольно распространенная и она мне не очень нравится своей банальностью, а вторую вы вряд ли знаете, она интереснее, но и сложнее в применении.
1 техника для “обсуждения-анализа”, называется “Декартовы Координаты”, часто применяется в индивидуальном коучинге, но в 99% упускается одна интересная деталь при ее использовании, на вебинаре я про нее расскажу.
2 техники для голосования, про точко-голосование вы все, конечно, уже в курсе, я расскажу еще две простые техники, может, они вам тоже знакомы. Я бы хотела больше остановиться даже не на самих техниках, а на том, как можно манипулировать будущими результатами голосования еще до самого голосования.
Продолжая тему манипуляций, мы рассмотрим валидность мажоритарного способа принятия решений и познакомимся с другими, возможно, более подходящими для ваших команд, подходами.
Запись прошлых вебинаров:
https://youtu.be/7x3uHaFqe1I
https://youtu.be/ykx54Kx6wOA
https://youtu.be/mjIu06mvO4A
Сопротивление изменениям. Как помочь команде пережить процессную трансформацию.LuxoftAgilePractice
В своей работе Agile коуча я часто сталкиваюсь не с тем, что какая-то практика не работает или какой-то фреймворк не приносит пользы, а с тем, что команда не хочет пробовать ничего нового, особенно если "особых проблем на проекте нет". Если нет проблем - стоит искать возможности. Мир (и особенно IT область) постоянно меняется. "Чтобы оставаться на месте, нужно бежать, а чтобы двигаться немного вперед, нужно бежать в два раза быстрее" Льюис Кэрролл.
В своем докладе я рассмотрю коучинговые и фасилитационные подходы, которые помогает мне уговорить/убедить команду попробовать новые практики и которые также снижают травматичность перемен для участников команд.
Presentation of webinar "Overview of Function Point Analysis"
On this webinar we investigated on a very high-level estimation in function points. It is introductory webinar and it provides basics on this estimation method. During the webinar we went over following topics:
Theoretical information on FP (Project estimation model, History, Concept, Pro and Con);
Practical information of FP (Application Boundary, Type of count, Application Elements and transactions, Formulas, Non-functional requirements);
Examples and Exercises;
Next steps and recommended materials.
[RUS] AgileDays 2016 - Михаил Подурец - Это невероятно! (PDCA)LuxoftAgilePractice
Бывает, например:
— Привет! Мы хотим внедрить парное программирование! Правда круто?
— Уоу! Полегче! Вы же будете тратить в два раза больше усилий на одно и то же! Это же дорого! Не нужно нам парного программирования...
Или вот так:
— Слушайте, у нас же тестировщики перегружены, давайте TDD внедрим: пусть меньше багов вылезает, когда до них доберется.
— Да не, помнишь, мы уже пробовали в прошлом году и не зашло.. Давай как-то по-другому.
Знакомо? Если да, то в своем выступлении Михаил рассказывал о том, как отвечать на вопросы про эффективность изменений, обосновывать коллегам необходимость внедрения новых процессных и инженерных практик. Бонусом: почему неудавшиеся практики не стоит выбрасывать в мусор.
4. www.luxoft.com
— Мы не можем протестировать всё за 2 недели. Ваш Скрам нам не подходит
(один банк)
4
— У нас слишком часто меняются требования, поэтому мы выбрали
вотерфолл (другой банк)
— И как мы решим в этом вашем розовом мире Скрама кто из четырех команд
должен делать интеграционное тестирование? (один стартап)
— Предложите нам способ справляться с нашим объемом работы, но сроки,
состав работ и финансирование менять нельзя (нефтяная компания)
Истории для затравки
5. www.luxoft.com
О чем пойдет речь
Что такое Agile
(напоминалка)
Как работают Agile-
методы, фреймворки, вот
это всё
Как они не работают
5
6. www.luxoft.com
Быстро освежим в памяти
Agility (гибкость,
проворность) -
способность организации
быстро реагировать на
изменения условий в
продуктивном ключе.
6
Надо
быстрее
А мотивация-то
падает…
10 лет не
релизимся…
10. www.luxoft.com
Что делать с найденным?
Люди и их
взаимодействие
Рабочее программное
обеспечение
Взаимодействие с
заказчиком
Реакция на изменения
11. www.luxoft.com
Так как же это работает?
Правила создают границы
Организация упирается в границы
Это показывает наличие проблемы
Организация принимает решение как решить
проблему, основываясь на текущем понимании
контекста, оставаясь в границах
12. www.luxoft.com
Мы не можем протестировать всё за 2 недели
Проблема: Высокий TTM
Граница: спринт
Решения
- Автоматизация тестирования
- Дробление требований
- Приемка инкрементов
13. www.luxoft.com
У нас слишком часто меняются требования
Проблема: количество работы только возрастает, потеря
прозрачности и предсказуемости
Граница: WIP, регулярный пересмотр бэклога
Решение:
- Пересмотр приоритетов (актуализация хвоста бэклога)
- Пересмотр прогнозов
- Пересмотр плана релизов
- Удержание WIP
13
14. www.luxoft.com
Кто должен делать интеграционное тестирование?
Проблема: низкий TTM, высокая стоимость внесения
изменений с UAT, непрозрачность процесса
Граница: инкремент в конце спринта
Решение:
- Автоматизация интеграционного тестирования
- Прозрачное распределение ролей
- Совместное планирование
- Регулярная синхронизация
14
15. www.luxoft.com
Большой объем работы
Проблема: потери из-за переинвентаризации
Граница: WIP
Решение:
- визуализация потерь,
- ограничение незаконченной работы
15
16. www.luxoft.com
Мне может напрямую позвонить Директор департамента и
тогда я буду работать по 60 часов в неделю, чтобы все
успеть
Проблема: потери из-за непрозрачности статуса, перегрузки
ключевого сотрудника, срыв сроков
Граница: один владелец продукта
Решение: фасилитацией бизнес-приоритетов занимается кто-то
кто имеет бизнес-вес.
16
18. www.luxoft.com
Как же быть?
Прекратите обманывать сами себя (остальных –
опционально)
Выявите проблемы (TTM, качество, сроки, предсказуемость…)
Определите границы, которые влияют на проблему (скорее всего,
все)
Совместно договоритесь как вернуться в границы
Повторите или сожмите границы
18