B>Это так. Но любая идея собирает вокруг себя людей определенного типа.
B>Ортодоксальность многих последователей Agile — это следствие методов,
B>с помощью которых Agile продвигается в "массы".

Не совсем понимаю, что имеется в виду. Агрессивного продвижения Agile в стиле "Гербалайф" я не видел (хотя, опять же, допускаю существование подобного).

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

B>Ты был на официальных курсах по тому же SCRUM?
B>Тот еще brainwashing...

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

Здравствуйте, Аноним, Вы писали:

А>Вот скажем я програмю . А дальше ?

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

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

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

G>>Как в манифесте такого нет? а это: "self-organization and motivation". Если двух "индусов" посадить по парам, они "саморганизуются"?
B>Самоорганизация не обозначает отсутствие контроля возведенное в абсолют.

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

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

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

Просто методы контроля другие. Как известно, мотивация бывает лишь одного вида — самомотивация, когда сотрудник решает "надо бы поработать", и работает. Руководству важно знать перспективы проекта: что и когда будет сделано. Именно эти проблемы решают некоторые вариации Agile-процессов, в т.ч. пресловутый SCRUM.

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

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

SD>Это очень скользкая тема, "больше" или "меньше" контроля.
SD>Визуально контроля может и меньше (т.к. над разработчиками не стоит тимлид с бамбуковой палкой).
SD>Но на практике, контроль куда более строгий: текущее состояние проекта известно в любой момент. В отличие от "традиционной" разработки, когда вроде бы "все готово, но вот здесь надо немножко доделать — немножко, это сколько? — ну, наверное, две недели (и так каждые 2 недели)".

Каким образом оно известно? Со слов разработчика на стенд-ап митинге?

SD>Просто методы контроля другие. Как известно, мотивация бывает лишь одного вида — самомотивация, когда сотрудник решает "надо бы поработать", и работает. Руководству важно знать перспективы проекта: что и когда будет сделано. Именно эти проблемы решают некоторые вариации Agile-процессов, в т.ч. пресловутый SCRUM.

Как эти проблемы решает скрам? Мой практический опыт показал вточности наоборот. В скраме проект делят на задачи и оценивают сроки сами разработчики. Что сренде-статистический разработчик может оценить, это классическая тема шуток по типу умножаем на 3, но т.к. тут нет тим-лида, никто ни на что не умножает. В итоге таски запиханные в спринты не выполняются вовремя и разработчики начинают кормить "на следущей неделе", "в следущем спринте" отмазками.
Мне кажется, намного логичнее дать оценить сроки выполнения проекта главному программисту, который знает, что:
"вот этот модуль А быстро сделает Петя примерно за столько и столько, он делал подобное на прошлом проекте, сложно, но он в теме, 3-4 недели"
"вот это будет делать Ваня, он новичек, пусть поковыряется 2-3 недель так как в теме не шарит, как раз модуль Х будет готов к тому времени для интеграции.."
"эту задачу будет делать Дима, ему хватит 3 недели, закончит раньше поможет Пете" итд. итп.
А в скраме: Ваня, ты что хочешь делать. Ваня я хочу делать модуль А, я с этой платформой никогда не работал, интересно попробовать. Сколько времени займет? Слюнявит палец, выставляет по ветру, 1 неделю., Петя опытный программист, берет себе оставшийся скучный таск для "юниоров", оценивает его в 2 недели, (пока Ваня курит новою платформу и кормит "следущими неделями"), делает не спеша прореживая форумами и одноклассниками — Это хорошая информация для начальства или нет? Кто делает ваш строгий контроль в данном случае? Скрам-мастер? Так он не в курсе о способностях конкретного разработчика, и даже если в курсе, тут только можно развести руками: чек выбрал новую для него тему, ну естественно надо курить документацию, ну естественно перенесем в следущий спринт.... Это хорошие методы контроля?

G>Каким образом оно известно? Со слов разработчика на стенд-ап митинге?

Зачем же так сложно.
Все в том же SCRUM — с результатов итерации — принятых user stories. Поскольку принимаются только те фичи, которые действительно *сделаны* (D of Done), состояние проекта прослеживается лучше, чем со слов менеджера проекта. которому тоже напели разные программисты и тестировщики.

