7 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Спринт в agile это

Шпаргалка по Agile Scrum

Если вы работаете над созданием полезного для пользователя продукта, идущего в ногу со временем, я познакомлю вас с прогрессивным процессом Scrum в методологии Agile.

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

Csrum команда

Оптимальный состав scrum команды насчитывает от 3 до 9 разноплановых специалистов. Если команда сформирована из 3-х и меньшего количества человек, есть риск, что у команды окажется недостаточно компетенций, чтобы создать полноценный продукт. Если в команде больше 9 человек, то высока вероятность возникновения сложностей в координации. Это владелец продукта, скрам мастер и команда разработчиков. Но обо всех по-порядку.

Product owner или владелец продукта

Produst owner отвечает за создание максимально полезного для пользователей продукта. Он также несет ответственность за управление бэглогом продукта. А именно:

  • составляет ясное описание пользовательских историй (user story) — элементов бэглога;
  • добивается 100% понимания user story командой;
  • расставляет приоритеты в бэглоге;
  • обеспечивает прозрачность, доступность и ясность предстоящего объема работ

Scrum Master

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

Работа с product owner

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

Работа с командой разработчиков

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

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

  • использовании единой терминологии;
  • понимания критериев готовности между скрам-командой и заказчиком;
  • регулярном мониторинге отклонений от целей;
  • своевременным внесением корректировок

Формирование бэглога продукта

Разделим одну большую задачу, ведущую к цели, на много маленьких подзадач. В контексте scrum процесса, маленькие задачи называются user story или пользовательскими историями. А список этих задач называют бэглогом.

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

User story или пользовательские истории

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

Для того чтобы User story была точной, нужно четко представлять персон целевой аудитории. Важно выявить проблемы Ц.А. Понять их истинные потребности поможет дизайн мышление.

Формула User story базируется на 3 составляющих:

  1. Как ;
  2. Я ;
  3. Чтобы .
  1. Как
  2. Ему
  3. Чтобы

Критериями приемки данной user story станут следующие решения:

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

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

Истории в бэглоге продукта присваивают ID (идентификационный номер) и записывают списком в порядке приоритета. Также, каждая user story измеряется в user points. Это предполагаемое количество времени, которое будет затрачено на проработку каждой истории.

Что такое спринт

Таким образом, спринт — это определенный промежуток времени, за который scrum команда создает готовый к выпуску продукт. Обычно, каждый спринт длится 2 недели и складывается из нескольких процессов:

  1. планирование спринта;
  2. ежедневный скрам;
  3. разработка;
  4. обзор спринта;
  5. ретроспектива спринта.

Также, спринт можно представить формулой:

СПРИНТ = ЦЕЛЬ + КОНЦЕПЦИЯ РЕАЛИЗАЦИИ + АДАПТИВНЫЙ ПЛАН ПО ЕЕ ДОСТИЖЕНИЮ + ИСПОЛНЯЕМАЯ РАБОТА + КОНЕЧНЫЙ ПРОДУКТ.

Иногда, из-за потери актуальности product owner отменяет спринт.

Планирование спринта

Это совместное обсуждение объема работ и планирование действий. На это отводится до 8 часов в месяц. Увеличение и сокращение времени спринта рассчитывается пропорционально.

По окончании планирования, команда получает ответы на вопросы:

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

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

Product owner определяет элементы бэглога и бизнес-задачи, которые будут достигнуты.

Скрам команда определяет цель спринта, выбирает элементы бэглога и план их реализации. Разделяет работу на задачи к концу планирования. Длительность планирования, как правило, не более 1 дня. В ситуации большого объема работ csrum team может скорректировать количество задач, согласовав это с product owner.

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

Ежедневный скрам

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

Основные вопросы, которые рассматриваются на daily scrum:

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

Обзор спринта

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

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

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

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

Ретроспектива спринта

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

Целью данного мероприятия является повышение эффективности работы команды и степень удовольствия, получаемого от работы. Улучшение качества продукта.

Бэклог продукта

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

Читать еще:  Можно ли греть нос при гайморите

Бэглог спринта

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

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

Scrum и Agile для чайников

Комментарий Котиков

