Здравствуйте, DmytroL, Вы писали:


DL>Господа, мне кажется, вы спорите о полезности Скрама в контексте проекта с более-менее стабильными требованиями, который можно оценить и запланировать заранее. И именно в таком контексте Скрам действительно может проигрывать другим инкрементально-итеративным методологием с бОльшим уклоном в предварительное планирование, нежели адаптацию.

Да в принципе это понятно, просто вся эта ветка шла про "самоконтроль" бойцов скрама vs. бардак, а потом разговор скатился как всегда до общих недостатков и преимуществ.

DL>И здесь стоит вспомнить о том ( да-да, капитанствую ), что Скрам задумывался несколько для других условий, а именно — когда динамика изменения требований очень высока и строить какие-либо долгосрочные планы просто не имеет смысла. Как в таких условиях могут работать более традиционные методологии, основывающиеся на тщательном планировании — я не очень себе представляю.

Никто, не спорит, задумывался для этого и соответсвенно кое-где успешно работает (где не считают деньги и сроки, стартапы с богатыми инвесторами? гугл?). Но проповедники агила пытаются его впихнуть в любую дырку, аргументируя тем, что в любом производстве требования меняются по ходу проекта, значит "скрам это то что вам нужно, вот вам книжки и наша визитка".

Здравствуйте, goondick, Вы писали:

G>Никто, не спорит, задумывался для этого и соответсвенно кое-где успешно работает (где не считают деньги и сроки, стартапы с богатыми инвесторами? гугл?).

Мне кажется, вы полагаете третью переменную, объем функционала (scope), всегда жестко зафиксированной. В то же время, Скрам прекрасно работает в условиях ограниченного бюджета и сроков при условии, что реализованный функционал остается степенью свободы и грамотно приоритезирован. А вот в сценарии fixed-all Скрам, действительно, не работает.

К тому же, стоит вспомнить тот факт, что в Скраме в конце каждой итерации получается полностью работоспособная версия продукта (в менее ортодоксальной трактовке — версия, требующая минимальной стабилизации). Если это условие не соблюдается, то это уже не Скрам, а простите, СкрамНо Из чего следует, что бюджет и сроки контролируются с гранулярностью стоимости и продолжительности итерации, и после любой итерации заказчик может сказать "стоп!" и не остаться у разбитого корыта, как это бывает при традиционном подходе, а получить версию, где реализованы и работоспособны наиболее критичные бизнес-функции.

Для стартапов это — дополнительный бонус, так как для них важно получить хоть что-нибудь рабочее, потратив минимум бюджета и времени.

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

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

Здравствуйте, DmytroL, Вы писали:

тут, вишь ты, вот в чем фокус....

В этой ветке коллега vpedak привел аргумент в пользу эджайла/скрама/etc.:

V>То-то большинство проектов как "вываливась" из сроков и бюджета и до скрама и после и продолжают вываливаться.

Так вот, уверяю тебя: если в "традиционном" менеджменте реализованный функционал также оставить на усмотрение менеджера проекта — с определенной (и достаточно большой) степенью свободы и грамотно расставленными приоритетами фич, — то и "традиционно" управляемые проекты вдруг перестанут вываливаться из сроков и бюджета.

Здравствуйте, goondick, Вы писали:

V>>То-то большинство проектов как "вываливась" из сроков и бюджета и до скрама и после и продолжают вываливаться.

G>Человеческий фактор.

Ну да, именно его и предлагает учитывать agile (и еще то, что требования будут изменяться). Поэтому и получается лучше, чем просто квадратики рисовать в MS Project


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

дак а где я писал что оценивать не надо? Fixed price проекты они и на agile могут делаться. Понятно, что когда проект подписывают то оговаривают что вот что-то надо сделать за какое-то время и за столько-то денег.

Только это описание проекта оно высокоуровневое. Разница в том какие именно и как фичи делать и с каким качеством. Это может в несколько раз менять размер реальной работы.

G>А то, что вы промахиваетесь даже в стринте, так это уже обсуждалось выше: средне-арифметической оценкой пессимистов и оптимистов точный ответ не узнаешь. Тем более если он дается в енотах в стори поинтах. Неопытный молодой программист не сможет хорошо оценивать обьем задачи, будь он оптимистом или пессимистом. При покер-шоу несколько таких "оценщиков" и вносят интересные коррективы, что грех не ошибиться даже в краткосрочном планировании.

ну да, конечно если команда которая реально это делает не может точно оценить, то какой-то "опытный" менеджер конечно лучше оценит... Все что он обычно и делает это закладывает дополнительное время на всякие риски (ему же по башке дадут если вовремя не успеет). Поэтому чем меньше запланируешь и чем больше заложишь на всякий-случай — тем ты более защищен.

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

Ну а так как в большинстве случаев всем пофиг на реальный результат — то и agile редко где реально нужен получается. Потому что он реальность показывает и надо принимать решения за которые приходится ответ держать... А кто же такое любит?


Вячеслав Педак

Здравствуйте, SkyDance, Вы писали:

SD>3. Теперь про сами оценки. Они берутся не с потолка (т.н. "экспертные оценки"), а являются согласованным компромиссом внутри команды. Сей процесс зовется нынче planning poker — все члены команды должны согласиться с оценкой сложности. Иными словами, если Вася считает, что это 4 SP, а Петя — что 8, с помощью всех остальных членов команды будет найден компромисс. Возможно, опытный программист Вася поймет, что был неправ и был слишком оптимистичен в оценке. Возможно и другое — Петя заручится поддержкой Васи, и согласится на 4 SP. В конце концов, взрослые же люди — договорятся как-нибудь. Может, договорятся, что Вася будет делать эту конкретную фичу (и Вася знает, что у него в этом спринте на это будет время). Мы, например, еще на входе в итерацию примерно раскидывали stories по людям с учётом того, кто сколько времени планирует на следующий спринт.