G>Как эти проблемы решает скрам?

В точности так, как написано в книгах и рассказывают в курсах. Другое дело, что мало кто в состоянии сделать scrum by the book, все обязательно считают своим долгом внести свою нетлёнку в это дело, и непременнейшим образом получить scrumbut.

G>Мой практический опыт показал вточности наоборот. В скраме проект делят на задачи и оценивают сроки сами разработчики. Что сренде-статистический разработчик может оценить, это классическая тема шуток по типу умножаем на 3, но т.к. тут нет тим-лида, никто ни на что не умножает. В итоге таски запиханные в спринты не выполняются вовремя и разработчики начинают кормить "на следущей неделе", "в следущем спринте" отмазками.

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

G>Мне кажется, намного логичнее дать оценить сроки выполнения проекта главному программисту, который знает, что:
G>"вот этот модуль А быстро сделает Петя примерно за столько и столько, он делал подобное на прошлом проекте, сложно, но он в теме, 3-4 недели"
G>"вот это будет делать Ваня, он новичек, пусть поковыряется 2-3 недель так как в теме не шарит, как раз модуль Х будет готов к тому времени для интеграции.."
G>"эту задачу будет делать Дима, ему хватит 3 недели, закончит раньше поможет Пете" итд. итп.

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

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

Это совершенно точно не скрам. Основная проблема Agile (и scrum в т.ч.), что все читали книжки, но никто их не понял. Потому что правильная реализация того же скрам невероятно проста. И в этом подвох, все начинают додумывать что-то своё, вместо scrum by the book поначалу и meta-scrum в дальнейшем.

То, что вы описали — традиционный раздолбай-менеджмент. Потому что в скрам все делается иначе.

Собирается вся команда. Сначала спрашивают — "Вася, сколько часов в следующем спринте (2 недели длиной) ты ожидаешь проработать с пользой?" Вася честно отвечает — "36 часов, потому что 3 дня на следующей неделе я проведу с женой и новорожденным, 2 дня я потрачу на исправление того-то и того-то для другой команды, и 4 часа каждые 2 недели мы тратим на вход/выход из итерации".
Потом этот же вопрос задают Пете. Петя оценивает реальную трудоспособность в 52 часа (80 часов — это 2 недели спринта, минус 3 дня запоя, минус 4 часа митингов).
Итогом этого мероприятия становится общее число теоретических часов, которые есть у команды. Эту цифра, вообще говоря, начальство может повергнуть в шок (т.к. легко выясняется, что половина времени команды уходит на непродуктивную ерунду), и начальство может завопить "аа-а-а-а-а никого не пущу в отпуск и всем запрещаю помогать другим командам". В этот момент важно не дрогнуть духом и не прогнуться при виде красной морды и воплей. Важно просто зафиксировать эту самую реальную оценку возможностей команды. В конце концов, можно ее даже и не показывать начальству (хотя это нарушит прозрачность процесса и суть скрам потеряется).

Далее, у команды есть список фич будущего продукта — backlog. Все они представляют собой сценарии работы пользователя. И все они имеют оценку сложности, но не в бессмысленных "2 недели" или "3 дня", а в относительных величинах (story points, SP): самая простой и легко реализуемый сценарий имеет сложность 1, остальные сценарии оцениваются относительно. Причем оценки эти не "от фонаря", и имеют вполне определенный ряд градаций. Кто-то применяет 1-2-4-8-16-32, кто-то ряд Фибоначчи (1-2-3-5-8-13-21), это некритично. Важен лишь факт, что ряд этих оценок фиксирован и конечен. Если какому-то сценарию хочется дать оценку "больше самой большой", значит, сценарий ошибочен (неатомарен или просто кривой), надо его разбивать на части или просто от него отказываться.

Далее, команда смотрит свою историю предыдущих спринтов. В ней видно, что имея 240 командных часов на спринт, команда в среднем заканчивает сценариев на 18 story points. Но в этом спринте у команды всего 180 часов (из-за ребенка Васи и запоя Пети), что позволяет набрать сценариев не более чем на 14 SP.

Что получается?

