Методики agile-тестирования: польза для вас | Atlassian

1 Введение в примеры проектов

Внедрение проекта: В соответствии с требованиями онлайн-B2B-компании мы разработаем поисковый сервис, аналогичный Google. Как веб-сервис, сервис может быть встроен в веб-страницу. Когда пользователь вводит ключевые слова и выбирает тип и местонахождение продавца, система возвращает список конкретных продавцов (см. Рисунок 3).

Рисунок 3. Схема примера проекта

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

Каждому периоду времени соответствуют соответствующие тестовые задания. Обычно циклы Sprint делятся на две категории: Feature Sprint и Release Sprint. Функциональный цикл в основном включает в себя разработку новых функций и различные тесты. Цикл выпуска будет объединен с планом для определения функций новой версии и последующего тестирования последних функций.

В итеративном цикле спринта часть разработки можно разделить на кодирование и модульное тестирование, рефакторинг и интеграцию в соответствии с традиционными шагами. Следует отметить, что рефакторинг и интеграция — это задачи, которые нельзя игнорировать в итерации гибкой разработки Sprint. Если вы хотите оптимизировать и улучшить последнюю функцию в новом цикле Sprint, рефакторинг и интеграция неизбежны.

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

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

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

Часть 1: введение в гибкую разработку программного обеспечения

Гибкая разработка программного обеспечения (Agile Software Development) началась в середине девяностых годов. Изначально она была предназначена для сравнения с традиционной моделью разработки программного обеспечения «водопад» (модель водопада), поэтому методы в то время назывались облегченными методами.

В начале своего создания Agile Alliance сформулировал четыре основных ценностных принципа:

1. Коммуникация с людьми важнее процессов и инструментов (Individuals and interactions over processes and tools）
2. Программные продукты важнее длинных статей (Working software over comprehensive documentation）
3. Сотрудничество с клиентами важнее переговоров по контракту (Customer collaboration over contract negotiation）
4. Отзывчивость важнее соответствия (Responding to change over following a plan）

На основе этих четырех принципов гибкая разработка программного обеспечения имеет свой уникальный процесс.

Весь процесс смешан со многими методами разработки программного обеспечения, появившимися еще до гибкой разработки, включая экстремальное программирование (1996 г.), Scrum (1986 г.), разработку через функции и разработку через тестирование. Подождите. Эти методы полностью отражены и применяются на всех этапах процесса гибкой разработки программного обеспечения.

Например, Скрам в основном фокусируется на управлении проектами. Менеджер проекта (Скрам-мастер) в команде должен сформулировать цикл Спринта при поступлении каждого запроса клиента, определить цели каждого Спринта, назначить задачи, контролировать и, наконец, подвести итоги достижений и результатов. потерь и начать Планируйте новый Спринт.

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

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

Менеджер проекта решает, следует ли исправить эти проблемы, в зависимости от хода проекта и серьезности дефектов. Дефект, который необходимо вовремя исправить, — это новая задача в текущем Спринте. Менеджер проекта добавит ее в Бэклог Спринта и уведомит разработчика об исправлении уязвимости.

Для процесса обзора в гибкой разработке и тестировании полностью применена идея коллегиального обзора в экстремальном программировании. Обзор кода и документации преследует цель простоты и эффективности. Члены команды образуют пару, чтобы проверять друг друга; иногда разработчик и тестировщик также могут образовать пару для сотрудничества друг с другом. Это может помочь устранить дефекты и проблемы в зародыше.

Гибкая разработка также имеет следующие ключевые концепции (ключевые вопросы):

1. Итерационный процесс (Итерационный процесс)
2. Истории пользователей
3. Задачи
4. Stand-up встреча
5. Непрерывная интеграция
6. Самые простые решения
7. Рефакторинг

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

2 Стадия разработки пользовательской истории и планирования выпуска

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

3.2.1 Поиск скрытых гипотез

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

Пример проекта:

1. Подумайте с точки зрения онлайн-компаний B2B

В: Какое значение имеет это окно поиска для бизнеса компании?

A: Поле поиска может помочь пользователю получить справочную информацию поставщика. Если все больше и больше пользователей будут использовать это окно поиска, это может увеличить количество посещений нашего веб-сайта.

1. Думайте с точки зрения пользователя

Q: Как пользователь веб-сайта ищет информацию и деловых партнеров, каковы преимущества окна поиска для меня?

A: Недостаток: я нашел адрес продавца только для того, чтобы узнать, что он был закрыт в прошлом.

Преимущества: найти продавцов легко, просто щелкните мышью

Недоволен: иногда я ищу продавца определенного типа, но не помню его конкретного названия.

1. Думайте с точки зрения программиста

3 Фаза итеративного спринта

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

Кроме того, каждая команда может соответствующим образом установить значение рабочей нагрузки (коэффициент нагрузки) в соответствии с возможностями и опытом работы соответствующих членов команды. Например, значение рабочей нагрузки нашей команды составляет 75%, что означает, что каждый человек работает 6 часов в день (рассчитывается как 8 часов). Затем каждый может приступить к назначению задач.

Когда группа разработчиков приступает к написанию кода и модульному тестированию, работа тестировщиков включает: оценку времени приемочного тестирования, оценку конструкции тестовой среды, детальный дизайн приемочного теста и написание кода приемочного тестирования.

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

3.3.1 Расчетное время приемочных испытаний

На ранних этапах разработки программного обеспечения необходимо оценить время, чтобы составить план. Это более широко используется в гибкой разработке. Если предыдущая модель разработки требовала, чтобы тестировщики оценивали план выпуска версии программного обеспечения (такой план обычно длится несколько месяцев), то теперь необходимо оценивать задачи от двух недель до одного месяца на каждой встрече по возможности спринта.

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

1. Быстрый и грубый метод

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

Пример проекта:

Предполагается, что разработка окна поиска займет 78 дней и 1 человек. Однако с учетом того, что в системе есть функция нечеткого поиска, на тестовое задание может приходиться около 40%, примерно 1 человек за 31 день. Конкретные задачи перечислены ниже:

1. Тщательный и вдумчивый подход

Этот метод начинается с основных шагов тестового задания и выполняет детальную классификацию. Они включают:

1. Подготовка к тесту (разработка тестовых примеров, подготовка тестовых данных, написание автоматического тестового кода и улучшение кода)
2. Тестовая операция (создание среды, выполнение теста, анализ и отчет о результатах)
3. Особые соображения

Пример проекта:

Примеры оценки одиночного тестового задания приведены в таблице ниже:

Сводная информация о предполагаемых нескольких тестовых задачах представлена ​​в следующей таблице:

3.3.2 Построение структуры оценочного тестирования

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

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

Пример проекта:

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

3.3.3 Сценарии приемочных испытаний детального проекта

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

Поскольку процесс гибкой разработки — это итеративный процесс, многие сложные функции могут быть оптимизированы в будущем цикле Sprint. Для тестировщиков эффективный метод — попытаться использовать некоторые тестовые примеры, которые проверяют базовые функции, в качестве базовых тестовых примеров для проверки (базовые тестовые примеры для проверки) для достижения автоматизации в первый раз; а для некоторых сложных функциональных тестовых случаев вы можете сначала использовать их Ручное тестирование метода, а затем рассмотрите возможность автоматизации, пока функция не достигнет стабильности в будущем цикле Sprint.

Кроме того, для выявления дефектов при тестировании могут быть разработаны примеры регрессионного тестирования (Regression Test Case), и для них может быть написан автоматический тестовый код, чтобы такие проблемы можно было легко и эффективно проверять в течение цикла выпуска (Release Sprint).

Пример проекта:

Основные тестовые сценарии проверки:

Функциональный тестовый пример:

3.3.4 Написать примеры приемочных испытаний

Гибкая разработка не рекомендует писать слишком много документов, а напрямую писать тестовые примеры. Кроме того, тестировщики и заказчики должны хорошо общаться, обобщать эти требования и преобразовывать их в примеры приемочного тестирования. Если ресурсов достаточно, лучше всего установить механизм контроля версий для тестовых примеров приемки.

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

Scrum

Вообще-то Scrum появился еще до того, как сформировался манифест Agile. Но его принципы хорошо укладываются в концепцию гибкой методологии, поэтому принято причислять его к этому семейству.

Впервые термин прозвучал в 1986 году. Японские исследователи Икуджиро Нонака и Хиротака Такеучи в статье The new New product development game сформулировали принципы, позволяющие быстрее создавать новый продукт. Среди условий такой разработки назвали самоорганизующуюся команду специалистов, их полную свободу в творчестве и работе — без ограничений со стороны топ-менеджмента. Этот подход авторы описали так:

«Это как оставить всех сотрудников на втором этаже и убрать лестницу, а потом сказать: прыгайте или делайте что угодно — решение за вами. Экстремальные условия рождают творческий подход!»

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

Главное для Scrum-подхода — особая динамика работы, когда команда постоянно обсуждает, как сделать продукт лучше. Такой ритм авторы сравнивают с регби: игроки передают мяч друг другу, но при этом команда движется по полю как единое целое, достигая общей цели. Из регби и пришел термин «скрам» — это схватка из-за мяча.

Методика, предложенная Нонака и Такеучи, нашла применение в IT-сфере, разработке инженерных решений в машиностроении, электронике. В 90-х Scrum оформился как проработанная и цельная методология, оброс конкретными приемами, помогающими с нуля наладить работу команды.

V-model (модель верификации и валидации)

Как и каскадная модель, методика V-Model основана на прямой последовательности шагов. Основным отличием между этими двумя методологиями является то, что тестирование в данном случае планируется параллельно с соответствующей стадией разработки. Согласно этой методологии тестирования ПО, процесс начинается как только определены требования и становится  возможным начать статическое тестирование, т.е. верификацию и обзор, что позволяет избежать возможных дефектов ПО на поздних стадиях.

Схема данной модели показывает принцип разделения задач на две части. Те, которые относятся к дизайну и разработке, размещены слева. Задачи, относящиеся к тестированию ПО, размещены справа:

Основные этапы этой методологии могут изменяться, однако обычно они включают следующие:

• Этап определения требований. Приемочное тестирование относится к этому этапу. Его основная задача состоит в оценке готовности системы к финальному использованию
• Этап, на котором происходит высокоуровневое проектирование, или High-Level Design (HDL). Этот этап относится к системному тестированию и включает оценку соблюдения требований к интегрированным системам
• Фаза детального дизайна (Detailed Design) параллельна фазе интеграционного тестирования, во время которой происходит проверка взаимодействий между различными компонентами системы
• После этапа написания кода начинается другой важный шаг — юнит-тестирование. Очень важно убедиться в том, что поведение отдельных частей и компонентов ПО корректно и соответствует требованиям

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

Вмешательство человека через глубокое тестирование

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

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

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

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

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

Гибкость во всем

С английского agile переводится как «подвижный, быстрый, проворный». Но в русской IT-лексике за этой группой методологий закрепилось определение «гибкие». Agile-подход динамично организует программирование, постоянно адаптируя проект к новым обстоятельствам и требованиям.

Не углубляясь в детали, вспомним, как устроена разработка по методологии Waterfall:

1. Выдвигаются требования к ПО, разрабатывается техническое задание (ТЗ).
2. Поставленные задачи воплощаются в коде.
3. Выполняется тестирование.
4. Готовое ПО внедряется в работу.

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

В Agile-методологии в приоритете не исходные установки, а актуальные потребности пользователя. Постоянно вносить изменения в ТЗ, даже в самый разгар разработки, для Agile нормально. В гибкой методологии не предусмотрен предварительный генеральный план — напротив, программный продукт пишется практически экспромтом.

Разработка проходит через ряд циклов — итераций. Каждая итерация — это фактически отдельный проект, где разрабатывают фрагмент программы, улучшают функциональность, добавляют новые возможности.

Чтобы понять, как это работает, представим коллектив разработчиков, создающих аудиоплеер. Уже написан костяк программного кода: интерфейс и базовый функционал. Программа умеет воспроизводить файлы формата MP3, WAV и OGG. Но пользователи предлагают добавить проигрывание CD-дисков и подключить горячие клавиши, чтобы быстро управлять плеером.

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

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

На этом итерация завершается — и начинается новый виток разработки.

Для большинства проектов хватит 4 направлений метрик:

К метрикам применимы те же правила, что и к другим Agile-инструментам.

Идеи и принципы

Гибкая методология — не единый подход к разработке, а набор идей и принципов, на которых основаны конкретные практические решения. Можно считать это особой философией, которая задает вектор, а не предписывает действия. Эти идеи и принципы были впервые сформулированы в Agile-манифесте.

Четыре центральных идеи Agile Manifesto

• Люди и взаимодействие важнее, чем процессы и инструменты.
• Работающее ПО важнее, чем исчерпывающая документация.
• Сотрудничество с заказчиком важнее, чем согласование условий контракта.
• Готовность к изменениям важнее, чем следование первоначальному плану.

12 принципов Agile

1. Задача высшего приоритета — регулярно и как можно раньше удовлетворять потребности заказчика, предоставляя ему программное обеспечение.
2. Учитывать, что требования могут измениться на любом этапе разработки. Если изменения быстро вносятся в проект, заказчик может получить конкурентные преимущества.
3. Выпускать версии готовой программы как можно чаще — с промежутком от двух недель до двух месяцев.
4. Ежедневно вместе работать над проектом — разработчикам и заказчикам.
5. Поручить работу мотивированным профессионалам. Обеспечить поддержку и условия, довериться им — и работа будет сделана.
6. Общаться напрямую — это самый эффективный способ взаимодействия внутри команды и вне ее.
7. Считать главным показателем прогресса работающий продукт.
8. Поддерживать постоянный ритм работы — касается и разработчиков, и заказчиков.
9. Уделять пристальное внимание техническому совершенству и качеству проектирования — это повышает гибкость проекта.
10. Минимизировать лишнюю работу.
11. Стремиться к самоорганизующейся команде — в ней рождаются наиболее эффективные и качественные решения.
12. Всем участникам команды — постоянно искать способы повышать эффективность работы.

Но руководствуясь только этими идеями и принципами, выстроить рабочие процессы нельзя. Поэтому принято считать, что Agile — это класс, в рамках которого существует ряд прикладных методологий.

Инкрементная модель

Данная методология может быть описана, как мультикаскадная модель тестирования ПО. Рабочий процесс разделяется на некоторое количество циклов, каждый из которых также делится на модули. Каждая итерация добавляет определенный функционал к ПО. Инкремент состоит из трех циклов:

1. дизайн и разработка
2. тестирование
3. реализация.

В этой модели  возможна одновременная разработка разных версий продукта. Например, первая версия может проходить этап тестирования в то время, как вторая версия находится на стадии разработки. Третья версия в то же самое время может проходить этап дизайна. Этот процесс может продолжаться до самого завершения проекта.

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

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

Минусы:

Для ведения проектов с Agile подходят далеко не все сервисы или программы для проектного менеджмента, ведь у каждого есть своя специфика.

Если ваш бизнес относится к маркетинг и рекламным, дизайнерским, seo или digital агентствам, то saas-сервис Worksection можно применить для работы всей команды целиком. Нас рекомендуют COXO Digital, Royal ® Advertising и Prozorro.

Вот пара лайфхаков, чтобы настроить Agile в Worksection:

Отказ от традиционных способов тестирования в пользу agile

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

Технический долг, как задолженность по кредитной карте, растущая с процентами, поначалу ощущается как небольшая заноза, но затем быстро приобретает пугающие масштабы и сковывает действия команды, не позволяя ей следовать принципам agile. Чтобы справиться с быстрорастущим техническим долгом, мы в компании даем разработчикам возможность быть главными специалистами по качеству (более того, мы ожидаем этого от них). Мы уверены, что разработчики обладают принципиально важными навыками для обеспечения качества продукта.

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

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

Приложение: инструменты управления гибкой разработкой

Давным-давно возникла такая идея: разработать комплекс эффективных управляющих программ для управления проектами в индустрии разработки программного обеспечения. Причина этой идеи связана с моим собственным опытом. В первые годы, когда я работал над системой **, директор отдела просил меня сделать такой набор вещей на основе Visual Basic и adodb. В то время у меня не было достаточно опыта, видения, и идеи, и я сделал это с мыслями о пробах и исследованиях. Это просто ограничено указанными выше ограничениями, как вы скажете, что вы сделали? Он кажется очень маленьким, потому что нет специального дизайна интерфейса, а дизайн UI не атмосферный.Отдел может реализовать только распределение задач на основе локальной сети, еженедельное написание отчетов и загрузку документов.

1. Leangoo, я узнал об этом инструменте через веб-поиск. Через веб-сайт я зарегистрировал учетную запись, создал новый список продуктов и просмотрел некоторые существующие примеры веб-сайта. Вообще говоря, он объединяет идеи управления гибкой разработкой., Вид ясный и приятный.

2. Teambition, это программное обеспечение, о котором я узнал раньше, и у него есть онлайн-версия и версия приложения. Есть управление задачами, управление часто задаваемыми вопросами и т. Д., Что неплохо, но концепции карточек задач управления гибкостью, канбан, диаграмма выгорания и т. Д.

, Похоже, не отображаются в программном обеспечении. Больше всего меня поразил FAQ, который может иметь какое-то отношение к характеру моей работы. Я лично считаю этот модуль более практичным. Это предыдущая ситуация. Не знаю, есть ли сейчас ревизия.

3. Worktile. В Worktile по умолчанию мы вводим «сообщение» IM. Эта функция мгновенного обмена сообщениями является воплощением коммуникации. В сценарии совместной работы предприятия задача — это начальный результат общения и суть выполняемой работы. Ядро Worktile — это задача.

Спиральная модель

Спиральная модель это методология тестирования ПО, которая основана на инкрементном подходе и прототипировании. Она состоит из четырех этапов:

1. Планирование
2. Анализ рисков
3. Разработка
4. Оценка

Сразу после того, как первый цикл завершен, начинается второй. Тестирование ПО начинается еще на этапе планирования и длится до стадии оценки. Основным преимуществом спиральное модели является то, что первые результаты тестирования появляется незамедлительно после появления результатов тестов на третьем этапе каждого цикла, что помогает гарантировать корректную оценку качества.

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

Читайте подробнее o спиральной модели в предыдущем блог посте.

Темная сторона силы: недостатки agile

Не факт, что программа когда-нибудь будет завершена.

Серьезно. После каждой итерации и у разработчика, и у пользователя будут возникать новые идеи, как сделать продукт еще мощнее и полезнее. Разработка грозит растянуться на годы.

Но если вы планируете долговременное сотрудничество с заказчиком и он готов платить за все время разработки — почему нет?

Пользователь требует все и сразу.

Большинство участников проекта со стороны пользователей могут на ранних этапах сформулировать множество требований к программе и будут ожидать, что все они будут реализованы в ближайших итерациях. Значительная часть требований получит наивысший приоритет — так что разработчику предстоит определять, какие задачи выполнить сейчас, а какие — отложить. А пользователи будут недовольны: они хотят все и сразу.

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

«Золотые пользователи»

Если в обсуждении участвуют несколько заказчиков (пользователей), их вклад в проект часто разномасштабный. Кто-то более внимателен и вносит много предложений, а другой сидит молча. Обсуждение проекта с широким охватом может и вовсе проходить на форуме.

Фактически это приведет к тому, что небольшая группа активистов будет уводить разработку по интересному лично им пути, формировать программу под себя. Мнения других пользователей уйдут в тень.

Строительство без чертежей

Еще одна проблема, на которую обращают внимание критики гибких методик — отсутствие генерального плана, концепции программы, единой структуры. Код такого программного продукта может напоминать небоскреб, который построили без чертежей и плана коммуникаций.

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

С каждой новой итерацией количество «подпорок» нарастает катастрофическими темпами, делая внутреннюю структуру программы нелогичной и малоэффективной. А тестирование на каждом этапе проводится только для вновь созданной или доработанной функциональности. Так что нельзя поручиться, что поправив код в одном месте, не сломаешь в другом.

Постоянная спешка

Ритм работы в Agile не располагает к медитации. Нововведения изобретаются на лету, реализовывать тоже надо быстро, реагировать моментально и действовать оперативно. Нет времени обдумывать все аспекты, неторопливо взвешивать за и против.

Это сказывается на качестве кода: бывает, фрагменты программы пишутся по принципу «и так сойдет», без попыток сделать их более изящными или эффективными. Разработчик осознает, что такой код годится только как временное решение, но вернуться и переписать получается редко. Работает — и хорошо.

До тех пор, пока работает…

Несмотря на критику, гибкая методология разработки успешно используется при создании программных продуктов.