Scrum: как и почему это работает

История появления Scrum как метода управления проектами

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

• формирование перечня требований к продукту;
• составление пошагового плана всех операций;
• написание кода;
• тестовая проверка.

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

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

По итогу продолжительных наблюдений были сделаны соответствующие выводы и сформулирован «Манифест гибкой разработки программного обеспечения». Суть его – в следующих четырех пунктах:

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

Узнай, какие ИТ - профессии
входят в ТОП-30 с доходом
от 210 000 ₽/мес

Павел Симонов

Исполнительный директор Geekbrains

Команда GeekBrains совместно с международными специалистами по развитию карьеры подготовили материалы, которые помогут вам начать путь к профессии мечты.

Подборка содержит только самые востребованные и высокооплачиваемые специальности и направления в IT-сфере. 86% наших учеников с помощью данных материалов определились с карьерной целью на ближайшее будущее!

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

Павел Симонов

Исполнительный директор Geekbrains

Топ-30 самых востребованных и высокооплачиваемых профессий 2023

Поможет разобраться в актуальной ситуации на рынке труда

Подборка 50+ бесплатных нейросетей для упрощения работы и увеличения заработка

Только проверенные нейросети с доступом из России и свободным использованием

ТОП-100 площадок для поиска работы от GeekBrains

Список проверенных ресурсов реальных вакансий с доходом от 210 000 ₽

Получить подборку бесплатно

pdf 3,7mb

doc 1,7mb

Уже скачали 30006

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

1. Во главе угла – качественное ПО и удовлетворение запросов клиента.
2. Готовность в любой момент вносить правки.
3. Чаще тестировать ПО еще в процессе его создания, добиваясь таким образом корректной работы.
4. Организовывать встречи команды (это действеннее, чем просто обмен данными).
5. Важно совместное участие в процессе и разработчиков, и заказчика.
6. Смело доверять другим выполнение части своей работы.
7. Готовая часть ПО корректно функционирует – значит, прогресс налицо.
8. Важна гибкость, она позволяет постоянно развиваться.
9. Гибкость появляется, благодаря вниманию к качеству.
10. Когда процесс максимально упрощен, исключаются лишние действия.
11. Команды, способные к самоорганизации, наиболее эффективны.
12. Важно всё время стремиться повышать эффективность.

О формировании собственного гибкого подхода к ведению разработок Джефф Сазерланд и Кен Швабер впервые заговорили в начале 1990-х. Идея родилась на основе наблюдений за тем, как выполняют свои задачи военные, спецназовцы, даже спортсмены-регбисты. У них огромное значение придается умению работать сплоченно, в команде. За основу методологии Scrum были взяты эти же принципы.

Авторы описали свою разработку в книге «Agile Software Development with SCRUM», вышедшей в 2001 году. В среде разработчиков данный подход теперь, пожалуй, самый популярный.

Что собой представляет методология Scrum

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

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

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

Разница между Scrum, Kanban и Agile

Понятия Scrum и Agile нередко смешивают, принимают одно за другое. Или выдают Scrum за платформу для реализации Agile-подхода. Причина в том, что в обоих случаях главная идея состоит в неуклонном совершенствовании.

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

Kanban — один из рабочих фреймворков системы Agile. Но суть Scrum-подхода — в его структурированности, а главный принцип Kanban — сбалансированность, то есть, равномерное распределение задач между членами рабочей группы. Тут не может быть такого, что кто-то перерабатывает, а кто-то сидит без дела.

Характерная особенность Scrum— это разбивка всего процесса на спринты, для каждого из которых четко определены задачи. В Kanban же задания могут прибавляться участникам ежедневно. Тут идет непрерывный рабочий процесс. А в Scrum на выполнение каждого куска работы выделяется конкретное время.

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

Плюсы и минусы Scrum

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

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