Команда реалистично оценивает свои возможности (как в виде того самого фокус-фактора, отношения "идеальных" и реальных рабочих часов, так и в виде количества SP/hr — т.н. velocity). Начальство, имея backlog, в любой момент может прикинуть, сколько еще пилить до релиза. Также упрощаются традиционные менеджмент-задачи вроде "а что будет, если мы Юру добавим к этому проекту" или "а если мы Васю насовсем отдадим в ту команду".

G>Кто делает ваш строгий контроль в данном случае? Скрам-мастер? Так он не в курсе

Вы совсем не поняли ни скрам, ни Agile в целом. Ваш подход традиционен для постсоветского гражданина: "над каждым поставить надсмотрщика с плёткой". Проявление этого эффекта я наблюдаю уже много лет (нынче, правда, со стороны) — в виде политической и экономической системы стран бСССР. Но попробуйте понять: руководству в первую очередь важны ответы на вопросы "что и когда будет реально сделано". Традиционный подход с экспертными оценками не в состоянии учитывать достаточное количество факторов. Кроме того, он негибок и требует постоянного вовлечения эксперта в проект. И даже в таком случае эксперт будет ошибаться. Доказано годами практики.
Описанный мной подход не заставит команду работать быстрее или лучше. Но при неукоснительном его соблюдении даст полную и прозрачную картину.

Настолько полную и прозначну, что, увы, руководство может решить закрыть проект, поняв, сколько на самом деле этот проект будет стоить. Ситуация реальная — принимал в этом непосредственное участие. Самое забавное — какой урок из этого вынесли сотрудники: "скрам — плохо, потому что проект закрывают, если бы не скрам, еще могли бы много лет тянуть и в ус не дуть". Это я к тому, что failure to implement scrum может быть вызвано разными причинами, в том числе и нежеланием сотрудников выставлять грязное бельё проекта на всеобщее обозрение. Тут требуется очень большая сила воли со стороны руководства. И, само собой, трезвое отношение оного руководства к реальности. Настоящей реальности, а не той, что создается отчетами линейными менеджерами.

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

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

SD> общее число теоретических часов, которые есть у команды.
SD> не в бессмысленных "2 недели" или "3 дня", а в относительных величинах (story points, SP): самая простой и легко реализуемый сценарий имеет сложность 1, остальные сценарии оцениваются относительно. Причем оценки эти не "от фонаря", и имеют вполне определенный ряд градаций. Кто-то применяет 1-2-4-8-16-32, кто-то ряд Фибоначчи (1-2-3-5-8-13-21), это некритично.
SD>Далее, команда смотрит свою историю предыдущих спринтов. В ней видно, что имея 240 командных часов на спринт, команда в среднем заканчивает сценариев на 18 story points. Но в этом спринте у команды всего 180 часов (из-за ребенка Васи и запоя Пети), что позволяет набрать сценариев не более чем на 14 SP.

Поймите уже наконец, что меняя шило на мыло: реальную временную оценку на поинты делу не поможет, потому что это все та же сверическо-вакуумная оценка времени выполнения проекта. Если стори весит 4SP, то для одного программиста она будет занимать неделю а для другого 2 дня, и наоборот для другой задачи.

SD> Команда реалистично оценивает свои возможности
средняя продуктивность среднего программиста помноженная на среднее время реального участия людей в команде с учетом среднестатицтической вероятности ухода в запои или задержек из-за курения новой документации?
Тим-лид также точно расчитать возможности своей команды только не в поинтах а в часах и даже с учетом запоев Пети.

SD> Начальство, имея backlog, в любой момент может прикинуть, сколько еще пилить до релиза.
А как же: "Но в этом спринте у команды всего 180 часов (из-за ребенка Васи и запоя Пети)"? Что они прикинут, если все спринты разные по количеству времени даже если velocity постоянная (сферически в вакууме), хотя и это не факт, потому что стори оцененная на 8SP к середине проекта может поменяться на 16 из-за того что это "команда оценила свои возможности" при составлении бэклога в начале проекта полгода назад. и тд. итп.

G>Да, я написал немного упрощенно, но смысл не меняется.

Да, вы написали упрощенно, отчего смысл не то что не поменялся, а потерялся вовсе.

G>Бардак не у нас в непонимании скрама а в самом скраме при разношерстной комманде (а идеальных комманд с равными по силе программистами практически нигде не встретишь, клонировать людей еще не научились).

