Отличная подача контента, спасибо за разобранные темы, буду смотреть вас

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

Давай про Docker. Это один из самых лучших каналов по донесению информации до разработчика. Ты лучший!

Коммент в поддержку. Удачи и процветания каналу!!!

@ListenIT_channel

Жыл бұрын

Спасибо, заходи ещё!

Спорная идея, но имеет большой смысл. Дело в том, что изначально Agile методы предложили, чтобы избавиться от излишней бюрократизации и повышения гибкости. Но люди... они такие... Довольно скоро создали методы разработки, ставшие новой бюрократией. И снова создали препятствия для гибкости.

Я видел уныние в людях. На панике были и руководители и рядовые сотрудники. А вообще эта трансформация убила лучшие и самые профессиональные коллективы в двух компаниях, в которых работал. Были лавины перехода людей на рынок труда.

@Micro-Moo

Жыл бұрын

Правильно. Хотели иметь agile-разработку, чтобы уйти от бюрократизации. На деле создали новую бюрократизацию.

Классная подача! По сути, это про любое крупное внедрение. Стадии те же, угрозы, вредные и полезные советы очень схожи. Жиза..

У системы современный и функциональный интерфейс сильно напоминающий Jira :)

Ухты, реклама. По ссылке перешел

спасибо братья что не забываете

Надеюсь, стационарное решение, не облачное на чужих серверах?

Ощущение, что статью писал тоже консультант, а не реальный спец.

@ListenIT_channel

Жыл бұрын

Статью написал Антон Зотин, Agile коуч и консультант. Но кто, в вашем понимании, будет реальным спецом по Agile, если не человек, который провел много трансформаций в разных компаниях?

@anp2991

Жыл бұрын

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

@ListenIT_channel

Жыл бұрын

@@anp2991 А по твоему опыту, что неправильно в статье?

@Micro-Moo

Жыл бұрын

@@ListenIT_channel Такой человек тоже изначально некомпетентен. Нужны люди с опытом и успешных и провальных проектов, как минимум.

@Micro-Moo

Жыл бұрын

@@ListenIT_channel Можно, я скажу? В статье много понимания и правильных мыслей. Но нет главного. Автор описывает проблемы «трансформации», но толком ничего не говорит о том, что плохого в самой Agile, о сути дела. Проблема в том, что это детская игра для детей, не сознательных творцов. Она очень способствует имитации деятельности, процедур и протоколов вместо самой работы. Когда-то стали переходить на agile, чтобы избавиться от излишней бюрократизации и улучшить гибкость, а создали новую бюрократизацию. В статье очень остро и жизненно описывается (пародируется?) поведение разных людей: «Нет, ну как это без Continuous Integration жить-то?» или «У вас стендапов нет? Фуу, лохи. Вы в прод выходите реже, чем раз в день? Ну, как так можно вообще? Прошлый век!» Типичное незрелое поведение, игра в работу. Приведу в пример мою реакцию: «Вы что, действительно собираетесь говорить взрослым людям, сидеть им, стоять или пить чай во время совещания? Серьёзно? А может вы ещё и дресс-код предложите? А если у вас нет темы для сегодняшнего совещания, и никто в команде не собирается ни о чём говорить, вы как, всё равно будете его собирать?» И так далее. Что за бессмысленные детские игры? Я лично вообще не понимаю, зачем иметь офис для разработчиков в компании, которая не работает с hardware. Только с целью приходить и говорить «ку»? И так далее... Знаете, мне пришла в голову одна мудрость, которой поделился один из моих друзей: если к человеку относиться как к дураку, он в конце концов начнёт вести себя как дурак. Это главный результат засилья «методологии». Какая же альтернатива? Прежде всего, метод работы должен отталкиваться от целей какого-то большого проекта. Его нужно создавать на месте, всем коллективом, по ходу, ориентироваться на перспективы. И главное: ваша цель не ублажить автора какого-то там очередного «метода» путём послушного следования «правилам», а успешно достигать целей коллектива, компании и своих пользователей. По аналогии с математикой: нужно изучать саму математику, а не школьные правила записи формул и вычислений, «дано» и «найти». А обсуждаемые нами методы это именно правила записи, и очень мало методы самой работы.

В 2023 очень странно об этом говорить. agile это общие принципы и рекомендации, скрам и канбан это уже более конкретные модели реализации процессов. Но никто не мешает адаптировать все это под свои нужды. В целом уже давно в любой адекватной компании используются agile подходы в том или ином виде. Главное это рациональный подход и адекватность.)

Придет ли осознание быстрее если показать это не видео пациентам?))

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