Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

Игорь Лужанский “Потери в процессе разработки ПО”

  • Identifiez-vous pour voir les commentaires

Игорь Лужанский “Потери в процессе разработки ПО”

  1. 1. «Учитесь видеть потери!» или «Принципы бережливого производства в разработке ПО» <br />Доклад <br />Игорь Лужанский<br />23 января 2010 года<br />
  2. 2. 2<br />Цели выступления: <br /><ul><li>Проиллюстрировать и классифицировать потери в процессе разработке ПО
  3. 3. Поделиться опытом избавления от конкретных потерь
  4. 4. Вдохновить участников на совершенствование собственных процессов разработки и повышение эффективности разработки </li></li></ul><li>3<br />Бережливое производство– набор методов и принципов которые работают везде <br /><ul><li>Бережливое производство рождено в Японской автомобильной индустрии
  5. 5. Широко применяется в большом спектре индустрий
  6. 6. Фокусируется на сокращении потерь и создании плавного потока ценности для потребителей
  7. 7. Парадигма бережливого производства используется так же и для оптимизации процесса разработки </li></li></ul><li>4<br />7 принципов lean<br /><ul><li>Сокращать потери
  8. 8. Действия не приносящие ценности заказчику – потери
  9. 9. Уважать / вдохновлять людей
  10. 10. Большинство ошибок от системы, а не от людей
  11. 11. Принимать решения как можно позже
  12. 12. Учиться, учиться и ещё раз учиться
  13. 13. Создавать как можно быстрее
  14. 14. Встраивать качество в процесс разработки
  15. 15. Оптимизировать всю систему </li></li></ul><li>5<br />Ценность это то, за что готов платить заказчик <br /><ul><li>Клиент готов заплатить только за те процессы, которые добавляют ценность продукту
  16. 16. Клиент определяет ценность продукта
  17. 17. Действия, добавляющие ценность продукту, приближают продукт к тому, что именно требуется заказчику
  18. 18. Любые действия, не добавляющие ценности продукту, считаются потерями. </li></li></ul><li>6<br />Потери – это то, что не добавляет ценности продукту<br />Увеличение затрат на разработку<br />ПОТЕРИ<br />Увеличение срока окупаемости инвестиций<br />Снижение мотивации разработчиков<br />Перепроизводство<br />Лишние действия и операции<br />Дефекты<br />Излишняя обработка<br />Поиск информации<br />Простои в работе<br />Транспортировка<br />Ожидание<br />Частично выполненная работа<br />
  19. 19. 7<br />Перепроизводство – функционал, который не нужен заказчику <br />ПРИЧИНЫ<br />СЛЕДСТВИЯ<br />ПЕРЕПРОИЗВОДСТВО<br />Недостатки <br />планирования<br />Увеличение затрат на разработку и тестирование<br />Большие заделы <br /> на будущее<br />Увеличение затрат на поддержку<br />Длительные циклы разработки<br />Уменьшение гибкостисистемы <br />Завышенные системные требования <br />Слабые контакты с <br />заказчиками<br />Экстра функциональность<br />
  20. 20. 8<br />Короткий цикл разработки позволяет исключить перепроизводство<br /><ul><li>Описание проблемы:
  21. 21. Заказчик не знает точно, чего он хочет (у проектной команды на руках только высокоуровневое описание бизнес-процессов, которые должна покрывать система)
  22. 22. Сжатые сроки и отсутствие времени на переделку
  23. 23. Решение проблемы
  24. 24. Сокращать цикл разработки
  25. 25. Получать регулярную обратную связь о реализуемой функциональности
  26. 26. Делать только то, что нужно заказчику</li></ul>Пример из жизни: как делать только то что нужно заказчику <br />
  27. 27. 9<br />Исправление дефектов на стадии <br />эксплуатации дороже, чем на стадии разработки <br />ПРИЧИНЫ<br />СЛЕДСТВИЯ<br />ДЕФЕКТЫ<br />(ПЕРЕДЕЛКА)<br />Отсутствие превентивнойсистемы контроля<br />Затраты на исправлениедефектов в продуктивной системе<br />Отсутствие чётких критериев качества<br />Затраты на исправлениерезультатов некорректной работы<br />Частично выполненная работа<br />Баги в системе<br />Снижение лояльности и удовлетворенности заказчика<br />Ошибки спецификации<br />Необходимость переделывать то, чтоуже было сделано<br />Пример из жизни: необходимость вносить изменение в спецификацию и сценарии тестирования при изменении требований<br />
  28. 28. 10<br />Встраивание качества в процесс разработки позволяет уменьшить количество дефектов <br /><ul><li>Тестирование требований до начала процесса разработки
  29. 29. Покрытие бизнес - логики системы Unit-тестами
  30. 30. Автоматизация процесса тестирования </li></li></ul><li>11<br />Излишняя обработка вызвана сложной <br />внутренней структурой приложения<br />ПРИЧИНЫ<br />СЛЕДСТВИЯ<br />ИЗЛИШНЯЯ ОБРАБОТКА<br />Завышенные требования к качеству<br />Увеличение времениразработки <br />Стремление создать универсальную систему<br />Уменьшение гибкости и масштабируемости системы<br />Сложная архитектура системы<br />Увеличение риска возникновения ошибок<br />Создание ненужных артефактов<br />Использование «передовых» технологий<br />Сложность доступа к внутренним функциям системы<br />
  31. 31. 12<br />Откладывание архитектурных решений позволяет уменьшить сложность системы <br />Написание кода, который не нужен<br />Потери времени из-за сложной архитектуры <br />Увеличение сложности системы<br />Увеличение риска возникновения ошибок<br />Сильная связанность программного кода<br />Использование шаблонов <br />проектирования для созданиягибкой архитектуры <br />Сокращение времени разработки<br />Создание гибкой и простой системы<br />Уменьшение риска возникновения ошибок <br />Разработка только того, что важно заказчику в данный момент<br />Пример из жизни: архитектура текущего проекта <br />
  32. 32. 13<br />Поиск необходимой информации приводит к простоям в работе<br />ПРИЧИНЫ<br />СЛЕДСТВИЯ<br />ПОИСК НЕОБХОДИМОЙ ИНФОРМАЦИИ<br />Отсутствие стандартов исходного кода<br />Простои в работе разработчиков<br />Отсутствие централизованной базы знаний<br />Риск появления ошибок<br />Удаленность членов команды друг от друга <br />Риск написания некачественного кода<br />Получение ответов на вопросы<br />Бюрократические процессы<br />Поиск необходимых классов, методови т.п.<br />
  33. 33. 14<br />Построение базы знаний позволяет сократить время на поиск информации <br /><ul><li>Описание проблемы
  34. 34. В процессе поддержки ПО, команда разработки привлекается для разрешения инцидентов
  35. 35. Разные инженеры поддержки обращаются с одними и теми же вопросами
  36. 36. Решение проблемы
  37. 37. Создание единой базы знаний
  38. 38. Контроль за результатами решения каждого инцидента </li></ul>Пример из жизни: разрешение инцидентов в команде поддержки <br />
  39. 39. 15<br />Транспортировка – передача знаний, системыи переключение между задачами<br />ПРИЧИНЫ<br />СЛЕДСТВИЯ<br />ТРАНСПОРТИРОВКА<br />Распределенная команда <br /> разработки <br />Увеличение длительности<br /> разработки <br />Участие разработчиков в нескольких проектах <br />Увеличение количества и длительности простоев <br />Бюрократические процессы<br />Передача знаний исистемы <br />Переключение между задачами<br />
  40. 40. 16<br />Специализация на одном виде задач эффективна благодаря отсутствию переключений между задачами<br /><ul><li>Описание проблемы
  41. 41. Один и тот же человек выполняет 2 различные задачи: разработку и поддержку ПО
  42. 42. Потери времени при переключении между задачами
  43. 43. Конфликт интересов
  44. 44. Решение проблемы
  45. 45. Разделение команды на 2 части (команда поддержки и разработки)
  46. 46. Разделение обязанностей и приоритетов для различных задач</li></li></ul><li>17<br />Ожидание – простой процесса из-за ожиданиярезультатов работы предыдущего процесса<br />ПРИЧИНЫ<br />СЛЕДСТВИЯ<br />ОЖИДАНИЕ<br />Плохое планирование<br />Увеличение времениразработки <br />Дискретность поставок<br />Увеличение временивозврата инвестиций<br />Недоступность <br />участников процесса<br />Увеличение затрат на разработку<br />Ожидание принятия решений<br />Ожидание необходимых для работы ресурсов<br />Пример из жизни: аналитик ожидающий решений заказчика<br />
  47. 47. 18<br />Способность разрабатывать, выпускать маленькие релизы – уменьшает ожидание <br /><ul><li>Описание проблемы
  48. 48. Отсутствие четких требований
  49. 49. Сжатые сроки разработки, при которых не может быть простоев
  50. 50. Решение проблемы
  51. 51. Разрабатывать маленькими партиями
  52. 52. Находиться близко к заказчику, регулярно получать обратную связь </li></ul>Пример из жизни: ночные build’ы и проект в котором сложно выжить<br />
  53. 53. 19<br />Частично выполненная работа – артефакты, <br />которые ждут своего использования<br />ПРИЧИНЫ<br />СЛЕДСТВИЯ<br />ЧАСТИЧНО ВЫПОЛНЕННАЯРАБОТА<br />Подстраховка на случай отсутствия работы <br />Риск морального устаревания результатов работы <br />Асинхронность спроса и потребления<br />Увеличение временивозврата инвестиций<br />Ограниченная доступность ресурсов<br />Требования ожидающие анализа <br />Увеличение затрат на разработку<br />Требования ожидающие реализации<br />Функциональность ожидающая тестирования<br />
  54. 54. 20<br />Маленькие релизы позволяют уменьшить риски внедрения систем<br /><ul><li>Описание проблемы
  55. 55. Текущая система ужасно написана и требует рефакторинга
  56. 56. У системы отсутствует какая–либо документация
  57. 57. В системе необходимо сделать серьёзные изменения
  58. 58. Решение проблемы
  59. 59. Разделить внедрение и развертывание на 2 части (система после рефакторинга и система с новой функциональностью)
  60. 60. Последовательно запускать одну часть за другой </li></ul>Пример из жизни: система контроля качества или как большой слон был съеден по кусочкам<br />
  61. 61. 21<br />Необходимо начинать с устранения потерь второго вида<br />ДЕЙСТВИЯ СОЗДАЮЩИЕ ЦЕННОСТЬ ДЛЯ ПОТРЕБИТЕЛЯ<br />Кодирование, анализ требований, развертывание системы, контроль качества<br />Сложно исключить из <br />процесса разработки<br />ПОТЕРИ ПЕРВОГО ВИДА<br />Ошибки архитектуры <br />Легко исключить из <br />процесса разработки<br />ПОТЕРИ ВТОРОГО ВИДА<br />Простои в работе, излишние требования, сложности коммуникации<br />
  62. 62. 22<br />Завершение <br /><ul><li>Принципы бережливого производства применяются в различных индустриях и при правильном подходе работают и в разработке ПО
  63. 63. Не существует универсальных решений, каждая практика должна быть хорошо обдумана перед её применением
  64. 64. Любые начинания в бережливой разработке бессмысленны без вовлечения и поддержки всех членов команды </li></li></ul><li>23<br />Послесловие …. <br /><ul><li>8-я потеря – нерациональное использование творческого и интеллектуального потенциала сотрудников
  65. 65. Мы достаточно знаем и умеем для эффективной и качественной разработки.</li></ul>….так чего же мы ждем….. ?<br />

×