Your SlideShare is downloading. ×
Процессные заболевания и методы их лечения
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Процессные заболевания и методы их лечения

5,928

Published on

Доклад на конференции Agile-Labs 31 марта 2009 года

Доклад на конференции Agile-Labs 31 марта 2009 года

Published in: Education
2 Comments
7 Likes
Statistics
Notes
  • Оригинал был MS Power Point 2007
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • А чем можно просмотреть файл презентации (тот, что скачать можно)?
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total Views
5,928
On Slideshare
0
From Embeds
0
Number of Embeds
10
Actions
Shares
0
Downloads
212
Comments
2
Likes
7
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Процессные заболевания и методы их лечения Асхат Уразбаев ScrumTrek http://scrumtrek.ru © ScrumTrek.ru, 2009
  • 2. Цель улучшения процессов разработки в проекте  Эффективное достижение бизнес целей проекта © ScrumTrek.ru, 2009
  • 3. Эффективность Эффективность = соблюдение ограничений © ScrumTrek.ru, 2009
  • 4. Явные ограничения  Разработка с использованием технологий Microsoft  Использование «нашего» фреймворка  Обойтись существующей командой  Уложиться в бюджет © ScrumTrek.ru, 2009
  • 5. Неявные, но подразумеваемые ограничения  Соблюдение УК РФ  Отсутствие несчастных случаев  Заказчик должен быть доволен © ScrumTrek.ru, 2009
  • 6. НЕявные и Неподразумеваемые ограничения  Архитектура должна быть «крутая»  Менеджер должен получить повышение после проекта  Наш отдел должен получить всю славу © ScrumTrek.ru, 2009
  • 7. Как добиться высокой эффективности?  Rational Unified Process, Prince2 , CMMi, ISO9000, Sc rum, Extreme Programming, PMBOK, P+, Evo, FDD, OpenUP, Crystal, Lean development, some text, nobody will be able to recognize, on the screen anyway. © ScrumTrek.ru, 2009
  • 8. Методология как …  …сборник рецептов  RUP полезно сравнивать с буфетом или рестораном (с) Doug Foote  …коллекция лучших практик  CMMI is a collection of best practices…(с) Wikipedia  …минимальный набор практик  Do not change Scrum (с) Ken Schwaber © ScrumTrek.ru, 2009
  • 9. Если существует самый эффективный метод, почему методов так много? © ScrumTrek.ru, 2009
  • 10. Три проблемы методологии  One size doesn’t fit ‘em all  Lack of rationale  Lack of understanding © ScrumTrek.ru, 2009
  • 11. Проект = организм?  Процессное заболевание  Дисфункция, приводящая к недостижению или неэффективному достижению целей проекта  Описание проблемы первично  Рецепт вторичен © ScrumTrek.ru, 2009
  • 12. Что можно сделать с процессным заболеванием?  Можно вылечить  Проблемы больше нет  Можно купировать  Проблема не исчезла, но больше не беспокоит  Можно объявить индивидуальной особенностью  Поменяем определение «эффективности» или цели проекта © ScrumTrek.ru, 2009
  • 13. Симптом ≠ Болезнь  Симптом = на что жалуются люди  Болезнь = что является причиной неэффективного достижения цели  Симптом  quot;У нас заказчик неадекватный»  Болезнь  Слабая связь с заказчика и разработчика © ScrumTrek.ru, 2009
  • 14. Дисфункции © ScrumTrek.ru, 2009
  • 15. Группа №1. Инфекции  Нарушения обмена информацией  Проблемы с распределением ответственности © ScrumTrek.ru, 2009
  • 16. Пример инфекции. Тестировщик против программиста  Симптомы Много открытых багов  Баги часто возвращаются  тестировщикам с пометкой «By design» Система уходит в  тестирование в полуразобранном состоянии Конфликты разработчик –  тестировщик  Причины «Все в порядке, сейчас пофиксим!» Программисты не отвечают  за качество продукта © ScrumTrek.ru, 2009
  • 17. Еще инфекции  “Неадекватныйquot; заказчик  Плохая связь разработки с заказчиками  Низкая вовлеченность/мотивация разработчиков  Низкий уровень ответственности разработчиков  Команда не соблюдает сроки разработки  Оценкой работ занимается заказчик, а не команда © ScrumTrek.ru, 2009
  • 18. Лечение инфекций  Наладим обмен веществ информацией  Короткие итерации, Daily Scrum, планирование, демонстрации и т.д.  Повысим иммунитет самоорганизацию команды  Коллективное принятие решений, прозрачность, Shared Vision, ретроспектива и т.д. © ScrumTrek.ru, 2009
  • 19. Лечение инфекций  В узком смысле  Scrum  Итеративность = прозрачность  Самоорганизация  В широком смысле  Определить роли и ответственности всех участников процесса  Agile: ответственность может нести команда! © ScrumTrek.ru, 2009
  • 20. Чеклист Role. Есть ли ответственный за решение проблемы?  Commit. Он знает, что он ответственный? Знает ли он область  своей ответственности? Openness. Все ли заинтересованные (ЗЛ) лица знают, кто  ответственый? Rights. Имеет ли ответственный эксклюзивные права на принятие  решений в его области ответственности? FUN. Получает ли ответственный удовлетворение от решения  проблемы? Means. Есть ли у него все необходимые средства для решения  проблемы? Communication. Все ли ЗЛ информируются о том, как проблема  решается? Feedback. Существует ли постоянная обратная связь по  результатам работы? © ScrumTrek.ru, 2009
  • 21. Группа №2. Токсины  Внешние по отношению к команде ограничения, влияющие на эффективность обмена информацией или правильное разделение ответственности © ScrumTrek.ru, 2009
  • 22. Примеры токсинов  Эффективность коммуникации Распределенная разработка  Языковой барьер  Разница во времени  Удаленный заказчик  quot;Отдел тестированияquot;   Разделение ответственности  Персональное бонусирование  quot;Пошареныеquot; члены проектной команды  Проекты Fixed Price © ScrumTrek.ru, 2009
  • 23. Работа с токсинами  Обмен информацией  Лечение. Убрать токсин  Купирование. Средства, облегчающие обмен информацией  Документация (Wiki, Word, Sharepoint, Scrum Notes etc)  Коммуникация (skype, videoconference, и т.д.)  Личные контакты (командировки, видео, «тимбилдинг»)  Разделение ответственности  Лечение. Убрать токсин  Купирование. Прокси - ответственный © ScrumTrek.ru, 2009
  • 24. Группа №3. Физическая форма  Проблемы объема жира документации  Проблемы качества мышечной массы кода © ScrumTrek.ru, 2009
  • 25. Примеры проблем с физической формой  Объем документации  Требования плавают в течении итерации  Никто не помнит почему мы приняли такие странные решения  Очень много переделок, которые можно было избежать  Качество кода  Долгий полный цикл тестирования  Много «наведенных» дефектов  Время на исправление дефекта невозможно оценить © ScrumTrek.ru, 2009
  • 26. Коммуникации в проекте © ScrumTrek.ru, 2009
  • 27. © ScrumTrek.ru, 2009
  • 28. © ScrumTrek.ru, 2009
  • 29. У кого из них нормальный вес? © ScrumTrek.ru, 2009
  • 30. Идеальный вес © ScrumTrek.ru, 2009
  • 31. Набор физической формы Как правило, длительный процесс  Нужно планировать работу над формой  Обязательно осознавать свои  возможности Процесс набора должен быть облегчен  по максимуму Практики  Технологический долг  TDD, Test Automation  Definition of Done  Шаблоны RUP/OpenUP  Собственные шаблоны  © ScrumTrek.ru, 2009
  • 32. Группа №4. Неврология  Фундаментальные дисфункции  Бизнес-цель неясна  Бизнес-цель недостижима  Бизнес-цель отсутствует  Ограничения эффективности несовместны © ScrumTrek.ru, 2009
  • 33. Кретинизм  Бизнес цель неясна  Лечение  Product Owner  Product Management  Vision & Biz Vison © ScrumTrek.ru, 2009
  • 34. Галлюцинации  Бизнес-цель недостижима  Лечение  Диагностика рынком  Динамично корректировать цель © ScrumTrek.ru, 2009
  • 35. Мозг мертв. Вегетативная кома  Проект еще существует, но необходимости в нем нет  Лечение  Эвтаназия © ScrumTrek.ru, 2009
  • 36. Шизофрения. Раздвоение личности  Ограничения эффективности несовместны  Как правило, означает наличие quot;политикиquot;  Лечение  Реформа внутри организации  Купирование  Product Owner ограждает команду от политики © ScrumTrek.ru, 2009
  • 37. Есть и другие дисфункции  Рак. Некомандное поведение  Недостаточность. Отсутствие всех необходимых навыков у команды  Незрелость. Непрофессионализм команды © ScrumTrek.ru, 2009
  • 38. Общие замечания  Оптимизировать процесс в целом  Заниматься болезнью, а не симптомами  Тяжелая болезнь может скрывать более легкую © ScrumTrek.ru, 2009
  • 39. Понимать процесс разработки ПО © ScrumTrek.ru, 2009
  • 40. Развитие идеи  Сделать каталог процессных дисфункций  Собрать best practices лечения  Подробности тут: http://scrumtrek.blogspot.com © ScrumTrek.ru, 2009
  • 41. Конец Будьте здоровы!  Вопросы? © ScrumTrek.ru, 2009

×