Post on 28-Nov-2014
description
Паттерны построения эффективного процесса разработки
© ScrumTrek.ru, 2009
Асхат УразбаевScrumTrek
http://scrumtrek.ru
Асхат Уразбаев
Agile CoachТренер и консультант по Agile
Совладелец компании ScrumTrek
Основатель и координатор сообщества AgileRussia
Процесс
© ScrumTrek.ru, 2008
$
CEO
Маркетинг
PM
Разработчики
Тестировщики
Аналитик
Коммуникации Ответственность
© ScrumTrek.ru, 2009
Дисфункция №1.Проблема коммуникаций Заказчик не знает, как
идет разработка Разработчики не
понимают, зачем нужна система
Тестировщики узнают о требованиях от программистов
Аналитики не видят готовую систему
© ScrumTrek.ru, 2009
Дисфункция №2. Ответственность !не равна= полномочиям
Команда не соблюдает сроки разработки А оценкой работ занимается
заказчик Менеджер проекта отвечает
за продуктивность команды Но не может вводить и
выводить людей из проекта
Тест-менеджер отвечает за качество продукта Но не может отменить релиз
продукта
© ScrumTrek.ru, 2009
Дисфункция №3Отсутствие commit’а
Заказчик работает "по-agile” Но не знает, что это такое
Аналитик отвечает за управление требованиями Но не считает себя обязанным это
делать
© ScrumTrek.ru, 2009
Дисфункция №4. Отсутствие средств/возможностей (Ответсвенный не может достичь
цели/решить проблему из-за отсутствия средств/возможностей)
В команде нет специалиста по пользовательским интерфейсам
Нет нужного сервера или продукта Не ведется проектная документация
© ScrumTrek.ru, 2009
Чеклист Role. Есть ли ответственный за решение проблемы? Commit. Он знает, что он ответственный? Знает ли он область
своей ответственности? Openness. Все ли заинтересованные (ЗЛ) лица знают, кто
ответственый? Rights. Имеет ли ответственный эксклюзивные права на
принятие решений в его области ответственности?
FUN. Получает ли ответственный удовлетворение от решения проблемы?
Means. Есть ли у него все необходимые средства для решения проблемы (навыки и знания, информация, инструменты)?
Communication. Все ли ЗЛ информируются о том, как проблема решается?
Feedback. Существует ли постоянная обратная связь по результатам работы?
© ScrumTrek.ru, 2009
«Классический» менеджер проекта: управление ответственностью
Role. Умеет делегировать Commit. Получает commit от ответственного Openness. Информирует заинтересованные лиц Rights. Передает эксклюзивные права на принятие
решений в его области ответственности
FUN. Побеспокоится о том, что ответственный получает удовлетворение от решения проблемы
Means. И о том, что у него есть средства решения проблемы
Communication. Создает "инструмент" постоянной передачи информации ЗЛ
Feedback. Осуществляет постоянную и мгновенную обратную связь по результатам работы
© ScrumTrek.ru, 2009
Дисфункция №5. Проблема взаимозависимости
К пуговицам претензии есть? "Настоящие
Программисты не тестируют!"
"А у меня на машине все работает!"
"Настоящий мужик свои проблемы решает сам!"
Проблема общей ответственности
© ScrumTrek.ru, 2009
Команда
… небольшая группа людей с дополняющими навыками, с общей целью, стремящаяся улучшить свою производительность и чуствующая ответственность по отношению к друг другу…
Katzenbach, Smith, “The Wisdom of Team”
© ScrumTrek.ru, 2009
Agile: ответственной может быть команда!
Общая цель Коллективное принятие
решений Доверие Взаимная
ответственость Прозрачность
© ScrumTrek.ru, 2009
© ScrumTrek.ru, 2009
Хорошее решение
PushPull
Magic :-)
Чеклист тот же. Решение принимает команда Role. Есть ли ответственный за решение проблемы? Commit. Он знает, что он ответственный? Знает ли он область
своей ответственности? Openness. Все ли заинтересованные (ЗЛ) лица знают, кто
ответственый? Rights. Имеет ли ответственный эксклюзивные права на
принятие решений в его области ответственности?
FUN. Получает ли ответственный удовлетворение от решения проблемы?
Means. Есть ли у него все необходимые средства для решения проблемы (навыки и знания, информация, инструменты)?
Communication. Все ли ЗЛ информируются о том, как проблема решается?
Feedback. Существует ли постоянная обратная связь по результатам работы?
© ScrumTrek.ru, 2009
Лечение «инфекций» в Agile Наладим обмен веществ
информацией Короткие итерации, Daily Scrum,
планирование, демонстрации и т.д.
Повысим иммунитет самоорганизацию команды Коллективное принятие решений,
прозрачность, Shared Vision, ретроспектива и т.д.
© ScrumTrek.ru, 2009
Средства
Регламент Артефакты Визуальные чарты Инструменты Навыки и знания
© ScrumTrek.ru, 2009
Регламент
Обязательные для выполнения правила
Примеры Проводить Code Review
перед коммитом Daily Scrum начинается
в 11-30 утра Scrum Master меняется
каждую итерацию
© ScrumTrek.ru, 2009
Артефакты
Документ Word, Wiki, Sharepoint, text и
т.д. Примеры
Vision, SRS, Use Case Model, Architecture Notebook etc.
Product Backlog, Iteration Plan и т.д.
© ScrumTrek.ru, 2009
Визуальные чарты Средства коммуникации, выставленные на всеобщее обозрение Пример
TaskBoard, BurnDown chart, Release Backlog etc.
© ScrumTrek.ru, 2009
Инструменты
Программные продукты Пример
Jira, Visual Studio, CruiseControl, FXCop, Resharper, IntelliJ IDEA etc.
© ScrumTrek.ru, 2009
Навыки и знания
© ScrumTrek.ru, 2009
Примеры Test Driven Development,
Continuous Integration, Use Case Modeling
Умение общаться с заказчиком Умение проектировать
пользовательские интерфейсы Умение проектировать
архитектуру систем
Внешние препятствия
© ScrumTrek.ru, 2009
«Токсины»
Внешние по отношению к команде ограничения, влияющие на эффективность обмена информацией или правильное разделение ответственности
© ScrumTrek.ru, 2009
Примеры токсинов Эффективность коммуникации
Распределенная разработка Языковой барьер Разница во времени Удаленный заказчик "Отдел тестирования"
Разделение ответственности Персональное бонусирование "Пошареные" члены проектной команды Проекты Fixed Price
© ScrumTrek.ru, 2009
Работа с токсинами Обмен информацией
Лечение. Убрать токсин Купирование. Средства, облегчающие обмен
информацией Документация (Wiki, Word, Sharepoint, Scrum Notes
etc) Коммуникация (skype, videoconference, и т.д.) Личные контакты (командировки, видео,
«тимбилдинг»)
Разделение ответственности Лечение. Убрать токсин Купирование. Прокси - ответственный
© ScrumTrek.ru, 2009
Качество и изменчивость
© ScrumTrek.ru, 2009
Интересы БИЗНЕСА
Придумываем БЫСТРОРазрабатываем СРАЗУВыкладываем НЕМЕДЛЕННО
© ScrumTrek.ru, 2008
© ScrumTrek.ru, 2008
Итог
Нет планаНет взаимодействияПлохой код
© ScrumTrek.ru, 2008
Интересы разработки
Придумываем ДОЛГОРазрабатываем
ТЩАТЕЛЬНОВыкладываем НЕ СКОРО
© ScrumTrek.ru, 2008
© ScrumTrek.ru, 2008
Итог
Тщательное планированиеТяжелые инженерные
решенияСлабая связь с рынком
© ScrumTrek.ru, 2008
Примеры дисфункций Объем документации
Требования плавают в течении итерации Никто не помнит почему мы приняли такие
странные решения Очень много переделок, которые можно было
избежать Качество кода
Долгий полный цикл тестирования Много «наведенных» дефектов Время на исправление дефекта невозможно
оценить
© ScrumTrek.ru, 2009
Проблема баланса интересов разработки и бизнеса
Проблема осознается, когда уже поздно что либо принимать
В этой области "здравый смысл" работает плохо
© ScrumTrek.ru, 2009
Физическая форма
Проблемы объема жира документации
Проблемы качества мышечной массы кода
© ScrumTrek.ru, 2009
Паттерны решения проблемы
Принципы: решение принимается заранее (раз и навсегда)
Принципы качества Scrum
We do not compromise quality! Continuous Testing
Extreme Programming Keep It Simple You Ain’t Gonna Need It
© ScrumTrek.ru, 2009
Инструменты управления качеством в agile
Технологический долг Definition Of Done Test Driven Development Continuous Integration Pair Programming
© ScrumTrek.ru, 2009
Коммуникации в проекте
© ScrumTrek.ru, 2009
Набор физической формы Как правило, длительный
процесс Нужно планировать работу
над формой Обязательно осознавать
свои возможности Процесс набора должен
быть облегчен по максимуму
© ScrumTrek.ru, 2009
Управление продуктом
© ScrumTrek.ru, 2009
Цель улучшения процессов разработки в проекте
Эффективное достижение бизнес целей проекта
© ScrumTrek.ru, 2009
Эффективность
Эффективность
=
соблюдение ограничений
© ScrumTrek.ru, 2009
Явные ограничения Разработка с
использованием технологий Microsoft
Использование «нашего» фреймворка
Обойтись существующей командой
Уложиться в бюджет
© ScrumTrek.ru, 2009
Неявные, но подразумеваемые ограничения
Соблюдение УК РФ Отсутствие несчастных случаев Заказчик должен быть доволен
© ScrumTrek.ru, 2009
НЕявные и НЕподразумеваемые ограничения
Архитектура должна быть «крутая»
Менеджер должен получить повышение после проекта
Наш отдел должен получить всю славу
© ScrumTrek.ru, 2009
«Неврологические» дисфункции
Бизнес-цель неясна Бизнес-цель
недостижима Бизнес-цель
отсутствует Ограничения
эффективности несовместны
© ScrumTrek.ru, 2009
Развитие идеи
Сделать каталог процессных дисфункций
Собрать best practices лечения Подробности тут:
http://blog.scrumtrek.ru
© ScrumTrek.ru, 2009
Конец
Будьте здоровы! Вопросы?
© ScrumTrek.ru, 2009