Agile что такое: Что такое Agile, зачем и где используется, разница Scrum и Kanban

Содержание

Что такое Agile: от идеи до потенциальных проблем | Блог

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

В чём идея

Гибкую методологию управления придумали, чтобы решить ряд проблем классической/каскадной/водопадной методологии (Waterfall). Например, слишком большой упор на планирование и влияние задержек в одних командах на работу других. Для этого, как я уже сказал, пришлось полностью пересмотреть взгляд на проектную работу, а не менять какие-то отдельные механики.

«Гибкость» заключается в способности agile-команды постоянно адаптироваться к изменяющимся условиям и достигается за счёт:

—
Итеративности. Вместо того чтобы долго-долго прорабатывать план, а потом ещё дольше делать идеальную версию продукта, agile-команда старается как можно раньше выпустить работоспособный прототип, а затем раз за разом его тестировать и допиливать. Итеративность может негативно повлиять на продолжительность разработки, но зато у тебя почти сразу есть более или менее рабочий продукт.
—
Самоорганизации. В команде все равны, нет никаких руководителей и управляющих, а значит нет и адских согласований. Это экономит ресурсы, особенно время.
—
Взаимопроникновения знаний. Любой специалист в agile-команде должен иметь хотя бы базовые знания о смежных специальностях. Помимо кросс-функциональности, постоянно погружение в новые темы позволяет держать мозг в тонусе (вообще, если мозгу регулярно давать новую информацию, ещё и деменция придёт гораздо позже; но это совсем другая история).

Краткая история Agile

Гибкий подход начинает своё существование где-то с первой половины XX века (хотя, есть мнение, что что-то на него похожее было и раньше). Примерно в 30-х физик Уолтер Шухарт применяет итеративный подход Plan-Do-Study-Act, которым делится со своим учеником Ульямом Демингом (сейчас мы знаем этот подход к управлению, как Цикл Деминга). После окончания Второй мировой, компания Toyota (та самая, где придумали Lean, Kanban и много чего ещё, связанного с Agile) нанимает Деминга обучить своих менеджеров.

В следующие годы во многих компаниях придумывают свои методики гибкого управления: Scrum, XP, FDD и так далее. Но про «agile» никто не говорит до 2001 года, пока 17 разработчиков, практикующих методики гибкого управления, не собираются вместе и не составляют Манифест гибкой разработки программного обеспечения (Manifesto for Agile Software Development или просто Agile Manifesto). Здесь и возникает понятие «agile», вокруг которого сегодня столько разговоров.

Основные ценности Agile-методологии

В статье про методы управления проектами я дал такое определение:

Методология — набор методов и принципов, подкреплённых теорией.

Так вот теория в случае с Agile — это ценности, описанные в Agile Manifesto:

—
Люди и взаимодействие важнее процессов и инструментов. Если в твоей команде есть принципы, традиции, структуры, инструменты или условия, которые явно мешают работе — от них следует избавиться. Люди сами должны выбирать способ организации, набор процессов, используемые инструменты. В конце концов, всё это должно помогать работе, а не мешать.
—
Работающий продукт важнее документации. Это не значит «работать по Agile — работать без документов». В agile-командах тоже есть документация, но на неё не тратят огромное количество времени и ресурсов.
—
Сотрудничество с заказчиком важнее согласования условий контракта. Посмотри немного дальше согласования ТЗ и сметы. Нет смысла портить отношения с заказчиком, пусть и ценой своевременной оплаты. Если ты не можешь согласовать работы и портишь общение, в итоге потеряешь и этого клиента, и, возможно, следующих. Любые контракты, документы и соглашения должны идти на руку твоим взаимоотношениям с клиентами, а не портить их.
—
Готовность к изменениям важнее следования первоначальному плану. Даже если есть план проекта, в него, почти наверняка, со временем придётся внести изменения — в этом суть Agile.

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

Какие могут быть проблемы

Ай, какой классный Agile, да? Увы, хотя его и можно применять в любой компании (даже если ты — прости, Господи — банк), подходит он далеко не всем. Да ещё и его внедрение может быть крайней болезненным.

Я вижу три проблемы (хотя, вполне может статься, что их больше), из-за которых нельзя советовать переходить на Agile всем подряд:

—
Сложно отказаться от концепции «начальник — подчинённый». Ведь Agile — это не способ планирования, а философия работы всей команды. Далеко не каждая компания сможет спокойно пережить подобную трансформацию.
—
Не все готовы к по-настоящему командной работе. Многим людям комфортнее работать в одиночку, отчитываться перед руководством и никуда не лезть. А в случае с Agile всем придётся во всём разбираться и постоянно участвовать в чужой работе.
—
Не все готовы к тому, что часть времени может просто пропасть. Допустим, команда работала над задачей, а потом оказалось, что цели проекта поменялись и продолжать почти законченную работу нет смысла. Все твои усилия были напрасны. Это психологически сложная ситуация, которая может запросто убить всю мотивацию.

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

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

