вторник, 3 сентября 2013 г.

Странная книга. Марри Кантор. "Управление программными проектами"

ПОРАЖАЕТ количеством ПОБЕДНЫХ реляций про RUP и UML.

Хотя отсутствие ПУБЛИЧНЫХ success story и настроение "в интернетах" - говорит об обратном.

Странно всё это....

http://www.slideshare.net/booksinslides/ss-5043474
http://www.ozon.ru/context/detail/id/1136908/

Книга - полезная... Но её настроение про "промышленный стандарт" и "множество вариантов использования" - настораживает...

Я эту книгу читал и раньше. Пару раз. Но в свете критики "UML - никому не нужен" - переосмысливаю, всё по-другому.

Приведу цитату из книги:

"НАИЛУЧШИЙ ВЫБОР
Лучше всего, если для разработки архитектуры программного обеспечения ваша организация выберет стандарт UML. Если разработка не будет создана на основе этого стандарта и не будет объектно-ориентированной, она никогда не сможет стать КОНКУРЕНТНОСПОСОБНОЙ".

На основании ЧЕГО автор так БЕЗАПЕЛЯЦИОННО это заявляет? Где success story? Почему он считает, что вправе "напялить шляпу гуру"? Где мотивация? Какие задачи решаем?

Нас с Максом и с Леоновым за гораздо более осторожные высказывания - "побили ногами" (http://habrahabr.ru/post/188604/). И были в общем-то - правы.

ГДЕ UML в Windows NT или "ядре Linux"?

Дальше - БОЛЬШЕ:

"Иногда покупатели и инвесторы настаивают на том, чтобы при создании архитектуры продукта разработчики руководствовались другими базовыми средствами. Если на этом настаивает покупатель, то с ним придётся согласится. Но даже в этом случае следует как можно больше пользоваться стандартом UML. Эта задача часто облегчается тем фактом, что многие другие подходы к созданию архитектуры имtют много общего со стандартом UML."

ОТКУДА это следует? Где мотивация? Какие задачи решаем? Где success story?

"Лозунги". Не более того. :-(

Дальше - БОЛЬШЕ:
"В любом случае избегайте использования идиосинкразитесчких схем. Если коллектив чересчур увлёкся ими, вы как руководитель должны быть встревожены и предпринять немедленные действия во избежание таких "отклонений". Примером таких действий может быть организация доступа к стандарту UML, обучение персонала или обсуждение необходимости и выгод соблюдения стандартов."

Блеск!!!

"Учение Маркса  - ВСЕСИЛЬНО, потому, что оно - ВЕРНО".

Хочется автору задать ОДИН ПРОСТОЙ вопрос - "а уж не про UML ли этот абзац написан?"

Вообще говоря - МЕЧТАЮ - написать книгу про "мой UML".. Но не ТАКУЮ. А с ПРАВИЛЬНОЙ МОТИВАЦИЕЙ.

Как говорил проф. Преображенский - "БРОНЯ, а не бумажка!"

Которую я "для себя" - НАШЁЛ. А вот для "массы" - похоже, что - что пока - нет.

МОТИВАЦИЯ. Это - главное. КАКУЮ ЗАДАЧУ РЕШАЕМ. От этого надо отталкиваться.

К книге Лармана (хотя она и ХОРОША) - у меня - примерно такие же вопросы (почему кстати "водопад" ХУЖЕ "итеративной модели" - так никто "на пальцах" - никто толком и не рассказал).

Про Фаулера - так я вообще - молчу.. Рассказал про "нотацию". И что? МОЛОДЕЦ! Но! "Какие вопросы и КАК решаем"?

Раньше я подобные "рекламные лозунги" - как-то пролистывал по-диагонали... А теперь - почему-то начал обращать внимание...

Наверное потому, что САМ ищу "мотивацию"...

Найду "мотивацию" - продолжу посты про UML.

Ну и в плане "лозунгов" -
http://msdn.microsoft.com/ru-ru/library/dd409465.aspx
http://ht.on.ufanet.ru/article.htm
http://ooad.asf.ru/standarts/UML/UMLSimple/

"Киты" нам голову морочат? Где "мотивация"?

4 комментария:

  1. Александр, тут вынужден с Вам поспорить.


    "Иногда покупатели и инвесторы настаивают на том, чтобы при создании архитектуры продукта разработчики руководствовались другими базовыми средствами. Если на этом настаивает покупатель, то с ним придётся согласится. Но даже в этом случае следует как можно больше пользоваться стандартом UML. Эта задача часто облегчается тем фактом, что многие другие подходы к созданию архитектуры имеют много общего со стандартом UML."

    Я, знаете ли, работал в инвестиционной компании. Т.е. "покупал" компании (включая IT-шные). И этот "бизнес" хорошо понимаю со всех сторон.

    Сценарий (парадигма, шаблон) работы консультанта-писателя ("фаулера").

    1. Написать книгу
    2. В книге побольше фраз, создающих комплекс неполноценности. Типа "если ты без UML, ты - профессиональный лох".
    3. Гонится волна а) ума "фаулера" б) UML-я как признака качества производства ПО
    4. Приходит инвестор в IT-компанию. Говорит - "а что, UML-я у вас нет? лохи! денег не дам"
    5. ... или дам, если UML внедрите
    6. Все бегут искать "фаулера" и платить ему за внедреж методы (UML-я). Как минимум - покупать книги.

    Самое главное во всём этом - что "фаулеры" об этом пишут ПРЯМО. Только немного нужно опыта, чтобы это видеть... причём даже не "между строк", а русским по белому.

    ОтветитьУдалить
  2. >>"Киты" нам голову морочат? Где "мотивация"?

    А никто не говорит про "нашу мотивацию". "Их мотивация" писать такие книги - очевидно.

    Кстати, на этом Borland и погорел. Повёлся. Начал развивать средства управления проектами/моделирование и т.д.

    Да, а ещё что обидно. Когда такой "пузырь" надувается - он потом лопается.
    И люди, сначала массово попав под влияние умль-стов, потом массово же в них разочаровываются. И это - плохо.
    Нам нужен новая UML-доктрина.
    Вот мы с Вами этим и занимаемся :)

    Такая же фигня с agile и scrum.
    Выдумали консультанты, чтобы немного зарабатывать себе на жизнь безответственной болтовнёй.

    Когда я на конференции Agile Days выступил с "спойлерским" докладом - меня чуть не выперли с кулаками. Здоровья не хватило :) Программисты...

    ОтветитьУдалить
  3. Всеволод, а в чем плох Agile и Scrum по конкретней, я например четко смог предоставить сколько у меня времени теоретически займет выполнение ТЗ(users story). Сколько работы осталось на текущий момент. Сколько действительно времени занимает разработка. И в конце концов, как далеко мне осталось идти до окончания спринта.
    Хотя в явном виде Скрам не получился. Получился Kanban с элементами Scrum и Agile. Выбрали сами то что посчитали нужным и ВОЗМОЖНЫМ...

    ОтветитьУдалить
  4. NameRec:

    Означенную книгу г-жи Кантор я не читал.
    Вместе с тем обратил внимание на время выхода этой книги, если не ошибаюсь - 2002 год.
    Это было время повсеместного UML-оптимизма, когда стройная концепция ООА/П/П созданная до этого Гради Бучем с сотоварищами, увенчалась разработкой первого стандарта UML.
    Насколько я помню, в литературе тогда преобладали настроения, что мол программы можно будет разрабатывать так же, как это делается со зданиями.
    Кстати, основные разработчики UML тогда работали в небезызвестной компании Rational Software, в которой появился, в частности RUP, опирающийся во многом на UML. В этой же компании были разработаны, самые мощные на тот момент инструменты для UML.
    Мне трудно судить, имела ли г-жа Кантор какое-либо отношение к означенной компании, позже поглощённой IBM. Если да — то не вижу в её заявлениях ничего неожиданного.

    Мотивация? - Могу предложить такую. Есть некая идея, которую автор разделяет. Вероятно — всецело. В таком случае для него вполне естественно включиться в популяризацию (и даже, пропаганду) этой идеи. Ну, а если это ещё подстегнёт продажи соответствующего ПО, то возникает ещё и материальная заинтересованность, пусть и непрямая.
    Отсутствие success story? - Специально не искал, но убеждён, что они в каком-то виде есть. Не сомневаюсь, что найдётся большое количество людей, которые заявят о положительном опыте применения диаграмм вообще и UML в частности при проектировании и для взаимодействия. Хотя такого, чтобы непосредственно программирование было синхронизировано с UML-диаграммами мне неизвестно. Ну, разве что, Ваш случай, хотя для меня в нём пока ещё очень много вызывающего вопросы.

    ОтветитьУдалить