Suche senden
Hochladen
Kanbanize
•
Als PPTX, PDF herunterladen
•
0 gefällt mir
•
650 views
Evgeny Kolesnikov
Folgen
История про использование Kanban в Maintenance проекте,
Weniger lesen
Mehr lesen
Business
Melden
Teilen
Melden
Teilen
1 von 104
Jetzt herunterladen
Empfohlen
Сайт конференції - http://liof.org Група в Linkedin - http://bit.ly/LIOFLIN Група в Facebook - http://bit.ly/LIOFFAC
Гліб Криштов:“Автоматизація бізнес процесів”
Гліб Криштов:“Автоматизація бізнес процесів”
Lviv Startup Club
Шаги, необходимые для старта DevOps-трансформации: 1. Выбрать сервис 2. Выявить, кто имеет отношение к сервису 3. Построить Value Stream Map 4. Создать временную команду 5. Поставить задачу 6. Вернуться к пункту 1
Как начать DevOps-трансформацию
Как начать DevOps-трансформацию
Andrey Aleksandrov
Agile methodologies workshop
Agile methodologies workshop
Alexey Ilyichev
Видео: http://youtu.be/CTrRzdzhj1s?list=PLu7pKL8OAoRSze5Ts9wrbcEQBvXDx-AGq Если вы начали проводить ретроспективы в своей команде, это ещё не значит, что вы внедрили процесс постоянного совершенствования (Kaizen). Часто у начинающих и не только Agile команд возникают те или иные сложности: выявленные проблемы не существенны или находятся за пределами влияния команды, действия по решению проблем не воплощаются в жизнь. На докладе мы рассмотрим типичные проблемы Agile ретроспектив и как с ними бороться. Начнём с такого часто встречаемого случая, когда члены команды достаточно позитивно настроены, не видят проблем в своей работе и их идеи по улучшению процесса сводятся к предложениям по организации инфраструктуры офиса: кондиционеры, видов чая и т.д. Здесь нужно вернуть команду с небес на землю, показать, какие проблемы есть на самом деле и профасилитировать нахождение решений. Другой частый случай почти полная противоположность первому по атмосфере, но по эффекту на ретро очень похож. Члены команды настолько сильно находятся под прессингом дефектов и постоянных "хотелок" заказчиков, что не верят, что что-то можно улучшить и видят проблемы только в других командах, но не у себя. Здесь более сложный процесс по нормализации атмосферы в команде. Рассмотрим первые 3 важных шага, как это сделать: снижение психологического напряжения процессным путём, решение основных проблем и маленькие победы. Третья проблема, которую успеем рассмотреть: принятые на ретроспективе решения, не претворяются в жизнь. Практики для исправления достаточно просты, но далеко не все о них знают и их соблюдают: добровольное назначение задач, голосование консенсусом и добавление задач в беклог.
Денис Тучин - Болезни Agile ретроспектив и как их лечить (2016 AgileTour.By)
Денис Тучин - Болезни Agile ретроспектив и как их лечить (2016 AgileTour.By)
Denis Tuchin
Доклад Евгения Ильина на SQA Days-22. 17-18 ноября 2017. Санкт-Петербург, Россия www.sqadays.com
Делаем автоматизацию проектных KPIs
Делаем автоматизацию проектных KPIs
SQALab
Доклад Максима Сахарова на SQA Days-22. 17-18 ноября 2017. Санкт-Петербург, Россия www.sqadays.com
Добиваемся эффективности каждого из 9000+ UI-тестов
Добиваемся эффективности каждого из 9000+ UI-тестов
SQALab
Intro 2 Lean
Intro 2 Lean
Maxim Dorofeev
Есть метрики бизнеса и метрики продуктовые. Есть метрики проекта, но вот с оценкой инженерного состояния всегда проблемы. Почитайте идею создания Engineering Assessment Framework, который поможет за 10 минут понять, в каком состоянии проект находится сейчас и в измерять его состояние в динамике.
Agile Engineering Assessment: оценка технического состояния проекта
Agile Engineering Assessment: оценка технического состояния проекта
Alexander Andronov
Empfohlen
Сайт конференції - http://liof.org Група в Linkedin - http://bit.ly/LIOFLIN Група в Facebook - http://bit.ly/LIOFFAC
Гліб Криштов:“Автоматизація бізнес процесів”
Гліб Криштов:“Автоматизація бізнес процесів”
Lviv Startup Club
Шаги, необходимые для старта DevOps-трансформации: 1. Выбрать сервис 2. Выявить, кто имеет отношение к сервису 3. Построить Value Stream Map 4. Создать временную команду 5. Поставить задачу 6. Вернуться к пункту 1
Как начать DevOps-трансформацию
Как начать DevOps-трансформацию
Andrey Aleksandrov
Agile methodologies workshop
Agile methodologies workshop
Alexey Ilyichev
Видео: http://youtu.be/CTrRzdzhj1s?list=PLu7pKL8OAoRSze5Ts9wrbcEQBvXDx-AGq Если вы начали проводить ретроспективы в своей команде, это ещё не значит, что вы внедрили процесс постоянного совершенствования (Kaizen). Часто у начинающих и не только Agile команд возникают те или иные сложности: выявленные проблемы не существенны или находятся за пределами влияния команды, действия по решению проблем не воплощаются в жизнь. На докладе мы рассмотрим типичные проблемы Agile ретроспектив и как с ними бороться. Начнём с такого часто встречаемого случая, когда члены команды достаточно позитивно настроены, не видят проблем в своей работе и их идеи по улучшению процесса сводятся к предложениям по организации инфраструктуры офиса: кондиционеры, видов чая и т.д. Здесь нужно вернуть команду с небес на землю, показать, какие проблемы есть на самом деле и профасилитировать нахождение решений. Другой частый случай почти полная противоположность первому по атмосфере, но по эффекту на ретро очень похож. Члены команды настолько сильно находятся под прессингом дефектов и постоянных "хотелок" заказчиков, что не верят, что что-то можно улучшить и видят проблемы только в других командах, но не у себя. Здесь более сложный процесс по нормализации атмосферы в команде. Рассмотрим первые 3 важных шага, как это сделать: снижение психологического напряжения процессным путём, решение основных проблем и маленькие победы. Третья проблема, которую успеем рассмотреть: принятые на ретроспективе решения, не претворяются в жизнь. Практики для исправления достаточно просты, но далеко не все о них знают и их соблюдают: добровольное назначение задач, голосование консенсусом и добавление задач в беклог.
Денис Тучин - Болезни Agile ретроспектив и как их лечить (2016 AgileTour.By)
Денис Тучин - Болезни Agile ретроспектив и как их лечить (2016 AgileTour.By)
Denis Tuchin
Доклад Евгения Ильина на SQA Days-22. 17-18 ноября 2017. Санкт-Петербург, Россия www.sqadays.com
Делаем автоматизацию проектных KPIs
Делаем автоматизацию проектных KPIs
SQALab
Доклад Максима Сахарова на SQA Days-22. 17-18 ноября 2017. Санкт-Петербург, Россия www.sqadays.com
Добиваемся эффективности каждого из 9000+ UI-тестов
Добиваемся эффективности каждого из 9000+ UI-тестов
SQALab
Intro 2 Lean
Intro 2 Lean
Maxim Dorofeev
Есть метрики бизнеса и метрики продуктовые. Есть метрики проекта, но вот с оценкой инженерного состояния всегда проблемы. Почитайте идею создания Engineering Assessment Framework, который поможет за 10 минут понять, в каком состоянии проект находится сейчас и в измерять его состояние в динамике.
Agile Engineering Assessment: оценка технического состояния проекта
Agile Engineering Assessment: оценка технического состояния проекта
Alexander Andronov
Доклад Дарьи Шишковой на SQA Days-22. 17-18 ноября 2017. Санкт-Петербург, Россия www.sqadays.com
Автоматизация 0.0: 0 - бюджет, 0 - опыт программирования
Автоматизация 0.0: 0 - бюджет, 0 - опыт программирования
SQALab
Доклад Павла Стрункина на конференции SQA Days-20. 24-26 ноября 2016. Минск www.sqadays.com
Когда стоит закончить автоматизировать?
Когда стоит закончить автоматизировать?
SQALab
Алексей Пименов, ScrumTrek
Discovery Kanban для управления беклогом Scrum-команды
Discovery Kanban для управления беклогом Scrum-команды
CEE-SEC(R)
Таисия Рыбак, HPE
Как развить отдел тестирования от палки-копалки до CI
Как развить отдел тестирования от палки-копалки до CI
CEE-SEC(R)
Доклад Алексея Вихрова на конференции SQA Days-20. 24-26 ноября 2016. Минск www.sqadays.com
Тестирование слоёного пирога
Тестирование слоёного пирога
SQALab
Доклад Алексея Маслова на конференции SQA Days-19, 20-21 мая 2016 г., Санкт-Петербург
Нагрузка и автоматизация в большой организации. Движение к DevOps
Нагрузка и автоматизация в большой организации. Движение к DevOps
SQALab
Доклад Александра Башарина на конференции SQA Days-19, 20-21 мая 2016 г., Санкт-Петербург
QA как драйвер трансформации
QA как драйвер трансформации
SQALab
ALM & Agile
ALM & Agile
Askhat Urazbaev
В своем докладе я расскажу о том, как мы адаптировали процесс разработки, в команде, где упор делался на максимальное качество и при этом был всего 1 тестировщик. Доклад будет состоять из двух частей. В первой я расскажу как взяв за основу методологию Crystal Agile мы скомпоновали набор из необходимых нам практик, отсекая все лишнее и получили процесс полностью устраивающий команду, направленный на обеспечение максимального качества. В этой части будут подниматься следующие вопросы: •Какие практики наиболее ценны с точки зрения тестировщика •Как безболезненно добавить практики XP и Kanban в Scrum процесс •Как не отсечь лишнего -Как превратить скомпонованный набор практик в работающий подход Вторая часть доклада будет посвящена непосредственно тому, как облегчить жизнь единственного тестировщика на большом проекте, в частности будут рассмотрены такие вопросы? •Как научить заказчика писать требования •Быстрое создание и поддержка тестовой документации, миф или реальность? •Быстрое внедрение автоматизации •Тестирование нефункциональных требований
QA Fest 2014. Игорь Бондаренко. Agile crystal. Создание процесса нацеленного ...
QA Fest 2014. Игорь Бондаренко. Agile crystal. Создание процесса нацеленного ...
QAFest
В презентации рассматриваются вопросы настройки процесса разработки программного обеспечения
Гибкость, возведенная в абсолют
Гибкость, возведенная в абсолют
amirutov
Доклад Антона Столяра на конференции SQA Days-12, 30 ноября-1 декабря, Минск
Управление качеством в Agile. Как опередить баги
Управление качеством в Agile. Как опередить баги
SQALab
1. Цель презентации: • Побудить аудиторию пользоваться описанными техниками, которые могут помочь уменьшить количество «фейлов» со стороны QA команды в Agile-based проектах. • Сфокусировать внимание на «фишках» которые особенно пропагандируются в Agile, которые помогают выпускать более качественный продукт 2. Какова практическая ценность презентации для аудитории: • Поделиться конкретным опытом использования всяческих Agile-техник : Sprint Planning на основе QA оценок, Создание командного Vision-a на основе Product Canvas, First Release Baseline • Поделиться некоторыми hint-ами когда ты вроде бы test team lead, но по факту менеджишь еще и команду разработки. 3. Для кого предназначена: • QA которые уже работали по Agile (Scrum в частности) • Начинающие ПМs и QA Team Leads • Ребята которым скоро придется лидать Agile-проекты 4. Короткий план презентации по шагам: • Чего могут жать от работы QA команды к зависимости от специфики проекта\компании • Чего ожидают от QA в Agile • Какие техники могут помочь выпустить более правильный\успешный\ качественный продукт o Как формировать у команды общий Vision и как это помогает снижать дефекты в продукте o Как планировать спринт отталкиваясь от QA-команды чтобы снизить овертаймы o Как First Release Baseline помогает спланировать регрессию, когда совсем не осталось на нее времени
Anton Stoliar SQADays2012 Управление качеством в Agile. Как опередить баги.
Anton Stoliar SQADays2012 Управление качеством в Agile. Как опередить баги.
Anton Stoliar
Бизнес требует от ИТ постоянно ускорять обороты. Сроки выхода на рынок постоянно сокращаются. Применение гибких методологий в небольшой команде позволяет значительно уменьшить Time-to-Market. Однако в крупной компании прямое использование Agile/Scrum затруднено: даже простое на первые взгляд изменение бизнес процесса может затрагивать несколько систем, за которые отвечают разные команды. Выпуск релиза приходится координировать с большим количеством заинтересованных лиц. Это сильно замедляет и проектирование и финальное интеграционное тестирование. В результате добиться снижения Time-to-Market кажется очень непростой задачей, осложненной к тому же непростой политической ситуацией, типичной для крупной организации. Мы поговорим о системном подходе к снижению Time-to-Market для сложных задач координации релиза, характерных для крупных организаций
Практики масштабирования гибкой разработки
Практики масштабирования гибкой разработки
Askhat Urazbaev
Речь пойдёт всего лишь об одной, но очень важной метрике – времени, которое работа проводит в процессе. Рассмотрим с разных сторон – откуда и докуда мерить, почему, как это соотносится с Канбан-системами и ограничением работы в процессе, какие неожиданности могут поджидать? Почему эту метрику трудно перехитрить? Какие полезные вопросы с её помощью можно задать? О метриках привычно думать как о числах. Однако, «неудобная правда» состоит в том, что время в процессе это не число, а распределение вероятностей. Мы рассмотрим примеры таких распределений по разным видам работы, проектам и компаниям, и отметим новейшие открытия в данной области. Вы получите рекомендации, как использовать эту информацию для наладки обратных связей и принятия решений в Вашей компании. Для менеджеров рабочих групп и проектов, всех, кому приходится делать оценки и прогнозы, приоритезировать работу, и всех, кто хочет глубже вникнуть в вероятностною природу процессов умственного труда.
Алексей Жеглов, Время в Канбан-системе – что мы о нём знаем и как использовать
Алексей Жеглов, Время в Канбан-системе – что мы о нём знаем и как использовать
ScrumTrek
AgileCamp'12 Нижний Новгород: Введение
AgileCamp'12 Нижний Новгород: Введение
Anton Katkov
Crystal Agile, или как мы приспособили процесс разработки для обеспечения мак...
Crystal Agile, или как мы приспособили процесс разработки для обеспечения мак...
SQALab
Presentation to a talk on AgileDays 2016 - "Metrics in Agile Projects"
AgileDays 2016 - Metrics in Agile Projects
AgileDays 2016 - Metrics in Agile Projects
Svetlana Mukhina ICP, -ATF, -BVA, - ACC, PSM I, CSPO
Что такое тестирование в Agile на самом деле? Что понимается под гордым званием Agile Tester? Можно ли получить ответы на эти вопросы, скажем, в ISTQB? Удовлетворят ли нас полученные ответы? Актуален ли вопрос для рынка труда РБ? Существуют ли отделы Agile Test-ирования, требуются ли Agile Tester-ы в РБ? Мы постараемся все вместе проговорить выше перечисленные вопросы и сделать выводы, которые помогут нам делать правильный выбор, эффективно построить карьеру.
Agile Testing & Agile Tester
Agile Testing & Agile Tester
COMAQA.BY
Причины неудач внедрений. Место статического анализа в DevOps-процессе. Статический анализ – друг или враг. Рассылка результатов анализа. Что делать с 10 000 сообщений от анализатора при первом запуске? Сколько времени нужно для правки всех ошибок? Q&A, или что дальше?
Что DevOps должен знать про статический анализ кода?
Что DevOps должен знать про статический анализ кода?
Andrey Karpov
SQA Days 11. День 2. Cекция C Олег Ладыгин ЗАО "ПЕТЕР-СЕРВИС" Санкт-Петербург, Россия
Автоматизация сборки и тестирования в разрезе эффективного производства
Автоматизация сборки и тестирования в разрезе эффективного производства
SQALab
Доклад на Analyst Days был посвящен оценке аутсорсинговых проектов
Analyst days 2015 Оценка аутсорсинговых проектов
Analyst days 2015 Оценка аутсорсинговых проектов
Natalia Zhelnova
Доклад Натальи Желновой на конференции Analyst Days-4, 17-18 апреля 2015 г., Минск www.analystdays.com
Оценка аутсорсинговых проектов
Оценка аутсорсинговых проектов
SQALab
Weitere ähnliche Inhalte
Was ist angesagt?
Доклад Дарьи Шишковой на SQA Days-22. 17-18 ноября 2017. Санкт-Петербург, Россия www.sqadays.com
Автоматизация 0.0: 0 - бюджет, 0 - опыт программирования
Автоматизация 0.0: 0 - бюджет, 0 - опыт программирования
SQALab
Доклад Павла Стрункина на конференции SQA Days-20. 24-26 ноября 2016. Минск www.sqadays.com
Когда стоит закончить автоматизировать?
Когда стоит закончить автоматизировать?
SQALab
Алексей Пименов, ScrumTrek
Discovery Kanban для управления беклогом Scrum-команды
Discovery Kanban для управления беклогом Scrum-команды
CEE-SEC(R)
Таисия Рыбак, HPE
Как развить отдел тестирования от палки-копалки до CI
Как развить отдел тестирования от палки-копалки до CI
CEE-SEC(R)
Доклад Алексея Вихрова на конференции SQA Days-20. 24-26 ноября 2016. Минск www.sqadays.com
Тестирование слоёного пирога
Тестирование слоёного пирога
SQALab
Доклад Алексея Маслова на конференции SQA Days-19, 20-21 мая 2016 г., Санкт-Петербург
Нагрузка и автоматизация в большой организации. Движение к DevOps
Нагрузка и автоматизация в большой организации. Движение к DevOps
SQALab
Доклад Александра Башарина на конференции SQA Days-19, 20-21 мая 2016 г., Санкт-Петербург
QA как драйвер трансформации
QA как драйвер трансформации
SQALab
ALM & Agile
ALM & Agile
Askhat Urazbaev
В своем докладе я расскажу о том, как мы адаптировали процесс разработки, в команде, где упор делался на максимальное качество и при этом был всего 1 тестировщик. Доклад будет состоять из двух частей. В первой я расскажу как взяв за основу методологию Crystal Agile мы скомпоновали набор из необходимых нам практик, отсекая все лишнее и получили процесс полностью устраивающий команду, направленный на обеспечение максимального качества. В этой части будут подниматься следующие вопросы: •Какие практики наиболее ценны с точки зрения тестировщика •Как безболезненно добавить практики XP и Kanban в Scrum процесс •Как не отсечь лишнего -Как превратить скомпонованный набор практик в работающий подход Вторая часть доклада будет посвящена непосредственно тому, как облегчить жизнь единственного тестировщика на большом проекте, в частности будут рассмотрены такие вопросы? •Как научить заказчика писать требования •Быстрое создание и поддержка тестовой документации, миф или реальность? •Быстрое внедрение автоматизации •Тестирование нефункциональных требований
QA Fest 2014. Игорь Бондаренко. Agile crystal. Создание процесса нацеленного ...
QA Fest 2014. Игорь Бондаренко. Agile crystal. Создание процесса нацеленного ...
QAFest
В презентации рассматриваются вопросы настройки процесса разработки программного обеспечения
Гибкость, возведенная в абсолют
Гибкость, возведенная в абсолют
amirutov
Доклад Антона Столяра на конференции SQA Days-12, 30 ноября-1 декабря, Минск
Управление качеством в Agile. Как опередить баги
Управление качеством в Agile. Как опередить баги
SQALab
1. Цель презентации: • Побудить аудиторию пользоваться описанными техниками, которые могут помочь уменьшить количество «фейлов» со стороны QA команды в Agile-based проектах. • Сфокусировать внимание на «фишках» которые особенно пропагандируются в Agile, которые помогают выпускать более качественный продукт 2. Какова практическая ценность презентации для аудитории: • Поделиться конкретным опытом использования всяческих Agile-техник : Sprint Planning на основе QA оценок, Создание командного Vision-a на основе Product Canvas, First Release Baseline • Поделиться некоторыми hint-ами когда ты вроде бы test team lead, но по факту менеджишь еще и команду разработки. 3. Для кого предназначена: • QA которые уже работали по Agile (Scrum в частности) • Начинающие ПМs и QA Team Leads • Ребята которым скоро придется лидать Agile-проекты 4. Короткий план презентации по шагам: • Чего могут жать от работы QA команды к зависимости от специфики проекта\компании • Чего ожидают от QA в Agile • Какие техники могут помочь выпустить более правильный\успешный\ качественный продукт o Как формировать у команды общий Vision и как это помогает снижать дефекты в продукте o Как планировать спринт отталкиваясь от QA-команды чтобы снизить овертаймы o Как First Release Baseline помогает спланировать регрессию, когда совсем не осталось на нее времени
Anton Stoliar SQADays2012 Управление качеством в Agile. Как опередить баги.
Anton Stoliar SQADays2012 Управление качеством в Agile. Как опередить баги.
Anton Stoliar
Бизнес требует от ИТ постоянно ускорять обороты. Сроки выхода на рынок постоянно сокращаются. Применение гибких методологий в небольшой команде позволяет значительно уменьшить Time-to-Market. Однако в крупной компании прямое использование Agile/Scrum затруднено: даже простое на первые взгляд изменение бизнес процесса может затрагивать несколько систем, за которые отвечают разные команды. Выпуск релиза приходится координировать с большим количеством заинтересованных лиц. Это сильно замедляет и проектирование и финальное интеграционное тестирование. В результате добиться снижения Time-to-Market кажется очень непростой задачей, осложненной к тому же непростой политической ситуацией, типичной для крупной организации. Мы поговорим о системном подходе к снижению Time-to-Market для сложных задач координации релиза, характерных для крупных организаций
Практики масштабирования гибкой разработки
Практики масштабирования гибкой разработки
Askhat Urazbaev
Речь пойдёт всего лишь об одной, но очень важной метрике – времени, которое работа проводит в процессе. Рассмотрим с разных сторон – откуда и докуда мерить, почему, как это соотносится с Канбан-системами и ограничением работы в процессе, какие неожиданности могут поджидать? Почему эту метрику трудно перехитрить? Какие полезные вопросы с её помощью можно задать? О метриках привычно думать как о числах. Однако, «неудобная правда» состоит в том, что время в процессе это не число, а распределение вероятностей. Мы рассмотрим примеры таких распределений по разным видам работы, проектам и компаниям, и отметим новейшие открытия в данной области. Вы получите рекомендации, как использовать эту информацию для наладки обратных связей и принятия решений в Вашей компании. Для менеджеров рабочих групп и проектов, всех, кому приходится делать оценки и прогнозы, приоритезировать работу, и всех, кто хочет глубже вникнуть в вероятностною природу процессов умственного труда.
Алексей Жеглов, Время в Канбан-системе – что мы о нём знаем и как использовать
Алексей Жеглов, Время в Канбан-системе – что мы о нём знаем и как использовать
ScrumTrek
AgileCamp'12 Нижний Новгород: Введение
AgileCamp'12 Нижний Новгород: Введение
Anton Katkov
Crystal Agile, или как мы приспособили процесс разработки для обеспечения мак...
Crystal Agile, или как мы приспособили процесс разработки для обеспечения мак...
SQALab
Presentation to a talk on AgileDays 2016 - "Metrics in Agile Projects"
AgileDays 2016 - Metrics in Agile Projects
AgileDays 2016 - Metrics in Agile Projects
Svetlana Mukhina ICP, -ATF, -BVA, - ACC, PSM I, CSPO
Что такое тестирование в Agile на самом деле? Что понимается под гордым званием Agile Tester? Можно ли получить ответы на эти вопросы, скажем, в ISTQB? Удовлетворят ли нас полученные ответы? Актуален ли вопрос для рынка труда РБ? Существуют ли отделы Agile Test-ирования, требуются ли Agile Tester-ы в РБ? Мы постараемся все вместе проговорить выше перечисленные вопросы и сделать выводы, которые помогут нам делать правильный выбор, эффективно построить карьеру.
Agile Testing & Agile Tester
Agile Testing & Agile Tester
COMAQA.BY
Причины неудач внедрений. Место статического анализа в DevOps-процессе. Статический анализ – друг или враг. Рассылка результатов анализа. Что делать с 10 000 сообщений от анализатора при первом запуске? Сколько времени нужно для правки всех ошибок? Q&A, или что дальше?
Что DevOps должен знать про статический анализ кода?
Что DevOps должен знать про статический анализ кода?
Andrey Karpov
Was ist angesagt?
(19)
Автоматизация 0.0: 0 - бюджет, 0 - опыт программирования
Автоматизация 0.0: 0 - бюджет, 0 - опыт программирования
Когда стоит закончить автоматизировать?
Когда стоит закончить автоматизировать?
Discovery Kanban для управления беклогом Scrum-команды
Discovery Kanban для управления беклогом Scrum-команды
Как развить отдел тестирования от палки-копалки до CI
Как развить отдел тестирования от палки-копалки до CI
Тестирование слоёного пирога
Тестирование слоёного пирога
Нагрузка и автоматизация в большой организации. Движение к DevOps
Нагрузка и автоматизация в большой организации. Движение к DevOps
QA как драйвер трансформации
QA как драйвер трансформации
ALM & Agile
ALM & Agile
QA Fest 2014. Игорь Бондаренко. Agile crystal. Создание процесса нацеленного ...
QA Fest 2014. Игорь Бондаренко. Agile crystal. Создание процесса нацеленного ...
Гибкость, возведенная в абсолют
Гибкость, возведенная в абсолют
Управление качеством в Agile. Как опередить баги
Управление качеством в Agile. Как опередить баги
Anton Stoliar SQADays2012 Управление качеством в Agile. Как опередить баги.
Anton Stoliar SQADays2012 Управление качеством в Agile. Как опередить баги.
Практики масштабирования гибкой разработки
Практики масштабирования гибкой разработки
Алексей Жеглов, Время в Канбан-системе – что мы о нём знаем и как использовать
Алексей Жеглов, Время в Канбан-системе – что мы о нём знаем и как использовать
AgileCamp'12 Нижний Новгород: Введение
AgileCamp'12 Нижний Новгород: Введение
Crystal Agile, или как мы приспособили процесс разработки для обеспечения мак...
Crystal Agile, или как мы приспособили процесс разработки для обеспечения мак...
AgileDays 2016 - Metrics in Agile Projects
AgileDays 2016 - Metrics in Agile Projects
Agile Testing & Agile Tester
Agile Testing & Agile Tester
Что DevOps должен знать про статический анализ кода?
Что DevOps должен знать про статический анализ кода?
Ähnlich wie Kanbanize
SQA Days 11. День 2. Cекция C Олег Ладыгин ЗАО "ПЕТЕР-СЕРВИС" Санкт-Петербург, Россия
Автоматизация сборки и тестирования в разрезе эффективного производства
Автоматизация сборки и тестирования в разрезе эффективного производства
SQALab
Доклад на Analyst Days был посвящен оценке аутсорсинговых проектов
Analyst days 2015 Оценка аутсорсинговых проектов
Analyst days 2015 Оценка аутсорсинговых проектов
Natalia Zhelnova
Доклад Натальи Желновой на конференции Analyst Days-4, 17-18 апреля 2015 г., Минск www.analystdays.com
Оценка аутсорсинговых проектов
Оценка аутсорсинговых проектов
SQALab
Agile тестирование в enterpise проектов: путь трансформации
Agile тестирование в enterpise проектов: путь трансформации
Andrey Rebrov
Автоматизируем процесс тестирования.
Enter: testing
Enter: testing
Kamil Samigullin
IT-шная история игрушек или feature-driven тестирование в действии
IT-шная история игрушек или feature-driven тестирование в действии
Gleb Rybalko
Наталья Руколь (Лаборатория Качества)
Наталья Руколь (Лаборатория Качества)
Ontico
андрей дмитриев взгляд со стороны разработчика
андрей дмитриев взгляд со стороны разработчика
Alexei Lupan
Презентация доклада на конференции WhaleRider 2010
О чем молчит Scrum. Whalerider 2010
О чем молчит Scrum. Whalerider 2010
Artem Volftrub
Презентация посвящена вопросам измерений в программной инженерии.
Measurement in software development
Measurement in software development
amirutov
Process Quality, QA and QC. QA Club. Kharkov. Ukraine
Process Quality, QA and QC. QA Club. Kharkov. Ukraine
Sergiy Povolyashko
Process Quality, QA and QC. QA Club. Kharkov. Ukraine
Process Quality, QA and QC. QA Club. Kharkov. Ukraine
Sergiy Povolyashko, PMP
Какие вопросы встают перед руководителем разработки? Что нужно анализировать для успешного решения задач и запуска проектов? Как меняются вопросы, когда тим-лид дорастает до руководства департаментом?
Наблюдай. Анализируй. Управляй
Наблюдай. Анализируй. Управляй
Max Babich
презентация с выступления на Luxoft LoGeek
Метрики в Agile проектах
Метрики в Agile проектах
LuxoftAgilePractice
Logeek Night Kiev - February, 4
Светлана Мухина "Metrics on agile projects"
Светлана Мухина "Metrics on agile projects"
Anna Shymchenko
presentation for a talk on logeek night
Metrics on Agile Projects
Metrics on Agile Projects
Svetlana Mukhina ICP, -ATF, -BVA, - ACC, PSM I, CSPO
Я думаю, что чем сложнее метрика, тем проще ее подвести под необходимые результаты. Зачастую достаточно немного исказить одно не самое важное значение в формуле расчета и в итоге на больших числах можно получить приличное искажение. С помощью визуализации метрик тоже можно оказывать влияние и изменять мнение в необходимую вам сторону. И тут возникает вопрос #2 - "Что делать?" Использовать или не использовать метрики. Возможно, вы найдете для себя ответ на этот вопрос в моем докладе про очень простые метрики: -capacity - кол-во идеальных часов доступное в итерацию; -velocity - количество сделанной работы в стори поинтах или других "попугаях"; -burn-down - прогресс команды на данный момент, сколько сделали и сколько осталось; -индекс стабильности требований - как часто меняются требования; И еще поделюсь своим мнением о том, какая может быть польза команде от заполнения системы учета времени; Я расскажу, как мы собираем эти метрики на проектах и что нам это дает. Например, иногда они помогают найти ответ на вопрос #1 "Кто виноват?" (это шутка).
Светлана Мухина, Метрики в Agile проектах
Светлана Мухина, Метрики в Agile проектах
ScrumTrek
Презентация доклада на AgileDays - Метрики в Agile проек
AgileDays 2016 - Метрики в Agile проек
AgileDays 2016 - Метрики в Agile проек
LuxoftAgilePractice
Четвертый доклад Конференции Докладчик Ребров Андрей, инженерный тренер ScrumTrek.
Практика DevOps в крупных организациях
Практика DevOps в крупных организациях
Softmart
Доклад Александра Белова об управлении распределенными проектами вызвал огромный интерес участников на проходившей в Санкт-Перербурге первой независимой профессиональной конференции INFOSTART EVENT 2012.
Управляемое внедрение. Основы управления распределенными программными проекта...
Управляемое внедрение. Основы управления распределенными программными проекта...
Cергей Мартынов
Ähnlich wie Kanbanize
(20)
Автоматизация сборки и тестирования в разрезе эффективного производства
Автоматизация сборки и тестирования в разрезе эффективного производства
Analyst days 2015 Оценка аутсорсинговых проектов
Analyst days 2015 Оценка аутсорсинговых проектов
Оценка аутсорсинговых проектов
Оценка аутсорсинговых проектов
Agile тестирование в enterpise проектов: путь трансформации
Agile тестирование в enterpise проектов: путь трансформации
Enter: testing
Enter: testing
IT-шная история игрушек или feature-driven тестирование в действии
IT-шная история игрушек или feature-driven тестирование в действии
Наталья Руколь (Лаборатория Качества)
Наталья Руколь (Лаборатория Качества)
андрей дмитриев взгляд со стороны разработчика
андрей дмитриев взгляд со стороны разработчика
О чем молчит Scrum. Whalerider 2010
О чем молчит Scrum. Whalerider 2010
Measurement in software development
Measurement in software development
Process Quality, QA and QC. QA Club. Kharkov. Ukraine
Process Quality, QA and QC. QA Club. Kharkov. Ukraine
Process Quality, QA and QC. QA Club. Kharkov. Ukraine
Process Quality, QA and QC. QA Club. Kharkov. Ukraine
Наблюдай. Анализируй. Управляй
Наблюдай. Анализируй. Управляй
Метрики в Agile проектах
Метрики в Agile проектах
Светлана Мухина "Metrics on agile projects"
Светлана Мухина "Metrics on agile projects"
Metrics on Agile Projects
Metrics on Agile Projects
Светлана Мухина, Метрики в Agile проектах
Светлана Мухина, Метрики в Agile проектах
AgileDays 2016 - Метрики в Agile проек
AgileDays 2016 - Метрики в Agile проек
Практика DevOps в крупных организациях
Практика DevOps в крупных организациях
Управляемое внедрение. Основы управления распределенными программными проекта...
Управляемое внедрение. Основы управления распределенными программными проекта...
Kanbanize
1.
2.
Кто я?
3.
4.
5.
6.
Maintenance in Telecom
7.
7 Разработчиков 4 Тестировщика
(точнее,тестировщицы) 1 Интегратор
8.
Разработчик:
по 50 часов на баг Тестировщик: по 6 часов на баг Интегратор: по 4 часа на баг
9.
При 160 часах
в месяц: 23 Fixes / Месяц Стоимость фикса 60 часов
10.
KPI
11.
Стоимость фикса Скорость ответа
12.
Стоимость фикса
Фикс предложен != Сделано
13.
60 часов
14.
15.
16.
17.
18.
Фикс предложен
== Сделано
19.
60 часов ->
30 часов
20.
Okay
21.
Время фикса находится примерно
в одинаковых пределах
22.
Система статистически
стабильна
23.
с 99% вероятностью
24.
проблема в системе
25.
Куча багов на разработчике
26.
27.
Сложно следить кто
чем занимается в real time
28.
Мало митингов
29.
30.
Почему Канбан
31.
32.
33.
34.
Теория ограничений
35.
Шухарт, Деминг, Голдратт
36.
Value Stream Mapping
37.
Деревья текущей действительности Деревья
будущей реальности
38.
Lean != Agile
39.
Знаний для практики
стало достаточно
40.
Нет сложности
41.
Легко и быстро объясняется
команде
42.
Простота встраивания
в текущие процессы
43.
Дешево
44.
Стоимость интеграции Стоимость
необходимого окружения Стоимость времени команды
45.
Для статистически стабильных систем
46.
Визуализация Минимизация WIP Уменьшение времени
цикла
47.
Визуализация
48.
Стикеры для обозначения багов
49.
50.
Доска
51.
52.
53.
54.
Минимизация WIP
55.
7
4 1
56.
Оптимизация времени цикла
57.
Lead time
!= Cycle time
58.
59.
Cycle time
60.
61.
62.
Supplier закрыт от нас
и не виден Заказчику
63.
Так нас попросили
64.
65.
Lead Time
66.
67.
Разборки с Supplier’ом
68.
Обнаружились косяки
69.
Другой WoW
70.
Другие KPI
71.
Другой бюджет
72.
73.
Выяснили количество разработчиков у Supplier’a
и примерный бюджет
74.
75.
Приоритезация
76.
77.
78.
Результаты внедрения
79.
Разработчик:
по 50 часов на баг Тестировщик: по 6 часов на баг Интегратор: по 4 часа на баг
80.
Разработчик:
по 22 часа на баг Тестировщик: по 4 часа на баг Интегратор: по 4 часа на баг
81.
60 vs 30
82.
Освободившиеся ресурсы
83.
Дополнительные
релизы (на 30% больше)
84.
Уменьшение времени
фикса от Supplier’а в 1,5 раза
85.
86.
Visibility
87.
Visibility Daily Stand-up
88.
Visibility Daily Stand-up Bottlenecks finders
& Improvements
89.
Ускорение работы команды
90.
Мотивация команды
91.
92.
Проблемы
93.
Доска пробковая!
94.
95.
LeadСycle time тяжело
считать
96.
Канбан как процесс
стал забываться
97.
Или интегрировался на ментальном
уровне в команде
98.
Не подходит для
Development
99.
Фичи разные по
размерам и сложности
100.
Development не статистически
стабильная система
101.
Рушит подсчеты и
оптимизацию Lead/Cycle time
102.
Канбан оказался решением
конкретных проблем
103.
104.
Questions?
Jetzt herunterladen