"Вы не поверите" (С), первые 8-9 итераций мы тоже все хотели свалить на "разношерстные команды", "разношерстных людей в команде" и т.п., а потом просто привыкли, прониклись, набрали статистику и собрались, наконец, с духом — стали честно заявлять планируемые часы работы. Это один из самых сложных моментов, мужественно признаться себе и начальству, что половина времени уходит впустую. Отмечу, что в будущем это признание привело к положительному эффекту — нам разрешили создать некое "входное тестирование". Поясню: мы пользовались платформой, создаваемой другой командой (которая, в теории, должна была учитывать наши интересы, но на практике — плевала на нас с высокой колокольни и делала что хотела). До осознания, сколько времени уходило на борьбу с этой "платформой", нас заставляли собирать все грабли каждого очередного изменения в "платформе". После демонстрации того, сколько на это уходит, нам разрешили создать входные тесты. Если тесты не проходят — мы не переходили на новую версию.

G>Поймите уже наконец, что меняя шило на мыло: реальную временную оценку на поинты делу не поможет, потому что это все та же сверическо-вакуумная оценка времени выполнения проекта. Если стори весит 4SP, то для одного программиста она будет занимать неделю а для другого 2 дня, и наоборот для другой задачи.

Вы в очередной раз демонстрируете непонимание как Agile, так и того, откуда и почему берутся оценки.
Давайте по пунктам.
1. "Реальную временную оценку" разработчик дать не может. Читайте Mythical Man-Month, там очень хорошо объяснено, почему. Вкратце: любой программист дает оценку "сколько часов/дней/месяцев делать". Делать именно эту конкретную задачу. Но у разработчика кроме этой задачи всегда есть другие — отчеты, баги, запои, разборки с тестированием. Даже если это опытный программист, который очень в теме и может точно сказать "вот ту штуку делать 3 дня" — это не значит, что через 3 дня "штука" будет готова. Кстати, это одна из любимых ловушек менеджеров: "Вася, сколько делать А? — 3 дня. — Вася, а Б? — 2 дня. — Окей, делай параллельно, через 4 дня жду что все будет готово".
2. Ключевой элемент SP — относительность оценки. Что дает автоматическую коррекцию времени выполнения задач исходя из доступного времени. Пример на пальцах: команда сделала оценки фич А (8 часов), Б (11 часов) и В (21 час). Начали делать Б — на нее ушло 19 часов. Хороший тимлид в этот момент попросит провести переоценку задач А и В. Обычный менеджер даже и не подумает это сделать, но будет ожидать, что на А все так же потребуется 8 часов, на В — 21. Теперь представьте, что сценарии оценивали бы в SP (например, по методу ряда Фибоначчи) — соответственно, 1 SP, 2SP, 3 SP. После завершения Б за все те же 19 часов даже плохонький тим-лид бы догадался, сколько времени потребуется на А и В. Трюк, казалось бы, дешевый — отвязать сложность фичи от времени. Но работает железно.
3. Теперь про сами оценки. Они берутся не с потолка (т.н. "экспертные оценки"), а являются согласованным компромиссом внутри команды. Сей процесс зовется нынче planning poker — все члены команды должны согласиться с оценкой сложности. Иными словами, если Вася считает, что это 4 SP, а Петя — что 8, с помощью всех остальных членов команды будет найден компромисс. Возможно, опытный программист Вася поймет, что был неправ и был слишком оптимистичен в оценке. Возможно и другое — Петя заручится поддержкой Васи, и согласится на 4 SP. В конце концов, взрослые же люди — договорятся как-нибудь. Может, договорятся, что Вася будет делать эту конкретную фичу (и Вася знает, что у него в этом спринте на это будет время). Мы, например, еще на входе в итерацию примерно раскидывали stories по людям с учётом того, кто сколько времени планирует на следующий спринт.

На эту тему, кстати, рекомендую хорошую книжку Agile Estimating and Planning. Не уверен, что она есть на русском языке, но, надеюсь, для менеджера-то не станет проблемой прочитать ее в английском варианте. Думаю, она снимет значительную часть вопросов и претензий.

G>средняя продуктивность среднего программиста помноженная на среднее время реального участия людей в команде с учетом среднестатицтической вероятности ухода в запои или задержек из-за курения новой документации?

