'

Паттерны построения эффективного процесса разработки

Понравилась презентация – покажи это...





Слайд 0

Паттерны построения эффективного процесса разработки © ScrumTrek.ru, 2009 Асхат Уразбаев ScrumTrek http://scrumtrek.ru


Слайд 1

Асхат Уразбаев Agile Coach Тренер и консультант по Agile Совладелец компании ScrumTrek Основатель и координатор сообщества AgileRussia


Слайд 2

Процесс © ScrumTrek.ru, 2008 $ CEO Маркетинг PM Разработчики Тестировщики Аналитик


Слайд 3

Коммуникации Ответственность © ScrumTrek.ru, 2009


Слайд 4

Дисфункция №1. Проблема коммуникаций Заказчик не знает, как идет разработка Разработчики не понимают, зачем нужна система Тестировщики узнают о требованиях от программистов Аналитики не видят готовую систему © ScrumTrek.ru, 2009


Слайд 5

Дисфункция №2. Ответственность !не равна= полномочиям Команда не соблюдает сроки разработки А оценкой работ занимается заказчик Менеджер проекта отвечает за продуктивность команды Но не может вводить и выводить людей из проекта Тест-менеджер отвечает за качество продукта Но не может отменить релиз продукта © ScrumTrek.ru, 2009


Слайд 6

Дисфункция №3 Отсутствие commit’а Заказчик работает "по-agile” Но не знает, что это такое Аналитик отвечает за управление требованиями Но не считает себя обязанным это делать © ScrumTrek.ru, 2009


Слайд 7

Дисфункция №4. Отсутствие средств/возможностей (Ответсвенный не может достичь цели/решить проблему из-за отсутствия средств/возможностей) В команде нет специалиста по пользовательским интерфейсам Нет нужного сервера или продукта Не ведется проектная документация © ScrumTrek.ru, 2009


Слайд 8

Чеклист Role. Есть ли ответственный за решение проблемы? Commit. Он знает, что он ответственный? Знает ли он область своей ответственности? Openness. Все ли заинтересованные (ЗЛ) лица знают, кто ответственый? Rights. Имеет ли ответственный эксклюзивные права на принятие решений в его области ответственности? FUN. Получает ли ответственный удовлетворение от решения проблемы? Means. Есть ли у него все необходимые средства для решения проблемы (навыки и знания, информация, инструменты)? Communication. Все ли ЗЛ информируются о том, как проблема решается? Feedback. Существует ли постоянная обратная связь по результатам работы? © ScrumTrek.ru, 2009


Слайд 9

«Классический» менеджер проекта: управление ответственностью Role. Умеет делегировать Commit. Получает commit от ответственного Openness. Информирует заинтересованные лиц Rights. Передает эксклюзивные права на принятие решений в его области ответственности FUN. Побеспокоится о том, что ответственный получает удовлетворение от решения проблемы Means. И о том, что у него есть средства решения проблемы Communication. Создает "инструмент" постоянной передачи информации ЗЛ Feedback. Осуществляет постоянную и мгновенную обратную связь по результатам работы © ScrumTrek.ru, 2009


Слайд 10

Дисфункция №5. Проблема взаимозависимости К пуговицам претензии есть? "Настоящие Программисты не тестируют!" "А у меня на машине все работает!" "Настоящий мужик свои проблемы решает сам!" Проблема общей ответственности © ScrumTrek.ru, 2009


Слайд 11

Команда … небольшая группа людей с дополняющими навыками, с общей целью, стремящаяся улучшить свою производительность и чуствующая ответственность по отношению к друг другу… Katzenbach, Smith, “The Wisdom of Team” © ScrumTrek.ru, 2009


Слайд 12

Agile: ответственной может быть команда! Общая цель Коллективное принятие решений Доверие Взаимная ответственость Прозрачность © ScrumTrek.ru, 2009


Слайд 13

© ScrumTrek.ru, 2009 Хорошее решение Push Pull Magic :-)


Слайд 14

Чеклист тот же. Решение принимает команда Role. Есть ли ответственный за решение проблемы? Commit. Он знает, что он ответственный? Знает ли он область своей ответственности? Openness. Все ли заинтересованные (ЗЛ) лица знают, кто ответственый? Rights. Имеет ли ответственный эксклюзивные права на принятие решений в его области ответственности? FUN. Получает ли ответственный удовлетворение от решения проблемы? Means. Есть ли у него все необходимые средства для решения проблемы (навыки и знания, информация, инструменты)? Communication. Все ли ЗЛ информируются о том, как проблема решается? Feedback. Существует ли постоянная обратная связь по результатам работы? © ScrumTrek.ru, 2009


Слайд 15

Лечение «инфекций» в Agile Наладим обмен веществ информацией Короткие итерации, Daily Scrum, планирование, демонстрации и т.д. Повысим иммунитет самоорганизацию команды Коллективное принятие решений, прозрачность, Shared Vision, ретроспектива и т.д. © ScrumTrek.ru, 2009


Слайд 16

Средства Регламент Артефакты Визуальные чарты Инструменты Навыки и знания © ScrumTrek.ru, 2009


Слайд 17

Регламент Обязательные для выполнения правила Примеры Проводить Code Review перед коммитом Daily Scrum начинается в 11-30 утра Scrum Master меняется каждую итерацию © ScrumTrek.ru, 2009


Слайд 18

Артефакты Документ Word, Wiki, Sharepoint, text и т.д. Примеры Vision, SRS, Use Case Model, Architecture Notebook etc. Product Backlog, Iteration Plan и т.д. © ScrumTrek.ru, 2009


