Участник:StasFomin/AgileDaysDraft

Подстраницы (1) →

Опубликовал видео с конференции AgileDays-2011.

Почему это интересно?

Хотя тема уже не новая, в сейчас как раз можно отпраздновать юбилей — Agile Manifesto стукнул десяток, «продвижение в массы» еще продолжается. Причем если раньше борьба была на фронте корпоративной разработки, в стиле «Agile vs. Some Waterfall Unified Process» и там он нес скорее избавление от лишних регламентов и бессмысленного труда, то то сейчас он добрался до самых широких масс (разработка сайтов, стартапы).

А тут, конкурируя с «методологиями» «Bardak and Chaos», «Code&Fix(?)», и вместо избавления приносит какие-то странные ритуалы, очень похожие на менеджерский карго-культ, что встречает, скажем так, очень скептический прием у девелоперов. Тут и детские дразнилки, и даже «антиманифесты» ([1], [2]). Модно даже обвинять Agile в эпичном Nokia-фейле.

Лично я считаю, что в разработке развитие идет постоянно (см. например «Культуры программных проектов»), потребности пользователей растут наперегонки с техническими возможностями девелоперов, внутри разработки, особенно в зависимости от типа проекта, меняется важность ролей и специализаций: «разработчики», «менеджеры», «тестировщики», «аналитики», «юзабилисты» и «сейлы». И надо понимать, как все это балансировать. И меня достал уже старый риторический баян, что «нет серебряной пули» среди методологий разработки. Конечно нет! Есть куча интересных, эффективных практик, в разработке, аналитике и организации, есть рефлексия, когда, где и как это работает. И все это происходит под лейблом «Agile», наверное потому, что проще объединится под очевидными ценностями Agile-манифеста, чем под прохождением сертификации какого-нибудь Process Management Institute.

И именно потому, что все динамично и разнородно, «кабинетный путь» — «прочесть N книг», не шибко эффективен. Проще изучить очень простые правила и терминологию самых распространенных Agile-процессов — SCRUM и Кanban, это займет считанные часы, а затем смотреть, какие реальные, непридуманные проблемы возникают у других разработчиков, и как они их решают. А вместо того, чтобы читать книгу, которую вряд ли напишет «боевой» разработчик или PM (скорее всего это будет западный тренер в запоздалом и кривом переводе), посмотреть и послушать свежий опыт команд разного типа, понять, что «это у нас работать не будет», а «это нужно здесь и сейчас, иначе эти парни-конкуренты нас порвут».

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

Конечно, полезно также общаться и лично, но сейчас летнее затишье после прошедших AgileCamp, Agile Base Camp, и можно неспешно, совмещая с пассивным отдыхом смотреть и рефлексировать над видео с докладов.

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

Почему это видео надо или хотя бы можно смотреть?

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

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

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

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

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

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

Такое видео, можно с удовольствием посмотреть, получив эффект присутствия, и даже более того!

Ведь у смотрящего есть власть над видео:

• Можно повторить непонятное,
• Промотать тривиальное,
• Ускорить или замедлить выступление. Например, в VLC, нажав пару раз на клавишу «]», даже самый скучный и заикающийся докладчик начнет жечь как Стив Баллмер (да, многие доклады я смотрел на «150%» скорости). И наоборот, можно замедлить (в VLC это «[») и разобрать непонятный момент.
• Можно рассмотреть внимательно экран или наоборот, сконцентрироваться на выразительных, многое поясняющих, жестах докладчика.
• В такой записи смотреть даже презентации-слайдоменты, не читаемые даже с третьего ряда, или презентации на черном фоне, которые сделал гордец, решивший уподобится Стиву Джобсу (смотреть их в незатемненном зале — невозможно).

Но такой монтаж — это нетривиальная, обычно ручная работа, и когда за нее берутся профессионалы, то и берут за нее очень много. И то, как правило, получается не очень. Так вот, мы, при проведении AgileDays-2011 озаботились этим вопросом, и научились это делать относительно быстро и качественно. Видео высокого-веб разрешения (1280×720), где всегда есть экран с точностью до пискеля, докладчик или зал, в зависимости от активности последних, маркерная доска, если докладчик таки порывался на ней что-то порисовать.

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

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

А кроме видео, также опубликованы дополнительные материалы,

• как от самих докладчиков: аннотации, слайды,
• так и очень важная штука — отзывы зрителей.

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

И наконец — для каждого автора доклада приведена ссылка на его профиль в IT-шной профессиональной сети, т.е. если вы заинтересовались, в пару кликов можно:

• Посмотреть «кто все эти люди», можно ли доверять их мнению.
• Связаться с автором, задать вопросы, поблагодарить, или выразить несогласие.

Темы докладов

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

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

Getting Started

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

• «Для тех, кто в танке — что такое Agile» был задуман, как быстрый ликбез для новых в Agile людей, и как альтернатива открывающему докладу Henrik-а Kniberga. Программный Комитет думал, что те, кто «в теме» обязательно пойдут на «гуру», а оставшихся надо «вводить в тему». Однако неожиданно на доклад набился полный зал народу, из которых «не в теме» было всего человека три, так что ликбез получился вполне глубоким, не стыдно посмотреть, даже если вы практик. Можете рекомендовать тем, кого бы вы хотели заинтересовать Agile-ценностями — новым сотрудникам, старым менеджерам и молодым HR-шам…
• «Lean Software Development» и «Применение принципов Lean в масштабах предприятия» лучше смотреть блоком и в такой последовательности — это введение в новомодную производственную культуру «бережливого производства», в приложении к разработке софта. В некоторым смысле, Agile — это частный случай реализации более глобального подхода LEAN, c которым можно замахиваться на такие задачи, как реформирование и оптимизация всей компании (а не просто внедрение Agile в одном из подразделений).
• «Гибкая теория ограничений» — обзорный рассказ об «Теории ограничений», еще одной философии менеджмента, в некотором смысле дополнительной к LEAN.

Менеджерское

Процесс

• «Что означает «Готово!» — применение практики Definition of Done» — почему DoD должен быть? Потому, что только за счет таких жестких элементов и можно строить гибкие процессы. Без введения бинарности задач бессмысленно считать любые метрики («100 задач готовы на 99%»), что-то оценивать, прогнозировать и корректировать. «Если у вас нет DoD — то у вас что угодно, только не SCRUM». Какой DoD должен быть, как его формулировать для задач разного уровня, где хранить, и т.п.

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

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

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

Оценки и планирование

Хотя в Agile все подходы к планированию делаются максимально простыми и надежными (как правило, «жадные алгоритмы» приоритезации задач и т.п.), сложности остаются. Ведь планировать нужно на разных уровнях (баги, задачи, story, marketing features, релиз, и т.п.) и разным потребителям (разработчикам, маркетологам, заказчикам, пользователям). А планирование невозможно без оценок, и хотя уже не все верят в мантру «You Can't Manage What You Don't Measure», тут обсуждаются также и надежные метрики, которых можно получать дешево и без «побочного влияния» на измеряемый объект.

• «Трехуровневое планирование в Agile » — опыт планирования на уровнях «квартал → Релиз → Спринт» и борьбы с технодолгами и изменением требований.
• «Agile с фиксированной стоимостью — это реально!» — что делать, когда самый неудобный для Agile-разработки случай: заказчик, который готов платить только фиксированную цену и за определенный объем. К сожалению, ничего волшебного, в основном, как страховать себя от рисков, как документально это оформлять («change request только за отдельные большие деньги») и т.п.
• «Предварительная оценка и планирование Agile проектов» — Взгляд на Agile матерого oldschool менеджера, очень много разнородного личного опыта по большим и долгоживущим проектам (не только планирование и оценка). Все под девизом «Лучше два раза встать на взрослые грабли, чем один раз на детские» (это о кейсе «Agile & FixedPrice», развивая тему «Agile с фиксированной стоимостью — это реально!»).
• «Agile Distribution Risk Score — планируйте распределенность осознанно» — «распределенность» еще одно известное неудобство для Agile-разработки (для любой, но для Agile — особенно). Но насколько это неудобно? Имеет ли смысл «слать на помощь» распределенной команде еще «один отряд», или это окончательно уронит КПД? Тут предлагается эмпирически выработанная на десятках проектов формула.
• «Планирование релизов в методологиях быстрой разработки» — инсайдерский опыт из таких крупных компаний, как Amazon и Microsoft.

Мотивация

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

• «Everyone likes change, but nobody likes to be changed» — Доклад (на английском, без перевода!) о проведении изменений от гуру-аджайла. Важность личного лидерства при проведении изменений, как определить истинную цель и выбрать конкретные шаги, ведущие к ней.
• «Культура лидерства в Agile» — лидерство, как новый тип менеджмента, в замен обычному иерархично-директивному. Менеджер должен быть харизматичный лидер и терпеливый учитель, да еще «в ответе за тех, кого приручил» — ведь даже делегирование не снимает ответственности!
• «И все-таки программисты — дети!» — Интеграция (по Адизесу) и People Management — очень схожи с воспитанием детей, и современные (именно продвинутые!) взгляды на детское развитие дают ключ и к пониманию и эффективному управлению командой. «Свобода и наставничество» вместо «Няньки, которая развращает команду».
• «В поисках гибкого разработчика» — Альтернативой мучениям по воспитанию эффективного командного игрока является правильный отбор. Какие качества желать от кандидатов, что реально важно, и нельзя починить после покупки? А как организовать эту входную «выбраковку»?

Опыт

Положительный и отрицательный опыт разных компаний и проектов.

• «Стихийный Agile во внутрикорпоративной среде» — как оно в внутри Embarcader'о (кстати, они maintener'ы Delphi). Немного сумбурно, «обо всем», куча разных кейсов.
• «Принципы Lean и развитие аутсорсинговой компании» — у них счастливая ситуация, так много новых проектов, что приходится оптимизировать их запуск и разгон. Марья Ивановна, всем бы ваши проблемы...
• «Экстремальный аджайл — танцуют все» — «SCRUM-беспредел»! Всех участвующих в разработке продукта, включая маркетологов, аналитиков, юзабилистов, в одну команду! Более того, в одну комнату! Всех 18 человек! Продукт (SAAS-бухгалтерия) получается весьма интересным.
• «Наследие капитана Флинта — трудности и ошибки внедрения Scrum на примере компании Промедичи» — вот, тот самый пример отрицательного опыта, чтобы не говорить, что Agile, как и дельфины, спасают всех тонущих. Тут же все было давно запущено, и внедрение SCRUM оказалось эвтаназией. «Ужасный конец лучше, чем ужас без конца».
• «Kanban vs Scrum – чьё кунг-фу сильнее» — Если SCRUM для вас слишком жесткий и перегружен ритуалами, то лучше не кастрировать его насмерть, комплексуя от того, что у вас «не настоящий SCRUM», а перейти сразу на полноценный Kanban (всего три правила!).
• «Jam session» — свободное обсуждение тем «Внедрение TDD», «Agile и госзаказчик», «Электронная скрам-доска», «Длинный скучный Daily Scrum команды из 18 человек» (догадайтесь у кого ^_^).