Проблема planning poker в том, что он таки дает оценку с потолка, хоть и согласованную между членами команды. Это происходит из-за того, что во время оценки члены команды зачастую не знают как именно они будут эту фичу реализовывать, надеясь сориентироваться в процессе её выполнения. У них просто нет времени и возможности хорошо подумать и покопаться в исходниках. В результате получается, что в процессе выполнения итерации вдруг неожиданно выясняется, что для реализации фичи потребуется масштабный рефакторинг и данные во время покера потолочные оценки совершенно неадекватны.

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

Я являюсь одним из самых опытных разработчиков на проекте, практически не осталось такого модуля, к которому бы я не приложил руку. Разрабатываемый коробочный продукт уже пережил несколько релизов, Critical Fix'ов, куча пользователей по всему миру. Когда у меня спрашивают о поведении продукта в той или иной не самой стандартной ситуации, как правило я отвечаю, что понятия не имею, надо в исходники смотреть и в течении 10-30 минут обычно нахожу нужный кусок кода и отвечаю. Чуть менее опытный разработчик может и 4 часа ковыряться, так и не найдя искомое. И что в таких условиях можно напланировать во время planing poker'a, сидя толпой народа в переговорке, когда практически каждая фича означает встраивание нового функционала в существующую нетривиальную архитектуру, которую полностью в уме никто не может удержать?

Здравствуйте, vpedak, Вы писали:

G>>Человеческий фактор.

V>Ну да, именно его и предлагает учитывать agile (и еще то, что требования будут изменяться). Поэтому и получается лучше, чем просто квадратики рисовать в MS Project

Квадратики в МS Project? Я думаю на этом можно завершить дискуссию...


V>дак а где я писал что оценивать не надо? Fixed price проекты они и на agile могут делаться. Понятно, что когда проект подписывают то оговаривают что вот что-то надо сделать за какое-то время и за столько-то денег.

Могут делатся, но зачем?

V>Только это описание проекта оно высокоуровневое. Разница в том какие именно и как фичи делать и с каким качеством. Это может в несколько раз менять размер реальной работы.

Т.е. скрам учитывает человеческий фактор и одновременно 100% вываливание из сроков? Я вас не понимаю.


V>ну да, конечно если команда которая реально это делает не может точно оценить, то какой-то "опытный" менеджер конечно лучше оценит... Все что он обычно и делает это закладывает дополнительное время на всякие риски (ему же по башке дадут если вовремя не успеет). Поэтому чем меньше запланируешь и чем больше заложишь на всякий-случай — тем ты более защищен.

"опытный" менеджер? нет, я говорил о тимлиде, старшем программисте и ему подобных.

V>В agile же все проще. Идет оценка производительности команды и на основании ее делается оценка когда проект будет закончен.

Полгода идет оценка производительности, потом узнают сроки

V>Но это работает только тогда когда и заказчик и исполнитель заинтересованы в результате. А не просто заинтересованы в том, чтобы какую-то хрень сдали вовремя (неважно насколько она получилась хороша и полезна).

А что, бывают не заинтересованны?

V>Ну а так как в большинстве случаев всем пофиг на реальный результат — то и agile редко где реально нужен получается.

Что за бред?

V_S>Вот тут у меня возникает логичный вопрос: а кто в этом случае "оплачивает банкет"?

А что, этот вопрос никогда не возникает в "традиционном менеджменте"?
Давайте рассмотрим типичный проект. Собственно, первую версию той же софтины. Разрабатывавшуюся той же компанией и практически той же командой (сменилось не более половины программистов).
Как все это происходит? Примерно оценивается объем работ, прикидываются фичи. Прикинули — получилось оптимистично полгода. Умножили на два, заложились на год. Периодически у менеджера спрашивали — ну как, on track? Менеджер первые полгода бодро рапортовал "да даже раньше успеем, говорили же, за полгода управимся". Вторые полгода "да, вот-вот, уже чуть-чуть осталось". Потом еще полгода "вот-вот и уже выпусим бету!"
И еще некоторое время (до его ссылки в другое место) "делаем что можем, дайте еще две недели, и выкатим что-то более-менее работающее, не более чем с сотней major bugs".
Все планы и сроки были сорваны более чем на год. Да, менеджера мягко отстранили, поставили другого, много более хитрого и скользкого. Проект сдали с грехом пополам, горой багов и годами будущей мучительной поддержки. Сколько был перерасход бюджета, мне даже представить страшно. Гарантированно больше, чем 14 двухнедельных итераций сурово поредевшей команды.
Именно это и подвигло руководство к серьезному шагу — попытке реализации SCRUM. Впрочем, по рассказам оставшихся коллег, все равно в итоге вышел фейл, т.к. уж слишком прозрачен скрам, линейному менеджменту такая прозрачность что заноза в известном месте. Да и job security страдает...

Компанию называть не хочу. Кто участвовал, тот сам знает и помнит.

V>Другое дело, что это надо чтобы и руководство это понимало и двигало скрам. Т.е. чтобы ему было выгодно реально софт делать, а не просто квадратики рисовать в microsoft project...

Кстати, это я упомянул во вступительном слове. При отсутствии реальной мотивации производить софт, хоть скрам, хоть ХР, хоть RUP — все это неважно и некритично. Можно продолжать работать "будем писать, а там, глядишь, что и получится".

V>Опять же скрам очень себя плохо показал на распределенной и интернациональной команде. Просто в силу разницы во времени и национальных особенностей не сложилась команда.

