Agile/Scrum методологии разработки программного обеспеченияjazzteam
Сотрудница компании JazzTeam провела ряд лекций в Гродненском государственном университете имени Янки Купалы.
После конференции Solit-2013 в рамках ознакомительного тура по Беларуси для одного из англозычных докладчиков, руководство компании посетило Гродненский государственный университет имени Янки Купалы, где состоялось знакомство с руководством кафедры программного обеспечения интеллектуальных и компьютерных систем. В рамках продолжения отношений между компанией и кафедрой представитель компании JazzTeam провела несколько лекции по тематике разработки программного обеспечения.
Лекции проходили в рамках заседания студенческого семинара “Информатика – Сегодня”, которые университет и кафедра проводят регулярно.
Первая лекция была проведена 22 марта 2013 года на тему: “Agile/Scrum методологии разработки программного обеспечения”.
Посетителей, участников, слушателей этой лекции заинтересовали такие вопросы: преимущества и недостатки agile и scrum, как разработчики решают спорные моменты, как новичок может повлиять на всю команду, как замотивировать разработчиков и т.д. После доклада была продолжительная и насыщенная дискуссия по возникшим у слушателей вопросам.
На лекциях присутствовало много людей, начиная от первокурсников до преподавателей.
Лекции охватывали большой спектр вопросов, и все моменты были разобраны на примерах. Публика вела себя очень оживленно и интересовалась больше примерами из жизни, практическими навыками.
Впечатления о проведенных лекциях остались самые положительные. Спасибо за интересные вопросы и обсуждения!
Презентация была представлена в ходе обсуждения вебинара "Scrum с нуля", автор - Валерий Федоров, руководитель проектов компании "Кодерлайн".
http://www.koderline.ru/
Обсуждение касалось вопроса, почему IT - самая передовая отрасль во всем мире отдает предпочтение именно Scrum. Выступающий представил личный практический опыт.
Agile/Scrum методологии разработки программного обеспеченияjazzteam
Сотрудница компании JazzTeam провела ряд лекций в Гродненском государственном университете имени Янки Купалы.
После конференции Solit-2013 в рамках ознакомительного тура по Беларуси для одного из англозычных докладчиков, руководство компании посетило Гродненский государственный университет имени Янки Купалы, где состоялось знакомство с руководством кафедры программного обеспечения интеллектуальных и компьютерных систем. В рамках продолжения отношений между компанией и кафедрой представитель компании JazzTeam провела несколько лекции по тематике разработки программного обеспечения.
Лекции проходили в рамках заседания студенческого семинара “Информатика – Сегодня”, которые университет и кафедра проводят регулярно.
Первая лекция была проведена 22 марта 2013 года на тему: “Agile/Scrum методологии разработки программного обеспечения”.
Посетителей, участников, слушателей этой лекции заинтересовали такие вопросы: преимущества и недостатки agile и scrum, как разработчики решают спорные моменты, как новичок может повлиять на всю команду, как замотивировать разработчиков и т.д. После доклада была продолжительная и насыщенная дискуссия по возникшим у слушателей вопросам.
На лекциях присутствовало много людей, начиная от первокурсников до преподавателей.
Лекции охватывали большой спектр вопросов, и все моменты были разобраны на примерах. Публика вела себя очень оживленно и интересовалась больше примерами из жизни, практическими навыками.
Впечатления о проведенных лекциях остались самые положительные. Спасибо за интересные вопросы и обсуждения!
Презентация была представлена в ходе обсуждения вебинара "Scrum с нуля", автор - Валерий Федоров, руководитель проектов компании "Кодерлайн".
http://www.koderline.ru/
Обсуждение касалось вопроса, почему IT - самая передовая отрасль во всем мире отдает предпочтение именно Scrum. Выступающий представил личный практический опыт.
Истории Пользователей (User Stories) - семинар на AgileUkraine 7, 2009-04-25Timofey (Tim) Yevgrashyn
Семинар на тему Историй Пользователя (User Stories) прошел в рамках седьмой конференции AgileUkraine.
Первоначально задуманный как практическое упражнение для 20 человек, он превратился в захватывающую тематическую дискуссию с аудиторией в 50 человек.
Судя по отзывам, участникам было о чем пообщаться.
Итак, вы делает свой проект по Agile методологии. Итерации, планы, Daily Scrum — вроде все это работает.
Один из первых вопросов, с которым сталкиваются команды: «что положить в Бэклог продукта?». Абстрактное слово Требования уже давно известно и в тоже время, Гибкие подходы требуют гибкости мышления во всех областях. Ведь мы договорились, что Требования будут появляться по мере необходимости — мы же AGILE в конце концов. А как же описать всю систему, как построить планы, в конце концов, как оценить сложность?
С одной стороны пользователям не нужны рассказы про архитектуру, базы данных, им нужно «клац-клац, тык-тык». С другой стороны, команда должна знать, что мы вообще строим. Простые инструменты и форматы оказываются более полезными в условиях гибкости и постоянных изменений.
Agile формат записи требований в виде Историй Пользователя уже широко популярен. О нем рассказывают на тренингах, в книгах, статьях и когда хвастаются успехами внедрения Scrum, XP и других методологий.
В тоже время, простота формата хранит много ловушек. Более того, этот формат не единственный
Мы поговорим о том, что же отличает Agile Работу с Требованиями, на чем фокус и какие инструменты нам помогут.
Михаил Лукьянов, Дмитрий Шайхатаров, Agile среди водопадов. Использование SCR...ScrumTrek
Трудно представить возможность применения Agile в компаниях с большим количеством зарегламентированных процессов, которые, к тому же, ориентированны на водопадную модель разработки ПО. На примере разработки системы управления рисками на Финансовых рынках мы поделимся своим опытом как можно построить полноценный Agile процесс исключительно с использованием стандартного SCRUM framework. Мы расскажем об бизнес процессе, решенных проблемах и инженерных практиках, которые позволили обеспечить высокую скорость delivery в рамках данной системы.
Истории Пользователей (User Stories) - семинар на AgileUkraine 7, 2009-04-25Timofey (Tim) Yevgrashyn
Семинар на тему Историй Пользователя (User Stories) прошел в рамках седьмой конференции AgileUkraine.
Первоначально задуманный как практическое упражнение для 20 человек, он превратился в захватывающую тематическую дискуссию с аудиторией в 50 человек.
Судя по отзывам, участникам было о чем пообщаться.
Итак, вы делает свой проект по Agile методологии. Итерации, планы, Daily Scrum — вроде все это работает.
Один из первых вопросов, с которым сталкиваются команды: «что положить в Бэклог продукта?». Абстрактное слово Требования уже давно известно и в тоже время, Гибкие подходы требуют гибкости мышления во всех областях. Ведь мы договорились, что Требования будут появляться по мере необходимости — мы же AGILE в конце концов. А как же описать всю систему, как построить планы, в конце концов, как оценить сложность?
С одной стороны пользователям не нужны рассказы про архитектуру, базы данных, им нужно «клац-клац, тык-тык». С другой стороны, команда должна знать, что мы вообще строим. Простые инструменты и форматы оказываются более полезными в условиях гибкости и постоянных изменений.
Agile формат записи требований в виде Историй Пользователя уже широко популярен. О нем рассказывают на тренингах, в книгах, статьях и когда хвастаются успехами внедрения Scrum, XP и других методологий.
В тоже время, простота формата хранит много ловушек. Более того, этот формат не единственный
Мы поговорим о том, что же отличает Agile Работу с Требованиями, на чем фокус и какие инструменты нам помогут.
Михаил Лукьянов, Дмитрий Шайхатаров, Agile среди водопадов. Использование SCR...ScrumTrek
Трудно представить возможность применения Agile в компаниях с большим количеством зарегламентированных процессов, которые, к тому же, ориентированны на водопадную модель разработки ПО. На примере разработки системы управления рисками на Финансовых рынках мы поделимся своим опытом как можно построить полноценный Agile процесс исключительно с использованием стандартного SCRUM framework. Мы расскажем об бизнес процессе, решенных проблемах и инженерных практиках, которые позволили обеспечить высокую скорость delivery в рамках данной системы.
Мастер-класс. Интерактивная презентация + деловая игра «Управление командами разрабатывающими ПО по Agile (Scrum) и выводу нового программного продукта (ПО) на рынок» c использованием симулятора проектной деятельности (СПД) BesTeamKpi®
The presentation was delivered on June 13th 2019 for Business Analysts and Project Managers in Kharkiv, Ukraine.
That is an analyzed summary of main (for the date) frameworks and description on processes and roles of Product Manager.
Prepared by Olena Petrova
Маркетинговая информационная система как основа для принятия решенийЭКСПЕРТ ПО МАРКЕТИНГУ
Хорошее управленческое решение базируется на творческой переработке собранной информации. Наиболее распространенным и оптимальным методом организации работы с информацией с точки зрения «цена - адекватные результаты» является самостоятельное построение маркетинговых информационных систем. Принципиальным преимуществом в данном случае является возможность учета специфики предприятия. Данная презентация является примером пособия «как сшить пиджак своими силами», а именно как можно самим создать систему по сбору, переработке и распределению информации.
Scrumble - это интересный способ узнать или закрепить свои знания относительно Scrum фреймворка в игровой и интересной форме. Данная Игра позволяет, в спокойной обстановке, без паники и спешки, найти решения самых распространенных проблем, с которыми сталкиваются команды во время реализации своих проектов, чтобы в реальной ситуации реагировать на них быстро, эффективно и адекватно.
4. Правила:
1. Изобразить слово или фразу на
карточке.
2. Изображения не должны содержать
ни цифр, ни букв.
3. Угадавший зарабатывает один бал.
4. Побеждает тот у кого больше всего
балов.
10 минут
5. Картинка того, какую ценность представляет продукт и каких бизнес целей помогает
достичь.
1
7. - High/Medium/Low
- MoSCoW
- Business value
- Стоимость риска и возможности
- Стоимость и эффект от внедрения
3
8. 4
Презентация Product Vision
Презентация Product Backlog
Проясняем и добавляем деталей к User story
Определяем критерии завершения User story
Проводим оценку User story
Разбивает Epic на User story
Разбиваем большие User story
Удаляем лишние PBI
Добавляем нужные PBI
9. 5
Cрок 3-4 месяца
Внедряемый функционал
Основывается на Product vision
План выбора User Stories и их
приоритетов
План изменений продукта
Фокусировка команды 3-4 месяца
10. 6
Готовые User story
Важные User story
Учитываем технические и логические зависимости
2 часа на выбор User story
2 часа на разбивку User story на Tasks
Определение необходимых компетенций
Определение необходимых ресурсов
Определить Цель Sprint
Презентация плана (Product owner)
11. Формула:
Как, <роль/персона юзера>,
я <что-то хочу получить>,
<с такой-то целью> .
Story points:
Title: Жилые дома
Priority:
Description:
Спонсор проекта хочет, чтобы в городке были 2
коттеджа для того, чтобы в них могли с комфортом жить
2 семьи.
Acceptance Criteria:
[ ] -В домах 1 и 2 готовы коробка и крыша
[ ] -В домах есть электричество
[ ] -В домах можно начинать внутреннюю отделку
Complexity: Business value:
10 Must have
HighHigh
6.1
Материалы:
2 доски, одна напротив другой
Маркеры 8 штук
10-20 карточек с терминами
Ватман для фиксации балов
Вопросы по завершению игры:
Что было сложно изобразить?
Что больше всего запомнилось?
Какие понятия термины не понятны?
Что нужно детальней обьяснить?
Каждая Идея остается идей пока она грамотно не зафиксирована на бумаге.
И первый документ с которого рождается проект есть Вижин продукта или проекта.
В Вижине продукта должно быть за фиксировано:
Целевая группа – для кого делается продукт
Потребности этой группу
Из чего состоит продукт, как он решает потребности этих пользователей
Ценности этого продукта
Если смотреть на это стороны проекта, то добавляются такие важные данные как
Цель проекта
Учасники проекта
Результаты проекта и активности
Ключевые контрольные поставки
Риски
Ограничения
Объём работ
Бизнес какой-то проект до добавляется такая составляющая как расходы и доходы.
Все это очень удобно и наглядно можно описать с помощью таких канвасов как Бизнес модел канвас и Проджект канвас.
Зачем это нужно в Скрам, да затем чтобы команда понимала какие изначально ставятся задачи и цели во главе этого продукта, и прикладывали все усилия к тому чтобы этих целей достичь.
В классике Вижин продукта/проекта представлен каким-то инициирующим документом проект, например Устав проекта.
Все с этого начинается.
Следующий очень важный артефакт в Scrame и в процессе создания продукта это создание Product Backlog.
Что такое Product Backlog, это плоский список составляющих частей продукта/результата которого команда планирует достичь.
Product Backlog создается на основании Product vision/Business vision.
Product Backlog определяет рамки проекта, он не статичный и постоянно Эволюционирует растет, уменьшаются.
Создает и отвечает за Product Backlog Product owner.
Только Product owner может добавлять и удалять элементы из Product Backlog.
Отдельный элемент Product Backlog называется Product Backlog Items (PBI).
Product Backlog Items есть двух типов:
Business User Stories
Non Business User Stories
Business User Stories – относятся все User Stories которые дадут Бизнес ценность, все остальные это не бизнес User Stories .
Есть еще такое понятие как Epic – это набор связаны User Stories.
Non Business User Stories – чаще всего добавляет команда проекта со Скрам мастером в Беклог.
Пример:
После того как Product Backlog сформирован, следующей очень важной задачей для Product Owner становится приоритезировать Product Backlog Items.
Эта задача не менее сложна чем его подготовить, особенно сложно оценить если это касается денег.
Также не всегда прослеживается прямая зависимость отдельных элементов продукта и Бизнес выгоды, поэтому чаще всего заказчики хотят все и сразу.
Есть много методик как это можно сделать, но на данном тренинге мы их рассматривать не будем так как это больше задача практик по бизнес анализу, чем по Scrum.
Вам нужно знать что это должно быть сделано, дальше вы поймете почему.
Следующая очень важное мероприятие это Product Backlog Grooming.
Данное мероприятие начинается с того что Product Owner презентует команде:
Презентация Product Vision
Презентация Product Backlog
Дальше команда проясняет и дополняет User stories необходимой информацией, а также критериями завершения.
Разбирать User story начинают с самых приоритетных, двигаясь в низ.
Если User story дополнена всей необходимой информацией ее оценивают.
Если User story очень большая ее дробят на User story по меньше.
Оценить желательно все User story, но детализировать нужно только на первые 2-3 спринта, так как после реализации Спринтов содержание Product Backlog может измениться.
User story не должны быть изначально сильно детализированы, так как это не вызовет дискуссии и каждый может понять написанное по совему.
Называют такое понятие Over Groomed – лишняя детализация, уменьшает коммуникации!
После проведения Product Backlog Grooming, Product Owner должен провести реприоритезация PBI, по следующим параметрам:
1. Бизнес потребности
2. Потребности команд
3. Организационные потребности
Одна из хороших практик которая может помочь на Backlog Grooming это User story maping.
Следующая задача не обязательная в Scrum, но рекомендуемая поэтому мы ее тоже проговорим.
Эта практика называется Release Planing
Не обязательно – но рекомендовано
Средний срок 3-4 месяца (бизнес ценность)
Внедряемый функционал
Основывается на Product vision
План выбора User Stories и их приоритетов
План изменений продукта
Фокусировка команды 3-4 месяца
1. Не являются детальным описанием требований
2. Простое описание функционала
3. Два атрибута для планирования (Размер, )
4. Это небольшие инкременты ценной функциональности
5. Не детализированы в самом начале проекта
Хорошая история:
Написана так чтобы можно было протестировать
Без технического жагрона
Небольшие истории лучше больших
Тесты должны быть написаны до кода.
История должна выполняться без привязки к конкретным элементам.
Каждая история должна содержать оценку.
История должна приводить к конкретному результату.
История должна вмещаться в Sprint.
Эмпирический процесс-не прерывное улучшение.
Цель – показать результаты и обсудить
Планируется - на последнем Daily Scrum
Когда - после завершения последней User Story
Где – в комнате команды
Как – в живую, без слайдов
Кто презентует – команда
Формат проведения – Вопросы ответы
Длительность – 1 час на одну неделю Sprint
Результат – принятые User Stories или новые User Stories
После Sprint Review
Выбрать цель встречи – что будем менять (процесс, коммуникации)
Сфокусированная беседа – только по теме
Обсуждение вариантов улучшения
Разработка плана улучшения
Выполнение ритуала на согласие (Понимаю, Принимаю, Поддерживаю)