Кто нибудь понимает нафиг это надо и реально использует?

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

Как я понимаю знание этих методик обязательно для прожект-менеджмента и тим-лидера.

Для этого вам нужно «забить голову» еще многим чем, а главное быть супер популистом /и это не ирония/.

это не гуманитарный булшит, а реальное нужные вещи. Учи, разбирайся.

Или чем груминг беклога отличается от обзора итогов спринта?

Я разработчик, а не експерт аджайла, но то о чем ты говоришь вроде вообще разные вещи

обзор итогов ( ретроспектива?) это когда обсуждают какие проблемы были, и как с ними не сталкиваться в будущем

груминг это проработка беклога на будущее (в моей маленькой команде было часто что некоторые таски становились не актуальными из-за других сделанных тасок, по этому время от времени пересматривали беклог и удаляли мусор)

Могу понять, за что сабж любят менеджера-недоучки. Но, что удивляет, находятся и девелоперы, которым по нраву все эти стендапы, груминги, ретроспективы, говноспективы… Сами надеются выбиться в менеджера? Или неумение работать заменяют умением производить впечатление на менеджеров? Или просто стокгольмский синдром? Или это такой сабмиссивный тип личности - хочется кому-то подчиняться и не думать?

А вот еще. «Скрам — это фреймворк, который помогает организовать работу в духе Аджайла.»

Что в такое данном случае «фреймворк»? Как сформулировать в более простых понятиях?

Все эти методологии, не решение а просто набор рекомендаций, как вроде бы можно сделать, так чтобы было хорошо, это значит что если компании А и Б обе используют одну и туже методологию, то они могут делать совершенно разные вещи, всё это гумно скармливается под соусом решения всех проблем, эдакая волшебная «пилюля». На практике получается цирк и вакхналия, потому что любая имплементация в реальной жизни требует от каждого понимания ролей, процессов и выполнения их. Дальше больше, каждые N лет, появляется новая методология, которую сейчас внедрим и все проблемы сразу уйдут, документация напишется, а задачи будут выполнены в срок, началась вся эта свистопляска с ITIL (кстати как по мне вполне здравая модель), но она довольно сложная, есть уровни сертификации и тд, к ней и тулзов дохера, но она совсем не подходит для небольших стартапов, верней она подходит только зрелым компаниям. Но её минус в том что она практикует узкую специализацию, что не выгодно, тут на сцену вышел Аджайл, где все делают все, и тут всё завертелось…

Теперь ближе к твоим вопросам, всё везде одно и тоже но имена меняются, везде есть животный ресурс, который собсно оказывает сервис ( не важно разработка или поддержка ), есть какойто трекер инцидентов/багрепортов/фичреквестов (канбан и пр. зоопарк ITSM), и циклы итерации (тут есть хоть какието различия, гдето четко опредлены сроки - спринты, где то по количеству багов/фич и тд) вот и вся любовь. Хз насколько этот поток сознания получился внятным

кому-то подчиняться и не думать?

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

Ага, и менеджеров в скраме нет - все делают, что хотят, и никто не указывает.

А ещё там есть скрам мастера, а лучше сразу два на комманду в 5 человек

И шоколадные конфеты бесплатно раздают.

Отвечаю. В Скраме нет анархии. Вместе с Командой работает Владелец Продукта — это человек, который знает, что хотят видеть клиенты, и делится видением с остальными. Он не указывает сотрудникам, но приоритизирует задачи перед стартом работы и помогает в процессе.

Да просто слово такое, что-то типа «подтип». Их не так много, scrum, kanban, scrumban, эти распространненые, scrum of scrums и прочее - редкие.

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

Почему менеджера такие тупые? Это не вопрос.

Может объяснить, в чем разница между скрам-мастером и аджайл-коучем?

Отвечаю. В Скраме нет анархии.

Не спорь с анонимусом, он мамкин 13 летний программист, «Уф, эти менеджеры лезут в мой уютный мир говнокодинга со своими умными американскими словами и каким-то тма бизнес требованиями»

А почему программисты такие умные, но не могут жить без менеджеров?

А почему программисты такие умные, но не могут жить без менеджеров?

Могут, но не все.

Может объяснить, в чем разница между скрам-мастером и аджайл-коучем?

Я могу, скрам-мастер что-то среднее между менеджером и СТО. Ходит устраняет конфликты между командами, отвечает за скрам процессы и так далее. Работает постоянно.

Коуч просто внешний хелпер, он посмотрим как у вас все идет, даст советы и уйдет

Колхозный Фронтенд

Никакой, разве что исповедуют разные метолодологии. Они пророки, проходящие в команду и ведующие паству в светлое будующее, назначая встречи (чаще всего рандомно, не учитывая время обеда, разницу во времени, если команда распределенная) и типа трекающими прогрес (тут обычно сильно лажают, т.к. нихера не понимают и не могут оценить трудозатраты и помочь начинающим с правильной оценкой этих трудозатрат), в классической офисной терминологии ближе всего к Project Manager’ам, но ток баблом рулить им не доверяют, да и они сами обычно считают себя выше этого всего, ведь команда это всё…

Как я понимаю знание этих методик обязательно для прожект-менеджмента и тим-лидера.

Может помочь. Но только все эти волшебные методики не будут тимлидить и прожектменеджить за тебя. Знание их может тебе помочь понять что вообще работает а что нет, но дальше все зависит только от тебя. Это как инструкции по тантрическому сексу. Знать не вредно, но опыта не заменяет.