Про распределенность на 100% верно, скрам годится только для локальной команды. С проблемами интернациональности не согласен, проблем между white people не возникало никогда. Есть определенные сложности с индусами (вероятно, также будут с китайцами — но у меня такого опыта нет), решаются путем избавления от индусов.

V>Так что по мне, дак скрам очень хорош для небольштх команд когда они сидят в одном месте и реально хотят что-то сделать и имеют поддержку руководства. Во всех остальных случаях — не работает...

Именно так. Команды до 10 человек (можно несколько, работающих над разными модулями), вся команда в одном офисе, реально что-то хочет сделать, и руководству реально нужна прозрачность ситуации в проекте. Этот рецепт работает.

Проблема распределенности может сниматься путем выведения из команды удаленных людей. Проблема масштабирования — как и в традиционном варианте, решается созданием нескольких команд.
Отсутствие поддержки руководства — это, понятно, 100% фейл.

G>Да запросто. Поддержка старых версий (помощь тех.саппорту по внезапно возникшим вопросам по старым версиям), поддержка QА отдела (помощь по внезапно возникшим вопросам по текущему проекту). Если с QА можно запланировать обьем времени, то с саппортом это не выйдет.

Выйдет. Мы попробовали. Сначала было непонятно, как это закладывать. Потом накопили статистику, выяснили, что 2-3 часа в неделю уходит на консультации всякого рода 3rd line support. В итоге, из "доступного времени" каждого спринта вычитали 6 часов (брали верхнюю границу, если потребуется меньше — отлично, поможем товарищам).

G>Так я и не понял, откуда у вас такое понятие, что разработчик должен "переступить через свой стыд и признатся" сколько времени он потратит на следущий спринт?

Вопрос ваш снова подчеркивает — вы никогда не пробовали это всерьез. Иначе бы он не возникал. Знаете, разработчикам как-то очень неприятно выдавать оценки "в следующие две недели только 28 часов я буду приносить пользу проекту", когда начальство (в роли silent spectator присутствующее на входе в итерацию) молчит, но цвет лица меняет с розового на багровый и алый.

G>Вы в этом уверенны? Это аксиома традиционного менеджмента? У вас был печальный личный опыт?

Да. В этом самом менеджменте описанные вами "поддержка предыдущий версий" и прочий саппорт не имеют ни четкого time-boxing'а, ни нормального планирования. Зачастую и вовсе идут по принципу "поработаете в выходной день".

G>Вот тут кстати интересно насчет самоконтроля. Поигрался народ в покер, начали спринт, потратили 15 часов на фейсбук, после замерили велосити. Новый спринт, опять фейсбук, велосити таже. В относительных числах фибоначчи все выглядит гладко. Не у кого звоночек не зазвонит.

Не зазвенит? Значит, руководство считает нормальной такую скорость команды. Ровно с тем же успехом в традиционном варианте разработчики объяснят — "вот, занимались этим и этим, успели только это". С одной лишь разницей — все это выяснится не через две недели, а через полгода, когда ничего не сделано и, соответственно, не работает. Потому что начальство поверило словам менеджера. Который, в свою очередь, также положился на разработчиков. Ну а с их точки зрения и так все работает! На их машинах.
Уверяю вас, с точки зрения менеджмента очень важно иметь прозрачное видение того, в каком состоянии проект. Именно для этого нужны спринты — итерации, на выходе из которых есть рабочий (в идеале — готовый к релизу) продукт.

G>За полтора десятка лет я чем только не занимался и даже в скраме имел честь несколько лет поучаствовать.

За несколько лет скрама вы так и не смогли понять его основ? Просите, видимо, вы ошибочно принимали СкрамНо за скрам.

G>Сколько потребуется с учетом фейсбуков — нет конечно. Но запросто может достаточно точно оценить за какое время именно данный разработчик с конкретной компетенцией ее может сделать.

"Жираф большой, ему видней" (С)
Вы заблуждаетесь. В книге Mythical Man-Month подобные заблуждения очень хорошо описаны. Рекомендую.

G>Это естественно, опиратся на экспертную сложность задачи с дальнейшим учетом способностей резработчика. Это почти что ваши стори поинты только с дополнительной точностю, т.к. учитывается индивидуальная "велосити" а не средняя по больнице.

Ага, и если Вася заболел, все оценки идут насмарку. Что уж говорить, если Вася вдруг уволится. Весь проект придется переделать, никто же не знает, что там Вася колбасил. Яркое проявление традиционного менеджмента.

G>Участвовал и проводил.

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

G>Привлекали специалистов, платили, кстати им кучу баблосов. Итог не порадовал. Скорость разработки и качество то же.

Погодите. А вы чего ожидали? Что у вас улучшится скорость или качество? Тогда вы точно обратились не туда. Эти методики нужны для получения предсказуемости и завершаемости проекта. Иными словами, для организации прозрачности и управляемости. Это инструменты для быстрой оценки любых изменений — "что будет, если мы вот это добавим, а вот это выкинем". Это способ мгновенно осознать — "если Вася уйдет, проект завершится на три месяца позднее, или придется урезать функционал, или снизими требования к багам".

SD>>В классическом scrum-by-the-book не выделяется персональная производительность члена команды.
G>Это и плохо. Очень плохо.

Для тех, кто не умеет работать с командой — может и так. Иными словами, результаты неприменимы для шарлатанства вида "аттестация" и прочих appraisal, синонимов субъективного отношения начальника к конкретному члену команды. Что уж там, скрам на святое покушается — на линейный менеджмент За что и должен быть предан анафеме.

