1. «Учитесь видеть потери!» или «Принципы бережливого производства в разработке ПО» Доклад Игорь Лужанский 23 января 2010 года

3. Поделиться опытом избавления от конкретных потерь

5. Широко применяется в большом спектре индустрий

6. Фокусируется на сокращении потерь и создании плавного потока ценности для потребителей

8. Действия не приносящие ценности заказчику – потери

9. Уважать / вдохновлять людей

10. Большинство ошибок от системы, а не от людей

11. Принимать решения как можно позже

12. Учиться, учиться и ещё раз учиться

13. Создавать как можно быстрее

14. Встраивать качество в процесс разработки

16. Клиент определяет ценность продукта

17. Действия, добавляющие ценность продукту, приближают продукт к тому, что именно требуется заказчику

19. 7 Перепроизводство – функционал, который не нужен заказчику ПРИЧИНЫ СЛЕДСТВИЯ ПЕРЕПРОИЗВОДСТВО Недостатки планирования Увеличение затрат на разработку и тестирование Большие заделы на будущее Увеличение затрат на поддержку Длительные циклы разработки Уменьшение гибкостисистемы Завышенные системные требования Слабые контакты с заказчиками Экстра функциональность

21. Заказчик не знает точно, чего он хочет (у проектной команды на руках только высокоуровневое описание бизнес-процессов, которые должна покрывать система)

22. Сжатые сроки и отсутствие времени на переделку

23. Решение проблемы

24. Сокращать цикл разработки

25. Получать регулярную обратную связь о реализуемой функциональности

26. Делать только то, что нужно заказчикуПример из жизни: как делать только то что нужно заказчику

27. 9 Исправление дефектов на стадии эксплуатации дороже, чем на стадии разработки ПРИЧИНЫ СЛЕДСТВИЯ ДЕФЕКТЫ (ПЕРЕДЕЛКА) Отсутствие превентивнойсистемы контроля Затраты на исправлениедефектов в продуктивной системе Отсутствие чётких критериев качества Затраты на исправлениерезультатов некорректной работы Частично выполненная работа Баги в системе Снижение лояльности и удовлетворенности заказчика Ошибки спецификации Необходимость переделывать то, чтоуже было сделано Пример из жизни: необходимость вносить изменение в спецификацию и сценарии тестирования при изменении требований

29. Покрытие бизнес - логики системы Unit-тестами

31. 12 Откладывание архитектурных решений позволяет уменьшить сложность системы Написание кода, который не нужен Потери времени из-за сложной архитектуры Увеличение сложности системы Увеличение риска возникновения ошибок Сильная связанность программного кода Использование шаблонов проектирования для созданиягибкой архитектуры Сокращение времени разработки Создание гибкой и простой системы Уменьшение риска возникновения ошибок Разработка только того, что важно заказчику в данный момент Пример из жизни: архитектура текущего проекта

32. 13 Поиск необходимой информации приводит к простоям в работе ПРИЧИНЫ СЛЕДСТВИЯ ПОИСК НЕОБХОДИМОЙ ИНФОРМАЦИИ Отсутствие стандартов исходного кода Простои в работе разработчиков Отсутствие централизованной базы знаний Риск появления ошибок Удаленность членов команды друг от друга Риск написания некачественного кода Получение ответов на вопросы Бюрократические процессы Поиск необходимых классов, методови т.п.

34. В процессе поддержки ПО, команда разработки привлекается для разрешения инцидентов

35. Разные инженеры поддержки обращаются с одними и теми же вопросами

36. Решение проблемы

37. Создание единой базы знаний

38. Контроль за результатами решения каждого инцидента Пример из жизни: разрешение инцидентов в команде поддержки

39. 15 Транспортировка – передача знаний, системыи переключение между задачами ПРИЧИНЫ СЛЕДСТВИЯ ТРАНСПОРТИРОВКА Распределенная команда разработки Увеличение длительности разработки Участие разработчиков в нескольких проектах Увеличение количества и длительности простоев Бюрократические процессы Передача знаний исистемы Переключение между задачами

41. Один и тот же человек выполняет 2 различные задачи: разработку и поддержку ПО

42. Потери времени при переключении между задачами

43. Конфликт интересов

44. Решение проблемы

45. Разделение команды на 2 части (команда поддержки и разработки)

48. Отсутствие четких требований

49. Сжатые сроки разработки, при которых не может быть простоев

50. Решение проблемы

51. Разрабатывать маленькими партиями

52. Находиться близко к заказчику, регулярно получать обратную связь Пример из жизни: ночные build’ы и проект в котором сложно выжить

53. 19 Частично выполненная работа – артефакты, которые ждут своего использования ПРИЧИНЫ СЛЕДСТВИЯ ЧАСТИЧНО ВЫПОЛНЕННАЯРАБОТА Подстраховка на случай отсутствия работы Риск морального устаревания результатов работы Асинхронность спроса и потребления Увеличение временивозврата инвестиций Ограниченная доступность ресурсов Требования ожидающие анализа Увеличение затрат на разработку Требования ожидающие реализации Функциональность ожидающая тестирования

55. Текущая система ужасно написана и требует рефакторинга

56. У системы отсутствует какая–либо документация

57. В системе необходимо сделать серьёзные изменения

58. Решение проблемы

59. Разделить внедрение и развертывание на 2 части (система после рефакторинга и система с новой функциональностью)

60. Последовательно запускать одну часть за другой Пример из жизни: система контроля качества или как большой слон был съеден по кусочкам

61. 21 Необходимо начинать с устранения потерь второго вида ДЕЙСТВИЯ СОЗДАЮЩИЕ ЦЕННОСТЬ ДЛЯ ПОТРЕБИТЕЛЯ Кодирование, анализ требований, развертывание системы, контроль качества Сложно исключить из процесса разработки ПОТЕРИ ПЕРВОГО ВИДА Ошибки архитектуры Легко исключить из процесса разработки ПОТЕРИ ВТОРОГО ВИДА Простои в работе, излишние требования, сложности коммуникации

63. Не существует универсальных решений, каждая практика должна быть хорошо обдумана перед её применением

65. Мы достаточно знаем и умеем для эффективной и качественной разработки.….так чего же мы ждем….. ?