Successfully reported this slideshow.

вольфсон основы Agile

8

Share

1 of 78
1 of 78

More Related Content

Viewers also liked

More from Magneta AI

Related Audiobooks

Free with a 14 day trial from Scribd

See all

вольфсон основы Agile

  1. 1. Основы Agile Борис Вольфсон HeadHunter
  2. 2. Поднимите руки, те кто использует Agile более полугода
  3. 3. Данный доклад предназначен только для новичков, поэтому все, кто уже работает по Agile идите слушать Shannon Ewan
  4. 4. CTO HeadHunter Вольфсон Борис Автор книги «Гибкое управление проектами и продуктами» Спикер и тренер
  5. 5. История программирования Если программирование - это индустрия, то почему бы не использовать методы управления из других областей?
  6. 6. Водопадная модель http://www.serena.com/docs/agile/papers/Managing-The-Development-of-Large-Software-Systems.pdf
  7. 7. Кто-то использует тяжеловесные методологии?
  8. 8. Это в западных странах, а у нас
  9. 9. Россия •Отсутствие процессов Запад •Тяжеловесные процессы
  10. 10. Кто-то работает без методологии?
  11. 11. Зачем нужен Agile?
  12. 12. Agile-манифест разработки программного обеспечения Мы постоянно открываем для себя более совершенные методы разработки программного обеспечения, занимаясь разработкой непосредственно и помогая в этом другим. Благодаря проделанной работе мы смогли осознать, что: Люди и взаимодействие важнее процессов и инструментов Работающий продукт важнее исчерпывающей документации Сотрудничество с заказчиком важнее согласования условий контракта Готовность к изменениям важнее следования первоначальному плану То есть, не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева. http://www.agilemanifesto.org/iso/ru/
  13. 13. Ценности Agile Мы постоянно открываем для себя более совершенные методы разработки программного обеспечения, занимаясь разработкой непосредственно и помогая в этом другим. Благодаря проделанной работе мы смогли осознать, что: Люди и взаимодействие важнее процессов и инструментов Работающий продукт важнее исчерпывающей документации Сотрудничество с заказчиком важнее согласования условий контракта Готовность к изменениям важнее следования первоначальному плану То есть, не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева. http://www.agilemanifesto.org/iso/ru/
  14. 14. Принципы Agile 1. Наивысшим приоритетом для нас является удовлетворение потребностей заказчика, благодаря регулярной и ранней поставке ценного программного обеспечения. 2. Изменение требований приветствуется, даже на поздних стадиях разработки. Agile- процессы позволяют использовать изменения для обеспечения заказчику конкурентного преимущества. 3. Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев. 4. На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе. 5. Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им. 6. Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды.
  15. 15. Принципы Agile 7. Работающий продукт — основной показатель прогресса. 8. Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно. Agile помогает наладить такой устойчивый процесс разработки. 9. Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта. 10.Простота — искусство минимизации лишней работы — крайне необходима. 11.Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд. 12.Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.
  16. 16. Что такое Agile Agile – подходы к созданию продуктов, путем непрерывной быстрой поставки ценного рабочего функционала самоорганизованной командой профессионалов в сотрудничестве с заказчиком © Борис Вольфсон
  17. 17. Принципы, ценности, практики http://www.slideshare.net/TechWellPresentations/to-presentation-30268801 Ценности Принципы Практики
  18. 18. Гибкие практики http://www.versionone.com/pdf/2013-state-of-agile-survey.pdf
  19. 19. Итеративность Водопадные Итеративные А А В В
  20. 20. Высокая турбулентность Водопадные Итеративные А А В В C C
  21. 21. Итеративно, но неинкрементально http://jpattonassociates.com/dont_know_what_i_want/
  22. 22. Итеративно и инкрементально http://jpattonassociates.com/dont_know_what_i_want/
  23. 23. Треугольник ограничений Водопад Agile Содержание Ресурсы Время Ресурсы Время Зафиксировано Планируется Содержание
  24. 24. Agile треугольник Ценность Качество Ограничения http://theagileexecutive.com/2010/07/22/the-devops-triangle/ http://www.brighthubpm.com/agile/50212-the-agile-triangle-value-quality-and-constraints/ Меняется определение успешности проекта
  25. 25. Что такое Agile с точки зрения процессов Agile – семейство методологий программного обеспечения, которые соответствуют ценностям и принципам Agile-манифеста © Борис Вольфсон
  26. 26. Agile-зонтик Henrik Kniberg
  27. 27. Гибкие методологии http://www.versionone.com/pdf/2013-state-of-agile-survey.pdf
  28. 28. Scrum
  29. 29. Кто-то работает по Scrum?
  30. 30. Хиротака Такэути и Икудзиро Нонака
  31. 31. The New New Product Development Game
  32. 32. Что значит Scrum?
  33. 33. Кен Швабер и Джеф Сазерленд
  34. 34. http://www.scrumguides.org
  35. 35. Scrum в двух словах Беклог продукта Беклог спринта Скам-митинг 15 минут Готовый продукт с новой функциональностью Владелец продукта Владелец продукта 8 часов Спринт 1-4 недели Ретроспектива Обзор спринта Планирование спринта Скрам-мастер Команда 7±2 человек
  36. 36. Определение Фреймворк, в рамках которого возможно решать сложные адаптивные проблемы и в то же время продуктивно и креативно разрабатывать продукты наивысшего качества.
  37. 37. Элементы Scrum Роли • Владелец продукта • Скрам-мастер • Команда разработки • Команда Артефакты • Бэклог продукта • Бэклог спринта • Инкремент продукта Процессы • Планирование спринта • Обзор спринта • Ретроспектива • Скрам-митинг • Спринт
  38. 38. Роли • Скрам Команда состоит из Владельца Продукта, Команды Разработки и Скрам Мастера. Скрам Команды являются самоорганизующимися и кросс-функциональными Скрам Команда • Владелец Продукта ответственен за достижение максимальной ценности продукта и работы, выполняемой Командой Разработки. Владелец Продукта • Команда Разработки состоит из профессионалов, выполняющих работу по разработке потенциально “Готового” к выпуску Инкремента продукта каждый Спринт Команда Разработки • Скрам Мастер отвечает за то, чтобы Скрам был понят всеми участниками и работал.Скрам Мастер
  39. 39. Процессы • Сердцем Скрама является Спринт длительностью в один месяц или менее, в течение которого создается потенциально готовый̆ к выпуску и использованию Инкремент продукта. Спринт • Работа на предстоящий Спринт планируется во время Планирования Спринта. План действий создается при совместной работе всей Скрам Команды.Планирование Спринта • Ежедневные Скрамы –это 15-минутные мероприятия для Команды Разработки с целью синхронизации действий и создания плана работы на ближайшие 24 часа.Ежедневный Скрам • Встреча по Обзору Спринта проводится в конце Спринта для инспекции Инкремента и при необходимости адаптации Беклога Продукта. Во время Обзора Спринта Скрам Команда и заинтересованные лица обсуждают выполненную во время Спринта работу Обзор Спринта • Ретроспектива Спринта дает Скрам Команде возможность инспектировать себя и создать план улучшений для следующего Спринта.Ретроспектива Спринта
  40. 40. Артефакты • Упорядоченный список всего, что может быть нужным в продукте, он является единственным источником требований для любых изменений, которые может потребоваться внести в продукт. Беклог Продукта • Набор Элементов Беклога Продукта, выбранных для выполнения в текущем Спринте, а также план разработки Инкремента продукта Беклог Спринта • Сумма всех выполненных требований Беклога Продукта, реализованных во время текущего Спринта, и ценности всех предыдущих Спринтов Инкремент
  41. 41. Оценка проекта
  42. 42. Шкала оценок 0 0,5 1 2 3 5 8 13 20 40 100
  43. 43. Покер-планирование
  44. 44. 1453 Пользователь вводит логин и пароль для того, чтобы авторизоваться на сайте
  45. 45. 2 3 5 3 8 5 1453 Пользователь вводит логин и пароль для того, чтобы авторизоваться на сайте
  46. 46. Ла-ла-ла ла-ла ла- ла-ла-ла Ла-ла-ла ла-ла ла- ла-ла-ла 2 3 5 3 8 5 1453 Пользователь вводит логин и пароль для того, чтобы авторизоваться на сайте
  47. 47. 3 3 3 3 5 5 1453 Пользователь вводит логин и пароль для того, чтобы авторизоваться на сайте
  48. 48. 3 3 3 3 3 3 1453 Пользователь вводит логин и пароль для того, чтобы авторизоваться на сайте Оценка: 3
  49. 49. Отбор задач на спринт на основе скорости 36 37 38 39 40 41 42 43 44 45 46 1 2 3 4 5 6 7 8 Скорость Средняя скорость Спринты Сторипоинты
  50. 50. Отбор задач на спринт на основе скорости А B C D F G H I J Важность А B C D F Беклог продукта Беклог спринта Скоростькоманды
  51. 51. Диаграмма сгорания 0 2 4 6 8 10 12 0 5 10 15 20 25 30 35 40 45 50 1 2 3 4 5 6 7 8 9 10 Диаграмма сгорания в конце спринта Сторипоинты Идеал Истории пользователя Дни Сторипоинты Историипользователей
  52. 52. Диаграмма сгорания с отставанием 0 5 10 15 20 25 30 35 40 45 50 1 2 3 4 5 6 7 8 9 10 Диаграмма сгорания с отставанием Сторипоинты Идеал Дни Сторипоинты
  53. 53. Диаграмма сгорания с опережением 0 5 10 15 20 25 30 35 40 45 50 1 2 3 4 5 6 7 8 9 10 Диаграмма сгорания с опережением Сторипоинты Идеал Дни Сторипоинты
  54. 54. Доска задач План Аналитика Разработка Тестирование Готово A B C D E Важность
  55. 55. Обзор спринта Поставляет Владелец продуктаВладелец продукта КомандаКоманда Изменения в требованиях Разрабатывает Инкремент продукта Демонстрируется
  56. 56. Ретроспектива Не хочешь пропустить со мной по пиву? Не могу, я делаю список, в чем я могу усовершенствовать себя в следующем году Не- плохая идея, сделаю тоже самое Ничего. Совершенство достигнуто Мда, вот это конструк- тивность. Какая едкая зависть, тебе бы поработать над этим «Совершенствоваться не обязательно. Выживание – дело добровольное»
  57. 57. Ретроспектива Открытие – 5% Сбор данных – 30%-50% Проникновение в суть – 20%-30% Принятие решение – 10% Закрытие – 5%-10%
  58. 58. Цикл Деминга-Шухарта Plan Do Check Act
  59. 59. Канбан
  60. 60. Кто-то работает, использую Kanban?
  61. 61. Девять ценностей
  62. 62. Принципы 1. Начать с того, что делаем сейчас 2. Придти к соглашению идти путём эволюционных перемен 3. Изначально уважать существующие роли, должности и обязанности 4. Поощрять инициативные действия на всех уровнях организации
  63. 63. Практики Визуализация Ограничение работы в процессе Управление потоком Явные правила Обратные связи Улучшения с помощью экспериментов, используя модели и научный подход
  64. 64. Визуализация План 5 Аналитика 3 Разработка 4 Тестирование 4 Готово A B C D E F G H I J K M N O P Q
  65. 65. Визуализация
  66. 66. Диаграмма кумулятивного поток http://paulklipp.com/blog/
  67. 67. Scrumban Scrum • Роли • Артефакты • Процессы • Псевдоитерации Kanban • WIP • Уменьшение Lead Time
  68. 68. Алтернативный путь к гибкости
  69. 69. Материалы
  70. 70. • http://www.piter.com/product/gibkoe-upravlenie- proektami-i-produktami • http://www.ozon.ru/context/detail/id/30003058/ • http://www.litres.ru/boris-volfson/gibkoe-upravlenie- proektami-i-produktami/
  71. 71. Материалы www.slideshare.net/Askhat/scrum-5545482 http://www.slideshare.net/Nfilippov/scrum-4432989 http://www.slideshare.net/azheglov/agile-piter http://www.slideshare.net/f0g/kanban-sketches Видео с AgileDays’14
  72. 72. Контакты • borisvolfson86@gmail.com • www.twitter.com/borisvolfson • www.facebook.com/borisvolfson

