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

    Черпаю мысли из забытых мною книг,
    Стараясь перед Богом оправдаться,
    Но что с того, что я смогу признаться,
    В соавторстве закрученных интриг.

    Леонид Самойлович

    Когда вы только начинаете разрабатывать программный продукт, возникает искушение не писать ТЗ и быстро набросать макет продукта, который обсуждали «в прошлый понедельник».
    Команда разработчиков пока еще небольшая и все можно обсудить, не вставая из-за стола.

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

    Приглашаем в проект тестировщика и, если опять фортуна к нам лицом, неизбежен вопрос: на основе чего тестировать?

    Завтра схожий вопрос уже от технического писателя: Как продукт должен работать, чтобы его правильно описать?

    А теперь, ВНИМАНИЕ, главный вопрос!

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

    Проблема осложняется еще и тем, что теперь большинство новых фич готовятся с учетом пожеланий реальных или вероятных покупателей продукта, которые еще менее терпеливы, чем дети.

    Итак, в начале долгого пути у нас есть макет продукта без требований к нему. Он не оттестирован и не описан.

    Так выглядит упрощенный agile в большинстве стартапов.

    Технология промышленной разработки программных продуктов крепко отличается. И вот почему.

    В таких проектах появляется несколько команд, каждая из которых ведет разработку своей части на основе функциональных требований, разработанных аналитиками.

    Появляется необходимость их координации. Необходимо добиться того, чтобы требования к системе все команды понимали одинаково. Возникает необходимость проводить межкомандную отладку. Команды должны писать требования к реализации или хотя бы фиксировать как именно реализованы функциональные требования. Для будущих поколений разработчиков также будет полезна информация почему реализовано именно так, а не иначе. Тестировщиков надо выделять в отдельную команду т.к. большинство ошибок возникает на стыках команд разработчиков.

    Разработка методом последовательного наращивания функционала таит в себе мину замедленного действия. В какой-то момент выясняется, что принятая изначально архитектура не может вместить в себя новую фичу или не справляется с возросшей нагрузкой. Этой проблемы не возникает, когда весь функционал и нагрузка заранее известны. Бывает, что и системное ПО, на котором вы базируетесь, меняет API, а еще хуже … архитектуру. И тогда возникает необходимость в рефакторинге. Он убивает все, что приносит радость в жизни, и.... затягивает сроки спринтов в разы. Его почти невозможно предусмотреть. Появляется необходимость в регрессионном тестировании значительной части продукта. В такие моменты начинает расти технический долг.

    Из запланированных фич исчезает все, кроме самого необходимого, без чего фича уже и не фича. Тестируются только положительные сценарии. Метод борьбы с ростом затрат автотесты для устоявшегося функционала.

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

    Продукт приобретает свойства промышленного и … появляются релизы, состоящие только из багфиксов.

    Это никому, кроме заказчиков, не нравится. Потому что надо отвлекаться на старый код. А это переключение контекста. А это трата времени и срыв текущего спринта. Правда, это подталкивает разработчиков к разработке автотестов, документированию кода, чего так все не любят и, что, до момента появления багфикс релизов, всем представляется прихотью менеджеров и пустой тратой времени.

    Поэтому в тестировании может находиться по несколько релизов одновременно: релиз багфиксов, выпускаемый релиз, текущий спринт следующего релиза…

    Чуть подробнее об автотестах. Перед командами стоит вопрос надо ли их разрабатывать и, если надо, то в каком объеме. Все наверняка знают про TDD (Test Driven Development). Но в продукте, где уже отлаженный функционал может меняться по несколько раз, это ведет к затратам на разработку теста при каждом изменении. В этом случае все тесты, кроме последнего, идут в корзину. Совсем не писать автотестов – другая крайность. Тогда все перекладывается на ручное тестирование, что ведет к недотестированию и поставке заказчикам полуфабрикатов. Это еще хуже. Каждая команда выбирает компромиссное решение. Обычно тесты пишутся на стабильный функционал, для проверки форматов, на нагрузку. Юнит тесты используются для функций со сложной логикой и/или большим количеством веток исполнений. Все тесты запускаются автоматически при каждой сборке компонентов продукта в системе CI (continuous integration). Идеальный вариант, если есть возможность воспользоваться бэта тестерами. Например, ... из числа лояльных заказчиков.

    - Why you call this version “beta”?
    - Because it’s betta than nothing

    Народная мудрость

    НИИ СОКБ
    Компания

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

                            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                            Самое читаемое