Как стать автором
Обновить

Монолог тимлида об использовании Agile-манифеста при промышленной разработке программных продуктов

Время на прочтение 4 мин
Количество просмотров 2.2K
Всего голосов 6: ↑4 и ↓2 +2
Комментарии 22

Комментарии 22

Статья воспринимается неоконченной, оборванной на полуслове.
Непонятен итог этих заметок — «все плохо»?

> Если удача улыбнулась и продукт оказался востребованным, значит его надо уже тестировать для отторжения от разработчиков.

То есть цель тестирования — отторжение продукта от разработчиков? Интересная мысль, но я пока не вникла. Можно этот момент поподробнее?

> Как фиксировать требования к продукту в условиях, когда нет ТЗ на конечный продукт, потому что никто пока не знает — что в итоге в него войдет?

Как раз в НИИСОКБ работая, я обнаружила, что во многом требования определяются тестировщиками (ну это когда нет ТЗ и аналитика)
> Непонятен итог этих заметок — «все плохо»?
Тут нет итога, как нет и предела совершенству.

> То есть цель тестирования — отторжение продукта от разработчиков? Интересная мысль, но я пока не вникла. Можно этот момент поподробнее?
Макет превращается в продукт в тот момент, когда его становится возможным использовать без участия компании-разработчика. Одно из обязательных условий для этого — устойчивая работа программы. Достичь этого без тестирования невозможно.
Спасибо за ответ. Хотя, мне кажется он немного устарел — в настоящее время трудно найти программу, которая работает без участия компании-разработчика.
> Статья воспринимается неоконченной, оборванной на полуслове.
Продолжение следует…
> большинство ошибок возникает на стыках команд разработчиков

Неудивительно, что самая востребованная внутри разработки часть требований — описания протоколов, форматов и прочих вводов/выводов компонентов системы.
Водопад — прекрасная методология,  дающая хороший результат. С предсказуемым результатом и сроками, и вдобавок с актуальной документацией. И она вполне применима в разработке, в значимом количестве случаев. И я уверена что в тех случаях где она применима она даст эффективность большую чем аджайл. Который возник потому, что значительная часть разботки ПО вышла за рамки применимости водопада — потому что для водопада требуется сначала понять, что делать, а потом делать. Причем понять надо подробно. Разработка ПО же часто начинается с пойди туда не знаю куда, принеси то, не знаю что. И тут спасает аджайл.
Но бывает, что аджайл используют не по назначению. Когда на год(ы) вперед ясно, что и как надо делать, и основная проблемка в том, что при имеющихся ресурсах не удается вписаться в сроки. Возникает вопрос как улучшить эффективность и попытка обратиться к аджайлу.
Приглашаем в проект тестировщика и, если опять фортуна к нам лицом, неизбежен вопрос: на основе чего тестировать? Завтра схожий вопрос уже от технического писателя: Как продукт должен работать, чтобы его правильно описать?

Если тестировщик будет точно знать, на основе чего тестировать, он забудет зачем нужен продукт. Тестировщики должны действовать как пользователи. Пользователи не читают документов технического писателя и не знают как именно должен работать продукт. Но у них есть желание решить свою задачу любой ценой, которую продукт должен удовлетворять без всякого «ТЗ».
Тестирование, как известно, это проверка соответствия продукта требованиям. Если их нет, то каждый тестировщик будет тестировать на соответствие своему видению. Обычно тестировщик не один. Если требований на бумаге нет, то разные часиь продукта будут соответствовать пониманиям разных тестировщиков. В итоге получим не то, что изначально задумывалось. Самый плохой вариант будет, когда баг зафиксирован одним тестировщиком, а исправление проверяется другим.
Из запланированных фич исчезает все, кроме самого необходимого, без чего фича уже и не фича. Тестируются только положительные сценарии.

