Позволяют ли метрики эффективно управлять проектом: диагностировать проблемы, локализовать их, исправлять и проверять? Как использовать метрики с максимальной результативностью?
Как оценить процесс тестирования на проектеCOMAQA.BY
Тестирование - это процесс, он не стоит на месте, а нуждается в непрерывном улучшении. Мы приходим к ним на ретроспективах, из собственного и чужого опыта и ошибок, интуитивно или на основании некоторых данных. В своем докладе я расскажу, как провести оценку процесса тестирования на проекте: с чего начать, на что обратить внимание, поделюсь практическим опытом и отвечу на ваши вопросы. До встречи на докладе!
Позволяют ли метрики эффективно управлять проектом: диагностировать проблемы, локализовать их, исправлять и проверять? Как использовать метрики с максимальной результативностью?
Как оценить процесс тестирования на проектеCOMAQA.BY
Тестирование - это процесс, он не стоит на месте, а нуждается в непрерывном улучшении. Мы приходим к ним на ретроспективах, из собственного и чужого опыта и ошибок, интуитивно или на основании некоторых данных. В своем докладе я расскажу, как провести оценку процесса тестирования на проекте: с чего начать, на что обратить внимание, поделюсь практическим опытом и отвечу на ваши вопросы. До встречи на докладе!
Презентация была представлена в ходе вебинара "Scrum с нуля". Ведущая: Анна Чащина – разработчик 1С, руководитель отдела внедрения компании "Кодерлайн".
Основная тема для обсуждения: почему IT - самая передовая отрасль во всем мире отдает предпочтение именно Scrum.
http://www.koderline.ru/
В начале 2011го года компания Skype купила небольшой стартап под названием Qik. На тот момент в компании Skype был официальный процесс на базе SCRUM. Вышло так, что после перехода на этот процесс, команда Qik сильно потеряла в скорости поставки. В своём докладе я расскажу, что именно произошло, и как следование правилам Scrum мешало команде быстро и качественно разрабатывать свой продукт.
В длительной перспективе ретроспективы – самая важная часть гибких процессов. Но очень часто у команд не получается запустить процесс непрерывного улучшения, либо через некоторое время этот процесс обрывается, когда команда думает, что все проблемы решены. Я расскажу не только теоритическую часть, которая позволит преодолеть эти проблемы, но и дам несколько десятков примеров конкретных практик, которые применяются на эффективных ретроспективах. Доклад рассчитан, как на начинающих ретроспективы, так и практиков гибких методологий.
Гибкие подходы перестали работать! По крайне мере, если судить по многочисленным публикациям, которые все чаще и чаще стали появляться. У кого-то не работает Scrum, у кого-то не прижился Канбан и, вообще, Agile не работает. В своем докладе я также приведу несколько примеров критики Agile в виде статей и докладов, разберу типичные заблуждения и ошибки, которыми оперируют критики.
Если использовать модель жизненного цикла принятия инноваций, можно спрогнозировать, что число такого негатива будет расти, потому что в России Agile начинают использовать не только инноваторы и ранние последователи, но и раннее большинство, которому трудно грамотно внедрить Agile и стать действительно гибкими.
Опытные управленцы, которые владеют гибкими подходами, обычно посмеиваются над этим негативом и пересказывают друг другу как анекдоты, а это как раз и есть та пропасть, которую Джеффри Мур описал в своей книге. Дополнительно мы обсудим, где сейчас находится Agile с точки зрения цикла зрелости технологий, так как эта модель тоже объясняет неудачный опыт использования Agile.
Agile-сообществу важно дальше вовлекать и помогать развиваться тем, кто пытается сделать свою команды, отдел или целую компанию гибкой.
Денис Тучин - Болезни Agile ретроспектив и как их лечить (2016 AgileTour.By)Denis Tuchin
Видео: http://youtu.be/CTrRzdzhj1s?list=PLu7pKL8OAoRSze5Ts9wrbcEQBvXDx-AGq
Если вы начали проводить ретроспективы в своей команде, это ещё не значит, что вы внедрили процесс постоянного совершенствования (Kaizen). Часто у начинающих и не только Agile команд возникают те или иные сложности: выявленные проблемы не существенны или находятся за пределами влияния команды, действия по решению проблем не воплощаются в жизнь.
На докладе мы рассмотрим типичные проблемы Agile ретроспектив и как с ними бороться. Начнём с такого часто встречаемого случая, когда члены команды достаточно позитивно настроены, не видят проблем в своей работе и их идеи по улучшению процесса сводятся к предложениям по организации инфраструктуры офиса: кондиционеры, видов чая и т.д.
Здесь нужно вернуть команду с небес на землю, показать, какие проблемы есть на самом деле и профасилитировать нахождение решений.
Другой частый случай почти полная противоположность первому по атмосфере, но по эффекту на ретро очень похож. Члены команды настолько сильно находятся под прессингом дефектов и постоянных "хотелок" заказчиков, что не верят, что что-то можно улучшить и видят проблемы только в других командах, но не у себя.
Здесь более сложный процесс по нормализации атмосферы в команде. Рассмотрим первые 3 важных шага, как это сделать: снижение психологического напряжения процессным путём, решение основных проблем и маленькие победы.
Третья проблема, которую успеем рассмотреть: принятые на ретроспективе решения, не претворяются в жизнь. Практики для исправления достаточно просты, но далеко не все о них знают и их соблюдают: добровольное назначение задач, голосование консенсусом и добавление задач в беклог.
10 главных идей гибкой разработки. С элементами, потому что довольно сложно применять чистый Scrum к большому проекту, в котором есть много поддержки и форсмажора. Подготовлена на базе книги Scrum Джеффа Сазерленда и материалов компании ScrumTrek. Презентация родилась после прочтения книги и посещения антиконференции AgileCamp. Рассказал команде проектов Колёса, Крыша и Маркет, будем более активно применять идеи и методики, которые помогают в разработке проектов по всему миру.
Презентация была представлена в ходе вебинара "Scrum с нуля". Ведущая: Анна Чащина – разработчик 1С, руководитель отдела внедрения компании "Кодерлайн".
Основная тема для обсуждения: почему IT - самая передовая отрасль во всем мире отдает предпочтение именно Scrum.
http://www.koderline.ru/
В начале 2011го года компания Skype купила небольшой стартап под названием Qik. На тот момент в компании Skype был официальный процесс на базе SCRUM. Вышло так, что после перехода на этот процесс, команда Qik сильно потеряла в скорости поставки. В своём докладе я расскажу, что именно произошло, и как следование правилам Scrum мешало команде быстро и качественно разрабатывать свой продукт.
В длительной перспективе ретроспективы – самая важная часть гибких процессов. Но очень часто у команд не получается запустить процесс непрерывного улучшения, либо через некоторое время этот процесс обрывается, когда команда думает, что все проблемы решены. Я расскажу не только теоритическую часть, которая позволит преодолеть эти проблемы, но и дам несколько десятков примеров конкретных практик, которые применяются на эффективных ретроспективах. Доклад рассчитан, как на начинающих ретроспективы, так и практиков гибких методологий.
Гибкие подходы перестали работать! По крайне мере, если судить по многочисленным публикациям, которые все чаще и чаще стали появляться. У кого-то не работает Scrum, у кого-то не прижился Канбан и, вообще, Agile не работает. В своем докладе я также приведу несколько примеров критики Agile в виде статей и докладов, разберу типичные заблуждения и ошибки, которыми оперируют критики.
Если использовать модель жизненного цикла принятия инноваций, можно спрогнозировать, что число такого негатива будет расти, потому что в России Agile начинают использовать не только инноваторы и ранние последователи, но и раннее большинство, которому трудно грамотно внедрить Agile и стать действительно гибкими.
Опытные управленцы, которые владеют гибкими подходами, обычно посмеиваются над этим негативом и пересказывают друг другу как анекдоты, а это как раз и есть та пропасть, которую Джеффри Мур описал в своей книге. Дополнительно мы обсудим, где сейчас находится Agile с точки зрения цикла зрелости технологий, так как эта модель тоже объясняет неудачный опыт использования Agile.
Agile-сообществу важно дальше вовлекать и помогать развиваться тем, кто пытается сделать свою команды, отдел или целую компанию гибкой.
Денис Тучин - Болезни Agile ретроспектив и как их лечить (2016 AgileTour.By)Denis Tuchin
Видео: http://youtu.be/CTrRzdzhj1s?list=PLu7pKL8OAoRSze5Ts9wrbcEQBvXDx-AGq
Если вы начали проводить ретроспективы в своей команде, это ещё не значит, что вы внедрили процесс постоянного совершенствования (Kaizen). Часто у начинающих и не только Agile команд возникают те или иные сложности: выявленные проблемы не существенны или находятся за пределами влияния команды, действия по решению проблем не воплощаются в жизнь.
На докладе мы рассмотрим типичные проблемы Agile ретроспектив и как с ними бороться. Начнём с такого часто встречаемого случая, когда члены команды достаточно позитивно настроены, не видят проблем в своей работе и их идеи по улучшению процесса сводятся к предложениям по организации инфраструктуры офиса: кондиционеры, видов чая и т.д.
Здесь нужно вернуть команду с небес на землю, показать, какие проблемы есть на самом деле и профасилитировать нахождение решений.
Другой частый случай почти полная противоположность первому по атмосфере, но по эффекту на ретро очень похож. Члены команды настолько сильно находятся под прессингом дефектов и постоянных "хотелок" заказчиков, что не верят, что что-то можно улучшить и видят проблемы только в других командах, но не у себя.
Здесь более сложный процесс по нормализации атмосферы в команде. Рассмотрим первые 3 важных шага, как это сделать: снижение психологического напряжения процессным путём, решение основных проблем и маленькие победы.
Третья проблема, которую успеем рассмотреть: принятые на ретроспективе решения, не претворяются в жизнь. Практики для исправления достаточно просты, но далеко не все о них знают и их соблюдают: добровольное назначение задач, голосование консенсусом и добавление задач в беклог.
10 главных идей гибкой разработки. С элементами, потому что довольно сложно применять чистый Scrum к большому проекту, в котором есть много поддержки и форсмажора. Подготовлена на базе книги Scrum Джеффа Сазерленда и материалов компании ScrumTrek. Презентация родилась после прочтения книги и посещения антиконференции AgileCamp. Рассказал команде проектов Колёса, Крыша и Маркет, будем более активно применять идеи и методики, которые помогают в разработке проектов по всему миру.
Поколения Digital заставляет ресторанный бизнес меняться.
С одной стороны необходимо научиться говорить с клиентами нового поколения на их языке, использовать их ценности и навыки digital общения. С другой, привнести шарм обслуживания в стиле Old School.
Развитие стратегических команд
Максим Шмакотин — тренер-консультант, лидер темы «Командные технологии», партнер Бутика.
Ключевые слова: типология команд, сообщества, внутрикомандные роли и функции, ловушки управления, программа развития топ-команд.
Все материалы Дня открытых дверей на сайте Тренинг-Бутика
Олег Афанасьев. Бизнес-планирование и стратегическое мышление. Тренинг-прак...Oleg Afanasyev
Этот тренинг был разработан как практикум, позволяющий закрепить знания о Стратегическом менеджменте в ходе разработки конкретных бизнес-проектов конкретной компании.
Тест проверки знаний. Школа Супервайзера Олега Афанасьева. Астана. 12.09.2016.Oleg Afanasyev
Этот тест дает возможность определить уровень владения теоретическим материалом Школы Супервайзера действующего сотрудника или вступающего в должность.
Светлана Мухина, Метрики в Agile проектахScrumTrek
Я думаю, что чем сложнее метрика, тем проще ее подвести под необходимые результаты. Зачастую достаточно немного исказить одно не самое важное значение в формуле расчета и в итоге на больших числах можно получить приличное искажение. С помощью визуализации метрик тоже можно оказывать влияние и изменять мнение в необходимую вам сторону. И тут возникает вопрос #2 - "Что делать?" Использовать или не использовать метрики. Возможно, вы найдете для себя ответ на этот вопрос в моем докладе про очень простые метрики: -capacity - кол-во идеальных часов доступное в итерацию; -velocity - количество сделанной работы в стори поинтах или других "попугаях"; -burn-down - прогресс команды на данный момент, сколько сделали и сколько осталось; -индекс стабильности требований - как часто меняются требования; И еще поделюсь своим мнением о том, какая может быть польза команде от заполнения системы учета времени; Я расскажу, как мы собираем эти метрики на проектах и что нам это дает. Например, иногда они помогают найти ответ на вопрос #1 "Кто виноват?" (это шутка).
Как сделать командные встречи более эффективными? У меня нет одного волшебного рецепта для решения этого комплексного вопроса, но я буду рада поделится с вами набором техник с примерами, которые помогут вам:
Быть лучше подготовленным к встречам;
Фокусировать участников на теме обсуждения;
Уменьшать количество разговоров не относящихся к основной теме дискуссии;
Научить участников быстро принимать решения;
Митигировать конфликтные ситуации;
Описывать механизм реализации договоренностей, принятых на встрече.
Из моего доклады вы узнаете, что такое фасилитации и кто такой фасилитатор, а так же изучите ряд фасилитационных техник, которые применяются для работы с определенными проблемными ситуациями.
Как UX/UI дизайнеру работать в команде? Выстраивание дизайн-процессаNetpeak
Презентация доклада с Netpeak Talks №5 в Харькове
Докладчики: Татьяна Гуменюк (Web designer for special projects at Netpeak) и Анна Даценко (Head of design at IdeaSoft Group).
30 мая, Харьков
Воркшоп по управлению командой проекта в Академии ПВТAliaksei Minkevich
Наша презентация с ВОРКШОПА ПО УПРАВЛЕНИЮ КОМАНДОЙ ПРОЕКТА 29 января в 19.00
Лидеры компании Juno поделятся с вами собственным опытом по следующим темам:
Как набирать и развивать команду проекта
Какие шаги проходит группа людей во время создания команды
Инструмент “Устав Команды”
Управление командой проекта
Обратная связь
Урегулирование конфликтов
Решение проблем
Принятие решений
Делегирование
Презентация Бибичева Андрея об опыте внедрения Scrum в компании CustIS, прочитанная на конференции РИТ-2008.
Текст статьи - http://www.slideshare.net/biBIGine/scrum-2029854
Similar to Оценка проектов. Быстро и эффективно (20)
Михаил Подурец. Почему Agile не работает (на самом деле нет). Agiledays2017LuxoftAgilePractice
Каждый уважающий себя Agile-coach рано или поздно должен высказаться на эту тему:
— АААА! Оно у нас не работает
— Ваш Скрам у нас невозможен
— Как вы предлагаете делать нам интеграционное тестирование внутри спринта, если оно занимает месяц!? О_о
Спокойно! На докладе мы разберем, почему оно не работает, и как на самом деле оно должно работать.
Презентация с доклада на AgileDays 2017. Скоро будет видео
Что такое групповая динамика и зачем про нее знать фасилитатору?LuxoftAgilePractice
Бывала ли у вас такая ситуация с командой, когда вы не понимали, чем вызван спад ее производительности или возросшее количество внутрикомандных конфликтов? На прошлой неделе еще все дружно работали, а на этой начался какой-то разлад и шатание.
Одной из причин такой метаморфозы может быть переход команды из стадии формирования в стадию штормления. Как это определить и что с этим делать, мы рассмотрим на вебинаре на примере модели командной динамики Брюса Такмана.
Модель Такмана - это, конечно, не единственный способ описания процессов, которые происходят с командой, компанией или социумом в целом. Для рассмотрения более глубокий, экзистенциальных потоков изменений можно использовать модель Спиральной Динамики. Эта модель может ответить не только на философские, но и на такие утилитарные вопросы как:
В чем причина бюрократии на проекте или в компании?
Каким сотрудникам будет сложно работать в Agile среде?
Почему участники одной команды могут действовать против друг друга и напоминать коллектив из басни “лебедь, рак и щука”?
Каким руководителям сложно увольнять сотрудникам и проводить дисциплинарные беседы с подчиненными?
Каким командам подойдет и принесет пользу Скрам фреймворк.
На вебинаре мы детально, но быстро, разберем две вышеперечисленные модели и еще один подход, который помогает последовательно сформировать команду из группы специалистов.
Запись прошлых вебинаров на тему фасилитации:
https://youtu.be/VqarmllTKD4 Фасилитируем командное обсуждение и принятие решений
https://youtu.be/7x3uHaFqe1I Майндсет и поведение Agile фасилитатора
https://youtu.be/ykx54Kx6wOA Фасилитируем встречи, повышающие уровень сотрудничества в команде
https://youtu.be/mjIu06mvO4A Вебинар От Agile фасилитатора до Agile коуча
Презентация к вебинару - 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
Третий вебинар из серии вебинаров ICAgile Agile Team Facilitation, которая состоит из 7 вебинаров о фасилитации Agile команд. Будем рассматривать техники и инструменты, которые повышают уровень сотрудничества в команде. Поговорим про особенности их применения, случаи, когда они работают, а когда нет.
Сопротивление изменениям. Как помочь команде пережить процессную трансформацию.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.
6. www.luxoft.com
Относительная оценка. Шкала Фибонначи
Оцените другие фигурки относительно “1” – 1,2,3,5,8,13,21,34,55,89, 144, 233
Двойка означает, что размер фигурки не более чем в два раза по отношению к самой маленькой
Тройка означает, что фигурка больше чем в два раза, но не больше чем в три раза, и.т.д
1
2
8. www.luxoft.com
Измеряем командную скорость
За одну минуту нужно закрасить как можно больше фигурок
Баллы набираются только на полностью закрашенные фигурки, вылазить за пределы нельзя
Выбирете стретегию работы
1
Засчитываем
1
2
3
3
5
5
8
8 13
21
34 55 88
246
Не засчитываем
9. www.luxoft.com
Size
Velocity
Calculation
Duration
250 pounds
Velocity = 50
Pounds
250/50 = 5 trips
120
story points
Velocity = 20
Points
120/20 = 6
Iterations
Что такое командная скорость?
Дайте мне оценку за сколько минут вы как команда сможете полностью закрасить все фигурки, теми
инструментами, которыми вы располагаете
10. www.luxoft.com
Измеряем командную скорость
Командная скорость. Считаем только полностью закрашенные фигурки
Пересчитываем остаток работ = 224
Делим остаток работ на командную скорость и даем новую оценку завершения работ (записать на флип-чарт)
1
1
2
3
3
5
5
8
8 13
21
34 55 88
224
11. www.luxoft.com
Case #1. Команда не могла оценить проект
Команда на протяжении месяца не могла оценить проект в человекоднях
Заказчику и команде предложили гибкий подход оценки и планирования
PM, PO и команда разработки провели вместе полных 3 дня
За три дня был сформирован Product Backlog и Release Roadmap
13. www.luxoft.com
Группировка историй по размеру
Команда выстроила все истории в цепочку возрастания сложности
Разместили истории по корзинам оценки
14. www.luxoft.com
Подготовка Release Roadmap
Product Owner поставил цель продукта на следующие 6 месяцев
Команда вместе с PO разместила истории по релизам
Комманда исследовала сбалансированность всех релизов
Истории больше “13” были отмечены как рисковые
Обсудили план разбивки больших историй на маленькие
15. www.luxoft.com
Адаптация плана
Release Roadmap показал что команда должна сжигать 30 SP за релиз
Реальная скорость была 20 SP. Что делать в этой ситуации?
Было принято решение подключить еще одну команду
Product Owner постепенно удалял из Product Backlog менее значимые истории
16. www.luxoft.com
Affinity Estimating
Создать «цепочку сложности» в режиме «полной тишины»
Выписать предположения по которым мы сравнили эти истории
Оценки выписываем прямо на стикеры
17. www.luxoft.com
Важно помнить
Скорость команды будет изменяться, соотвественно даты или объем тоже должен
адаптироваться
У команды должны быть критерии “Завершенности”
Стоимость одного стори поинта может изменяться, в зависимости от того как романда растет
Когда стори поинт фиксируется на количестве часов или дней, команда перестает расти
Определение одного стори поинта не изменятся с течением времени
18. www.luxoft.com
What Makes a Good Plan?
Хороший процесс планирования и оценки способствует
правильному процессу принятия решений