Про UML, холивар и последующий холишит

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

Когда писался agile manifesto, все были утомлены фанатиками имеющихся на рынке методологий. Структурный подход и имеющиеся методики стали настолько тяжелыми, что рухнули практически везде. Но надо помнить, что изначально они были вполне работоспособными. По ним жили десятки лет, но однажды поняли, что накладные расходы на эти методологии слишком велики. Такова судьба любой хорошей методики – она обрастает деталями, диаграммами, чеклистами, чтобы разобраться во всем этом деле пишут инструкции, инструкции сводят в подборки документов, подборки перерабатывают в процессы – и оба-на! мы получили очередную мегатяжеловесную Методологию, доведенную до идиотизма детализацией и оснащенную армией фанатиков, которые борются уже не за успех проекта, а за чистоту канона – чтоб все было Как-Завещал-Великий-Ленин, и если проект от этого загнулся – тем хуже для проекта.

Похоже, то самое начинается с аджайлом. Мы недавно запускали новый проект. Проект со старта имеет довольно развесистую структуру. Представить графически эту развесистую структуру – довольно сложно. Однако для релиз плэннинга надо не только структуру представить, но и рамки очертить. Мы использовали для этого UML и Sparx Enterprise Architect. UML потому что юзкейс-диаграммы все с грехом пополам читают, Sparx – потому что удобно рисовать и все отрисованные юзкейсы можно поддерживать в синхронизации с Visual Studio Team System 2008, который используется на проекте. Соответственно затем пользуясь интеграцией Team System + Microsoft Office делаем релиз плэннинг – хоть в Excel, хоть в Project.

Подход исключительно прост, польза для проекта очевидна, удобство для команды знакомой с UML и Sparx – тоже очевидно. Рассказал про это камрадам в Питере. Что тут было! ЕСЛИ ВЫ ИСПОЛЬЗУЕТЕ UML, ЗНАЧИТ У ВАС НЕ АДЖАЙЛ! ИБО В АДЖАЙЛЕ СКАЗАНО – НИКАКОЙ ДОКУМЕНТАЦИИ! Дорогие камрады, это распространенное заблуждение. На самом деле:

  1. Если посмотреть множество диаграмм с примерами, хотя бы из книжек Бека или специальных изданий, то становится ясно – диаграммы вообще и UML-диаграммы в частности как визуальное средство коммуникаций очень ценились отцами-основателями.
  2. Аджайл не требует отсутствия документации. Если бы требовал – фотографии доски тоже были под запретом, потому что это хоть и кривая, но тоже документация. Аджайл требует минимальной и достаточной документации – и UML-диаграммы (при условии что у вас их все умеют читать) отлично эту задачу решают.
    С частным вопросом разобрались легко, но этот частный вопрос – следствие попытки превратить аджайл в некий догмат, довести его до абсолюта, и все что противоречит догмату – объявить неверным. Затем – требующим искоренения.
    Коллеги, напоминаю: изначальный посыл аджайла – ставка на умных людей и их умение думать, а не на процесс. То, что хорошо для проекта – это и должно входить в вашу методику. Все остальное – от лукавого.

Post Author

This post was written by who has written 29 posts on Agile.by.

  • http://yuri.shilyaev.com Yuri Shilyaev

    Денис, очень актуальное замечание. Я тоже как-то уже хотел написать нечто подобное.

    Все Agile-style методологии это прежде всего не process, а process framework. Т.е. что надо для конкретного проекта и для конкретной команды, то и хорошо. Не хочу сказать, что если просто использовать дайли-митинги, то можно называть это Agile’ом, нет. Но в целом надо подходить гибко к процессу и требованиям.

    Кстати, что касается использования UML. Если при этом гибкость управления требованиями не нарушается, т.е. клиент может вносить изменения при планировании очередной итерации, то собственно — в чем вопрос? 🙂

  • Konstantin Razumovsky

    Трудно не согласиться с моралью статьи, но пример С UML, по-моему, не на 100% подходит тут.

    Этот пример говорит не о том, что не надо следовать догматам, а о том, что кто-то просто не понимает, что такое Agile и приписывает ему какие-то мифические характеристики (как отсутствие документации).

    Вот если бы пример показывал, как фанатичное следование реальным (а не мифическим)принципам Agile может навредить проекту, это было бы в точку… Правда, на мой взгляд, большую опасность представляют как раз те, кто чрезмерно гибко трактует Agile 🙂

  • http://yuri.shilyaev.com Yuri Shilyaev

    Есть умные, есть дураки. Научи дурака богу молиться — он голову расшибет. 🙂
    Все фанатики — “дураки” априори.

  • http://thetorch.ru/ Денис Петелин

    Константину:
    “Вот если бы пример показывал, как фанатичное следование реальным (а не мифическим)принципам Agile может навредить проекту, это было бы в точку…”
    ок, ну вот смотри: Заказчик нам говорит – ребята, для меня главное – чтоб мы быстро получили демо с парой функций. Но – БЫСТРО, понимаете? Через неделю я должен показать его инвестору и взять деньги. Результат – выкинем на помойку. Поэтому тесты – в топку, автоматизацию – в топку, интеграция – давайте не тратить время на круиз контроль, проект такого размера не взападло собрать и проверить руками. А мы ему – нет, ты что: ты давай пиши тесты, мы пока развернем сервер интеграции, да вгрузим все в наш мингл…
    Ну и как следствие – Заказчик говорит “нафиг надо”, то есть проект умер не начавшись.