Напоминает Microsoft, который отлаживает продукты на пользователях после выпуска. Чем меньше фича, тем меньше проверять. Зачем ограничиваться только положительными сценариями?
Ограничение тестирования только положительными сценариями один из способов снижения затрат на выпуск продукта. При этом проверяется только то, что реально нужно для выполнения задач пользователем. Проверка того, что при попытке ввода логина длинной 600 символов система реагирует неадекватно улучшает качество ПО минимально. В реальной работе этого почти никогда не случается, а ресурсы тестировщика на проверку и разработчиков на исправление тратятся. При этом реальные сценарии остаются непроверенными, так как количество времени на тестирование фиксировано и определяется внешними сроками.
Разработка методом последовательного наращивания функционала таит в себе мину замедленного действия. Этой проблемы не возникает, когда весь функционал и нагрузка заранее известны.

Для этого придумали говнокод. Читай агил (разрешён на территории РФ). Быстро слепили, показали заказчику, не понравилось — выкинули и забыли. Иначе платим технические алименты за то, что уже не нужно, но жалко выбросить, «авось пригодится».
Но в продукте, где уже отлаженный функционал может меняться по несколько раз, это ведет к затратам на разработку теста при каждом изменении… Обычно тесты пишутся на стабильный функционал, для проверки форматов, на нагрузку.

Как определить какой функционал стабилен, если он меняется по несколько раз?
Формально только в случае, елси никак по другому сделать нельзя. Инженерно на основе того, что функционал востребован заказчиками и запросов на доработки по нему нет в течение не менее двух (цифра меняется с опытом) релизов.
появляются релизы, состоящие только из багфиксов,… это подталкивает разработчиков к… документированию кода

Как документирование кода поможет избежать ошибок? Код должен быть понятным. Код — лучшая документация. Это в детективах и фильмах Нолана интересно, когда запутанно. В случае с кодом многоуровневые хитровложенные друг в друга абстракции сколько ни документируй, всё равно ничего не понятно.
Документировать нужно не что код делает, а зачем он написан. Комментарии вида «присвоим переменной i значение 2 для строки i=2;» никому и правда не нужны.
Большинство ошибок возникает на стыках команд разработчиков… Каждая команда выбирает компромиссное решение. Обычно тесты пишутся на стабильный функционал, для проверки форматов, на нагрузку.

Если основные проблемы возникают на стыках, почему команды пишут тесты только для себя? Кто пишет тесты на API или работу нескольких компонентов?
> Если основные проблемы возникают на стыках, почему команды пишут тесты только для себя?
Сначала это не очевидно. Потом, когда приходит понимание, тестировщики выделяются в отдельную команду и тесты пишет команда тестировщиков или разработчики по их запросу.
В какой-то момент выясняется, что принятая изначально архитектура не может вместить в себя новую фичу или не справляется с возросшей нагрузкой… Появляется необходимость в регрессионном тестировании значительной части продукта.

Выглядит как описание монолитного кода. Менять ничего нельзя. После рефакторинга одной части нужно тестировать всё целиком. Так еще кто-то делает?
Монолитность наше все. Но, на самом деле, в основном бывает так. Вам в вашем компоненте надо вызвать 3 хранимые процедуры из БД. Вы пишете код для каждой из них, потому что больше вам никогда ничего из БД не понадобится. Но потом выясняется, что количество процедур, с которыми надо работать будет 10. Вы решаете: ну ладно, напишу еще для 10. Когда их становится 20 и их количество продолжает расти приходит понимание, что надо бы обобщить. Рефакторинг. Регресс всего компонента.
"… В такие моменты начинает расти технический долг."

И как вы избавляетесь от него?
Дожидаемся, когда станет неактуальным. Это самый эффективный путь. )))
Стараемся включать задачи в релизы. Когда становится совсем плохо делаем спринт состоящий только из техдолга.
Мудрые друиды сотни лет сражаются за спасение agile c авнакодом у водопада :-)
Зарегистрируйтесь на Хабре , чтобы оставить комментарий