Главное, помни, что Agile – это методология и философия. Чтобы применять всё это для управления проектами, нужно собрать свою методику или выбрать одну из существующих — о них я расскажу в следующих статьях.

методология, команда, оценка эффективности — статьи на Skillbox

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

Как сделать так, чтобы задержка в работе одного отдела не останавливала остальных?
Как справиться с тем, чтобы разработка плана проекта не занимала до 30% времени от всего объема его реализации?
Как, в конце концов, добиться того, чтобы эти планы соблюдались?

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

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

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

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

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

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

Agile-команда строится на принципах самоорганизации и относительного равенства всех участников. Даже человек, которого многие представляют главой проекта, product owner, на самом деле — лишь персонификация требований к продукту. Он выполняет роль носителя знаний о том, каким ожидается конечный результат, но отнюдь не является управляющим в стандартном понимании. Поскольку привычка к иерархичности трудноискоренима, во многих командах product owner’у, увы, приходится брать на себя и контролирующие функции. Но идеалом гибкой разработки является коллективная ответственность членов команды друг перед другом.

Принципы формирования agile-команд разнятся в зависимости от конкретного проекта. Например, в музыкальном сервисе Spotify они строятся вот так:

Еще одна важная ценность agile-команд — взаимопроникновение знаний. Член команды не должен замыкаться в своей узкой области, ему следует стремиться к кросс-дисциплинарности. Это не значит, что программист должен быть и продавцом, а дизайнер — маркетологом.

Важно!

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

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

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

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

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

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

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

Следование им и поможет на этапе внедрения, и будет подспорьем в процессе работы.

Лучше познакомиться с Agile и другими современными методологиями, применяемыми от IT до медиа и маркетинга, а также погрузиться в построенные на их основе процессы, вы сможете, пройдя курс «Управление digital-проектами» от Skillbox.

Курс «Управление Digital-проектами»

Курс поможет вам оценить себя как менеджера: разобраться и понять, почему у вас что-то не получается. Определить, какие навыки и знания нужно подтянуть. И сделать это, выполняя практические задания.

Живая обратная связь с преподавателями
Неограниченный доступ к материалам курса
Стажировка в компаниях-партнёрах
Дипломный проект от реального заказчика
Гарантия трудоустройства в компании-партнёры для выпускников, защитивших дипломные работы

Что такое Agile. Гайд по гибким методологиям, или Как работать с пользой. Часть 1

Алена Лепилина

Agile — гибкий подход к разработке, включающий разные методологии (Scrum, Канбан, ХР, Lean и другие). Об этом знают многие. Но есть десятки мелочей и всяких интересных штук, которые не лежат на поверхности.

Подготовили серию статей и для новичков, которые с гибкими методологиями пока на «вы», и для тех, кто с ними давно дружит. Расскажем и об основных понятиях (вкратце), и о неожиданном применении Agile и Scrum в повседневной жизни. Сегодняшняя статья — как вводная лекция: о том, что такое Agile и с чем его едят.

Большой взрыв проектов

Если провести параллель с зарождением Вселенной — эту роль отведем Agile, — тогда Большим взрывом станет проблема номер один, которая довела до нервного срыва не одну сотню менеджеров проектов, — изменение требований к продукту. Именно это — причина стенаний, надрывных возгласов «За что мне эта кара?» и поредевших шевелюр.

Обычно процессы работают в рамках каскадной модели (или waterfall model) — все происходит поэтапно и последовательно. Проще говоря, «вижу цель — иду к цели». И если в какой-то момент требования к продукту, конечной цели меняются, иногда приходится переделывать заново. Как только превосходно отточенный план сталкивается с реальностью, он сразу рассыпается в прах. Но вместо того чтобы выбросить в мусорную корзину и сам план, и свой подход к нему, руководители делают вид, будто план работает, и даже нанимают для этого специалистов. По сути, они платят людям за то, что те им лгут.

По мнению Джеффа Сазерленда, создателя Scrum, это напоминает модель поведения Политбюро ЦК КПСС в конце 1980-х годов, якобы верившему отчетам, которые оно получало накануне крушения Советского Союза.

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

Манифест Agile

Если упростить формулировки, чтобы «выкристаллизовать» соображения, которыми руководствуются все, кто работает по эджайлу, получится что-то вроде этого:

Самое главное люди, а не вещи
Документация (которую еще и никто не читает) не должна никому мешать работать
Сотрудничайте, а не перечитывайте контракт
Живите, дышите, меняйтесь — так быстро, насколько это возможно

Как устроены процессы

Посмотрим, как можно работать по эджайлу. Для примера возьмем Scrum — сегодня это самая популярная гибкая методика. Джефф Сазерленд, автор книги «Scrum», изобрел эту методику, чтобы справиться с недостатками классического управления проектами.

1. Выберите владельца продукта — это человек, который видит, к какой цели вы идете и что хотите получить в итоге.

2. Определитесь с командой — от 3 до 10 человек, владеющих навыками, которые позволят получить результат (т.е. работоспособный продукт).

