Здравствуйте, zfima, Вы писали:
Pzz>>Тут важны такт, умения и опыт, а не багаж прочитанных книжек и заученных модных слов. Z>Кто же тогда становится Ageile-технологом? Менеджеры и т.д?
Могут менеджеры, может сама команда. Agile — это всего лишь один из способов управления проектами. Причем у Agile в целом много разновидностей и некоторые разновидности можно еще вручную тюнинговать под конкретную ситуацию. Я плохо представляю, кто такой Agile-технолог. Наверное, это все же слишком узкая специализация в рамках управления проектами.
Если рассматривать Scrum-мастера, это вообще скорее "формальная роль". Какой-то долгой специальной подготовки она не требует. Да и времени на нее обычно нужно мало (пара часов за неделю может наберется). Иногда приглашают внешнего человека, который уже вел скрам и тренируются при нем. Фактически это ускоспециализированный внешний консультант.
Z>Помоему, менеджер не захочет им стать, выглядит типа downgrade. Нет?
Так Agile-технолога на полный рабочий день не наберется. Это будет как раз менеджер со знанием Agile, выполняющий некоторые роли из этого Agile.
Могут быть разные ситуации в конкретной команде. Особенно если отходить от "чистого" Agile/Agile по книжке. Например, менеджер может выступать в качестве аналитика/представителя заказчика (было, команда была маленькая). Может заниматься какими-то согласованиями (политические в основном) с другими техническими командами. Или просто координация задач в нетехнической части (художники, аниматоры, звукорежиссеры).
Вообще, нужно задать вопрос: а кто решил делать Agile и почему им понадобился мастер? Грубо говоря, человек, решивший, что нужен Agile, либо сам может им руководить (это менеджер решил, что команда хорошо подходит), или планировал процесс с учетом конкретного лидера (т.е. кандидатура уже есть).
Z>Или выпускники менеджмента?
Интересная идея, кстати. Но только их на подобные "процессные" роли все равно нужно ставить под контролем более опытных товарищей. Т.е. уже есть какой-то человек, который решил, что "будет Agile".
Z>И вообще, есть тут Agile-мастеры, которые могут рассказать, как стали таковы?
Agile-мастер — это такой buzzword, с помощью которого человек пытается продать свои услуги. Не больше и не меньше. Основное время у него уходит на поиск клиентов и разъезды по ним. Вы тоже можете сделать свой сайт и заявлять сбея Agile-мастером. Только вот я, например, в случае необходимости скорее всего не будут искать Agile/Scrum/прочих мастеров. Я буду искать специалиста по управлению проектами. И пусть он уже решает, какой процесс применять.
Так что вопрос "как стать" — сложный. На самом деле вам нужно убедить других в том, что "нужен agile". Не мене важно также убедить всех в том, что за процессом внедрения вы готовы следить, корректировать его при необходимости (т.е. основные проблемы и подводные камни знато тоже должны сразу). Ну и быть готовы отказаться от внедрения при неудачен. Это people skills и все, что с ними связано. И авторитет, и политика (в зависимости от сложившихся условий) и все остальное.
Здравствуйте, maxkar, Вы писали:
M>Здравствуйте, zfima, Вы писали:
Pzz>>>Тут важны такт, умения и опыт, а не багаж прочитанных книжек и заученных модных слов. Z>>Кто же тогда становится Ageile-технологом? Менеджеры и т.д? M>Могут менеджеры, может сама команда. Agile — это всего лишь один из способов управления проектами. Причем у Agile в целом много разновидностей и некоторые разновидности можно еще вручную тюнинговать под конкретную ситуацию. Я плохо представляю, кто такой Agile-технолог. Наверное, это все же слишком узкая специализация в рамках управления проектами.
M>Если рассматривать Scrum-мастера, это вообще скорее "формальная роль". Какой-то долгой специальной подготовки она не требует. Да и времени на нее обычно нужно мало (пара часов за неделю может наберется). Иногда приглашают внешнего человека, который уже вел скрам и тренируются при нем. Фактически это ускоспециализированный внешний консультант.
А вот тут написано, что по-нормальному у мастера куча обязанностей:
http://agiletrail.com/2011/11/14/42-tasks-for-a-scrum-masters-job/
Z>>Помоему, менеджер не захочет им стать, выглядит типа downgrade. Нет? M>Так Agile-технолога на полный рабочий день не наберется. Это будет как раз менеджер со знанием Agile, выполняющий некоторые роли из этого Agile.
M>Могут быть разные ситуации в конкретной команде. Особенно если отходить от "чистого" Agile/Agile по книжке. Например, менеджер может выступать в качестве аналитика/представителя заказчика (было, команда была маленькая). Может заниматься какими-то согласованиями (политические в основном) с другими техническими командами. Или просто координация задач в нетехнической части (художники, аниматоры, звукорежиссеры).
M>Вообще, нужно задать вопрос: а кто решил делать Agile и почему им понадобился мастер? Грубо говоря, человек, решивший, что нужен Agile, либо сам может им руководить (это менеджер решил, что команда хорошо подходит), или планировал процесс с учетом конкретного лидера (т.е. кандидатура уже есть).
Z>>Или выпускники менеджмента? M>Интересная идея, кстати. Но только их на подобные "процессные" роли все равно нужно ставить под контролем более опытных товарищей. Т.е. уже есть какой-то человек, который решил, что "будет Agile".
Z>>И вообще, есть тут Agile-мастеры, которые могут рассказать, как стали таковы? M>Agile-мастер — это такой buzzword, с помощью которого человек пытается продать свои услуги. Не больше и не меньше. Основное время у него уходит на поиск клиентов и разъезды по ним. Вы тоже можете сделать свой сайт и заявлять сбея Agile-мастером. Только вот я, например, в случае необходимости скорее всего не будут искать Agile/Scrum/прочих мастеров. Я буду искать специалиста по управлению проектами. И пусть он уже решает, какой процесс применять.
M>Так что вопрос "как стать" — сложный. На самом деле вам нужно убедить других в том, что "нужен agile". Не мене важно также убедить всех в том, что за процессом внедрения вы готовы следить, корректировать его при необходимости (т.е. основные проблемы и подводные камни знато тоже должны сразу). Ну и быть готовы отказаться от внедрения при неудачен. Это people skills и все, что с ними связано. И авторитет, и политика (в зависимости от сложившихся условий) и все остальное.
Ну давайте разберем. Но вы немного не правы. Это не совсем "обязанности". И сам автор не прав, это не "tasks". Больше всего туда подходит название "activites".
Сначала еще немного вводных слов. Я не совсем понял, он "agile по книжке" рассматривает? Т.е. команда совсем взаимозаменяемых профессионалов? Ну да, там будут провалы в определенных местах наблюдаться. Ну так проще процесс потюнинговать, нанять бизнес-аналитика или менеджера (с функциями бизнес-аналитика). И работать "в духе agile". А еще у меня местами возникают вопросы, Scrum ли это или уже пошли вариации на тему. Вообще, автор пытается обосновать, почему же его такого хорошего (и других аналогичных), которые не умеют производить реальный value, все же стоит брать и платить ему полную ставку.
А теперь спискота.
* Митинги. В митингах участвуют все роли. И готовятся тоже. Чего такого специального готовит scrum-мастер? Переговорку заказывает? Модерация — да, роль в течение митинга. Постобработка — да, может быть полезна (зависит от конкретики). А может, можно секретаршу взять и потом попросить все решения занести в wiki. Ретроспективы ничем принципиальным не отличаются.
* Coaching имеет много смыслов. В смысле "give (someone) instructions as to what to do or say in a particular situation" — это уже фейл менеджера/руководителя. Не нужно доводить до таких ситуаций. Во всех остальных значениях попытки coaching'а — это объявление войны. Чтобы нетехнический специалист (который кодом задачи не занимается) указывал мне, как делать мою работу? Это безобразие и страдание фигней. Пусть лучше скажет, что делать и ответит на нужные вопросы. Правда, для ответов на вопросы есть заказчик рядом.
* Разрешение конфликтов. В технических конфликтах мастер ничем помочь не может. Ну не знает он внутренних деталей, он другими делами занят. А в нетехнических (т.е. личностных) достаточно практически любого человека с лидерскими качествами. Ну да, в команде желательно наличие лидера (можно не одного, если они смогут уживаться друг с другом). Почему этим человеком не может быть кто-то другой из команды —
* Принятие решений... Каких? Когда? И вообще, это два раза посчитано. Его основная задача — борьба с impediments. Так что этот пункт вычеркиваем.
* Развитие самоорганизации... Это тоже странный пункт. Если команда самоорганизуется, зачем тогда scrum-мастер? Или все-таки команду нужно организовывать, чтобы складывалась видимость самоорганизации?
* "Mediating the general conflict". А это вообще не его дело. Это его косяк в организации всей работы команды. Окончатеное право голоса по этим вопросам у stakeholder. Да, они должны в определенной степени доверять техническим специалистам (оценка последствий, сложности, и т.п.). И разработчики должны не испытывать проблем с таким решением (все возникшие проблемы — это проблемы стейкхолдеров). При нормальной организации это автоматически работает. Гайдлайны (побыстрее/понадежнее) устанавливаются перед проектом. Конкретные решения (если мы сделаем это быстро, потом придется переписать) принимаются по месту. Заказчик то рядом.
* Просиживание на форумах, конференциях. Чтение художественной литературы на тему agile. Писание в ЖЖ-шке. Да уж... Важная деятельность. Только вот связь ее с выполняемым проектом совершенно не понятна.
* Консультация команды по Agile... Вот интересно, сколько на это времени уходит. И не проще ли члену команды задать вопрос на форуме, чем держать целого консультанта рядом?
* Поддержание information radiator. Да, нарисовать на доске картинку — это сложно, блин. Почему-то наша команда сама рисовала на досках нужные диаграммы (и фотографировала их на память). Причем ведь даже не "поддержание", а "помощь команде в поддержании"! Это он что, под руководством команды стрелочки рисует? И не лучше ли, чтобы член команды потратил свое время (он и так его уже тратит, см. оказывать помощь) и создать качественный радиатор.
* Какой он feedback хочет давать команде? Для этого можно пару раз внешних консультантов пригласить (если по процессу feedback), они в отличие от scrum master будут лицами незаинтересованными. Для другого feedback есть представитель заказчика.
* Про релизы и прочие инструменты просто вранье. В крупной компании инструменты поставит и настроит специально обученная команда системных администраторов. А в маленькой команде сложные инструменты не нужны. One-click delivery — это разовая инвестиция на старте проекта. Ну да, можно отдельного человека взять на один раз (на неделю-две), чтобы он настроил delivery. В общем, при правильных людях это задача одноразовая и не слишком долгая. Нет там никакого huge.
* Про challenge team не совсем понял. Вполне возможно, это объявление войны наподобие coaching (вместо решения продуктивных/конкретных вопросов занятие ерундой).
* Посещение курилок и треп с коллегами. Тоже очень важная задача. Прямо наравне с посещением форумов. А вот разработчик не справится с такой задачей. И вооще, они в курилках не сидят и форумы не посещают (иначе — всего лишь еще один форум и еще одна тема для общения).
* Экскурсии на территорию заказчика. Не понятно только, почему это нельзя совместить разработчику? Тем более, разработчику то это будет полезнее. Он сам увидит ситуацию а не будет получать информацию через посредника.
* User stories — да, хорошая штука. Только под эту роль можно ведь и аналитика/менеджера завести (у которого будет и ряд функций по модерации собраний). Прощай, чистый agile. Но работать то схема будет, а чистый agile — не самоцель.
* Прочее из product. Везде helping. Сам он ничего не делает. Так что никаких затрат при отказе от scrum manager по этому пункту мы не получим. Такой мальчик на побегушках, кстати, полезная функция, но к scrum отношения не имеет и может совмещаться для нескольких команд без других обязанностей "scrum master".
* "Being familiar with the team’s work (i.e. the product)." Ну правильно. Как же без этого. Иначе самоорганизовавшаяся команда (см. выше) его выгонит как лишний балласт. Кстати, а разработчикам и owner'у это не нужно? Т.е. они не знают, что команда делает? Или эту функцию можно прекрасно совместить с остальными и не тратить на нее лишнее время?
* Сводничество (в команде и не только). В небольшой команде это и так не проблема. Люди знают, с кем общаться. В больших/сложных командах это может быть отдельная роль (человек по связям с общественностью). Т.е. роль совсем не обязательная.
* Общение со stakeholder. Стоп, а зачем митинги тогда? Давайте скажем, что это — менеджер, а процесс — вариации на тему agile (и даже не scrum). А вообще, некоторые вариации вообще требуют представителя stakeholder'а в рабочей комнате (не знаю, относится ли к ним scrum). И вот роль этого представителя точно не может соединяться с ролью scrum master.
* Еще пара helping. Кстати, там где-то появился management, которому нужно отчеты делать. Это вообще что за зверь в agile? И почему тот менеджмент не может выполнять работу scrum master'а (точнее, ее часть вроде управления фичами/качеством)?
* Внедрение Agile во всей организации. Это какая-то террористическая организация получается. Организация нуждается в "нужных и полезных практиках", а не в Agile. Ну да, такими практиками может быть agile, но само по себе agile — не самоцель.
* Организация конференций. Не понятно, кому, зачем и в каком виде нужно. Чем отличается от простого "в следующую пятницу собираемся в кабаке"? А в больших организациях (и даже в средних) есть отдельные люди, которые этим занимаются. Им нужно правильно сформулировать задачу, и они организуют конференцию. Не нужно держать человека в каждой команде. Ну а про одну команду я уже сказал, она и сама хорошо организуется (кстати, да, есть же самоорганизация).
* Опять бложики. Вроде же было про это выше. Кстати, а owner/developer бложики не имеют права вести? А если имеют, какую полезную информацию можно подчеркнуть из блога scrum master'а? Т.е. что он может написать лучше, чем знающий тему разработчик/заказчик?
* Еще один раз упомянуто про консультацию по Agile. Если процесс так часто требует консультации, может, в топку этот процесс? Много где можно подобрать процесс, где консультаций "по процессу" не требуется.
* Еще одна религия. Опять "внедрять Agile"... Причем в рабочее время (хотя в некоторых случаях это оправдано).
* impediments. С этим спорить не буду. Но их не должно быть много. Если их слишком много, это повод задуматься над всем процессом. Может, нужна другая методолгия. Или другая команда. Или вообще проект стоит заморозить на время.
* Метрики как катализатор изменений — это смешно. Метрики, конечно, будут катализировать изменения. Направленные на накручивание этих метрик и больше ничего. А вообще обычно метрики используются как индикатор "туда ли идем" и скорости изменений. Это инструмент мониторинга, а не управленя.
* "Reflecting Agile and Scrum values to the team." А у команды на это время есть? Может, обойтись без рефлексии по поводу Agile и потратить это на какую-нибудь другую обязанность из списка (вроде организации совместных посиделок).
* "Reminding the team of their arrangements (e.g. policies)." Представил себе scrum-master'а с дубинкой, стоящего в центре общей комнаты команды. Вообще, первично определение нужных policy и мониторинг их актуальности. А "напоминать квалифицированным профессионалам их место в команде" — это какое-то странное занятие.
* Улучшение процесса. Да, в какой-то степени. Но часть вещей прекрасно можно совмещать с другими занятиями. Хотя тут спорная ситуация. Часть проблем лучше видна изнутри, часть — снаружи.
* За постановку "открытых вопросов" можно и по лицу получить. Команде больше делать нечего кроме этого.
* Проверять модели — странное занятие. Наверное, это потому, что в команде только недавние выпускники и разницы между реальным миром и моделями не видят. Или потому что блоги и конференции надоели, кодом заниматься квалификация не позволяет, команда работает хорошо, вот и приходится какое-нибудь занятие выдумать.
* Отвлечение внешних раздражителей на себя — полезная вещь. Но если их слишком много, нужно принимать некоторые радикальные меры вплоть до переезда команды в здание без телефонов в другом районе города. Да и откуда у scrum-команды много внешних раздражителей (кроме scrum master'а, напомниающего о месте в команде и необходимости сохранять vision).
* Про инструменты же было уже один раз. Куда у scrum master'а уехал фокус?
* Да, помощь product owner'у. Почти аналитик. А может, ну его, этот scrum, взять одного аналитика и работать дальше?
В общем, там почти все спорное. Особенно постулат про необходимость scrum. В принципе, многие активности может выполнять "просто менеджер" (совмещая управление с должностью аналитика, достаточно частый вариант). Вот если этот менеджер осознанно выбрал scrum, то может быть и scrum master'ом. А может посоветовать взять аналитика (для определения vision, definition of done и поездок на производство к заказчику), например. Я опять повторюсь, лучше взять "универсального менеджера", чем узкого специалиста по scrum. Пространство для маневра больше. Да и часть обязанностей из списка выше достаточно часто отдается именно менеджерам.
Здравствуйте, Pzz, Вы писали:
Pzz>Нет. Если бы у меня в группе завелся какой-нибудь птенец неоперившийся, который в бою не бывал, а командира учит, я бы предпринял осмысленные усилия, чтобы направить его энергию в мирное русло, а если бы это не помогло, постарался бы от него избавиться. Это потому, что я добрый, либеральный и демократичный, и вообще, людей расстраивать не люблю. Другой бы на моем месте сразу бы уволил нахрен, чтобы не баламутил команду.
Странное поведение для руководителя. Почему-бы такому мудрому и опытному не помочь своей мудростью и опытом молодому? Или сакральные знания нельзя передавать дальше? ИМХО руководитель на то и руководитель, чтобы прогнозировать и поощрять рост своей команды. А если инициативу гнобиьт со словами: "мал еще, не дорос" и т.п. можно инициативных и талантливых людей потерять.
Задумайтесь, откуда человек может получить опыт, если ему не дают его получить? Что, все сразу стали руководителями, тим-лидерами, скрам-мастерами? Нет, они шли, набивали шишки, искали пути. ИМХО автору топика надо посоветовать идти к руководству и пробивать идею дальше, особенно, если и его руководитель понимает, что их процесс гуано полное. И здесь неважно, кто будет главным — важно, кто будет инициативу проявлять.
2Автор темы:
Если руководитель до сих пор сам не решился что-то изменить, значит надо понять, почему. Он или боится развалить команду или боится еще больше ухудшить показатели. Сделайте не просто предложение, а с четким планом, со сроками, с детальными действиями. Если он в Вас сомневается, посоветуйте ему нанять консультантов по Agile, они помогут сделать первые шаги. А далее, старайтесь не выпускать инициативу из своих рук, но так, чтобы руководитель не чувствовал, что Вы его подсиживаете. Пусть он будет главный за весь процесс перехода, пусть ему достанется вся слава. Вам же нужно сейчас получить опыт скрам-мастера, а не почет. С другой стороны — вы должны понимать, что если что-то пойдет не так, то все шишки на Вас повесят и уволят . Но... волков боятся — в лес не ходить.
Z>Заметил, что процесс у нас не отвечает никаким методологиям/фреймуоркам, ну может немного смахивает на водопад Z>3-4 месяца интересуюсь Agile методоглогиями, тема понравилась, читаю и смотрю много чего, записался на курс CSM. И всё потому, что тема мне нравится.
Стало быть, вам просто интересно "прокачать скиллы" (С)
У вашего работодателя (или начальника, или кого-то еще) могут быть другие планы и ожидания, идущие вразрез с вашими. Возможно, по этой причине вам не дадут качать скиллы за счет работодателя.
Еще одна инетерсная особенность, самостоятельное изучение хоть и дает знания, но не дает опыт. А без опыта и шишек вряд ли у вас получится правильно отвечать на вопросы, которые неизбежно возникают при внедрении любых новшеств.
Здравствуйте, zfima, Вы писали:
Z>Здравствуйте Z>Наверное, вопрос касается общей темы — как продвинуть себя
Z>Дело такое. Z>Заметил, что процесс у нас не отвечает никаким методологиям/фреймуоркам, ну может немного смахивает на водопад Z>3-4 месяца интересуюсь Agile методоглогиями, тема понравилась, читаю и смотрю много чего, записался на курс CSM. И всё потому, что тема мне нравится. А не для того, чтобы кому-то что-то...
Z>Представил начальнику примерную схему и объяснил что к чему
Z>Как только это произошло и манагер начал шевелиться, один товарищ, более приблеженный к нему, начал брать тему в свои руки, не понимая ничего и отвечая на вопросы начальника с помощью поиска ответов в IPhone. Не буду загрязнять пост особенностями "товарища".
Z>Как быть? Дать им всё завалить?
Ну, вы уже догадались, чем всё закончилось?
Нет?
Товарищ под эгидой манагера начал проводить небольшие лекции на которые были приглашены только девелоперы, находящиеся с ним в хороших отношениях
Меня через 2-3 встречи после пары моих замечаний по поводу перестали приглашать
M>Сначала еще немного вводных слов. Я не совсем понял, он "agile по книжке" рассматривает? Т.е. команда совсем взаимозаменяемых профессионалов? Ну да, там будут провалы в определенных местах наблюдаться. Ну так проще процесс потюнинговать, нанять бизнес-аналитика или менеджера (с функциями бизнес-аналитика). И работать "в духе agile". А еще у меня местами возникают вопросы, Scrum ли это или уже пошли вариации на тему. Вообще, автор пытается обосновать, почему же его такого хорошего (и других аналогичных), которые не умеют производить реальный value, все же стоит брать и платить ему полную ставку.
Отдельное спасибо за эту фразу. В компаниях разрабатывающих софт добавочную стоимость создают программисты. Наемный управленец добавочной стоимости не создает, но может влиять на процесс ее создания. К сожалению, немногие менеджеры способны "экономически" объяснить свою пользу и являются, скорее глашатаями того или иного карго-культа (в том числе и scrum). Интересно, что некоторые оказываются неспособны объяснить свою необходимость даже команде, которой они управляют. Вопрос, а зачем вы нужны этой команде ставит их в тупик, т.к. они привыкли мыслить в парадигме "зачем мне нужна эта команда".
Вообще, это очень интересная тема для дискуссии. Она затрагивает и размер команды, и квалификацию программистов и даже необходимость тестировщиков в проекте. Последнее время я все больше склоняюсь к тому, что небольшие команды (до 5 человек) сильных специалистов являются наиболее эффективной моделью разработки софта для гораздо большего спектра задач, чем это принято считать. А если это так, то и архитектура разрабатываемых систем и процессы внутри компании должны быть подчинены этой модели.
Здравствуйте, zfima, Вы писали:
Z>Здравствуйте Z>Наверное, вопрос касается общей темы — как продвинуть себя
Z>Дело такое. Z>Заметил, что процесс у нас не отвечает никаким методологиям/фреймуоркам, ну может немного смахивает на водопад Z>3-4 месяца интересуюсь Agile методоглогиями, тема понравилась, читаю и смотрю много чего, записался на курс CSM. И всё потому, что тема мне нравится. А не для того, чтобы кому-то что-то...
Z>Представил начальнику примерную схему и объяснил что к чему
Z>Как только это произошло и манагер начал шевелиться, один товарищ, более приблеженный к нему, начал брать тему в свои руки, не понимая ничего и отвечая на вопросы начальника с помощью поиска ответов в IPhone. Не буду загрязнять пост особенностями "товарища".
Z>Как быть? Дать им всё завалить?
Здравствуйте, zfima, Вы писали:
Z>Ну, на пример ты начальник. Любишь музыку самоа, картины художника П. и фильмы о тасмании. Чудесным образом мне тоже всё это нравится!
Почему бы не объяснить ситуацию начальнику и прямо не предложить решение? Почему мешают фильмы о тасмании?
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