Отдельно выделю целых три доклада о SCRUM в Luxoft:

• «В чем счастье заказчика? Готовые фичи вместо гант-чарта!» — гимн Agile от Luxoft, три года как начавший внедрять Agile в ряде своих проектов.
• «Agile in Investment Banking» — внедрение в самой сложной ситуации: распределенная команда, фикспрайс, финансовый хайлоад (трейдинг) с дорогими ошибками — как выжить, какие практики работают, а что, нужно отбросить.
• «Enterprise Scale Agile. Lessons learned» — «корпоративный Agile такой корпоративный», весь обвешанный графиками и метриками.

Техническое

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

Архитектура

• «Архитектура в Agile — переосмысляя идею модульности и компонентности (Андрей Бибичев, AgileDays-2011)» — Лучший технический доклад конференции, квинтессенция двух десятков лет опыта, от самого крутого из моих знакомых разработчиков. По сути — каким должно быть правильное ООП.
• «Модель системы — архитектура для Agile-разработки (Максим Цепков, AgileDays-2011)» — Удачный опыт так называемой «моделеориентированной» системной инженерии, когда вместо размазанной в коде бизнес-логики, четко выделяется всегда актуальная модель предметной области и механизмы ее реализации. Тут для предметной области учета удалось придумать компактную и полную модель, представимую в специальных диаграммах («диаграммы плана счетов»). Ее напрямую проектируют и изменяют со временем совместно с заказчиком, а специальный интерпретатор этой модели («учетная машина») гарантирует безошибочность.
• «Domain Driven Design в условиях разработки распределенных приложений (Николай Гребнев, AgileDays-2011)». «Domain Driven Design» как раз одно из направлений «моделеориентированной разработки», популярной среди корпоративных .NET-разработчиков. Однако с таким подходом к разработке распределенных приложений возникает куча сложностей, о чем и был этот доклад.
• «Все в ваших руках — быть готовым к изменениям в системах БД (Андрей Совцов, AgileDays-2011 )» — Производитель инструментов для работы с реляционными СУБД напоминает, что издревне, скелетом информационных систем (а также архитектурой и моделью) являлись реляционные базы данных, и что правильные инструменты работы (ER/studio, DB Aristan, Performing center, DB optimizer, Change manager) — сильно облегчат развитие вашей информационной системы.
• «Модель принятия инженерных решений — ключ к ответам на технические вопросы (Евгений Кривошеев, AgileDays-2011)» — «Что такое хорошо и что такое плохо в проектировании, аналитике и документировании». Изначально доклад даже назывался вызывающе просто — «42», намекая на то, что это и есть окончательный ответ на все эти вопросы.