3. Выберите скрам-мастера — этот человек следит за ходом проекта и помогает команде бороться с трудностями.

4. Составьте бэклог продукта — соберите в одном месте (желательно на Agile-доске) все-все-все требования к продукту и расставьте приоритеты. Владелец продукта должен продумать и собрать все пожелания. Затем команда должна оценить бэклог, чтобы понять, возможно ли все это сделать и сколько времени потребуется.

Так выглядит agile-доска в Яндексе, — источник.

5. Запланируйте спринты — отрезки времени (неделя или две), за которые команда выполняет определенный набор задач. Спринты будут регулярными: например, 15 раз по две недели, пока получится готовый продукт.

6. Проводите ежедневные встречи на 15 минут (и ни минутой больше) — на повестке три вопроса, на которые коротко отвечает каждый: что делал вчера, что буду делать сегодня и какие преграды мешают «взять высоту».

7. Делайте обзоры — по итогам спринта команда рассказывает, что удалось сделать, и демонстрирует работоспособные части продукта. На обзоры может прийти кто угодно: владелец продукта, главный заказчик или даже потенциальные клиенты.

8. Проводите ретроспективу — после каждого спринта Agile-команда обсуждает проблемы и ищет решения. Должен получиться план изменений, который команда сразу же и внедрит — на следующем спринте.

Более подробно о том, как внедрить скрам и повысить эффективность команды, читайте в этой статье.

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

Знать Agile в лицо

Agile-методики легко опознать по ключевым характеристикам, эдаким «сигнальным флажкам».

Минимизация рисков — это главная цель в рамках любого гибкого подхода.
Итеративная разработка — работа в коротких циклах.
Люди и коммуникация — самое важное.

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

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

Команде на руку общение с заказчиком и коллегами (чтоб без этого: «Вы меня неправильно поняли — переделайте все быстренько. И да, это надо вчера!»), прозрачность процессов, что уменьшает шансы на неожиданности, быстрое решение проблем. Ну и многие понимают, куда девается время и где работа стопорится. Мелочь (на самом деле нет), а приятно.

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

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

Кому это может не понравиться?

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

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

Читайте продолжение:

Что такое Agile. Гайд по гибким методологиям, или Как работать с пользой. Часть 2
Что такое Agile. Гайд по гибким методологиям, или Как работать с пользой. Часть 3

P.S. Хотите каждую неделю получать полезные советы из самых интересных книг по бизнесу и маркетингу, узнавать о новинках и получать скидки? Подписывайтесь на нашу рассылку. В первом письме — подарок.

кратко о методологиях Agile / Блог компании ИТ Гильдия / Хабр

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

Но все принимаемые решения нужно как-то «синхронизировать». Один из резидентов Hacker News отметил, что ему приходилось наблюдать за тем, как пяти сотням разработчиков в одной крупной компании разрешили самостоятельно принимать некоторые решения в «отрыве» от команды. По его словам, это был хаос. И хотя команда начала работать быстрее, она двигалась в никуда, потому что позднее возникали проблемы на этапах поддержки ПО.

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

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

/ Flickr / Sebastian Sikora / CC

Scrum

Scrum — это фреймворк гибкой разработки ПО, который считается методологией «по умолчанию». Для многих является синонимом Agile. По статистике за 2016 год, предоставленной VersionOne, Scrum используют 58% «гибких» компаний. При этом её поддерживают многие SaaS-платформы. Например, решение ServiceNow, частью которого является инструмент Agile Development.

Методология была разработана в конце 80-х — начале 90-х годов. Процесс управления состоит из фиксированных коротких итераций — спринтов (sprints).

Используя методологию Scrum, представитель заказчика плотно работает с командой разработки, расставляя приоритеты в списке требований к продукту (Product Backlog). Этот список состоит из баг-фиксов, функциональных и нефункциональных требований — из всего, что нужно сделать для реализации рабочего приложения.

Функциональные элементы, добавляемые в бэклог, называют историями. Каждая задача оценивается в определенное количество очков. Очки являются абстрактной метрикой и для её оценки могут использоваться самые разные шкалы (например, ряд Фибоначчи или степени двойки).

На основании списка требований заказчика команда определяет функции, которые хочет реализовать, и начинает свой спринт. Обычно он длится 30 дней. В конце подсчитывается общее количество очков, набранных командой за спринт (скорость). Это позволяет более четко планировать следующие спринты.

За последние десять лет программисты Кен Швабер (Ken Schwaber), Майк Бидл (Mike Beedle) и Джефф Сазерленд (Jeff Sutherland) приложили множество усилий для развития Scrum. Кен Швабер — наиболее активный сторонник фреймворка, и его сайт — хорошее место, чтобы начать свое знакомство с методологией. Он также выпустил книгу.

Scrum за все время существования приобрел огромную популярность и используется командами разработчиков даже в крупных компаниях. Однако сообщество за это время выявило и определенные её недостатки.

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

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

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

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

Extreme Programming