Теперь о недостатках Scrum. Требования в Scrum вполне минималистичны, а потому довольно строги. И это подрывает постулат о клиентоориентированности, потому что заказчику не интересно, на какие именно внутренние правила опирается команда (и уж тем более, если они связаны с ограничениями). Например, клиент может пожелать изменить Sprint backlog. Его пожелания будут выполнены, хоть это и идет вразрез с принципами Scrum.

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

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

Главные принципы Scrum

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

• Вся работа делится на спринты (короткие отрезки)

В течение каждого спринта (или цикла) команда реализует законченный отрезок продукта. Проект не планируется целиком, а именно по частям.

• Гибкость, проверки, корректировки

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

• Тесное взаимодействие между заказчиком и пользователями

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

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

Читайте также!

Организация работы в команде: шаги и ошибки

Подробнее

• Коммуникации внутри команды

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

Состав Scrum-команды

Чаще всего в состав Scrum-команды входит от 5 до 9 человек, иногда – от 3 до 4. Scrum подразумевает тесное взаимодействие между звеньями цепочки, а если привлечь больше людей, то оно уже не будет таким продуктивным, что не лучшим образом отразиться на результате.

Основных ролей в Scrum-команде существует три, и они следующие:

Владелец продукта

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

Только до 23.09

Скачай подборку материалов, чтобы гарантированно найти работу в IT за 14 дней

Список документов:

ТОП-100 площадок для поиска работы от GeekBrains

20 профессий 2023 года, с доходом от 150 000 рублей

Чек-лист «Как успешно пройти собеседование»

Чтобы получить файл, укажите e-mail:

Введите e-mail, чтобы получить доступ к документам

Подтвердите, что вы не робот,
указав номер телефона:

Введите телефон, чтобы получить доступ к документам

Скачать подборку бесплатно pdf 2,5mb

Уже скачали 52300

Я подтверждаю согласие на обработку персональных данных.

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

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

Вот что должен делать владелец в рамках Scrum-проекта:

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

Scrum-мастер

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

Вот что обычно должен делать Scrum-мастер:

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

Технические разработчики

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

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

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

Обязанности команды разработчиков примерно такие:

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

4 артефакта методологии Scrum

В Scrum-разработках задействуется всего 4 артефакта. Это:

Product backlog

Он включает в себя:

• Перечень требований, обязательных к выполнению. Если в Backlog’e не осталось требований, значит, работа над проектом завершена.
• User Story (пользовательская история) – это специальный шаблон, по которому излагаются упомянутые требования.
• Формулировка требований должна ясно демонстрировать, насколько они ценны для пользователя.
• Требования записываются в приоритетном порядке, который на каждом этапе (спринте) заново пересматривается.

Популярные статьи

Высокооплачиваемые профессии сегодня и в ближайшем будущем

Дополнительный заработок в Интернете: варианты для новичков и специалистов

Востребованные удаленные профессии: зарабатывайте, не выходя из дома

Разработчик игр: чем занимается, сколько зарабатывает и где учится

Как выбрать профессию по душе: детальное руководство + ценные советы

Sprint backlog

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

Пусть, например, речь идет о пожелании пользователя для Amazon.com. Тогда оно может быть таким: «Я, как потребитель, хочу заходить в огромный книжный интернет-магазин и покупать там любые книги, когда захочу».

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

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

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

Итак, что такое Sprint Backlog:

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

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

Sprint Goal

Это:

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

Данный артефакт позволяет разработчикам самостоятельно выбирать самые эффективные решения из разных вариантов (когда их образуется несколько). Product Owner задает цель спринта, то Sprint Goal гарантирует осознанность принимаемых решений.

Sprint Burndown Chart

Это:

• дословный перевод – «диаграмма сгорания»;
• что именно «сгорает»? человеко-часы либо Story Points (так называемые идеальные единицы);
• после завершения той или иной задачи тут же происходит обновление диаграммы.

5 этапов работы команды по методологии Scrum

Условно можно выделить пять этапов, из которых складывается процесс разработки с применением Scrum-подхода.

Этап 1: планирование задач для каждого спринта.

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

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

