работа содержит описание метода Agile Scrum в проектах внедрения корпоративных информационных систем на базе SAP. Рассматриваются вопросы применения Scrum в проектах развития, тиражирования и внедрения «с нуля» решений SAP, а также использования гибкой методологии Agile для разработки и кастомизации информационных систем. Сделан вывод о целесообразности применения метода Scrum в проектах развития SAP-систем путём доработки.
Примеры различных информационных стендов которые помогают вовлекать команды к решению проблем и внедрению методов lean six sigma, TPM, SMED и так далее
Позволяют ли метрики эффективно управлять проектом: диагностировать проблемы, локализовать их, исправлять и проверять? Как использовать метрики с максимальной результативностью?
Test strategy - what it is and what differs from the test plan;
No one canceled Waterfall or how we got to SCRUM;
Large and small test activity cycles: Small activity (testing -> QC), Large (QC -> QA);
What is the actual benefit of adhering to the strategy;
The lecture will be useful for testing specialists, team leaders and those who want to organize testing in their team.
работа содержит описание метода Agile Scrum в проектах внедрения корпоративных информационных систем на базе SAP. Рассматриваются вопросы применения Scrum в проектах развития, тиражирования и внедрения «с нуля» решений SAP, а также использования гибкой методологии Agile для разработки и кастомизации информационных систем. Сделан вывод о целесообразности применения метода Scrum в проектах развития SAP-систем путём доработки.
Примеры различных информационных стендов которые помогают вовлекать команды к решению проблем и внедрению методов lean six sigma, TPM, SMED и так далее
Позволяют ли метрики эффективно управлять проектом: диагностировать проблемы, локализовать их, исправлять и проверять? Как использовать метрики с максимальной результативностью?
Test strategy - what it is and what differs from the test plan;
No one canceled Waterfall or how we got to SCRUM;
Large and small test activity cycles: Small activity (testing -> QC), Large (QC -> QA);
What is the actual benefit of adhering to the strategy;
The lecture will be useful for testing specialists, team leaders and those who want to organize testing in their team.
В рамках доклада будут рассмотрены основы Теории ограничений, применимость Теории ограничений при разработке ПО, а также будут рассмотрены практические примеры оптимизации процесса разработки.
Extensive experience in delivering world-class business solutions enabled Luxoft to become a leader in providing educational service in Agile methodologies.
Luxoft is accredited as a Member Training Organization (MTO) of the International Consortium for Agile (ICAgile). ICAgile develops educational tracks and learning objectives for its member training classes and authorizes course materials for covering a particular set of topics.
Trainings are conducted by certified instructors and include exercises and games aimed at better understanding the topics covered and finding the best ways to adopt them into practice.
Блок-схема - это графическое отображение процесса, которое четко показывает, как протекает процесс. Блок-схема показывает систематическую последовательность этапов выполнения работы и то, какие ресурсы (люди, материал, машины…) вовлечены в процесс.
Скачать презентацию Вы можете перейдя по ссылке: http://sixsigmaonline.ru/load/16-1-0-4
Как оценить процесс тестирования на проектеCOMAQA.BY
Тестирование - это процесс, он не стоит на месте, а нуждается в непрерывном улучшении. Мы приходим к ним на ретроспективах, из собственного и чужого опыта и ошибок, интуитивно или на основании некоторых данных. В своем докладе я расскажу, как провести оценку процесса тестирования на проекте: с чего начать, на что обратить внимание, поделюсь практическим опытом и отвечу на ваши вопросы. До встречи на докладе!
Презентация доклада Максима Дроздова, менеджера проектов компании "ИСС Арт" "Контроль над распределенной командой".
Вебинар "Управление удаленной командой разработчиков".
В рамках доклада будут рассмотрены основы Теории ограничений, применимость Теории ограничений при разработке ПО, а также будут рассмотрены практические примеры оптимизации процесса разработки.
Extensive experience in delivering world-class business solutions enabled Luxoft to become a leader in providing educational service in Agile methodologies.
Luxoft is accredited as a Member Training Organization (MTO) of the International Consortium for Agile (ICAgile). ICAgile develops educational tracks and learning objectives for its member training classes and authorizes course materials for covering a particular set of topics.
Trainings are conducted by certified instructors and include exercises and games aimed at better understanding the topics covered and finding the best ways to adopt them into practice.
Блок-схема - это графическое отображение процесса, которое четко показывает, как протекает процесс. Блок-схема показывает систематическую последовательность этапов выполнения работы и то, какие ресурсы (люди, материал, машины…) вовлечены в процесс.
Скачать презентацию Вы можете перейдя по ссылке: http://sixsigmaonline.ru/load/16-1-0-4
Как оценить процесс тестирования на проектеCOMAQA.BY
Тестирование - это процесс, он не стоит на месте, а нуждается в непрерывном улучшении. Мы приходим к ним на ретроспективах, из собственного и чужого опыта и ошибок, интуитивно или на основании некоторых данных. В своем докладе я расскажу, как провести оценку процесса тестирования на проекте: с чего начать, на что обратить внимание, поделюсь практическим опытом и отвечу на ваши вопросы. До встречи на докладе!
Презентация доклада Максима Дроздова, менеджера проектов компании "ИСС Арт" "Контроль над распределенной командой".
Вебинар "Управление удаленной командой разработчиков".
Доклад на открытом форуме PMI о том, что такое Business Agility и к каким изменениям в организации оно ведет.
https://www.youtube.com/watch?v=ZfLqWwDp5QQ&feature=youtu.be&t=22465
Статегия agile-трансформации крупной компанииAskhat Urazbaev
Достаточно ли обойтись внедрением Agile-практик на уровне Scrum/XP или для успешной работы нужно нечто большее?
Опыт показывает, что существование в компании Agile только как методологии для команд приводит к слабому и часто кратковременному эффекту повышения производительности. Порой это дисбалансирует компанию и приводит к результатам даже хуже, чем были до внедрения Agile.
Для получения максимального результата изменения в культуре организации необходимы на всех уровнях.
Что это означает на практике и как этого добится?
В этом выступлении мы обсудим подходы проведения Agile-трансформации в больших организациях. Мы рассмотрим практики которые работают в российских корпорациях, а также типичные ловушки и грабли на которые вы можете наступить при старте изменений.
Миф об Agile как это работает в реальности / Анатолий Стояновский (ТАСС)Ontico
Считается, что гибкие методологии и управление компанией — это ответ на нынешнюю эпоху быстрых изменений. По-разному, но agile-подходы нужны всем: стартапам, высокотехнологичным компаниям, крупным неповоротливым компаниям. Есть компании, которые построены по этой философии изначально, но если отбросить победные отчеты о том, как хорошо иметь возможность менять продукты компании в любую сторону в любой момент времени, то за ней часто можно увидеть трагедии команд, потерявших ориентиры, фрагментировавших свои продукты тысячей мелких изменений. Или наоборот, крупные компании увлекаются миграцией в гибкие методологии. И оказывается, что пусть неэффективная, но работающая система ломается и превращается в трагедию всей компании.
Получается, гибкие подходы — это не панацея и не решение, а замена шила на мыло? Методологи agile ответят, что он просто внедрен неправильно, и даже будут по-своему правы. Но проблема эффективности или неэффективности лежит выше agile, она в области корпоративного управления в целом. Много ли на самом деле экспертов, способных анализировать и управлять ситуацией в комплексе? И, вообще, насколько agile может быть эффективно встроен в остальные управленческие процессы?
Андрей Войнов. Трансформация по Agile: почему не работает классическое управл...ScrumTrek
Почему не работает классическое управление, основанное на иерархии, постановке задач и контроле их исполнения. Примеры того, в какие ловушки попадает организация и руководители, исповедующие традиционные методы менеджмента, и какие практики Agile позволяют избежать этих ошибок, сделать управление быстрее, дешевле и эффективнее. Доклад основан на практическом опыте организации управления по Agile в крупной IT-компании.
Доклад предназначен для руководителей среднего и высшего звена.
Как не собрать все грабли при Agile трансформации компании?Alexey Voronin
Agile хайп делает свое дело: многие компании от крупных банков до растущих стартапов ринулись трансформироваться в Agile. Но все так или иначе наступают на грабли: Нужно ли менять организационную структуру компании или не стоит? В какой момент это делать? Если менять, то как? Есть ли какие-то шаблоны или нужно использовать другие подходы? Как формировать Agile команды? Довериться мнению бизнеса, функциональных руководителей IT? Я расскажу о нетривиальных проблемах, в решении которых я участвовал за предыдущий год в крупных компаниях (количество команд >= 5), и, конечно же, о решениях.
Scrum, Kanban, XP, Crystal и прочие еще более редкие фреймворки и методы, что обещают Вам стать agile, уже давно опробованы, как в чистом виде, так и в составе ядерных коктейлей а воз и ныне там. Ваши отделы, продуктовые группы и вся компания целиком все так же далеки от того, чтобы быть agile. Меж тем верхи действительно хотят, а низы однозначно могут и даже обратное все так же верно. Так в чем же дело? В рамках этого доклада мы попытаемся ответить на этот вопрос. Будем говорить о разной степени важности тех или иных элементов больших agile-трансформаций, их влиянии друг на друга и правильно расставленных акцентах и приоритетах. В конце, как обычно, секретный ингредиент успеха.
6-7 июня на мероприятии Startup Village в Сколково прошла серия митапов, организованных совместно Сбербанком и СберТехом. Вашему вниманию - серия презентационных материалов с мероприятия.
Фреймворк Scrum
Основные понятия фреймворка
Преимущества и недостатки фреймворка
Артефакты Scrum
Роли в Scrum
Event - ы в Scrum
Работа с Backlog. Приоритезация задач
Планирование и мониторинг спринта
Выбор методологии для проекта:
Подходы
Рекомендации
Постановка и улучшение скрам процесса для группы проектов в большой компании,...viktor_bezhenar
Презентация с конференции Lviv PM Day весны 2014 года:
- Что мешает организациям начать использовать гибкие методологии и почему это сложно?
- Преобразование методологий разработки портфеля проектов к Scrum методологии с помощью ЕТС (enterprise transition community - сообщество по изменениям на предприятии):
* наш путь
* его пересечение с моделью Майка Кона и работа по модели
* обязанности и методы работы ЕТС
Creative or competitor analysis? How important is analytics when choosing tasks? How often to update backlog? On what period it should be? Oleg gives answers to these and other relevant questions related to backlog filling.
Светлана Мухина, Метрики в Agile проектахScrumTrek
Я думаю, что чем сложнее метрика, тем проще ее подвести под необходимые результаты. Зачастую достаточно немного исказить одно не самое важное значение в формуле расчета и в итоге на больших числах можно получить приличное искажение. С помощью визуализации метрик тоже можно оказывать влияние и изменять мнение в необходимую вам сторону. И тут возникает вопрос #2 - "Что делать?" Использовать или не использовать метрики. Возможно, вы найдете для себя ответ на этот вопрос в моем докладе про очень простые метрики: -capacity - кол-во идеальных часов доступное в итерацию; -velocity - количество сделанной работы в стори поинтах или других "попугаях"; -burn-down - прогресс команды на данный момент, сколько сделали и сколько осталось; -индекс стабильности требований - как часто меняются требования; И еще поделюсь своим мнением о том, какая может быть польза команде от заполнения системы учета времени; Я расскажу, как мы собираем эти метрики на проектах и что нам это дает. Например, иногда они помогают найти ответ на вопрос #1 "Кто виноват?" (это шутка).
Гибкие подходы перестали работать! По крайне мере, если судить по многочисленным публикациям, которые все чаще и чаще стали появляться. У кого-то не работает Scrum, у кого-то не прижился Канбан и, вообще, Agile не работает. В своем докладе я также приведу несколько примеров критики Agile в виде статей и докладов, разберу типичные заблуждения и ошибки, которыми оперируют критики.
Если использовать модель жизненного цикла принятия инноваций, можно спрогнозировать, что число такого негатива будет расти, потому что в России Agile начинают использовать не только инноваторы и ранние последователи, но и раннее большинство, которому трудно грамотно внедрить Agile и стать действительно гибкими.
Опытные управленцы, которые владеют гибкими подходами, обычно посмеиваются над этим негативом и пересказывают друг другу как анекдоты, а это как раз и есть та пропасть, которую Джеффри Мур описал в своей книге. Дополнительно мы обсудим, где сейчас находится Agile с точки зрения цикла зрелости технологий, так как эта модель тоже объясняет неудачный опыт использования Agile.
Agile-сообществу важно дальше вовлекать и помогать развиваться тем, кто пытается сделать свою команды, отдел или целую компанию гибкой.
В длительной перспективе ретроспективы – самая важная часть гибких процессов. Но очень часто у команд не получается запустить процесс непрерывного улучшения, либо через некоторое время этот процесс обрывается, когда команда думает, что все проблемы решены. Я расскажу не только теоритическую часть, которая позволит преодолеть эти проблемы, но и дам несколько десятков примеров конкретных практик, которые применяются на эффективных ретроспективах. Доклад рассчитан, как на начинающих ретроспективы, так и практиков гибких методологий.
1. Как внедрить Agile за 14 недель<br />Вольфсон БорисВерсия 0.3 (альфа)<br />Содержание TOC quot;
1-2quot;
<br />Введение PAGEREF _Toc306189680 2<br />Принципы внедрения PAGEREF _Toc306189681 3<br />Цикл Деминга (PDCA-цикл) PAGEREF _Toc306189682 3<br />Shu Ha Ri PAGEREF _Toc306189683 3<br />График и содержание внедрения PAGEREF _Toc306189684 4<br />Неделя №1 (подготовка к трансформации) PAGEREF _Toc306189685 4<br />Неделя №2 (нулевой спринт) PAGEREF _Toc306189686 4<br />Неделя №3 (старт первого «калибровочного» спринта) PAGEREF _Toc306189687 4<br />Неделя №4 (завершение первого «калибровочного» спринта) PAGEREF _Toc306189688 5<br />Неделя №5 (старт второго спринта) PAGEREF _Toc306189689 5<br />Неделя №6 (завершение второго спринта) PAGEREF _Toc306189690 5<br />Неделя №7 (старт третьего спринта) PAGEREF _Toc306189691 5<br />Неделя №8 (завершение третьего спринта) PAGEREF _Toc306189692 6<br />Неделя №9 (старт четвертого спринта) PAGEREF _Toc306189693 6<br />Неделя №10 (завершение четвертого спринта) PAGEREF _Toc306189694 6<br />Неделя №11 (старт пятого спринта) PAGEREF _Toc306189695 6<br />Неделя №12 (завершение пятого спринта) PAGEREF _Toc306189696 6<br />Неделя №13 (старт шестого «идеального» спринта) PAGEREF _Toc306189697 7<br />Неделя №14 (завершение «идеального» шестого спринта) PAGEREF _Toc306189698 7<br />Введение<br />Основная цель составления данного плана по внедрению Agile: дать четкую и краткую инструкцию по трансформации компании/подразделения в гибкую и эффектную бизнес-единицу по производству программного обеспечения.<br />План рассчитан на небольшие компании размером примерно от 20 до 50 человек и нуждается в адаптации под конкретную компанию. Для компаний (или отдельных команд) меньшего размера, можно использовать этот же план за исключением масштабирования методологий. <br />Будем считать, что в компании по исторически сложившимся обстоятельствам используется «методология» Code&Fix. В качестве допущений будем использовать следующие положения<br />длина спринта – 2 недели,<br />длина релиза фиксирована – 3 итерации,<br />внедрение Agile поддерживается руководством;<br />План внедрение рассчитан на то, чтобы не отрываться серьезно команды от производства, и сделать внедрение управленческих и технологических инноваций частью корпоративной культуры компании.<br />453453570739000Предполагается, что организацией внедрения будет заниматься один человек, работая полный день над этой задачей. Это может быть как внешний тренер/консультант, так и внутренний эксперт-внедренец. <br />Автор: Вольфсон Борис <br />http://www.facebook.com/borisvolfson<br />http://twitter.com/borisvolfson<br />borisvolfson@gmail.com <br />Благодарности за замечания и предложения:<br />Дмитрий Паньшин <br />Михаил Подурец<br />Сергей Рогачев<br />Андрей Свердлов<br />Евгений Сорокин<br />Принципы внедрения<br />Цикл Деминга (PDCA-цикл)<br />При организационных изменениях очень помогает использования здравого смысла и научного подхода. Традиционным методом в данном случае является цикл Деминга, который состоит из 4 шагов:<br />302958524574500Plan (планирование)Производится анализ системы и вырабатываются возможные подходы к улучшениям и определяются желаемые результаты<br />Do (исполнение)Решения, выработанные на предыдущем шаге, реализуются.<br />Check (проверка)Производится анализ, полученных результатов, на предыдущем шаге.<br />Act (корректировка)Выполняются корректирующие действия, для уменьшения отклонений от плана.<br />Shu Ha Ri<br />Внедрение методологии и практик можно разбить на три этапы, и важно, чтобы компания и отдельные команды их прошли, не застряв на одном из них. Названия<br />Shu (守:しゅ – «защита», «подчинение») — изучение традиционной мудрости — изучение методологии, работа строго по книжкам, руководствуясь предписаниями тренера/внедренца.<br />Ha (破:は - “отделение”, “отклонение”) — отступление от традиции — понимание методологии на очень глубоком уровне и ее адаптация под требования проектов/бизнеса/внешней среды<br />Ri (離:り - “покидание”, “отделение”) — превосходство над традицией — осознанное отступление от методологии, например, переход со Scrum на Scrumban.<br />Важно, что необходимо пройти все этапы не перепрыгивая их: достаточно стандартная ситуация, когда команда, не может делать Scrum перепрыгивает на Kanban, что в итоге выливается в классический Code and Fix.<br />График и содержание внедрения<br />План состоит из трех частей:<br />Подготовка компании к трансформации: сбор и анализ информации, получение знаний и навыков сотрудниками компании.<br />Первый релиз: знакомство с основными элементами Scrum и Lean<br />Второй релиз: адаптация Agile к бизнесу компании <br />Неделя №1 (подготовка к трансформации)<br />Цели: собрать и проанализировать основную информацию о компании, дать основным участникам базовые знания об Agile<br />Изучение и описание текущих бизнес-процессов компании<br />Составление карты бизнес-процессов в графическом или текстовом виде, касающихся разработки ПО/веб-сайтов<br />Изучение проектов и организация их в портфель проектов<br />Составление списка с проектов<br />Разработка методологии приоритезации, принятия решений о запуске/завершения проектов<br />Приоритезация и балансировка портфеля проектов<br />Буткемп по основам Scrum (Однодневный тренинг по основам скрама с деловыми играми)<br />Каждый участник тренинга должен понимать роли, процессы и артефакты Scrum<br />Продвинутое обучение скрам-мастеров (4-х часовой тренинг)<br />Скрам-мастера должны получить дополнительные знания и навыки по процессам Scrum, навыки фасилитации и организации работы команд.<br />Продвинутое обучение владельцев продуктов (4 часовой тренинг)<br />Владельцы продуктов должны получить дополнительные знания и навыки по управлению продуктами (выявление ролей пользователей, проведение сторимаппинга, управление беклогом, управление релизами)<br />Неделя №2 (нулевой спринт)<br />Цели: выработать понимание продукта и создать высокоуровневую архитектуру<br />Исследование продукта<br />Выявление ролей и персонажей по проектам<br />Сторимаппинга<br />Прототипирование основных интерфейсов<br />Сессия для выявления основных рисков и выработки контрмер<br />Создание высокоуровневой архитектуры продукта<br />Выбор платформы реализации<br />Диаграмма предметной области / высокоуровневая диаграмма классов<br />Неделя №3 (старт первого «калибровочного» спринта)<br />Цели: отработать процессы по запуску спринта и проведению Scrum of Scrum<br />Старт первого спринта с командами<br />Проведение планирования спринта и разбиение юзер-стори на задачи<br />Проведение покер-планирования для оценки юзер-стори<br />Scrum of Scrum<br />Определение сроков проведения Scrum of Scrum<br />Проведение первого Scrum of Scrum<br />Отработка механизма эскалации проблем<br />Отработка механизма синхронизации деятельности команд<br />Неделя №4 (завершение первого «калибровочного» спринта)<br />Цели: отработать завершения спринта и провести ретроспективу на основе качественных показателей<br />Проведение демонстрации и получение фидбека<br />Ретроспектива (что было сделано хорошо, что было сделано плохо, список улучшений)<br />Определение эмпирически скорости команды<br />Неделя №5 (старт второго спринта)<br />Цели: отработать старт спринта и планирования на основе количественных показателей, начать внедрения базовых практики экстремального программирования<br />Планирование и старт второго спринта<br />Планируем исходя из скорости предыдущего спринта<br />Тренинг и мастер-класс по практикам экстремального программирования<br />Внедрение системы непрерывной интеграции: полная сборка продукта происходит автоматически и непрерывно<br />Выработка и внедрение стандартов кодирования<br />Неделя №6 (завершение второго спринта)<br />Цели: отработать завершения спринта и провести ретроспективу на основе количественных показателей, использую инструменты бережливого производства<br />Изучение практик и инструментов бережливого производства<br />Виды потерь при производстве<br />Value Stream Mapping для текущего процесса<br />«5 почему»<br />Демонстрация<br />Ретроспектива с применением инструментов бережливого производства<br />Разбор причин не успевания по несделанным задачам<br />«5 почему» по каждому дефекту<br />Неделя №7 (старт третьего спринта)<br />Цели: отработать старт предрелизного спринта и понять, как в будущем избежать таких «стабилизационных» спринтов, начать активно использовать автоматизированное тестирование<br />Планирование и старт третьего спринта<br />Особое внимание уделяем недоделанным историям пользователей, которые не успели сделать из-за ограничения по скорости команды<br />Рассматриваем возможность взять поменьше скорость команды, чтобы успеть всё к релизу<br />Внедрение модульных и приемочных тестов<br />Проведения тренинга по приемочным тестам <br />Покрытие 5% основного бизнес-функционала продукта приемочными тестами<br />Проведения тренинга по модульным тестам<br />Покрытие 50% кода, реализованного за спринт, модульными тестами<br />Внедрение рефакторинга <br />Неделя №8 (завершение третьего спринта)<br />Цели: сделать первый Agile-релиз продукта и выработать значительные меры по улучшению процессов на основе информации, полученной за три спринта.<br />Кайдзен-сессия на ретроспективе<br />Диаграмма Исикавы по глобальным проблемам проекта и выработка мер по устранению проблем<br />Завершение третьего спринта<br />Первый релиз продукта: обязательно, чтобы его попробовали конечные пользователи и дали свой фидбек.<br />Post-mortem релиза в рамках ретроспективы<br />Неделя №9 (старт четвертого спринта)<br />Цели: научиться планировать и управлять релизом<br />Планирование релиза<br />Начало ведения бёрндауна релиза<br />Отбор владельцем продукта юзер-стори для релиза<br />Возможная переоценка беклога командой «на пальцах»<br />Внедрение (трех)четырехзвенной архитектуры <br />Планирование и старт четвертого спринта<br />Скорость команды считаем эмпирически по трем предыдущим спринтам<br />Неделя №10 (завершение четвертого спринта)<br />Цели: внедрение статистического управления качеством<br />Завершение четвертого спринта<br />Внедрение основ статистического управления качеством<br />Статистика по дефектам<br />Диаграмма Парето по модулям <br />Диаграммы Шухарта<br />Неделя №11 (старт пятого спринта)<br />Цели: внедрение Kanban для команды саппорта<br />Планирование и старт пятого спринта<br />Анализируем и изменяем скоуп по релиз-бёрндауну<br />Переход на Scrumban команды саппорта<br />Тренинг по Kanban (4 часа) для членов команды<br />Отказ от жестких итераций<br />Внедрение разработки через тестирование<br />Тренинг и мастер-класс по разработке через тестирование<br />Покрытие тестами модулей ядра системы (не менее 50% строк кода)<br />Неделя №12 (завершение пятого спринта)<br />Цели: улучшение внутреннего качества ядра системы<br />Частичный рефакторинг модулей ядра системы<br />Определение стратегии рефакторинга и выбор модулей<br />Завершение пятого спринта<br />Неделя №13 (старт шестого «идеального» спринта)<br />Цели: запуск идеального спринта<br />Планирование и старт шестого спринта<br />Анализируем и изменяем скоуп по релиз-бёрндауну<br />Неделя №14 (завершение «идеального» шестого спринта)<br />Цели: завершение идеального спринта<br />Завершение шестого спринта<br />Релиз продукта<br />Post-mortem релиза в рамках ретроспективы<br />Анализ бёрндауна релиза<br />