Целью таких методик является производство продукта. Целью всякого рода "начальников" является извлечение прибыли для себя. Если эти цели находятся на одном векторе (начальник — основной бенифициар), тогда скрам катит. Если начальник получает деньги "подушно" за количество работников, скрам и agile невыгодны и обречены на провал, как верно заметил Вячеслав.

G>Да я понимаю, чем они хороши и что вы мне пытаетесь доказать. Я все это в книжках по скраму прочитал и закрепил практикой.
G>Но вы никак не видите, чем они плохи: тем, что ими не измеришь ни деньги, ни время.

Ровно так же не оценить ни время, ни деньги в предлагаемом вами подходе. Потому что оценки с потолка начальника касаемо своих подчиненных вида "Вася это сделает за три дня" ничуть не менее относительны, чем SP. Разница только в том лукавстве, с которыми преподносятся абсолютные оценки, и с тем, что следует при ошибке в прогнозе. Заметьте абсурдность ситуации — начальник оценил в 3 дня, Вася делал 8, виноват, как правило, Вася — "плохо работал".

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

Не знаю, что вы вкладываете в понятие "классика", но вполне могу в это поверить. Ничего удивительного для первых опытов с любой новой методикой. Но — есть один нюанс: в случае со скрам вся жизнь проекта сохранена в истории разработки. В любой момент было ясно, что происходит. В любой момент можно было изменить что угодно — от функционала (scope) до состава команды. Представьте, что в таком варианте происходит с "классикой".

G>И что произошло потом? Вы попросили у заказчика еще столько же денег или обьявили себя банкротом? В этом вся "прелесть" скрама. Узнать "потянем-не потянем" в середине распила.

Да, именно в этом прелесть первого опыта внедрения. Узнать всего лишь через полгода, а не через год, что ничего не выходит. И таки да, для проектов того масштаба это было весьма ранним обнаружением — по традиционному варианту, я уверен, пилили бы еще не меньше полугода (потом закрыли бы, а может, и доделали бы — для хоть какой-то компенсации убытков).

Если бы члены команды уже имели бы опыт скрам — все выяснилось бы через 2-3 месяца.

G>Я вообще не сказал, что скрам плох. Есть в нем положительные моменты, но бардака там полно, как бы вы тут его медом не мазали.

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

V_S>Хорошо. Ты можешь еще до начала проекта по скраму/эджайлу/etc. четко сказать Заказчику — когда проект будет закончен и сколько денег на это потребуется?

КО в студии. До начала проекта никакого скрама/agile нет и быть не может.

Все сколь-нибудь серьезные проекты (в т.ч. заказные) делаются поэтапно. Через стадии концепта и прототипа до RTM. Чем ближе к завершению — тем точнее оценка.
Гуглить по ключевым словам cone of uncertainty.

V_S>Так вот, уверяю тебя: если в "традиционном" менеджменте реализованный функционал также оставить на усмотрение менеджера проекта — с определенной (и достаточно большой) степенью свободы и грамотно расставленными приоритетами фич, — то и "традиционно" управляемые проекты вдруг перестанут вываливаться из сроков и бюджета.

В теории, да. На практике — нет. Потому что именно итеративная разработка с жестко выделенными критериями Definition of Done является визитной карточкой SCRUM и основной его идеей. В традиционном варианте, теоретически, итерации тоже имеют место быть. Но что я видел на практике — постоянно разобранный trunk и вечные "стабилизационные ветки".

T>Проблема planning poker в том, что он таки дает оценку с потолка, хоть и согласованную между членами команды. Это происходит из-за того, что во время оценки члены команды зачастую не знают как именно они будут эту фичу реализовывать, надеясь сориентироваться в процессе её выполнения. У них просто нет времени и возможности хорошо подумать и покопаться в исходниках.

Мы сталкивались с этой проблемой. И успешно ее преодолели итерации этак к шестой, заложив 2 часа на pre-planning meeting, время, которое как раз уходит на "посмотреть в код" и пообщаться с коллегами из других команд.
Как я уже писал — надо быть честным. Если для обдумывания фичи требуется заглянуть в код — надо учесть это время.

На planning poker команда приходит подготовленной.

V>>дак а где я писал что оценивать не надо? Fixed price проекты они и на agile могут делаться. Понятно, что когда проект подписывают то оговаривают что вот что-то надо сделать за какое-то время и за столько-то денег.
G>Могут делатся, но зачем?

Fixed all, как тот самый мифический единорог, могут делаться на чем угодно. Их все равно не существует. Основная хитрость этих самых fixed all — умение засунуть variable часть в подготовку к проекту. Которая как бы не учитывается, или учитывается по факту — например, по осознанию факта, что на подготовку и согласование всех требований ушло вот столько-то.

G>Т.е. скрам учитывает человеческий фактор и одновременно 100% вываливание из сроков? Я вас не понимаю.

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

G>"опытный" менеджер? нет, я говорил о тимлиде, старшем программисте и ему подобных.

Всегда забавлял этот подход. Вы бы хотели, чтобы Вася за вас оценивал, сколько вы потратите на ту или иную фичу? Или вы думаете, что раз вы теперь "старший программист", вам сие не грозит, и только вы будете заниматься сочинительством и гаданием по кофейной гуще за Петю и Колю?

G>Полгода идет оценка производительности, потом узнают сроки

Для команды, которая впервые в жизни столкнулась со скрам, это нормальный результат. В дальнейшем требуется меньше времени. Для сравнения можно взять новичка-тимлида. Думаете, он ошибется на меньшие величины?

G>А что, бывают не заинтересованны?