Нет. Исторически подтвержденная производительность команды в целом. В scrum зовется velocity. А также отношение полезно проведенного времени к полному рабочему времени (focus factor).

G>Тим-лид также точно расчитать возможности своей команды только не в поинтах а в часах и даже с учетом запоев Пети.

Выше уже объяснено, почему тим-лид это сделает с низкой точностью. Кстати, тим-лид в scrum не нужен, scrummaster — это несколько иная роль.

G>А как же: "Но в этом спринте у команды всего 180 часов (из-за ребенка Васи и запоя Пети)"? Что они прикинут, если все спринты разные по количеству времени даже если velocity постоянная (сферически в вакууме), хотя и это не факт, потому что стори оцененная на 8SP к середине проекта может поменяться на 16 из-за того что это "команда оценила свои возможности" при составлении бэклога в начале проекта полгода назад. и тд. итп.

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

Вообще, IMHO, самая большая сложность во внедрении любых подобных процессов — набраться смелости и честно освещать состояние проекта. На моей памяти большинство менеджеров предпочитают держать эту информацию в самой строжайшей тайне, особенно если дела идут так себе. Не помню кто, но, кажется, кто-то из участников rsdn давал ссылки на занятный блок одного человека — про illusion management.

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

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

Кстати, очень хорошая метафора — большинству ПМов/тимлидов, воспитанных на "классическом" подходе к проектному менеджменту, очень сложно осознать, что соотношение человеко-часы/story-point не является константой, и вся суть философии непрерывного улучшения как раз и сводится к тому, чтобы это соотношение минимизировать.

Что еще более интересно, в мире "классического" подхода к эстимированию у стори-поинтов есть практически полный аналог для выражения сложности — функциональные точки (и иже с ними — use case points, feature points и т.п.). Другое дело, что чуть менее чем всегда подход "сначала оцениваем сложность, и только потом из нее выводим оценку стоимости" отбрасывается в пользу "дубовой" экспертной оценки непосредственно стоимости в человеко-часах.

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

G>>Да, я написал немного упрощенно, но смысл не меняется.

SD>Да, вы написали упрощенно, отчего смысл не то что не поменялся, а потерялся вовсе.

G>>Бардак не у нас в непонимании скрама а в самом скраме при разношерстной комманде (а идеальных комманд с равными по силе программистами практически нигде не встретишь, клонировать людей еще не научились).

SD>"Вы не поверите" (С), первые 8-9 итераций мы тоже все хотели свалить на "разношерстные команды", "разношерстных людей в команде" и т.п., а потом просто привыкли, прониклись, набрали статистику и собрались, наконец, с духом — стали честно заявлять планируемые часы работы.

Тут я не понимаю вобще вашей проблемы. Часы работы могут быть меньше за счет вдруг возникших других внеочередных задач, тех.поддержки, разборок с тестировщиками итд. Частично это можно запланировать, но иногда это не получается. В этом случае дается какой-то фиксированный средний процент от раб.времени на такие вещи. О каком "набраться с духом", "честно заявлять" вы говорите? О том что ваш разработчик заявит, что он будет 15 часов в неделю тратить на фейсбук?! Отличный самоконтроль и мотивация.

G>>Поймите уже наконец, что меняя шило на мыло: реальную временную оценку на поинты делу не поможет, потому что это все та же сверическо-вакуумная оценка времени выполнения проекта. Если стори весит 4SP, то для одного программиста она будет занимать неделю а для другого 2 дня, и наоборот для другой задачи.

SD>Вы в очередной раз демонстрируете непонимание как Agile, так и того, откуда и почему берутся оценки.
SD>Давайте по пунктам.
SD>1. "Реальную временную оценку" разработчик дать не может. ...

Никто и не спорит. Может дать тим-лид. Он может оценить сложность задачи относительно опыта разработчика которому она будет поручена. Естественно тим-лид должен быть в теме и знать свою команду.

SD>2. Ключевой элемент SP — относительность оценки. Что дает автоматическую коррекцию времени выполнения задач исходя из доступного времени. Пример на пальцах: команда сделала оценки фич А (8 часов), Б (11 часов) и В (21 час). Начали делать Б — на нее ушло 19 часов. Хороший тимлид в этот момент попросит провести переоценку задач А и В.

