Urazbaev

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

Асхат Уразбаев
ScrumTrek
http://scrumtrek.ru

© ScrumTrek.ru, 2009

Асхат Уразбаев

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

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

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

Процесс

Разработчики
CEO

$
PM

Тестировщики
Аналитик
Маркетинг


Коммуникации
Ответственность


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


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


Дисфункция №3
Отсутствие commit’а
 Заказчик работает quot;по-agile”
 Но не знает, что это такое
 Аналитик отвечает за управление
требованиями
 Но не считает себя обязанным это
делать


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


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


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


Дисфункция №5. Проблема
взаимозависимости
 К пуговицам претензии
есть?
 quot;Настоящие Программисты
не тестируют!quot;
 quot;А у меня на машине все
работает!quot;
 quot;Настоящий мужик свои
проблемы решает сам!quot;

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


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


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


Хорошее решение

Pull Push

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


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


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


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

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


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


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


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


Внешние
препятствия


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


Примеры токсинов
 Эффективность коммуникации
 Распределенная разработка
 Языковой барьер
 Разница во времени
 Удаленный заказчик
 quot;Отдел тестированияquot;
 Разделение ответственности
 Персональное бонусирование
 quot;Пошареныеquot; члены проектной команды
 Проекты Fixed Price


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


Качество и
изменчивость


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


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


Интересы разработки

Придумываем ДОЛГО
Разрабатываем
ТЩАТЕЛЬНО
Выкладываем НЕ СКОРО


Итог
 Тщательное планирование
 Тяжелые инженерные
решения
 Слабая связь с рынком


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


Проблема баланса интересов
разработки и бизнеса
 Проблема
осознается, когда
уже поздно что
либо принимать
 В этой области
quot;здравый смыслquot;
работает плохо


Физическая форма
 Проблемы объема
жира документации
 Проблемы качества
мышечной массы
кода


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


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


Коммуникации в проекте


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


Управление
продуктом


Цель улучшения процессов
разработки в проекте
 Эффективное достижение бизнес целей
проекта


Эффективность

Эффективность

=
соблюдение
ограничений


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


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


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


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


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


Конец

Будьте здоровы! 
Вопросы?


Urazbaev

Recommended

Recommended

More Related Content

What's hot

What's hot (19)

More from sef2009

More from sef2009 (20)

Urazbaev