“Хрен и палец – это одно и то же!”, или тэйлористам аджайла посвящается

clip_image002

Любопытное дело – среди людей, которые попробовали работать в true agile компаниях типа FogCreek, не остается равнодушных – и загадочным образом всем нравится! Но есть другой лагерь – тех, кто однозначно уверен, что аджайл – это сакс, новое модное слово которое прикрывает все те же старые добрые приколы – овертайм, выходы в субботу, меняющиеся требования, “давай-давай!” менеджеров. Ну то есть это тот же бегемот – просто раньше показывали только морду, а теперь открыли вид сзади-сбоку и его узаконили. И этих людей – почему то не в разы, а на порядки больше. Как это получается? Ответ простой: благодаря тому что аджайл – это фрэймворк, а не методология. Как это наносит предательский удар по аджайлу? Почитайте вот эти рассуждения, и затем давайте пройдемся по рассуждениям автора и разберемся, как очередные благие намерения становятся дорогой в ад.

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

Если ты возьмешь в руки более толковые источники, типа толкового или энциклопедического словаря, ты легко увидишь различия:

  • Методология – это учение об организации деятельности; учение о структуре, логической организации, методах и средствах деятельности (CЭС).
  • Framework (слово буржуйское, поэтому толкование из буржуйского словаря) is a real or conceptual structure intended to serve as a support or guide for the building or constructionsystem (SETD).

Таким образом, методология – она тебе тебе дает принципы + описание методов и средств деятельности, объединенные в логическую структуру. Если ты вспомнишь структуру RUPа, то сразу поймешь почему это методология – там есть четкие описания шагов с разделами (методы) и кучей шаблонов + Rational Enterprise Suite (средства).

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

Если RUP тебе говорит – “должен быть написан юзкейс, вот правила его написания, вот шаблон для заполнения”, то agile говорит – “чувак, надо получить требования от пользователя – суть вот такая, вот можно на бумажке, вот можно в экселе, вот можно в онтайме, тээфэсе и акуноте, а можешь придумать свой способ.” Но реализация принципов – она обязательная, понимаешь?

В чем же прорыв аджайл-фрэймворков? В том, что методологии эволюционировали и разрослись до неприемлемых размеров, там уже не разобраться без поллитры. Именно формат записи этих инструкций “на входе то, сначала должны быть выполнены те и те действия, на выходе вот это” – приводит к тому, что для конечных пользователей RUP выглядит как водопад. Соответственно аджайл просто обнулил эти тонны инструкций – сказал “ребята, давайте вспомним про то, зачем это все делалось – про принципы!”

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

Набор принципов и сложность их реализации – накладывает определенные ограничения на применение. Жадность – накладывает кучу ограничений на применение. Тупость – делает его невозможным.

Тогда возникает необходимость в “тэйлоринге”. Например. “Команда состоит из людей, которым начхать на проект? Давайте затейлорим – поставим парня с плетью, который будет трахать по утрам на скрам митинге! Чтобы получить больше прибыли надо поставить на проект людей, которые подешевле? Давайте затейлорим – вместо профессионалов поставим на проект людей без опыта и начхать что они ничерта не смыслят в OOD! Говнокод задизайнен так, что он в принципе не testable? Давайте затейлорим – выкинем к едрене фене юнит тесты! Ой, смотрите какой у нас славный аджайл получился! И затейлорен в полном соответствии с реальностью! Кто тут будет спорить?!! У меня мега-аргумент – ведь это работает!!!”

Да, чувак, это работает, но это – не аджайл. Понятно, что у тебя такие люди, что их надо трахать по утрам чтоб работали, и висеть на телефоне по 2 часа объясняя что надо сделать и что ты с ними сделаешь если они не сделают – твой рецепт работает, но не называй ты блин это аджайлом!!! Оттого что утренний трах у тебя называется “daily scrum”, а adhoc полуexploratory тестирование – agile testing, слепленная тобой поделка на станет аджайлом! Потому что суть у тебя – совсем другая.

Если хочешь назвать это красивым словом – выбери другое. Например, девелоперы в “классическом” RUP делятся на Designer (думает и трахает реализущих) и Implementer (трахаем и реализует). Это будет гораздо ближе к сути.

Хочешь сделать аджайл? Тогда будь добр, выпиши основные принципы, и придумай модель разработки для своего проекта, реализующую эти принципы, и претвори ее в жизнь. Не можешь это сделать, посколько это сложно? Ну так учись! Да, у тебя где-то получится лучше, где-то хуже, что-то ты сразу не сможешь – но даже минимальная реализация принципов даст тебе такое заглядение, что ты себе не поверишь!

Почему меня так заботят твои ошибки, дружище?

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

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

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

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