Именно так. В значительной части случаев ни команда, ни ее руководство не заинтересованы в производстве продукта. Их интерес в получении зарплаты. Чем дольше и чем в бОльшем количестве они будут ее получать, тем для них лучше. С этой точки зрения выгоднее содержать состояние проекта в тумане. И через год поставить перед фактом — надо еще год и больше людей. Компании, уже столько вложившей в проект и давшей обязательства перед партнерами, придется идти на уступки. Если бы все это было известно полгода назад — с высокой долей вероятности компания бы просто зафиксировала убытки и отменила продукт.

Здравствуйте, SkyDance, Вы писали:

SD>В теории, да. На практике — нет. [....] Но что я видел на практике — постоянно разобранный trunk и вечные "стабилизационные ветки".

По-видимому, это как раз и зависит от личного опыта. У меня это самый личный опыт — положительный: проекты были сданы в срок и уложились в бюджет. (Да, менеджились они — "традиционно", а вот объемом функционала можно было управлять....)

Здравствуйте, SkyDance, Вы писали:

V_S>>Вот тут у меня возникает логичный вопрос: а кто в этом случае "оплачивает банкет"?

SD>А что, этот вопрос никогда не возникает в "традиционном менеджменте"?
SD>Давайте рассмотрим типичный проект. Собственно, первую версию той же софтины. Разрабатывавшуюся той же компанией и практически той же командой (сменилось не более половины программистов).
SD>Как все это происходит? Примерно оценивается объем работ, прикидываются фичи. Прикинули — получилось оптимистично полгода. Умножили на два, заложились на год. Периодически у менеджера спрашивали — ну как, on track? Менеджер первые полгода бодро рапортовал "да даже раньше успеем, говорили же, за полгода управимся". Вторые полгода "да, вот-вот, уже чуть-чуть осталось". Потом еще полгода "вот-вот и уже выпусим бету!"
SD>И еще некоторое время (до его ссылки в другое место) "делаем что можем, дайте еще две недели, и выкатим что-то более-менее работающее, не более чем с сотней major bugs".
SD>Все планы и сроки были сорваны более чем на год. Да, менеджера мягко отстранили, поставили другого, много более хитрого и скользкого. Проект сдали с грехом пополам, горой багов и годами будущей мучительной поддержки. Сколько был перерасход бюджета, мне даже представить страшно. Гарантированно больше, чем 14 двухнедельных итераций сурово поредевшей команды.
SD>Именно это и подвигло руководство к серьезному шагу — попытке реализации SCRUM. Впрочем, по рассказам оставшихся коллег, все равно в итоге вышел фейл, т.к. уж слишком прозрачен скрам, линейному менеджменту такая прозрачность что заноза в известном месте. Да и job security страдает...

SD>Компанию называть не хочу. Кто участвовал, тот сам знает и помнит.

Такими страшилками обычно промывают моск на вступительном часе на скрам тренингах.

Здравствуйте, Vlad_SP, Вы писали:

V_S>Так вот, уверяю тебя: если в "традиционном" менеджменте реализованный функционал также оставить на усмотрение менеджера проекта — с определенной (и достаточно большой) степенью свободы и грамотно расставленными приоритетами фич, — то и "традиционно" управляемые проекты вдруг перестанут вываливаться из сроков и бюджета.

Если под "традиционным" менеджментом понимать итеративно-инкрементальный подход, только с более тщательным планированием и более формальным подходом к управлению требованиями, рисками и т.п. — то, разумеется, такой подход сработает не хуже аджайла. Единственное — если темп изменения требований слишком высок, то накладные расходы на перепланирование и переписывание спецификаций могут стать неоправданно высокими.

А тот "традиционный" менеджмент, который обычно ругают — это водопадная или околоводопадная модель жизненного цикла (не в смысле формальности подхода, а именно в смысле временнОй последовательности фаз).

Здравствуйте, SkyDance, Вы писали:


G>>Так я и не понял, откуда у вас такое понятие, что разработчик должен "переступить через свой стыд и признатся" сколько времени он потратит на следущий спринт?

SD>Вопрос ваш снова подчеркивает — вы никогда не пробовали это всерьез. Иначе бы он не возникал. Знаете, разработчикам как-то очень неприятно выдавать оценки "в следующие две недели только 28 часов я буду приносить пользу проекту"

Я так и не понял, что же тут неприятного если на то есть обьяснение уважительной причины?! У ваших людей проблемы с психикой или они настолько не адекватны, что не могут обьяснить причины?

G>>Вы в этом уверенны? Это аксиома традиционного менеджмента? У вас был печальный личный опыт?

SD>Да. В этом самом менеджменте описанные вами "поддержка предыдущий версий" и прочий саппорт не имеют ни четкого time-boxing'а, ни нормального планирования. Зачастую и вовсе идут по принципу "поработаете в выходной день".

Да откуда вы взяли эту чушь? Такое впечатление, что вы со школьной скамьи попали на скрам тренинг и потом в скрам команду, где и по сей день.

G>>Вот тут кстати интересно насчет самоконтроля. Поигрался народ в покер, начали спринт, потратили 15 часов на фейсбук, после замерили велосити. Новый спринт, опять фейсбук, велосити таже. В относительных числах фибоначчи все выглядит гладко. Не у кого звоночек не зазвонит.

SD>Не зазвенит? Значит, руководство считает нормальной такую скорость команды.

Как в скраме руководство может оценить скорость команды если она величина постоянная? Кстати, руководство вы имеете ввиду: скрам-мастер, продакт оунер?

SD>Ровно с тем же успехом в традиционном варианте разработчики объяснят — "вот, занимались этим и этим, успели только это".

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

SD>С одной лишь разницей — все это выяснится не через две недели, а через полгода

Почему через пол-года. Есть модули которые надо сдавать в определенные сроки, тестировать, сдавать на ревью, в QA ит.д. Отличие от скрама только в том что сроки задач более логичные и варьируются в разумных пределах в зависимости от сложности задачи, а не фиксированные искусственно-раскроенные на равные части итерации как в скраме.

