Воздействие внешнего окружения на Agile – ISV и корпорации (автор: Павел Веллер)

Обсуждая agile техники и подходы к разработке и управлению проектами, мы, как правило, смотрим на проблему изнутри команды, говорим о том, как команда должна быть организована и каковы основные ингредиенты успеха. При этом мы зачастую опускаем внешнее окружение или предполагаем, что внешнее окружение легко прогнется под воздействием команды под ее нужды и мировоззрение. А так ли это? Очевидно, что ответ зависит от контекста, в котором работает команда. В условиях совместной с клиентом разработки (co-development) пренебрегать внешним окружением нельзя, и, не понимая его, считаться с ним эффективно не получится. Давайте разбираться на примерах.

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

  • ISV, основной бизнес которых есть производство софтверных продуктов
  • Бизнес компании, занимающиеся производством или оказанием услуг в других областях и пользующиеся софтверными продуктами как инструментом

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

  • ISV делают софт “всю жизнь”, этим зарабатывают деньги, и практически на всех ролях в компании работают инженеры. Отсюда – знание и понимание процессов разработки и жизненного цикла, почерпанное не только из книжек. Знание это не обязательно “кошерное”, но зато оно опробовано на собственной шкуре.
  • IT отдел в бизнес компании есть всего лишь сервис, который долгое время варится в своем соку и разговаривает с бизнесом через “переводчиков”. Отсюда медлительность и возведение многих аспектов процесса разработки в религию. Энциклопедические знания по теме зачастую превышают ожидания, но, неподкрепленные практическим опытом, превращаются в идейные лозунги.
  • ISV нацелены на результат, тогда как IT отделы корпораций больше нацелены на процесс. Отсюда давление и сжатые сроки при работе с ISV, и (на контрасте) очень политизированная и электризованная среда в корпорациях.
  • Конкуренция вынуждает ISV рисковать и опробовать новые техники (как в выборе инструментария и платформ, так и в выборе подходов к организации процессов), в то время как IT отделы бизнес клиентов в большей степени озабочены надежностью и предсказуемостью. А когда делают инновации – делают их очень основательно.

Список этот можно продолжать, но для моего сегодняшнего примера приведенных различий достаточно. Хотелось бы добавить только одно забавное наблюдение. Карьера профессионалов редко пересекает границы двух миров: любо карьера в бизнес компаниях, либо карьера в ISV. Похоже, что сформированную ментальность по одному из двух путей развития тем сложнее перетащить в другой, чем больше времени проведено в изначально освоенной. Архитектор с большим опытом работы в корпорации при случае окажется не способен оценить и принять практичную направленность работы своих коллег в ISV, а главное: не сумеет быстро отрабатывать свои предложения. Такой же опытный архитектор из ISV подвергнет свой мозг и характер серьезному испытанию, перейдя в политизированный, медлительный, а главное теоретическо-направленный мир архитектурной профессии своих коллег из корпоративного мира. Хотя оба легко и одинаково хорошо сдадут тесты проф пригодности в области своей компетенции.

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

А сегодня – о причудливых формах agile, развернутом IT отделом большой корпорации, и о влиянии этих форм на agile команду разработки за океаном. По версии клиента квинтэссенцией agile являются истории, которые надо измерять (ни в коем случае!) не в человеко-часах, а только лишь в поинтах). Истории, которые можно насаживать на дерево функциональных областей (feature tree), но нельзя записывать в бэклоги (и вообще, бэклоги есть рудимент, отмирающий на пути к agile 2.0). Истории должны проходить четкий процесс утверждения на реализацию и каждая иметь за собой индивидуальную ветку в системе контроля версий (GIT). Ветка проходит обязательный peer review и зайдет в основной репозиторий только через гейт кипера (definition of done в частности запрещает To-Do комментарии в коде). А промежуточные демонстрации бизнесу должны проходить гладко, чтоб без сучка без задоринки и по заранее оговоренному сценарию. А сверху положен должен быть MPP для отражения плана и прогресса в наглядной форме, понятной главному руководству. Ну, и конечно, правильная гранулярность WS API и семантика публичных методов сервисов важнее всего.

