Комментарии 724
Великолепно!
А зачем тогда компания? Это ж какой-то дружеский стартап в хорошем смысле получается. По моему суть работы на дядю, что ты делаешь, что просят с требуемыми метрикам, и в конце месяца получаешь оговоренную зарплату хоть трава не расти.
А с большей ответственностью можно и до своего бизнеса дойти.
(А кстати у нас в лаборатории видимо полный Agile, да-с).
Agile-команд… подразумевает самоорганизацию. Задание не дают, его нужно взять… Потом это задание нужно самому и сформулировать, общаясь с Product Owner или даже… напрямую с заказчиком. Вместе с командой надо запланировать спринт. А потом ещё нести ответственность за общий результат...
А зачем тогда компания? Это ж какой-то дружеский стартап в хорошем смысле получается. По моему суть работы на дядю, что ты делаешь, что просят с требуемыми метрикам, и в конце месяца получаешь оговоренную зарплату хоть трава не расти.
А с большей ответственностью можно и до своего бизнеса дойти.
(А кстати у нас в лаборатории видимо полный Agile, да-с).
Это именно то, что отличает отAgileенного человека от не отAgileенного ;)
Если уровень осознанности сотрудника "я работаю на дядю" — хоть ногти ему вырывай — никакого Agile не построется. Если сотрудник дорос до идеи "мне с этой компанией попути так как сей час у нас общие цели и интересы" — добро пожаловать в Agile.
Как верно замечает автор статьи, задачей мастера является донести эту светлую мысль до руководства компании и менять ее культуру.
Вы спросите, а как управлять этим бардаком?
Через целеполагание, ведь у вас работают самостоятельные профессионалы, которым с вами по пути.
Ок, а если у нас скучная работа по поддержке страшного велосипеда с историей в 15 лет? Значит вам не нужен Agile, проходим мимо этой практики.
мне с этой компанией попути
Ещё может быть мышление в формате «это мой проект, я в него вкладываюсь и могу сделать лучше». Особенно, когда процессы реально построены так, что можно влиять и получать результат.
С таким подходом даже иные страшные велосипеды можно привести в порядок :)
«я работаю на дядю»За зарплату думать иначе — преступление.
Если сотрудник дорос до идеи «мне с этой компанией по пути...»Если нет доли в кампании, то это все тупой буржуйский развод айтишного пролетариата.
Согласен, особенно если речь идет о зп средней по больнице). Думаю agile стратегия должна применяться от уровня тимлид и выше
А как же удовольствие от работы? Когда в голове сидит установка «я тяну лямку», удовольствия не будет.
Не всегда равно удовольствие и напрягаться ). И не каждый работает программистом ради удовольствия, как минимум потому что не раздражает
А как же удовольствие от работы? Когда в голове сидит установка «я тяну лямку», удовольствия не будет.Удовольствие — отдельно, финансы — отдельно.
Ну это кому как. Я, например, предпочитаю получать деньги за работу, которая мне нравится, а не которая вызывает тоску.
Мне вот работа нравится, она интересна, оклад устраивает, и я не пинаю известные органы на работе, а выполняю свои задачи с адекватной скоростью и качеством. Однако, я понимаю, что работаю «на дядю», и не буду бросаться в огонь и воду ради блага фирмы. А есть люди, которые из-за «понравившейся» работы готовы реально пахать овертайм, да и по выходным, и дома. Имхо — это такой себе подход, если у вас нет доли в бизнесе.
Личный выбор каждого. Я вот частенько, задержавшись на работе или дома, рефакторингом или другими улучшениями DX занимаюсь, чтобы на работе было проще работать. В своё удовольствие и для себя, а не для "дяди". Дяде это тоже пользу приносит, но делаю я это для себя, а не для него.
Ну-у-у, я например люблю в рабочее время писать пет проекты. Как аджайл к этому относится?
А вам не кажется, что такое поведение — обман работодателя?
Нет, не кажется – я так повышаю свою квалификацию и отдыхаю от скучной работы. Что очень полезно для работодателя, потому что потом отдохнувши, я могу писать для него реально высококачественный софт. А если работаю все 8 часов над его рутинных проектов то код получится у меня глючный и проблемы будут большие.
А я не виноват, что работодатель не понимает такие простые вещи и хочет чтобы я работал все 8 часов на него.
А я не виноват, что работодатель не понимает такие простые вещи и хочет чтобы я работал все 8 часов на него.
Немного слабоватая аргументация на мой взгляд. Как ни крути, а работодателя вы обманываете. Возможно при этом вы исходите из лучших побуждений, но факт остаётся фактом.
Просто представьте себе что все работодатели в свою очередь начнут вас постоянно обманывать тоже исходя из каких-то своих «самых лучших побуждений» которые лично вы не понимаете. Вам бы это понравилось? Как вы например среагируете если такое вдруг вскроется?
Так, работодатели всегда обманывают. А если не обманывают (есть, есть такие!), то становятся банкротами.
Очень категоричное заявление, с которым лично я не согласен. И если вам попадались только такие работодатели, то могу вам только посочувствовать.
Вы не согласен только потому что у нас с вами не совпадают определения на слово "обман". Что считать обманом и что нет.
Очень может быть. Но тогда скажем так: далеко не все мои работодатели пытались меня намеренно ввести в заблуждение или уж тем более поступали со мной нечестно :)
Я тоже могу честно заявить то же самое. Но несмотря на это считаю свои прежние посты верными. :)
Но при этом если я всё правильно понял, то вы свои пет-проекты от начальства скрываете и следовательно как минимум уже «намеренно вводите начальство в заблуждение» :)
Самый простой пример обмана — сокрытие зарплат одного человека от другого. Одному говорят «денег нет, поднять не можем», а второго сразу нанимают за 5000 баксов в месяц без торга. И что, ни разу такого не встречалось? :)
По-моему это самая классическая практика которая есть везде.
И применяется ровно с целью уменьшения затрат у клиента на разработчиков.
По-моему это самая классическая практика которая есть везде.
И применяется ровно с целью уменьшения затрат у клиента на разработчиков.
Я вот сейчас пытаюсь припомнить, но вроде бы именно «денег нет поэтому поднять зарплату не можем» мне не говорили ни разу. То есть что эту самую зарплату мне поднимать не будут(ну или не будут это делать в том размере как я хочу) мне говорили много раз. Но с совсем другими обоснованиями :)
Сокрытие ещё не обман. Обман, наверное, начинается в этой ситуации только когда говорят «денег нет, поднять не можем», а деньги есть. А часто ведь не говорят такого, а говорят что-то типа "ну ты ещё себя не показал, давай сделаем тебе план развития" или "по нашим правилам повышение с НГ" и т..п
Интересно услышать мнение человека, который минус поставил?
Ровно так же, как agile — обман работника.
Ты пилишь проект и твоя мотивация — успех проекта, ты вовлечён. Если твоя цель отсидеть от звонка до звонка и делать такой минимум чтобы тебя не уволили, а на всё остальное пофиг, то действительно с тобой не по пути. Даже если ты хорошо пишешь хороший код (допустим за плохой увольняют, так что ты пишешь хороший).
на всё остальное пофиг
На что имено остальное? Тимбилдинги? Общение «за жизнь» с коллегами?
Даже если ты хорошо пишешь хороший код
Ого, теперь мало просто хорошо работать — хотят ещё и в голову залезть?
Впрочем, я сомневаюсь, что «делать такой минимум чтобы тебя не уволили» и «хороший код» реально совместимы.
Вот именно, суть этого просто в том что никто не может написать хороший проект, если у него нет внутренней мотивации это сделать и единственная его мотивация тупо получить деньги и всё.
Ты пилишь проект и твоя мотивация — успех проекта, ты вовлечён. Если твоя цель отсидеть от звонка до звонка и делать такой минимум чтобы тебя не уволили, а на всё остальное пофиг, то действительно с тобой не по пути. Даже если ты хорошо пишешь хороший код (допустим за плохой увольняют, так что ты пишешь хороший).Нет, я говорил, не про это. Конечно, мотивация делать работу так, чтобы результат «аж сиял» — это просто здорово, и каждый должен стремится к этому. Но…
Часто под такую мотивацию работодатель подсовывает своим сотрудникам очень невыгодные условия работы (финансовые, организационные, бытовые и т.д.).
Другими словами — человек должен всегда иметь внутреннюю мотивацию, но в беседах с работодателем отстаивать свои права на внешние условия работы. Это как-бы непересекающиеся плоскости.
Например моя мотивация — писать код. Мне нравится писать код, мне нравится находить решения сложных задач и преодолевать трудности. А вот успех проекта мне глубоко безразличен. Для этого есть менеджер и выше. И если завтра проект умрет, то я с таким же удовольствием буду работать над следующим (возможно со сменой работы). То есть получать удовольствие от работы и быть вовлеченным в проект — это могут быть совершенно не пересекающиеся понятия.
«я работаю на дядю»
За зарплату думать иначе — преступление.
Мне непонятно откуда эта позиция берётся, да ещё в таком экстремальном виде? Надеюсь вы не против, если ваш доктор подумает так же, когда вы к нему прийдете с непонятной болезнью следующий раз. Или учительница, которая ваших детей в школе учит заявит на родительском собрании — «знаете я тут на дядю работаю, поэтому как он скажет так и делаю, на знания в головах ваших детей мне плевать, мне деньги за отчеты платят. С отчетами все ок? Значит претензии не ко мне, я все делаю по инструкции. Предъявляйте начальству, процессу и гороно.»
Свою работу нужно любить не за долю в компании, а просто так, потому что нравится это делать. Хочешь долю — или покупай акции или делай свою компанию.
Было время когда я думал, что финансовая мотивация улучшит работу. Но нет, когда разработчики и менеджеры получали долю в прибыли они просто продолжали работать как обычно, ничего не менялось. Для меня, акции и прочие «мотиваторы» этого толка это метод привязать сотрудника, но никак не метод повысить его мотивацию. Мотивация, она внутри, снаружи плохо поддаётся влиянию.
Слова «нужно» и «любить» несовместимы.
Было время когда я думал, что финансовая мотивация улучшит работу.Есть интересные исследования, которые показывают, что внешняя мотивация как раз подавляет внутреннюю.
ссылки дадите?
Ссылок не нашёл. Помню фамилии исследователей (Deci и Ryan) и содержание одного из экспериментов.
Исследователи взяли группу студентов, увлекающихся головоломками и разделили на две части. Эксперимент длился три дня. В одной группе студенты просто разгадывали головоломки все три дня, в другой на второй день ввели денежное поощрение за успешно разгаданные головоломки, на третий — убрали.
Первая группа в плане мотивации шла ровно все три дня. А вот вторая на третий день мотивацию подрастеряла, после того, как отменили внешнее поощрение.
Исследователи взяли группу студентов, увлекающихся головоломками и разделили на две части. Эксперимент длился три дня. В одной группе студенты просто разгадывали головоломки все три дня, в другой на второй день ввели денежное поощрение за успешно разгаданные головоломки, на третий — убрали.
Первая группа в плане мотивации шла ровно все три дня. А вот вторая на третий день мотивацию подрастеряла, после того, как отменили внешнее поощрение.
Так это не внешняя мотивация подавляет, а ее прекращение. Немножко разные вещи.
Не, там снижение по сравнению не со вторым, а с первым днём (когда так же не платили), и с контрольной группой.
Представьте что есть 3 состояния морали(внутренней мотивации):
0 = Как обычно
+1 = Сделали лучше
-1 = Сделали хуже
Так вот день 3 это мораль "-1", а не «0»
То есть день 1 это мораль «0», день 2 это мораль "+1", а день 3 это мораль "-1"
0 = Как обычно
+1 = Сделали лучше
-1 = Сделали хуже
Так вот день 3 это мораль "-1", а не «0»
То есть день 1 это мораль «0», день 2 это мораль "+1", а день 3 это мораль "-1"
Видите ли: прекращение оплаты — это отрицательная мотивация. И ее эффект, разумеется, будет перекрывать эффект от нулевой мотивации первого дня.
Чтобы отмена оплаты не оказывала влияния на работу, нужен далеко не один день, и отмена должна быть очень постепенной. Почитайте, как собак дрессируют, чтобы они выполняли команды «Ко мне», «Сидеть» и так далее.
Чтобы отмена оплаты не оказывала влияния на работу, нужен далеко не один день, и отмена должна быть очень постепенной. Почитайте, как собак дрессируют, чтобы они выполняли команды «Ко мне», «Сидеть» и так далее.
Мне кажется, там был еще такой нюанс: те, кому платили, разгадывали ровно столько головоломок, сколько было оплачено. Оставшееся время убивали, валяли дурака, но к головоломкам не притрагивались. В итоге, те кому не платили, решали головоломок больше, чем те, кому платили.
Вообще мотивацию подрывает не любая оплата, а скорее сдельная, нерегулярная. Один раз дадут премию, больше без премии никто такую работу делать не будет. Даже если интересно.
Лучше всего просто платить фиксированную з/п. Достаточную, чтобы человек не чувствовал себя недооцененным. Тогда он начинает сам себя мотивировать, вне связи с деньгами.
Вы не правы про премию. Ее просто надо правильно использовать
Премию надо давать неожиданно и время от времени. И не за определенные вещи, а просто с формулировкой "начальство решило, что ты хорошо работаешь".
Тогда сотрудники будут хорошо работать "на всякий случай". Эффект описан у Вайшенк, по-моему, в книжке Законы влияния. Там был эксперимент про детей.
В таком виде, как Вы говорите, по идее премия не должна навредить. Но по факту, правильно премировать крайне трудно. Так или иначе, человек свяжет премию с какими-то своими действиями.
Кроме того, считается правильным давать сотруднику обратную связь. Если явно не говорить, что именно он сделал хорошо, а что плохо, он может всё неправильно интерпретировать.
В общем, уже во многих источниках читал, и сам с этим согласен, что с премиями лучше не рисковать. Денежное вознаграждение – слишком мощный стимул, с которым можно легко "наломать дров".
Ну премировать можно и не только конкретного человека за конкретные заслуги, но и скажем абсолютно всех работников фирмы. Всем разные суммы, но всем дать прнмию. И в качестве обоснования привести скажем удачный год или что-то в этом роде.
Соответственно люди сделают для себя вывод что чем лучше дела у фирмы тем больше вероятность получить бонус. Ну или что бонус будет тем больше чем лучше идут дела.
Соответственно люди сделают для себя вывод что чем лучше дела у фирмы тем больше вероятность получить бонус. Ну или что бонус будет тем больше чем лучше идут дела.
книга Дэниел Пинк, Драйв: Что на самом деле нас мотивирует
Мне непонятно откуда эта позиция берётся, да ещё в таком экстремальном виде?Нормальная адекватная позиция для экономики, основанной на товарных взаимоотношениях.
Надеюсь вы не против, если ваш доктор подумает так же, когда вы к нему прийдете с непонятной болезнью следующий раз.Какой-то чужой человек не хочет решать мои проблемы просто так? Какой ужас!
Свою работу нужно любить не за долю в компании, а просто такА давайте вы мне будете платить просто так из любви к людям?
потому что нравится это делатьА если не всегда нравится? Или вообще не нравится?
когда разработчики и менеджеры получали долю в прибылиИ на сколько доля в прибыли повышала доходы работников? На 5%?
Какой-то чужой человек не хочет решать мои проблемы просто так? Какой ужас!
Отношения людей не исчерпываются товарно-денежными. Если я покупаю услугу, то рассчитываю, что тот, кто услугу оказывает приложит все разумные усилия и все свои знания чтобы мне помочь. Почему? Потому что так принято в моем окружении, потому что такое поведение приводит к равновесию в некоторых моделях теории игр, потому что это соответствует морали всех известных мне религий. Выбирайте, что вам больше нравится.
А давайте вы мне будете платить просто так из любви к людям?
Немного глупо себя чувствую, ну да ладно… Если вы будете на меня работать, я буду вам платить зп и буду рассчитывать, что вы сделаете все возможное, в рамках вашей компетенции, для решения моих проблем за мои деньги.
И на сколько доля в прибыли повышала доходы работников? На 5%?
Сотрудники получали 30% от прибыли компании. Для некоторых позиций прибавка была в 100% и более в удачный месяц. В абсолютном выражении — 300-400 тыс. рублей при средней зп в 150. Это был 2013-2015 год.
Простой вывод — люди работают лучше не от того, что у них доля появилась. Они работают лучше от того, что у них новые знания появились, новые модели поведения они усвоили (типа научились задавать правильные вопросы заказчику/менеджеру)
Сама фраза «работать на дядю» отдаёт homo-sovericus, фу таким быть. Гораздо приятнее себя ощущать свободным человеком, помогать другим людям, в частности, с помощью своей профессии.
Отношения людей не исчерпываются товарно-денежными.Работник и работодатель вступают именно в товарно-денежные отношения.
Если я покупаю услугу, то рассчитываю, что тот, кто услугу оказывает приложит все разумные усилия и все свои знания чтобы мне помочь.Нет, вы хотите, чтобы оказывающий услугу фанатично делал больше, чем то, о чём вы договорились.
Если вы будете на меня работать, я буду вам платить зп и буду рассчитывать, что вы сделаете все возможное, в рамках вашей компетенции, для решения моих проблем за мои деньги.Не всё возможное, а столько, сколько диктует рынок. У вас нет никаких оснований рассчитывать на что-то большее.
В абсолютном выражении — 300-400 тыс. рублей при средней зп в 150Получается, что ваши работники и так работали на пределе своих способностей. Чего вы ещё от них хотели? Думаю, что вы хотели избежать необходимости кого-то ещё нанимать.
Простой вывод — люди работают лучше не от того, что у них доля появилась. Они работают лучше от того, что у них новые знания появились, новые модели поведения они усвоили (типа научились задавать правильные вопросы заказчику/менеджеру)
Гораздо приятнее себя ощущать свободным человеком, помогать другим людям, в частности, с помощью своей профессии.Согласен, что приятнее. Но с товарно-денежными отношениями это стыкуется плохо.
Нет, вы хотите, чтобы оказывающий услугу фанатично делал больше, чем то, о чём вы договорились.
Это вы себе придумали, я ничего такого не говорил и не имел в виду. Вы меня пытаетесь неким таким рабовладельцем выставить. Зачем-то додумываете контекст, которого я не давал и которого нет и даёте ответы не на поставленные вопросы, а на те которые вы сами придумали. Я в такие игры не играю.
Работник и работодатель вступают именно в товарно-денежные отношения.
Ну вообще-то это назыаается трудовые отношения. Товарно-денежные это немного о другом.
Нет, вы хотите, чтобы оказывающий услугу фанатично делал больше, чем то, о чём вы договорились.
Это опять же вопрос того как и о чём конкретно договорились. И вопрос того что в таких случаях обычно принято как вариант «по умолчанию».
Ну вообще-то это назыаается трудовые отношения. Товарно-денежные это немного о другомТрудовые отношения — это вид товарно-денежных отношений, в которых в качестве товара выступает труд.
Трудовые отношения — это вид товарно-денежных отношений, в которых в качестве товара выступает труд.
Не совсем. С одной стороны, трудовые отношения — это нечто более сложное, т.к. тянут за собой большой пласт социальной ответственности и обязательств, с другой — далеко не каждая продажа труда и рабочего времени является трудовыми отношениями.
Если вы будете на меня работать, я буду вам платить зп и буду рассчитывать, что вы сделаете все возможное, в рамках вашей компетенции, для решения моих проблем за мои деньги.
Частично я согласен с Вами обоими, но частично и не согласен с этой фразой.
Если работодатель платит конкретную зарплату за конкретную работу, он получает эту конкретную работу, если он хочет «все возможное», значит в оплату работы должна идти тоже максимально возможная сумма. Но так как 99% работодателей не платят все возможное(грубо говоря, «свободную» прибыль не переводят в зарплату), то и люди это видят и соответствующе ведут себя.
Да, не делать «все возможное» конечно тоже не значит пинать балду, «все возможное» и «не все возможное» это скорее вопросы именно мотивации, но надеяться что люди будут из кожи вон лезть, когда работодатель не ведет себя соответствующе, не стоит.
p.s. Ну и да, описанное выше подходит пожалуй только для долгосрочных отношений работодатель-работник, для разовой работы уже отдельный развовор.
А если и нужны только товарно-денежные отношения? Необходимые мне услуги/товары за мои деньги по взаимному договору без всяких других отношений. Тем более без религии, морали, блата, неявных соглашений и т.п.
Получить что-либо от людей и избежать при этом отношений с людьми – сложновато.
Даже если не станете нанимать сотрудников, а захотите заказать работу по договору, напишете детальное ТЗ, то потом всё равно придется немало понервничать, когда дойдет дело до приемки. С веротяностью 99% всё сделают не так, как Вы хотели.
Товар в данном случае это продукт работы мозга, он не отделим от человека и его отношения к вам и к своей работе.
Какой-то чужой человек не хочет решать мои проблемы просто так? Какой ужас!
Ну я бы порешал, если бы денег было достаточно. После определённого порога уже +- пофиг, работаешь на интерес, а не на выживание.
Уточню. Вот если у меня не хватает денег пожрать вечером, тогда и работать не хочется. А если у меня не хватает денег купить дом через пару лет, или скажем на стартовый бюджет собственной компании, то это вообще не так воспринимается уже, и послать заказчика в лес по дрова не хочется.
Даже если бы мне резко стало не хватать на еду, ну или там резко деньги понадобились, я скорее тихо мирно буду искать новую работу где платят больше. А не филонить на этой. Ибо смысла в этом ноль вообще.
Фокус в том, что откуда-то берутся люди, живущие в Украине, получающие от 2-5 тысяч $ и всё равно имеющие позицию «ни малейшей мысли сверх джиры, ни строчки кода сверх оговоренного». Я таких видел. Не очень понравилось, для стартапа такая позиция подходит наихудшим образом, плохо было всем.
Я бы поставил +10, если бы мог.
Деньги – это гигиенический фактор мотивации. Человек должен понимать, что ему не недоплачивают. После этого порога деньги отходят на второй план. Внешняя мотивация начинает даже душить внутреннюю.
Многие люди находятся ниже этого порога, отсюда и позиция про «дядю».
Могу ещё добавить, что если слишком зацикливаться на этой позиции, есть риск никогда не превысить порог. И всю жизнь прозябать, успокаивая себя тем, что и «дядя» на тебе не сильно наварился.
Мой подход, в котором я ни разу не разочаровался: если хочешь что-то получить, не скупись раздавать. Не убудет.
Всё так, менталитет «работаю на дядю» порождает добровольных, низкопродуктивных рабов, хотя никому это ненужно.
А это не так? Тобой пользуются, покупая твое бесценное время жизни за копейки, в то время как у самих миллиарды. И этими миллиардами не собираются делиться
Может быть не стоит так обобщать? Как будто у всех работодателей прямо миллиарды, которыми они с вами не хотят делиться…
Есть так же куча работодателей, которые кредиты берут чтобы своё дело начать и у них на счету не миллиарды, а скорее минусовые значения.
Есть так же куча работодателей, которые кредиты берут чтобы своё дело начать и у них на счету не миллиарды, а скорее минусовые значения.
Вопрос на засыпку — если время бесценное и приносит миллиарды, то почему бы вам его не продать за миллиард-10%? Конкуренция дала сбой планетарного масштаба? Или у нас картельный сговор всех миллиардеров против всех программистов с целью покупать за бесценок их бесценное время и получать миллиарды таким образом?
Я скажу даже больше — у нас картельный сговор миллиардеров не только против программистов, но и против всего остального населения. Иначе как вы объясните, что 5% населения владеют 90% богатств? Или почему большая часть населения живет почти за чертой бедности без удовлетворения базовых потребностей?
Многие феномены порождённые обществом описываются распределением Паретто, те самые соотношения 80 на 20 или 95 на 5 как раз оттуда. Например размеры городов, богатство людей и т.п. Возможно эти феномены объясняется наличием положительных обратных связей где-то в механизмах градообразования и деньгозарабатывания.
Интересно было бы узнать ваши идеи по поводу создания и функционирования тайного сговора с 610^90.05=300 000 000 членов. Как они съезды устраивают, как новых челнов вербуют, как решают споры между собой, как следят за соблюдением договоренностей и т.п. Ну и все это в режиме строгой секретности.
Откройте список этого 1%- миллиардеров и их семей и увидите как они набирают новых членов, а еще у них есть куча вполне открытых организаций типа мвф, сьезды на любом экономическом форуме типа давоса и тд. Они не то чтобы закрыты, но и не особо открыты, вам часто гендир или собственник рассказывают свои планы или просто общаются о бизнесе?
Тобой пользуются, покупая твое бесценное время жизни за копейки, в то время как у самих миллиарды. И этими миллиардами не собираются делиться
Ну так и путь «в миллиардеры» вроде никто особо не закрывает, ищите нишу, занимайтесь бизнесом. Или там тоже «злые дяди» не дают разбогатеть?
Добро пожаловать в реальный мир, тут все дяди — «злые».
«ищите нишу, занимайтесь бизнесом. „
Вот только это путь чтобы войти в 1% богатых людей которые могут позволить себе нормально жить. Правильно было бы если бы богатства были распределены более равномерно и нормально могло жить хотя бы больше половины населения, в идеале — 80%
Вот только это путь чтобы войти в 1% богатых людей которые могут позволить себе нормально жить. Правильно было бы если бы богатства были распределены более равномерно и нормально могло жить хотя бы больше половины населения, в идеале — 80%
Это 1% богатых людей живут ненормально, нормально живёт так называемый средний класс.
Так называемый средний класс на западе — от силы 10% мирового населения
Ну это и есть нормально. Средний класс на западе отнюдь не мешает, например, неграм афроафриканцам в Африке сдать на металлолом автоматы Калашникова, перестать друг друга геноцидить, и заняться сельским хозяйством, образованием и строительством. Точно так же он никак не препятствует индийскому правительству развивать социальные программы, бороться с нищетой в трущобах Мумбаи. Не каждый может стать миллионером, но это ведь и не требуется. На первую ступеньку цивилизации — обеспечиться едой, одеждой, крышей над головой и средним образованием, может ступить каждый, и проблема эта решается непосредственно на месте, на уровне общин, сёл, городов. А с первой ступеньки уже открывается доступ ко второй, третьей и так далее.
Ну я бы не сказал что совсем не мешает. Палки им в колёса местами всё-таки пихают. Вон например на тему того же сельского хозяйства: Европа у нас во всю эспортирует в Африку избытки своего оверсубсидированного сельскохозяйственного производства. Причём по демпинговым ценам(всё лучше чем выкидывать). При этом ни запретить ввоз, ни ввести ккаие-то пошлины африканцам не дают на международном уровне. Соотвественно развить своё собсетвенное сельское хозяйство Африка не особо то и в состоянии.
То есть конечно если все африканцы сговорятся и перестанут покупать дешёвые европейские продукты и начнут покупать более дорогие местные, то в теории это должно сработать. Но на практике вероятность такого равна нулю.
То есть конечно если все африканцы сговорятся и перестанут покупать дешёвые европейские продукты и начнут покупать более дорогие местные, то в теории это должно сработать. Но на практике вероятность такого равна нулю.
Не знаю, я лично сильно сомневаюсь, что в странах, где значительной части населения жрать нечего, а рабочая сила стоит сущие копейки, собственное с/х не развивается по внешнеэкономическим причинам, а не по каким-то иным, начиная от менталитета (бабушка маис собирала, мама маис собирала, и нам суждено), и заканчивая сильной, исторически сложившейся коррупцией.
Естественно это не единственная причина. Но это одна из причин и при этом далеко не самая неважная. Так что именно «мешать» там однозначно присутствует.
Так что именно «мешать» там однозначно присутствует.Показательным в плане оных «мешать» является гражданская война в США, когда капиталюгам оказалось гораздо выгоднее расхреначить половину собственной страны и потерять более 2% населения, чем мирится с причинами мешающими перевести чуть более 10% населения с мотыжного земледелия на более высокие технологии.
То что 90% мира живет в говне — это не нормально, более того, этот средний класс и есть причина. Капитализм — это мировая экономическая система, и если одним выгодно, они будут пользоваться или даже способствовать тому чтобы другие выращивали маис за гроши всю жизнь. Почему большая часть населения должна обслуживать спиннеры меньшей, когда самим нечего жрать?
Капитализм — это мировая экономическая система, и если одним выгодно, они будут пользоваться или даже способствовать тому чтобы другие выращивали маис за гроши всю жизнь.А кто сказал что им это выгодно? На самом деле даже захват территории дает экономический эффекта, в том и только в том случае если захватчик может обеспечить население оной территории более высокими технологиями чем они сейчас используют. И это актуально со времен как минимум Древнего Вавилона.
Почему большая часть населения должна обслуживать спиннеры меньшей, когда самим нечего жрать?
И как же они могут их осблуживать если с них взять нечего в результате их технологической отсталости? Или скажите в этой отсталости тоже Америки с Европами виноваты, которые оные технологии изобретали и развивали, пока оные собиратили маиса развлекались ловлей друг друга на обед?
На самом деле капитализму выгодно не втоптать окружающие страны в грязь, а повысить их технологический уровень, чтобы вынести туда задачи которые стали для самих низкотехнологичными. Сравните к примеру «свободных» собирателей капусты в Сервеной Корее с «порабащенной» Южной Кореей, или с «продавшимся буржуям» Въетнамом и Коста-Рикой.
У вас проц в компе где произведен? Как вы думаете смогли бы вьетнамцы, малазийцы или коста-риканцы перейти от мотыжного земледелия к технологиям которых у России и даже СССР не было и не будет в обозримом будущем, если бы капиталюги тока и старалитсь у них оный рис отабрать?
На самом деле даже захват территории дает экономический эффекта
Причем тут захват территории? Разве США захватило Китай, Сингапур и тд?
И как же они могут их осблуживать если с них взять нечего в результате их технологической отсталости?
Причем тут технологическая отсталось и как оно относится к теме разговора? В Китае, Индии, Бангладеш находятся производства почти всех товаров в мире и они бедно живут, Россия, СА и некоторые арабские страны поставляют ресурсы и также не входят в золотой миллиард?
И вообще, в чем смысл вашей речи если вьетнамец что собирая рис, что производя процессоры остается одинаково бедным?
В Китае, Индии, Бангладеш находятся производства почти всех товаров в мире и они бедно живут.ВВП Китая почти в 2 раза ниже ВВП США при том что население в 5 раз больше. Т.е. производительность китайца в 10 раз ниже производительности американца. А ВВП Индии ниже ВВП США почти в 10 раз, хотя население почти такое же как в Китае.
Вот вам и причина разного уровня жизни — разная производительность в следствие технологической отсталости от развитых стран.
ВВП это не только о производительности, а ещё и о рыночной стоимости. Китайцы могут производить в десять раз больше чем США, но если стоимость произведённых продуктов будет ниже, то и ВВП будет ниже. Даже если это абсолютно идентичные товары и/или услуги.
. Китайцы могут производить в десять раз больше чем США, но если стоимость произведённых продуктов будет ниже, то и ВВП будет ниже
Рецепт высококачественного «китайскога» станка — лазер производства ФРГ, направляющие Тайвань, двигателя и зеркала — США, контроллер и софт — Япония, закручивание шурупов — Китай, а значит Made in China. Реально доля труда китайцев в тех продуктах на которых написано Made in China процентов 10 максимум. А иначе какой бы им смысл было что то экспортировать если бы могли без импорта все производить для внутреннего рынка?
В том то и дело что Китай делает наиболее низкоквалифицированную часть работы. А на большую не тянет. К примеру те же кристаллы для лазеров выращивают в самом Китае. Но на обработку и сборку отправляют немцам. Сами то не умеют. А никакого лазерного станка без собранного лазера не будет. Это по твердотельным. По газовым там вообще только немецкие колбы. От оно так и получается в результате.
Даже если это абсолютно идентичные товары и/или услуги.
Естественно. Более высокие технологии дают более низкую себестоимость за счет более высокой производительности при более высоком качестве, что и рынок захватить позволяет и в результате дает больший ВВП за счет количества. К примеру американские моторы в китайские станки ставят потому, что если делать в Китае, на том оборудовании которое у них есть, и при этом аналогичного качества, то этот мотор будет в 10 раз дороже американца. А сделанный по американским технологиям для производителя станка обходится процентов на 10 дороже китайского гуано, но при этом в 10 раз лучше. При этом процентов 30 а то и 50 в этой цене — прибыль китайского посредника-импортера.
А выносят производство за границу потому что местный персонал уже реально привлекать к производству по еще более высоким технологиям, в то время как выносимое за границу производство — предел до которого можно подтянуть квалификацию персонала в отстающей стране. При этом абсолютно естественно что менее квалифицированный труд и оплачивается ниже.
Т.е. к примеру — производство процессоров по американским меркам труд не самой высокой квалификации. Его выносят во Вьетнам. Инженеров которые в результате высвободились от рутинной для их уровня знаний работы привлекают туда где у самих дефицит — т.е. в проектирование процессоров, которое требует гораздо более высокой квалификации чем производство, и осилить которое Вьетнам не в состоянии на его текущем уровне развития. В результате и США хорошо, и Вьетнаму куда лучше чем без США, а тем более чем воевать с США.
Вы написали очень много текста и местами даже очень правильные вещи. Но это не отменяет того факта что не стоит пытаться из одного только ВВП делать выводы о производительности.
Грубо говоря какой-нибудь массажист, работая только своими руками, за час работы в США-Европе "вносит в ВВП" 50-100 долларов. А точно тот же массажист в каком-нибудь Вьетнаме "внесёт" 50-100 центов.
ВВП не показывает производительность от слова совсем. Официант в США получает больше чем инженер в России или Китае, технологическая отсталость никак не влияет на количество получаемых денег.
Ну как не показывает? Официант производит продукт — услугу по обслуживанию — за что и получает свои деньги.
Производительность не показывает, потому что ВВП измеряется в абсолютных величинах. И, грубо говоря, официант, обслуживший триста клиентов в месяц в Куршавеле, и официант, обслуживший триста клиентов в местном кафе в Улан-Баторе, имеют примерно одинаковую производительность труда, но кардинально разный вклад в ВВП. Более адекватную картину даст ВВП, скорректированный на паритет покупательной способности, но и то, это будет средняя температура по больнице, т.к. в странах с разным достатком и структура затрат сильно отличается.
Смотря в чём мереть производительность. В долларах в час первый гораздо большую производительность имеет. И это куда больше интересует и его самого, и его работодателя, и инвесторов его работодателя, и государство.
И это куда больше интересует и его самого, и его работодателя, и инвесторов его работодателя, и государство.
Нет, в том-то и дело, что без учета поправки на упомянутый мной ППС, интересует не больше. Уж поверьте, вы не почувствуете разницы между зарплатой $4000 в месяц и $400, если сосиски в соседнем магазине будут стоить $10 в первом случае, и $1 — во втором.
Да, та часть экономики, которая занимается импортом товаров из-за границы, намного лучше себя чувствует, когда внутренние субъекты имеют бОльший доход. С другой стороны, та часть экономики, которая занимается экспортом, наоборот, предпочитает низкие доходы внутри страны. Так что эти два фактора в среднем компенсируют друг друга.
То есть услуга по обслуживанию столика более производительна, чем тысяча продуктов на заводе?
А то что инженер в китае или россии получает меньше официанта в штатах показывает общую технологическую отсталость россии и китая. Официант по факту задействован в обеспечении производства, а не непосредственно в производстве. Т.е. его з/п зависит от производительности тех кого он обслуживает.
И вообще, в чем смысл вашей речи если вьетнамец что собирая рис, что производя процессоры остается одинаково бедным?Бедными остаются те, кто пока что не вовлечен в это хай-теч производство, в первую очередь по причине отсутствия у них нужной для такого труда квалификации. Те же кто участвуют как в оном производстве непосредственно, так и в его обеспечении люстричеством и т.п. имеют достаточный для поддержания и повышения квалификации уровень жизни. Со временем примитивный труд вытесняется квалифицированным полностью. К примеру в той же Коста-Рике уровень з/п давно выше российского раз в 5 — т.е вплотную приближаются к уровню стран ЕС а то и превосходит его.
Причем тут захват территории? Разве США захватило Китай, Сингапур и тд?А вот в том и отличие капитализма от имперского феодализма что «рабы» сами продаются «хозяевам» в обмен на доступ к более высоким технологиям обеспечивающим более высокую производительность и как следствие более высокий уровень жизни.
Бедными остаются те, кто пока что не вовлечен в это хай-теч производство, в первую очередь по причине отсутствия у них нужной для такого труда квалификации.
Но при этом какой-нибудь «неквалифицированный» житель Европы/США будет однозначно богаче такого же «неквалифицированного» жителя Вьетнама. А местами даже и богаче «квалифицированного».
Но при этом какой-нибудь «неквалифицированный» житель Европы/США будет однозначно богаче такого же «неквалифицированного» жителя Вьетнама.При этом от «неквалифицированного» жителя Европы, ака уборщица или мусорщик, уже давно требуется знание робототехники хотя бы на уровне управления оной, в отличии от подавляющего большинства квалифицированных вьетнамцев.
В результате же «порабощения» Западом уровень з/п во Вьетнаме за крайние 15 лет вырос в 17 раз. Так что такими темпами на уровень Европы выйдут очень быстро.
Я не хочу разрущать ваши иллюзии в отношении жителей Европы. Но «знание робототехники хотя бы на уровне управления оной» это вещи, которым можно за день научить семилетнего ребёнка. И пожалуй большинство «неквалифицированных» жителей Европы это вчерашние жители Вьетнама, Сирии, Афганистана и Африки. Или вы думаете беженцы в Европу прут из-за толерантности и свтского общества? :)
«Бедными остаются те, кто пока что не вовлечен в это хай-теч производство»
Вот только большая часть населения этих стран бедное, миграция в города огромная и в Китае уже почти закончилась поэтому можно говорить что большая их часть вовлечена в производство. Да и вообше повторюсь — бедные 80-90% населения ПЛАНЕТЫ. То есть по вашему это норма вообще?
Причем тут вообще технологии? Рабы продаются за деньги, за которые можно купить еду, одежду, квартиру. Это не высокий уровень жизни, это базовые потребности человека которых у многих либо нет, либо они не удовлетворяют качеству. Да и вообще посмотрите на зарплаты в том же IT в регионах или зарплаты рабочих на заводе — у меня например есть родственник который собирает спутники на заводе и получает 20к в месяц, что полностью не вписывается в ваш тезис о высоком уровне жизни
Ну и как уже сказали выше — квалифицированный вьетнамец будет получать меньше чем неквалифицированный американец
Вот только большая часть населения этих стран бедное, миграция в города огромная и в Китае уже почти закончилась поэтому можно говорить что большая их часть вовлечена в производство. Да и вообше повторюсь — бедные 80-90% населения ПЛАНЕТЫ. То есть по вашему это норма вообще?
А вот в том и отличие капитализма от имперского феодализма что «рабы» сами продаются «хозяевам» в обмен на доступ к более высоким технологиям обеспечивающим более высокую производительность и как следствие более высокий уровень жизни.
Причем тут вообще технологии? Рабы продаются за деньги, за которые можно купить еду, одежду, квартиру. Это не высокий уровень жизни, это базовые потребности человека которых у многих либо нет, либо они не удовлетворяют качеству. Да и вообще посмотрите на зарплаты в том же IT в регионах или зарплаты рабочих на заводе — у меня например есть родственник который собирает спутники на заводе и получает 20к в месяц, что полностью не вписывается в ваш тезис о высоком уровне жизни
Ну и как уже сказали выше — квалифицированный вьетнамец будет получать меньше чем неквалифицированный американец
Это не высокий уровень жизни, это базовые потребности человека которых у многих либо нет, либо они не удовлетворяют качеству.у меня например есть родственник который собирает спутники на заводе и получает 20к в месяц,Ну надеюсь понятно что нельзя клепать гуано по технологиям 50-х и при этом жить как в америках в 21-ом веке? А тем более мотыгой махать. Бери побольше — кидай подальше на достойную жизнь не накидаешь.
Тут что то потехнологичней надо. Кста сантехник во Вьетнаме получает больше чем ваш знакомый.
Да и вообще посмотрите на зарплаты в том же IT в регионахНу у нас в стране околовсяческих веб-«разрабов» которые хотят з/п до 500 — ну хоть пулемет ставь отбиваться. А спецов на з/п от 5k — днем с огнем не найдешь. Оно потому и разница что квалификация разная.
или зарплаты рабочих на заводе
Видел кстати одно интересное сравнение где расписано почему. Новейший сталелитейный комплекс высокоточного литья два одинаковых в Германии и в России закупленный у немцев.
Германия. Производство x тыс тон. Брак 0.1%. Персонал 200 чел. Средняя з/п ~ 3000k евро.
Россия. Производство 1.1*x тыс тонн. Брак 15%. Персонал 2000 чел. Надеюсь понятно что при прочих равных з/п больше 300 евро быть не может в принципе?
А вообще рабочие специальности — это как раз тот пережиток который следует изжить. В развитых странах интеллектуальным трудом давно занимается более 50% наемных работников. Синие же воротнички все больше и больше управлением робототехникой занимаются а не ручной работой.
Ну и как уже сказали выше — квалифицированный вьетнамец будет получать меньше чем неквалифицированный американец
Ну дык в высокотехнологичной стране производительность выше. Поэтому и на то меньшинство, которое в результате недостаточной квалификации работу потеряло произведенного худо-бедно хватает. В отличии от страны где основная масса — мотыгомахатели, которых за счет квалифицированного меньшинства подкармливать надо, особенно если от пережитков совдепии еще не избавились.
Т.е. еще раз — производство выносят во Вьетнам не потому что там у инженера занимающегося той же работой может быть ниже уровень жизни — по вашему же Марксу он не может быть ниже необходимого для восстановления рабочей силы — в том числе и уровень образования и используемых в быту технологий и т.д., а потому что высвободившихся в результате американцев можно привлечь к еще более квалифицированному труду чем вынесен во Вьетнам. Отсюда и разница в з/п. Т.е. разница в спросе и предложении на спецов на внутреннем рынке страны. Те спецы которые высвободились в штатах банально востребованы на такой работе где им могут заплатить еще больше. От отсюда и разница. И другой причины выносить производство нет в принципе. Ну разве что в следствии горного рельефа и постоянных осадков во Вьетнаме еще и розетка практически халявная, в отличии от той же Малазии, где люстричество на вес золота. И для того чтобы производство начали именно во Вьетнам выносить политбюраторам Вьетнама пришлось очень усердно помолится — устроить 10-летнюю национальную программу по строительству гидростанций.
Ну надеюсь понятно что нельзя клепать гуано по технологиям 50-х и при этом жить как в америках в 21-ом веке?
То есть вы считаете что сантехник во вьетнаме делает более технологичную работу чем мой родственник с красным дипломом по физике и использующий последние конструкторские решения по созданию спутников? Если нет, почему он получает 20к, а сантехник больше?
В развитых странах интеллектуальным трудом давно занимается более 50% наемных работников.
Откуда у вас эта информация? В развитых странах более 60% населения работают в сфере обслуживанию — поэтому они называются постиндустриальными странами. Там официант в кафе и клерк в отеле получает больше чем моя зарплата программиста.
Ну дык в высокотехнологичной стране производительность выше.
Вот только что толку от этой производительности если все деньги все равно утекают в руки к финансистам и банкам? Если прибыль завода — 1%, а прибыль банкиров и торгашей 20%? Да даже сам МВФ уже года два трубит тревогу что разница доходов между богатыми и бедными все растет и растет и это грозит новым кризисом
В развитых странах более 60% населения работают в сфере обслуживанию — поэтому они называются постиндустриальными странами.А основными направлениями сферы обслуживания есть таки образование, медицина, транспорт, обслуживание инженерных коммуникаций жилья и т.п., где без работы москами и руками то работать не получится от слова совсем, а никак не официанты и прочие гарсоны.
Вот только что толку от этой производительности если все деньги все равно утекают в руки к финансистам и банкам?В компартии что вообще хотя бы чему то учить перестали, а только зомбируют? Ну хотя бы тому что финансовый оборот вертится в обратную сторону от продуктового и оценивать все нужно именно по продуктовому?
Новый завод он из сферического вакуума взяться не может. Его в его физическом виде можно получить только путем производства оборудования на уже существующих. В финансовом эквиваленте это означает — необходимо где то аккумулировать их прибыль. При этом прибыль — это разница между рыночной ценой и себестоимостью. Т.е. то что сверх затрат на сырье, зарплаты, налоги, амортизацию оборудования, отчисления в фонд развития производства и т.д. и т.п.
Если прибыль завода — 1%, а прибыль банкиров и торгашей 20%?С каких пор владельцы завода перестали быть торгашами скупающими труд оптом и продающими его результат в розницу? На самом деле сдвиг этот показывает только степень срастания банковского и промышленного капитала и больше ничего. А большая концентрация капитала как известно повышает эффективность его использования.
Да даже сам МВФ уже года два трубит тревогу что разница доходов между богатыми и бедными все растет и растетТока доходы багатых — это прирост доли контроля в управлении капиталом, а не той доли которую персонально спустит в унитаз, как наемный работник. Реально персональное потребление — это не более 1% финансового потока. Все остальное — средства производства сырье и ноу- хау.
Очевидно что развитие технологий будет увеличивать разницу между приростом капитала и тем что реально можно проесть.
Точно так же очевидно что доля в управлении будет стекаться к тем кто делает в оном управлении меньше ошибок.
и это грозит новым кризисомА кризисы они происходят в результате того, что концентрация капитала превосходит те пределы для которых существуют эффективные способы управления. И никакого решения этой проблемы не существует. К примеру СССР сгубил точно точно такой же кризис, только отсроченный лет на 30. А как известно из того же Маркса чем отсроченней кризис тем он сильнее — больше ошибок накостылили.
Решение же проблемы кризисов в принципе может существовать ни разу не в экономической и даже не в политической плоскости. Для этого достаточно банально снижения себестоимости до нуля — т.е. технология самовоспроизводящихся самообслуживающихся средств производства и как результат полное изжитие рабочих специальностей.
А основными направлениями сферы обслуживания есть таки образование, медицина, транспорт, обслуживание инженерных коммуникаций жилья и т.п.
Как-то у вас слишком однобоко) И гарсоны и официанты и риелторы и автомеханики тоже входят в эту категорию, и я подозреваю их сильно больше чем врачей и т.д. Ну и потом это все равно не высококвалифицированный труд в вашем понимании, там можно не получать образование, максимум колледж и жить лучше Васи с РФ с двумя высшими
финансовый оборот вертится в обратную сторону
Вы верно описали процесс — капиталист копит деньги на завод, завод дает прибыли, он строит за эти прибыли новый завод. Вот только это все увеличивает прибыль капиталиста, и остальному населению не перепадают жалкие крохи, отсюда и возникает такая колоссальная разница доходов.
Тока доходы багатых — это прирост доли контроля в управлении капиталом, а не той доли которую персонально спустит в унитаз
Богатые могут делать со своей долей что угодно в том числе продать акции и спустить в унитаз. Факт того что весь мировой капитал находится в паре рук не перестает быть более радостным для народных масс, им от этого ничего не перепадает.
То есть вы считаете что сантехник во вьетнаме делает более технологичную работу чем мой родственник с красным дипломом по физикеНу вы спросите у вашего родственника как просчитать динамические эффекты перепада давлений в системе труб так, чтоб исключить выбросы содержимого. От тут образ вечно пьяного совдепоского сантехника моментом испарится. Один знакомый сантехник когда задался вопросом почему у него такой то этаж бытовки заливает постоянно, в процессе поисков метода гарантированного решения и институт с красным дипломом закончил и диссертацию написал и т.д.
Ну и опять же результирующий экономический выхлоп. Если ваш знакомый еще и на оборонку работает — то это с экономической точки зрения чистый убыток а не выхлоп, в отличии от работы сантехника.
Вы правы что сантехники это сложная работа и пример некорректен, но можно сравнить моего одного родственника с родственницей которая работала клерком в отеле в италии — 700 евро против 20к рублей
Касательно СНГ это не к капитализу вопросы а к верным ленинцам, которые здесь путем смены государственной религии законсервировали махровый феодализм на весь 20-ый век. И к тем которые черти как производство развивали что пока оно полностью не обанкротится и не построится по уму по новой толку не будет. И к тем комсоргам которые нонче буржуинами заделались. И к мохровому совку который не умер а чуток усох, особенно в реалиях крупных госпредприятий. И особенно к самому дедушке Ленину, по которому ИТР — издержки производства, и работать должны из под палки за доширак.
миграция в города огромная и в Китае уже почти закончилась поэтому можно говорить что большая их часть вовлечена в производствоПреимущественно в неквалифицированный труд по закручиванию шурупов в доширак и упаковку айфонов в тарельки.
Если в течении нескольких следующих лет эту работу на роботов переложат, причем в штатах, опять типа буржуи будут виноваты что их без работы оставили? А именно в этом суть закручивания гаек Трампом — технологии соответствующие давно созрели и гораздо дешевле ручного труда, но их внедрение требует больших единовременных капиталовложений, в отличии от размазывания затрат по оборотным средствам с которых весь Китай и кормится.
Да и вообше повторюсь — бедные 80-90% населения ПЛАНЕТЫ.Кто им виноват что их предки 2000 тысячи лет груши и прочие пальмы хвостом околачивали, пока Европа и Америка технологии развивали?
То есть по вашему это норма вообще?
Капитализм тут при чем если у этих 80-90% еще до сих пор дремучий феодализм с государственной религией и прочими имперскими замашками, местами слегка подстроенный под реалии мало-мало
Причем тут вообще технологии? Рабы продаются за деньги, за которые можно купить еду, одежду, квартиру.
При том что нельзя купить/потребить то что не произведено. А именно более производительные технологии позволяют произвести больше оных еды, одежды, квартир, и т.д. чтобы их было достаточно.
Любое производство имеет своей конечной целью потребление иначе оно хереет. (с) И.В.Сталин.
Причем не важно при каком строе. Все что
производится — это или продукты потребления или средства их производства или средства производства средств производства. И вся инженерная и научная деятельность тоже в конечном итоге направленна именно на это.Чем оно все производительней тем в результате выше уровень жизни — т.е. насыщенность населения продуктами потребления.
Если в течении нескольких следующих лет эту работу на роботов переложат, причем в штатах, опять типа буржуи будут виноваты что их без работы оставили?
Эту работу не переложат на роботов потому что вы не понимаете что в Китае занимаются отнюдь не низковалифицированной работой, учитывая что большая часть населения тех же США — просто обслуживающий персонал то дважды не низковалифицированной.
Кто им виноват что их предки 2000 тысячи лет груши и прочие пальмы хвостом околачивали, пока Европа и Америка технологии развивали?
Америки не существовало даже триста лет назад, а Европа до ренесанса была сборищем быдла по сравнению с великолепными и прогрессивными царствами китая и востока. Большая часть богатства Европы и США — отобранное силой у других народов
А именно более производительные технологии позволяют произвести больше оных еды, одежды, квартир, и т.д. чтобы их было достаточно.
Да хоть сколько угодно производите, кто их будет покупать если денег нету у рабов?
Америки не существовало даже триста лет назад, а Европа до ренесанса была сборищем быдла по сравнению с великолепными и прогрессивными царствами китая и востока.Тока вот кадры для создания Америки таки Европа дала.Да и оборудования с Европы навезли по началу. А то думаете откуда там в конце 17-го века промышленность взялась когда в России и царствах востока на нее еще и намека не было?
Ну а насчет утери античных знаний не сходится приход с расходом от слова совсем. Ну никак дремучесть не стыкуется с архитектурой замков, формой доспехов, и неожиданно червячными передачами вместо ухвата в каждой распоследней халупе. Да образованых было не так уж и много. Но как бе кляти буржуи безграмотность таки искоренили введя всеобщее образование за счет местных налогов еще в 17-ом веке. В отличии от оных примитивны царств в которых до середины 20-го века основной технологией оставалось мотыжное земледелие.
Да хоть сколько угодно производите, кто их будет покупать если денег нету у рабов?
Вы сути закон спроса и предложения похоже так и не поняли. Пока чего то мало пока оно и дорогое. Стало достаточно и цена доступная. Все очень просто. рабочей скотине нужен хлев чтобы она не подохла. Какой они сами себе построят — хозяину сугубо фиолетово в принципе. Поэтому какие технологии доступны такого качества и сарайчики будут и такого размеру на душ. Все в конечном итоге сводится к тому сколько человеко-часов требуется для производства того или иного продукта. Причем независимо от социального строя.
Большая часть богатства Европы и США — отобранное силой у других народовВы часом Европу и США с Россией не перепутали?
учитывая что большая часть населения тех же США — просто обслуживающий персонал то дважды не низковалифицированной.
www.bls.gov/cps/cpsaat18b.htm
Еще раз для особо одаренных — все образование, медицина, формакология и даже полиция и детективы — это СФЕРА УСЛУГ. Точно так же как и индивидуальный пошив однежды, производство мебели по индивидуальному проекту и т.д. и т.п.
в Китае занимаются отнюдь не низковалифицированной работойВ основной массе — не сложнее чем закрутить шуруп. Выполнение более сложных операций одним работником для конвейера неприемлемо медленно.
Пока чего то мало пока оно и дорогое. Стало достаточно и цена доступная.
Вот именно, поэтому можно искусственно делать ограниченные серии как делает Apple или держать монополии которые диктуют цены. Почитайте про экономику чтоле, например про индекс Хиршнера, много нового узнаете
Вы часом Европу и США с Россией не перепутали?
Не перепутали. Все страны Европы в том числе и Россия замараны в геноциде и обворовывании других народов. США — это геноцид индейцев почти подчистую, рабство негров и индейцев. Великобритания — рабство и колонии по всему миру: Африка, Индия, Океания, частично Китай на протяжении веков. Испания, Франция, Бельгия, Нидерланды, Россия и т.д. — почти все страны были замараны в этом за исключением Германии, Австрии и Италии, которые начали Первую Мировую войну как раз из-за того что им не достались колонии и надо было переделывать сферы влияния.
То что 90% мира живет в говне — это не нормально, более того, этот средний класс и есть причина.
Нет. Капитализм тут не причём. Капитализму очень даже выгодно, чтобы миллиард голодающих стал бы средним классом и тратил на товары не 30 баксов в месяц, а 1000. Причины того, что люди живут в говне, всякие-разные. От национального менталитета до собственной лени. Жадность капиталистов в этом списке на двадцать пятом месте между «не повезло» и «родился в семье алкоголика и не видел другой жизни».
Боюсь вы слишком промыты чтобы вам что-то доказывать :(
Дело в том что чтобы тратить на товары 1000 баксов эти товары должен кто-то продать за 100 баксов чтобы капиталист поимел с этого сверхприбыли. Я понимаю если бы золотой миллиард был самодостаточен — сам бы производил и потреблял, но почему-то так получается что выгоднее когда тебе качают нефть одни рабы, собирают товары на заводах другие, и при этом рады что это позволяет протянуть им еще один день.
А вообще капитал очень сильно зависит от того куда инвестируют деньги, каким бы ты неленивым и менталитетным ты ни был, то на твой бизнес с меньшей вероятностью дадут инвестиции если ты из плохой страны, а без денег ты в принципе не сможешь сделать бизнес если это не лавка за углом. Это кстати еще один из фильтров для бизнесов третьих стран
Ну и если бизнес даже стал успешен в своей стране, на международном рынке ему будет во много раз тяжелее, ибо финансовый перевес не на твоей стороне
Дело в том что чтобы тратить на товары 1000 баксов эти товары должен кто-то продать за 100 баксов чтобы капиталист поимел с этого сверхприбыли. Я понимаю если бы золотой миллиард был самодостаточен — сам бы производил и потреблял, но почему-то так получается что выгоднее когда тебе качают нефть одни рабы, собирают товары на заводах другие, и при этом рады что это позволяет протянуть им еще один день.
А вообще капитал очень сильно зависит от того куда инвестируют деньги, каким бы ты неленивым и менталитетным ты ни был, то на твой бизнес с меньшей вероятностью дадут инвестиции если ты из плохой страны, а без денег ты в принципе не сможешь сделать бизнес если это не лавка за углом. Это кстати еще один из фильтров для бизнесов третьих стран
Ну и если бизнес даже стал успешен в своей стране, на международном рынке ему будет во много раз тяжелее, ибо финансовый перевес не на твоей стороне
Боюсь вы слишком промыты чтобы вам что-то доказывать :(
Зря вы начинаете с подобных заявлений. Просто чтобы мне доказать, нужны доказательства или хотя бы здравые логические рассуждения, а не безосновательные обвинения. Например,
продать за 100 баксов чтобы капиталист поимел с этого сверхприбыли
вообще и близко к здравому смыслу не лежит. Сверхприбыли в капиталистическом мире бывают, но достаточно редко и длятся недолго. Капиталист имеет не 900 прибыли баксов с 1000 проданных, а 100. Или даже 50. И это считается вполне себе неплохим доходом.
Я понимаю если бы золотой миллиард был самодостаточен — сам бы производил и потреблял
Золотой миллиард вполне себе самодостаточен. Глобализация позволила удешевить производство за счет стран третьего мира, но и без этого он вполне себе прекрасно жил, когда одежда шилась не во Вьетнаме, а компьютеры производились не в Китае. Более того, именно благодаря тому, что капиталистам открылась дешёвая рабочая сила в странах третьего мира, эта самая рабочая сила стала жить не на тарелку риса в день по праздникам, а получила на порядки лучшие условия жизни и быстрыми темпами стала развиваться.
Вряд бедуины, которые за полвека с верблюдов пересели на Феррари, так уж расстроились, что капиталисты качают их нефть. Равно как и корейцы/вьетнамцы/китайцы тоже не грустят. Бедные и нищие как раз те, у кого капиталисты золотого миллиарда ничего не покупают.
Ну и если бизнес даже стал успешен в своей стране
Понимаете, проблема бедных стран в том, что у них нет никаких условий для бизнеса даже в своей стране. Для достойного уровня дохода совершенно не обязательно быть экспортёром, внутренних рынков в подавляющем большинстве случаев вполне себе будет достаточно. Но о каких внутренних рынках может идти речь в большинстве бедных стран, если там тебя просто прирежут, когда узнают, что у тебя денег под подушкой слишком много накопилось? Такие государства просто не обеспечивают базовые функции — безопасность, равные права и возможности для населения, образование, поддержку предпринимательства и т.д. И вот в этом главная проблема, а не в мифической руке капитализма. Вы сейчас описываете что-то вроде стереотипного сказочного образа 1920-х, такого жирного буржуина в котелке, с тростью и с сигарой, сидящего на мешках с долларами и золотом.
Золотой миллиард вполне себе самодостаточен.
Не то чтобы совсем. С голода он конечно сам по себе не помрёт, но поддерживать существующий на даный момент уровень жизни без стран третьего мира «золотой миллиард» пока ещё сам не в состоянии. И нужен приличный технологический скачок(причём не только в плане автоматизации) чтобы это стало возможно.
но поддерживать существующий на даный момент уровень жизни без стран третьего мира
Он это прекрасно делал почти всю вторую половину ХХ века, когда на заводах в Европе и США работали не беженцы из Сирии или эмигранты из Китая, а местные рабочие, при этом зарплаты им хватало на достойную жизнь, которая рабочим из стран третьего мира и не снилась. Если процесс повернуть вспять, без шоковой терапии, конечно, то экономики перестроятся обратно на этот режим, не сомневайтесь.
Ну так правильно. Если «повернуть этот процесс вспять» и полностью отказаться от стран третьего мира, то мы на мой взгляд и придём примерно к уровню жизни 70-80-х годов. Как минимум в «количественном плане» уж точно. Это как бы не смертельно и жить вполне себе можно, но потребление всем придётся заметно сократить.
Если «повернуть этот процесс вспять» и полностью отказаться от стран третьего мира, то мы на мой взгляд и придём примерно к уровню жизни 70-80-х годов.
Если повернуть процесс в спять то для развитых стран это выльется разве что в ускорение вытеснения неквалифицированного труда робототехникой.
А то что будет в бедных странах описывается литералом 3.1415здец.
Вообще, для поддержания полного стека современных технологий нужна экономическая агломерация примерно 250 миллионов человек вооруженных современными средствами производства. И у пресловутого золотого миллиарда есть овердостаточно в этом плане чтобы их не только поддерживать но и развивать. У отсталых же стран этого нет вне зависимости от численности, даже если они смогут как то наладить взаимодействие. Т.е. суть — золотой миллиард способен обеспечить себя высокопроизводительными средствами производства (и не только себя как видим), а значит и всем остальным. Отставшие в развитии страны нет. В этом плане они зависимы от золотого миллиарда.
На данный момент робототехника ещё даже близко не на том уровне чтобы обойтись без стран третьего мира. И не только робототехника.
И когда мы этот уровень достигне это вопрос открытый. На данный момент даже нет 100% гарантии что мы его в принципе достигнем. Хотя вероятность достаточно высока.
И когда мы этот уровень достигне это вопрос открытый. На данный момент даже нет 100% гарантии что мы его в принципе достигнем. Хотя вероятность достаточно высока.
На данный момент робототехника ещё даже близко не на том уровне чтобы обойтись без стран третьего мира.
Ну при этом не забывайте что к примеру шурупы в айфоны закручивать придется тоже тока на США а не на весь мир. И одежды шить на миллиард оборудования для ее пошива потребуется в 7 раз меньше чем если со странами третьего мира. Суть то в чем — получают оборудование за это обшивают и тех кто оборудование дал и себя. А соответственно в количественном плане в вопросе снабжения пострадают исключительно бедные страны, которые не способны обеспечить себя оборудованием. У развитых только возрастет скорость роста коэффициента автоматизации производства, хотя бы потому что при сокращении рынка оборудования экстенсивное количественное развитие будет невозможно, а соответственно будет более быстрое качественное развитие. А то думаете c какого перепугу Трамп бодаться с Китаем и прочими шуруповертами затеял?
И когда мы этот уровень достигне это вопрос открытыйНу вопрос же не в полной и 100% роботизации всего и вся стоит. А в том чтобы автоматизировать в достаточной мере, для того чтобы тех кто высвободится в результате прекращения производства оборудования для стран третьего мира и безработных было достаточно для сохранения того же объема производства продуктов потребления для себя. Это абсолютно достижимо уже давно. Вернее оно всегда было возможно. Вопрос только в том какое количество оных беженцев и т.д. придется отстреливать на границе в результате. Для них на тех же заводах и фермах какую то примитивную работу изобретают только потому, что если держать их на пособии, то их вовлеченность во всякого рода криминал будет 100%.
Ну при этом не забывайте что к примеру шурупы в айфоны закручивать придется тоже тока на США а не на весь мир. И одежды шить на миллиард оборудования для ее пошива потребуется в 7 раз меньше чем если со странами третьего мира.
Это я понимаю. Но даже учитывая это «золотой миллиард» свой нынешний уровень жизни сам держать пока ещё не может.
Ну вопрос же не в полной и 100% роботизации всего и вся стоит. А в том чтобы автоматизировать в достаточной мере, для того чтобы тех кто высвободится в результате прекращения производства оборудования для стран третьего мира и безработных было достаточно для сохранения того же объема производства продуктов потребления для себя. Это абсолютно достижимо уже давно.
Извините, но нет. Во всяком случае я как раз недавно смотрел передачу именно на эту тему и все эксперты придерживались именно этого мнения. То есть с голоду мы не умрём и голыми ходить не будем. Но и смартфоны каждые пару лет менять тоже не получится.
Капиталист имеет не 900 прибыли баксов с 1000 проданных, а 100. Или даже 50.
Это если капиталист занимается прибылью с заводов, а не махинациями с финансами, кредитами, акциями и т.д. Финансисты уже много лет как переиграли и стали богаче производственников, поэтому кстати и Трампа топят за попытки возвращения производства на родину
Золотой миллиард вполне себе самодостаточен.
А вот и нет. Посмотрите к чему привела обычная эпидемия Китая — сразу рухнули рынки, состояния богатейших людей сократилось на лярды долларов, МВФ орет что если так дальше продолжится то будет великая депрессия 2.0 и еще похуже.
Такие государства просто не обеспечивают базовые функции — безопасность, равные права и возможности для населения, образование, поддержку предпринимательства и т.д.Вы сейчас описываете что-то вроде стереотипного сказочного образа 1920-х, такого жирного буржуина в котелке
В капитализме-то и дело, что жирный буржуин в котелке с мешками золота, который не обеспечивает образование, безопасность и т.д. для всех кроме себя и своих мафиозных монополий — и есть классический капиталист, прям эталон. И в развитых странах они бы рады стать такими, но им не дают работающие институты госвласти, как например антимонопольное законодательство, готовый к протестам народ и социальные элементы для поддержки этого народа в тонусе
Это если капиталист занимается прибылью с заводов
Именно этим занимаются 99% капиталистов.
А вот и нет. Посмотрите к чему привела обычная эпидемия Китая — сразу рухнули рынки, состояния богатейших людей сократилось на лярды долларов
Эпидемия, так, к слову, отнюдь не обычная. И опять же таки, голода в Европе или США не наблюдается и не ожидается. Современный капитализм отнюдь не так сильно завязан на фондовые биржи, как сто лет назад.
но им не дают работающие институты госвласти, как например антимонопольное законодательство, готовый к протестам народ и социальные элементы для поддержки этого народа в тонусе
Именно так. И эти регулирующие механизмы, и государственные, и профсоюзные — это неотъемлемая часть современной капиталистической экономики, выработанная ей в процессе эволюции. Потому что так эффективнее. Понимаете? У капиталиста нет желания вас разорить и забрать ваши последние сто долларов. Наоборот, у него есть желание, чтобы вы были богатыми, жили долго и счастливо, и каждый месяц что-то у него покупали.
Именно этим занимаются 99% капиталистов.
Может 99% капиталистов этим и занимаются, вот только 99% всех денег принадлежат тому 1% что занимается финансовым сектором
И опять же таки, голода в Европе или США не наблюдается и не ожидается.
Это пока рынки не сильно рухнули. Если все придет в состояние великой депрессии или даже хуже — то там будет и не только голод
это неотъемлемая часть современной капиталистической экономики
Это не неотъемлемая часть капитализма, это то чего добились социалисты путем протестов и собственных жертв в 50-70е прошлого века в западных странах. Если бы они не раскачивали лодку то там было бы все также как и тут.
у него есть желание, чтобы вы были богатыми, жили долго и счастливо, и каждый месяц что-то у него покупали.
У капиталиста есть желание чтобы все мои деньги были у него и я работал на него за бесплатно, давая больше капитала. Ему абсолютно плевать на меня, особенно плохо если я деньги не трачу, а коплю у себя. Хотя если я коплю в банке то он итак может распоряжаться моими деньгами, считай все деньги это как «сервис» которым мне дают временно попользоваться без каких-либо гарантий и могут отнять когда угодно
Может 99% капиталистов этим и занимаются, вот только 99% всех денег принадлежат тому 1% что занимается финансовым сектором
Эммм, а почему вы так уверенно пишете то, что вы себе нафантазировали и даже не удосужились никак проверить, хотя информация в общем-то лежит на поверхности. Погуглите, например, «самые богатые люди планеты». Найдите среди них хотя бы одного финансиста.
Это пока рынки не сильно рухнули. Если все придет в состояние великой депрессии или даже хуже
Торговля ценными бумагами сейчас — это инвестирование в развитие, а не поддержание жизнедеятельности экономики. Её остановка в принципе не способна привести к великой депрессии.
Это не неотъемлемая часть капитализма, это то чего добились социалисты
Социалисты? Какие социалисты, минуточку, были в США? Или в Великобритании? Да или даже в Германии?
Ему абсолютно плевать на меня
Нет, вообще нет. Про теорию игр слышали? Максимальный выигрыш не там, когда все друг друга изничтожают, а там, когда когда выбирают взаимовыгодную стратегию игры. Вот поэтому капиталисты и придумывают всякие штуки вроде мотивации, премий, соцпакетов и так далее. Потому что сытый и довольный работник, минуточку, денег больше приносит, чем голодный и злой.
«Найдите среди них хотя бы одного финансиста.»
Уже на третьей строчке можно найти, и это по официальным данным. А по неофициальным данным просто погуглите банки которые печатают банкноты для МВФ, думаю станет все понятно
То есть в МВФ сидят дураки и паникуют зазря? Вы же в курсе что текущая экономика настолько разогналась, что без инвестиций в развитие она сразу же рухнет? Что если Америка не сможет выплачивать по долгам и объявит себя банкротом, напомните какой там госдолг сейчас?
«Или в Великобритании? Да или даже в Германии?»
Бывший президент франции Франсуа Олланд — председатель соцпартии, в скандинавии социал-демократические партии у руля уже много лет, Германия была вообще наполовину социалистической, в западной части были постоянные протесты, даже радикалы вроде RAF.
США и Великобритания не социалистические страны, все их богатство было нажито за счет истребления и рабства других народов.
Вы правы, по теории игр это работает только в том случае, если рынку есть куда расширяться. Если рынку становиться некуда расширяться все вырождается в монополию и игру с нулевой суммой, где один выигрывает, остальные проигрывают.
А вообще мне слили карму уже до того что я могу отвечать раз в час, поэтому если хотите продолжить дискуссию надо искать другую площадку)
Уже на третьей строчке можно найти, и это по официальным данным. А по неофициальным данным просто погуглите банки которые печатают банкноты для МВФ, думаю станет все понятно
Её остановка в принципе не способна привести к великой депрессии.
То есть в МВФ сидят дураки и паникуют зазря? Вы же в курсе что текущая экономика настолько разогналась, что без инвестиций в развитие она сразу же рухнет? Что если Америка не сможет выплачивать по долгам и объявит себя банкротом, напомните какой там госдолг сейчас?
«Или в Великобритании? Да или даже в Германии?»
Бывший президент франции Франсуа Олланд — председатель соцпартии, в скандинавии социал-демократические партии у руля уже много лет, Германия была вообще наполовину социалистической, в западной части были постоянные протесты, даже радикалы вроде RAF.
США и Великобритания не социалистические страны, все их богатство было нажито за счет истребления и рабства других народов.
Максимальный выигрыш не там, когда все друг друга изничтожают, а там, когда когда выбирают взаимовыгодную стратегию игры.
Вы правы, по теории игр это работает только в том случае, если рынку есть куда расширяться. Если рынку становиться некуда расширяться все вырождается в монополию и игру с нулевой суммой, где один выигрывает, остальные проигрывают.
А вообще мне слили карму уже до того что я могу отвечать раз в час, поэтому если хотите продолжить дискуссию надо искать другую площадку)
Уже на третьей строчке можно найти, и это по официальным данным.
Да, извиняюсь, про Баффета я забыл. Впрочем, найдите тогда хотя бы двух финансистов ;) Суть не меняется — это редкость.
То есть в МВФ сидят дураки и паникуют зазря? Вы же в курсе что текущая экономика настолько разогналась, что без инвестиций в развитие она сразу же рухнет
Нет, не в курсе. А с чего бы это? Некоторые инвестиционные фонды разорятся, но не они хлеб пекут и бензин производят.
Бывший президент франции Франсуа Олланд — председатель соцпартии, в скандинавии социал-демократические партии у руля уже много лет
Спасибо, но я не просил привести пример социалистов во Франции. Я просил привести пример социалистов Великобритании.
США и Великобритания не социалистические страны,
И при этом там прекрасно работают механизмы государственного регулирования экономики. О чём и была речь — это не заслуга социалистов, а естественное развитие капиталистического строя. Капитализм эволюционирует точно так же, как и любые другие институты общества. Более того, я могу достаточно уверенно утверждать, что достижения социалистов в Европе стали возможны лишь благодаря мощной финансовой основе, заложенной капитализмом, и сейчас они её активно подъедают. И если социальная ориентированность той же Франции не ослабнет в обозримом будущем, её экономика испытает жесточайший кризис.
поэтому если хотите продолжить дискуссию надо искать другую площадку)
Я не готов к слишком активной дискуссии :)
Впрочем, найдите тогда хотя бы двух финансистов ;) Суть не меняется — это редкость.
А потом попросите трех, четырех и тд?) Вы мне лучше ответьте — Рокфеллеры были самыми богатыми в США в прошлом веке, после разбиения монополии standart oil сказали что его состояние многократно увеличилось. Вопрос, куда это состояние подевалось и почему его нет в списках, а есть вылизанные безосы и цукеры?
Нет, не в курсе. А с чего бы это? Некоторые инвестиционные фонды разорятся, но не они хлеб пекут и бензин производят.
С того что сейчас все живут за счет долговых обязательств (США с ее госдолгом как главный пример). Если развитие вперед остановиться, то придется платить по долгам, а тк денег нет ибо все спланировано на развитие то все может рухнуть, вы это понимаете?
Спасибо, но я не просил привести пример социалистов во Франции. Я просил привести пример социалистов Великобритании.
А я где-то говорил что Великобритания относится к социалистическим странам? В первую очередь я говорил про Скандинавию, материковая Европа 50 на 50, где-то социалисты, где-то нет, но они много где встречаются в парламенте.
Вообще в Великобритании и США традиционно спектр смещен вправо, поэтому их левые — это либералы, которые во всем остальном мире были бы справа
О чём и была речь — это не заслуга социалистов, а естественное развитие капиталистического строя
Это заслуга капиталистов-либералов, которые увидели как СССР раскачивает лодку в некоторых странах и вынесли все производство в страны третьего мира чтобы низкий уровень жизни оставался там, позволив жить себе хорошо. Почитайте жалобы работников Амазон на нечеловеческие условия, если ВСЕ производство вернется в США то там станет очень плохо в социальном плане
Вопрос, куда это состояние подевалось
Вы серьёзно? Вот так вот серьёзно намекаете на существование некоего подпольного суперкапитала, который круче безосов/биллгейтсов?
Что вы там про промывку мозгов ранее писали?
На вопрос, куда подевалось, могу только попросить открыть поширше глаза и заметить слона. Слон крупный, примерно треть триллиона долларов стоит, ни от кого не прячется.
С того что сейчас все живут за счет долговых обязательств
Все — это кто конкретно?
а тк денег нет ибо все спланировано на развитие то все может рухнуть, вы это понимаете?
Нет, не понимаю. Почему должно рухнуть? Кредиторы всегда реструктуризируют долги в подобных случаях, откладывая платежи на будущее. Это совершенно обычная ситуация в мире.
А я где-то говорил что Великобритания относится к социалистическим странам?
Вы говорили, что регулирование бизнеса — заслуги социалистов. Я привёл в пример страны, где социалистов у власти нет, и все эти механизмы прекрасно работают => социалисты не причём.
Почитайте жалобы работников Амазон на нечеловеческие условия
Амазон — не единственная компания в США. Вы про условия работы строителей БАМа в СССР почитайте.
В первую очередь я говорил про Скандинавию, материковая Европа 50 на 50, где-то социалисты, где-то нет, но они много где встречаются в парламенте.
Какие социалисты? СД-ки — это партия буржуазного толка, которая льет воду на мельницу крупного капитала. Там весь сыр-бор в том, что буржуям которые могут так или иначе уйти от уплаты налогов очень выгодно переложить часть социальной ответственности на государство — т.е. обеспечение своих работников иметь за счет налогов которые платят другие.
Это заслуга капиталистов-либераловВообще то либерализм — это как раз таки абсолютное невмешательство государства в дела бизнеса.
Почитайте жалобы работников Амазон на нечеловеческие условия, если ВСЕ производство вернется в США то там станет очень плохо в социальном планеОни давно жалуются на то что их заменяют роботами. Опять же кто на что учился. Суть капитализма на сегодняшний день в изжитии неквалифицированного труда. А для этого нужен профессионально образованный пролетариат. От так те кто не хотел образовываться и изживаются путем экономического стимула. И у них это получается в отличии от СССР, в котором в этом плане был антистимул, а заставить качественно учится как известно невозможно даже под угрозой растрела…
Вы серьёзно? Вот так вот серьёзно намекаете на существование некоего подпольного суперкапитала, который круче безосов/биллгейтсов?Просто любая технология управления обеспечивает эффективность до какого то определенного размера концентрации капитала. Дальше она перестает эфеективно работать и капитал растекается по более меньшим конторкам.
При этом поскольку сама технология в общем то открыта, то занять доминирующее положение в стране ни одна контора/клан не в состоянии. На чем собственно гря и держится главенство закона, а не вертикали власти, в развитых капстранах.
Это как бы интересная идея, но не думаю что это так. По крайней мере если взять ту же Швецию, то там этого пожалуй нет. И в Швеции это легко проверяется так как доходы и налоги абсолютно открыты и любой может эту информацию свободно просмотреть. Ну и как бы в отношении других скандинавcких стран я тоже не думаю что ваша теория верна.
И в Швеции это легко проверяется так как доходы и налоги абсолютно открыты и любой может эту информацию свободно просмотреть.Хоть в Швеции хоть где угодно существуют легальные способы минимизации налогов. Т.е. вынос регистрации в оффшор, транснациональная корпорация, и т.д. и т.п. А перекладывается все это на плечи более мелких конотр/занимающихся другим видом деятельности, которые не могут действовать подобным образом.
Если человек зарабатывает относительно много денег и при этом платит относительно мало налогов, то в странах вроде Швеции это приводит к возникновению вопросов со стороны отдельных людей и общественных организаций. И даже если выясняется что такое легально благодаря каким-то «дыркам» в законах, то такие дырки относительно быстро закрываются.
То есть все эти полулегальные «игры» с налогами хорошо работают пока о них мало кто знает. Или точнее пока это всё сложно проконтролировать. То есть в странах вроде Германии-Швейцарии-Франции-Великобритании это относительно большая проблема. У скандинавов скорее нет.
То есть все эти полулегальные «игры» с налогами хорошо работают пока о них мало кто знает. Или точнее пока это всё сложно проконтролировать. То есть в странах вроде Германии-Швейцарии-Франции-Великобритании это относительно большая проблема. У скандинавов скорее нет.
Боюсь вы слишком промыты чтобы вам что-то доказывать :(
Да то вам в компартии моски промыли сказочкой про злую аморальную капитализьму и добрую православную социализьму с ее
А на самом деле разница между капитализмом и социализмом только в том, что при капитализме размер управленческой ошибки ограничен размером капитала, контролируемым совершившим ее буржуем. При социализме же размер оной ошибки ограничен исключительно некомпетентностью ответственных товарищей, для которых единственной важной наукой есть Марксизм-Ленинизм.
Инвестируют в те страны в которых есть политическая стабильность. Никто не будет инвестировать туда, где нет политической стабильности и право собственности не гарантировано. А особенно это касается отставших в развитии стран, потому что инвестировать нужно в первую очередь в образование и инфраструктуру, что начнет давать возврат инвестиций не раньше чем лет через 20 да и то, только при условии последующих инвестиций непосредственно уже в промышленность.
К примеру Бангладеш стабильность есть — в нее инвестиции текут рекой.
В n-ой стране СНГ стабильности нет — в нее никто инвестировать не будет, ни иностранцы, ни свои, хотя инфраструктура и уровень образования куда повыше чем в Бангладеш.
Да то вам в компартии моски промыли сказочкой про злую аморальную капитализьму и добрую православную социализьму
Я не состою ни в каких партиях, а злой аморальный капитализм я вижу каждый день потому что я в нем живу.
размер управленческой ошибки ограничен размером капитала, контролируемым совершившим ее буржуем.
Вы абсолютно правы. Вот только при капитализме буржуй всегда увеличивает свой капитал пока не становится монополией, и в итоге его управленческая ошибка также влияет на все население страны.
Инвестируют в те страны в которых есть политическая стабильность. Никто не будет инвестировать туда, где нет политической стабильности и право собственности не гарантировано.
Вы не находите что это замкнутый круг? Нет инвестиций — нет денег — нет стабильности- нет инвестиций. Ну и даже с инвестициями Бангладеш такой же бедный как и индия и китай — а это большая часть населения Земли
Вы не находите что это замкнутый круг?Ну и кто им виноват, что их так и тянет устроить с соседями войнушку по поводу того кто из них самый-самый собиратель земель нищебродских или чей аллах круче? Вспомните к примеру к чему привела советская помощь Сомали.
Ну и даже с инвестициями Бангладеш такой же бедный как и индия и китай — а это большая часть населения ЗемлиНу и кто им этом виноват? А вы считаете что меньшая технологически развитая часть населения земли вот так прям обязана всем и сразу обеспечить этих бедных и при этом абсолютно на халяву и без малейших телодвижений в этом направлении со стороны оных дикарей? Так не получится. Вспомните чем и почему закончилась операция ООН по оказанию гуманитарной помощи Сомали в связи с гуманитарной катастрофой, возникшей в результате нецелевого использования советской помощи. Там же где где стабильность есть начинают с образования и инфраструктуры — те реально те кто смогут хотя бы как то юзать технологии там появятся лет через 20 после начала инвестиций.
а злой аморальный капитализм я вижу каждый день потому что я в нем живуОшибаетесь. Вы живете в монархическом феодализме. Другого социального строя в России никогда не было.
Вот только при капитализме буржуй всегда увеличивает свой капитал пока не становится монополиейРазваливаться она начинает куда раньше чем это сможет привести к краху страны. При этом при социализме абсолютно все монополия по определению и его дни всегда сочтены. Кстати еще 1918-ом году американские экономисты оценили время жизни совдепии в 150 максимум 200 лет. Ошиблись в 2 раза. Причина — не могли просчитать что во 2-3-ем поколении произойдет полная остановка развития, с последующей деградацией на протяжении как минимум 2-3 поколений, связанная в первую очередь с наличием экономического антистимула к получению более высокого уровня образования.
Т.е. какой бы капитализм несовершенный не был, но до получения технологии самовоспроизводящихся самообслуживающихся средств производства и падения в результате себестоимости всего до нуля, разумной альтернативы ему нет и не будет.
Ну и кто им этом виноват?
Дело не в том что кто-то виноват, дело в том что за счет них богатеют другие и это неправильно
Вы живете в монархическом феодализме. Другого социального строя в России никогда не было.
Что? Монархический феодализм подразумевает собой монархию — передачу власти по наследству (этого нет) и феодализм — где каждый лендлорд сам себе царь и бог (этого нет тк жесткая вертикаль власти). Так что это типичный мафиозный капитализм, когда всем заправляют братки
Разваливаться она начинает куда раньше чем это сможет привести к краху страны.
С чего бы ей разваливаться если все от нее зависят? Это скорее все вокруг разваляться, а она переведет активы в другие страны, лол.
При этом при социализме абсолютно все монополия по определению и его дни всегда сочтены
Где вы видите монополии в Финляндии, Швеции, Норвегии? Да и вообще во многих странах Европы значительную часть парламенты составляют социал-демократы, из-за них вводят социалочку и прогрессивную шкалу, а также регулируют рынок разбивая монополии.
Монархический феодализм подразумевает собой монархию — передачу власти по наследству
Монархический подразумевает под собой в первую очередь самодержавную пожизненную(ну или пока не надоест) власть. При этом когда наследника нет выбирает власть учредительное собрание (бояре) или скажите этого нет?.. При этом когда наследника нет выбирает власть учредительное собрание (бояре) или скажите этого нет?
Где вы видите монополии в Финляндии, Швеции, Норвегии?
А где вы видели социализм в Финляндии, Швеции или Норвегии? При социализме частной собственности нет — т.е. все средства производства и все жилье находится в общественной собственности, которой управляет государство — т.е. абсолютная монополия, при этом монополия государства на найм наемных работников закреплена конституционно.
Так что в Скандинавии самый обычный постиндустриальный капитализм. А социализм — это то что на Кубе и в Северной Корее. Китай и Въетнам от него уже отказались.
С чего бы ей разваливаться если все от нее зависят?Ну а с чего бы это вдруг к примеру Боинг разваливаться начал, хотя до монополии ему еще как пешком до Луны (он просто один из двух ключевых игроков на мировом рынке в своей нише)?
Монархический подразумевает под собой в первую очередь
Монархический подразумевает под собой в первую очередь передачу власти наследникам. Под самодержавную пожизненную власть подходит обычная диктатура.
ru.wikipedia.org/wiki/%D0%94%D0%B8%D0%BA%D1%82%D0%B0%D1%82%D1%83%D1%80%D0%B0
При социализме частной собственности нет
А вот тут вы не правы. Социализм не про частную собственность вообще, социализм про социальные блага населения и равномерное распределение дохода. Если обществу удастся придумать систему, в которой частная собственность сохранена но при этом все живут счастливо-богато и потребности каждого удовлетворены — ну и пожалуйста, социализм только рад этому, вернее это и будет социализм по своей сути.Вообще социалисты на западе в пику СССР уже давно отошли от концепции частной собственности, там было несколько разных концепций, одна из них кстати это культурный марксизм, где во всем винят не частную собственность, а белую семью
Ну а с чего бы это вдруг к примеру Боинг разваливаться начал
С чего вы взяли что он начала разваливаться? Живет и здравствует
Монархический подразумевает под собой в первую очередь передачу власти наследникам. Под самодержавную пожизненную власть подходит обычная диктатура.
И шо вы думаете найти что то реально соответсвующее действительности в этой вики-мурзилке? Хотя если читать вдумчиво то таки до действительности можно добраться. Для начала — для того чтобы власть передавать она должна быть и быть пожизненной. К примеру королеве Англии передавать нечего окромя чуства собственного достоинства. При этом по наследству — это далеко не обязательно родственникам. А к примеру еще и выбранному самодержцем приемнику, как это сделал в свое время Ельцын. И именно такой способ передачи Петр I законодательно закрепил выше степени родства и решений учредительного собрания.
А вот тут вы не правы.Эт вы не правы. Социализм — это начальная стадия коммунизма. А соответсвенно это именно про запрет частной собственности, политбюраторов, и прочих врагов народа.
А про высокий уровень жизни — это таки уровень развития промышленности и технологий. Потому что че там не декларируй, но либо есть достаточные производственные мощности и достаточная производительность труда, чтобы произвести все необходимое, либо страна тотального дифицита.
А то что в Скандинавии «социализмом» называют по совсем другой причине — они давно достигли и предостигли тот уровень обеспечения, который некоторый дедушка, который живее всех живых, объявил недостижимым для капитализма (т.е. без ликвидации частной собственности). Это ироническое название.
При социализме частной собственности нет — т.е. все средства производства и все жилье находится в общественной собственности
С каких это пор? При социализме частная собственность совсем не исключена. Даже в случае со средствами производства и уж тем более в случае с жильём.
Просто всё это должно в той или иной мере контролироваться государством и/или обществом.
Вы по моему социализм с коммунизмом спутали.
Социализм — это начальная стадия коммунизма.
А соответсвенно это именно про запрет частной собственности, политбюраторов, и прочих врагов народа.
Это так считали отдельные исторические личности. Но история нам в общем-то показала насколько и теории оказались реализуемы.
С каких это пор? При социализме частная собственность совсем не исключена
Она не исключена на начальном этапе построения социализма. Крупная буржуазия уничтожается сразу. Но мелкая — т.е. самонаемные работники, которые одновременно и буржуи и трудящиеся, постепенно коллективизируются.
Кооперативное жилье в том же СССР — не более чем признание госмонополией своей неспособности по выполнению взятых на себя социальных обязанностей. При этом не стоит путать личную собственность с частной. Сдавать жилье в аренду в СССР было нельзя. Либо проживаешь в нем сам либо продавай. Так же как и количество в котором его можно было купить ограничивалось нормами.
То же что происходит в Китае и Въетнаме — это постепенный планомерный переход к капитализму. Точно так же СССР все время своего существования вводил рынок в час по капле. В результате он хлынул как из ведра.
Просто всё это должно в той или иной мере контролироваться государством и/или обществом.
Неотъемлимая часть права собственности — это распоряжение ей по своему усмотрению. Поэтому ни о каком контроле того, как буржуи используют принадлежащие им средства производства и т.д. со стороны кого бы то ни было быть не может.
Контролировать можно только использование своей собственности/
А государство — это не более чем аппарат насилия, предназначенный для защиты интересов господствующего класса. И их существует три типа — феодальное, в котором господствующим классом является сама вертикаль власти, концентрирующая в своих руках всю полноту законодательной исполнительной и судебной власти,
буржуазное, в котором буржуазия концентрирует в своих руках законадательную власть, а исполнительная и судебная работают сторго в рамках установленных законов, и социалистическое, в котором декларируется власть пролетариата, на самом же деле точно такая же феодальная вертикаль партии, власть которой закреплена конституционно.
К социальной же направленности приводит в любом случает только развитость промышленности и как результат конкуренция буржуев за квалифицированного работника, без которого его собственность не более чем металолом.
Т.е. если к примеру в коституции Украины декларируется социальная направленность государства, но промышленность не способна обеспечить производство всего необходимого, то маемо те що маемо.
Если в Норвегии промышленность способна обеспечить достаточную поизводительность для производства всего что надо, или таких объемов того что надо другим странам, для обмена на то что надо самим то социальная направленность будет без всяких деклараций.
Она не исключена на начальном этапе построения социализма. Крупная буржуазия уничтожается сразу. Но мелкая — т.е. самонаемные работники, которые одновременно и буржуи и трудящиеся, постепенно коллективизируются
Вы по моему используете исключительно советское определение этого самого социализма. И я бы не сказал что стоит следовать именно этому определению. Во всяком случае мало кто в мире это делает.
Неотемлимая часть права собственности — это распоряжение ей по своему усмотрению.
Если вы внимательно почитаете законы и конституции европейских стран, то вы увидите что именно в вопросах жилья и средств производства никакого «абсолютного» права собственности там обычно и нет. И в случае чего у государства есть механизмы, которые позволят ему эту вашу собственность у вас отобрать на абсолютно легальных основаниях.
Дело не в том что кто-то виноват, дело в том что за счет них богатеют другие и это неправильно
Объясните каким образом к примеру США — крупнейший экспортер продуктов питания, энергоносителей, оборудования, комплектующих и технологий может багатеть за счет мотыгокапателей которые себя продуктами питания в достаточной мере обеспечить не в состоянии?
Таким что при всём при этом импортирует США примерно в полтора раза больше чем экспортирует.
Больше получается в финансовом эквиваленте исключительно потому, что шурупозакручивали, импортирующие американские компоненты, накручивают накрутку от 2х раза на комплектующие, импортированные из США и потом продают их США уже с этой накруткой в составе собранных девайсов. Если же сборку перенести на территорию США то тот же Китай вообще по миру пойдет.
О да, конечно. Запчасти для айфонов у нас американцам продают с огромной накруткой, а США уже готовые айфоны продают по себестоимости :)
Если уж, то ситуация скорее даже наоборот выглядит. То есть это скорее США и остальной «золотой миллиард» диктуют странам третьего мира правила игры. И скорее именно они могут диктовать остальным по каким ценам что-то там покупается или продаётся.
А если серьёзно, то цены обычно диктует рынок. И если кто-то завышает цены, то обычно просто покупают у кого-то другого. Или по вашему страны третьего мира производят что-то такое уникальное без чего США не может обойтись и у чего нет альтернативных поставщиков?
Если уж, то ситуация скорее даже наоборот выглядит. То есть это скорее США и остальной «золотой миллиард» диктуют странам третьего мира правила игры. И скорее именно они могут диктовать остальным по каким ценам что-то там покупается или продаётся.
А если серьёзно, то цены обычно диктует рынок. И если кто-то завышает цены, то обычно просто покупают у кого-то другого. Или по вашему страны третьего мира производят что-то такое уникальное без чего США не может обойтись и у чего нет альтернативных поставщиков?
Дело не в том что кто-то виноват, дело в том что за счет них богатеют другие и это неправильно
Каков механизм этого "за счет них богатеют другие"?
Всё верно сказано. Вот только Agile тут ни при чем.
Или учительница, которая ваших детей в школе учит заявит на родительском собрании — «знаете я тут на дядю работаю, поэтому как он скажет так и делаю, на знания в головах ваших детей мне плевать, мне деньги за отчеты платят. С отчетами все ок? Значит претензии не ко мне, я все делаю по инструкции.
Кстати в реальном то мире так и работает. Если вам нужно качественное образование независимое от настроения учителя, вы его отдаете в дорогую/платную школу. Именно там и будут построены построены процессы, которые «гарантируют» это качество
Извините, но нет. В реальном мире вполне себе есть реальные люди, которые вполне себе нормально и ответственно работают даже если при этом они работают не в дорогих/платных учереждениях. И как минимум в моём понимании это нормально и этого можно и даже нужно ожидать.
В частном случае это может вообще один человек. Т.е. учитель работает на полставки в частной школе, и в государственной. Но в частной например у него 10 человек и есть возможность менять процесс под конкретного ученика, а в государственной 30 и все жестко зарегулированно. Вы получите совершенно разное качество от одного и того же человека, который работает совершенно одинаково. Т.е. выстроенные процессы на порядок ценнее для клиента чем конкретные личности
«В частном случае» у вас и в государственной школе могут быть классы на 10 учеников и/или возможность менять процесс под каждого ученика.
П.С. Да и вообще на мрй взгляд не стоит автоматом исходить из того что государственная школа в принципе не может быть хорошей и что частная обязательно ею будет. И уж тем более не стоит считать что так и должно быть и по другому просто быть не может.
П.С. Да и вообще на мрй взгляд не стоит автоматом исходить из того что государственная школа в принципе не может быть хорошей и что частная обязательно ею будет. И уж тем более не стоит считать что так и должно быть и по другому просто быть не может.
Ну и ладненько, пусть 30 человек. Учитель сделает, что возможно сделать с классом в 30 человек и пойдёт домой спать с чистой совестью. Я не понимаю другого, когда класс в 30 человек становится оправданием собственной лени. «Ну дядя тут все через жопу устроил поэтому и я буду кое-как работать».
Можно с «дядей» бороться или договариваться, можно сменить работу, можно тихо сидеть и делать все, что можно сделать в этих условиях. Но «работаю на дядю значит работаю кое-как» это позиция лузера, обреченного всю жизнь «кое-как» работать.
Мне непонятно откуда эта позиция берётся, да ещё в таком экстремальном виде? ...Ответил выше.
Или учительница, которая ваших детей в школе учит заявит на родительском собрании — «знаете я тут на дядю работаю, поэтому как он скажет так и делаю, на знания в головах ваших детей мне плевать, мне деньги за отчеты платят.
В целом, в 95 случаях из 100 современная школа именно про это.
Вы живете в иллюзиях, что на самом деле иначе?
Можно же просто строить «симметричные отношения». То есть как фирма относится к работникам, то примерно так же и работники могут относиться к фирме. И если фирма только платит зарплату, то тогда да мы получаем банальное «работаем на дядю».
А если фирма скажем меня регулярно посылает на курсы и/или сертификации которые интересны лично мне, то мне с такой фирмой уже и «немножко по пути».
А если фирма скажем меня регулярно посылает на курсы и/или сертификации которые интересны лично мне, то мне с такой фирмой уже и «немножко по пути».
Совершенно верно. Фирма в первую очередь должна об этом думать, делать первый шаг навстречу.
Иначе она рискует остаться лишь с теми, кто «работает на дядю». А от них прорывов ждать не приходится.
Можно же просто строить «симметричные отношения». То есть как фирма относится к работникам, то примерно так же и работники могут относиться к фирме. И если фирма только платит зарплату, то тогда да мы получаем банальное «работаем на дядю».Конечно! Не финансовые отношения тоже важны.
Просто там речь шла не про них, а про то, как если ваш босс говорит «вы все должны „переться“ от своей работы, поэтому я снижаю вам з/п и внедряю Эджайл» ))
Обычно "по пути" бывает с маленькими компаниями, тогда конечно можно влиять на процесс (и довести его до полного бардака).
ИМХО, ТС (и многие приверженцы) Agile — забывают, что это всего лишь инструмент. Причем, далеко не универсальный — подходит для определённого склада людей, для определённого типа задач и для (весьма) ограниченного типа корпоративной культуры. Поэтому, на мой взгляд, необходимо подбирать инструмент, подходящий для решения данной задач, в конкретной компании и с учётом характера конкретных людей в коллективе ("команда" — слишком абстрактна, внутри всегда есть противоречия и проблемы, если у вас команда из людей, а не из карточек).
Приведу пример — немного наивно рассчитывать изменить культуры "старой" компании с помощью Agile — сначала надо изменить культуру (или хотя бы сдвинуть в нужную сторону), тогда возникнет потребность в методике, для управления изменениями, а вот тогда может и Agile пригодится.
А по поводу мотивации наёмных работников — боюсь, очень скоро мы увидим очень много мотивированных программистов, ищущих новую работу в стабильных корпорациях, и на командный дух и творческую составляющую им будет наплевать — лишь бы з/п (весьма скромную, зато без задержек) вовремя переводили… Проходили мы это во времена краха дот.комов, 20 лет назад, причем почти в "сердце событий"… Когда сотни (или тысячи) стартапов закрываются — "программист" уже звучит не так гордо… И мотивация на след. рабочем месте не располагает к Scrum ))
>Если уровень осознанности сотрудника «я работаю на дядю»
… соответствует реальному положению вещей и он таки работает на дядю? Зачем использовать для обозначения этой стандартной и вполне рабочей бизнес-модели какие-то эвфемизмы?
>Если сотрудник дорос до идеи «мне с этой компанией попути так как сей час у нас общие цели и интересы»
А почему сотрудник должен до чего-то там дорастать, кроме как до определенных уровней своих профессиональных навыков? Это компания должна продемонстрировать сотруднику, что ему выгодно в ней работать и дальше — и это, кстати, единственная реальная общая цель и общий интерес сотрудника и компании: получение выгоды. Рыба ищет где глубже, а человек — где лучше. (Редко, конечно, может добавиться и другая общая цель, если сотруднику просто таки чертовски интересен некий проект, разрабатываемый компанией, но это — редко и, как правило, скорее характерно для стартапов с небольшим числом участников, где границы между владельцами и сотрудниками неочевидны.) В противном случае — это какое-то превращение компании в натуральную секту, с «миссией компании», «гордостью сотрудников» и тому подобной чушью, призванной промыть мозг юным и не очень идеалистам, чтобы они не слишком часто просили повысить им зарплату. А лучше — чтобы не просили вообще, но при этом светились от счастья и ощущения «сопричастности».
Так что нет. Просто давайте внятное ТЗ и платите приличную зарплату. Всё. Ой, сотрудник ничего не делал целую неделю? Ну, это определенно не проблемы сотрудника, ему просто не дали конкретного задания и он вынужден был бить баклуши, не понимая, какого чёрта он уже который день приходит на работу с утра — баклуши определенно комфортнее бить дома. Ой, он все же работал целую неделю, выполняя задание, но у вас не получилось приткнуть куда-то написанный сотрудником по вашему заданию код? Ну, это определенно не проблемы рядового сотрудника. Это ваши проблемы. Наймите нормальных руководителей проектов. Не получилось приткнуть к делу проект, который под руководством опытного сениора пилили дцать или даже целых сят человек полгода? Это определенно не проблемы сениора. Это ваши проблемы. Наймите нормальных менеджеров. И так далее, вплоть до — ищите адекватных клиентов, если уж на то пошло. Не пытайтесь свалить проблемы вашего бизнеса на сотрудников, играя с ними в «социалистическое соревнование» и «заинтересованность трудящихся». Не пудрите им мозги, просто платите зарплату. Ой, не получается платить зарплату, потому что вы не сумеливпарить продать клиенту продукт? Это не проблемы сотрудников. Это ваши проблемы — заплатить сотрудникам, чтобы они не подали на вас в суд. А потом сотрудники плюнут и просто найдут себе другого работодателя.
… соответствует реальному положению вещей и он таки работает на дядю? Зачем использовать для обозначения этой стандартной и вполне рабочей бизнес-модели какие-то эвфемизмы?
>Если сотрудник дорос до идеи «мне с этой компанией попути так как сей час у нас общие цели и интересы»
А почему сотрудник должен до чего-то там дорастать, кроме как до определенных уровней своих профессиональных навыков? Это компания должна продемонстрировать сотруднику, что ему выгодно в ней работать и дальше — и это, кстати, единственная реальная общая цель и общий интерес сотрудника и компании: получение выгоды. Рыба ищет где глубже, а человек — где лучше. (Редко, конечно, может добавиться и другая общая цель, если сотруднику просто таки чертовски интересен некий проект, разрабатываемый компанией, но это — редко и, как правило, скорее характерно для стартапов с небольшим числом участников, где границы между владельцами и сотрудниками неочевидны.) В противном случае — это какое-то превращение компании в натуральную секту, с «миссией компании», «гордостью сотрудников» и тому подобной чушью, призванной промыть мозг юным и не очень идеалистам, чтобы они не слишком часто просили повысить им зарплату. А лучше — чтобы не просили вообще, но при этом светились от счастья и ощущения «сопричастности».
Так что нет. Просто давайте внятное ТЗ и платите приличную зарплату. Всё. Ой, сотрудник ничего не делал целую неделю? Ну, это определенно не проблемы сотрудника, ему просто не дали конкретного задания и он вынужден был бить баклуши, не понимая, какого чёрта он уже который день приходит на работу с утра — баклуши определенно комфортнее бить дома. Ой, он все же работал целую неделю, выполняя задание, но у вас не получилось приткнуть куда-то написанный сотрудником по вашему заданию код? Ну, это определенно не проблемы рядового сотрудника. Это ваши проблемы. Наймите нормальных руководителей проектов. Не получилось приткнуть к делу проект, который под руководством опытного сениора пилили дцать или даже целых сят человек полгода? Это определенно не проблемы сениора. Это ваши проблемы. Наймите нормальных менеджеров. И так далее, вплоть до — ищите адекватных клиентов, если уж на то пошло. Не пытайтесь свалить проблемы вашего бизнеса на сотрудников, играя с ними в «социалистическое соревнование» и «заинтересованность трудящихся». Не пудрите им мозги, просто платите зарплату. Ой, не получается платить зарплату, потому что вы не сумели
Просто давайте внятное ТЗ и платите приличную зарплату. Всё. Ой, сотрудник ничего не делал целую неделю? Ну, это определенно не проблемы сотрудника, ему просто не дали конкретного задания и он вынужден был бить баклуши
Вообще-то нет. Все сотрудники разные. Кто-то бьет баклуши просто потому, что ему лень, или там осень наступила, настроение плохое. Кто-то сделал задачу значительно быстрее эстимейта и пинает балду, вместо того, чтобы об этом сказать.
Ой, он все же работал целую неделю, выполняя задание, но у вас не получилось приткнуть куда-то написанный сотрудником по вашему заданию код? Ну, это определенно не проблемы рядового сотрудника. Это ваши проблемы.
Тоже неверно. Это, конечно, мои проблемы. Но причиной их может быть что угодно — как плохое ТЗ с моей стороны, так и то, что я нанял рукожопа. И вот если произошёл второй кейс, то за мою проблему отдуваться будет как раз этот самый рядовой сотрудник.
Не пытайтесь свалить проблемы вашего бизнеса на сотрудников, играя с ними в «социалистическое соревнование» и «заинтересованность трудящихся»
А это ещё почему? Если сотрудника можно мотивировать делать что-то лучше, то с чего вдруг его бы не мотивировать? Вас мотивирует только зарплата? Ну а других мотивируют ещё и социальные плюшки, вендорские семинары с халявным кофе или дружеские посиделки на природе. Каждому своё.
>Вообще-то нет. Все сотрудники разные. Кто-то бьет баклуши просто потому, что ему лень
Вообще-то в контексте подразумевалось, что вырожденные и тривиальные случаи «сотрудник ленив и/или некомпетентен» не рассматриваются.
>(...) я нанял рукожопа. И вот если произошёл второй кейс, то за мою проблему отдуваться будет как раз этот самый рядовой сотрудник
Отчасти да, но — 1) См. предыдущий абзац 2) Совершенствуйте метод подбора квалифицированных сотрудников: Кэп подсказывает, что не стоит нанимать рукожопов.
>А это ещё почему?
Потому что плюшки — это приятное дополнение к зарплате. В этой фразе ключевым словом является «дополнение». Если же для некоего сотрудника определяющим фактором при выборе компании являютсяпопойки корпоративы с массовиками-затейниками евангелистами вендоров и халявная плошка риса бесплатный кофе — это значит, что такой сотрудник не выбрался эмоционально из детского возраста. А разводить лохов эксплуатировать детей — безнравственно.
Вообще-то в контексте подразумевалось, что вырожденные и тривиальные случаи «сотрудник ленив и/или некомпетентен» не рассматриваются.
>(...) я нанял рукожопа. И вот если произошёл второй кейс, то за мою проблему отдуваться будет как раз этот самый рядовой сотрудник
Отчасти да, но — 1) См. предыдущий абзац 2) Совершенствуйте метод подбора квалифицированных сотрудников: Кэп подсказывает, что не стоит нанимать рукожопов.
>А это ещё почему?
Потому что плюшки — это приятное дополнение к зарплате. В этой фразе ключевым словом является «дополнение». Если же для некоего сотрудника определяющим фактором при выборе компании являются
Если же для некоего сотрудника определяющим фактором при выборе компании являются попойки корпоративы с массовиками-затейниками евангелистами вендоров и халявная плошка риса бесплатный кофе — это значит, что такой сотрудник не выбрался эмоционально из детского возраста.
Это вы на основании чего такой вывод делаете? Что там для кого является определяющим фактором для выбора работы это как бы личное дело каждого. Если кому-то коллектив важнее чем зарплата, то почему бы и нет.
И если уж на то пошло, о выбирать работу исходя исключительно из размера зарплаты это как минимум на мой взгляд тоже не самый умный подход.
Вообще-то в контексте подразумевалось, что вырожденные и тривиальные случаи «сотрудник ленив и/или некомпетентен» не рассматриваются.
А почему «вырожденные»? Это совершено типовой кейс, ничуть не более редкий, нежели жадный работодатель.
Кэп подсказывает, что не стоит нанимать рукожопов.
Ну, да. Вот только не всегда это можно определить на собеседовании. Ну нет у человека кода, который он может продемонстрировать вам на собесе, говорит складно, матчасть вроде знает. Не скажу, что это такой уж частый кейс, когда к вам приходит специалист по прохождению собеседований и в то же время дятел по реальным профессиональным навыкам, но тоже когда-никогда случается.
Потому что плюшки — это приятное дополнение к зарплате. В этой фразе ключевым словом является «дополнение»
Скажите, вот в наше время с таким высоким спросом на ИТ-специалистов, что может заставить программиста работать в компании, где уровень зарплаты для него ниже рынка? Нежелание что-то менять в своей жизни, выходить из зоны комфорта? Ну так это не в работодателе проблема, уж точно. А если ему там и правда настолько нравятся условия работы, проект или совместные попойки, что он правда готов ради всего этого зарабатывать меньше, чем мог бы, ну так что тут плохого? Ведь действительно бабло — не краеугольный камень жизни, по крайней мере, если его в целом и так достаточно.
ты просто сказочный дол...б.
Просто давайте внятное ТЗ и платите приличную зарплату. Всё.
Палю лайфхак. Совсем не обязательный, но способ рабочий, зп увеличивает в разы. Если ТЗ дали невнятное, то можно его уточнить. Ещё лучше разобраться в проблемах клиентов, и любое невнятное ТЗ усилием мозга превращать во внятное. За пару лет такой деятельности существенно прокачается soft skills, появится понимание бизнеса, откуда в нем деньги и клиенты. Высокий риск роста зп и должности. Если нет, то можно уйти к конкурентам на позицию топ. менеджера (CEO, CTO) или его заместителя. Там такому кадру будут рады, у них гарантировано проблемы с людьми которые конкретно их бизнес знают.
>Если ТЗ дали невнятное
>лучше разобраться в проблемах клиентов, и любое невнятное ТЗ усилием мозга превращать во внятное
И это означает, что «прослойка» между руководством (или даже хозяевами) компании и сотрудниками нижнего звена не выполняет своей работы, раз у сотрудника нижнего звена есть только два варианта — уйти или начать прокачивать дополнительные скиллы (заниматься не своей работой) и готовиться к карьерному росту. Если сотрудник оказывается в положении «умри или возвысься» — это плохая, негодная компания, у которой стратегия выживания на рынке оказывается зависимой исключительно от амбициозности рядовых юнитов, вынужденных спасать компанию ради того, чтобы продержаться на работе ещё какое-то время.
>лучше разобраться в проблемах клиентов, и любое невнятное ТЗ усилием мозга превращать во внятное
И это означает, что «прослойка» между руководством (или даже хозяевами) компании и сотрудниками нижнего звена не выполняет своей работы, раз у сотрудника нижнего звена есть только два варианта — уйти или начать прокачивать дополнительные скиллы (заниматься не своей работой) и готовиться к карьерному росту. Если сотрудник оказывается в положении «умри или возвысься» — это плохая, негодная компания, у которой стратегия выживания на рынке оказывается зависимой исключительно от амбициозности рядовых юнитов, вынужденных спасать компанию ради того, чтобы продержаться на работе ещё какое-то время.
И это означает, что «прослойка» между руководством (или даже хозяевами) компании и сотрудниками нижнего звена не выполняет своей работы,
Подавляющее большинство ИТ-компаний в мире не обладают прослойками, имеющими достаточные технические скиллы для того, чтобы принести на блюдечке разработчику ТЗ, по которому у него не будет вопросов к заказчику. Да, менеджер может выступать в роли простого прокси — пересылать вопрос от разработчика к заказчику, и форвардить обратно ответ. Это ничем не отличается от того, что разработчик сам будет задавать эти вопросы нужным людям, ну кроме того, что ответы будут дольше идти.
И это не плохие компании, а самые обычные. Альтернатива этим компаниям — крупные конторы с мощным звеном менеджмента. И знаете, если вы хотите, чтобы к вам относились как к человеку, а не как к исполнительному девайсу по зарабатыванию денег, то лучше искать среди первой группы компаний.
Если сотрудник оказывается в положении «умри или возвысься»
Разбираться в предметной области, которую автоматизируешь — это не «умри или возвысься». Это естественный профессиональный рост разработчика. Программист, который не вникает в предметку, это все равно что автомеханик, который тщательно изучает как крутить гайки, но при этом не знает устройство автомобиля, и ничего не сможет сделать без няньки-начальника, который ему пальцем тыкает: вот тут открути, вот тут закрути, вот тут открути, вот тут закрути.
Понятное дело, что можно и остаться на этом уровне. Но вполне логично, что и рост зарплаты в общем-то тоже вам особо не светит, причём вполне заслуженно.
Да, менеджер может выступать в роли простого прокси — пересылать вопрос от разработчика к заказчику, и форвардить обратно ответ. Это ничем не отличается от того, что разработчик сам будет задавать эти вопросы нужным людям, ну кроме того, что ответы будут дольше идти
Это значит, что данный менеджер — "рукожоп", и плохо справляется со своей работой. Частое явление, к сожалению.
где границы между владельцами и сотрудниками неочевидны
обычно список владельцев можно увидеть в выписке из ЕГРЮЛ или его аналогов.
Так что разница очевидна практически всегда, за исключением откровенно семейного бизнеса.
Это именно то, что отличает отAgileенного человека от не отAgileенного ;)
«отAgileенный», это что-то вроде «воцерковленного» или просто с «Agile головного мозга»?
А потом адепты Agile еще обижаются, что их сравнивают с религиозными сектантами.
НАчнем с того, что agile — это адовый и очень дорогой костыль менеджмента, когда менеджеры не смогли придумать и составить техзадания. ОН в 5 раз неэффективней обычного ТЗ в начале, но по другому нельзя, когда заказчик сам не знает чего хочет.
Почему костыль? Если уж на то пошло, то менеджеры и не должны ТЗ составлять — это прямая обязанность инженеров и иных технических специалистов, техническое задание — технический документ
И эффективность аджайл стремится к бесконечности по отношению к "ТЗ в начале", если после конца продукт выкидываетсся, потому что не удовлетворяет новым требованиям.
А зачем тогда компания?
Потому что кто-то всё равно должен искать этих самых заказчиков и трясти с них деньги за сделанную работу. Кто-то должен заниматься организацией таких банальных вещей как помещение и инструменты для работы. Кто-то должен заниматься бухгалтерией. Кто-то в конце концов должен быть готов нести на себе финансовые риски.
Если ваша команда готова взять это всё (и ещё кучу других мелочей) на себя, то вам тогда компания действительно не нужна.
Классно, вот только как замотивировать того, кто с агил накушался и хочет обыкновенного водопада? А никак? Если агил не прекратит выкачивать разработчиков под нуль, так оно и будет.
как замотивировать того, кто [...] хочет?
Как-то странно звучит. Мотивация = желание/стремление. Он уже хочет, цель достигнута.
Замотивировать его предложением хорошего выходного пособия ;) Други люди вам нужны /сарказм
Это человек, работающий всегда строго за деньги и, если очень повезет, за интерес к проекту, но это бывает очень редко.
На самом деле очень легко.
Показать работающий agile и отвратительный водопад и все.
Я не очень понимаю, по какой причине водопад считается эталоном хорошего планирования. Видел много случаев, где водопад втупую тратил ресурсы, время, кучи переделок перед дедлайном, потому что спланировать все сразу не смогли.
Видел и плохой аджайл, где полистали пару книжек, назначили митинги, но на ретро все озвученные проблемы месяцами остаются на бумаге.
Видел и хороший аджайл, где за 2-4 спринта решаются вопросы организационного уровня.
Вопрос не в аджайле или ватерфолле. В основном это вопрос грамотного менеджера, который следит за работой менеджеров младшего звена, которые следят за работой тимлидов, вникают в проблемы и решают их, а не занимаются очковтирательством и метрикособирательством для начальства за менеджерские бонусы.
Слышал от друзей, у них на работе тоже Agile, только если ты не успеваешь в спринт сделать то, что запланировал на него, то тебя штрафуют.
Ещё слышал такое мнение, что невозможно по Agile работать всё время (ну как невозможно всё время спринт бежать), надо отдыхать периодически. Вот что на это скажете?
А отпуск вам на что?
Могу рассказать, как это работает у нас.
если ты не успеваешь в спринт сделать то, что запланировал на него, то тебя штрафуют.
Если кто-то не успевает сделать в спринт то, что запланировал, и в результате в релиз не попала какая-то важная фича, которую ждал заказчик, данный вопрос будет поднят на ретроспективе. Цель – понять, что в следующий раз мы могли бы сделать по-другому, чтобы успеть сделать важную фичу в срок.
Так как все важные фичи мы берем в работу в первую очередь (согласно приоритету), на практике мы редко не успеваем их сделать. Неважные фичи просто переносятся в следующий спринт, либо возвращаются в бэклог (по усмотрению PO).
В любом случае, не припомню, чтобы кого-то когда-то в связи с этим даже упрекнули. Ведь если искать виноватого, в следующий раз мы будем перестраховываться, ставить оценки выше, брать меньше, и в результате, приносить меньше пользы.
невозможно по Agile работать всё время (ну как невозможно всё время спринт бежать), надо отдыхать периодически
Это меня повеселило. В "водопаде" тоже наверное нельзя постоянно сплавляться :)
Если серьезно, то упоминание об этом есть прямо в Манифесте:
Инвесторы, разработчики и пользователи должны иметь возможность
поддерживать постоянный ритм бесконечно. Agile помогает наладить такой
устойчивый процесс разработки.
Это означает жесткое "нет" переработкам.
Скажу больше, так как мы работаем по SAFe (Scaled Agile Framework), то у нас каждая пятая итерация – это Innovation & Planning. Это означает, что команда сама решает, чем она будет заниматься. И это не бизнес-фичи. Обычно мы устраняем технический долг, автоматизируем рутинные процессы или рефакторим код.
Еще у нас в офисе есть, например, теннисные столы, настольные игры, книги. Для того, чтобы люди могли передохнуть, даже посреди рабочего дня. И я знаю, что такое есть во многих других компаниях, практикующих аджайл.
В конце концов, с чего бы я стал пропагандировать аджайл, если бы в нём было так хреново? Я не владелец бизнеса, я тимлид.
А вот как, по вашему мнению, получается, что Agile извращают и превращают его способом ещё больше выжать соков из людей? Может есть какие-то кейсы, клинические случаи?
офисе есть, например, теннисные столы
А, ну и ещё про Agile удалённо, есть чем из опыта поделиться?
А вот как, по вашему мнению, получается, что Agile извращают и превращают его способом ещё больше выжать соков из людей?
Это на мой взгляд скорее проблема культуры управления, а не аджайла как такового.
Комментарии к данной статье стали для меня откровением.
Ранее я сталкивался с извращением Agile с целью саботировать его внедрение. Менеджеры проектов, не видя своего места в Agile, тиражировали искаженные идеи.
Здесь я вижу, что многие компании вооружились Agile с целью мобилизовать разработчиков, возможно, не понимая, что перегибают палку. Дополнили Agile совершенно инородными практиками в виде штрафов и т.п. Как результат, видим всеобщее отвращение к тому, что должно было наоборот облегчить жизнь.
Справедливости ради, надо стказать, что далеко не все разработчики "обожглись" об Agile. У нас в компании я не слышал подобных настроений.
про Agile удалённо, есть чем из опыта поделиться?
У нас есть удаленные сторудники. Они сидят в офисах, но не в Москве.
Agile удалённо – это трудно. Намного труднее, чем face-to-face. Но помогают такие практики как видео-мосты и, что действительно важно, надо хотя бы иногда (особенно при старте) видеться вживую.
Забавно, слышать, что для Agile строятся планы по внедрению чего-то.
Видимо наш клиент, который решил разработать для себя некую систему и вплести в неё нашу систему, как-то не так понимает этот Agile. Устраивает встречи с болтовнёй иногда на несколько часов, рассказывает, что они хотят увидеть от нас к такой-то дате (Agile или всё таки Waterfall). А потом, когда сроки подходят, начинаю орать «а-а-а-а-а, всё пропало, половину того, что сделано, надо выкинуть и сделать совершенно другое и вообще мы делали не то, что они запланировали». А когда им показываешь бумагу с итогами встречи, то говорят, чтоб мы эту бумагу запихнули куда подальше, а у них Agile.
Видимо мы что-то не понимаем в Agile, либо клиент и у них в головах вместо Agile бардак.
Видимо наш клиент, который решил разработать для себя некую систему и вплести в неё нашу систему, как-то не так понимает этот Agile. Устраивает встречи с болтовнёй иногда на несколько часов, рассказывает, что они хотят увидеть от нас к такой-то дате (Agile или всё таки Waterfall). А потом, когда сроки подходят, начинаю орать «а-а-а-а-а, всё пропало, половину того, что сделано, надо выкинуть и сделать совершенно другое и вообще мы делали не то, что они запланировали». А когда им показываешь бумагу с итогами встречи, то говорят, чтоб мы эту бумагу запихнули куда подальше, а у них Agile.
Видимо мы что-то не понимаем в Agile, либо клиент и у них в головах вместо Agile бардак.
Вы можете пригласить внешнего модератора на такие встречи.
Как-то он там хитро назывался в терминах Agile.
Даже в нашей компании есть специально обученный модератор, но, лично мне не сильно понравился этот опыт, но я в этих аджайлах/скрамах не силён.
P.S.: нашел, модератор, который работает с этими вещами, называется фасилитатор.
Как-то он там хитро назывался в терминах Agile.
Даже в нашей компании есть специально обученный модератор, но, лично мне не сильно понравился этот опыт, но я в этих аджайлах/скрамах не силён.
P.S.: нашел, модератор, который работает с этими вещами, называется фасилитатор.
про штрафы — это никакого отношение к agile не имеет, просто менеджмент кретины. в нормальную компанию вносить принципы должен коуч, а не человек, который прочитал книжку.
Естественно не имеет (я ещё там курсивом написал :) ), но это реальный случай. А так-то, конечно, хорошо быть богатым и здоровым. Но на практике что-то повсюду видим Agile курильщика.
Ну, формально, аджайл про команду мотивированных профессионалов, угроза штрафа или увольнения некоторых тоже мотивирует.
Слышал от друзей, у них на работе тоже Agile, только если ты не успеваешь в спринт сделать то, что запланировал на него, то тебя штрафуют.
Не так давно искал работу, так мне на одном собеседовании рассказывали что у них принято так — не успеваешь сделать фичу в спринт — никого не еб… в смысле не волнует, делай ее дома ночью, вместо обеда и выходных, в общем как хочешь, фича должна быть запилена, точка. Продолбался со сроками — сам дурак, никаких компенсаций за переработку, само-собой.
Незадолго до этого сетовали на текучесть, тупой и ленивый народ как-то несовместим с их передовыми методами разработки.
Ну в крайности тоже не стоит ударяться. Просто есть люди, которые просто патологически не могут оценить свое время даже при том, что никто на них не давит и бери запас сколько хочешь. Работал как-то с таким — на любой вопрос от всех «да, конечно, сделаю», а потом «ой, чет занят был, давай на след неделе».
Бывает часто так, что задачу ставят очень расплывчато, или оказывается постановщик задачи и исполнитель вообще о разном думали.
Опытный разработчик задаст много вопросов, постарается разобраться, если задача все равно «мутная» то возьмет времени минимум с двукратным запасом. Неопытный может и так — «да фигня за неделю сделаю», а там работы на пол года на самом деле…
Только это больше вопрос к организации работы, либо отдавайте постановку и реализацию задач полностью команде, либо задачи ставьте так что-бы не было WTF эффекта после их прочтения.
Опытный разработчик задаст много вопросов, постарается разобраться, если задача все равно «мутная» то возьмет времени минимум с двукратным запасом. Неопытный может и так — «да фигня за неделю сделаю», а там работы на пол года на самом деле…
Только это больше вопрос к организации работы, либо отдавайте постановку и реализацию задач полностью команде, либо задачи ставьте так что-бы не было WTF эффекта после их прочтения.
на любой вопрос от всех «да, конечно, сделаю», а потом «ой, чет занят был, давай на след неделе».Я даже могу рассказать, как такое получается.
Рассмотрите такого работника, как ящик с входом и выходом. На входе непрерывный поток запросов от всех.
Внутри ящика каждый запрос ставится в очередь с присваиваемым приоритетом. «Бери запас сколько хочешь» в этой ситуации означает, что приоритет будет самым низким. А поскольку очередь приоритетная, а поскольку запросы идут от всех (а не только от вас), а поскольку (скорее всего) не все озвучивают «времени сколько хочешь» — в каждый момент времени будет находиться актуальная задача с более высоким приоритетом. До вашего запроса дело не дойдет ни-ког-да.
Что с этим делать?
Формулировать дедлайн в том или ином виде. Не «бери сколько хочешь», а «к понедельнику потянешь? Отлично, договорились!».
Статья сводится к тому, что аджайл хороший, просто он не работает, потому что его не понимают, и не желают под него менятся так, чтобы он заработал.
Вопрос: а зачем?
Есть же альтернатива — открываем глаза, включаем мозг и выстраиваем процессы с учётом конкретных людей и задач. Бывает даже так, что процессы как-то сами выстраиваются по большей части.
Вопрос: а зачем?
Есть же альтернатива — открываем глаза, включаем мозг и выстраиваем процессы с учётом конкретных людей и задач. Бывает даже так, что процессы как-то сами выстраиваются по большей части.
А как быть, если, к примеру, Вы включили мозг, выстроили процессы, а разработчикам не нравится? Какие могут быть причины?
выстраивать процессы под людей и с ними согласовывать, осоьо упертым разъяснять кто платит зарплату и за что именно хочет заказчик
а процессы по аджайлу гарантированно понравятся? есть конторы, которые внедряют скрам чисто на бумаге, потому что клиент или руководство дорастёт до принципов аджайл только через пару тысяч лет.
Какие могут быть причины?Процессы не подходят разработчикам и/или задачам? Вы же составили список, что конкретно людям не нравится в аджайле, т.е. разобрались, так же можно и со своим процессом. Просто в отличие от своих процессов, аджайл менять нельзя, потому что если это сделать, будет уже не аджайл, а свой процесс. А свои процессы менять можно изначально.
Вот она, причина, казалось бы, противоречия. И кроется, опять же, в неправильном понимании аджайла.
Есть такое утверждение, которое нетрудно вывести из Agile Manifesto:
любая практика перестает быть Agile, как только становится обязательной для выполнения
Аджайл процессы можно и нужно менять. Для начала нужно только убедиться, что вы приняли культуру Agile (уважение к людям, общность целей, живое общение, обратная связь). Также для начала рекомендуют сделать всё "по книжке", прочувствовать, что и зачем, а уж потом менять с пониманием.
Также считаю, что каким хорошим ни был бы процесс, с людьми всё равно нужно работать, так как изначально не все могут понять всё правильно.
любая практика перестает быть Agile, как только становится обязательной для выполнения
К практикой давать обратной связи и к стэндапам это относится?
А в аджайл манифесте где-то написано что это обязательные вещи? :)
А если серьёзно, то если вам не смогли нормально объяснить что это такое и зачем это нужно, то на мой взгляд лучше обойтись без них. Потому что иначе это просто будет очередной карго-культ.
А если серьёзно, то если вам не смогли нормально объяснить что это такое и зачем это нужно, то на мой взгляд лучше обойтись без них. Потому что иначе это просто будет очередной карго-культ.
Выходит, Аджайл, это свобода по Марксу (ну, пусть по Спинозы) – "Осознанная необходимость".
Ну если смотреть с позиции наёмного работника, то на мой взгляд аджайл это больше свободы действий в обмен на большую ответственность. Это если совсем упрощать.
И если кому-то не интересна эта самая свобода действий и/или если он не хочет дополнительной ответственности, то наверное аджайл не для таких людей. И это как бы не то чтобы обязательно плохо или неправильно.
И если кому-то не интересна эта самая свобода действий и/или если он не хочет дополнительной ответственности, то наверное аджайл не для таких людей. И это как бы не то чтобы обязательно плохо или неправильно.
Где там та свобода? Тот же Scrum на практике куда более жесткий.
Хм, а можно поконкретнее в чём вы видите большую жёсткость скрама?
Вроде бы что и как делать решаешь сам. Темп работы тоже сам выбираешь. Или как это выглядит по вашему?
Ну, собственно, Дейв Томас так и говорит, что «Манифест гибкой разработки ПО» превратился в умах людей в «Гибкий манифест», совсеми вытекающими:
https://youtu.be/a-BOSpxYJ9M?t=561 — видео 2015 года, а дела, похоже, всё хуже и хуже.
Просто в отличие от своих процессов, аджайл менять нельзя, потому что если это сделать, будет уже не аджайл, а свой процесс.
Вроде в самом слове agile заключен смысл, что он гибкий и ОБЯЗАН меняться под условия конкретного проекта/команды.
Тот, кто говорит что аджайл менять нельзя — вот именно он строит не аджайл а свой недопроцесс.
Ну тут две проблемы — проблема руководителя и проблема руководителя. Но увы, чаще всего валят всё на команду. Первое — что эти люди делают в этих процессах, они же не сами себя набрали — это первая проблема руководителя. Вторая — неправильно подумали и выстроили систему, процессы и ПРОЦЕСС ПЕРЕХОДА к новой системе. Обычно это происходит так: завтра начинаем работать по «название схемы», через две недели не перешедших начинаем штрафовать. А что, зачем, переходные период, период адаптации, да тупо горящий период в которые переходить некогда. И на выходе «а нафига оно мне вообще надо за такую зарплату?», только в другой формулировке, потому что за такую сразу попросят покинуть компанию.
А по тематике статьи — моя позиция как работника была бы такой (сейчас я собственник) — за Agile надо доплачивать, так как подразумевает более широкий спектр обязанностей и компетенций. Но как я подозреваю ЗП там ничем не отличается обычно от позиции обычного разработчика.
А по тематике статьи — моя позиция как работника была бы такой (сейчас я собственник) — за Agile надо доплачивать, так как подразумевает более широкий спектр обязанностей и компетенций. Но как я подозреваю ЗП там ничем не отличается обычно от позиции обычного разработчика.
>Обычно это происходит так: завтра начинаем работать по «название схемы»
Обычно это происходит еще смешнее. Завтра начинаем работать по… Х. А до этого успешно работали много лет, разве было плохо? Ну то есть, вместо того, чтобы в существующей работающей структуре поставить/скорректировать цели, начинается полная хрень «с понедельника работаем по новому». Независимо от команды, проекта, и многих сопутствующих факторов, в том числе таких, которые делают X непригодным. Вот это, кстати, и не нравится.
Обычно это происходит еще смешнее. Завтра начинаем работать по… Х. А до этого успешно работали много лет, разве было плохо? Ну то есть, вместо того, чтобы в существующей работающей структуре поставить/скорректировать цели, начинается полная хрень «с понедельника работаем по новому». Независимо от команды, проекта, и многих сопутствующих факторов, в том числе таких, которые делают X непригодным. Вот это, кстати, и не нравится.
ну, а зачем вам React, Angular, Vue? пишите на голом js, если настолько умные. аналогия. это такой же фреймворк — так проще.
Я не согласен с вашей аналогией. React, Angular, Vue, решают типовые инженерные задачи.
Управление командой — это не типовая инженерная задача и не наука, это soft skills. Каждый сотрнудник индивидуален, к каждому нужен свой подход. Кто-то умеет и хочет подстраиваться под команду, а кто-то наоборот, гораздо производительнее если его не трогают.
Поэтому любые попытки применить "фреймворк" к человеческим отношениям выглядят так же нелепо, как книги по пикапу с набором составленных фраз.
Индивидуальность сотрудников это преувеличение. На уровне линейного персонала все примерно одинаковы и взаимозаменяемы, а особо «уникальные» просто не приживаются или не попадают в компанию вообще.
Так что управленческие фреймворки с такими типовыми задачами (чай не академиками руководим) справляются.
Так что управленческие фреймворки с такими типовыми задачами (чай не академиками руководим) справляются.
Я считаю что именно талантливые и уникальные люди создают успешные продукты, и такие люди — залог успеха любой компании. И как правило они выполняют 90% полезной работы и двигают всех остальных вперёд. Если вы так не считаете, ваше право.
Есть программисты, у которых большой опыт, понимание и умение в узкой области разработки. Взять, к примеру, ту-же САПР разработку — самые востребованные тут программисты те, которые сначала учились и работали инженерами-проектировщиками. Которые знают и процессы той отрасли, которую они стараются теперь автоматизировать. И еще лучше, если они фанатики своего дела.
Тоже и в других отраслях.
Так вот таких вы днем с огнем не сыщите! И они не подойдут под ваш фреймворк.
Тоже и в других отраслях.
Так вот таких вы днем с огнем не сыщите! И они не подойдут под ваш фреймворк.
Отличие Agile от других управленческих фреймворков в том, что он пытается работать с людьми именно как с академиками. Пытается зачерпнуть и раскрыть огромный пласт креативности, присутствующей в людях, но тщательно подавляемой традиционными управленческими фреймворками.
Да, для этого нужно "лезть в душу". Да, нужно говорить о том, о чем традиционно на работе не говорят, о ценностях и личных целях, о комфорте и дискомфорте, потому что только поняв друг друга, можно наладить настоящую командную работу, с эффективностью которой не сравнится ничто ранее существовавшее.
Плюсую! "Кадры решают всё"
Вопрос: а зачем?
Это вопрос можно задать и в отношении таких вещей как ЯП или фреймворки. И точно так же как отдельные ЯП, так и отдельные методики организации процессов иногда имеет смысл использовать, а иногда нет.
Но однозначный ответ на «а зачем», который подходит для всех ситуаций, вы вряд ли найдёте.
Кому-то может действительно не нравится реализация процесса разработки.
Причем, не важно, аджайл это или не аджайл, ведь плохой процесс разработки может быть в обоих случаях.
Но гораздо хуже, когда продолжают молиться и навязывать различные ритуалы, и списывая бардак на плохо реализованный аджайл.
Причем, не важно, аджайл это или не аджайл, ведь плохой процесс разработки может быть в обоих случаях.
Но гораздо хуже, когда продолжают молиться и навязывать различные ритуалы, и списывая бардак на плохо реализованный аджайл.
Вообще статья была не про то, как списать бардак на плохую реализацию. Речь шла о том, как реализовать хорошо то, что может работать хорошо, но почему-то не работает.
Как Вы правильно сказали, не работать может любой процесс. В статье я пытаюсь анализировать, почему аджайл не работает с точки зрения разработчиков. Делюсь теми ответами, которые уже нашел. С интересом читаю комментарии в поисках новых неотвеченных вопросов.
По моему опыту — когда нет личной ответственности и возможности влиять на результат, можно очень быстро перейти в режим «у меня лапки, пока не пнёшь — не полечу» :)
Почему-то все боятся ответственности — видимо, потому что накажут, если что не так? Но ответственность, в её правильном смысле, работает благотворно.
В статье я пытаюсь анализировать, почему аджайл не работает с точки зрения разработчиков.
Вы абсолютно правильно обозначили причины, почему он не нравится разработчикам. Но я не думаю, что тут есть какое-либо решение, отличное от «если ваша команда не любит эджайл, значит, не используйте эджайл». Это в значительной мере зависит от психотипа людей, а не от организации процессов, социальных скиллов скрам-мастера и так далее.
Эджайл предполагает, что в вашей команде все люди общительные и инициативные. В то время как среди людей, которые хорошо пишут код, таких едва ли половина найдётся. Многие хотят просто получить задачу и делать её, как можно меньше отвлекаясь на болтовню. И действительно сделают её намного быстрее и качественнее, если их не мордовать скрамами.
Эджайл предполагает, что в вашей команде все люди общительные и инициативные.
Да на самом деле совсем и необязательно. На мой взгляд достаточно если будет определённый процент «общительных и инициативных», а остальные просто «нормальные». Ну то есть что остальные в принципе в состоянии общаться с другими и хотя бы не саботируют работу :)
За увеличение ответственности необходимо вознвграждать финансово и действительно делегировать полномочия.
А все эти скоропостижные попытки натянуть сову на глобус с разводиловом про "работу на результат", постоянные "скачки" и аврал, переработки и прочую бюрократию. Неадекватные требования бизнеса, которые кому то там, чего то пообещали и прочее и прочее.
Разрабоичик это инструмент. Бывают супер инструменты, бывают обычные… Но за ними надо следить и ухаживать. Статья о том, какие разработчики паразиты и не понимают какое счастье им прилетело. Хотя весь вопрос в качестве менеджмента. Не умеешь руководить. Хоть аджайл, хоть что… Не поможет
«если ваша команда не любит эджайл, значит, не используйте эджайл»
Полностью согласен. Но пытаюсь понять, что именно команда подразумевает под «эджайл», и что именно она не любит. Из всего здесь сказанного, я не вижу почти ничего, что относилось бы к настоящему «эджайл». Есть очень много подмененных понятий, к сожалению.
И после того, как я расскажу своей команде, какой именно «эджайл» я предлагаю использовать, не думаю, что кто-то откажется.
Статью прочитал, но сделал из неё обратные выводы.
Расскажите, где я ошибаюсь?
Создалось впечатление, что описываемый agile подходит только для одиночек, когда над одним разработчиком сидит 5 менеджеров, но в разработке только один человек. Он делает абсолютно всё — frontend, backend, базы, настройка серверов, даже заключение договора с каким-нибудь хостингом лежит на нём.
А теперь представим ситуацию — есть некий высоконагруженный сервис и в команде есть админ, разработчик бекэнда с бизнес-логикой на java/erlang/go, разработчик бэкенда gui на php, разработчик фронтенда на JS, дизайнер и тестировщик.
Приходит бизнес-заказчик и говорит "мне нужно, чтобы у меня появилась статистика по всем транзакциям за последний год с отчётностью в реальном времени и скорость формирования отчёта не дольше 3 секунд, даже опишет список отчётов".
Это вполне нормальная бизнес-задача, бизнесу и не надо лезть в дебри.
Предположим, кто-то из них взял на себя роль архитектора и расписал, что для задачи нужно арендовать 3 сервера, развернуть там кластер ElasticSearch, доработать высоконагруженное ядро, сделав импорт в ES, создать API для запросов о данных реального времени для бекэнда gui, доработать бэкенд gui, доработать фронтэнд, прикрутить дизайн,...
Теперь вопрос — кто берётся за задачу и несёт ответственность?
И что делать, когда в процессе реализации выяснится, что не всегда данные в ES реально рушить напрямую и в разрыв схемы надо ещё какую-нибудь Kafka поставить?
Предположим, что за это всё взялся дизайнер (ну хочет он переквалифицироваться в будущем в проджекты). Всё у него получается, но тут засада — админ категорически отказывается ему помогать, т.к. он уже набрал параллельных задач по, скажем, миграции всего и вся из одного облака в другое и у него уже нагрузка 120%. Сроки летят чёрт знает куда, разворачивать нужный софт никто не умеет, встаёт даже разработка, т.к. нет тестового стенда.
Либо в статье чего-то упустили, либо подразумевается, что дизайнер команды одновременно хорош во всём (покажите мне одновременно хорошего дизайнера, разработчика одновременно бекэнда и фронтэндп и админа — верю, что такие уникумы существуют, но их единицы), либо в любом случае должен быть маршрутизатор задач, должны строиться причинно-следственные связи (что после чего можно начать разрабатывать, что в какой последовательности пускать в прод и т.д.) и должно быть гибкое регулирование уровня "админ обещал, но не сделал из-за аварии в продуктиве и сроки начинают ехать? не страшно, у нас 4 параллельных стрима в работе, переключаемся на стрим #3, там админ не на критическом пути".
Либо… либо ресурсов должно быть всегда больше, чем задач. Один человеко-админ чисто админит, второй чисто деплоит, третий ждём аврала, четвертый в резерве на случай отпуска/болезни кого-то из первых троих (а для сохранения экспертизы роли меняются каждую неделю), у прогнозов и дизайнеров та же схема… но нафига такой agile, когда в команде на 50% больше ресурсов только для того, чтобы всегда гарантированно выполнять сроки??
p.s. Ах, да, ещё можно завышать сроки с учётом рисков. Работы на день? Пишем неделю, тогда точно успеем.
Поправьте меня если неправ, но:
Agile — это не про процессы. Это манифест про «мир во всём мире». А вот если взять одну из реализаций Agile-а (например тот-же скрам), то:
Это про команду в одном функционале (всё одинаково ориентируются в области знаний/языке программирования).
И эта команда ничем больше не занимается, кроме своего спринта.
Т.е. админ не может набрать других задач на 120%.
И если команда в середине спринта и приходит заказчик с «мне нужно срочно доработать» — его посылают лесом.
И архитектуру/распиливание на задачи/др. должен делать кто-то другой (или «её может сделать каждый»).
У вас бизнес с такой командой будет работать?
А вот чтобы работал — нужен скрам-мастер и набор других менеджеров.
Или использовать не-скрам.
Как-то так…
Agile — это не про процессы. Это манифест про «мир во всём мире». А вот если взять одну из реализаций Agile-а (например тот-же скрам), то:
Это про команду в одном функционале (всё одинаково ориентируются в области знаний/языке программирования).
И эта команда ничем больше не занимается, кроме своего спринта.
Т.е. админ не может набрать других задач на 120%.
И если команда в середине спринта и приходит заказчик с «мне нужно срочно доработать» — его посылают лесом.
И архитектуру/распиливание на задачи/др. должен делать кто-то другой (или «её может сделать каждый»).
У вас бизнес с такой командой будет работать?
А вот чтобы работал — нужен скрам-мастер и набор других менеджеров.
Или использовать не-скрам.
Как-то так…
НЛО прилетело и опубликовало эту надпись здесь
Как раз-таки говорит:
Вернее, вы немножко подменяете понятия. Знать и уметь можно по-разному, но это ни на что не влияет.
- Development Teams are cross-functional
- Scrum recognizes no titles for Development Team members
- Scrum recognizes no sub-teams in the Development Team
Вернее, вы немножко подменяете понятия. Знать и уметь можно по-разному, но это ни на что не влияет.
Всё это верно. Но это всё равно не означает что каждый участник команды должен знать и уметь всё. И уж тем более что каждый участник должен всё знать и уметь одинаково хорошо.
То есть первый пункт это про команду в целом. А второй и третий это скорее о том, что не должно быть вещей вроде «это проблема бэкенда, а я фронтенд, поэтому меня это вообще не касается»
То есть первый пункт это про команду в целом. А второй и третий это скорее о том, что не должно быть вещей вроде «это проблема бэкенда, а я фронтенд, поэтому меня это вообще не касается»
НЛО прилетело и опубликовало эту надпись здесь
«Контекст» — это предваряющие и последующие фразы, которые задают определённые условия или иным образом уточняют сферу применения. И я, и вы цитируем самостоятельные тезисы. Своей цитатой вы не добавили/расширили контекст.
Мне можно поставить в упрёк, что я интерпретирую их слишком буквально. Но поскольку, это не брошенная наспех фраза на форуме, а явно выделенные утверждения в документе, им нужно следовать как есть. Как-то расширяете их смысл (по-своему интерпретируете) вы.
«Последний абзац», явно говорит не об общей практике, а о допустимой вариации: «may have». Очевидно, что нельзя постоянно закладываться на особые знания и умения одно конкретного члена команды — он может заболеть, уволиться и т.п. Т.е. (в виде исключения) команда под коллективную ответственность может взять на себя задачу, в которой компетентен лишь один человек.
Мне можно поставить в упрёк, что я интерпретирую их слишком буквально. Но поскольку, это не брошенная наспех фраза на форуме, а явно выделенные утверждения в документе, им нужно следовать как есть. Как-то расширяете их смысл (по-своему интерпретируете) вы.
«Последний абзац», явно говорит не об общей практике, а о допустимой вариации: «may have». Очевидно, что нельзя постоянно закладываться на особые знания и умения одно конкретного члена команды — он может заболеть, уволиться и т.п. Т.е. (в виде исключения) команда под коллективную ответственность может взять на себя задачу, в которой компетентен лишь один человек.
НЛО прилетело и опубликовало эту надпись здесь
не всякий Agile — это Scrum
Просто не называйте Scrum'ом то, что наадаптировали.
«два человек с соответствующим скиллом» — это явная sub-team
Просто не называйте Scrum'ом то, что наадаптировали.
«два человек с соответствующим скиллом» — это явная sub-team
НЛО прилетело и опубликовало эту надпись здесь
его посылают лесом.
зачем же такие драконовские методы. если в середине спринта выяснилось, что то, что в спринте не нужно, а нужно что-то другое, то не обязательно доделывать что-то ненужное.
Но заказчик должен понимать, что если он себе так каждый спринт будет ломать, то не сможет планировать глобальный прогресс его продукта. Смысл внедрения scrum теряется.
И если команда в середине спринта и приходит заказчик с «мне нужно срочно доработать» — его посылают лесом.А как же принцип манфеста «Responding to change over following a plan»?
Скорее нужно подумать, что это за новая задача. Если у заказчика от этого бизнес теряет каждый час миллионы и он согласен на то, что новые фичи подождут (всё не успеть), то есть смысл взять в работу новую срочную задачу, выкинув из спринта что-то менее срочное. А если это нужно будет через месяц, то просто учесть это при наборе скоупа следующего спринта.
А как же принцип манфеста «Responding to change over following a plan»?
Это сколько угодно. Но уже в следующем спринте. Или обрываем спринт и начинаем новый с нуля.
… плюс, надо отметить, что такое (про потерю миллионов) случается крайне редко.
А если заказчик слишком часто меняет желания, то надо ему объяснить, что так он саботирует работу команды. Либо, если не понимает, то подождать, может через полчаса он принесет что-то новое и отменит предыдущее, либо вообще вернется к старому.
Если это происходит часто, то может помочь некая комбинация скрама и канбана: спринты спринтами, но каждый спринт выделяется определённый слот на решение непрогнозируемых проблем, при наличии которых все силы бросаются на их скорейшее решение (по приоритетам). Если такового не было, а задачи из скопа спринта завешены, то можно брать задачи из бэклога.
В любом случае, прерывать работу над одной задачей, чтобы заняться другой более срочной, слишком расточительно.
Сценарий из реальной жизни: поддержка приложения в продакшене. Задачи, причем ультра-срочные, могут возникать из ниоткуда. Для этого у нас есть дежурный по поддержке. Пытались совмещать дежурство с разработкой (типа 50/50%) – создает слишком много стресса на этом человеке: только возьмется что-то писать, а тут сбой. В итоге на 100% он сейчас выделен. Если успеет что-то еще сделать, хорошо, нет – тоже вполне ожидаемо.
создает слишком много стресса на этом человеке: только возьмется что-то писать, а тут сбой.У вас что электропитание настолько часто отключают?
Не все любят или даже могут нормально работать если тебя каждые полчаса-час отрывают от актуальной задачи и требуют чтобы ты быстро что-то где-то пофиксил. Я уж точно совсем не люблю.
Я уж точно совсем не люблю.Ну этого действительно никто не любит. Я по такому поводу могу и рявкнуть по не русски.
каждые полчаса-час отрывают от актуальной задачи и требуют чтобы ты быстро что-то где-то пофиксил.
Так разговор же вроде как про то что скрам качество софа поднимает. Высококачественный значит у всех качеств высокие числовые значения. Одно из качеств — надежность. Измеряется в часах наработки на отказ, измерение обязательно продолжается и в продакшине. Для реально качественного софта его измерить обычно не удается — то электричество вырубят то железо выгорит.
Если железо — то это не дежурного программиста забота, а дежурного электроника. Хотя в банках частенько электроников вообще нет (железо то современное выгорает гораздо реже чем свет выключают), и между программистом и эникейщиком разницы не видят — все это IT отдел.
От и хотел уточнить — они таки дежурного эникейщика добавили, или настолько ненадежный софт в продакшине — это такая фишка срама?
Тут главная ошибка в том, что это не одна задача, а целая куча задач. Необходимо для начала сделать груминг. Итого у вас примерно выйдет следующий набор эпиков:
Функциональный блок:
Не функциональный блок:
Бизнес-блок:
Дальше будет приоритезация. Строить отчёт и статистика, это максимальный приоритет. Без этого бизнес не может начинать работу. В этот момент фильтрации для списка необходимых отчётов можно захардкодить, а по поводу 3х секунд и реального времени, ну такое. Для начала нужно хотя бы РоС сделать. Нужен ли UI сразу или достаточно вывести в эксель, тоже вопрос для обсуждения. Итого эти задачки можно разбить на 2-3 спринта и обозначить возможные риски. Так же не забываем, что каждый эпик разбивается ещё на истории.
Функциональный блок:
- Уметь строить отчёты;
- Уметь строить статистику;
- Уметь настраивать фильтрации;
Не функциональный блок:
- Время выполнения менее 3х секунд;
- Отчёт в реальном времени;
Бизнес-блок:
- Список необходимых отчётов;
Дальше будет приоритезация. Строить отчёт и статистика, это максимальный приоритет. Без этого бизнес не может начинать работу. В этот момент фильтрации для списка необходимых отчётов можно захардкодить, а по поводу 3х секунд и реального времени, ну такое. Для начала нужно хотя бы РоС сделать. Нужен ли UI сразу или достаточно вывести в эксель, тоже вопрос для обсуждения. Итого эти задачки можно разбить на 2-3 спринта и обозначить возможные риски. Так же не забываем, что каждый эпик разбивается ещё на истории.
Спасибо за интересный и весьма жизненный сценарий!
кто берётся за задачу и несёт ответственность?
Команда берется. Все садятся кругом и кто-то, кто хочет быть лидером в этой задаче, спрашивает: "ну, что? возьмемся за эту задачу в этот спринт?".
Далее идет обсуждение, где админ говорит: "… у меня уже нагрузка 120%. я пасс".
В принципе, на этом всё может и закончиться – команда говорит PO/бизнесу: "мы не можем это сделать, т.к. админ перегружен".
Но может и не закончиться, если админ сам (или другой член команды, болеющий за общий результат) скажет: "вообще, из тех задач, которыми я сейчас перегружен, одна всё равно зависла, т.к. сервера не привезли, а другая, возможно не та сильно важна для нашей текущей цели, может, product owner сможет перенести ее в следующий спринт?".
Так чудесным образом перегрузка админа может резко сократиться, и он скажет: "да, я берусь за эту задачу".
И дизайнер скажет "берусь", и все остальные участники. Так задача попадает в спринт.
что делать, когда в процессе реализации выяснится… надо ещё какую-нибудь Kafka поставить
Значит, взять, и поставить. Если это не выбивается за границы спринта, то вообще нет проблем. Если выбивается, то: 1) оповестить всю команду, PO, заказчика, о том, что на пути возникло непредвиденное препятствие, предложить варианты решения; 2) быть может, выделить Кафку в отдельную задачу и запланировать ее в слудеющий спринт, либо наоборот, сделать сейчас вместо другой подзадачи, которую можно вынести в следующий спринт. Так или иначе, команда должна собраться и решить.
подразумевается, что дизайнер команды одновременно хорош во всём
Не подразумевается.
должен быть маршрутизатор задач, должны строиться причинно-следственные связи
Это сама команда. Если это настоящая команда, у них нет нужды обращаться к стороннему маршрутеризатору, чтобы решить, что делать. В кросс-функциональной команде есть все необходимые специалисты, чтобы построить связи и всё реализовать.
должно быть гибкое регулирование уровня "админ обещал, но не сделал"
Совершенно верно. Команда может не успеть сделать то, за что взялась. Это можно обсудить на ретро, чтобы повысить прогнозируемость в будущем. Что делать с незаконченной задачей – нужно всем собраться и обсудить при планировании следующего спринта.
нафига такой agile, когда в команде на 50% больше ресурсов только для того, чтобы всегда гарантированно выполнять сроки?
Справедливый вопрос. Не нужен. Поэтому и важно не искать виноватых, не наказывать за неуспевание. Иначе так и будет: "Работы на день? Пишем неделю, тогда точно успеем."
Напоследок добавлю, один человек не может работать в нескольких командах. Это сделает все эти команды неполноценными.
НЛО прилетело и опубликовало эту надпись здесь
Ох я помню эту боль, когда мы 3 реальных часа сидели отбирали задачи в следующий спринт. Реально оценить срок исполнения, подводные камни задач могут 2 человека из 12. Оценки получались усреднённые (бралась медиана, но всё же), а итог, как правило, — плачевным.
почему не успели и что надо делать чтобы успеватьБрать меньше?
Не в смысле «оценивать с запасом», а именно брать меньше.
А почему нельзя просто выбросить спринты и оставить только беклог? Я примерно так и работаю со своими разработчиками. И нет никакого цейтнота. Это уже не Agile?
По-моему в смысле самих слов «sprint» и «scrum» заложена проблема и цейтноты. Отсюда и проблемы. Всем вставить шило в заднее место — и бежать-бежать!
Ну вообще-то количество задач, которые берутся в спринт, должна определять сама команда. Если вы берёте слишком много, то сами и виноваты. Если кто-то вас «заставляет» брать больше чем вы хотели бы, то это уже не скрам.
Проблема в том, что нельзя спринт делать планом, как в старые добрые советские времена. Т.е. не должно быть виноватых, обвиняемых, обвиняющих и т.д. ИМХО это и убивает Agile.
Разработчик в Agile должен быть настроен на то, что есть задача и ее надо выполнить качественно, а не за определенное время.
Разработчик в Agile должен быть настроен на то, что есть задача и ее надо выполнить качественно, а не за определенное время.
Если кто-то вас «заставляет» брать больше
Как тут уже обсуждали, есть такой «скрам», что нет возможности не брать. Ну т.е. либо работаешь, либо уволят. А потом люди с высунутыми языками и тяжёлым дыханием говорят, вот у нас скрам-аджайл-спринты.
И чего делать, если вроде как хорошую идею извратили?
Если у вас такой "с[к] рам" и нет шансов что что-то изменится, то на мой взгляд остаётся только увольняться.
А такой скрам много где, далеко не факт, что найдёшь нормальный
Это всё конечно ещё и от региона зависит, но я бы сказал что программист себе вполне может работу по вкусу найти. И если в фирме такой бардак, то наверное лучше поискать что-то ещё.
Ну вот мне по вкусу "ванильный" скрам, вот прямо по гайду. Нигде его не встречал, везде какие-то отклонения, основное можно сформулировать так: менеджмент лезет в процессы, которые по гайду чисто внутреннее дело команды разработки (даже не скрам-команды), а скрам-мастер по сути является частью менеджмента, начальства. Причём в особо запущенных случаях определить это можно только проработав с полгода и более, до первого серьёзного фейла.
Ну, это субъективное восприятие.
Изначально термин "спринт" в скарме означал быстрое перемещение рывком, после которого нужно собраться, отдохнуть, собраться с силами, подумать, перегруппироваться, ..., и дальше – следующий рывок. И это было в противоположность непрерывной гребле против течения, чтобы взобраться на водопад :)
НЛО прилетело и опубликовало эту надпись здесь
точно оценить в часах задачи спринта, чтоб всё влезло в спринт, когда кода в глаза не видел или макета или тз.
Ээээ, а зачем прямо точно, да ещё и в часах? То есть рано или поздно у вас начнёт получаться примерно угадывать сколько каких задач вы можете запихать в этот спринт. Чтобы вот всегда точно угадывать я ещё нигде не видел…
точно отработать эти часы, а это 8 часов в день чистой работы, что абсолютно нереально в реальном мире
На мой взгляд если уж планировать в часах, то тогда «реальный рабочий день» это часов пять в лучшем случае. А то и четыре.
почему не успели и что надо делать чтобы успевать
Прсосто планировать меньше? Ну если вы из раза в раз не успеваете, то просто сначала запланируйте «как обычно », а потом выкиньте скажем 20% и посмотрите успеете или нет. Если всё равно не успеете, то в следующий раз выкиньте треть. Рано иои поздно начнёте успевать. Примерно так скрам и работает…
Можно включать в часы время на отдых, кофе, работа под вечер — умножать на коэффициент (т.к. усталость). Почему обязательно чистая работа?
А вообще, чтобы избавиться от всего этого геморроя раз и навсегда рекомендуют оценивать задачи в стори-поинтах, при планировании спринтов использовать среднюю скорость (velocity) – число стори-поинтов, которое команда в среднем выполняет в спринт.
Система саморегулируется, т.к. если переоценивать, закладывать больше стори-поинтов, то скорость будет выше, а если недооценивать, то ниже, и соответственно в следующий спринт войдет меньше работы.
Вот только вчера вышла подробная статья на эту тему: https://habr.com/ru/post/489500/
ориентированны на качество итогового продукта, а не на ежедневные ритуалы.
Выглядит так, что у них Agile)
Так статья же ровно про это: что под ярлыками "скрам" и "аджайл" очень часто скрывается менеджерский булшит. Загляните между делом в Agile Manifesto или в Scrum Guide. Не найдёте там ни "точной оценки в задачах", ни "8 часов чистой работы в день". Это 100%-ная менеджерская отсебятина.
Вот это куда ближе к настоящему Agile: "помочь коллеге", "ориентация на качество". Но увы, такое найти сложнее.
Для решения этой проблемы придумали фокус фактор. Который может быть равен и 50% и 33% и расчитывается для команды и условий. Это значит, что если вы оценили задачу в 8 идеальных часов, то в реальности 1 разработчик будет делать ее 3 дня. Исходя из этого спринт и планируют.
Очень странно, что у вас его не использовали и на ретро обсуждали почему не успеваете. Да всегда понятно почему, работа не состоит только из решения задач по спринту.
Очень странно, что у вас его не использовали и на ретро обсуждали почему не успеваете. Да всегда понятно почему, работа не состоит только из решения задач по спринту.
Ну вот у нас на двухнедельный спринт (80 рабочих часов) нормальным считается на 48 часов набрать задач. Часов 12 на скрам-ритуалы суммарно, 20 часов на код-ревью и резерва. Правда всё равно фейлим, нормальным считается сделать процентов 80 от запланированного
А как вы планируете? По идее "метод вчерашней погоды" должен колебания привести к среднему.
Неправильно планируем. Оцениваем азадачи на груминги в СП, на планинге в часах и набираем по 48 часов на разработчика (QA члены команды разработки формально, но по факту у них своя кухня и параллельный бэклог задач). В итоге стабильно получаем порядка 100-120 SP на команду и делаем 80-100. Метод "вчерашней погоды" не применяем. На ретро одно время постоянно появлялись пункты "надо лучше оценивать", но перестали, потому что конкретных действий не влекут.
Т.е. все занимаются самообманом в отношении планирования.
Пункт "надо лучше оценивать" имхо слишком общий — это постановка проблемы, а не результат ретры. Обычно на ретрах рекомендуется выбрать какой-то эксперимент, чтобы на следующей ретре оценить его результаты. Типа "сравнить точность метода вчерашней погоды на готовых данных".
Наверное не все. Я, например, не занимаюсь. Точно понимаю, что в следующем спринте графики такие же плохие будут. если ничего плохого не случится — тогда ещё хуже.
В общем воспринимаю этот наш конретный скрам теперь как менеджерскую игру. Если на старте спринта понятно, что не то, что все таски сделаны не будут, но даже цели (хорошо, если их три как в текущем, а не семь как пару спринтов назад), но никто не чешется, то я только на ретро и дэйли долблю "нереально"
А результат планирования кому-то нужен? Что происходит если план не соответсвует факту? Кто-то страдает от этого?
Ну в целом страдают все, но большинство косвенно. Типа разработчики доверие теряют. Точно не могу сказать, но вероятно продактовнеры как-то страдают. Это в обычной ситуации, когда нет внешних обязательств.
Тогда почему все выбирают неправильно оценивать?
Ну я бы предположил что кто-то «сверху» определил как это «правильно оценивать» и все должны следовать этой «методике оценивания». И если ты вдруг от неё отклоняешься, то вот за это попадает уже тебе.
По крайней мере лично я такое встречал.
По крайней мере лично я такое встречал.
Так исторически сложилось, и, судя по всему, раньше как-то работало. Команда увеличилась в пару раз, и уже почему-то перестало работать. Возможно (моя личная гипотеза) считают, что команда ещё не устаканилась, и надо просто подождать.
Чтобы изменить систему оценки, нужна чья-то инициатива и поддержка большинства остальных. Мои инициативы достаточной поддержки не находят. А аргументы против из разряда "Jira не умеет суммировать SP по подзадачам".
А какой у вас сейчас размер команды если не секрет? Просто по мне скрам как-то очень плохо начинает работать если в команде больше 7-8 человек(и это с ПО и скрам-мастером). А пожалуй и не только скрам.
Сейчас две команды 7 и 8 человек. Работаем по Scrum of Scrum, но проблемы одинаковы
Вот со всякими Scrum of Scrum или нексусами это я уже не особо дружу. Ну то есть ни разу не видел чтобы это нормально работало. И обычно это просто начинает ломать обычный скрам потому что тебе вдруг надо подстраиваться под другие команды и начинается «у всех спринт две недели зачем вы хотие три», «все митинги делают делают до обеда, так давайте и вы тоже так будете делать», «подвиньте ваш дэйли на полчаса, а то нексус-дэйли делать неудобно», «вон люди считают таски в часах, а вы в каких-то стори поинтах»… :)
Из своей практики.
Дисклеймер.Затрудняюсь соотнести такие результаты с тем, что у нас эджайл со скрамом, возможно, у нас просто что-то было не так настроено или я не так понял взаимосвязь. Просто когда перешли на новомодные процессы, тогда проблемы и начались.
Проблема в том, что отсутствуют критерии конечности процесса. Есть только нескончаемая стена из тасков. И нету понимания, что мы что-то доделали, пусть не до конца, но до какого-то конкретного рубежа, за которым начинается новый этап развития. Нету ТЗ, нету критериев законченности, нету смысла. И что самое главное, нету чувства собственного удовлетворения от хорошо сделанной работы. Потому что она не закончена. И не будет закончена примерно никогда. Конец спринта — не то. Очередной деплой на прод — не то. Это не веха в развитии. Это будни. Это убиение удовольствия от работы. Не перестаёшь чувствовать себя осликом, идущим за подвешенной перед мордой морковкой.
Дисклеймер.Затрудняюсь соотнести такие результаты с тем, что у нас эджайл со скрамом, возможно, у нас просто что-то было не так настроено или я не так понял взаимосвязь. Просто когда перешли на новомодные процессы, тогда проблемы и начались.
Проблема в том, что отсутствуют критерии конечности процесса. Есть только нескончаемая стена из тасков. И нету понимания, что мы что-то доделали, пусть не до конца, но до какого-то конкретного рубежа, за которым начинается новый этап развития. Нету ТЗ, нету критериев законченности, нету смысла. И что самое главное, нету чувства собственного удовлетворения от хорошо сделанной работы. Потому что она не закончена. И не будет закончена примерно никогда. Конец спринта — не то. Очередной деплой на прод — не то. Это не веха в развитии. Это будни. Это убиение удовольствия от работы. Не перестаёшь чувствовать себя осликом, идущим за подвешенной перед мордой морковкой.
А вы не планируете релизы с учетом всех фич, которые в них должны входить?
отсутствуют критерии конечности процесса, нет смысла, нет чувства собственного удовлетворения
У нас тоже так было. Скорее всего вы не в курсе тех бизнес-целей, которые ставит бизнес. Они их достигают, радуются, но успехами с вами не делятся. Так было у нас.
У любой деятельности должна быть цель. Она наполняет ее смыслом и приносит удовлетворение по достижении. Это часть happiness метрики.
Попросите бизнес объяснять вам цели, повысьте прозрачность в обоих направлениях.
НЛО прилетело и опубликовало эту надпись здесь
Может быть, вашего? Уйдите от него, есть места, где не так.
НЛО прилетело и опубликовало эту надпись здесь
То есть, есть боссы, которым не все равно на сотрудников?
Однозначно есть. Возможно это не боссы транснациональных коропораций, но в принципе такие тоже встречаются.
Да вы же и сами пишите что только в 90% случаев «начальству глубоко фиолетово». Получается что в 10% случаев это не так :)
Вот я босс, бмв есть, дачку строю, любовницы не имею :) о сотрудниках думаю. Вам может показаться странно, но нет, иначе и быть не может. Мне толковый сотрудник обходится с очень дорого. Его нужно найти, а затем обучить, а на это уходит месяцев 6 в лучшем случае, чаще год и более. Учат его не учителя информатики, а мои самые опытные спецы, у которых время стоит вполне осязаемых денег. Так что мне пипец как важно удерживать сотрудников, особенно ключевых.
А знаете кто становится ключевым? Тот кто интересуется моими проблемами и проблемами моего бизнеса. Сам интересуется, по своей инициативе. Тот кто не просто код пишет как ему «дядя» сказал, а тот кто голову включает. И внезапно у таких людей не совсем рыночные зарплаты.
Я здесь где-то выше или ниже написал, что те кто работает «на дядю» это добровольные непродуктивные рабы. Они сами себя ставят в позицию, когда их не только легко заменить, но даже иногда и хочется. И все эти люди выбирают такую позицию добровольно. От этого никому не лучше loose-loose, но так уж у них голова устроена.
Его нужно найти
Но сейчас повсеместно на рынке ищут не толковых, а «под agile» (который, как мы уже выяснили, не является тем изначальным Agile). Т.е. молодёжь, которой можно платить меньше рынка, не доплачивать за переработки.
все эти люди выбирают такую позицию добровольно
Возможно, потому что в индустрию рванулось слишком много толпы? В Индии вон, за тарелку риса код пишут :) Весь upwork стонал одно время.
Людей, которые будут работать больше и которым при этом можно платить меньше, искали и ищут всегда и во всех отраслях. Потому что это мечта любого работодателя. Но я бы не сказал что сейчас в ИТ эти качества прямо вот повсеместно являются основными критериями при отборе кандидатов :)
Работодатель должен понимать, что «работать больше» и «платить меньше» никак не связано с качеством работы. Не бывает такой экономии бесплатно. Не смогут 2 джуна заменить сеньора. А 3-4 джуна — тем более (см. Брукса) не смогут.
прямо вот повсеместно являются основными критериями
А, ну есть ещё другой перекос — хотят «крутого», так сильно, что всех крутых на собеседовании отсеивают.
Ну, собственно, погружение в бизнес и означает степень «сеньорности» специалиста. Кому-то это нужно (с прибавкой в зарплате, должности, ответственности), а кому-то и нет (у него помимо работы другие интересы).
То есть, есть боссы, которым не все равно на сотрудников?
У меня есть забавная статистика — во всех местах, где работала моя жена, боссы были настоящими чистейшими жадными и психованными ублюдками. Я с некоторыми из них в какой-то мере знаком, это действительно факт. В то же время все мои боссы были абсолютно нормальными людьми. Где-то были приличные рабочие отношения, где-то даже дружеские, я ни про кого не могу сказать дурного слова. Если мне была нужна помощь — просто брали и помогали, по зарплате и по рабочим моментам не жадничали, не делали гадостей, и я могу точно сказать — им было не всё равно на сотрудников.
И мне сейчас точно так же далеко не всё равно на людей, с которыми я работаю.
Больно было читать. Скрам мастер, Agile менеджер… И уж не обессудьте, я процитирую твиттер Аллена Холуба:
Words that DO NOT appear in the Agile Manifesto & Principles:
sprint
backlog
product owner, scrum master
release train
story
story points
estimate
velocity
meeting
Jira
manager
productivity
utilization
Words that DO appear in the Agile Manifesto & Principles:
individuals
interaction
valuable (software)
collaboration
change
customer
deliver…frequently
conversation
technical excellence
simplicity
self-organizing
reflects on…effective
adjusts
Этот твит – яркий пример троллинга. Человеку нечего было сказать, но он подловил другого на слове.
Я не просто так упомянул в статье "Agile менеджера". Не думаю, что кто-то из присутствующих работает наемным сотрудником в компании, где нет менеджеров. А если менеджер есть, то каким он должен быть, чтобы в компании работал Agile? Возможно, я посвящу этому отдельную статью.
Автору нужно было сделать find and replace: «agile» -> «scrum» и тогда статья имела бы больше смысла.
yaroslav2 в упор не понимаю, каким образом цели и ценности банка становятся целями и ценностями конкретных людей. С чего это вдруг мне должно быть интересно снижать чьи-то операционные расходы или увеличивать маржинальность маркетинга с помощью улучшения таргетинга? Мне, может быть, интересно оптимизировать доступ к данным или играться с новой библиотекой для machine learning. Но это лет до 30, а затем интересно уже с семьей время провести, в спортзал сходить, музыку послушать и т.д.
Ценности мои — работать в команде людей близких мне по духу и квалификации, делать то, что интересно мне лично, например исследовать связь между архитектурой ПО и абстрактной алгеброй. А компании интересно оптимизировать труд по критерию цена/качество, на абстрактную алгебру ей начхать, ей нужно деньги зарабатывать.
Не могу согласиться с тезисом о том, что командная работа это когда люди сами задачи себе берут. С этим даже бабуины справятся, особенно если задачи в берлоге лежат, понятно описаны и приоретизированы. А вот самим себе задачи придумывать, это уже из разряда фантастики. Чтобы задачу «придумать» нужно бизнес знать изнутри, а это, бывает, очень много информации и часто об этом книг не написано, а информация лежит в головах и 2-3 сотен топ менеджеров. Много людей в вашей команде в банковском бизнесе разбираются? Как это вообще должно работать?
Чем больше я общаюсь с топ менеджерами, тем больше убеждаюсь что никакой ценной информации в их головах не лежит. Дошло блин до того что топ менеджер не понимает концепции «стоимость владения» (total cost of ownership) не говоря уже о том из чего он складывается и на что мы можем дешево повлиять.
черт )) в моей команде средний разработчик знает банковско-финансовую сферу чуть лучше среднего юзера в стой стороны ) Он не знает только того, что получается с опытом работы там, кейсы и ньюансы, это да. Но матчасть — все же получше. Но это редкое исключение.
каким образом цели и ценности банка становятся целями и ценностями конкретных людей
В статье я писал только про ценности людей. Не говорил, что их нужно под кого-то подстраивать. Я против этого. Ими нужно просто делиться. Так возникает доверие между людьми.
У банка, кстати, тоже есть ценности, от которых я бы не стал открещиваться – они весьма разумны и и мне близки. Зная ценности банка, я понимаю, что в целом нахожусь в дружелюбной среде. Так я чуть больше доверяю банку.
чего это вдруг мне должно быть интересно снижать чьи-то операционные расходы или увеличивать маржинальность
А зачем люди играют в шахматы? Исследуют связь между архитектурой ПО и абстрактной алгеброй? Стреляют по банкам в тире (ведь можно и в потолок стрелять)? Иметь цель – это всегда лучше, чем жить без цели.
В статье я также указал, что команде полезно определить свои собственные цели. Они будут ближе, понятнее, и при этом наполнят работу смыслом.
командная работа это когда люди сами задачи себе берут. самим себе задачи придумывать
В моей статье нет таких тезисов. Возможно, Вы меня неправильно поняли.
Иметь цель – это всегда лучше, чем жить без цели.
Цели при этом должны быть достойными, иначе и принять очередную дозу героина — тоже цель (а что, за этим спринтом будет следующий...). И цели банкира или иного капиталиста на рубеже переломного (когда на носу новая Великая Депрессия, усугубленная проблемами экологии и ядерного оружия) десятилетия XXI века — уже не могут считаться достойными.
И попытаюсь ответить на ваши вопросы основываясь на своём опыте. Год назад я сменил место работы. Мне очень повезло попасть в команду, которую собирали с нуля.
У нас нет скрама, спринтов и бэклога. Зато есть понимание бизнес-требований продукта каждым членом команды. Есть глубокое понимание того, что важно на данный момент, почему мы работаем над той или иной задачей и какова конечная цель.
У нас нет утренних пятнадцатиминутных стендапов — мы сидим на расстоянии вытянутой руки друг от друга и постоянно общаемся. Мы любим парное программирование, а ещё больше мы любим программирование толпой (mob programming). Мы хорошо знаем, что совершаем кучу глупых ошибок и что вместе мы умнее, внимательнее, сильнее.
У нас нет проблем с деплоем — от коммита до деплоя в продакшн проходит не более 10 минут. У нас практически нет веток — они живут максимум сутки и то — для того, чтобы недоделанное мною вечером, мог продолжить и залить коллега, приходящий рано утром. А баги фиксятся здесь и сейчас. Какой смысл разрабатывать новую фичу, если в программе содержится ошибка и мы о ней знаем?
Да и обособленных ретроспектив, как вы наверное уже поняли, тоже нет. Процесс построен так, чтобы получать обратную связь в наикратчайшие сроки, делать выводы, обсуждать и воплощать новые идеи в жизнь.
НЛО прилетело и опубликовало эту надпись здесь
Пока код свеж, а проект мал. Потом он вырастает до маленького (иногда маленького) монстра, проходит 5 лет и вышеописанная идиллия ломается :)
Я спрашивал, с какими возражениями против Agile сталкивались Вы. Но Вы описали практически идеальный Agile.
Что нужно, чтобы к такому придти? (за исключением везения)
Нужно доверие "сверху" и желание "снизу". Доверие менеджеров команде профессионалов и доверие членов команды к менеджерам и друг к другу.
В противном же случае, если у менеджера продукта в голове Скрам, и спринты ему необходимы как мана небесная — это плохо. Если у разработчиков отношение, как писали выше, "работать на дядю и делать таски записанные в бэклоге" — это ещё хуже.
Как писали в обсуждении — дело в культуре. Культуру не изменишь, поменяв скрам на канбан.
Мне кажется, что рабочий вариант при такой ситуации — выделить маленькую мотивированную команду из 3-4 человек, пересадить их спина к спине в отдельное пространство и дать им карт-бланш на пол-года. Пусть пробуют новые процессы, подходы к разработке, DDD, DevOps. Пусть тратят своё время на совместный просмотр лекций (или котиков).
У такой команды безусловно должны быть цели и сроки, должна быть отчётность. Но вместо категорических вопросов из серии "почему вы не работаете над вот этой очень_нужной_фичей?", должны быть "ребята, как ваши коллеги и компания может вам помочь?".
А дальше — смотреть по результатам. Если эксперимент удался — внедрить в команду ещё 1-2 человека. Дать им поработать ещё пол-года. Потом разбить команду на две и внедрить в каждую новую команду новых людей. Буквально — распространять новые практики как вирус :) И стараться не переусердствовать, влив в команду больше новых людей, чем она может "переварить".
Золотые слова.
Именно в таких условиях вырастают специалисты высочайшего уровня. И именно эти условия большая часть бизнеса себе позволить не может. И это трагедия. Оттого у нас людей, которые могут что-то сложнее формочки для таблички из БД сделать днём с огнём не найти.
Замечательное предложение, и я даже разок в приближенных к таким условиям работал! Одна беда — это описание социализма или даже коммунизма, где люди могут творить, но никак не капитализма, где "бизнес" вынуждает зарабатывать деньги.
В нашей компании (которая, на минуточку, вообще строительством и проектированием занимается, но имеет отдел разработки) тоже вот начитались/наслушались про Agile и повсеместно пытаются его воткнуть во все проекты.
И недавно я подключился к проекту, который ведется по спринтам, имеет достаточно крупную команду (11 человек для этого проекта — достаточно крупно).
И знаете — это достаточно ужасно!
Все комментарии выше (да и сама статья) не затронули самое главное — те минусы, которые описаны в самом начале. Причем, статья должна была ответить как превратить их в плюсы, но ответа я так и не увидел.
Самое первое, что я почувствовал — работа по спринтам с задачами напрочь убивает творчество в работе. А значит, постепенно и мотивацию. И все эти скрам-мастера не смогут это изменить, так как они свято верят, что все эти принципы Agile по-умолчанию должны мотивировать участников. А вот хрен там. Я не творю — я просто выполняю задачу.
Далее — таск-трекеры и стендапы. Я не могу взять в толк зачем нужно второе, когда есть первое??? Все задачи ставятся в таск-трекере, но при этом команда КАЖДЫЙ день устраивает стендап (у нас это созвон, так как часть команды является аутсорсерами с другого города). А она из себя представляет знаете что? Правильно — пересказывание написанного в таск-трекере! Нахрена это надо? Пустая трата времени.
Причем, что забавно, я всячески избегал этих созвонов, пока меня начальник отдела не заставил. Agile-мотивация? Не, не слышали.
Третье — как продолжение второго — да, не все любят разговаривать! Даже не в плане того, что это пустая трата времени, а в плане того, что некоторым от этого не комфортно! Но тебя никто не слушает, говоря «ничего страшного — втянешься». Нет, я не могу втянуться в то, что каждый день меня нервирует!
А самое забавное — мне еще и высказывают потом за то, что я не умею общаться! Ну что поделать — я зарплату получаю за написание кода, а не за умению разговаривать.
Про оценку времени выше уже говорили — это вообще прям бесит. Тебе ставят абстрактную задачу и тут же ждут от тебя оценки времени! Да бывает, что маленькая задача может загнать в недельный тупик. Но этого не узнать, пока не начать.
А вот с ответственностью — вот тут все понятно! Как только случается проблема, сразу находится участник команды, который отхватит пиз… лей. При этом вся бирюзовость исчезает и организация моментально становится красной =))
Фууух — высказался. Кратко, хотя по каждому пункту еще можно расписать с примерами. А за компанию еще и ссылку на статью скинул нашему скрам-мастеру — пусть почитает
И недавно я подключился к проекту, который ведется по спринтам, имеет достаточно крупную команду (11 человек для этого проекта — достаточно крупно).
И знаете — это достаточно ужасно!
Все комментарии выше (да и сама статья) не затронули самое главное — те минусы, которые описаны в самом начале. Причем, статья должна была ответить как превратить их в плюсы, но ответа я так и не увидел.
Самое первое, что я почувствовал — работа по спринтам с задачами напрочь убивает творчество в работе. А значит, постепенно и мотивацию. И все эти скрам-мастера не смогут это изменить, так как они свято верят, что все эти принципы Agile по-умолчанию должны мотивировать участников. А вот хрен там. Я не творю — я просто выполняю задачу.
Далее — таск-трекеры и стендапы. Я не могу взять в толк зачем нужно второе, когда есть первое??? Все задачи ставятся в таск-трекере, но при этом команда КАЖДЫЙ день устраивает стендап (у нас это созвон, так как часть команды является аутсорсерами с другого города). А она из себя представляет знаете что? Правильно — пересказывание написанного в таск-трекере! Нахрена это надо? Пустая трата времени.
Причем, что забавно, я всячески избегал этих созвонов, пока меня начальник отдела не заставил. Agile-мотивация? Не, не слышали.
Третье — как продолжение второго — да, не все любят разговаривать! Даже не в плане того, что это пустая трата времени, а в плане того, что некоторым от этого не комфортно! Но тебя никто не слушает, говоря «ничего страшного — втянешься». Нет, я не могу втянуться в то, что каждый день меня нервирует!
А самое забавное — мне еще и высказывают потом за то, что я не умею общаться! Ну что поделать — я зарплату получаю за написание кода, а не за умению разговаривать.
Про оценку времени выше уже говорили — это вообще прям бесит. Тебе ставят абстрактную задачу и тут же ждут от тебя оценки времени! Да бывает, что маленькая задача может загнать в недельный тупик. Но этого не узнать, пока не начать.
А вот с ответственностью — вот тут все понятно! Как только случается проблема, сразу находится участник команды, который отхватит пиз… лей. При этом вся бирюзовость исчезает и организация моментально становится красной =))
Фууух — высказался. Кратко, хотя по каждому пункту еще можно расписать с примерами. А за компанию еще и ссылку на статью скинул нашему скрам-мастеру — пусть почитает
стендапы нужны, что бы сразу отлавливать проблемы с задачами. что бы разработчик, который взяв на себя задачу, которую оценили в 1 рабочий день, сразу сообщил, что у него с ней проблемы. не прятался по углам, а пообщался с командой, менеджером, нашли в чем причина проблемы, возможно подключили других разработчиков, или менеджера, или увели выше к заказчику.
про оценки — оценки делаются по принципу «а какая задача была похожа на эту». делайте декомпозицию, получайте самые мелкие кусочки, которые похожи на «сделанное раньше», и оценивайте. нехватает данных — просите нормальной постановки задачи, а не нечто абстрактное.
про оценки — оценки делаются по принципу «а какая задача была похожа на эту». делайте декомпозицию, получайте самые мелкие кусочки, которые похожи на «сделанное раньше», и оценивайте. нехватает данных — просите нормальной постановки задачи, а не нечто абстрактное.
НЛО прилетело и опубликовало эту надпись здесь
О проблемах с задачей можно сразу узнать из трекера, как уже написали в комменте выше и спросить у соответствующего разработчика лично что не получается, почему задача всё ещё в колонке doing.
Это противоречит тезису "Правильно — пересказывание написанного в таск-трекере!"
Т.е. в вашем случае impediment находится не в трекере, а в голове разработчика, из которой требуется дополнительное усилие, чтобы ее извлечь.
Описанный вами способ узнавания о препятствиях (impediments) так же ограничивает перечень препятствий только теми, которые выражаются в видимой задержке исполнения задачи в масшатбах рабочего дня (т.е. сами задачи должны быть записаны с длительностью день или меньше). Еще требует дополнительной коммуникации в том случае, если нужна помощь команды.
Наверняка можно организовать то же самое что и в случае стендапа через трекер и чаты, только это будет требовать больше писанины и самодисциплины от участников.
Вот именно, чтобы не было вопросов со стороны менеджмента (или на них был готовый ответ у любого из команды) и проводятся дэйлики, чтобы команда разработки знала о проблеме и решила что с ней делать. "Втык" если и будет, то когда и если команда решит менеджменту сообщить, что возможно/скорее всего/точно цели спринта достигнуты не будут.
Да, на стендапе говоришь публично, и иногда тебя это спасает, а вечно кормящие завтраками коллеги задумываются о том, чтобы сделать связанные с твоим кодом задачи.
В моем проекте сейчас работают: 2 человека, делающие плагин-клиент под Revit. Причем, один я, а у второго я ПР принимаю. 2 тестировщка, 2 фронтендера, которые пилят web-часть и еще несколько участников, которые занимаются бэком.
Я каждый день слушаю что они делали вчера и что будут делать сегодня и лично мне, для работы со своей частью проекта, эта информация не нужна. От слова совсем!
Вопрос — зачем мне это? Зачем я трачу каждый день свое время, получая при этом порцию информации, мне совершенно не нужной?
Нет тут никаких плюсов или мои управленцы неправильно поняли с кем нужно проводить стендапы.
А про оценки — вот и вы не поняли мою мысль про творчество в работе. Если я уже что-то подобное делал много раз и теперь повторяю (ну или очень похожие), то моя работа перестает быть увлекательной и превращается в банальное кодерство. Мне не нужно придумывать, не нужно решать новое — мне просто нужно прикинуться конвейером и делать похожее
Я каждый день слушаю что они делали вчера и что будут делать сегодня и лично мне, для работы со своей частью проекта, эта информация не нужна. От слова совсем!
Вопрос — зачем мне это? Зачем я трачу каждый день свое время, получая при этом порцию информации, мне совершенно не нужной?
Нет тут никаких плюсов или мои управленцы неправильно поняли с кем нужно проводить стендапы.
А про оценки — вот и вы не поняли мою мысль про творчество в работе. Если я уже что-то подобное делал много раз и теперь повторяю (ну или очень похожие), то моя работа перестает быть увлекательной и превращается в банальное кодерство. Мне не нужно придумывать, не нужно решать новое — мне просто нужно прикинуться конвейером и делать похожее
Зачем ждать очередного стендапа целый рабочий день, когда можно прямо сейчас про проблемы поделиться в общем чате, либо сказать коллегам неподалёку?
Блин, да когда оценку времени просят для абстрактной задачи, это делают не для того, чтобы ответственность навязать, а чтобы задачу из абстрактной сделать конкретной.
Классический диалог-пример, проблему в котором решает оценка времени:
- Нам нужно сделать X.
Вася: - Хорошо, я сделаю.
- Сколько времени займет?
- Ну не знаю...
- А все-таки?
- Ну, может, неделю.
- А можно детальнее оценить и в часах?
- Ну что привязался. Ладно, хорошо, а что там нужно сделать-то? (БИНГО!)
- Сделать нужно A и B.
- А C надо? Самая проблема в C.
- Нет, C не надо совсем.
- А, ясно. Ну тогда — 4 часа.
Понимаете? Просьба оценить в часах стимулирует общение и детальную проработку задачи еще до того, как над ней началась работа. Это самый эффективный способ вытащить инженера из раковины.
Только обычно нет В и С. Есть только абстрактное А
И все эти оценки превращаются в тыкву, если задача нетривиальна. Типа есть 3 алгоритма, последовательно работающие на определённых данных, и их нужно оптимизировать так, чтобы они всегда отрабатывали за <0.5с. Или поиск какого-нибудь хитрого бага.
НЛО прилетело и опубликовало эту надпись здесь
А никто не знает, сложная она или нет. Всё может кончится ровно одной простой оптимизацией одного из трёх алгоритмов. Проблема не в сложности, а в невозможности эту сложность оценить.
Оцените с «запасом». В конце-концов если вдруг окажется проще чем думали, то добавить новые задачи в спринт вы всегда сами можете. Это если мы про скрам говорим.
Другое дело что если у вас большинство задач такие, то возможно вам стоит не по скраму работать, а например какой-нибудь канбан взять.
П.С. Но это в всё равно будет головной болью. Даже если вы водопад делать будете. Просто в водопаде это будет головной болью только для тимлида, который эти сложности будет в одиночку оценивать…
Другое дело что если у вас большинство задач такие, то возможно вам стоит не по скраму работать, а например какой-нибудь канбан взять.
П.С. Но это в всё равно будет головной болью. Даже если вы водопад делать будете. Просто в водопаде это будет головной болью только для тимлида, который эти сложности будет в одиночку оценивать…
НЛО прилетело и опубликовало эту надпись здесь
Оценка задачи в стори-поинтах должна включать в себя:
- неопредленность, неясность
- риски, что что-то пойдет не так
- собственно трудозатраты
Если удалось закрыть задачу за меньшее число SP – это нормально. Это всё будет учтено в velocity, усреднено по всему спектру решаемых задач, и поможет более точно спланировать следующий спринт.
НЛО прилетело и опубликовало эту надпись здесь
Где это именно "считается"? Участвовал в самом настоящем planning poker, с картами — дык это часы.
В скрам гайде не определяется как именно проводить оценки
Но достаточно популярное мнение использовать условные единицы (изначально это были "идеальные часы", насколько я помню, потом стали "стори поинты", в частности, потому, что народ не понимал, что был соблазн воспринять "идеальные часы" как реальные.)
Вот, например, мнение Сазерленда
Знаете что я на это отвечу, от лица, пожалуй, много кого? Вот эта описанная безответственность была применена при разработке CGI::WebIn/WebOut и прочего "как в php", в результате получилась такая херня. которую людям приходится разгребать и спустя много лет. В такие моменты хочется, чтоб карма существовала в реальном, мире, дабы думали перед тем как делать.
Спасибо. Всё очень четко и понятно. Именно это я и просил.
Ритуалы вызывают у Вас раздражение вполне закономерно. Вы не понимаете, зачем они нужны. И, вполне вероятно, даже тот, кто у вас их проводит, тоже не понимает, зачем. И никто Вам этого не объяснил.
Объяснения у ритуалов в принципе есть, их можно найти в книгах, статьях, обсуждениях. Могу повторять и пересказывать, но Вы это и так слышали. Вы не примете эти объяснения от того, кому не доверяете (и у Вас нет ни малейшего основания доверять мне).
Проблема Вашего раздражения не в аджайле, а в том, что Вы не доверяете своей команде, своему начальнику (судя по упоминаниям, вполне обоснованно), и разумеется своему скрам-мастеру. Скорее всего взаимно.
Поэтому я и остановился в статье на командной работе. Это главное.
Ритуал — это что-то, имеющее отношение к религии?
Если я не знаю значения слова, я обычно смотрю его в словаре.
Вот, например, в википедии
Практически все источники допускают нерелигиозное трактование понятия «ритуал» и, таким образом, полное отождествление его с понятием «обряд»[1][4][2][3]. Тем не менее, например, Ю. В. Чернявская проводит чёткую границу между ритуалом и обрядом, определяя их как равнозначные формы преемственности культуры и дополняя их третьей формой — обычаем. При этом обряд определяется как «десакрализованный ритуал»[7].
Независимо от определений всё это явно попахивает сектантством.
Конечно. Я согласен.
Се́кта (сред.-в. лат. secta — школа, учение, от лат. sequor — следую) — понятие (термин), которое используется для обозначения религиозной, политической, философской или иной группы, иногда отделившейся от основного направления и противостоящей ему, или указания на организованную традицию, имеющую своего основателя и особое учение[1][2]
Я могу найти нечто общее между сектой и agile. Как и практически между сектой и любым другим направлением мысли.
Да и другие люди тоже бывают "java guru", "C# pundit" и прочее. Религия — достаточно частая метафора.
Вы тоже почему-то в этом комментарии не смогли объяснить. Нет, разумеется, я как человек, потративший несколько лет жизни на психологию как хобби, имею объяснение. Но оно не в пользу скрама, а ровно наоборот.
Далее — таск-трекеры и стендапы. Я не могу взять в толк зачем нужно второе, когда есть первое???
Отвечу Вам с точки зрения психологии, которую это неявно подразумевает, но обычно не осознается (и соответственно не озвучивается). Это — ритуал. И, как любой подобного рода ритуал, служит незаметной, исподволь и потихоньку, промывке мозгов в нужном направлении. Примерно как в армии — круглое тащить, квадратное катить, "мне не нужно, чтоб работало, мне нужно, чтоб вы за@бались". Там это служит довольно явственной цели воспитания нерассуждающего исполнителя приказов (хотя подавляющим большинством так и не осознается), здесь, поскольку труд интеллектуальный, производится более тонко.
Причём здесь психология и промывка мозгов? Это просто две разные вещи с разными задачами.
Таск-трекер это банальная организация тасков. То есть чтобы команда и/или каждый человек в отдельности могли видеть какие там таски есть и кто над каким работает или собирается работать. И это нужно например чтобы банально не забыть какой-нибудь таск. Или чтобы два человека не начали делать один и тот же таск параллельно.
Стендапы и дэйли нужны для того чтобы понять нет ли у кого-то каких-то проблем, которые мешают им в актуальной работе. И для того чтобы понять может ли ему помочь команда. И если да, то как.
А если команда помочь не может, то чтобы запросить помощи «извне» или чтобы сообщить о проблеме «наверх».
Другое дело что в куче фирм взяли за моду на стендапах играть в игру «перечисли что ты уже сделал и расскажи что ты собираешься делать». И люди вместо того чтобы просто сказать что у них проблем нет, начинают по полчаса рассказывать о том чем они там конкретно занимаются…
Таск-трекер это банальная организация тасков. То есть чтобы команда и/или каждый человек в отдельности могли видеть какие там таски есть и кто над каким работает или собирается работать. И это нужно например чтобы банально не забыть какой-нибудь таск. Или чтобы два человека не начали делать один и тот же таск параллельно.
Стендапы и дэйли нужны для того чтобы понять нет ли у кого-то каких-то проблем, которые мешают им в актуальной работе. И для того чтобы понять может ли ему помочь команда. И если да, то как.
А если команда помочь не может, то чтобы запросить помощи «извне» или чтобы сообщить о проблеме «наверх».
Другое дело что в куче фирм взяли за моду на стендапах играть в игру «перечисли что ты уже сделал и расскажи что ты собираешься делать». И люди вместо того чтобы просто сказать что у них проблем нет, начинают по полчаса рассказывать о том чем они там конкретно занимаются…
Стендапы и дэйли нужны для того чтобы понять нет ли у кого-то каких-то проблем, которые мешают им в актуальной работе. И для того чтобы понять может ли ему помочь команда. И если да, то как.
Для этого гораздо эффективнее не дэйли-стендапы, а тематические чаты (или иной более подходящий аналог в форме переписки, вплоть до email-рассылок внутренних), где может прочитать вся команда в то время, когда это удобно каждому, где можно делать это с примерами кода и прочего.
Другое дело что в куче фирм взяли за моду на стендапах играть в игру «перечисли что ты уже сделал и расскажи что ты собираешься делать».
Ну да, в моем опыте только так и было.
Для этого гораздо эффективнее не дэйли-стендапы, а тематические чаты
Вот такое это точно без меня. Мы одно время работали с удалёнщиками в команде и пытались все митинги проводить с ними в чатах и/или видеоконференциях. Не сказал бы что было особо удобно.
Ну да, в моем опыте только так и было.
Ну я бы такое «настоящим скрамом» называть не стал.
Как по мне, то сакрального глубинного психологического какого значения дэйлики не имеют. Но это не просто отчёт "что сделал вчера, что буду делать сегодня" (это как раз в треккере можно посмотреть), это точка озвучивания проблем, мешающих достижению целей спринта.
Вот он, отличный пример этой самой неявной промывки мозгов. Не существует никаких "целей спринта", и в принципе не может быть (иначе это перестанет быть спринтом). Это всего лишь выборка задач из бэклога, жестко ограниченная временем исполнения, а не целью — что для любых условий, отличающихся от идеальных, противоречиво. Тут как с разницей релизов в софта в нормальные времена, и нынешние "гоним на-гора семь мажорных версий браузера в год!" — если раньше ставились некие цели к релизам, и их исполнение могло требовать разных усилий в зависимости от сложившихся обстоятельств, а значит и разного времени — то теперь эти "релизы" являются просто по сути снапшотами, в результате объем новых фич в них может быть совершенно разный.
И вот, вместо понимания этого, дэйли как ритуал исподволь создают впечатление, что эти цели (и прочие хорошие слова) — как будто бы есть.
Не существует никаких «целей спринта», и в принципе не может быть (иначе это перестанет быть спринтом).
Есть вполне себе устоявшееся выражение «sprint goals». Которое в общем-то есть и в описании самого скрама. И «цели спринта» это на мой взгляд не самый худший вариант перевода.
Есть разные подходы. У нас практика в этом году показала, что фокус на 1-3 целях позволяет работать эффективней. Как минимум меньше переключения контекстов по сравнению с ситуацией, когда на тебе 10-15 тасок за две недели, никак не связанных.
Последний заказчик недавно «порадовал». Он весь такой был модный-стильный-молодежный, аджайл и все такое, а потом PM звонит и говорит, «ну да, но нам нужно план на полгода вперед с майлстоунами». Мы такие — «говно вопрос — присылайте детальный FSD, как согласуем — так сразу дадим вам план на полгода». Тут-то они и стухли…
Правильный Agile — это такой метод работы, с которым разработчик об этом не задумывается и уж тем более не напрягается. Всё остальное — это днище-управленцы и от таких нужно бежать, а лучше сразу к таким не попадать.
В общем за аглай конечно должны доплачивать минимум вдвойне, тогда может будет дело, но я бы и за двойную оплату не согласился.
Есть ведь всякие трекеры канбаны и там видно, какая задача у кого зависла, если волнуют почему, всегда можно разобраться, не затрагивая лишний народ, заказчик ведь даже примерно не отдупляется, во что ему обходится лишний раз отвлечь разраба от текущих дел, отвлек не вовремя и получил задержку выполнения, совсем не равную тому времени, на которое отвлек, мысль и настроение и желание сделать нормально ушли моментально и когда вернуться хз, кому знакомо?
Есть ведь всякие трекеры канбаны и там видно, какая задача у кого зависла, если волнуют почему, всегда можно разобраться, не затрагивая лишний народ, заказчик ведь даже примерно не отдупляется, во что ему обходится лишний раз отвлечь разраба от текущих дел, отвлек не вовремя и получил задержку выполнения, совсем не равную тому времени, на которое отвлек, мысль и настроение и желание сделать нормально ушли моментально и когда вернуться хз, кому знакомо?
У меня вот вопросы вызывает Kanban для больших проектов. У нас есть система управления проектами, а команда — человек 20. Висит доска на другом этаже.
В первый опыт Канбана стендапы растягивались на час, потому что номера тикетов нужно было найти, а имеющиеся стикеры передвинуть или переписать (потому что клей на них не расчитан на постоянное перетягивание).
Второй раз поставили одного из разработчиков, который печатает себе страницы из системы управления проектами, и ориентируясь по ним переклеивает. Все это занимает где-то полчаса до стендапа.
Менеджер доволен, ведь у него есть «видение, как движется проект».
***
В сериале «Кремниевая долина», как ни странно, доска им помогала. У них не было развернуто никаких систем, им не нужно было писать свои подвиги в тикеты. Им просто нужно было синхронизировать работу друг с другом.
Мое впечатление — Канбан-доски придумали в эпоху, когда планирование шло на бумаге. Но а потом его стали вводить как «прогрессивную методику» больше по привычке.
В первый опыт Канбана стендапы растягивались на час, потому что номера тикетов нужно было найти, а имеющиеся стикеры передвинуть или переписать (потому что клей на них не расчитан на постоянное перетягивание).
Второй раз поставили одного из разработчиков, который печатает себе страницы из системы управления проектами, и ориентируясь по ним переклеивает. Все это занимает где-то полчаса до стендапа.
Менеджер доволен, ведь у него есть «видение, как движется проект».
***
В сериале «Кремниевая долина», как ни странно, доска им помогала. У них не было развернуто никаких систем, им не нужно было писать свои подвиги в тикеты. Им просто нужно было синхронизировать работу друг с другом.
Мое впечатление — Канбан-доски придумали в эпоху, когда планирование шло на бумаге. Но а потом его стали вводить как «прогрессивную методику» больше по привычке.
Есть предположение, что долгие стендапы/встречи возникают, когда количество участников больше 7 — 8 человек, так как каждый хочет высказаться и обсудить.
НЛО прилетело и опубликовало эту надпись здесь
Мало того, что там больше 7-8 человек, так и скоупы у всех разные, и даже разные подпроекты.
В итоге дизайнеру не интересен сетевик, а сетевику не интересны чьи-то проблемы c Java.
В итоге дизайнеру не интересен сетевик, а сетевику не интересны чьи-то проблемы c Java.
Это точно. Помню всю эту смертную скуку на всевозможных стендапах, когда приходится выслушивать по пол часа живоописание «захватывающих» приключений какого-либо девопса, который настраивал какую-то там свою девопскую хрень. Или как какой-либо фронтенд в очередной раз боролся с каким-то там фронтендерским фреймворком (само собой им мой рассказ был так-же неинтересен)
Ну как бы срвсем не удивительно что смертная скука потому стендап он вообще не для этого придуман. Да и длится столько ну никак не должен.
Стендап он скорее для того чтобы понять не будет ли на сегодня каких-то ненужных пересечений в работе(например два человек вдруг стали менять код в одном и том же классе) и есть ли у кого-то проблемы с которыми он не в состоянии справиться сам. По хорошему я бы сказал что при команде в 7-8 человек он занимает где-то 3-5 минут максимум.
И по моему опыту великолепно проходит пока все стоят на кухне и делают себе кофе :)
Стендап он скорее для того чтобы понять не будет ли на сегодня каких-то ненужных пересечений в работе(например два человек вдруг стали менять код в одном и том же классе) и есть ли у кого-то проблемы с которыми он не в состоянии справиться сам. По хорошему я бы сказал что при команде в 7-8 человек он занимает где-то 3-5 минут максимум.
И по моему опыту великолепно проходит пока все стоят на кухне и делают себе кофе :)
Ну, автор статьи поднял вопрос — за что разработчики ненавидят Аджайл. Вот люди и перечисляют за что.
Я так понял в основном за то что под видом Аджайла в большинстве мест внедряют идиотские «клубы анонимных программистов» с бессмысленными стендапами на которых выступает по 20-30 человек (реально доводилось в таких участвовать), с потогонкой, с истеричным сколачиванием фич на костылях, лишь бы успеть за очередной спринт и не получить втык за продолбанные сроки, с кучей прочего карго-культа, бессмысленного и беспощадного.
Поучаствовав во всей этой вакханалии, невольно начинаешь с тоской вспоминать водопад, в котором тебе дают ТЗ и ты просто, блин, спокойно работаешь.
Я так понял в основном за то что под видом Аджайла в большинстве мест внедряют идиотские «клубы анонимных программистов» с бессмысленными стендапами на которых выступает по 20-30 человек (реально доводилось в таких участвовать), с потогонкой, с истеричным сколачиванием фич на костылях, лишь бы успеть за очередной спринт и не получить втык за продолбанные сроки, с кучей прочего карго-культа, бессмысленного и беспощадного.
Поучаствовав во всей этой вакханалии, невольно начинаешь с тоской вспоминать водопад, в котором тебе дают ТЗ и ты просто, блин, спокойно работаешь.
Это в общем-то понятно. Просто лично мне удивительно где был этот самый водопад в котором тебе просто давали спокойно работать. Лично я такого водопада не встречал и в водопаде тоже полно различного бардака и геморроя. Там просто другой бардак и геморрой…
Есть подозрение, что "водопада" в том виде, в каком его рисуют сторонники Agile, никогда не существовало.
В каком «таком»? Когда определеяется ТЗ, а потом проект делается пр этому ТЗ в течении достаточно длительного времени прежде чем клиент первый раз видит какой-то результат?
Такое не только существовало, но и до сих пор вполне себе встречается. И местами это никому и каких-то особых проблем не создаёт.
Такое не только существовало, но и до сих пор вполне себе встречается. И местами это никому и каких-то особых проблем не создаёт.
Канбан-доски придумали в эпоху, когда планирование шло на бумаге.
Именно так и есть. Более того, канбан — это в переводе с японского и есть «карточка»
У меня вот вопросы вызывает Kanban для больших проектов.
Это нормально. Kanban обычно применяется не для того, для чего он был изобретен. Канбан в разработке — это инструмент управления ресурсами.
У вас есть примерно одинаковые по трудозатратам задачи с одинаковыми фазами. Вы выкладываете их на канбан доску и смотрите сколько задач в какой фазе. Если где-то скапливается слишком много задач, значит там болтнэк, туда надо больше ресурсов.
Я вот пока не видел живой компании, где канбан применялся по назначению.
И вам не нужно делать ежедневный стенд-ап у этой доски, это инструмент для менеджера
И правильно, что у вас вопросы. Но вопросы у вас должны быть не к инструменту, а к менеджерам, которые не умеют эти инструменты применять.
В сериале «Кремниевая долина», как ни странно, доска им помогала.
Еще бы)
У меня вот вопросы вызывает Kanban для больших проектов. У нас есть система управления проектами, а команда — человек 20. Висит доска на другом этаже.
Смысле на другом этаже? Это же в системе, типа трелло какой нибудь или битрикс24, если там такая толпа народу бейте на несколько вспомогательных досок, а на главную результаты со вспомогательных, у каждой группы свои задачи, а в кучу их главный архитектор проекта собирает или типа него кто-то.
Любопытно, как много негативных комментариев в сторону эджайла\скрама и как мало положительных. На мой взгляд новомодные методологии эджайла служат целям найти разумный баланс между управляемостью и комфортом разработки. В то же время, баланс этот слишком хрупкий для того, чтобы выдержать изменение хотя бы одного элемента, как, например, штрафы за проваленный спринт или оценка задач в часах.
разумный баланс между управляемостью и комфортом разработки
А кто сказал, что это две разные полярности? Наоборот, когда чётко понятно, куда плывём, то это очень комфортно. Только не просите ускоряться.
Да потому что agile всегда превращается в задницу.
как правило планирование берет на себя менеджмент.
В итоге имеем
— почти всегда хреново спланированный спринт (задачи не правильно побиты, не все поставлены).
— хреновое описанием задач, менеджмент просто физически не успевает описывать что он хочет от разрабов.
— разрабы вынуждены добавлять задачи и баги прям в спринт, или делать действительно нужные задачи которые нужно выполнить до поставленных а время списывать на поставленные.
Это все не лучшим образом сказывается на диаграммах выгорания,
реальные результаты подменяются формальными диаграммами
все сроки идут по бороде.
Постоянный стресс
Этот бардак повышает текучку.
Недоукомплектованность штата (разрабы, тестеры, девопсы) лишь обостряют проблемы
как правило планирование берет на себя менеджмент.
В итоге имеем
— почти всегда хреново спланированный спринт (задачи не правильно побиты, не все поставлены).
— хреновое описанием задач, менеджмент просто физически не успевает описывать что он хочет от разрабов.
— разрабы вынуждены добавлять задачи и баги прям в спринт, или делать действительно нужные задачи которые нужно выполнить до поставленных а время списывать на поставленные.
Это все не лучшим образом сказывается на диаграммах выгорания,
реальные результаты подменяются формальными диаграммами
все сроки идут по бороде.
Постоянный стресс
Этот бардак повышает текучку.
Недоукомплектованность штата (разрабы, тестеры, девопсы) лишь обостряют проблемы
Потому что это должен делать не менеджмент, а сама команда.
НЛО прилетело и опубликовало эту надпись здесь
Да потому что agile всегда превращается в задницу.
Очень категоричное заявление. Я допускаю что аджайл часто «превращается в задницу». Но точно не всегда. Хотя потому что мне известны случаи когда этого не произошло.
П.С. У меня всё больше и больше подозрение что аджайл «превращается в задницу» когда натыкается на уже неоднократно описанное на хабре «красное управление».
Этот баланс выдерживает многое, но есть вещи просто несовместимые. И, увы, такие встречаются часто.
TLDR: нужно искать баланс, а не бездумно всё подряд применять.
В целом не стоит применять бездумно все практики подряд из Agile, там действительно есть много хорошего, но оно не все командам и инженерам подходит — это отлично видно из комментариев.
К сожалению холакратия и всё что было описано в статье будет хорошо работать только с профессионалами — экстравертами и командой размером не более 8 человек. Реальность такова, что очень сложно собрать и содержать такую команду.
Самое классное, что есть в Agile — это процесс самосовершенствования внутри команд (ретроспектива). Внутри этого процесса можно обсудить принимает ли решения один человек или это делает команда самостоятельно. Нет смысла человека заставлять быть командным, если он этого не хочет. Если навязывать ему ценности команды/компании, либо его выгонят или он сам уйдёт, потому что цели будут разные — у него писать код, дизайнить или деплоить, а у вас заработать X к дате Y. И вы и он будете правы, но вот над чем стоит задуматься: будет ли быстрее/дешевле будет сделать продукт наняв интровертов и раздав им задачи? Или всё же собрать команду, дать цель и пускай она сама найдёт к ней маршрут?
P.S. У нас в команде мы идём к холакратии, однако я не за и не против, для меня это просто один из видов управления внутри организации
Да, настоящую команду собрать сложно. Но необязательно нужны экстраверты.
Я, например, однозначный интроверт. Общение меня не заряжает и не заводит, наоборот, утомляет. Но это не избавляет меня от того, чтобы иметь мнение по тем или иным вопросам. И я не против это мнение высказать, если меня спросят (и даже если не спросят).
Нужно чтобы была цель и желание.
Индустрия придумала какой-то стереотип и лепит его без ума.
HR почему то решила, что модное слово должно привлечь больше кандидатов. Ну как почему, менеджеры сказали: "Мы работаем по Aglie!", она слышала, что это типа круто, вот и поставила в объявление.
Топикстартер тоже путается в терминах. Прыгает с Agile на Scrum и обратно. По сути, подразумевает везде Scrum, но пишет при этом Agile.
Agile — это набор из 4 ценностей. Scrum — методология разработки. Авторы Scrum утверждают, что используя эту методологию компания сможет реализовать Agile ценности. Возможно у них другой опыт, но на своем опыте я этого не ощутил.
Обычно получается, что компания и менеджеры не обладая набором Agile ценностей выборочно внедряют Scrum практики и дальше гордо объявляют, что теперь они Agile. И HRам говорят. А в результате получается то, что написано в посте.
И, конечно, это им Agile виноват. Не менеджеры)
Agile – маркер хаоса
Очень точное описание действительности
неправильной ассоциации Agile с бардаком
Очень правильные ассоциации. Людей просто так не обманешь. Я обычно говорю "Я слышу Agile, но я не вижу Agile"
Перегибы на местах возникают из-за неправильного понимания Agile руководителями компаний и IT-департаментов.
Очень точное замечание. Но только эти перегибы приняли уже настолько массовый характер, что культурологическое значение термина изменилось. Это как социализм. Вроде звучит неплохо, а на практике так много людей угробили, что, пожалуй, ну его.
Сейчас у термина Agile поменялось значение. Теперь это не то, что было описано в Agile Manifesto. Это бардак и хаос. Постмодернизм в чистом виде)
(напишите, пожалуйста, в комментариях, какие еще жалобы слышали вы)Milfgard — существуют ли бизнесы, где продавцы умоляют покупателей: «пожалуйста, купите у нас хоть что-нибудь»?
Мне кажется, ситуация является прямым продолжением бездумного хайпа вокруг гибких/итерационных технологий разработки, который мы имели лет 5 назад.
Вспоминайте — все кому не лень вешали себе ярлыки «мы работаем по эджайлу», хотя у многиз даже итерационных процессов разработки и в помине не было.
Что в итоге? Молодые, насмотревшись на это, закрепили у себя в голове ассоциацию — «если говорят про agile — значит 90% пытаются обмануть».
И я даже из в этом не просто понимаю, я их поддерживаю.
К молодым, тоже, есть вопрос вида — а вы разобраться в сути вопроса не пробовали? (потому что, увы, не разбирались в большинстве своем).
Но повторюсь, что когда я вижу компанию, которая в вакансиях в первую очередь говорит про модные хайпанутые в этом сезоне технологии, процессы, или вещи — не важно будет это «эджайл», «девопс», «ангуляр на первом месте», «всем сотрудникам макбуки», «работаем только в идее», «git-flow» и тд и тп. — степень доверия к вакансии и к компании падает в разы, пропорционально числу использованных «слов для привлечения внимания». Не первостепенные это вещи. ;)
Как с бороться с негативов в сторону «эджайла» — не знаю.( и надо ли — «бороться»? пусть будет урок — вы хайпанули? попытались легковесную не масштабируемую технологию воткнуть везде? использовали «эджайл» как рекламный слоган в вакансиях для фактического обмана соискателей? — «получите негатив, распишитесь вот тут»… и пусть это будет памятник всем кто решил верить рекламе и хайпу)…
Наверное, надо, в первую очередь учить думать, не вестись на хайп, не раздувать хайп, не подменять понятия, вести разъяснительную работу.
В первую очередь — представлять из себя разумного рассуждающего человека.
И не пытаться выставлять очередную технологию как «мировую вакцину» — не пихать ее везде и всегда. Технология, процесс — это не серебрянная пуля. это просто тезнология, как и все технологии ограниченная.
Пять лет назад пихали эджайл во все дыры? — пихали. Даже туда, где эджайл не применим в силу условий среды; совершенно не разбираясь и не думая о границах применимости технологии…
Получили (ну наконец то!) негативный фидбек. Все закономерно, «шила в мешке не утаить», «нельзя обманывать всех людей все время» и тд.
Эджайл хорошая технология, но и как всякая технология она применимы далеко не во всех условиях, не на всех типах проектов. Об этом надо помнить, и, имхо, в таком направлении вести разъяснительную работу, а не пытаться обелить «имя эджайла» разбирая конкретные вопросы за и против.
Эджайл уже стал жертвой хайпа, извратившего суть термина. Ближайшее время это не изменится. Тут только разъяснять конкретным людям и объяснять про то, что «вы знаете о том, когда надо прекратить применять эджайл» и переходить на более тяжеловестный или другие по структуре процессы, и, в том числе, — доказывать, что вы знаете на какие процессы переходить и когда.
Вспоминайте — все кому не лень вешали себе ярлыки «мы работаем по эджайлу», хотя у многиз даже итерационных процессов разработки и в помине не было.
Что в итоге? Молодые, насмотревшись на это, закрепили у себя в голове ассоциацию — «если говорят про agile — значит 90% пытаются обмануть».
И я даже из в этом не просто понимаю, я их поддерживаю.
К молодым, тоже, есть вопрос вида — а вы разобраться в сути вопроса не пробовали? (потому что, увы, не разбирались в большинстве своем).
Но повторюсь, что когда я вижу компанию, которая в вакансиях в первую очередь говорит про модные хайпанутые в этом сезоне технологии, процессы, или вещи — не важно будет это «эджайл», «девопс», «ангуляр на первом месте», «всем сотрудникам макбуки», «работаем только в идее», «git-flow» и тд и тп. — степень доверия к вакансии и к компании падает в разы, пропорционально числу использованных «слов для привлечения внимания». Не первостепенные это вещи. ;)
Как с бороться с негативов в сторону «эджайла» — не знаю.( и надо ли — «бороться»? пусть будет урок — вы хайпанули? попытались легковесную не масштабируемую технологию воткнуть везде? использовали «эджайл» как рекламный слоган в вакансиях для фактического обмана соискателей? — «получите негатив, распишитесь вот тут»… и пусть это будет памятник всем кто решил верить рекламе и хайпу)…
Наверное, надо, в первую очередь учить думать, не вестись на хайп, не раздувать хайп, не подменять понятия, вести разъяснительную работу.
В первую очередь — представлять из себя разумного рассуждающего человека.
И не пытаться выставлять очередную технологию как «мировую вакцину» — не пихать ее везде и всегда. Технология, процесс — это не серебрянная пуля. это просто тезнология, как и все технологии ограниченная.
Пять лет назад пихали эджайл во все дыры? — пихали. Даже туда, где эджайл не применим в силу условий среды; совершенно не разбираясь и не думая о границах применимости технологии…
Получили (ну наконец то!) негативный фидбек. Все закономерно, «шила в мешке не утаить», «нельзя обманывать всех людей все время» и тд.
Эджайл хорошая технология, но и как всякая технология она применимы далеко не во всех условиях, не на всех типах проектов. Об этом надо помнить, и, имхо, в таком направлении вести разъяснительную работу, а не пытаться обелить «имя эджайла» разбирая конкретные вопросы за и против.
Эджайл уже стал жертвой хайпа, извратившего суть термина. Ближайшее время это не изменится. Тут только разъяснять конкретным людям и объяснять про то, что «вы знаете о том, когда надо прекратить применять эджайл» и переходить на более тяжеловестный или другие по структуре процессы, и, в том числе, — доказывать, что вы знаете на какие процессы переходить и когда.
В статье не затронули 1 аспект, который был в минусах — бесконечные митинги. Стендапы, грумминги, планирования, демо, ретро — это все жрет кучу времени. А еще кучу времени жрет переключение со своей задачи на митинг и назад на свою задачу. И ведь нельзя сказать — я тут в процессе разработки алгоритма — давайте перенесем — команда ждет же. Вот и получается — решил начать работу, увидел, что до митинга 30 минут — ушел пить кофе, все равно ничего не успеешь сделать. И в итоге вроде как и стендап это 15 минут, и остальные митинги вроде не долгие, в времени тратится раза в 2-3 больше, чем на сами митинги. Еще ни 1 раза не встречал реальной пользы от аджайла, который именно внедряется. Ну а если команда и сама в состоянии работать по принципам аджайла, то обычно она доходит до этого сама и без всяких манифестов, скрам-мастеров и прочих «помощников»
решил начать работу, увидел, что до митинга 30 минут — ушёл пить кофе
Да ладно, это как раз 1 помидор. Даже если этого не хватит на полноценное погружение в задачу, то можно хотя бы подготовить это погружение. Например: накидать предварительный план действий, составить список тест-кейсов для TDD, сформулировать гипотезу "почему происходит баг" и т.п. А мелкая задача за это время делается вообще целиком без спешки.
Лично мое мнение — эти помидоры, как и скрам, не помогают рабочему процессу, а только мешают. Есть люди, которые любят сесть, сконцетрироваться, и сделать свою работу, а не метаться от задачи к задаче.
Не отрицаю, что есть и обратные примеры — это всего лишь мое субъективное мнение
Не отрицаю, что есть и обратные примеры — это всего лишь мое субъективное мнение
Есть люди, которые любят сесть, сконцетрироваться, и сделать свою работу, а не метаться от задачи к задаче.
А это как бы с скраму никакого отношения и не имеет. Более того в том самом «ванильном» скраме вам вообще никто не может сказать в каком порядке вы там что должны делать.
Только уточнить надо, что "вам" — это команде, прежде всего, а не конкретному человеку. Команда решает в каком порядке тикеты брать в работу, можно ли их откладывать недоделанными и т. п. Должен ли быть порядок один на всю команду, или каждый сам решает.
Не правильно выразился. Имел в виду метаться от задачи к митингу
Ну во первых даже если вы делаете какой-нибудь водопад, то скорее всего какие-то митинги у вас всё равно будут. И не факт что их будет меньше. И если у вас все люди из «разных временных зон», то на мой взгляд у вас и в водопаде будут проблемы с «метаться». А во вторых насколько вы будете «метаться» в том же скраме тоже в общем-то скорее зависит от вашей команды. То есть если вам удастся найти нормальный компромис, то и метаться вам не придётся.
Ну как бы на мой взгляд у любой команды есть куча "работы" кроме непосредственно программирования или скажем тестирования. И кто-то когда-то эту работу всё равно должен делать.
И в том же скраме под это дело выделенны те самые митинги. И поэтому не то чтобы они были прямо уж бесполезными. Если они конечно используются по назначению, а не просто прикручены как какой-то карго-культ.
Ну и да, расположить эти самые митинги так чтобы было удобно всем и чтобы минимизировать потерю времени это не самая тривиальная задача.
Согласен, работа есть. Но согласитесь, что зачастую эту работу делают 1-2 человека, а не всей толпой. А на митингах обычно требуется присутсвие всей команды. А про расположение — это легко сделать когда все приходят и уходят в одно и то же время, ну или хотя бы находятся в одной часовой зоне. А так получается, что митинги ставят так, чтоб никому не было очень уж неудобно. И получатеся, что у кого-то стендап в начале рабочего дня, у кого-то через 2 часа после старта, а у кого-то через 30 минут. И естесвенно, последнему легче эти 30 минут кофе попить, чем прям утром бежать за 30 минут подготавливать погружение в задачу. Когда я пришел с этим вопросам к ажаль-коучу — ответ был шикарный — приходите на работу в другое время. Естественно вся команда моментально побежала пересматривать свой ежеденевный график ради стендапов
Согласен, работа есть. Но согласитесь, что зачастую эту работу делают 1-2 человека, а не всей толпой. А на митингах обычно требуется присутсвие всей команды.
С одной стороны да. С другой стороны если эту работу делают не 1-2 человека, а все заинтересованные лица то она обычно выполняется более качественно. То есть грубо говоря если у вас сложность задач оценивает не тот человек, который их потом будет делать, то он гораздо менее заинтересован в том чтобы оценка была точной :)
Ну и как бы далеко не на всех митингах в аджайле должна присутствоватъ вся команда. И даже в скраме это всего четыре митинга и они не то чтобы отнимают кучу лишнего времени и на мой взгляд вполне себе «окупаются».
Когда я пришел с этим вопросам к ажаль-коучу — ответ был шикарный — приходите на работу в другое время. Естественно вся команда моментально побежала пересматривать свой ежеденевный график ради стендапов
Ну вот это на мой взгляд как раз и неправильно. И именно если пытаешься такого избежать в команде с людьми «из разных временных зон», то это не так уж и просто.
Скрам предполагает, что команда разработки сама решает когда проводить дэйлики, скрам-мастер только следит чтобы не передрались в процессе решения :)
В статье речь не про аджайл в целом, а исключительно про скрам.
И да, канбан лишён описанных проблем.
НЛО прилетело и опубликовало эту надпись здесь
Ведь одна из целей Agile – создание комфортных условий для работы тех самых разработчиков.
:)))))))))))))))))
Смешно. Аджайл создан для того что-бы менеджеры хоть как-то научились управлять «стаей котов», что-бы команда бежала марафон со спринтерской дистанцией (это хотелки, которые не работают в реальной жизни), что-бы выдоить разработчиков досуха и выбросить жмых на улицу, наняв новое мясо, которое так-же будет выжато.
Любое отклонение от «кошерной методики» просто позволяет людям хотя бы как-то мириться с этой дичью и работать. Все эти ритуалы соблюдаются формально, тупо тратят время и силы, к ним не относятся серьезно и только потому все не разваливается. Как только приходит какой-либо чертов евангелист, который хочет внедрить «настоящий скрам», так все и катится в задницу.
НЛО прилетело и опубликовало эту надпись здесь
Без менеджеров — формальных или фактических ничего не получится, это утопия. Как корабль, в котором нет капитана, штурмана и прочих офицеров, курс которого определяет общее собрание команды, при котором механик, отлично разбирающийся в устройстве дизеля, должен решать как правильно проходить залив и как швартоваться в порту, а кок, мастер лепки пельменей, будет решать как правильно настроить ТНВД на правом дизеле.
Для возникновения самоорганизующейся команды нужно в первую очередь руководство, которое доверяет сотрудникам, и не боится самоорганизации. На практике обычно все просто превращается в унылые ежедневные отчеты руководителю, когда каждый оттарабанив свою речь уныло дожидается конца собрания, когда наконец-то можно будет заняться делом. В особо запущенных случаях это становится ежедневным разносом плана «какого х… а вы так долго возитесь!».
Для возникновения самоорганизующейся команды нужно в первую очередь руководство, которое доверяет сотрудникам, и не боится самоорганизации. На практике обычно все просто превращается в унылые ежедневные отчеты руководителю, когда каждый оттарабанив свою речь уныло дожидается конца собрания, когда наконец-то можно будет заняться делом. В особо запущенных случаях это становится ежедневным разносом плана «какого х… а вы так долго возитесь!».
Ну на мой взгляд даже в аджайле какие-то менеджеры и руководство вне команды обычно всё равно остаются. Кто-то должен искать клиентов и договариваться с ними об оплате. Кто-то должен нанимать людей и составлять эти самые команды. И так далее и тому подобное.
Но при этом на том самом «командном уровне» менеджеры и руководство уже не нужны. То есть грубо говоря аджайл позволяет обойтись без тимлидов или скажем начальников отделов.
Но при этом на том самом «командном уровне» менеджеры и руководство уже не нужны. То есть грубо говоря аджайл позволяет обойтись без тимлидов или скажем начальников отделов.
Возможно формально их не будет (не будет должности), по факту так не работает. Любая группа людей всегда обзаводится лидерами, так наш вид устроен, без какого-то человека, который соберет всех и задаст направление — никто с места не сдвинется. Даже о вечерней попойке без организатора никто не договорится, не то что о чем-то сложном и не слишком интересном.
А называть такого человека тимлидом, менеджером или групенфюрером — от этого суть не изменится.
А называть такого человека тимлидом, менеджером или групенфюрером — от этого суть не изменится.
Любая группа людей всегда обзаводится лидерами, так наш вид устроен, без какого-то человека, который соберет всех и задаст направление — никто с места не сдвинется.
Как то очень сильно обобщено и не сказал бы что обязательно верно. То есть в случае с каким-нибудь глобальными вещами это может быть и так, но небольшие группы людей на мой взгляд вполне себе могут нормально функционировать и без какого-то определённого лидера. Особенно если есть какой-то внешний(а может даже и внутренний) фактор, который указывает «примерное направление».
А если взять ваш пример с «вечерней попойкой», то например сегодня таким «лидером» могут быть я, в следующий раз кто-то другой, потом кто-то третий и так далее. То есть в такой ситуации у нас каждый в какой-то момент является «лидером», но при этом одного конкретного лидера в группе нет. И это как бы тоже вполне себе нормально для команд в аджайл.
Без лидера это не команда а просто аморфная толпа людей. Существовать она, конечно, может. Только вот ничего плодотворного она сделать не сможет в принципе. А сменяемость лидера возможна, но только когда меняется задача команды. В случае с разработкой задача команды в конечном итоге — получить прибыль и разделить ее между всеми участниками. Так уж получилось, что большинство программистов в этом разбираются слабовато, и потому по любому рулить в коммерческой разработке будут не они, не они определяют круг задач, не они расставляют их приоритет, не они ищут компромиссы.
А свобода разработчика это нечто вроде свободы гребца на галере — как поудобнее за весло взяться что-бы гребок помощнее получился и руки не сильно уставали.
Аджайл же просто пытается внушить нам что мы тут с веслами тоже немного капитаны.
А свобода разработчика это нечто вроде свободы гребца на галере — как поудобнее за весло взяться что-бы гребок помощнее получился и руки не сильно уставали.
Аджайл же просто пытается внушить нам что мы тут с веслами тоже немного капитаны.
Без лидера это не команда а просто аморфная толпа людей. Существовать она, конечно, может. Только вот ничего плодотворного она сделать не сможет в принципе. А сменяемость лидера возможна, но только когда меняется задача команды.
Интересно. Но вот только к сожалению(а может и к счастью) написанное вами не особо совпадает с моим личным опытом.
Аджайл же просто пытается внушить нам что мы тут с веслами тоже немного капитаны.
Естественно аджайл это не то чтобы абсолютная свобода для разработчика. Но это однозначно больше свободы.
Естественно аджайл это не то чтобы абсолютная свобода для разработчика. Но это однозначно больше свободы.
Разница между аджайлом и водопадом, для разработчика, это разница между поваром крутого ресторана, который сам может придумывать рецепты и не сильно ограничен в приготовлении блюд (ему по большему слову озвучивают пожелание клиента, а не то что нужно сделать что-бы получить «котлету по киевски»), и «поваром» в Макдаке, который свободен в выборе между стоянием на кассе, мытьем туалетов и жаркой котлет на гриле.
Хорошая аналогия. Вот только похоже что у нас с вами абсолютное расхождение в том плане что считать "крутым рестораном", а что "макдаком". И по моему личному опыту в аджайле мною гораздо меньше командовали и у меня было больше свободы в выборе того что и как я хочу делать.
Ну, значит, похоже вы из тех немногочисленных счастливцев, видевших святой Грааль настоящий Аджайл (tm).
О нет. Вот именно настоящий аджайл я тоже ни разу пожалуй не видел. Но я уже несколько раз встречал "варианты приближения", которые позволяли мне достаточно комфортно работать.
И как минимум по моим субъективным ощущениям и как минимум у нас в регионе таких вариантов становится больше из года в год. Хотя опять же может я каким-то образом попал в "пузырь".
Интересно. Но вот только к сожалению(а может и к счастью) написанное вами не особо совпадает с моим личным опытом.
Лукавите, либо просто не понимаете то что видите каждый день в каждом коллективе.
выдоить разработчиков досуха и выбросить жмых на улицу, наняв новое мясо, которое так-же будет выжато.
Без лидера это не команда а просто аморфная толпа людей
пытается внушить нам что мы тут с веслами тоже немного капитаныВы прекрасно иллюстрируете причину написания обсуждаемой статьи. А также цикла статей про цвета управления, ага.
Просто эталонный образец, как по мне.
бежала марафон со спринтерской дистанцией
скоростью, конечно, опечатался
Почему разработчикам не нравится Agile?
По той простой причине что срамо-агил — это антинаучная «методология» вносящая исключительно хаос и гарантированно обеспечивающая экспоненциальное замедление разработки.
Спасибо. Звучит внушительно. Не могли бы Вы всё это чуть более развернуто обосновать?
Во первых — что можно разработать без проектной документаци ака постановка задачи?
Во вторых — на кой ляд там вооще в планировании нужен заказчик? Он в этих вопросах некомпетенетен от слова совсем.
В третьих — какой к глиняной маме покер планирования? Порядок разработки компонент можно определить исключительно по сетевому графику — единственно возможному способу определения зависимостей между компонентами.
Ну и в главных — о какой гибкости можно говорить если процесс сводится к обкостыливанию костылей? Чтобы была гибкость софт должен собираться из гибких компонентов каждый из которых универсальным образом покрывает свою зону ответственности. Но тогда разработка должна строится не по фичам а по слоям абстракций. И именно такое построение позволяет избежать бесконечного рефакторинга и обкостыливания костылей который и затягивает разработку экспоненциально. В отличие от срамо-агила разделение на слои универсальных компонет позволяет сэкономить до 99% объема кода а так же позволяет гибко изменять а то и просто переконфигурировать софт без изменения исходника. Это же азы построения архитектуры которые в любом вузе на 3 — 4 курсе изучают.
Во вторых — на кой ляд там вооще в планировании нужен заказчик? Он в этих вопросах некомпетенетен от слова совсем.
В третьих — какой к глиняной маме покер планирования? Порядок разработки компонент можно определить исключительно по сетевому графику — единственно возможному способу определения зависимостей между компонентами.
Ну и в главных — о какой гибкости можно говорить если процесс сводится к обкостыливанию костылей? Чтобы была гибкость софт должен собираться из гибких компонентов каждый из которых универсальным образом покрывает свою зону ответственности. Но тогда разработка должна строится не по фичам а по слоям абстракций. И именно такое построение позволяет избежать бесконечного рефакторинга и обкостыливания костылей который и затягивает разработку экспоненциально. В отличие от срамо-агила разделение на слои универсальных компонет позволяет сэкономить до 99% объема кода а так же позволяет гибко изменять а то и просто переконфигурировать софт без изменения исходника. Это же азы построения архитектуры которые в любом вузе на 3 — 4 курсе изучают.
НЛО прилетело и опубликовало эту надпись здесь
Такое что пункты для него подготавливают абсолютно некомпетентные вопросе вопросе люди ака менеджер заказчик и т.п. которые абсолютно не в курсе что и как надо делать для достижения требуемого от эксплуатации софта эффекта. Т.е. хотелка у заказчика всегда одна и онли одна — увеличить скорость телодвижений/эффективность работы офисного планктона/оборудования. Но компетенцией в вопросе что для этого надо реализовать а тем более как это реализовать он не обладает от слова совсем. Исследование предметной области это как раз основная работа программистов. Программная реализация это только финальная стадия.
НЛО прилетело и опубликовало эту надпись здесь
Атомарная задача — это один компонент/класс. При правильной декомпозиции его текст редко превышает экран. На кой ляд это выносить на какие то обсуждения раз в неделю а то и месяц? При этом водопад как бы и ругают за то что требует настолько глубокого анализа декомпозиции сразу. И лечится это как раз таки каскадным водопадом или RAD когда декомпозиция производится на крупные узлы а на атомарные уже непосредственно реализующим крупную подсистему/библиотеку разработчиком. Т.е. то что выносится на спринты это в любом случае не атомарные задачи. И именно как раз такое ущемление в плане анализа и ломает гибкость и при этом ка раз таки аки убивает эффективность декомпозиции.
Водопад ругают не за то, что он требует анализа сразу, а за то, что к концу проекта, а то и раньше, большая часть результатов этого анализа и имплементации на их их основе, неактуальна для заказчика, у него уже другое видение, что он хочет.
Да кому вооще интересно его видение то? Интересно какая предметная область у задачи. Нарисовали модель сущностей предметной области — т.е. базис для реализации видений. Вот теперя можно и про видение спрашивать. Тока лучше сначала свое предложить. Некоторых видетелей реально водкой отпаивали по поводу того что они проморгали. А те которые поумнее те по принципу — посмотри что тут изобрести можно сразу действуют.
Психология, например, предметная область. Причём конкретной школы, из всех материалов которой талмуд основателя оной, он же заказчик.
Ну как бы это вам объяснить попонятнее то… Вот представьте себе что вы заказчик и у вас есть выбор в какую из фирм отдать свой заказ. Обе фирмы друг от друга мало чем отличаются. Но одна из них говорит что давайте напишем ТЗ, вы отстаёте от нас на три года и через три года мы дадим вам готовый продукт.
А другая говорит что давайте напишем ТЗ и мы его будем три года реализовывать. Но каждый месяц мы вам будем показывать промежуточные результаты. И если вы на основании этих результатов захотите что-то поменять или добавить, то это вполне себе обсуждаемо.
И неужели вы в такой ситуации выберете первую фирму?
А другая говорит что давайте напишем ТЗ и мы его будем три года реализовывать. Но каждый месяц мы вам будем показывать промежуточные результаты. И если вы на основании этих результатов захотите что-то поменять или добавить, то это вполне себе обсуждаемо.
И неужели вы в такой ситуации выберете первую фирму?
Вторая только показывает или можно попользоваться?
Какой у меня опыт заказа, не было ли в прошлом такого, что через три года обнаруживается что я (или они) упустил что-то важное и результат не совсем тот, который я имел ввиду?
Ни одну из этих. А ту которая пойдет произведет анализ и предложит свое видение комплексной автоматизации. И при этом способна в процессе увидеть и внести необходимые коррекции. То что сами накосячили в своем плане пусть сами и разруливают. Человеку свойственно ошибатся, а тем более в сложных технических системах. Это и ежу понятно. Мы академиев не кончали. А они спецы. У них вероятность серьезных ошибок мизерна. Им за это деньги и платят. Пусть делают свое дело — используют научно обоснованные методы разработки. А мне в это вникать некогда и без толку. Достаточно отчетов раз в квартал о проделанной работе. Ну и главное требование — надежность софта сразу. Финансовая ответственность за последствия багов в продакшине на них.
PS. А по некоторым системам, в некоторых случаях, за баги в продакшине УК предусматривает до 10 лет.
PS. А по некоторым системам, в некоторых случаях, за баги в продакшине УК предусматривает до 10 лет.
НЛО прилетело и опубликовало эту надпись здесь
Ни одну из этих. А ту которая пойдет произведет анализ и предложит свое видение комплексной автоматизации
Допустим это могут сделать обе фирмы. И дальше что?
.А мне в это вникать некогда и без толку.
То есть по вашему программисты должны уметь читать мысли и предсказывать будущее? И зачем им тогда программистами работать? :)
Они должны уметь исследовать объект/процеес на предмет автоматизации. Это их должностная обязанность. Почему я должен ее за них выполнять? Еще раз — цель любой автоматизации — увеличение экономической эффективности автоматизируемого процесса. При этом чем полнее автоматизация процесса тем больше экономический эффект. Как это сделать — их забота.
Срамо-агил тут при чем?
Вот небольшая компания столкнулась с необходимость оптимизации логистики: vc.ru/life/107930-mne-govorili-chto-ya-idiot-no-ya-prodolzhal-skupat-platezhnye-terminaly-postroenie-uspeshnogo-biznesa-v-padayushchey-nisheНу с учетом количества точек — задача на курсач для толкового студента. Если точек поменьше и получение реальной геолокации не учитывать- то банально 1/4 олимпиадного задания для десятиклассников лихих 90-х. При этом автоматизация заданного процесса абсолютная.
Срамо-агил тут при чем?
Они должны уметь исследовать объект/процеес на предмет автоматизации. Это их должностная обязанность. Почему я должен ее за них выполнять?
Вы как клиент должны для этого предлставить всю необходимую информацию. При этом совсем не исключён вариант что вы всей необходимой информации на данный момент не имеете. Ну или как минимум совсем не исключён вариант что в течении этих самых последующих трёх лет вы получите какую-то дополнительную информацию, которая может в теории повлиять на ваши процессы и даже их изменить.
Как это сделать — их забота.
Тогда зачем им вы нужны? Ну если они и в программировании лучше вас разбираются и в вашей области тоже. Тогда это вы уже лишнее звено.
Вы как клиент должны для этого предлставить всю необходимую информацию.Начнем с того — зачем они мне нужны? Для того чтобы произвести комплексную автоматизацию. Инженер-программист — это специалист именно по комплексной автоматизации. С белого листа и до наиболее полной возможной с современными техническими средствами автоматизации.
Т.е. пусть идут смотрят на процесс общаются с нужными специалистами и т.д. А мне на это отвлекаться некогда. И так дел выше крыши.
Тогда зачем им вы нужны?
А я им для проведения автоматизации и не нужен. И сформировать план мероприятий по автоматизации — их обязанность. Если им кто то должен в этом вопросе задницу подтирать — это называется абсолютная их некомпетентность в специальности.
Все эти бредни про вовлеченность заказчика — на самом деле прикрытие некомпетентности горе-веб девов и т.п. выпускников курсов, на которых специальности не обучают от слова совсем. Не бывает программиста какого то языка. Это называется быдлокодеры. Бывают инженеры программисты. Для справки — курс алгоритмических языков в универе 144 часа. А все остальное время изучают все необходимое именно для проведения анализа на предмет автоматизации, постановки задачи и проектирования архитектуры для автоматизации любого процесса/объекта. Именно это основная часть работы инженера-программиста. А программная реализация — финальная часть, результат всей этой основной части. И именно так оно и делается когда все по серьезному. Причем вне зависимости от объемов задачи. Вашему сраму такой скорости разработки, качества и гибкости результата, самоорганизации и погружения в предметную область при таком подходе не видать аки своих ушей.
А все эти вовлеченности клиента актуальны только в вопросе в какой цвет свистоперделку покрасить. Но сам этот вопрос только для лендингов актуален, которые никак не к разработке софта относятся а к интерактивной рекламной полиграфии. Для всего же остального важны должностные инструкции по проведению оных расчетов. Или техническая документация по объекту автоматизации и технологическому процессу на нем, если это АСУТП.
И прямые контакты по горизонтали со спецами на стороне клиента, выполняющими сейчас работу без компа/на старой софтине для выяснения непоняток/неточностей.
Вы ей богу как ни дня в отделе АСУТП или АСУП не работали.
Начнем с того — зачем они мне нужны? Для того чтобы произвести комплексную автоматизацию.
Автоматизацию не проводят саму по себе. Автоматизировать надо какие-то процессы. Для того чтобы какой-то процесс автоматизировать вы сначала должны понять что вы вообще собираетесь автоматизировать. И для этого вам однозначно нужна хоть какая-то информация от вашего клиента.
А я им для проведения автоматизации и не нужен.
Ок. Вы не затруднитесь тогда провести автоматизацию скажем у меня? Сколько это будет стоить и сколько займёт времени?
Для того чтобы какой-то процесс автоматизировать вы сначала должны понять что вы вообще собираетесь автоматизировать.
Пример из реальной жизни. Звонок генерального начальнику отдела АСУТП: «На передаче химсостава между цехами по телефону теряем овер 200 килобаксов в сутки. Нужна автоматика. АСУП отказался — сказали там какие то контроллеры — не их профиль. Отправь пару человек пусть разберутся. Через неделю график реализации мероприятий мне на стол».
От так это все по серьезному и делается. И больше там тот директор нафиг не улыбался для полной автоматизации. Ну разве что смету на оборудование подписать и приказ на выделение линий связи. А после того как передал слово в слово ведущему группы автоматизации отдела то и начальник отдела уже нафиг не нужен. Ну разве что директору сказать — реальные мероприятия по плану могут производится только при наличии требуемого по смете оборудования и каналов связи.
Через час были уже в лаборатории химанализа ощупывали с оным ведущим оный контроллер.
Для продукта нужно сделать больше действий, чем просто имплементировать алгоритм.
Т.е. аджайл нужен чтобы сунуть толпу некомпетентных бездельников на пол года, туда где все за пару часов в одиночку решается при правильном наборе тулзов?
Ну о чем и была речь — срам не более чем прикрытие некомпетентности.
Вы конечно извините, но во первых это не «по серьёзному». Это скорее какой-то детский сад.
А во вторых даже если сам директор и «нафиг не улыбался», но зато там «назаулыбалась» куча других людей которые представляли сторону этого самого директора во время нахождения решения проблемы. А «клиент» это как бы тоже обычно не только сам директор фирмы, которая у вас софт заказыаает. Обычно этот самый директор в такой ситуации вообще и не нужен.
А во вторых даже если сам директор и «нафиг не улыбался», но зато там «назаулыбалась» куча других людей которые представляли сторону этого самого директора во время нахождения решения проблемы. А «клиент» это как бы тоже обычно не только сам директор фирмы, которая у вас софт заказыаает. Обычно этот самый директор в такой ситуации вообще и не нужен.
А во вторых даже если сам директор и «нафиг не улыбался», но зато там «назаулыбалась» куча других людей которые представляли сторону этого самого директора во время нахождения решения проблемы.Проблема решалась примерно так. Ком порт для снятия инфы есть. Дока по контроллеру еcть? Нету. Твою мать опять реверсить. Реально дирекция только создала проблем закупив у сторонней конторы контроллеры связи с квантометрами, даже не поставив АСУТП в известность и не проконтролировав наличие необходимой документации по подключению и т.д.
Аджайл своим отношением к документации только проблемы создает, решение которых по трудозатратам кратно превышает создание этого условно рабочего софта.
Прикиньте сколько проблем в результате для того чтобы раз в з час вытащить строчку таблицы и вкинуть ее по сетке в информационную систему центральной лаборатории.
Аджайл своим отношением к документации только проблемы создает, решение которых по трудозатратам кратно превышает создание этого условно рабочего софта.
Я всё больше и больше понимаю что вы вообще не понимаете о чём пишите. Вы аджайл манифест то вообще читали? Советую вам прочитать и обратить анимание на второй пункт в этом самом манифесте…
Манифест аджайла показывает исключительно абсолютную некомпетентность его создателей и больше ничего.
Основное средство общения инженеров, в том числе и с самим собой в будущем — документация. Разговоры инженеров не на основе документации — балачки не о чем. Личные контакты нужны только для устранения неоднозначностей/неточностей/недопонимания/ликвидации просчетов в документации.
Они отнимают гораздо больше времени чем чтение доки и распараллелить процесс получения инфы от одного источника многими потребителями в отличии от чтения доки не реально.
Даже соло разработка ведется на основании доки как по инструментам (т.е. языку и апи окружения) так и по цели (специальная летиратура/дока по предметной области). Другое дело что в процессе разработки атомарной задачи (а это такая задача которая не допускает дальнейшей декомпозиции а соответственно реализация выполняется только соло) доку удобнее оформлять карандашиком на полях. Но сразу же по завершению этой атомарной задачи она должна быть оформлена по существующим стандартам. Потому что реализованный компонент сразу же становится частью локального апи. А соответственно без исчерпывающей доки никакая командная работа невозможна. Код же при этом хоть и несет всю полноту знаний о задаче, но докой не является. Извлечь оные знания оттуда трудно, а об причинах принятия того или иного технического решения остается только гадать на кофейной гуще.
А соответственно без исчерпывающей доки создание работающего софта нереально, а гибкое его расширение в будущем принципиально не возможно.
Т.е. манифест аджайла — полнейшая чушь, противопоставляющая цель средствам ее достижения.
Основное средство общения инженеров, в том числе и с самим собой в будущем — документация. Разговоры инженеров не на основе документации — балачки не о чем. Личные контакты нужны только для устранения неоднозначностей/неточностей/недопонимания/ликвидации просчетов в документации.
Они отнимают гораздо больше времени чем чтение доки и распараллелить процесс получения инфы от одного источника многими потребителями в отличии от чтения доки не реально.
Даже соло разработка ведется на основании доки как по инструментам (т.е. языку и апи окружения) так и по цели (специальная летиратура/дока по предметной области). Другое дело что в процессе разработки атомарной задачи (а это такая задача которая не допускает дальнейшей декомпозиции а соответственно реализация выполняется только соло) доку удобнее оформлять карандашиком на полях. Но сразу же по завершению этой атомарной задачи она должна быть оформлена по существующим стандартам. Потому что реализованный компонент сразу же становится частью локального апи. А соответственно без исчерпывающей доки никакая командная работа невозможна. Код же при этом хоть и несет всю полноту знаний о задаче, но докой не является. Извлечь оные знания оттуда трудно, а об причинах принятия того или иного технического решения остается только гадать на кофейной гуще.
А соответственно без исчерпывающей доки создание работающего софта нереально, а гибкое его расширение в будущем принципиально не возможно.
Т.е. манифест аджайла — полнейшая чушь, противопоставляющая цель средствам ее достижения.
Они отнимают гораздо больше времени чем чтение доки и распараллелить процесс получения инфы от одного источника многими потребителями в отличии от чтения доки не реально.
Вполне возможно, как минимум в краткосрочной перспективе. Собственно всякие демо в скраме и для этого нужны. Если они выродились в демонстрацию UI для стейкхолдеров, то отдельные сессии для разработчиков типа "я тут новый API создал, пользуйтесь"
то отдельные сессии для разработчиков типа «я тут новый API создал, пользуйтесь»
docs.microsoft.com/en-us
Ну вот вам пример постоянно действующая презинтации с функцией поиска нужной конкретному разрабу апи.
Написали добавили в референс — и его юзать начнут гараздо раньше презинтации. Весь код является АПИ. Вообще весь. Любая процедура/функция может быть повторно использована. А класс тем более. Любой класс есть точка расширения. А тем более в рамках одного проекта, для которого декомпозиция кода без многократного переиспользования вообще безсмысленна, а востребованность локального апи очень часто по принципу надо не то что вчера а год назад.
Вы сигнатуры всех методов крайнего разработанного вами класса помните? А того который три месяца назад разрабатывали? Толку от этих плясок с бубном и прочих словесов без референса, если без него даже вы свой собственный апи юзать не сможете?
Не верите? Ну сравните доку по винапи и линуксапи по полноте и глубине изложения. Теперь понимаете почему винда овер 90% рынка занимает а линукс овер 90% «презентаций» на тему майки монополисты под линукс софт делать не дают а рынка имеют 1.75% при том что абсолютно бесплатен.
У вас слишком резкие суждения, чтобы не цепляться к деталям типа "декомпозиция бессмысленна без повторного использования". Вот как раз в целях документирования декомпозиция может быть полезна. И это будет самая актуальная документация.
Вы сигнатуры всех методов крайнего разработанного вами класса помните?
Ой где же я могу посмотреть сигнатуры методов кроме как в документации?
Ой где же я могу посмотреть сигнатуры методов кроме как в документации?
Ну как бы код вместо референса юзать и долго и неудобно. И искать слишком долго, и что именно тот или иной метод делает тоже не всегде ясно без очень детального исследования.
В общем объем кода который выходит за пределы его комфортного юзания его аки референса — примерно то что один человек может разработать и отладить за 3 месяца.
А соответственно в команде разрабов 6 человек без референса полный бардак в этом плане начинается примерно через 2 недели. Это уже не говоря о том что в случае возникновения нестыковок, без постановок на каждый компонент, которые банально поясняют как именно он делает то что делает и почему именно так начинается вообще мрак.
Это при нормальных названиях, тестах и кодревью? У меня другой опыт.
Это при нормальных названиях, тестах и кодревью? У меня другой опыт.
Это при использовании сверхвысокоуровневого языка и нормальной декомпозиции, когда большая часть того что чуть выше самого низа делается как минимум частично декларативно.
Представьте себе количество методов и классов если размер методов редко превышает 5 строк (в основном 1-3 строки), классов больше 200 строк вообще нет, а подавляющее большинство классов вообще на экран влазит.
Вы сигнатуры всех методов крайнего разработанного вами класса помните?
А что такое «крайний класс», кстати? Это класс с края программы?
НЛО прилетело и опубликовало эту надпись здесь
Потому что срам это методика менеджмента направлен на срезание функциональности и ограничения времени и в результате ведет к резкому снижению качетсва софта и экспоненциальному замедлению разработки, которая полностью исключает современные научно-обоснованные методики проектирования направленные на снижение трудоемкости комплексной автоматизации и повышению гибкости РЕЗУЛЬТАТА.
Аджайл это только декларирует. А на самом деле это методологии «эффективного менеджмента» которые именно это полностью и исключают.
Аджайл — это как раз про гибкость результата, самоорганизацию и погружение в предметную область.
Аджайл это только декларирует. А на самом деле это методологии «эффективного менеджмента» которые именно это полностью и исключают.
Можете конкретно показать, что эта методика менеджмента исключает какие-то методики проектирования? Как по мне это вещи ортогональные, как и методики разработки — три ортогональных оси программного продукта.
Достаточно того что она полностью исключает декомпозицию по зонам ответсвенности, распараллеливание разработки, и как результат вынуждена производить планирование на основании субъективных оценки трудоемкости вместо технической возможности и техической востребованности и объективных оценок трудоемкости.
А как результат срывает ускорение разработки технологичнской базы (набора компонент моделирующих сущности предметной области) для реализации фич. Т.е. навязывает абсолютно дилетантский подход к разработке. Даже если фичи и меняются то сами по себе они не более чем результат взаимодействия сущностей предметной области.
При этом выбором типа приоритетных фич выбросить из этого набора сущностей ничего не удастся.
Предметная область — это набор сущностей которыми оперирует та или иная теория и т.п. А соответственно «все украдено до вас». Вернее отчекрыжино бритвой Оккама. Хфилософы они ребяты простые аки смартпоинтеры — чуть рефкаунт 0 так хвать бритву и Банзай!
А соответсвенно для наиболее быстрой реализации нужно оценить предметную область целяком, разделить на подсистемы очертив их зоны ответсвенности, ну и далее рекурсивно. Выделить взаимозависимости и уже в очередности зависимостей разрабатывать компоненты. А уже из готового набора клепать какие угодно фичи.
Т.е. срам абсолютно не пригоден к использованию с объектно-ориентированной методологией проектирования (т.е. проектирования на базе модели акторов — ООП инструмент программной реализации по этой методологии). Достаточно того что срам полностью исключает декомпозицию по зонам ответсвенности, распараллеливание разработки, и как результат вынужден производить планирование на основании субъективные оценки трудоемкости вместо технической возможности и техической востребованности и объективных оценок трудоемкости.
А как результат срывает ускорение разработки технологичнской базы (набора компонент моделирующих сущности предметной области) для реализации фич. Т.е. навязывает абсолютно дилетантский подход к разработке. Даже если фичи и меняются, то сами по себе они не более чем результат взаимодействия сущностей предметной области набор которых постоянен.
При этом выбором типа приоритетных фич выбросить из этого набора сущностей ничего не удастся.
Предметная область — это набор сущностей которыми оперирует та или иная теория и т.п. А соответственно «все украдено до вас». Вернее отчекрыжино бритвой Оккама. Хфилософы они ребяты простые аки смартпоинтеры — чуть рефкаунт 0 так хвать бритву и Банзай!
Ну а вообще любая программа явно или неявно представляет собой конечный автомат. Если пара автоматов имеет n+m состояний то эквивалентный ей единый автомат имеет n*m состояни. А соответсвенно рекурсивно разбивая на субоавтоматы имеем экспоненциальное снижение сложности как анализа так и реализации. При этом имеем еще и график зависимостей который четко показывает трудоемкость а так же используется для определения разработку каких компонентов можно распараллелить а разработка каких должна идти последовательно т в каком порядке.
Но именно это срам и исключает от слова совсем.
А как результат срывает ускорение разработки технологичнской базы (набора компонент моделирующих сущности предметной области) для реализации фич. Т.е. навязывает абсолютно дилетантский подход к разработке. Даже если фичи и меняются то сами по себе они не более чем результат взаимодействия сущностей предметной области.
При этом выбором типа приоритетных фич выбросить из этого набора сущностей ничего не удастся.
Предметная область — это набор сущностей которыми оперирует та или иная теория и т.п. А соответственно «все украдено до вас». Вернее отчекрыжино бритвой Оккама. Хфилософы они ребяты простые аки смартпоинтеры — чуть рефкаунт 0 так хвать бритву и Банзай!
А соответсвенно для наиболее быстрой реализации нужно оценить предметную область целяком, разделить на подсистемы очертив их зоны ответсвенности, ну и далее рекурсивно. Выделить взаимозависимости и уже в очередности зависимостей разрабатывать компоненты. А уже из готового набора клепать какие угодно фичи.
Т.е. срам абсолютно не пригоден к использованию с объектно-ориентированной методологией проектирования (т.е. проектирования на базе модели акторов — ООП инструмент программной реализации по этой методологии). Достаточно того что срам полностью исключает декомпозицию по зонам ответсвенности, распараллеливание разработки, и как результат вынужден производить планирование на основании субъективные оценки трудоемкости вместо технической возможности и техической востребованности и объективных оценок трудоемкости.
А как результат срывает ускорение разработки технологичнской базы (набора компонент моделирующих сущности предметной области) для реализации фич. Т.е. навязывает абсолютно дилетантский подход к разработке. Даже если фичи и меняются, то сами по себе они не более чем результат взаимодействия сущностей предметной области набор которых постоянен.
При этом выбором типа приоритетных фич выбросить из этого набора сущностей ничего не удастся.
Предметная область — это набор сущностей которыми оперирует та или иная теория и т.п. А соответственно «все украдено до вас». Вернее отчекрыжино бритвой Оккама. Хфилософы они ребяты простые аки смартпоинтеры — чуть рефкаунт 0 так хвать бритву и Банзай!
Ну а вообще любая программа явно или неявно представляет собой конечный автомат. Если пара автоматов имеет n+m состояний то эквивалентный ей единый автомат имеет n*m состояни. А соответсвенно рекурсивно разбивая на субоавтоматы имеем экспоненциальное снижение сложности как анализа так и реализации. При этом имеем еще и график зависимостей который четко показывает трудоемкость а так же используется для определения разработку каких компонентов можно распараллелить а разработка каких должна идти последовательно т в каком порядке.
Но именно это срам и исключает от слова совсем.
А соответсвенно для наиболее быстрой реализации нужно
Это если ставим себе цель наиболее быструю реализацию огромного набора фич "под ключ".
Скрам ставит другие цели — наиболее быструю реализацию очень ограниченного набора фич и предполагает, что модель предметной области постоянно уточняется как в коде, так и в головах разработчиков. Например, при скрам подходе нет нужды сразу браться за релятивистскую и квантовую механику для решения задачи перемещения из точки А в точку Б, достаточно простой бытовой модели на уровне пятого класса. Если пользователи будут жаловаться на неточность, то уточним модель.
Что до оценки трудоемкости, то не представляю как она может быть объективной, если оцениваем результат работы недетерминированной системы — разработчика.
Это если ставим себе цель наиболее быструю реализацию огромного набора фич «под ключ».
Это когда мы хотим устранить зависимость от списка фич вообще. Т.е. при таком подходе нам список фич вообще не важен. Технологический базис от него не зависит. Но создание технологического базиса — это 95%-99% трудоемкости.
А соответственно при реализации по фичам вместо экспоненциального ускорения создания технологического базиса происходит экспоненциальное замедление за счет нестыковок в дублированных для каждого частного случая реализациях одного и того же.
При этом выкинуть необходимые сущности предметной области выбором каких то фич не получится. Все уже отрезано бритвой Оккама.
При этом выкинуть необходимые сущности предметной области выбором каких то фич не получится. Все уже отрезано бритвой Оккама.
Если пользователи будут жаловаться на неточность, то уточним модель.Т.е. заменяет научно-обоснованный инженерный расчет методом антинаучного тыка. Такой подход допустим тока для мусорного софта с 0-ой отсетсвенностью ака интерактивная рекламная полиграфия и геймдев, кои есть менее чем 1% задач индустрии… А юзер примерно 25% софта даже пожаловаться не сможет, потому что если точность оказалась недостаточной он уже мертв. Еще 50% — ну он уже кого то угробил. Еще 24% — понес финансовые убытки кратно превосходящие потенциальный выхлоп от внедрения софта.
Если бы вы за последствия бага вызанного недостаточной точностью несли персональную финансовую ответсвенность вы бы так делали?
При этом там где от точности модели перемещений из точки A в точку B действительно что то зависит ответсвенность с огромной вероятностью будет не финансовой а уголовной.
При этом с определением и имплементацией общесистемных требований (надежность точность лимиты времени на отклик и т.д.), которые либо нужно учитывать в течении всей разработки, либо когда они всплывут пределать придется абсолютно все с нуля, в срамо-обложайле вооще полные жутики.
Какая там нужна точность определяется таки путем анализа и постановки.
Вы сами критикуете гибкую разработку, а потом оказывается, что в целом у вас всё совпадает.
На самом деле весь этот эффективный менеджмент — кривая попытка копирования формы местного «уяк-уяк и в продакшин» без понимания его сути. В технических вопросах менеджмент всегда не прав. Особенно топ менеджмент. Именно поэтому нельзя подстраиваться под его видение как это требует агил. Напротив «уяк-уяк и в продакшин» подразумевает прямое противопоставление технической целесообразности, которая в результате и дает экономический эффект, видению топ-менеджмента.
Все остальное в том же скраме — копирование того что к разработке вообще не относится от слова совсем. К примеру покер планирования — бездумное копирование заседания парткома с некоторыми отличиями, делающими его абсолютно бессмысленным. Стендапы — опять же копирование формы а не сути ежедневного рапорта, в котором принимают участие начальники служб и участвок цеха, и замы начальника — т.е. менеджмент нижнего звена производственных цехов в которых вся работа распараллелена и его цель ежедневная синхронизация, но не технических отделов где такая синхронизация чаще чем раз в неделю бессмысленна. Проведение чего то подобного среди рядовых разрабов при том что распараллеливание прямо запрещено — абсолютная бессмыслица, превращающая все это в плохую пародию партсобрания. Надеюсь хоть в этой стране понятно что до добра это не доведет?
Персональная ответственность за качество технических решений в сраме отсутствует. Коллективная же ответственность преследуется по закону. В результате получается коллективная безответственность. Отсутствие же разбора полетов и поиска причин косяков надежно скрывает тот факт что в 99.9% проблем виноват именно менеджмент и подстройка под его видение.
При этом вся эта пляска с бубном исключает как распараллеливание задачи так и ломает научно-обоснованные методологии проектирования. Т.е. срамо-агил для разработки чего то кроме примитивного софта с нулевой ответственностью пригоден чуть менее чем никак.
В результате у всей этой «гибкой разработки» нет ни гибкости ни разработки как таковой. Есть лепление черти чего из говна без палок, с последующим доливанием в вывонявшуюся какашку свежего поноса обновлений.
Инженер-программист — это специалист именно по комплексной автоматизации.
А можно источник для такого определения? Насколько я помню только к нескольким специальностям 220* єто можно біло применить в 90-е, не ко всем где выпускали инденеров-программистов.
Ну некоторые из 220* — те которые по направлениям «Автоматизация технологических процессов и производств» это соседи по цеху в определенной части задач. Они делают нервы и мозжечек систем управления оборудованием. Причем очень комплексно. Т.е. начиная с исследования технических характеристик объектов и т.д. Но к автоматизации в широком смысле этого слова отношения не имеют вообще. Их задача непосредственное иследование того или иного оборудования на параметры отклика на управление, построение функций управления т.е. автоматики непосредственного работающей в цепи датчик-исполнительный механизм.
И хотя их ознакамливают с программированием контроллеров нижнего звена и объем предметов связанных с разработкой софта у них второй после чисто компьютерных специальностей, они не программисты. У них для этого математическая подготовка недостаточная, как и у всех остальных технических специальностей. (по часам весь курс вышки у технических специальностей, равен курсу только матанализа у программистов). Программисты же в задачах АСУТП делают мозг системы и ее стыковку с системами АСУП.
А «Прикладная математика и вычислительная техника» это что то типа что то типа 010206 код насколько помню. Разлива 90-х и ранее это полностью включает современные 230*, в вопросах которые касаются применения вычислительной техники полностью 220* (теория автоматического управления в том же объеме), частично 210* но это скорее ознакомительно. А другие кафедры тогда программистов не готовили.
Во всем что касается разработки вычислительных систем основным является математическая подготовка, причем более разноплановая чем в чисто математических специальностях, необходимая для того чтобы разобраться в любой предметной области, и умение делать постановку. Другого способа создать алгоритм чем цикл анализ задачи-постановка независимо от масштаба задачи, а значит и схему применения вычислительных средств в целом не существует. А соответственно все 230* и т.д. это та же а ПМиВТ по сути. При этом задача эффективного планирования — это чисто математическая задача оптимизации.
У чисто менеджмента банально недостаточная для этого математическая подготовка а по другим направлениям недостаточная инженерная. Именно поэтому менеджмент нижнего звена должен осуществляться наиболее опытным спецом в бюро и т.п. непосредственно участвующим в разработке наравне с подчиненными. Среднего звена тоже лучше спецом по направлению хотя тут уже гораздо менее критично. Именно их задача донести до топ менеджмента технические реалии обнаруженные их подчиненными.
А особенно это касается программистов — чисто менеджеры насколько бы топ они ни были, в сравнении с программистами — ничто пыль под ногами как в плане технических аспектов так и в плане эффективного планирования, поскольку для программистов оная оптимизация — это всего лишь технический аспект.
Вот поэтому под видение топ-менеджмента подстраиваться и вредно. Т.е. если к примеру подсистема A зависит от подсистемы B при этом насяльника хочет именно подсистему A то пусть хоть головой об стену бъется но первой надо полноценно делать подсистему B пкоторую насяльника посчитал опциональной. При этом с огромной вероятностью именно подсистема B и является наиболее эффективной в экономическом плане и на нее завязаны еще и под системы C D E F и т.д.
Срам же который не дает оценить эти зависимости приведет к кастраци именно ключевой для всего остального подсистемы B. Т.е. реализация для того чтобы быть быстрой качественной и гибкой должна идти в порядке технической возможности и технической востребованности, а не в той которую се менеджмент напридумывал.
И хотя их ознакамливают с программированием контроллеров нижнего звена и объем предметов связанных с разработкой софта у них второй после чисто компьютерных специальностей, они не программисты. У них для этого математическая подготовка недостаточная, как и у всех остальных технических специальностей. (по часам весь курс вышки у технических специальностей, равен курсу только матанализа у программистов). Программисты же в задачах АСУТП делают мозг системы и ее стыковку с системами АСУП.
А «Прикладная математика и вычислительная техника» это что то типа что то типа 010206 код насколько помню. Разлива 90-х и ранее это полностью включает современные 230*, в вопросах которые касаются применения вычислительной техники полностью 220* (теория автоматического управления в том же объеме), частично 210* но это скорее ознакомительно. А другие кафедры тогда программистов не готовили.
Во всем что касается разработки вычислительных систем основным является математическая подготовка, причем более разноплановая чем в чисто математических специальностях, необходимая для того чтобы разобраться в любой предметной области, и умение делать постановку. Другого способа создать алгоритм чем цикл анализ задачи-постановка независимо от масштаба задачи, а значит и схему применения вычислительных средств в целом не существует. А соответственно все 230* и т.д. это та же а ПМиВТ по сути. При этом задача эффективного планирования — это чисто математическая задача оптимизации.
У чисто менеджмента банально недостаточная для этого математическая подготовка а по другим направлениям недостаточная инженерная. Именно поэтому менеджмент нижнего звена должен осуществляться наиболее опытным спецом в бюро и т.п. непосредственно участвующим в разработке наравне с подчиненными. Среднего звена тоже лучше спецом по направлению хотя тут уже гораздо менее критично. Именно их задача донести до топ менеджмента технические реалии обнаруженные их подчиненными.
А особенно это касается программистов — чисто менеджеры насколько бы топ они ни были, в сравнении с программистами — ничто пыль под ногами как в плане технических аспектов так и в плане эффективного планирования, поскольку для программистов оная оптимизация — это всего лишь технический аспект.
Вот поэтому под видение топ-менеджмента подстраиваться и вредно. Т.е. если к примеру подсистема A зависит от подсистемы B при этом насяльника хочет именно подсистему A то пусть хоть головой об стену бъется но первой надо полноценно делать подсистему B пкоторую насяльника посчитал опциональной. При этом с огромной вероятностью именно подсистема B и является наиболее эффективной в экономическом плане и на нее завязаны еще и под системы C D E F и т.д.
Срам же который не дает оценить эти зависимости приведет к кастраци именно ключевой для всего остального подсистемы B. Т.е. реализация для того чтобы быть быстрой качественной и гибкой должна идти в порядке технической возможности и технической востребованности, а не в той которую се менеджмент напридумывал.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
А по некоторым системам, в некоторых случаях, за баги в продакшине УК предусматривает до 10 лет.
По каким системам, в каких случаях (явный саботаж не рассматриваем, именно баги, ошибки по неосторожности)? Реально очень интересно
И неужели вы в такой ситуации выберете первую фирму?
Могу сказать как разработчик ПО, что фирму, которая работает по Agile, себе в подрядчики я вряд ли выберу. С вероятностью 99% они будут максимально доить деньги, примерно как клиника страховую компанию. Я предпочту исполнителя, который составит смету по ТЗ, прикинет риски, установит свой рейт за изменения первоначального ТЗ.
Я если честно не совсем понимаю в чём в данном контексте аджайл фирма отличается от не аджайл? Как вы там будете смету составлять это же к аджайлу вообще никакого отношения не имеет.
Дык, типичная аджайл-фирма не будет осмечивать стоимость проекта вообще. Вернее, будет, но не дальше компреда, в договоре они будут подписываться на оплату часов по факту.
Я так подозреваю что какую-то статистику подтверждающую ваши слова вы привести не сможете.
С другой стороны я пока вроде бы ни в одной фирме не работал которая бы таким образом смету составляла.
С другой стороны я пока вроде бы ни в одной фирме не работал которая бы таким образом смету составляла.
Да какая статистика-то? Это банальный опыт сотрудничества. Может, у кого-то он отличается, я же писал про то, как я принимаю решения в этом вопросе.
Ну, в теории, фиксед скоуп в разных вариациях и аджайл прямо противоречат друг другу. Предварительные сметы по работам для аджайл бессмысленны. Аджайл нужен как раз там, где изначально скоуп не ясен и ясно, что он будет меняться. Внутренняя это разработка или внешний заказчик особо не важно, но общая схема аджайла это "работаем пока заказчик не скажет "горшочек не вари", при этом уверены, что требования заказчика будут меняться". Момент "Горшочек не вари" может быть оговорен заранее в виде сроков/бюджетов, но результат на этот момент заранее не фиксируется.
Опять же я никогда особо не лез в финансы и вещи вроде заключения контрактов, но насколько я всё это дело понял, то в «скрам-фирмах», которые работали с посторонними клиентами всегда как минимум были дефинированы какие-то майлстоуны и какой результат «минимально» ожидается по завершению.
А когда речь шла просто о ИТ-отделе или дочерней ИТ-фирме концерна, так там естественно всегда просто был какой-то годовой бюджет или что-то в этом роде. Но это как бы вне зависимости от конкретных процессов и от того был там какой-то аджайл или нет.
В общем по моему опыту у «клиентов» начальство и менеджмент обычно деньги считать умеют и тоже как бы не дураки. И обычно имеют позицию "мухи аджайл отдельно, котлеты деньги отдельно.
А когда речь шла просто о ИТ-отделе или дочерней ИТ-фирме концерна, так там естественно всегда просто был какой-то годовой бюджет или что-то в этом роде. Но это как бы вне зависимости от конкретных процессов и от того был там какой-то аджайл или нет.
В общем по моему опыту у «клиентов» начальство и менеджмент обычно деньги считать умеют и тоже как бы не дураки. И обычно имеют позицию "
А так да, аджайл как раз про погружение разработчиков в предметную область, чтобы они могли предложить достаточно эффективное решение задачи.
Скорее про помехи в оном погружении. Потому что никто кроме инженеров-программистов вообще никакое решение предложить не может по определению.
Забавно, что в этом же треде нелюбители аджайла говорят, что их самих заставляют исследовать предметную область и это им не нравится. Они хотят, чтобы им менеджеры приносили всё готовое и разжёванное.Это обычно характерно для неквалифицированных горе-разработчиков, не имеющих инженерного образования по специальности, вне зависимости от методологии.
Покер планирования — это метод оценки атомарных задач, на которые исходную задачу декомпозирует сама команда.Покер планирования сам по себе показатель полной некомпетентности разработчиков срама как методологии. Потому как призван минимизировать время разработки каждой отдельной фичи, что нарушает принцип суперпозиции (оптимальность каждого отдельно взятого элемента не гарантирует оптимальность комбинации). При этом нет никакой гарантии что все что было сделано для реализации этой фичи не придется переделывать при следующем бзике клиента. Время общей реализации проекта способно снизить только полное и универсальное покрытие каждым отдельно взятым атомарным компонентом его зоны ответственности, что приводит к экспоненциальному снижению объема атомарных задач при реализации новых фич /функциональности.
Но ведь покер вообще ничего не минимизирует.
Какой тогда в нем смысл если он ничего не минимизирует? При этом какой смысл оценки атомарных задач? Атомарная — значит не требует дальнейшей декомпозиции. А это возможно только в том случае если задача имеет известное тривиальное решение. А соответственно оценивать для таких задач уже нечего и декомпозиция на уровень таких задач есть ни что иное как результат полного цикла классического проектирования. А то что называют атомарными задачами в срамоагиле на самом деле вертиакльные срезы фич и покер планирования как раз и занимается минимизацие времени для конкретной фичи за счет кастрации компонентов из которых она собираетирается, что приводит к экспоненциальному росту как кода так и рефакторинга.
На мой взгляд единственный смысл этого покера это помочь найти консенсунс в команде и устранить возможное недопонимание. Если "оценки" расходятся, то значит кто-то в команде что-то понял по другому. И тргда надо выяснить почему это так произошло.
А если у вас в покере всегда все оценки одинаковые, то он вам и не нужен. Правда я лично такого пока не встречал.
А если у вас в покере всегда все оценки одинаковые, то он вам и не нужен. Правда я лично такого пока не встречал.Ну следовательно ни о каких атомарных задачах речь и не идет. Для них все оценки уже математически доказаны. Речь идет таки о кастрации компонентов вертикальных срезов фич что и приводит к экспоненциальному замедлению разработки.
Речь идёт о банальном планировании и прикидке того сколько примерно времени займёт каждая задача.
Неужели у вас в водопаде никто не занимается планированием хотя бы на две недели вперёд? И никто не прикидывает сколько времени уйдёт на ту или иную задачу или на разработку той или иной фичи? Как-то мне не верится чио ничего этого нет..
Нет кастрации вертиакльных срезоаов. Есть послойная реализация расширяемых наборов универсальных компонентов с закладкой всех мыслемых и немыслемых параметризаций и точек расширения. А как результат нет рефакторинга от слова совсем. Зато через очень короткое время компоненты начинают работать на тебя все больше и больше. Постройте экспоненту и график лагорифма. Они пересекутся в некоторой точке. До этой точки срам быстре. Дальше срам все сильнее и сильнее вязнет в рефакторинге и дублировании кода. Послойная же классическая разработка все больше и больше ускоряется за счет накопления номенклатуры повторно используемых универсальных первокирпичиков. При этом чем сложнее предметная область тем труднее предсказать где будет эта точка пересечения и тем ближе эта точка к нулю.
Ок. Теперь я примерно понимаю в чём проблема. Давайте зайдём с другой стороны: вы всегда выпускаете готовый продукт одним единственным "пакетом"? И никогда не занимаетесь вещами вроде дальнейшего развития продукта и добавления новых фич с течением времени?
Если это так, то скрам как таковой именно для вас не особо оптимален. Но можно посмотреть на каких-нибудь канбан.
Вы вооще воспринимаете что пишут? В исходе закладываются все мыслимые и немыслимые параметризаци и точки расширения.
Как результат исчезает необходимость в рефакторинге при расширениях.
А это в свою очередь делает ненужными ничего не тестирующие юнит-тесты, зато дает зеленый свет зависимым от реализации бренч-тестам, которые не только реально тестируют, но и показывают что именно, где именно, и почему не так в процессе отладки.
Как результат исчезает необходимость в рефакторинге при расширениях.
А это в свою очередь делает ненужными ничего не тестирующие юнит-тесты, зато дает зеленый свет зависимым от реализации бренч-тестам, которые не только реально тестируют, но и показывают что именно, где именно, и почему не так в процессе отладки.
Если даже допустить что вы можете предугадать все возможные "расширения" (во что лично я верю с трудом), то что мешает вам первым делом залепить ваш "исход", а потом уже спокойно допиливатт "расширения" по скраму?
Я их не предугадываю. Я закладываю возможность расширения без рефакторинга. Пример — как работает список всегда известно. Как аллоцируется под него память зависит от конкретной задачи. Поэтому делаем универсальный список которому аллокатор задается параметром и парочку ходовых вариантов аллокатора. В случае если понадобится более другой он доделывается без рефакторинга чего либо.
Я их не предугадываю. Я закладываю возможность расширения без рефакторинга.
Я всё ещё не понимаю почему вы считаете что вы в скраме не можете этого делать? Скрам позволяет вам перенести «планирование» какой-то части вещей на более поздний срок. Но он не запрещает вам запланировать что-то заранее.
Все проектты которые я делал в скраме «с нуля2 обычно имели стартовую фазу где были вещи воде PoС, планирования будущей архитектуры и „закладывания“ каких-то теоретических „возможностей“ на будущее.
В скраме все в конечном итоге построено по вертикальным срезам ака фичи с циклической переделкой уже сделанного. При научном же подходе разработка ведется слоями универсальных полностью законченных компонентов которые позволяют реализовывать любые фичи в рамках предметной области. Пример — геометрическое ядро имеющее только часть функциональности никому нафиг не надо.
Потому что для его юзабельности дожна быть обеспечена непротиворечивость. Т.е. в результате любых операций над любым списком из реализованного набора примитивов должен получаться список примитивов из того же набора. А соответсвенно реализация по фичам не имеет никакого смысла. Имеет смысл реализовывать по слоям абстрации
Потому что для его юзабельности дожна быть обеспечена непротиворечивость. Т.е. в результате любых операций над любым списком из реализованного набора примитивов должен получаться список примитивов из того же набора. А соответсвенно реализация по фичам не имеет никакого смысла. Имеет смысл реализовывать по слоям абстрации
В скраме все в конечном итоге построено по вертикальным срезам ака фичи с циклической переделкой уже сделанного
Мне всё ещё интересно откуда вы это взяли? Личный опыт? Или вы это как-то «формально вывели» из определения скарама? Если последнее, то можно поcмотреть как вы это сделали?
При научном же подходе разработка ведется слоями универсальных полностью законченных компонентов которые позволяют реализовывать любые фичи в рамках предметной области.
Даже если мы допустим что это оно так на самом деле(что в общем-то не само собой разумеется и как минимум требует доказательств), то почему это обязательно противоречит скраму?
то что мешает вам первым делом залепить ваш «исход», а потом уже спокойно допиливатт «расширения» по скраму?Они допиливаются по необходимости а не по скраму.
Так скрам и предпологает то самое «допиливание по необходимости». Это именно то что скрам и аджайл предлагают и в чём их преимущество. Та самая возможность решитъ что необходимо сейчас и что нужно «допиливать» сейчас.
Это предполагает нет не скрам а теория принятия решений. Т.е. зона ответсвенности компонентов разделяется на известную и неизменную для этого компонета часть а часть которая может менятся делегируется другому сменному компонету с которым этот компонент может работать как с черным ящиком. И именно это подразумевает классический водопад за счет чего и позволяет полностью избежать рефакторинга и т.д. Негоразды водопада проявляются в том что для избежания дублирования оных черных ящиков необходим их полный список предварительно. И решается это банально ведением учета и распределением между разрабами понадобившихся новых ящиков в реальном времени, а не плясками с бубном раз в месяц и нарезкой на фичи исключающие такой подход
Это предполагает нет не скрам а теория принятия решений.
То естъ по вашему если что-то предполагает теория принятия решений, то ни скрам, ни что-то другое этого же предполагатъ уже не могут? :)
Т.е. зона ответсвенности компонентов разделяется на известную и неизменную для этого компонета часть а часть которая может менятся делегируется другому сменному компонету с которым этот компонент может работать как с черным ящиком. И именно это подразумевает классический водопад за счет чего и позволяет полностью избежать рефакторинга и т.д.
На мой взгляд это всё вообще лежит «вне плоскости» вещей вроде скрама и водопада. То естъ это спокойно можно делать и в скрамe и точно так же это совершенно спокойно может отсутсвовать и в водопаде.
И решается это банально ведением учета и распределением между разрабами понадобившихся новых ящиков в реальном времени, а не плясками с бубном раз в месяц и нарезкой на фичи исключающие такой подход
Ну так делайте это в скраме в «реальном времени», кто вам это запрещает? Я всё ещё не понимаю в чём проблема.
Mожетe хоть какой-то конкретный пример привести на примере конкретных фич? Ну то есть как это работает у вас и почему по вашему это точно так же нельзя будет сделать в скраме…
Но можно посмотреть на каких-нибудь канбан.Это на 100% противоположно кэнбэн поскольку при каскадном водопаде имеем дело опять же с не доконца известной предметноетной областью. Т.е. к примеру если нужен парсер JSON то сделай его через универсальный PEG c переключением на лету пораждающего и детектирующего режимов. Иначе какой то горе-умник вложил в какое то веб-апи с которым потребуется взаимодейстовать какие либо объекты сериализованные внутри строк горя не оберешся с впихиванием невпихуемого, рефакторингом, и закончится вся эта эпопея таки универсальным PEG парсером который все это разрулит за 5 минут и для XML и для заголовков HTTP и для HTML и для чего угодно.
Это на 100% противоположно кэнбэн поскольку при каскадном водопаде имеем дело опять же с не доконца известной предметноетной областью.
Вы бы уже определились что ли. то вы можете предусмотреть «все расширения и параметризацию», то вы имеете дело с «не доконца известной предметноетной областью»… Если у вас не всё ясно на 100%, то берёте скрам, планируете известные вам 90% процентов и начинаете их делать с учётом оставшися 10% и возможных вариантов. А потом когда доходите до этих самых оставшихся 10%, то уже планируете их детально. В чём проблема?
Вы бы уже определились что ли. то вы можете предусмотреть «все расширения и параметризацию», то вы имеете дело с «не доконца известной предметноетной областью»…
Вот как раз для работы с не до конца известной предметной областью и нужны гибкие компоненты — т.е. полностью покрывющие свою зону ответсвенности с заложенными по максимум возможностями параметризации их черными ящиками. Вы похоже не понимаете суть полного покрытия компонентом его зоны ответственности. Это означает что что бы от него не понадобилось в будущем в рамках его зоны ответственности он уже способен это сделать.
Именно это и ломает скрам его нарезкой на фичи. Т.е. если типа седня нужен парсер JSON лепим на коленке пять спринтов парсер JSON завтра нужен парсер XML лепим еще 5 спринтов парсер XML — это не универсальный подход. Сразу всовываем универсальный КС-парсер и в результате что для JSON что для XML что для CPP достаточно указать нужную грамматику и куда сложить результат. И именно такой подход дает скорость в не до конца исследованной предметной области а не нарезка на фичи.
Именно это и ломает скрам его нарезкой на фичи. Т.е. если типа седня нужен парсер JSON лепим на коленке пять спринтов парсер JSON завтра нужен парсер XML лепим еще 5 спринтов парсер XML
У вас на мой взгляд какое-то ну очень извратное понимание скрама. Если ко мне приходит клиент и говорит «мне нужен парсер под JSON», то я его спрашиваю уверен ли он что нужен только парсер под JSON или есть хотъ малейшая вероятность того что понадобится ещё и какой-то другой парсер. И если такая вероятность не исключена, то мы с ним решаем не имеет ли смысла потратить сейчас немного больше времени, но зато при этом подготовить систему к тому что в будущем будут добавлены и другие парсеры тоже.
Это на мой взгляд вообще не вопрос скрама или не скрама. Это вопрос грамотного подхода к программированию в целом.
НЛО прилетело и опубликовало эту надпись здесь
Клиент говорит нужно стянуть и определенным образом обработать инфу с того то того то того то и того то сайтов. На сайтах есть REST там вроде джейсон заявлен но что в самих джейсонах может быть черт ногу сломит — в доке официяльно ищите полный список в сырцах их серва. С каких сайтов он захочет добавить инфу завтра мы не знаем. Вернее ему еще даже мысль не пришла что он может захотеть подумать еще что то добавить. Но известно что сайты подобной тематики имеют свойство плодится хотя и не ежедневно.
Универсальный парсер от месяца. JSON с возможностью кое-какой кастомизации типа замены знаков припинания/убрать имена полей и т.п. которая для такого парсера возможный максимум — 4-8 часов.Если заложим толко JSON в случае замены его на универсальный рефакторинг обещается быть эпическим.
Система хранилищ с автоматическим декларативно настраиваемым распознанием семантики (ну там по ключам связать полученные данные между собой и т.д.) — около месяца в любом случае. Насколько глубоко рефакторинг в случае замены может коснутся ее неизвестно, потому что реализовывать ее надо уже при наличии парсера (отладить без поступления данных из парсера не удастся).
При этом знаем что и компоненты системы хранилищ и универсальный парсер точно имеют огромный потенциал повторного использования в том числе и в этом проекте. Универсальный парсер при этом ускорит еще и разработку бойлерплейтов привязки. Че делать будем?
Вот что интересно — в сраме что действительно принято заставлять клиента производить анализ водопадом до мельчайшего винтика маскируя это под типа скажите хотелки? А то что то хотелки какие то слишком мелкие в духе хочет джейсон или хочется другой — ну какие то уж неестественно близкие для клиента к системной части о которой он знать ничего не хочет. В реальности его ниче из этого не интерисует кроме результатов обработки его инфы побыстрее.
А так вооще от самая веселая хотелка которую слышал — эт от директора индустриального гиганта — хочу чтобы я кнопку нажал, и у меня на экране сразу показало сколько сегодня завод заработал сколько потерял, и кто в этом виноват. А детали реализации ему абсолютно не интересны. Ему тупо не до вникания в них и даже не до выслушивания их.
Универсальный парсер от месяца. JSON с возможностью кое-какой кастомизации типа замены знаков припинания/убрать имена полей и т.п. которая для такого парсера возможный максимум — 4-8 часов.Если заложим толко JSON в случае замены его на универсальный рефакторинг обещается быть эпическим.
Система хранилищ с автоматическим декларативно настраиваемым распознанием семантики (ну там по ключам связать полученные данные между собой и т.д.) — около месяца в любом случае. Насколько глубоко рефакторинг в случае замены может коснутся ее неизвестно, потому что реализовывать ее надо уже при наличии парсера (отладить без поступления данных из парсера не удастся).
При этом знаем что и компоненты системы хранилищ и универсальный парсер точно имеют огромный потенциал повторного использования в том числе и в этом проекте. Универсальный парсер при этом ускорит еще и разработку бойлерплейтов привязки. Че делать будем?
Вот что интересно — в сраме что действительно принято заставлять клиента производить анализ водопадом до мельчайшего винтика маскируя это под типа скажите хотелки? А то что то хотелки какие то слишком мелкие в духе хочет джейсон или хочется другой — ну какие то уж неестественно близкие для клиента к системной части о которой он знать ничего не хочет. В реальности его ниче из этого не интерисует кроме результатов обработки его инфы побыстрее.
А так вооще от самая веселая хотелка которую слышал — эт от директора индустриального гиганта — хочу чтобы я кнопку нажал, и у меня на экране сразу показало сколько сегодня завод заработал сколько потерял, и кто в этом виноват. А детали реализации ему абсолютно не интересны. Ему тупо не до вникания в них и даже не до выслушивания их.
Насколько глубоко рефакторинг в случае замены может коснутся ее неизвестно, потому что реализовывать ее надо уже при наличии парсера (отладить без поступления данных из парсера не удастся).
Вы вот это сейчас серьёзно? Вы мне тут столько времени рассказываете про «разработку по науке» и при этом у вас проблема написать и протестировать систему без уже готового парсера? Что например мешает просто дефинировать интерфейс на стыке между парсером и вашей системой хранилищ? И тогда и парсер можно без проблем в любой момент поменять или даже несколько одновременно использовать. И можно в любой момент начинать тестировать систему не имея готового парсера…
Вот что интересно — в сраме что действительно принято заставлять клиента производить анализ водопадом до мельчайшего винтика маскируя это под типа скажите хотелки?
При необходимости да. Но обычно в этом необходимости нет.
А так вооще от самая веселая хотелка которую слышал — эт от директора индустриального гиганта — хочу чтобы я кнопку нажал, и у меня на экране сразу показало сколько сегодня завод заработал сколько потерял, и кто в этом виноват.
Нормальная хотелка. Вопрос только в том реализуемо ли это при их процессах и имеющейся информации или нет. Но это обычно выясняется ещё до старта проекта. То есть до того как начинается собственно скрам.
А «гибкость» скрама в данном случае это вещи вроде «где вы хотите расположить кнопку и какого она должна быть цвета» и «нужна ли возможность экспортировать полученную информацию и в каком формате это надо делать». И такие вещи уже обычно и ближе к делу можно обсудить.
А «гибкость» скрама в данном случае это вещи вроде «где вы хотите расположить кнопку и какого она должна быть цвета»
А я то по наивности думал что Drag & Dock в этом плане погибче будет.
И такие вещи уже обычно и ближе к делу можно обсудить.Такие вещи вообще не обсуждаются. Либо этот отчет есть в должностной инструкции на проведение учета либо бухгалтерша и иже с ним скажет что его не хватает для удобства. Заказчик то зачем? Нужны контакты с непосредственно исполнителями которые сейчас делают это вручную/на старой софтине.
И тогда и парсер можно без проблем в любой момент поменять или даже несколько одновременно использоватьНу естественно что там все декомпозировано. Вопрос в том что вложения — это зависимость синтаксиса от семантики. И сложность как раз в том чтобы втулить это переключение в адаптер порождающего режима. И по ходу с универсальным парсером это будет абсолютно не совместимо. У них банально разный способ выхода данных.
И можно в любой момент начинать тестировать систему не имея готового парсера…Если бы система тестировалась бы на синтетических данных фейл в результате был бы эпическим. Данные банально приходят не в том порядке как ожидалось. Какой то нехороший
Но суть не в этом. Суть в том что сначала под давлением клиента была заложена техническая задолженность в виде неуниверсального парсера. Главное в том к чему это привело. Когда оттуда поперли закладки началось прикручивание переключателя и т.д. Полтора месяца ушло только на то чтобы втыкнуть что это зависимость синтаксиса от семантики, чего вменяемый разраб формата данных в принципе никогда не сделает, так же как и подобных закладок вообще. При этом уже по принципу делать универсальный дольше чем доделать то что осталось здесь чтобы распарсить, эта эпопея с новыми нежданчикми на каждом шагу продолжалась месяца три, после чего в данных до которых удалось добраться вылез такой нежданчик, который в принципе нельзя распознать переключением знаков припенаний в неуниверсальном парсере.
Мораль сей басни такова:
Клиент всегда не прав — идти у него на поводу только терять время. А особенно в вопросах в которых нет полноты информации на момент принятия технического решения.
НЛО прилетело и опубликовало эту надпись здесь
Ладно, спасибо конечно за общение, но вы всё больше и больше пишите какую-то ерунду и всё больше и больше начинаете сами себе противоречить. Так что пожалуй лично я дискуссию на этом закончу. Счастливо оставаться и не болейте.
НЛО прилетело и опубликовало эту надпись здесь
Гораздо быстрее чем нарезка на вертикальные слои с постоянным рефакторингом, который будет продолжаться до тех пор, пока все не будет переделано с нуля по слоям.
При этом чем крупнее/сложнее проект тем быстрее разработка по слоям поскольку каждый предыдущий слой ускоряет разработку следующего. А универсальность компонент слоя исключает любые рефактор-нежданчики со стороны не до конца исследованной предметной области.
При этом чем крупнее/сложнее проект тем быстрее разработка по слоям поскольку каждый предыдущий слой ускоряет разработку следующего. А универсальность компонент слоя исключает любые рефактор-нежданчики со стороны не до конца исследованной предметной области.
НЛО прилетело и опубликовало эту надпись здесь
Чем меньше деталей известно о предметной области/изменениях в будущем тем ближе эта точка пересечения к нулю.
мне нужно быстро перед Новым годом запустить продукт хотя бы в каком-то виде, чтобы получить первых клиентов.Та вот как раз недавно был интересный случай. Насрамоаилили одному клиенту от так от в срок системку которая по задуумке дожна стать очень посещаемой. Единственное что вышло в результате — Овер 40 килобаксов чистого убытку в первый месяц по причине бага и после устранения (а вернее обкладывания табличками тут заминировано бага) софт требующий в случае необходимости масштабирования полной переделки с нуля. Чем собственно сейчас и занимаюсь. И вопрос стоит не когда а чтобы без багов.
Оно было развернуто в AWS/GCP/Azure или там просто никто не проверял часть, которая работает с деньгами?
Это тупо был баг позволяющий использовать сид одной казиношной игры в другой когда рандом уже известен. Огораживание бага потребовало общей базы отыганных хешей что в результате исключает масштабируемость поскольку она упрется в производительность базы которая не может иметь временную рассогласованность данных иначе баг будет активен.
НЛО прилетело и опубликовало эту надпись здесь
Водопадная модель сама по себе тоже не сможет оценить потенциальные изменения в будущем.А вопрос стоит не об оценке изменений в бущем, а о том что любой разработанный компонент принципиально не должен теребовать изменений при любом изменении фич в будущем. При этом требуется только переконфигурация/пересборка/расширение номенклатуры вспомогательных параметризующих его компонентов. Вооще вы похоже не понимаете суть классики. По классике — даже если знаешь что то о конкретной конфигурации/частном случае использовании компонета, лучше заложи то что ничего об этом не знаешь какая там конфигурация/юсекейс будет. Он для примеру возьмите любой оконный фреймверк или любой оконный фреймверк или любую стандартную библиотеку любого языка. При их проектировании как то абсолютно неизвестно в каких задачах они будут использоваться. Но никакой необходимости их рефакторинга для прикручивания к конкретно взятой задаче никогда не возникает. Вот вам явный пример слоеной разработки. Т.е. все эти «невозможно предсказать» — не более чем миф Свидетелей Срама. На самом то деле даже предсказывать ничего не надо. Достаточно просто производить декомпозицию на универсальные компоненты. А в силу своей универсальности они подойдут как оные атомарные кирпичики к любой задаче из их направления.
По классике — даже если знаешь что то о конкретной конфигурации/частном случае использовании компонета, лучше заложи то что ничего об этом не знаешь какая там конфигурация/юсекейс будет.
В большинстве случаев такой подход на практике просто нереализуем. Потому что даже если взять мой нынешний проект, то пока я закончу закаладывать базу для абсолютно любых возможных в будущем изменений, мой проект настолько морально и технически устареет что никому уже нафиг не будет нужен. Потому что этих самых «возможных в будущем изменений» настолько много что я их только разбирать, каталогизировать и формализировать несколько лет буду.
НЛО прилетело и опубликовало эту надпись здесь
Масштабирование системы они учли. А вот проанализировать пригодность к нему взятого с гита алгоритма контроля честности забыли.
А вооще там все очень грустно. Полная каша в части смарт-контрактов по причине того что нет нормальной системы учета и конфигурации. Нормальной системы учета и конфигурации которая не допустила бы кашу даже не пытались поскольку нет тулза для нормального просмотра таблиц и отслеживания изменений в них. В результате напихали все в одну таблицу для которой сделалиспециализированный кастомный просмотрщик. вроде все пашет вроде рабочий сайт рабочее все есть но через две недели слили половину кассы — хорошо хоть овнер заметил процесс и положил серв. Одно им оправдание — что конкурентов которые у них контракты скопировали слили вообще в ноль. От сижу пилю тулз для нормального просмотра таблиц которые в соответсвии со скрамом и одобрямсом заказчика ими был признан некритичным а то и не нужным и оставлен на потом. Хотя конечно форматы там такие и что парсить их на же-се и гуй соответствующий рисовать лучше не связываться. а с профессиональными языками они давно дружить перестали. 15 лет опыта веб дева у ребят
А вооще там все очень грустно. Полная каша в части смарт-контрактов по причине того что нет нормальной системы учета и конфигурации. Нормальной системы учета и конфигурации которая не допустила бы кашу даже не пытались поскольку нет тулза для нормального просмотра таблиц и отслеживания изменений в них. В результате напихали все в одну таблицу для которой сделалиспециализированный кастомный просмотрщик. вроде все пашет вроде рабочий сайт рабочее все есть но через две недели слили половину кассы — хорошо хоть овнер заметил процесс и положил серв. Одно им оправдание — что конкурентов которые у них контракты скопировали слили вообще в ноль. От сижу пилю тулз для нормального просмотра таблиц которые в соответсвии со скрамом и одобрямсом заказчика ими был признан некритичным а то и не нужным и оставлен на потом. Хотя конечно форматы там такие и что парсить их на же-се и гуй соответствующий рисовать лучше не связываться. а с профессиональными языками они давно дружить перестали. 15 лет опыта веб дева у ребят
с закладкой всех мыслемых и немыслемых параметризаций и точек расширения.
Всех нужных и не нужных?
А откуда мы знаем какие понадобятся а какие нет? При этом закладка возможности расширения имеет свойство не только гибкость увеличивать но и снижать сложность разработки самого компонента. Это в основном делается декомпозицией по зонам ответсвенности.
Я вообще не представляю как так можно работать, если вы, конечно, не троллите.
Условно, вы должны выпускать сразу продукт в котором есть все-все-все фичи никак не получая обратной связи с рынком/пользователями. Либо у вас какая-то специфическая ниша, либо вы чего-то не замечаете, либо вы тролите.
Условно, вы должы выпускать сразу продукт в котором есть все-все-все фичи никак не получая обратной связи с рынком/пользователями.Условно говоря я сначала создаю технологический базис моделей сущности предметной области обеспечивющий декларативную сборку самоуправляемых иерархий. Ну такую себе роботизированную фабрику фич способную в том числе и к саморасширению и при этом не имеющую абсолютно никаких технологических задолженностей. А потом уже хренячу с ее помощью фичи по принципу чем больше тем лучше.
Условно, вы должны выпускать сразу продукт в котором есть все-все-все фичи никак не получая обратной связи с рынком/пользователями.Для того чтобы сделать к примеру геометрическое ядро вам нужны учебник по начерталке учебник по вычислительной геометрии и учебник по матанализу, а никак не обратная связь с рынком или заказчиком. И фичи там действительно нужны сразу все. Иначе оно абсолютно не юзабельно. И такого софта 99%. Исключения составляют разве что веб-лендинги которые относятся по большому счету к к интерактивной рекламной полиграфии а не к софту.
И откуда такая уверенность что для разработки чего то нужна связь с рынком или что рынок даст какой то фидбек четвертьфабрикату? Вы когда нибудь первый раздел диплома писали? Ну вот там четко написано почему куцый обрубок будет поиметь эпический фэйл на маркетплейсе и никакого фидбека дать не может в принципе и почему этот фидбек не нужен от слова совсем.
Это потому, что большинство нынешних так называемых программистов — на самом деле быдлокодеры, и кроме популярных вещей, типа веба, мало что в жизни видали. Из наиболее понятных такому "массовому кодеру" вещей будут, видимо, только те, которыми занимаются системные программисты.
Ну, например, интерфейсы ядра или libc — пока Вы минимум сотню функций не реализуете, на Вашей системе (hint: это не только специфический случай "своя операционка", это еще куча самых разных применений, начиная от виртуализации) не будут запускаться даже достаточно простые программы. И Вы о них, этих программах, заранее ничего не знаете. Или графический фреймворк — пока он не умеет некое, весьма широкое, множество поддерживаемых функций, он тоже будет никому не нужен (и о программах, которые будут использовать, опять-таки ничего не знаете). Можно вспомнить, как первоначальные авторы Qt благодарили своих жен за то, что те верили в них и поддерживали те первые 2-3 года, пока создавалась эта базовая часть.
Печально, что фразы товарища "стандартная библиотека любого языка" и "геометрическое ядро" требуют вот такого разжевывания примерами на пальцах, когда мы вроде как на программистском ресурсе...
пока Вы минимум сотню функций не реализуете, на Вашей системе
Не-не-не, никакого минимума, перечитайте то сообщение которое обсуждается
"с закладкой всех мыслемых и немыслемых параметризаций и точек расширения."
Так что все сразу.
Так это то же самое. Возьмем, например, стандартную юниксовую функцию read() — она должна уметь и обычные файлы, и устройства, и TCP-сокеты, и… Вот они, заложены, все эти мыслимые, а также на момент создания в 70-х, и немыслимые, расширения.
Под сотней функций имелось в виду то, что если с конкретным приложением повезёт, оно на них уже запустится, порадоваться, так сказать, пока полная поддержка всего-всего еще не готова, и уже показать заказчику.
Всё что должны делать менеджер и заказчик это решить какие фичи этот самый заказчик хочет от вас получить. И например описать эти фичи в виде user story или любого другого формата который предпочитает команда.
А как конкретно эти фичи будут реализованы и как их разбить на задачи это решает уже сама команда. И сколько времени займёт реализация тоже она решает. И реализуемо ли это в принципе.
А с каких пор менеджер и заказчик стали настолько квалифицированными в вопросе автоматизации чего либо что возомнили себя в состоянии решать какие именно фичи и в каком порядке необходимо реализовывать для достижения целей автоматизации? И с каких это пор нарезка на вертикальные срезы ака фичи стала способствовать ускорению разработки и повышению качества софта? Наоборот это только экспоненциально затягивает разработку и вносит баги принципиально не приемлимые в примерно 75% задач индустрии (инженерный и научный расчет и управление оборудованием в реальном масштабе времени), и ведущие к финансовым потерям кратно превосходящим не то что стоимость разработки а потенциальный выхлоп от автоматизации еще в примерно 24% задач (сфера корпоративного учета).
А с каких пор менеджер и заказчик стали настолько квалифицированными в вопросе автоматизации чего либо что возомнили себя в состоянии решать какие именно фичи и в каком порядке необходимо реализовывать для достижения целей автоматизации?
Ок, тут произошло недопонимание. В моём понимании это и в данном контексте это не «фичи». «Фичи» это например «возможность обновления версий с минимальмным оффлайном системы». А как это будет реализовано это решает уже команда.
И с каких это пор нарезка на вертикальные срезы ака фичи стала способствовать ускорению разработки и повышению качества софта?
А с кaких пор «нарезка на вертикальные срезы» являтся обязательным условием скрама? С чего вы решили что скрам без этого работать не может?
«Фичи» это например «возможность обновления версий с минимальмным оффлайном системы»
А в моем понимании это не фичи а дурость. Зачем закладывать понос обновлений в то что можно сделать сразу? Может лучше заложить что то в духе норматива безотказного работы системы без технического обслуживания и других остановок этак в 10-20 тысяч часов? От это то что реально требуется от подавляющего большинства софта. При этом допустимость частичной реализации из говна без палок с последующим доливанием свежего поноса обнов опять же допустима только для мусорных веб-хеллоувердов с нулевой ответственностью софта, которые составляют не более 1% задач индустрии, и относятся по большому счету к интерактивной рекламной полиграфии, а не к софту как таковому.
А в моем понимании это не фичи а дурость. Зачем закладывать понос обновлений в то что можно сделать сразу?
Если это клиенту десйтвительно необходимо, то это его дело. Ситуации разные бывают.
При этом допустимость частичной реализации из говна без палок с последующим доливанием свежего поноса обнов опять же допустима только для мусорных веб-хеллоувердов с нулевой ответственностью софта, которые составляют не более 1% задач индустрии, и относятся по большому счету к интерактивной рекламной полиграфии, а не к софту как таковом
Я сейчас пишу софт для автоматических продукционных линий для различных клиентов. Вообще ни грамма веба у нас нет. Но почему-то всем клиентам такое надо. То есть сначала именно базовые версии но с возможнстью добавления новой функциональности позже при необходимости.
Может лучше заложить что то в духе норматива безотказного работы системы без технического обслуживания и других остановок этак в 10-20 тысяч часов?
Может и лучше. Обсудите это с клиентом, опишите как фичу и отдайте вашим разработчикам делать. В чём проблема то?
Может и лучше.Это обычно не лучше а таки требование к оным линиям. Причем достаточно мягкое.
Я сейчас пишу софт для автоматических продукционных линий для различных клиентов.Нескромный вопрос — какая максимальная мощность приводов на этих линиях?
Это обычно не лучше а таки требование к оным линиям. Причем достаточно мягкое.
Это уже клиенты обычно сами решают по каким-то своим внутренним причинам.
Нескромный вопрос — какая максимальная мощность приводов на этих линиях?
Не могу вам сказать потому что это до сих пор не было важно в контексте моих задач.
Потому что горизонтальная нарезка с универсальной реализацией каждого компонента сразу называется классика.
Кем называется? И почему? И самое главное какое это имеет отношение к моим вопросам?
Вопрос — зачем нужны срамные пляски с бубном если не то что его какая то пригодность к изменениям предметной области миф, а сами изменения предметной области/требований — миф вызванный недостаточной глубиной анализа оной, при том что именно срам и прочий агил и приводит к оной недостаточности глубины анализа?
Еще один момент — при разделении задач между разрабами нельзя точно определить какие кому компоненты понадобится создать для реализации его части. А соответсвенно это определяется в процессе. Поэтому чем больше команда/проект тем вероятнее дублирование компонентов особенно нижнего слоя абстракции. А соответственно первым делом стоит прикинуть тот минимальный набор нижнего уровня абстракции, который понадобится в любом случае, реализовать его расширяемым, и только потом уже приступать к следующему слою. При этом во избежание дублирования расширений базового набора спецификация добавляемых компонентов должна сначала искаться в существующей базе и только в случае ее отсутствия сначала вносится в базу а потом уже реализовываться. Именно это дает экспоненциальный прирост скорости реализации функциональности. И именно это срам полностью исключает своими спринтами и прочими глюпостями
Извините а почему вы решили что скрам это исключает? Кто вам мешает это делать? Всякие грумминги на мой взгляд как раз для этого и существуют в скраме.
Декомпозицию до тривиальных компонентов выполняет каждый разраб самостоятельно в процессе. А соответсвено во избежании дублирования и окостыливания оных компонентов и их сборок их номенклатура/спецификация должна утрясаться планироваться и расшариваться между разрабами непрерывно, а не раз в вечность за 5 минут. Фиксированность же скрама в пределах спринта заставляет каждого костылить свой кастрированный вариант одного и того же иначе спринт не будет выполнен.
Декомпозицию до тривиальных компонентов выполняет каждый разраб самостоятельно в процессе.
А таски у вас тоже каждый сам для себя делает? ТЗ каждый сам для себя пишет?
Фиксированность же скрама в пределах спринта заставляет каждого костылить свой кастрированный вариант одного и того же иначе спринт не будет выполнен.
Я всё ещё не понимаю с чего вы это взяли. Ни разу такого не встречал до сих пор…
Я встречал. Причём не из-за каких-то там зависимостей, а просто не распознали, что часть функциональности двух задач пересекается и могла бы быть выделена в отдельную задачу.
«Не распознали» я тоже часто встречал. И не только в скраме. А вот чтобы какой-то процесс сам по себе заствалял людей «не распознавать»…
Вариант: в спринте две таких таски, на разных людей, четко подогнать, чтоб один начал, когда другой закончит, чтобы использовать его наработки, не получается по процессам принятым в рамках скрама, типа что фича считается законченной, тогда и только тогда, когда ее можно деплоить.
Ну это как-то очень искуственно сделанная ситуация. Например кто мешает тогда оба таска отдать одному разработчику. Или просто как-то по другому разбить таски и часть из них перенести на другой спринт. То есть это конечно от конкретной ситуации зависит, но если такую проблему обнаружили, то на мой взгляд её в скраме можно решить без особых проблем.
Решить её можно, если все сочтут, что проблема действительно в плохом разбитии на таски, их приоритетах и т. п., а не в том, что разработчики оценивать не умеют.
Я что-то всё больше и больше начинаю подозревать что мне с моим опытом аджайла-скрама как-то очень сильно повезло.
То есть мы сейчас этим всем «оцениванием» уже даже не особо и заморачиваемся. Примерно прикидываем что мы успеем сделать в следующий спринт и всё. Ну бывает конечно что ошибаемся на один-два таска в ту или иную сторону, но это в общем-то ни нас не волнует, ни начальство, ни даже клиентов. В «среднем» скорость выдачи новых фич нормальная, багов особых нет и все вроде бы довольны.
То есть мы сейчас этим всем «оцениванием» уже даже не особо и заморачиваемся. Примерно прикидываем что мы успеем сделать в следующий спринт и всё. Ну бывает конечно что ошибаемся на один-два таска в ту или иную сторону, но это в общем-то ни нас не волнует, ни начальство, ни даже клиентов. В «среднем» скорость выдачи новых фич нормальная, багов особых нет и все вроде бы довольны.
ТЗ каждый сам для себя пишет?А кто их будет писать если клиент в этом нифига не смыслит? Поэтому он к разрабам и обращается, что автоматизация хочется, но самому не можется. При этом ТЗ — это результат поверхностного анализа задачи и отправная точка для более глубокого анализа и написания постановки задачи, которая уже в свою очередь является основой программной реализации. И без четкой постановки разрабатывать код вооще никакого смысла не имеет. А позволяет запустить реализацию до полного завершения постановки именно тот факт что ее задача — выделить глубинные универсальные сущности предметной области из которых собираются «фичи», что и позволяет начать разработку закольцованных по зависимостям на себя инфраструктурных слоев абстракций до полного завершения постановки.
А кто их будет писать если клиент в этом нифига не смыслит?
То есть я вас правильно понимаю что у вас каждый разработчик просто сам решает когда что и как он будет делать? И это вообще никем и никак не контролируется? Ни начальством, ни каким-нибудь тимлидом? А клиенты вам просто деньги платят и в процесе вообще никак не участвуют? И просто потом получают что-то, что ваши программисты в этот раз решили написать? Хорошо живёте :)
При этом ТЗ — это результат поверхностного анализа задачи и отправная точка для более глубокого анализа и написания постановки задачи, которая уже в свою очередь является основой программной реализации.
Ну вот смотрите кaк это примерно работает в скраме. То есть как минимум у нас: клиент с менеджером обсуждают что клиент хочет получить на выходе. Потом это оформляется в те самые user story. Потом менеджер с кем-то из сениоров прозматривают user story и если user story более-менее тривиальные, то сразу лепят из них PBI(читай ваше ТЗ). Если user story не тривиальные, то они сначала отправляются на грумминг где разрабы думают реализуемо ли это и если да, то как из всего этого слепить адекватный PBI. Потом на плэнинге вся команда решает какие PBI можно будет сделать в следующем спринте. Потом разрабы примерно делят PBI между собой и уже тогда сами их анализируют и по необходимости разбивают на таски.
Ну вот смотрите кк это примерно работает в скраме. То есть как минимум у нас: клиент с менеджером обсуждают что клиент хочет получить на выходе.
А теперь как это делается по нормальному — клиент в данном случае дирекция завода говорит — у нас Овер 200 килобаксов в сутки потери на телефонной передаче химсостава между цехами. Ану там отдел АСУТП сделайте что нибудь. Назначается пара человек которые этим будут заниматься и побежали эти пара разрабов по всем лабораториям химанализа на заводе выяснять что там и как что надо сделать и какое оборудование для этого надо и т.д. И от это называется хорошо живут. А отлично живут это к примеру когда разрабы сами выдвигают идею к примеру автоматически обестачивать некритичное оборудование, время возврата которого в стендбай по необходимости допускает подъем из холодного состояния что в масштабах завода и реализуется месяца за три на всех системах и экономии дает в мегабаксах. И никакой насяльника/менеджер этой фичи увидеть не в состоянии.
Ну или более простой пример — разработка системы расчет з/п. Вывалит знач бугалтер простыню видов начислений и удержани такую шо просто ховайся так она еще и имеет свойство постоянно меняться. И срамоагилить это будут до бесконечности через манагеров и насялника которые не в теме. А докопаться до того что там принципов расчета суммы меньше десятка, и чуйство глубокого сексуального удовлетворения оная бугалтерша испытывает не от всей этой захордкоженной простыни, а от примитивнейшего конструктора удержаний и начислений который делается толковым школьником за два дня и позволяет ей иметь все изменения здесь и сейчас а не после следующего спринта — ну это тока программисту дадено при детальном допросе с пристрастием оной бухгалтерши, ибо именно инженер-программист обучен выделять такие абстракции а никак не бухгалтерша и тем более не менеджер и не насяльника.
А теперь как это делается по нормальному
Я честно говоря не совсем понимаю с чего это вдруг описанная вами ситуация вдруг стала «по нормальному» :)
А отлично живут это к примеру когда разрабы сами выдвигают идею к примеру автоматически обестачивать некритичное оборудование, время возврата которого в стендбай по необходимости допускает подъем из холодного состояния что в масштабах завода и реализуется месяца за три на всех системах и экономии дает в мегабаксах. И никакой насяльника/менеджер этого увидеть не в состоянии
Это если разрабы работают прямо на предприятии и ещё и разбираются во всё происходящем на все 100%. А такое это тоже редкость. И если уж на то пошло то по моему опыту средние менеджеры/нчальство обычно в таких вещах разбираются не хуже средних разрабов.
Я честно говоря не совсем понимаю с чего это вдруг описанная вами ситуация вдруг стала «по нормальному» :)
По нормальному — это когда оценкой что можно сделать в плане автоматизации того или иного процесса занимаются квалифицированные в этой области специалисты. А квалифицированы в этой области исключительно инженеры- программисты. Ни одну другую специальность не обучают анализу процессов на предмет автоматизации.
По нормальному — это когда оценкой что можно сделать в плане автоматизации того или иного процесса занимаются квалифицированные в этой области специалисты. А квалифицированы в этой области исключительно инженеры- программисты.
Я вас сейчас наверное оченъ удивлю но как минимум у наших клиентов обычно есть и свои инженер и свои программисты и даже свои инженеры-программисты. И они как раз обычно и решают что там и как надо автоматизровать.
Потом они там у себя сами решают что из необходимого они будут делать сами, а что отдадут на аутсорс фирмам вроде нашей. Потому что во первых у них просто не хватает народа чтобы всё самим реализовать. А во вторых в вопросах не касающихся конкретно их инфраструктуры и их процессов у них know how меньше чем у сторонних фирм.
Ни одну другую специальность не обучают анализу процессов на предмет автоматизации.
Я вас сейчас наверное опять очень удивлю, но это давно уже не так. Этому уже давно много кого учат. И в том числе и менеджеров тоже :)
Я вас сейчас наверное оченъ удивлю но как минимум у наших клиентов обычно есть и свои инженер и свои программисты и даже свои инженеры-программисты. И они как раз обычно и решают что там и как надо автоматизровать.Т.е. делают четкую постановку задачи — т.е. полностью занимаются аналитикой и архитектурой. Если это касается систем учета — то для этой сферы уже овер 25 лет существуют тулзы в которых реализация задачи на 99,9% совпадает с компьютеризированным оформлением постановки.
Это возможно именно потому что для систем учета раздел математическая постановка практический пустой, а разделы информационная постановка и проект интерфейса нащелканные мышой попутно осуществляют декларативную сборку компонентов универсальной библиотеки для работы с БД и т.д. В результате для разработки нужен только аналити-архитектор и больше никто и никакие другие ноу-хау. Т.е. зачем им привлекать кого то если они могут спроектировать систему сами а это аналогично реализации?
При этом если требуются другие ноу-хау о которых они не в курсе то как они могут руководить их адаптацией к их системе?
В конце концов применимость каждой конкретной библиотеки и даже методики расчета к конкретно взятой задаче должна мтематически доказываться. А особенно когда это касается инженерного расчета и управления оборудованием.
Т.е. делают четкую постановку задачи — т.е. полностью занимаются аналитикой и архитектурой.
Нет, полную постановку задачи они не делают. Потому что свои нужды они понимают хорошо, а вот технологии для их реализации не особо. Поэтому аналитикой мы занимаемся вместе с ними, а вот архитектура как раз таки целиком на нас.
Это если разрабы работают прямо на предприятии и ещё и разбираются во всё происходящем на все 100%.
Ну вот именно для этого крупные конторы и держат свои отделы АСУТП АСУП и т.д. и такое отслеживание должностной обязанностью инженеров-программистов. Если и не всех поголовно, то специально выделенной группы. И это позволяет развивать системы с опережением а не в догонку.
НЛО прилетело и опубликовало эту надпись здесь
У нас в командах такое было неоднократно. Вплоть до прямого общения с операторами — конечными пользователями системы в обход иерархии менеджеров-заказчиков.
Ну вот главный фишкан классики в том что эта иерархия вооще не нужна как таковая. Задача менеджера — организовать беспрепятственный доступ разрабов к необходимой доке/спецам по предметной области по необходимости своевременное обеспечение нужным оборудованием и прочие бытовые хотелки разрабов и не лезть в сам процесс.
Не факт. Команда разработки может и должна сама вникнуть в предметную
Когда она этим заниматься будет то??? Во время спринтов? Или во время планирования хаоса? И после какой сотни спринтов команду вдруг осенит что тут то тут не команда нужна а один человек за неделю со всей системой управится после нескольких часов допроса с пристрастием спеца по предметной области?
Программисты не должны ничего изобретать в предметной области (если это конечно не системное программирование — т.е. программирование ради облегчения программирования)
Они должны только адаптировать существующие методики к машинному счету. А соответсвенно манаджер и заказчик в этой цепочке — лишнее ненужное звено. Нужны непосредственно те спецы которые делают этот счет сейчас без компа идостаточное время на допросы с престрастием а потом анализ выбитой из них инфы на предмет адаптации к машинной обработке, до каких либо телодвижений по программной реализации.
А наиболе ненужное звено именно начальство конторы-заказчика. Самые толковые обычно сразу говорят — я не программист и не специалист в предметной области я не умею и не хочу в это вникать. В конце концов заказчик бабки разрабам платит за то чтобы он в это не вникал но это работало.
Можно и во время спринтов. Почему нет?
Ну это называется запрягать лошать позади телеги. Т.е. сначала что то планируем потом только выясняем что это и т.д. Какие к глиняной маме эстемайты вооще могут быть при таком подходе и какое избежание обкостыливания костылей?
Кто вам мешает сначала выделить какое-то количество спринтов на ознакомление и вникание?
P.S.То что вы пишите потихоньку начинает напоминать «сама придумала-сама обиделась». То есть вместо того чтобы подумать как что-то может работать в скраме вы тратите время и придумываете как это всё так усторить что оно в скраме обязательно не будет работать. С таким подходом я вам что угодно могу «очернить»…
P.S.То что вы пишите потихоньку начинает напоминать «сама придумала-сама обиделась». То есть вместо того чтобы подумать как что-то может работать в скраме вы тратите время и придумываете как это всё так усторить что оно в скраме обязательно не будет работать. С таким подходом я вам что угодно могу «очернить»…
Кто вам мешает сначала выделить какое-то количество спринтов на ознакомление и вникание?Ну это уже какое то угададай мелодию получается а не планирование.
Зачем вооще нужны спринты и все эти пляски с бубнами если в конечном итоге все равно все стремится к класcике при правильном подходе? Для того чтобы мешать разрабам нормально работать?
Ну это уже какое то угададай мелодию получается а не планирование.
С чего это вдруг? Bот вы в вашем водопаде когда занимаетесь ознакомлением и вниканием в тему?
Зачем вооще нужны спринты и все эти пляски с бубнами если в конечном итоге все равно все стремится к класcике при правильном подходе?
Потому что оно не «стремится к классике». Оно просто местами действует похоже, а местами нет.
Потому что оно не «стремится к классике». Оно просто местами действует похоже, а местами нет.Ну вот там где нет там и начинается абсолютный фейл. Потому что в такой штуке как софт реальную гибкость, а попутно и скорость реализации дает гибкость результата и составляющих его компонент. А именно на это во главу угла ставит и лучше всего обеспечивает классика. Поэтому и работает гораздо лучше срамов имеющих свойство превращаться в хаос ненужного рефакторинга. Единственное что в ней можно улучшать — это распараллеливать некоторые моменты которые это позволяют. А все остальные пляски с бубном — прямой путь к эпическому фейлу.
Ну вот там где нет там и начинается абсолютный фейл.
Вы в очередной раз делаете достаточно категоричное заявление, которое при этом не то чтобы обязательно соотвествует действительности. Я вот точно так же могу заявить что «там где нет там у классики и начинается абсолютный фейл, а скрам цветёт и пахнет розами». И дальше что? Оно от этого внезапно так станет?
Потому что в такой штуке как софт наибольшую гибкость а попутно и скорость дает гибкость результата и составляющих его компонент. А именно на это нацелен скрам.
Ну и опять же: я ваш текст поправил и теперь он на мой взгляд больше соотвествует действительности. Вы его в таком виде примете без каких-либо дальнейших разъяснений и доказательств с моей стороны? Почему вы ожидаете что я вдруг возьму и внезапно соглашусь с вашим вариантом?
Потому что в такой штуке как софт реальную гибкость, а попутно и скорость реализации дает гибкость результата и составляющих его компонент.
Аджайл прямо требует создание софта готового к изменениям. Водопадная классика в моём понимании — нет. Захотят программисты, возьмут на анализ и проектирование времени три раза больше, не захотят — не возьмут.
С чего это вдруг? Bот вы в вашем водопаде когда занимаетесь ознакомлением и вниканием в тему?А что по вашему есть постановка задачи?
А что по вашему есть постановка задачи?
У этого понятия есть много смыслов. Мне интересно какой вкладываете в это лично вы и почему вы решили что в скраме обязательно отсуствует какой-то аналог этому процессу. И почему он обязательно присутствует в абсолютно любом водопаде.
У этого понятия есть много смыслов.Конкретно применительно к разработке софта есть четкое определение. Это документ четко описывающий математические методы используемые при решении задачи. С доказательством их применимости к данной задаче, оптимальности выбранных методов, оптимизацией частных и пределов их применимости. В том числе схемы БД потоков данных запросы к БД, с доказательством непротеворечивости оных и т.д. и т.п. и весь остальной результат вникания в задачу по самые немогу. И именно с создания этого документа и начинается любая научно-обоснованная разработка, а не с бесполезных плясок с заказчиком под бубен менеджера.
И почему он обязательно присутствует в абсолютно любом водопаде.Потому что любой научно-обоснованный метод разработки построен вокруг именно постановки задачи. И это не обязательно водопад. Это в том числе и каскадный водопад и RAD. Но все они держатся на одном железном правиле — сначала полное завершение постановки в объеме достаточном для той или иной части потом реализация. При этом к примеру для RAD компьютеризированное оформление постановки это уже 99% реализации.
Конкретно применительно к разработке софта есть четкое определение.
Конкретно применительно к разработке это словосочетание даже вроде бы не во всех языках существует.
Потому что любой научно-обоснованный метод разработки построен вокруг именно постановки задачи.
Кто это сказал? И самое главное с каких это пор абсолютно любой водопад вдруг является научно-обоснованным методом разработки?
Но все они держатся на одном железном правиле — сначала полное завершение постановки в объеме достаточном для той или иной части потом реализация.
А по вашему в скраме реализация обязаетельно делается когда «постановка» сделана «в объеме не достаточном для той или иной части»? Я серьёзно не понимаю с чего вы это взяли. И на мой взгляд это опять же не относится к плоскости «скрам-водопад», а скорее к тому нормально вы пишите софт или кое как.
А по вашему в скраме реализация обязаетельно делается когда «постановка» сделана «в объеме не достаточном для той или иной части»?Если вы затрудняетесь ответить что такое постановка задачи то как вы ее можете создать?
Если вы затрудняетесь ответить что такое постановка задачи то как вы ее можете создать?
Ну я сомневаюсь что вы сможете детально описать весь процесс получения кислорода из воздуха вашим организмом. Да ещё и в правильной «биологической-химической терминологии» и на латыни. Но дышать вам это вряд ли особо мешает.
Ну я сомневаюсь что вы сможете детально описать весь процесс получения кислорода из воздуха вашим организмом.
НУ я как бе и не претендую на то чтобы называться биологом или даже врачем. А вот для того кто претендует называться программистом — умение создавать постановку задачи это основной рабочий инструмент.
НУ я как бе и не претендую на то чтобы называться биологом или даже врачем.
Но дышать то вы дышите? Или нет?
А вот для того кто претендует называться программистом — умение создавать постановку задачи это основной рабочий инструмент.
Во первых нет, это необходимо далеко не всем программистам. А во вторых это не обязательно должно называться " умение создавать постановку задачи". Я вон точно так же могу заявить что «умение грамотно составлять PBI это основной рабочий инструмент программиста».
И на мой взгляд это опять же не относится к плоскости «скрам-водопад», а скорее к тому нормально вы пишите софт или кое как.Вот именно качественно сделанная постановка задачи прямо доказывает что изменения предметной области — не более чем миф. А все потенциальные изменения требований со стороны заказчика в рамках предметной области на 99,99999% осуществимы за счет конфигурации. Так что все эти срамопляски и прочие агилы выдуманы в свое время неквалифицированными разработчиками для оправдания своей некомпетентности. в заграничных буржуинствах с квалифицированными разработчиками (даже с какими нибудь завалящими бакалаврами) дефицит такой что ну приходится им индусов нанимать вебхеллоуверды верстать. Дорого долго бажно но с учетом нулевой ответсвенности софта на безрыбье и рак рыба. Но это не значит что им стоит уподобляться.
Вот именно качественно сделанная постановка задачи прямо доказывает что изменения предметной области — не более чем миф.
Ничего она не доказывает.
А все потенциальные изменения требований со стороны заказчика в рамках предметной области на 99,99999% осуществимы за счет конфигурации.
Даже близко не все. Я посмотрю как вы «за счёт конфигурации» переведёте весь зоопарк вашего софта с линукса на винду или наоборот. Или скажем с десктопа на андроид.
Так что все эти срамопляски и прочие агилы выдуманы в свое время неквалифицированными разработчиками для оправдания своей некомпетентности
Да вобщем-то список людей которые «выдумали агил» известен:
+
Kent Beck
Mike Beedle
Arie van Bennekum
Alistair Cockburn
Ward Cunningham
Martin Fowler
James Grenning
Jim Highsmith
Andrew Hunt
Ron Jeffries
Jon Kern
Brian Marick
Robert C. Martin
Steve Mellor
Ken Schwaber
Jeff Sutherland
Dave Thomas
Mike Beedle
Arie van Bennekum
Alistair Cockburn
Ward Cunningham
Martin Fowler
James Grenning
Jim Highsmith
Andrew Hunt
Ron Jeffries
Jon Kern
Brian Marick
Robert C. Martin
Steve Mellor
Ken Schwaber
Jeff Sutherland
Dave Thomas
Почему-то я уверен в том что они как минимум не менее компетентны чем вы :)
Дорого долго бажно но с учетом нулевой ответсвенности софта на безрыбье и рак рыба.
Ну это заявление тоже как минимум требует доказательства. Хотя бы потому что начальники и владельцы фирм обычно деньги считать умеют и вряд ли стали бы повсеместно использовать дорогие процессы выдающие багованный код :)
Ничего она не доказываетА вы ее когда нибудь писали или хотя бы читали?
Хотя бы потому что начальники и владельцы фирм обычно деньги считать умеют и вряд ли стали бы повсеместно использовать дорогие процессы выдающие багованный код :)Они то умеют. Тока вот потенциальных бакалавров способных к более другим процессам их собратья из хайтечу раскупают еще за год-два до выпуска и ресурс для аукциона имеют куда поболе. Не сидеть же им теперя вооще без лендингов?
Я вон точно так же могу заявить что «умение грамотно составлять PBI это основной рабочий инструмент программиста».
Да заявлейте скока угодно. Квалификационная комиссия по этому поводу научного мнения придерживается а не вашего. Потому что ваш срамоагил банально подменяет инженерный расчет хотелками некомпетентных в сабдже людей и методом антинаучного тыка. Скока сотен записей о взрыве реактора вам нужно занести в баклог чтобы создать рабочую систему управления?
Конкретно применительно к разработке это словосочетание даже вроде бы не во всех языках существует.Не на все оно дословно переводится. Но на всех языках но на всех языках на которых ведут доку квалифицированные разрабы такие документы есть. Особенно у немцев. Он у Сименса постановки какие на спроектированные ими системы. Любо дорого взглянуть.
А вы ее когда нибудь писали или хотя бы читали?
Ну приведите мне ваш вариант «постановки задачи» который является доказательством вашего тезиса.
Тока вот потенциальных бакалавров способных к более другим процессам их собратья из хайтечу раскупают еще за год-два до выпуска и ресурс для аукциона имеют куда поболе.
Это да. Это просто огромная беда прямо для кучи концернов. Бедный гугл себе понимаешь ли не может «правильных бакалавров» нанять. Самим то не смешно? :)
Квалификационная комиссия по этому поводу научного мнения придерживается а не вашего.
Вот и ещё интереснее становится. Что у нас теперь за «квалификационная комиссия» появилась? И самое главное откуда? И почему кого-то должно интересовать её мнение?
Но на всех языках но на всех языках на которых ведут доку квалифицированные разрабы такие документы есть. Особенно у немцев
Естественно есть. И в скраме они есть. Особенно у немцев. Иногда называются Technische Spezifikation, иногда Projektbeschreibung, иногда Projektauftrag, а иногда и Product Backlog Item или Feature Definition.
Он у Сименса постановки какие на спроектированные ими системы. Любо дорого взглянуть.
Я ваш мир наверное сейчас переверну с ног на голову, но тот же Сименс уже давно и успешно практикует различные аджайл-методики. В том числе и скрам. И кстати не только в разработке софта.
Бедный гугл себе понимаешь ли не может «правильных бакалавров» нанять. Самим то не смешно? :)Ну вообще то топ-менеджеры гуглела аккурат по этому поводу кракадиловыми слезами то рыдают — гуглеры есть инженеров то нету. Оно может и смешно тока смеяться над чужим горем грешно.
У огрызка тоже более 50% без профильного образования. Но там топ-менеджеры этим гордятся. Ну говно конфеткой называть — это маркетинговое кредо огрызка с самого его основания.
Ну приведите мне ваш вариант «постановки задачи» который является доказательством вашего тезиса.Ну приводил уже пример с расчетом з/п. Сама предметная область не меняется. Меняются только значения коэффициентов по большому счету.
Естественно есть. И в скраме они есть. Особенно у немцев. Иногда называются Technische Spezifikation, иногда Projektbeschreibung, иногда Projektauftrag, а иногда и Product Backlog Item или Feature Definition.Ну смешали праведное с грешным. Technische Spezifikation — это таки ТЗ. т.е. просто перечень что система должна обеспечить и хотелки. К примеру для системы автоматизации прокатного стана это писулька страницы три. А постановка тысячи полторы страниц. А вообще доки стелажа четыре 3-х этажных. Ну там правда все сименс — и железо и ось и софт. Так вот для того чтобы доказать что ничего поменяться не может в принципе доста писульки которая и есть одной этой писульки которая есть отправная точка для создания постановки. Там банально перечислены параметры механической части которые нельзя превышать и указаны предельные толщины металла на входе и выходе а так же требуемый темп прокатки. Так вот очевидно что ничего из этого для данного конкретного стана поменяться не может. Мало того — для другого стана список параметров останется тем же. Поменяются только числовые значения. Но самое интересное это список хотелок. Их всего две — обеспечение максимального коэффициента загрузки оборудования и наработка на отказ не менее 10 тыс часов (это кстати растет из той цифери которая была для железа) — т.е. сбоев по вине софта не должно быть в принципе. Ну кроме того что они априори не могут поменяться — а ну как попробуйте объясните каким каким спринтом можно реализовать эти хотелки? Первая может быть реализована только правильной постановкой задачи учитывающей ее во всех компонентах системы. А вторая вообще требует применения особых отказоустойчивых методов как постановки так и реализации причем как оси так и самой системы равтоматики так и местных форточек. Какой к глиняной маме срамоагил при таких раскладах
Я ваш мир наверное сейчас переверну с ног на голову, но тот же Сименс уже давно и успешно практикует различные аджайл-методики. В том числе и скрам. И кстати не только в разработке софта.Ну как бе Сименс хоть и хайтеч но софта он много делает. в том числе и некритичного. И если то что связано с реалтаймом и САПР делают реально инженеры с реально прямой докой и по научным методикам — ну по другому этот софт просто не сертифицируют к применению. Но как бе это не значит что у него разрабов девать некуда. Реально то универы не более 10% процентов потребности покрыть могут. А пытаться их перекупить у партнеров типа Дассо и т.д. — ну это чем больше перекупишь тем глубже себе же могилу и выроешь. Поэтому с некритичным софтом как у всех. Ну а в некоторых других областях может быть полезно. Например в ловле блох или перетягивании каната. От там предметная область действительно постоянно меняется. Не вообще приучать неквалифицированный персонал головой думать идея хорошая тока бесперспективная. А инженеров погружать никуда не надо. они и так погружены по самые небалуй. Особенно программисты. Ну разве что переодически для профилактики менять на другую корпараивную предметную область — ну типа шашлычек шнапс цигане с медведем и прочий срам. А то если тут агил не поможет то гляди и забудут где у жены главная хотелка.
Что у нас теперь за «квалификационная комиссия» появилась? И самое главное откуда? И почему кого-то должно интересовать её мнение?Да она еще с петровских времен прописалась. Комиссия перед которой дипломный проект защищаешь. И которая по результатам защиты присваивает квалификацию инженера-программиста. И таки постановка задачи — основная часть доки по оному проекту. И в общем то защита заключается в кратком изложении постановки по плакатам и ответам на возникшие у комиссии вопросы по оной и по результатам работы программной реализации. И другого способа стать инженером-программистом нет. Только освоить все нужные разделы математики и прочие науки нужные для грамотного универсального и
гибкого проектирования софта в любой предметной области. А знание языка — ну это подготовительная стадия обучения. 1-ый курс обычно 1-2 универсальных языка. к примеру курс плюсов обычно 72 максимум 144 часа. И этого выше крыши. Потому что следующие 4,5 года будешь его применение оттачивать на задачах из практически всех предметнных областей. Потом несколько вспомогательных ознакомительно. Ну а после курса семиотики на 3-ем курсе лекции по каким либо языкам этим студентам читать уже абсолютно бессмысленно. Потому что после этого вопрос быстрого самостоятельного освоения любого нужного языка вооще никого не заботит. Вот если нет нужного тут да придется студенту поднапрячься — опыт создания языков то минимальный.
Я посмотрю как вы «за счёт конфигурации» переведёте весь зоопарк вашего софта с линукса на винду или наоборот. Или скажем с десктопа на андроид.И че какие проблемы? Обертка апи оси это такой же сменный компонент. Перекомпилил и полетели. Ну это еще Керниган и Ритчи так придумали. А щас и готовых сменных оберток валом, он та же FireMonkey или Qt
Ну приводил уже пример с расчетом з/п
Приводили. Но он ничего не доказывает. Об этом и речь.
Ну смешали праведное с грешным
Я ничего не смешал. Оно само «смешалось». Это часто одно и тоже и делают это одни и те же люди. И часто это вообще один и тот же документ, который для разных организаций получает разное название и другую «обложку».
Ну как бе Сименс хоть и хайтеч но софта он много делает. в том числе и некритичного.
Medical Solutions и энергетика(в том числе и атомная) это по вашему достаточно критично? :)
Да она еще с петровских времен прописалась. Комиссия перед которой дипломный проект защищаешь.
Ну уж извините, я диплом не в России защищал. И те люди которые мою защиту принимали, они против аджайла-скрама ничего и не имели. Я с одним из них даже как-то потом в одном скрам-тиме умудрился поработать :)
И другого способа стать инженером-программистом нет.
Я вас сейчас наверное опять очень сильно удивлю, но ваш ВУЗ не является единственным в мире…
И че какие проблемы? Обертка апи оси это такой же сменный компонент. Перекомпилил и полетели
Я прав в своём предположения что вы сейчас только теоретизируете и на практике этого ни разу не делали? :)
Приводили. Но он ничего не доказывает. Об этом и речь.Ну дак тоже самое неизменяемый уровень находится для любой задачи. И эта главная часть работы программиста. Что то вы в азах плаваете. Меняется не предметная область. Она всегда неизменна. Меняются наши знания о ней в процессе анализа. При этом существуют и такие задачи у которых разные слои вообще к разным предметным областям относятся.
Ну уж извините, я диплом не в России защищал. И те люди которые мою защиту принимали, они против аджайла-скрама ничего и не имели. Я с одним из них даже как-то потом в одном скрам-тиме умудрился поработать :)Ну толи вы в какой то неправильный ликбез попали, то ли просто по молодости еще не осознали чему вас там учили. Реально на всю глубину понимать начинаешь годам к 40. Даже касательно казалось бы вообще элементарных вещей.
Я прав в своём предположения что вы сейчас только теоретизируете и на практике этого ни разу не делали? :)Ну со штатными форточками пока что тока для винды адаптер делал. А соответственно все сводилось к банальному адаптеру DX/OpenGL. Нет тут никакой магии. Самое обычное ООП. Ну разве что статический полиморфизм гораздо больше юзается чем обычно. Вам че в вашем ликбезе забыли рассказать что алгоритм — штука универсальная и от смены таргета меняются только детали реализации ввода-вывода и ничего больше?
Medical Solutions и энергетика(в том числе и атомная) это по вашему достаточно критично? :)С тех пор как GUI переселился с УВМ на отдельный вычислитель он перестал быть критичным. При этом в той же атомной энергетике валом и систем учета которые вооще ни разу не к АСУТП относятся а к АСУП.
А в медицинских делах там как бы баз данных куда поболе чем критичных частей. Тут комп вооще преимущественно только роль агента сбора и хранения данных выполняет. А в реалтаймовую часть срамо-агил не пустят. Немцы не такие дураки как американский менеджмент. А как вы думаете почему Боинги падают? 60 лет этот семейство был самым надежным а теперь софт их валить начал. Досрамоагилились.
Что то вы в азах плаваете.
Это не азы. Это какие-то ваши странные фантазии, которые вы почему-то пытаетесь выдать за доказательства и факты.
Ну толи вы в какой то неправильный ликбез попали
Пока никто особо не жаловался. «Люди с Сименса»тоже там же учились. Некоторые даже прямо вместе со мной.
Реально на всю глубину понимать начинаешь годам к 40. Даже касательно казалось бы вообще элементарных вещей
Мне ещё раз немного перевернуть ваше представление о мире? :)
Вам че в вашем ликбезе забыли рассказать что алгоритм — штука универсальная и от смены таргета меняются только детали реализации ввода-вывода и ничего больше?
Это вам по моему забыли рассказать что теория не всегда на 100% совпадает с практикой…
А в реалтаймовую часть срамо-агил не пустят. Немцы не такие дураки как американский менеджмент.
Ну видимо всё таки такие :) Я понимаю что это разрушает ту картину мира, которую вы себе придумали, но с Сименсе даже КБ работают по аджайлу-скраму. И в medical solutions, и в энергетике, и в автомобилестроении и ещё много где. И не только в Сименсе, но и в куче других фирм. Добро пожаловать в 21-й век.
Это вам по моему забыли рассказать что теория не всегда на 100% совпадает с практикой…Глюпости. Особенно в том плане в каком это касается разницы между осями. А особенно между потомками одной и той же оси.
Глюпости. Особенно в том плане в каком это касается разницы между осями. А особенно между потомками одной и той же оси.
Как говорится: «блажен кто верует» :)
Это не азы. Это какие-то ваши странные фантазии, которые вы почему-то пытаетесь выдать за доказательства и факты.Это как раз азы. Которые исключительно секта свидетелей Срама и пытается отрицать. Банально по той причине что скрам не позволяет применять научно-обоснованные методологии проектирования.
Как говорится: «блажен кто верует» :)Знает тот кто делает. А особенно тот кто понимает что делает.
Добро пожаловать в 21-й век.
Ну 21-ый век это как бы не повод чтобы навязывать методологии менеджмента которые напрочь ломают методологии быстрой и качественной разработки софта.
Задача формализация задачи не формализуема. Это давно доказанная теорема. А соответственно единственная задача менеджмента — не мешать.
Агил же и особенно Срам ломает абсолютно все. Ибо нарушает как порядок действий необходимых для применения научных методологий проектирования, так и лишает разработчиков нормального взаимодействия в команде.
Это как раз азы.
Вы это ваше видение мира пытаетесь протолкнуть уже достаточно долго. Но сколько бы вы не пытались, пока вы не начнёте приводить какие-то факты и доказательства, то это всё ещё останется просто вашим видением мира и ничем больше.
Знает тот кто делает. А особенно тот кто понимает что делает.
Вот именно. И вы как я понял ни разу этого не делали и похоже что и не особо то и понимаете о чём говорите:)
Ну 21-ый век это как бы не повод чтобы навязывать методологии менеджмента которые напрочь ломают методологии быстрой и качественной разработки софта.
Ну так никто этого и не делает. Потому что ни аджайл, ни скрам сами по себе ничего и не ломают.
Агил же и особенно Срам ломает абсолютно все.
Это ваше личное мнение и после всего того что вы тут успели понаписать это на мой взгляд скорее даже ваша личная вера. И это не совпадает с реальным положением вещей. И уж однозначно это не совпадает с мнением и опытом кучи людей, которые эти самые аджайл и скрам уже вовсю применяют чуть ли не десятилетиями. И если бы аджайл и скрам были настолько ужасны как вы их себе представляете, то от них давно бы уже все отказались. И если не все, то как минимум большинство.
И уж однозначно это не совпадает с мнением и опытом кучи людей, которые эти самые аджайл и скрам уже вовсю применяют чуть ли не десятилетиями.Действительно опытные люди делают софт сразу качественно и работает он после этого действительно десятилетия без изменений. А вся эта бредятина про сверхсложность примитивных предметных областей — как раз и показатель отсутсвия опыта и умений разработки.
И если не все, то как минимум большинство.Ну дак людей которые понимают как софт делать всегда меньшинство. Вообще по любым техническим аспектам существует всего два мнения — мое и неправильное. Потому что мое всегда обосновано. Вы же ни одного обоснования не привели. Что в прочем не удивительно. Это вооще болезнь срамоагила. Сколько с жертвами срамоагила не сталкивался в плане когда надо их косяки разруливать — на вопрос обоснуйте то или иное решение использованное в проекте — всегда затрудняются ответить. О каком научном подходе к разработке может идти речь?
Действительно опытные люди делают софт сразу качественно и работает он после этого действительно десятилетия без изменений.
Тогда давайте просто сойдёмся на том что по вашему личному определению «качества» практически все кроме вас делают его «некачественно». В том числе и так любимый вами Сименс.
И что практически всех кроме вас такая ситуация устраивает. В том числе и так любимый вами Сименс.
Ну дак людей которые понимают как софт делать всегда меньшинство.
Да я так посмотрю на то что вы пишите, и похоже по вашему мнению вообще никто кроме вас этого не понимает…
И что практически всех кроме вас такая ситуация устраивает.Т.е. вы хотите сказать что постоянный понос обновлений с ухудшением даже самого примитивного софта от версии к версии когото устраивает? Не смешите мои тапочки.
Тогда давайте просто сойдёмся на том что по вашему личному определению «качества» практически все кроме вас делают его «некачественно».О том же самом говорит к примеру Страуструп. Только он слишком мягкий человек чтобы прямо назвать быдлокод быдлокодом. А Торвальдс к примеру по тому же поводу в выражениях не стесняется.
В том числе и так любимый вами Сименс.Ну может сейчас и Сименс испортился не знаю. я с их софтом уже лет 20 не пересекался. А тогда они были весьма достойными конкурентами.
Да я так посмотрю на то что вы пишите, и похоже по вашему мнению вообще никто кроме вас этого не понимает…Ну дак и четкого математического обоснования к примеру не то что преимуществ а пригодности срамо-агила к научно-обоснованным методик проектирования тоже пока что так и не увидел. А вот пртиворечия а у агила в целом с этими методиками абсолютные.
Т.е. вы хотите сказать что постоянный понос обновлений с ухудшением даже самого примитивного софта от версии к версии когото устраивает?
Я хочу сказать что «постоянный понос обновлений с ухудшением даже самого примитивного софта от версии к версии » вообще не зависит от тогo делаете вы скрам или не скрам и зависит от совсем других вещей.
Ну может сейчас и Сименс испортился не знаю. я с их софтом уже лет 20 не пересекался. А тогда они были весьма достойными конкурентами.
Ну или просто вы ошибаетесь и всё.
Ну дак и четкого математического обоснования к примеру не то что преимуществ а пригодности срамо-агила к научно-обоснованным методик проектирования тоже пока что так и не увидел.
Ну так во первых никто и не утверждает что они существуют. А вы утверждаете что у вас есть доказательства в отношении водопада.
Более того никто не утверждает что аджайл всегда лучше чем альтернативы. А вы утверждаете что они всегда хуже.
А вот пртиворечия а у агила в целом с этими методиками абсолютные.
Какие-то подтверждения этому высказыванию будут? Или это опять просто ваше личное мнение?
Ну так во первых никто и не утверждает что они существуют. А вы утверждаете что у вас есть доказательства в отношении водопада.А при чем здесь методология менеджмента к методологиям проектирования то? И почему менеджмент не имеющий компетенции в вопросах разработки должен вооще влазить в дела разработчиков? И почему именно водопад? Есть еще к примеру истинно православный «уяк-уяк и в продакшин». Касательно водопада — он хотя бы не нарушает взаимодействие в команде и сконцентрирован таки на общении между разработчиками. Хотя и не позволяет использовать все преимущества в скорости анализа и гибкости реализации, даваемые появившейся позже объектно-ориентированной методологией проектирования, позволяющую за счет декомпозиции по зонам ответственности значительно упрощать и распараллеливать как анализ так и реализацию. Срам же напрочь ломает и то и другое.
А при чем здесь методология менеджмента к методологиям проектирования то?
Ну так это опять же вас надо спросить почему вы смешиваете всё в одну кучу :)
И почему менеджмент не имеющий компетенции в вопросах разработки должен вооще влазить в дела разработчиков?
Я вам сейчас открою страшный секрет: один из плюсов скрама в том, что он как раз таки не даёт менеджерам лезть именно в дела разработки. Это запрещенно правилами самого скрама.
А вот правила того же водопада этого как раз таки нигде не запрещают. И «уяк-уяк и в продакшин» этого тоже не запрещает.
P.S. У меня всё больше и больше складывается впечатление что вы вообще не понимаете что такое скрам, никогда его вживую не видели и даже описание его до конца не прочитали. И всё что вы здесь пишите это банальное «слышу звон, да не знаю где он»…
«уяк-уяк и в продакшин» этого тоже не запрещаетуяк-уяк — это то что делают со скрам-мастером в начале проекта. После этого уже ничего не мешает быстренько довести проект до продакшина.
Ну так это опять же вас надо спросить почему вы смешиваете всё в одну кучу :)Ну это вы начинаете противопоставлять срам с говном мамонта, когда вас просят привести доказательства совместимости этой методологии менеджмента его с современной методологией проектирования софта — т.е. анализа предметной области, создания постановки и программной реализации. Скрам эту методологию не просто ломает а на куски рвет. Начнем с того что основная форма общения между разрабами — это постановка задачи и референс по компонетам/интерфейсам/форматам данных. Причем это форма общения в том числе и с самим собой в будущем. Все остальное — ненужные балачки. Но именно это срам и ломает нафиг в первую очередь. А вводя разработку по фичам, выбираемым менеджером, нафиг убивает всю эффективность декомпозиции по зонам ответственности.
И всё что вы здесь пишите это банальное «слышу звон, да не знаю где он»…Да то вы похоже не слышали что софт разрабатывается по методикам проектирования а не по методикам менеджмента. И главная задача методологии менеджмента — не ломать методологию проектирования. Т.е. в идеале — не изобретать пляски с бубном и прочие срамные ритуалы, а просто организовывать обеспечение разрабов всем необходимым — доступом к инфе, техникой, каналами связи и т.д. А кому с кем когда в каком режиме и по какому поводу нужно провести совещание — сами разберутся по необходимости.
Скрам эту методологию не просто ломает а на куски рвет.
Вы это заявляете уже не знаю в какой раз. Но при этом не может нормально обьяснить почему по вашему он её ломает и в каком конкретно месте он это делает.
Начнем с того что основная форма общения между разрабами — это постановка задачи и референс по компонетам/интерфейсам/форматам данных.
Кто это сказал? Вы решили что это так и теперь все должны этому следовать?
Ну и кроме того кто вам мешает в скраме общаться именно таким образом? И как вам конкретно мешают это делать?
А вводя разработку по фичам, выбираемым менеджером, нафиг убивает всю эффективность декомпозиции по зонам ответственности.
Это то вы откуда взяли? Можно конкретную цитату из описания скрама из которой вы сделали такой вывод?
Да то вы похоже не слышали что софт разрабатывается по методикам проектирования а не по методикам менеджмента.
Так никто вам и не мешает разрабатывать софт по любым вами выбранным методикам проектирования. Скрам конкретно разработку ну вот вообще не регламентирует. Вся разработка лежит целиком и полнотью в зоне отвественности комадны разработки. И эта команда сама решает как она хочет писать код и каким методикам проектирования следовать. И если команда разработки считает что фича не реализуема в том виде как её им предложил менеджер, то она совершенно спокойно может отклонить эту фичу и/или потребовать чтобы её по другому описали/скомпоновали/резрезали. Или опять же сама может взять user story от клиента и написать по нему то ТЗ, которое оно считает правильным, и работать по этому ТЗ. Ну вот вообще не запрещено.
А кому с кем когда в каком режиме и по какому поводу нужно провести совещание — сами разберутся по необходимости.
Если у вас единственная проблема в том что вам не нравятся именно совeщания скрама, то возьмите любую другую аджайл-методику или придумайте свою со своими совещаниями. Тоже не запрещено.
И это как раз таки один из основных пунктов аджайл манифеста: «Люди и взаимодействие важнее процессов и инструментов». Аджайл это прямо и чётко указывает. А вот ваш водопад нет. Поэтому если у вас на фирме обьявили что вы теперь делете аджайл, то вы как разработчик автоматом получает право голоса в вопросе выбора процессов и инструментов. И если этого нет, то это уже не аджайл.
А вот если у вас скажем водопад, то по идее ваши менеджеры могут придумывать любые процессы и вы как разработчик должны им молча следовать.
Кто это сказал?Наука. Или по вашему математическая формулировка и обоснование принятых проектных решений не является единственной целю проведения анализа и единственно пригодной основой для реализации? О какой тогда научно-обоснованной разработке может идти речь? Или референс разрабы должны в голове весь держат или по чужому коду постоянно рыться? В отсутсвии доки что научного то? Т.е. во главе угла должна стоять именно дока как инструмент общения между разрабами. Инженеры общаются при помощи чертежей. Никакую машину или здание без этого соорудит невозможно. Программисты — при помощи формул и схем. Никакую софтину без этого соорудить невозможно. Все остальное — пустые ненужные балачки. А именно их срам и требует ежедневно вместо утрясания интерфейсов между разными зонами ответственности в рабочем режиме.
А вот если у вас скажем водопад, то по идее ваши менеджеры могут придумывать любые процессы и вы как разработчик должны им молча следовать.Да при чем тут водопад то??? У нас тут менеджмент-маразмом никогда не страдали. Поэтому у нас в основном «утрясем в рабочем режиме». И если менеджер сам не является очень опытным а то и самым опытным разрабом и/или аналитиком (А другие руководителями среднего звена бывают редко, а нижнего — вообще никогда), он в этот рабочий режим нос вооще не сует. А то очень сильно прищимят. А соответственно непосредственный руководитель — это первый человек к которому разраб обратится за советом если у него самого что то не срастается.
Аджайл не отменяет документацию, просто декларирует, что работающий продукт важнее документации. Не более, но и не менее.
Наука.
Какая конкретно наука? В каком виде и в каком месте? Вы можете пpоцитировать какой-то закон, который это доказывает? Привести научные работы, которые это подтверждают? Или это всё опять же ваше личное мнение и ваше личное понимание ситуации?
Инженеры общаются при помощи чертежей. Никакую машину или здание без этого соорудит невозможно.
Нет. Инжнеры общаются в том числе и при помощи чертежей. Но не исключительно при помощи чертежей.
Программисты — при помощи формул и схем. Никакую софтину без этого соорудить невозможно.
Формулы и схемы помогают. Иногда, именно иногда, они действительно являются необходимы. Но заявлять что никакой софт в принципе невозможно создать без формул и схем это уже откровенный бред.
Да при чем тут водопад то??? У нас тут менеджмент-маразмом никогда не страдали
Конкретно у вас? Или вообще в любом водопаде, который когда-либо использовался? Я ведь тоже могу заявить что у нас тут в аджайле никаким менеджмент-маразмом никто не страдает. И я уверен что куча людей могут так заявить. И что дальше?
Поэтому у нас в основном «утрясем в рабочем режиме».
И у нас тут в основном тоже «утрясём в рабочем режиме»
И если менеджер сам не является очень опытным а то и самым опытным разрабом и/или аналитиком (А другие руководителями среднего звена бывают редко, а нижнего — вообще никогда), он в этот рабочий режим нос вооще не сует.
А у нас менеджер в «рабочий режим» в принципе свой нос не суёт. Вне зависимости от того каким он там себя опытным считает. Не его это дело и не его зона ответственности. Его дело получить у клиента информацию в нужном нам формате и передать её нам. И всё.
А соответственно непосредственный руководитель — это первый человек к которому разраб обратится за советом если у него самого что то не срастается.
А у нас для этого есть техлиды и архитекты. И даже начальник в это дело свой нос не суёт.
Конкретно у вас?
Конкретно — в бывшем СССР. Во всяком случае там где еще не осрамились а следом не обанкротились. Не было здесь никогда никаких водопадов и прочего менеджмент-маразма. Всегда был научный подход и утрясание в рабочем режиме.
Его дело получить у клиента информацию в нужном нам формате и передать её нам.Это вообще то задача аналитиков. В роли которых чаще всего выступают непосредственные исполнители. Зачем лишний раз играть в испорченный телефон?
И даже начальник в это дело свой нос не суёт.Если это насяльника уровня бюро — то зачем тогда этот дормоед нужен? На этом уровне здесь всегда были руководители а не начальники, и его прямая обязанность нырять глубже всех.
А если насяльника уровня отдела ему не до сования носа в такие мелочи — его задача организация взаимодействия с другими отделами. типа отдела оборудования, цеха связи ит.д
А у нас для этого есть техлиды и архитектыНу знаете старый американский анекдот? Тимлид — это такой человек который может за день без багов сделать недельную работу всей команды. А почему не делает? А где потом найти разрабов которые поймут как это работает?
Так вот у нас не просто делает, а и тех кто недопонимает подтягивает в процессе до своего уровня. В этом собственно говоря и есть отличие руководителя от менеджера и насяльника. Ну а табеля учета рабочего времени заполнить для бюро из от 2 до 10 чел обычно и т.п. начальственные функции — это у него много времени не занимает.
И у нас тут в основном тоже «утрясём в рабочем режиме»Главный вопрос что именно утрясается? При правильном подходе стыки между разными подсистемами/компонентами которые при этом разрабатывают разные группы/разрабы. И особо утрясать больше нечего.
Но заявлять что никакой софт в принципе невозможно создать без формул и схем это уже откровенный бред.Компьютер — универсальная числодробилка. Все что умеет компьютер — числодробить. Иллюзия что компьютер может что то еще возникает исключительно в результате грамотно организованного числодробления. Как можно организовать числодробление без формул, а тем более грамотно? Опять у вас антинаучный бред лезет и полное незнание азов.
Какая конкретно наука?Конкретно — любая которая задействованна в задаче.
В каком виде и в каком месте?В том месте что Любая наука начинается ровно с того места в котором появляется расчет. Без расчета это гадание на кофейной гуще. А там где есть расчет, там есть и формулы по которым он выполняется. Или вы считаете что проектные решения не требуют никакого научного обоснования?
Инжнеры общаются в том числе и при помощи чертежей. Но не исключительно при помощи чертежей.А вы хоть раз видели чтобы инженеры обсуждали какие либо реальные производственные вопросы без чертежа? Обычно первая фраза — чертеж доставай. А любой инженер-электроник начинает обсуждение с фразы схему мне на стол. Чем инженеры-программисты хуже то?
Это вообще то задача аналитиков. В роли которых чаще всего выступают непосредственные исполнители. Зачем лишний раз играть в испорченный телефон?
Ну например потому что «менеджер» этому обучен и тем самым экономит время разработчиков? Которым как бы тоже есть чем заняться :)
Если это насяльника уровня бюро — то зачем тогда этот дормоед нужен?
Ну может быть потому что ему принадлежит фирма? :)
А если насяльника уровня отдела
У нас нет «начальников отделов».
Тимлид — это такой человек
Тимлидов у нас тоже нет.
Главный вопрос что именно утрясается?
Что надо утрясать, то и утрясается. По необходимости так сказать.
Ну например потому что «менеджер» этому обучен и тем самым экономит время разработчиков? Которым как бы тоже есть чем заняться :)Ну если он сам квалифицированный и опытный инженер-программист то это все допустимо. Производство допрос с престрастием требует должной квалификации. Но все таки лучше если это будет делать тот кто непосредственно нашел нестыковку/неточность/неоднозначность и т.д. Он гораздо точнее понимает какую именно инфу нужно выбить из какого именно спеца заказчика. А соответсвенно допрос пройдет гораздо быстрее и безболезненнее для допрашиваемого. Связи по горизонтали в таких делах обычно гораздо эффективней. Ну естественно речь идет не о том в какой цыет покрасить свистоперделку.
Но это все частности. Касательно же того почему скрам полностью ломает нормальную разработку — то для начала нужно вынести вопрос из плоскости что лучше — говнопад или срам в абсолютно другую плоскость.
Практика — это теория с учетом несовершенства материала. А соответсвенно смотрим насколько методология проектирования соответсвует тому что предписывает теория и насколько методология менеджмента способствует или мешает имплементации методологии проектировния.
Итак начнем с того что предписывает теория. Первое что она предписывает — рассмотреть предметную область в целом. При этом под пердметной областью понемается не набор фич, а именно та область знаний которую затрагивает разрабатываемая система. Если определять предметную область так,, то она если и меняется то очень редко. При этом если что то и меняется — это надстройка над тем что уже существует.
Далее необходимо выделить абстракции, описать математически как делать их конкретизации и последовательно их реализовывать закладывая необходимые точки расширения для создания надстроек в будущем. Это позволяет создать не имеющую технических задолженностей технологическую базу для быстрой реализации какой угодно функциональности в рамках этой предметной области.
Как в какой последовотельности и т.д. производить надстройку абстракций — теория никак не ограничивает. Единственное что предписывается — для реализации какого либо компонента предварительно нужео сделать полный анализ и постановку на него. Если в процессе реализации возникли нестыковки то нужно доработать постановку и после этого продолжить реализацию. Т.е.«утрясем в рабочем режиме» — это как раз напрямую вытекает из теории.
Как эта постановка оформляется — это тоже теорией никак не регламентируется. Это регламентируется стандартом на документацию принятую в стране (в пост-СССР — ГОСТ ЕСПД). При соло разработке можно и карандашиком на полях, но обязательно до реализации каждого компонента. Требование же к исчерпывающей документации выплывает именно из практики а не из теории. И возникает оно именно для того чтобы не гадать на кофейной гуще при коррекции постановки почему здесь было сделано так, а не иначе. Поэтому передача клиенту системы не имеющей исчерповающей проектной документации — это по сути мошенничество.
Недостатки говнопада видны сразу — он экономит на спичках в анализе в результате ломает как процесс коррекции так и созданние технологической базы. Каскадный водопад в отличии от срама теории соответсвует гораздо ближе но там уже начинаются нестыковки с методологией проектирования.
Касательно же методологий проектирования — то полностью соответсвующий теории инструмент — ООП как методология — получили только в 80-х а нормально использовать научились разве что к концу 90х.
Суть методологии — моделируются сущности предметной области с четким разделением зон ответсвенности между ними. Т.е. сначала выделаются абстрактные сущности, их зоны ответсвенности и взаимосвязи между ними.
Это позволяет выделить группы взаимосвязанных сущностей не зависимые или слабо зависимые от других и дальнейший более детальный анализ и реализацию производить отдельно — т.е. распараллелить разработку подсистем между командами/разрабами и для кажой подсистемы повторить процесс рекурсивно до достижения атомарного уровня, что существенно упрощает разработку.
Каждая программа явно или неявно представляет собой конечный автомат. При этом если пара автоматов имеет n+m состояний то эквивалентный ей единый автомат имеет n*m состояний. А соответсвенно рекурсивное разделение автоматов на подавтоматы экспоненциально снижает сложность как анализа так и реализации.
При этом с технической стороны вопроса каждый реализованный класс автоматически является точкой расширения. Т.е. чем на более мелкие сущности произведена декомпозиция тем больше точек расширения имеет софтина. При этом для реализации какой либо фичи всегда нужен набор сущностей при этом универсально реализованная сущность всегда задействована в реализации многих фич.
Вот именно это — упрощение разработки и цельное восприятие предметной области срам своим разделением на фичи, запрашиваемые клиентом в каком то его порядке, срам и ломает напрочь. От эта типа «бизнес направленность» и типа «вовлеченность» приводит к кастрации сущностей для более быстрой реализации одной фичи, и приводит к обкостыливанию костылей при создании следующей.
Т.е. для реальной бизнес-ориентированности нужно как можно более быстрое создание именно технологической базы — т.е. моделей сущностей предметной области. И чем полнее предметная облась покрыта моделями сущностей тем быстрее реализация любой фичи.
При этом особенно в многослойных системах, задействующих сразу несколько предметных областей, фичи начинают становится доступными огроменными пачками, задолго до завершения разработки всей технологической базы. Т.е по завершенным слоям.
И именно такой подход позволяет гибко реагировать на изменения самой предметной области — произошли изменения достроили еще слой сущностей которые их моделируют.
И имено это срам и ломает напрочь, а распараллеливание разработки так вообще прямо запрещает. Так же как и какой либо вменяемый менеджмент. Потому что в отличии от того же каскадного говнопада эстимейт нужно дать до детального анализа фичи.
Ну если он сам квалифицированный и опытный инженер-программист то это все допустимо.
Нет. У нас менеджеры не инженеры-программисты, а именно мендежеры. Но им это не мешает нормально делатъ свою работу. Более того я бы даже сказал что они её делают гораздо лучше чем её на их месте делали бы инженеры-программисты.
Касательно же того почему скрам полностью ломает нормальную разработку...
Вы написали кучу текста, но так и не ответили на вопрос почему «скрам не совместим с нормальной разработкой». Или почему он совместим с ней меньше чем какой-нибудь водопад.
Всё что вы понаписали к скраму и водопаду применимо на абсолютно одном и том же уровне. Ну никакой разницы нет.
Вот именно это — упрощение разработки и цельное восприятие предметной области срам своим разделением на фичи
Нет в скраме никакого осбенного «скрамовского разделения на фичи». Вы может в скраме «делить на фичи», а можете не делить. Точно так же как вы в водопаде можете «делить на фичи», а можете не делить.
Вы написали кучу текста, но так и не ответили на вопрос почему «скрам не совместим с нормальной разработкой»Из текста не понятно? Ну тогда вкратце — исключает целостное восприятие предметной области и создание не имеющей технической задолженности технологической базы. А соответсвенно исключает экспоненциальный прирост скорости реализации функциональности.
Или почему он совместим с ней меньше чем какой-нибудь водопад.Или почему он совместим с ней меньше чем какой-нибудь водопад.
Вопрос не в водопадах или еще чем. Вопрос в том что весь этот менеджмент в корне неправелен. И насколько аджайлтстым или водопадовым он не был аджайлистым, он на порядок уступает сложившимся здесь практике «уяк-уяк и в продакшин» как по скорости разработки так и по качеству результата. Именно потому что не соответсвует методологии проектирования.
Вы может в скраме «делить на фичи», а можете не делить. Точно так же как вы в водопаде можете «делить на фичи», а можете не делить.Ну дак тогда и все эти покера планирования и т.д. не нужны. Потому что порядок реализации компонент технологической базы определяется исключительно зависимостями в предметной области. Нарушение же этого порядка ведет к обкостыливанию костылей, постоянному рефакторингу и экспоненциальному замедлению разработки.
Но им это не мешает нормально делатъ свою работу.
Любое звено в общении между инженерами — лишнее. Хотя бы потому что это звено должно иметь квалификацию в вопросе не ниже обоих инженеров — т.е. в совершенстве владеть языком на котором они общаются. К примеру при утрясании вопросов (а именно неоднозначности/нестыковки в доке описания техпроцесса) между программистом и инженером по автоматизации общение будет вестись на языке теории автоматического управления. Наивно ждать от менеджера понимания этого языка.
Нет в скраме никакого осбенного «скрамовского разделения на фичи».Вы пример уже привадили фичи — типа минимизация довнтайма при заливке апдейта. Эт не фича на самом деле. Это требование ко всей системе цеояком. И если оно вдруг появилось в конце разработки — то поздно пить боржоми когда почки отказали.
Всю разработку нужно было вести с учетом этого тебования. Горячей замены кода без переделки всего теперь точно не получите. Остается надеятся только на резервериоование — залили стенд-бай переключились залили основу, или на совмещение апдейта с плановым майнтейсом механики.
А вообще если это потом как фича всплыло и пришло от заказчика а не самими разрабами заложено — это показатель абсолютной некомпетентности оных. Поелику одна из двух главных целей автоматизации — таки повышение коэффициента загрузки и минимизация простоев оборудования.
Или почему он совместим с ней меньше чем какой-нибудь водопад.Водопад затягивает начало реализации и затрудняет коррекцию постановки — т.е. недостаточно гибок. Срам же полностью срывает реализацию технологической базы. А она составляет не менее 95% того что надо сделать при разработке любой системы.
Ну тогда вкратце — исключает целостное восприятие предметной области и создание не имеющей технической задолженности технологической базы.
В каком месте и почему конкретно он по вашему это исключает? Просто вы это повторяете как мантру уже не первый раз, но при этом так и не можете обьяснить на основании чего вы сделали этот вывод. Можете процитировать отрывок из описания скрама, на основании которого вы делаете такой вывод?
Именно потому что не соответсвует методологии проектирования.
И опять же: можете процитировать отрывок из описания скрама, на основании которого вы делаете такой вывод?
Ну дак тогда и все эти покера планирования и т.д. не нужны.
Покер планирования не является частью скрама. Это всего лишь способ нахождения консенсуса. Он был придуман задолго до скрама и существует аж с 70-80-х годов прошлого века. Можете погуглить «Wideband Delphi estimation method»
. Это всего лишь способ нахождения консенсуса.Консенуса в чем? В том что однозначно и недвусмысленно диктуется предметной областью? Единственное что там могут уяснять — как кастрировать тот или иной элемент для ускорения реализации той или иной фичи в сферическом вакууме. Т.е. созданием технических задолженностей и дублирования функциональности нарастающих в результате по экспоненте.
И опять же: можете процитировать отрывок из описания скрама, на основании которого вы делаете такой вывод?
Вот конкретно вот этот:
Журнал пожеланий проекта (англ. Project backlog) — это список требований к функциональности, упорядоченный по их степени важности, подлежащих реализации. Элементы этого списка называются пользовательскими историями (user story) или элементами беклога (backlog items). Журнал пожеланий проекта открыт для редактирования для всех участников скрам-процесса. Project backlog ведется SCRUM Product Owner.
Именно такой подход дает экспоненциальное замедление разработки. Именно такой подход дает экспоненциальное замедление разработки. Все это должно определяться на основе сетевого графика зависимостей проекта, который отображает зависимости компонентов. Нельзя реализовать компонент пока не реализованы те компоненты от которых он зависит.
Консенуса в чем?
В любой оценке.
Вот конкретно вот этот:
Ок. Вас не смущает то, что в переводе этого самого PB стоит слово «пожеланий»? И это именно список пожеланий и есть. Если эти пожелания по какой-то причине нереализуемы, то их делать никто не обязан.
Более того и приоризирование там конечно делается с точки зрения «хотелок клиента», но при этом это не значит что кто-то должен делать эти вещи именно в таком порядке.
А теперь опять немного о том как это работает у нас на практике. Когда мы берёмся за проект, то мы первым делом составляем вместе с клиентом так называемый MVP(Minimum Viable Product). То есть грубо говоря это та функциональность которую клиент обязательно хочет иметь и без которой проект не имеет смысла. И на основании этого MVP и прикидываются технологии и архитектура. И минимальная длительность/стоимость проекта. И это мы обязуемся сделать в любом случае.
А вот уже далее клиент может добавлять какие-то дополнительные пожелания в бэклог. Но это именно пожелания. И если они не вписываются в архитектуру и изначальный план, то они не делаются. И если в бюджет не вписываются, то тоже не делаются(ну или оплачиваются отдельно). И клиент не может потребовать от нас чтобы мы их делали до того как готов MVP.
У вас всё ещё остались какие-то претензии к этому пункту скрама?
Более того и приоризирование там конечно делается с точки зрения «хотелок клиента», но при этом это не значит что кто-то должен делать эти вещи именно в таком порядке.
Зачем он в таком случае вообще нужен?
В каком месте и почему конкретно он по вашему это исключает?Именно в той что все диктуется бэк-логом. Если есть целостное восприятие предметной области то ни для определения приоритетов ни для оценки эстимейта бек-лог не нужен от слова совсем. А список функциональности — ну есть и хорошо. Нет — еще лучше.
Восприятие клиента всегда субъективно. Максимум что он видит в классической троице ввод-обработка-вывод — это ввод и вывод. А 95+% которые и есть обработка ему вникать даже не хочется.
Еще раз — овер 95% работы — это создание технологической базы, являющейся моделью предметной области. От хотелок клиента она не зависит от слова совсем. А приоритет реализации компонетов тем более. Он зависит от востребованности компонета другими компонентами.
Во всемС таким же успехом можно гадать на кофейной гуще. Наука не признает авторитетов. Техника тем более. Подобный консенсус — это всего лишь авторитет большинства не подкрепленный ни какими техническими обоснованиями.
Возьмите ориентированный граф зависимостей компонентов моделирующих сущности предметной области, для каждой подсчитайте количество компонентов которые от него зависят — вот вам и приоритет. Возьмите любую фичу, выберите нужные для ее реализации компоненты и посчитайте еще не реализованные зависимости — вот вам и эстимейт.
Есть набор нужных — реализовать фичу практически ничего не стоит. Нету — реализуем сущности. При этом к примеру если реализовать набор компонет нужный для хотелок с A,B, С,D то получим и базу для реализации хотелок E-Z хотя клиент даже в самых смелых помыслах еще даже до F не добрался.
Все просто до ужаса и никаких гаданий на кофейной гуще. А эстимейт он эстимейт потому что реальные затраты времени на реализацию каждого компонента предсказать нереально. Что то что казалось ужас-ужас может собраться за 15 минут. А что то что казалось относительно простым влететь в жесткую отладку на пару месяцев.
А для автоматизированных линий все еще проще. Из троицы слежение за материалом — расчет схемы обработки — последовательное управление приводами — т.е. ввод — процесс- вывод применительно к пром автоатике автоматике для первого и последнего шикарнейшие наборы существуют в софте поставляемом с контроллерами тем же сименсом.
Технологический процесс на линии ограничен в изменении механическим оборудованием линии. Т.е. даже функциональность не меняется и все алгоритмы расчета обработки расписаны в любом случае — это регламентируется техпроцессом. Сложность здесь не в этом, а в обеспечении обработки в реальном масштабе времени и отказоустойчивости.
А для этого нужна как раз реализация по слоям. А список функциональности мало того что он есть полный и неизменный, так он еще и вторичен.
А теперь опять немного о том как это работает у нас на практике. Когда мы берёмся за проект, то мы первым делом составляем вместе с клиентом так называемый MVP(Minimum Viable Product).
Опять глупостями занимаетесь. Во всех системах автоматизации которые видел, техпроцесс автоматизирован на 100%. Вплоть до того что на одном из прокатных станов на Новый Год стан живет своей жизнью, операторы прокатки своей.
Так вот функции автоматики так друг на друга завязаны, что любую выкинь — еще десяток отвалится, и от системы толку будет что от козла молока. А соответсвенно MVP — это реализация всего из техпроцесса что датчики способны узреть.
Касательно же MVP вообще абстрактного корбочного продукта в сферическом вакууме — то первую диплома когда нибудь писали? Ну ту которая называется «Обоснование актуальности разработки»? Ну вот там четко написано почему MVP — это вообще все фичи которые можно изобрестить.
У вас всё ещё остались какие-то претензии к этому пункту скрама?Если технология менеджмента призвана обрубать функциональность а не ускорять разработку она уже не годна в принципе. Потому что цели методологи проектирования как раз абсолютно противоположны — ускорение комплексного решения задачи.
Гибкий подход — это когда неизменная часть — т.е. модель предметной области — отделяется от переменной — т.е. набора фич. Ну и пока разрабы клепают технологический базис, аналитики ищут как можно больше фич которые на этом базисе можно поиметь.
Зачем он в таком случае вообще нужен?
Чтобы иметь представление о хотелках клиента.
Именно в той что все диктуется бэк-логом
Что «всё» по вашему диктуется бэклогом? Бэклог вообще ничего не диктует. Это список пожеланий.
Опять глупостями занимаетесь. Во всех системах автоматизации которые видел, техпроцесс автоматизирован на 100%.
Рад за вас. Но тогда я не понимаю зачем в таком случае вообще было нужно ваше участие.
Так вот функции автоматики так друг на друга завязаны, что любую выкинь — еще десяток отвалится
Ну вот вообще нет. Есть куча функций которые абсолютно опциональны. И есть куча функций о которых лет 5-10-15-20 назад вообще никто не задумывался, но которые стали нужны сейчас. И некоторые из них вполне себе можно добавить в уже существующие системы.
Вы помоему опять начинаете теоретизировать в вещах, с которыми вы на практике дела не имели.
Ну вот там четко написано почему MVP — это вообще все фичи которые можно изобрестить.
Извините, но это чушь полная. Если я пишу какой-нибудь текстовый редактор, то ему вряд ли когда-то понадобится фича вроде «показ hd-видео с ютюба» или фича «управление ядерной ракетой в реальном времени».
Если есть целостное восприятие предметной области то ни для определения приоритетов ни для оценки эстимейта бек-лог не нужен от слова совсем.
Ну как не нужен? Нужно сделать 10 фич, хоть с восприятем, хоть без, но 3 из них можно запускать в продакшен как только будут готовы и они начнут приносить деньги (если идея взлетит), а 7 остальных без этих трёх вообще никакого смысла не имеют. Разве не надо делать эти три в первую очередь?
А если фича1 предполагает реализацию компонентов А и Б, а фича5 реализацию компонетов Б и В, то разве оценка срока разработки этих фич (отдельно, не суммарно) не будет зависеть от того в какой последовательности их делать?
Ну как не нужен? Нужно сделать 10 фич, хоть с восприятем, хоть без, но 3 из них можно запускать в продакшен как только будут готовы и они начнут приносить деньги (если идея взлетит), а 7 остальных без этих трёх вообще никакого смысла не имеют. Разве не надо делать эти три в первую очередь?
Ну атомарной задачей тут называется то что не требует дальнейшей декомпозиции. Т.е. реализация одного компонента который не имеет нереализованных зависимостей.
Ну а как бы график показывает очередность в которой компоненты становятся атомарными задачами… Т.е. если компонент A зависит от компонета B и С то он не может быть реализован ранее чем B и C. Т.е. дает четкий путь от низа до верха. Что позволяет как объективно оценить трудоемкость, так и выделить те места где реализацию можно распараллелить. В общем эффективнее из независимых друг от друга компонентов сначала реализовывать тот, который является зависимостью для большего количества других. Но возможны и другие варианты приоритетов — к примеру путь к конкретной фиче. Здесь главное другое — в любом случае реализовать его универсально без кастраций. Т.е. чем и плох срам — сначала субъективная оценка потом шашки наголо идем от фичи вниз рубим костыли всего и вся что зависимо ну и т.д. В результате коэффициент новизны выше крыши отладка сразу пачкой, повторного использования ноль, для следующей фичи обкостыливание тех же костылей взгляд сбоку и стыковка при помощи матери которая в писании свтом точно не упомяналось с костылями предыдущей фичи, ну и в общем мрак. Здесь же даже если выбираем какую то конкретную фичу то имеем четкий роадмап сверху до низу по которому методично проходим — полностью отладили депенденсы берем того кто от них зависел. В результате никаких технических задолженностей и дублирования реализации, да и багам выжить трудно как не прячься. Чем больше компонент юзают этот компонет, тем у бага меньше шансов дойти до QA. Т.е. берем все депенденсы перекаршиваем в другой цвет и идем по ним считаем конкретно для этой фичи. Но при этом практически ничего не поменяется. Нижнюю часть все равно покроем почти полностью, следующий левел чуток меньше ну и с уменьшением до верха. При этом реализация остальных фич уже упростилась — компоненты то шаренные. Ну а если закрасить для всех трех фич и клиент хотя бы чуток в адеквате — т.е. действительно важную функциональность выбрал — то глядишь и весь десяток поимеем причем штуки 4 еще до того как те три, и еще штук 15 бонусом. Предметная область — это список сущностей которыми оперирует та или иная научная теория и т.п. Т.е. вынести за ворота ничего не удастся. Все украдено до нас. Вернее отчекрыжино бритвой Оккама. Дохтора философии они такие же простые как смартпоинтеры — рефкаунт 0 — сразу бритву хвать и Банзай!
В результате никаких технических задолженностей и дублирования реализации, да и багам выжить трудно как не прячься. Чем больше компонент юзают этот компонет тем у бага меньше шансов дойти до QA. Собственно говоря если одну любую фичу делать без технических задолженностей то и остальные это ускоряет. Ну и в результате экспоненциальное ускорение. Т.е. фиксированные по времени спринты и вся остальные ритуалы ну вообще ни о чем. А тем более запреты на разбиение на подгруппы, которое нужно для распараллеливания.
Ну опять же в принципе эта методология рождалась в совковые времена и расчитана на то что разрабы только с в/о. А в/о расчитано на то что спец способен сделать систему любой сложности с чистого листа вернее с фразы ну посмотри что он там можно сделать до программной реализации самостоятельно. Ну естественно что человеко-часов у него на любую систему не хватит, но может в разработке выполнять любую роль.
Интересно а этому что в универах сейчас вообще не учат? У нас в 90-х это было краем. Ну типа чуть ли не консульацией к выполнению доки по диплому. Ну типа вот граф зависимостей нарисуйте а дальше как обычное распараллеливание ниче сложного — каждый курсач именно так же и реализовывали, тока в уме держали а не на бамаге — как вам не ай-яй-яй. Кста на самом деле это абсолютно естественная методология, в чем ее и сила. Поэтому ломать ее всяким «эффективным менеджментом» смысла никакого. Т.е. если в описание скрама внести пункт — начинать разработку с того что выпинать скрам-мастера за пределы офиса, то глядишь и скрам гибким станет.
Скрам он как раз об атомарных задачах. Если задачу нельзя сделать за спринт, то её нужно декомпозировать, так чтобы можно было сделать и при этом декомпозированные задачи имели самостоятельную ценность и были готовы к вводу в эксплуатацию, хотя бы опытную. Вводить или не вводить решает владелец продукта, но они должны быть готовы к вводу.
По самостоятельности скрам немного ослабляет требования к разработчикам. Он допускает, что любой член команды разработки может выполнить любую задачу, но главный критерий — команда должна быть способна выполнить любую задачу в целом. Набирать команду универсалов или узких специалистов — непринципиально в рамках скрама, пока команда может решать поставленніе задачи. Чаще всего несоблюдаемое требование скрама в этом плане — фактическое существование подкоманд фронтенд, бэкенд, мобайл, QA в рамках скрам-команды. В тоже время самый частый на практике компромисс между командой универсалов/генералистов/фулстэков и командой узких специалистов — T или Ш специалисты, хорошо знающие одну (T) или несколько (Ш) областей ответственности команды, но способные решать типовые задачи и в других областях на уровне джуна как минимум.
В 90-х учили по разному. Дипломы, в которых я, скажем так, принимал участие, сначала писался код, часто в интеративном режиме с руководителем работы, а уже потом оформлялась документация. Уровень контроля за кодом бывал разный: от демонстрации функциональности без заглядывания в код, до тщательного код-ревью без запуска кода :)
. Если задачу нельзя сделать за спринт, то её нужно декомпозировать, так чтобы можно было сделать и при этом декомпозированные задачи имели самостоятельную ценность и были готовы к вводу в эксплуатацию, хотя бы опытную
Как по мне, это надуманное условие. Задачи, которые нельзя декомпозировать на подзадачи, имеющие самостоятельную ценность, готовые ко вводу в эксплуатацию, и которые возможно сделать в рамках спринта (если спринт не длится, скажем, полгода :-), вещь достаточно обыденная.
Если у вас такие задачи это обыденная вещь, то тогда вам просто не подходит конкретно скрам.
Но лично я на такие задачи натыкаюсь исключительно редко и обычно это вещи, которые нужно делать на старте проекта. То есть например PoC или создание архитектуры и базовой «инфраструктуры» для абсолютно новых и ещё «малопонятных» запросов.
Но лично я на такие задачи натыкаюсь исключительно редко и обычно это вещи, которые нужно делать на старте проекта. То есть например PoC или создание архитектуры и базовой «инфраструктуры» для абсолютно новых и ещё «малопонятных» запросов.
Вот именно, только такие задачи в спринт и должны входить. Никаких "тут на несколько месяцев работы, сколько сделаем за спринт, столько сделаем, потом перетащим в следующий, или эту назовём "задача А часть1", а в следующий "задача А часть 2"
P.S. А вы точно "не" нигде в комментарии не пропустили?
Скрам он как раз об атомарных задачах. Если задачу нельзя сделать за спринт, то её нужно декомпозировать, так чтобы можно было сделать и при этом декомпозированные задачи имели самостоятельную ценность и были готовы к вводу в эксплуатацию, хотя бы опытную. Вводить или не вводить решает владелец продукта, но они должны быть готовы к вводу.
Ну вот именно поэтому и получается антинаучный срам. Ломает основу методологии проектирования — принцип декомпозиции. А соответсвенно тупо убивает нафиг и скорость и качество разработки.
Он допускает, что любой член команды разработки может выполнить любую задачу, но главный критерий — команда должна быть способна выполнить любую задачу в целом.Строго говоря декомпозиция идет рекурсивно на подсистемы. Проектирование подсистемы — это такая же задача как проектирование системы тока более мелкой. И так рекурсивно разбивается до самого мельчайшего компонента. Соответственно с какого то уровня разбиения каждый разраб должен смочь осилить весь цикл разработки сам иначе распараллеливание срывается, и получается и получается срам со сроками…
Почему ломает? Он требует декомпозировать задачи до уровня возможности ввода в эксплуатацию за один спринт. Более детально — сколько угодно можете декомпозировать, крупнее нельзя (хотя можно поиграть с длительностью спринта если, например, типовая атомарная задача занимает порядка 3-5 человеко-месяцев и достаточно хорошо параллелится).
Довольно дорогие для бизнеса разработчики, которые могут и будут самостоятельно разбираться с каждой задачей по многим направлениям сразу. Вот на нашем текущем стэке может потребоваться писать код/конфиги в рамках одной атомарной бизнес-задачи на HTML/CSS/TS/React/Node/PHP/MySQL/PostgreSQL/ElasticSearch/RabbitMQ/Docker/bash/k8s/nginx. Ни один человек в команде не может сходу решить задачу, которая затрагивает весь стэк. Вот у меня, мягко говоря, пробелы с ElasticSearch, на любую задачу с ним связанную мне надо закладывать минимум день на то, чтобы разобраться что это такое вообще (статью на вики я прочитал) и как мы его готовим в частности. И это оптимистическая оценка.
Ломает основу методологии проектирования — принцип декомпозиции.
Да где же он его ломает то? Неужели вы в вашем «научном подходе» не разбиваете на подзадачи? И неужели у вас подзадачи такие большие что команда разработки не в состоянии с ними справиться за 2-4 недели? И неужели вы отдаёте клиенту недоделанные компоненты, которые не будут нормально функционировать без доработки?
Да где же он его ломает то? Неужели вы в вашем «научном подходе» не разбиваете на подзадачи?Атомарной задачей является реализация компонета (класса), не имеющего нереализованных зависимостей. Именно это позволяет экспоненциально упростить разработку. И именно это срам и ломает от слова совсем И именно это срам и ломает от слова совсем.
И неужели у вас подзадачи такие большие что команда разработки не в состоянии с ними справиться за 2-4 недели?В подавляющем большинстве случаев реализация подобной задачи занимает от нескольких минут до пары дней. Но когда дело доходить до сложных счетных алгоритмов во взаимодействии группы классов отладка наиболее сложных моментов может занимать и несколько месяцев. При этом другими способами на это могут и годы уйти.
И именно это срам и ломает от слова совсем И именно это срам и ломает от слова совсем.
Каким образом то он это делает? Если скрам хочет чтобы вы разбивали на подзадачи и вы сами и по себе всё равно разбиваете на подзадачи, то в чём проблема?
Но когда дело доходить до сложных счетных алгоритмов во взаимодействии группы классов отладка наиболее сложных моментов может занимать и несколько месяцев.
Взаимодействие отдельных рпботающих компонентов это уже по хорошему отдельная задача. И она на мой взгляд точно так же великолепно разбивается на отдельные подзадачи, которые вполне себе реализуемы за 2-4 недели. Так в чём проблема?
Такой подход даёт прежде всего ускорение разработки необходимой клиенту функциональности, на которой он может валидировать свои бизнес-гипотезы: нет смысла, тратить, например несколько человеко-лет на разработку по вашему подходу, если можно за несколько человеко-месяцев сделать MVP, поиграть с ним немного и выкинуть, поняв, например, что автоматизация какого-то процесса рынку не нужна, платить за неё никто не готов.
А если "выстрелит", то даже если конечная функциональность будет сделана несколько дольше чем с вашим подходом, то разница окупится тем, что с продукт начнёт приносить деньги, пока вы ещё к имплементации не приступили. При том, что с почти 100% вероятностью, потратив несколько человеко-лет, вы сделаете не совсем то, а очень вероятно, что совсем не то, что нужно рынку. То, что сказал заказчик сделаете, но рынку это не нужно будет почти наверняка, в том виде, в котором вы сделаете, заказчик ненмого поиграет придёт просить переделать.
Рад за вас. Но тогда я не понимаю зачем в таком случае вообще было нужно ваше участие.Оборудование производства 70-х имеет свойство изнашиваться и устаревать быстрее механики. А соответственно нужна переделка всего этого под более современное железо.
Такой подход даёт прежде всего ускорение разработки необходимой клиенту функциональности, на которой он может валидировать свои бизнес-гипотезы:
Не начнет. На рынке вы в позиции отстающего. И быстрее не будет. А особенно доделка дальнейших фич. Потому что на этапе MVP уже будет заложена гигантская техническая задолженность, для ликвидации которой проще переделать все с нуля по наукам.
Вы первую главу диплома писали когда нибудь? Ну ту которая называется «Oбоснование актуальности разработки»? Что там пишется? Обзор того что есть на эту тему, чего в нем нету, и что вы собираетесь улучшить.
Т.е. для коробочного софта пока набор фич, надежность, эффективность и в общем все качества не выйдут на уровень того что там уже есть никто этот софт не купит. Когда выйдет — уже есть какие то шансы. При этом если у одного конкурента кроме общего набора фич есть фича A а у другого только фича B а вы имеете и A и B то есть шанс погнать обоих с рынка сцанными тряпками.
А догнать их можно только одним способом — избежать при разработке технических задолженностей и дублирования реализации.
При том, что с почти 100% вероятностью, потратив несколько человеко-лет, вы сделаете не совсем то, а очень вероятно, что совсем не то, что нужно рынку.
Еще раз — начните с обоснования актуальности. При этом со 100% вероятностью технологический базис подавляющего большинство продуктов либо покрывает предметную область на 100% либо вообще никакую фичу на нем сделать не реально.
А если покрывает то юзать это будут очень долго. Для примеру — ядро ParaSolid. Сделано в середине 90-х меньше чем за год. Ходят упорные слухи что одним человеком. Первый же продукт сделанный на этой технологической базе фактически вышвырнул с рынка местного гигемона который лет 20 был почти монополистом. Полный список фич которые на него можно навесить ищут всем миром до сих пор.
Оборудование производства 70-х имеет свойство изнашиваться и устаревать быстрее механики. А соответственно нужна переделка всего этого под более современное железо.
Такое на мой взгляд если и есть, то это достаточно узкая ниша. Я лично пока ни разу не встречал чтобы оборудование 70-х годов «просто переделывали под новое железо».
НЛО прилетело и опубликовало эту надпись здесь
А у большинства автопроизводителей есть и бюджетные автомобили, в которых нет адаптивных круиз-контролей, 4-зонного климат-контроля, третьего ряда сидений и беспроводной зарядки для телефонаУ всех крупных продуктов тоже есть комплектации. Технологический базис при этом везде один. Набор фич запиленных на этом базисе разный.
Получается, что разработчикам уже не нужно делать никакой проект с нуля, потому что обязательно нужен проект с суммой всех фич подобных проектов?В этом и недостаток конкурентного рынка в данном случае. Хотя и решается в какой то мере такой прослойкой как мидлвар. Тот же ParaSolid очень даже охотно продают само ядро. На нем сейчас 75% рынка САПР живет.
На практике же продукт даже с одной фичей может захватить рынок. Или не весь, но выйти на какую-то его часть.
Исключительно во влажных фантазиях евангелистов срамо-агила. В реальности же имеем Гугл плей, Майкрософт стор, Стим гит, и т.д. заваленные мусорными поделками слепленными из говна без палок. И постоянное ухудшение софта в плане надежности и эффективности без добавления какой либо функциональности.
А для более-менее серьезного софта, для реализации даже одной фичи, нужно ровно 100% технологического базиса. Например для реализации любой из фич SolidWorks или Siemens MX нужна модель всего набора примитивов и операций над ними. Что собственно ядро ParaSolid и делает.
Т.е. софт это не автомобили. В автомобилях само производство тоже денег стоит и не малых а не только проектирование как в софте. А соответственно любая комплектация софта фичами идет на одной и той же технологической базе.
НЛО прилетело и опубликовало эту надпись здесь
Как пример, Basecamp, Wrike, хотя были и есть аналоги.Если много кричать «Срам» там где есть тока водапад или еще какая фигня мешающая разработке, и при этом квалифицированных разрабов дефицит жуткий, то в любую бредятину вкладываться будут лишь бы соломинку какую обещали спасительную. Особенно в веб-девах всяких. Разрабов то на 3-месячных курсах веб-дева на базе средней школы графы чертить то не учат так же как и азам специальности от слова совсем. А какой без графов анализ зависимостей то?
А тем более если там промотивировать обещают. А то у этого контингента мотивация обычно действительно очень сильно хромает.
НЛО прилетело и опубликовало эту надпись здесь
Водопад фиксирует набор фич и затягивает начало реализации пока этот набор не определен. При этом как известно Мерфи был оптимистом. Здесь же нам пофиг на то как этот список меняется. Система из предметной области «Ы». Клиент хочет фичу «кражу со взломом» предлагает 300рэ. Посчитали кружочки — от трех до пяти. Нее… 330. Каждому.
А если хочет фичу «Бомбардия Кыргыду» это уже совсем другое кино. Но про того же Шурика.
Вообще был интересный как то проект. Вернее сам то проект был скучный. Интересно это было именно в плане утрясания фич. Суть была такая. Делал систему учета диллера мобильных контрактов для CDMA. Ну и шло это типа как дополнительно в свободное время от от систем массового предпродажного обслуживания оных трубок. При этом вся нижняя часть технологической базы была в наличии шикарная. Ну грубо говоря VCL. В общем клиент неделю шурупает че он хочет. Присылает ТЗ на лист. Перечень функциональности. В течение суток ему улетал софтина со всем этим прикрученым. В общем за два месяца так сделали все модуля данных — т.е. учет самих контрактов учет труб и прочего инвентаря учет ремонта и там учет всего че можно. гуй под сенсорник печать чеков с формированием превьюхи прямо на лету. Учет рабочего времени оператора. Подмену собой рабочего стола и невозможность снять и запустить другую софтину даже через диспетчер задач. Ну от получается — при наличии технологической базы даже не полной (все эти гуи и системные примочки естественно ручками) на реализацию ушло в 7 раз меньше времени чем на придумывание фич.
Ну а если технологической базы нет? Получается скажите предметную область. Потом изобретайте свои фичи хоть до усерачки. Наберется технологическая база реализуется все это быстрее чем изобретался список.
Ну грубо говоря — если делаем к примеру графику то какой там список фич не будет начнем все равно с вектора и матрицы. Если делаем САПР начнем все равно с вектора и матрицы. Если делаем физический движок начнем все равно с вектора и матрицы.
Т.е. для того чтобы начинать реализацию нужен роадмап как к этим фичам прийтить от самого низу а не список оных фич. При этом в подавляющем большинстве предметных областей к какой фиче не иди, а первый десяток шагов будет одинаков, причем для целой группы предметных областей.
А если хочет фичу «Бомбардия Кыргыду» это уже совсем другое кино. Но про того же Шурика.
Вообще был интересный как то проект. Вернее сам то проект был скучный. Интересно это было именно в плане утрясания фич. Суть была такая. Делал систему учета диллера мобильных контрактов для CDMA. Ну и шло это типа как дополнительно в свободное время от от систем массового предпродажного обслуживания оных трубок. При этом вся нижняя часть технологической базы была в наличии шикарная. Ну грубо говоря VCL. В общем клиент неделю шурупает че он хочет. Присылает ТЗ на лист. Перечень функциональности. В течение суток ему улетал софтина со всем этим прикрученым. В общем за два месяца так сделали все модуля данных — т.е. учет самих контрактов учет труб и прочего инвентаря учет ремонта и там учет всего че можно. гуй под сенсорник печать чеков с формированием превьюхи прямо на лету. Учет рабочего времени оператора. Подмену собой рабочего стола и невозможность снять и запустить другую софтину даже через диспетчер задач. Ну от получается — при наличии технологической базы даже не полной (все эти гуи и системные примочки естественно ручками) на реализацию ушло в 7 раз меньше времени чем на придумывание фич.
Ну а если технологической базы нет? Получается скажите предметную область. Потом изобретайте свои фичи хоть до усерачки. Наберется технологическая база реализуется все это быстрее чем изобретался список.
Ну грубо говоря — если делаем к примеру графику то какой там список фич не будет начнем все равно с вектора и матрицы. Если делаем САПР начнем все равно с вектора и матрицы. Если делаем физический движок начнем все равно с вектора и матрицы.
Т.е. для того чтобы начинать реализацию нужен роадмап как к этим фичам прийтить от самого низу а не список оных фич. При этом в подавляющем большинстве предметных областей к какой фиче не иди, а первый десяток шагов будет одинаков, причем для целой группы предметных областей.
Скрам, точнее аджайл в целом, заточен под команду (не путать с рабочей группой) мотивированных профессионалов, способных и желающих самостоятельно организовать свою работу. Уже способных и уже мотивированных. Можно сказать, уже уставших от менеджеров, прибегающих каждый день с криками "бросай всё, вот это нужно вчера" и желающих спланировать свою работу хотя бы на пару недель вперёд. При этом фикс критических багов — форс-мажор, требующий отмены спринта. Ведь профессионалы крайне редко допускают баги, требующих полчаса-час локализации и фикса в пару строк и при этом не могущих подождать 2-4 недели.
Большинство страданий от скрама обе стороны (бизнес и разработка) я наблюдал (и страдал на стороне разработки) либо от отсутствия мотивированной команды профессионалов (либо профессионалов было критически мало, либо командой не являлись, просто пилили задачи из бэклога по очереди с единственной наблюдаемой мотивацией выполнить свои задачи и, желательно, что-нибудь ещё, часто не из бэклога спринта, а из общего, чтобы премию получить). Другая основная причина — убежденность (часто обоснованная из-за первой) менеджмента в неспособности команды к самоорганизации на достижение поставленных целей и, как следствие, постоянное вмешательство в, по скраму, строго внутренние процессы скрам-команды и даже команды разработки.
НЛО прилетело и опубликовало эту надпись здесь
Потому крупнейшие мировые автопроизводители и не успевают за Теслой: им нужно переделать свои платформы практически с нуля.А у того же Белаза мотор-колеса с рождения. И в плане выживаемости водителя при лобовом столкновении в случае слета с катушек автопилота ТЕслы шансы выжить куда выше чем у водителя Теслы.
Разговор то в принципе про то что комплектации одного производителя идут на той же технологической базе, в отличии от автомобилей. Ну а то что не угоняются за Теслой — ну вот накопили технических задолженностей а Тесла за счет разработки с нуля от них свободна.
А как получается что у парасолид есть новые фичи в новых версиях?
Если все что вы рассказываете верно, я представляю ченджлог так:
- Версия 1.0 — все мыслимые и немыслимые фичи
- Версия 1.1 — багфиксы
- Версия 1.2 — багфиксы
.... - Версия 9999.99999 — багфиксы
А как получается что у парасолид есть новые фичи в новых версиях?
Сименс когда его перекупил начал гибрид лепить — кроме твердотельного еще и нечто подобное аки в максе напрямую с полигонами пытаются прикрутить. Зачем это надо мало понятно. Никто кроме Siemens MX это юзать не захотел по абсолютно понятным причинам.
Опять же фичи — это просто слой над ядром. Если какая то из них востребована во многих САПР-потребителях то можно ее и в комплект вогнать, хотя к технологическому базису она уже не относится — т.е. по большому счету оттянуть на себя часть прибыли покупателей ядра. Расширение то путем надстройки — это именно его суть которая и делает его ядром. Т.е. фичи это как бы то что меняется и реализуется как взаимодействие сущностей предметной области. Ядро — это набор оных сущностей и он постоянен, пока в самой предметной области не произойдут серьезные изменения. К примеру солид так и потеснил автокад — перешел к 3D моделированию на NURBS, разработанных в конце 80-х, раньше. А для этого весь набор 2D фич должен был быть как минимум не хуже.
Если все что вы рассказываете верно, я представляю ченджлог так:
Ядро. 100% моделей предметной области. 100% баг фри. Поскоку дублирования функциональности, нет а повторное юзанье абсолютное, и рефакторингов не было и не будет, то оттестировано все абсолютно и N раз — 1-ый раз нижний слой компонентов вооще пробренчин разрабом вдоль и поперек во время отладки иначе оно просто не отладится — бренч в отличие от юнита показывает не просто работает/не работает, а что именно и даже очень часто почему именно. А дальше в силу повторного использования второй слой при отладке жестко бренчит первый и т.д. Т.е. скрытому багу выжить без шансов.
А дальше используя ядро, аки фабрику фич клепаем чем больше тем лучше. Кста на роль фабрики фич в ParaSolid канает операция нахождения пересечения NURBS. Т.е. банально решение систем нелинейных уравнений. Оно же и в решении ограничений трудится. Только уравнения немного другие. А строятся то по тому же принципу. Все осталньое — оптимизации для некоторых частных случаев тел, из которых двуногие предпочитают лепить свои поделки.
Он посмотрите список фич солида 1.0 и 2019-го. А функциональность ядра не менялась. Потом правда над ним ядро обсчета конечными элементами добавилось, которое модели и сетки на них юзает построенные геометрическим ядром. Та же эпопея. Делали очень быстро несколько человек. Озадачивают фичами как минимум 2000 ученых из разных областей техники уже лет 10 как минимум. А тут фичи то эти вооще не код а конфигурации.
Т.е. так оно все экспоненциально упрощается. А при этих бреднях про MVP наоборот экспоненциально усложняется.
Т.е. банально — нарисуй схему зависимостей между сущностями предметной области и сразу видишь и сложность реализации каждой фичи какую ни захоти клиент, и какие фичи имеют общий базис и т.д. Т.е. в результате все равно выходит что технологический базис MVP 100% сущностей или около того юзает.
А если дело касается сугубо информационных систем — то начертив это в специальной софтине уже и всю схему БД имеешь. Остается только таблицы и поля к элементам GUI прибиндить и можешь сдавать клиенту. Ну можно еще дизайнера натравить чтоб свистоперделками обвешал. Но серьезная клиентура за свистоперделки во внутрикорпоративных системах по рукам надает и будет права на 100%.
Ну и еще такой момент — вы баги в стандартных библиотеках часто видели? А они именно по такому принципу строятся. По другому не получится. Компоненты слоев, особенно нижних, по зависимостям то закольцованы.
НЛО прилетело и опубликовало эту надпись здесь
Вот как раз недавно: habr.com/ru/company/jugru/blog/490250
Ну жаба это вооще ошибка природы. Но по сравнению с баглом к примеру скайпа или вижака 19-го — ну как бы очень редко.
В C++ так вообще сначала спроектировали auto_ptr, затем объявили deprecated, потому что кривой получился.
Да она вообще кривая как я не знаю что. Не потому что бажная. А потому что начальную архитектуру контейнеров делал физик под свои личные нужды. Под его нужды может и подходит отлично. Тока возможности кастомизации которые язык позволяет не юзает и на 5%. То же касается и auto_ptr. А вообще это по большому счету фишка для облегчения перехода студентов с жабы. Там в школах моск жабой насилуют поголовно. Поэтому без перехода никаких топ-разрабов не будет в принципе. А для чего то серьезнее чем студенческие поделки она не годится от слова совсем. Слишком уж не гибкая и интерфейс уродский. И самая большая беда — никакой гарантии бинарной совместимости подкапотных данных разных реализаций. А поменять — ну на него стока легаси завязано что ужас.
Эту взаимозависимость в джавовских модулях как раз недавно рубили.Ну это уже в зависимости от зависимости. Закольцованность это очень часто инкапсуляция более высокого порядка. Т.е. скрывается от вмешательства не какая то часть данных, а механизм взаимодействия между сущностями.
Т.е. ненужные кольца надо рубить, нужные наоборот вносить. Но это опять же актуально в основном в системных делах, где предметную область по большому счету мы сами изобретаем. Для каких то областей не связанных с разработкой для облегчения разработки все зависимости уже продиктованы какой то более другой наукой. При этом есть и неявные зависимости. Ну не по иерархии наследования или композиции. К примеру базис от вектора зависит прямо — он из них состоит. А вот вектор от базиса прямо не зависит. Но толку от него без операции умножения на базис что с козла молока.
Зачем это надо мало понятно. Никто кроме Siemens MX это юзать не захотел по абсолютно понятным причинам.
Вы ж сами недавно писали, что чем больше фич тем лучше. Продукт с большим количеством фич вытесняет продукт меньшим.
Опять же фичи — это просто слой над ядром.… хотя к технологическому базису она уже не относится ...
Эээ. Все ваши рассуждения относятся только к ядрам или к продуктам в целом тоже?
Можно ли где-то увидеть ченджлог того, что вы называете ядром Parasolid?
Вы ж сами недавно писали, что чем больше фич тем лучше.
В данном случае это внесение какой то ущербной фичи. Полигон — это NURBS-сурфес первого порядка. Т.е. сглаженная поверхность моделируемая одним NURBS-сурфейсом моделируется сеткой полигонов. При этом сетку из сурфейса построить элементарно (так кста весь рендер в редакторе и живет). А вот восстановить параметры сурфейса из сетки ну как минимум неодноззначно. Т.е. сетка полигонов инфы о характеристиках всей поверхности в целом не имеет. Почему еще в 60-х перешли к рациональным сплайнм Безье, и в последствии к NURBS. Т.е. это какой то шаг на 70 лет назад. При этом все эти дела делаются и штатными средствами твердотельного моделирования.
Продукт с большим количеством фич вытесняет продукт меньшим.
Кого вытеснять? Аскон? Так он и так не конкурент на мировом рынке. А на российском он вне конкуренции по программе импортозамещения. Или Автокад? Так у того есть такая фича как огроменная база легаси-чертежей в 2D. И с этим в обозримом будущем ничего не сделаешь. Даже при наличии фичи их импорта. Кого вытеснять? Аскон? Так он и так не конкурент на мировом рынке. А на российском он вне конкуренции по программе импортозамещения. Или Автокад? Так у того есть такая фича как огроменная база легаси-чертежей в 2D. И с этим в обозримом будущем ничего не сделаешь. Даже при наличии фичи их импорта.
А все остальные, не считая пет-проектов, на ParaSolid живут. Хотели бы че то реально апать смотрели бы в сторону математического новшества — T-сплайнов. Но там опять же преимущества не шибко внятные.
Можно ли где-то увидеть ченджлог того, что вы называете ядром Parasolid?Чендж-лог апи солида посмотрите. Это все по сути набор информационных запросов к ядру. Меняются только интерфейсы причем незначительно, в целях увеличинеия удобства использования. Сам же перечень сущностей и выполняемы ими счет постоянный. Естественно что там за это время была адаптация к новому железу — т.е. и распараллеливание добавили и на x64 перешли. А вот на аппаратную тасселяцию NURBS в шейдере почему то нет.
Но набор примитивов и операций над ними был тот же самый сразу. И тут вариантов нет. Либо набор непротеворечив — т.е. все операции в результате дают примитивы того же набора, либо ядро неюзабельно. Т.е. ничего в этом плане ни добавить ни убрать нельзя.
А полный чендж-лог скорее всего не найдете. Оно всегда было в собственности фирм завязанных по полной на оборонку. Конкретно — на проектирование истребителей. И собственно говоря с этой целью и создавалось.
С технической точки зрения, Agile всего лишь компенсирует отсутствие правильного менеджмента и позволяет работать пусть и менее эффективно, но безопасно (для бизнеса). Расплачиваются за это конечно его сотрудники.
НЛО прилетело и опубликовало эту надпись здесь
Вопрос об эффективности сильно спорный. Для начала нужно определить критерии эффективности. Реализация по «классическому» способу может получиться архитектурно более совершенной и более качественной в плане будущей поддержки, но этапы анализа задачи, проектирования и согласования могут занять непозволительно много времени.Ну вот потому классический способ и существует, что без проектирования довести до стадии готового продукта что то сложнее хеллоуверда вооще малореально или как минимум на порядки дольше. Давно уже сложилась практика не использовать в разработке/продакшине изготовленные путем срамо-агила поделки (либы/софтины) с историей версий менее 5 лет.
Аджайл применяется (должен применяться) там, где нет конечного вида продукта на старте проекта (там и проекта в смысле пмбука обычно нет), а есть бесконечная проверка бизнес-гипотез. Там, где результат, полученный "на порядки быстрее" можно сразу выбрасывать, потому что никто им пользоваться в итоговом виде (совпадающим с начальным видением) не будет.
P.S. Можно представлять скрам как череду проектов длительностью в пару недель и фазой проектирования в пару дней из них. Два дня попроектировали, за восемь дней реализовали, и начали новый проект "фиксед прайс энд тайм" с определения его целей и типовым уставом.
Ну дык такое если где и есть то только в развешивании свистоперделок на мусорных веб-лендингах. Но это как бы не к разработке софта относится а таки к интерактивной рекламной полиграфии. Да и то только к самому процессу развешивания а не к созданию фреймверков для оного
потому что никто им пользоваться в итоговом виде (совпадающим с начальным видением) не будетПри нормальной разработке серьезного софта серьезному начальству глубоко пофиг как это будет выглядеь. Ему важно что оно будет обеспечивать в плане процента прироста выработки офисного планктона/оборудования. А как это обеспечить уже программисты решают вникая в специальную литературу по предметной области и доки по объекту автоматизации. Ну или на худой конец из непосредственного общения с бугалтершей, если это какая нибудь банальная система бухучета конторы «рога и копыта», скрывающаяся под солидным термином «бизнес-логика».
Могу переформулировать так "никто им пользоваться не будет, потому что от него будет не процент прироста выработки, а процент его уменьшения". Проведут опытную эксплуатацию, посмотрят, и увидят, что не автоматизированные процессы лучше отвечают реалиям рынка, чем то, что автоматизировали "на порядок быстрее". Поговорили с бухгалтершей, она рассказала, что делает на тот момент, а пока анализировали, проектировали и имплементировали, что-то произошло, что сделало 90% функциональности не помогающей, а мешающим основному бизнес-процессу.
Могу переформулировать так «никто им пользоваться не будет, потому что от него будет не процент прироста выработки, а процент его уменьшения».Знаете еще в студенческие времена в лихих 90-х имел дело с переносом на новое железо систем корпоративного учета сделаных в 70-х по мохровому классику. Так вот единственной хотелкой закзчика было — чтобы все было так аки есть. Ну или хотя бы чтобы гибкость конфигурации была не хуже. Прошло лет 20. Новая волна обновления. И что вы думаете хотелки поменялись? Та не меняется эта предметная область. В принципе не меняется. С Древнего Рима не меняется. Меняются только всяческие коэффициенты которые конфигурацией и задаются.
С технической точки зрения, Agile размазывает фазу проектирования на весь период разработки ПО. Это, во-первых, позволяет быстрее получить и выпустить в прод MVP, что обеспечивает конкурентное преимущество для бизнеса. Во-вторых, это позволяет подстраивать разработку продукта к условиям рынка. В третьих, это позволяет заблаговременно находить «подводные камни» в решаемой задаче и адаптировать решение с их учётом (найти другой способ реализации, изменить, отложить или отменить исходную задачу).Хорошо сказано! Но если бы Agile на этом и останавливался, то таких бурных дебатов вокруг него не было бы. Но в нем, к сожалению, начинают применять какие-то странные методики управления социумом наемных работников, что просто диву даешься — зачем это все? Нет, конечно, мне могут всё объяснить зачем нужно то или это. Только я не верю этим объясняльщикам, что они вообще понимают, о чем говорят.
Думаю, есть две основные причины не любить аджайл вообще, и скрам в частности:
- не разделять их ценности, принципы, рамки, процедуры. Ну вот если люди, которые терпеть не могут постоянных изменений, которые хотят получить расписанные ТЗ на год вперёд и пилить их. Или те, которые считают, что без надлежащей документации задача не сделана и лучше сделать на 70% документацию и задачу, чем на 100% задачу и 40% документацию. Или ежедневные митинги считают потерей времени, типа в джире всё есть, посмотртеь можно в любой момент.
- в принципе могли бы полюбить (насколько это слово применимо), но сталкиваются с "перегибами на местах", когда на словах вроде аджайльнейший скрам, а по факту, например, набор ритуалов ради галочки, с нарушением их принципов и без оглядки на их цели.
Да, логично.
Так как по сути аджайл – это не столько рамки или процедуры, сколько ценности, то первый пункт я бы переформулировал так:
есть люди, для которых
- процессы и инструменты важнее людей и человеческого общения; или
- исчерпывающая документация важнее работающего продукта; или
- соблюдение условий контракта важнее отношений с заказчиком; или
- следовать первоначально намеченному плану важнее, чем реагировать на изменения.
Им аджайл не по душе.
есть люди, для которыхВот это вы натянули аджайл на глобус! Сказали бы проще: кто не аджайлист — тот не д'Артаньян.
процессы и инструменты важнее людей и человеческого общения; или
исчерпывающая документация важнее работающего продукта; или
соблюдение условий контракта важнее отношений с заказчиком; или
следовать первоначально намеченному плану важнее, чем реагировать на изменения.
Им аджайл не по душе.
Аджайл для тех людей, которым:
-
процессы и инструменты важнее людей и человеческого общения; или
Вот часто и получается так, что вместо работы все превращается в бесконечное «человеческое общение», когда команда топчется вокруг пары формочек, раз по тридцать её переделывая. Когда «человек» там, не может толком сформулировать чего ему надо.
исчерпывающая документация важнее работающего продукта; или
Это когда документации нет, «продукт» как-то там работает, но никто толком не представляет как, потому что те сотрудники, которые все это начинали, давно уже сгорели и свалили, а новые смотрят на все это по принципу «ну вот так сделано, а почему — хрен его знает, доков-то нет»соблюдение условий контракта важнее отношений с заказчиком; или
Это когда работы сделано на десяток проектов, а контракт так и не выполнен, и заказчик придумывает все новые и новые гениальные решения плана «покрасьте ту кнопку в зеленый и подчеркните ее пятью перпендикулярными друг-другу линиями»?следовать первоначально намеченному плану важнее, чем реагировать на изменения.
Это когда планы меняются быстрее чем ты успеваешь сесть за компьютер? А потом тебе выставляют претензии «ну что ты там так долго возишься, задачка то простая!!!!11111
Это когда работы сделано на десяток проектов, а контракт так и не выполнен, и заказчик придумывает все новые и новые гениальные решения плана «покрасьте ту кнопку в зеленый и подчеркните ее пятью перпендикулярными друг-другу линиями»?
Самый подходящий контракт для скрама: оплата каждого спринта почасово, возможно с поправкой на процент выполненных задач.
Это когда планы меняются быстрее чем ты успеваешь сесть за компьютер? А потом тебе выставляют претензии «ну что ты там так долго возишься, задачка то простая!!!!11111
Скрам фиксирует требования на спринт. В исключительных случаях они могут меняться с согласия команды с тем или иным видом перепланирования.
Вот реально, было дело так довелось поработать, мотивация стухла после трех-четырех спринтов, потому что вообще непонятно что я тут делаю и нахрена оно кому-то нужно. З/п была неплохая, но как уже в том числе и тут говорилось, з/п это монтивация не главная после определенного ее уровня.
Продолбались пол года с пятью-шестью формами, раз по десять переделывая каждую, в процессе чего я в режиме реального времени наблюдал как люди выгорают и сваливают. На старте энтузиазм бил фонтаном, через пол года на проекте осталось три калеки.
Продолбались пол года с пятью-шестью формами, раз по десять переделывая каждую, в процессе чего я в режиме реального времени наблюдал как люди выгорают и сваливают. На старте энтузиазм бил фонтаном, через пол года на проекте осталось три калеки.
Видимо как раз дело в "непонятно что я тут делаю и нахрена оно кому-то нужно".
Мне в подобной ситуации было очень интересно. Были определены ключевые метрики типа конверсии, среднего чека и т. п., делали форму, заливали на A/B тесты (иногда A/B/C/D или даже A+B/A+C/D+B/D+C), смотрели метрики, кто выигрывает, улучшали, заливали… (один из внезапных выводов: добавили искусственную задержку в 0.45 с перехода между формами, хотя до этого вылизывали милисекунды на фронте и бэке)
Да, раз по 10, но с азартом, в духе соревнования как с рынком, так и друг с другом, кто лучше идею предложит.
Ну это мощно зашли, с учетом того что это написано в аджайл манифесте…
… То есть, иными словами, технари, а не гуманитарии. Или, языком соционики, логики, а не этики. Разумеется, процессы, инструменты, документация и контракты важнее отношений и маниакально-депрессивной смены настроения — мы давно не в первобытном обществе живем, где это роляло среди приматов, а находимся в построенной на базе науки высокотехнологичной сфере, ведущей человечество вперёд. Точнее, так должно быть — в нонешней реальности не дотягиваем, любые вот эти "общения" и срамы-эджайлы, бизнес-требования и капитализмы — отбрасывают нас назад, к приматам.
P.S. Если кто воспринял слишком обобщенно — не переживайте, в мире, конечно, есть место и общению, и эмоциям, и настроению. Вот только выбирайте правильно сферу. В соответствии с тождеством филогенеза и онтогенеза, перенесенным на общество и индивидуальную человеческую жизнь, самое место им — например, в воспитании детей в детском саду и начальной школе. Тоже очень важно, без базару (любой психолог подтвердит) — но в программирование, т.е. другую сферы, это совать нефиг.
Очевидно, что чаще всего с "разумеется" и т. п. начинается какая-то демагогия. :)
Бизнес-требования и капитализмы отбрасывают нас назад?!
Ну разумеется, отбрасывают, ибо вперёд человечество двигают наука и технический прогресс. А демагогией это кажется лишь тем, у кого опыт/эрудиция по теме настолько низки, что через несколько ступеней разницы в развитии они уже зачастую даже понять не могут, что им говорят. Очень наглядно в большом треде выше это — по маааленькому под-вопросу! — инженер АСУТП продемонстрировал: он им про научный подход, а они ему как суеверные крестьяне XIX века на трактор смотрят. Ну или как антипрививочники и прочие верующие в мистическую чепуху — на достижения медицины.
Вот, кстати, кризисы и другие форс-мажоры — отличный пример. Китай, будучи уже хоть не много не совсем капитализмом, справляется с эпидемией гораздо лучше Италии. Но это сейчас, а дальше будет типичное бизнесовое — если вакцину разрабатывать скажем год, а вдруг её потом не купят, то зачем инвестировать и разрабатывать? Плевать на жизни, пусть помирают! Вполне отбрасывание назад.
В куче других отраслей (даже программировании) та же фигня — они будут делать не то, что НАДО, а то, что будет приносить прибыль.
Ну а совсем глобально если, капитализмы-бизнесы — игра с нулевой суммой. Кто в состоянии из этого сделать логические выводы, тот прекрасно поймёт, чем это плохо.
Это не игра с нулевой суммой, валовый продукт растёт постоянно, всё больше благ производится и распределяется.
И даже в вашем примере с вакциной (пускай факты такие), где вы видите отбрасывание? Ну не инвестируют средства в вакцину, не будет в этой области прогресса, будет в какой-то другой, а а тут просто без прогресса.
Agile = бардак. В крупных корпах эджайл надёжное прикрытие для неспособности организовать производство софта.
Хозяйчик продукта — в крупных корпах полно продактовнеров, не желающих что-то менять для удобства смежной команды. Согласование форматов взаимодействия подсистем может длиться по полгода.
Нет хозяина — нет продукта.
Всё зависит от целей этого хозяина.
Он может бояться, что изменения в продукте принесут новые баги, сбои, аварии, недовольство начальства.
Еще может использовать полномочия для подчеркивания своего статуса, чтобы все шли к нему на поклон.
Хозяин, как говорится – барин. Царю жалуйтесь!
(не понимаю только, как это связано с Agile)
Самым прямым образом, учитывая комментарий "про общение и отношения" парой экранов выше. То есть этот вашенский эджайл, типа, претендует на общение и хорошие отношения, но на деле не может их обеспечить даже с соседней командой.
Аджайл и не ставит своей целью их обеспечивать. Это необходимое условие для его применения. В среде, где ставят процессы и инструменты выше людей и общения, практики аджайл работать не будут. Или среду меняйте, или попытки внедрения аджайл без изменения среды — разбазаривание времени и других ресурсов.
"Ах если бы, ах если бы, не жизнь была б, а песня бы!"
Как видно по статье и комментариям даже топикстартера в этой ветке, эти вещи у них в головах полагаются взаимосвязанными. Но ведь, если подумать, и в самом деле: если этот ваш эджайл требует себе по зависимостям некие идеальные условия — то нафиг он в реальном жизни нужен? А если, с другой стороны, он не включает в себя конкретные методики по изменению этой самой среды (так сказать, инсталляции зависимостей) для возможности своей работы — то опять же, зачем он такой нужен? Оба вопроса, естественно, идут в контексте того, что вот это утверждение, о среде, никто обычно не говорит (я лично первый раз слышу). Оно и понятно, как ж тогда коучинг и прочее продавать… А потом эджайл закономерно и не любят, в т.ч. за такой обман, да.
Ну вот, прямая цитата из манифеста, например "Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им."
Разве не очевидно, что в среде, где люди работают из-под палки и/или "на отвали", "ты начальник — я дурак...", а руководство проверяет каждый их чих, аджайл работать не будет?
Не знаю, ребят. У меня опыт работы по Agile только в двух компаниях, и в обеих — положительный. Никаких проблем нет от него, и вообще, все работает как часы.
Всё хорошо в меру. Работал в фирме, где Agile-ритуалам следовали настолько строго, что они напоминали сборища продавцов Гербалайфа: система, в которой как продаём важнее, чем что продаём. Форма важнее содержания. Работал и в таких, где чуть больше agile помогло бы структурировать бардак.
небо над головой – это наши цели, к которым мы стремимся
А если моя цель — это получать зарплату за качественно сделанную работу, я идеологически неправильный по меркам Agile?
Ваша цель не уникальна и никому не чужда. На этой почве Вы найдете общий язык со многими. Возможно, поделившись своей целью с коллегами, вы станете больше доверять друг другу, сработаетесь в отличную команду.
Возможно после этого Вы сможете поделиться с ними и другими своими целями, о которых пока стесняетесь говорить, прячась за маской циника.
И всё это, походу, никак не противоречит Agile.
Когда говорят про командную работу, обычно кидает из крайности (и жнец, и на дуде игрец) в крайность (сидение в колодцах), поэтому я бы добавил следующее:
1. Универсальные солдаты бывают только в кино. У каждого члена команды есть и должна быть специализация, надо дать возможность эту специализацию реализовывать. На примере химии скажу: есть учёные, которые в моделирование умею, а есть талантливые экспериментаторы. И это очень плохая идея таланливого головой, но редкостного рукожопа ставить к lab bench с серной кислотой. А крутые работы возникают тогда, когда каждый делает своё дело, но при этом интенсивно общаются, объединяя свои опыты и знания.
2. Не мешать другим делать свою работу. Этот пункт вытекает из первого. Спрашивать о помощи, предлагать её, но не влезать без смазки во всех места сразу.
3. Самоорганизующаяся команда — это фантастика на грани со сказкой. Есть PO, который ставит задачи, направления работы, которые он получает в общем случае от стейков (это и владельцы, и PO других команд, и заказчики). Да, внутри команды эти вводные перераспределяются, обрабатываются, но называть это самоорганизацией я бы не стал.
Про цели. Фанатиков на Земле не так много, как кажется, чтобы ими насытить все agile-компании, чтобы они работали 24/7. Глобальные и достижимые цели должны ставиться руководством, наверное, а не рядовым сотрудником, который не обладает необходимой информацией, верно?! Но при этом должна быть обратная связь с самого низа до самого верха иерархии.
А вообще всё это довольно забавно, так как в Советское время было понятие, как научная организация труда, которая сейчас по большому счёту превратилась в Scrum/Agile.
1. Универсальные солдаты бывают только в кино. У каждого члена команды есть и должна быть специализация, надо дать возможность эту специализацию реализовывать. На примере химии скажу: есть учёные, которые в моделирование умею, а есть талантливые экспериментаторы. И это очень плохая идея таланливого головой, но редкостного рукожопа ставить к lab bench с серной кислотой. А крутые работы возникают тогда, когда каждый делает своё дело, но при этом интенсивно общаются, объединяя свои опыты и знания.
2. Не мешать другим делать свою работу. Этот пункт вытекает из первого. Спрашивать о помощи, предлагать её, но не влезать без смазки во всех места сразу.
3. Самоорганизующаяся команда — это фантастика на грани со сказкой. Есть PO, который ставит задачи, направления работы, которые он получает в общем случае от стейков (это и владельцы, и PO других команд, и заказчики). Да, внутри команды эти вводные перераспределяются, обрабатываются, но называть это самоорганизацией я бы не стал.
Про цели. Фанатиков на Земле не так много, как кажется, чтобы ими насытить все agile-компании, чтобы они работали 24/7. Глобальные и достижимые цели должны ставиться руководством, наверное, а не рядовым сотрудником, который не обладает необходимой информацией, верно?! Но при этом должна быть обратная связь с самого низа до самого верха иерархии.
А вообще всё это довольно забавно, так как в Советское время было понятие, как научная организация труда, которая сейчас по большому счёту превратилась в Scrum/Agile.
Почему разработчикам не нравится Agile?