Собственно говоря я очень похоже отношусь к Scrum’у. Просто пытаюсь выделить из него идеи, рациональные звенья и применять то, что наиболее эффективно.

И вот как раз с самоорганизующемися командами, как по мне, достаточно большая проблема.
Как ты точно написал, а если из 10 – только 9 самоорганизовалось, а если 5 или 3?
В этом то и проблема, что в любой команде есть несколько лидеров/активных, которые и так самоорганизованы, а остальные тихонько бредут вслед.

а) К сожалению, даже реализация всех практик классического менеджмента не гарантирует успешность проекта (впрочем, это можно сказать и о Scrum, но в меньшей мере). Очень много зависит от особенностей проекта и заказчика и не зная их не берусь утверждать, что Scrum лучше или хуже классического менеджмента. В данном случае принципиальная разница лишь одна: либо это один человек, пусть и профессиональный менеджер с опытом, кто занимается реализацией всех практик, либо это несколько человек (а может и вся команда). Одна голова хорошо, а 2 лучше.

б) Никто не обещал, что команда так рррраз – и организовалась В Scrum есть определенные практики (ретроспективы, например) для постоянного улучшения процесса, что в итоге все равно так или иначе приведет к увеличению производительности, а ведь именно увеличение производительности должно быть следствием образования самоорганизующейся команды. Менеджеру ведь тоже нужно время, чтобы организовать работу команды, и вряд ли это недели, скорее месяцы. Так что все можно исправить, причем не кардинально (что есть опасно: а вдруг не в ту сторону _кардинально_ подправили), а небольшими шажками, но при этом _постоянно_ улучшая процесс и производительность.

Впрочем, идея самоорганизующейся команды – это лишь одна из практик Scrum, причем не самая важная. Не сочтите за рекламу, но на моем блоге есть статья под названием Scrum без самоорганизующейся команды. Она как раз про то, что даже в данный момент команда не смогла самоорганизоваться еще рано ее увольнять. Каждая из практик Scrum полезна сама по себе и даже в отрыве от других практик.

Ну и последний, совсем маленький комментарий. Наверное мне везло, но я почти не встречал равнодушных Пусть и Вам повезет

а) Если менеджер не может добиться хороших результатов, мы увольняем менеджера, нанимаем нового (желательно такого, у которого есть уже опыт (который можно проверить)) и он нам аккуратненько реализует практики.

Звучит, как то, что мы ищем стрелочника. На самом деле, просто есть человек, есть задача за которую он ответственнен. Делает хорошо – молодец, делает плохо – не молодец.

б) Берем команду и вдруг обнаруживаем, что она не смогла самоорганизоваться. Что будем делать дальше? Увольнять всю команду/весь отдел разработки? М… Достаточно сомнительное дело.

В целом я имею в виду, что при распределенных ответственностях, если что-то идет не так, то пиши пропало. Фактически невозможно что-то исправить.

Ну и насчет того, что команды самоорганизовываются. Я видел гигантское количество разработчиков, которым можно хоть Scrum, хоть сделай за наделю, то что обычно месяц – они просто приходят в 9 и уходят в 5 и им посрать на все методологии.

Не хочу сказать, что все такие, но тем не менее, для того, чтобы самоорганизовать нужно на самом деле много желания и энергии. И то и другое зачастую (особенно в фирмах в штатах) достаточно редкая вещь.
Проблема в том, что вне exUSSR обычно возрастной состав старше и это накладывает свой отпечаток. Во первых, энергии уже меньше, а во вторых голова у людей болит о том, что ребенок себя нехорошо чувствует и какое следующее авто купить.

И кстати, никто и никогда не утверждал, что из любая команда сможет самоорганизоваться – это одна из самых сложных задач, но, тем не менее, овчинка стоит выделки.

И еще прошу прощения, но вы забываете, что Scrum – это не пошаговое руководство «как заработать на феррари за 1 год», а набор идей. Если КОМАНДА СМОЖЕТ реализовать эти идеи – у нее будет очень хорошая производительность, стабильность и предсказуемость результатов, высокое качество кода и пр. Если не сможет – ничего этого, естественно, не будет. Но вопрос – разве в классическом менеджменте не похожая ситуация? Есть набор практик (PMBOK, например). Смог МЕНЕДЖЕР реализовать все эти практики – будет все хорошо, а не смог – будет плохо.

Scrum – не панацея и не серебрянная пуля Да, некоторая чрезмерная восторженность присутствует, но вы много знаете людей, которые реализовали Scrum в своей команде, а потом вернулись к классическому менеджменту? Лично я знаю всего нескольких людей, которые недовольны результатами работы по Scrum, но почти во всех случаях выясняется, что либо эти самые люди неверно поняли и реализовали принципы Scrum, либо условия их проекта не соответствуют требованиям Scrum (ну, например, заказчик не всегда доступен команде).

Вобщем, любые идеи нужно реализовывать с умом, а не пытаться расшибать лбы, пытаясь втиснуть идею туда, куда ее втиснуть невозможно.

Где-то я это слышал. На похожих принципах СССР вроде пытались строить.

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

Scrum это лишь слово, надо разбирать отдельные практики. Например достижение командной отвественности. Причем это самая сложная штука.

>Если конечно стать диктатором – то пожалуй да.
Человек существо увлекающееся, порой очень сложно сдержать и не переборщить. Я всего лишь предупреждаю.

>Мне достаточно тяжко видеть, что задачу которую можно решить за 30 минут, мусолят день.
Порой сложно быть перфекционистом в этом несовершенном мире:)

Если бы вы не хотели участвовать в процессе где бонус начисляется
команде, то о какой командной работе может идти речь? Цель, достижение и результат, награждение должны быть общими.

Бонус выдается один раз в год (что, как по мне, слишком редко, так как фактически исчезает связь между сделал проект хорошо – получил денюжку).

Бонус выдается 50% за личные достижения и 50% за компанейские (вот это хорошая идея).

Насчет командным бонусов… М.. Я бы НЕ хотел в таком участвовать. Боюсь, что сам очень быстро бы скатился до рукоприкладства относительно людей, которые активно расслабляются на работе.

>Анализируя ваши высказывания об авторитарном стиле и scrum, можно прийти >к выводу, что результаты труда ваших программистов вас не устраивают.

Когда руководил бизнесом, я бы сказал, что в целом меня результаты устраивали, но сейчас я вижу, как можно было получить лучшие результаты.

А еще более важно, то что как раз в тот момент когда компания начала «взрослеть», то очень уж нервно было продолжать удерживать веселую и забавную обстановку внутри компании, когда количество проблем пошло вверх.

Увы, в тот момент я о Scrum не знал. Так что мои комментарии вообще.

С Scrum’ом познакомился позже (в США) будучи наемный работником.

>Но по моему мнению авторитарный стиль усугубит ситуацию и станет только >хуже.

Если конечно стать диктатором – то пожалуй да. Если найти золотую середину – то должна улудшить.

>Кстати причина скорее всего в том что вы имеете опыт программирования и >видите неэффективность ваших >подчиненных.

Согласен. Мне достаточно тяжко видеть, что задачу которую можно решить за 30 минут, мусолят день. Кстати, даже не ведя бизнес, а будучи наемным рабочим – мне все равно тяжко видеть эту ситуацию.