Особенность Scrum заключается в том, что этот фреймворк уделяет мало внимания практикам разработки. Поэтому некоторые agile-компании (порядка 10%) комбинируют его с экстремальным программированием (XP).

Экстремальное программирование привлекло к себе внимание в конце 90-х. Концепция зародилась в сообществе Smalltalk, а её авторами считаются разработчики Кент Бек (Kent Beck) и Уорд Каннингем (Ward Cunningham), которые хотели сформировать новые практики в разработке ПО, сделанные для людей.

Первым проектом, созданным по методологии Extreme Programming, стала система контроля платежей Chrysler Comprehensive Compensation (C3) в середине девяностых. Сам термин «экстремальное программирование» появился в 1997 году.

Концепция строится на основании двенадцати приёмов:

Разработка через тестирование (Test-driven development)

Игра в планирование (Planning game)

Заказчик всегда рядом (Onsite customer)

Парное программирование (Pair programming)

Непрерывная интеграция (Continuous integration)

Рефакторинг (Design improvement)

Частые небольшие релизы (Small releases)

Простота проектирования (Simple design)

Метафора системы

Коллективное владение кодом (Collective code ownership)

Стандарт оформления кода (Coding standard)

40-часовая рабочая неделя (Sustainable pace)

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

Однако Extreme Programming делает сильный упор на тестирование, что отличает её от Scrum. Методология гласит, что разработчик не может сказать, что код написан правильно до тех пор, пока не пройдут все модульные тесты. Поэтому часто XP идет рука об руку с техникой разработки Test Driven Development (TDD), когда сперва пишется тест, а затем логика для его прохождения.

Но такая «тестоориентированность» одновременно и недостаток подхода. Чтобы адаптировать XP, нужно инвестировать в создание инфраструктуры автоматизированных тестов и непрерывного развертывания ПО.

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

/ Flickr / U.S. Army / CC

Канбан

Scrum по-прежнему остается эффективной методологией, которая пользуется популярностью. Особенно в комбинации с экстремальным программированием. Вместе их процент использования среди Agile-команд достигает 68%.

Однако сегодня многие команды рассматривают иные варианты и обращают внимание на другие методологии. Одной из них стал канбан. CTO ConvertKit Грант Аммонс (Grant Ammons) говорит, что компании сперва адаптируют Scrum, который учит их необходимым дисциплинам для разработки ПО, а затем ищут более удобную альтернативу и обращаются к канбану.

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

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

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

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

Однако, как отмечают в сообществе HN, у такого подхода тоже есть определённые недостатки. В том же Scrum короткие спринты положительно сказываются на мотивации разработчиков. Программисты знают, что работа над продуктом закончится, когда весь список требований на 30 дней будет выполнен. В случае с канбаном — это постоянный и нескончаемый поток заданий. Однако есть выход — краткое обсуждение списков задач на неделю (или две).

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

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

P.S. Еще несколько статей из нашего корпоративного блога:

Что такое Agile. Гайд по гибким методологиям, или Как работать с пользой. Часть 2

Алена Лепилина

Публикуем вторую статью о работе с гибкими методологиями (если вдруг пропустили, вот первая): как избежать потерь, что такое скрам скрамов, как внедряют Agile в российских компаниях и каковы плюсы и минусы agile-подхода.

Скрам против потерь

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

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

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

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

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

Делайте все правильно с первого раза. Совершив ошибку, исправ- ляйте ее сразу. Отложите все другие дела и займитесь ею. Устранение дефекта спустя некоторое время займет в двадцать раз больше сил и часов, чем немедленное исправление ошибки.
Если слишком усердно трудиться, работы становится больше. Если работать сверхурочно — это не значит, что успеешь больше. Слишком усердный труд приводит к усталости, которая в свою очередь приводит к браку в работе, и его приходится сразу устранять. Чем трудиться допоздна и еще по выходным, лучше работать в будни в постоянном ритме. И не забывать об отпуске.
Не будьте неразумны. Амбициозные цели — лишь мотиваторы, которыми пользуются ваши руководители. Недостижимые цели только вызывают депрессию.
Без героизма. Если для выполнения работы вам нужен герой — у вас проблема. Героическое усилие следует рассматривать как признак ошибки при планировании.
Довольно с нас глупых концепций. Любая политика, кажущаяся смехотворной, с большой вероятностью таковой и является. Глупые формуляры, глупые совещания, глупые утверждения, глупые стандарты — все они просто глупы. Если ваш офис напоминает офис Дилберта, значит есть что исправлять.
Никаких засранцев. Не будьте им сами и не позволяйте другим. Любой человек, создающий эмоциональный хаос, внушающий страх и ужас, унижающий людей, должен получить по заслугам. Его не должно быть в вашем коллективе.

Скрам скрамов

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

Для больших проектов, которые в типичные цифры скрама «команда 7±2 человека» не вписываются, эффективнее использовать масштабировать методологию и «уйти» в скрам скрамов — Scrum of Scrum или даже Scrum of Scrum of Scrum, когда команды объединяются в подобие нейросети.

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

