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

Содержание

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

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


Слайд 2Асхат Уразбаев

Agile Coach
Тренер и консультант по Agile


Совладелец компании ScrumTrek

Основатель и координатор

сообщества AgileRussia

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


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


Слайд 5Дисфункция №1. Проблема коммуникаций
Заказчик не знает, как идет разработка
Разработчики не понимают, зачем

нужна система
Тестировщики узнают о требованиях от программистов
Аналитики не видят готовую систему

© ScrumTrek.ru, 2009


Слайд 6Дисфункция №2. Ответственность !не равна= полномочиям
Команда не соблюдает сроки разработки
А оценкой

работ занимается заказчик
Менеджер проекта отвечает за продуктивность команды
Но не может вводить и выводить людей из проекта
Тест-менеджер отвечает за качество продукта
Но не может отменить релиз продукта


© ScrumTrek.ru, 2009


Слайд 7Дисфункция №3 Отсутствие commit’а
Заказчик работает "по-agile”
Но не знает, что это такое
Аналитик отвечает

за управление требованиями
Но не считает себя обязанным это делать


© ScrumTrek.ru, 2009


Слайд 8Дисфункция №4. Отсутствие средств/возможностей
(Ответсвенный не может достичь цели/решить проблему из-за отсутствия

средств/возможностей)
В команде нет специалиста по пользовательским интерфейсам
Нет нужного сервера или продукта
Не ведется проектная документация

© ScrumTrek.ru, 2009


Слайд 9Чеклист
Role. Есть ли ответственный за решение проблемы?
Commit. Он знает, что

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

© ScrumTrek.ru, 2009


Слайд 10«Классический» менеджер проекта: управление ответственностью
Role. Умеет делегировать
Commit. Получает commit от ответственного
Openness.

Информирует заинтересованные лиц
Rights. Передает эксклюзивные права на принятие решений в его области ответственности
FUN. Побеспокоится о том, что ответственный получает удовлетворение от решения проблемы
Means. И о том, что у него есть средства решения проблемы
Communication. Создает "инструмент" постоянной передачи информации ЗЛ
Feedback. Осуществляет постоянную и мгновенную обратную связь по результатам работы

© ScrumTrek.ru, 2009


Слайд 11Дисфункция №5. Проблема взаимозависимости
К пуговицам претензии есть?
"Настоящие Программисты не тестируют!"
"А у

меня на машине все работает!"
"Настоящий мужик свои проблемы решает сам!"

Проблема общей ответственности

© ScrumTrek.ru, 2009


Слайд 12Команда
… небольшая группа людей с дополняющими навыками, с общей

целью, стремящаяся улучшить свою производительность и чуствующая ответственность по отношению к друг другу…

Katzenbach, Smith, “The Wisdom of Team”

© ScrumTrek.ru, 2009


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

© ScrumTrek.ru, 2009


Слайд 14© ScrumTrek.ru, 2009
Хорошее решение
Push
Pull
Magic :-)


Слайд 15Чеклист тот же. Решение принимает команда
Role. Есть ли ответственный за решение

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

© ScrumTrek.ru, 2009


Слайд 16Лечение «инфекций» в Agile
Наладим обмен веществ информацией
Короткие итерации, Daily Scrum, планирование,

демонстрации и т.д.
Повысим иммунитет самоорганизацию команды
Коллективное принятие решений, прозрачность, Shared Vision, ретроспектива и т.д.

© ScrumTrek.ru, 2009


Слайд 17Средства
Регламент
Артефакты
Визуальные чарты
Инструменты
Навыки и знания

© ScrumTrek.ru, 2009


Слайд 18Регламент
Обязательные для выполнения правила
Примеры
Проводить Code Review перед коммитом
Daily Scrum начинается в

11-30 утра
Scrum Master меняется каждую итерацию


© ScrumTrek.ru, 2009


Слайд 19Артефакты
Документ
Word, Wiki, Sharepoint, text и т.д.
Примеры
Vision, SRS, Use Case Model, Architecture

Notebook etc.
Product Backlog, Iteration Plan и т.д.

© ScrumTrek.ru, 2009


Слайд 20Визуальные чарты
Средства коммуникации, выставленные на всеобщее обозрение
Пример
TaskBoard, BurnDown chart, Release Backlog