Многие детали я опустил, но суть вы уже поняли – реализовано много хороших и правильных практик, местами некорректно интерпретированных, частью возведенных в абсолют, разбавленных старыми добрыми традициями водопадных процессов (mainframe софт по-другому не писали) и особенностями взаимоотношений отделов. Бизнес ведь все-таки клиент и музыку заказывает, но сам играть не умеет. Вот мы и будем играть, как считаем нужным, а они нам перечить не станут – не их профессия да и культура не позволяет (про культурные отличия мы тоже обязательно поговорим). Надо бы оговориться, что и ISV клиенты успешно навязывают свое видение мира, особенно в условиях совместной работы, но их мировоззрение, пусть не всегда более близкое к истине, все-таки (как правило) более практично и имеет свои корни не в эрудированности наставляющих, а в синяках на различных частях их тела.

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

  • Вариант 1. Можно пробовать максимально игнорировать нездоровые идеи, выставляя прокси/маску наружу, и инсталлируя внутри команды тот agile, который наиболее подходит для команды и задачи. В теории – работает. A на практике – прозрачность stand up -ов и распределенная разработка по веткам-историям создает слишком много барьеров, прятать которые за маски каждый день просто не получается без серьезных потерь в эффективности
  • Вариант 2. Можно принимать правила игры полностью и катиться по проторенной колее. Побочные эффекты: тяжелая адаптация, постоянный внутренний конфликт (особенно ярко наблюдаемый в активных личностях, остро болеющих за эффективность), и часто не лучшие отношения с бизнесом.

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

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

