Добрый день, коллеги.
27 апреля прошел ALM Summit 2012, первый из проведенных в России. Под катом, я хочу привести паттерны, применение которых в рамках жизненного цикла приложения разрабатываемого по Agile позволит снизить барьеры между всеми теми людьми, которые участвуют в разработке ПО. Собственно все эти паттерны вчера на саммите и обсуждались. И если вы не были на этом мероприятии и не смотрели трансляцию, а тема вам покажется интересной, то, как только выложат записи, вы все это сможете посмотреть.
Итак, давайте определимся, какие же люди у нас участвуют в жизненном цикле нашего приложения. В первую очередь, это пользователи, которым предстоит решать свои задачи при помощи разрабатываемого ПО. Вторым участником процесса является Product Manager, который собирает пожелания пользователей и доносит их до третьего участника процесса – команды разработчиков. Четвертыми по порядку, но не по важности идут тестировщики. Ну, и на последнем этапе, ко всему этому подключаются специалисты по развертыванию и сопровождению (на саммите их называли Operations). И вот между всеми этими участниками процесса возникают барьеры. Если позволите, небольшой пример из моей практики:
К нам обратились с вопросом автоматизации учета материалов и компонентов в процессе производства, причем заказчик пришел уже с готовым ТЗ, подписанным главным технологом и директором. Доуточнив темные пятна ТЗ, мы разработали первую часть функционала (для отдела входного контроля), развернули на железе заказчика. И… Выяснилось, что начальник службы входного контроля этого ТЗ в глаза не видел, и нормативные документы, которые они используют не ложатся на то средство автоматизации, которое им поставили. Рассказать что было дальше? А время и деньги уже потрачены.
Ну еще пара небольших примеров: Первый классический, про него можно даже не расписывать, а просто привести одну фразу «А у меня на компьютере все работает!». Разработчики и тестировщики себя уже узнали? Второй чуть менее классический, но возникающий достаточно часто. Вы разрабатываете систему, разрабатываете. Все хорошо, все функции выполняются. Но когда вы разворачиваете в Production и на систему идут реальные пользователи, под нагрузкой все работать перестает. И начинается Ping Pong. Разработчики: «да у нас все хорошо. Это сисадмины с развертыванием что то не так сделали». Сисадмины не отстают: «Да что тут можно не так сделать? Мы все развернули по вашей инструкции, это у вас в программе косяки».
И все это мешает нам поставить полезность для бизнеса, получить счастливых пользователей и, как итог, снижает нашу с вами удовлетворенность от проделанной работы.
Ладно, с присказкой пора заканчивать, переходим к сказке. Ниже приведу 6 паттернов, которые могут быть применены в процессе жизненного цикла ПО. Здесь, они перечислены декларативно (причем в некоторых случаях я успел записать не все), но для памяти пусть будет, а потом понапишу по ним отдельных статей. Поехали!
1. Совместное мышление
Проблемы:
Текстовые требования устаревают
Тратится огромное количество времени на согласование проектной документации
Позднее обнаружение ошибок
Решение:
Объединить разработчиков и пользователей
Рецепты:
Совместное планирование сценариев
Совместное прототипирование
Совместное определение критериев качества
Ценность:
Быстрый цикл описания требований
Получение ПО нужного пользователю
2. Быстрая поставка
Проблемы:
Очень долгий путь производства ПО приводящий к Big Bang Releases.
Поставленное решение не отвечает ожиданиям пользователей.
Решение:
Последовательная поставка функционала небольшими частями (минимально жизнеспособный продукт - Minimally Viable Products (MVP)).
Рецепты:
Совместная работа над сценариями
Совместное планирование версий
Общая команда разработки, пользователей и внедрения
Ценность:
Сокращение времени до начала продаж
Непрерывный поток полезности
3. Разработка на основе ожиданий
Проблемы
Поздняя проверка на соответствие требованиям
ПО не соответствует ожиданиям заказчика
Решение:
Разрабатывать в соответствии с ожиданиями (TDD)
Рецепты:
Определение понятия готовности
Запись требований готовности
Проверка требований готовностиЦенность:
Поставка программного обеспечения отвечает требованиям заинтересованных сторон
4. Непрерывный контроль качества
Проблема:
Баланс между скоростью разработки и качеством
Решение:
Непрерывное управление качеством
Рецепты:
Палитры автотестов
Контроль архитектуры
Поддержка эксплуатации
Непрерывная интеграция
Непрерывные тесты
Статический анализ кода
Code Review
Непрерывный сбор отзывов
Прослеживаемость от начала до конца
Ценность:
Обеспечение высокого качества при высокой скорости
5. Адекватные процессы
Проблемы:
Отсутствие процессов
Усложненные процессы
Решение:
Применение хорошо зарекомендовавших себя процессов
Рецепты:
Внедрение процессов постепенно
Начинать внедрение с простых процессов
Оценивать эффективность процессов и ценность которую можно получить от их внедрения
Постоянный процесс улучшения
Ценности:
Эффективное использование ресурсов
Комфортная работа
Готовность к новым достижениям
6. DevOps
Проблемы:
Разрозненность разработки и внедрения снижает продуктивность на «последней миле»
Решение:
DevOps практики
Рецепты:
Проектирование для развертывания (в критерии приемки ставить требования из развертывания)
Автоматическое развертывание
Единая среда управления инцидентами
Использование опыта полученного в развернутой среде для разработки и тестирования
Ценность:
Увеличение производительности команды на «Последней миле»
Сокращение MTTR (mean time to repair)
27 апреля прошел ALM Summit 2012, первый из проведенных в России. Под катом, я хочу привести паттерны, применение которых в рамках жизненного цикла приложения разрабатываемого по Agile позволит снизить барьеры между всеми теми людьми, которые участвуют в разработке ПО. Собственно все эти паттерны вчера на саммите и обсуждались. И если вы не были на этом мероприятии и не смотрели трансляцию, а тема вам покажется интересной, то, как только выложат записи, вы все это сможете посмотреть.
Итак, давайте определимся, какие же люди у нас участвуют в жизненном цикле нашего приложения. В первую очередь, это пользователи, которым предстоит решать свои задачи при помощи разрабатываемого ПО. Вторым участником процесса является Product Manager, который собирает пожелания пользователей и доносит их до третьего участника процесса – команды разработчиков. Четвертыми по порядку, но не по важности идут тестировщики. Ну, и на последнем этапе, ко всему этому подключаются специалисты по развертыванию и сопровождению (на саммите их называли Operations). И вот между всеми этими участниками процесса возникают барьеры. Если позволите, небольшой пример из моей практики:
К нам обратились с вопросом автоматизации учета материалов и компонентов в процессе производства, причем заказчик пришел уже с готовым ТЗ, подписанным главным технологом и директором. Доуточнив темные пятна ТЗ, мы разработали первую часть функционала (для отдела входного контроля), развернули на железе заказчика. И… Выяснилось, что начальник службы входного контроля этого ТЗ в глаза не видел, и нормативные документы, которые они используют не ложатся на то средство автоматизации, которое им поставили. Рассказать что было дальше? А время и деньги уже потрачены.
Ну еще пара небольших примеров: Первый классический, про него можно даже не расписывать, а просто привести одну фразу «А у меня на компьютере все работает!». Разработчики и тестировщики себя уже узнали? Второй чуть менее классический, но возникающий достаточно часто. Вы разрабатываете систему, разрабатываете. Все хорошо, все функции выполняются. Но когда вы разворачиваете в Production и на систему идут реальные пользователи, под нагрузкой все работать перестает. И начинается Ping Pong. Разработчики: «да у нас все хорошо. Это сисадмины с развертыванием что то не так сделали». Сисадмины не отстают: «Да что тут можно не так сделать? Мы все развернули по вашей инструкции, это у вас в программе косяки».
И все это мешает нам поставить полезность для бизнеса, получить счастливых пользователей и, как итог, снижает нашу с вами удовлетворенность от проделанной работы.
Ладно, с присказкой пора заканчивать, переходим к сказке. Ниже приведу 6 паттернов, которые могут быть применены в процессе жизненного цикла ПО. Здесь, они перечислены декларативно (причем в некоторых случаях я успел записать не все), но для памяти пусть будет, а потом понапишу по ним отдельных статей. Поехали!
1. Совместное мышление
Проблемы:
Текстовые требования устаревают
Тратится огромное количество времени на согласование проектной документации
Позднее обнаружение ошибок
Решение:
Объединить разработчиков и пользователей
Рецепты:
Совместное планирование сценариев
Совместное прототипирование
Совместное определение критериев качества
Ценность:
Быстрый цикл описания требований
Получение ПО нужного пользователю
2. Быстрая поставка
Проблемы:
Очень долгий путь производства ПО приводящий к Big Bang Releases.
Поставленное решение не отвечает ожиданиям пользователей.
Решение:
Последовательная поставка функционала небольшими частями (минимально жизнеспособный продукт - Minimally Viable Products (MVP)).
Рецепты:
Совместная работа над сценариями
Совместное планирование версий
Общая команда разработки, пользователей и внедрения
Ценность:
Сокращение времени до начала продаж
Непрерывный поток полезности
3. Разработка на основе ожиданий
Проблемы
Поздняя проверка на соответствие требованиям
ПО не соответствует ожиданиям заказчика
Решение:
Разрабатывать в соответствии с ожиданиями (TDD)
Рецепты:
Определение понятия готовности
Запись требований готовности
Проверка требований готовностиЦенность:
Поставка программного обеспечения отвечает требованиям заинтересованных сторон
4. Непрерывный контроль качества
Проблема:
Баланс между скоростью разработки и качеством
Решение:
Непрерывное управление качеством
Рецепты:
Палитры автотестов
Контроль архитектуры
Поддержка эксплуатации
Непрерывная интеграция
Непрерывные тесты
Статический анализ кода
Code Review
Непрерывный сбор отзывов
Прослеживаемость от начала до конца
Ценность:
Обеспечение высокого качества при высокой скорости
5. Адекватные процессы
Проблемы:
Отсутствие процессов
Усложненные процессы
Решение:
Применение хорошо зарекомендовавших себя процессов
Рецепты:
Внедрение процессов постепенно
Начинать внедрение с простых процессов
Оценивать эффективность процессов и ценность которую можно получить от их внедрения
Постоянный процесс улучшения
Ценности:
Эффективное использование ресурсов
Комфортная работа
Готовность к новым достижениям
6. DevOps
Проблемы:
Разрозненность разработки и внедрения снижает продуктивность на «последней миле»
Решение:
DevOps практики
Рецепты:
Проектирование для развертывания (в критерии приемки ставить требования из развертывания)
Автоматическое развертывание
Единая среда управления инцидентами
Использование опыта полученного в развернутой среде для разработки и тестирования
Ценность:
Увеличение производительности команды на «Последней миле»
Сокращение MTTR (mean time to repair)
Комментариев нет:
Отправить комментарий