Будучи мотоциклистом, регулярно просматриваю ролики с авариями, дабы сохранять холодную голову на дороге и не забывать возможных последствий, не входить в кураж
Тоже заметил аналогию и здесь: Все нелепые и смертельные аварии, как правило, содержат один общий элемент: байкер либо без шлема, либо в минимальной экипировке (как это в шутку называется "мотосланцы" и "мотофутболка")
Само по себе отсутствие экипировки не обуславливает стиль езды - я сам некоторое время без неё ездил за неимением, но предельно аккуратно - однако в подавляющем большинстве случаев это маркер именно безответственности и легкомысленного отношения, что уже является причинами трагедий
Обычно читаю с другого браузера, в котором нет авторизации в хабре. Тут даже решил зайти, чтобы тот же коммент написать. Сломал голову 4 раза только на первом абзаце
Запятые не там, излишние "сложносочинения" в предложениях, в которые не всегда получается (всегда не получается)
Первый принцип Agile как он есть. Нет, не тот Agile, который продают всякие консалтинги, скрам мастера со своих курсов и их преподаватели, а истинный, который здесь
Откликается мой опыт: из-за мискоммуникации и довольно "странных" процессов оценки задач на одной из работ столкнулся с ситуацией, в которой получил в управление около 12 проектов с жестким дедлайном, который ну совсем не вписывается в реальность. Вместо честного и открытого "давайте чем-то из этого жертвовать, что-то менять, всё не успеем" жертвовал своим личным временем, работал с температурой 39 на порошочках, делал всё за всех. Как итог: сделали только половину, остальную половину - частично, что всё равно не было актуально заказчику, в итоге доделывали в следующий квартал до состояния "как нужно". Пролюбленные 2 месяца вечеров с родными, благо без долгосрочных последствий здоровью. Если бы делали по-нормальному, сделали практически всё точно также, но без аврала, максимум перенсли бы пару незначительных проектов.
В общем, в статье истина - проверено, подтверждаю)
Применение гибких подходов там, где высокая степень неопределённости ещё одно заблуждение
Не совсем понял в чём заблуждение.
Гибкий подход означает, что он устойчив и приветствует изменения (любые). Изменения в скоупе, например, как раз таки рождаются из неопределённости. Гибкий подход на то и гибкий, а не хрупкий, чтобы процесс не сломался под весом этих изменений, а адаптировался. Неопределённость это самое первое, что толкает к использованию гибких подходов. Или я не правильно трактую смысл гибких подходов и неопределённости в проекте/продукте?
Поэтому инкремент в подобных системах настолько большой, что его невозможно поставить в один спринт, и не в два и даже не в три
Об этом и речь, что критерии "Большой инкремент" и "Большая ERP система" это не тождественные понятия
Работай по Scrum. Кажется, что эта методология стала слишком популярной
Это фреймворк
традиционный Waterfall стал мифическим
Всё. Ещё бы слово "стал" убрать)
причина может быть в частых вмешательствах или недовольстве заказчика
Но Scrum guide говорит, что PO - полноценный участник команды..
Несмотря на это, его часто пытаются использовать там, где этот подход совсем не нужен. Например, при разработке информационных или ERP-систем, а также при миграции инфраструктуры. Все это — крупные проекты, которые затрагивают всю компанию и требуют детальной документации.
В ходе разработки нет инкремента и поставки ценности? Это невозможно сделать итерационно? Тогда не подходит. Для разработки крупных проектов - как раз таки самое то, особенно при наличии неопределённости. А при её отсутствии смысл никуда не потерялся - завершать итерацию и смотреть на то, что сделано, получать фидбек - это дофаминовая игла, которая в любом случае поможет команде ехать в долгосроке
Ну и совсем не понятно, почему scrum только для поддержания существующих продуктов? Если речь про быструю инкрементальную поставку и получения быстрой ОС от пользователей с целью корректировки вектора, разве речь это всё не про стратегию стартапа?
~~~
Я это всё к тому, что да, согласен, никто нигде (по крайней мере, по отзывам других и опыту лучному) не использует скрам в том виде, в котором о нём идёт речь в скрам гайде. Но зачем вносить ещё больший разрыв в умы людям?
Оценка разработчиков менеджерамиона строится на воспоминаниях
Что за странная аксиома? Гораздо правильней будет в лоб спросить: "Как оценивается моя эффективность?" Никто не скажет "по воспоминаниям", это сюр)
Всё это решается простыми договорённостями между сотрудником и его менеджером: Оцениваешь по количеству задач закрытых в срок? Срок откуда берётся? Из головы менеджера? Думайте сами, устраивает вас такое или нет. Если срок берётся от программиста - замечательно, то что искали.
Я к тому, что как правило такие метрики эффективности обсуждаемы в нормальных коллективах, если вы не договоритесь за себя, то кто?
Эта картинка - МВП статьи. И если кому-то понятно общее видение и ситуация, и они относятся нейтрально, то есть люди, которым это совсем не понятно. Видимо, автор столкнулся со вторым "лагерем". Как и я. Скину статью коллегам, кстати
Грубо говоря это создание пралаллельных слоёв к языковой модели, которые тоже участвуют в генерации ответа пользователю, при этом учитываются старые полученные знания модели. Вот этой вот надстройкой и может стать ваша база знаний. Хороший материал на эту тему видел тут
Сама постановка "Почему Agile популярен?" весьма спорна
Согласен Сам заголовок говорит о том, что Agile манифест разработки программного обеспечения) является популярным и в принципе я рассматриваю это как факт и данность, при этом нигде не подтверждая этот факт.
Такая постановка связана с тем, что часто вижу примеры людей, которые могут быть даже в принципе своими взглядами на построение рабочей среды далеки от сабжа, тем не менее пытаются освоить гибкие методологии. Где-то получается, где-то нет.
Вся популярность только в моём окружении, получается. Верно будет так: "Почему я всё чаще вижу Agile вокруг себя")
Ведь очень много на самом деле статей не про то как здорово с гибкими подходами, а про то как перестали всех контролировать, забили болт на процессы и документацию и почему-то их спринты не дают результата сами по себе
Отсылает нас к завершению статьи и карго-культу: "щя спринт с дейликами сделаем и буит мясо") Планирую логично продолжить статью и раскрыть эту тему: почему не работает, на что обратить внимание и так далее.
Scrum - 1995 год, изначальная статья упоминавшая это слово, опубликована в 1986 году
Kanban - 2006 год
Да, эти вещи не новы. Тем не менее статья, на которую я ссылаюсь (первая линка) возрастом в 3 года. Также видел статьи моложе (до года) которые говорят примерно то же самое
Ну и ещё важные нюансы. Не просто Аджайл, а Аджайл манифест разработки программного обеспечения. Канбан - не просто канбан, а канбан-метод, который отличается от производственного канбана (ещё более старого метода).
В чужом глазу замечаю, в своём - не замечаю) Спасибо, что подсветили, обращу на это внимание
Вы пишите, что они становятся популярными, а некоторые разработчики и менеджеры уже во всю хайпуют статьями "аджайл мёртв" )
Воот как раз в таких-то статьях и говорят, что "Это мейнстрим", "Это уже везде и повсюду", "Ни дня без аджайла не могут прожить" и в таком духе. Ну и как правило приводятся примеры неудачных применений аджайлов, которые являются причиной смерти аджайла. Кажется, что как раз таки бьётся с заголовком. Или нет?)
Хороший комментарий, но не к той статье. Посыл статьи про новичка в IT и "С чего начать", а не где применить тот или иной инструмент. Вы всё совершенно верно говорите, но не в тм контексте
самое интересное, что название не отражает, а что именно делается, почему названо именно так) Ну кроме покраски "длинных" задач в красный цвет и "коротких" в синий
>простой, прямой, бинарный вопрос: «С каких пор решение о статусе трудоустройства инженера принимает менеджер?».
Да
Будучи мотоциклистом, регулярно просматриваю ролики с авариями, дабы сохранять холодную голову на дороге и не забывать возможных последствий, не входить в кураж
Тоже заметил аналогию и здесь:
Все нелепые и смертельные аварии, как правило, содержат один общий элемент: байкер либо без шлема, либо в минимальной экипировке (как это в шутку называется "мотосланцы" и "мотофутболка")
Само по себе отсутствие экипировки не обуславливает стиль езды - я сам некоторое время без неё ездил за неимением, но предельно аккуратно - однако в подавляющем большинстве случаев это маркер именно безответственности и легкомысленного отношения, что уже является причинами трагедий
Обычно читаю с другого браузера, в котором нет авторизации в хабре. Тут даже решил зайти, чтобы тот же коммент написать. Сломал голову 4 раза только на первом абзаце
Запятые не там, излишние "сложносочинения" в предложениях, в которые не всегда получается (всегда не получается)
В общем, ударило больно в глаз, плюсую
Сейчас бы прочитать это всё НЕ ближе к концу среднего возраста..((
Первый принцип Agile как он есть. Нет, не тот Agile, который продают всякие консалтинги, ск
рам мастера со своих курсов и их преподаватели, а истинный, который здесьОткликается мой опыт: из-за мискоммуникации и довольно "странных" процессов оценки задач на одной из работ столкнулся с ситуацией, в которой получил в управление около 12 проектов с жестким дедлайном, который ну совсем не вписывается в реальность. Вместо честного и открытого "давайте чем-то из этого жертвовать, что-то менять, всё не успеем" жертвовал своим личным временем, работал с температурой 39 на порошочках, делал всё за всех. Как итог: сделали только половину, остальную половину - частично, что всё равно не было актуально заказчику, в итоге доделывали в следующий квартал до состояния "как нужно". Пролюбленные 2 месяца вечеров с родными, благо без долгосрочных последствий здоровью. Если бы делали по-нормальному, сделали практически всё точно также, но без аврала, максимум перенсли бы пару незначительных проектов.
В общем, в статье истина - проверено, подтверждаю)
Да как и везде: злоупотреблять - плохо, в нормальных количествах - полезно
Нумерованные ссылки 1-9 не работают(
Статья понравилась, спасибо, то что нужно
Не совсем понял в чём заблуждение.
Гибкий подход означает, что он устойчив и приветствует изменения (любые). Изменения в скоупе, например, как раз таки рождаются из неопределённости. Гибкий подход на то и гибкий, а не хрупкий, чтобы процесс не сломался под весом этих изменений, а адаптировался. Неопределённость это самое первое, что толкает к использованию гибких подходов. Или я не правильно трактую смысл гибких подходов и неопределённости в проекте/продукте?
Об этом и речь, что критерии "Большой инкремент" и "Большая ERP система" это не тождественные понятия
Это фреймворк
Всё. Ещё бы слово "стал" убрать)
Но Scrum guide говорит, что PO - полноценный участник команды..
В ходе разработки нет инкремента и поставки ценности? Это невозможно сделать итерационно? Тогда не подходит. Для разработки крупных проектов - как раз таки самое то, особенно при наличии неопределённости. А при её отсутствии смысл никуда не потерялся - завершать итерацию и смотреть на то, что сделано, получать фидбек - это дофаминовая игла, которая в любом случае поможет команде ехать в долгосроке
Ну и совсем не понятно, почему scrum только для поддержания существующих продуктов? Если речь про быструю инкрементальную поставку и получения быстрой ОС от пользователей с целью корректировки вектора, разве речь это всё не про стратегию стартапа?
~~~
Я это всё к тому, что да, согласен, никто нигде (по крайней мере, по отзывам других и опыту лучному) не использует скрам в том виде, в котором о нём идёт речь в скрам гайде. Но зачем вносить ещё больший разрыв в умы людям?
Что за странная аксиома?
Гораздо правильней будет в лоб спросить: "Как оценивается моя эффективность?"
Никто не скажет "по воспоминаниям", это сюр)
Всё это решается простыми договорённостями между сотрудником и его менеджером: Оцениваешь по количеству задач закрытых в срок? Срок откуда берётся? Из головы менеджера? Думайте сами, устраивает вас такое или нет. Если срок берётся от программиста - замечательно, то что искали.
Я к тому, что как правило такие метрики эффективности обсуждаемы в нормальных коллективах, если вы не договоритесь за себя, то кто?
Как связано с хабом "Agile"?) Точно не мимо?
Слово менеджера. Маркер на флип-чарте)
Хорошая статья и критерии для грейдов простыми словами. Спасибо
Эта картинка - МВП статьи. И если кому-то понятно общее видение и ситуация, и они относятся нейтрально, то есть люди, которым это совсем не понятно. Видимо, автор столкнулся со вторым "лагерем". Как и я. Скину статью коллегам, кстати
Грубо говоря это создание пралаллельных слоёв к языковой модели, которые тоже участвуют в генерации ответа пользователю, при этом учитываются старые полученные знания модели. Вот этой вот надстройкой и может стать ваша база знаний. Хороший материал на эту тему видел тут
Модели уже можно дообучать на своих данных, своей базой знаний или, например, внутренней кодовой базой, о которой вы говорите. (LoRA)
При желании и достаточном времени для обучения можно скармливать ей информацию и тем самым подстраивать её под себя, в том числе в таком виде:
Согласен
Сам заголовок говорит о том, что Agile манифест разработки программного обеспечения) является популярным и в принципе я рассматриваю это как факт и данность, при этом нигде не подтверждая этот факт.
Такая постановка связана с тем, что часто вижу примеры людей, которые могут быть даже в принципе своими взглядами на построение рабочей среды далеки от сабжа, тем не менее пытаются освоить гибкие методологии. Где-то получается, где-то нет.
Вся популярность только в моём окружении, получается. Верно будет так: "Почему я всё чаще вижу Agile вокруг себя")
Отсылает нас к завершению статьи и карго-культу: "щя спринт с дейликами сделаем и буит мясо")
Планирую логично продолжить статью и раскрыть эту тему: почему не работает, на что обратить внимание и так далее.
Да, эти вещи не новы. Тем не менее статья, на которую я ссылаюсь (первая линка) возрастом в 3 года. Также видел статьи моложе (до года) которые говорят примерно то же самое
В чужом глазу замечаю, в своём - не замечаю) Спасибо, что подсветили, обращу на это внимание
Воот как раз в таких-то статьях и говорят, что "Это мейнстрим", "Это уже везде и повсюду", "Ни дня без аджайла не могут прожить" и в таком духе. Ну и как правило приводятся примеры неудачных применений аджайлов, которые являются причиной смерти аджайла. Кажется, что как раз таки бьётся с заголовком. Или нет?)
Хороший комментарий, но не к той статье. Посыл статьи про новичка в IT и "С чего начать", а не где применить тот или иной инструмент. Вы всё совершенно верно говорите, но не в тм контексте
самое интересное, что название не отражает, а что именно делается, почему названо именно так) Ну кроме покраски "длинных" задач в красный цвет и "коротких" в синий