В этом случае необходимо, чтобы был руководитель программы (РМ), который организовывает собрания. От каждой команды на него приходит скрам-мастер, а митинг проводится так, как будто это одна скрам-команда. Можно задавать разные вопросы, например, что было сделано с момента прошлого Scrum of Scrum или что помешало завершить спринт так, как планировалось.

Точно так же можно масштабировать еще на уровень выше — проводить Scrum of Scrum of Scrum.

Agile в российской практике

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

источник

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

Чтобы «погрузить» своих сотрудников в тему, в начале года в Сбербанке организовали семинар для сотен сотрудников. Сбербанк сотрудничает с консалтинговой компанией McKinsey, которая должна сделать из него компанию с Agile-структурой. Что уж говорить о тысячах компаний не такого масштаба: там переход на гибкую методологию разработки куда проще.

Мы попросили поделиться мнением Дмитрия Григорьева, основателя платформы Rubrain, прошедшего путь от программиста до технического директора, его опыт в управлении проектами — 8 лет:

«В наше время практически на любом рынке выигрывает тот, кто научился быть „гибким“. Сейчас очень популярны такие концепции предпринимательства, как Lean Startup, в основе которых лежит правило быстрой валидации гипотез. Подобные подходы не могли бы существовать без поддержки гибких методологий. Поэтому, на мой взгляд, Agile выигрывает у классической каскадной модели разработки и помогает многим компаниям становиться лидерами на своем рынке.

Scrum — это фреймворк и, конечно, он не является „серебряной пулей“ и гарантией успеха проекта, но дает большие преимущества. Я люблю этот фреймворк за то, что он:

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

В качестве „минусов“ Scrum я бы отметил то, что он может обмануть вас своей простотой и легкостью. На самом деле его легко понять, но не так просто использовать. Недостаточно прочитать несколько брошюр в интернете и идти с ног на голову менять процессы в вашей команде. На мой взгляд, гибкие методологии требуют от человека глубокого осознания и понимания. Как говорится, нужно „стать Agile“ :)».

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

P.S. Понравилось? Подписывайтесь на нашу рассылку по бизнесу и маркетингу. Раз в неделю рассказываем о самых ценных идеях их новинок и даем скидки только для своих.

Методологии разработки ПО: Agile | GeekBrains

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

https://d2xzmw6cctk25h.cloudfront.net/post/1863/og_cover_image/6ae757601184e793149f82c869acca51

GeekBrains уже рассказывал о «Водопаде» (Waterfall), на очереди — Agile: познакомимся с этой схемой, по которой организуют работу многие коллективы программистов.

В феврале 2001 года семнадцать человек — крупные IT-специалисты и разработчики — собрались на горном курорте в штате Юта. Отдохнули, пообщались и составили небольшой документ — Agile-манифест.

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

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

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

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

Выдвигаются требования к ПО, разрабатывается техническое задание (ТЗ).

Поставленные задачи воплощаются в коде.

Выполняется тестирование.

Готовое ПО внедряется в работу.

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

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

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

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

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

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

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

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

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

Четыре центральных идеи 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 [5 ключевых вопросов]

Разберемся с Agile: Что такое Agile и как использовать в практике бизнеса

Давайте разберемся и определим: что такое Agile? и каким образом можно внедрить Agile (методы гибкого управления) в своих компаниях и как нужно это на самом деле делать?

Когда речь заходит об Agile (эджайл) сразу возникает довольно много вопросов, ведь данная тема сейчас очень популярна, но на самом деле это направление очень старое и известно уже несколько десятков лет.

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

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

Что такое Agile?

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

Возможности Agile

Самое интересное в методологии Agile является возможность корректировать последовательность своих действий вне зависимости от первоначально задуманного плана или стратегии.

Корпоративные тренинги для руководителей по Agile

Скачать листовку для руководителя: корпоративный тренинг по Agile

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

Зачем внедрять Agile методы гибкого управления в компании

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

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

Зачем нужен Agile?

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

Agile меняет модель мышления в самой организации, так как в рамках компании создается некая рабочая группа, в задачи которой входит поиск интересных и неординарных решений, которые можно внедрить на рынок.
При этом актуальность данных решений подчеркивается с точки зрения финансово-экономического обоснования.
Следует понимать, что сама команда, которая проводит подобные мозговые штурмы может быть небольшая от 6 до 20 человек, а для небольшого бизнеса вполне достаточно 2-4 сотрудника и это те люди, которые образуют по большому счёту костяк мышления в компании.

[bctt tweet=»Agile это не конкретная технология — это набор различных методов и подходов» username=»SavkinKS»]

Проектная команда по внедрению Agile

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

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

