Просто о сложном: agile-разработка | Далее
Изначально аджайл был вотчиной программистов. Так они называли методы разработки ПО, принципиально отличавшиеся от традиционного. Но оказалось, что принципы аджайла с успехом можно применять в самых разных областях. Так аджайл стал философией разработки продукта в целом.
Что было до аджайла
До гибкой разработки все диджитал и IT-компании создавали продукты целиком. Например, в студию обращался заказчик и говорил, что он хочет сайт. Студия отвечала, что не может начать работу без исчерпывающего технического задания. Заказчик вздыхал, садился за бумагу, писал ТЗ на сто страниц, пытаясь по пути не упустить ничего важного. Команда принимала техзадание, закрывалась у себя в студии, работала 2 месяца и показывала результат. После тестирования и правок сайт запускали.
Если в процессе у команды возникала новая идея, которая шла вразрез с техзаданием, ее либо игнорировали, либо возвращались на предыдущие этапы и все переделывали.
В итоге растягивались сроки и бюджет, или получался не такой крутой продукт, как мог бы.
Также стало очевидно, что негибкая разработка не подходит для масштабных проектов: рынок постоянно меняется, технологии устаревают — и часто продукт выходит уже неактуальным.
Agile Manifesto
Со временем разработчики стали тестировать и изменять продукт во время работы. Так появились новые техники, которые назвали гибкими. В 2001 году 17 представителей профессии собрались в горной деревне штата Юта, покатались на лыжах и заодно обсудили свои подходы к разработке.
Итогом встречи стал «Манифест Аджайла», в котором излагались основные принципы, выводы и целая философия гибкого программирования. Сейчас эту философию широко практикуют не только в диджитал-среде, но и в любой другой. Вот 4 основных ее положения:
- Люди и взаимодействие важнее процессов и инструментов.
- Работающий продукт важнее исчерпывающей документации.
- Сотрудничество с заказчиком важнее согласования условий контракта.
- Готовность к изменениям важнее следования первоначальному плану.
То есть разработчики отказались от формализации требований, безоговорочного следования жестким регламентам и планам — в пользу самого продукта, людей и продуктивного сотрудничества. Это была историческая веха.
Как команды работают по аджайлу
Возьмем ту же ситуацию. В студию приходит заказчик и просит сделать сайт. Вместе с командой они записывают все пожелания, идеи и представления о том, что должно получиться в результате. Потом решают, что самое приоритетное, и начинают работу.
Каждый день команда и заказчик обсуждают, что они сделали, какие проблемы возникли, что планируют делать дальше. Если в процессе появляются новые идеи, их рассматривают и внедряют — это может произойти прямо в процессе работы над этапом.
В конце условной недели у них получается каркас проекта с минимумом функций.
Его запускают и тестируют на реальных пользователях, а сами продолжают работать дальше.
Следующий этап повторяет предыдущий с той только разницей, что теперь у команды есть обратная связь от пользователей. Таким образом появляется возможность сразу убрать лишнее и добавить недостающее — ну и параллельно работать над следующими по приоритетности пунктами.
Так повторяется несколько раз, и после тех же двух месяцев у заказчика есть готовый продукт, протестированный и актуальный
Кое-что еще
Все это кажется ужасно заманчивым, однако на практике переключиться на аджайл бывает сложно. У нас привыкли работать по подробному техзаданию, не каждый заказчик захочет общаться с командой каждый день — стоит только начать, и обнаруживается масса препятствий.
Чтобы упростить эту задачу, существуют специальные наборы правил, фреймворки. Например, Скрам и Канбан, которые сейчас на слуху. У каждого своя система и правила, их можно видоизменять, дополнять и адаптировать под команду.
Расскажем об этих подходах как-нибудь в другой раз, а пока суть:
Процесс работы по Scrum: спринты, циклы разработки, standup-митинги
Канбан-доска: карточки перемещаются по колонкам-этапам
Главное, чего стоит опасаться, когда обращаешься в студию, которая заявляет, что работает по аджайлу: за формальным соблюдением правил может стоять все та же традиционная разработка. Обнаружить это на подлете непрофессионалу бывает сложно.
Какому продукту точно нужен аджайл?
Применять аджайл при работе над каждым продуктом нецелесообразно. Скажем, простую промо-страницу можно от и до сделать по техзаданию, и все останутся довольны. Но есть несколько признаков проекта, которому нужна гибкая разработка.
- Большой и технологически сложный. Когда дешевле делать все постепенно и постоянно тестировать, чем переделывать уже готовый продукт.
- Длительный по времени. Чем дольше проект будет функционировать, тем тяжелее представить его развитие — например, интернет-магазин.
- С высокой неопределенностью. Когда проект инновационный, невозможно заранее продумать все функции, проще делать его маленькими рывками и тестировать.
- Когда идей ну очень много и непонятно, какие из них окажутся удачными. Внедрять все сразу — рискованно и экономически неоправданно.
- С идеальным заказчиком. Когда клиент настолько заинтересован в продукте, что хочет сам во всем участвовать. Аджайл — идеальный сценарий.
Если хоть один пункт из этого списка подходит под проект, нужно задуматься об аджайле. Если пунктов несколько, то без него вряд ли получится.
Методологии разработки ПО: Agile | GeekBrains
https://gbcdn.mrgcdn.ru/uploads/post/1863/og_cover_image/6ae757601184e793149f82c869acca51
GeekBrains уже рассказывал о «Водопаде» (Waterfall), на очереди — Agile: познакомимся с этой схемой, по которой организуют работу многие коллективы программистов.
В феврале 2001 года семнадцать человек — крупные IT-специалисты и разработчики — собрались на горном курорте в штате Юта.
Отдохнули, пообщались и составили небольшой документ — Agile-манифест.
Он стал новацией в разработке программного обеспечения и положил начало ряду практических подходов к программированию. Классической методологии «Водопад» пришлось потесниться.
Гибкость во всем
С английского agile переводится как «подвижный, быстрый, проворный». Но в русской IT-лексике за этой группой методологий закрепилось определение «гибкие». Agile-подход динамично организует программирование, постоянно адаптируя проект к новым обстоятельствам и требованиям.
Не углубляясь в детали, вспомним, как устроена разработка по методологии Waterfall:
- Выдвигаются требования к ПО, разрабатывается техническое задание (ТЗ).
- Поставленные задачи воплощаются в коде.
- Выполняется тестирование.
- Готовое ПО внедряется в работу.
Теоретически в Waterfall возможен возврат на предыдущие ступени — например, если оказывается, что ту или иную задачу невозможно выполнить по техническим причинам.
В этом случае ТЗ пересматривают, но это скорее чрезвычайная ситуация. В норме конечный продукт должен идеально соответствовать требованиям, целям и задачам, которые были сформулированы до разработки.
В Agile-методологии в приоритете не исходные установки, а актуальные потребности пользователя. Постоянно вносить изменения в ТЗ, даже в самый разгар разработки, для Agile нормально. В гибкой методологии не предусмотрен предварительный генеральный план — напротив, программный продукт пишется практически экспромтом.
Разработка проходит через ряд циклов — итераций. Каждая итерация — это фактически отдельный проект, где разрабатывают фрагмент программы, улучшают функциональность, добавляют новые возможности.
Чтобы понять, как это работает, представим коллектив разработчиков, создающих аудиоплеер. Уже написан костяк программного кода: интерфейс и базовый функционал. Программа умеет воспроизводить файлы формата MP3, WAV и OGG. Но пользователи предлагают добавить проигрывание CD-дисков и подключить горячие клавиши, чтобы быстро управлять плеером.
Начинается новая итерация разработки. Коллеги-программисты собираются на короткое совещание: обсуждают задачи, распределяют их и вырабатывают способы решения. Один из разработчиков предлагает добавить воспроизведение онлайн-радио.
Следующий этап — разработка — может занять от нескольких дней до недель. Создается программный код, интегрируется в продукт, выполняется тестирование. Когда новая функциональность полностью готова к работе, компилируется очередная версия программы и исполняемый файл отправляется к пользователям.
На этом итерация завершается — и начинается новый виток разработки.
Идеи и принципы
Четыре центральных идеи Agile Manifesto
- Люди и взаимодействие важнее, чем процессы и инструменты.
- Работающее ПО важнее, чем исчерпывающая документация.
- Сотрудничество с заказчиком важнее, чем согласование условий контракта.
- Готовность к изменениям важнее, чем следование первоначальному плану.
12 принципов Agile
- Задача высшего приоритета — регулярно и как можно раньше удовлетворять потребности заказчика, предоставляя ему программное обеспечение.
- Учитывать, что требования могут измениться на любом этапе разработки. Если изменения быстро вносятся в проект, заказчик может получить конкурентные преимущества.
- Выпускать версии готовой программы как можно чаще — с промежутком от двух недель до двух месяцев.
- Ежедневно вместе работать над проектом — разработчикам и заказчикам.
- Поручить работу мотивированным профессионалам. Обеспечить поддержку и условия, довериться им — и работа будет сделана.
- Общаться напрямую — это самый эффективный способ взаимодействия внутри команды и вне ее.
- Считать главным показателем прогресса работающий продукт.
- Поддерживать постоянный ритм работы — касается и разработчиков, и заказчиков.
- Уделять пристальное внимание техническому совершенству и качеству проектирования — это повышает гибкость проекта.
- Минимизировать лишнюю работу.
- Стремиться к самоорганизующейся команде — в ней рождаются наиболее эффективные и качественные решения.
- Всем участникам команды — постоянно искать способы повышать эффективность работы.
Но руководствуясь только этими идеями и принципами, выстроить рабочие процессы нельзя. Поэтому принято считать, что Agile — это класс, в рамках которого существует ряд прикладных методологий.
Scrum
Вообще-то Scrum появился еще до того, как сформировался манифест Agile. Но его принципы хорошо укладываются в концепцию гибкой методологии, поэтому принято причислять его к этому семейству.
Впервые термин прозвучал в 1986 году.
Японские исследователи Икуджиро Нонака и Хиротака Такеучи в статье The new New product development game сформулировали принципы, позволяющие быстрее создавать новый продукт. Среди условий такой разработки назвали самоорганизующуюся команду специалистов, их полную свободу в творчестве и работе — без ограничений со стороны топ-менеджмента. Этот подход авторы описали так:
«Это как оставить всех сотрудников на втором этаже и убрать лестницу, а потом сказать: прыгайте или делайте что угодно — решение за вами. Экстремальные условия рождают творческий подход!»
Руководство ставит перед командой задачу и, возможно, сообщает сроки, но не дает конкретных указаний — рабочая группа самостоятельно ищет решение.
Главное для Scrum-подхода — особая динамика работы, когда команда постоянно обсуждает, как сделать продукт лучше. Такой ритм авторы сравнивают с регби: игроки передают мяч друг другу, но при этом команда движется по полю как единое целое, достигая общей цели. Из регби и пришел термин «скрам» — это схватка из-за мяча.
Методика, предложенная Нонака и Такеучи, нашла применение в IT-сфере, разработке инженерных решений в машиностроении, электронике. В 90-х Scrum оформился как проработанная и цельная методология, оброс конкретными приемами, помогающими с нуля наладить работу команды. Благодаря Кену Шваберу и Джеффу Сазерленду Scrum пришел в IT и приобрел популярность среди разработчиков — некоторые даже считают эту методологию революционной.
Командный дух
В команде, работающей по принципам Scrum, нет внутренней иерархии: ни руководителей, ни подчиненных, ни указаний-приказов. Есть два особых члена группы: product owner — владелец продукта, и scrum master — скрам-мастер.
Product owner лучше всех знает, каким должен быть продукт. Зачастую это заказчик, его представитель или сотрудник, ответственный за взаимодействие с клиентом. Он должен ясно понимать, что именно требуется конечному пользователю программы. Все пожелания и предложения по функциональности и внешнему виду продукта (в Scrum они называются stories — истории) он заносит в специальный список — Product Backlog.
Бэклог формируется до старта разработки и по ходу постоянно пополняется. Здесь же указывают приоритеты доработок.
На скрам-мастере лежит ответственность за сплоченную работу коллектива. Он не начальник команды, но делает все возможное, чтобы разработка шла в постоянном темпе, каждый участник был вовлечен и мотивирован, а важные детали не оставались без внимания.
Рывок! Еще рывок!
Работа над программой в Scrum, как и в Agile в целом, разделена на итерации. Здесь любят спортивную терминологию: эти отрезки разработки называют забегами или спринтами. Каждый начинается с того, что команда сообща определяет, какие именно истории из списка владельца продукта она сможет реализовать на этом спринте. Выбранные идеи переносятся в отдельный список — sprint backlog. Фиксируется цель: что конкретно команда сможет продемонстрировать пользователю в итоге. Задачи распределяют, и начинается забег.
Как и на матче регби, в скрам-разработке ситуация меняется быстро: пользователь может передумать или изменить требования, а Agile трепетно относится к его пожеланиям.
Поэтому скрам-мастер собирает короткие ежедневные совещания — скрамы. Каждый участник рассказывает о своих успехах и неудачах, остальные могут предложить новые пути решения проблем. Задачи корректируются, спринт продолжается.
В конце забега результаты демонстрируют владельцу продукта. И немедленно начинают новый спринт — очередную итерацию цикла разработки.
Важно помнить, что в итоге скрам-забега пользователь получает готовую версию программы: можно запускать и работать. На ранних этапах проекта программа может быть способна только вывести сообщение «Hello, world!». Но даже самый первый спринт должен дать результат: программа уже есть и она запускается.
XP — программируем экстремально!
Речь не о Windows XP. Под этой аббревиатурой скрывается еще одна методология из класса Agile: eXtreme Programming — экстремальное программирование. Ее придумал разработчик Кент Бек, развивали Уорд Каннингем, Мартин Фаулер и другие. Это набор простых принципов и практик, которые помогают наладить эффективную работу.
Экстремальное программирование не предлагает разработчикам писать код, сидя в бассейне с пираньями, или отлаживать его, скатываясь с горы. Авторы методологии делают интенсивнее приемы обычного программирования, чтобы повысить их продуктивность.
Вспомним, как работает классический разработчик. Он тщательно продумывает, планирует, а затем пишет фрагмент программы — работающий блок или функцию. Тестирует ее, отлавливает баги, устраняет их, снова проверяет и исправляет… Потом передает завершенный код на проверку тестировщикам или коллегам-программистам. Когда накапливаются изменения, их сводят воедино и создают работающую версию программы.
В экстремальном программировании все эти принципы доведены до предела. Нет времени объяснять — нужно делать! Планируют на короткий срок. Итерации разработки максимально сжатые. Чем быстрее выйдет рабочая версия — тем лучше. Реализуется самое простое из решений, а код пишется и тестируется параллельно.
Экстремальные практики
Как и в других Agile-методологиях, в XP чем итерации короче, тем лучше.
Если доработку можно выполнить за один день — нужно так и сделать. Но вряд ли пользователю захочется ежедневно обновлять версию своей рабочей программы. Максимальный срок в XP — месяц. Так что в среднем итерация длится две недели.
В начале каждого цикла разработчики устраивают общее собрание — представителя заказчика тоже приглашают. Совместно решают, какую функциональность будут реализовать. За основу берутся пользовательские истории — то есть задачи и требования — с учетом их значимости.
Важное условие в XP — реализуется самое простое из возможных рабочих решений и его исполнений, соответствующих заданным условиям. Не создается лишнего: никаких «примочек на будущее», которые могут понадобиться позже, но не нужны прямо сейчас. На последующих этапах функциональность решения можно расширить и доработать, но об этом разработчик будет думать, когда потребуется.
Есть риск: примитивное техническое решение, которое успешно работало на первых порах, может стать проблемой, когда программа начнет развиваться и потребуется более продвинутая функциональность.
Это может показаться минусом технологии: XP не любит планировать на отдаленную перспективу, предпочитая оперативно перестраиваться на ходу. Но на практике редко возникают ситуации, когда работающий код надо переписать с нуля. Их смогут предвидеть опытные профессионалы, которые работают в agile-командах.
Вопросы такого порядка решает и рефакторинг — еще одна практика экстремального программирования. Суть — регулярно пересматривать и улучшать код, а цель — сделать программу быстрее и надежнее. Разработчики убирают задвоенные фрагменты кода, упрощают его, приводят к единым стандартам проекта.
Другая полезная практика — постоянная коллективная работа. XP подразумевает тесное сотрудничество и взаимопомощь. Разработку ведут в группах по десять человек, которые активно обмениваются информацией. Практикуется парное программирование: один разработчик создает модуль, второй наблюдает.
Парное программирование — одна из полезных практик XP
Может показаться, что подход расточительный: фактически получается, что программисты напишут в два раза меньше кода, чем если бы каждый работал над своим фрагментом программы.
И исследования показывают, что парное программирование продвигается на 15 % медленнее, чем аналогичная разработка одним специалистом.
Но есть и преимущества. Недочеты устраняются на самом раннем этапе — фактически еще до того, как модуль будет впервые запущен. Напарник может подсказать полезный прием или предложить более простой и эргономичный способ решения задачи — то есть рефакторинг идет сразу за созданием кода. По данным исследований, при работе вдвоем ошибок становится на 60 % меньше. И сохраняется преемственность кода — не возникнет ситуация, когда «только Вася знает, как работает эта функция, а он в отпуске».
Принципиально, что код — общее достояние команды. Никто не может единолично знать модуль программы или владеть им.
Поэтому важна стандартизация кодирования, единообразное оформление: соблюдать правила именования переменных и классов, использовать одни приемы программирования.
XP требует постоянной интеграции кода, то есть регулярного и частого обмена написанными и отлаженными модулями.
Части программы могут быть взаимозависимы, и чтобы исключить внутреннюю несовместимость, у всех участников проекта должен быть доступ к самым актуальным версиям модулей.
Переработку XP не поощряет: требует от программистов неукоснительно соблюдать рамки 40-часовой рабочей недели. Никаких «я только допишу эту функцию»! Если не умеете переключаться и отдыхать — скоро не сможете и продуктивно работать.
Экстремально — не значит плохо
Если правильно применять практики экстремального программирования, эта методика обеспечивает эффективное взаимодействие всех сотрудников, обмен опытом и стабильный рост профессионального мастерства, высокую продуктивность.
Есть и подводные камни: практики XP требуют конкретных навыков и твердой самодисциплины. При парном программировании важна вовлеченность обоих разработчиков и взаимное уважение. Если один считает себя мастером, а напарника — новичком, не прислушивается к советам и не снисходит до объяснений, пользы от такого сотрудничества не будет.
Напарник, который не отслеживает код, а занимается своими делами, тоже ставит крест на парном программировании. Суть практики в том, чтобы работать вместе — передавая клавиатуру, устраивая мозговые штурмы, обмениваясь мнениями.
Экстремальное программирование не предписывает, как действовать в конкретной ситуации. Если решение задачи для всех очевидно и написать код не составит труда — нет реальной необходимости в парном программировании. Если на часах 18:00, а вам осталось дописать двадцать строк кода — можно не откладывать на завтра. Методология не заменяет здравый смысл!
Никакого волшебства
Гибким методологиям приписывают невероятные достижения и чудодейственные свойства решать любые проблемы разработки. Но в действительности ничего фантастического в них нет. Это хорошие инструменты: если ими грамотно пользоваться, они могут сделать рабочие процессы быстрыми и эффективными, а еще мотивировать членов команды трудиться творчески и развиваться.
Agile-методологии предъявляют высокие требования к профессионализму, квалификации и настрою специалистов.
Важна сплоченность коллектива, взаимное уважение и обмен опытом. Экстремальные практики не научат плохого программиста гениально кодить, Scrum не поможет конфликтному специалисту влиться в коллектив.
Вы можете сказать, что уже работали по похожей схеме, хоть и не знали об Agile. Для разработчика естественно писать код небольшими фрагментами, время от времени собираясь с коллегами у кофейного автомата, чтобы обменяться мнениями и информацией. Разумно разбивать разработку на итерации, в ходе которых устранять баги и добавлять фичи, а в конце выкатывать новую версию. В этом прелесть методологий Agile: они интуитивно понятны и близки каждому программисту.
Преимущества Agile
- Программный продукт готов к использованию на самых ранних этапах его разработки, пусть и не с полной функциональностью.
- Разработчики постоянно в контакте с заказчиком и пользователем и всегда знают, что именно требуется от программы, могут оперативно реагировать на новые потребности пользователя и пожелания к продукту.
- Нет жестких рамок, поэтому программный продукт постоянно изменяется и улучшается, становится эффективнее и привлекательнее для пользователя.
Заказчик и пользователь в этой схеме выступают не столько как инвесторы, сколько как партнеры и идейные вдохновители. И это оправдано — не всегда программист ясно представляет, что именно хочет получить пользователь. Но и он, далекий от разработки, понятия не имеет о возможностях, которые может получить с помощью программы, какие процессы можно автоматизировать и на каком уровне. Объединив усилия и общаясь, пользователь и разработчик способны создать продукт, превосходящий аналоги по эффективности и эргономичности.
Нет заранее и подробно сформулированного технического задания — значит, разработчик может решить задачу творчески. Но не слишком — пользователь не позволит ему оторваться от реальности и наплодить ненужного кода. Каждый фрагмент программы будут обсуждать и продумывать совместно.
Темная сторона силы: недостатки Agile
Не факт, что программа когда-нибудь будет завершена.
Серьезно. После каждой итерации и у разработчика, и у пользователя будут возникать новые идеи, как сделать продукт еще мощнее и полезнее. Разработка грозит растянуться на годы.
Но если вы планируете долговременное сотрудничество с заказчиком и он готов платить за все время разработки — почему нет?
Пользователь требует все и сразу.
Большинство участников проекта со стороны пользователей могут на ранних этапах сформулировать множество требований к программе и будут ожидать, что все они будут реализованы в ближайших итерациях. Значительная часть требований получит наивысший приоритет — так что разработчику предстоит определять, какие задачи выполнить сейчас, а какие — отложить. А пользователи будут недовольны: они хотят все и сразу.
Работа над проектом требует не только профессионализма разработчика, но и сознательности пользователя. А спросите у программистов, часто ли им встречались адекватные, понимающие пользователи.
«Золотые пользователи»
Если в обсуждении участвуют несколько заказчиков (пользователей), их вклад в проект часто разномасштабный.
Кто-то более внимателен и вносит много предложений, а другой сидит молча. Обсуждение проекта с широким охватом может и вовсе проходить на форуме.
Фактически это приведет к тому, что небольшая группа активистов будет уводить разработку по интересному лично им пути, формировать программу под себя. Мнения других пользователей уйдут в тень.
Строительство без чертежей
Еще одна проблема, на которую обращают внимание критики гибких методик — отсутствие генерального плана, концепции программы, единой структуры. Код такого программного продукта может напоминать небоскреб, который построили без чертежей и плана коммуникаций. Решения о нововведениях принимаются буквально на ходу, о долговременном планировании и речь не идет. В результате оказывается, что уже реализованные участки кода не вписываются в архитектуру, которую подразумевает новая функциональность. Их приходится дорабатывать и добавлять «костыли», а то и переделывать.
С каждой новой итерацией количество «подпорок» нарастает катастрофическими темпами, делая внутреннюю структуру программы нелогичной и малоэффективной.
А тестирование на каждом этапе проводится только для вновь созданной или доработанной функциональности. Так что нельзя поручиться, что поправив код в одном месте, не сломаешь в другом.
Постоянная спешка
Ритм работы в Agile не располагает к медитации. Нововведения изобретаются на лету, реализовывать тоже надо быстро, реагировать моментально и действовать оперативно. Нет времени обдумывать все аспекты, неторопливо взвешивать за и против.
Это сказывается на качестве кода: бывает, фрагменты программы пишутся по принципу «и так сойдет», без попыток сделать их более изящными или эффективными. Разработчик осознает, что такой код годится только как временное решение, но вернуться и переписать получается редко. Работает — и хорошо.
До тех пор, пока работает…
Несмотря на критику, гибкая методология разработки успешно используется при создании программных продуктов.
Кому подойдет Agile
Методологии класса Agile хорошо себя покажут, если:
- В вашей команде работают опытные и квалифицированные специалисты, умеющие действовать сообща и помогать друг другу.
- У заказчика нет ясного представления, как должна выглядеть программа, но он готов участвовать в совместной работе, чтобы развивать и улучшать продукт.
- Сфера применения продукта постоянно меняется, часто возникают новые потребности и задачи.
- Нет конкретных сроков, к которым продукт должен быть завершен, и жестких ограничений бюджета.
- Работоспособную программу необходимо получить как можно скорее.
Такие условия могут сложиться, например, при работе над стартапом. Он подразумевает инновации в конкретной области, и важно успеть занять нишу, выдав работающий продукт. При этом нет долгосрочных прогнозов о том, в каком направлении будет развиваться проект.
Больше методологий богу методологий!
Мы рассмотрели Scrum и XP, но класс Agile включает и другие методологии. Есть любопытные подходы и вне Waterfall и Agile. Продолжим в следующей статье.
Глоссарий и терминология Agile | Agile Alliance
Все термины глоссария
Разработка через приемочное тестирование (ATDD) включает в себя членов команды с разными точками зрения (клиент, разработка, тестирование), которые совместно пишут приемочные тесты до реализации соответствующих функций.
(подробнее)
Приемочное испытание — это формальное описание поведения программного продукта, обычно выраженное в виде примера или сценария использования. Для таких примеров или сценариев был предложен ряд различных обозначений и подходов. Во многих случаях цель состоит в том, чтобы можно было автоматизировать выполнение таких тестов с помощью программного инструмента, либо специального для команды разработчиков, либо имеющегося в наличии. (узнать больше)
Антипаттерны — это распространенные решения общих проблем, решение которых неэффективно и может привести к нежелательным последствиям. (подробнее)
В контексте разработки программного обеспечения под сборкой понимается процесс, который преобразует файлы и другие активы, находящиеся под ответственностью разработчиков, в программный продукт в его окончательной или готовой форме. Сборка автоматизирована, если эти шаги повторяемы, не требуют прямого вмешательства человека и могут быть выполнены в любое время без какой-либо информации, кроме той, которая хранится в репозитории управления исходным кодом.
(узнать больше)
⇑ наверх
Уточнение невыполненной работы (ранее называвшееся «Уход за невыполненной работой») — это когда владелец продукта и некоторые или все остальные члены команды регулярно уточняют невыполненную работу, чтобы убедиться, что в ней содержатся соответствующие элементы, которые они расставлены по приоритетам, и что элементы в верхней части очереди готовы к доставке. (подробнее)
BDD — это практика, при которой члены команды обсуждают ожидаемое поведение системы, чтобы сформировать общее понимание ожидаемой функциональности. (узнать больше)
Диаграммы выгорания и диаграммы выгорания отслеживают объем выходных данных (в часах, баллах или элементах невыполненной работы), выполненных командой за итерацию или проект. (подробнее)
Гибкость бизнеса — это способность организации ощущать изменения внутри или снаружи и реагировать соответствующим образом, чтобы приносить пользу своим клиентам. (подробнее)
⇑ наверх
Коллективное владение кодом – это явное соглашение, согласно которому каждый член команды может вносить изменения в любой файл кода по мере необходимости: либо для выполнения задачи разработки, либо для устранения дефекта, либо для улучшения кода.
общая структура. (узнать больше)
Непрерывное развертывание направлено на сокращение времени, прошедшего между написанием строки кода и предоставлением доступа к этому коду пользователям в рабочей среде. Чтобы обеспечить непрерывное развертывание, команда полагается на инфраструктуру, которая автоматизирует и инструментирует различные шаги, ведущие к развертыванию, так что после каждой интеграции, успешно отвечающей этим критериям выпуска, работающее приложение обновляется новым кодом. (подробнее)
Непрерывная интеграция — это практика объединения изменений кода в общий репозиторий несколько раз в день с целью выпуска версии продукта в любой момент. Для этого требуется воспроизводимая и автоматизированная процедура интеграции. (узнать больше)
Карточки Class Responsibility Collaborator (CRC) — это метод объектно-ориентированного проектирования, который команды могут использовать для обсуждения того, что класс должен знать и делать, а также с какими другими классами он взаимодействует.
(см. подробнее)
Развитие клиентов — это четырехступенчатая структура, которая позволяет использовать научный подход для проверки предположений о вашем продукте и бизнесе. (узнать больше)
⇑ наверх
Ежедневное совещание является одним из наиболее часто применяемых Agile-методов и дает команде возможность регулярно собираться вместе для координации своей деятельности. (узнать больше)
Определение «выполнено» — это согласованный список действий, которые считаются необходимыми для доведения приращения продукта, обычно представленного пользовательской историей, до состояния «выполнено» к концу спринта. (подробнее)
Определение готовности включает в себя создание четких критериев, которым должна соответствовать пользовательская история, прежде чем она будет принята в следующую итерацию. Обычно это основано на матрице INVEST. (подробнее)
⇑ наверх
Эпопея — это большая пользовательская история. (подробнее)
В разработке программного обеспечения «оценка» — это оценка усилий, необходимых для выполнения данной задачи разработки; это чаще всего выражается в терминах продолжительности.
(узнать больше)
Исследовательское тестирование — это больше, чем строго говоря «практика», стиль или подход к тестированию программного обеспечения, который часто противопоставляется «тестированию по сценарию». (подробнее)
Экстремальное программирование (XP) — это гибкая среда разработки программного обеспечения, целью которой является создание программного обеспечения более высокого качества и повышение качества жизни команды разработчиков. XP является наиболее конкретной из гибких сред в отношении соответствующих инженерных методов разработки программного обеспечения. (подробнее)
⇑ наверх
Фасилитатор — это человек, который выбирает или получает явную роль ведения собрания. (подробнее)
Agile-команда часто передает свой продукт в руки конечных пользователей, прислушиваясь к отзывам, как критическим, так и благодарным. (подробнее)
⇑ наверх
Формула «Дано-Когда-Тогда» представляет собой шаблон, предназначенный для руководства по написанию приемочных тестов для Пользовательской истории: (Дано) какой-то контекст, (Когда) выполняется какое-то действие, (Тогда) должен получиться определенный набор наблюдаемых следствий..jpg)
(узнать больше)
⇑ наверх
В контексте Agile инкрементальная разработка — это когда можно использовать каждую последующую версию продукта, и каждая из них основывается на предыдущей версии, добавляя видимые пользователю функции. (подробнее)
«Излучатель информации» — это термин, обозначающий любой из ряда визуальных дисплеев, которые команда размещает на видном месте, чтобы все члены команды могли сразу видеть самую свежую информацию. (см. подробнее)
«Интеграция» (или «интеграция») относится к любым усилиям, которые по-прежнему необходимы проектной группе для выпуска продукта, пригодного для выпуска в виде функционального целого. (узнать больше)
Аббревиатура INVEST означает набор критериев, используемых для оценки качества пользовательской истории. Если история не соответствует одному из этих критериев, команда может переформулировать ее. (подробнее)
Итерация — это временной интервал, в течение которого происходит разработка. Продолжительность может варьироваться от проекта к проекту и обычно является фиксированной.
(подробнее)
Agile-проекты являются итеративными, поскольку они намеренно позволяют «повторять» действия по разработке программного обеспечения и потенциально «пересматривать» одни и те же рабочие продукты (иногда используется фраза «запланированная доработка»; хорошим примером является рефакторинг) . (узнать больше)
⇑ наверх
Канбан-метод — это средство проектирования, управления и улучшения потока для работы с знаниями, которое позволяет командам начинать с того места, где они есть, для осуществления эволюционных изменений. (подробнее)
Канбан-доска — это визуальный инструмент рабочего процесса, состоящий из нескольких столбцов. Каждый столбец представляет отдельный этап рабочего процесса. (подробнее)
⇑ наверх
Время выполнения — это время между заказом клиента и доставкой. В разработке программного обеспечения это также может быть время между предъявлением требования и его выполнением. (узнать больше)
⇑ наверх
Ретроспектива вех — это подробный анализ командой важных событий проекта по прошествии определенного периода времени или по завершении проекта.
(подробнее)
Минимальная рыночная функция — это небольшая автономная функция, которую можно быстро разработать и которая представляет значительную ценность для пользователя. (подробнее)
Минимально жизнеспособный продукт — это, как сказал Эрик Райс, «версия нового продукта, которая позволяет команде собрать максимальное количество подтвержденных данных о клиентах с наименьшими усилиями». (узнать больше)
Мобильное программирование — это подход к разработке программного обеспечения, при котором вся команда работает над одним и тем же, в одно и то же время, в одном месте и на одном компьютере. (см. подробнее)
Мок-объекты (обычно используемые в контексте создания автоматизированных модульных тестов) состоят из создания экземпляров тестовой версии программного компонента. (подробнее)
⇑ наверх
Календарь Нико-нико обновляется ежедневно с учетом настроения каждого члена команды в этот день. С течением времени календарь выявляет закономерности изменения настроения команды или отдельных ее членов.
(узнать больше)
⇑ наверх
На встречах, мероприятиях или конференциях Open Space участники создают и управляют своей собственной программой параллельных сессий по определенной теме. (подробнее)
⇑ наверх
Парное программирование состоит из двух программистов, использующих одну рабочую станцию (один экран, клавиатура и мышь среди пары). (подробнее)
Персонажи — это синтетические биографии вымышленных пользователей будущего продукта. (подробнее)
Подход к оценке, используемый Agile-командами. Каждый член команды «разыгрывает» карточку с числовым значением, соответствующим баллу за пользовательскую историю. (узнать больше)
Agile-команды обычно предпочитают выражать оценки в единицах, отличных от проверенных временем «человеко-часов». Возможно, самая распространенная единица — это «очки истории». (подробнее)
Бэклог продукта — это список новых функций, изменений в существующих функциях, исправлений ошибок, изменений инфраструктуры или других действий, которые команда может выполнить для достижения определенного результата.
(подробнее)
Владелец продукта — это роль, созданная Scrum Framework и отвечающая за то, чтобы команда достигла желаемого результата. (узнать больше)
Краткое изложение ключевых факторов успеха проекта, отображаемое на одной из стен комнаты команды в виде листа бумаги размером с флипчарт. (подробнее)
⇑ наверх
Когда выбор «простого дизайна» имеет далеко идущие последствия, два или более разработчиков встречаются для быстрого сеанса проектирования у доски. (подробнее)
⇑ наверх
Рефакторинг заключается в улучшении внутренней структуры исходного кода существующей программы при сохранении ее внешнего поведения. (узнать больше)
Относительная оценка состоит из оценки задач или пользовательских историй путем сравнения или группировки элементов одинаковой сложности. (подробнее)
Команда регулярно встречается, чтобы обсудить наиболее значимые события, произошедшие со времени предыдущей такой встречи, и определить возможности для улучшения.
(подробнее)
Правила простоты — это набор критериев в порядке приоритета, предложенный Кентом Беком для оценки того, является ли исходный код «достаточно простым». (подробнее)
⇑ наверх
Scrum — это процессная структура, используемая для управления разработкой продукта и другой информационной работы. (подробнее)
Scrumban — это смесь Scrum и Kanban.
Чтобы узнать больше о Scrumban, см. этот пост, написанный создателем метода Scrumban Кори Ладасом.
Скрам-мастер отвечает за то, чтобы команда придерживалась agile-ценностей и принципов и следовала практикам, которые команда согласилась использовать. (подробнее)
Техника масштабирования Scrum до больших групп (более десятка человек), состоящая из разделения групп на Agile-команды по 5–10 человек. (подробнее)
Члены группы Agile-разработчиков обычно сами выбирают, над какими задачами работать, а не получают задание от менеджера. (подробнее)
Команда, использующая практику «простого проектирования», основывает свою стратегию разработки программного обеспечения на наборе принципов «простого проектирования».
(подробнее)
Бэклог спринта — это подмножество бэклога продукта, которое команда должна выполнить в течение спринта, чтобы достичь цели спринта и добиться прогресса в достижении желаемого результата. (узнать больше)
Планирование спринта — это событие, происходящее в начале спринта, когда команда определяет элементы незавершенной работы над продуктом, над которыми они будут работать в течение этого спринта. (подробнее)
Картирование историй состоит из упорядочения пользовательских историй по двум независимым измерениям. (подробнее)
Разделение состоит в разбиении одной пользовательской истории на более мелкие, при этом сохраняется свойство, заключающееся в том, что каждая пользовательская история в отдельности имеет измеримую ценность для бизнеса. (см. подробнее)
Команда стремится к такому темпу работы, который они могли бы поддерживать в течение неопределенного времени. (узнать больше)
⇑ наверх
Самая простая форма доски задач разделена на три столбца с пометками «Сделать», «Выполняется» и «Готово».
Карточки размещаются в столбцах, чтобы отразить текущий статус этой задачи. (подробнее)
«Разработка через тестирование» — стиль программирования, в котором тесно переплетаются три действия: кодирование, тестирование (в виде написания модульных тестов) и проектирование (в виде рефакторинга). (см. подробнее)
«Команда» в Agile-понятии – это небольшая группа людей, назначенных для одного и того же проекта или задачи, почти все они работают полный рабочий день. (узнать больше)
Команда (в идеале вся команда, включая владельца продукта или эксперта в предметной области) может использовать выделенное пространство на время проекта, отделенное от деятельности других групп. (см. подробнее)
«Карта, Разговор, Подтверждение» — это формула, которая фиксирует компоненты пользовательской истории. (см. подробнее)
Three amigos относится к основным точкам зрения для изучения части работы до, во время и после разработки. Этими перспективами являются Бизнес, Разработка и Тестирование.
(узнать больше)
Ежедневная встреча строится вокруг одного из вариантов следующих трех вопросов: Что вы выполнили? Что вы будете делать дальше? Что мешает вам? (подробнее)
Временной интервал — это предварительно согласованный период времени, в течение которого человек или команда неуклонно работают над достижением какой-либо цели. (подробнее)
⇑ наверх
Стремление использовать терминологию данной области бизнеса не только в обсуждениях требований к программному сам исходный код». (узнать больше)
Модульный тест — это короткий фрагмент программы, написанный и поддерживаемый разработчиками из группы продукта, который проверяет некоторую узкую часть исходного кода продукта и проверяет результаты. (подробнее)
Юзабилити-тестирование — это эмпирический исследовательский метод, позволяющий ответить на такие вопросы, как «как конечный пользователь отреагирует на наше программное обеспечение в реальных условиях?» (подробнее)
По согласованию с заказчиком или владельцем продукта команда делит работу, которую необходимо выполнить, на функциональные этапы, называемые «пользовательские истории».
(узнать больше)
Шаблон пользовательской истории является одним из наиболее часто рекомендуемых вспомогательных средств для написания пользовательских историй: Как… Я хочу… Чтобы… (см. подробнее)
⇑ наверх
В конце каждой итерации команда добавляет оценить усилия, связанные с пользовательскими историями, которые были завершены во время этой итерации. Эта сумма называется скоростью. (подробнее)
Контроль версий не является строго Agile-практикой, поскольку в настоящее время он широко распространен в отрасли в целом. Но он упоминается здесь по нескольким причинам. (узнать больше)
⇑ наверх
Экстремальное программирование (XP) — это гибкая среда разработки программного обеспечения, целью которой является создание программного обеспечения более высокого качества и повышение качества жизни команды разработчиков. XP является наиболее конкретной из гибких сред в отношении соответствующих инженерных методов разработки программного обеспечения. (подробнее)
⇑ наверх
Что такое Agile-разработка и почему это важно?
Что такое Agile-разработка и почему это важно? | OpenTextПерейти к основному содержанию Перейти к нижнему колонтитулу
- Доставка приложений
Обзор
Каждый день мы используем программное обеспечение и приложения, чтобы планировать поездки, заказывать еду и играть в игры.
Но подумали ли вы о времени, усилиях и ресурсах, необходимых для создания программного обеспечения от начала до конца?
Программное обеспечение, даже на самом базовом уровне, является сложным. Поэтому успешные разработчики программного обеспечения должны использовать такие системы управления проектами, как Agile, чтобы упростить весь процесс и создать идеальное приложение.
Но как работает Agile-разработка и какие этапы входят в этот процесс? В этой статье мы расскажем все, что вам нужно знать об Agile-разработке программного обеспечения.
Гибкая разработка
Что такое гибкая методология разработки?
Гибкая разработка — это методология управления проектами, в которой люди и взаимодействие ценятся выше процессов и инструментов. Манифест Agile, созданный в 2001 году, описывает четыре основные ценности и двенадцать принципов Agile-разработки.
Четыре ценности Agile позволяют взглянуть изнутри на то, на чем основана методология:
- Люди и взаимодействие важнее процессов и инструментов
- Рабочее программное обеспечение поверх исчерпывающей документации
- Сотрудничество с клиентами в ходе переговоров по контракту
- Реагирование на изменения согласно плану
Другими словами, Agile-разработка фокусируется на быстром создании работающего программного обеспечения, частом сотрудничестве с клиентами и способности легко адаптироваться к изменениям.
Эта методология особенно полезна для проектов, которые являются сложными или имеют неопределенные требования.
Kellogg’s — развертывает OpenText™ ALM Octane
Как работает Agile-разработка?
Теперь, когда мы знаем основы Agile-разработки, давайте более подробно рассмотрим, как это работает. Мы можем разбить процесс Agile на три основных этапа:
- Подготовка
- Планирование спринта
- Спринт
На этапе подготовки владелец продукта создает список функций, которые он хочет включить в конечный продукт. Это известно как отставание продукта. Затем команда разработчиков оценивает, сколько времени потребуется для создания каждой функции.
На совещании по планированию спринта команда решает, над какими функциями из бэклога продукта они будут работать в течение спринта.
Спринт — это установленный период (обычно две недели), в течение которого команда разработчиков должна достичь определенной цели. Команда также решает, сколько заданий каждого типа они могут выполнить в течение спринта.
Например, команда может решить, что в течение спринта они могут выполнить три задачи по кодированию, две задачи по тестированию и одну задачу по документации. Затем эта информация добавляется в журнал спринта.
3. Спринт Во время спринта команда работает над выполнением задач в бэклоге спринта. Они также могут столкнуться с новыми проблемами для решения. Если это произойдет, они добавят эти проблемы в бэклог продукта и соответствующим образом расставят их по приоритетам. В конце спринта команда разработчиков должна завершить все функции в бэклоге спринта.
Если нет, команда перенесет их на следующий спринт. Затем команда проводит совещание по обзору спринта, на котором демонстрирует реализованные функции владельцу продукта и заинтересованным сторонам. Они также обсуждают, что было хорошо во время спринта и как они могли бы улучшить следующий спринт.
Наконец, команда проводит ретроспективное совещание, на котором они размышляют о том, что было хорошо, а что не очень хорошо во время спринта. Затем они создают план действий для решения этих проблем в будущих спринтах. Эта петля обратной связи помогает гарантировать, что каждый спринт будет более успешным, чем предыдущий.
Почему Agile-разработка важна?
Гибкая разработка важна, потому что она помогает командам разработчиков выполнять проекты вовремя и в рамках бюджета. Это также помогает улучшить общение между командой разработчиков и владельцем продукта.
Кроме того, методология гибкой разработки может помочь снизить риски, связанные со сложными проектами.
Это позволяет командам разработчиков быстро и легко вносить изменения, не влияя на общий график проекта.
Каковы преимущества гибкой методологии разработки?
Существует множество преимуществ гибкой методологии разработки, некоторые из которых включают:
- Повышенная гибкость : Гибкая разработка более гибкая, чем другие методологии управления проектами. Команды разработчиков могут легко вносить изменения на лету.
- Улучшенная коммуникация : Гибкая разработка помогает улучшить коммуникацию между командой разработчиков и владельцем продукта. Из-за этого больше внимания уделяется сотрудничеству и обратной связи.
- Снижение рисков : Гибкая разработка может помочь снизить риски, связанные со сложными проектами. Разбивая сложные проекты на более мелкие этапы, менеджеры проектов могут анализировать их и выполнять требования акционеров.
- Повышение удовлетворенности клиентов : Гибкие среды разработки часто приводят к повышению удовлетворенности клиентов. Это связано с тем, что заказчик участвует в процессе разработки и обеспечивает обратную связь на каждом этапе проекта.
Это связано с тем, что заказчик участвует в процессе разработки и обеспечивает обратную связь на каждом этапе проекта.Каковы недостатки гибкой методологии разработки?
Существуют также некоторые недостатки методологии гибкой разработки, в том числе:
- Ограниченный контроль : Поскольку гибкая разработка является более гибкой, владельцу проекта может быть трудно осуществлять контроль над проектом. Это проблема для проектов, которым необходимо уложиться в жесткие сроки или уложиться в определенный бюджет.
- Отсутствие документации : Гибкая разработка часто производит меньше документации, чем другие методологии управления проектами. Это проблема для проектов, которые требуют обширной документации.
- Высокий уровень сотрудничества : Высокий уровень сотрудничества, необходимый для гибкой разработки, может стать проблемой для удаленных команд, которые не привыкли работать вместе. Это может привести к конфликту и разочарованию.
- Сложные проекты могут быть длительными : Гибкая разработка часто требует больше времени, чем другие методологии управления проектами. Это связано с необходимостью более частых встреч и необходимостью создания большего количества документации.
Это может привести к конфликту и разочарованию.Agile-методология против Scrum
Гибкая разработка — это широкий термин, который может относиться к любой методологии управления проектами, использующей итеративный и гибкий подход. Scrum — это особый тип гибкой разработки, который фокусируется на коротких спринтах, ограниченных по времени. Обычно эти ограниченные по времени спринты длятся месяц или меньше, а еще один начинается сразу после последнего.
И agile-разработка, и scrum — важные инструменты для управления сложными проектами. Однако они имеют разные сильные и слабые стороны.
Преимущества Agile-разработки по сравнению со Scrum включают:
- Agile-разработка более гибкая, чем Scrum. Это означает, что может быть проще вносить изменения во время проекта.
- Agile-разработка производит меньше документации, чем Scrum. Это может быть преимуществом, если вам не нужна обширная документация для вашего проекта.
- Agile-разработка может быть хорошим выбором для проектов, которые не очень подходят для ограниченных по времени спринтов Scrum. Например, если ваш проект рассчитан на длительный срок, Agile-разработка может быть лучшим вариантом.
Недостатки Agile-разработки по сравнению со Scrum включают:
- Scrum более структурирован, чем Agile-разработка. Это означает, что может быть легче не сбиться с пути и укладываться в сроки.
- Scrum может быть хорошим выбором для проектов, которые необходимо выполнить быстро. Это связано с тем, что спринты с ограничением по времени вынуждают команду разработчиков сосредоточиться на завершении проекта в определенные сроки.
- Scrum производит больше документации, чем Agile-разработка. Это преимущество, если вам нужна обширная документация для вашего проекта.
Это преимущество, если вам нужна обширная документация для вашего проекта.Agile против Канбана
Канбан — это еще один тип Agile-разработки, в котором используется другой подход к управлению проектами. Канбан фокусируется на создании визуального представления работы, которую должны выполнить команды разработчиков. Отличным примером этого является традиционная канбан-доска с делами, незавершенными и готовыми для программных проектов. Это помогает держать команду организованной и сосредоточенной.
Преимущества Канбана по сравнению с Agile включают:
- Канбан может помочь сократить количество времени, затрачиваемого на совещания. Визуальное представление работы позволяет легко увидеть, что нужно сделать команде разработчиков и кто отвечает за каждую задачу. Канбан
- может помочь уменьшить путаницу и конфликты в команде разработчиков. Каждая задача возложена на конкретного человека и нет места для интерпретаций. Канбан
- может быть хорошим выбором для проектов, требующих высокого уровня координации между членами команды разработчиков.
К недостаткам Канбана по сравнению с Agile относятся:
- Канбан может быть сложнее реализовать, чем гибкую разработку. Это требует визуального мышления об управлении проектами. Канбан
- может быть хорошим выбором для проектов, которые хорошо подходят для гибкой разработки. Однако это может быть не лучший выбор для каждого проекта.
Agile против XP
XP фокусируется на создании набора лучших практик, которым может следовать команда разработчиков. Эти «лучшие практики» касаются в основном улучшения качества проекта, например, уделения большего внимания тестированию и удовлетворенности акционеров. Например, одна из основных ценностей XP — быстрая обратная связь. Ожидается, что члены команды будут максимально откровенны в отношении проекта, чтобы создать бесспорно великолепный конечный продукт.
Преимущества XP по сравнению с Agile включают:
- XP может помочь улучшить качество кода. Основные ценности XP помогают гарантировать, что код написан последовательным и чистым образом.
- XP может помочь сократить количество времени, затрачиваемого на совещания. Это связано с тем, что передовой опыт помогает проводить собрания целенаправленно и по плану.
Недостатки XP по сравнению с Agile включают:
- XP может быть сложнее внедрить, чем Agile-разработку. Это связано с тем, что для этого требуется другой способ мышления об управлении проектами.
- XP может быть хорошим выбором для проектов, хорошо подходящих для Agile-разработки. Однако это может быть не лучший выбор для каждого проекта, особенно для более сложных проектов, требующих большего внимания к движущимся частям, а не к конечному продукту.
Оптимизируйте доставку приложений с помощью OpenText
Agile-разработка является важной основой для выполнения всех видов проектов, от проектов по разработке программного обеспечения до маркетинговых кампаний.
Agile-практики могут:
- Разбивайте комплексные проекты на отдельные задачи, называемые спринтами.
- Сделайте проекты более эффективными и менее трудоемкими.
- Вовлекайте всех акционеров и сотрудников таким образом, чтобы это способствовало общему успеху.
OpenText ALM Octane — это инструмент планирования Agile, который может помочь вам автоматизировать разработку и доставку Agile. ALM Octane может помочь улучшить качество вашего кода и сократить время, затрачиваемое на совещания. Это также может помочь уменьшить путаницу и конфликты внутри команды разработчиков.
Если вы ищете способ улучшить процесс доставки приложений, начните бесплатную пробную версию ALM Octane сегодня.
Новые возможности OpenText™ ValueEdge и ALM Octane 16.0.400
А с помощью ValueEdge, нашей платформы управления потоками создания ценности, вы можете использовать самые современные передовые методы Agile и DevOps для отслеживания невыполненных работ по выпуску приложений и хода конвейера.
- Управление работой Agile и DevOps
- Управление невыполненной работой команды
- Релизы и спринты
- Управление трубопроводом
- Инструментальная панель Agile
Начните работу с ValueEdge сегодня!
Ресурсы
Ресурсы
сопутствующие товары
ValueEdge™
Полностью интегрированная сквозная платформа управления потоками создания ценности и облачная платформа разработки программного обеспечения для визуализации и управления потоками создания ценности.
Узнать большеАЛМ Октан
ALM Octane включает интегрированное планирование, непрерывную интеграцию, управление тестированием и управление выпусками.
Узнать большеOpenText™ ALM/Центр контроля качества
ALM/Quality Center служит единой панелью управления качеством программного обеспечения.
