Agile практики - рассказ не разработчикам
•Download as PPTX, PDF•
1 like•243 views
Слайды про практики Agile, которые я показываю, когда общаюсь не с разработчиками
Recommended
Recommended
More Related Content
What's hot
What's hot (19)
Viewers also liked
Similar to Agile практики - рассказ не разработчикам
Similar to Agile практики - рассказ не разработчикам (20)
More from Vladimir Kalenov
More from Vladimir Kalenov (11)
Agile практики - рассказ не разработчикам
- 2. Владимир Калёнов Туту.ру руководитель проектов организационного совершенствования/ куратор SCRUM-мастеров • MBA IT • icAgile Agile Team Facilitator • SAFe Agilist • ITIL Practitioner • Занимаюсь процессами с 2003-го года • В разное время в Ай-Теко, Гелиос ИТ, Сбербанке занимался процессами ITSM, системами мониторинга, управления проектами • Много работал с гос. структурами и банками, в том числе запускал процессы QA Сейчас отвечаю за процессы и знания в компании https://vimeo.com/user19751732 kalenov@tutu.ru 2
- 3. "Какая медлительная страна! — сказала Королева. — Ну, а здесь, знаешь ли, приходится бежать со всех ног, чтобы только остаться на том же месте! Если же хочешь попасть в другое место, тогда нужно бежать по меньшей мере вдвое быстрее." 3
- 4. 4 Трансакционные издержки Новая институциональная теория Что мы вкладываем в решение задач/проекты?
- 5. 5 Формулируем потребности Что Описать Проверить Заказчик Гибкость Requirements / Требования конкретные, проверяемые характеристики продукта контрольные примеры Acceptance Criteria глубоко разбирается в продукте и Только так! Use Cases / Юзкейсы поведение системы в ответ на действия пользователя Test Cases описывающие позитивные и негативные сценарии. глубоко понимает продукт, но не технологии Ну или так… User Story / Пользовательск ие истории ожидания и цели пользователя Как я понимаю, что это то что нужно Definition of Done Хорошо ощущает потребность А как лучше?
- 6. • Продукты очень сложные, один человек не может досконально знать продукт • Никто не может детально, до уровня требований, описать потребность даже среднего размера… до того как она устареет • Нужно успеть разработать до того как технология изменится • Agile это подход, а не методика 6 Тезисы
- 7. 7 • Люди и взаимодействие важнее процессов и инструментов • Работающий продукт важнее исчерпывающей документации • Сотрудничество с заказчиком важнее согласования условий контракта • Готовность к изменениям важнее следования первоначальному плану Команда и ответственность важнее индивидумов и взаимодействия Бизнес ценность важнее рабочего продукта Развитие партнёрских отношений важнее сотрудничества с клиентом Готовиться к изменениям важнее реакции на изменения • Стратегия голубого океана • Lean Canvas • Data Mining • Journey Map • ... • Жалоба как подарок • BSM • ... • SCRUM/KANBAN • Agile Project Management • Retrospective • Facilitation … • 12 принципов XP • DevOps • Cont integration/Delivery • LeanArch …
- 8. 8 Владелец продукта (Product Owner)
- 9. 9
- 11. Продуктовые практики • Афинное оценивание • Покер планирования • Discovery Kanban • User Story Mapping • User Story Canvas • Игры, как инструменты фасилитации 11
- 12. 12 KANBAN Backlog Готовы к исполнению В процессе Сделано Panic Line
- 14. Командные практики • Визуализация (Kanban доски и т.п.) • Синхронизация / Стендапы • «Право на ошибку» • Ретроспектива* • Команда в одном месте • Практика Demo 14 *«Ретроспектива проекта» Норм Керт
- 16. Работа с рисками • «Сначала тестирование!» - Test First • Право на ошибку – Safe to Fail • «Затвердевающая» архитектура • Совместное планирование (PI Planing) 16
- 17. 17Фотографии Алексей Пименов ScrumTrek
- 18. • Переход от последовательных к гибким методикам разработки произошел под давлением изменений внешней среды • Внедрение гибких методологий требует не только самомотивации, но и высокой внутренней организации команды • Гибкие методики контринтуитивны и основаны на доверии • Гибкие методики «очень жесткие» в плане применения инструментов 18 Тезисы
- 19. 19 Отношение организации или команды с окружающей средой Автор: Максим Цепков
- 20. 20 Отношение организации или команды с окружающей средой Автор: Максим Цепков
- 21. Balancing Agility and Discipline: A Guide for the Perplexed 1st Edition by Barry Boehm (Author), Richard Turner (Author), Grady Booch (Foreword), Alistair Cockburn (Foreword), Arthur Pyster (Foreword) А насколько будет трудно?
- 22. 2 2 Вопросы?
Editor's Notes
- Важно понимать, какие инструменты подходят и для чего, чтобы вовремя их применить.
- Организация и изменения внешней среды Говоря о методике разработки в компании, важно понимать, что мы говорим не просто о правилах работы, а о совокупности: люди, процессы, технологии. Которые задают то каким образом организуется производственная (производящая) функцию компании. Есть еще более широкий взгляд на управления компании, включающий все аспекты управления, финансовые, сервисные, взаимоотношения с партнерами, которые оказывают влияние на то как организована разработка. но я дальше буду говорить о них как о таких же внешних по отношению разработки факторах,
- Неоинституциональная теория вводит понятие транзакционных издержек Проекты это высокорисковые инвестиции коммуникаций, а не вложения Очень дорого снижать риски проекта до приемлемого уровня из-за изменчивости внешней среды Интеграторы давно работают на корпоративном рынке в таком режиме
- Requirements / Use Cases / User Story (требования, юзкейсы, юзерстори). Как проверить качество: Требование - соответствует описанию или нет. Acceptance Criteria. Use Case - содержит позитивный и негативные сценарии их можно проверить. Test Cases. User Story - ПО задает Definition of Done. В дальнейшем при уточнении с учетом технологии реализации превращается в UseCase. Регресс всегда :)
- Про изменение технологии – например к ним относятся решения КФ и backend-а, т.е. не только внешние, но и внутренние.
- Про четыре уровня проворности. Про возвращение проворности в Enterprise.
- Роли ПО SCRUM мастер Команда (Team) Отвечает за оценку элементов баклога Принимает решение по дизайну и имплементации Разрабатывает софт и предоставляет его заказчику Отслеживает собственный прогресс (вместе со Скрам Мастером). Отвечает за результат перед Product Owner Анекдот про свиней и куриц. Делать правильные функции - ПО Делать функции правильно - команда и SCRUM-мастер Создавать функции быстро - ЛР, методологи, тренеры, коучи ПО - не член команды. Легче всего понять на примере B2B разработки, когда у функции есть конкретный заказчик. http://habrahabr.ru/company/taucraft/blog/124241/
- Канбан (точнее канбан-доски) Организация процесса разработки так, чтобы обеспечить принцип вытягивания заказчиком. Минимизируем количество незавершенных задач в процессе. Решает следующие проблемы: Позволяет сократить (выбросить) время на планирование, когда команда не может сходу разобраться в продукте (например, неравноценные знания у разных участников команды о продукте) Без нарушения процесса работать даже если много внеплановых задач Позволяет менять приоритет задач во время итерации (! следим за тем, чтобы недоделанная работа не возникала) Для планирования и улучшения процессов используется среднее время выполнения задачи. Оценки задач опциональны Можно добавлять новые задачи, в любой момент времени. Непрерывный поток задач не привязанный к итерации Чего требует: определенная универсальность команды в рамках основных шагов (разработчики могут примерно одно и тоже, аналогично тестировщики) иначе не будет эффективным. Артефакты: WIP Product backlog Cumulative Flow Diagram Control Chart Чтобы это пощупать у нас будет игра.
- 5 ключевых факторов влияющих на возможность/простоту применения методик класса Agile. Balancing Agility and Discipline: A Guide for the Perplexed 1st Edition by Barry Boehm (Author), Richard Turner (Author), Grady Booch (Foreword), Alistair Cockburn (Foreword), Arthur Pyster (Foreword)