Для начала. Scrum и Agile — в чем разница? Если коротко, Agile — это философия, семейство гибких подходов к разработке ПО. Scrum — один из таких подходов. У него есть братик — Kanban. Он тоже подход, используемый в Agile.

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

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

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

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

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

Эджайл

(англ.agile —«проворный, шустрый, сообразительный»)

Концепция гибкости:

Подставьте свой вид деятельности вместо слова «разработка» — и эти принципы станут близкими и понятными.

«Работающий продукт — основной показатель прогресса», «простота как искусство минимизации лишней работы» и «люди и взаимодействие важнее процессов и инструментов» — правда, звучит разумно?

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

Скрам

(англ. scrum — толкотня в борьбе за мячик в регби)

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

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

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

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

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

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

Команда в скраме

Стандартный размер скрам-команды — 7 плюс-минус 2 человека. То есть от пяти до девяти. Бывает скрам-масштабирование: можно из 25 команд состроить систему работы над гигантской задачей. Но основная единица скрама — команда.

В каждой команде есть:

  • участники (в случае IT — разработчики, кто эти семь человек у вас — решите сами)
  • продакт оунер (product owner, владелец продукта). Его роль: понимать рынок и пользователя, формулировать задачи на языке бизнеса и пользователей, держать в голове осознание того, в каком направлении должны развиваться ценность и польза, придумывать и отбирать задачи для развития продукта. Что-то вроде руководителя продукта (не команды).
  • скрам мастер (scrum master, скрам-евангелист). Его роль: следить за процессом, наблюдать за внутренней жизнью команды, мотивировать людей, устранять препятствия. Что-то вроде тренера.
    Вокруг команды есть пользователи и стейк-холеры (stakeholders, заказчики). К этим людям продакт оунер ходит советоваться.

Устройство спринт

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

У продакт оунера есть список идей от бизнеса для осчастливливания пользователей. Он называется «продакт бэклог» (product backlog, список продуктовых идей). В нем идеи отсортированы по важности и значимости.

В каждом спринте есть спринт бэклог (sprint backlog, список задач на спринт) — отсортированный список идей, которые команда решила сделать за ближайший спринт. Смысл скрама в том, что команда сама оценивает сложность каждой задачи и решает, какие задачи войдут в очередной спринт.

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

Читать еще:  Как пишется сончас

В начале своей жизни команда всегда плохо планирует. Это объективная реальность. Но она ведет статистику того, что ей удается сделать за спринт, и со временем планирует всё точнее. Ей помогает итоговая встреча спринта — ретроспектива. На ней можно обсудить слабые моменты уходящего спринта и придумать способы делать по-другому.

Обычно в спринт влезает 5 плюс-минус 2 идеи. Если идеи слишком большие, команда их дробит так, чтобы в каждом спринте можно было что-нибудь маленькое, да показать.

В скраме идеи называются юзер-сториз (user stories, истории про пользователей) и формулируются так: «Я как (роль?) хочу (что?) для того, чтобы (зачем?)». Таким образом команда видит не только функциональность, но и смысл её создания, причем для конкретной роли: пользователь, заказчик, покупатель.

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

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

Структура спринта

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

Каждый день есть стендап-митинг (stand up meeting, совещание стоя) на 15 минут. Делать его стоя важно: если кто-то заболтается, остальные красноречиво будут переминаться с ноги на ногу и чесать ухо. Можно использовать какой-то предмет, чтобы говорил в один момент времени только один участник, и передавать его по кругу.

Каждый участник стендапа по очереди отвечает на три вопроса:

  • что я сделал вчера
  • что я сделаю сегодня
  • что меня тормозит

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

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

В конце спринта происходит демо (demo, демонстрация) с показом того, что удалось создать в течение спринта, спринт-ревью (sprint review, обзор спринта) с пересмотром продакт-беклога и разговорами о том, ЧТО мы делаем, а также ретроспектива (retro) — что мы делали не самым лучшим образом весь спринт и хотим улучшить далее — о том, КАК мы это делаем.

«Если бы у меня было восемь часов для того, чтобы срубить дерево, я бы шесть часов потратил на заточку топора». (приписывается лесорубу и президенту Аврааму Линкольну)

Agile, scrum, kanban: в чем разница и для чего использовать?

Главный редактор Rusbase

