SCRUM - часть 2 - "Состав участников"

Подолжение того что начато было вот тут.

В этот раз я хочу рассказать о составе участников методики SCRUM ("Скрам").

Сразу хочу поставить ударение на том что ключевым моментом эффективности методики является СМЫСЛ того что делается и зачем. Протокол и форма предлагаемые методикой лишь являются выражением этого смысла. Тупое соблюдение протокола без преследования смысла неминуемо приведёт к профанации и потере эффективности.

Как говорят классики этого жанра - "Если вы видите что что-то не работает и надо что-то менять - меняйте свою организации, не пытайтесь менять Скрам"

Невозможность применения Скрам организацией как правило является индикатором серьёзных дизфункций в её структуре или кадровом составе. Чаще всего организации пытающиеся применять Скрам натыкаются на эти дисфункции и делают вывод что Скрам им не подходит. Большинство из таковых стремятся скорректировать протокол лишив всю методику смысла и тем самым превращают свой метод работы в "Скрам-бат". Так и говорят в таких случаях - "We are using SCRUM but..."

( И так о кадровом составе методики SCRUM )

Auckland Waterfront

Вот! Получилось выбирать альбом для показа в слайд-шоу.

Оказыается кнопка на него спрятана под "Link to this album" (на которую надо кликнуть).

Breaking the praradigm principle

Пара слов о том как работает принцип "сломанной парадигмы".

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

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

Проблема "сплошной парадигмы" состоит в том что за решение задачи обычно берутся с одного конца. Кто-то берётся со стороны Средств, кто-то со стороны Ожиданий.

Самый модный нынче подход - UX или User Centerd Design по сути состоит в том чтобы исходить в построении решения исключительно из Ожиданий. В качестве аргумента в пользу этого подхода приводится как правило критика "старого" метода с подходом от Средств.

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

Проблема тут в том что парадигма конструкции Ожиданий и парадигма устройства Сресдств на самом деле ДОЛЖНЫ НЕ совпадать.

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

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

Оба подхода принципиально ошибочны и оба приводят в конечном итоге к провалу.

Решением является "сломанная парадигма"!

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

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

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