Автор
Энтони Лаудер (Anthony Lauder), англичанин, в разработке ПО с 1987 года, поработал в куче контор — Англия, Штаты (включая Силиконовую Долину), и в конце концов, на удивление, осел в Праге (Чехословакия).

Что важно понимать об авторе — это не методолог, не писатель, не тренер, не маркетолог-продавец, не фантазер, а достаточно успешный практик (разработчик, project and product manager, консалтер,…) у которого, наконец-то, дошли руки, отрефлексировать свое понимание и написать книгу.

В течение нескольких следующих лет консалтинга я стал замечать, что и другие люди задают похожие вопросы:

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

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


Software Project Cultures
Книга свежая, 2008 год, на бумаге вовсе не публиковалась, автор просто выложил ее в вебе http://sites.google.com/site/anthonylauder/SoftwareProjectCultures.pdf и она стала набирать популярность.

Путь очень схожий с книжкой Книберга — «SCRUM from Trenches» — свободная публикация привела к популярности, и к переводам добровольцев.

Так и здесь, нашлись переводчики на русский язык — Альберт Мустафин (кстати, коллега автора книги), сделал русский перевод (к сожалению, все-таки с кучей смысловых ошибок, если бегло читаете на английском — лучше ---), так что прочитать книгу можно в виде набора постов в блоге Алекса Орлова (о котором мы уже писали), а для желающих оффлайн чтения (на ебуках или КПК), есть и PDF-верстка (куда переводчик добавил немного картинок).


Рецензия Стаса Фомина

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

А ключевые идеи (в моем понимании) следующие. Вспоминая известный софизм Горгия «Если что и существует, то оно не познаваемо. Если оно и познаваемо, то знание невозможно передать…», понимаешь, что он прав — знание о эффективной разработке ПО очень трудно зафиксировать на бумаге — в виде текстов, регламентов, правил (даже эвристических), даже основанных на метриках и статистике. Все это не работает, получившиеся таким образом толстые своды best practices и методологий — не работают, являя собой лишь кладбища мертвой информации. В то время, как опытные ПиЭмы таки как-то набирают опыт и применяют его на проектах разных типов.

Так вот, первая мысль в том, что люди усваивают знания не с нуля, а в привязке к «общечеловеческому культурному слою», выражая новые сложные понятия из ITшных областей в виде метафор — живых аттракторов из общечеловеческой культуры. И упаковка знаний в метафоры — наиболее емкая и гибкая, позволяет адаптироваться к решению изменяющихся задач. В тему хочется процитировать широко известного в узких кругах Левенчука: «Задать правильную метафору -- это очень сильное действие. Метафора позволяет буквально увидеть одну систему "внутри головы", и потом пытаться перенести соответствующие образы на совсем другие системы» [1]

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

Очень полезно взглянуть (даже не читая книги) на #Ключевая таблица.

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

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

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

Т.е. некотором смысле это не конкурирующие равнозначные модели — «здесь мы делаем дизайн», а «здесь мы стараемся лизать заказчика», нет, скорее считается что каждая новая модель включает старую, т.е.

В любом случае, важно:

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

Note.svg Например, над одной конференции, я наблюдал классическую иллюстрацию — докладчик, рассказывая о usability, высказал мысль о важности понимания usability тестировщиков и вообще, важности сбора usability. На что один известный специалист задал неуменный вопрос «Зачем проблемы юзабилити тестировщику, его должно волновать только соотвествие продукта спецификациям». Классическое столкновение на уровне непонимания между «сервисной» и «заводской» моделью! Еще классный пример такого конфликта («спецификации против THE USER DOESN'T CARE») — это свежая история «Linux, memcpy, glibc, и чертов Flash» (рекомендую!).

Поэтому настоятельно рекомендуется не только ПиЭмам, но и HRам и маркетологам. Впрочем, книга интересна и разработчикам, и тестировщикам, ну в общем, читайте все!

Ключевая таблица

Доминирующие Метафоры ↓ Культуры → Заводская Дизайнерская Сервисная
Разработка приложений – это Конвейер Дизайн Архитектуры Удовлетворение клиента
Аспекты продукции Программы Жёсткие Гибкие Мягкие
Дизайн – это Проект Техническая деятельность Людская деятельность
Требования Записываются Моделируются Делятся
Аспекты людей ↓
Менеджеры – это Командиры и Надзиратели Лидеры Референты
Команды – это Рабочие Эксперты Сотрудники
Заказчики – это Покупатели Деловые люди Короли
Аспекты рисков ↓
Содержание Фиксировано Уточняемо Вечно меняется
Время – это Деньги Качество Изменения
Качество Проверяется Это Стабильность Это приёмка клиентом
Деньги – это Стоимость Производительность Незначимое
Аспекты Контроля ↓
Успех – это Соответствие нормам Продукция с правильным дизайном Счастливые Заказчики
Неудача Наказуема Код-Спагетти Выявляется рано
Растрата Небрежность Бюрократия Низкая ценность
Прогресс – это Завершение задачи Улучшение дизайна Частые поставки

Избранные Стасом Фоминым цитаты



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

Клиенты хотят вести с нами дела, если мы помогаем им в удовлетворении их самых критичных желаний. Это означает фокусироваание больше на их успехе, а не на своём личном. [5]

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

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

Вот почему я предпочитаю название Сервисная Культура в качестве метафоры для этих методологий. Я обнаружил, что эта метафора заставляет новичков исследовать ассоциации, в результате чего им приходят на ум образы, более соответствующие образам людей, которые уже используют «Проворные» методологии. [6]



Любые правки этой статьи будут перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».

Репликация: База Знаний «Заказных Информ Систем» → «Культуры программных проектов (Энтони Лаудер)»