Ну так о таком тимлиде и говорим. Так что пофиг если задачи оценивали числами фибоначчи или человеко-часами. Относительность оценки в скраме еще более усугубляется тем, что для одно задача потянет на 4СП, для другого (менее опытного) на 8СП. Так что это не работет как вы тут вкусно все написали.

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

Вот эти оценочные собрания и есть самый забавный цирк и эпический фейл скрама.

SD>На эту тему, кстати, рекомендую хорошую книжку Agile Estimating and Planning. Не уверен, что она есть на русском языке, но, надеюсь, для менеджера-то не станет проблемой прочитать ее в английском варианте. Думаю, она снимет значительную часть вопросов и претензий.

G>>средняя продуктивность среднего программиста помноженная на среднее время реального участия людей в команде с учетом среднестатицтической вероятности ухода в запои или задержек из-за курения новой документации?

SD>Нет. Исторически подтвержденная производительность команды в целом. В scrum зовется velocity. А также отношение полезно проведенного времени к полному рабочему времени (focus factor).

G>>Тим-лид также точно расчитать возможности своей команды только не в поинтах а в часах и даже с учетом запоев Пети.

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

нет, не обьяснено

SD>Кстати, тим-лид в scrum не нужен, scrummaster — это несколько иная роль.

Естественно не нужен. Был бы тимлид, небыло бы бардака с оценками и "самоконтролем", не было бы этого разговора.

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

Смысл от этого не меняется. Без разницы как вы оцениваете сложность задачи: в часах или енотах, время окончания проекта не будет известно, количество ресурсов не будет толком оценено ни в начале ни в сердине проекта. Только ближе к завершению можно верить velocity и умножать ее на ваши числа фибоначи. Почему ваша красивая теория редко работает в реале: да потому что нет в скраме "реальной оценки командой своих возможностей". Будет средняя по больнице оценка которую можно в классике добится даже без тимлида, спросив каждого раработчика, найдя среднее и умножив на 3.


SD>Вообще, IMHO, самая большая сложность во внедрении любых подобных процессов — набраться смелости и честно освещать состояние проекта.

Согласен, и это не зависит от методологий.

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

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

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

Не беспокойтесь — такие заявления никто не воспринимает всерьез. Это не значит, что разработчик не тратит упомянутые 15 часов на фейсбук. Это значит, что velocity (именно velocity, а не focus factor) из-за этого снижается.

G>Никто и не спорит. Может дать тим-лид. Он может оценить сложность задачи относительно опыта разработчика которому она будет поручена. Естественно тим-лид должен быть в теме и знать свою команду.

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

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

Позвлю себе задать вопрос: вы хоть раз вообще проводили planning poker? Не в виде шутливого баловства, в которое никто не верит (ну так, поржать собрались), а — на полном серьезе? Проведите. Хотя бы десяток раз. Удивитесь эффективности этого инструмента. Само собой, не забывайте о time boxing — дабы, как это часто бывает, встреча не превратилась в треп на тему "как лучше сделать".

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

G>Ну так о таком тимлиде и говорим. Так что пофиг если задачи оценивали числами фибоначчи или человеко-часами. Относительность оценки в скраме еще более усугубляется тем, что для одно задача потянет на 4СП, для другого (менее опытного) на 8СП. Так что это не работет как вы тут вкусно все написали.

Попробуйте понять: в scrum оценки идут на команду. Не на человека. И они делаются относительно самой простой фичи. Понимаете? Что для опытного, что для неопытного — фича 2 SP вдвое сложнее, чем 1 SP. Вы никак не возьмете в толк, что SP не является аналогом или синонимом man-hour. В SP меряется сложность реализации фичи, а не то, сколько времени это займет у того или иного программиста.

В классическом scrum-by-the-book не выделяется персональная производительность члена команды. Все работают вместе. Вася мог сделать 8 SP в итерации, Петя — всего 4 (менее опытный, дольше разбирался). Вместе они сделали 12. На следующую итерацию, если в ней ожидается столько же рабочего времени, следует взять ровно те же 12 SP. С высокой долей вероятности Вася снова сделает 8, Петя — 4.