SD>Уверяю вас, с точки зрения менеджмента очень важно иметь прозрачное видение того, в каком состоянии проект. Именно для этого нужны спринты — итерации, на выходе из которых есть рабочий (в идеале — готовый к релизу) продукт.

Да с чего вы взяли, что его нет в традиционной разработке? Проeкт на стадии планирования делится на модули и подзадачи, для которых определены свои сроки (кстати также с учетом техподдержки, болезней и тд.)

G>>За полтора десятка лет я чем только не занимался и даже в скраме имел честь несколько лет поучаствовать.

SD>За несколько лет скрама вы так и не смогли понять его основ? Просите, видимо, вы ошибочно принимали СкрамНо за скрам.

Я понял основы и детали, и вижу его преимущества и кучу недостатков. Может это вам надо попробовать снять розовые очки?

G>>Это естественно, опиратся на экспертную сложность задачи с дальнейшим учетом способностей резработчика. Это почти что ваши стори поинты только с дополнительной точностю, т.к. учитывается индивидуальная "велосити" а не средняя по больнице.

SD>Ага, и если Вася заболел, все оценки идут насмарку. Что уж говорить, если Вася вдруг уволится. Весь проект придется переделать, никто же не знает, что там Вася колбасил. Яркое проявление традиционного менеджмента.

Вот знание о том, что колбасил Вася вточности одинаково как в традиционной разработке, так и в скраме. Не надо опять все красить в черно-белое.

G>>Привлекали специалистов, платили, кстати им кучу баблосов. Итог не порадовал. Скорость разработки и качество то же.

SD>Погодите. А вы чего ожидали? Что у вас улучшится скорость или качество? Тогда вы точно обратились не туда. Эти методики нужны для получения предсказуемости и завершаемости проекта. Иными словами, для организации прозрачности и управляемости. Это инструменты для быстрой оценки любых изменений — "что будет, если мы вот это добавим, а вот это выкинем". Это способ мгновенно осознать — "если Вася уйдет, проект завершится на три месяца позднее, или придется урезать функционал, или снизими требования к багам".

предсказуемости и завершаемости — спасибо, посмеялся.

SD>>>В классическом scrum-by-the-book не выделяется персональная производительность члена команды.
G>>Это и плохо. Очень плохо.

SD>Для тех, кто не умеет работать с командой — может и так. Иными словами, результаты неприменимы для шарлатанства вида "аттестация" и прочих appraisal, синонимов субъективного отношения начальника к конкретному члену команды. Что уж там, скрам на святое покушается — на линейный менеджмент За что и должен быть предан анафеме.

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

SD>Целью таких методик является производство продукта. Целью всякого рода "начальников" является извлечение прибыли для себя. Если эти цели находятся на одном векторе (начальник — основной бенифициар), тогда скрам катит. Если начальник получает деньги "подушно" за количество работников, скрам и agile невыгодны и обречены на провал, как верно заметил Вячеслав.

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

G>>Да я понимаю, чем они хороши и что вы мне пытаетесь доказать. Я все это в книжках по скраму прочитал и закрепил практикой.
G>>Но вы никак не видите, чем они плохи: тем, что ими не измеришь ни деньги, ни время.

SD>Ровно так же не оценить ни время, ни деньги в предлагаемом вами подходе. Потому что оценки с потолка начальника касаемо своих подчиненных вида "Вася это сделает за три дня" ничуть не менее относительны, чем SP. Разница только в том лукавстве, с которыми преподносятся абсолютные оценки, и с тем, что следует при ошибке в прогнозе. Заметьте абсурдность ситуации — начальник оценил в 3 дня, Вася делал 8, виноват, как правило, Вася — "плохо работал".

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

G>>И что произошло потом? Вы попросили у заказчика еще столько же денег или обьявили себя банкротом? В этом вся "прелесть" скрама. Узнать "потянем-не потянем" в середине распила.

SD>Да, именно в этом прелесть первого опыта внедрения. Узнать всего лишь через полгода, а не через год, что ничего не выходит. И таки да, для проектов того масштаба это было весьма ранним обнаружением — по традиционному варианту, я уверен, пилили бы еще не меньше полугода (потом закрыли бы, а может, и доделали бы — для хоть какой-то компенсации убытков).

Опять страшилки с вводной части курса по скраму. Узнаю

SD>Если бы члены команды уже имели бы опыт скрам — все выяснилось бы через 2-3 месяца.

Все же мне интересно, что вы говорите заказчику? "Ну мы начнем делать то, что вы хотите, а через 3 месяца мы вам назовем сроки и цену. Подождите чутка, у нас опытная команда, не ищити другую фирму, плиииз"

G>>Я вообще не сказал, что скрам плох. Есть в нем положительные моменты, но бардака там полно, как бы вы тут его медом не мазали.

SD>Как раз бардака — минимум.

Не хаос конечно, но бардака очень много.

Здравствуйте, SkyDance, Вы писали:


G>>Т.е. скрам учитывает человеческий фактор и одновременно 100% вываливание из сроков? Я вас не понимаю.

SD>Скрам не манипулирует сроками. Само понятие срока в скрам отсутствует. Есть только итерации, спринты. Если вы годами работали по скрам, зачем вы задаете такие вопросы?

понятие срока в скрам отсутствует, но в планировании и менеджменте присутствует у любого проекта и вываваливание из сроков это как раз из вашего примера как через полгода узнают что "непотянут"

G>>"опытный" менеджер? нет, я говорил о тимлиде, старшем программисте и ему подобных.