Если раньше офисы модно было обустраивать «по фэн-шую», то теперь — исключительно «по эджайлу». Agile – это не только цветные стикеры, на которых удобно отмечать ход работы (стикеры, скорее, стоит относить конкретно к подходу kanban). А ведь есть еще и scrum – он тут при чем?

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

Определение

Agile (agile software development, от англ. agile – проворный) – это семейство «гибких» подходов к разработке программного обеспечения. Такие подходы также иногда называют фреймворками или agile-методологиями.

Agile возник в IT-среде, но затем распространился и в другие сферы – от промышленной инженерии до искусственного интеллекта.

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

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

К отдельным agile-подходам относятся scrum и kanban.

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

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

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

Вся команда едина – в kanban нет ролей владельца продукта и scrum-мастера. Бизнес-процесс делится не на универсальные спринты, а на стадии выполнения конкретных задач: «Планируется», «Разрабатывается», «Тестируется», «Завершено» и др.

Главный показатель эффективности в kanban – это среднее время прохождения задачи по доске. Задача прошла быстро – команда работала продуктивно и слаженно. Задача затянулась – надо думать, на каком этапе и почему возникли задержки и чью работу надо оптимизировать.

Читать еще:  Как получить галочку вк

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

Примеры употребления

Один из принципов Agile стоит на личной ответственности человека, а не на отлаживании внутренних процессов.

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

(Из интервью «Ведомостей» с Фрэнком Сосьером, коучем компании Freestanding Agility)

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

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

(Управляющий партнер ScrumTrek Алексей Пименов в статье на Rusbase)

Слово экспертам

В зависимости от задач мы применяем разные методы в рамках философии – agile, scrum, kanban.

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

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

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

Важный момент: agile-методология – это общее направление, а kanban и scrum – уже ее разновидности.

Мы используем связку scrum + waterfall, а также дорабатывали в течение года саму agile-доску. Главная причина использования: прозрачность и простота. По сути, это получается тот же самый конвейер Генри Форда: переход задачи от статуса к статусу со сменой исполнителя, поэтому основным принципом к самой agile-доске является уже простота.

Мы используем agile как непосредственную часть нашего workflow, поэтому все проекты, от брендинга и разработки сайтов и вплоть до нашего стартапа по AI и нативной рекламе NativeOS, в бюро Chernika ведутся как раз по данному workflow.

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

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

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

Для наглядности и открытости работы отдела разработки мы повесили специальную доску с пометками “to do”, “in progress”, ”review”, ”test”, “done”, где все члены команды наклеивают стикеры с задачами (в колонке “to do”), а по мере их выполнения перемещают в последующие пункты. И счастливый финал – конечный пункт “done”. Это помогает составить общую картину и дает возможность видеть, над чем работает каждый участник.

Очень важный момент метода (и организации рабочего процесса): после утверждения всех задач (“to do”), список блокируется на внесение. Так новые поступающие задачи не отвлекают от процесса и не тормозят работу.

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

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

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

Agile – это философия, scrum – структура, waterfall – метод, kanban – система управления. Scrum и kanban – варианты agile, но у них есть некоторые явные различия. Методика scrum требует фиксированных ролей, тогда как у kanban нет необходимых ролей. Scrum основана на итерациях, объединяющих планирование, оптимизацию процессов и выпуск. В kanban это можно делать регулярно или каждый раз, когда вам нужно. Команда scrum требует оценки своей работы, тогда как команде kanban это не нужно.

Что почитать по теме?

  1. Agile-манифест разработки программного обеспечения (Manifesto for Agile Software Development)
  2. Дж. Сазерленд «Scrum. Революционный метод управления проектами»
  3. Д. Андерсон «Канбан. Альтернативный путь в Agile»
  4. Э. Стелманн, Дж. Грин «Постигая Agile. Ценности, принципы, методологии»
  5. K. Schwaber, J. Sutherland “The Scrum Guide”
  6. M. Cohn “Agile estimating and planning”

Текст: Александр Петров.

Видео по теме:

Источники:

http://www.sndesign-market.ru/ux-dizajn/54-agile-scrum
http://madcats.ru/business/scrum-and-agile/
http://rb.ru/story/agile-scrum-kanban/

Ссылка на основную публикацию
Статьи c упоминанием слов:
Adblock
detector