Наверх ▲

Принципы Деминга и Agile

Михаил Кумсков Михаил Кумсков Эксперт Luxoft Training по методологиям управления требованиями, использования методологии RUP и инструментария IBM Rational, доктор физ.-мат. наук., профессор кафедры вычислительной математики механико-математического факультета МГУ им.М.В.Ломоносова.

Михаил Кумсков: Очень приятно, что была сделана пауза. Как по хорошим правилам, мы начинаем доклад не раньше, чем он был объявлен. Это такая хорошая практика. С другой стороны, мне как докладчику [кхм…] было видеть, как народ уходит тихо из зала.

Что я хотел рассказать. Есть такая фраза: "Чем ближе к источнику, тем меньше воды". Источником Agile являются принципы, что самое главное – это человек. Впервые эти принципы неявно были сформулированы в 1950-х годах. Причем сформулированы и внедрены на очень большом предприятии – это "Toyota".

Сегодня много говорилось про процессы, про менеджмент. Процессы, так и так, есть – другое дело, записаны они или нет. А вот как сделать так, чтобы люди эти процессы, как традицию (мы всегда делаем так, как было сказано), исполняли. Исполняли радостно, получали удовольствие от работы, и получал заказчик от работы. Это было сформулировано в 1950-х годах. 

Было сформулировано Демингом (Deming) – его называют статистиком, экономистом. Он опубликовал книжечку. Эта книжечка в Америке не была принята, сказали: "Это все академическая наука, а мы дело делаем".

Японцы, 1950-е годы – надо было восстанавливать страну, нужны были какие-то идеи. Ресурсов у них не было, ну, вот они Деминга пригласили, сказали: "Делай! Сделай, как ты считаешь". 

Собственно, оказалось потом, что эти принципы были переоткрыты, но явно так не сформулированы.

История этого доклада начинается 5 лет назад. Сюда в Москву приезжал Кент Бек (Kent Beck) на недельку. Я вместе с Асхатом Уразбаевым от фирмы "Luxoft" был послан на этот семинар послушать, о чем будет говорить Кент Бек про "экстремальное программирование". 

При этом я как человек, который 10 лет занимается методологией, внедрением процессов в разных организациях, до этого семинара считал, что Agile XP – это методологически грамотный способ развести заказчика на деньги. То есть требования не пишем, но заказчик за все платит. Сделали –  ему не понравилось. Он платит – мы переделаем. Нет проблем! Если он не хочет с требованием поработать предварительно, методически это можно – да, это называется Agile XP. Нормально. Ты платишь – мы переделаем. Как скажете!

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

Известно, что есть два вида менеджмента:

I.Менеджмент задачный. Он предполагает, что если каждому раздать задачку activity, и он ее вовремя выполнит – проект будет успешный.

Правильно? Так менеджеры делают? Дают, раздают задачки. Сделал задачку вовремя – ты молодец. Если что-то не так, значит, что-то не так. Обычно, на этапе интеграции выясняется.

II.Есть другой менеджмент. Он говорит, что локальные метрики оценки работы (вовремя ли ты сделал) могут не работать в глобальном этапе, и что ключевой фигурой фирмы и самым главным, что есть у фирмы, является Клиент, Заказчик. 

Собственно, заказчик должен возвращаться. Поэтому мы должны работать качественно. А за качество отвечает система. Вот – некое требование. 

Если что-то делается некачественно, клиент не приходит, то Деминг сказал, что в 85% случаев виноваты не конкретные исполнители, а системы, регламенты работы.

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

Базовые картинки. Обычно ее всегда приводят, чтобы показать масштаб бедствия. Standish Group, который показывает, что большая часть проектов не успешна. 

•Зелененькие – успешные проекты: уложились во время, деньги, заказчик доволен. 

•Основная масса (где-то около 50%) превышают время и деньги, но завершаются. 

•Где-то от четверти до пятой части проектов прекращаются на марше, поскольку инвестор видит, что проект пошел не туда, риски не минимизируются; проще оставить проект, чем дальше терять деньги.

При этом когда топы смотрят на эту картинку… Смотрят, что 1994-й, 1996-й – 15 лет и ситуация не меняется. Мы теряем, индустрия теряет огромные деньги. Почему не меняются? Что происходит? 

Дома строим вовремя, дороги строим вовремя. А софт – посмотрите. Безобразная картина! Непонятно что происходит. 

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