Разработка

• «В погоне за качеством. Code Review (AgileDays-2011)» — Зажигательное шоу, что-то среднее между парным конферансом («Привет Бим! Привет Бом!») и проповедью среди неверных от двух известных евангелистов практик экстремального программирования.
• «Непрерывная интеграция при разработке баз данных (Владимир Бахов, AgileDays-2011)» — Скорее не про Continuous Integration, а про совокупность практик ведения, тестирования, и деплоймента реляционных СУБД.
• «Практики «Экстремального Программирования» в оффшорном проекте (Сергей Андржеевский, AgileDays-2011)» — добротный рассказ об eXtreme Programming на основе своего опыта. Ибо SCRUM/Kanban штуки весьма общие, хоть в личной жизни используй, хоть в строительстве, а XP — именно программистские практики. И если даже не применять, то хотя бы знать о них обязательно.
• «Шаблоны «Асинхронный фильтр» и «HasValue» в разработке desktop приложений (Олег Клинчаев, AgileDays-2011)»

Тестирование

• «Тестирование встроенного ПО: альтернатива классическому TDD (Дмитрий Овечкин, AgileDays-2011)» — в разработке для девайсов, если нет симулятора и перед запуском каждого бинарника нужно заново прошивать сборку на маленькую флеш-память — места для классических юнит-тестов нет. Зато у девайса (в отличие от сложного GUI), есть четкие интерфейсы, и пользуясь ими можно написать кучу дешевых и гибких скриптовых автоматических тестов.
• «Почему я не люблю огурцы и фитнес — плюсы и минусы BDD и ATDD (Алексей Баранцев, AgileDays-2011)» — Атака на инструменты Fitnesse и Cucumber, которые вроде как должны облегчить жизнь тестировщикам (и уволить многих из них), а на практике, как «морская свинка» — не облегчают жизнь аналитикам-заказчикам, и не заменяют тестировщиков. Интересен не только доклад, но и жаркая дискуссия после — в зале было много активно несогласных, имеющих удачный опыт использования этих инструментов.
• «Как сервисному отделу не стать бутылочным горлышком (Юля Нечаева, AgileDays-2011)» — В Agile-принято, что тестировщики внутри команд, а отдельные «отдел тестирования» или «департамент документирования» являются классическим антипаттернами, «как создать deadlock на пустом месте» (ни у кого в зале, например, такого уже не было). Ну а что делать тем, у кого это тем не менее так? («…Мы сами знаем, что она не имеет решения, — сказал Хунта, немедленно ощетинившись. — Мы хотим знать, как ее решать.©»). Полезные практики — как тестировать еще до разработки, как бить в слабые стороны разработчиков, чтобы завертывать сборки с багами обратно максимально быстро и т.п. И кстати, только на нетестерской конференции от тестера можно услышать правду, что «тестирование не самодостаточно».

