• Save
Scrum practic
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Scrum practic

on

  • 1,292 views

Общие проблемы разработки средних и больших проектов. Их решение в scrum. ...

Общие проблемы разработки средних и больших проектов. Их решение в scrum.
Особенности работы по методологии scrum.

Statistics

Views

Total Views
1,292
Views on SlideShare
1,292
Embed Views
0

Actions

Likes
1
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Scrum practic Presentation Transcript

  • 1. Теория и практика методологии разработки Scrum Владислав Богатырёв
  • 2. Разработка продукта это не только кодТЗ на функционал и информационная архитектурачто сделатьЭкранные формыкак выглядит НачалоИнформационная структура проектакак организовано внутриПоверхностное проектированиеНьюансыаудитория, бизнес-процессы, наследование старыхтехнологий/контента, etcСтоимость и сроки
  • 3. Разработка продукта это не только код Проектирование Собственно, разработка Документация Дизайн Середина Верстка Тестирование проекта Промежуточный контроль результата
  • 4. Разработка продукта это не только код. Приемка и доводка Внедрение Конец Инструкции Поддержка проекта
  • 5. Этапы разработки
  • 6. Большие и средние проекты это вам немалыеМалые Средние и большие Заказчик это организация. Решения принимает Заказчик это человек комитет (долго и мучительно) или вечно занятый биг Над проектом работает обычно 1-2 босс. программиста, одинаковое понимание Могут возникать проблемы с тем, что контактное лицо не системы достигается легко, устно. имеет полномочий или не хочет брать ответсвенность, а Техзадание делается быстро биг босс недоступен. Многие стадии пропускаются или не Большой объем предварительной работы по описанию осознаются системы, много коммуникации с заказчиком. Создание Стадии легкие и быстрые, ТЗ может тянуться месяцами. последовательность не критична Неправильная последовательность стадий или Если что то забыли, можно быстро сделать пропущенные/забытые стадии блокируют другие на Изменения в ТЗ и переделки дешевы недели и месяцы, затягивается весь проект Ошибки архитектуры незаметны или Изменения в ТЗ дороги, поиск компромисса тяжелый дешевы Архитектурные ошибки могут быть фатальны Обычно затягивание сроков не так критично Затягивание сроков чревато потерями прибыли для для заказчика и разработчика заказчика/гневом начальства, а для разработчика Внедрение простое, часто делается голодной смертью заказчиком. Над проектом работает команда, которой нужно единое Приемка делается быстро понимание системы Практически любые проблемы могут быть Сверхурочная работа не помогает компенсированы сверхурочной работой. Риск для вашей репутации и кошелька, ценность Не получилось, ну и ладно. заказчика. От 1й встречи до оплаты недели/пара От 1й встречи до оплаты месяцы месяцев
  • 7. Homo Заказчикус Не знает точно чего хочет и как оно должно выглядеть У него нет времени описывать будущую систему Постоянно меняет требования Обычно половину требований держит в тайне, чтобы потом предъявить их на этапе сдачи Хочет заранее знать сколько это стоит и сколько займет времени Хочет платить за готовый результат
  • 8. Методология разработки "Водопад"В классическом водопаде, следующие фазы идут примерно в такомпорядке: 1. Определение требований 2. Проектирование 3. Реализация 4. Интеграция 5. Тестирование и отладка (также «верификация») 6. Инсталляция 7. Поддержка
  • 9. Методология разработки "Водопад": естьнедостатки Долго - пока не сформулированы все требования, а система не спроектирована, работа не ведется. Нельзя менять требования. (заказчик их все равно вынужден менять и меняет, вероятность чего прямопропорциональна длительности проекта) Длительный и бюрократизированный подготовительный этап (отдельно его заказчик не хочет оплачивать, не всегда проект начинается, по крайней мере, с вами) И заказчик, и разработчик заложники собственных планов. Менять планы трудоемко. ...Не решает проблем больших и средних проектов
  • 10. Методология разработки "Scrum"Итеративная и гибкая(agile) методология разработки.Scrum — это набор принципов, на которых строится процессразработки, позволяющий в жёстко фиксированные небольшиепромежутки времени (спринты от 2 до 4 недель) предоставлятьконечному пользователю работающее ПО с новыми возможностями,для которых определён наибольший приоритет.
  • 11. Методология разработки "Scrum"Использует артефакты:Pruduct Backlog - содержит функциональные блоки(истории) дляреализации в проекте с приоритетами. Формируется всемиучастниками процесса. Приоритеты ставит заказчик.Sprint Backlog - содержит уточненные задачи к реализации витерации (спринте), определяются заказчиком и командой.Burndown Chart - индикатор прогресса, вместо диаграмм Ганнта
  • 12. Методология разработки "Scrum"История - задача на создание функционально завершенного, несущего пользу,компонета системы или фичи. Содержит минимально необходимые для успешнойсдачи описание и "how to demo", и приблизительную оценку трудоемкости.Приоритет историй определяет заказчик, принимая во внимание приблизительнуюоценку команды трудоемкостиСпринт - итеративный, фиксированный период работы команды (2 - 4 недели) пореализации взятых в работу историй. В период спринта, ТЗ на взятые в работуистории замораживается. Спринт завершается внедрением реализованной истории втекущую сборку системы.Команда сама определяет, когда готова к следующему спринтуКоманда сама определяет истории, которые готова взять в работу, руководствуясьприоритетом.Заказчик уточняет желаемый результат по заявленным к реализации историям,формируя sprint backlogВместо PM Scrum-мастер. Следит за соблюдением методологии, но не управляетвручную командой. Команда управляет собой сама
  • 13. Методология разработки "Scrum": Решаетпроблемы больших и средних проектов Быстрый старт. Поскольку разработка итеративна, перед каждой итерацией создается только необходимый набор документации. Поскольку разработка итеративна, а итерации коротки, заказчик может менять функциональные требования к еще не реализованным историям. Поскольку Product Backlog формируется динамически, заказчик может добавлять истории по изменению реализованного функционала. Поставка готового продукта происходит часто, что быстро выявляет проблемы и минимизирует риски. Частые итерации позволяют отказаться от ресурсоемких и сковывающих календарных планов Коммуникация с заказчиком более частая, более короткая, более продуктивная. Всегда обсуждается то, что существенно в данный момент. Любые ошибки и срывы сроков локальны и поэтому обходятся на порядок дешевле и менее критичны. Могут быть исправлены сверхурочной работой. Частые поставки снижают риск срыва проекта на порядок. Заказчик совершает оплаты часто
  • 14. О чем молчит "Scrum" Как получить Product Backlog с историями, которые пойдут в работу Когда проектировать Не говорит о обеспечении разработчиков всем необходимым для спринта: достаточно точным ТЗ и дизайном Когда делать приблизительные оценки историй Что делать с ошибками А как же поддержка внедренного функционала
  • 15. О чем молчит "Scrum": нулеваяитерация и трек проектирования
  • 16. О чем молчит "Scrum": нулевая итерацияПроектировщикам Необходима для создания приблизительной, высокоуровневой картины будущей системы с точки зрения пользователя Необходимо определить последовательность реализации историй на несколько историй вперед.Разработчикам Необходима для минимально достаточного проектирования, нужного для определения и оценки историй. Прежде чем взять в работу 1ю историю, необходымы знания о "стыковке" историй между собой
  • 17. О чем молчит "Scrum": параллельный трекпроектированияИдет впереди трека разработки хотя бы на одну итерациюВысокая нагрузка на команду проектировщиков: много взаимодействия с заказчиком, консультации разработчиков по их текущей итерации тестирование результата разработчиков по прошлой итерации и его сдача заказчику создание ТЗ, use case, прототипов и дизайна, etc для следующей итерации разработчиковВысокая нагрузка определяет необходимости: делегирования проектирования реализации разработчикам. быстрого прототипирования
  • 18. Scrum good practiciesПроектировщикам:Детализируйте прототипы итеративно, по мере назревающейнеобходимости и доступных ресурсов. Если времени нет/мало,лучше вначале решать задачи, блокирующие разработку.Когда нет времени, прототипируйте на бумаге. Делайте быстрее ипроще, все что можете, без излишней детализации.Используйте прототипы в качестве ТЗ, всегда, когда этовозможно.
  • 19. Scrum good practiciesРазработчикам:Управляйте конфигурацией и качеством поставок в угоду срокам.Лучше не сделать фичи или сделать наполовину, или попростому, чем сорвать дату поставки.Неэффективный/некрасивый код/архитектуру можно рефакторитьв следующей итерации, если это оправдано.Используйте магию проектирования гибких систем, дабы ихразвитие не определялось их архитектурой. Откладывайтереализацию определяющих архитектурное развитие компонент,на сколько возможно. Уделяйте максимум внимания приразработке фундаментальных компонент, которые неподдадутся изменениям в будущем.
  • 20. РезюмеБольшие и средние проекты это вам не маленькиеОсознанно и правильно выбранная методология разработки этонеобходимое условие успеха проектаScrum это гибкость и скоростьВ эффективном Scrum, параллельно разработке существует трекпроектировщиков, идущий на опережение разработчиков нанесколько итераций.В Scrum и разработчикам, и проектировщикам, и заказчику нужнанулевая итерация.Практикуйте хорошую практику: правильные шаги в правильнойпоследовательностью с правильной детализацией.
  • 21. Теория и практика методологии разработки Scrum Владислав Богатырёв