Давайте дальше посмотрим. Факторы, влияющие на успех.

Из этих факторов видно, что ключевыми моментами является понимание, что надо заказчику, требования. 

Ключевой фактор "поддержка со стороны высшего руководства" – это фактор внедрения системы. У внедренцев, известно, есть три основные принципа успешного внедрения проекта:

Первый принцип: поддержка со стороны высшего руководства,

Второй принцип: поддержка со стороны высшего руководства,

Третий принцип: поддержка со стороны высшего руководства. 

Поскольку при внедрении информационной системы меняются информационные потоки, и средний менеджмент теряет власть монопольного владения.

Дальше посмотрите требования: 

участие в пользователя в проекте, 

четко поставленные цели, бизнес-цели проекта (что изменится, когда проект будет успешно развернут в фирме, что у бизнеса изменится – ориентация клиента на качество), 

минимизация объема работ, 

стабильные требования, 

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

Смотрите дальше: это просто статистика Standish Group, где основные ошибки лежат. Это ошибки в понимании, что надо заказчику, и, соответственно, в проектировании этих вещей. 

При этом есть очень простое определение, что такое качество – это удовлетворенное ожидание клиента, заказчика. Все ожидания записать не возможно. Мы что-то пишем (требования), но многое лежит под водой. Когда мы показываем продукт, человек видит, заказчик видит и дает нам обратную связь, feedback.

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

Базовая картинка как бы отвечающая на вопрос "почему же проекты не успешны?" – я привожу в метафоре "Хомячок - Медведь". 

Она из известного анекдота, когда на нижегородскую ярмарку весной приехал мужик с большим медведем, стал ходить по рядам, вглядываясь в лица продавцов. По рядам разгоняет покупателей, мешает работать. К нему послали мальчонку. Он спрашивает: "Ты чего хочешь?" Говорит: "Я на этой ярмарке осенью хомячка купил. Вот ищу, кто продал". 

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

Называется "работа в режиме трудового подвига". Резко возрастающая сложность, а мы к ней были не готовы. Управление изменениями не ставили, конфигурацию управления не ставили, правильные отношения с заказчиком не выстроили – собственно, появляются соответствующие проблемы. 

Вот эта неожиданность роста проектов приводи к тому, что заранее надо как-то правильно ставить формальные и неформальные процессы.

Один из известных способов решения проблем… 

Кстати, я сталкивался несколько раз с ситуацией, когда слово "Agile" подразумевается с итерационной разработкой – это синонимы, как оказывалось. 

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

В Agile это 2 недели, общая рекомендация – 4 недели.  Четыре (плюс-минус две недели) – общая продолжительность этой временной рамки, когда мы даем релиз и показываем его заказчику. 

Вот здесь появляются те ожидания, которые мы не документировали. Заказчик говорит свои (то, что называется change request): это не так, это не так, это не так. Следующая итерация – у нас получается два источника работ, задач. Фичи следующей итерации и change request'ы, которые у нас получились. 

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

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

С такой ситуацией столкнулся Кент Бек, когда ему в Германии дали умирающий проект, который вышел из всех сроков и графиков, и сказали: "Что хочешь – вытаскивай!" Люди были демотивированы: шаг вправо, шаг влево – расстрел, наказание. Кент Бек сформулировал несколько очень интересных принципов.

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

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

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

 12

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

Приведу пример, который был задан Кенту Беку на семинаре. 

Встал российский PM и говорит: "Мы работаем по вашей методологии "экстремальное программирование" – классно работаем, все хорошо, все получается. Но есть в команде девочка, младший тестировщик – она не справляется со своими задачами, которые ей дают. Она хохотушка, душа общества, пирожки печет, всем кофе варит, мальчики перед ней хвосты пушат, но как тестировщик не справляется". 

Увольнять ее или нет – спросили у Кента Бека. 

Он говорит: "Ребята, команда как работает? У команды нет проблем, все нормально. Чего вы к ней пристали? Команда работает нормально – она в команде. Она как катализатор: в реакцию не вступает, без нее реакция не пойдет. Она в команде". 

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

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

Таким образом, получается, что метрики, которые поставлены – там вставлен процесс (это Деминг сказал, сейчас мы это посмотрим) постоянного улучшения.