Post Author

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

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

    Имхо мы имеем характерное непонимание смысла agile – типа agile значит “адаптироваться”, а “адаптироваться” значит “тут добавим водопада, а тут выкинем пару практик, тут поставим Главного, тут маленько поднапишем спецификацию, и вот мы уже подстроились под заказчика!”
    В результате получается бодяга, которая через пень колоду работает с этим данным заказчиком. У нее есть несомненное достоинство – она работает. Но эта бодяга не дает прироста производительности, использования коллективного опыта, экономии на накладных расходах – потому что при подстройке в интересах QMS+топменеджеров+еще_кого_то она теряет те принципы, ради которых задумывался agile, и не дает эффекта ради которого вводились принципы.
    И вот тут как раз хорошо виден дефект мышления нас контуженных аутсорсингом (и я брут, ага) – “команда должна подстроиться под окружение”. Блин, команда не подстраивается под окружение. Окружение, которое реально готово и способно работать agile, создает agile-команду. Тогда – когда окружение и команда – готово и способно работать по agile – вот тогда и получаются чудеса. Тогда – прирост производительности, радостная команда, супер-системы, польза для бизнеса.
    Иначе – окружение “подстраивает” команду под псевдо-agile: c терминами “дэйли скрам” (ежеутренний трах менеджером), бэклогами (набор 10страничных документов), “скрам мастерами” (“ты будешь делать то-то и то-то”), DoDами (“ни одна тупая скотина не комитит в транк пока я не отревьиюл!!!”) Это можно называть аджайлом, но это не будет аджайлом. И очередной заказчик скажет за пивом своему товарищу – “знаешь, попробовали мы этот аджайл – чё-то не заметил я ни прироста качества, ни производительности, по моему та же фигня тока вид сбоку…”

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

    Денис, я с тобой согласен в выводах о том, есть ли сей зверь agile. Но я пока только рассказал о том, как клиент представляет себе “правильный” процесс, но еще не рассказал, как команда вышла из ситуации. Я как раз таки не предлагал замешивать все в котел и думать, что пришла нирвана.

    Задача у меня была другой – показать, как реальность НЕ помогает сервисным командам играть правильную игру. Agile можно и нужно делать, и делают его в разных контекстах, в разных окружениях. Не считаться с окружением невозможно. Одно дело – рассуждать, как “правильно” делать agile или как чудо полчается само, другое – о том, как это возможно или не всегда возможно в конкретном окружении.

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

    Заказчик, кстати, считает, что с agile у них все в порядке 🙂

    Ну, и немного о контузии. Я не соглашусь с диагнозом. Желание “чтобы работало”, происходит не от дефекта мышления. Мы же не non profit организация, цель который огранивать алмаз agile методологии на собственных примерах. Наши цели просты – зарабатывать и развивать бизнес. Для лучшего результата надо стремиться к чудесам, я с тобой согласен, но без результата за идею стремиться не очень получается.

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

    Камрад, про контузию – это не про желание “чтобы работало”, как раз когда заказчик считает что у него с аджайлом все нормально 🙂
    А про нашу прибыль – да, наша прибыль это наше все, зачастую для прибыли надо работать хуже: продавать больше людей, делать больше багов чтоб продать саппорт, работать хуже чтоб работать дольше чтоб получить больше…

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

    И все-таки основная нить похоже проходит мимо, хотя ты с Тимуром эту тему еще в мае проходил (ссылаюсь на “Самый непонимаемый принцип в Agile Manifesto” и коменты к оному).

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

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

    Дык и моя красная линия проходит мимо многих.
    Получается разговор вроде такого:
    – Парни, самолет – он летает по небу. Летает, понимаете? За час пролетает иной раз по тыще километров. Но летает когда аэродинамика правильная + двигатель и топливо.
    – Денис, ты пойми – у нас такие обстоятельства с заказчикомресурсами…, что есть лошади, а двигателя нет. Поэтому надо адаптироваться к жизни. Вот мы запрягли 1200 лошадей (что равнозначно движку с тягой 1200лс), и самолет уверенно перемещаем на довольно большие расстояния.
    – Парни, самолет – он летает. Быстро летает. А без двигателя – не летает. Вы можете говорить что у вас самолет (и по форме он самолет, можно с чеклистом проверить – крылья, шасси и т.д.), но по сути – он телега с 1200 лошадей, которые друг другу мешают.
    – Но он же перемещается!!!
    – Да, но не говорите что это самолет, говорите “телега в форме самолета”. Потому что человек неопытный увидит вашу телегу и будет считать что все самолеты такие.
    – Нет, наша телега – это такой адаптированный самолет. Поэтому давайте обсудим свойства самолетов на примере нашей телеги.

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

    Э… я теперь понимаю, что именно в моем посте вызвало такой резонанс – то место где я предлагал адаптироваться и провел параллель с agile. Вешать ярлык не было мой целью (философски о методологиях и некоторых особенно ярких ярлыках и клише я как раз собирался написать в следующем посте – там и продолжим :)). Моей целью было обозначить, что здравый смысл и поиск решения, а не следование «методологии», – есть правильный ответ вызову. Именно это я вкладывал в свое предложение.

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

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

  • http://alovak.com Павел Габриель

    То, о чем говорит Денис – 100% следование Agile. Шаг вправо/влево – уже не agile.

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

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

    Допустим так и есть и я не всегда пишу тесты, но я четко понимаю: где/как/когда/зачем их писать, т.к. за спиной большой опыт. Коллега же пока только изучает вопрос, но уже так и ищет, где бы схалтурить… и что-то не написать.

    Так же и с применением agile. Очень хорошо подстроиться под окружение: что-то применить, опустить, адаптировать. Но лишь в том случае это будет работать хорошо, если вы набили шишки и неоднократно прошли все и вся, применяя ВСЕ практики agile.

    Возможно Павел прошел этот путь, достиг вершины и теперь его идея – адаптирование. А Денис ведет всех к этой вершине путем продвижения 100% чистого Agile и только после того, как он увидит, что вы неоднократно и правильно сделали все по agile он разрешит вам адаптироваться.

    Как вам мои мысли?

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

    Камрад Габриэль, ты мудр . Изложенное тобой правильно подмечает один из аспектов обсуждения, который пока оставался за кадром.
    Я немного про другое говорил – я говорил про то, что принципы работы которые лежат в основе всех работоспособных методологий на самом деле одни и те же – давай возьмем например RUP Made Easy и сравним с Agile Project Management with SCRUM. Спорим – мы НЕ найдем разногласий по принципам, обе книги призывают делать одно и то же разными способами. Каждая методика предлагает использовать разные практики – но если проследить практики до истоков, то окажется что они реализуют принципы, в следствие чего получается и 40часовая рабочая неделя, и загадочная вещь под названием “удовольствие от работы” и много чего еще другого. Лично для меня удовольствие от работы и worklife баланс – очень важные вещи (подымите руки для кого это не так). Именно за эти вещи я люблю аджайл, именно поэтому его пропагандирую. Именно поэтому не дам называть концлагеря страной свободы и победившей демократии.
    Поэтому дело в не следовании “догматическому аджайлу” – перечитайте мои посты, я против этого. Но я и против того, чтобы херить основные принципы, которые делают аджайл аджайлом.
    “Адаптации” же методом “намешаем до кучи и повыкидываем то что не можем делать”, которых я видел уже достаточно много (в том числе и в компании которой мы вместе работаем) – часто убивают эти принципы и их полезные следствия напрочь.
    Получается это так: представь например ситуацию – у тебя есть будильник и механические наручные часы. Функция – одна: показывать время, принципы осуществления функции – одинаковые: часовая пружина + маятник + передача системой колес. Но тебе же не приходит в голову произвольно поменять шестеренки между часами или повыкидывать половину? Потому что ты понимаешь – все детали (винтикишестеренкипрактики) образуют функциональное единство (часыметодологию), и выбрасываниезамена просто сломают часыметодологию. Даже если часы чудом будут идти – они будут показывать время с большой ошибкой.
    Даже тщательное вдумчивое многократное разбирание и собирание часов (выполнение правильного аджайла) ничем тебе не помогут – ты только лучше сможешь понять, что маятник D5 нельзя поставить на место маятника D2.5 – ну не встанет он просто!!! Ты можешь понять, что добавление камней может увеличить точность хода, да, и сделать такую адаптацию – если тебе позволяет квалификация.
    Адаптации же, о которых идет речь – они проистекают совсем из других источников: дураки в руководстве заказчика, немотивированные недоспециалисты в своей команде, неумение делать те или вещи, нежелание делать те или иные вещи, унаследованный “говнокод” (с) Дима Губа, амбиции менеджеров “показать себя мегаПМом”, политические игры “прикрыть задницу”. Вот такие адаптации – нах не нужны.
    Другое дело что сама бизнес-модель больших аутсорсинговых компаний часто заставляет идти на такие “адаптации”. Это вопрос не к менеджерам и не к команде, это вопрос к модели; но если мы обсуждаем “аутсорсинговые телеги” – давайте не называть их “аджайл самолетами”.

  • http://alovak.com Павел Габриель

    Денис, согласен с тобой, что для того, чтобы получить мега-результат нужно разделять/понимать/принимать все ценности и принципы agile.

    То, чего я не нашел в статье Павла – общее понимание ценностей/принципов между клиентом и исполнителем. Павел говорит о практиках и о том, что их можно адаптировать. Но практики – это не agile.

    Возможно мы говорим о разных вещах, называя их одним именем? 🙂

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

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

    Да, Паша, ты тут прав. Вопрос из плоскости применения практик, т.е. плоскости инструментов, выходит на более высокий уровень — ценностей и идеологии. Философии я бы сказал. Agile на корпоративном уровне постигает та же судьба, что и канбан и lean production — менеджеры с обоих сторон ничего фактически не меняя в своей практике работы с протестантским рвением выписывают только те составляющие из общей методологии, которые им нужны и удобны. Т.е. даже не просто меняя один маховик на другой, а собирая из будильника, курантов и касио некий механизм, который сами же потом и вращают периодическим взбадриванием, называя это “эффективной командой”. Тот у кого в голове есть только модель “телеги”, ничего кроме “телеги” собрать не сможет. Надо сначала новую модель загрузить в мозг.
    Вопрос с адаптациями с моей т.з. таит в себе проблему, о которой частично Паша (Габриель) пытался сказать: для тех кто еще не усвоил принципы и имеет не много опыта работы, адаптации это как сигнал: “Это идеализм, так не работает! Скомпануй что сможешь и пользуйся тем, что получилось. А что получилось назови — Agile.” Я не хочу сказать, что именно эта мысль читается в данной статье у Павла Веллера, нет. (Он говорит о том, как принципы agile преломляются в кривом зеркале сложных корпоративных взаимоотношений.) Но такая мысль будет кристаллизоваться в неокрепших умах. Это как молодые студенты начитавшись скрама уверывают, что все все кто не по скраму работают — старые закоренелые пердуны, которым место на свалке истории.
    Поэтому первое на что мы и будем обращать внимание — это на философию, ценности и принципы agile, а позже как из следования им рождаются и применяются практики, подходы, отношения, а уже из их эффективного применения проистекает эффективность и производительность.

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

    Юра сказал то что я хотел сказать еще понятнее 🙂
    Если мы правильно понимаем идеал и движемся к нему – то даже если мы приблизимся на ~70%, это уже даст офигенные результаты.
    А если мы сразу говорим “идеала нет” и соответственно париться приближением к нему мы не будем – то и этих 70% не получим.
    При это правильно указано что идеал у всех свой, у одних один, у других – другой, третьи агностики, а четвертые мистики. Ну так не надо тогда путать теплое с мягким: сделал что-то свое и оно работает – скажи “вот я сделал прикольную бодягу, отталкивался от идей аджайла!” Но не называй блин эту штуку аджайлом.

  • http://pveller.blogspot.com/ Павел Веллер

    >> [..] если мы обсуждаем “аутсорсинговые телеги” [..]

    Сервисная компания в режиме совместной разработки с корпоративным клиентом – вот контекст моего поста

    >> как принципы agile преломляются в кривом зеркале сложных корпоративных взаимоотношений

    Да. Именно так

    >> Но такая мысль будет кристаллизоваться в неокрепших умах

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

    >> идеал у всех свой, у одних один, у других – другой, третьи агностики, а четвертые мистики

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

    >> А если мы сразу говорим “идеала нет” и соответственно париться приближением к нему мы не будем [..]

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

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

    Э, камрад, я не против конкретных примеров. Главное, чтоб самовар известной субстанции на проектах не подавался как данность, с которой ничего нельзя сделать.
    И вообще осторожней – чтоб по итогам народ не разочаровался в работе в аутсорсе в свете изложенной “практики” 🙂

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

    >> [..] не подавался как данность

    это как стакан, который либо наполовину пустой либо наполовину полный. спорить можно долго, только воды там, как было 50%, так и осталось 50%. Нельзя абсолютно все воспринимать как данность – согласен полностью! Но и поменять асболютно все нельзя. Не всегда и не все. А для правильных выводов – надо понимать, откуда ноги растут.

    Ладно, я надеюсь, что та часть моего поста, которая была до фразы про адаптацию и agile, нашла свою аудиторию также, как ее нашла эта самая фраза 🙂

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

    Часть несомненно нашла. Тем, кто глубоко закопался в аутсорсинг, будет полезно узнать ускоренные методы раскидывания вилами и виляния частью – тут я с тобой согласен.
    У меня только одна, но большая просьба, которую я видимо никак не могу донести – не называть это словом “аджайл”, после аджайла адаптированного “под сложного но прибыльного клиента” разлива люди начинают считать что аджайл это отстой.
    P.S. И давай без закидываний “я практик” – тут все практики, просто у всех практика разная: одни сидят с индусским самоваром, другие делают хорошие продукты, третьи запускают интересные стартапы. То, что данность и практика для тебя – для многих нонсенс и повод посочувствовать.

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

    >> не называть это словом “аджайл”

    Эту часть ты донес абсолютно понятно. Про значение слов мы обязательно поговорим на этой площадке (я как раз тебе послал статью для публикации 🙂 ). Давай там продолжим, ок?

    >> И давай без закидываний “я практик” – тут все практики, просто у всех практика разная [..]

    Согласен. Не закидывания ради было сказано – я обозначал свои идеалы. И сегодня, действительно, они в практике сервисных компаний, для которых, кстати, не чужд и тот самый правильный Аджайл. У меня много интересных живых примеров, которыми я надеюсь в скором времени поделиться на этой площадке. Этим летом своими глазами видел и общался с командой (в компании, в который мы с тобой вместе работаем), которая (пример, только один пример, прошу не цепляться) работает только в парах на столах с двойными мониторами (даже часть open space специальным образом перестроена, перегородки убраны, и т.д.).

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

    И, кстати, про механику раскидвания вилами и умение вилять частью я еще не успел рассказать 🙂 Одно слово сказал – адаптироваться, остальное сказал не я. Я же все больше писал про истоки “нестандартного” и нам не всегда понятного поведения корпораций и их отличия от нам более понятных, но от этого не всегда более приятных ISV клиентов. Эта часть, как думаешь, дошла? не утонула в наших дебатах ?

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

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

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

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

    [..] Бизнес ведь все-таки клиент и музыку заказывает, но сам играть не умеет. Вот мы и будем играть, как считаем нужным, а они нам перечить не станут [..]

    была сказана от лица IT отдела той самой бизнес копмании (их мысли вслух), не команды за океаном.

  • http://www.targetprocess.com firefalcon

    Прочитал статью. Прочитал комментарии. Чего-то не до конца понял о чем спор. Вы спорите о том, что такое Agile? Или о том что такое он же в non-ISV компаниях?

    Кстати, переубеждение кого-либо с помощью метафор опасно, потому что метафоры могут быть совершенно не применимы к рассматриваемому случаю. Но про самолет мне понравилось 🙂

    Вообще в статье при прочтении много мест, которые я считаю неправильными. Автор работал в ISV компании хотя бы год?

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

    >> Чего-то не до конца понял о чем спор

    Да, ты прав. Я старался привлечь аудиторию к той части статьи, где я обобщал истоки и мотивационные позывы корпоративных клиентов в выборе того или иного способа производства проектных работ. А аудитория, в основном, апеллировала к другой части статьи, где я назвал словом agile варрант выходы из подобных ситуаций, предполагающий активную адаптацию. И, тем не менее, обмен мнениями состоялся, и общие точки обнаружены были.

    >> Вы спорите о том, что такое Agile?

    Нет. Но, надеюсь, очень скоро обменяемся мнениями, обсуждая мой следующий пост. Уважаемая редакция уже имеет материал к публикации. Ждем.

    >> Или о том что такое он же в non-ISV компаниях?

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

    >> Вообще в статье при прочтении много мест, которые я считаю неправильными

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

    >> Автор работал в ISV компании хотя бы год?

    Нет. Ни в ISV ни в корпорации автор не работал (если, конечно, не считать онсайт консалтинга. Другими словами – сотрудником не был и соответственно год стажа в одной конкретной компании такого типа насчитать не смогу). Я, кстати, свою точку зрения и систему координат достаточно четко обозначил: сервисная компания, работающая на (а не в) ISV и корпорации американского рынка. Поэтому и угол зрения у меня немного другой. Очевидно, что конкретная компания может разительно отличаться от общих выводов: и среди ISV, я уверен, есть закидоны похлеще корпоративных, и в обратную сторону формула работает и есть корпорации с уникальным климатом для IT. Я подводил общий знаменатель своего опыта. Насколько репрезентативна моя выборка, я смогу сказать, только проработав еще столько же и перепроверив свои выводы. Или, как вариант, просуммировав наш общий опыт. Давайте делиться.

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

    Павел, однозначно правильные ответы – в каждой ситуации есть. Как и однозначно неправильные. Есть более-менее сносные, более или менее удачные.
    Главное чтоб одни не назывались другими под соусом “адаптации” 🙂
    Ну и чтоб после адаптации мы не выдавали гамбургер за филе миньон 🙂

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

    >> однозначно правильные ответы – в каждой ситуации есть.

    не соглашусь с тобой, Денис, и вот почему. В настоящей ситуации слишком много неизвестных, чтобы гарантировано давать однозначно верный ответ. Люди – не линейные системы (и слава Богу). Задача коммивояжера, например, решается только в частных случаях. Например, рассматривая пропускную способность дорог, принимают среднюю скорость движения как константу на отдельных участках, так как достоверно учесть реальное поведение других участников движения и неисправности собственного транспорта невозможно. Настоящего правильного ответа нет – только приближенные решение разной степени достоверности. Вот что есть – это правильный вектор (!) решения, который чем лучше описан частный случай (= меньше неизвестных), тем к более достоверному ответу приведет.

    И уж тем более нету однозначных ответов в общих случаях. А в своем последнем комментарии я именно общие случаи (типа «ISV клиент» или «non-ISV клиент») имел в виду.

    А про гамбургеры – в следующем посте. Там и продолжим.

  • http://www.targetprocess.com firefalcon

    1. Ввиду того, что коменты длинные, предлагаю засунуть форму добавления комента вниз и сделать ее большой. Неудобно же.

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

    Мне пофиг, работает команда по скрам, по экспи или еще как. Мне важны следующие вещи.
    1. Деливери нормальных качественных билдов с частотой соответствующей контексту
    2. Чтоб люди из команды не бежали (а приводили хороших спецов из числа друзей в нее же)
    3. Чтобы клиенты находили багов мало, а не много
    4. Чтобы клиенты были довольны софтом, за который деньги платят

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

    Так ли хорош манифест и нельзя ли придумать чего-то получше? Может и можно, но я пока ничего получше не встречал (я имею ввиду фундаментально получше)

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

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

    Не знаю, чего я это пишу в столь поздний чаc…

  • http://www.targetprocess.com firefalcon

    Блин! Поправте форматирование абзацев в коментах! Или дайте мне доступ на FTP я сам поправлю.

  • http://www.targetprocess.com firefalcon

    PPS. И еще у сервера время на час отстает.

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

    @firefalcon Да, именно так устроен и мо

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

    виноват. вторая попытка

    @firefalcon Да, именно так устроен и мой мир. И в частности об этом – в моем следующем посте, который, я надеюсь, появится на agile.by сегодня-завтра.

    Я предлагаю закруглиться с комментариями к этому посту и продолжить в новом. Там контекст будет куда ближе.

    p.s. на счет абзацев – это, похоже, стили. перевод каретки в p теги верно расставляется. В RSS, например, все путем отображается.

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

    2firefalcon,
    1. Займемся сайтом — может быть поменяем дизайн и тогда же заменим форму доб. комментария.
    2. Форма хоть и небольшая, но умеет скроллится вдоль комментов (в FF и Chrome).
    3. Что не нравится в абзацах? Их надо разделить небольшим промежутком?
    4. Сервер как ты понимаешь не в Минске находится. 🙂

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

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

  • http://www.targetprocess.com firefalcon

    У меня в сафари не скролится форма к сожалению. И да, надо промежутки между P

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

    >> Но ответ для каждого конкрентного контекста – есть.

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

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

    Блин, ну вот этот ответ и будет однозначно правильным, согласен?
    Будут и другие ответы – только они будут менее правильные, хоть и допустимые.

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

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

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

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

  • http://www.targetprocess.com firefalcon

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

    Вот, скажем, возьмем парное программирование. Скажем, одобрила его команда. Внедрили. Программируют. И через пару месяцев двоим не нравится. Колбасит их от ПП. Что с ними делать? Увольнять? Изолировать? Переубеждать долго и упорно пока не надоест? Или уволить всю команду, а их оставить? Или убрать ПП вообще? Или послать на рыбалку на неделю всей командой?

    И фиг поймешь, какой вариант в долгосрочной перспективе будет оптимальный. Это нелинейные системы. Это сложные адаптивные системы. И решение часто не очевидно. И очевидное решение часто не лучшее в долгосрочной перспективе.

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

    Не-линейность – не единственная сложность. Еще один немаловажный фактор, добавляющий сложности, – не-дискретность. Пилотируя проект, решения мы принимаем непрерывно (continuously), и степень неопределенности всегда больше ноля. Но Денис, я думаю, говорит о решениях, которые определяют общий вектор, а не конкретные шаги на 5 ходов вперед, как в шахматах. Так что спорить, скорее всего, не о чем. Процесс выбора решения и последующего непрерывного тюнинга можно назвать моделированием. Как обычно, вопрос интерпретации. Принимая решения, я четко отдаю себе отчет, что решаю задачу оптимизации (вполне себе моделирование). Не хочу только соглашаться, что где-то там есть однозначно верное решение – есть целый ворох правильных решений, в разной степени удовлетворяющих все заинтересованные стороны. С чем могу согласиться – так это с тем, что принятое правильное решение необходимо превращать в действие и ответственно отрабатывать. Это проще делать, считая принятое решение однозначно верным 🙂 Уверенность в себе и в своих действиях и дает это самое ощущение.

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

    Ой, давайте толькое без метафизики, ладно?
    Если бы надо было построить универсальную модель поведения многоэтнического общества в момент смены экономических формаций – вот это было бы да, это было бы сложно; модели же для проектных команд – довольно просты и имеют достаточно небольшое количество переменных. Собственно базовые модели я даю на тренингах, и модели эти отлично работают – что подтверждается а) постоянным перезаказом тренингов и б) собственным использованием этих моделей.
    У отрицающих концептуальную простоту этих моделей обычно одна из двух проблем – или а) им хочется быть Супер-Дупер-Менеджерами, Единственными Обладателями Сакрального знания или б) системный анализ пока за пределами их возможностей, ну как алгебра для папуасов при миклухе.
    Есть, конечно, еще одна проблема – не у всех достаточно воли и умения претворить модели в жизнь. Но это уже совсем другой вопрос – некоторые и пьяную компанию под окнами разогнать не могут, не то что модель реализовать.
    А что касается “Процесс выбора решения и последующего непрерывного тюнинга можно назвать моделированием” – вот как раз эта фраза демонстрирует непонимание сущности моделирования, при понимании они звучала бы так: “я постоянно держу в голове модель своего текущего проекта и постоянно обновляю ее как по значениям параметров, так и по их составу – и отталкиваясь от этой модели принимаю решения”. Вот так и получается что “code-and-fix с внесением скрамовских терминов можно назвать agile”.
    Вообще если говорить про эпам – менеджмент by exception это повальная болезнь менеджеров на всех уровнях, моделей строить и прогнозировать развитие событий не принято – думаем про сейчас, пытаемся сделать, как где что сломается – “будем адаптироваться”, если что – ударный труд нас спасет.

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

    Камрады, ваше текущее расуждение явно вышло за пределы обсуждения статьи.
    У нас есть такой отличный инструмент, как лист рассылки на гугле. О нем указано внизу под комментами (agile-belarus@googlegroups.com). Мы когда-то специально не стали форум на сайт, а сделали этот лист рассылки. Думаю, что интересующиемя моделями и их построением могут перенести свое обсуждение туда.
    Возражения есть?

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

    Возражений нет. Только один короткий комментарий. Денис не прав с выводами про management by exception и с ярлыком code-and-fix в им названной компании. Но об этом, как Юра ты правильно заметил, не правильно продолжать в обсуждении оригинального поста. Идеальная площадка для такой дискуссии – закрытый семинар. Что мы и сделаем в мой следующий приезд в Минск.

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

    Не, даже в закрытом семинаре обсуждений с приписыванием мне вещей которые я не говорил мы вести не будем.

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

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

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

      Камрад, да можешь не соглашаться – мне изофаллически в общем-то; но работоспособный метод принятия решений – он именно такой, и его вывела именно часто поминаемая тобой практика. Так что спорить ты будешь не со мной, а с практикой.
      Ну а аналогии… При правильном использовании – аналогии не менее точный инструмент чем скальпель. При неправильном использовании даже термины и логика – не работают. Срочно учись ими пользоваться, иначе в менее дружелюбном месте можно наткнуться на более жОсткие указания ошибок в рассуждениях (типа “ну тогда можно назвать тебя балбесом – раз ты не заморочен соблюдением признаков классификации явления: если мы привязываемся к 1-2 признакам вместо полной совокупности, то по 1-2 признакам ты на балбеса вполне проходишь”). no offence, это ценный совет на будущее от профессиональных доносителей мысли 🙂