Этап 2: регулярные общие совещания.

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

• Что удалось сделать после предыдущей встречи и до текущего момента?
• Что конкретно нужно выполнить сегодня?
• Что может помешать поставленным целям?

Задача Scrum-мастера – при обнаружении проблем поспособствовать их решению.

Этап 3: формирование скрам-доски.

Её следует повесить в помещении, где проходят упомянутые совещания. Доска делится на три графы: «предстоит сделать», «делается сейчас», «выполнено».

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

Читайте также!

Стоит ли применять метод Agile: кому подходит, а кому нет

Подробнее

Этап 4: внесение изменений в текущую итерацию.

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

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

Этап 5: отслеживание результатов.

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

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

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

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

Частые ошибки при внедрении метода управления проектами Scrum

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

• За реализацию Scrum берутся неверно или задействуют его не в полной мере

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

• Слабая мотивация группы разработчиков

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

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

• Требования к продукту, взятому в разработку, противоречат принципам Scrum

По сути, Scrum – это детище Agile. А это означает, что здесь должна быть возможность в любой момент менять Product backlog (то есть, требования к продукту). Но для fixed-cost/fixed-time проектов такой подход не годится. Согласно идеологии Scrum, бессмысленно планировать сразу весь проект целиком, потому что нельзя заранее предвидеть все предстоящие изменения. Тут куда эффективнее себя показывает just-in-timе планирование (в рамках текущей итерации). И это далеко не единственное ограничение.

• Изначальное непонимание участниками зон ответственности

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

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

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

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

Проблемы возникают и по причине неверного понимания сферы ответственности Scrum-мастера.

• Довольно часто он выполняет роль тим-лидера, то есть распределяет задачи и следит за их выполнением.
• Еще чаще происходит так: Scrum-мастер не распределяет задачи, но на него «навешивают» всё управление процессом. Он устраивает Scrum-встречи и ведет их (и даже ежедневные, которые, вообще-то, должны организовывать сами разработчики), делает записи, доводит до членов группы принятые решения. Плюс сам же устраняет проблемы, например, беседует со «сложными» сотрудниками, несогласными с общим мнением и т.п.
• Бывает, что одному Scrum-мастеру поручают работать сразу с четырьмя командами (не меньше!). Так компании пытаются экономить.

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

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

Работает ли Scrum без Agile

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

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

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

Например, демонстрация спринта выглядит как отчет перед начальником (а он, кстати, по терминологии Scrum «заинтересованное лицо» продукта), который в ходе обзора лишь отчитывает сотрудников за отклонение от ТЗ. В то время как его задача – искать решения и достигать договоренностей совместно с командой, задавать ей достаточную мотивацию. Обзоры спринтов для того и проводятся, чтобы наладить тесное взаимодействие между разработчиками и конечными пользователями или продавцами продукта.

Касательно Scrum-доски, учитывайте следующее:

• Она выполняет роль наглядного и максимально понятного (без излишнего нагромождения технических деталей) источника информации. Доска каждый день должна быть перед глазами у команды и с первого взгляда давать представление о возможных проблемах в ходе реализации спринта.
• Доска должна сплачивать участников группы. Пусть, например, было решено вместо одного столбца «В работе» сделать на доске три колонки: «Анализ», «Разработка» и «Тестирование». В итоге кто-то, выполнив свою часть работы, будет сидеть без дела, потому что тестирование – уже не его проблема. Ну и далее в таком духе. При подобном подходе велика вероятность невыполнения спринтов и срыва сроков. Например, именно на моменте тестирования могут «зависнуть» какие-то элементы бэклога, а всё потому, что каждый делает лишь «свою» работу, а потом ждёт, пока справятся другие (но где же тогда взаимопомощь?). В принципе, это вполне рабочий подход (когда под каждый шаг выделяется отдельный столбец), но тут нужно помнить о подобных рисках.

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

Автор статьи:

Редакция сайта GeekBrains Шеф-редактор раздела Программирование