SD>Всегда забавлял этот подход. Вы бы хотели, чтобы Вася за вас оценивал, сколько вы потратите на ту или иную фичу? Или вы думаете, что раз вы теперь "старший программист", вам сие не грозит, и только вы будете заниматься сочинительством и гаданием по кофейной гуще за Петю и Колю?

нет никакого гадания. У вас просто мало опыта, скорее всего. Потом никто и не говорил, что тимлид ставит сроки в одиночку. Он таки общается со всеми программистами, просто учитывает их оценки с дополнительным индивидуальным коэффициентом.

G>>Полгода идет оценка производительности, потом узнают сроки

SD>Для команды, которая впервые в жизни столкнулась со скрам, это нормальный результат. В дальнейшем требуется меньше времени. Для сравнения можно взять новичка-тимлида. Думаете, он ошибется на меньшие величины?

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

G>>А что, бывают не заинтересованны?

SD>Именно так. В значительной части случаев ни команда, ни ее руководство не заинтересованы в производстве продукта. Их интерес в получении зарплаты. Чем дольше и чем в бОльшем количестве они будут ее получать, тем для них лучше. С этой точки зрения выгоднее содержать состояние проекта в тумане. И через год поставить перед фактом — надо еще год и больше людей. Компании, уже столько вложившей в проект и давшей обязательства перед партнерами, придется идти на уступки. Если бы все это было известно полгода назад — с высокой долей вероятности компания бы просто зафиксировала убытки и отменила продукт.

Вы хотите сказать, что скрам полезно и нужно применять в командах, где малая заинтересованность в конечном продукте, для полного контроля ситуации со стороны заказчика? Т.е. он раз в три недели будет присутствовать на демонстрационных показах фич в конце спринта и тем самым контролировать, если его не кинут со сроками и деньгами? А если там все сгнило внутри (лишь бы уложится в итерацию) и ближе к концу проекта начинаются постоянные рефакторинги, скорость и качество падают потому что первые итерации говнокодили в основном для демо? Где контроль? Скрам не содержит сосотяние проекта в тумане?

Здравствуйте, goondick, Вы писали:

G>Здравствуйте, SkyDance, Вы писали:

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

SD>>С одной лишь разницей — все это выяснится не через две недели, а через полгода

G>Почему через пол-года. Есть модули которые надо сдавать в определенные сроки, тестировать, сдавать на ревью, в QA ит.д. Отличие от скрама только в том что сроки задач более логичные и варьируются в разумных пределах в зависимости от сложности задачи, а не фиксированные искусственно-раскроенные на равные части итерации как в скраме.

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

И вопрос здесь даже не в сроках. Скрам (да и весь Agile) не пытается решить проблему определения сроков всего проекта. Но при этом позволяет оперативно реагировать на ситуацию и балансировать в рамках треугольника сроки/качество/функционал. Если все три параметра фиксированы, ничего нового и интересного (кроме раннего обнаружения невыполнения проекта) вы не получите.

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

И все вышесказанное справедливо даже при том, что ТЗ фиксированное. А оно далеко не всегда фиксированное. Клиент, увидев начальный результат, может что-то изменить в проекте. Оказывается, какие-то задачи он может выполнить раньше/более простыми средствами, но при разработке ТЗ забыл совершенно про другую важную задачу.

SD>>Уверяю вас, с точки зрения менеджмента очень важно иметь прозрачное видение того, в каком состоянии проект. Именно для этого нужны спринты — итерации, на выходе из которых есть рабочий (в идеале — готовый к релизу) продукт.

G>Да с чего вы взяли, что его нет в традиционной разработке? Проeкт на стадии планирования делится на модули и подзадачи, для которых определены свои сроки (кстати также с учетом техподдержки, болезней и тд.)

Вы забываете самый большой риск для "модульного" проекта — интеграция всех модулей в единое целое. Ее очень сложно планировать, там всплывают различные баги, допущенные на начальных этапах (что-то не оттестировали, что-то не заложили в спецификацию). В хронических случаях может доходить до того, что проще переделать какой-то модуль, чем интегрировать его в остальную систему. Гораздо более реалистичным и управляемым является не план в терминах "модулей", а в терминах "функциональность, реализуемая продуктом". Т.е. интеграция с самого начала. А это основной постулат вообще всех Agile. И наличие/отсутствие функциональности прекрасно видно (в отличие от модулей, которые по-отдельности работают хорошо, но нужно потратить кучу времени на их интеграцию). Ну а дальше добавляем различные стратегии оперативного управления и получаем различные варианты Agile.


SD>>>>В классическом scrum-by-the-book не выделяется персональная производительность члена команды.
G>>>Это и плохо. Очень плохо.

SD>>Для тех, кто не умеет работать с командой — может и так. Иными словами, результаты неприменимы для шарлатанства вида "аттестация" и прочих appraisal, синонимов субъективного отношения начальника к конкретному члену команды. Что уж там, скрам на святое покушается — на линейный менеджмент За что и должен быть предан анафеме.

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

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

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

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

Ах да, забыл. Здесь больше всего страдает менеджер, а не программисты . Вот ему не получится изображать бурную деятельность и валить все проблемы на программистов. Работать ему придется, объяснять заказчикам и программистам, какие задачи решает scrum или любой другой процесс разработки. Следить за текущим состоянием дел, анализировать проблемы, принимать меры к их устранениню. Но если не лениться это делать, и менеджер/мастер может гордиться результатами своего труда (а также сроками/качестовм и т.п.) и продуктом, который команда сделала.

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

