M>А там и до "рефакторингов" скорее всего дело не дошло. Я так подозреваю, что они получили честный velocity на разработке и решили, что продолжать смысла нет. Это совсем не из-за подпорок. Это из-за того, что с нормальным качеством они получили объективную скорость и команда не успевала. А вот при "гонке за планом" было бы готово уже "90% модулей", но вот при интеграции и тестировании вылезла бы куча проблем. И не важно, был бы план двухнедельным (с целью его догнать!) или с неравными интервалами для разных модулей.

Все именно так и было. С одной добавкой, изначально (в самом начале проекта) планировалось, что через 3 месяца к нам присоединятся опытные разработчики, занятые на тот момент поддержкой старой версии продукта. Потому что по тому самому big upfront plan и традиционному менеджменту, допиливать критические фиксы надо было где-то еще с месяц.

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

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

Не готов обсуждать современную молодежь. Более того, само понятие "молодежь" весьма расплывчато, кому-то и 40-летние молодежь, а кому-то и 30-летние — деды.
Достаточный опыт работы в индустрии на очень разных ролях (даже с забегом в чистую аналитику — вообще далекую от программирования и управления) дает мне возможность обоснованно утверждать, какие идеи и процессы работают. В каких условиях и почему. "Грамотно организовать процесс", это, извините, очень расплывчатое определение, под которое можно подвести что угодно.

G>а что, тимлид скрывает косяки от PMa, PM от начальства?

Для вас это новость? Открытие? Не вы ли парой сообщений назад писали про 15 лет опыта (правда, непонятно, что за опыт, коммерческий ли, фуллтайм ли, в какой индустрии, и чем вообще приходилось заниматься).

G>"задушевные беседы", "саботирует проект", "устаканивать архитектуру", "не иметь работающего продукта вообще". — ну если это ваше представление ситуации в традиционной разработки

Вы утверждаете, что этого всего нет в традиционной разработке? Если вы вправду _никогда_ с таким не встречались — могу лишь позавидовать вашей удаче.

G>недостатки:
G>1. ритмичность итераций. Следствие: архитектурные проблемы
G>2. готовый продукт после каждой итерации. Следствие: никому не нужный абсурд, занимающий дополнительное время и архитектурные проблемы
G>3. самоорганизация. Следствие: "лебедь, рак и щюка"
G>4. общее владение кодом и общая ответственность за код. Следствие: знаю обо всем помаленьку — не знаю ничего.
G>5. отсутствие распределения разработки функционала в зависимости от квалификации разработчика. Следствие: снижение качества и/или скорости разработки

Понятно.
Вы никогда не работали в скрам-команде. СкрамНо — это не Скрам. Вы даже основы не хотели осилить. В частности, архитектурные проблемы из-за ритма итераций (1) — абсурд, который вменяемый человек постеснялся бы вообще писать. Опять же, впервые слышу и том, чтобы наличие готового продукта (2) вело к архитектурным проблемам
Общее владение кодом не является атрибутом scrum и вообще agile. Вы спутали книжки. Даже не знаю, с чем. С ХР, вестимо? Равно как и отсутствие специализации внутри команды не имеет никакого отношения к скрам. Разумеется, члены команды имеют разное образование и разные знания о разных частях системы. Кто-то больше занимается БД, кто-то сетями. С чего бы вдруг им заставлять друг друга делать то, что они не умеют? Вы точно скрам с ХР не путаете?

Остается лишь вопрос самоорганизации. По вашему мнению, люди самостоятельно не способны орзанизоваться. Могу предположить лишь одно — вам катастрофически не везло с коллегами. В моем опыте как раз _внутри_ команды проблем организации не стояло. Все они возникали исключительно уровнем выше — в грызне за ступени корпоративной лестницы.

G>В скраме же команда без главного и ролей.

"Главный" есть. Это deliverables (valuable). Роли же никуда не делись, Вася как был спецом по БД, так и остался. И если сценарий требует взаимодействия с БД, скорее всего, Васю попросят эту часть реализовать. Вы однозначно перепутали скрам с чем-то другим.

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

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

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

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

Надеюсь это была шутка

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

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

Это забирает нмного времени , на безсмыссленое ченить ЧСВ. Обычно не больше чем другие формальные методики, требующие бессмысленного бреда.

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

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

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

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

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

_>Это я о "заповеди" "пишем чтобы тест проходил, потом рефакторим". В этой "заповеди" не указаны временные метки, когда это надо делать. Когда есть утвержденные требования, то код можно написать хорошо сразу и предвидя возможные изменения или доработки заложить их в дизайн.

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

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

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

_> В рамках одной задачи писать так, чтобы сначала тест просто проходил, а потом рефакторить и доводить до ума — отсутствие опыта.

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

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

Я бы сказал — возможны варианты. Если речь идет об изменении бизнес-логики — то да, скорее всего, так и будет. Если же требования меняются кардинально (делали под десктоп, а потом решили переделать под Web) — хорошая архитектура, конечно, облегчит процесс, но только облегчит.

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

