Требования постоянно меняются в ходе разработки
Требования могут противоречить друг другу
Меняются приоритеты разработки
Ограничены ресурсы – нужно уметь расставлять приоритеты
Ограничены сроки – нужно ясно понимать, какой функционал к какой дате будет реализован
Devprom ALM - платформа для поддержки процессов разработкиEvgeny Savitsky
В рамках внедрения Devprom ALM мы выполняем предварительную настройку ПО, проводим обучение современным практикам разработки (включая все элементы процесса), предоставляем видеоматериалы и рабочие инструкции.
Денис Тучин - Пользовательские истории в Agile-проектахDenis Tuchin
Видеозапись вебинара: https://www.youtube.com/watch?v=YBjbaygwvBM&index=9&list=PLu7pKL8OAoRTTwi3KK2OmVmuX9VllOFwt
1. Что такое пользовательские истории (User Stories)
2. Зачем они нужны в ваших проектах?
3. Как пользовательские истории помогают повысить удовлетворённость заказчика?
4. Как применяются пользовательские истории в Scrum?
Для кого:
Вебинар будет полезен менеджерам продуктов, менеджерам проектов, бизнес-аналитикам, владельцам продуктов, проектировщикам и разработчикам систем, которые хотят начать использовать преимущества разработки требований и создания продуктов в стиле Agile в своих проектах
Система управления жизненным циклом разработки программного обеспечения Devpr...Evgeny Savitsky
Devprom - российская компания-разработчик инструментов в области управления проектами
Дата образования: июнь 2008
Количество сотрудников: 9 человек
Количество загрузок дистрибутива: 8600
Количество зарегистрированных пользователей: 4800
Цикл выпуска новых версий продукта: 1 месяц
Денис Тучин - Болезни Agile ретроспектив и как их лечить (2016 AgileTour.By)Denis Tuchin
Видео: http://youtu.be/CTrRzdzhj1s?list=PLu7pKL8OAoRSze5Ts9wrbcEQBvXDx-AGq
Если вы начали проводить ретроспективы в своей команде, это ещё не значит, что вы внедрили процесс постоянного совершенствования (Kaizen). Часто у начинающих и не только Agile команд возникают те или иные сложности: выявленные проблемы не существенны или находятся за пределами влияния команды, действия по решению проблем не воплощаются в жизнь.
На докладе мы рассмотрим типичные проблемы Agile ретроспектив и как с ними бороться. Начнём с такого часто встречаемого случая, когда члены команды достаточно позитивно настроены, не видят проблем в своей работе и их идеи по улучшению процесса сводятся к предложениям по организации инфраструктуры офиса: кондиционеры, видов чая и т.д.
Здесь нужно вернуть команду с небес на землю, показать, какие проблемы есть на самом деле и профасилитировать нахождение решений.
Другой частый случай почти полная противоположность первому по атмосфере, но по эффекту на ретро очень похож. Члены команды настолько сильно находятся под прессингом дефектов и постоянных "хотелок" заказчиков, что не верят, что что-то можно улучшить и видят проблемы только в других командах, но не у себя.
Здесь более сложный процесс по нормализации атмосферы в команде. Рассмотрим первые 3 важных шага, как это сделать: снижение психологического напряжения процессным путём, решение основных проблем и маленькие победы.
Третья проблема, которую успеем рассмотреть: принятые на ретроспективе решения, не претворяются в жизнь. Практики для исправления достаточно просты, но далеко не все о них знают и их соблюдают: добровольное назначение задач, голосование консенсусом и добавление задач в беклог.
Бизнес требует от ИТ постоянно ускорять обороты. Сроки выхода на рынок постоянно сокращаются.
Применение гибких методологий в небольшой команде позволяет значительно уменьшить Time-to-Market.
Однако в крупной компании прямое использование Agile/Scrum затруднено: даже простое на первые взгляд изменение бизнес процесса может затрагивать несколько систем, за которые отвечают разные команды. Выпуск релиза приходится координировать с большим количеством заинтересованных лиц. Это сильно замедляет и проектирование и финальное интеграционное тестирование. В результате добиться снижения Time-to-Market кажется очень непростой задачей, осложненной к тому же непростой политической ситуацией, типичной для крупной организации.
Мы поговорим о системном подходе к снижению Time-to-Market для сложных задач координации релиза, характерных для крупных организаций
Devprom ALM - платформа для поддержки процессов разработкиEvgeny Savitsky
В рамках внедрения Devprom ALM мы выполняем предварительную настройку ПО, проводим обучение современным практикам разработки (включая все элементы процесса), предоставляем видеоматериалы и рабочие инструкции.
Денис Тучин - Пользовательские истории в Agile-проектахDenis Tuchin
Видеозапись вебинара: https://www.youtube.com/watch?v=YBjbaygwvBM&index=9&list=PLu7pKL8OAoRTTwi3KK2OmVmuX9VllOFwt
1. Что такое пользовательские истории (User Stories)
2. Зачем они нужны в ваших проектах?
3. Как пользовательские истории помогают повысить удовлетворённость заказчика?
4. Как применяются пользовательские истории в Scrum?
Для кого:
Вебинар будет полезен менеджерам продуктов, менеджерам проектов, бизнес-аналитикам, владельцам продуктов, проектировщикам и разработчикам систем, которые хотят начать использовать преимущества разработки требований и создания продуктов в стиле Agile в своих проектах
Система управления жизненным циклом разработки программного обеспечения Devpr...Evgeny Savitsky
Devprom - российская компания-разработчик инструментов в области управления проектами
Дата образования: июнь 2008
Количество сотрудников: 9 человек
Количество загрузок дистрибутива: 8600
Количество зарегистрированных пользователей: 4800
Цикл выпуска новых версий продукта: 1 месяц
Денис Тучин - Болезни Agile ретроспектив и как их лечить (2016 AgileTour.By)Denis Tuchin
Видео: http://youtu.be/CTrRzdzhj1s?list=PLu7pKL8OAoRSze5Ts9wrbcEQBvXDx-AGq
Если вы начали проводить ретроспективы в своей команде, это ещё не значит, что вы внедрили процесс постоянного совершенствования (Kaizen). Часто у начинающих и не только Agile команд возникают те или иные сложности: выявленные проблемы не существенны или находятся за пределами влияния команды, действия по решению проблем не воплощаются в жизнь.
На докладе мы рассмотрим типичные проблемы Agile ретроспектив и как с ними бороться. Начнём с такого часто встречаемого случая, когда члены команды достаточно позитивно настроены, не видят проблем в своей работе и их идеи по улучшению процесса сводятся к предложениям по организации инфраструктуры офиса: кондиционеры, видов чая и т.д.
Здесь нужно вернуть команду с небес на землю, показать, какие проблемы есть на самом деле и профасилитировать нахождение решений.
Другой частый случай почти полная противоположность первому по атмосфере, но по эффекту на ретро очень похож. Члены команды настолько сильно находятся под прессингом дефектов и постоянных "хотелок" заказчиков, что не верят, что что-то можно улучшить и видят проблемы только в других командах, но не у себя.
Здесь более сложный процесс по нормализации атмосферы в команде. Рассмотрим первые 3 важных шага, как это сделать: снижение психологического напряжения процессным путём, решение основных проблем и маленькие победы.
Третья проблема, которую успеем рассмотреть: принятые на ретроспективе решения, не претворяются в жизнь. Практики для исправления достаточно просты, но далеко не все о них знают и их соблюдают: добровольное назначение задач, голосование консенсусом и добавление задач в беклог.
Бизнес требует от ИТ постоянно ускорять обороты. Сроки выхода на рынок постоянно сокращаются.
Применение гибких методологий в небольшой команде позволяет значительно уменьшить Time-to-Market.
Однако в крупной компании прямое использование Agile/Scrum затруднено: даже простое на первые взгляд изменение бизнес процесса может затрагивать несколько систем, за которые отвечают разные команды. Выпуск релиза приходится координировать с большим количеством заинтересованных лиц. Это сильно замедляет и проектирование и финальное интеграционное тестирование. В результате добиться снижения Time-to-Market кажется очень непростой задачей, осложненной к тому же непростой политической ситуацией, типичной для крупной организации.
Мы поговорим о системном подходе к снижению Time-to-Market для сложных задач координации релиза, характерных для крупных организаций
Денис Тучин - Удачные и неудачные паттерны распределённого Agile (Agile Days ...Denis Tuchin
Видео выступления: https://www.youtube.com/watch?v=vOMSRSTl1Xo
Хотим мы этого или нет, но часто приходится работать с удалёнными командами, а иногда и с полностью распределёнными, когда все участники сидят в разных местах. На докладе разберём некоторые паттерны организации взаимодействия распределённых Agile команд, какие из них работают лучше, какие хуже и почему, а также посмотрим, что можно изменить, чтобы получился всё же Agile. Рассмотрим такие паттерны как:
- передача изолированных User Story удалённой команде
- Индивидуальные User stories
- Scrum of Remote Scrums
- Функциональные распределённые команды
- Scrum in spite of distributed team
В “классическом” энтепрайзе правят водопадные процессы. Это позволяет снизить затраты на старт новых проектов, но сильно ухудшает время Time to market. Переход на гибкие методологии позволяет это время значительно улучшить. Это очень не просто. Каждая команда разработки страдает от большого количества зависимостей. И в большой организации таких зависимостей настолько много, что представленный самому себе Agile в такой команде через какое-то время может и помереть. Перестраивать организацию процессов приходится полностью, сверху донизу.
Мы поговорим про специфику внедрения Agile в крупной организации сравнив две компании — типичную крупную веб-компанию и классический “кровавый энтепрайз”.
Agile Vector - внедрение agile разработки в РайффайзенбанкеAlexey Deryushkin
Доклад на 60 минут с пошаговым описанием процесса внедрения гибких методологий разработки в окружении, работающем по «водопаду», проблем такого точечного внедрения и их способов решений на примере нескольких связных проектов, а также влияние такого внедрения на IT банка в целом. Затрагиваются все темы, связанные с постановкой производства ПО -- от технических практик до образа мышления, на примерах из жизни. История успеха длинной в два года, которая не собирается завершаться.
Максим Богуславский, Ищем специалиста по обеспечению качества вместеScrumTrek
Проворные методологии прочно вошли в жизнь современной разработки, мы изучили процессы, внедрили их и пожимаем плоды. Теперь вам в команду нужен специалист по обеспечению качества. На примере своего опыта подбора, я хочу показать как собрать команду своей мечты. На докладе я расскажу о:
- подготовке к подбору человека;
- составлении описания вакансии;
- проведении собеседования;
- проведении испытательного срока;
- последующей работе с сотрудником.
Антон Немчинов, Применимость SAFe в крупной финансовой организацииScrumTrek
Гибкие практики разработки ПО не могут существовать долго в рамках одной команды в крупной организации. Попытки масштабирования подхода на всю организацию сталкиваются с ограничением самой организации. Можно придумать подход самому. А можно воспользоваться готовыми методики, как на пример SAFe. Но без адаптации, изменения процессов, ролей и мировоззрения в организации такая трансформация взлететь не сможет. Мой доклад об опыте применимости SAFe в конкретной крупной финансовой организации и о том, через какие изменения она должна пройти, чтобы достичь успеха.
Выбор лучших специалистов, снижение расходов
Фриланс, аутсорсинг и офшорная разработка
Быстрый старт и безболезненное завершение
Адаптация под текущие условия рынка
Возникающие проблемы
Денис Тучин - Удачные и неудачные паттерны распределённого Agile (Agile Days ...Denis Tuchin
Видео выступления: https://www.youtube.com/watch?v=vOMSRSTl1Xo
Хотим мы этого или нет, но часто приходится работать с удалёнными командами, а иногда и с полностью распределёнными, когда все участники сидят в разных местах. На докладе разберём некоторые паттерны организации взаимодействия распределённых Agile команд, какие из них работают лучше, какие хуже и почему, а также посмотрим, что можно изменить, чтобы получился всё же Agile. Рассмотрим такие паттерны как:
- передача изолированных User Story удалённой команде
- Индивидуальные User stories
- Scrum of Remote Scrums
- Функциональные распределённые команды
- Scrum in spite of distributed team
В “классическом” энтепрайзе правят водопадные процессы. Это позволяет снизить затраты на старт новых проектов, но сильно ухудшает время Time to market. Переход на гибкие методологии позволяет это время значительно улучшить. Это очень не просто. Каждая команда разработки страдает от большого количества зависимостей. И в большой организации таких зависимостей настолько много, что представленный самому себе Agile в такой команде через какое-то время может и помереть. Перестраивать организацию процессов приходится полностью, сверху донизу.
Мы поговорим про специфику внедрения Agile в крупной организации сравнив две компании — типичную крупную веб-компанию и классический “кровавый энтепрайз”.
Agile Vector - внедрение agile разработки в РайффайзенбанкеAlexey Deryushkin
Доклад на 60 минут с пошаговым описанием процесса внедрения гибких методологий разработки в окружении, работающем по «водопаду», проблем такого точечного внедрения и их способов решений на примере нескольких связных проектов, а также влияние такого внедрения на IT банка в целом. Затрагиваются все темы, связанные с постановкой производства ПО -- от технических практик до образа мышления, на примерах из жизни. История успеха длинной в два года, которая не собирается завершаться.
Максим Богуславский, Ищем специалиста по обеспечению качества вместеScrumTrek
Проворные методологии прочно вошли в жизнь современной разработки, мы изучили процессы, внедрили их и пожимаем плоды. Теперь вам в команду нужен специалист по обеспечению качества. На примере своего опыта подбора, я хочу показать как собрать команду своей мечты. На докладе я расскажу о:
- подготовке к подбору человека;
- составлении описания вакансии;
- проведении собеседования;
- проведении испытательного срока;
- последующей работе с сотрудником.
Антон Немчинов, Применимость SAFe в крупной финансовой организацииScrumTrek
Гибкие практики разработки ПО не могут существовать долго в рамках одной команды в крупной организации. Попытки масштабирования подхода на всю организацию сталкиваются с ограничением самой организации. Можно придумать подход самому. А можно воспользоваться готовыми методики, как на пример SAFe. Но без адаптации, изменения процессов, ролей и мировоззрения в организации такая трансформация взлететь не сможет. Мой доклад об опыте применимости SAFe в конкретной крупной финансовой организации и о том, через какие изменения она должна пройти, чтобы достичь успеха.
Выбор лучших специалистов, снижение расходов
Фриланс, аутсорсинг и офшорная разработка
Быстрый старт и безболезненное завершение
Адаптация под текущие условия рынка
Возникающие проблемы
Профессиональное управление распределенными проектамиEvgeny Savitsky
Web система для профессионального управления распределенными проектами
Покрывает весь цикл разработки проекта – от пожелания заказчика до работающего продукта
Обеспечивает максимальную «прозрачность» выполнения проекта
НЕ является набором интегрированных инструментов
Полный жизненный цикл – от первоначальной идеи до поставки продукта
Работа с требованиями онлайн
Репозиторий требований, редактирование в браузере
Двухсторонняя интеграция с MS Word
Версионирование требований, бейзлайны
Контроль изменений, сравнение версий
Трассировки требований
База знаний
Работа с тестовой документацией
Доски задач проекта
Эволюция управления требованиями в ЖЦ информационной системыEvgeny Savitsky
Процесс управления требованиями меняется в зависимости от стадии жизненного цикла продукта. В начале, когда нет требований лучше использовать легковесные практики, например, Scrum и User Story. По мере развития продукта необходимо документировать требования и принятые технические решения. Таким образом, на этапе эксплуатации и поддержки продукта вы сможете организовать процесс разработки основанный на требованиях и добиться высокой эффективности и качества при внесении изменений.
Автоматическое управление DevOps активностями в стартапеEvgeny Savitsky
Культура DevOps отлично подходит инженерной команде стартапа. Однако, после автоматизации тестирования и выпуска сборки, на команду сваливается большой объем разноплановых задач, превращая весь план работ в неуправляемый хаос. DevOps board решает эту проблему путем дополнения DevOps инструментарем сбора баг-репортов непосредственно по факту возникновения ошибок и автоматизации управления активностями инженерной команды.
Система управления требованиями Devprom alm 3.5Evgeny Savitsky
Современный web-инструмент для разработки и управления требованиями
Совместное создание полноценных документов требований из браузера
Обсуждение и рецензирование требований всей командой
Документирование UML-моделей, формул и алгоритмов
Версионирование и трассировка требований на проектные артефакты
Разработка, тестирование и документирование основанные на требованиях
Загрузка и выгрузка требований в формате Microsoft Word
Полностью настраиваемый процесс работы над требованиями
Сбор и визуализация метрик для анализа проблем и повышения продуктивности
Конспект составлен по Е-курс "Использование и управление информационной системы" для подготовки к экзамену по квалификации специалиста информационной технологии
Семён Факторович (Noveo) рассказывает о карьерных лестницах и различных профессиях в IT-индустрии, 20.02.2013
Software Industry 101 — это серия обзорных лекций для студентов Новосибирского государственного университета о профессиях в IT и о реалиях коммерческой разработки софта.
Более подробную информацию, материалы лекций и раписание занятий можно посмотреть на http://bit.ly/industry101
* Немного общей информации про проектное управление
* Детально - про классическое планирование по PMBoK (спасибо Рите Мулкахи и ее команде).
* Немного общей информации про SCRUM
Презентация "Использование механизмов управления проектами с помощью функцион...Helen Kopteva
Данная презентация была подготовлена Андреем Кукановым ("Кодерлайн") для вебинара "Использование механизмов управления проектами с помощью функционала 1С:Документооборот". Речь шла о том, как контроль при проектном управлении меняет подходы к работе со стороны высшего менеджмента, делает управление более прозрачным и понятным.
Методики управления развитием ис на базе 1сHelen Kopteva
Данная презентация была представлена в ходе вебинара "Методики управления развитием ИС на базе 1С. СППР как возможный инструмент поддержки данных методик". Ведущий - Олег Демиденко, руководитель отдела внедрения, руководитель проектов компания "Кодерлайн".
Формирование и управление командой проекта
• Выбор партнера. Ключевые роли и люди на Проекте;
• Различия в подходах к внедрению систем;
• Мотивация персонала на достижение результата и преодоление сопротивления внутри компании.
Similar to Система управления требованиями Devprom (20)
2. Мы знаем, что..
• Все требования к ПО однозначно и
непротиворечиво формулируются в
Техническом Задании
• Требования не меняются по ходу
проекта
• Сроки разработки строго соблюдаются
3. В реальной жизни
• Требования постоянно меняются в
ходе разработки
• Требования могут противоречить
друг другу
• Меняются приоритеты разработки
• Ограничены ресурсы – нужно уметь
расставлять приоритеты
• Ограничены сроки – нужно ясно
понимать, какой функционал к какой
дате будет реализован
Требования
Планы
Трудозатраты
4. Постоянно важно знать
• Что нужно сделать и почему именно это?
• Что именно сейчас делают разработчики?
• Когда будет сделано то, что нам нужно?
• Сколько ресурсов на это уже ушло?
• Сколько ресурсов на это планируется еще
потратить?
«..Надо найти и актуализировать план..»
5. Реализовать функцию
печати файлов
Структурное решение
Проектный офис
Требования = ТЗ
Разработать GUI
модуля печати
Задачи
Сидоров
Программисты
4
Итерация
Настройка
параметров печати
Пожелания
Печать файлов
Функция
2010.1
РелизMS Word
Проект
Департамент разработки
6. Требования
• Требование = Техническое
Задание
• Функциональные требования
описываются в виде UML-
диаграмм, прецедентов
• У требований есть иерархия
• У требований всегда есть
ссылка на источник
• Требования можно выгружать в
MS Word
Реализовать функцию
печати файлов
Требования = ТЗ
7. Сбор и анализ требований
• Настраиваемые типы
требований
• Настраиваемые состояния
и переходы (workflow)
• Настраиваемые списки
• История изменений
требований
• «Срезы» по тегам
• Архив страниц
9. Валидация требований
• Формирование тестовых планов
• Ручной запуск тестов
• Поддержка окружений
• Создание дефектов, связанных с тестом
• Отчеты по тестированию версий продукта
10. Пожелания
• Пожелания – декомпозиция требований на
небольшие блоки, имеющие ценность для
заказчика
• У пожеланий есть приоритет, состояние, оценка
• Результат работы по пожеланию можно
протестировать и продемонстрировать
ОшибкиДоработки
Реализация
требований
Настройка параметров
печати
Пожелания
11. Задачи
• Задача – назначается на
участника проекта
• Исполнитель отчитывается о
прогнозируемых и фактических
трудозатратах
• Задача относится к итерации, у
задачи есть состояние
• У задачи есть тип (анализ,
разработка, проектирование,
тестирование…)
Разработать GUI
модуля печати
Задачи
12. Совместная работа
• Руководство, сейлы, заказчики – получают отчеты и
статистику
• Аналитики – заносят требования и пожелания
• Руководители проектов – планируют релизы, управляют
пожеланиями, подписывают требования
• Разработчики – дают оценку трудозатрат, указывают
фактические трудозатраты
• Тестировщики – заносят ошибки, отмечают протестированный
функционал
• Внедренцы – заносят ошибки, ведут базу знаний
• Все – общаются
17. Портфели проектов
• «Взгляд сверху» на проекты компании
• Основные вехи проектов
• Отклонения от плановых сроков
18. Анализ загрузки ресурсов
• Планируемая и фактическая загрузка
сотрудников
• Индикация перегрузки и недогрузки
• Быстрый просмотр назначенных задач
19. Таймшиты
• Сводная информация по затраченному
времени по каждому проекту и сотруднику
• Экспорт в Excel для отчетности
20. Ценность для компании
• Инструмент управления требованиями
• Приоритеты, исходные данные, трудозатраты,
история изменений
• Управление разработкой
• Прозрачность, трудозатраты
• Управление проектом
• Сроки, ответственные, выгрузка в MS Project
• Аналитические данные
• Отчеты для руководства
21. Преимущества Devprom
• Скорость и стоимость внедрения и
поддержки
• Гибкость и простота настройки
• Быстрая реализация требуемых доработок
• Цикл выпуска новых версий 1 месяц
• Качественная поддержка на русском языке
22. Стоимость решения
• Лицензия пользователя 6750 рублей
• Не имеет срока окончания действия
• Не привязана к конкретному человеку
• Включен 1 год поддержки
• Поддержка от 49000 рублей в год
• Всегда бесплатные обновления до
новых версий
23. Дальнейшие шаги
• Пробная установка на тестовый сервер
• Помощь в установке и настройке
• Пилотный проект (проекты)
• Обучение пользователей
• Промышленная эксплуатация
• Перенос на боевое окружение
• Подключение всех пользователей
Editor's Notes
----- Meeting Notes (20.06.11 10:39) -----
сведение всех затрат на проекте, включая непроектные работы