[su_note note_color=»#FFFF66″ text_color=»#333333″ radius=»3″ class=»»]
Методы гибкого управления Agile (эджайл) позволяет:

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

[/su_note]

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

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

Мы узнали что-то новое? Скорее всего нет, а с другой стороны ДА!

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

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

Внедрение Agile в больших компаниях

Но когда мы пытаемся применить Agile в больших компаниях, то происходит очень интересный момент:

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

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

Конечно данная высказывание относится к практике, в теории будет все отлично.

Рекомендую ознакомиться: Стоимость внедрения Agile в компании

Конфликты при внедрении Agile

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

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

[su_note note_color=»#FFFF66″ text_color=»#333333″ radius=»3″ class=»»]Если мы игнорируем согласование как факт, то нарушаем бизнес-процессы компании, а следовательно это может привести к довольно серьезным последствиям.[/su_note]

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

Пример внедрения Agile

Рассмотрим простой пример, который я привожу на своем корпоративном тренинге по Agile, когда рассматриваем с руководителями вопрос формирования Agile команд:

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

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

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

[su_note note_color=»#ADFF2F» text_color=»#333333″ radius=»3″ class=»»]Прямой зависимости между Agile и прибылью компании нет, пока нет, но скоро будет![/su_note]

Agile методологию интересно применять для небольших команд, для того чтобы найти какую-либо интересную идею или интересное решение, которое даст вашей компании «эффект прорыва» с минимальными затратами, именно для этого Agile и предназначен.

Как работает Agile в России

На мой взгляд:

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

[su_note note_color=»#FFFF66″ text_color=»#333333″ radius=»3″ class=»»]Для достижения результата собственник или ТОП менеджмент любых компаний очень часто обращается к своим доверенным лицам или сотрудникам, для того чтобы найти то или иное интересное решение, а не создают Agile команды, я думаю понятно над чем следует работать.[/su_note]

Специфика внедрения Agile

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

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

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

Agile и антикризисное управление

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

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

Вы должны помнить: что вы и только вы, как руководитель несете ответственность за внедрение каких-либо новых подходов и методов своей компании, но с другой стороны:

вам нужны новые подходы и новые методы,
вам нужно четкое понимание прибыли,
четкое понимание новых рынков, на которое нацелена ваша компания.

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

Agile, делаем выводы

Многие компании, которые стремятся внедрить Agile забывают:

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

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

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

Последние статьи по Agile:

[catlist id=662 numberposts=5]

На этом все, ваше мнение и отзыва про Agile приветствуются, а с интересными идеями в области стратегии компании вы можете ознакомиться в рубрике: Стратегия на моем бизнес-блоге. Спасибо!

Если вы захотите быть в курсе новых публикаций подпишитесь на мой телеграмм-канал @SavkinKS и расскажите друзьям.

Agile Project Management — Полное руководство

Перейти к основному содержанию

Поиск

США (английский)
Великобритания (английский)
нидерландский язык
Немецкий
Шведский

Авторизоваться

Рабочий фронт
ProofHQ

Связаться с отделом продаж

США (английский)
Великобритания (английский)
нидерландский язык
Немецкий
Шведский

Почему Workfront
Обзор
Клиенты
Услуги и поддержка
Решения
Все решения
Маркетинг
ЭТО
Агентства
Профессиональные услуги
Разработка продукта
Продукты
Обзор продуктов
Все

Agile-методология: обзор | Zenkit

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

Определение методологии Agile:

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

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

Краткая история гибкой разработки программного обеспечения

В 1990-е годы разработка программного обеспечения столкнулась с небольшим кризисом. Отрасль, получившая название «кризис разработки приложений» или «задержка доставки приложений», осознала, что она не может двигаться достаточно быстро, чтобы удовлетворить потребности и требования клиентов — расчетное время между бизнес-потребностями и фактическим приложением составляло около трех лет.

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

Когда деньги и усилия были потрачены впустую, а некоторые проекты даже были отменены на полпути, профессиональные лидеры программного сообщества подумали, что пришло время для нового, обновленного подхода. Затем в 2001 году в заснеженном лыжном домике в Юте собралось 17 человек. Некоторых из них уже интересовала идея нового метода разработки программного обеспечения.Все они стремились закрепить процесс, узаконивший то, что применялось, и поэтому был создан Agile Manifesto.

Что такое Agile Manifesto?

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

Ценности и принципы «Манифеста для гибкой разработки программного обеспечения»:

Значения

Люди и взаимодействие важнее процессов и инструментов
Рабочее программное обеспечение важнее исчерпывающей документации
Сотрудничество с клиентами в ходе переговоров по контракту
Реагирование на изменения следование плану

Принципы

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

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

Что такое гибкое управление проектами?

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

Результаты

Заявление о видении продукта: Краткое изложение, в котором сформулированы цели продукта.
Дорожная карта продукта: Общий обзор требований, необходимых для достижения видения продукта.
Журнал незавершенных заказов: Отсортированный по приоритету, это полный список того, что необходимо сделать для завершения вашего проекта.
План выпуска: График выпуска рабочего продукта.
Журнал спринта: Пользовательские истории (требования), цели и задачи, связанные с текущим спринтом.
Приращение: Функциональность рабочего продукта, которая представляется заинтересованным сторонам в конце спринта и потенциально может быть передана заказчику.

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

Двумя наиболее популярными из них, которые поддерживают жизненный цикл гибкой разработки, являются Scrum и Kanban.

Методология Agile Scrum

Scrum — это гибкая структура, которая используется для реализации идей, лежащих в основе гибкой разработки программного обеспечения.Созданный Джеффом Сазерлендом и Кеном Швабером (которые также были частью 17 человек, утверждавших Agile Manifesto), он состоит из пяти ценностей: приверженность, смелость, сосредоточенность, открытость и уважение. Его цель — разрабатывать, поставлять и поддерживать сложные продукты за счет сотрудничества, подотчетности и непрерывного прогресса.

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

Командные роли Scrum

Владелец продукта : Эксперт по продукту, который представляет интересы заинтересованных сторон и является голосом клиента.
Команда разработчиков : Группа профессионалов, поставляющих продукт (разработчики, программисты, дизайнеры).
Скрам-мастер : Организованный служащий-лидер, который обеспечивает понимание и выполнение Скрама.

Scrum-события

Sprint : Итерационные временные рамки, в которых достигается цель. Сроки не превышают одного календарного месяца и одинаковы на протяжении всего процесса разработки.
Планирование спринта : где вся команда Scrum собирается — в начале каждого спринта — для планирования предстоящего спринта.
Daily Scrum : 15-минутная встреча с ограничением по времени, проводимая в одно и то же время каждый день спринта, на которой обсуждаются достижения предыдущего дня, а также ожидания на следующий день.
Обзор спринта : Неформальная встреча, проводимая в конце каждого спринта, на которой команда Scrum представляет свой прирост заинтересованным сторонам и обсуждает отзывы.
Ретроспектива спринта : собрание, на котором команда Scrum размышляет о ходе предыдущего спринта и устанавливает улучшения для следующего спринта.

Артефакты Scrum

Журнал отставания по продукту : Управляется владельцем продукта, здесь в порядке приоритета перечислены все требования, необходимые для жизнеспособного продукта. Включает функции, функции, требования, улучшения и исправления, которые разрешают вносить любые изменения в продукт в будущих выпусках.
Журнал спринта : список задач и требований, которые необходимо выполнить во время следующего спринта. Иногда сопровождается доской задач Scrum, которая используется для визуализации хода выполнения задач в текущем спринте и любых изменений, которые вносятся в формате «To Do, Doing, and Done».

Канбан

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

Его шесть общих практик:

Визуализация
Ограничение незавершенных работ
Управление потоками
Детализация политик
Использование петель обратной связи
Совместная или экспериментальная эволюция

Концепция, которая была разработана на производственной линии На заводах Toyota в 1940-х годах Kanban обеспечивает эффективность за счет визуальных сигналов, сигнализирующих об определенных этапах процесса разработки.Указанные реплики представляют собой канбан-доску, канбан-карты и иногда даже канбан-дорожки.

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

Другие подходы к жизненному циклу гибкой разработки

Экстремальное программирование (XP)

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

Игра в планирование
Малые релизы
Метафора
Простой дизайн
Тестирование
Рефакторинг
Парное программирование
Коллективная собственность
Непрерывная интеграция
40-часовая неделя
На месте Заказчик
Стандарт кодирования

Crystal

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

Метод разработки динамических систем (DSDM)

DSDM — это гибкая методология, ориентированная на полный жизненный цикл проекта.Он был создан в 1994 году после того, как пользователи Rapid Application Development (RAD) захотели большего управления и дисциплины в этом итеративном способе работы. Его философия, основанная на восьми принципах, заключается в том, что «любой проект должен быть согласован с четко определенными стратегическими целями и сосредоточен на раннем предоставлении реальных выгод для бизнеса».

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

Семинары с фасилитированными семинарами
Моделирование и итеративная разработка
Приоритезация MoSCoW
Временные рамки

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

Feature-Driven Development (FDD)

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

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

Моделирование объектов предметной области
Разработка по функциям
Владение компонентами / классами
Функциональные группы
Проверки
Управление конфигурацией
Регулярные сборки
Видимость прогресса и результатов

Гибкая методология лучшие практики

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

Сотрудничество с клиентами

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

User Stories

Инструмент, используемый для объяснения функции программного обеспечения с точки зрения конечного пользователя, цель User Story — создать упрощенное описание требования.Это помогает представить себе тип пользователя продукта, то, что он хочет, и причину (ы) для этого. Обычно используется формат User Story:

В качестве [роли] мне нужна [функция], потому что [причина].

Непрерывная интеграция

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

Автоматические тесты

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

Парное программирование

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

Разработка через тестирование (TDD)

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

Диаграммы сгорания

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

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

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

Cheers,

Динни и команда Zenkit

Была ли эта статья полезной? Пожалуйста, оцените это! [Всего: 51 Среднее: 4,8 / 5].

Agile Tutorial | Учебное пособие по Agile-методологии для тестирования

Home
Testing
- - Back
  - Agile Testing
  - BugZilla
  - Cucumber
  - Database Testing
  - JTL Testing JUnit
  - LoadRunner
  - Ручное тестирование
  - Мобильное тестирование
  - Mantis
  - Почтальон
  - QTP
  - Назад
  - Центр качества (ALM)
  - RPA
  - SAP Testing
  - RPA
  - TestLink
SAP
- - Назад
  - ABAP
  - APO
  - Начинающий
  - Basis
  - BODS
  - BI
  - BPC
  - CO
  - Назад
  - CRM
  - Crystal Reports
  - FICO
  - 000 HRM
  - 000 HRM
  - MM Pay
  - Назад
  - PI / PO
  - PP
  - SD
  - SAPUI5
  - Безопасность
  - Менеджер решений
  - Successfactors
  - SAP Tutorials
Web
Web
AngularJS
ASP.Net
C
C #
C ++
CodeIgniter
СУБД
JavaScript

Назад
Java
JSP
Kotlin
Linux
Linux
Kotlin
Linux

Perl

Назад
PHP
PL / SQL
PostgreSQL
Python
ReactJS
Ruby & Rails
Scala
SQL

000

0003 SQL

000

0003 SQL

000

UML
VB.Net
VBScript
Веб-службы
WPF

Обязательно учите!

- Назад
- Бухгалтерский учет
- Алгоритмы
- Android
- Блокчейн
- Business Analyst
- Создание веб-сайта
- CCNA
- Облачные вычисления
- 0003 COBOL
- 000 Compiler
  - 000 9000 Compiler
  - Ethical Hacking
  - Учебники по Excel
  - Программирование на Go
  - IoT
  - ITIL
  - Jenkins
  - MIS
  - Сети
  - Операционная система
  - 0003
  - Назад
  - Управление проектами Обзоры
  - Salesforce
  - SEO
  - Разработка программного обеспечения
  - VB A
Big Data
- - Назад
  - AWS
  - BigData
  - Cassandra
  - Cognos
  - Хранилище данных
  - HBOps
  - HBOps
  - MicroStrategy
  - MongoDB
  - NiFi
  - OBIEE
  - Pentaho
  - Назад
  - Power BI
  - Qlikview
  - Tableau
  - Pro000300030003
  - 000 Live
  - Live Agile Testing
  - Live HP ALM
  - Live Java Project
  - Live Mobile Testing
  - Live Payment Gateway
  - Live PHP Project
  - Live Projects Hub

Декабрь 2024
Пн	Вт	Ср	Чт	Пт	Сб	Вс
						1
2	3	4	5	6	7	8
9	10	11	12	13	14	15
16	17	18	19	20	21	22
23	24	25	26	27	28	29
30	31

Agile что такое: Что такое Agile, зачем и где используется, разница Scrum и Kanban

Что такое Agile: от идеи до потенциальных проблем | Блог

В чём идея

Основные ценности Agile-методологии

Какие могут быть проблемы

методология, команда, оценка эффективности — статьи на Skillbox

Что такое Agile. Гайд по гибким методологиям, или Как работать с пользой. Часть 1

Большой взрыв проектов

Манифест Agile

Как устроены процессы

Знать Agile в лицо

кратко о методологиях Agile / Блог компании ИТ Гильдия / Хабр

Scrum

Extreme Programming

Канбан

Что такое Agile. Гайд по гибким методологиям, или Как работать с пользой. Часть 2

Скрам против потерь

Скрам скрамов

Agile в российской практике

Методологии разработки ПО: Agile | GeekBrains

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

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

Scrum

Командный дух

Рывок! Еще рывок!

XP — программируем экстремально!

Экстремальные практики

Экстремально — не значит плохо

Никакого волшебства

Преимущества Agile

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

Кому подойдет Agile

Больше методологий богу методологий!

Что такое Agile [5 ключевых вопросов]

Что такое Agile?

Рекомендую изучить по Agile

Возможности Agile

Зачем нужен Agile?

Проектная команда по внедрению Agile

Внедрение Agile в больших компаниях

Конфликты при внедрении Agile

Пример внедрения Agile

Как работает Agile в России

Специфика внедрения Agile

Agile и антикризисное управление

Agile, делаем выводы

Последние статьи по Agile:

Agile Project Management — Полное руководство

Agile-методология: обзор | Zenkit

Определение методологии Agile:

Краткая история гибкой разработки программного обеспечения

Что такое Agile Manifesto?

Значения

Принципы

Что такое гибкое управление проектами?

Результаты

Методология Agile Scrum

Командные роли Scrum

Scrum-события

Артефакты Scrum

Канбан

Его шесть общих практик:

Другие подходы к жизненному циклу гибкой разработки

Экстремальное программирование (XP)

Crystal

Метод разработки динамических систем (DSDM)

Feature-Driven Development (FDD)

Гибкая методология лучшие практики

Сотрудничество с клиентами

User Stories

Непрерывная интеграция

Автоматические тесты

Парное программирование

Разработка через тестирование (TDD)

Диаграммы сгорания

Agile Tutorial | Учебное пособие по Agile-методологии для тестирования

Добавить комментарий Отменить ответ