Давайте посмотрим. Предположим, вы на новую фирму устроились программистскую. У вас глаз не замылен и вы сразу все косяки видите. Вы подходите к начальству. "Слушайте, ребята, тут можно улучшить", – говорите вы PM'у или начальнику отдела. Что говорит вам начальник отдела? "Тебе что сказали делать? Вот иди и работай! С верху виднее. Нам скажут – мы улучшим, а сейчас…" Помните: "Тебе что сказали? Дыни стеречь. А ты что делаешь?"

А вот если поставлен процесс всеобщего улучшения, понятно, кому сказать, что можно улучшить, кто это должен из топов рассмотреть, как это улучшать, и какой ты получишь benefit, если это будет принято. Такой человек называется "владелец процесса" – это один из топов, который может поправить регламенты (формальные и неформальные), чтобы дело пошло лучше. 

Фактически, такой разбор полетов в Agile должен проводиться в конце итерации. Смотреть, что не так, что так, что надо поменять – это называется "заточка пилы" иногда в некоторых методологиях.

Собственно, давайте посмотрим принципы Деминга. Кто такой Деминг.

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

Мы увидим потом квинтэссенцию принципов – так называемый цикл Деминга по менеджменту, plan–do–check–act. Он показывает, что любой экземпляр процесса задач, который сделан (в Agile это итерация) – в конце надо мерить, что мы хотели, посмотреть, что мы хотели, достигли ли мы результата и поменять регламент, улучшить. Ориентация на совершенство становится ключевой не только у людей, отвечающих за тестирование качества, а у всех.

Собственно, понимание того, что Agile – это не только программный менеджмент, что эти принципы появились раньше (стал в докладах появляться, появились японские слова "kaizen", "kanban", "lim-разработка"). Получилось, что та революция на массовом производстве товаров в крупных фирмах, которая произошла в Японии, о ней в Америке очень интересно узнали. 

В 1970-х годах произошел автомобильный кризис в Америке. Появились дешевые, надежные и мало потребляющие бензин автомобили, которые обрушили продажи "Ford", "Chrysler". Очень хорошо эта ситуация описана в книжке "Я менеджер" Ли Якокка (Lee Iacocca). 

Собственно, только после этого американские(?) топ-менеджеры стали интересоваться, что же они там, в Японии, сделали. Фактически конец 1970-х, начало 1980-х годов – это флаг качества у американских производителей. Эти методологии назывались "Total Quality Management", "6 sigma", "Just in time" – оболочки были разные, но принцип был заимствован у японцев.

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

Смотрите, что получается. Что сказал Деминг. Три аксиомы.

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

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

Помните, Владимир Ильич Ленин говорил про революционную ситуацию? Нет революционной ситуации: низы не хотят, а верхи не могут управлять – и ничего не изменишь, революции не будет. Пытались в Латинской Америке сделать революцию – не получилось. 

Система должна быть нестабильна. Двери к нестабильности системы открывает менеджмент. Если менеджмент, топы не хотят ничего менять… Помните эту фразу: "когда все есть, ничего не надо"? Если ничего не надо – ничего и не получится. 

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

Третий (собственно, самый важный) ключ менеджмента – за качество отвечают топы, за качество отвечает руководство фирмы. Не PMы, а руководство фирмы! Самое ценное у нас – клиент, заказчик, и за качество отвечают топы. Что это значит? Значит, топы делегируют свои полномочия по изменению вниз: средний менеджмент, PM'ы. Флаг качества спущен оттуда, и ворота для изменения системы приведения открыты.

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

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

Второе. Конечная цель всего этого хозяйства – не достижение результата. Несколько раз сегодня слышал: "Задача PM'а – достичь результата". Если этот результат – качество, удовлетворенный заказчик, то да. А если это результат, чтобы все вовремя выполнили свои задачи, в срок, который я вам поставил – то нет, это не результат. 

Получается, ваша цель (это очень актуально для интернет-компаний) – стать конкурентоспособным и остаться в бизнесе. Как все быстро меняется на рынке интернет-компаний! Получается, вот она цель – остаться в бизнесе и обеспечить рабочие места. Вот первый принцип. 

Едем дальше. Второй принцип: новая философия ориентации на удовлетворение клиента. Получается, что мы не можем уживаться с задержками, ошибками, дефектами, браками. Соответственно, мы берем ответственность (топы) за то, чтобы клиент был удовлетворенным. Соответственно, добиться перемен, изменить менеджмент – фактически, изменить мышление в те времена, изменить метрики, что значит "мы хорошо работаем". В результате стабильность качества определяет стабильность предприятия.

Как определить, что такое качественно, что такое не качественно.

