Successfully reported this slideshow.

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

7

Share

1 of 22
1 of 22

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

7

Share

Download to read offline

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

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

More Related Content

Related Audiobooks

Free with a 14 day trial from Scribd

See all

Теория ограничений в 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-у (по готовым тест-кейсам), тем самым улучшить качество фичи до попадания в QA 2. Привлечь пользователей к тестированию ● Внедрить Continuous delivery
  21. 21. Литература
  22. 22. Вопросы? Контакты: Twitter: @AndreyGeonya Email: a.geonya@gmail.com

×