Теперь вы понимаете, почему так хороши относительные оценки?

G>Вот эти оценочные собрания и есть самый забавный цирк и эпический фейл скрама.

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

G>Естественно не нужен. Был бы тимлид, небыло бы бардака с оценками и "самоконтролем", не было бы этого разговора.


Улыбнуло. Выходит, когда тим-лид есть, никакого бардака с оценками нет. Еще, поди, и проекты в срок завершаются. Со всеми фичами и без багов.

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

Практика показывает, что достаточно 8-10 итераций для команды, никогда не пробовавшей scrum. И буквально 3-5 для тех, кто уже работал по scrum, но не в этой конкретной команде.

G>Почему ваша красивая теория редко работает в реале: да потому что нет в скраме "реальной оценки командой своих возможностей". Будет средняя по больнице оценка которую можно в классике добится даже без тимлида, спросив каждого раработчика, найдя среднее и умножив на 3.

Это не теория, это практика — по закрытию проекта по истечении 14 (или 18? склероз-с, не помню-с) итераций. Как раз тогда, когда стало понятно — "не потянем". Ибо с тем бюджетом, velocity и обязательным набором фич до релиза было еще 14-17.

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

Повторю свою рекомендацию — Agile Estimating and Planning. Отличная книга. Даже для тех, кто заведомо похоронил для себя Agile.

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

SD>Это не теория, это практика — по закрытию проекта по истечении 14 (или 18? склероз-с, не помню-с) итераций. Как раз тогда, когда стало понятно — "не потянем". Ибо с тем бюджетом, velocity и обязательным набором фич до релиза было еще 14-17.

Вот тут у меня возникает логичный вопрос: а кто в этом случае "оплачивает банкет"? Если считать, что итерация — две недели, это где-то полгода работы. Т.е. проект закрыт — только после полугода работы стало ясно: "не потянем". Однако, на протяжении этого полугода N разработчиков как минимум получали зарплату. За чей счет банкет?
И, кстати, как отнесся заказчик к тому факту, что потерял полгода времени — и получил (около)нулевой выхлоп в результате?

Или я не прав? Проясни эти моменты, плз.

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

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

А вообще SkyDance все очень правильно пишет. У меня был очень положительный опыт работы на скраме. Если понимать зачем все это делается и делать реально, а не эмулировать скрам (т.е. собираться один раз в день на daily scrum и все) — то эффект очень положительный.

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

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

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

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

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

V_S>Вот тут у меня возникает логичный вопрос: а кто в этом случае "оплачивает банкет"? Если считать, что итерация — две недели, это где-то полгода работы. Т.е. проект закрыт — только после полугода работы стало ясно: "не потянем". Однако, на протяжении этого полугода N разработчиков как минимум получали зарплату. За чей счет банкет?
V_S>И, кстати, как отнесся заказчик к тому факту, что потерял полгода времени — и получил (около)нулевой выхлоп в результате?

V_S>Или я не прав? Проясни эти моменты, плз.

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


SD>Внутри спринта не может возникнуть никаких незапланированных задач. Одна из обязанностей скраммастера — следить за этим.

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

SD>В традиционном менеджменте этому не уделяется достаточно внимания.

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


SD>Не беспокойтесь — такие заявления никто не воспринимает всерьез. Это не значит, что разработчик не тратит упомянутые 15 часов на фейсбук. Это значит, что velocity (именно velocity, а не focus factor) из-за этого снижается.

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

SD>Кажется, я начинаю понимать. Вы, вероятнее всего, никогда не занимались управлением.

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

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

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

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

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

SD>Видите ли, planning poker — это не только инструмент для оценки сложности задачи. Но еще и метод согласования оной оценки.

Ну при классической разработке тимлиды с PM и CTO не закрываются в черной комнате для решения кому сколько и к какому сроку надо что сделать. Есть свои методы согласования в команде как во время планирования так и во время реализации. Собрания, летучки, брейн-штормы никто не отменял.


SD>Позвлю себе задать вопрос: вы хоть раз вообще проводили planning poker? Не в виде шутливого баловства, в которое никто не верит (ну так, поржать собрались), а — на полном серьезе? Проведите. Хотя бы десяток раз. Удивитесь эффективности этого инструмента. Само собой, не забывайте о time boxing — дабы, как это часто бывает, встреча не превратилась в треп на тему "как лучше сделать".

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

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

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