Контролировать все время: контролировать запчасти, контролировать, как идут работы. Хорошо. А кто будет контролировать тех, кто контролирует? Контролеров кто будет контролировать? Они хорошо контролируют свою работу? А кто будет контролировать тех, кто контролирует контролеров? Получается, что если меня начинают контролировать, я же все равно их обману. Правда, ведь? Даже интересно становится! Он меня контролирует, а я внизу все равно уйду от этого. 

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

Типичный пример. Я грузчик, перевожу стекла, пластиковые окна. Я вижу, что мне грузят окно с разбитым стеклом – я его должен буду устанавливать. Я скажу, чтобы мне не грузили, или не скажу? Мое собачье дело какое? Я –  грузчик! Мне сказали отнести – я положил. 

Формально это не мое дело, правильно? А по жизни, если так, я точно скажу: "Ребята!.."

В "Toyota" это было вообще сформулировано очень круто: если я вижу качество, я могу остановить конвейер. Представляете, рабочий конвейер "ВАЗ" останавливает и говорит: "Ребята, тут у вас штучечка плохо сделана". Представили? А там было дано право, и никто не скажет, что ты такой нехороший человек, мы тебя уволим сразу. Ему было дано право конвейер останавливать. 

Получается, что мы встраиваем качество, и у нас есть стат-поддержка по Демингу (вообще он статистик по началу) статистического подтверждения встроенного качества. 

Из этого статистического подтверждения появилась методология качественной разработки "6 sigma", которая предполагает, что на миллион изделий у нас всего 3,5 дефекта. Рекомендую для тех, кто хочет это хозяйство посмотреть, почитать книжечку: есть хорошая книжка на русском языке "6 sigma для чайников", которая сейчас проросла в методологию вообще улучшений постановки процессов. По-английский "6 Sigma For Dummies ". Английский вариант в интернете есть, русский у меня только бумажный.

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

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

Есть очень простая лакмусовая бумажка, в фирме поставлен процессный менеджмент или нет, или работаем позадачно. Нужно просто сказать: "Ребята, дайте мне должностные обязанности сотрудников". Если в должностных инструкциях написано, что в обязанности входит, в том числе, улучшение процессов (это в должностных инструкциях) – значит, процессный менеджмент есть. 

Значит, понятно, кому сказать, что нужно покрасить потолки в синий цвет, поскольку производительность труда программистов по статистике улучшается на 1,5% – я об этом прочитал. Я делаю какой-то запрос, и топ менеджер (это обычно владелец этого процесса), который обязан его рассмотреть, принять или не принять соответствующее решение. Если он принимает, я получаю какой-то бонус (benefit). 

Например, в фирме "IBM" в 1980-е годы автор рацпредложения, которое было внедрено, получал 10% прибыли фирмы за год. Топы в своих книжках пишут: "Несколько раз мне приходилось выписывать чеки на сотни тысяч долларов". То есть выгода была в год больше миллиона долларов. Это значит, постоянные улучшения вставлены в регламенты фирмы.

Обучение. Причем обучение (иногда говорят "knowledge transfert" – передача знаний) делается не только в формальной обстановке, но и на рабочих местах. Мы проводим обучение на рабочих местах. Наша практика "парное программирование" – это и есть обучение на рабочих местах, когда пара программирует, мастер и новичок.

Эффективная работа. За что отвечает менеджмент? Вот очень хорошая фраза (фактически, в Agile проектах она перекликается): менеджер не должен мешать работать сотрудникам, он должен их оберегать от внешних воздействий, не мешать работать, оказывать помощь. А если вы делаете проверки и инспекции (не для того, чтобы "вот ты нарушил – я тебя накажу") – для того, чтобы помочь. 

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

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

Дальше. Помните, "начинай перестройку с себя"? 

Отказаться от лозунгов. Фактически, лозунги разрушают. Мы видим, что говорят лозунги – и видим, какой есть реальный менеджмент. Люди не дураки. 

С другой стороны, обычно низкое качество, низкая производительность вызваны системой: рабочий ничего поправить не может – правила кривые. А у меня никто не спрашивает: "Подскажи, что можно изменить". Хотя мне снизу все видно. 

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

Лозунги…

Дальше квоты и нормы. 

Что-то считать надо. Метрики нужны. Собственно, метрикой работы по итерациям является, сколько функционал уже работает. Не так как мы "сколько работ по плану сделали", а сколько уже фич сделано и сколько осталось сделать.

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