Блиц-доклады

Особняком выделю блиц-доклады. Для тех, кто привык к краткости YouTube-роликов, 8-10 минутные доклады, которых можно просмотреть на одном дыхании.

• «Пуассоновое горение сроков (Андрей Бибичев, AgileDays-2011)» — Лучший (IMHO) блиц-доклад. Почему все ошибаются в оценках? Почему оценки надо умножать на PI? Строгая математика докажет, что вы не виноваты в срыве сроков! (Близко к «Черному Лебедю», для тех, кто в курсе).
• «Agile. Путь от хаоса к потоку (Николай Алименков, AgileDays-2011)» — «Сначала был Хаос, … затем он сгустился и появился Agile, началась эволюция, и Авраам родил Исаака… Agile породил Lean…». Взгляд на эволюцию методологий со стороны тех, у кого в «доаджайлный» период был не «RUP/CMMI 5 уровня/SixSigma», а реальный бардакХаос, и наконец-то появились какие-то вменяемые процессы.
• «Agile — вид из окна тренажёрного зала (Алексей Солнцев, AgileDays-2011)» — «Хочешь похудеть и внедрить SCRUM — спроси меня как!»© Автор попал в ситуацию, когда осознал, что потерял форму, а компания — что теряет последних заказчиков. → … → И результат → -15кг, +девушка→жена, +компания, в которой не стыдно работать.
• «Ахиллес и черепаха. Разумный подход к работе над крупными клиентскими проектами (Юрий Гугнин, AgileDays-2011)» — Дизайнер-менеджер про ужасы гигантомании крупных заказчиков, приводящих либо к epic failам, либо к очередному УГ в едином корпоративном стиле. Альтернатива — «есть слона по частям», в каждой из частей максимизируя и креативность, и customer satisfaction.
• «Agile и жизнь (Александр Калугин, AgileDays-2011)» — как аджайлизировать рабочие, но непроектные задачи — инфраструктурные или личное карьерное развитие. И предлагалось не городить параллельно два скрама («проектный и непроектный»), а засунуть все это в основной, проектный «Скрам»: и персональный бэклог сотрудника, и стратегический бэклог компании.
• «Зачем нам это надо? или Как продать Agile команде! (Михаил Карпов, AgileDays-2011)» — Автор тоже заметил, что движуха к Agile идет с двух сторон: от измученных нарзаном жестким «CMMI»-водопадом компаний, когда их освобождают от кучи бессмысленной работы — но такое в основном на Западе, у нас только в очень крупных компаниях. А в России же движение идет от бардака, и продавать «Agile-свободу» бессмысленно, надо продавать решение проблем («лишняя работа из-за бардака с требованиями и т.п.»), и делать это постепенно.
• «Поведенческая модель DISC в Agile проектах (Кирилл Климов, AgileDays-2011)» — Yet Another (в дополнении к MBTI/Майерс-Бриггс/Адизесу/Белбину/Юнгу...) DISC-классификация людей, тоже, как и большинство других (включая теорию групп крови…), из середины прошлого века, когда казалось, что если разложить многомерного человека по какому-нибудь базису — то дальше простейшей линейной алгеброй и арифметикой можно этими людьми эффективно рулить. Плюс практические выводы, как это использовать в SCRUM-командообразовании.

---