в IBM есть ещё Аджайл чемпионы

Потому что ты трогаешь себя ночью?

В нашей фирме нет менеджеров, лол. Один директор, он же владелец, он же уборщица + один дизайнер + восемь разработчиков. Наверно, что-то делаем не так.

Линус Торвалдс это менеджер?

Это не тот ресурс, где такие вопросы надо обсуждать :)
Даже по коментам в этой теме видно, что примерно хотя бы понимает вопрос максимум один человек, а другие даже представления не имеют об этих процессах.

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

Если тебе действительно интересна тема, то сейчас очень много всякой литературы, где описаны разные методики agile, почитай и сам поймешь надо ли тебе это и что конкретно может пригодиться.

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

В Скраме сотрудники не руководят друг другом, а работают сообща.

Скрамота !

Это не тот ресурс, где такие вопросы надо обсуждать :)

Да тут все эксперты по любым вопросам, особенно в Девелопмент. Многие работают программистами в продакшене, уровень экспертизы 8 из 10.

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

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

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

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

Что мешает освоить методики сначала и даже пройти сертификацию?

Слишком высокий IQ?

Ну сертификацию-то ты пройдёшь, а умище-то куда девать?

А зачем? Тебе это ничего не даст. Если у тебя нет опыта менеджмента, это будет видно сразу, сколько там методик не изучай.

Есть разница когда на собеседовании будешь рассказывать, что я изучала в университе «управление проектами» или у тебя уже есть сертификат аджайл-коуча?

Зависит от того кто будет тебя собеседовать, твоя задача не прийти в команду, открыв дверь с ноги и сказав «Всё фигня, ща я вас научу как надо правильно делать продукт, который вы тут с божьей помощью последние 5 лет пилити», тебе надо будет «оптимизировать» уже существующие процессы внутри команды, ВОЗМОЖНО, используя некоторые рекомендации, из Scrum или Agile, а для этого зания методологий маловато, посему их знание это скорее плюс поверх уже имеющегося опыта управления командой. Нашел хороший пример, когдато в начале карьеры, я работал в Магните, системотехником, у них прям всё четенько, выверенные методологии на каждый чих, всё оптимизировано до безумия, и каждый магазин это классическая команда, с двумя мастерами Директором и Товароведом, которым на специальных тренингах, очно, раскзаали все тонкости этой методологии, и в контексте того что всех максимально натаскивают на одно и тоже, далеко не все магазины Магнит работают одинавоко эффективно.

коучи ходят не на собеседования, а на переговоры

для начала выучи это

Это не сразу. Но думаю, что надо устроиться куда-нибудь чашки мытьстаршей помошницей зам. младшего пм. К окончанию уже опыт будет. Программировать мне не нравится, примитивная работа.

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

Так толсто, что даже тонко.

у них прям всё четенько, выверенные методологии на каждый чих, всё оптимизировано до безумия

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

старшей помошницей зам. младшего пм.

А такое вообще бывает? Я не часто вижу вакансии на junior PM.

Я думал туда попадают по какой-то из цепочек

dev -> lead -> pm

junior hr -> hr -> head of hr -> pm

qa -> pm

Линус Торвалдс это менеджер?

Скорее техлид. Он не решает задачи человеческих и вычислительных ресурсов, не занимается коммуникациями и прочим.

в некоторых компаниях «выращивают» своих ПМ, но там тот же самый зоопарк методологий, всякие там Prince, RAD…

Читали? Я так работать не хочу.

https://habr.com/ru/post/476916/

В общем из личного опыта:

1. Есть задача написать новую систему распределенных вычислений. Команда дробит ее на части и каждый занимается своим куском. Раз в N недель команда синхронизируется. Все довольны, задача интересная и сложная.

2. Есть задача написать CRM, которая продается внешним заказчикам. Обычно человек с опытом за свою жизнь на все это насмотрелся столько раз, что желания допиливать очередную CRM уже нет. Но зарплату платят из денег, полученных от клиентов. Клиенты ставят задачи, согласовывают сроки и дальше нужно как-то контроллировать разработку. Скрам здесь вполне подходит, т.к. бизнесовая логика не требует недель рассуждений как выровнять структуру так, чтобы кэш линии заполнялись правильным образом и подобной мути. Планирование, демо и прочее помогают команде понять кто что делал, кто что сделал и как оптимально загрузить разработчиков, чтобы не получалось так, что один сидит в носу ковыряется, а другой ночами сидит.

«Менеджеры» могут придти в любую компанию и начать ее планомерно уничтожать.

Отсутствие базовых знаний.

Ты, например, знаешь, почему и для чего люди придумали аджайл и прочие скрамы с канбанами?

Кто нибудь понимает нафиг это надо и реально использует? Все эти итеративные, спиральные, каскадные модели? Или чем груминг беклога отличается от обзора итогов спринта?

Вот у меня сейчас такой аджайл-тимлид на нынешней работе. Человек читает код, и не может понять, в нем написано, при этом имеет четкий план, правила работы, чётко пропускает все сроки релизов, потому что все спринты оказываются бегом на месте или хождением под себя.

Лучшее, что может сделать руководитель - не мешать программисту писать код. К сожалению, часто программист пишет не то, что надо - в таком случае руководителю нужно вернуть его к реальности, но не более того. И абсолютно никакие методы организации разработки не помогут, если кол-во дебилов в команде превышает некий критический порог, который довольно низок для C/C++, но весьма высок для PHP/JS - потому последние и стали так популярны.