Получается, что если ты делаешь квоты "вам по плану, план по валу" и, наказывая, этого не получаешь, фактически это часто основано на страхе. Ты не выполнил план – премии не жди. Очень простая формулировка.

Дальше. Получается, понимание, кто потребитель, как мы можем ему лучше услужить и обслужить еще лучше – меньше обещать и больше производить. Это ощущение качества получается. А дальше работники должны гордиться. 

В частности, в конвейерном принципе "Toyota" на последних этапах конвейер был остановлен, они собирали машины бригадами. При этом бригада сама принимала решение, набирать людей к себе или нет (то есть,  маленькая такая Agile команда). У них было личное клеймо (у этой бригады), которое ставили на "Toyota", показывая: "это мы, мы сделали, мы за это гордимся". Очень плохо, если пришла (рекламация) на наше клеймо – это совсем не допустимо. "Мы гордимся этой машиной".

Во все учебники по процессному менеджменту вошла ситуация. 

Уставший работник "Toyota" вечером идет с работы домой. Видит припаркованную "Toyota", у которой неправильно стоят дворники (эта "Toyota" не его), совершенно на автомате поправляет дворники и идет дальше. Потому что это – "Toyota". 

 

Вот пример отношения к марке, к гордости.

Дальше соответствует принцип к совершенствованию не только внутри, но и вовне. Поощряем стремление к самообразованию, к самосовершенствованию. У них там кружки по качеству, они передают знания – система налажена, реализующая этот принцип.

Соответственно, как сказка начиналась (менеджмент должен за это взяться), так сказка кончается. 

Непоколебимый принцип высшего руководства постоянного улучшения качества – вот ключ. 

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

Для того, чтобы его принципы были наглядны, он ввел понятие принципа Деминга, который учат во всех топ-менеджерских и менеджерских школах. Принцип Деминга – "plan–do–check–act".

Обычно ситуация следующая: у нас есть то, что надо сделать, план, регламент работ – и мы его делаем. После этого, если никто не жалуется – классно! А Деминг говорит: "А вот и нет!" 

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

Act – это изменение процесса, изменение регламентов работ. Фактически в интернет-проектах в ходе итерации – это цикл итерации. Вот она – итерация. Но всегда в конце итерации мы "затачиваем пилу" – проверяем, что шло так или не так, и меняем регламенты, меняем процесс. 

"Заточка пилы" – это метафора из прекрасной книжки Стивена Кови (Stephen Covey) "Семь навыков высокоэффективных людей". Это седьмой принцип ("заточка пилы"), основанный на метафоре. 

Прохожий видит, как в жаркий солнечный день два мужика пилят большое толстое бревно тупой пилой. Он пять минут посмотрел – они за пять минут ничего не распилили. Он говорит: "Извините, я вмешиваюсь, но пилу надо заточить". – "Нам некогда, нам пилить надо". 

То есть надо делать промежутки и осматриваться. Я на самом деле пилил тупой пилой (она, правда, была бензо-), но после заточки совершенно другой уровень работы. Мы остановились, заточили – все по-другому совсем идет.

Итак, цикл Деминга. Здесь правило: то, что меряешь, то и получишь. Фактически, получается, что правильная установка "что же мы хотим", включение осознанности, что мы хотим достичь в измеримых коллективах, и почему мы этого не достигли, что не так – здесь участвует вся команда. Почему не так, что можно изменить.

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

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

Манифест. Собственно, вот этот манифест. Я рассматриваю Agile как попытку обобщить успех методологии Кента Бека и привнести, найти там общие вещи.

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

Работающее software, метрикой является, сколько фич мы сделали уже. 

Взаимодействие с customer'ом, то есть customer (заказчик) может вносить изменения по ходу. То, что он вносит изменения, это хорошо, потому что он получается лучший продукт. Плохо, если мы к этому не готовы. 

А также responding to change. Отсюда следует, что для того, чтобы с customer работать, у нас должно быть с ним доверие, траст. А это значит, контракт, по которому мы работаем с заказчиком, не должен быть fix price. 

Понятно, что я говорю? Fix price проекты. Agile не работает на fix price проектах, Agile работает на проектах time and material – когда с заказчиком оговаривается объем работ, и он за них платит. То мы сделали, не то – если мы это обговорили, то сделали.

