Comments 116
Отсутствие конкуренции это монополия. В отсутствии конкуренции что заставит монополию меняться к лучшему? не понятно
Тут существует куда более системная проблема — никто не знает, как надо. А если и думает, что знает — то может ошибаться.
Плюрализм, при всей его неэффективности, спасает человечество от принятия единого неправильного решения, которое это самое человечество и похоронит (ввиду отсутствия альтернатив).
ЗЫ: При этом с авторской критикой Agile можно в солидной степени согласиться, кстати.
Плюрализм, при всей его неэффективности, спасает человечество от принятия единого неправильного решения, которое это самое человечество и похоронит (ввиду отсутствия альтернатив).
ЗЫ: При этом с авторской критикой Agile можно в солидной степени согласиться, кстати.
Сначала поставим вопрос: зачем вообще меняться? Капиталистическим монополиям — очевидно только в случае серьёзной угрозы со стороны других монополий (если это глобальный рынок) или под давлением госрегулятора.
Социалистической централизованной экономике — под давлением со стороны пользователей. Естественно, тут есть всякие тонкости, чтобы не получилось в итоге, как СССР. Но глобально это правильнее: удовлетворять нужно нужды пользователей, а не рынка
под давлением со стороны пользователей
Простите, а как вы представляете давление на централизованную экономику от потребителей? Вот даже чисто в теории? Какими механизмами это могло бы обеспечиваться и регулироваться?
Уже есть многочисленные системы сбора мнений: отзывы, рейтинги. Если убрать отсюда маркетнговую составляющую и оставить собственно исследовательскую функцию, то будет отличный инструмент обратной связи. В маркетинге вообще много наработок. Главное — заставить их работать на пользу потребителя
ключ думается лежит в смене концепции «давление» на концепцию «интерес», в смысле творчество, престиж, общественное признание. Линукс разве под давлением возник и развивается, а не от интереса и амбициозности?
Это не работает. Линукс развивается «от интереса» только потому, что те, кому он неинтересен — идут мимо и вообще никак не зацепляются. Для них есть альтернативы.
Общественные механизмы же должны работать почти на 100% общества. Ну или отправлять всех незаинтересованных на Луну. Без скафандров.
ЗЫ: Но да, вы в общем-то повторили мысль известных теоретиков коммунизма 30-50-х годов: надо всего лишь сделать систему из людей, которые в эту систему вписываются. И сразу всё будет хорошо ^_^
Общественные механизмы же должны работать почти на 100% общества. Ну или отправлять всех незаинтересованных на Луну. Без скафандров.
ЗЫ: Но да, вы в общем-то повторили мысль известных теоретиков коммунизма 30-50-х годов: надо всего лишь сделать систему из людей, которые в эту систему вписываются. И сразу всё будет хорошо ^_^
> под давлением со стороны пользователей.
Которого не было (или было крайне незаметным для системы).
Которого не было (или было крайне незаметным для системы).
В принципе, есть сценарий монополии open-source проекта. Например, существует ровно один компилятор хаскеля, одно linux kernel, и т.д. Возможен не везде, но мне кажется идеальным, т.к. берет лучшее от монополии, но гораздо слабее проблемы монополии.
Грустно это всё. Человек поработал в Сбертехе 3 месяца (=1 испытательный срок), и теперь думает, что детально разбирается, что такое Agile, и как его "исправить".
Есть спорные моменты, но в целом идея автора верна. Agile — это не методики, решающие проблему «сделать как лучше». Это методики, решающие проблему «как заставить заказчика больше платить». Поэтому в конкурентной борьбе, когда таковая появится на рынке разработки ПО, аджайл скорее всего проиграет.
Agile как бы загоняет нас обратно в эру примитивного обслуживания станка. Да, знания и голова работника по-прежнему нужны работодателю. Однако теперь, когда процесс разбит на максимально короткие отрезки, работник уже не концентрируется на производстве продукта целиком. Его фокус внимания направлен на постоянное изготовление мелких улучшений. Он производит гайки, которые потом каким-то образом сами вырастут в цельный механизм.
Второй важный процесс, который ускоряется с внедрением Agile, это фактическое разложение трудовых коллективов. Agile преподносится как удобный механизм, который позволяет перебрасывать имеющиеся у капиталиста трудовые ресурсы на разные проекты, при этом сохраняя высокое качество поставляемого продукта.
Какая лютая околесица.
Любой Agile-фреймворк и сама философия стоит на кроссфункциональных автономных командах. То есть не предполагает функционального деления, заточенности отдельных представителей под отдельные гайки, ресурсного мышления (перебрасывания «ресурсов» из проекта в проект). А предполагает вовлечение каждого в создание итоговой ценности в противовес фокуса на узкой специализации и постоянном составе команды (иначе это не команда, а временная группа людей).
Из неверных исходных предпосылок растут мощные но бессмысленные выводы и опровержения.
Сопротивления аджайлу в Сбертехе обоснованно, потому что то, что там практикуется и подаётся там под видом аджайла (по описанию процессов, которые я слышу от приходящих оттуда кандидатов) на самом деле имеет к нему весьма отдалённое отношение.
Это только в теории. В реальности специалист сталкивается с тем, что ему нужно постоянно дополнять свои знания в своей узкой предметной области, либо он проигрывает в конкуренции и вылетает с работы. Допустим, у специалиста по Java, который в рамках кроссфункциональности перетёк на фронтенд-задачи, показатели резко упали, задачи выпали из графика.
В том же Сбертехе предполагалось слить все специализации в одну — аналитик-тыжпрограммист. Код предполагалось писать в системе написания автокода, кастомный делать вставками только в определённых местах. Вот что такое кроссфункциональность, когда предполагается, что все могут делать всё. Нн знаю, довели они эту инициативу до конца или нет. Надеюсь, что нет.
В том же Сбертехе предполагалось слить все специализации в одну — аналитик-тыжпрограммист. Код предполагалось писать в системе написания автокода, кастомный делать вставками только в определённых местах. Вот что такое кроссфункциональность, когда предполагается, что все могут делать всё. Нн знаю, довели они эту инициативу до конца или нет. Надеюсь, что нет.
UFO just landed and posted this here
В теории да. На практике? Если в каком-то месте случается bottleneck, то поскольку спринты короткие и надо типа что-то выкатывать к концу каждого — то на узкое место кидают всех, кто не может отбиться от этой сомнительной чести.
А уж если сразу очевидно, что какой-то узкий спец не вполне будет загружен в одной команде (например, дизайнер, у которого по завершению основного этапа проектирования всё равно постоянно есть работа по доработкам и правкам, но этой работы маловато) — то им начинают играть в пинг-понг между командами, про что автор статьи тоже упоминал.
ЗЫ: У нас в конторе хоть аджайл и всё еще в стадии «выкатывания», и многое криво, но тем не менее вот эта вот тенденция на перемешивание уже стоит в полный рост и никуда деваться не собирается. Я уже даже ментально привык, что меня (фронтэндщика) могут либо сдёрнуть на пару недель в другую команду, потому что у них всё плохо, а ты крутой и разберешься, ну и что, что там технологический стек совсем другой; либо же предложать понастраивать деплой, потому что надо вотпрямщас, а имеющиеся спецы в данный момент загружены по макушку.
А уж если сразу очевидно, что какой-то узкий спец не вполне будет загружен в одной команде (например, дизайнер, у которого по завершению основного этапа проектирования всё равно постоянно есть работа по доработкам и правкам, но этой работы маловато) — то им начинают играть в пинг-понг между командами, про что автор статьи тоже упоминал.
ЗЫ: У нас в конторе хоть аджайл и всё еще в стадии «выкатывания», и многое криво, но тем не менее вот эта вот тенденция на перемешивание уже стоит в полный рост и никуда деваться не собирается. Я уже даже ментально привык, что меня (фронтэндщика) могут либо сдёрнуть на пару недель в другую команду, потому что у них всё плохо, а ты крутой и разберешься, ну и что, что там технологический стек совсем другой; либо же предложать понастраивать деплой, потому что надо вотпрямщас, а имеющиеся спецы в данный момент загружены по макушку.
Как же принцип, что команда сама даёт оценки трудозатрат?
Если случается bottleneck, при планировании спринта непрофильные специалисты поставят задаче «5 дней на разобраться» и профильный поставит «2 часа быстро сделать». В среднем получится адекватно.
Если случается bottleneck, при планировании спринта непрофильные специалисты поставят задаче «5 дней на разобраться» и профильный поставит «2 часа быстро сделать». В среднем получится адекватно.
В теории да. На практике?
А на практике зависит от реализации и понимания реализаторами теории.
В основе аджайл и скрама в частности стоит самоорганизация, то есть никто не вправе указывать команде, как выполнять работу и тем более перекидывать участников между командами по своему разумению. Если же это наблюдается, то не стоит называть это аджайлом, пусть и в стадии «выкатывания». Иначе, получается, виноват аджайл, а вовсе не то, что его кто-то толкует извращённо.
В моей текущей команде, разработчики С++ не гнушаются помогать с разбором и написанием тестов на Java, потому что в данный момент это важнее для достижения конечной цели. Да, это не доставляет им особого удовольствия, писать новый функционал интереснее, но это был их осознанный выбор, а не указание свыше.
В процессе такой взаимопомощи они обретают новые взгляды на продукт — с точки зрения тестирования — что приводит к идеям по дальнейшему изменению и развитию архитектуры. В этом суть командной кросс-функциональности и гибкости, а не во взаимозаменяемости и перебрасывании людей.
Но важен менталитет. И далеко не только менеджеров. Если человеку хочется писать только на плюсах и только бэкенд, то аджайл конечно ему зачем? Классический функциональный колодец будет предпочтительнее.
В основе аджайл и скрама в частности стоит самоорганизация, то есть никто не вправе указывать команде, как выполнять работу и тем более перекидывать участников между командами по своему разумению.
И это как раз одно из довольно многочисленных мест, где теория скрама в сравнении с реальностью напоминает розовых пони.
Если принимать команду за цельный юнит без отсутствия вмешательства, то совершенно очевидно, что у команды должны быть все функции найма/увольнения для регулирования собственного размера и состава. На практике — если только контора по большей части не представляет из себя одну команду — никто так просто команде эти функции не отдаст. Разумеется, существенная часть фактического найма и увольнения скорее всего будет происходить именно в команде, но каждый раз это будет требовать дополнительной работы вне команды и согласований (в части финансов, HR, секьюрити, и тэ дэ).
Плюс, у команды должны быть функции слияния/деления, опять же чисто исходя из скрамовских «команде следует быть от 3 до 9 человек» (а продукты бывают каких угодно размеров). На практике же это легчайше выливается в сопротивление внешних сил плюс всё те же вопросы с наймом, так как разная разбивка на команды может требовать меньше или больше организационных усилий (и соотсветственно, разного количества людей под это).
Но важен менталитет. И далеко не только менеджеров. Если человеку хочется писать только на плюсах и только бэкенд, то аджайл конечно ему зачем? Классический функциональный колодец будет предпочтительнее.
Ну в общем-то вы сами всё и подтвердили. «Мы кроссфункциональная команда и каждый из нас специалист своего дела, но если вдруг случайно вам не нравится то, что вы можете оказаться на любом участке продукта в любой из используемых нами технологий — то, пожалуйста, проходите мимо» ^_^
… то есть никто не вправе указывать команде, как выполнять работу и тем более перекидывать участников между командами по своему разумению
Ну вообще управление ресурсами как-раз и есть основная задача предприятия. Или мы тогда понимаем компанию как де-факто конгломерат мелких фирм, которые берут один крупный подряд и уже сами внутри себя решают все вопросы от и до. Но я такого не видел в живых компаниях. Может, где-то и есть.
Ну вообще управление ресурсами как-раз и есть основная задача предприятия.
Да, но люди это не ресурсы. И как только эта концепция осознаётся, всё встаёт на свои места.
www.stickyminds.com/article/management-myth-32-i-can-treat-people-interchangeable-resources
Ну как… Везде только и говорят о «человеческом капитале». Капитал, как мы помним, это самовозрастающая стоимость. Это то, что инвестируется с целью получить деньги-штрих. Это самый основной ресурс и есть.
Весь HR — это про то, как привлечь и удержать необходимых людей, то есть обеспечить компанию лучшим человеческим ресурсом. Компании вкладываются в обучение, чтобы развить свой ресурс. Да, он чуть более сложен в управлении, чем парк станков, но тем не менее.
Весь HR — это про то, как привлечь и удержать необходимых людей, то есть обеспечить компанию лучшим человеческим ресурсом. Компании вкладываются в обучение, чтобы развить свой ресурс. Да, он чуть более сложен в управлении, чем парк станков, но тем не менее.
Ага. Это по идее наоборот защищает команду и ее членов. Команда, которая может выполнять полный цикл разработки, при проблемах с обуревшим маняманагером 9000 звена может свалить всей толпой куда-то. Хоть в другую фирму, хоть на фриланс, параллельно развивая командный бренд и пет-проекты. Просто решается проблма того, что в одно лицо крайне тяжело уметь все: уграничения мясной тушки, системная консолидация, вот это все.
Сбертех, Сбертех, Сбертех. Это рекламная статья? Так бы сразу и написали, чтобы люди время не тратили.
Каким образом настанет это «счастливое будущее»? Корпорации крепко вцепились во власть и так просто её не отдадут.
Это второй вопрос, он не по теме этого ресурса. Но интересно предположить, как будет организовано производство после капитализма
А мне кажется, что вопрос поставлен верно: каким же это образом будущее настанет. Сейчас это выглядит как рассуждение о том, чего мы будем делать, если завтра прилетят инопланетяне, которым срочно потребуются наши запасы марганцовки.
Пока что едва ли не все механизмы отказа от капитализма подразумевали насильственную смену парадигмы и по сути запрет капиталистической деятельности. Этот путь вряд ли кому-то захочется ещё раз пробовать, а альтернативы непонятны.
Пока что едва ли не все механизмы отказа от капитализма подразумевали насильственную смену парадигмы и по сути запрет капиталистической деятельности. Этот путь вряд ли кому-то захочется ещё раз пробовать, а альтернативы непонятны.
Сберджайл
«с общественной точки зрения гораздо выгоднее и разумнее произвести один раз хороший продукт,»
Общество не соглашается. Общество хочет иметь возможность выбора. Для этого продуктов должно быть много. На разных этапах нужны разные продукты. Если после внезапного показа во всех кинотеатрах страны «Бриллиантовой руки» возникнет ажиотажный спрос на мобильники с перламутровыми пуговицами — что будем делать? Срочно выпускать такие телефоны или объяснять пользователю, что это блажь и ему не следует этого хотеть?
botyaslonim Влиять возможно можно — например петиции/требования о ремонтопригодности техники. Но не обходится без нюансов. Скажем взять ту же заправку картридже принтеров. Хитрые пользователи заправляющие картриджи по пять раз по сути запускают руку в карман пользователям которые меняют картриджи целиком. И это всё инертно.
И даже когда мы выкладываем свои типовые решение в open-source, это не останавливает рост трудозатрат в IT-отрасли: есть ещё вендоры, создатели новых, ещё чуть более усовершенствованных технологий, языков, фреймворков, которые требуют постоянного переобучения и разработки нового кода, новых прикладных решений.
То что действительно не нужно — не находит применения и последователей. А если люди всем этим занимаются — то… профит видимо есть.
P.S.
Чем виноват Agile я так и не понял.
Общество не соглашается. Общество хочет иметь возможность выбора. Для этого продуктов должно быть много. На разных этапах нужны разные продукты. Если после внезапного показа во всех кинотеатрах страны «Бриллиантовой руки» возникнет ажиотажный спрос на мобильники с перламутровыми пуговицами — что будем делать? Срочно выпускать такие телефоны или объяснять пользователю, что это блажь и ему не следует этого хотеть?
botyaslonim Влиять возможно можно — например петиции/требования о ремонтопригодности техники. Но не обходится без нюансов. Скажем взять ту же заправку картридже принтеров. Хитрые пользователи заправляющие картриджи по пять раз по сути запускают руку в карман пользователям которые меняют картриджи целиком. И это всё инертно.
И даже когда мы выкладываем свои типовые решение в open-source, это не останавливает рост трудозатрат в IT-отрасли: есть ещё вендоры, создатели новых, ещё чуть более усовершенствованных технологий, языков, фреймворков, которые требуют постоянного переобучения и разработки нового кода, новых прикладных решений.
То что действительно не нужно — не находит применения и последователей. А если люди всем этим занимаются — то… профит видимо есть.
P.S.
Чем виноват Agile я так и не понял.
Хитрые пользователи заправляющие картриджи по пять раз по сути запускают руку в карман пользователям которые меняют картриджи целикомА хитрые пользователи, которые варят борщи дома, по сути запускают руку в карман пользователям, питающимся в ресторанах (те же недополучают прибыль, а значит, увеличивают цены).
Ну не совсем. Если бы в магазинах продавали продукты дешевле себестоимости ресторанам, чтобы те потом делились прибылью с магазинами, а тут ррраз — хитрые готовильщики дома подсуетились — и тоже покупают задешево чтобы варить борщи — тогда да, а сейчас — для оптовиков одна цена, в розницу — другая. В плане картриджей — видимо должны быть модели которые заправляются без проблем — но эти принтеры тогда дороже стоят. А если дешево будет всё — то производитель принтеров/картриджей перестанет их производить. Впрочем это всё очевидный маркетинг.
P.S. Возможно открытие магазина (скажем со вкусными полуфабрикатами) рядом с рестораном утянет часть клиентуры, ресторану придется повышать цены… и тогда да — всё как вы сказали. Посетители магазинов по сути залезают в карман посетителям ресторанов. )))
P.S. Возможно открытие магазина (скажем со вкусными полуфабрикатами) рядом с рестораном утянет часть клиентуры, ресторану придется повышать цены… и тогда да — всё как вы сказали. Посетители магазинов по сути залезают в карман посетителям ресторанов. )))
Соковыжималка системы agile уйдёт в прошлое.
Я тоже думаю, что agile отомрёт. Хотя и обогатит собой почву. Но вот Ваше утверждение про «соковыжималку» не поддерживаю. По моим наблюдениям, agile в силу его неэфыективности декларируют в комфортабельных проектах, со стабильным долговременным бюджетом и необходимостью подпралять и улучшать существующее или делать примерно одно и тоже.
В сложных, больших и срочных проектах agile не работает. Одна из основных причин — чтобы сделать что-то сложное и/или новое, надо хорошо подумать. Думать про тестирование лучше до начала реализации, но интеграционные тесты можно делать когда всё сделано. Поэтому задание спринта расщепляется как минимум на три фазы — продумывание (архитектура/дизайн), реализация, тестирование. Либо вся команда участвует во всех трёх фазах — что неэфыективно, либо во время разных фаз (спринтов) члены команды занимаются разными фичами (одни тестируют фичу N, другие программируют фичу N +1, третьи продумывают фичу N +2) но это тогда не agile.
Agile предполагает в том числе и разветвлённую метрику активности работников. В идеале, каждый рабочий час работника должен быть посвящён решению совершенно конкретной задачи. В спринт никто не ставит 10 часов на «подумать» и «пообщаться с коллегами». Я это имел ввиду
Отнюдь. Мой "эджайл" другой (и больше я люблю перевод "адаптивный подход")
Точнее из моего опыта:
Кроссфункиональность команды!=кроссфункиональность каждого ее члена;
Стабильный состав команды -> важное условие достижения эффективности;
Вовлечение члена команды во все стадии разработки продукта (от идеи до продакшна) -> помогает человеку не быть винтиком и чувствовать свой вклад лучше, чем в традиционных подходах (ака водопад).
Статья во многом интересная, много пищи для размышлений, но некоторые предпосылки мне кажутся ошибочными.
Эджайл про умение адаптироваться, и индиферентен к тому, адаптироваться под повышение маржинальности или под удовлетворении потребности пользователя. Тут выбор за нами.
помогает человеку не быть винтиком и чувствовать свой вклад лучше, чем в традиционных подходах (ака водопад).
Вы поработали в большом количестве агильных и неагильных проектов и это ваш эмпирический опыт или у вас есть достоверная статистика на этот счёт?
Это эмпирический опыт многих людей. Работая в отделе фронтенд, ты даже не знаешь зачем пилится продукт. Поэтому будьте уверены — вовлеченность значительно больше. Целеполагание, прозрачность, инспекция бэклога участниками команды — это все составляющие части одного из Agile фреймворков. Они не то чтобы дают вовлеченность, это просто одна из основных ЦЕЛЕЙ.
А я думаю, инспектируя бэклог никогда не узнаешь, зачем (выражаясь Вашими словами) пилится продукт. И вообще, пилится ли он. Целепологание тоже отсутствует. Никогда не ясно, мы закончим через 3 месяца или через три года. Всё зависит от того, что в бэклог ещё добавят.
Область, где Agile работет, черезвычайно узка. Об этом писали многие, например feodorbene в комментарии и я здесь.
Область, где Agile работет, черезвычайно узка. Об этом писали многие, например feodorbene в комментарии и я здесь.
Зачем пилится продукт очень даже хорошо узнается, если об это хотя бы просто поговорить, но тот же Lean заставляет работать над портретами своих клиентов, понимать их потребности, обозначать гипотезы и проверять их. Тот же скрам заставляет имперически проверять что работает для клиентов, а что нет. В итоге приходит поинимание, что проект пилится для таких-то людей, которые ночью любят покушать, а днем поездить на велосипеде, грубо говоря. Это как минимум — становится понятно зачем этот продукт клиенту. При этом, конечно никто не заставляет формулировать цель продукта для производителя, это уже не из области agile, это из области управления портфелем.
Целеполагание лежит в основе, как я уже сказал, одного из фреймворков. Оно есть по определению. Его нет, если разработка по сути «хаотическая».
Про когда закончим, откровенно говоря, вообще вопрос дискуссионный. Хотя бы потому что другие инструменты тоже не отвечают на этот вопрос сколько нибудь точно. Любые планы оказываются ложью, хоть строительство космического корабля, хоть моста, хоть разработка ПО для магазина одежды для кошек. Но, по-крайней мере в скраме, планы строятся на основе факта о производительности команды.
Целеполагание лежит в основе, как я уже сказал, одного из фреймворков. Оно есть по определению. Его нет, если разработка по сути «хаотическая».
Про когда закончим, откровенно говоря, вообще вопрос дискуссионный. Хотя бы потому что другие инструменты тоже не отвечают на этот вопрос сколько нибудь точно. Любые планы оказываются ложью, хоть строительство космического корабля, хоть моста, хоть разработка ПО для магазина одежды для кошек. Но, по-крайней мере в скраме, планы строятся на основе факта о производительности команды.
Так дело в том, что в современной экономике клиент сам часто не знает, что для него пилить. Требования рынка постоянно меняются. Рассматривая предметную область, исследуя клиента, мы часто работаем впустую, т.к. оно потом всё-равно сильно поменяется. Экономика в целом работает не на максимальное удовлетворение конкретных потребностей, а на удовлетворение хаотичных движений рынка, и от этого проблемы.
Я попытался с этого боку посмотреть на организацию производства сейчас.
Я попытался с этого боку посмотреть на организацию производства сейчас.
Экономика в целом работает не на максимальное удовлетворение конкретных потребностей, а на удовлетворение хаотичных движений рынка, и от этого проблемы.
А я вот слышал, что сейчас есть всякое стратегическое видение и создание потребностей. Что именно вы читали об экономике где так написано?
Стратегическое видение — просто слово из презентаций. Конечно, есть планирование, но есть, допустим, неожиданные обвалы рынка. Есть, наконец, совершенно закономерные циклические кризисы капиталистической экономики. Я не видел, чтобы компании публично в своих планах учитывали: «С 20… по 20… циклический кризис, падение продаж 20%». За таким релизом мгновенно последует обвал акций такой компании
не видел, чтобы компании публично в своих планах учитывали: «С 20… по 20… циклический кризис, падение продаж 20%».
Откуда тут взялось слово публично. Как отсутствие чего-то публичного доказывает тезис "Экономика в целом работает не на максимальное удовлетворение конкретных потребностей, а на удовлетворение хаотичных движений рынка, и от этого проблемы."
Нет ли у движений рынков своих закономерностей? У вас в институте макроэкономика была как предмет?
У меня в техническом вузе была экономика, да. Ещё я читал Маркса, Энгельса, Ленина, немного Мизеса, Хайека и Смита, а также статьи современных авторов, которые объясняют что-то лишь в своём поле допущений.
Между удовлетворением рынка и потребностей есть очевидная разница, как можно этого не видеть?
Между удовлетворением рынка и потребностей есть очевидная разница, как можно этого не видеть?
Между удовлетворением рынка и потребностей есть очевидная разница, как можно этого не видеть?
Разумеется есть. А с кем вы спорите? Если вы вменили мне это мнение то по какой причине? Я лишь оспаривал хаотичность движения рынка.
Во-вторых, нельзя сказать, что движения рынка никак не связаны с потребностями покупателей. Или вы это утверждаете?
Это мой эмпирический опыт. Но, думаю, just for fun, было бы классно посчитать статистику.
Может быть, поделитесь Вашим опытом, где эджайл не работал, и почему так (с Вашей точки зрения) вышло?
Про личный опыт я говорить не вправе, поэтому обобщённый опыт. Agile точно не работает если:
1. Необходимо иметь фазу архитектуры и фазу интеграционного текстов (более детально здесь
2. Команда больше 9 человек
3. График релизов предопределён и не совпадает со спринтами.
4. Бюджет и сроки жестко заданы заказчиком.
1. Необходимо иметь фазу архитектуры и фазу интеграционного текстов (более детально здесь
2. Команда больше 9 человек
3. График релизов предопределён и не совпадает со спринтами.
4. Бюджет и сроки жестко заданы заказчиком.
1. Я пока в своей жизнь, в разработке ПО, не встречал случая, где разработку архитектуры стоит выносить в отдельную фазу. Может у меня мало опыта, а может «отдельная фаза» просто привычное дело, которое пихают во все щели просто потому что это привычно? Впрочем допускаю, что где-то это может пригодиться, но пока еще такого не встретил.
Интеграционные тесты вполне уместны в Agile. Тот же Дядюшка Боб или Гойко Аджич хорошо описали как их надо делать. Все что автоматизируется — хорошо ложится в рамки Agile. То что не автоматизируется — может не лечь красиво.
2. Нет проблем, есть фреймворки для масштабирования.
3. Релизы не должны совпадать со спринтами. Спринты вообще не являются неотъемлемой частью Agile.
4. Здесь сложнее.
Но вообще-то вы затронули темы совершенно новые, не относящиеся к теме статьи никак. Основной посыл статьи — компании хорошо, а человеку — плохо. Это не так. Agile учит сотрудничеству и создавать ценный продукт вместо прикрывания своего зада и игры в футбол. Agile это этап развития, который учит людей работать совместно. Agile учит командной работе. Agile даёт удовольствие от работы, если конечно участник команде не хочет только крутить бесполезные гайки. Такой человек, да, будут выгнан самой командой, т.к. он просто не работает на общую цель.
Интеграционные тесты вполне уместны в Agile. Тот же Дядюшка Боб или Гойко Аджич хорошо описали как их надо делать. Все что автоматизируется — хорошо ложится в рамки Agile. То что не автоматизируется — может не лечь красиво.
2. Нет проблем, есть фреймворки для масштабирования.
3. Релизы не должны совпадать со спринтами. Спринты вообще не являются неотъемлемой частью Agile.
4. Здесь сложнее.
Но вообще-то вы затронули темы совершенно новые, не относящиеся к теме статьи никак. Основной посыл статьи — компании хорошо, а человеку — плохо. Это не так. Agile учит сотрудничеству и создавать ценный продукт вместо прикрывания своего зада и игры в футбол. Agile это этап развития, который учит людей работать совместно. Agile учит командной работе. Agile даёт удовольствие от работы, если конечно участник команде не хочет только крутить бесполезные гайки. Такой человек, да, будут выгнан самой командой, т.к. он просто не работает на общую цель.
На «подумать, проанализировать» и т.д. в Agile есть понятие «spikes», если что.
Что мешает все это за-agile-ить в вашем стиле? Все что вы озвучили можно оформить в Agile. Я даже сам себя так организовываю, а не команду. Просто не нужно воспринимать все в штыки и офорьмте очередность. Думайте и дизайнируйте сколько понадобится и двигайте дедлайн при неудачах, но очередность и карта действий быть должна, просто это удобно называть все Agile и Scrum, иначе не ясно как все это называть )
Если Вы увидите незнакомый фрукт, вряд ли стоит называть его знакомым названием помидор. Так же и с Agile и Skrum. Не стоит применять эти названия, если это не они (в соответствии с общепринятыми определениями).
Мой тезис — если вам в проекте необходимы фазы архитектура/дезайн, реализация, интеграционный тест (возможно другие) — то лучше не обманывать себя, что вам подходит агильный подход.
Это не будет фатальной ошибкой, но будет неэффективно, ИМХО.
Мой тезис — если вам в проекте необходимы фазы архитектура/дезайн, реализация, интеграционный тест (возможно другие) — то лучше не обманывать себя, что вам подходит агильный подход.
Это не будет фатальной ошибкой, но будет неэффективно, ИМХО.
Сколько существует agile-команд, столько существует и вариаций agile. Понимаете в чем дело, вне зависимости от того, какую именно гибкую методологию выбирают, она будет искажена потребностями тех, кто ее внедрял. Видимо, вам особенно не повезло
А в гуглах-фейсбуках тоже используют agile/scrum?
Что-то у меня большое сомнение на этот счёт…
Что-то у меня большое сомнение на этот счёт…
Прекращение конкуренции, снижение рабочего времени, выбор единых технологий и фреймворков. Звучит как утопия.
Хорошо, что вы уверены в будущем ) Управлять задачами нужно будет и не важно как вы это назовете. Каждый кто добавляет код в OpenSource всеравно сам себя организует при помощи Agile, может не по манифесту, а так как ему хочется, иначе — никак. Просто самообман и задрочество к терминам до добра не доведут. Нет единой системы на все случае — это невозможно исходя из психологии и просто объективной реальности относительности.
Я снова получу сейчас минусы, на которые, мне, в общем-то всё равно, но снова и снова вижу посты «знатоков» Agile и Scrum.
Ваша фраза «Спринт должен заканчиваться релизом...» уже говорит о том, что точно не на вашем текущем уровне понимания методологии рассуждать о её будущем. Ознакомьтесь сначала с матчастью, а, то, как опять же таки, если вернуться к вашей статье, ваши рассуждения выглядят не больше, чем рассуждения пролетариата о руководстве страной.
Тоже хотел написать аналогичный комментарий, что в статье бред и в лучшем случае обсуждается Scrum (и то какой-ко недовнедренный), а не Agile. Да и в большинстве комментариев тоже.
Однако стоит признать, что Scrum и Agile сейчас имеют негативную окраску. И не потому, что они в принципе плохи, а потому что они очень сложны во внедрении (хотя первый порядка 16стр, а второй 2стр). Поэтому они наверняка формально уйдут и будут заменены более простой системой.
Еще, думаю, важный момент в психологической совместимости культуры Scrum и программистов на нашей территории. Может быть, нужно что-то менее самоуправляемое только из-за этого.
PS. В этой связи мне нравятся книги компании Basecamp про организацию удаленной работы — они в какой-то мере могут заменить слова Agile/Scrum. Плюс, ориентир на надомную работу.
Однако стоит признать, что Scrum и Agile сейчас имеют негативную окраску. И не потому, что они в принципе плохи, а потому что они очень сложны во внедрении (хотя первый порядка 16стр, а второй 2стр). Поэтому они наверняка формально уйдут и будут заменены более простой системой.
Еще, думаю, важный момент в психологической совместимости культуры Scrum и программистов на нашей территории. Может быть, нужно что-то менее самоуправляемое только из-за этого.
PS. В этой связи мне нравятся книги компании Basecamp про организацию удаленной работы — они в какой-то мере могут заменить слова Agile/Scrum. Плюс, ориентир на надомную работу.
Особенность любых обсуждений этой темы в том, что сторонники подхода в ответ на любые замечания говорят "вы все не так поняли и неправильно делаете". А как надо-то? ЧСХ если привлечь консультанта, то можно оказаться в ситуации "у вас был плохой консультант". И, да, поскольку манифест писал лично Капитан Очевидность, то непосредственно из него мало что следует, отсюда масса толкователей, есть свои еретики и свои салафиты, и в целом не очень понятно, кто же прав, что считается харам и можно ли сторонникам Agile вступать в однополые браки (шутка, не принимайте на личный счёт). Ну а конкретные методологии чуть более конкретны, и потому имеют весьма ограниченное применение даже в разработке софта, а тем более в промышленности в целом.
Ещё всегда интересно слышать, что гибкий подход (к чему-либо) может быть как-то неправильно гибким. Не поняли вы аджайл, там про гибкость, но по-другому, не как у вас! Из серии "у вас неправильная демократия, потому что вы выбрали не того кандидата".
P.S.: Я в целом "за", а мой скепсис вызван тем, что я наверное просто испорчен разработкой "железных" продуктов, где объективно не все это применимо, хотя касаясь конкретно нас — у нас ооочень гибкий подход к разработке, много гибче, чем у других.
Особенность любых обсуждений этой темы в том, что сторонники подхода в ответ на любые замечания говорят "вы все не так поняли и неправильно делаете".
Тут вопрос общей культуры. Мне достаточно мало встречалось критиков, которые хоть немножко пытались разобраться в предмете. Например, очень редко встретишь такого, который бы ссылался на источник сведений о конкретной методике.
Для меня идеально было бы что-то вроде "У меня тут внедряют SAFe и тут возникли сложности вот с тем-то (ссылка на сайт с цитатой про какую-то практику) консультант говорит, что надо делать так-то, в сети еще встречаются такие-то советы (ссылка1, ссылка2, ссылка3) но все равно не работает из-за того-то и того-то"
Обычно я вижу вопли типа "Аджайл это соковыжималка потому, что у нас Скрам и штрафуют за то, что мы не успеваем к срокам, которые назначает начальник".
А так, да, аджайл понятие нечеткое и, одновременно, модное. Поэтому много желающих назвать аджайлом все, что угодно.
Перед написанием этой статьи я прочёл других штук 10, в т.ч. и на Хабре, чтобы ещё раз понять, что другие понимают под agile.
Базовое описание подхода (moneyfest) действительно очень размытое и общее. Интереснее рассмотреть, как он уже реализуется на практике и почему так.
Базовое описание подхода (moneyfest) действительно очень размытое и общее. Интереснее рассмотреть, как он уже реализуется на практике и почему так.
Например, очень редко встретишь такого, который бы ссылался на источник сведений о конкретной методике
Причина очевидна — с критикой обычно выступают непосредственные жертвы, а не организаторы процесса. Очевидно жертвам не столь хорошо знакомы источники сведений.
Аджайл это соковыжималка потому, что у нас Скрам и штрафуют за то, что мы не успеваем к срокам, которые назначает начальник
Очевидно они вопят неспроста? И вопрос «а почему у вас начальник сроки назначает?» вряд ли облегчит их боль.
Любая идея хороша тогда, когда исполнима с учетом факторов. Иначе, извините уж, не факторы виноваты, а либо идея, либо сонм ее поклонников, повсюду ее сующих. Вспоминается утверждение о том, что коммунизм надо было строить не в России, страна, мол, неподходящая была, потому эксперимент кончился крахом. Сдается мне, что либо сама идея, либо ее исполнители — не очень, а страна тут ни при чем.
А так, да, аджайл понятие нечеткое и, одновременно, модное. Поэтому много желающих назвать аджайлом все, что угодно.
Я повторюсь — сам по себе аджайл настолько общ, что под это определение на самом деле много чего подпадает (разве что пункт про частые релизы в некоторых видах разработок попросту неприменим). Это как Конституция России — хорошая, добрая и честная. Между тем конкретные методологии уже начинают слегка отдавать маразмом и неисполнимостью — примерно как некоторые российские законы, а то и целые своды их.
Избыток политоты политоты прошу считать сугубо сборником примеров.
Причина очевидна — с критикой обычно выступают непосредственные жертвы, а не организаторы процесса. Очевидно жертвам не столь хорошо знакомы источники сведений.
А жертвы слишком тупы и безинициативны чтобы сами сделать анализ ситуации и подумать что можно изменить. Они могут только орать "Ыыы больно".
И вопрос «а почему у вас начальник сроки назначает?» вряд ли облегчит их боль
Если они себе зададут этот вопрос себе, дополнив вопросом, "почему в скраме это не так" посмотрев на аргументацию, то они смогут попробовать переубедить начальника либо при поиске работы задать правильный вопрос.
Любая идея хороша тогда, когда исполнима с учетом факторов. Иначе, извините уж, не факторы виноваты, а либо идея, либо сонм ее поклонников, повсюду ее сующих.
Почему вы из трех причин выбираете одну чтобы сделать ее виноватой. С какой целью? При чем здесь вообще вина? По мне, так надо понять, какую из причин можно изменить.
Если можно изменить факторы, то надо менять факторы, если идею или поклонников, то надо их. Но чтобы разобраться, надо сначала их изучить.
Это как Конституция России — хорошая, добрая и честная. Между тем конкретные методологии уже начинают слегка отдавать маразмом и неисполнимостью — примерно как некоторые российские законы, а то и целые своды их.
В этой ситуации можно поступать по разному. В последнем подкасте медузы Олег Навальный рассказывал, что он очень изучил правила внутреннего распорядка когда сидел и добился их соблюдения от ФСИН там где ему было нужно.
Тогда он бросает всю пачку на пол — причем расписок там на долларов сорок-пятьдесят от каждого игрока — и поворачивается к выходу из ванной. В дверях останавливается и оглядывается.
— Но я хотя бы попытался, — говорит он. — Черт побери, я сделал все, что мог, в отличие от вас, разве не так?
И выходит, оставляя выпачканные бумажки на полу для тех, кто захочет в них разбираться.
А жертвы слишком тупы и безинициативны чтобы сами сделать анализ ситуации и подумать что можно изменить
А если просто не хотят? Вас вот все идиотские процессы на вашем предприятии интересуют, или только некоторые?
Если они себе зададут этот вопрос себе, дополнив вопросом, «почему в скраме это не так» посмотрев на аргументацию, то они смогут попробовать переубедить начальника либо при поиске работы задать правильный вопрос.
Да, сделать ноги сразу и далеко — очевидный выход. Но не всем подходит, да и вообще деструктивен.
Почему вы из трех причин выбираете одну чтобы сделать ее виноватой
Потому что это проверенное жизнью правило.
В последнем подкасте медузы Олег Навальный рассказывал, что он очень изучил правила внутреннего распорядка когда сидел и добился их соблюдения от ФСИН там где ему было нужно
Олег, при всем моем к нему уважении, может рассказывать что угодно — он фигура политическая, со всеми присущими ей минусами и плюсами. Я говорю о ситуации в целом, о том, как закон обходится с менее известными фигурами. Но это политота, давайте прекратим.
Но я хотя бы попытался
Ясно, традиционная волынка. Не менее традиционная впрочем, чем другая.
А если просто не хотят? Вас вот все идиотские процессы на вашем предприятии интересуют, или только некоторые?
Только некоторые. Обычно то, что мне сильно эмоционально не нравится, меня интересует. И, наоборот, если что-то меня не интересует, оно не вызывает потребности жаловаться.
Да, сделать ноги сразу и далеко — очевидный выход. Но не всем подходит, да и вообще деструктивен.
Интересно, что я вам предоставил несколько вариантов для обсуждения, а вы выбрали один. Почему? Деструкция не всегда плохо.
Я говорю о ситуации в целом, о том, как закон обходится с менее известными фигурами.
Я думаю, известность, можно тоже воспринимать как недостаток. Вполне можно ныть "Ыыыы ну конечно я ничего не мог сделать, потому, что я брат такого человека, они меня будут мучать" и так далее. Просто "жертва" — это такой подход к жизни. Я сам бываю таким, я знаю.
Но это политота, давайте прекратим.
Вы привели сравнения, я ответил на этом же поле.
Обычно то, что мне сильно эмоционально не нравится, меня интересует
Вот тут у многих людей как раз проблема — далеко не все изучают, например, механизмы распространения HIV, даже если страшно его боятся. Не хватит жизни на все «новости».
Интересно, что я вам предоставил несколько вариантов для обсуждения, а вы выбрали один. Почему? Деструкция не всегда плохо.
Буду говорить за рашен бизнес — другие варианты просто не работают.
Насчет деструкции — конечно оно так, «чем хуже — тем лучше», но глобально это не лучший подход.
Просто «жертва» — это такой подход к жизни. Я сам бываю таким, я знаю.
Это у всех периодически бывает, но ИМХО глобально дело не в этом, просто когда механизм воздействия на власть/руководство даже формально не прописан (а в тюрьмах он как раз прописан по крайней мере формально), то ничего не делать — естественный процесс. А вот ныть никто не запрещал, например кто-то про климат ноет, что же теперь.
Вы привели сравнения, я ответил на этом же поле
Я при этом и сразу написал, что предлагаю не продолжать.
далеко не все изучают, например, механизмы распространения HIV, даже если страшно его боятся.
Ну да боятся, сами болеют и не изучают — таких большинство
Буду говорить за рашен бизнес — другие варианты просто не работают.
Если не пытаться, то точно не работают. Если пытаться, то есть варианты. Кстати рашен бизнес это, в том числе, ABBYY, JetBrains, Касперский, Яндекс. Интересно, как у них.
Насчет деструкции — конечно оно так, «чем хуже — тем лучше», но глобально это не лучший подход.
Деструкция это не хуже, если она на месте. Уволиться из говноконторы эта правильная деструкция. Рак — это сбой деструкции.
Если не пытаться, то точно не работают. Если пытаться, то есть варианты
Ага, например заслужить репутацию «бессильного жалобщика». В этом нет ничего страшного itself, но деловые контакты у такого человека потом сильно усложняются, потому что — см. пирамиду Лебедева.
Кстати рашен бизнес это, в том числе, ABBYY, JetBrains, Касперский, Яндекс. Интересно, как у них.
Не могу сказать ничего о перечисленных компаниях «изнутри», но выскажу ничем не обоснованный скепсис в отношении любого рашен бизнеса и любых рашен бизнесменов.
Уволиться из говноконторы эта правильная деструкция
Ага, и бросить проект, и бросить людей, которые вместе с тобой тут ночевали, вот это вот все. То есть это конечно бывает необходимо. но от этого не легче.
например заслужить репутацию «бессильного жалобщика»
Если кроме жалоб не приходит на ум никаких других способов действия, то да. В таком случае репутация будет заслужена и лучше жаловаться на форумах :) тогда репутация будет только у ника.
Ага, и бросить проект, и бросить людей, которые вместе с тобой тут ночевали, вот это вот все. То есть это конечно бывает необходимо. но от этого не легче.
Проект не вечен. По определению. Возможно эти люди тоже так думают и не уходят и таким образом они друг друга мучают в говноконторе.
И вообще это напоминает манипуляцию чувством вины.
Если кроме жалоб не приходит на ум никаких других способов действия
Пример другого способа? Не вообще, а конкретно применительно к этому комментарию.
Проект не вечен. По определению. Возможно эти люди тоже так думают и не уходят и таким образом они друг друга мучают в говноконторе.
Вполне вероятно.
И вообще это напоминает манипуляцию чувством вины
Манипуляция с чьей стороны в данном случае?
Пример другого способа? Не вообще, а конкретно применительно к этому комментарию.
Конструктивное предложение, например, на ретроспективе желательно подтвержденное данными и учитывающее личную выгоду начальника.
Манипуляция с чьей стороны в данном случае?
Начальника, коллег, родителей, государства, общества.
Конструктивное предложение
Ну а какое именно?
Вот мы ноем — ааа, сроки задает начальник, в спринт не успеваем, нас штрафуют. Что предложить?
Я бы начал с анализа ситуации — почему все сложилось так, и какие цели у лиц принимающих решения.
Можно спросить начальника как он оценивает и посмотреть чего не хватает в оценках. Можно в багтрекере собрать статистику по реальной трудоемкости vs оценка и предложить на основе нее увеличить оценки, чтобы соблюдать условия. Можно посмотреть к каким последствием приводит такая политика (спешка => люди не тестируют => в последующие итерации разгребаем баги (статистика по багам, анализ откуда взялись, общая стоимость исправления на всех этапах) или (спешка => овертайм => выгорание => увольнения). Можно спросить почему именно все так устроено, почему он не доверяет оценке программистов.
Часто начальству нужна предсказуемость планирования, а тут вот баги-то как раз и мешают.
Еще если постоянный овертайм и штрафы, то просто похоже что программистам платят меньше чем договорились. Если это сознательная политика, а не по незнанию.
Тут как по мне, надо либо разбираться на уровень выше либо уходить.
Можно спросить начальника как он оценивает и посмотреть чего не хватает в оценках. Можно в багтрекере собрать статистику по реальной трудоемкости vs оценка и предложить на основе нее увеличить оценки, чтобы соблюдать условия. Можно посмотреть к каким последствием приводит такая политика (спешка => люди не тестируют => в последующие итерации разгребаем баги (статистика по багам, анализ откуда взялись, общая стоимость исправления на всех этапах) или (спешка => овертайм => выгорание => увольнения). Можно спросить почему именно все так устроено, почему он не доверяет оценке программистов.
Часто начальству нужна предсказуемость планирования, а тут вот баги-то как раз и мешают.
Еще если постоянный овертайм и штрафы, то просто похоже что программистам платят меньше чем договорились. Если это сознательная политика, а не по незнанию.
Тут как по мне, надо либо разбираться на уровень выше либо уходить.
Ок, зафиксировали. Вот вам ответы условного начальника, условно «внедрившего» условный скрам:
1) Вы должны делать задачи быстрее.
2) Хватит изобретать и мудрствовать, пилите проще, пусть будут костыли, главное быстрее.
3) Нет, ну конечно должна быть хорошая архитектура и комментарии.
4) Так, стоп, хватит болтать, тут в Н-ске ваши прошлые баги вылезли, бегом все чинить (При этом сроки новых разработок никуда не двигаются — Прим. авт.).
Естественно начальник не дурак, и периодически градус накала снижает, журит, двигает сроки релизов — ладно, мол, подождем. Более того, даже штрафов, положим, нет! Но от выгорания и появления новых складов с костылями и протезами это не спасает, потому что прессинг и бардак все время.
Само собой, и это декларируется постоянно и везде. Только при этом хочется, как в анекдоте, чтобы разработчику еще и пилу в задницу вставили — пусть заодно и дрова пилит.
1) Вы должны делать задачи быстрее.
2) Хватит изобретать и мудрствовать, пилите проще, пусть будут костыли, главное быстрее.
3) Нет, ну конечно должна быть хорошая архитектура и комментарии.
4) Так, стоп, хватит болтать, тут в Н-ске ваши прошлые баги вылезли, бегом все чинить (При этом сроки новых разработок никуда не двигаются — Прим. авт.).
Естественно начальник не дурак, и периодически градус накала снижает, журит, двигает сроки релизов — ладно, мол, подождем. Более того, даже штрафов, положим, нет! Но от выгорания и появления новых складов с костылями и протезами это не спасает, потому что прессинг и бардак все время.
Часто начальству нужна предсказуемость планирования
Само собой, и это декларируется постоянно и везде. Только при этом хочется, как в анекдоте, чтобы разработчику еще и пилу в задницу вставили — пусть заодно и дрова пилит.
1) Вы должны делать задачи быстрее.
Давайте обсудим, за счет чего? Пока я вижу что люди оптимизируют фазу тестирования, в результате предыдущая итерацию мы были заняты в основном исправлением багов. Для исправления бага его пришлось сначала воспроизвести службе поддержки, потом Васе потом Вася пообщался со службой поддержки чтобы уточнить шаги и потом он разобрался в коде и исправил. Если бы Петя протестировал это тщательнее то он бы исправил это быстрее, так как он помнил код и не отнимал время у трех человек.
Вот моя идея. А вы как считаете за счет чего мы должны работать быстрее?
2) Хватит изобретать и мудрствовать, пилите проще, пусть будут костыли, главное быстрее.
Я совершенно за простоту как и вы.
3) Нет, ну конечно должна быть хорошая архитектура и комментарии.
В этом мы на одной волне.
4) Так, стоп, хватит болтать, тут в Н-ске ваши прошлые баги вылезли, бегом все чинить (При этом сроки новых разработок никуда не двигаются — Прим. авт.).
Давайте потом подумаем, как сделать чтобы их было поменьше.
Потом прислать письмо с кратким описанием откуда возникли баги.
Само собой, и это декларируется постоянно и везде.
По моему опыту это не только декларируется. И я работал преимущественно в Российских компаниях.
Еще заметьте что аджайл совершенно выпал из этого диалога — он просто не является фактором тут. Основные проблемы тут отношение к разработчикам, планирование и качество. Эти проблемы можно решать, хоть в аджайле, хоть в водопаде только разными средствами и в соответствующих книжках описано какими.
Ваш сэмулированный начальник не ссылается на скрам или канбан. И еще вполне может быть что реальный начальник сложнее сэмулированного и поддается агрументированному убеждению в какой-то мере.
Ок, продолжаю быть начальником ))
By the way, все мои ответы будут непридуманными, это реальный опыт.
Надо просто лучше и больше работать, а не играть два раза в день по десять минут в пинг-понг и не читать статьи на Хабре после обеда.
Тогда почему вы постоянно ноете про этот ваш «технологический долг»? Не нужна эта ваша красота архитектуры, нужно быстро!
Ну так пишите же комментарии! Только не надо на это полдня тратить, мы не комментарии продаем!
Не потом, а сию секунду! Иначе я позвоню Самому Главному, и он вам объяснит, кому куда идти. Удовлетворенность клиентов на первом месте!
Мне это нафиг неинтересно, откуда они возникли (хотя я и делаю вид, что интересно), просто скажите, кто виноват.
Далее не от имени начальника.
Само собой, это то, что реально необходимо любому руководителю, реально необходимо. Но когда следом за вопросом «когда по вашему мнению это возможно» следуют слова «нет, это нужно раньше и имеющимися ресурсами», а потом еще оказывается, что имелось в виду значительно больше результатов и никто не брал в расчет, что появятся новые и новые проекты, то это уже не «запрос на предсказуемость».
Так конечно же! Большинство виденных мной начальников транслируют запрос бизнеса, а запрос рашен бизнеса известно какой. Как следствие — все перечисленные проблемы. И любая из гибких методик оказывается плоха именно тем, что по общему безусловному убеждению она способствует безусловному увеличению эффективности. И вот когда, например, скрам, начинает натягиваться на имеющуюся реальность, где у вас не будет ни защиты от прессинга, ни скрам-мастера, ни вменяемой системы формирования требований, ни свободной работы с бэклогом, ничего вот этого вот, а только одни ожидания, что гибкость позволит взять от вас больше — тут и начинается адуха. То есть, буквально, вы работаете в тех же условиях, что и раньше, но ждут от вас больше.
Почему в данном случае я скепсисирую в отношении идеи, а не реализации — вспомним «от каждого — по возможностям, каждому — по потребностям». Эта прекрасная идея декларировалась реально и реально же не работала, потому что работать НЕ МОГЛА. Не учитывала обстоятельства реального мира.
By the way, все мои ответы будут непридуманными, это реальный опыт.
А вы как считаете за счет чего мы должны работать быстрее?
Надо просто лучше и больше работать, а не играть два раза в день по десять минут в пинг-понг и не читать статьи на Хабре после обеда.
Я совершенно за простоту как и вы
Тогда почему вы постоянно ноете про этот ваш «технологический долг»? Не нужна эта ваша красота архитектуры, нужно быстро!
В этом мы на одной волне
Ну так пишите же комментарии! Только не надо на это полдня тратить, мы не комментарии продаем!
Давайте потом подумаем, как сделать чтобы их было поменьше
Не потом, а сию секунду! Иначе я позвоню Самому Главному, и он вам объяснит, кому куда идти. Удовлетворенность клиентов на первом месте!
Потом прислать письмо с кратким описанием откуда возникли баги
Мне это нафиг неинтересно, откуда они возникли (хотя я и делаю вид, что интересно), просто скажите, кто виноват.
Далее не от имени начальника.
По моему опыту это не только декларируется
Само собой, это то, что реально необходимо любому руководителю, реально необходимо. Но когда следом за вопросом «когда по вашему мнению это возможно» следуют слова «нет, это нужно раньше и имеющимися ресурсами», а потом еще оказывается, что имелось в виду значительно больше результатов и никто не брал в расчет, что появятся новые и новые проекты, то это уже не «запрос на предсказуемость».
Еще заметьте что аджайл совершенно выпал из этого диалога — он просто не является фактором тут. Основные проблемы тут отношение к разработчикам, планирование и качество. Эти проблемы можно решать, хоть в аджайле, хоть в водопаде только разными средствами и в соответствующих книжках описано какими.
Так конечно же! Большинство виденных мной начальников транслируют запрос бизнеса, а запрос рашен бизнеса известно какой. Как следствие — все перечисленные проблемы. И любая из гибких методик оказывается плоха именно тем, что по общему безусловному убеждению она способствует безусловному увеличению эффективности. И вот когда, например, скрам, начинает натягиваться на имеющуюся реальность, где у вас не будет ни защиты от прессинга, ни скрам-мастера, ни вменяемой системы формирования требований, ни свободной работы с бэклогом, ничего вот этого вот, а только одни ожидания, что гибкость позволит взять от вас больше — тут и начинается адуха. То есть, буквально, вы работаете в тех же условиях, что и раньше, но ждут от вас больше.
Почему в данном случае я скепсисирую в отношении идеи, а не реализации — вспомним «от каждого — по возможностям, каждому — по потребностям». Эта прекрасная идея декларировалась реально и реально же не работала, потому что работать НЕ МОГЛА. Не учитывала обстоятельства реального мира.
где у вас не будет ни защиты от прессинга, ни скрам-мастера, ни вменяемой системы формирования требований, ни свободной работы с бэклогом, ничего вот этого вот, а только одни ожидания, что гибкость позволит взять от вас больше
Так, а причем здесь скрам?
У кого-то неправильные ожидания от… (неважно от чего). И этот кто-то потом с удивлением обнаруживает, что его ожидания от… не оправдываются.
Скрам, в целом довольно прагматичен. С одной стороны, есть команда, у которой известна средняя производительность, и как следствие известно какие плюшки получит бизнес через итерацию, больше не накидаешь даже если сильно надо. С другой, команда подписывается под скоуп плюшек, и старается обещание выполнить. Дальше, ежедневно отслеживается прогресс (на тех самых митингах). Т.е. той гибкости как возможно многие ожидают, конкретно в этом аспекте в скраме ее нет — запланировали, подписались под план, пашем, контролируем исполнение, сдаемся, рефлексируем.
И скрам никак не решает проблему защиты от прессинга.
Скрам никак не решает проблему управления требованиями.
Не решает и кучу всего того, что чаще всего мешает деятельности ИТ в частности, и предприятия в целом.
Так, а причем здесь скрам?
Совершенно, верно! Сам по себе скрам как бы не виноват, но…
Вот почему не удалась на практике идея «от каждого — по возможностям, каждому — по потребностям»? Да потому, что она физическому миру, психологии людей и структуре экономики по крайней мере на тот момент противоречила. И я склонен считать, что проблема не в реальном мире, а в этой самой идее и\или ее сторонниках.
То есть разработчикам и принципа Agile в общем и отдельных методологий в частности стоило сказать явно — сей метод заведомо НЕ работает там-то и там-то. Согласен с тем, что известный манифест например не содержит указаний на то, что это работает везде, но и не оговаривает ограничения. А стоило бы.
Манифест это просто набор целей, а не конкретный процесс. Но в разных источниках есть про ограничения.
Вот я поискал.
- https://en.wikipedia.org/wiki/Scrum_(software_development)#Limitations
- Открываете SCRUM GUIDE, ищете слово must
- У Алистера Коберна (автора Crystal) в книжке полно рассуждений что когда работает и для чего предназначено.
Еще есть agile fluency model ( https://martinfowler.com/articles/agileFluency.html )
т.е. тот, кто захочет, может найти информацию, как помешать называть аджайлом или там скрамом ктому-то все, что угодно я не знаю.
Ну что тут сделаешь, философский дуализм…
Наши слабости проистекают из наших сильных сторон.
Из рисков возникают возможности.
Да, краеугольный камень всех agile-практик — рефлексирующий саморазвивающийся человек.
Наши слабости проистекают из наших сильных сторон.
Из рисков возникают возможности.
Да, краеугольный камень всех agile-практик — рефлексирующий саморазвивающийся человек.
Надо просто лучше и больше работать, а не играть два раза в день по десять минут в пинг-понг и не читать статьи на Хабре после обеда.
Хорошо, мы я постараюсь чтобы в рабочее время больше этого не было.
Тогда почему вы постоянно ноете про этот ваш «технологический долг»?
Чтобы сделать проще надо подумать. Технический долг это как раз когда делают слишком сложно из-за спешки.
Не потом, а сию секунду! Иначе я позвоню Самому Главному, и он вам объяснит, кому куда идти. Удовлетворенность клиентов на первом месте!
Конечно, я это и имел ввиду. Сейчас исправим, потом подумаем, как сделать чтобы больше не повторялось. (Прекратить разговор до следующего удобного случая чтобы не передавить)
Мне это нафиг неинтересно, откуда они возникли (хотя я и делаю вид, что интересно), просто скажите, кто виноват.
Это очень странно, что человеку неинтересно откуда возникли проблемы, если они есть. Как вы убедились, что он только делает вид?
никто не брал в расчет, что появятся новые и новые проекты, то это уже не «запрос на предсказуемость».
Это означает, что либо данный уровень качества на самом деле всех устраивает либо люди не понимают что они за баги платят больше, либо происходит явный обман клиента, когда сознательно обещают намного больше чем надо сделать. Надо разобраться какой именно вариант в конкретном случае.
Большинство виденных мной начальников транслируют запрос бизнеса, а запрос рашен бизнеса известно какой.
По-моему, что с товарами, что с услугами часто следующий сценарий — сначала люди выбирают подешевле, потом понимают, что они уже выбросили три самых дешевых чайника и покупают один подороже и смотрят отзывы. Для меня странно, что современный русский бизнес в массе работает как-то по другому. Причем, я работал в русских компаниях внутри и вижу изменения как пользователь снаружи — качество практически всего растет, включая госуслуги.
Кроме нескольких проколов люди достаточно адекватно оценивали сроки и делали запасы. И обращались к техническим специалистам при планировании.
одни ожидания, что гибкость позволит взять от вас больше — тут и начинается адуха.
Начальник которого вы сэмулировали никак не аппелировал к тому, что в аджайле так или нет так.
Гибкость позволяет больше взять за счет того, что результат именно тот, что нужен. Т.е. это последствие выбора того, кто руководит процессом. Если он выбирает скорость каждой конкретной итерации, то он это получит. Если он выбирает качество то, он это получит.
Я думаю, описанный вами начальник сможет создать давление вполне и без скрама и получить то же самое.
Я думаю, описанный вами начальник сможет создать давление вполне и без скрама и получить то же самое.
Извините, что я отвечу только на эту часть вашего сообщения, но просто все здесь вертится вокруг именно вот этого вот — да, конечно, дело не в agile/scrum, а в условном нехорошем начальнике, который и так уже всех загнал в отказ от самого необходимого, а теперь решил «дожать» еще и за счет «гибкости».
Тут два варианта. Или это все самому ему объективно нужно (например, он сам знает что пообещал сделать быстрее чем может и понял, что ошибся в оценке и ему надо свалить вину на кого-то) или он искренне не понимает как это все работает и в его сознании отсутствие необходимого не связано с багами, которые вдобавок дополнительно замедляют.
Что тут может сделать разработчик?
Самому разобраться как это должно работать, разобраться к какому варианту относится ситуация и показать или начальнику или начальнику начальника или коллегам что в результате все проигрывают. Начальники не вечны и один из коллег вполне может быть следующим начальником.
Уволиться (при поиске работы может пригодиться знание что такое аджайл и за счет чего он работает — т.е. он сможет по беседе понять какие части пропущены и с чем могут быть проблемы). Еще вся эта система держится на том, что по какой-то причине разработчики не уходят — или не уважают себя или просто безинициативны. Станьте круче, учитесь себя продавать, найдите более широкий рынок (как у вас с английским, например).
Ныть на форуме
Я думаю, если разработчик хочет улучшить свою жизнь, а не просто выпустить пар и продолжить в том же духе, первые два пути более перспективны.
So, when would I not want to do Scrum?
I gave two examples.
- If two people on the 7 person Team say “I hate Scrum”, then I probably would not do Scrum with that Team. Almost surely they will make it fail. Maybe you would do waterfall instead. (I might fire myself, though, and get myself on another Team.)
- If they give you an impossible project (say 18 months of work that must be done in 12 months), and if you don’t succeed they will fire you — then, I recommend waterfall.
Management won’t really know how the (waterfall) project is doing. Just say: Green. You will have plenty of time to work on your resume, post it on Monster.com (or CareerBuilder), have some interviews, and get a new job. It is important that you protect yourself and your family from these jerks (or this situation). (Firing someone for not accomplishing the impossible is being a jerk.)
Some people laugh when I describe that situation, but seriously, you have to protect yourself. As you are leaving, wave goodbye and tell them the project is RED.
Откуда цитата? Отлично сказано!
Здесь оригинал: www.leanagiletraining.com/better-agile/when-should-you-not-use-scrum?
Здесь оригинал: www.leanagiletraining.com/better-agile/when-should-you-not-use-scrum?
например, он сам знает что пообещал сделать быстрее чем может и понял, что ошибся в оценке и ему надо свалить вину на кого-то
Ну, вообще говоря он необязательно кого-то винит, но суть в том, что, да, для рашен бизнеса в особенности характерно мечтать всех обмануть и родить ребенка за месяц (но усилиями не девяти женщин, а, например, трех). И не те самые «плохие менеджеры» стоят во главе этой идеологии, отнюдь.
Ныть на форуме
Вот уж не думал, что вы мою писанину воспринимаете как нытье… Лучше тогда прекратить это обсуждение.
Ну, вообще говоря он необязательно кого-то винит, но суть в том, что, да, для рашен бизнеса в особенности характерно мечтать всех обмануть и родить ребенка за месяц (но усилиями не девяти женщин, а, например, трех). И не те самые «плохие менеджеры» стоят во главе этой идеологии, отнюдь.
С моей точки зрения это не так. См пример про чайники.
Вот уж не думал, что вы мою писанину воспринимаете как нытье…
Я про тех кто пишет даже не попытавшись разобраться. С того, про что начался разговор.
С моей точки зрения это не так
Думаю вам сильно повезло.
На философском уровне я это так понимаю — рашен бизнес в среднем не живет насколько долго, чтобы осознать вред «быстрых и дешевых» решений. По ощущениям для бизнеса, связанного с реальным производством (т.е. не чистая разработка ПО) этот срок составляет не менее четверти века — большинство российских предприятий в принципе этот срок не прошло.
Во всём этом прекрасном agile вижу следующие неприятные моменты (что, впрочем, никак не мешает самому работать в этом стиле):
1. Разгоняет безумный улучшайзинг ради улучшайзинга. Не, ну в самом деле, господа, нам реально нужны эти безумные апдейты всего на свете раз в неделю? Если хотя бы раз в месяц порядок кнопочек на панельке не поменяется, у нас что, ломка начинается? Мне как потребителю (даже когда мы сами производители, мы всё равно в отношении остальных 99.999% IT мы потребители) весь этот долбаный улучшайзинг больше мешает, чем помогает. Зачем всё это? Не понимаю. Иррациональные объяснения есть (прогресс, развитие, бла-бла-бла), а рациональных на ломаный грош.
2. Качество. Agile прекрасен в сфере услуг, но для производства массового продукта он не годится совсем. Проиллюстрирую аналогией. Если, допустим, автопроизводитель решает изменить, например, конструкцию крепления глушителя, то подойдёт к этому вопросу капец как серьёзно. Сопромат и материаловедение по полной программе. Испытание опытных образцов в разных режимах — на экстремально низких и высоких температурах, вибрация, загрязнения, агрессивные среды и т.д. и т.п. Никакого «в релиз через неделю» там нет и быть не может. Иначе отзыв ста тысяч изделий, мало не покажется никому. В сфере услуг подход принципиально другой: «Петрович, возьми там из ящика какой-нибудь хомутик и привари чтобы не болталось». Вот он agile в его естественной среде обитания. А чё? Дёшево и сердито, и клиент получил ту фичу, которую хотел.
С массовым внедрением agile в продуктовое производство мы неизбежно приходим к тому, что у нас всё становится похожим на самоделку из гаража Петровича. Всё безобразие, конечно, убрано за пластиковую панельку, но менее безобразным оно от этого не становится.
Давайте договоримся так. Если наша деятельность — удовлетворение конкретного заказчика, то врубаем agile на полную катушку и радуем клиента быстрым удовлетворением любого каприза. И релизы хоть два раза в день, почему бы и нет. Но если создаём продукт, то любое поползновение в сторону agile приравниваем к саботажу и караем по законам военного времени.
1. Разгоняет безумный улучшайзинг ради улучшайзинга. Не, ну в самом деле, господа, нам реально нужны эти безумные апдейты всего на свете раз в неделю? Если хотя бы раз в месяц порядок кнопочек на панельке не поменяется, у нас что, ломка начинается? Мне как потребителю (даже когда мы сами производители, мы всё равно в отношении остальных 99.999% IT мы потребители) весь этот долбаный улучшайзинг больше мешает, чем помогает. Зачем всё это? Не понимаю. Иррациональные объяснения есть (прогресс, развитие, бла-бла-бла), а рациональных на ломаный грош.
2. Качество. Agile прекрасен в сфере услуг, но для производства массового продукта он не годится совсем. Проиллюстрирую аналогией. Если, допустим, автопроизводитель решает изменить, например, конструкцию крепления глушителя, то подойдёт к этому вопросу капец как серьёзно. Сопромат и материаловедение по полной программе. Испытание опытных образцов в разных режимах — на экстремально низких и высоких температурах, вибрация, загрязнения, агрессивные среды и т.д. и т.п. Никакого «в релиз через неделю» там нет и быть не может. Иначе отзыв ста тысяч изделий, мало не покажется никому. В сфере услуг подход принципиально другой: «Петрович, возьми там из ящика какой-нибудь хомутик и привари чтобы не болталось». Вот он agile в его естественной среде обитания. А чё? Дёшево и сердито, и клиент получил ту фичу, которую хотел.
С массовым внедрением agile в продуктовое производство мы неизбежно приходим к тому, что у нас всё становится похожим на самоделку из гаража Петровича. Всё безобразие, конечно, убрано за пластиковую панельку, но менее безобразным оно от этого не становится.
Давайте договоримся так. Если наша деятельность — удовлетворение конкретного заказчика, то врубаем agile на полную катушку и радуем клиента быстрым удовлетворением любого каприза. И релизы хоть два раза в день, почему бы и нет. Но если создаём продукт, то любое поползновение в сторону agile приравниваем к саботажу и караем по законам военного времени.
Иначе отзыв ста тысяч изделийПо $10000 каждое, цена ошибки — 1 миллиард.
Разгоняет безумный улучшайзинг ради улучшайзинга
Так это нынче основной драйвер индустрий, и не первое десятилетие уже.
С массовым внедрением agile в продуктовое производство мы неизбежно приходим к тому, что у нас всё становится похожим на самоделку из гаража Петровича
Воооот, а об этом пишут непозволительно мало. Рискну сказать, что на Хабре впервые вижу эту мысль в такой прямой форме.
А теперь внимание — это уже так и есть.
В недавней статье про Гугл говорилось, что улучшайзеры продвигаются по службе, а радетели за хороший код в аутсайдерах, потому что «ничего полезного не делают».
С вашим комментарием полностью солидарен
С вашим комментарием полностью солидарен
1. Разгоняет безумный улучшайзинг ради улучшайзинга. Не, ну в самом деле, господа, нам реально нужны эти безумные апдейты всего на свете раз в неделю? Если хотя бы раз в месяц порядок кнопочек на панельке не поменяется, у нас что, ломка начинается? Мне как потребителю (даже когда мы сами производители, мы всё равно в отношении остальных 99.999% IT мы потребители) весь этот долбаный улучшайзинг больше мешает, чем помогает. Зачем всё это? Не понимаю. Иррациональные объяснения есть (прогресс, развитие, бла-бла-бла), а рациональных на ломаный грош.
Это со стороны выглядит как улучшайзинг.
При правильном процессе — изменение цвета кнопочек и их расположение (а также любой прочий «улучшайзинг» — что-то реально полезное) оказывает влияние на… (и тут что-нибудь, что является нашей целью, какаю-нибудь конверсия, длительность сессии и т.д.)
Часто это иррационально, и суровых ИТников с детерминированным миром вводит в ступор, но это работает.
Это не означает, что в принципе улучшайзинг отсутствует как класс. Люди разные, каждый зарабатывает как может, кто-то на улучшайзинге.
Качество. Agile прекрасен в сфере услуг, но для производства массового продукта он не годится совсем. Проиллюстрирую аналогией. Если, допустим, автопроизводитель решает изменить, например, конструкцию крепления глушителя, то подойдёт к этому вопросу капец как серьёзно. Сопромат и материаловедение по полной программе. Испытание опытных образцов в разных режимах — на экстремально низких и высоких температурах, вибрация, загрязнения, агрессивные среды и т.д. и т.п. Никакого «в релиз через неделю» там нет и быть не может. Иначе отзыв ста тысяч изделий, мало не покажется никому. В сфере услуг подход принципиально другой: «Петрович, возьми там из ящика какой-нибудь хомутик и привари чтобы не болталось». Вот он agile в его естественной среде обитания. А чё? Дёшево и сердито, и клиент получил ту фичу, которую хотел.
Никто никогда и не утверждал, что agile-подходы работают всегда и везде. Да, есть куча областей деятельности, где agile применять не стоит. Даже если речь про ИТ. Разве кто-то утверждает что тесты нужно писать абсолютно на любой код? Разве кто-то утверждает что деплой абсолютно всегда должен выполняться только автоматизированными инструментами? И уже тем более, про мир реальных вещей. Сложно представить себе стройку работающую спринтами, или клинику, работающую спринтами, или заведение общепита, работающаее спринтами. И тем не менее, все это не означает, что разработка конкретного продукта, основанного на ИТ, не может вестить очень эффективно с помощью agile.
Давайте договоримся так. Если наша деятельность — удовлетворение конкретного заказчика, то врубаем agile на полную катушку и радуем клиента быстрым удовлетворением любого каприза. И релизы хоть два раза в день, почему бы и нет. Но если создаём продукт, то любое поползновение в сторону agile приравниваем к саботажу и караем по законам военного времени.
Продукты бывают разные.
Соответственно и способы их создания и доведения до блестящего состояния — тоже разные.
Где-то здесь, в похожей теме я приводил пример. Представьте, вы работаете в крупном банке. Принято решение создать мобильное приложение для мелких предпринимателей. Ни у вас, ни у ваших коллеги в принципе нет понимания, что реально болит у мелких предпринимателей, потому ни вы, ни ваши коллеги не были мелкими предпринимателями. Какие проблемы должно решать мобильное приложение? Что действительно важно, а чем можно пренебречь? Слабо себе предствляю, как можно создать реально работающее полезное приложение с активными пользователями, без гипотез, их быстрой проверки, и затем отбразывания или дальнейшего улучшения, и прочих штук типа a/b, a/z, etc.
… что-нибудь, что является нашей целью, какаю-нибудь конверсия, длительность сессии и т.д.Есть проги, которыми раньше с удовольствием пользовался (и меня в них устраивало абсолютно всё), снёс нахрен потому, что в результате улучшайзинга они превратились в отвратительных тормозных прожорливых неудобных монстров.
Допустим, у меня есть потребность в некой функциональности, которая подразумевает фичи А, Б, В, Г и Д. Из них А и Б обязательны, а остальные опциональны. Нахожу прогу, в которой есть А, Б и В. Отсутствие Г и Д меня если и колебает, то не сильно. Быстро приучаюсь обходиться без них. Первый апдейт добавляет Г. Вау! Молодцы! Второй — Д. Вообще круто. Третий добавляет Е. Так, стоп. Мне это было не нужно. Ну ладно, уговариваю себя умерить свой эгоцентризм и допускаю, что есть те, кому это нужно позарез. Но прогресс нельзя остановить (это запрещено!!!), и фичи начинают высасываться из пальца. Когда дело доходит до У, Ф и Х, фичи А и Б перестают нормально работать. Под снос. Притом, что интересно, если бы прогресс остановился на самом первом релизе, я был бы в выигрыше относительно того, что получилось в итоге.
Кстати сказать, в программке Word со времён офиса-98 появилась куча всего, а маленькой ненапряжной безделицы, без которой действительно всё время грустно, не появилось. Ну, это так, к слову.
Представьте, вы работаете в крупном банке. Принято решение создать мобильное приложение для мелких предпринимателей.Плохой пример. Если нет понимания того, что нужно людям, выпускать абы что и смотреть реакцию — только терять лицо. Использование массового пользователя в качестве подопытного животного — редкостное свинство, которое матушкой-эволюцией жёстко наказывается.
Использование agile в разработке продукта мягко но настойчиво подталкивает и к улучшайзингу ради улучшайзинга, и к опытам над пользователями. Если раз в неделю релизится новая версия продукта, то почему бы не пошалить? А теперь представьте себе, что релизы — раз в два года. И пипец, крутитесь как хотите. Что недодумали, где косякнули, где недотестили — не беда, через два года новым релизом всё исправите.
Концепция бесконечного неостановимого прогресса рассматривает потребителя как ненасытное чудовище, алчущее новых фишек. Но это, прямо скажем, очень далеко от реального положения дел. В подавляющем своём большинстве люди живут своими жизнями, решают свои задачи, борятся со своими проблемами. Эти задачи и проблемы не имеют никакого отношения ко всему этому улучшайзингу. Если у кого-то депрессия, ей не поможет смена объёмного дизайна на плоский. Если кто-то повздорил с соседом, ему не поможет замена звёздочки на сердечко. Реальная человеческая жизнь и весь этот псевдопрогресс существуют как будто в параллельных вселенных. Когда псевдопрогресс не мешает жить, то и фиг с ним (пусть мальчики и девочки развлекаются), но так бывает, к сожалению, редко.
Все верно.
Если бы вы были единственным клиентом, то только к вашему мнению нужно было бы прислушиваться.
Обычно, клиентов не один, а несколько, и поэтому чуваку, отвечающему за продукт приходится прислушиваться к мнению нескольких, плюс смотреть что у конкурентов, плюс следить за изменением среды (новые законы), плюс слушать владельцев бизнеса, и в итоге принимать решение по продукту. Т.к. владелец продукта обычно не глубоко делится с пользователями причинами изменения в продукте, то его пользователю иногда кажется странным последние изменения в продукте, может даже сложиться впечатление о диверсии.
Это просто бизнес.
Да, есть риск потерять лицо (время, деньги, и т.д). И нужно с этим риском что-то делать.
Кто-то скажет, риск критичный, ничего с ним сделать не можем, и остановится.
Кто-то — определится с подходами по минимизации риска, и стартанет.
Кто из них окажется прав — покажет время.
Если бы вы были единственным клиентом, то только к вашему мнению нужно было бы прислушиваться.
Обычно, клиентов не один, а несколько, и поэтому чуваку, отвечающему за продукт приходится прислушиваться к мнению нескольких, плюс смотреть что у конкурентов, плюс следить за изменением среды (новые законы), плюс слушать владельцев бизнеса, и в итоге принимать решение по продукту. Т.к. владелец продукта обычно не глубоко делится с пользователями причинами изменения в продукте, то его пользователю иногда кажется странным последние изменения в продукте, может даже сложиться впечатление о диверсии.
Плохой пример. Если нет понимания того, что нужно людям, выпускать абы что и смотреть реакцию — только терять лицо. Использование массового пользователя в качестве подопытного животного — редкостное свинство, которое матушкой-эволюцией жёстко наказывается.
Это просто бизнес.
Да, есть риск потерять лицо (время, деньги, и т.д). И нужно с этим риском что-то делать.
Кто-то скажет, риск критичный, ничего с ним сделать не можем, и остановится.
Кто-то — определится с подходами по минимизации риска, и стартанет.
Кто из них окажется прав — покажет время.
maslyaev, правильно говорите про прогресс. в моей отрасли (voip) я четко вижу, что прогресс теперь не такой, каким был прежде. сейчас прогресс двигается в сторону удешевления (я двигаю). при наличии массы конкурентов и массы уже готовых продуктов сейчас очень просто заниматься reverse engineering и делать лучший продукт меньшими усилиями, меньшей командой, и, соответственно, дешевле.
кто-нибудь может прокомментировать? что там в других отраслях?
кто-нибудь может прокомментировать? что там в других отраслях?
В моей области (всякий бизнес-софт) прогресс волнами. Лично пронаблюдал пару десятилетий, но, судя по всему, история значительно длиннее. Типичный сценарий: появляется новый продукт — компактный, шустрый, удобный, дешёвый. Потом начинает пухнуть, потом на фазе «ща забацаем полноценное ERP масштаба крупной корпорации» или дохнет, или превращается в чудовище, которым пугают детей и которое в равной степени люто ненавидят и пользователи, и внедренцы. Сейчас в эту печальную фазу входит 1С. Печалька.
Представьте, вы работаете в крупном банке. Принято решение создать мобильное приложение для мелких предпринимателей.
Блестящий пример. Только пусть это будет Росевробанк и не приложение для пбоюлов, а интернет-офис. Пока они на мне экспериментировали методами Эджайла, я просто решился наконец уйти из этого банка — не только конечно из-за интернет-офиса, но это тоже было каплей. Банк продолжал чахнуть и недавно решил лечь под Совкомбанк. Не потому ли, что в том банке вообще ВСЕ состояло из гаражных поделок?
Но если создаём продукт, то любое поползновение в сторону agile приравниваем к саботажу и караем по законам военного времени.
Я думаю, для начала надо расстрелять покупателей. А то, ишь, не хотят платить за списки дел, разработанные по нормам для создания автомобилей и по такой же цене!
Естественно, гибкие команды не имеют постоянного костяка, они могут быть в любой момент расформированы, преобразованы. Некому быть второй стороной осмысленного диалога с работодателем.Как правило Agile команда цельная и не только она решает кого нужно добавить кого убрать.
Что нового я привношу своей работой, если смотреть глазами нашего общего коллективного потребителя, человечества в целом? – Да практически ничего.Вы сами ниже пишите про open-source, то что компании не делятся своим кодом, это не проблема Agile.
Мы просто нагреваем воздух, чтобы один производитель на какое-то короткое время вышел вперёд в конкурентной борьбе с другим производителем.
Мы можем переиспользовать результаты работы только в рамках одного экономического агента, в данном случае коммерческой компании.
И даже когда мы выкладываем свои типовые решение в open-source, это не останавливает рост трудозатрат в IT-отрасли:Ну ок, давайте писать все на VBS, нафиг все остальное.
есть ещё вендоры, создатели новых, ещё чуть более усовершенствованных технологий, языков, фреймворков,
которые требуют постоянного переобучения и разработки нового кода, новых прикладных решений.
Настоящий прорыв будет состоять в правильной постановке задач, когда производственный процесс будет подчинён лишь одному: удовлетворению потребностей.Product Owner — выполняет эту функцию. И это должен быть человек который разбирается в бизнесе,
как со стороны того как продукт приносит денег, так и со стороны чего хочет большинство пользователей его продукта.
… как из всего зоопарка имеющихся технологий выбрать наиболее удачные...Что-то эволюция за 3.5 млрд. лет не выбрала наиболее удачный вариант.
Да, есть лидирующий (в нашем понимании) «продукт», но не единственный)
Ну или возвращаемся к VBS
с общественной точки зрения гораздо выгоднее и разумнее произвести один раз хороший продукт, чем производить 20 продуктов,Что есть хороший продукт? Для Васи это одно для Пети другое.
каждый из которых ещё нужно постоянно доводить до ума.
Телефоны как раз сейчас клепают один на другой похожие, нет разнообразия.
… Однако нам не нужно для этого вставать на линейку в 10 утра и рассказывать другим, что мы сделали вчера.Ну почему же есть люди которые воспринимают стендапы как встречи для докладов и отчетности(
Нашим надсмотрщиком является только наше желание сделать мир лучше.
Это в первую очередь встреча команды, для понимания кто какой задачей занимается и нужна ли ему помощь от коллег.
Agile и Scrum нужно уметь подавать, его нельзя директивно навязывать, люди должны сами хотеть трансформации.
Что-то эволюция за 3.5 млрд. лет не выбрала наиболее удачный вариант. — но ведь у людей практически идентичные глаза, уши, нервная система, сердце и всё остальное.
Вы, как и некоторые другие выше, поняли текст так, что при капитализме отменить agile. Мол, что же тогда делать с рыночными требованиями. Я же писал с позиции более абстрактной: что будет с agile, когда капитализм кончится
Вы, как и некоторые другие выше, поняли текст так, что при капитализме отменить agile. Мол, что же тогда делать с рыночными требованиями. Я же писал с позиции более абстрактной: что будет с agile, когда капитализм кончится
но ведь у людей практически идентичные глаза, уши, нервная система, сердце и всё остальное.
совсем не факт. только с виду похожие, но стратегии поведения у всех разнообразные. что там с нервной системой — не понятно, никто не понимает, как точно она работает. не понимая работу нервной системы, нельзя утверждать о том, что она «практически идентичная»
если в первый раз в жизни послушать какой-либо новый жанр музыки — все композиции будут казаться «практически идентичными»
Максим, на ваш взгляд, что пошло не так в Советском Союзе? И как этого избежать обществам будущего в процессе самоусовершенствования?
Sign up to leave a comment.
Почему в будущем Agile станет не нужен