На примере крупного холдинга и инжиниринговой компании показано, что необходимо для запуска ИСУП в компании. Доклад Павла Алферова, представленный на конференции "Внедрение проектного управления. УСпешный проектный офис 2016"
На примере крупного холдинга и инжиниринговой компании показано, что необходимо для запуска ИСУП в компании. Доклад Павла Алферова, представленный на конференции "Внедрение проектного управления. УСпешный проектный офис 2016"
Как перевести требования на agile-рельсы в действующем проектеMagneta AI
Антон Зотин, Luxoft (Москва)
Проект уже несколько месяцев, а возможно и лет, идет своим ходом не по agile. И приходит тот день, когда мы, по тем или иным причинам, начинаем активно переходить на agile. Коучи, если они есть, читают тренинги. Заказчики радостно ждут potentially shippable product increment. Программисты робко говорят о continuous integration и TDD. Тестировщики пробуют на вкус автоматизацию тестирования.
Аналитики... а аналитики узнают, что им больше не нужно писать документы. И документы их никто не читает, а если кто и читает, то недовольны качеством. И вообще теперь backlog, user stories, acceptance criteria. И если про agile requirements management еще можно почитать или поспрашивать, то что делать со всем, что нажито непосильным трудом? Как максимально безболезненно перейти от старого подхода к новому? Как не потерять результатов предыдущей работы? Как свести сотни страниц детально написанных требований с, простите, user stories в единую стройную систему? Как сделать то, о чем умные книжки молчат?
В докладе мы рассмотрим комплекс практических техник которые позволяют перевести требования действующего проекта на agile. Посмотрим как не потерять и эффективно использовать уже написанные документы. Поговорим о рисках и ценах на такие изменения.
Жду аналитиков, scrum master-ов, начинающих коучей и всех тех, кому не безразличны требования.
Мертвая зона - Как визуализировать поток требований в распределенном проектеMagneta AI
Сергей Прохоренко, Luxoft (Киев)
Последние несколько лет я работаю в Agile-командах в различных ролях - аналитика, proxy PO, процессного коуча. За это время я наблюдал самые различные проекты, сталкивающиеся с похожими препятствиями при масштабировании и помогал им в решении проблем.
Общепринятые практики Scrum предлагают большое количество инструментов для визуализации командной работы: product/sprint backlog, доска, ежедневные стэндапы, burndown chart. Но если ваш проект распределен по трем-четырем локациям, а количество людей в проекте перевалило за сотню - как понять, правильно ли расставлены приоритеты, понимают ли команды, чем они и их коллеги по проекту будут заниматься в следующем спринте и дальше?
Многие из этих вопросов часто попадают в "мертвую зону", что приводит к проблемам при масштабировании процесса.
Рассмотрев несколько практических примеров из практики, мы обсудим, как построить эффективную коммуникацию между командами в проекте, как визуализировать поток требований и как определять критерии для продвижения новых требований из product backlog в sprint backlog.
Agile Management. Теория и практика спасения крупного проекта.Magneta AI
Алексей Пименов, R-Style (Москва)
Как внедрить Agile в крупном проекте и не скатиться в культ карго? Подкрепляем практику классической теорией менеджмента и организационных изменений. Рассмотрим на реальном примере, как был построен Agile процесс разработки для спасения остановившегося проекта. Что работало и почему. Что не работало и почему. Какие каноны и best practices пришлось нарушить и почему. Как объять необъятное и совмещать несовместимое.
Как перевести требования на agile-рельсы в действующем проектеMagneta AI
Антон Зотин, Luxoft (Москва)
Проект уже несколько месяцев, а возможно и лет, идет своим ходом не по agile. И приходит тот день, когда мы, по тем или иным причинам, начинаем активно переходить на agile. Коучи, если они есть, читают тренинги. Заказчики радостно ждут potentially shippable product increment. Программисты робко говорят о continuous integration и TDD. Тестировщики пробуют на вкус автоматизацию тестирования.
Аналитики... а аналитики узнают, что им больше не нужно писать документы. И документы их никто не читает, а если кто и читает, то недовольны качеством. И вообще теперь backlog, user stories, acceptance criteria. И если про agile requirements management еще можно почитать или поспрашивать, то что делать со всем, что нажито непосильным трудом? Как максимально безболезненно перейти от старого подхода к новому? Как не потерять результатов предыдущей работы? Как свести сотни страниц детально написанных требований с, простите, user stories в единую стройную систему? Как сделать то, о чем умные книжки молчат?
В докладе мы рассмотрим комплекс практических техник которые позволяют перевести требования действующего проекта на agile. Посмотрим как не потерять и эффективно использовать уже написанные документы. Поговорим о рисках и ценах на такие изменения.
Жду аналитиков, scrum master-ов, начинающих коучей и всех тех, кому не безразличны требования.
Мертвая зона - Как визуализировать поток требований в распределенном проектеMagneta AI
Сергей Прохоренко, Luxoft (Киев)
Последние несколько лет я работаю в Agile-командах в различных ролях - аналитика, proxy PO, процессного коуча. За это время я наблюдал самые различные проекты, сталкивающиеся с похожими препятствиями при масштабировании и помогал им в решении проблем.
Общепринятые практики Scrum предлагают большое количество инструментов для визуализации командной работы: product/sprint backlog, доска, ежедневные стэндапы, burndown chart. Но если ваш проект распределен по трем-четырем локациям, а количество людей в проекте перевалило за сотню - как понять, правильно ли расставлены приоритеты, понимают ли команды, чем они и их коллеги по проекту будут заниматься в следующем спринте и дальше?
Многие из этих вопросов часто попадают в "мертвую зону", что приводит к проблемам при масштабировании процесса.
Рассмотрев несколько практических примеров из практики, мы обсудим, как построить эффективную коммуникацию между командами в проекте, как визуализировать поток требований и как определять критерии для продвижения новых требований из product backlog в sprint backlog.
Agile Management. Теория и практика спасения крупного проекта.Magneta AI
Алексей Пименов, R-Style (Москва)
Как внедрить Agile в крупном проекте и не скатиться в культ карго? Подкрепляем практику классической теорией менеджмента и организационных изменений. Рассмотрим на реальном примере, как был построен Agile процесс разработки для спасения остановившегося проекта. Что работало и почему. Что не работало и почему. Какие каноны и best practices пришлось нарушить и почему. Как объять необъятное и совмещать несовместимое.
Усвоенные уроки одной кросс-функциональной командыMagneta AI
Сергей Рогачев, Астерос Лабс (Москва)
Алексей Воронин, Астерос Лабс (Москва)
Сергей Рогачев работает в сфере разработки программного обеспечения последние 10 лет. Основные роли, в которых выступал Сергей: разработчик, архитектор и менеджер. За это время Сергей успел поработать в таких крупных компаниях как Лукойл-Информ и Лаборатория Касперского. Последнее время Сергей занимается вопросами организации подразделений исследований и разработки (R&D), постановки в них процессов разработки продуктового программного обеспечения, способного достойно конкурировать с аналогами на рынке.
А способны ли вы оглянуться на год назад и признаться себе, что то, как вы смотрели на мир год назад, абсолютно отличается от того, как вы смотрите на мир сейчас? А, главное, понять, какие причины повлияли на это изменение?
Это история о том, какие принципы, интуитивно заложенные основу построения нашей команды в начале проекта, помогли ей пройти путь от аборигенов, повторяющих ритуалы Scrum, до состояния осознанного применения готовых, адаптации и поиска новых гибких методик для эффективного достижения целей и постоянного развития.
Об этих принципах и изменениях мы расскажем на примере уроков, которые мы усвоили за год работы над проектом.
Джеф Паттон проектирует и разрабатывает ПО во множестве проектов, от интернет заказа деталей самолетов до электронных медицинских записей. Джеф нацелен на Agile подходы со времен работы в XP команде в 2000 году. Джеф специализируется на применении ориентированных на пользователя методик проектирования, чтобы улучшить Agile требования, планирование и продукт. Его статьи на эту тему можно найти на сайте www.AgileProductDesign.com и в Crystal Clear Алистара Коберна.
Сейчас Джеф - независимый консультант, создатель и модератор Yahoo группы по agile-usability, обозреватель StickyMinds.com и IEEE Software и победитель премии Agile Alliance’s 2007 Gordon Pask Award за вклад в Agile разработку.
“Mediocrity guaranteed.” This sad tagline describes most of the processes we use today including typical agile process. It’s easy to see why: software development is an expensive, risky business. To deal with the risk, we clearly separate responsibilities, creating a client-vendor model so that we know who’s accountable when things go wrong. Although we know things rarely go as planned, and innovative ideas rarely spring from such a relationship, we continue to work in processes where treating our coworkers as outsourced vendors is considered “best practice” and risking everything on the ideas of a select few isn’t regarded as risky.
This talk is about an alternative way of working.
In this talk, Jeff explores companies beginning to adopt a style of working where everyone in the organization gets involved with identifying and solving problems. You’ll hear examples from real companies describing their practices for learning first-hand about customers and users. You’ll learn about practices for collaboratively designing solutions for the problems found in the real world, and approaches for learning if what we created really benefited anyone. This new style of work is a process cocktail combining the best of agile development, lean software development and lean startup, user-centered design, and collaborative design thinking.
This style of work isn’t the traditional client-vendor model where knowing who’s to blame is the primary concern. It’s a co-making style of work where everyone brings their skills and experience to the table and together takes ownership for making great products.
Доклад Сергея Нужненко (ООО «Лаборатория системного анализа» (lab-sa.ru)) "ИТ-проекты и ИТ-результаты" на 130-м заседании Русского отделения INCOSE, 9 ноября 2017 г.
Сергей Рогачев; Лилия Алексеева. Дизайн и запуск Agile-команд.ScrumTrek
Запуск в Agile — это одно из ключевых событий в жизни команды: от него зависит, взлетит ли Agile? Но запуск дает только 30% гарантии успеха, около 60% зависит от правильного дизайна команды. Мы расскажем, как проводить дизайн команды. Причем покажем на цифрах реального статистического исследования, как ошибки при дизайне отражаются на эффективности команд. Мы поделимся опытом, как непосредственно при запуске команды можно исправить кривой дизайн. И что делать, если нужно запустить одновременно много команд.
Как сделать командные встречи более эффективными? У меня нет одного волшебного рецепта для решения этого комплексного вопроса, но я буду рада поделится с вами набором техник с примерами, которые помогут вам:
Быть лучше подготовленным к встречам;
Фокусировать участников на теме обсуждения;
Уменьшать количество разговоров не относящихся к основной теме дискуссии;
Научить участников быстро принимать решения;
Митигировать конфликтные ситуации;
Описывать механизм реализации договоренностей, принятых на встрече.
Из моего доклады вы узнаете, что такое фасилитации и кто такой фасилитатор, а так же изучите ряд фасилитационных техник, которые применяются для работы с определенными проблемными ситуациями.
Мы представили новые мобильные решения для разных типов сотрудников, условий работы и устройств, новые средства вовлечения и обучения работе в системе, развитие инструмента разработки и ускорение внедрения в новой версии DIRECTUM 5.1 и решениях на ее основе.
Все доклады с конференции Открытые дни DIRECTUM 2014 http://days.directum.ru/
Успешная карьера в современной разработки программного обеспеченияSergey Morgunov
Краткая информация о том, что должен знать каждый разработчик программного обеспечения.
Видео версия презентации http://www.youtube.com/watch?v=MqKFIcfouQc
Гибкая разработка пользовательской документацииSergey Rogachev
Презентация доклада "Гибкая разработка пользовательской документации" Сергея Рогачева на конференции AgileKitchen в Москве в октябре 2013 года (http://bit.ly/1a6gfQU). См. больше информации в слайдкасте (http://penxy.com/lyna) или заметке "Отчет об участии в AgileKitchen’10/13" (http://wp.me/p1650o-dq) в персональном блоге Рогачева Сергея.
Автоматизируем тестирование интерфейса мобильных приложенийSPB SQA Group
В докладе рассказано, что из себя представляют автоматические тесты интерфейса мобильных приложений и когда их стоит внедрять, сделан обзор наиболее распространенных бесплатных средств автоматизации для iOS и Android.
We have a lot of businesses working in Ukraine as Outsource company. But all we know that outsource is not options as the long-term
business strategy. From the other perspective, there are a few firms that are trying to move to the product development but it too risky
for two reasons:
— You need to invest your money and losing your margin.
— You have no any experience in product management or startup landing neither fundraising.
We in Octoberry, start to work as Product Sourcing company three years ago. We find this way very useful to gain experience in product
management and fundraising and after we moved to own product development and we want to share our case. In this talk, we will
discuss:
— What is product sourcing?
— Why product source.
— Five steps key steps to run Product Source project
— Moving from product source to Product Company
AgileCamp — летняя практическая конференция, которую ежегодно проводить компания ScrumTrek. Участники процессного трека на практике отрабатывают все цепочку создания продукта. Используются такие техники как проведение опросов, игра в ТЗ, user story mapping, bucket estimation, planning poker, getkanban, world cafe и др.
Как создать концепцию продукта в виде Lean CanvasMagneta AI
Lean Canvas — инструмент, который позволяет быстро понять ценность продукта, проблемы, которые он решает, его основную аудиторию и способы монетизации. В презентации подробно рассмотрен шаблон lean canvas и дается подробное руководство по заполнению.
Зачем нужны ретроспективы и как их проводить? Основные отличия ретроспектив в различных фреймворках, например, Scrum или Kanban, рекомендации по продолжительности, наполнению, советы по каждому этапу ретроспективы.
2. Алексей Лосев
С 1999 года программирую за деньги
С 2003 по 2011 преподавал
программирование
С 2007 руковожу командой разработчиков
С 2011 года занимаюсь внутренней
автоматизацией
в ФГ Лайф
3.
4. Agile манифест
важнееРеакция на изменения следования плану
важнее
Сотрудничество с
заказчиком
контрактных
обязательств
важнее
Люди и их
взаимодействие
процессов и
инструментов
важнее
Работающее
программное
обеспечение
полной документации
8. • причина системная
• реакция как на особуюЗарегулированность
• причина особая
• ошибочно считается что
причина общая
Бездействие
К чему приводит непонимание?
17. Что почитать
1. Эдвардс Деминг. Выход из кризиса: Новая
парадигма управления людьми, системами
и процессами
2. ГОСТ Р 50779.42-99. Статистические
методы. Контрольные карты Шухарта