Comments 51
Практически все хайповые методики включают два как мне кажется важных пункта
1 наладить взаимодействие в команде
2 все кроме пункта один (канбан доски, стоячие оперативки и т.п.) опциональны за исключением пункта 1
В противном случае применение хайповых методик напоминает русскую народную сказку Солнце, Месяц и Ворон Воронович. Да и кстати если уж применять методики то на всех этапах проекта. Поясню что имею в виду. Полтора года потрачено на предварительные невнятные работы. За три месяца до сдачи проекта наконец дело доходит с высот менеджмента до низов разработки. И тут кого то наконец осеняет идея. А давайте будем теперь пинать их по скраму.
1 наладить взаимодействие в команде
2 все кроме пункта один (канбан доски, стоячие оперативки и т.п.) опциональны за исключением пункта 1
В противном случае применение хайповых методик напоминает русскую народную сказку Солнце, Месяц и Ворон Воронович. Да и кстати если уж применять методики то на всех этапах проекта. Поясню что имею в виду. Полтора года потрачено на предварительные невнятные работы. За три месяца до сдачи проекта наконец дело доходит с высот менеджмента до низов разработки. И тут кого то наконец осеняет идея. А давайте будем теперь пинать их по скраму.
> 1 наладить взаимодействие в команде
это и называется организовать работу ;) Собственно скрам, канбан и весь остальной аджайл вроде именно про то, как «наладить взаимодействие в команде». Подходят ли конкретные практики для компании и команды и как они «внедряются» — это конечно отдельный разговор.
это и называется организовать работу ;) Собственно скрам, канбан и весь остальной аджайл вроде именно про то, как «наладить взаимодействие в команде». Подходят ли конкретные практики для компании и команды и как они «внедряются» — это конечно отдельный разговор.
Полтора года потрачено на предварительные невнятные работы. За три месяца до сдачи проекта наконец дело доходит с высот менеджмента до низов разработки
Классика.
Скоро сдавать один из проектов. Полгода по нему кидают десятки задач. Ничего не согласовано — менеджмент договаривается еще.
На что они рассчитывают? Не ясно.
По сути срок сорван еще на уровне менеджмента: до разработчиков задачи еще не дошли, и оставшегося времени на их реализацию им при всем желании не хватит.
Так и живем.
Отмечено, что необходимым условием я вляется компетентность команды (хотя какой смысл применения этих методик для некомпетентной команды, точнее какой в ней смысл вообще).
Хотя если команда компетентна, регулярно повышает свой уровень компетентности, то зачем ей траты времени на всякие организационные мероприятия.
Также, если на первое место выводится здравомыслие, навыки и опыт, то зачем нужна производственная иерархия
> Хотя если команда компетентна, регулярно повышает свой уровень компетентности, то зачем ей траты времени на всякие организационные мероприятия.
Команда подразумевает совместную работу над продуктом в скраме. Совместная работа предполагает необходимость договариваться, обсуждать и принимать решения. Собственно, все встречи в скраме так или иначе про это. И без этих встреч эффективность была бы хуже — лебедь, рак и щука тянули бы в разные стороны.
> Также, если на первое место выводится здравомыслие, навыки и опыт, то зачем нужна производственная иерархия
Скрам про организацию не любых работ или проектов, а только в применении к разработке продуктов в небольших (до 9 человек) кросс-функциональных командах
Команда подразумевает совместную работу над продуктом в скраме. Совместная работа предполагает необходимость договариваться, обсуждать и принимать решения. Собственно, все встречи в скраме так или иначе про это. И без этих встреч эффективность была бы хуже — лебедь, рак и щука тянули бы в разные стороны.
> Также, если на первое место выводится здравомыслие, навыки и опыт, то зачем нужна производственная иерархия
Скрам про организацию не любых работ или проектов, а только в применении к разработке продуктов в небольших (до 9 человек) кросс-функциональных командах
Вот Вы сказали 9 человек. И упомянули о кросс-функиональности. Хотелось бы знать на реальном (не гипотетическом примере) из реальной разработки кто эти девять человек. Не поименно, а по функциям, конечно.
На реальном примере: владелец продукта, 2 фронтенд разработчика, 3 бекенд разработчика.
выделенных тестировщиков — нет, но автотесты пишут разработчики, мы сознательно «убили» QA.
бизнес-аналитика в основном на плечах владельца продукта.
инжнерная часть — devops с настройкой пайпланов выкладки, мониторинг, алертинг все на стороне команды.
«Железная» часть — на стороне эксплуатации, которая не входит в команду.
выделенных тестировщиков — нет, но автотесты пишут разработчики, мы сознательно «убили» QA.
бизнес-аналитика в основном на плечах владельца продукта.
инжнерная часть — devops с настройкой пайпланов выкладки, мониторинг, алертинг все на стороне команды.
«Железная» часть — на стороне эксплуатации, которая не входит в команду.
Кроссфункциональость часто понимают как владение всеми навыками всеми членами команды. Но многие считают, что суть кроссфункционалтности в том, что в команде просто должны быть все ключевые компетенции, что команда должна быть способна "зарелизиться" без внешних блокеров. Если есть внешние зависимости (очень часто, например, дизайнеры и админы/девопсы не часть команды), то по скрам должны быть изменения в постановке задач (дизайн как часть условий, а не "вы пока пилите логику, а дизайн-отдел будет рисовать) и приёмки, например, результаты разработки не реальный релиз, а поставленная админам задача на его выкатывание.
не реальный релиз, а поставленная админам задача на его выкатывание.
Поставленная админам задача не содержит business value — краеугольного камня скрама.
Кроссфункциональость часто понимают как владение всеми навыками всеми членами команды.
Это кроссфункциональность команды состоящей из одного человека. Мне кажется, это совсем неверное понимание термина — он просто совсем не то означает (см. доступные определения)
например, результаты разработки не реальный релиз, а поставленная админам задача на его выкатывание.
как уже отметили, это очень плохой пример, противоречащий духу agile.
правильно — у команды есть реальные рычаги на админов, а еще лучше команда и админы понимают, что в общей упряжке, и решают общее дело. это все требует усилий и от команды, и от админов, но agile как раз и был ответом на потребность бизнеса — все ваши IT-шные заморочки решайте внутри себя, дайте мне, бизнесу реальный результат, я не хочу разбираться, кто из вас, разрабов или админов правее, у меня своих бизнес-проблем хватает.
В SCRUM как достичь бизнес-цели, решает проектная команда, а не руководствоДругими словами, руководство перекладывает часть своих обязанностей на команду? Логично, пусть «тыжпрограммисты» думают — они же в очках и умные. Но в чем тогда функция руководства? Увольнять и делить прибыль?
SCRUM дает власть именно тем членам команды, кто ясно формулирует здравые идеиТо есть тем, кто понаглее, и громче кричит? Кто и как определяет здравость этих идей? Каким-то общим голосованием? За кем последнее слово? Тут я серьезно спрашиваю, без сарказма.
> Другими словами, руководство перекладывает часть своих обязанностей на команду? Логично, пусть «тыжпрограммисты» думают — они же в очках и умные. Но в чем тогда функция руководства? Увольнять и делить прибыль?
В скраме функция руководства, точнее того, что не отдано на откуп команде — это обеспечение ресурсами — рабочее место, сервера и т.д, плюс верхнеуровневое целеполагание, ну и увольнять и делить прибыль, как правильно замечено. «Перекладывание» ответственности — это просто необходимость, потому что в условиях высокой неопределенности централизация менеджмента становится крайне неэффективной.
> То есть тем, кто понаглее, и громче кричит? Кто и как определяет здравость этих идей? Каким-то общим голосованием? За кем последнее слово? Тут я серьезно спрашиваю, без сарказма.
У команд есть обычно командные правила относительно того, как принимаются решения. Это может быть консенсус — все должны быть согласны или не-против, большинство — мнение большинства, это может быть апрув самого важного по функциональной части. Или все три.
Предполагается, что люди в команде обычно взрослые и зрелые и могут договорится друг с другом. Если работать в команде кому-то не нравится, или команде не нравится, как кто-то работает, совершенно спокойно можно это обсудить, для этого в скраме есть специальная встреча — ретроспектива. И по результатам, либо меняются процессы, либо, например, человек может покинуть команду.
В скраме функция руководства, точнее того, что не отдано на откуп команде — это обеспечение ресурсами — рабочее место, сервера и т.д, плюс верхнеуровневое целеполагание, ну и увольнять и делить прибыль, как правильно замечено. «Перекладывание» ответственности — это просто необходимость, потому что в условиях высокой неопределенности централизация менеджмента становится крайне неэффективной.
> То есть тем, кто понаглее, и громче кричит? Кто и как определяет здравость этих идей? Каким-то общим голосованием? За кем последнее слово? Тут я серьезно спрашиваю, без сарказма.
У команд есть обычно командные правила относительно того, как принимаются решения. Это может быть консенсус — все должны быть согласны или не-против, большинство — мнение большинства, это может быть апрув самого важного по функциональной части. Или все три.
Предполагается, что люди в команде обычно взрослые и зрелые и могут договорится друг с другом. Если работать в команде кому-то не нравится, или команде не нравится, как кто-то работает, совершенно спокойно можно это обсудить, для этого в скраме есть специальная встреча — ретроспектива. И по результатам, либо меняются процессы, либо, например, человек может покинуть команду.
в условиях высокой неопределенности централизация менеджмента становится крайне неэффективной
Спорное утверждение. Но если заменить слово «неопределенности» на «некомпетентности», то тогда ближе к правде. Глупость начальника многократно усиливается его административным рычагом, и может все разрушить. В такой ситуации отдать решения команде будет эффективнее. А руководитель пусть ретранслирует желания клиента, или сам фантазирует — назовем это целеуказанием.
Это может быть консенсус — все должны быть согласны или не-противТ.е. если два фронтендера не могут определиться с выбором фреймворка, решающие голоса будут у девопса и бэкэндера?
Предполагается, что люди в команде обычно взрослые и зрелые и могут договорится друг с другомЭх, если бы это было так — насколько лучше и спокойнее было бы в нашем мире. Не могут договориться лидеры мировых держав, не могут договориться депутаты в парламенте. Даже здесь, на Хабре, среди, казалось бы, спокойных уравновешенных айтишников, Вы легко найдете полемику на сотни комментариев. Рассчитывать, что разногласия в команде решатся «как-то сами» несколько наивно и безответственно. По факту, инакомыслящие и несогласные при такой методике из команды будут вынуждены уйти, не получив даже шанса на реализацию своих нестандартных или старомодных подходов. Останутся только приверженцы одинаковых взглядов и идей, одинаковых ценностей, как в какой-то тоталитарной секте.
> Т.е. если два фронтендера не могут определиться с выбором фреймворка, решающие голоса будут у девопса и бэкэндера?
Т.е. должен определять начальник (тим лид)? Т.е. он должен уметь разбираться прекрасно в бекенде, во фронтенде, в девопсе, в архитектуре и быть гуру разрешения конфликтов? Т.е. быть самым компетентным и самым лучшим во всем — как в софт-скиллах, так и в хард? Эх, если бы это было так — насколько лучше и спокойнее было бы в нашем мире.
> По факту, инакомыслящие и несогласные при такой методике из команды будут вынуждены уйти, не получив даже шанса на реализацию своих нестандартных или старомодных подходов. Останутся только приверженцы одинаковых взглядов и идей, одинаковых ценностей, как в какой-то тоталитарной секте.
Все так. Ровно так же как это происходит в случае начальника, который нанимает в команду только тех, кто ему нравится, с кем он может и хочет работать, и увольняет остальных. Т.е. вместо тоталитарный секты — авторитарная. Хотя какая разница какая секта, если работа сделана в срок? ;)
> Эх, если бы это было так — насколько лучше и спокойнее было бы в нашем мире.
А если конфликтов в команде много, то получается, что начальник по факту принимает все решения и чуть ли не один везет весь проект? В таком случае не проще ли научить команду саму принимать решения — дать критерии принятия решений, и помогать решать только важные и сложные конфликты?
Начальник — это очень часто ОДНА из сторон конфликта. И получается, что начальник должен разрешить конфликт, в котором он участвует. Совершенно очевидно, как будет конфликт решен и в чью пользу. И конфликты с начальником не будут разрешаться должным образом.
И по моему опыту проблема ровно обратная: конфликт разных инициатив встречается реже, чем отсутствие инициативы и проактивности со стороны разработчиков в принципе. Люди не хотят брать на себя ответственность, им проще, чтобы за них решил начальник.
Т.е. должен определять начальник (тим лид)? Т.е. он должен уметь разбираться прекрасно в бекенде, во фронтенде, в девопсе, в архитектуре и быть гуру разрешения конфликтов? Т.е. быть самым компетентным и самым лучшим во всем — как в софт-скиллах, так и в хард? Эх, если бы это было так — насколько лучше и спокойнее было бы в нашем мире.
> По факту, инакомыслящие и несогласные при такой методике из команды будут вынуждены уйти, не получив даже шанса на реализацию своих нестандартных или старомодных подходов. Останутся только приверженцы одинаковых взглядов и идей, одинаковых ценностей, как в какой-то тоталитарной секте.
Все так. Ровно так же как это происходит в случае начальника, который нанимает в команду только тех, кто ему нравится, с кем он может и хочет работать, и увольняет остальных. Т.е. вместо тоталитарный секты — авторитарная. Хотя какая разница какая секта, если работа сделана в срок? ;)
> Эх, если бы это было так — насколько лучше и спокойнее было бы в нашем мире.
А если конфликтов в команде много, то получается, что начальник по факту принимает все решения и чуть ли не один везет весь проект? В таком случае не проще ли научить команду саму принимать решения — дать критерии принятия решений, и помогать решать только важные и сложные конфликты?
Начальник — это очень часто ОДНА из сторон конфликта. И получается, что начальник должен разрешить конфликт, в котором он участвует. Совершенно очевидно, как будет конфликт решен и в чью пользу. И конфликты с начальником не будут разрешаться должным образом.
И по моему опыту проблема ровно обратная: конфликт разных инициатив встречается реже, чем отсутствие инициативы и проактивности со стороны разработчиков в принципе. Люди не хотят брать на себя ответственность, им проще, чтобы за них решил начальник.
Т.е. должен определять начальник (тим лид)? Т.е. он должен уметь разбираться прекрасно в бекенде, во фронтенде, в девопсе, в архитектуреДа, а в чем проблема? Разве тим лид не должен быть более зрелым и опытным, чем остальные члены команды? Сначала он выслушает все мнения, но решение в итоге принимает он. Я вижу такой подход более эффективным, чем псевдодемократия.
Ровно так же как это происходит в случае начальника, который нанимает в команду только тех, кто ему нравится, с кем он может и хочет работать, и увольняет остальныхТак начальник в любом случае уволит того, кто его не устраивает. Но компетентный начальник будет больше оценивать профессиональные качества сотрудника, в то время как SCRUM-начальник может оценить только софт-скиллы (т.е., проще говоря, умение работать языком).
Начальник — это очень часто ОДНА из сторон конфликтаНачальник и подчиненный изначально на разных ступенях, какой между ними может быть конфликт? Подчиненный говорит — начальник слушает. Начальник говорит — подчиненный выполняет. Не согласен с решением начальника? Выбор есть: смириться и делать, обращаться в высшие инстанции, увольняться, самому становиться руководителем.
конфликт разных инициатив встречается реже, чем отсутствие инициативы и проактивности со стороны разработчиков в принципе
Здесь интересно было бы послушать, как SCRUM мотивирует реально проявлять инициативу, а не радостно поддакивать на митингах и со всем соглашаться, оставаясь пассивным на деле. Как распределяется ответственность в команде, кто ее распределяет, и как применяется система поощрений и наказаний, если она вообще есть.
Я допускаю, что если взять группу отборных высококвалифицированных японских трудоголиков, они могут показать очень высокий результат, работая по данной системе. Но это вовсе не означает, что эту методику можно перенести на всех остальных.
> Да, а в чем проблема? Разве тим лид не должен быть более зрелым и опытным, чем остальные члены команды? Сначала он выслушает все мнения, но решение в итоге принимает он.
Одновременно разбираться во всем невозможно. Быть самым умным чуваком в команде можно только в том случае, если ты управляешь джунами-мидлами.
> Я вижу такой подход более эффективным, чем псевдодемократия.
В скраме нет задачи сделать всем хорошо, в скраме есть задача сделать качественный продукт за минимальное время.
Псевдодемократии — нет. При принятии рабочих решений есть критерий, который все знают, и которым руководствуются. Если критерий не срабатывают — идут к медиатору (и это совсем не обязательно начальник), который решает конфликт.
Демократия и обсуждения нужны для того, чтобы все понимали, что сейчас происходит. Эта прозрачность дает возможность всем принимать более качественные решения на местах.
> Так начальник в любом случае уволит того, кто его не устраивает. Но компетентный начальник будет больше оценивать профессиональные качества сотрудника, в то время как SCRUM-начальник может оценить только софт-скиллы (т.е., проще говоря, умение работать языком).
«Начальником», которые оценивает профессиональные качества сотрудником может быть функциональный руководитель — главный по фронту или главный по беку, который не входит в состав команды.
> Начальник и подчиненный изначально на разных ступенях, какой между ними может быть конфликт? Подчиненный говорит — начальник слушает. Начальник говорит — подчиненный выполняет. Не согласен с решением начальника? Выбор есть: смириться и делать, обращаться в высшие инстанции, увольняться, самому становиться руководителем.
Конфликт может быть любой — «Вася не нравится Пете-начальнику как человек, поэтому Пете Васе не дает премию». «Петя-начальник дает скучные и простые задаче Васе, Вася этим не доволен, но боится прийти к Пете, потому что его уволят». И т.д. и т.п.
Уход человека — это обычно самый плохой исход конфликта, потому что поиск нового человека и его адаптация — это очень затратно.
> Здесь интересно было бы послушать, как SCRUM мотивирует реально проявлять инициативу, а не радостно поддакивать на митингах и со всем соглашаться, оставаясь пассивным на деле. Как распределяется ответственность в команде, кто ее распределяет, и как применяется система поощрений и наказаний, если она вообще есть.
Скрам не призван решать эту проблему. Но в целом возможность брать на себя инициативу, определенная свобода в выборе технических решений и определении сроков, возможность видеть результаты своего труда вживую — это очень сильный мотиватор.
Скрам не решает проблему распределения отвтественности внутри команды. Считается, что люди сами между собой могут договорится. В целом у меня за несколько лет, в нескольких командах было не больше 5-6 конфликтов, когда люди не смогли договорится кто что делает и кто за что отвечает. И те решались на ретроспективе самостоятельно командой, либо между собой без эскалации наверх.
Система поощрений и наказаний тоже вне рамок скрама. Но обычно проста как палка — функциональный руководитель принимает решение о том поощрять человека или нет.
> Я допускаю, что если взять группу отборных высококвалифицированных японских трудоголиков, они могут показать очень высокий результат, работая по данной системе. Но это вовсе не означает, что эту методику можно перенести на всех остальных.
нельзя, поэтому главное требование к таким командам — это зрелость. Скрам не заработает в случае, если у нас склочная команда инфантильных разработчиков. Более того, в таких ситуациях скрам противопоказан.
Одновременно разбираться во всем невозможно. Быть самым умным чуваком в команде можно только в том случае, если ты управляешь джунами-мидлами.
> Я вижу такой подход более эффективным, чем псевдодемократия.
В скраме нет задачи сделать всем хорошо, в скраме есть задача сделать качественный продукт за минимальное время.
Псевдодемократии — нет. При принятии рабочих решений есть критерий, который все знают, и которым руководствуются. Если критерий не срабатывают — идут к медиатору (и это совсем не обязательно начальник), который решает конфликт.
Демократия и обсуждения нужны для того, чтобы все понимали, что сейчас происходит. Эта прозрачность дает возможность всем принимать более качественные решения на местах.
> Так начальник в любом случае уволит того, кто его не устраивает. Но компетентный начальник будет больше оценивать профессиональные качества сотрудника, в то время как SCRUM-начальник может оценить только софт-скиллы (т.е., проще говоря, умение работать языком).
«Начальником», которые оценивает профессиональные качества сотрудником может быть функциональный руководитель — главный по фронту или главный по беку, который не входит в состав команды.
> Начальник и подчиненный изначально на разных ступенях, какой между ними может быть конфликт? Подчиненный говорит — начальник слушает. Начальник говорит — подчиненный выполняет. Не согласен с решением начальника? Выбор есть: смириться и делать, обращаться в высшие инстанции, увольняться, самому становиться руководителем.
Конфликт может быть любой — «Вася не нравится Пете-начальнику как человек, поэтому Пете Васе не дает премию». «Петя-начальник дает скучные и простые задаче Васе, Вася этим не доволен, но боится прийти к Пете, потому что его уволят». И т.д. и т.п.
Уход человека — это обычно самый плохой исход конфликта, потому что поиск нового человека и его адаптация — это очень затратно.
> Здесь интересно было бы послушать, как SCRUM мотивирует реально проявлять инициативу, а не радостно поддакивать на митингах и со всем соглашаться, оставаясь пассивным на деле. Как распределяется ответственность в команде, кто ее распределяет, и как применяется система поощрений и наказаний, если она вообще есть.
Скрам не призван решать эту проблему. Но в целом возможность брать на себя инициативу, определенная свобода в выборе технических решений и определении сроков, возможность видеть результаты своего труда вживую — это очень сильный мотиватор.
Скрам не решает проблему распределения отвтественности внутри команды. Считается, что люди сами между собой могут договорится. В целом у меня за несколько лет, в нескольких командах было не больше 5-6 конфликтов, когда люди не смогли договорится кто что делает и кто за что отвечает. И те решались на ретроспективе самостоятельно командой, либо между собой без эскалации наверх.
Система поощрений и наказаний тоже вне рамок скрама. Но обычно проста как палка — функциональный руководитель принимает решение о том поощрять человека или нет.
> Я допускаю, что если взять группу отборных высококвалифицированных японских трудоголиков, они могут показать очень высокий результат, работая по данной системе. Но это вовсе не означает, что эту методику можно перенести на всех остальных.
нельзя, поэтому главное требование к таким командам — это зрелость. Скрам не заработает в случае, если у нас склочная команда инфантильных разработчиков. Более того, в таких ситуациях скрам противопоказан.
UFO just landed and posted this here
Идеология скрама произрастает из исследования Нонака и Такеуши (Ikujiro Nonaka, Hirotaka Takeuchi, 1986, "The New Product Development Game"). Они рассмотрели, как успешные компании изменяют подход к разработке новых продуктов. Раньше разработка новых продуктов проходила фазы, продукт передавался по цепочке от одного отдела другому. А подход «рэгби», как они назвали его в работе, стирает эти границы. Собирают команду, и дают им задачу. Например сделать фотокамеру компактной, надежной, простой и на 30% ниже средней рыночной стоимости. (Т.е. дают явно «невозможную» задачу)
Такая команда представляет собой «Task Force». Выкладываясь более чем на 100 %, люди работают в тесном взаимодействии друг с другом. Они притираются друг к другу и работают как одно целое.
Естественно, для такого взаимодействия необходимо, чтобы у людей не было завышенного эго, чтобы не было рангов и титулов. Каждый имеет свою сильную сторону. Каждый умеет что-то лучше других.
По моему мнению, основанному на моих наблюдениях по внедрению аджайла в нескольких командах, ключ к успеху зависит именно от этого. Насколько люди смогут отказаться от своего эго и посвятить себя общему результату.
Я думаю, что у японцев другой ментатлитет. Они черезвычайно лояльны, и никогда не проявляют своего эго. Поэтому такой подход работает в Японии. (Подумайте о Камикадзе). И успех внедрения зависит именно от того, смогут ли люди сформировать такую команду, которая будет готова на все ради цели.
Не во всех странах можно найти людей с подходящим менталитетом. А также правовые рамки могут не предусматривать такой режим работы, где человек будет самозабвенно отдавать себя всего работе.
Теперь, когда мы поняли что такое скрам как идеология, (это не столько методология, сколько в первую очередь идеология), то попробую дать ответ на вопрос, в чем же функция руководства?
Функция руководства — ставить команде цели.
И другой вопрос: за кем в команде последнее слово ?
Вопрос хороший.
В команде, как я описал ее выше, не может быть таких людей которые тянут одеяло на себя. Подразумевается, что все умеют слушать друг друга. И решение принимается командой, т.е. каждый высказал непредвзято свое мнение, его непредвзято выслушали и непредвзято выразили свои мысли. Непредвзято взвесили все за и против, и приняли решение. Если кто-то будет постоянно выпячивать свое эго — такому человеку нечего делать в команде. Вот и все. В современном скраме, есть скрам-мастер, в конце концов, который выступает в качестве модератора, и не даст никому давить других громкостью.
Поэтому подводя итог, скажу, хотите делать аджайл — берите людей в первую очередь с определенным менталитетом, а не с определенным сертификатом. Людей которые будут готовы «лечь на амбразуру». Но условием для этого, и об этом тоже говорится в статье, является то, что руководство будет давать людям свободу действий. Следить за их успехами, но давать свободу действий.
P.S.
От себя еще добавлю совет: хотите внедрять аджайл, читайте статьи не на тему «scrum», а на тему «психология команды»
Такая команда представляет собой «Task Force». Выкладываясь более чем на 100 %, люди работают в тесном взаимодействии друг с другом. Они притираются друг к другу и работают как одно целое.
Естественно, для такого взаимодействия необходимо, чтобы у людей не было завышенного эго, чтобы не было рангов и титулов. Каждый имеет свою сильную сторону. Каждый умеет что-то лучше других.
В статье говорится,
что такой подход может быть не пригоден в организациях, где разработкой нового продукта руководит «гений», который рождает на свет идею/изобретение, и спускает вниз четкую инструкцию по ее реализации. It may not apply to organizations where product development is masterminded by a genius
who makes the invention and hands down a welldefined set of specifications for people below to follow
who makes the invention and hands down a welldefined set of specifications for people below to follow
По моему мнению, основанному на моих наблюдениях по внедрению аджайла в нескольких командах, ключ к успеху зависит именно от этого. Насколько люди смогут отказаться от своего эго и посвятить себя общему результату.
Я думаю, что у японцев другой ментатлитет. Они черезвычайно лояльны, и никогда не проявляют своего эго. Поэтому такой подход работает в Японии. (Подумайте о Камикадзе). И успех внедрения зависит именно от того, смогут ли люди сформировать такую команду, которая будет готова на все ради цели.
Не во всех странах можно найти людей с подходящим менталитетом. А также правовые рамки могут не предусматривать такой режим работы, где человек будет самозабвенно отдавать себя всего работе.
В статье говорится,
что недостатком такого подхода являются возможные пиковые перегрузки до ста часов в месяц, и шестьдесят часов в месяц в остальное время.It requires extraordinary effort on the part of all project memhers throughout the span of the
development process. Sometimes, team members record monthly overtime of 100 hours during the peak and 60 hours during the rest of the project
development process. Sometimes, team members record monthly overtime of 100 hours during the peak and 60 hours during the rest of the project
Теперь, когда мы поняли что такое скрам как идеология, (это не столько методология, сколько в первую очередь идеология), то попробую дать ответ на вопрос, в чем же функция руководства?
Функция руководства — ставить команде цели.
И другой вопрос: за кем в команде последнее слово ?
Вопрос хороший.
В статье говорится,
что в команду берут не лучших специалистов, а «не-экспертов», тогда те будут вынуждены учиться и развиваться вширь. А это в свою очередь является необходимым условием для «совместного разделения труда». Second, a different kind of learning is required. Under the traditional approach, a highly competent group of specialists undertakes new product development. An elite group of technical experts does most of the learning. Knowledge is accumulated on an individual basis, within a narrow area of focus-what we call learning in depth.
In contrast, under the new approach (in its extreme form) nonexperts undertake product development. They are encouraged to acquire the necessary knowledge and skills on the job. Unlike the experts, who cannot tolerate mistakes even 1% of the time, the nonexperts are willing to challenge the status quo. But to do so, they must accumulate knowledge from across
all areas of management, across different levels of the organization, functional specializations, and even organizational boundaries. Such learning in breadth serves as the necessary condition for shared division of labor to function effectively
В команде, как я описал ее выше, не может быть таких людей которые тянут одеяло на себя. Подразумевается, что все умеют слушать друг друга. И решение принимается командой, т.е. каждый высказал непредвзято свое мнение, его непредвзято выслушали и непредвзято выразили свои мысли. Непредвзято взвесили все за и против, и приняли решение. Если кто-то будет постоянно выпячивать свое эго — такому человеку нечего делать в команде. Вот и все. В современном скраме, есть скрам-мастер, в конце концов, который выступает в качестве модератора, и не даст никому давить других громкостью.
Поэтому подводя итог, скажу, хотите делать аджайл — берите людей в первую очередь с определенным менталитетом, а не с определенным сертификатом. Людей которые будут готовы «лечь на амбразуру». Но условием для этого, и об этом тоже говорится в статье, является то, что руководство будет давать людям свободу действий. Следить за их успехами, но давать свободу действий.
P.S.
От себя еще добавлю совет: хотите внедрять аджайл, читайте статьи не на тему «scrum», а на тему «психология команды»
С фотокамерой, допустим, понятно: там неудачная идея сразу же негативно отразится на характеристиках, а через два года камера морально устареет и её выбросят.
Как быть с разработкой софта, где выбор неподходящего инструмента или технологии, на определенном этапе, может создать большие проблемы спустя годы, а чтобы это предвидеть, нужно обладать опытом в определенной сфере, которым не владеют все члены команды?
И существуют ли примеры создания серьезных ответственных вещей по данной методике? (самолет, АЭС, ракетный двигатель, другое сложное инженерное сооружение)
Как быть с разработкой софта, где выбор неподходящего инструмента или технологии, на определенном этапе, может создать большие проблемы спустя годы, а чтобы это предвидеть, нужно обладать опытом в определенной сфере, которым не владеют все члены команды?
И существуют ли примеры создания серьезных ответственных вещей по данной методике? (самолет, АЭС, ракетный двигатель, другое сложное инженерное сооружение)
Я думаю что при создании таких прорывных изделий как например буран использовались. Только называлось это программно целевое планирование и управление.
Но в том виде как сейчас это пытаются сделать вайти это конечно скорее напоминает упоминавшуюся недавно опубликованную на одном из штатовских официальных сайтах инструкцию для саботажа фашистской Германии авторства ЦРУ опубликованную по истечению срока секретности
Но в том виде как сейчас это пытаются сделать вайти это конечно скорее напоминает упоминавшуюся недавно опубликованную на одном из штатовских официальных сайтах инструкцию для саботажа фашистской Германии авторства ЦРУ опубликованную по истечению срока секретности
Очевидно, что АЭС строить или ракетный двигатель, лучше по другим подходам.
Почему?
Очевидно, из-за природы software и hardware.
В software ты можешь каждый день выкатывать релиз и проверять его пригодность на практике.
В hardware получать на сколько нибудь регулярной основе новую версию можно (в некоторых случаях) но периоды этой активности несколько больше.
Почему?
Очевидно, из-за природы software и hardware.
В software ты можешь каждый день выкатывать релиз и проверять его пригодность на практике.
В hardware получать на сколько нибудь регулярной основе новую версию можно (в некоторых случаях) но периоды этой активности несколько больше.
А ещё за десять лет до этого вышла монография Гермогена Поспелова Программно целевое планирование и управление. Вне зависимости от вопроса о приоритетах. Почему упоминание о скраме в нашем средечтатичтичесуом айти вызывает явную досаду у многих комментаторов этой статьи. Мне кажется что причина в том что наш менеджер в опять же среднестатистическом случае выбрасывает суть метода и концентрируется на внешних атрибутах, которые на самом деле не имеют никакого значения.
Можно много фантазировать о том, какие люди должны быть, но красивые рассказы о скраме обычно разбиваются о суровую реальность.
В SCRUM как достичь бизнес-цели, решает проектная команда, а не руководство. Такой метод мотивирует и стимулирует творческий подход
В реальном мире большинство людей не склонны отходить от привычных паттернов. Тем более, если нововведения предложены не ими самими. Толпой вы можете сделать очередной клон популярного сервиса. Но чтобы создать что-то по настоящему новое нужен визионер, которому не будут бить по рукам, когда он гонит очередную дичь.
SCRUM создает такую среду, в которой авторитетом пользуются не титулы и должности, а навыки и опыт.
Наоборот, он создаёт среду, где любая посредственность имеет такое же право голоса, как и опытный инженер. Звучит это, конечно, красиво, но ровно до тех пор пока такие посредственности не собираются в группы и не продавливают своё мнение большинством голосов. Можно сколько угодно высказывать свою "чёткую и обоснованную позицию", но от тебя с лёгкостью отмахнутся, воспользовавшись одним из многочисленных когнитивных искажений.
SCRUM — это хорошо, но о стратегии и об архитектуре задумываться надо.
Но кто и когда это будет делать? Если потратить N итераций вначале на проектирование, то это ничем не отличается от водопада. А если, как обычно, сразу начать пилить, то потом никакой итерации не хватит на изменение архитектуры.
За счет того, что SCRUM команды относительно маленькие, членам команды приходится осваивать весь стек технологий в рамках проекта, над которым они работают.
И насколько качественный выйдет результат, если над проектом работают люди, которые в процессе реализации только осваивают технологии?
Резюмируя: скрам — методология, как посредственной командой достичь посредственного результата за долго и за дорого, растеряв по дороге всех талантливых людей.
Как я понимаю, в большинстве проектов, которые хорошо попадают под аджайл на бищнес-уровне, рефакторинг архитектуры на техническом уровне постоянная и неотъемлемая часть процесса разработки. При груминге задач иногда нужно специально поднимать вопрос а ложится ли планируемой решение на существующую архитектуру или перед началом имплементации новых требований, нужно изменить архитектуру. Как минимум занести нелюобходимые изменения в техдолг.
рефакторинг архитектуры на техническом уровне постоянная и неотъемлемая часть процесса разработки
Рефакторинг кода. Изменение платформы, языка или хотя бы фреймворка — вещи неподъёмные.
При груминге задач иногда нужно специально поднимать вопрос
И этот вопрос всегда откладывается в долгий ящик, так как всегда можно придумать какой-нибудь влезающий в итерацию костыль. А потом костыль к костылю и тд.
В lean есть такой принцип — «defer commitment» или «decide as late as possible» — откладывать решения (тяжелые, необратимые) как можно дольше. Это не значит, что не надо об этом думать, наоборот. Но есть масса вещей которые можно сделать до принятия необратимого решения.
Создавать техдолг идет вразрез с идеологией lean. Техдолг это inventory — «запас». Его надо уменьшать. (см. Applying Lean Thinking to Software Development by Steven Peeters, 2013)
Рефакторинг архитектуры это уменьшение техдолга. Но нужно учитывать, что он сам по себе в общем случае не добавляет ценности конечному продукту. Однако, в частном случае, если задача поставлена так, что нужно, например, приложение ускорить, то тут изменение архитектуры явно корреллирует с целью. Но такую задачу можно/нужно раздробить, чтобы не одна работа не блокировала другую. Ведь есть еще и другие точки в которых можно добиться улучшения производительности.
Да, приходится думать как организовать работу так, чтобы был постоянный результат. Это часть подхода. И в моем понимании, в скраме это одна из компетенций скрам-мастера — обеспечивать «текучесть» проекта.
В техническом плане если мы хотим сначала сделать самокат, потом велосипед, потом мотоцикл, потом автомобиль — то рефакторинг архитектуры на каком-то этапе может понадобиться. Но если планировать изначально, что ты в конце концов собираешься делать автомобиль, то можно выбрать такие технические рамки (например фреймворк) которые будут позволять трансформировать продукт по ходу дела. На каком-нибудь высокоразвитом фрейворке типа spring можно делать и самокат, а можно и самолет. Просто в разные сроки. Ведь один из принципов agile это — design for change.
А если мы будем учитывать, что все может измениться, то и архитектура приложения будет максимально гибкая, где мы ничего не прибиваем гвоздями.
Проблема аджайла в том, что его продают заказчикам как «быстро и дешево», но на самом деле это не быстро и не дешево. Это гибко. Когда заказчик сам еще не знает до конца что ему нужно. Как в истории про Стива Джобса, когда ему не понравился дизайн калькулятора, и он заставлял его переделывать, пока команда не сделала ему конструктор, и он не подобрал все параметры так, как нравится ему.
Создавать техдолг идет вразрез с идеологией lean. Техдолг это inventory — «запас». Его надо уменьшать. (см. Applying Lean Thinking to Software Development by Steven Peeters, 2013)
Рефакторинг архитектуры это уменьшение техдолга. Но нужно учитывать, что он сам по себе в общем случае не добавляет ценности конечному продукту. Однако, в частном случае, если задача поставлена так, что нужно, например, приложение ускорить, то тут изменение архитектуры явно корреллирует с целью. Но такую задачу можно/нужно раздробить, чтобы не одна работа не блокировала другую. Ведь есть еще и другие точки в которых можно добиться улучшения производительности.
Да, приходится думать как организовать работу так, чтобы был постоянный результат. Это часть подхода. И в моем понимании, в скраме это одна из компетенций скрам-мастера — обеспечивать «текучесть» проекта.
В техническом плане если мы хотим сначала сделать самокат, потом велосипед, потом мотоцикл, потом автомобиль — то рефакторинг архитектуры на каком-то этапе может понадобиться. Но если планировать изначально, что ты в конце концов собираешься делать автомобиль, то можно выбрать такие технические рамки (например фреймворк) которые будут позволять трансформировать продукт по ходу дела. На каком-нибудь высокоразвитом фрейворке типа spring можно делать и самокат, а можно и самолет. Просто в разные сроки. Ведь один из принципов agile это — design for change.
А если мы будем учитывать, что все может измениться, то и архитектура приложения будет максимально гибкая, где мы ничего не прибиваем гвоздями.
Проблема аджайла в том, что его продают заказчикам как «быстро и дешево», но на самом деле это не быстро и не дешево. Это гибко. Когда заказчик сам еще не знает до конца что ему нужно. Как в истории про Стива Джобса, когда ему не понравился дизайн калькулятора, и он заставлял его переделывать, пока команда не сделала ему конструктор, и он не подобрал все параметры так, как нравится ему.
Это гибко.
Надо выделить жирным. Не быстро, не дешево, не качественно, а гибко.
Еще важно отметить agile у носителей английского, это не столько гибкий (резиновый), а сколько ловкий. Ловкий в решении проблем, которые стоят перед бизнесом. Опять же, проблем бизнеса, а не проблем ИТ.
Я бы сказал «юркий» — т.е. ему легче остановиться и развернуться.
То что гибкие проекты выпускаются быстрее (что не всегда и не обязательно так) обусловлено тем, что по сравнению с эстафетной (или водопадной, если хотите) моделью, меньше вероятности, что под конец выяснится, что сделали вообще не то что надо было и придется переделывать вообще с нуля. Этот риск действительно меньше.
Качественно оно должно быть в понимании «good enough quality» — достаточное качество. Стандартное качество, потребительское.
Дешево оно скорее всего не будет. Как я приводил в комментарии выше — люди работают в принципе в режиме кранча, с чего бы оно было дешево? Да и про стоимость вообще нигде ничего не говорится.
Т.е нужно понимать какому клиенту нужна именно гибкая разработка, а кому нет, Пихать гибкую методологию во все дыры как это сейчас делают, это, конечно, в корне неправильно.
То что гибкие проекты выпускаются быстрее (что не всегда и не обязательно так) обусловлено тем, что по сравнению с эстафетной (или водопадной, если хотите) моделью, меньше вероятности, что под конец выяснится, что сделали вообще не то что надо было и придется переделывать вообще с нуля. Этот риск действительно меньше.
Качественно оно должно быть в понимании «good enough quality» — достаточное качество. Стандартное качество, потребительское.
Дешево оно скорее всего не будет. Как я приводил в комментарии выше — люди работают в принципе в режиме кранча, с чего бы оно было дешево? Да и про стоимость вообще нигде ничего не говорится.
Т.е нужно понимать какому клиенту нужна именно гибкая разработка, а кому нет, Пихать гибкую методологию во все дыры как это сейчас делают, это, конечно, в корне неправильно.
Хорошее сравнение:, например нужно сделать ремонт в квартире. При эстафетном подходе сначала приходит один мастер, делает свое дело и уходит, приходит другой, говорит что предыдущий свое дело не доделал и он не может начинать, снова вызываем первого, тот валит на второго. И так далее, картина всем знакомая. Как было бы удобно если бы они оба сразу пришли и договорились. Это и был бы аджайл. Пришли все мастера, договорились и начали делать работу.
Будет это дешевле? Нет, не обязательно. Будет это качественней? Не обязательно. Но заказчик может прийти через два дня и внести поправки в работу. Вот и весь «фокус-покус», аккордная работа вроде бы это называется, и существовало еще до компьютеров.
Будет это дешевле? Нет, не обязательно. Будет это качественней? Не обязательно. Но заказчик может прийти через два дня и внести поправки в работу. Вот и весь «фокус-покус», аккордная работа вроде бы это называется, и существовало еще до компьютеров.
Проверить опытным путем какие по какой из методик проект будет сделан быстрее невозможно! Т.к. один и тот же проект невозможно сделать дважды той же самой командой и в то же самое время. Если основываться на чисто умозрительных на суждениях то по аджайлу проект будет выпускаться гораздо дольше, хотя по идее он принесет больше пользы заказчику. Т.к. в аджайл предполагается на первое место ставить выполнение так сказать сверьхзадачи решение проблемы заказчика а не простое следование ТЗ и выполнение пунктов договора. Теперь вопрос знатокам, насколько фирмам разработчикам это выгодно затратить уйму времени, отклониться от ТЗ не выполнить условия договора? Здается мне что разговоры о том что мы работаем по аджайлу в большей степени носят маркетинговый характер.
Когда эти методики примняются для себя например в Apple или в Пентагоне, то здесь ясно что для себя важен результат. Хотя конечно бюрократия есть всюду. А если это говориться что мы вам по аджайлу создадим что то то слабо верится
Когда эти методики примняются для себя например в Apple или в Пентагоне, то здесь ясно что для себя важен результат. Хотя конечно бюрократия есть всюду. А если это говориться что мы вам по аджайлу создадим что то то слабо верится
Теперь вопрос знатокам, насколько фирмам разработчикам это выгодно затратить уйму времени, отклониться от ТЗ не выполнить условия договора?
Настолько, насколько это выгодно заказчику.
Кого-то интересует следование ТЗ, кого-то решение конкретной проблемы.
Могу поделиться только тем, что читал:
https://en.wikipedia.org/wiki/Agile_contracts
https://martinfowler.com/bliki/ScopeLimbering.html
https://www.scaledagileframework.com/agile-contracts/
Каждый спринт может оформлять допкой к рамочному договору. В каждой допке скоуп работ и критерии приёмки.
Интересная статья, давайте обсудим.
Почему Вы пишите Scrum капсом? Это же не аббривеатура.
Книга называется «Scrum: The Art of Doing Twice the Work in Half the Time»
Во-первых, в скраме нет такого понятия, как проектная команда, есть только команда разработки и скрам-команда. Во-вторых, несмотря на то, что команда разработки может принимать участие в формировании бизнес-идеи, ответственность за этот процесс несет владелец продукта. Команда же отвечает за сам процесс поставки.
В данном контексте непонятно, что Вы имеете в виду под проектной командой. Предположу, что Вы имеете в виду скрам-команду целиком. Даже в этом случае, Ваше определение не верно. Прозрачность должна достигаться в рамках всей организации, так как стейкхолдеры могут и будут находиться за пределами скрам-команды.
«Significant aspects of the process must be visible to those responsible for the outcome. Transparency requires those aspects be defined by a common standard so observers share a common understanding of what is being seen.»
Опять же, некорректное название для ежедневного события. В скраме оно называется ежедневный скрам. Его цель — не повысить прозрачность, для этого существуют другие инструменты, а проинспектировать прогресс в сторону цели спринта и в сторону выполнения задач в бэклоге спринта.
«The Development Team uses the Daily Scrum to inspect progress toward the Sprint Goal and to inspect how progress is trending toward completing the work in the Sprint Backlog.»
Скрам отменяет все титулы, кроме разработчик.
Вот с этим я спорить не стану)
Скрам никому не дает власти — все участники равны.
Коммитят в мастер не джуны или миддлы, а команды разаработки. Вся команда несет ответсвенность за коммит.
Это, конечно, хорошие идеи, но здравый смысл подсказывает, что так и должно быть в любой организации, если это не какой-нибудь малочисленный стартап.
Проектные спринты — уши режет(
Да! Все верно!
Скрам — это не методология, и поэтому процесс обучения в нем не оговаривается) Обучение — это процесс, который в каждой организации проводится по своему. Например, митапы, о которых Вы упоминали ранее, или парное программирование.
Опять же, скрам — это не метод, это всего лишь фреймворк. Он не покрывает все аспекты деятельности организации. Скрам — это лишь способ эффективно организовать процесс разработки. В организациях помимо процессов разработки еще достаточно других процессов. Конечно, это не означает, что команды должны существовать в скрамовом вакууме, а организация должна оставаться работать по старым принципам. В этом случае скрам не будет эффективным.
Кроме того, если брать Аджайл в целом, то в первую очередь — это майндсет, а практики можно использовать разные
SCRUM
Почему Вы пишите Scrum капсом? Это же не аббривеатура.
Книга так и называется — SCRUM
Книга называется «Scrum: The Art of Doing Twice the Work in Half the Time»
В SCRUM как достичь бизнес-цели, решает проектная команда, а не руководство. Такой метод мотивирует и стимулирует творческий подход, в отличие от классического менеджмента, где сотрудникам делегируют выполнение конкретных низкоуровневых действий, а те, в cвою очередь, часто даже не понимают, для чего это и как это повлияет на проект в целом.
Во-первых, в скраме нет такого понятия, как проектная команда, есть только команда разработки и скрам-команда. Во-вторых, несмотря на то, что команда разработки может принимать участие в формировании бизнес-идеи, ответственность за этот процесс несет владелец продукта. Команда же отвечает за сам процесс поставки.
В данном контексте непонятно, что Вы имеете в виду под проектной командой. Предположу, что Вы имеете в виду скрам-команду целиком. Даже в этом случае, Ваше определение не верно. Прозрачность должна достигаться в рамках всей организации, так как стейкхолдеры могут и будут находиться за пределами скрам-команды.
«Significant aspects of the process must be visible to those responsible for the outcome. Transparency requires those aspects be defined by a common standard so observers share a common understanding of what is being seen.»
Stand-up митинги
Опять же, некорректное название для ежедневного события. В скраме оно называется ежедневный скрам. Его цель — не повысить прозрачность, для этого существуют другие инструменты, а проинспектировать прогресс в сторону цели спринта и в сторону выполнения задач в бэклоге спринта.
«The Development Team uses the Daily Scrum to inspect progress toward the Sprint Goal and to inspect how progress is trending toward completing the work in the Sprint Backlog.»
SCRUM не отменят титулов.
Скрам отменяет все титулы, кроме разработчик.
в процессе обсуждения того или иного решения главенствующим фактором является четкая и обоснованная позиция, подкрепленная личным опытом сотрудника в обсуждаемой области
Вот с этим я спорить не стану)
SCRUM дает власть именно тем членам команды
Скрам никому не дает власти — все участники равны.
Армия джунов и мидлов (синеры, как известно, стоят дорого и их мало) уверенно коммитит в master своё творчество, а заказчик спринт за спринтом пожинает блестящие результаты SCRUM.
Коммитят в мастер не джуны или миддлы, а команды разаработки. Вся команда несет ответсвенность за коммит.
Во-первых, на проекте должны работать как минимум 1-2 как можно больше опытных инженеров, которые будут пропускать через себя все коммиты в репозиторий во время code review. Во-вторых, уделять много времени обучению (не менее 3 часов в неделю) младших и средних инженеров архитектуре ПО, паттернам проектирования и тому, как это накладывается на существующий проект.
Это, конечно, хорошие идеи, но здравый смысл подсказывает, что так и должно быть в любой организации, если это не какой-нибудь малочисленный стартап.
Выполнение практических заданий можно встраивать в backlog проектных спринтов
Проектные спринты — уши режет(
Владелец продукта решает, что нужно сделать, а команда решает — как.
Да! Все верно!
Таким образом, краеугольным камнем методологии SCRUM является обучение.
Скрам — это не методология, и поэтому процесс обучения в нем не оговаривается) Обучение — это процесс, который в каждой организации проводится по своему. Например, митапы, о которых Вы упоминали ранее, или парное программирование.
SCRUM, как и любой другой метод управления проектами, имеет свои особенности и шероховатости, которые надо знать и учитывать. Несмотря на это, он дает лучший результат среди известных на сегодняшний день методов.
Опять же, скрам — это не метод, это всего лишь фреймворк. Он не покрывает все аспекты деятельности организации. Скрам — это лишь способ эффективно организовать процесс разработки. В организациях помимо процессов разработки еще достаточно других процессов. Конечно, это не означает, что команды должны существовать в скрамовом вакууме, а организация должна оставаться работать по старым принципам. В этом случае скрам не будет эффективным.
Кроме того, если брать Аджайл в целом, то в первую очередь — это майндсет, а практики можно использовать разные
Sign up to leave a comment.
Основные заблуждения о SCRUM