Наша цивилизация уже находится на том уровне развития, когда производство носит глобальный, мировой характер. Его характер сейчас во многом определяют транснациональные корпорации.
На самом деле, современные глобальные компании есть крупные добровольные объединения людей, которые работают на одну конкретную цель (мы сейчас не говорим о вопросах эксплуатации труда, а просто рассматриваем деятельность в рамках компаний как таковую). Например, компания Сбертех делает программы для того, чтобы они могли использоваться в работе Сбербанка, а также для клиентов, которым нужно взаимодействовать со Сбербанком.
Вот и Ильич в своём труде «Государство и революция» замечает:
«Один остроумный немецкий социал-демократ семидесятых годов прошлого века назвал почту образцом социалистического хозяйства. Это очень верно. Теперь почта есть хозяйство, организованное по типу государственно-капиталистической монополии. Империализм постепенно превращает все тресты в организации подобного типа. Над „простыми“ трудящимися, которые завалены работой и голодают, здесь стоит та же буржуазная бюрократия. Но механизм общественного хозяйничанья здесь уже готов. Свергнуть капиталистов, разбить железной рукой вооруженных рабочих сопротивление этих эксплуататоров, сломать бюрократическую машину современного государства — и перед нами освобожденный от „паразита“ высоко технически оборудованный механизм, который вполне могут пустить в ход сами объединенные рабочие, нанимая техников, надсмотрщиков, бухгалтеров, оплачивая работу всех их, как и всех вообще „государственных“ чиновников, заработной платой рабочего...»
Кстати, а почему я упомянул Сбертех? Эта компания известна тем, что нарочито, напоказ старается проповедовать идеологию разработки в стиле Agile. У них даже в фойе офисного здания на Кутузовском, 32 стоит инсталляция «Agile home». Герман Греф, глава всего Сбербанка, постоянно проповедует новые, модные способы управления бизнесом.
Давайте кратко рассмотрим, что такое Agile и почему в будущем он нам не пригодится.
***
Суть подхода Agile можно понять из Манифеста, который был оформлен в 2001 году:
2) Изменение требований приветствуется, даже на поздних стадиях разработки.
3) Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев.
4) На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе.
5) Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им.
6) Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды.
7) Работающий продукт — основной показатель прогресса.
8) Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно.
9) Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта.
10) Простота — искусство минимизации лишней работы — крайне необходима.
11) Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд.
12) Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы
Кроме того, есть т.н. «ценности»:
2) Работающий продукт важнее исчерпывающей документации.
3) Сотрудничество с заказчиком важнее согласования условий контракта.
4) Готовность к изменениям важнее следования первоначальному плану.
Да, красивые слова. Вроде бы всё, чтобы сделать продукт более хорошим, а работу над ним более продуктивной. Но основная уловка современной экономической пропаганды (не только насчёт методов разработки продукта, но и в широком смысле) – это попытка смотреть на всё глазами бизнеса. Когда говорят «повышается эффективность» – говорят о повышении маржинальности, когда говорят «повысится скорость разработки», говорят о том, что бизнес может разрабатывать и продавать свои продукты быстрее, а, следовательно, вытеснять конкурентов. Но нам ничего не говорится о том, нужно ли это вообще людям, человечеству в целом?
Главная фишка подхода Agile, которая и обеспечивает ту самую «гибкость в разработке» – это разбитие процесса на мелкие отрезки времени, называемые спринтами. Обычно это 1 или 2 недели. Спринт должен заканчиваться релизом – выпуском какого-то законченного объёма продукции, который даёт видимый для заказчика результат. Другая особенность Agile – заказчик продукта может по ходу действия менять техзадание, чтобы то, что делает разработчик продукта, в каждый момент времени соответствовало тому, что хочет заказчик в данный момент.
Что это означает для разработчика продукта, то есть пролетария? Давайте теперь попробуем посмотреть на это дело его глазами, а не «глазами Сенкевича», то есть бизнеса.
Работник наёмного труда прежде всего вынужден продавать свою способность к труду, чтобы иметь элементарные средства к существованию. Сейчас, в XXI веке, когда уже повсеместно уходит в небытие такое слой занятых, как крестьяне, когда производство становится всё более централизованным, класс наёмников – пролетариат – постоянно растёт:
«Figure A1 shows that the share of paid employees (or wage employees) has experienced an increase of about 10 percentage points during the last 20 years, rising from 41.8 per cent in 1995 to 51.6 per cent in 2015. In developed countries, where the incidence of own-account workers is relatively low and female participation is higher, the percentage of wage employees relative to the working population has remained high and stable during the observed period. Consequently, the global increase is driven mostly by emerging and developing countries, which have seen a 13 percentage point increase (from 29.9 per cent to 42.9 per cent) in wage employees in the two decades since 1995.»
Это цитата из доклада Международной организации труда при ООН . По найму работает уже более половины от всех работающих в мире.
Как известно, с развитием экономики растёт и степень разделения труда. Труд как осмысленная, творческая деятельность человека всё более отчуждается от него самого. Грубо говоря, если сначала человек делал примус, то потом он начал делать только лишь одну центральную гайку, которая скрепляет этот примус, но делать это максимально эффективно, на оборудовании, которое идеально приспособлено к производству именно этой гайки. Человек таким образом становился придатком к орудию производства. Думаю, далее нет смысла пояснять, этот момент очень подробно разобран у Карла Маркса.
С наступлением века науки, когда знание стало подлинным орудием труда, работа пролетария приобрела некую степень свободы. Действительно, человек, который может на основе своих знаний синтезировать новое, самостоятельно делать выводы, творчески преобразовывать производственные процессы, не так закрепощён в смысле своего отношения к труду. Буржуа по-прежнему изымает прибавочный продукт, однако сам работник чувствует свою вовлечённость в процесс труда. Задействуются его высшие человеческие способности. Говоря другими словами, ему может быть даже интересно.
Agile как бы загоняет нас обратно в эру примитивного обслуживания станка. Да, знания и голова работника по-прежнему нужны работодателю. Однако теперь, когда процесс разбит на максимально короткие отрезки, работник уже не концентрируется на производстве продукта целиком. Его фокус внимания направлен на постоянное изготовление мелких улучшений. Он производит гайки, которые потом каким-то образом сами вырастут в цельный механизм. Либо, что бывает ещё чаще, лишь улучшает то, что уже кем-то построено.
Второй важный процесс, который ускоряется с внедрением Agile, это фактическое разложение трудовых коллективов. Agile преподносится как удобный механизм, который позволяет перебрасывать имеющиеся у капиталиста трудовые ресурсы на разные проекты, при этом сохраняя высокое качество поставляемого продукта. Обратной стороной этого является то, что люди в командах постоянно тасуются. Собственно, многие компании прямо поощряют так называемый «горизонтальный рост»: частые перемещение людей по отделам, департаментам, смену ролей в командах.
Для работодателя это плюс: если рабочий юнит заточен под то, чтобы на каждом участке быстро приходить в рабочее положение и выдавать на гора продукт, то гибкость производства возрастает, а накладные расходы в связи со сменой номенклатуры снижаются. Для работника всё это на деле оборачивается постоянным стрессом. Мы, люди, в ходе эволюции получили некие навыки и особенности социального взаимодействия. Для нас существует примерно понятный набор социальных связей, которые мы можем поддерживать неограниченно долгое время (обычно говорится о 80-120 людях). У нас, как правило, есть более близкий круг общения и более дальний. Нам привычно строить более тесные связи с теми людьми, с кем мы проводим больше времени (а на работе мы как минимум 40-50 часов из 168 в неделе).
«Гибкая» разработка рушит этот комфорт. Если люди всё-равно постоянно меняются, нет смысла строить долговременные отношения. Межчеловеческие контакты деградируют до обычного обмена рабочей информацией. Люди ощущают пресловутое «одиночество в опенспейсе»: когда народу вокруг много, а процессы построены так, что поддерживать удовлетворительную атмосферу внутри своего коллектива весьма трудно.
Кстати, в самом Сбертехе сопротивление agile серьёзное. Мне довелось там поработать три месяца, но я успел понять, что вся организация буквально сопротивляется тому, что деклассирует её до набора слабо связанных друг с другом мелких команд. Наконец, объективные требования к серьёзному банковскому продукту заставляют людей мыслить гораздо большими категориями, чем спринт и утренний стенд-ап. Поэтому поверх собственно agile-практик Сбертех ведёт другой слой «взрослых» управленческих решений, которые де-факто обеспечивают каркас устойчивости всего производства программного продукта.
Ещё несомненный для работодателя плюс: он больше застрахован от организованных действий со стороны своих коллективов. Устроить забастовку или хотя бы решиться на какие-то действия по отстаиванию своих прав можно лишь тогда, когда команда спаяна, её члены имеют общий интерес и одинаковый взгляд на минусы в построении производственного процесса. Естественно, гибкие команды не имеют постоянного костяка, они могут быть в любой момент расформированы, преобразованы. Некому быть второй стороной осмысленного диалога с работодателем.
***
Что нас ждёт в будущем? Конечно, мы понимаем, что наше нынешнее капиталистическое производство суперзатратно. Ещё до эры автоматизации люди вполне обоснованно мечтали, что с вводом электронно-вычислительных устройств работать придётся меньше: основную рутину возьмут на себя машины. Что мы имеем на исходе 2-го десятилетия XXI века? – То, что люди и в самых передовых странах по-прежнему работают много, очень много. В основе этого положения лежит неотъемлемая черта капиталистических отношений: хаотичное рыночное производство и всеобщая конкуренция.
На нынешнем месте работы я делаю некие условные системы взаимодействия с пользователем. Такие же системы уже были сделаны примерно 100500 раз по всему миру. В общем и целом у них один и тот же функционал, они различаются лишь деталями. Что нового я привношу своей работой, если смотреть глазами нашего общего коллективного потребителя, человечества в целом? – Да практически ничего. Мы просто нагреваем воздух, чтобы один производитель на какое-то короткое время вышел вперёд в конкурентной борьбе с другим производителем. Мы можем переиспользовать результаты работы только в рамках одного экономического агента, в данном случае коммерческой компании. Мы не можем как-то повлиять на процесс постановки всё новых и новых требований к продукту: конкурентная борьба предлагает постоянные изменения. И даже когда мы выкладываем свои типовые решение в open-source, это не останавливает рост трудозатрат в IT-отрасли: есть ещё вендоры, создатели новых, ещё чуть более усовершенствованных технологий, языков, фреймворков, которые требуют постоянного переобучения и разработки нового кода, новых прикладных решений.
Таким образом, вся та оптимизация, которую дают новые методы управления, в частности, agile, практически не приносит общего прогресса отрасли и шире экономике. Это инструмент для перетягивания каната, в соревновании, где составы команд к тому же постоянно меняются.
***
Настоящий колоссальный прорыв будет состоять не в интенсификации производственной деятельности, не в упаковывании ещё большей «эффективности» в то время, пока сотрудник находится на рабочем месте. Настоящий прорыв будет состоять в правильной постановке задач, когда производственный процесс будет подчинён лишь одному: удовлетворению потребностей. Наше общество ещё кое-кто по привычке называет потребительским, однако по сути оно общество продаж: именно перманентное требование оборота капитала определяет всю нашу деятельность. Компании внедряют новшества не по мере появления новых фундаментальных открытий и не по мере накопления серьёзного, существенного багажа прикладных разработок. Они внедряют их для поддержания инвестиционного цикла в рамках существующей глобальной модели экономических отношений. Мы все постоянно заняты своей часто бессмысленной работой только потому, что иначе этот велосипед упадёт.
С обобществлением средств производства и прекращением часто бессмысленной конкуренции человечество наконец начнёт по-настоящему использовать весь потенциал, накопленный по мере развития науки и техники. Встанет насущный вопрос о подлинном освобождении человеческого труда, которое будет сопровождаться сокращением рабочего времени. Этот вопрос так же разобран у классиков. Нам лишь только стоит заметить, что взрывной рост эффективности производства в обществе пойдёт по двум путям: кроме обозначенного выше прекращения бессмысленной конкуренции и, как следствие, постоянного воспроизводства одних и тех же решений, также будет массово внедряться настоящая автоматизация, до этого сдерживаемая как высоким порогом внедрения (рискованность инвестиций при капитализме), так и постоянно готовым к использованию привычным рынком труда. Человечество относительно быстро найдёт способ, как из всего зоопарка имеющихся технологий выбрать наиболее удачные, как уже максимально переиспользовать накопленный опыт. Повальная роботизация и автоматизация, сплошное использование лучших наработок, а не только тех, на которые есть деньги, будет только высвобождать человека из под гнёта рутинного производственного процесса, даст ему время на подлинно творческую работу.
Наконец, из-под agile уйдёт самая главная его основа: производству не надо будет больше суетиться. В самом деле: с общественной точки зрения гораздо выгоднее и разумнее произвести один раз хороший продукт, чем производить 20 продуктов, каждый из которых ещё нужно постоянно доводить до ума. Никто не будет запрещать делать бесчисленные модификации одних и тех же решений (например, миллион разных моделей телефонов). Однако изменится само отношение к такому понятию, как время. Поскольку уйдёт пресс тотальной конкуренции с другими экономическими агентами, то появится время и стимулы сделать свою работу, задействуя все свои творческие, духовные силы. По мере роста мощи производства на основе передовой науки, техники и способов организации производства и снижению времени, которое требуется человеку для обеспечения своих необходимых жизненных потребностей, у него будет появляться всё больше времени и возможностей, чтобы быть в ладу с собой: а именно, заниматься тем, что получается лучше всего и, как следствие, приносит максимальную пользу другим людям.
Естественно, при таком подходе к производству человеку не нужно будет постоянно сливаться-разливаться в различные команды и ставить сроки выпуска продукта раз в неделю или две, только чтобы поспеть за постоянно уходящим вперёд рынком. Продукты материального и духовного мира наконец вернут себе ту подлинную основательность, продуманность, глубину замысла, которая так отличает мир классических шедевров от мира одноразовых вещей современного постоянно ускоряющегося рынка.
Конечно, глупо будет отказываться от всех тактических наработок, полученных в прошлую эпоху. Возможно, какие-то элементы agile пригодятся и в будущем. Наверняка, останутся такие ситуации, когда действовать будет нужно быстро и в рамках ограничений по ресурсам. Также человечество, вероятно, больше будет уделять сил междисциплинарному взаимодействию, там, где возможен синергетический эффект от сплава разных знаний. В таких случаях элементы организации гибкого производства пригодятся.
Итеративный подход к разработке также будет иметь место. IT-сообщество само уже находит правильные формы взаимодействия на основе новых отношений. Так, например, в opensource-проектах мы каждый можем предложить свой merge-request. Однако нам не нужно для этого вставать на линейку в 10 утра и рассказывать другим, что мы сделали вчера. Нашим надсмотрщиком является только наше желание сделать мир лучше.
Человек по мере своего освобождения от давления экономических обстоятельств всё больше будет подчинять производство себе, а не подчиняться ему в качестве безмолвного орудия. Вместо постоянного потока хаотичных требований рынка человек сам станет со-заказчиком своей работы. Вне экономического принуждения можно будет формировать команды настоящих единомышленников. Без постоянной угрозы проигрыша на рынке ритм работы станет таким, чтобы человек полностью восстанавливал свои физические и духовные силы. Соковыжималка системы agile уйдёт в прошлое.
Комментарии (80)
zloddey
10.11.2018 13:14+3Грустно это всё. Человек поработал в Сбертехе 3 месяца (=1 испытательный срок), и теперь думает, что детально разбирается, что такое Agile, и как его "исправить".
botyaslonim Автор
10.11.2018 13:42+1Нет, почему. Я работал в разных компаниях. В том числе и в таких, где agile был поставлен весьма грамотно
DrPass
10.11.2018 13:52Есть спорные моменты, но в целом идея автора верна. Agile — это не методики, решающие проблему «сделать как лучше». Это методики, решающие проблему «как заставить заказчика больше платить». Поэтому в конкурентной борьбе, когда таковая появится на рынке разработки ПО, аджайл скорее всего проиграет.
kabal375
10.11.2018 13:58+1Agile как бы загоняет нас обратно в эру примитивного обслуживания станка. Да, знания и голова работника по-прежнему нужны работодателю. Однако теперь, когда процесс разбит на максимально короткие отрезки, работник уже не концентрируется на производстве продукта целиком. Его фокус внимания направлен на постоянное изготовление мелких улучшений. Он производит гайки, которые потом каким-то образом сами вырастут в цельный механизм.
Второй важный процесс, который ускоряется с внедрением Agile, это фактическое разложение трудовых коллективов. Agile преподносится как удобный механизм, который позволяет перебрасывать имеющиеся у капиталиста трудовые ресурсы на разные проекты, при этом сохраняя высокое качество поставляемого продукта.
Какая лютая околесица.
Любой Agile-фреймворк и сама философия стоит на кроссфункциональных автономных командах. То есть не предполагает функционального деления, заточенности отдельных представителей под отдельные гайки, ресурсного мышления (перебрасывания «ресурсов» из проекта в проект). А предполагает вовлечение каждого в создание итоговой ценности в противовес фокуса на узкой специализации и постоянном составе команды (иначе это не команда, а временная группа людей).
Из неверных исходных предпосылок растут мощные но бессмысленные выводы и опровержения.
Сопротивления аджайлу в Сбертехе обоснованно, потому что то, что там практикуется и подаётся там под видом аджайла (по описанию процессов, которые я слышу от приходящих оттуда кандидатов) на самом деле имеет к нему весьма отдалённое отношение.botyaslonim Автор
10.11.2018 16:16Это только в теории. В реальности специалист сталкивается с тем, что ему нужно постоянно дополнять свои знания в своей узкой предметной области, либо он проигрывает в конкуренции и вылетает с работы. Допустим, у специалиста по Java, который в рамках кроссфункциональности перетёк на фронтенд-задачи, показатели резко упали, задачи выпали из графика.
В том же Сбертехе предполагалось слить все специализации в одну — аналитик-тыжпрограммист. Код предполагалось писать в системе написания автокода, кастомный делать вставками только в определённых местах. Вот что такое кроссфункциональность, когда предполагается, что все могут делать всё. Нн знаю, довели они эту инициативу до конца или нет. Надеюсь, что нет.staticlab
10.11.2018 21:30+1Вот что такое кроссфункциональность, когда предполагается, что все могут делать всё.
Кроссфункциональность команды на самом деле означает, что команда может делать всё. Разумное требование, потому что устраняются излишние внешние взаимодействия команды, которые тормозят процесс разработки. Например, если команда сама может подготовить дизайн продукта, ей не нужно ждать его откуда-то извне. Но это не означает, что кроссфункциональным должен быть каждый из членов команды, когда бэкендщика принудительно сажают за фронтенд, а фронтендщика — настраивать деплой.
JustDont
10.11.2018 21:52В теории да. На практике? Если в каком-то месте случается bottleneck, то поскольку спринты короткие и надо типа что-то выкатывать к концу каждого — то на узкое место кидают всех, кто не может отбиться от этой сомнительной чести.
А уж если сразу очевидно, что какой-то узкий спец не вполне будет загружен в одной команде (например, дизайнер, у которого по завершению основного этапа проектирования всё равно постоянно есть работа по доработкам и правкам, но этой работы маловато) — то им начинают играть в пинг-понг между командами, про что автор статьи тоже упоминал.
ЗЫ: У нас в конторе хоть аджайл и всё еще в стадии «выкатывания», и многое криво, но тем не менее вот эта вот тенденция на перемешивание уже стоит в полный рост и никуда деваться не собирается. Я уже даже ментально привык, что меня (фронтэндщика) могут либо сдёрнуть на пару недель в другую команду, потому что у них всё плохо, а ты крутой и разберешься, ну и что, что там технологический стек совсем другой; либо же предложать понастраивать деплой, потому что надо вотпрямщас, а имеющиеся спецы в данный момент загружены по макушку.qw1
11.11.2018 09:21+1Как же принцип, что команда сама даёт оценки трудозатрат?
Если случается bottleneck, при планировании спринта непрофильные специалисты поставят задаче «5 дней на разобраться» и профильный поставит «2 часа быстро сделать». В среднем получится адекватно.
kabal375
11.11.2018 11:29+2В теории да. На практике?
А на практике зависит от реализации и понимания реализаторами теории.
В основе аджайл и скрама в частности стоит самоорганизация, то есть никто не вправе указывать команде, как выполнять работу и тем более перекидывать участников между командами по своему разумению. Если же это наблюдается, то не стоит называть это аджайлом, пусть и в стадии «выкатывания». Иначе, получается, виноват аджайл, а вовсе не то, что его кто-то толкует извращённо.
В моей текущей команде, разработчики С++ не гнушаются помогать с разбором и написанием тестов на Java, потому что в данный момент это важнее для достижения конечной цели. Да, это не доставляет им особого удовольствия, писать новый функционал интереснее, но это был их осознанный выбор, а не указание свыше.
В процессе такой взаимопомощи они обретают новые взгляды на продукт — с точки зрения тестирования — что приводит к идеям по дальнейшему изменению и развитию архитектуры. В этом суть командной кросс-функциональности и гибкости, а не во взаимозаменяемости и перебрасывании людей.
Но важен менталитет. И далеко не только менеджеров. Если человеку хочется писать только на плюсах и только бэкенд, то аджайл конечно ему зачем? Классический функциональный колодец будет предпочтительнее.
JustDont
11.11.2018 13:21В основе аджайл и скрама в частности стоит самоорганизация, то есть никто не вправе указывать команде, как выполнять работу и тем более перекидывать участников между командами по своему разумению.
И это как раз одно из довольно многочисленных мест, где теория скрама в сравнении с реальностью напоминает розовых пони.
Если принимать команду за цельный юнит без отсутствия вмешательства, то совершенно очевидно, что у команды должны быть все функции найма/увольнения для регулирования собственного размера и состава. На практике — если только контора по большей части не представляет из себя одну команду — никто так просто команде эти функции не отдаст. Разумеется, существенная часть фактического найма и увольнения скорее всего будет происходить именно в команде, но каждый раз это будет требовать дополнительной работы вне команды и согласований (в части финансов, HR, секьюрити, и тэ дэ).
Плюс, у команды должны быть функции слияния/деления, опять же чисто исходя из скрамовских «команде следует быть от 3 до 9 человек» (а продукты бывают каких угодно размеров). На практике же это легчайше выливается в сопротивление внешних сил плюс всё те же вопросы с наймом, так как разная разбивка на команды может требовать меньше или больше организационных усилий (и соотсветственно, разного количества людей под это).
Но важен менталитет. И далеко не только менеджеров. Если человеку хочется писать только на плюсах и только бэкенд, то аджайл конечно ему зачем? Классический функциональный колодец будет предпочтительнее.
Ну в общем-то вы сами всё и подтвердили. «Мы кроссфункциональная команда и каждый из нас специалист своего дела, но если вдруг случайно вам не нравится то, что вы можете оказаться на любом участке продукта в любой из используемых нами технологий — то, пожалуйста, проходите мимо» ^_^
botyaslonim Автор
12.11.2018 15:03… то есть никто не вправе указывать команде, как выполнять работу и тем более перекидывать участников между командами по своему разумению
Ну вообще управление ресурсами как-раз и есть основная задача предприятия. Или мы тогда понимаем компанию как де-факто конгломерат мелких фирм, которые берут один крупный подряд и уже сами внутри себя решают все вопросы от и до. Но я такого не видел в живых компаниях. Может, где-то и есть.kabal375
12.11.2018 15:08Ну вообще управление ресурсами как-раз и есть основная задача предприятия.
Да, но люди это не ресурсы. И как только эта концепция осознаётся, всё встаёт на свои места.
www.stickyminds.com/article/management-myth-32-i-can-treat-people-interchangeable-resourcesbotyaslonim Автор
12.11.2018 15:22Ну как… Везде только и говорят о «человеческом капитале». Капитал, как мы помним, это самовозрастающая стоимость. Это то, что инвестируется с целью получить деньги-штрих. Это самый основной ресурс и есть.
Весь HR — это про то, как привлечь и удержать необходимых людей, то есть обеспечить компанию лучшим человеческим ресурсом. Компании вкладываются в обучение, чтобы развить свой ресурс. Да, он чуть более сложен в управлении, чем парк станков, но тем не менее.
Foxcool
11.11.2018 12:47Ага. Это по идее наоборот защищает команду и ее членов. Команда, которая может выполнять полный цикл разработки, при проблемах с обуревшим маняманагером 9000 звена может свалить всей толпой куда-то. Хоть в другую фирму, хоть на фриланс, параллельно развивая командный бренд и пет-проекты. Просто решается проблма того, что в одно лицо крайне тяжело уметь все: уграничения мясной тушки, системная консолидация, вот это все.
KevlarBeaver
10.11.2018 14:31-1Сбертех, Сбертех, Сбертех. Это рекламная статья? Так бы сразу и написали, чтобы люди время не тратили.
botyaslonim Автор
10.11.2018 16:17Он просто очень пиарит свою agile-предрасположенность. Текст не про него
AndriyVolosh
10.11.2018 16:09Каким образом настанет это «счастливое будущее»? Корпорации крепко вцепились во власть и так просто её не отдадут.
botyaslonim Автор
10.11.2018 16:10Это второй вопрос, он не по теме этого ресурса. Но интересно предположить, как будет организовано производство после капитализма
rg_software
11.11.2018 03:21+1А мне кажется, что вопрос поставлен верно: каким же это образом будущее настанет. Сейчас это выглядит как рассуждение о том, чего мы будем делать, если завтра прилетят инопланетяне, которым срочно потребуются наши запасы марганцовки.
Пока что едва ли не все механизмы отказа от капитализма подразумевали насильственную смену парадигмы и по сути запрет капиталистической деятельности. Этот путь вряд ли кому-то захочется ещё раз пробовать, а альтернативы непонятны.
Daddy_Cool
10.11.2018 19:06«с общественной точки зрения гораздо выгоднее и разумнее произвести один раз хороший продукт,»
Общество не соглашается. Общество хочет иметь возможность выбора. Для этого продуктов должно быть много. На разных этапах нужны разные продукты. Если после внезапного показа во всех кинотеатрах страны «Бриллиантовой руки» возникнет ажиотажный спрос на мобильники с перламутровыми пуговицами — что будем делать? Срочно выпускать такие телефоны или объяснять пользователю, что это блажь и ему не следует этого хотеть?
botyaslonim Влиять возможно можно — например петиции/требования о ремонтопригодности техники. Но не обходится без нюансов. Скажем взять ту же заправку картридже принтеров. Хитрые пользователи заправляющие картриджи по пять раз по сути запускают руку в карман пользователям которые меняют картриджи целиком. И это всё инертно.
И даже когда мы выкладываем свои типовые решение в open-source, это не останавливает рост трудозатрат в IT-отрасли: есть ещё вендоры, создатели новых, ещё чуть более усовершенствованных технологий, языков, фреймворков, которые требуют постоянного переобучения и разработки нового кода, новых прикладных решений.
То что действительно не нужно — не находит применения и последователей. А если люди всем этим занимаются — то… профит видимо есть.
P.S.
Чем виноват Agile я так и не понял.qw1
10.11.2018 20:36Хитрые пользователи заправляющие картриджи по пять раз по сути запускают руку в карман пользователям которые меняют картриджи целиком
А хитрые пользователи, которые варят борщи дома, по сути запускают руку в карман пользователям, питающимся в ресторанах (те же недополучают прибыль, а значит, увеличивают цены).Daddy_Cool
10.11.2018 22:21Ну не совсем. Если бы в магазинах продавали продукты дешевле себестоимости ресторанам, чтобы те потом делились прибылью с магазинами, а тут ррраз — хитрые готовильщики дома подсуетились — и тоже покупают задешево чтобы варить борщи — тогда да, а сейчас — для оптовиков одна цена, в розницу — другая. В плане картриджей — видимо должны быть модели которые заправляются без проблем — но эти принтеры тогда дороже стоят. А если дешево будет всё — то производитель принтеров/картриджей перестанет их производить. Впрочем это всё очевидный маркетинг.
P.S. Возможно открытие магазина (скажем со вкусными полуфабрикатами) рядом с рестораном утянет часть клиентуры, ресторану придется повышать цены… и тогда да — всё как вы сказали. Посетители магазинов по сути залезают в карман посетителям ресторанов. )))
visirok
10.11.2018 20:18+1Соковыжималка системы agile уйдёт в прошлое.
Я тоже думаю, что agile отомрёт. Хотя и обогатит собой почву. Но вот Ваше утверждение про «соковыжималку» не поддерживаю. По моим наблюдениям, agile в силу его неэфыективности декларируют в комфортабельных проектах, со стабильным долговременным бюджетом и необходимостью подпралять и улучшать существующее или делать примерно одно и тоже.
В сложных, больших и срочных проектах agile не работает. Одна из основных причин — чтобы сделать что-то сложное и/или новое, надо хорошо подумать. Думать про тестирование лучше до начала реализации, но интеграционные тесты можно делать когда всё сделано. Поэтому задание спринта расщепляется как минимум на три фазы — продумывание (архитектура/дизайн), реализация, тестирование. Либо вся команда участвует во всех трёх фазах — что неэфыективно, либо во время разных фаз (спринтов) члены команды занимаются разными фичами (одни тестируют фичу N, другие программируют фичу N +1, третьи продумывают фичу N +2) но это тогда не agile.botyaslonim Автор
10.11.2018 21:08Agile предполагает в том числе и разветвлённую метрику активности работников. В идеале, каждый рабочий час работника должен быть посвящён решению совершенно конкретной задачи. В спринт никто не ставит 10 часов на «подумать» и «пообщаться с коллегами». Я это имел ввиду
senpay
10.11.2018 21:47Отнюдь. Мой "эджайл" другой (и больше я люблю перевод "адаптивный подход")
Точнее из моего опыта:
Кроссфункиональность команды!=кроссфункиональность каждого ее члена;
Стабильный состав команды -> важное условие достижения эффективности;
Вовлечение члена команды во все стадии разработки продукта (от идеи до продакшна) -> помогает человеку не быть винтиком и чувствовать свой вклад лучше, чем в традиционных подходах (ака водопад).
Статья во многом интересная, много пищи для размышлений, но некоторые предпосылки мне кажутся ошибочными.
Эджайл про умение адаптироваться, и индиферентен к тому, адаптироваться под повышение маржинальности или под удовлетворении потребности пользователя. Тут выбор за нами.
visirok
10.11.2018 23:03помогает человеку не быть винтиком и чувствовать свой вклад лучше, чем в традиционных подходах (ака водопад).
Вы поработали в большом количестве агильных и неагильных проектов и это ваш эмпирический опыт или у вас есть достоверная статистика на этот счёт?vryashentsev
11.11.2018 16:09Это эмпирический опыт многих людей. Работая в отделе фронтенд, ты даже не знаешь зачем пилится продукт. Поэтому будьте уверены — вовлеченность значительно больше. Целеполагание, прозрачность, инспекция бэклога участниками команды — это все составляющие части одного из Agile фреймворков. Они не то чтобы дают вовлеченность, это просто одна из основных ЦЕЛЕЙ.
visirok
11.11.2018 19:23-1А я думаю, инспектируя бэклог никогда не узнаешь, зачем (выражаясь Вашими словами) пилится продукт. И вообще, пилится ли он. Целепологание тоже отсутствует. Никогда не ясно, мы закончим через 3 месяца или через три года. Всё зависит от того, что в бэклог ещё добавят.
Область, где Agile работет, черезвычайно узка. Об этом писали многие, например feodorbene в комментарии и я здесь.vryashentsev
12.11.2018 03:31Зачем пилится продукт очень даже хорошо узнается, если об это хотя бы просто поговорить, но тот же Lean заставляет работать над портретами своих клиентов, понимать их потребности, обозначать гипотезы и проверять их. Тот же скрам заставляет имперически проверять что работает для клиентов, а что нет. В итоге приходит поинимание, что проект пилится для таких-то людей, которые ночью любят покушать, а днем поездить на велосипеде, грубо говоря. Это как минимум — становится понятно зачем этот продукт клиенту. При этом, конечно никто не заставляет формулировать цель продукта для производителя, это уже не из области agile, это из области управления портфелем.
Целеполагание лежит в основе, как я уже сказал, одного из фреймворков. Оно есть по определению. Его нет, если разработка по сути «хаотическая».
Про когда закончим, откровенно говоря, вообще вопрос дискуссионный. Хотя бы потому что другие инструменты тоже не отвечают на этот вопрос сколько нибудь точно. Любые планы оказываются ложью, хоть строительство космического корабля, хоть моста, хоть разработка ПО для магазина одежды для кошек. Но, по-крайней мере в скраме, планы строятся на основе факта о производительности команды.botyaslonim Автор
12.11.2018 11:13Так дело в том, что в современной экономике клиент сам часто не знает, что для него пилить. Требования рынка постоянно меняются. Рассматривая предметную область, исследуя клиента, мы часто работаем впустую, т.к. оно потом всё-равно сильно поменяется. Экономика в целом работает не на максимальное удовлетворение конкретных потребностей, а на удовлетворение хаотичных движений рынка, и от этого проблемы.
Я попытался с этого боку посмотреть на организацию производства сейчас.ApeCoder
12.11.2018 14:43Экономика в целом работает не на максимальное удовлетворение конкретных потребностей, а на удовлетворение хаотичных движений рынка, и от этого проблемы.
А я вот слышал, что сейчас есть всякое стратегическое видение и создание потребностей. Что именно вы читали об экономике где так написано?
botyaslonim Автор
12.11.2018 14:59Стратегическое видение — просто слово из презентаций. Конечно, есть планирование, но есть, допустим, неожиданные обвалы рынка. Есть, наконец, совершенно закономерные циклические кризисы капиталистической экономики. Я не видел, чтобы компании публично в своих планах учитывали: «С 20… по 20… циклический кризис, падение продаж 20%». За таким релизом мгновенно последует обвал акций такой компании
ApeCoder
12.11.2018 15:16не видел, чтобы компании публично в своих планах учитывали: «С 20… по 20… циклический кризис, падение продаж 20%».
Откуда тут взялось слово публично. Как отсутствие чего-то публичного доказывает тезис "Экономика в целом работает не на максимальное удовлетворение конкретных потребностей, а на удовлетворение хаотичных движений рынка, и от этого проблемы."
Нет ли у движений рынков своих закономерностей? У вас в институте макроэкономика была как предмет?
botyaslonim Автор
12.11.2018 15:20У меня в техническом вузе была экономика, да. Ещё я читал Маркса, Энгельса, Ленина, немного Мизеса, Хайека и Смита, а также статьи современных авторов, которые объясняют что-то лишь в своём поле допущений.
Между удовлетворением рынка и потребностей есть очевидная разница, как можно этого не видеть?ApeCoder
12.11.2018 17:05Между удовлетворением рынка и потребностей есть очевидная разница, как можно этого не видеть?
Разумеется есть. А с кем вы спорите? Если вы вменили мне это мнение то по какой причине? Я лишь оспаривал хаотичность движения рынка.
Во-вторых, нельзя сказать, что движения рынка никак не связаны с потребностями покупателей. Или вы это утверждаете?
senpay
11.11.2018 21:18Это мой эмпирический опыт. Но, думаю, just for fun, было бы классно посчитать статистику.
Может быть, поделитесь Вашим опытом, где эджайл не работал, и почему так (с Вашей точки зрения) вышло?
visirok
11.11.2018 23:05Про личный опыт я говорить не вправе, поэтому обобщённый опыт. Agile точно не работает если:
1. Необходимо иметь фазу архитектуры и фазу интеграционного текстов (более детально здесь
2. Команда больше 9 человек
3. График релизов предопределён и не совпадает со спринтами.
4. Бюджет и сроки жестко заданы заказчиком.vryashentsev
12.11.2018 03:411. Я пока в своей жизнь, в разработке ПО, не встречал случая, где разработку архитектуры стоит выносить в отдельную фазу. Может у меня мало опыта, а может «отдельная фаза» просто привычное дело, которое пихают во все щели просто потому что это привычно? Впрочем допускаю, что где-то это может пригодиться, но пока еще такого не встретил.
Интеграционные тесты вполне уместны в Agile. Тот же Дядюшка Боб или Гойко Аджич хорошо описали как их надо делать. Все что автоматизируется — хорошо ложится в рамки Agile. То что не автоматизируется — может не лечь красиво.
2. Нет проблем, есть фреймворки для масштабирования.
3. Релизы не должны совпадать со спринтами. Спринты вообще не являются неотъемлемой частью Agile.
4. Здесь сложнее.
Но вообще-то вы затронули темы совершенно новые, не относящиеся к теме статьи никак. Основной посыл статьи — компании хорошо, а человеку — плохо. Это не так. Agile учит сотрудничеству и создавать ценный продукт вместо прикрывания своего зада и игры в футбол. Agile это этап развития, который учит людей работать совместно. Agile учит командной работе. Agile даёт удовольствие от работы, если конечно участник команде не хочет только крутить бесполезные гайки. Такой человек, да, будут выгнан самой командой, т.к. он просто не работает на общую цель.visirok
12.11.2018 11:08Я затронул темы, ответив на Ваш вопрос.
И с моей стороны вопрос-предположение: я правильно предпологаю, что Вы работаете Scrum- мастером или руководителем agile проекта?
eugenvz
11.11.2018 10:52На «подумать, проанализировать» и т.д. в Agile есть понятие «spikes», если что.
Dimash2
11.11.2018 06:19Что мешает все это за-agile-ить в вашем стиле? Все что вы озвучили можно оформить в Agile. Я даже сам себя так организовываю, а не команду. Просто не нужно воспринимать все в штыки и офорьмте очередность. Думайте и дизайнируйте сколько понадобится и двигайте дедлайн при неудачах, но очередность и карта действий быть должна, просто это удобно называть все Agile и Scrum, иначе не ясно как все это называть )
visirok
11.11.2018 12:44Если Вы увидите незнакомый фрукт, вряд ли стоит называть его знакомым названием помидор. Так же и с Agile и Skrum. Не стоит применять эти названия, если это не они (в соответствии с общепринятыми определениями).
Мой тезис — если вам в проекте необходимы фазы архитектура/дезайн, реализация, интеграционный тест (возможно другие) — то лучше не обманывать себя, что вам подходит агильный подход.
Это не будет фатальной ошибкой, но будет неэффективно, ИМХО.
Asen
10.11.2018 22:02+1Сколько существует agile-команд, столько существует и вариаций agile. Понимаете в чем дело, вне зависимости от того, какую именно гибкую методологию выбирают, она будет искажена потребностями тех, кто ее внедрял. Видимо, вам особенно не повезло
vladimir123456
10.11.2018 23:54А в гуглах-фейсбуках тоже используют agile/scrum?
Что-то у меня большое сомнение на этот счёт…mat300
11.11.2018 09:57Не гугл, но используем. Несколько месяцев как… Но лучше бы… Это просто тушите свет…
ukrbublik
11.11.2018 00:22Прекращение конкуренции, снижение рабочего времени, выбор единых технологий и фреймворков. Звучит как утопия.
Dimash2
11.11.2018 05:47Хорошо, что вы уверены в будущем ) Управлять задачами нужно будет и не важно как вы это назовете. Каждый кто добавляет код в OpenSource всеравно сам себя организует при помощи Agile, может не по манифесту, а так как ему хочется, иначе — никак. Просто самообман и задрочество к терминам до добра не доведут. Нет единой системы на все случае — это невозможно исходя из психологии и просто объективной реальности относительности.
eugenvz
11.11.2018 10:47Я снова получу сейчас минусы, на которые, мне, в общем-то всё равно, но снова и снова вижу посты «знатоков» Agile и Scrum.
Ваша фраза «Спринт должен заканчиваться релизом...» уже говорит о том, что точно не на вашем текущем уровне понимания методологии рассуждать о её будущем. Ознакомьтесь сначала с матчастью, а, то, как опять же таки, если вернуться к вашей статье, ваши рассуждения выглядят не больше, чем рассуждения пролетариата о руководстве страной.hippoage
11.11.2018 15:38Тоже хотел написать аналогичный комментарий, что в статье бред и в лучшем случае обсуждается Scrum (и то какой-ко недовнедренный), а не Agile. Да и в большинстве комментариев тоже.
Однако стоит признать, что Scrum и Agile сейчас имеют негативную окраску. И не потому, что они в принципе плохи, а потому что они очень сложны во внедрении (хотя первый порядка 16стр, а второй 2стр). Поэтому они наверняка формально уйдут и будут заменены более простой системой.
Еще, думаю, важный момент в психологической совместимости культуры Scrum и программистов на нашей территории. Может быть, нужно что-то менее самоуправляемое только из-за этого.
PS. В этой связи мне нравятся книги компании Basecamp про организацию удаленной работы — они в какой-то мере могут заменить слова Agile/Scrum. Плюс, ориентир на надомную работу.
hhba
12.11.2018 09:02Особенность любых обсуждений этой темы в том, что сторонники подхода в ответ на любые замечания говорят "вы все не так поняли и неправильно делаете". А как надо-то? ЧСХ если привлечь консультанта, то можно оказаться в ситуации "у вас был плохой консультант". И, да, поскольку манифест писал лично Капитан Очевидность, то непосредственно из него мало что следует, отсюда масса толкователей, есть свои еретики и свои салафиты, и в целом не очень понятно, кто же прав, что считается харам и можно ли сторонникам Agile вступать в однополые браки (шутка, не принимайте на личный счёт). Ну а конкретные методологии чуть более конкретны, и потому имеют весьма ограниченное применение даже в разработке софта, а тем более в промышленности в целом.
Ещё всегда интересно слышать, что гибкий подход (к чему-либо) может быть как-то неправильно гибким. Не поняли вы аджайл, там про гибкость, но по-другому, не как у вас! Из серии "у вас неправильная демократия, потому что вы выбрали не того кандидата".
P.S.: Я в целом "за", а мой скепсис вызван тем, что я наверное просто испорчен разработкой "железных" продуктов, где объективно не все это применимо, хотя касаясь конкретно нас — у нас ооочень гибкий подход к разработке, много гибче, чем у других.
ApeCoder
12.11.2018 11:05+1Особенность любых обсуждений этой темы в том, что сторонники подхода в ответ на любые замечания говорят "вы все не так поняли и неправильно делаете".
Тут вопрос общей культуры. Мне достаточно мало встречалось критиков, которые хоть немножко пытались разобраться в предмете. Например, очень редко встретишь такого, который бы ссылался на источник сведений о конкретной методике.
Для меня идеально было бы что-то вроде "У меня тут внедряют SAFe и тут возникли сложности вот с тем-то (ссылка на сайт с цитатой про какую-то практику) консультант говорит, что надо делать так-то, в сети еще встречаются такие-то советы (ссылка1, ссылка2, ссылка3) но все равно не работает из-за того-то и того-то"
Обычно я вижу вопли типа "Аджайл это соковыжималка потому, что у нас Скрам и штрафуют за то, что мы не успеваем к срокам, которые назначает начальник".
А так, да, аджайл понятие нечеткое и, одновременно, модное. Поэтому много желающих назвать аджайлом все, что угодно.
botyaslonim Автор
12.11.2018 11:10Перед написанием этой статьи я прочёл других штук 10, в т.ч. и на Хабре, чтобы ещё раз понять, что другие понимают под agile.
Базовое описание подхода (moneyfest) действительно очень размытое и общее. Интереснее рассмотреть, как он уже реализуется на практике и почему так.
hhba
12.11.2018 13:06Например, очень редко встретишь такого, который бы ссылался на источник сведений о конкретной методике
Причина очевидна — с критикой обычно выступают непосредственные жертвы, а не организаторы процесса. Очевидно жертвам не столь хорошо знакомы источники сведений.
Аджайл это соковыжималка потому, что у нас Скрам и штрафуют за то, что мы не успеваем к срокам, которые назначает начальник
Очевидно они вопят неспроста? И вопрос «а почему у вас начальник сроки назначает?» вряд ли облегчит их боль.
Любая идея хороша тогда, когда исполнима с учетом факторов. Иначе, извините уж, не факторы виноваты, а либо идея, либо сонм ее поклонников, повсюду ее сующих. Вспоминается утверждение о том, что коммунизм надо было строить не в России, страна, мол, неподходящая была, потому эксперимент кончился крахом. Сдается мне, что либо сама идея, либо ее исполнители — не очень, а страна тут ни при чем.
А так, да, аджайл понятие нечеткое и, одновременно, модное. Поэтому много желающих назвать аджайлом все, что угодно.
Я повторюсь — сам по себе аджайл настолько общ, что под это определение на самом деле много чего подпадает (разве что пункт про частые релизы в некоторых видах разработок попросту неприменим). Это как Конституция России — хорошая, добрая и честная. Между тем конкретные методологии уже начинают слегка отдавать маразмом и неисполнимостью — примерно как некоторые российские законы, а то и целые своды их.
Избыток политоты политоты прошу считать сугубо сборником примеров.ApeCoder
12.11.2018 15:09Причина очевидна — с критикой обычно выступают непосредственные жертвы, а не организаторы процесса. Очевидно жертвам не столь хорошо знакомы источники сведений.
А жертвы слишком тупы и безинициативны чтобы сами сделать анализ ситуации и подумать что можно изменить. Они могут только орать "Ыыы больно".
И вопрос «а почему у вас начальник сроки назначает?» вряд ли облегчит их боль
Если они себе зададут этот вопрос себе, дополнив вопросом, "почему в скраме это не так" посмотрев на аргументацию, то они смогут попробовать переубедить начальника либо при поиске работы задать правильный вопрос.
Любая идея хороша тогда, когда исполнима с учетом факторов. Иначе, извините уж, не факторы виноваты, а либо идея, либо сонм ее поклонников, повсюду ее сующих.
Почему вы из трех причин выбираете одну чтобы сделать ее виноватой. С какой целью? При чем здесь вообще вина? По мне, так надо понять, какую из причин можно изменить.
Если можно изменить факторы, то надо менять факторы, если идею или поклонников, то надо их. Но чтобы разобраться, надо сначала их изучить.
Это как Конституция России — хорошая, добрая и честная. Между тем конкретные методологии уже начинают слегка отдавать маразмом и неисполнимостью — примерно как некоторые российские законы, а то и целые своды их.
В этой ситуации можно поступать по разному. В последнем подкасте медузы Олег Навальный рассказывал, что он очень изучил правила внутреннего распорядка когда сидел и добился их соблюдения от ФСИН там где ему было нужно.
Тогда он бросает всю пачку на пол — причем расписок там на долларов сорок-пятьдесят от каждого игрока — и поворачивается к выходу из ванной. В дверях останавливается и оглядывается.
— Но я хотя бы попытался, — говорит он. — Черт побери, я сделал все, что мог, в отличие от вас, разве не так?
И выходит, оставляя выпачканные бумажки на полу для тех, кто захочет в них разбираться.
hhba
12.11.2018 23:13А жертвы слишком тупы и безинициативны чтобы сами сделать анализ ситуации и подумать что можно изменить
А если просто не хотят? Вас вот все идиотские процессы на вашем предприятии интересуют, или только некоторые?
Если они себе зададут этот вопрос себе, дополнив вопросом, «почему в скраме это не так» посмотрев на аргументацию, то они смогут попробовать переубедить начальника либо при поиске работы задать правильный вопрос.
Да, сделать ноги сразу и далеко — очевидный выход. Но не всем подходит, да и вообще деструктивен.
Почему вы из трех причин выбираете одну чтобы сделать ее виноватой
Потому что это проверенное жизнью правило.
В последнем подкасте медузы Олег Навальный рассказывал, что он очень изучил правила внутреннего распорядка когда сидел и добился их соблюдения от ФСИН там где ему было нужно
Олег, при всем моем к нему уважении, может рассказывать что угодно — он фигура политическая, со всеми присущими ей минусами и плюсами. Я говорю о ситуации в целом, о том, как закон обходится с менее известными фигурами. Но это политота, давайте прекратим.
Но я хотя бы попытался
Ясно, традиционная волынка. Не менее традиционная впрочем, чем другая.
maslyaev
12.11.2018 19:21Во всём этом прекрасном agile вижу следующие неприятные моменты (что, впрочем, никак не мешает самому работать в этом стиле):
1. Разгоняет безумный улучшайзинг ради улучшайзинга. Не, ну в самом деле, господа, нам реально нужны эти безумные апдейты всего на свете раз в неделю? Если хотя бы раз в месяц порядок кнопочек на панельке не поменяется, у нас что, ломка начинается? Мне как потребителю (даже когда мы сами производители, мы всё равно в отношении остальных 99.999% IT мы потребители) весь этот долбаный улучшайзинг больше мешает, чем помогает. Зачем всё это? Не понимаю. Иррациональные объяснения есть (прогресс, развитие, бла-бла-бла), а рациональных на ломаный грош.
2. Качество. Agile прекрасен в сфере услуг, но для производства массового продукта он не годится совсем. Проиллюстрирую аналогией. Если, допустим, автопроизводитель решает изменить, например, конструкцию крепления глушителя, то подойдёт к этому вопросу капец как серьёзно. Сопромат и материаловедение по полной программе. Испытание опытных образцов в разных режимах — на экстремально низких и высоких температурах, вибрация, загрязнения, агрессивные среды и т.д. и т.п. Никакого «в релиз через неделю» там нет и быть не может. Иначе отзыв ста тысяч изделий, мало не покажется никому. В сфере услуг подход принципиально другой: «Петрович, возьми там из ящика какой-нибудь хомутик и привари чтобы не болталось». Вот он agile в его естественной среде обитания. А чё? Дёшево и сердито, и клиент получил ту фичу, которую хотел.
С массовым внедрением agile в продуктовое производство мы неизбежно приходим к тому, что у нас всё становится похожим на самоделку из гаража Петровича. Всё безобразие, конечно, убрано за пластиковую панельку, но менее безобразным оно от этого не становится.
Давайте договоримся так. Если наша деятельность — удовлетворение конкретного заказчика, то врубаем agile на полную катушку и радуем клиента быстрым удовлетворением любого каприза. И релизы хоть два раза в день, почему бы и нет. Но если создаём продукт, то любое поползновение в сторону agile приравниваем к саботажу и караем по законам военного времени.hhba
12.11.2018 23:16Разгоняет безумный улучшайзинг ради улучшайзинга
Так это нынче основной драйвер индустрий, и не первое десятилетие уже.
С массовым внедрением agile в продуктовое производство мы неизбежно приходим к тому, что у нас всё становится похожим на самоделку из гаража Петровича
Воооот, а об этом пишут непозволительно мало. Рискну сказать, что на Хабре впервые вижу эту мысль в такой прямой форме.
А теперь внимание — это уже так и есть.JustDont
12.11.2018 23:32Воооот, а об этом пишут непозволительно мало. Рискну сказать, что на Хабре впервые вижу эту мысль в такой прямой форме.
Да вообще-то я эту мысль вижу в каждой первой статье с критикой аджайла (коих на Хабре уже порядочно). Вот натурально, в каждой.
botyaslonim Автор
13.11.2018 11:27В недавней статье про Гугл говорилось, что улучшайзеры продвигаются по службе, а радетели за хороший код в аутсайдерах, потому что «ничего полезного не делают».
С вашим комментарием полностью солидарен
maksim_ms
13.11.2018 11:47Естественно, гибкие команды не имеют постоянного костяка, они могут быть в любой момент расформированы, преобразованы. Некому быть второй стороной осмысленного диалога с работодателем.
Как правило Agile команда цельная и не только она решает кого нужно добавить кого убрать.
Что нового я привношу своей работой, если смотреть глазами нашего общего коллективного потребителя, человечества в целом? – Да практически ничего.
Вы сами ниже пишите про open-source, то что компании не делятся своим кодом, это не проблема Agile.
Мы просто нагреваем воздух, чтобы один производитель на какое-то короткое время вышел вперёд в конкурентной борьбе с другим производителем.
Мы можем переиспользовать результаты работы только в рамках одного экономического агента, в данном случае коммерческой компании.
И даже когда мы выкладываем свои типовые решение в open-source, это не останавливает рост трудозатрат в IT-отрасли:
Ну ок, давайте писать все на VBS, нафиг все остальное.
есть ещё вендоры, создатели новых, ещё чуть более усовершенствованных технологий, языков, фреймворков,
которые требуют постоянного переобучения и разработки нового кода, новых прикладных решений.
Настоящий прорыв будет состоять в правильной постановке задач, когда производственный процесс будет подчинён лишь одному: удовлетворению потребностей.
Product Owner — выполняет эту функцию. И это должен быть человек который разбирается в бизнесе,
как со стороны того как продукт приносит денег, так и со стороны чего хочет большинство пользователей его продукта.
… как из всего зоопарка имеющихся технологий выбрать наиболее удачные...
Что-то эволюция за 3.5 млрд. лет не выбрала наиболее удачный вариант.
Да, есть лидирующий (в нашем понимании) «продукт», но не единственный)
Ну или возвращаемся к VBS
с общественной точки зрения гораздо выгоднее и разумнее произвести один раз хороший продукт, чем производить 20 продуктов,
Что есть хороший продукт? Для Васи это одно для Пети другое.
каждый из которых ещё нужно постоянно доводить до ума.
Телефоны как раз сейчас клепают один на другой похожие, нет разнообразия.
… Однако нам не нужно для этого вставать на линейку в 10 утра и рассказывать другим, что мы сделали вчера.
Ну почему же есть люди которые воспринимают стендапы как встречи для докладов и отчетности(
Нашим надсмотрщиком является только наше желание сделать мир лучше.
Это в первую очередь встреча команды, для понимания кто какой задачей занимается и нужна ли ему помощь от коллег.
Agile и Scrum нужно уметь подавать, его нельзя директивно навязывать, люди должны сами хотеть трансформации.
ssurrokk
Отсутствие конкуренции это монополия. В отсутствии конкуренции что заставит монополию меняться к лучшему? не понятно
JustDont
Тут существует куда более системная проблема — никто не знает, как надо. А если и думает, что знает — то может ошибаться.
Плюрализм, при всей его неэффективности, спасает человечество от принятия единого неправильного решения, которое это самое человечество и похоронит (ввиду отсутствия альтернатив).
ЗЫ: При этом с авторской критикой Agile можно в солидной степени согласиться, кстати.
botyaslonim Автор
Сначала поставим вопрос: зачем вообще меняться? Капиталистическим монополиям — очевидно только в случае серьёзной угрозы со стороны других монополий (если это глобальный рынок) или под давлением госрегулятора.
Социалистической централизованной экономике — под давлением со стороны пользователей. Естественно, тут есть всякие тонкости, чтобы не получилось в итоге, как СССР. Но глобально это правильнее: удовлетворять нужно нужды пользователей, а не рынка
JustDont
Простите, а как вы представляете давление на централизованную экономику от потребителей? Вот даже чисто в теории? Какими механизмами это могло бы обеспечиваться и регулироваться?
botyaslonim Автор
Уже есть многочисленные системы сбора мнений: отзывы, рейтинги. Если убрать отсюда маркетнговую составляющую и оставить собственно исследовательскую функцию, то будет отличный инструмент обратной связи. В маркетинге вообще много наработок. Главное — заставить их работать на пользу потребителя
JustDont
«Инструмент обратной связи» давления не создаёт. Инструментом можно не пользоваться, им можно пользоваться некорректно, или им можно пользоваться корректно, но класть с прибором на всю обратную связь.
Это несерьезно.
botyaslonim Автор
Инструменты работают по-разному в разной среде. Легко собирать информацию о выпускаемом продукте уже умеют. Как этим пользоваться — вопрос системы. В нынешней системе, за определённым (и всё более растущим) корпусом исключений, голосуют рублём.
Ark_V
ключ думается лежит в смене концепции «давление» на концепцию «интерес», в смысле творчество, престиж, общественное признание. Линукс разве под давлением возник и развивается, а не от интереса и амбициозности?
JustDont
Это не работает. Линукс развивается «от интереса» только потому, что те, кому он неинтересен — идут мимо и вообще никак не зацепляются. Для них есть альтернативы.
Общественные механизмы же должны работать почти на 100% общества. Ну или отправлять всех незаинтересованных на Луну. Без скафандров.
ЗЫ: Но да, вы в общем-то повторили мысль известных теоретиков коммунизма 30-50-х годов: надо всего лишь сделать систему из людей, которые в эту систему вписываются. И сразу всё будет хорошо ^_^
botyaslonim Автор
Зачем 100%? Кому интересно высказать своё особо ценное мнение, тот высказывает. Кому некогда или просто неинтересно — пользуется тем, что создали при участии других. Это простая система
rg_software
Ну да, вполне себе советский подход: вот тебе сапоги, и носи чего дают, а не нравится, иди в сапожники. Не очень хочется в такое будущее.
roscomtheend
> под давлением со стороны пользователей.
Которого не было (или было крайне незаметным для системы).
MikailBag
В принципе, есть сценарий монополии open-source проекта. Например, существует ровно один компилятор хаскеля, одно linux kernel, и т.д. Возможен не везде, но мне кажется идеальным, т.к. берет лучшее от монополии, но гораздо слабее проблемы монополии.
leotsarev
Опенсорс работает благодаря форку. Если ядро не будет удовлетворять потребителя, он форкнет и самостоятельно разработает подходящую ему версию. Если угрозы форка, угрозы конкуренции нет, то потребитель бессилен.
MikailBag
Ну да. Именно форк, т.е. возможность легко составить конкуренцию, и является причиной крутизны OpenSource монополии.