Comments 26
Любая команда — это рабочий коллектив.
– ВОТ ОНИ – СМЕРТНЫЕ, – продолжал Смерть. – ВСЕ, ЧТО У НИХ ЕСТЬ, – СОВСЕМ НЕМНОГО ЛЕТ В ЭТОМ МИРЕ. И ОНИ ПРОВОДЯТ ДРАГОЦЕННЫЕ ГОДЫ ЖИЗНИ ЗА УСЛОЖНЕНИЕМ ВСЕГО, К ЧЕМУ ПРИКАСАЮТСЯ. ОЧАРОВАТЕЛЬНО. ПОПРОБУЙ КОРНИШОН.
В связи с этим, хорошая команда — команда, которая действует заодно. Вместе работают над продуктом, живут им. Вместе решают трудовые конфликты, а не ходят по одному за повышениями и проектами к руководству. Хорошая команда не расходится, а уходит на следующую работу единым коллективом. Отличная команда — без пяти минут ячейка профсоюза.
Такая команда явление уникальное, много их не может быть по определению, звезды редко складываются так, что в одном месте собирается десяток отличных профессионалов, которых объединяет общий интерес, и которые при этом отлично совместимы друг с другом. А Аджайл вроде как претендует на звание панацеи от всех проблем разработки ПО.
Думаю как раз это и является главной причиной того почему в большинстве фирм получается так, что «мы все делаем по заветам религии, а на выходе получается какое-то говно» — или карго-культ или потогонка, конвейер для сгорания разработчиков.
Такая команда явление уникальное, много их не может быть по определению, звезды редко складываются так, что в одном месте собирается десяток отличных профессионалов, которых объединяет общий интерес, и которые при этом отлично совместимы друг с другом.
vvbob, я с вами согласен! Очень стараюсь посещать побольше IT-конференций, спрашивать у людей как у них на работе, есть ли какая-то солидарность, ценят ли труд разработчиков, как команда воспринимает Agile. К сожалению, мой скромный опыт показывает, что далеко не все пытаются такую команду найти.
Думаю как раз это и является главной причиной того почему в большинстве фирм получается так, что «мы все делаем по заветам религии, а на выходе получается какое-то говно» — или карго-культ или потогонка, конвейер для сгорания разработчиков.
И с этим согласен. Но на это есть управа — религии/культу/идеологии нужно противопоставить именно экономическое обоснование, материальные причины. Собственно, этой статьёй я пытался показать причины и следствия.
Да, Канбан-метод не очень пересекается с аджайлом, но это и не скрывается — это не плод любви ужа и ежа, это самостоятельная философия со своей историей, своими ценностями и принципами. Частично они пересекаются с ценностями и принципами Agile, частично нет.
Исторически Канбан-метод базируется на теории ограничения систем, бережливом производстве и трудах Деминга. В его основе лежат ценности, базирующиеся на убеждении о том, что взаимное уважение всех лиц, делающих совместный вклад в общее дело, обеспечивает не только успех такого предприятия, но и его целесообразность. Все ценности Канбана можно свести к одному слову — «уважение». Это прозрачность, баланс, сотрудничество, клиентоориентированность, поток, лидерство, понимание, согласение и уважение.
Это совсем история не про Agile и даже не про Waterfall. Это отдельный независимый взгляд на проблему организации разработки.
Чем отличается материалистический взгляд от идеалистического? Тем что я писал про деньги, а вы про философию, убеждения и уважение. Т.е. Канбан за всё хорошее? То что кажется — это не то что есть. Соглашусь, что возможно Канбан чудно подходит для расправляющих плечики с гениальными идеями.
Где вы видите гениальный инструмент, я вижу скрещенного ужа с ежом ради оптимизации затрат, эффективной эксплуатации сотрудников и разрешения некоторых противоречий крупного органического производства.
Если быть честными, то такие важные слова как ценности, уважение, мифы, успех — очковтирательство, за которым есть в лучшем случае передача описательного опыта (не аналитическая работа), в худшем (см. критика идеологии) — втюхивание инфобизнеса. Мой ответ обязан быть жёстким, потому что вы занимаетесь пастырством.
Если быть честными, то Вы просто не очень круто разобрались в сути Agile, и совсем паршиво — конкретно в Kanban.
С практической точки зрения — Kanban предпочтительнее других гибких методологий в большинстве ситуаций, равно как гибкие предпочтительнее водопада опять же в большинстве ситуаций. Вы можете называть это эксплуатацией сотрудников ради оптимизации затрат, а я это называю продуктивной работой. Разница в том, что я на работе не штаны просиживаю за зарплату, а пытаюсь что-то сделать полезное — для себя, для продукта, для команды, для заказчика — не важно. (Не потому, что мне за это платят, а чисто чтобы не тратить время своей жизни впустую, тупо разменивая большую его часть на зарплату.) И мне нравится получать больше того результата, к которому я стремлюсь, за то же время — я называю это продуктивностью. И мне нравятся процессы, инструменты и методологии, которые этому способствуют.
Так уж сложилось, что именно я выбирал используемую методологию во всех проектах, в которых участвовал за последние много лет. Мне никто не навязывал "модные" гибкие методологии. Я начал использовать канбан абсолютно по доброй воле, и только в тот момент, когда разобрался, в чём его суть и как его применять с пользой для себя. Проекты разные, в одних вообще никаких методологий не требуется (как раз в прошлом месяце один такой я сделал), в других нужен водопад (напр. когда достаточно хорошо заранее знаешь что нужно получить, плюс нужно гарантировать высокое качество), в третьих лучше всего работает канбан (напр. все админские/девопсовые задачи и разработка мелких микросервисов небольшими командами), в четвёртых скрам позволяет получить более предсказуемые и сбалансированные результаты (впрочем, тут мы ступаем на тонкий лёд предположений, потому что нормально работающего скрама я пока не видел, а то, что видел, в лучшем случае работало очень средненько и создавало впечатление, что канбан дал бы лучшие результаты).
В том, как я использую все эти методологии нет никакой религии и никакой эксплуатации. Это просто инструменты, которые можно применять по назначению, понимая их суть и с пользой для себя, а можно крайне расточительно и болезненно, в духе "забивал гвоздь микроскопом, попал по пальцу, сломал и палец и микроскоп, а гвоздь так и остался незабитым". Умный человек не станет в этой ситуации винить микроскоп, правда ведь?
я это называю продуктивной работой. Разница в том, что я на работе не штаны просиживаю за зарплату, а пытаюсь что-то сделать полезное
я выбирал используемую методологию во всех проектах, в которых участвовал за последние много лет. Мне никто не навязывал "модные" гибкие методологии. Я начал использовать канбан абсолютно по доброй воле, и только в тот момент, когда разобрался, в чём его суть и как его применять с пользой для себя.
Канбан чудно подходит для расправляющих плечики с гениальными идеями
Вот и атланты подошли. Канбан вам нравится потому, что как лиду/архитектору, вам с ним проще проталкивать свои решения, да ещё и "продутивно". Почему это плохо, из моего текста выше понять можно.
Вы просто не очень круто разобрались в сути Agile, и совсем паршиво — конкретно в Kanban
Разоблачайте! С аргументированной критикой, по пунктам, с привязкой к прибыли (политической экономией как инструментом в идеале), а не апеллируя к критически не осознанному личному опыту. А в вашем же ответе Вы клерик культа, ведь говорите что я не разобрался, не попробовал как следует, не приблизился — это типичный разговор атеиста и священника.
Всё дело в том, что это пост в рамках политэкономии. Я сначала проанализировал вид нового, нетоварного способа производства, а исследование гибких практик тут явилось логичным продолжением. Только заглянув в самое основание производства — товара или же виртуального товара, каковы производственные отношения — только в этом случае возможно действительно понять как работает Scrum, XP, OKR, Kanban, Waterfall.
Вы не слышите ничего, кроме собственных мыслей, к сожалению.
Я же чётко написал, что на практике канбан на определённых типах проектов заметно повышал продуктивность (и лично мою и команды), т.е. количество результата в продакшне за то же время. Где Вы здесь нашли культ — я не знаю. Я не фанат конкретной методологии и не агитирую за неё, я выбираю ту, которая лучше работает в конкретном типе проектов и для конкретной имеющейся команды — и на практике активно применяю как отсутствие методологии, так и водопад, и канбан.
с привязкой к прибыли (политической экономией как инструментом в идеале)
Мне нет дела до прибыли, уж простите. Здравый смысл подсказывает, что, вероятно, повышение продуктивности должно увеличивать прибыль, потому что при тех же расходах увеличивается количество производимого продукта. Ну и плюс ещё ни один из моих заказчиков, которые как раз бизнесмены, в отличие от меня, на повышение продуктивности не жаловался, что у него из-за этого прибыль падает.
а не апеллируя к критически не осознанному личному опыту
Это хамство, вообще-то. У меня с осознанностью всё в порядке, благо медитации практикую очень много лет. Так что мой опыт вполне критически осознан.
Другое дело, что я действительно опираюсь на личный опыт — это правда. Не устраивает — игнорируйте. У других этот опыт вполне может показывать противоположные результаты, и я не считаю свой опыт единственный истинно верным.
только в этом случае возможно действительно понять
Почему Вы так решили? И каким образом Ваше понимание отменяет мой практический опыт?
Мне нет дела до прибыли
я действительно опираюсь на личный опыт
Я не фанат конкретной методологии и не агитирую за неё, я выбираю ту, которая лучше работает в конкретном типе проектов и для конкретной имеющейся команды — и на практике активно применяю как отсутствие методологии, так и водопад, и канбан.
вы не слышите ничего, кроме собственных мыслей, к сожалению.
Вы уверены что это я не слышу? я последователен, держусь своей позиции. Почему ваш опыт недостаточен?
- Ошибка выжившего.
- Это описательное наблюдение, а не анализ. Возможно следует посмотреть ваши публикации.
Хотите использовать канбан — пожалуйста. Моя позиция в том, что он компромисс, ради управляемости, который недобирает ни у одного подхода. Любая методология может работать — вопрос ресурсов и результатов.
Это хамство, вообще-то. У меня с осознанностью всё в порядке, благо медитации практикую очень много лет. Так что мой опыт вполне критически осознан.
Простите, с моей стороны это НЕ переход на личности. Вы предъявляете свой опыт, и предлагаете в него верить. Если бы вы рассказали о проектах, их экономике, причине выбора канбана/неканбана это бы выглядело совершенно иначе.
В статье сказано следующее — экономике продукта (типу производства) соответствуют производственные отношения (методология). Так как мы все живём при свободном рынке, работаем чаще всего в иерархических организациях, мы не свободны от общества в котором живём. Поэтому выбор нередко лишь в нашей голове.
Моя позиция в том, что он компромисс, ради управляемости, который недобирает ни у одного подхода.
Да, он компромисс. Моя позиция в том, :) что именно благодаря этому — он неплохо работает, в отличие от своих менее компромиссных альтернатив.
Если бы вы рассказали о проектах, их экономике, причине выбора канбана/неканбана это бы выглядело совершенно иначе.
Да запросто.
Первый основной кейс: небольшие команды (3-7 человек) программистов, разрабатывают микросервисы.
Второй основной кейс: задачи для админов/девопсов.
Второй объяснить проще всего: у админов задачи обычно срочные, ждать пока начнётся следующий спринт скрама чтобы взять задачу в работу — вообще не вариант. Плюс у них случаются регулярно повторяющиеся задачи, плюс зачастую нет какого-то набора "функциональности", который они обязательно должны релизнуть за один спринт. В целом — ни скрам, ни тем более водопад сюда не лепятся, от слова совсем. Так что выбор обычно между ничем и канбаном, и он довольно очевиден, нет?
Первый кейс вполне может использовать и водопад, и скрам. Но. Хоть микросервисы и "микро", но требования всё-равно успевают меняться один-два раза в неделю (обычно источник даже не бизнес, а фронт, который "внезапно" осознаёт, что запланированное API не даёт им то, чего им хочется, и делает это не в момент ревью предложенного API, а когда сами доходят до реализации нужной фичи) с одной стороны, никто не даёт время на его тщательное проектирование и разработку по водопаду с другой стороны, и работы по микросервису обычно не так много, чтобы растягивать её на несколько полных спринтов с третьей стороны. В результате при использовании скрама и спринтов разработка идёт заметно медленнее, частично из-за блокирования реализации новых требований до следующего спринта, частично из-за того, что задачи нередко оказываются готовы к релизу раньше, чем заканчивается спринт (и нет, набирать больше задач на спринт в этой ситуации проблему не решает, просто такова природа спринтов — фиксированное количество задач за фиксированное время редко складывается так, что ровно всё это время реально было использовано на эти задачи). А ещё при разработке микросервисов нередко нужно выкатывать их на стейдж/прод несколько раз в неделю, не дожидаясь конца спринта (иными словами релизы и спринты сильно не соответствуют друг другу, что тоже не помогает).
Помимо этого, канбан, благодаря компромиссам, намного легче внедрить. Он сходу решает некоторые, более чем реальные проблемы — напр. когда в работу набирают тьму задач, все начаты, и ни одна не закончена. Он значительно дешевле обходится в плане дополнительных процессов и митингов. Он предъявляет намного более низкие требования к команде. Иными словами, как я и говорил: он более практичен.
Есть идеальный мир, в котором лучше всего бы работал коммунизм… в теории. А на практике идеального мира нет, люди такие какие они есть, и поэтому никакого коммунизма нам пока не светит. Та же фигня актуальна для водопада и скрама: в идеальных условиях, когда постановка задачи полностью известна с самого начала, и не будет меняться — лучше всего сработает водопад… но такое почти не встречается; идеальные условия в которых скрам будет показывать чудеса тоже довольно очевидны и довольно редко встречаются в реальном мире.
Приведённые вами примеры совершенно не противоречит тому что я написал в статье. Похоже, что у вас некоторая анархия производства (хотя за DevOps точно не скажу), которую вы пытаетесь разрешить самым понятным и удобным способом — применяя канбан.
Есть идеальный мир, в котором лучше всего бы работал коммунизм… в теории. А на практике идеального мира нет, люди такие какие они есть, и поэтому никакого коммунизма нам пока не светит. Та же фигня актуальна для водопада и скрама: в идеальных условиях, когда постановка задачи полностью известна с самого начала, и не будет меняться — лучше всего сработает водопад… но такое почти не встречается; идеальные условия в которых скрам будет показывать чудеса тоже довольно очевидны и довольно редко встречаются в реальном мире.
Видимо с этим вы и входите в клинч — с вашим субъективным опытом, признанием исторического материализма. Сейчас есть ПО в каждом кармане, такси по МСК ездят в пилотном режиме без водителей, грузовики скоро на закрытых териториях будут без водителей, появляются магазины без продавцов и грузчиков, 3D принтеры становятся всё доступнее, сельское хозяйство уже обходится без комбайнёров, скоро в прошлое начнут уходить машинисты поездов, есть роботы готовящие еду. Оглянитесь — мир меняется. Он не идеальный но уже другой.
На основании простейшей модели делаются тривиальные выводы.
Которые справедливы в той же мере, в какой модель отражает реальность.
Гибкие методологии разработки — это один из способов снижения рисков от неопределенности в ожидаемых результатах и оценке трудозатрат проектов.
Но Agile совершенно не является инструментом повышения эксплуатации.
А где Вы доказываете, что сокращение сроков разработки зависит именно от повышения эксплуатации?
Вы же совершенно верно пишете, что Agile — не делать лишнего, а не делать быстрее.
А где Вы доказываете, что сокращение сроков разработки зависит именно от повышения эксплуатации? Вы же совершенно верно пишете, что Agile — не делать лишнего, а не делать быстрее.
Вы просите осветить вопрос интенсивности работ при Agile, как это может происходить без повышения эксплуатации? Если так, я ответил. Повышение степени эксплуатации снижает вовлечённость, а значит вредит результату. Чтобы работники были заинтересованы в результатах труда, их труд должен быть менее отчуждён (свопы, премиальный фонд от прибыли).
На основании простейшей модели делаются тривиальные выводы. Которые справедливы в той же мере, в какой модель отражает реальность.
Наверное не правильно вступать в спор с тем у кого только комментарии… но я в отпуске)
Где же я отрываюсь от реальности? Будут конструктивные кейсы?
Гибкие методологии разработки — это один из способов снижения рисков от неопределенности в ожидаемых результатах и оценке трудозатрат проектов.
Эта и прошлая статья о том, почему вы не правы. Гибкие методологии — не один из инструментов, а набор инструментария для определённых задач, при определённых производственных отношениях.
Риски, приемлемая норма прибыли — это всё сказки для тараски, как паттерны тех.анализа на форекс — можно играть, но 97% проигрывают, как и в напёрстки.
Наверное не правильно вступать в спор с тем у кого только комментарии
Вот тут я не корректно выразился, и может восприниматься шовинистически. Смотрите, в профиле у вас нет не только публикаций, но не указаны хабы на которые вы подписаны, вы не подписаны на авторов или компании, у вас весьма обезличенная учётка. Для весьма ананонимизированного пользователя, вы как-то жирно заходите с троллингом. Не уверен, что это не профессиональное хобби, но готов к любому конкретному обсуждению.
Но какое это имеет отношение к обсуждаемому вопросу?
Комментирую я менее 1% от прочитанных статей.
Рассматривать современное общество и производственные отношения только с точки зрения экономических отношений… Да, я считаю, что это очень упрощенная модель. Вы не согласны?
Как в эту модель вписывается гемификация или другие нематериальные способы пощекотать ЧСВ? Почему зону комфорта предпочитают более высокой зарплате?
Рассматривать современное общество и производственные отношения только с точки зрения экономических отношений… Да, я считаю, что это очень упрощенная модель.
Вообще-то, я упоминал какие средства поощрения доступны кроме материального. Но это не важно, потому что если кто-то из нас берёт ипотеку в коронокризис, нет у нас никаких факторов более важных, чем деньги. Сначала деньги, потом рюшечки и хотелки. Какое бытие — такое сознание. Вы считаете что это не важно, очевидно потому, что не понимаете как живёт средний россиянин, материальное положение ваших знакомых достойное. IT'шники — рабочая аристократия, очень близорукая к положению остального рабочего движения. И я считаю, что во многом потому, что в нашей сфере есть место новому способу нетоварного производства.
Ответ нет, я не согласен. В чём разница между материализмом и идеализмом, быстро сможете найти видео на ютубе.
Возможно ли ускорить выход продукта, внедрив Agile?
Нет, невозможно.
Это же неверный вывод!
Agile методологии позволяют ускорять выход продуктов за счет нереализации ненужного или слабо востребованного функционала, который можно будет добавить позднее при наличии подтверждённого спроса, а не гипотез.
Ну и экономический вывод, что Agile работает там, где венчурный капитал — достаточно спорен. Управление портфелем проектов в крупных компаниях не имеет отношения к венчурному капиталу.
Но то, что для успешного внедрения требуются вполне определенные производственные отношения, здесь мне возразить нечего.
Agile расцвел, когда пофейлился RUP.
Стоимость детерменизма в «водопадной» разработке слишком высока для большинства проектов, которые востребованы на рынке.
Свопы, премиальные фонды — очень плохо работают там, где финансовый результат не зависит напрямую от трудозатрат. Это скорее средство удержания, а не мотивации. И своего рода лотерея (у меня были опционы в 2-х компаниях, миллионов не принесли).
«В итоге, если продукт разрабатывается под одного потребителя и не будет изменяться, применять Agile, следовать принципам и практикам SOLID, GRASP, DDD, TDD, KISS экономически нецелесообразно.»
Вот это достаточно сильное упрощение модели.
ПО, которое не изменяется, очень часто вызывает у пользователей только боль и со временем умирает.
Т.к. предсказывать будущее мало кто умеет, т.ч. причина для изменений может появится (новые бизнес-процессы, изменение норм, эволюция IT систем и т.п.)
И базируется утверждение на предпосылке, что заказчик точно знает чего хочет (т.к. пишет техническое задание). А реальные потребности и сценарии использования возникают на этапе внедрения и эксплуатации.
Возьмите автомобиль времен Маркса и современный. Можно ли было запроектировать так, чтобы потом ничего не менять?
Agile методологии позволяют ускорять выход продуктов за счет нереализации ненужного или слабо востребованного функционала, который можно будет добавить позднее при наличии подтверждённого спроса, а не гипотез.
Вы в данном случае говорите о MVP. Имелось ввиду другое. Представим себе гипотетическую ситуацию, когда продукт А делают по водопаду, а конкурирующий продукт B по скраму. Оба продукта в итоге имеют один и тот же функционал. Какой продукт обойдётся дешевле по ресурсам? Очевидно, продукт А. Продукт В строится итеративно, а значит должен итеративно реагировать на обратную связь. Что здесь важно — что эти фреймворки не должны становится поводом к увеличению интенсификации труда.
Ну и экономический вывод, что Agile работает там, где венчурный капитал — достаточно спорен. Управление портфелем проектов в крупных компаниях не имеет отношения к венчурному капиталу.
В прошлом посте я это разъяснял. Дело в том, что если вы делаете продукт под определённого клиента с установленным списком требований, производитель вынуждены авансировать капитал (вкладывать деньги) во все стадии производства (разработки), и даже по результату, акт приёма вы можете не подписать. В случае виртуального товара, потребители получают продукт порционно, и вкладывать всю сумму не нужно — в любой момент можно отказаться от проекта. Венчурный капитал — это инвестирование в рисковые проекты, всегда с планом, поэтапное.
«В итоге, если продукт разрабатывается под одного потребителя и не будет изменяться, применять Agile, следовать принципам и практикам SOLID, GRASP, DDD, TDD, KISS экономически нецелесообразно.»
Вот это достаточно сильное упрощение модели.
Рыночек решает. Если ваша выгода -реализовать требования и сдать, вы не будете от своих команд просить качественного кода — только минимальный продукт, соответствующий пожеланиям заказчика. Остальное — расходы! Таково товарное производство и его имманентные законы.
ПО, которое не изменяется, очень часто вызывает у пользователей только боль и со временем умирает.
Т.к. предсказывать будущее мало кто умеет, т.ч. причина для изменений может появится (новые бизнес-процессы, изменение норм, эволюция IT систем и т.п.)
И базируется утверждение на предпосылке, что заказчик точно знает чего хочет (т.к. пишет техническое задание). А реальные потребности и сценарии использования возникают на этапе внедрения и эксплуатации.
Рыночек решает — имманентные законы товарного производства. На практике, заказчика садят на "поддержку", и все всем довольны. Если мы будем в этом моменте честны, то SOLID и прочие в таких проектах возникает вопреки организации, по инициативе команд.
Я не пытаюсь противоречить здравому смыслу — вы упрощаете мою позицию. Есть противоречия между работниками и менеджерами, между собственниками и работниками, между собственниками и потребителями, между производительными рабочими и потребителями. Моя позиция, материалистическая, она отталкивается от этих противоречий. Но точно не исключает здравого смысла.
Представим себе гипотетическую ситуацию, когда продукт А делают по водопаду, а конкурирующий продукт B по скраму. Оба продукта в итоге имеют один и тот же функционал. Какой продукт обойдётся дешевле по ресурсам? Очевидно, продукт А.
Нет, это совсем не очевидно.
Стоимость исправления дефектов разная в зависимости от того, на какой фазе ЖЦ он обнаружен.
Подход А позволяет выявлять дефекты на ранних стадиях за счет методологии и обратной связи, подход Б нет. Т.е. стоимость устранения архитектурных просчетов может может значительно сказаться на стоимости реализации.
Нет гарантий, что водопад эффективнее даже при статических требованиях.
Какой продукт обойдётся дешевле по ресурсам? Очевидно, продукт А. Продукт В строится итеративно, а значит должен итеративно реагировать на обратную связь.
Цитировать стоило так.
Просчёты архитектуры не связаны с методологией. Вы идеализируете, рассматриваете коня в вакууме. Ваши просчёты останутся в техдолг, а за крупные просчёты заплатите лично (где-то доверием, где-то премией, где-то штрафом, иногда работой).
Водопад эффективнее, потому что он директивный, потому что такова сущность деятельности. Если у вас не исследовательская задача, а понятная и рядовая, то водопад эффективнее, но губительно для качества кода, команды, и т.д. Странно с этим спорить.
В случае продукта В, вы будите тратить время как минимум на регулярное планирование и прочие церемониалы.
Вот выиграли вы тендер на госзакупках. Вы действительно хотите сказать что будет полноценный Agile? Заказчик возможно не станет отвечать на ваши уточняющие вопросы. И на практике такое бывает не редко. Бывает так что менеджмент берёт задачи которые командам не по силам в отведённое время, потому что это его KPI. Вы действительно считаете, что в этой ситуации что-то бывает гибким, или не сталкивались с таким?
В случае продукта В, вы будите тратить время как минимум на регулярное планирование и прочие церемониалы.
Это инвестиции сродни покупке страхового полиса.
Если страховой случай не наступил, то кажется потерей денег.
Но без этих ритуалов очень сложно обеспечить прозрачный статус проекта.
Высокая степень неопределенности для реальных больших и сложных проектов — основная проблема водопада.
Детерминизм бывает только в простых проектах или тиражируемых решениях (типа сайта-визитки).
Ну и отдельный момент — мотивация команды и наработанная методология.
Перекраивать их ради одного проекта? Слишком накладно.
Еще есть тема морального духа и производительности, которая падает драматически в случае потери мотивации.
Просчёты архитектуры не связаны с методологией.
Просчеты не связаны, но некоторые методологии позволяют их выявить быстрее и устранить дешевле.
Проверка нефункциональных требований в водопаде начинается на стадии интеграционных или системных тестов. И если мы им не удовлетворяем — это не технический долг, это переделка (в лучшем случае).
Для меня Agile не является религией, т.к. я понимаю, какая «магия» скрывается за его эмпирическими методами и ритуалами.
Поэтому разоблачительную часть памфлета я не считаю убедительной, уж извините.
С некоторыми утверждениями я вполне согласен.
В традиционной иерархической организации с директивным управлением внедрить Agile невозможно, нужно каким-то образом менять отношения между сотрудниками и руководством.
Как человек, имеющий опыт управления проектами в десятки человеко-лет
Не будем засвечивать тут знаки отличия и медали.
я не буду использовать классический водопад даже в случае выигранного тендера. Да, не будет обратной связи от заказчика, но итеративная разработка появилась раньше agile манифеста.
А я встречал немало людей с опытом, которые делали иначе — потому что так дешевле.
Кроме того, что бы вы не думали за итеративность, без обратной связи, это просто инженерный момент — планирование работ. Тут ничего гибкого, не правда ли?
Для меня Agile не является религией, т.к. я понимаю, какая «магия» скрывается за его эмпирическими методами и ритуалами. Поэтому разоблачительную часть памфлета я не считаю убедительной, уж извините.
Наша длинная переписка говорит о том, что вас всё-таки зацепило. Думаю, что вы ослеплены блеском новых методологий, и не готовы обсуждать критически; думаю что в своих убеждениях вы отталкиваетесь именно от своего опыта, и не смотрите в корень.
Как я писал выше, я не отрицаю SOLID, DDD, Scrum, XP, etc. — я не готов работать без этого, и взгляд в этой статье идёт несколько в разрез с моими пожеланиями. Однако же, считаю очень важным понимать в чём причина появления этих практик, почему иногда они не работают, и понимая причины и следствия, можно приблизиться к истинному положению дел, уходу от невежества.
Автору вообще жирный плюс за взгляд на проблему.
Отрасли давно пора взрослеть и самой себе задавать вопрос за счет чего она живёт. И понимать свою экономику не в мире почти бесплатных денег, когда Uber может потрать на 8.6 миллиарда больше чем вырученные 14.16, а в мире где на твои потери кто-то должен заработать.
Тем более, что отрасль принесла миру социальную инженерию как инструмент управления самого высокого уровня.
Спорным мне кажется следующее:
«Когда работает Agile»
1. Для индивидуальных продуктов гибкость не нужна, нужны традиционный менеджмент и водопад.
Строгая последовательность критически нужна только при создании продуктов с неприемлемыми рисками эксплуатации, для нас это системы управления жизнеобеспечением и опасными техническими объектами и т.п.
В остальных случаях даже скрупулезно зафиксированные требования к продукту не слишком-то и эффективно достигать водопадом, поскольку риск попасть в изменяющуюся среду ненулевой. В том, что многие могут похвастаться постоянной работой на основе таких требований, я тоже не уверен.
Кроме того, даже если ваш продукт делается внутри для себя и вроде бы все можно узнать (но это не точно в 9X% случаев :) ), процессы для которых он предназначен, тоже меняются на ходу. В клинических случаях даже не сами процессы, а качество их модели в головах их исполнителей и владельцев. Есть ощущение, что в нашей отрасли водопад придает уверенности «излишне доверчивым» менеджерам и на этом его плюсы заканчиваются.
2. Экономика продукта выглядит уж очень упрощенно. Из прошлой статьи следует, что результат в виде прибыли получается по модели:
«применяем венчурный капитал -> вовлекаем человека, а не работника -> повышается ценность продукта -> расширяется рынок -> имеем результат».
И в каждой операции сталкиваемся с ограничениями. Более-менее логично можно обсуждать 2 из них:
— «расширяется рынок». Рынок всегда ограничен спросом. И по А.Смиту и по К.Марксу и по многим другим. Спрос всегда конечен, хотя мы и живем в расширяющейся вселенной, получить в обмен больше, чем есть у потребителя, мы не сможем.
— печально, но из этого следует, что и повышение ценности продукта ограничено.
Отсюда следует потребность в балансировании входных ресурсов и результата. И тут венчурный капитал in the wild становится злом, так как его цель перераспределить результат (часть спроса) в сторону своего продукта, то есть отняв его у кого-то еще. Социально-экономическая система расбалансируется, так как чтобы программист получал свое растущее вознаграждение, нужно, чтобы спрос, из которого оно формируется, был изъят у другой отрасли в системе, например у производителей продуктов питания. Что, в общем-то, несправедливо. Либо система должна расширяться за чей-то ещё счет, но опять планетарное ограничение никто не отменил, грабить уже некого.
И тогда логично, вовлеченность массово должна стать не экономической, а ценностной. То есть совершенствование с целью принесение пользы должны стать смыслом деятельности, это последний резерв развития экономики и основанного на ней общества. Слабо?
Незаметно получился «возврат к классикам», даже нового в комментарии не придумывается.
Поэтому идея разделять применимость Agile, базируясь на экономической основе, противоречит экономической логике. Как и виртуальность продуктов можно оставить для экономики эмоций, а не реальности.
«Как именно работает Agile»
3. Ценности. С т.з. результата через расширение не получилось, но экономить ресурсы ценности помогают в любом продукте.
4. Принципы. Увеличение цены продукта ограничено. Вовлеченность тоже, кроме ценностного. Техническая и материальная стороны продукта ограничены пределом спроса.
«Насущные вопросы»
5. Если исходить из желания совершенствоваться, то построить Agile снизу, очевидно можно. Сложно, что также очевидно. Получить команду, которая желает стать лучше сама по себе, чтобы приносить больше пользы, это большая радость. Но есть www.youtube.com/watch?v=-__m1hHb75A и далее www.youtube.com/watch?v=vxkm083j2AE. В корпоративе сложнее, чем в рыночном продукте, так как влияние продукта на результат сильно модерируется остальной деятельностью.
6. Злобный энтерпрайз, канбан. Дружат в обнимку. Корпоратив умеет считать результат по всей цепочке (иначе он не жилец), канбан приносит хотя бы минимально ценный продукт. Что согласуется с результатом всей модели стоимости.
В общем автору спасибо за тему, удачи!
Автору вообще жирный плюс за взгляд на проблему.
Спасибо! Но мои ответы вам не понравятся.
1. Agile серебряная пуля
Строгая последовательность критически нужна только при создании продуктов с неприемлемыми рисками эксплуатации, для нас это системы управления жизнеобеспечением и опасными техническими объектами и т.п.
В остальных случаях даже скрупулезно зафиксированные требования к продукту не слишком-то и эффективно достигать водопадом, поскольку риск попасть в изменяющуюся среду ненулевой. В том, что многие могут похвастаться постоянной работой на основе таких требований, я тоже не уверен.
Кроме того, даже если ваш продукт делается внутри для себя и вроде бы все можно узнать (но это не точно в 9X% случаев :) ), процессы для которых он предназначен, тоже меняются на ходу. В клинических случаях даже не сами процессы, а качество их модели в головах их исполнителей и владельцев. Есть ощущение, что в нашей отрасли водопад придает уверенности «излишне доверчивым» менеджерам и на этом его плюсы заканчиваются.
Для процесса, в большинстве случаев, полезнее подходить именно со стороны адаптивности к изменениям: будь это массовый продукт, enterprise, а иногда и заказная разработка. Как инженер я с вами согласен. И это главное — я, вероятно как и вы, в этой точке зрения заангажирован.
Есть другая сторона сил приложения — менеджмент, чьи ключевые показатели, нередко идут вразрез с любыми agilами. Безусловно, эти показатели могут составляться по-разному. Однако в целом, внутренние и внешние противоречия часто заставляют управленцев, особенно при заказной разработке, работать по принципу сейчас прибыль, а завтра посмотрим. Внутренняя конкуренция менеджеров выносит вверх тех, кто следует именно этому принципу. И вот когда после меня хоть потоп, можно много надумывать, но люди, делегированные для принятия решений, не проявят сознательности, иное — вера в хорошего мужика. Замечательные люди бывают, но уповать на то, что они такими окажутся и есть идеализм. Мой первый пост о том, как управленец в пользу скорейшей прибыли, нарушает принципы предметно-ориентированного проектирования.
Призываю не путать планирование, регулярное подведение итогов, которое должно быть и при производстве товаров (что я возможно несколько неаккуратно уровнял до водопада), и положение дел, когда мы стараемся периодически получать обратную связь от пользователей.
2. Некорректная модель
Экономика продукта выглядит уж очень упрощенно. Из прошлой статьи следует, что результат в виде прибыли получается по модели применяем венчурный капитал -> вовлекаем человека, а не работника -> повышается ценность продукта -> расширяется рынок -> имеем результат.Мне казалось, что в этой статье я не противоречил предыдущей, напротив, она является следствием, статьи о реплицируемом продукте. Если такое противоречие есть, пожалуйста, напишите подробнее, буду очень благодарен!
— «расширяется рынок». Рынок всегда ограничен спросом. И по А.Смиту и по К.Марксу и по многим другим. Спрос всегда конечен, хотя мы и живем в расширяющейся вселенной, получить в обмен больше, чем есть у потребителя, мы не сможем.
Понятия спроса я настойчиво избегал. Во-первых, не предполагаются рыночные отношения (характерные для товаров). В том и дело, что нет необходимости получить всё, что есть у потребителя. Нужно сделать достаточно, чтобы пользователю это было полезно. Например, онлайн-бухгалтерии, open source, да просто игры в онлайн-магазинах. У каждого примера немного своя монетизация, однако вынуть всё из потребителей тут не применимо. Во-вторых, возможно, коронокризис всё изменит, и спекулитивное понятие спроса/предложения будет рассматриваться иначе. И в-третьих, даже в этой системе рыночных координат нужно понимать, что agile часть инструментария по управлению эластичностью спроса, ведь итогом industry 4.0 станет то, что больше нет статики — всё в движении.
Социально-экономическая система расбалансируется, так как чтобы программист получал свое растущее вознаграждение, нужно, чтобы спрос, из которого оно формируется, был изъят у другой отрасли в системе, например у производителей продуктов питания. Что, в общем-то, несправедливо.
Поэтому идея разделять применимость Agile, базируясь на экономической основе, противоречит экономической логике.
Ваша логическая цепочка мне кажется надуманной. Так вы говорите о расширении, но непонятно почему оно должно быть максимальным? Непонятно почему система должна разбалансироваться? Каким образом Agile противоречит экономической логике? Возможно вы рассуждаете с позиций товарно-денежного фетишизма, потому что рассматриваете отношения не с базовой единицы продукции, а с высоты всеобщего рынка и отношений в нём. Возможно я вас не понял, но мне кажется, что также вы могли бы поспорить с рынком нефти — он огромный, перенасыщенный, влияет на другие отрасли, но он есть.
Поэтому идея разделять применимость Agile, базируясь на экономической основе, противоречит экономической логике. Как и виртуальность продуктов можно оставить для экономики эмоций, а не реальности.
Видимо весь пункт посвящён именно этому — отрицанию виртуального товара и его свойств? То что процесс уже начался, доказали другие.
Самым очевидным примером виртуального товара будет патент. И если есть такая форма частной собственности, то есть и её объект — виртуальный товар.
У товара и виртуального товара есть противоположные свойства. Фабрикат(сырьё для производства) после приложения заранее известных рабочих усилий становится товаром и ищет себе спрос на рынке. А виртуальный товар не имеет границы применимости этих усилий — для него свойственно изменяться, формируя себе спрос.
Ценности. С т.з. результата через расширение не получилось, но экономить ресурсы ценности помогают в любом продукте.
Спорно. Получи вы контракт на госзакупку, вообще не факт, что вы возьмётесь за эти ценности, т.к. вы сначала сделаете положеное по контракту, иначе неустойка.
Ценностная вовлечённость
И тогда логично, вовлеченность массово должна стать не экономической, а ценностной. То есть совершенствование с целью принесение пользы должны стать смыслом деятельности, это последний резерв развития экономики и основанного на ней общества. Слабо?
Принципы. Увеличение цены продукта ограничено. Вовлеченность тоже, кроме ценностного. Техническая и материальная стороны продукта ограничены пределом спроса.
До поры до времени, конечно, работает эй дурачок, держи значок, но не в этом случае. Мы живём в рыночных отношениях, и пока это так, денежная мотивация самая эффективная, хоть и не единственная. Ещё у вас образовалась подмена, якобы не возможно материальное поощрение в силу ограниченного спроса. То есть, из-за этой ограниченности прибыль справедливо распределяется в одни руки, а работникам значки? Очень похоже на фокус, где вы маячите перед глазами спросом, а за спиной у вас по карманам распихивают прибыль, и чем больше, тем лучше. И если фокус выделаете осознанно, он не внедрён вам извне, с вашей позицией вы не по адресу.
Я пытался отметить именно материальное мотивирование с целью повышение вовлечённости, а не вульгарно делить прибыли. С другой стороны, возможно, мы (человечество) когда-нибудь научимся кооперироваться правильно не только в области open source, возможно тогда распределение будет по сделанному вкладу. StoryPoint's например :)
Agile снизу
Если исходить из желания совершенствоваться, то построить Agile снизу, очевидно можно. Сложно, что также очевидно. Получить команду, которая желает стать лучше сама по себе, чтобы приносить больше пользы, это большая радость. Но есть www.youtube.com/watch?v=-__m1hHb75A и далее www.youtube.com/watch?v=vxkm083j2AE. В корпоративе сложнее, чем в рыночном продукте, так как влияние продукта на результат сильно модерируется остальной деятельностью.
Если менеджмент не согласится на гибкие практики, то как вы перейдёте? А если это ещё и не выгодно, имеет ли менеджмент право не воспротивиться?
Поводом для этой статьи был доклад на Agile снизу на agileDays2019. К сожалению, видео доклада в сети больше нет, а там было что покритиковать, и вся статья должна была быть вокруг него. Вышло лучше.
Канбан
Злобный энтерпрайз, канбан. Дружат в обнимку. Корпоратив умеет считать результат по всей цепочке (иначе он не жилец), канбан приносит хотя бы минимально ценный продукт. Что согласуется с результатом всей модели стоимости.
Все гибкие практики приносят MVP.
Тьма комментариев выше про канбан. Дружат в обнимку и пусть дружат, но это не мешает ему быть искажённым. Канбан хорошо подходит для реализации продукта основанного на знании иерархии. Плюсы и минусы вокруг этого.
Возможно Канбан вам нравится именно как средство контроля (цепочки и метрики), а не инструмент повышения потребительской стоимости?
Надеюсь вы продолжите дискуссию.
Agile без идеализма. Когда и как именно работает гибкий менеджмент. Политэкономический памфлет