SD>Попробуйте понять: в scrum оценки идут на команду. Не на человека. И они делаются относительно самой простой фичи. Понимаете? Что для опытного, что для неопытного — фича 2 SP вдвое сложнее, чем 1 SP. Вы никак не возьмете в толк, что SP не является аналогом или синонимом man-hour. В SP меряется сложность реализации фичи, а не то, сколько времени это займет у того или иного программиста.

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

Это и плохо. Очень плохо.

SD>Теперь вы понимаете, почему так хороши относительные оценки?

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


SD>Выходит, когда тим-лид есть, никакого бардака с оценками нет. Еще, поди, и проекты в срок завершаются. Со всеми фичами и без багов.

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

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

SD>Практика показывает, что достаточно 8-10 итераций для команды, никогда не пробовавшей scrum. И буквально 3-5 для тех, кто уже работал по scrum, но не в этой конкретной команде.

G>>Почему ваша красивая теория редко работает в реале: да потому что нет в скраме "реальной оценки командой своих возможностей". Будет средняя по больнице оценка которую можно в классике добится даже без тимлида, спросив каждого раработчика, найдя среднее и умножив на 3.

SD>Это не теория, это практика — по закрытию проекта по истечении 14 (или 18? склероз-с, не помню-с) итераций. Как раз тогда, когда стало понятно — "не потянем". Ибо с тем бюджетом, velocity и обязательным набором фич до релиза было еще 14-17.

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

SD>А вы демонстрируете классическую ошибку начинающего — "опрошу всех, возьму среднее и умножу на N". Этот метод не работает. Потому что в таком варианте (подходите по очереди к каждому разработчику) разработчики не контактируют между собой и не могут объяснить, почему эту фичу делать сложно (или, напротив, легко). Если дать им возможность это сделать — оценки будут более взвешенными.

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


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

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

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

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


V>А вообще SkyDance все очень правильно пишет. У меня был очень положительный опыт работы на скраме. Если понимать зачем все это делается и делать реально, а не эмулировать скрам (т.е. собираться один раз в день на daily scrum и все) — то эффект очень положительный.

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

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

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

Скрам реально работает, если... если выполнить очень грамотно очень много "если". И результат в итоге будет такой же, как от классической методологии, где "если" тоже нужны но их надо гораздо меньше.

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

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

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

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

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

_>Тот кто пишет код без дизайна и архитектуры — пропадет. Дизайн присутствует практически в каждой задаче. Т.к. за редким исключением переписывается чисто приватная реализация чего-либо. наиболее часто меняются связи между компонентами, что-то расширяется, что-то убивается. Без понимания единой линии дизайна кода это будет "борода" из говнокода.

Знаете, это как в старом анекдоте про "celibate" и "celebrate", ну, или, если хотите, другом старом анекдоте про "Рабинович напел"

Во-первых, насколько я помню, только одна из Agile-методологий, а именно — Extreme Programming, призывает не проектировать архитектуру системы заранее, но даже в XP есть понятия архитектурного прототипирования и, по сути, описывающей основные концепции дизайна метафоры системы. К тому же, XP обязательно требует наличия практики test-driven development, а это и есть методика дизайна кода, только альтернативная традиционному рисованию UML-диаграмм.

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

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

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

очень смешно... Вы хоть один проект пытались так оценить? И у вас получилось?
То-то большинство проектов как "вываливась" из сроков и бюджета и до скрама и после и продолжают вываливаться.
Мы блин тут пытаемся реально оценить разработку в 3 недели сроком (один спринт) и то не очень попадаем (ну хоть не на 100% промахиваемся), а тут за год оценить надо...


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

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

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

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

(А ведь именно это интересует Заказчика больше всего, а не применяемые методологии....)

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

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

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

V>очень смешно... Вы хоть один проект пытались так оценить? И у вас получилось?

По разному бывало... Со стажем и со знанием команды получается более точно, это факт.

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

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

V>Мы блин тут пытаемся реально оценить разработку в 3 недели сроком (один спринт) и то не очень попадаем (ну хоть не на 100% промахиваемся), а тут за год оценить надо...

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

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