etc.

© ScrumTrek.ru, 2009


Слайд 21Инструменты
Программные продукты
Пример
Jira, Visual Studio, CruiseControl, FXCop, Resharper, IntelliJ IDEA etc.

© ScrumTrek.ru,

2009

Слайд 22Навыки и знания
© ScrumTrek.ru, 2009
Примеры
Test Driven Development, Continuous Integration, Use Case

Modeling
Умение общаться с заказчиком
Умение проектировать пользовательские интерфейсы
Умение проектировать архитектуру систем

Слайд 23Внешние препятствия
© ScrumTrek.ru, 2009


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

или правильное разделение ответственности

© ScrumTrek.ru, 2009


Слайд 25Примеры токсинов
Эффективность коммуникации
Распределенная разработка
Языковой барьер
Разница во времени
Удаленный заказчик
"Отдел тестирования"
Разделение ответственности
Персональное бонусирование
"Пошареные"

члены проектной команды
Проекты Fixed Price

© ScrumTrek.ru, 2009


Слайд 26Работа с токсинами
Обмен информацией
Лечение. Убрать токсин
Купирование. Средства, облегчающие обмен информацией
Документация (Wiki,

Word, Sharepoint, Scrum Notes etc)
Коммуникация (skype, videoconference, и т.д.)
Личные контакты (командировки, видео, «тимбилдинг»)
Разделение ответственности
Лечение. Убрать токсин
Купирование. Прокси - ответственный

© ScrumTrek.ru, 2009


Слайд 27Качество и изменчивость
© ScrumTrek.ru, 2009


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


Слайд 29© ScrumTrek.ru, 2008


Слайд 30Итог
Нет плана
Нет взаимодействия
Плохой код

© ScrumTrek.ru, 2008


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


Слайд 32

© ScrumTrek.ru, 2008


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


Слайд 34Примеры дисфункций
Объем документации
Требования плавают в течении итерации
Никто не помнит почему мы

приняли такие странные решения
Очень много переделок, которые можно было избежать
Качество кода
Долгий полный цикл тестирования
Много «наведенных» дефектов
Время на исправление дефекта невозможно оценить

© ScrumTrek.ru, 2009


Слайд 35Проблема баланса интересов разработки и бизнеса
Проблема осознается, когда уже поздно что

либо принимать
В этой области "здравый смысл" работает плохо

© ScrumTrek.ru, 2009


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


Слайд 37Паттерны решения проблемы
Принципы: решение принимается заранее (раз и навсегда)
Принципы качества
Scrum
We do

not compromise quality!
Continuous Testing
Extreme Programming
Keep It Simple
You Ain’t Gonna Need It

© ScrumTrek.ru, 2009


Слайд 38Инструменты управления качеством в agile
Технологический долг
Definition Of Done
Test Driven Development
Continuous Integration
Pair

Programming

© ScrumTrek.ru, 2009


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


Слайд 40Набор физической формы
Как правило, длительный процесс
Нужно планировать работу над формой
Обязательно осознавать

свои возможности
Процесс набора должен быть облегчен по максимуму

© ScrumTrek.ru, 2009


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


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

2009

Слайд 43Эффективность

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


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

бюджет

© ScrumTrek.ru, 2009


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

ScrumTrek.ru, 2009

Слайд 46НЕявные и НЕподразумеваемые ограничения
Архитектура должна быть «крутая»
Менеджер должен получить повышение после

проекта
Наш отдел должен получить всю славу

© ScrumTrek.ru, 2009


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


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

© ScrumTrek.ru, 2009


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


Обратная связь

Если не удалось найти и скачать презентацию, Вы можете заказать его на нашем сайте. Мы постараемся найти нужный Вам материал и отправим по электронной почте. Не стесняйтесь обращаться к нам, если у вас возникли вопросы или пожелания:

Email: Нажмите что бы посмотреть 

Что такое ThePresentation.ru?

Это сайт презентаций, докладов, проектов, шаблонов в формате PowerPoint. Мы помогаем школьникам, студентам, учителям, преподавателям хранить и обмениваться учебными материалами с другими пользователями.


Для правообладателей

Яндекс.Метрика