Editor's Notes

  • http://www.allaboutagile.com/impediment-management-and-the-agile-triangle/
  • Организуйте работу в вашей организации в небольших кроссфункциональных командах, которые содержат всех необходимых специалистов для реализации проекта. Выделите человека - скрам-мастера, который будет отвечать за соблюдение процессов в команде и конструктивную атмосферу.
    Требования разбейте на небольшие, ориентированные на пользователей, функциональные части, которые максимально независимы друг от друга, в результате чего получите бэклог продукта. Затем упорядочите элементы бэклога по их важности и произведите относительную оценку объемов каждого элемента. Выделите отдельного человека – владельца продукта, который будет отвечать за требования и их приоритеты, работая с заинтересованными лицами.
    Всю работу ведите короткими (от 1 до 4 недель) фиксированными итерациями – спринтами, поставляя в конце каждого из них законченный функционал, который можно при необходимости вывести на рынок – инкремент продукта. Команда согласно своей скорости набирает задачи на неизменяемую по времени итерацию – спринт. Каждый день проводится скрам-митинг, на котором команда синхронизирует свою работу и обсуждает проблемы. В процессе работы члены команды берут в работу элементы бэклога согласно приоритету.
    В конце каждого спринта проводите обзор спринта, чтобы получить обратную связь от владельца продукта, и ретроспективу спринта, чтобы оптимизировать ваши процессы. После этого владелец продукта может изменить требования и их приоритеты и запустить новый спринт.
  • Роли
    В Scrum принято выделять три основных роли, которые составляют в Scrum-команду: владелец продукта, скрам-мастер и команда разработки.
    Владелец продукта (Product owner, Продукт оунер, Менеджер продукта) – это член команды, ответственный за максимизацию ценности продукта и управление бэклогом продукта;
    Скрам-мастер (Scrum Master) – член команды, который дополнительно отвечает за процессы, координацию работы команды и поддержание социальной атмосферы в команде.
    Команда разработки (Development Team) – это кроссфункциональная и самоорганизующаяся группа специалистов, которая создает инкремент продукта.
    Владелец продукта
    Основной задачей владельца продукта является максимизация ценности продукта через управление бэклогом продукта включая:
    Создание и обработку элементов бэклога;
    Приоритезацию элементов бэклога;
    Выработку понимания элементов бэклога у команды;
    Часть из этих задач владелец продукта может делегировать членам команды, но он остается ответственным за них. Кроме того, владелец продукта – это всегда один человек, а не группы или комитет, и все требования в виде элементов бэклога поступают команде через него.
    Команда разработки
    Команда разработки каждый спринт поставляет потенциально готовый к релизу продукт. Она состоит из кроссфункциональных специалистов без разделение на профессии, хотя возможны специализации отдельных ее членов, но ответственность за поставку все равно лежит на команде в целом.
    Важным свойством команды разработки является ее самоорганизация: она сама определяет способ, которым сделает из элементов бэклога инкремент продукта.
    Минимальный размер команды разработки – 3 человека, не считая владельца продукта и скрам-мастера, если они непосредственно не участвуют в создании инкремента. Максимальный размер команды - 9 человек, так как при дальнейшем увеличении теряется эффективность.
    Скрам-мастер
    Скрам-мастер – это член команды, который ответственен за понимание и реализацию Scrum’а, и помогает в этом следующим субъектам:
    Владелец продукта
    Помогает в планировании и оценке элементов бэклога
    По необходимости помогает в организации процессов
    Команда разработки
    Обучает команду самоорганизации и кроссфункциональности
    Устраняет внешние препятсвия
    По необходимости помогает в организации процессов
    Организация в целом
    Адаптирует Scrum в соответствии с потребностями организации
    Помогает понять внешним к команде людям Scrum
    Обменивается лучшими практиками с другими скрам-мастерами
  • К сожалению даже в 21-ом веке оценки программных проектов производятся очень плохо. Фактически менеджер просто высказывает догадки на основе своего опыта…
    Фундаментальная проблема лежит в области того, что я бы назвал «корпоративной психологии». Дело в том, что для оценки DM-проектов необходимо база знаний не по обычным проектам (да и такие базы не всегда ведутся в наших компаниях), а именно формализованные знания по DM-проектам. Но компании предпочитают как можно быстрей забывать про такие проекты, как на уровне менеджмента, так и на уровне команд.
    Таким образом, использую опыт обычных проектов оценки делают достаточно оптимистичные, что еще больше загоняет проект в разряд неподъемных.
  • В долгосрочном плане ретроспективы (или сокращенно «ретро») являются самой важной практикой Scrum: ведь именно они позволяют адаптировать и кастомизировать Scrum, делая из него по-настоящему гибкий фреймворк для управления проектами.
    Ретроспективу традиционно проводят после обзора спринта спустя небольшое количество времени, чтобы оперативно получить фидбек. Скрам-мастер собирают всю команду для обсуждения результатов спринта. Рекомендуется на ретроспективу приглашать владельца продукта для получения дополнительной обратной связи.
    Структура ретроспективы
    Обычно ретроспектива занимает от 30 минут до 4 часов и ее продолжительность зависит от следующих факторов:
    Длина спринта: чем длиннее спринт, тем больше команда успевает сделать и тем больше материала для обсуждения;
    Размер команды: чем команда больше, тем больше надо времени, чтобы у каждого ее члена была возможность высказаться и тем больше функционала команда успевает сделать;
    Наличие проблем: со временем команда решает проблемы и ретроспективы сокращаются по времени.
    В процентном соотношении принято выделять такую структуру.

    Также традиционным является формат по сбору данных, который заключается в ответах каждого участника на три вопроса:
    Что было сделано хорошо?
    Что можно улучшить?
    Какие улучшения будем делать?
    Количество улучшений, которые команда берет в реализацию, не должно превышать 2-3, чтобы не снизить скорость реализации бизнес-функционала и не потерять фокус. Команда должна обязательно в том или ином виде составить план улучшений для контроля их исполнения.
    Для максимальной открытости и прозрачности обсуждения необходимо использовать основное правило ретроспективы, которое можно озвучивать в начале:
    «В независимости от того, что удастся выяснить в результате ретроспективы, каждый член команды сделал всё, чтобы добиться успеха»
    Если у команды отсутствуют яркие проблемы, то желательно следующие темы обсудить на ретроспективе:
    скорость команды и ее изменение по сравнению с предыдущими спринтами;
    нереализованные истории пользователей и причины опоздания;
    дефекты и их причины;
    качество процессов (нарушения, отступления).
    К паттернам можно отнести анализ сделанных улучшений за несколько прошлых спринтов. Такая «ретроспектива ретроспектив» может проводить раз в 4 спринта и позволяет контролировать уровень сделанных улучшений.

  • Акцент делаем на научном подходе.

    Plan (планирование)
    Производится анализ системы и вырабатываются возможные подходы к улучшениям и определяются желаемые результаты
    Do (исполнение)
    Решения, выработанные на предыдущем шаге, реализуются.
    Check (проверка)
    Производится анализ, полученных результатов, на предыдущем шаге.
    Act (корректировка)
    Выполняются корректирующие действия, для уменьшения отклонений от плана.
  • ×