А вы с юниорами тесно работали? Нельзя узнать, сколько у юниора займет более-менее реальная задача. Можно дать кодить готовый дизайн, но это совсем не интересно и юниора не тренирует. А если давать что-то чуть более сложное, возможны варианты:
1. Начальное решение будет "совсем не в тему". Это нужно отлавливать, предлагать (именно предлагать, а не навязывать) свое решение, обсуждать варианты и т.п.
2. Решение в более/менее предлагаемом варианте. Тут просто нужно следить за скоростью реализации.
3. Предложен вариант лучше, чем предполагался. Здесь скорость реализации будет даже быстрее, чем изначально планировалось.
4. Предложен "оригинальный" вариант и сложно сказать, что выйдет. Здесь нужно экспериментировать, смотреть. И нужно сам процесс принятия решения организовывать.
В общем, не все так просто. Тот же scrum предполагаемое решение согласует на scrum-meeting'е и со сроками будет определенность.

А еще производительность плавает по мере набора опыта и т.п. И переход от "пишем в три итерации под надзором" до "оно работает и есть интересные решения". Плавает она и по внешним причинам (как и у других членов команды). И уж тем более плохо с оценкой новых задач для Junior'а. Может, он не делал ничего ни разу, но у него отличная теоретическая подготовка и задачу он сделает быстро. Или, наоборот, не получается у него какая-то одна тема (даже у опытных разработчиков есть слабые и сильные места).

В общем, с юниорами как раз получается "agile в миниатюре" с планированием в рамках "небольшой командной итерации" и этапами "1-2 дня", контролем, принятием при необходимости мер и т.п. И ни в коем случае не "классическое планирование".

SD>>Если бы члены команды уже имели бы опыт скрам — все выяснилось бы через 2-3 месяца.

G>Все же мне интересно, что вы говорите заказчику? "Ну мы начнем делать то, что вы хотите, а через 3 месяца мы вам назовем сроки и цену. Подождите чутка, у нас опытная команда, не ищити другую фирму, плиииз"

Нормальному заказчику в общих чертах объясняется процесс. То, что через 2 недели будет минимальный набор функциональности, через 1 месяц функциональности будет чуть больше и т.д. И при этом по завершении двухнедельной итерации можно будет покрутить продукт, спланировать его дальнейшее развитие и т.п. Можно также рассказать о типичных сложностях планирования "fixed cost", незавершающихся проектах и т.п. Ну да, заказчику придется поднапрячься и понять, что же будет происходить. Но зато если он разберется, получит возможность управлять затратами, возможность закрыть проект (если он не выгоден) и т.п. Это нормальное управление рисками. А вот "отдать проект реализовывать на три месяца без вестей с фронта" можно только если за просрочку/недостаточную функциональнось предусмотрена хорошая неустройка. Но ведь не пойдут на это компании, разрабатывающие по классике.

Здравствуйте, goondick, Вы писали:


G>>>Полгода идет оценка производительности, потом узнают сроки

SD>>Для команды, которая впервые в жизни столкнулась со скрам, это нормальный результат. В дальнейшем требуется меньше времени. Для сравнения можно взять новичка-тимлида. Думаете, он ошибется на меньшие величины?

G>Представьте на минуточку разбить задачу на подзадачи, оценить сроки выполнения подзадач. По мере реального выполнения подзадач корректировать сроки или ресурсы проекта.

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

Да и корректирование "срок/ресурсы" — это уже шаги к Agile (большой план вам только зависимости между компонентами будет показывать). Но нужно еще и функционал корректировать. Может быть выгоднее менее функциональная программа в более короткий срок, чем полнофункциональная программа за долгий срок.

G>>>А что, бывают не заинтересованны?

SD>>Именно так. В значительной части случаев ни команда, ни ее руководство не заинтересованы в производстве продукта. Их интерес в получении зарплаты. Чем дольше и чем в бОльшем количестве они будут ее получать, тем для них лучше. С этой точки зрения выгоднее содержать состояние проекта в тумане. И через год поставить перед фактом — надо еще год и больше людей. Компании, уже столько вложившей в проект и давшей обязательства перед партнерами, придется идти на уступки. Если бы все это было известно полгода назад — с высокой долей вероятности компания бы просто зафиксировала убытки и отменила продукт.

G>Вы хотите сказать, что скрам полезно и нужно применять в командах, где малая заинтересованность в конечном продукте, для полного контроля ситуации со стороны заказчика? Т.е. он раз в три недели будет присутствовать на демонстрационных показах фич в конце спринта и тем самым контролировать, если его не кинут со сроками и деньгами? А если там все сгнило внутри (лишь бы уложится в итерацию) и ближе к концу проекта начинаются постоянные рефакторинги, скорость и качество падают потому что первые итерации говнокодили в основном для демо? Где контроль? Скрам не содержит сосотяние проекта в тумане?

Таки не держит. Нету в скраме (да и другом agile) демо. Просто нет! Есть полноценный программный продукт с урезанной (может быть — очень сильно) функциональностью. И заказчик видит продукт не на презентации, а у себя. Уже после первой (это в идеале, но в любом случае после небольшого количества) итерации производится внедрение. Все, можно гонять, искать баги, проверять функциональность. Если за следующую итерацию заказчик не нашел бага, видимо, это совсем не критичный баг (за 2-3 недели функция не проверялась или не использовалась, например).

С деньгами "по-крупному" при таком подходе кинуть сложно. Продукт же передается заказчику и риск в пределах 1-3 итераций (зависит от активности использования и т.п.). Явно меньше, чем при водопаде на полгода. А то, что внутри, никого при грамотном риск-менеджменте не интересует. Вся критичная/важная функциональность будет реализована в начальных итерациях и если какие-то рюшечки сдохнут под тяжестью проекта, почти никто расстраиваться не будет (ну да, разработчики во главе с менеджером меньше денег получат).