Слайд 19

Визуальные чарты Средства коммуникации, выставленные на всеобщее обозрение Пример TaskBoard, BurnDown chart, Release Backlog etc. © ScrumTrek.ru, 2009


Слайд 20

Инструменты Программные продукты Пример Jira, Visual Studio, CruiseControl, FXCop, Resharper, IntelliJ IDEA etc. © ScrumTrek.ru, 2009


Слайд 21

Навыки и знания © ScrumTrek.ru, 2009 Примеры Test Driven Development, Continuous Integration, Use Case Modeling Умение общаться с заказчиком Умение проектировать пользовательские интерфейсы Умение проектировать архитектуру систем


Слайд 22

Внешние препятствия © ScrumTrek.ru, 2009


Слайд 23

«Токсины» Внешние по отношению к команде ограничения, влияющие на эффективность обмена информацией или правильное разделение ответственности © ScrumTrek.ru, 2009


Слайд 24

Примеры токсинов Эффективность коммуникации Распределенная разработка Языковой барьер Разница во времени Удаленный заказчик "Отдел тестирования" Разделение ответственности Персональное бонусирование "Пошареные" члены проектной команды Проекты Fixed Price © ScrumTrek.ru, 2009


Слайд 25

Работа с токсинами Обмен информацией Лечение. Убрать токсин Купирование. Средства, облегчающие обмен информацией Документация (Wiki, Word, Sharepoint, Scrum Notes etc) Коммуникация (skype, videoconference, и т.д.) Личные контакты (командировки, видео, «тимбилдинг») Разделение ответственности Лечение. Убрать токсин Купирование. Прокси - ответственный © ScrumTrek.ru, 2009


Слайд 26

Качество и изменчивость © ScrumTrek.ru, 2009


Слайд 27

Интересы БИЗНЕСА Придумываем БЫСТРО Разрабатываем СРАЗУ Выкладываем НЕМЕДЛЕННО © ScrumTrek.ru, 2008


Слайд 28

© ScrumTrek.ru, 2008


Слайд 29

Итог Нет плана Нет взаимодействия Плохой код © ScrumTrek.ru, 2008


Слайд 30

Интересы разработки Придумываем ДОЛГО Разрабатываем ТЩАТЕЛЬНО Выкладываем НЕ СКОРО © ScrumTrek.ru, 2008


Слайд 31

© ScrumTrek.ru, 2008


Слайд 32

Итог Тщательное планирование Тяжелые инженерные решения Слабая связь с рынком © ScrumTrek.ru, 2008


Слайд 33

Примеры дисфункций Объем документации Требования плавают в течении итерации Никто не помнит почему мы приняли такие странные решения Очень много переделок, которые можно было избежать Качество кода Долгий полный цикл тестирования Много «наведенных» дефектов Время на исправление дефекта невозможно оценить © ScrumTrek.ru, 2009


Слайд 34

Проблема баланса интересов разработки и бизнеса Проблема осознается, когда уже поздно что либо принимать В этой области "здравый смысл" работает плохо © ScrumTrek.ru, 2009


Слайд 35

Физическая форма Проблемы объема жира документации Проблемы качества мышечной массы кода © ScrumTrek.ru, 2009


Слайд 36

Паттерны решения проблемы Принципы: решение принимается заранее (раз и навсегда) Принципы качества Scrum We do not compromise quality! Continuous Testing Extreme Programming Keep It Simple You Ain’t Gonna Need It © ScrumTrek.ru, 2009


Слайд 37

Инструменты управления качеством в agile Технологический долг Definition Of Done Test Driven Development Continuous Integration Pair Programming © ScrumTrek.ru, 2009


Слайд 38

Коммуникации в проекте © ScrumTrek.ru, 2009


Слайд 39

Набор физической формы Как правило, длительный процесс Нужно планировать работу над формой Обязательно осознавать свои возможности Процесс набора должен быть облегчен по максимуму © ScrumTrek.ru, 2009


Слайд 40

Управление продуктом © ScrumTrek.ru, 2009


Слайд 41

Цель улучшения процессов разработки в проекте Эффективное достижение бизнес целей проекта © ScrumTrek.ru, 2009


Слайд 42

Эффективность Эффективность = соблюдение ограничений © ScrumTrek.ru, 2009


Слайд 43

Явные ограничения Разработка с использованием технологий Microsoft Использование «нашего» фреймворка Обойтись существующей командой Уложиться в бюджет © ScrumTrek.ru, 2009


Слайд 44

Неявные, но подразумеваемые ограничения Соблюдение УК РФ Отсутствие несчастных случаев Заказчик должен быть доволен © ScrumTrek.ru, 2009


Слайд 45

НЕявные и НЕподразумеваемые ограничения Архитектура должна быть «крутая» Менеджер должен получить повышение после проекта Наш отдел должен получить всю славу © ScrumTrek.ru, 2009


Слайд 46

«Неврологические» дисфункции Бизнес-цель неясна Бизнес-цель недостижима Бизнес-цель отсутствует Ограничения эффективности несовместны © ScrumTrek.ru, 2009


Слайд 47

Развитие идеи Сделать каталог процессных дисфункций Собрать best practices лечения Подробности тут: http://blog.scrumtrek.ru © ScrumTrek.ru, 2009


Слайд 48

Конец Будьте здоровы! ? Вопросы? © ScrumTrek.ru, 2009


×

HTML:





Ссылка: