[Управление разработкой, Agile, Тестирование IT-систем, Промышленное программирование] Монолог тимлида об использовании Agile-манифеста при промышленной разработке программных продуктов
Автор
Сообщение
news_bot ®
Стаж: 6 лет 5 месяцев
Сообщений: 27286
Черпаю мысли из забытых мною книг,
Стараясь перед Богом оправдаться,
Но что с того, что я смогу признаться,
В соавторстве закрученных интриг.Леонид Самойлович
Когда вы только начинаете разрабатывать программный продукт, возникает искушение не писать ТЗ и быстро набросать макет продукта, который обсуждали «в прошлый понедельник».
Команда разработчиков пока еще небольшая и все можно обсудить, не вставая из-за стола.
Если удача улыбнулась и продукт оказался востребованным, значит его надо уже тестировать для отторжения от разработчиков. Приглашаем в проект тестировщика и, если опять фортуна к нам лицом, неизбежен вопрос: на основе чего тестировать? Завтра схожий вопрос уже от технического писателя: Как продукт должен работать, чтобы его правильно описать?А теперь, ВНИМАНИЕ, главный вопрос!Как фиксировать требования к продукту в условиях, когда нет ТЗ на конечный продукт, потому что никто пока не знает - что в итоге в него войдет?
Проблема осложняется еще и тем, что теперь большинство новых фич готовятся с учетом пожеланий реальных или вероятных покупателей продукта, которые еще менее терпеливы, чем дети.
Итак, в начале долгого пути у нас есть макет продукта без требований к нему. Он не оттестирован и не описан. Так выглядит упрощенный agile в большинстве стартапов.Технология промышленной разработки программных продуктов крепко отличается. И вот почему.В таких проектах появляется несколько команд, каждая из которых ведет разработку своей части на основе функциональных требований, разработанных аналитиками.Появляется необходимость их координации. Необходимо добиться того, чтобы требования к системе все команды понимали одинаково. Возникает необходимость проводить межкомандную отладку. Команды должны писать требования к реализации или хотя бы фиксировать как именно реализованы функциональные требования. Для будущих поколений разработчиков также будет полезна информация почему реализовано именно так, а не иначе. Тестировщиков надо выделять в отдельную команду т.к. большинство ошибок возникает на стыках команд разработчиков.
Разработка методом последовательного наращивания функционала таит в себе мину замедленного действия. В какой-то момент выясняется, что принятая изначально архитектура не может вместить в себя новую фичу или не справляется с возросшей нагрузкой. Этой проблемы не возникает, когда весь функционал и нагрузка заранее известны. Бывает, что и системное ПО, на котором вы базируетесь, меняет API, а еще хуже … архитектуру. И тогда возникает необходимость в рефакторинге. Он убивает все, что приносит радость в жизни, и.... затягивает сроки спринтов в разы. Его почти невозможно предусмотреть. Появляется необходимость в регрессионном тестировании значительной части продукта. В такие моменты начинает расти технический долг.
Из запланированных фич исчезает все, кроме самого необходимого, без чего фича уже и не фича. Тестируются только положительные сценарии. Метод борьбы с ростом затрат автотесты для устоявшегося функционала. Когда продукт начинает продаваться, появляется необходимость в его поддержке. От службы поддержки появляются запросы на исправления багов. Возникает желание в исправлении только в следующей версии, не отвлекая ресурсы от разработки новых фич. Если же идти навстречу заказчикам и править баги в старом релизе, то начинают сыпаться уже согласованные спринты следующего релиза. Так как каждый исправленный баг требует тестирования в старом релизе и, в дальнейшем, проверки в правильности портирования в текущий. Разработчикам приходится переключаться с разработки новых фич на исправление ошибок и обратно. Можно заставить заказчика ждать нового релиза, обещая, что баги будут исправлены в нем. Но заказчики не готовы ждать. Поэтому, чтобы не потерять заказчика и деньги за техподдержку, приходится править ошибки в старом релизе.
Продукт приобретает свойства промышленного и … появляются релизы, состоящие только из багфиксов. Это никому, кроме заказчиков, не нравится. Потому что надо отвлекаться на старый код. А это переключение контекста. А это трата времени и срыв текущего спринта. Правда, это подталкивает разработчиков к разработке автотестов, документированию кода, чего так все не любят и, что, до момента появления багфикс релизов, всем представляется прихотью менеджеров и пустой тратой времени. Поэтому в тестировании может находиться по несколько релизов одновременно: релиз багфиксов, выпускаемый релиз, текущий спринт следующего релиза…
Чуть подробнее об автотестах. Перед командами стоит вопрос надо ли их разрабатывать и, если надо, то в каком объеме. Все наверняка знают про TDD (Test Driven Development). Но в продукте, где уже отлаженный функционал может меняться по несколько раз, это ведет к затратам на разработку теста при каждом изменении. В этом случае все тесты, кроме последнего, идут в корзину. Совсем не писать автотестов – другая крайность. Тогда все перекладывается на ручное тестирование, что ведет к недотестированию и поставке заказчикам полуфабрикатов. Это еще хуже. Каждая команда выбирает компромиссное решение. Обычно тесты пишутся на стабильный функционал, для проверки форматов, на нагрузку. Юнит тесты используются для функций со сложной логикой и/или большим количеством веток исполнений. Все тесты запускаются автоматически при каждой сборке компонентов продукта в системе CI (continuous integration). Идеальный вариант, если есть возможность воспользоваться бэта тестерами. Например, ... из числа лояльных заказчиков.
- Why you call this version “beta”?
- Because it’s betta than nothing Народная мудрость
===========
Источник:
habr.com
===========
Похожие новости:
- [Смартфоны, Социальные сети и сообщества, IT-компании] Состоялся релиз Telegram 7.1: комментарии в каналах, фильтры для поиска и анонимные администраторы в группах
- [Карьера в IT-индустрии, Развитие стартапа, Управление персоналом, Управление разработкой] Почему разработчикам так много платят: опыт Netflix, Wistia и Stripe
- [IT-компании, Microsoft Azure, Облачные сервисы] Причина масштабного сбоя облака Microsoft 365 определена — единой точкой отказа стала Azure Active Directory
- [Учебный процесс в IT, Карьера в IT-индустрии, IT-компании] Студенческие IT стажировки — как мы стараемся делать их наиболее эффективными
- [IT-компании, Конференции, Презентации, Развитие стартапа, Управление продажами] Как свозить свой продукт на международную IT-выставку, зачем и почём
- [Анализ и проектирование систем, Программирование, Промышленное программирование, Системы управления версиями] О системах контроля версий
- [IT-инфраструктура, Информационная безопасность, Исследования и прогнозы в IT] «Ростелеком-Солар»: 90% IT-систем российских госструктур могут взломать киберхулиганы
- [Анализ и проектирование систем, Управление проектами, Управление продуктом, IT-компании] Архитектурное мышление на примере одиночного велопутешествия по Алтаю
- [Управление e-commerce, IT-компании] Amazon определила день скидок Prime Day на 13-14 октября
- [IT-компании, Ноутбуки, Планшеты] Lenovo открыла предзаказ на ноутбук ThinkPad X1 Fold с гибким экраном. Стоимость устройства от $2499
Теги для поиска: #_upravlenie_razrabotkoj (Управление разработкой), #_agile, #_testirovanie_itsistem (Тестирование IT-систем), #_promyshlennoe_programmirovanie (Промышленное программирование), #_timlid (тимлид), #_agile, #_testirovanie_po (тестирование по), #_avtotestirovanie (автотестирование), #_agilemanifesta (Agile-манифеста), #_tz_na_programmirovanie (тз на программирование), #_razrabotka_prilozhenij (разработка приложений), #_itkompanii (it-компании), #_blog_kompanii_nii_sokb (
Блог компании НИИ СОКБ
), #_upravlenie_razrabotkoj (
Управление разработкой
), #_agile, #_testirovanie_itsistem (
Тестирование IT-систем
), #_promyshlennoe_programmirovanie (
Промышленное программирование
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 08-Июл 23:27
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 5 месяцев |
|
|
Черпаю мысли из забытых мною книг,
Стараясь перед Богом оправдаться, Но что с того, что я смогу признаться, В соавторстве закрученных интриг.Леонид Самойлович Команда разработчиков пока еще небольшая и все можно обсудить, не вставая из-за стола.  Если удача улыбнулась и продукт оказался востребованным, значит его надо уже тестировать для отторжения от разработчиков. Приглашаем в проект тестировщика и, если опять фортуна к нам лицом, неизбежен вопрос: на основе чего тестировать? Завтра схожий вопрос уже от технического писателя: Как продукт должен работать, чтобы его правильно описать?А теперь, ВНИМАНИЕ, главный вопрос!Как фиксировать требования к продукту в условиях, когда нет ТЗ на конечный продукт, потому что никто пока не знает - что в итоге в него войдет?  Проблема осложняется еще и тем, что теперь большинство новых фич готовятся с учетом пожеланий реальных или вероятных покупателей продукта, которые еще менее терпеливы, чем дети.  Итак, в начале долгого пути у нас есть макет продукта без требований к нему. Он не оттестирован и не описан. Так выглядит упрощенный agile в большинстве стартапов.Технология промышленной разработки программных продуктов крепко отличается. И вот почему.В таких проектах появляется несколько команд, каждая из которых ведет разработку своей части на основе функциональных требований, разработанных аналитиками.Появляется необходимость их координации. Необходимо добиться того, чтобы требования к системе все команды понимали одинаково. Возникает необходимость проводить межкомандную отладку. Команды должны писать требования к реализации или хотя бы фиксировать как именно реализованы функциональные требования. Для будущих поколений разработчиков также будет полезна информация почему реализовано именно так, а не иначе. Тестировщиков надо выделять в отдельную команду т.к. большинство ошибок возникает на стыках команд разработчиков.  Разработка методом последовательного наращивания функционала таит в себе мину замедленного действия. В какой-то момент выясняется, что принятая изначально архитектура не может вместить в себя новую фичу или не справляется с возросшей нагрузкой. Этой проблемы не возникает, когда весь функционал и нагрузка заранее известны. Бывает, что и системное ПО, на котором вы базируетесь, меняет API, а еще хуже … архитектуру. И тогда возникает необходимость в рефакторинге. Он убивает все, что приносит радость в жизни, и.... затягивает сроки спринтов в разы. Его почти невозможно предусмотреть. Появляется необходимость в регрессионном тестировании значительной части продукта. В такие моменты начинает расти технический долг.  Из запланированных фич исчезает все, кроме самого необходимого, без чего фича уже и не фича. Тестируются только положительные сценарии. Метод борьбы с ростом затрат автотесты для устоявшегося функционала. Когда продукт начинает продаваться, появляется необходимость в его поддержке. От службы поддержки появляются запросы на исправления багов. Возникает желание в исправлении только в следующей версии, не отвлекая ресурсы от разработки новых фич. Если же идти навстречу заказчикам и править баги в старом релизе, то начинают сыпаться уже согласованные спринты следующего релиза. Так как каждый исправленный баг требует тестирования в старом релизе и, в дальнейшем, проверки в правильности портирования в текущий. Разработчикам приходится переключаться с разработки новых фич на исправление ошибок и обратно. Можно заставить заказчика ждать нового релиза, обещая, что баги будут исправлены в нем. Но заказчики не готовы ждать. Поэтому, чтобы не потерять заказчика и деньги за техподдержку, приходится править ошибки в старом релизе.  Продукт приобретает свойства промышленного и … появляются релизы, состоящие только из багфиксов. Это никому, кроме заказчиков, не нравится. Потому что надо отвлекаться на старый код. А это переключение контекста. А это трата времени и срыв текущего спринта. Правда, это подталкивает разработчиков к разработке автотестов, документированию кода, чего так все не любят и, что, до момента появления багфикс релизов, всем представляется прихотью менеджеров и пустой тратой времени. Поэтому в тестировании может находиться по несколько релизов одновременно: релиз багфиксов, выпускаемый релиз, текущий спринт следующего релиза…  Чуть подробнее об автотестах. Перед командами стоит вопрос надо ли их разрабатывать и, если надо, то в каком объеме. Все наверняка знают про TDD (Test Driven Development). Но в продукте, где уже отлаженный функционал может меняться по несколько раз, это ведет к затратам на разработку теста при каждом изменении. В этом случае все тесты, кроме последнего, идут в корзину. Совсем не писать автотестов – другая крайность. Тогда все перекладывается на ручное тестирование, что ведет к недотестированию и поставке заказчикам полуфабрикатов. Это еще хуже. Каждая команда выбирает компромиссное решение. Обычно тесты пишутся на стабильный функционал, для проверки форматов, на нагрузку. Юнит тесты используются для функций со сложной логикой и/или большим количеством веток исполнений. Все тесты запускаются автоматически при каждой сборке компонентов продукта в системе CI (continuous integration). Идеальный вариант, если есть возможность воспользоваться бэта тестерами. Например, ... из числа лояльных заказчиков. - Why you call this version “beta”?
- Because it’s betta than nothing Народная мудрость =========== Источник: habr.com =========== Похожие новости:
Блог компании НИИ СОКБ ), #_upravlenie_razrabotkoj ( Управление разработкой ), #_agile, #_testirovanie_itsistem ( Тестирование IT-систем ), #_promyshlennoe_programmirovanie ( Промышленное программирование ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 08-Июл 23:27
Часовой пояс: UTC + 5