Комментарии 7
Ох уж эти скрам эджайл коучи — бизнесмолодость от IT
:-) Ну, во-первых, оставаться молодым не так уж и плохо. Мне как раз печально видеть 30-40 летних (дети еще ж!) которые типа уже закостенели в своем величии и предрассудках. Мастерство оно все-таки в том что бы оставаться молодым и не бояться нового.
А во-вторых, если вы не очень внимательно прочитали, речь идет о том что в Agile пришли ребята которые по сути с конца 70-х годов прошлого века как раз и построили те процессы, на которых типа сейчас сидят умудренные опытом и покрытые сединами аксакалы от IT. Я говорю о Project Management Institute и их PMBOK. Большая часть всех этих CMM и прочих красивых строгих систем построена именно на нем.
Сейчас вообще прям забавно смотреть как те, кто придумал waterfall уже сами от него отказываются, а адепты все еще цепляются в мудрость веков. :-)
В третьих, честно говоря, я не верю что с IT в РФ всё настолько плохо, что Agile это не устоявшийся процесс, а «бизнесмолодость». Мы тут уже лет пять как рассматриваем и внедряем адаптации Gemba Kaizen и DevOps практики как ту самую бизнес-молодость. Не пугайте меня что правда так все печально. :-)
А во-вторых, если вы не очень внимательно прочитали, речь идет о том что в Agile пришли ребята которые по сути с конца 70-х годов прошлого века как раз и построили те процессы, на которых типа сейчас сидят умудренные опытом и покрытые сединами аксакалы от IT. Я говорю о Project Management Institute и их PMBOK. Большая часть всех этих CMM и прочих красивых строгих систем построена именно на нем.
Сейчас вообще прям забавно смотреть как те, кто придумал waterfall уже сами от него отказываются, а адепты все еще цепляются в мудрость веков. :-)
В третьих, честно говоря, я не верю что с IT в РФ всё настолько плохо, что Agile это не устоявшийся процесс, а «бизнесмолодость». Мы тут уже лет пять как рассматриваем и внедряем адаптации Gemba Kaizen и DevOps практики как ту самую бизнес-молодость. Не пугайте меня что правда так все печально. :-)
Кстати, а можно вопрос? Я только сейчас подумал что возможно ваш комментарий как-то связан с тем что под agile coach понимается что-то специфическое для РФ.
Вообще-то роль agile coach формально — это роль аналогичная Scrum Master в Scrum или Team Lead в XP. И тот и другой являются частным случаем agile coach. А кто такие коачи в РФ?
Вообще-то роль agile coach формально — это роль аналогичная Scrum Master в Scrum или Team Lead в XP. И тот и другой являются частным случаем agile coach. А кто такие коачи в РФ?
Недавно у меня возникло стойкое ощущение что весь этот Аджайл нужен только для того чтобы «заставить» работать людей которые не хотят работать. Все эти «танцы» вокруг команды, вокруг людей. А проблема изначально не в этом, не в процессах. Проблема в найме и построении команды. Набирают людей которые не хотят работать, не мотивированы, не подходят данной команде, и пытаются склеить это всё гов… аджайлом и скрамом.
Привет :-) Хорошее наблюдение, спасибо. Кстати, случающееся и у нас тут в штатах точно так же на каждом шагу.
Вообще если так пытаться сделать — то это точно применять Agile не там, где он должен бы применяться. Как раз в 12 практиках все начинается с того, что «стройте свои проекты вокруг замотивированных людей». Это наоборот проблема при настройке Agile — где ж их взять, пытающихся работать. И большинство пугающих франкенштейнов, понастроенных что в РФ, что в США под типа-эта-Agile как раз от того, что попытка строить его была сделана без привязки к правильному управлению персоналом.
А так — это нормально, когда от 30 до 50% команды приходится заменять при переходе от waterfall к agile, я лично несколько лет пытался с этими цифирями бороться, типа самый умный, но увы, тоже не получилось. :-)
Вообще если так пытаться сделать — то это точно применять Agile не там, где он должен бы применяться. Как раз в 12 практиках все начинается с того, что «стройте свои проекты вокруг замотивированных людей». Это наоборот проблема при настройке Agile — где ж их взять, пытающихся работать. И большинство пугающих франкенштейнов, понастроенных что в РФ, что в США под типа-эта-Agile как раз от того, что попытка строить его была сделана без привязки к правильному управлению персоналом.
А так — это нормально, когда от 30 до 50% команды приходится заменять при переходе от waterfall к agile, я лично несколько лет пытался с этими цифирями бороться, типа самый умный, но увы, тоже не получилось. :-)
Я думаю, что проблема в том, что еще и нормальный agile (scrum etc.) предъявляет очень высокие требования к квалификации сотрудников. Недостаточно быть высокомотивированным, но нужно быть и высококвалифицированным. И наоборот — можно быть высококвалифицированным, но этого тоже недостаточно. Получается формула В+В. А еще нельзя быть токсичным ) К сожалению, в России всего этого не хватает. На рынке такой огромный дефицит кадров, что собрать такую… я даже не знаю с чем сравнить… с командой спасателей? спецназа?… команду разработчиков — это ОЧЕНЬ БОЛЬШАЯ удача. Хотя нет, это плохое слово. Это должна быть работа СТО — ему за это деньги платят. И я знаю буквально несколько человек, которые capable это делать.
Я бы еще посмотрел со стороны зачем это все нужно. Такой подход нужен, если мы пытаемся делать что-то новое, инновационное. Для условного перекладывания json'ов на существующих технологиях можно использовать "старые" "негибкие" подходы
Ну кстати не то что бы на самом деле высокая квалификация была камнем преткновения.
Я ставил команды вполне себе из вполне себе среднего уровня ребят, которые более чем успешно пилили проекты в рамках Scrum. Cross-functionality она все-таки не абсолютная величина, именно способность команды делать конкретный проект/продукт, не более. И если для продукта хватает — то вполне себе команда подойдет. А если быть честным — ну какой процент проектов действительно является так уж challenging? Я уж очень разборчив в выборе работ, бо могу себе позволить, и то дай Бог один из пяти действительно интересен и заставляет мозг шевелиться. А так чаще приходится придумывать как бы команду ну хоть чуть-чуть подтолкнуть к росту. :-)
Токсичность тоже сложный момент. Мне кажется «борьба с токсичностью» (как и за «диверсити») это просто элемент злоупотребления модой на Agile в корыстных целях недобросовестных «внедрителей». Классически-правильным как раз считается, что хорошая Agile команда находится в постоянном «constructive disagreement» (конструктивном несогласии?). Что говорит одновременно и о реальном diversity (мнений, устройства ума и опыта, а не форм носа и цвета попы!) и о правильном климате. С точки зрения Scrum Master'а (ну или enterprise coach если говорить о роли подобной CTO в Agile, но как я понял слово коач в русском ругательное :-))) — важно просто не допускать развития конфликта в деструктивную фазу — когда все это переходит на личности и на победу ради победы, а не чтобы сделать продукт лучше.
Тут еще сильно мешает неправильная система мотивации (частая ошибка!). Если не дай Бог система оплаты не привязана к кросс-оценке внутри команды и к результатам командой работы — соблазн сесть на шею тем кто пашет очень часто оказывается просто непреодолимым. И привет сразу же и токсичность и конфликт. И толпы обиженных которые рассказывают про плохой Agile на всех языках мира. Потому что одних выжили как лентяев, а на других ездили под соусом «ну у нас Agile, ты должен!».
Я ставил команды вполне себе из вполне себе среднего уровня ребят, которые более чем успешно пилили проекты в рамках Scrum. Cross-functionality она все-таки не абсолютная величина, именно способность команды делать конкретный проект/продукт, не более. И если для продукта хватает — то вполне себе команда подойдет. А если быть честным — ну какой процент проектов действительно является так уж challenging? Я уж очень разборчив в выборе работ, бо могу себе позволить, и то дай Бог один из пяти действительно интересен и заставляет мозг шевелиться. А так чаще приходится придумывать как бы команду ну хоть чуть-чуть подтолкнуть к росту. :-)
Токсичность тоже сложный момент. Мне кажется «борьба с токсичностью» (как и за «диверсити») это просто элемент злоупотребления модой на Agile в корыстных целях недобросовестных «внедрителей». Классически-правильным как раз считается, что хорошая Agile команда находится в постоянном «constructive disagreement» (конструктивном несогласии?). Что говорит одновременно и о реальном diversity (мнений, устройства ума и опыта, а не форм носа и цвета попы!) и о правильном климате. С точки зрения Scrum Master'а (ну или enterprise coach если говорить о роли подобной CTO в Agile, но как я понял слово коач в русском ругательное :-))) — важно просто не допускать развития конфликта в деструктивную фазу — когда все это переходит на личности и на победу ради победы, а не чтобы сделать продукт лучше.
Тут еще сильно мешает неправильная система мотивации (частая ошибка!). Если не дай Бог система оплаты не привязана к кросс-оценке внутри команды и к результатам командой работы — соблазн сесть на шею тем кто пашет очень часто оказывается просто непреодолимым. И привет сразу же и токсичность и конфликт. И толпы обиженных которые рассказывают про плохой Agile на всех языках мира. Потому что одних выжили как лентяев, а на других ездили под соусом «ну у нас Agile, ты должен!».
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Disciplined Agile. В чем смысл?