Создание scrum доски в word

Обновлено: 07.07.2024

Гайд по тому, как перестать ходить с презентациями, создать Scrum-команду и начать делать продукт с нуля.

То, что я опишу, вполне посильно и человеку, который никогда не был скрам-мастером или аджайл коучем. При этом все-таки рекомендую перед применением почитать книги по Scrum и конечно же Scrum Guide, который, кстати, обновился осенью 2020.

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

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

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

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

Их стоит вовлечь на 100% именно в этот продукт. И ни во что больше. Сложно? Непривычно? Но с этого начинается эффективность Скрама(а не со специфичных совещаний). Никаких битв за ресурсы, никаких переключений крутого человека между десятком проектов. HR называют это штатным расписанием.

3. Определить, кто будет исполнять роль владельца продукта. В случае стартапа там все достаточно просто. Чья идея, тот и владелец продукта. В корпорациях чуть сложнее.

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

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

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

Проще всего аджайл командам поддерживать Agile-процессы в Jira, она специально настроена под это прямо из коробки на их сайте, для команд до 10 человек бесплатно. Есть и те, кто помнит Jira жестким энтерпрайз софтом, в котором сложно разобраться. Но они не такие, покупка Trello пошла этому софту на пользу. Лучше завести ее бесплатно, если это не противоречит требованиям компании.

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

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

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

Для запуска отлично подходит заполнение карты компетенций "Star map", но можно и любые другие, означающие старт.

Пример карты приведен ниже. В столбик компетенции. В строчку люди. Можно наоборот. Звездочкой отмечается уверенное владение компетенцией. Галочкой или плюсом возможность что-то сделать. Карту можно заполнять прямо на белой доске внутри Zoom, нарисовав от руки.

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

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

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

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

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

В конце раздела есть короткий опрос для сбора фидбека.

Note: Scrum - не единственная методология разработки программного обеспечения. Инженеры могут использовать Kanban, Waterfall, DevOps, Rapid Application или другой подход. Следуя Scrum, его можно адаптировать / настраивать / изменять. Основным принципом здесь является принятие методологии, которая синхронизируется с тем, как компания разрабатывает программное обеспечение. Остановимся на Scrum, потому что это самый распространенный подход.

Введение

Если вы не знакомы со Scrum, попробуйте сначала ознакомиться с методологией, прежде чем читать этот раздел. Начните с чтения руководства Scrum. Если вы предпочитаете книжную версию, см. Scrum: The art of doing twice the work in half the time. Это руководство к подходу (небольшая книга).

Подключаемся к Scrum разработки, или создаем свой Scrum

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

Существует несколько преимуществ присоединения к готовому процессу:

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

Помимо преимуществ такого подхода есть и отрицательные моменты:

  • еcли тех. писатель является временным ресурсом в проекте, с продолжительностью работы около месяца или около того, то, вероятно, нет смысла присоединяться к инженерному Scrum. Там слишком много адаптации, знакомство с процессом и многое другое;
  • если Scrum работает плохо, например, ежедневные встречи длятся более 30 минут, и есть несколько scrum-команд, с которыми нужно работать, все это убивает время, истощает пропускную способность, не давая ничего взамен;
  • скорее всего, у тех. писателя будет несколько проектов одновременно. Если нужно изменить свой подход к каждому из них, используя разные варианты Scrum, то собственный рабочий процесс и методология могут почувствовать себя немного разрозненными. Например, если каждый подход рассчитывает все по-разному, имеет разную продолжительность спринта и другие вариации, такое несоответствие своей методологии может быть утомительным;
  • команда инженеров хочет, чтобы тех. писатель присутствовал на всех их встречах Scrum, но не станет относиться к нему как к полноправному участнику Scrum (например, без задач, и т.д.), стоит задуматься о создании собственном Scrum-процессе.

Адаптация Scrum-процессов для создания документации

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

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

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

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

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

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

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

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

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

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

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

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

d) Ревью с юр.отделом Если у документации есть какие-либо “флажки”, которые могут вызвать проблемы с юристами, нужно передать документацию группе своих юристов для проверки. e) бета-ревью партнерами Можно сделать бета-ревью документации крупных проектов до ее публикации. Как правило, в этом могут участвовать полевые инженеры и партнер-заказчики.

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

Заключение

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

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

Дополнительные материалы

Небольшой опрос

Для сбора фидбека о данном разделе автор курса создал небольшой опрос. Результаты опроса можно посмотреть по ссылке

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

Неотъемлемым артефактом методологии Scrum является scrum-доска. Она становится центром информации о проекте и задачах на спринт.

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

Что такое scrum-доска?

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

Классическая доска содержит всего три столбца:

  • что нужно сделать, TO DO,
  • что делается, IN PROGRESS,
  • что сделано, DONE.

Размещение пользовательских историй на доске также помогает:

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

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

Доска может быть более детализирована. Тогда на неё добавляются дополнительные столбцы, например:

  • не запущено,
  • ускорить,
  • на проверке и т. д.

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

Общий принцип работы

Во время планирования спринта команда соглашается выполнить отобранные задачи. Они попадают в список TO DO, или «Сделать».

На утреннем стендапе каждый из команды выбирает задачу и берёт ответственность за её выполнение. Она перемещается в графу In Progress, или «В процессе».

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

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

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

Физическая scrum-доска

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

Подходит : для небольших команд, которые физически находятся рядом. Для них обновление состояния доски не займёт много времени.

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

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

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

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

Scrum-доска онлайн

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

Подходит : большой, удалённой команде; командам, которые демонстрируют рабочий процесс удалённым стейкхолдерам.

Чтобы сочетать удобство электронной доски и наглядность физической, некоторые команды ведут одновременно два борда. Например, мы в Realize поддерживаем аналоговую доску на самой длинной стене кабинета, там же размещаем диаграмму сгорания и другие заметки, связанные с командой. Scrum-мастер параллельно ведёт проект в Kaiten.

Какую онлайн-доску выбрать?

Kaiten — одна из возможных scrum-досок онлайн. Она доступна по подписке. Кроме возможности вести несколько досок, в программе есть функциональные карточки, автоматические диаграммы, генерация отчетов, учёт затраченного времени и интеграция с другими сервисами.

Другой популярный вариант — Jira. Это мощный сервис для полноценного управления проектами с большим количеством настроек. На нём останавливают свой выбор многие компании, но для маленьких команд стоимость подписки будет нерациональной тратой.

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

Есть несколько критериев выбора удобной и надёжной доски:

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

Где ещё используют доски задач

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

Прежде чем разобраться, что такое 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-команда — это чаще всего группа из пяти-девяти человек. Это оптимальное количество, но иногда встречаются команды и из трех человек. Если людей больше, то им становится сложнее взаимодействовать между собой, что мешает работе и снижает продуктивность.

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