Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Теория ограничений в Agile команде

1,859 views

Published on

В рамках доклада будут рассмотрены основы Теории ограничений, применимость Теории ограничений при разработке ПО, а также будут рассмотрены практические примеры оптимизации процесса разработки.

  • Be the first to comment

Теория ограничений в Agile команде

  1. 1. Теория ограничений в Agile команде Андрей Геоня, 2GIS 19.05.2012
  2. 2. Введение в Теорию ограниченийТеория ограничений (ТО) - философия управления,направленная на повышение скорости генерированияприбыли любого предприятия. Разработанная в 1980-х гг. доктором Элияху Голдраттом.
  3. 3. Основные понятия ТО● Выработка - количество продукции, произведенной за единицу времени;● Запасы - активы, используемые в качестве сырья, материалов и т. п. при производстве продукции;● Операционные расходы - повседневные затраты компании для ведения бизнеса.
  4. 4. ТО в разработке ПО● Выработка - готовые бизнес-фичи;● Запасы - незавершенные бизнес-фичи;● Операционные расходы - все, что не несет ценности для бизнеса, но требуется при разработке (багфиксинг, рефакторинг и т. п.).
  5. 5. ЦельУвеличение выработки при сохранении или сниженииоперационных расходов и запасов:● Готовые бизнес-фичи ++;● Ожидающие бизнес-фичи --;● Багфиксинг, рефакторинг и т. п. --.
  6. 6. КомандаКоманда(ы) - это система взаимосвязанных элементов.Пример зависимостей:Аналитика~>Дизайн~>Верстка~>Разработка~>Тестирование
  7. 7. ПроизводительностьПроизводительность всей системы = производительности её"слабого звена" (ограничения):Аналитика~>Дизайн~>Верстка~>Разработка~>Тестирование
  8. 8. Шаги к цели1. Найти ограничение(я) системы - "слабое звено";2. Принять решение об эффективном использовании ограничений;3. Адаптировать всю команду для работы с ограничением;4. Увеличить пропускную способность "слабого звена";5. Если ограничение перестало быть ограничением, тогда начать все сначала.
  9. 9. Как найти ограничение● Спросить у команды - провести ретроспективу;● Проверить нагрузку на каждое "звено";● Определить загруженность "звеньев" - элементы системы, идущие после "слабого звена" будут простаивать.
  10. 10. Как использовать ограничение?Чтобы понять, как эффективно использовать ограничение,нужно выяснить, что ему мешает:● Определить во время ретроспективы;● Взглянуть на процесс в целом.
  11. 11. Как подчинить команду ограничениюВсе ресурсы, не являющиеся ограничениями, не должныработать больше, чем от них требует ограничение, но приэтом своевременно обеспечивать ограничение нужнымиресурсами.
  12. 12. Как "прокачать" ограничение● Исключить простаивание;● Улучшить качество работы перед ограничением;● Распределить обязанности "слабого звена" между членами команды (обычно это "соседние звенья").
  13. 13. Грабли. Опыт нашей команды
  14. 14. Use case. Белоснежка и 7 гномов Тестировщик и 7 программистов Ресурсы: ● 1 тестировщик; ● 7 разработчиков Проблема: ● Много задач для тестирования; ● Мало пользы....~>Разработка(7)~>Тестирование(1)
  15. 15. Как мы дали QA "разгрести" буфер задачНет, не так:Вот так:● Разработчики выполнили ряд исследовательских задач;● Разработчики начали декомпозировать задачи backlog-а.
  16. 16. Как мы исключили простаивание QA● Разработчики начали следить за буфером задач QA;● И начали поддерживать равномерный буфер, не давая ему закончиться. Простаивание QA - это очень дорого!Буфера тестировщиков:
  17. 17. Как мы улучшили качество перед QA● Перестали пропускать задачи в QA без code review;● Составили детальный checklist для code review;● Настроили уведомления Jenkins-а по commit-у;
  18. 18. Как мы ускорили само тестирование● Улучшили покрытие функционала авто-тестами;● Начали группировать задачи на тестирование в функциональные группы.
  19. 19. Что мы получили● Больше нагрузку на программистов;● Меньше нагрузку на QA;● Больше готовых фич в конце спринта.
  20. 20. Но хочется большего1. Сократить цикл работы над фичей:● Свести тестирование фичи к одной итерации (в худшем случае - одна итерация + одна верификация)Для этого:● Программировать по checklist-у (по готовым тест-кейсам), тем самым улучшить качество фичи до попадания в QA2. Привлечь пользователей к тестированию● Внедрить Continuous delivery
  21. 21. Литература
  22. 22. Вопросы?Контакты:Twitter:@AndreyGeonyaEmail:a.geonya@gmail.com

×