_>UML нарисовать намного проще и быстрее, чем писать код. TDD нечто вроде библии, слепо следуя которой потратишь кучу времени, а бизнес результат будет сомнительный. Это я о "заповеди" "пишем чтобы тест проходил, потом рефакторим". В этой "заповеди" не указаны временные метки, когда это надо делать.

Указаны. Сразу как только тест стал зеленым.

_>Когда есть утвержденные требования,

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

_>то код можно написать хорошо сразу и предвидя возможные изменения или доработки заложить их в дизайн.

Это миф. То же самое, что код можно написать сразу без ошибок.

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

Причесать написанный код перед пуллом закрытого таска это отсутствие опыта?

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

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

Нет, если у нас есть все 100500 требований к софтине и они точно не будут меняться, это все меняет. Но единственный способ их получить — дать юзерам потрогать полуготовый продукт.

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


Z>Тот же миф. Чаще встречается архитектура которая предусматривает все, что угодно, кроме свежего требования которое нужно вчера. Между прочим архитектура совершенно не бесплатно дается, это жесткие рамки, в которые приходится втискивать код. И хорошая архитектура это не та, в которую вписываются все новые требования, а та, которая ставит меньше рамок, не давая при этом проекту превратиться в спагетти. В идеале ее вообще не заметно, но она, как тот суслик, есть.
Да, да, да. Конечно, конечно. А вот фиг. Хорошая архитектура позволяет легко реализовывать новые требования. И требует мало доработок для требований которые в нее не вписываются в 95% случаев. И у меня как-то так интуитивно получается что действительно, практически все места где закладывал на будущее пригодились. Хотя могло пройти пол года после разработки куска. Ни разу не видел идеальной архитектуры которую незаметно. Это наверно что-то из разряда сферических коней в вакууме. Да и вообще идеальной архитектуры не бывает, ибо требования к идеальной архитектуре противоречивы. Архитектура это компромисс, в любом случае.

А>Вот скажем я програмю . А дальше ?
Ой вей, это такая ржака
Мне повезло и в полном объеме я с этим цирком не сталкивался.

Максимум что было это срам scrum т.е. это когда на минут 10 теоретически а фактически на 0.5 час
все рассказывают чем занимались/будут. Не то что бы это было прямо очень полезно каждый день
, но немного проясняет ситуацию.

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

N>Я сел в самой дльной точке зала посмотреть на этот цирк

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

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

А>В вашей фирме — может быть, и 99.9%. В среднем по планете — гораздо меньше.
А>Существует множество фирм, работающих по старой доброй схеме концепция-разработка-сдача, и по соотношению дохода на сотруднико-рыло легко переплевывающих весь суперкульный ультрамодерный agile-детсад.

Ну, как бы это сказать... Доход на рыло — не показатель ни разу. Кусочек прошлой жизни: супер-пупер контора, торгуется на бирже, ежегодно загребает даже не миллионы, инвесторы счастливы до последнего миноритария. Однако внутренняя организация работ — ад. Сроки исполнения со всеми waterfall-согласованиями — ад. Попробовали аджайл — опять получился ад. Потому что проблема не в workflow.

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

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

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

Господин, возьмите меня в свою Вселенную. Я есть много уметь. Моя полезный! Вы иметь такой хороший заказчики. Знать что хотеть.

Здравствуйте, Maxim S. Shatskih, Вы писали:

MSS>Хороший человек по имени Peter Viscarola, который является одним из лучших специалистов по ядру Windows за пределами MS, помнится, сильно ругал Agile.

MSS>Причина: эта методология приучает людей писать код наспех, без должного внимания, приводит к медленной сходимости числа багов к нулю, и в отраслях девелопмента с высокой (по человеко-часам исправления) ценой баги может просто убить проект. Что не раз и случалось.

Т.е. во всё виноват аджайл. И когда waterfall-проект начинает вываливаться за сроки и бюджеты, там продолжают вдумчиво писать код и питаться святым духом, а затем раз — и с помощью машины времени отправляют дискету с исходниками на стол глав-инженеру на дату релиза?

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

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

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

Есть два аджыле, не ясно, какой ты имеешь ввиду.

Первый — всё, как и раньше, "я(мы) программлю(руковожу, планирую, тестирую)", только добавляются спринты, автоматические тесты, мега-митинги и прочие приседания. Ничего не меняется, добавляется только геморрой, а процесс в целом тот же ватерфол что и раньше. Это 90% контор, сорта энтерпрайза, заказной софт и прочее пиление бабла. Баззворды собираются по принципу "это скрам(аджыле)", "так правильно", "мы решили", "а что непонятно ?"

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

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

DL>На масштабе проекта, который будет делать команда из более чем 100 человек, прописать требования так, чтобы потом их не пришлось менять, попросту невозможно [...]

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

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

H>...
H>Обратная сторона медали — поскольку не выделяется время на архитектуру и
H>проектирование, при решении следующих задач скорее всего придётся
H>переписать часть системы заново.

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