Scrum доска что это
Будь гибким: как понять Scrum и создать agile-команду
Scrum — методология гибкого процесса разработки программного обеспечения. Сейчас этот метод управления популярен и активно применяется.
Прежде чем разобраться, что такое Scrum и как внедрить эту методологию, давайте посмотрим на предпосылки её возникновения.
Как и зачем появилась Scrum-методология
До появления Scrum в мире разработки программного обеспечения было принято использовать «водопадный подход». Работа над продуктом велась по следующему плану.
Разработчики согласовывали план работы с заказчиком и чётко следовали техническому заданию. Когда продукт был готов, его тестировали, но уже не было возможности что-то поменять. Поэтому, если выявлялись ошибки, приходилось начинать всё сначала, а сроки работы увеличивались.
Так было, пока группа новаторов не решила изменить ситуацию полностью. Они наблюдали за тем, как работают успешные команды: не срывая сроки и получая именно тот результат, который планировали. Оказалось, что успех обеспечивала гибкость процесса.
Выводы, которые были сделаны, помогли создать «Манифест гибкой разработки программного обеспечения». В него вошли всего четыре пункта, но они полностью изменили процесс.
Манифест гибкой разработки ПО
1. Люди важнее инструментов.
2. Качество продукта важнее документации.
3. Взаимодействие с заказчиком важнее контракта.
4. Готовность к изменениям важнее установленного плана.
Эти четыре пункта стали основой для появления Agile, гибкого процесса разработки программного обеспечения. Позже были созданы 12 принципов, которые и сейчас используются в любой Agile-методологии.
12 принципов Agile
1. Главное — хорошее ПО и довольный заказчик.
2. Готовность к изменениям в любой момент.
3. Полностью рабочее ПО — как можно чаще.
4. Встреча команды — лучше всего для обмена информацией.
5. Заказчик и команда разработки должны работать вместе.
6. Доверять людям делать свою работу.
7. Есть рабочее ПО — есть прогресс.
8. Гибкие процессы — непрерывное развитие.
9. Внимание к качеству способствует гибкости.
10. Простота процесса позволяет не делать лишней работы.
11. Самоорганизующаяся команда лучше работает.
12. Постоянное стремление к большей эффективности.
Одна из методологий гибкого процесса разработки программного обеспечения, которая базируется на agile-принципах, — Scrum.
Создатели Scrum Джефф Сазерленд и Кен Швабер долгие годы наблюдали за работой американских военных, спецназовцев и даже регбистов. И заметили, что их успех основан на взаимодействии и командной работе. Сазерленд и Швабер поняли, что этого как раз и не хватает разработчикам программного обеспечения. Так появилась методология Scrum.
Принципы Scrum
Scrum всегда ориентируется на клиента, который должен получить желаемый продукт вовремя и с минимальными затратами. Этого можно достичь при соблюдении нескольких обязательных принципов.
Работа короткими циклами (спринтами)
Планируйте один спринт, а не весь проект сразу. Каждый спринт — период, в который команда работает над полностью законченной частью продукта.
Гибкость. «Проверять и адаптироваться»
Гибкость процесса и тестирование продукта после каждого спринта. Если что-то идёт не так, команда всегда готова сменить стратегию разработки или пересмотреть бэклог продукта.
Участие заказчика и пользователей в создании продукта
Заказчик не стоит в стороне, а полностью задействован в работе. Для этого существует роль владельца продукта, которую выполняет сам заказчик или его представитель. Именно через него команда взаимодействует с пользователями. Так как разработка ведётся короткими этапами, пользователи подключаются к тестированию почти сразу.
После первичного тестирования им открывают доступ к продукту, а владелец продукта собирает обратную связь. Так команда может совершенствовать результат.
Scrum-команда — это несколько человек, которые работают на один результат и как единое целое. Каждый стремится к общей цели.
О важности scrum-команды
Scrum-команда — это чаще всего группа из пяти-девяти человек. Это оптимальное количество, но иногда встречаются команды и из трёх человек. Если людей больше, то им становится сложнее взаимодействовать между собой, что мешает работе и снижает продуктивность.
Состав команды
Принципы работы scrum-команды
Чтобы работать по методологии Scrum, команда разработчиков должна соблюдать три основных принципа.
Совершенствование продукта за счёт самосовершенствования сотрудника.
Каждый член команды отвечает за свою часть работы и за общий результат.
Каждая команда самодостаточна, так как в ней собраны люди с разными навыками.
Процесс работы scrum-команды
Процесс работы scrum-команды проходит в несколько обязательных этапов.
Каждый спринт начинается с планирования. Scrum-мастер, владелец продукта и остальные члены команды вместе смотрят на бэклог продукта и выбирают направления, по которым будут работать в данном цикле. Так получается бэклог спринта, то есть список задач на этот период.
Дальше команда оценивает объём работ, оговаривает длительность спринта, в конце которого должен появиться результат, то есть готовый продукт.
Каждый день вся команда проводит короткую встречу, не более 15 минут. Scrum-мастер и владелец продукта тоже участвуют. Суть встречи — получить от каждого члена команды ответ на три вопроса:
Задача scrum-мастера — понять, если что-то идёт не так, и помочь команде справиться с трудностями.
Scrum-команда вешает в помещении для совещаний доску с разноцветными стикерами. Она делится на части, где отражается весь процесс работы над проектом. Тут могут быть варианты, но обязательно присутствуют три части. Первая — «Что нужно сделать», вторая — «В работе», третья — «Сделано». Этот простой способ помогает всем членам команды следить за общим ходом работы.
Если кто-то из членов команды понимает, что не укладывается в спринт, он сообщает владельцу продукта, а тот распределяет время иначе. То же самое происходит, если команда понимает, что справится с задачей досрочно, — тогда можно добавить дополнительных задач из бэклога продукта.
Когда задачи спринта выполнены, команда должна продемонстрировать полностью работающую демоверсию той части ПО, над которой велась работа в спринте.
Как внедрить scrum-методологию
Сейчас методология Scrum находится на пике популярности. Вопрос о её пользе уже почти не звучит. Но как внедрить Scrum правильно, чтобы заметно улучшить ситуацию с продуктивностью и качеством итогового продукта?
Кажется, что всё просто. Нужны несколько последовательных действий.
Это первый и основной шаг. Именно от слаженной работы команды зависит качество будущего продукта. Но не так легко собрать кросс-функциональную команду.
2. Назначить владельца продукта
Это может быть заказчик или его представитель. Владелец продукта будет отвечать за взаимодействие с заказчиком и работать с пользователями на всех этапах разработки.
3. Выбрать scrum-мастера
Scrum-мастер — важная часть команды. От него зависит, насколько комфортно всем участникам процесса будет работать. Тут нужен опытный scrum-мастер, который хорошо знаком с методологией не только в теории.
4. Создать список требований к продукту
Прежде чем начать разработку, стоит подумать над списком требований и согласовать их. Получится своего рода техническое задание, которое будет направлять работу.
5. Спланировать спринт
Разделить всю работу на периоды. Планировать каждый спринт. Не весь процесс разработки сразу, а только ближайший цикл.
6. Постоянно анализировать и оценивать результат
Подводить итоги после каждого спринта и оценивать результат. Переходить к следующему спринту, только если довольны результатом предыдущего.
Вот они — шесть шагов, которые ведут к увеличению продуктивности разработчиков, сокращению сроков работы и качественному программному обеспечению. Но так ли это просто, как кажется на первый взгляд? Как понять, успешно ли внедрён Scrum, и сделать так, чтобы не испортить показатели ещё больше?
Сейчас много scrum-теоретиков, которые плохо понимают, как работать с реальным продуктом. Поэтому важно учиться только у тех, кто знает, что такое Scrum, на практике, разбирается во всех тонкостях не только методологии, но и её внедрения в конкретную область. Ведь этот процесс сильно зависит от продукта, который вы собираетесь создавать с помощью Scrum.
Пишет про управление в Skillbox. Работала координатором проектов в Русском музее, писала для блога агентства CRM-маркетинга Out of Cloud.
Упорядоченный список задач, над которыми scrum-команда работает при создании продукта.
Что такое SCRUM-доска и как она учит ребёнка управлять своими делами
Чтобы научить своего 12-летнего сына Никиту навыкам самоорганизации, мы стали использовать дома своеобразную версию методологии управления проектами SCRUM. Спустя полгода могу с уверенностью сказать, что это работает. Рассказываю о самой системе и её базовых принципах.
Сразу оговорюсь, я не фанат тайм-менеджмента и планирования, в моей жизни инструменты управления делами появились в глубоко взрослом возрасте как вынужденное зло. Можете представить себе, каким стрессом для меня было попасть в ситуацию, когда несколько лет назад мне стало нужно не только свои дела организовывать, но и координировать работу целой команды «Банды умников»?
Я искренне восхищаюсь своими коллегами, которые легко и эффективно планируют своё время, концентрируются на важных вещах, ведут карточки в Trello, записывают дела и задачи не на случайных бумажках, а в специальном блокноте, и он не теряется у них через неделю.
Так вот, ближе к «детскому» вопросу: в работе «Банды» уже полтора года мы используем методологию (идеологию, фреймворк… да неважно!) SCRUM. Вот так в самом начале внедрения выглядели наши SCRUM-доски (сейчас они переехали в электронный вид).
Сказать, что навыки самоорганизации стали камнем преткновения для Никиты и наших отношений с ним — ничего не сказать. Он не только гениально ленив, инертен, «забывчив», изобретателен в отговорках, склонен к прокрастинации, но ещё и абсолютно устойчив к уговорам, подкупу, шантажу, санкциям, социальному давлению, похвалам и всем остальным попыткам заставить его делать что-то, чего ему прямо сейчас почему-то не хочется. Я бы давно отчаялся, если бы не рассказы мамы о моём поведении в детстве, из которых становится понятно, от кого Никите достались эти таланты.
В общем, внедрение Baby-SCRUM было для нас, мягко говоря, серьёзным вызовом, и по итогам полугода можно точно сказать, что это работает. Расскажу вкратце о самой системе и её базовых принципах.
Стикеры с задачами
Начну с этой простой вещи, которая кажется избитой и очевидной, но на самом деле замечательно отражает саму суть Agile-подхода к управлению делами.
Так вот, стикеры с задачами — просто гениальная вещь при умелом использовании. Перечень или список задач — жёсткая, непластичная вещь. Написав перечень задач в блокноте или на доске, уже сложно поменять задачи местами, дописать что-то, разбить какую-то из задач на части, убрать потерявшие актуальность.
Но стоит переписать задачи на клейкие стикеры — и всё приходит в движение! Например, их можно сначала наделать сколько угодно, а потом подумать, в каком порядке их выполнять — и без проблем переклеить. Или часть отложить на будущее. Или переклеить в перечень дел другому человеку. Красота!
Стикеры можно использовать не только на доске, но и в папке или даже в блокноте.
SCRUM-доска
Это командная рубка всей системы, тут наглядно видны все текущие задачи и задачи на ближайшее будущее. В нашем случае доска на холодильнике — это стратегический узел домашней логистики на входе в кухню: хочешь не хочешь, а сталкиваешься с ней десятки раз в день.
SCRUM-доска состоит из колонок, стикеры с задачами продвигаются по ним по мере приближения к состоянию «сделано». Прелесть этих простых действий с переклеиванием стикеров туда-сюда заключается в том, что в повседневных заботах можно оставить в поле зрения только те дела, на которых нужно сфокусироваться, не забивая голову тем, что ещё только предстоит или тем, что уже сделано.
Вот как устроены колонки:
«Бэклог»
Сюда попадают задачи с пока неопределённым сроком выполнения, вроде «надо не забыть когда-то потом при случае сделать». В общем, они на виду, и когда придёт их черёд — про них не забудут.
Например, пришла вам идея, что неплохо бы как-нибудь в выходные сходить в зоопарк. Но, как всегда, когда эти самые выходные наступят, это как-то забудется, и пройдут выходные буднично и бездарно… А вечером воскресенья — бац! Точно, в зоопарк же хотели! Вот если в бэклог писать все идеи на выходные, то прямо вечером пятницы будет просто спланировать выходные.
Это уже не просто идеи, а конкретные задачи, которые нужно сделать на этой неделе. Они туда попадают и из бэклога, и напрямую (например, в школе что-то задали). Часть стикеров тут появляется вечером воскресенья, а часть добавляются в течение недели.
«Делать»
Это задачи на день. Часть задач здесь оказывается вечером накануне, из колонки «надо» или напрямую. Собственно, вечер — это единственное время, когда я вижу Никиту в будни, утром он уезжает в школу намного раньше меня. А часть оперативных задач сюда поступает от Юли (моей жены), это хозяйственные дела по дому, помощь с Алисой (нашей младшей) и всё в этом духе.
«Проверка»
Промежуточная колонка, куда Никита перемещает сделанные (по его мнению) дела. Оттуда они попадают (или не попадают) в «Готово» или в течение дня, после проверки мной или Юлей, или только вечером, когда мы с ним делаем обзор дня.
«Готово»
Сюда задачи попадают из «Проверки», но не всегда. Дело в том, что наше с Никитой мнение относительно «сделанности» дел иногда очень сильно расходится. Например, он считает, что прибрался на кухне, а я вижу оставшуюся на плите грязную сковороду и крошки на столе, и стикер возвращается в «Делать».
Лайфхак: вместо стикеров для стандартных повторяющихся задач (вынести мусор, купить воду и прочее) удобно использовать магнитные стикеры.
SCRUM-доска настолько классный и удобный инструмент, что постепенно там появились и мои собственные хозяйственные дела, а потом появился и отдельный цвет стикеров для Юли.
Ежедневное и еженедельное планирование
Как известно, в квартире вещи могут быть всегда на местах, только если этот порядок постоянно поддерживается — все кладут вещи на место, а не оставляют, где придётся. Точно так же и в организации дел: SCRUM-доска не только должна быть на виду, с ней нужно работать с установленной регулярностью и по чётким правилам. Иначе рано или поздно какие-то задачи окажутся не записанными, какие-то стикеры — не переклеенными, а контроль над состоянием дел утрачен. В общем, её постигнет судьба моих многочисленных блокнотов и ежедневников.
У нас две обязательные процедуры: ежедневный обзор дел и еженедельный обзор.
Ежедневный обзор
Каждый вечер мы с Никитой и Юлей смотрим на доску и оцениваем, что из сегодняшних дел сделано, а что нет. Естественно, Никита очень гордится, если продуктивно провёл день, ну а я, как любой родитель, горжусь не меньше. Если что-то не сделано — обсуждаем причины или возникшие сложности.
Сначала мы смотрим колонку «Проверка». Например, Никита должен был сделать задания в тетради по английскому — тут же её смотрим, даём обратную связь, стикер двигается либо в «Готово», либо, если задания нужно ещё доработать — возвращаем в «Делать».
Потом смотрим колонку «Делать» — что не сделано, что помешало, как это сделать завтра.
Потом колонку «Надо» — дела, которые стоит взять в работу на завтра. Кроме этого, конечно же, можно посмотреть в расписание уроков, график занятий, в календарь, чтобы понять, какие ещё дела на завтра ещё актуальны. Например, если вечером пойдём в гости, то после школы нужно сбегать в магазин за тортом.
Получилось аж несколько абзацев, но на практике такой вечерний обзор занимает пять-десять минут, потому что в обычный будний день обсуждения заслуживает одно-два дела.
Еженедельный обзор
Тоже довольно быстрое дело, минут на 10—15:
• Делаем обзор колонки «Готово». Резюмируем успехи и выводы, после этого освобождаем её от всех стикеров (теоретически можно сохранить для истории и статистики, но мы просто выбрасываем).
• Наполняем колонку «Надо» новыми задачами. Задачи сюда вносятся из «Бэклога», календарей, расписания и просто из головы.
Хотя, как я уже написал, очень важна обязательность и регулярность. У нас, к сожалению, пропускается как минимум 20—30% вечерних обзоров — или я поздно прихожу с работы, или дома обстоятельства совсем не позволяют найти удачный момент. В субботу вечерний обзор не особо нужен, в воскресенье делаем обзор недели и планирование следующей (иногда это сползает на вечер понедельника).
Действия с колонками по времени:
Ещё в процессе обзора и планирования стараюсь больше задавать вопросы, чем указывать, что делать — мы ведь хотим научить Никиту самого контролировать свои дела, распределять приоритеты, выстраивать график.
Обязательные правила
Есть несколько обязательных правил, о которых мы поэтапно договорились с Никитой, чтобы всё это работало. Их немного, часть из них, как мне кажется, универсальны, а часть нужны именно исходя из нашей жизненной ситуации, уклада.
1. Любая задача сразу фиксируется на стикере
Вы сами, наверное, знаете, сколько раз ребёнку нужно сказать «убери вещи в шкаф», чтобы вещи в конце концов там оказались. Одна из целей обучения управлению делами — чтобы человек был сам в состоянии удерживать свои задачи под контролем.
В практическом плане это правило введено для того, чтобы дела Никиты не нужно было отслеживать и напоминать. Иначе зачастую проще сделать что-то самому, чем пять раз напоминать (ведь у ребёнка всегда найдётся какое-то текущее дело поинтереснее) и постоянно следить, выполнено или нет.
Если Никита получает какое-то задание (а это далеко не всегда происходит на планировании), оно сразу же пишется на доску (в «Бэклог», «Надо» или «Делать — смотря что за дело).
Исключение — только дела, которые нужно «всё бросить и сделать» прямо сейчас, вроде «быстро разобрать сумки из магазина». Ну и ещё есть дела, которые выполнить быстрее, чем написать, например, «убрать обувь с прохода на полочку».
2. Есть перечень постоянных обязанностей, которые Никита контролирует сам каждый день
Этих задач не так много, но перечень, конечно же, расширяется со временем. Сейчас это утренний разбор посудомоечной машины, покупка питьевой бутилированной воды, вынос мусора.
А ещё обязательно нужно после школы выполнять хотя бы три хозяйственных поручения, полученных от Юли (я в это время на работе). То есть, придя домой, Никита должен сам в инициативном порядке спросить, что ему нужно сделать, чем помочь, записать это на стикеры и взять в работу.
3. Видео и компьютер — после всех остальных дел
Ну тут всё просто: у Никиты есть ежедневный лимит по времени, которое он может пользоваться компьютером и планшетом. Это дело даже вынесено на отдельный стикер и стоит в «надо» каждый день, но в самом конце перечня дел.
Наша общая цель — чтобы на это дело тоже хватало времени, и мы в этом заинтересованы не меньше его. Наша позиция: «Никита, от жизни нужно получать удовольствие, тебе нравится играть в компьютерные игры — давай стараться, чтобы у тебя на это хватало времени!»
Очень важный, на мой взгляд, момент, заключается в том, чтобы не превращать систему управления делами в «тоталитарную машину». Мы с Никитой обсуждаем планы и дела, но не мы с Юлей указываем каждый день, что и как должно происходить в жизни Никиты. Здесь, как мне кажется, стоит перекладывать на ребёнка ответственность за планирование дел, ответственность за выбор, за принятие многих решений.
Есть область взаимных обязанностей, ведь мы одна семья и совместно ведём домашнее хозяйство, и тут родители как бы являются «начальством». Но обязательно должны быть и задачи, появление и выполнение которых исходит от ребёнка, в выполнении которых заинтересован он сам.
По затратам времени: ведение дел в таком виде требует определённой организованности, но во много раз экономичнее по времени, чем постоянно контролировать дела ребёнка и напоминать по десять раз о том, что ему нужно сделать прямо сейчас.
Разбираемся в Scrum и Kanban
Аспирант Нетологии Максим Пименов продолжает рассказ про гибкие методологии создания ПО. На этот раз Максим разбирает Kanban и Scrum — два подхода к работе над проектом, основанных на Agile.
Scrum и Kanban — это гибкие методологии создания продукта. По ним можно работать в любой отрасли, но особенно хорошо они подходят для ИТ. В основе обеих методологий лежат принципы Agile, о которых я писал в предыдущей статье.
Чистый Scrum — более директивная методология — больше предписаний. Kanban — демократичнее, поэтому его проще внедрить.
Обе технологии близки, потому их инструменты можно комбинировать.
Команды в Kanban и Scrum
Основа обеих методологий — Agile, поэтому и в Scrum, и в Kanban работают небольшие автономные команды из 5—9 человек. В командах нет формального руководителя, и никто извне не диктует, как организовывать работу над продуктом.
Поскольку команда автономная и самоорганизующаяся, за успех или неудачу она отвечает как единое целое. Провал не свалить на ленивого разработчика или невнимательного тестировщика.
Обе методологии подразумевают, что команда располагается в едином пространстве. Лучше, если это не кубиклы, а общая комната. Главный принцип — свободное общение между специалистами и общие обсуждения.
А вот дальше в Kanban и Scrum начинаются различия.
Kanban. Над задачей может работать несколько узкопрофильных команд. К примеру, сначала работают аналитики, потом дизайнеры рисуют прототип, а на третьем этапе включаются разработчики.
При этом универсальные команды не запрещены.
В Kanban внутри команды нет ролей.
Scrum. Над проектом работает одна универсальная команда. В ней столько разноплановых специалистов, сколько нужно для решения любой задачи проекта.
Поскольку команда самоорганизуется, у специалистов scrum-команды нет формальной компетенции. Когда необходимо, тестировщик помогает дизайнеру, а аналитик — разработчику.
В scrum-команде помимо собственно специалистов есть две роли.
Scrum-мастер — человек, который организует работу. Это не управленческая должность, и он не раздает указания. Его задачи:
В свободное от этих задач время скрам-мастер работает так же, как другие члены команды.
Владелец продукта — product owner — определяет ход проекта, он может представлять внешнего заказчика. Владелец знает все о рынке и целевой аудитории. Он ставит приоритеты задачам. Результат работы команда представляет владельцу продукта.
Как составляют список задач
Для начала команда берет проект и делит его на десятки, а то и сотни задач поменьше. Это часть философии Agile, поэтому так делают и в Kanban, и в Scrum.
Все задачи проекта, которые предстоит выполнить, складывают в общий список — бэклог. Бэклог — это банк задач проекта. Каждая задача должна быть актуальна. Если потребуется, их можно добавлять в бэклог или удалять из него «на лету».
Каждая задача имеет вес — обычно это время, которое нужно на решение. Команда сама оценивает вес всех задач, поэтому если проект не закончен в срок, виновата команда.
Также у каждой задачи есть приоритет. В Kanban приоритеты расставляет команда, в Scrum — владелец продукта. Приоритеты можно и даже нужно пересматривать по ходу проекта — это один из столпов гибких методологий.
Как работают над проектом
Когда начинается работа, Scrum становится понятно, почему его называют намного более директивной методологией.
Scrum-команда разбивает время работы над проектом на равные отрезки — спринты. Спринт может длиться и день, и месяц, а в последние годы стандартом стал спринт в 2 недели.
Поскольку все спринты одинаковы по длительности, в работе команды появляется ритм. Ритм — важный аспект методологии.
Спринт состоит из четырех последовательных этапов.
В Scrum категорически нельзя добавлять задачи в текущий спринт, поэтому Scrum менее гибок. Даже если появилась срочная и важная задача, она пойдет в работу только со следующего спринта.
В конце спринта недоделанные задачи уходят обратно в бэклог. Нужно ли их доделывать и когда, определяют на этапе планирования следующего спринта.
По сравнению со Scrum-директивами Kanban — это оплот либерализма и хаос.
Спринтов как таковых нет. Проект обычно делят на итерации, но они могут быть любой длины. Ритмичность Kanban не предписывает.
Вспомним этапы scrum-спринта:
В Kanban один этапы не завязаны на другие. Наступают они, когда решит команда. К примеру, релиз — по вторникам, планирование — когда закончились задачи, ретроспективы — каждый последний четверг месяца, а на фоне всего этого непрерывно идет разработка.
Поскольку выраженных спринтов нет, появляются особенности:
Что за доски используют Scrum и Kanban
Доска — это сердце kanban- и scrum-разработки, единственный визуальный атрибут методологий. Доски первым делом вешают на стену, когда хотят показать, что работают по Kanban или Scrum.
Доску используют, чтобы сделать проект прозрачнее, распланировать задачи и поставить ограничения.
Доску расчерчивают на столбцы. Каждый столбец — это состояние задачи («Разработка», «Тестирование», «Релиз»). Количество столбцов зависит от проекта, но чем их меньше, тем лучше.
Карточки — это задачи. На каждой описание, вес и приоритет. Когда задача проходит очередной этап, ее переклеивают в соответствующий столбец. При простом взгляде на доску понятно, как дела с проектом в целом и с каждой задачей.
Доски бывают физические и электронные.
Физическая доска. Часто доска — это действительно доска с клетками из малярного скотча. Задачи — липкие листочки, которые удобно двигать по доске.
Настоящая доска стоит в комнате и каждый в команде видит, как идут дела. Вокруг настоящей доски хорошо собираться во время совещаний.
Электронная доска. Электронная доска под рукой на пляже, на даче, в машине и в метро. Если у вас есть сотрудники, которые работают удаленно, электронная доска — единственный выход.
Я люблю настоящие доски, но без электронных иногда не обойтись.