Post Author

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

  • http://www.targetprocess.com firefalcon

    Agile is a mindset.

  • http://www.targetprocess.com firefalcon

    Кстати, именно поэтому менеджерам со стажем бывает сложно понять и принять его. Изменение всего твоего представления о разработке софта… Это не каждому под силу.

  • http://pveller.blogspot.com/ Pavel Veller

    Денис, ты меня переиначил, а зря. Отказываться от принципов я не предлагал. Я просто притушил абсолютизм оных, возведенных некоторыми до небес и с той высоты вдруг сказавших, что только такая степень имплементации принципа – есть аджайл. Вот смотри. Считаешь ли ты, что само-организующаяся команда – есть необходимое условие? А в манифесте написано, что с такой командой будет наилучший результат. Я с этим и не спорю. Но неполное соответствие этому принципу не может быть причиной отказа в принятие в члены клуба.

    Тэйлорингом я тоже называл процесс кастомизации RUP-а, а не построение аджайл команды.

    Так что ошибок я не вижу. Но твою мысль услышал за километр 🙂

  • Konstantin Razumovsky

    Вот интересно, а на каком основании ты считаешь Fog Creek “true agile компанией”? Ты лично проверял там реализацию 4-х ценностей и 12-ти принципов? Ну, вот например, принцип номер 6 – про face-to-face conversation? Реализуется он в этой компании, где почти все разработчики сидят по одному в комнате (судя по блогу Джоэла)? Может, и реализуется как-то, а может и нет. Причем у тебя может быть на этот счет одно мнение, а у меня – другое. Как у Джоэла с Бобом Мартином, которые так и не договорились, нужны ли все-таки юнит-тесты или нет. Никакой официальной системы подтверждения соответствия agile опять-таки не существует.

    Собственно, это я к тому, что понятие agile не настолько определенное и материальное, чтобы гнобить Павла, который попытался проинтерпретировать его удобным для себя способом :). Да, у тебя в проекте реализуется, допустим, 11 из 12 принципов agile, а у Павла, скажем, 6. Строго говоря, вы оба не делаете agile – ни большой, ни маленький.

    P.S. Наверное, одной из самых популярных книг по RUP является книга Кратчена: http://www.amazon.com/Rational-Unified-Process-Introduction-3rd/dp/product-description/0321197704
    Согласно определению оттуда, RUP – никакая не методология, а в зависимости от контекста, процесс или framework(а также продукт фирмы IBM в узком смысле). Это тоже к вопросу о разных подходах к понятиям и определениям.

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

      @konstantion razumovsky: Да, я лично там проверял. Если я даю непроверенные данныеспорную гипотезу, я говорю “по моей гипотезе”, “по непроверенным данным”, “мое мнение”. И обнаруженное привело меня в восторг. Как нормальный человек я стал сразу анализировать “почему так” – и обнаружил потому что аджайл манифесто мог быть написан ими. Поэтому хоть они и не говорят “у нас аджайл”, у них больше аджайл чем в 95% компаний которые говорят “у нас аджайл”. И даже если бы им пришло в голову отрицать – у них все равно был бы аджайл.

      А про “свободную интерпретацию” я тебе объясню на твоем собственном примере, чтоб ты испытал личные чувства и лучше понял мои личные чувства.
      Вот есть такое понятие – кретин. У него есть вполне четкая дефиниция. Однако мне эта четкая дефиниция представляется излишне строгой, поэтому я хочу ее “проинтерпретировать удобным для себя способом”. Например, думаю можно ее расширить так, чтобы все с именем “костя” сразу считались кретинами. Тебе обидно? А главное что особенно обидно – это не соответствует реальности, по всем признакам ты явно не кретин, как бы я себе не интерпретировал это определение.

      Про то что считает Кратчен – это отдельный вопрос. Например Бонни и Клайд считали что они благодетели общества, однако закон однозначно трактует их как преступников. Они могут быть и не согласны (как Кратчен с тем что итоговый RUP – это методология), но быть преступниками от этого они не перестанут. Но это тема отдельного разговора, давай его если что в почту вынесем.

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

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

  • http://pveller.blogspot.com/ Pavel Veller

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

    Денис, о чем мы спорим? Я разве где-то предложил топтать ногами добрые и светлые идеи Аджайла? Нет. Я где-то предложил отказываться от некоторых в пользу «что бы работало»? Тоже нет.

  • http://pveller.blogspot.com/ Pavel Veller

    @firefalcon agile is a software development methodology 🙂 а ментальность правильная в любом деле нужна.

  • http://www.targetprocess.com firefalcon

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

    Тут присутствует фундаментально непонимание того, как функционируют сообщества людей (во сказал). Команда В ЛЮБОМ СЛУЧАЕ самоорганизуется. А как она это сделает уже зависит от среды (условий работы, начальника, и тп)

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

    @pavel veller: Во блин, началось – “не бойтесь себя назвать!”. Да хоть горшком назовись – ты не станешь от этого горшком. И лучше не называйся – потому что другие, кто раньше горшка не видел, будут считать что горшок – это такой павел веллер.
    Об этом мы и спорим – у меня никак не получается донести до тебя простую мысль, ее уже и костя указал – если у тебя реализовано 6 принципов, а у меня реализовано 11 – ни у тебя ни у меня НЕ АДЖАЙЛ. Ты можешь сказать “мы работаем над тем чтобы быть аджайл”, я могу сказать “мы практически уже аджайл, лишь чуть-чуть не хватает” – но пока ни у тебя ни у меня не аджайл.
    Согласен?

  • Konstantin Razumovsky

    @Денис: Кратчен, он как бы, один из создателей RUP 🙂 . Lead Architect этого проекта. И если создатель RUP говорит, что это не методология, а как раз-таки framework, то это во всяком случае повод задуматься. Хотя бы о том, что до однозначности в этих понятиях далеко и значит, нельзя быть очень категоричным в этом вопросе. Я только про это хотел сказать )

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

    @Konstantin Razumovsky: ты на самом деле интереснейшую тему поднял 🙂 Например, задумывал ли Сталин отстроить страну чтоб разъезжать на боевом треножнике и с уханьем пить кровь – или кровавым упырем его назначили потом, по формальным признакам? Демократия ли в Америке (по формальным признакам) – или олигархия, по факту? Ну и так далее.
    Самое прикольное, что люди, которые стоят за строгую классификацию в одном случае, считают допустимым “расширенное толкование” в других.
    Про Кратчена и про то, что ему лучше знать, что он задумывал – лично мне кажется справедливым. Но про то что получилось по факту и установлено на моем лэптопе – можно с уверенностью сказать “методология”.
    Тут нужно перейти на несколько другой уровень – уровень философии и системного анализа; если аудитория попросит – я могу про это статью написать; но по формальным признакам – это будет оффтопик 😀

  • http://pveller.blogspot.com/ Pavel Veller

    >> если у тебя реализовано 6 принципов, а у меня реализовано 11 [..] ни у тебя ни у меня не аджайл. Согласен?

    Нет. Проблема основная в том, что не все принципы, о которых мы так жарко спорим, могут быть измерены только двумя значениями: 0 или 1, нету или есть, аджайл или не аджайл.

    The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Ясный перец. А вот у меня distributed scrum. И мы не все делаем face-to-face. Многое, но не все. Что, мы обречены?
    Simplicity–the art of maximizing the amount of work not done–is essential. Точно! А как измерить, реализовал ты это или нет? 0 или 1?

    Среди 4+12 есть и такие, наличие или отсутствие которых определить легко, и я их назвал необходимыми условиями. Там не надо спорить. Не делаешь частый деливери, не умеешь продуктивно отвечать изменениям и работать через них, работаешь, перебрасывая через забор, пишешь тонны документов и меряешь там свой прогресс, думаешь только о % complete – не аджайл. Делаешь все вышенаписанное правильно, клиент доволен софтом, софт пишется быстро и качественно, команда довольна и производительность растет, вопросов кто что делает и зачем не возникает – в чем проблема с именованием этого аджайлом? Где несоответствие определению или нарушенные ценности?

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

    Павел, я вот так и знал что ты ответишь как ответишь.
    Казуистически можно доказать что белое – это разновидность черного, а солнце ночью светит. Точно также если хочется поспорить (ради спора) реализует та или иная команда на практике принцип – можно поспорить. Мы этого делать не будем, демагогия – это глупо и непродуктивно.
    На самом деле – это проверяется достаточно просто. Если не ставить себе целью парить мозг. Если ты на полном серьезе этого не понимаешь, а не прикалываешься полемизируя ради самой полемики – извини, я в тебе ошибался и немного разочарован, но errare humanum est.
    Другое дело, что ты сам можешь быть не в состоянии проверить. Это нормально, сам можешь всего не знать. Позови знающего человека – он тебе объяснит, достаточная ли у тебя простота (simplicity). Позови Гену Драгуна если тебя интересует достаточно ли у тебя прост интерфейс, позови Диму Губу если тебя интересует достаточно ли прост твой дизайн.
    И если ты все принципы реализовал, сам или с помощью специалистовкочейконсультантовучебы… – да, можешь говорить что у тебя аджайл.
    Но если ты реализовал 11, а 12й похерил “расширенно истолковав” и сославшись на “отсутствие возможности установить да или нет” – ну так будь готов что тебя тоже расширенно истолкуют как в примере который я привел косте. Ну конечно сделав поправку на то что кретинизм не абсолютный, но где-то в промежутке от 0 до 1 🙂 (no offense, чисто пример хороший).
    Еще большая просьба. Я тебе уже все что хотел сказать – сказал. Все уже кажется поняли. Свою точку зрения ты тоже озвучил. Все уже кажется поняли. Свои мысли тебе сообщили. По новой затевать ту же песню – не надо. Если хочешь, ты лично ко мне зайди при случае – я тебе попробую более подробно объяснить, с примерами, если тебе действительно интересно. А так время тратить уже надоело, извини 🙂

  • http://pveller.blogspot.com/ Pavel Veller

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

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

      Ну тогда нам дальше это бессмысленно в онлайне обсуждать, видишь – не понимаем мы друг друга. Есть мнение, что при случае можно выпить пива и перетереть эту тему.

  • http://pveller.blogspot.com/ Pavel Veller

    Принимается. именно так и сделаем

  • http://pveller.blogspot.com/ Pavel Veller

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

    Кстати, с удовольствием прочел “Просто ли делать Agile?”, на который ты сослался. Оставлю там комментарий, хоть и пост старый.

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

    Так и я не против поучиться.
    Буде будет чему учиться – я всегда ищу возможности.
    Еще классно эффективно это делать, но с этим разберемся постепенно.

  • Тимур Хащеватский

    Коллеги, с интересом прочёл вашу дискуссию в этой и нескольких предыдущих ветках (две статьи Павла и одна Дениса). Хочу вставить пять копеек (сразу про всё).

    По поводу сравнения Павлом agile и plan-driven методологий – на мой взгляд не надо ничего изобретать, есть волшебная книжка Барри Боэма и Ричарда Тёрнера – Balancing Agility and Discipline: A Guide for the Perplexed (с почтительнейшими предисловиями от кардиналов обеих Церквей – Гради Буча и Алистера Кокберна). Цитировать оттуда по теме дискуссии хочется всё, но я приведу только два абзаца:

    The Top Six Conclusions

    Our top six conclusions are
    1. Neither agile nor plan-driven methods provide a silver bullet.
    2. Agile and plan-driven methods have home grounds where one clearly dominates the other.
    3. Future trends are toward application developments that need both agility and discipline.
    4. Some balanced methods are emerging.
    5. It is better to build your method up than to tailor it down.
    6. Methods are important, but potential silver bullets are more likely to be found in areas dealing with people, values, communication, and expectations management.

    A Tailorable Method for Balancing Agile and Plan-Driven Methods

    Step 1
    Rate the project’s environmental, agile, and plan-driven risks. If uncertain about ratings, buy information via prototyping, data collection, and analysis.

    Step 2a
    If agility risks dominate plan-driven risks, go risk-based plan-driven.

    Step 2b
    If plan-driven risks dominate agility risks, go risk-based agile.

    Step 3
    If parts of the application satisfy 2a and others 2b, architect the application to encapsulate the agile parts. Go risk-based agile in the agile parts and risk-based plan-driven elsewhere.

    Step 4
    Establish an overall project strategy by integrating individual risk mitigation plans.

    Step 5
    Monitor progress and risks/opportunities, readjust balance and process as appropriate.

    Особо прошу обратить внимание на второй и третий пункт выводов. Agile и plan-driven методы имеют разные области применения. В некоторых случаях лучшее решение – конвергенция через объединение практик (мой бывший коллега-француз работает ныне консультантом в IBM Rational и рассказывает, что концепция RUP for Agile Teams пользуется большой популярностью).

    Поэтому, хоть я и согласен практически полностью с общим ходом мысли Павла (о необходимости адаптации, о недискретности etc.), я не согласен с его выводами. Не надо разделять Agile и “agile”, надо называть вещи своими именами: есть проекты в которых agile (частично или полностью) неэффективен, значительно больше проектов, в которых неэффективен сверхмодный нынче scrum (но про это вообще отдельный разговор). И это далеко не только проекты выполняемые дебилами для дебилов с целью не достичь цели.

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

    (Отступление: меня вообще настораживает некоторая полурелигиозная суета (или по крайней мере мифологизация) вокруг agile – по крайней мере евангелие имеется, евангелистов навалом, у адептов-джедаев велика иррациональная составляющая выбора и есть тенденция к излишне простым ответам на сложные вопросы. Градус холиваров слишком велик, самые забавные – за чистоту веры (самая жестокая борьба – внутривидовая). Я, впрочем, будучи агностиком, своих ценностей не навязываю и никого обидеть не хочу – так что держим свои световые мечи в …. ножнах).

    Также хочу поспорить и с Денисом:
    1. Приличная часть пафоса твоих комментариев сводится к тому, что говно (-код, -менеджмент, -тестирование, далее по списку) не следует выдавать за agile. Собственно с этим спорить трудно. Только вот не настораживает ли тебя растущий поток информации о подобных фальсификациях ? Не занесло ли само волшебное лекарство новый вирус ? Agile по определению работает только в среде личностно и профессионально зрелых индивидуумов. Теперь ответь на два вопроса: какой процент таковых работает в аутсорсинговой индустрии и какой процент работающих в аутсорсинговой индустрии считает себя таковыми ? Так, теперь вычитаем (ну или делим – как больше нравится). Делаем выводы.

    (К слову – говно-RUP, разумеется, тоже встречается, но в отличии от говно-scrum реализовать его значительно сложнее, а живучесть его меньше.

    И ещё, по поводу говно-RUP: должен сказать тебе по секрету, что твоё феерическое “Например, девелоперы в “классическом” RUP делятся на Designer (думает и трахает реализущих) и Implementer (трахаем и реализует).” – это он самый, говно-RUP, и есть. Причём это искажение не только духа, но и буквы).

    2. Ты считаешь, что agile – это когда 4+12. Между тем приличная часть из этих 16 определяет ценности, но не является чёткими разграничителями agile и не-agile (наглядный пример: “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”, да и вся четвёрка из манифеста). Измеряемы вообще всего пара-тройка (однозначно меряется вообще по-моему только принцип длины итераций в пределах от пары недель до пары месяцев). Отсюда два вывода: во первых Павел прав про недискретность: когда речь идёт о наборах ценностей мы всегда можем говорить о степени их близости – иначе впадаем в религиозный фанатизм. Во вторых прав firefalcon с цитатой: agile is a mindset. Ну то-есть у нас плохо дело с объективными критериями agile/not agile. Приходится обращаться к толкователям-евангелистам, мнения которых зачастую не совпадают.

    3. Про прорыв agile, выраженный в отправке “фтопку” чрезмерно разросшихся методологий.
    Во-первых: у того же Боэма есть совершенно блестящий кусочек про “серебрянные пули”:
    It is easy to assume universality when we find something that works. This is the essence of a silver bullet, whose life cycle has been delightfully described by Sarah Sheard of the Software Productivity Consortium as a journey through discovery, successful application, publicity of success, momentum building and publication, first (slightly modified) replication, confirmation by early adopters, proceduralization and implementation in disparate environments by uninformed middle management, insufficient funding and misapplication, diminishing returns due to devolution of original idea, denigration of the original idea, and ultimately demise and new discovery..

    C agile мы уже вполне подобрались к misapplication и подбираемся к devolution.

    Во-вторых: “до основанья, а затем” малость отдаёт ВОСРом (ну да это больше эстетического характера претензия).

    В третьих: как ты думаешь, что могут сделать из agile специалисты (коих навалом), ухватившиеся за него не приняв его принципов, но обрадовавшись формальной простоте практик ?

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

    Собственно с этим спорить трудно. Только вот не настораживает ли тебя растущий поток информации о подобных фальсификациях ? Не занесло ли само волшебное лекарство новый вирус?
    Дык я строго про это и пишу-само оформление аджайла в виде методики создает множество возможностей интерпретации и конечно адаптации, в том числе – неверных. Да, аджайл сам виноват.
    Agile по определению работает только в среде личностно и профессионально зрелых индивидуумов. Теперь ответь на два вопроса: какой процент таковых работает в аутсорсинговой индустрии и какой процент работающих в аутсорсинговой индустрии считает себя таковыми?
    Строго в цель, камрад. Я когда ретвит статьи делал, в комменте написал: “как же меня задрали тейлористы аджайла от аутсорсинга” 🙂
    И ещё, по поводу говно-RUP: должен сказать тебе по секрету, что твоё феерическое “Например, девелоперы в “классическом” RUP делятся на Designer (думает и трахает реализущих) и Implementer (трахаем и реализует).” – это он самый, говно-RUP, и есть. Причём это искажение не только духа, но и буквы).
    Камрад, дословно цитирую букву, прямо из RUP:
    The designer identifies and defines the responsibilities, operations, attributes, and relationships of design elements. The designer ensures that the design is consistent with the software architecture, and is detailed to a point where implementation can proceed.

    The implementer role is responsible for developing and testing components, in accordance with the project’s adopted standards, for integration into larger subsystems. When test components, such as drivers or stubs, must be created to support testing, the implementer is also responsible for developing and testing the test components and corresponding subsystems.
    Дальше, нигде в тексте ты не найдешь “у тебя должны быть компетентные мотивированные профессионалы.” – зато в Concepts ты много прочитаешь про то, как одни думают (Concepts: Architecture, Concepts: CapsuleComponents Design), а другие – делают. Так что один главный с плеткой, и куча говнокодеров – это ничуть не искажение принципов RUP, так – легкая адаптация; по крайней мере никто не декларировал что такая адаптация запрещена – именно поэтому software factories так любят RUP, точнее версию “говно-РУП”. Что думали по этому поводу его придумщики? Не знаю, но подумай-случайно ли они ввели такое разделение: DesingerImplementer? Причем не Developer, не программер, а именно Implementer – реализатор?
    Так что имхо принципы рупа, задекларированные например в RUP Made Easy, потом здорово были подпорчены рупом как коммерческим продуктом и еще больше – его тейлористами.
    Agile и plan-driven методы имеют разные области применения.
    Именно так. И визуально ты можешь замаскировать один под другой – подделаться под терминологию, артефакты, практики. Но суть будет безнадежно изгажена.
    Лучше понимать область применения и условияграницы применимости. И когда надо и нет иной возможности – использовать толпу студентов с лопатами, когда есть возможность – бульдозер.
    C agile мы уже вполне подобрались к misapplication и подбираемся к devolution.
    Именно так, увы.

  • http://pveller.blogspot.com/ Pavel Veller

    Тимур, снимаю шляпу.

    Ты не согласился со стремлением к Agile, обобщив мы на всех нас. А мы там – agile практики, активно внедряющие и практикующие именно agile методы, а не все мы. Кто ж не захочет полной синергии «в среде личностно и профессионально зрелых индивидуумов».

  • Тимур Хащеватский

    2 Денис

    Ты, коллега, наступаешь на одни из самых известных RUPовских граблей.
    Цитирую первоисточник (bold мой):

    Key Concept: Role

    Note that roles are not individuals; instead, they describe how individuals should behave in the business and the responsibilities of an individual. Individual members of the software development organization will wear different hats, or perform different roles. The mapping from individual to role, performed by the project manager when planning and staffing the project (see Activity: Acquire Staff), allows different individuals to act as several different roles, and for a role to be played by several individuals.

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

  • Тимур Хащеватский

    2 Павел

    Ну да, я здесь в некотором роде гость. Agile-практиком я не являюсь, к ценностям agile отношусь очень осторожно – это тема для длинного разговора. Хотя и признаю, что agile полез именно туда, куда давно стоило – в область интеграции УП с психологией и социологией, именно там и может родиться нечто важное. Кроме того среди приверженцев agile масса талантливых людей.
    Но вот чего я не понимаю – так это сознательного нерационального самоограничения. Зачем загонять себя в рамки ? Единственные неприкосновенные рамки это рамки морали и этики. Всё остальное должно рассматриваться критически – приниматься либо выкидываться по мере надобности.

  • http://pveller.blogspot.com/ Pavel Veller

    @Тимур

    я абсолютно согласен. Вся моя практика и опыт – тому подтверждение.

    В одной из версий статьи (а пост проходил серию редакционных корректировок – коллеги держатели agile.by активно помогали мне четче выразить мысль, не пуская неорганизованный поток сознания в печать, за что им отдельное спасибо), вывод был другой. Я изначально пытался привести к вот какому общему знаменателю:
    Хорошо – Результат
    Плохо – отсутствие результата и хорошая история об этом
    Где Результат ни в коем случае не подразумевает «любой ценой», а есть всего лишь конечное состояние, достичь которого и была изначальная цель. Идея и изюминка в том, чтобы подобрать правильный инструмент. И пост сначала назывался “Что такое Хорошо и что такое Плохо», а в последнем драфте перед печатью – «Необходимые и достаточные условия agile». У меня, к сожалению, не получилось вывести эти формулы адекватно четко в формате одного законченного поста. Может в следующий раз.

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

    @ Pavel
    Павел, я тебя понял. Но вот ты как раз меня понять не можешь – зачастую именно помещение себя в рамки дает результат лучший, чем безграничная свобода. Типа как знаешь, если порох поджечь на столе – будет дым и вспышка, если зажечь в стволе – толкнет пулю. Ну а дальше начинается эволюция стволов – гладкие, нарезные, конические… И если ты назовет свою “браун бесс” “бэррет” – она не станет от этого бэрретом.
    @ Тимур
    Ты сам болдом выделил – roles are not individuals; мы оперируем “шапкой”, элементом технологического процесса. Поэтому RUP нигде ничего не говорит о мотивации – какие у элементов технологического процесса могут быть мотивации?

  • Тимур Хащеватский

    2 Павел

    Ага, понятно, ну вот как раз об этом (прагматичном выборе инструментов) вся книжка Боэма и Тёрнера (доступна в инете).

    2 Денис

    Ты неправильно понимаешь суть. Роль – это не переменная в уравнении куда мы подставляем некоего Петю или Васю. И не должность. Это абстракция, набор взаимосвязанных активностей. Причём это не толкование, а буква RUP. Есть набор активностей, предполагающий “думать”, а есть – предполагающий “делать”.
    В реале (это уже толкование, но вполне очевидное) упомянутые тобой роли Designer и Implementer зачастую исполняются одним человеком, если его квалификация это позволяет (ну и по тексту цитаты из классика “трахает реализующих” он в своём же м-м-м лице). Вообще есть древняя концепция job enrichment (разработана Херцбергом ещё в 1950х), которая в принципе говорит о том, что мотивация и производительность растут с ростом ответственности и разнообразия работ. Азы менеджмента – бери и применяй, знание agile для этого не требуется.

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

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

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

  • Konstantin Razumovsky

    2Денис, Тимур:
    Вот вы говорите, что у agile и plan-driven методологий разные области применения и для одних проектов подходит одно, а для других – другое. А можно привести пример проекта, для которого не подходит какая-то из 4-х ценностей манифеста или хотя бы один из 12 принципов? Надеюсь, вы все-таки хотели сказать, что XP и Scrum подходят не для всех проектов? 🙂

  • http://pveller.blogspot.com/ Pavel Veller

    Денис,

    Почему же, я тебя понимаю. Ты говоришь: результат я ваш вижу/верю, но вы, ребята, чем про результат говорить, взяли бы лучше в руки правильный инструмент, только по-настоящему взяли, по всем правилам, и сами бы удивились эффекту (и не называйте ваши методы этим самым инструментом, как бы они на него не походили). Где-то так, если в одном предложении. Не сильно, надеюсь, переврал?

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

  • http://pveller.blogspot.com/ Pavel Veller

    2 Konstantin Razumovsky

    Тут очень важно договориться, что именно мы ищем. Ты спросил не подходит, и в такой формулировке, наверное, примеров нет. Все проекты (и не только софтверные) только выиграют от наличия 4+12. А значит – всем проектам это подходит. Я уже писал свое мнение о том, что в манифесте выражен здравый смысл. Было бы странно, если бы нашлись проекты, которым бы не подходил здравый смысл (опуская, безусловно, действительно клинические случаи, где проект создается здравому смыслу вопреки. Был у меня такой, когда клиент через какое-то время сам признал дословно: this is not a delivery project, this is a communication project. было весело)

    Что, я думаю, было бы более интересно поискать, так это сетапы, где невозможно получить все 4+12. Еще интереснее, где plan-driven более применим, чем agile при том, что явных проблем с 4+12 нет. И совсем интересно, где рулит “конвергенция через объединение практик”.

    Для того чтобы предметно обсуждать такие вещи, надо место. Делать это в длинных комментариях к статье про хрен и палец как-то не очень сподручно. Если бы держатели agile.by были бы не против, мы бы могли попробовать серию задачи для agile, где предметом обсуждения стали бы конкретные проектные сетапы (только без имен, все чтут NDA). Что-то вроде пост на задачу и дальше конструктивное обсуждение в комментариях. Важно только слушать и слышать друг друга. Если, например, описывается проект, выполняемый сервисной организацией, где контрактными требованиями заложена earned value отчетность, то не конструктивно будет предлагать объяснить заказчику, что earned value ему не поможет, а значит команда, выбравшая plan-driven методологию, просто не умеет готовить agile среду.

    Денис, Юра, Павел (Габриель), что скажете?

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

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

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

    @ Pavel
    Нет, не слышишь ты меня.
    Я тебе говорю (последний раз, бо надоело): сделал классный телескоп – молодец! Но не называй его микроскопом.

  • Тимур Хащеватский

    2 Денис

    Хотел я сказать, камрад, очень простую вещь: девелоперы в RUP не делятся на Designers и Implementers.

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

    Дружище, я тебе выше процитировал соотв. места RUPа. Могу скриншот прислать 🙂

  • Тимур Хащеватский

    Твои цитаты – это разделение между ролями, а не между индивидуумами. Неужели не врубаешься 🙂 ?

  • Тимур Хащеватский

    2 Константин

    Ты сам себе ответил в первой фразе своего коммента. Ключевое слово “методологии”, речь шла о них, а не о манифесте.

    В более широком смысле речь шла о сравнении changes-driven (agile) и plan-driven подходов.

    Но раз уж ты спросил про манифест, то скажу вот что: ценности имеют отношение к людям, а не к проектам. Т.е. вопрос о ценностях некорректен. А вот насчёт принципов – готов навскидку сконструировать контрпримеры проектов как минимум к половине принципов agile 🙂 .

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

    Мне кажется врубаюсь 🙂 Если я тебя правильно понял, то ты пытаешься до меня донести следующее: роль – это абстракция, а не человек, поэтому один человек может совмещать несколько ролей, и как следствие – один человек вполне может быть и дизайнером и имплементером. так? 🙂

  • Тимур Хащеватский

    Да, именно об этом и говорит RUP 🙂 !

    A role is an abstract definition of a set of responsibilities for activities to be performed and artifacts to be produced.

    Roles are typically realized by an individual, or a set of individuals, working together as a team. A project team member typically fulfills many different roles.

    Roles are not individuals, nor are they necessarily equivelant to job titles; instead, they describe how individuals assigned to the roles will behave in the context of a software engineering project.

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

    @ Тимур
    Ну значит понимаю я тебя правильно 🙂
    Согласись предложенное тобой (процитированное) определение вовсе не лишает меня права сделать “вот этот человек занимает вот эту роль?”
    Согласен?

  • Тимур Хащеватский

    Безусловно не лишает. Более того – будучи PM-ом ты обязан создать матрицу люди/роли (хотя бы у себя в голове). RUP не научит тебя делать это правильно – этот вопрос вне сферы его компетенции. Поэтому одного RUP для качественного УП мало. Но если ты построил команду неэффективно и дизайнеры у тебя трахают имплементеров – не вали на RUP 🙂 . Хотя, должен заметить, иногда и такая модель является единственно возможной.

  • Тимур Хащеватский

    Итак, выполняю (и перевыполняю) обещанное упражнение на контрпримеры к принципам agile.

    Под первым номером проект, которым я управляю непосредственно сейчас. Имеем fixed price проект (вернее сказать серия проектов) для английского подразделения (по сути фабрики) крупной международной компании. Непосредственный заказчик – IT-департамент. Задачи – улучшение и гармонизация IT-инфраструктуры. Требования проработаны на весьма приличном
    уровне. Сроки не жмут. Но в силу важности софта и потенциальной дороговизны ошибок acceptance тесты на стороне клиенты очень тщательные, длительные и соответственно дорогостоящие. Никакой early and continuous delivery никому не нужен – нужна минимизация количества поставок и заблаговременное их планирование. Первый принцип не пригодился.

    Про второй принцип пример приводить не буду – скажу вот что: инфраструктура, позволяющая относительно безболезненно
    вносить изменения на поздних стадиях вполне возможна. Но она стоит денег. Поэтому наша задача носит количественный,
    а не качественный характер: мы (совместно с клиентом) пытаемся оценить вероятность и потенциальную важность
    изменений и если их функция превышает затраты на инфраструктуру – мы на них идём. Ну и конечно – за отдельные деньги
    wellcome чему угодно и в любое время ! В этом (буквальном) смысле второй принцип вообще не имеет смысла.

    Под третьим номером серия проектов (выпуск версий продукта), которой мне посчастливилось управлять около девяти лет.
    Тяжелая CAD/CAM система, Fortran + C, 6 платформ (пачка юниксов, Windows и VAX/VMS), команда в Минске в лучшие времена около 30 человек, часть разработчиков, QA, интеграторов во Франции. Одна major version в два года, одна
    minor version в год, revisions (куммулятивные сервиспаки преимущественно с багфиксами) по обстановке. Номинальный
    (упрощённый) цикл производства версии примерно следующий – 8-9 месячная итерация (всё что планировано в версию)->
    2-3 месячная итерация (качество + самое важное и самое безопасное из того, что не успели)->1-2 месячная итерация (только качество). Естественно continuous integration (синхронно на обоих сайтах) and automated tests, на их базе –
    индикатор качества проекта, ежедневно. Во время длинной итерации – контролируемый хаос. Что-то вроде FDD – контроль
    осуществляется по приоритезированным features, запланированным в версию (baseline/completed/rest to do). Успеваем – не успеваем, перебрали – не перебрали, всё как обычно – ручное управление. Короткие итерации в конце для сведения по
    качеству. Крайне эффективно. Прекрасный аналог – переходные процессы в электротехнике: несколько затухающих
    колебаний и стабилизация, снижение амплитуды колебаний возможно, но стоит или увеличения времени затухания или
    денег. Третий принцип – на свалку.

    Четвёртый принцип: с одной стороны только для полных идиотов подобное следует писать на бумаге
    (“выходя из самолёта убедись в наличии трапа”), с другой – а что, обязательно daily ? А почему не weekly или hourly ?

    Пятый принцип вызывает у меня вопрос только в последней его части. Что значит “trust them to get the job done” (“доверься им в том, что они выполнят эту работу”) с практической точки зрения ? Тут одно из двух: либо это означает
    призыв к отказу от контроля – и тогда это ахинея. Либо это просто популистская фраза, не имеющая практического смысла. Плюс опять же распространённый и вполне безобидный практический пример – очень мотивированный и многомудрый
    чел, которого просто время от времени заносит в побочные исследования и написания всемогущих компонентов. И что – я
    должен ему trust ? Да ни за что! Любить и уважать – сколько угодно, но только не “trust them to get the job done”.

    Шестой принцип работает не всегда и не для всех. Даже не хочется разжёвывать, ну да ладно. Есть информация, которую
    письменно распространять намного правильнее чем устно. Есть технические дискуссии, требующие детальной проработки ответов. Есть, в конце концов, категория людей, которым личностные конфликты, в силу определённых свойств лучше разрешать письменно. Вообще есть куча литературы о выборе правильных средств коммуникации. Зачем всё так упрощать ? Привиделась этакая картинка – Татьяна пишет письмо (e-mail ?) Онегину, а ей в ответ укоризненно “а как же face to face conversation ? You are not effective and efficient !”

    Седьмой принцип. Ну – здесь просто. В упомянутом мной CAD/CAM продукте отдельные алгоритмы (в основном топология) писались и отлаживались месяцами, а то и годами. Тем не менее мы старались отслеживать их прогресс по промежуточным результатам, не представляющим никакой практической ценности для конечного клиента. Это же будет верно для любого проекта-айсберга (не путать с проектом-Титаником) с развитой подводной частью.

    Что касается восьмого – это пожалуй не принцип, а условие выживания agile проекта – если sponsors не могут или users не хотят – никакого agile не выйдет. Пропускаем.

    Перед девятым и особенно десятым снимаю шляпу ! Святая правда.

    Одиннадцатый – неправда. Лучшая архитектура идёт от лучших архитекторов. Лучшие требования – от лучших аналитиков.
    Лучшая организация – от лучшего PM. Последний тезис нуждается в доказательствах. Они, впрочем, просты: каждый является специалистом в своём деле. Прекрасные разработчики могут быть провальными организаторами (и даже
    самоорганизаторами). Прекрасный PM – не может, иначе он не прекрасный. Всё это не отменяет того факта, что когда
    команда активно и позитивно взаимодействует (это не тоже самое, что самоорганизуется), результат получается намного
    лучше.

    С двенадцатым согласен.

    Всё, начинаем пинать меня ногами, световыми мечами и шворцами (смотрим Spaceballs) 🙂 .

  • http://pveller.blogspot.com/ Pavel Veller

    2 Дорогая Редакция

    Может, стоит опубликовать комментарий от Тимура в отдельный пост, чтобы там спокойно и обсудить? а то как-то тут уже ну очень много. И давно уже не про хрен с пальцем 🙂

  • Ivan Padabed

    “как превратить хрен в палец” – по-моему хорошее название следующего тренинг для Дениса 🙂 дарю идею безвозмездно