Вот история. Я считаю, что успех "экстремального программирования" Кента Бека привлекло внимание к этому направлению. Финансисты честно провели эксперимент и увидели: качество повышается, value повышается, удовлетворенность потребителя повышается – собственно, с этого в него(?) стали вкладывать деньги. 

Сейчас "IBM" развернулся на Agile. Существуют бесплатные проекты – например, "Team Concert". До девяти пользователей бесплатная, можно сказать, лицензия. Там в одном флаконе управление версиями, конфигурациями, визуальное моделирование – а дальше проект масштабируется.

Самое главное – удовлетворить пользователя. Видите, как перекликается с Демингом – Деминг то же самое говорил. Соответственно, welcome changing requirements – даже позже, за это должны платить. В проектах (Agile, не Agile), есть фаза, когда мы готовы изменяющиеся требования (как строить дом-то – дом надо построить) определить, а потом надо строить дом. Если что-то меняется, заказчику надо сказать, сколько это будет стоить с точки зрения времени и денег – мы можем выбиться из ритма создания продукта.

Working software – те фичи, которые работают (функциональные, не функциональные), являются основным измерением, как идет дела, а не план работ, так скажем.

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

Траст, доверие – ключевой момент. Это очень сложно. Доверие можно очень быстро разрушить, но если оно сделано, команда работает хорошо.

Face-to-face conversation. Да, это правда, но для больших команд вопросы масштабированности – это уже не так. Если у нас 100 человек, то принципы ориентации на качество всей фирмы (включая топ-менеджмент) позволяются эти совместно ведущиеся проекты, совместные группы тоже как-то правильно зарядить и помогать друг другу. 

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

Простота. Фактически, Кент Бек здесь сделал такую метафору, что мы требования детализируем только под текущую итерацию. Это он сравнил с методологией "Just in time" в производстве, когда нет склада. Мы заранее не пишем требования, у нас нет склада требований. 

Технология организации производства "Just in time" означает, что у нас нет склада. Из трейлеров запчасти сразу поступают на конвейеры. Нам не надо их на склад оприходовать, писать листочки и где-то класть, а когда нужно – искать и снова писать листочки, что мы со склада сдали. Этот этап траты (накладных расходов) снимается. 

То же самое с требованиями. Есть фича крупноблочная, а реальные требования пишутся в начале. Соответственно, чтобы программисты читали требования, их очень просто сформулировать: сначала пишем тесты (test driven development), а потом уже пишем программу. А чтобы написать тест, надо понять, что нужно. Test driven development – когда заставляют программистов наконец требования прочитать и написать код, который потом можно делать refactoring.

Самоорганизующаяся команда – ключ. Если нет самоорганизации, если менеджмент делает мелкий контроль – никакого Agile не будет.

Вот практики Кента Бека. Вот проверка качества – посмотрите, синеньким выделено. 

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

Здесь соответствие плану (как идет дела, как по плану) – здесь сколько фич мы сделали. 

Здесь команда и контроль – здесь лидерство, взаимодействие, ориентированное на заказчика. 

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

Здесь большой test consult – тут итерационно постоянно делают.

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

Семь основных практик – я думаю, вы их знаете, я их не буду здесь читать. 

Давайте посмотрим выводы, которые отсюда следуют. Они в разных методологиях явно сформулированы, перекликаются с интерпретацией, с принципами, изложенными Кентом Беком.

Сustomer – самый главный. Успех проекта – это знание неопределенностей и снятие их на ранних этапах. А также качество – это стиль жизни. Не тестировщики за него отвечают, точно совершенно – все отвечают.

А это Microsoft Solutions Framework Agile принципы – "Microsoft" тоже Agile'ом озаботился. Видите, для небольших проектов все эти принципы перекликаются.

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

Мне очень нравится это определение, что значит "правильный процессный менеджмент": сотрудники вовремя, правильно и качественно выполняют задачи, которые им формально никто не поручал. Они сами знают, что надо делать. 

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

Книжечки. Вот собственно книжечки Кента Бека, которые приведены. А также вот книжечки, которые можно почитать о том, как это было. Сейчас я посмотрю. Да, вот они здесь приведены.

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

Спасибо.

 (Аплодисменты).

Один-два вопроса, говорят, можно.

Вопросы и Ответы

Реплика из зала: Здравствуйте! Спасибо за доклад, хорошая теоретическая основа, которую вы преподнесли.

Михаил Кумсков: Хорошие идеи есть?

Реплика из зала: Идея хорошая. Мне больше интересно, как вы на практике пришли к этому. Я так понимаю, опыт у вас большой управления проектами, и вы работали еще до Agile.

Михаил Кумсков: Я вообще методологист, моя любимая методология – RUP, которая воспринимается иногда неправильно. Как неправильно? Если есть регламенты, их надо прочитать, а RUP прочитать невозможно до конца.

А пришел я к этому – Кент Бек меня… Я увидел принцип. Должна быть звезда. Есть много вещей, которые…

Реплика из зала: Есть лидер, который ведет за собой, дальше за ним идут вполную.

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

Реплика из зала: Мой вопрос именно в том, как на практике вы переходили со старых RUPовских проектов на Agile проекты.

Михаил Кумсков: Есть RUP-Agile. Смотрите, мы как оцениваем людей. Очень простой первый принцип. Как вы оцениваете: люди нормально работают? Как вас оценивают, когда вы приходите на работу? Вовремя пришел, вовремя ушел, задачи выполнил – молодец.

Реплика из зала: Нет, я говорю не об оценке, я говорю о переходе.

Михаил Кумсков: Так вот смотрите! Перво-наперво, надо изменить правила оценки хорошо или плохо кто как работает. Есть командный метод хорошо или плохо ты работаешь. Как военные говорят: "Любую задачу выполним, поставленную родиной". Правильно? У него три авианосца – он сейчас задачу выполнит. Ему поставили – он там всех помял.

А другой момент, когда говорим: "Ребята, клиент – самое главное, и задача в том, чтобы этот проект сдать так, так, так и идти, постепенно наращивая".

Реплика из зала: А вывод в чем?

Михаил Кумсков: Вывод в чем? Очень простой. Для того, чтобы… Я, кажется, понял с чего начать. У вас проблемы есть? У вас проблемы с проектами, с качеством есть или нет?

Реплика из зала: У меня? У меня лично нет.

Михаил Кумсков: Если у вас лично нет – вам ничего менять не надо, все хорошо.

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

Михаил Кумсков: Первая проблема, с которой я столкнулся (я ее метафорически переформулирую) – это проблема, с которой сталкиваются родственники алкоголика. Знаете, почему алкоголизм трудно лечить? Потому что человек не считает, что он больной. 

Главная проблема, с которой мы сталкиваемся – начальство не считает, что нам что-то надо менять. Вот главная проблема, с которой мы столкнулись. Вы снизу видите, а они говорят: "Ребята, да вы что! Какие вам "RequisitePro", какие вам розы (Rational Rose). Работать лучше надо!"

Реплика из зала: У вас Agile снизу вверх пошел?

Михаил Кумсков: Нет, там получилась неустойчивость: низы не хотят, а верхи не могут. Реально получилось, что если продолжаем дальше, мы этот проект завалим, и следующий крупный проект тоже завалим. Фактически, понимание, что что-то идет не так, и если мы еще так полгода поживем – будет совсем плохо. А люди ногами голосуют. Очень просто. Ты им говоришь – тебя посылают.

Реплика из зала: У вас это эволюционно произошло, правильно я понял?

Михаил Кумсков: Да! Получается, что нужно, чтобы начальство поняло, что надо что-то менять. Это значит, надо, чтобы все одинаково поняли, что меняем и зачем. Только тогда оно открывает дверь. Вот так.

Реплика из зала: Я понял. Спасибо.

Реплика из зала: Успею я задать еще один вопрос?

Реплика из зала: К сожалению, давайте остальные вопросы перенесем  в кулуары.

Михаил Кумсков: Спасибо.

Реплика из зала: Спасибо вам.

 

Комментарии

Нет ни одного комментария

Только пользователи могут оставлять комментарии

Возможно, вам будет интересно:

Ольга Павлова

Ольга Павлова

Владелец 80% компании «Собака Павлова»

Я абсолютно уверена в том, что большинство из вас вещь, которая называется словом "usability" еще не щупали руками. Или, может быть, щупали как-то случайно… В общем, не успели поиграть. Постараюсь рассказать о том, как в это можно поиграть. И где в нее можно играть.

Михаил Якшин

Михаил Якшин

Координатор команды разработчиков кластерной части Openstat.

Доклад Михаила Якшина об управляемом code injection в Apache Hadoop в системе интернет-статистики Openstat.

Олег Бунин

Олег Бунин

Генереральный директор студии разработки высоконагруженных интернет-проектов "Онтико".