Что такое Agile development ? В жизни ? Не из googl-я - Управление проектами

On 27.08.2012 15:17, maxkar wrote:
> А если
> там все сгнило внутри (лишь бы уложится в итерацию) и ближе к концу
> проекта начинаются постоянные рефакторинги, скорость и качество падают
> потому что первые итерации говнокодили в основном для демо? Где
> контроль? Скрам не содержит сосотяние проекта в тумане?
>
> Таки не держит. Нету в скраме (да и другом agile) демо. Просто нет! Есть
> полноценный программный продукт с урезанной (может быть — очень сильно)
> функциональностью. И заказчик видит продукт не на презентации, а у себя.
> Уже после первой (это в идеале, но в любом случае после небольшого
> количества) итерации производится внедрение. Все, можно гонять, искать
> баги, проверять функциональность. Если за следующую итерацию заказчик не
> нашел бага, видимо, это совсем не критичный баг (за 2-3 недели функция
> не проверялась или не использовалась, например).

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

--
WBR,
Serge.

Posted via RSDN NNTP Server 2.1 beta

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

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

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

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

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

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

И? Скрам как эти проблемы решает? Не срабатывает подход решения задачи, вместо 1 ~~"енота"~~SP задача будет внезапно весить 16 ~~"енотов"~~ SP. Отлично, все что посчитали ранее по велосити и SP можно считать недействительным. В чем разница эпического фейла с менежерской точки зрения на эту проблему?

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

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

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

Именно демонстрацией какой-либо фичи (натянутой за уши как готовой) заказчик всегда и ограничивался на практике.
1. Фича очень часто зависит от другой, которая будет готова в след. итерации.
2. Даже полнофункциональная фича часто теряет смысл в практическом применении в технологическом процессе, пока не будет готова большая часть продукта.
3. Продукт после нескольких итераций используется пару людьми из тех.отдела в рамках тестирования, теми кто ответственный за финальное внедрение. Много они его натестируют в отрыве от "реальной жизни"? Даже если условия позволяют подключить к процессу тестирования всю фирму, у тех.персонала просто физически не будет возможности к дистибуции версий, обучения и сбора багрепортов каждые 3 недели.

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

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

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

Ну вот вы сами и ответили, как одно компенсирует другое

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

"сроки/качество/функционал" — в чем разница баллансирования в других видах разработки?

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

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

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

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

<...в терминах "модулей", а в терминах "функциональность, реализуемая продуктом". Т.е. интеграция с самого начала.> — кхм... что это? как это увязать с выдачей фичи народу в пользование каздые три недели?

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

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

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

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

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

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

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

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

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

Могли ли вы в любой момент сказать "а если добавим вот это, то проект завершится на 2 недели позже"? Могли ли ответить на вопрос "мы у вас Васю заберем на месяц, починить соседям проект" — как это отразится на вас?
Я тоже участвовал в "традиционных проектах без фиксации функционала" — и завершались они все примерно так: волевым решением объявлялся feature freeze, потом code freeze, и потом релизили что получилось. Между упомянутым решением "релизим что есть" и собственно релизом проходило более 4х месяцев (на самом деле, три из них — до беты, и еще месяц на то, чтобы дырки беты кое-как заткнуть, получился RC, который уже в некотором роде релиз).
Только все это было не по понятному и осмысленному плану, а по факту: "все, больше времени нет, релизим что можем".

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

Основная выгода в прозрачности и предсказуемости.

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

Прекратите паясничать. Если вы продолжите это делать, я просто перестану вам отвечать.

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

Если бы было так, как вы предположили, откуда бы у меня было знание того, как это происходит в традиционном варианте? У меня было семь лет коммерческого опыта до внедрения скрам. И еще три — после ухода из той компании. Итого, более 10 лет вне скрам. Кстати, ни одной "вступительной лекции по скрам" я не посетил. Моё понимание предмета идет исключительно из практики.

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

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

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

Это вам в ветку про метрики. "Сколько строчек в день нужно коммититить, чтобы стать самым крутым программистом". Ни одна из известных мне agile-методик не оценивает производительность команды по количеству строк кода. Потому как методики направлены на доставку функционала (value) заказчику.

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

И это важнейшее свойство скрам — ритмичность итераций! Ключевое, не побоюсь этого слова. Каждую итерацию есть готовый продукт (ну, хорошо, будем честными — обычно для релиза нужно одну или две стабилизационные итерации). Такого, чтобы проект был полностью разобран и на приведение его в релизный вид нужно было полгода — в скрам ситуация невозможная по определению. В традиционном варианте я видел это сплошь и рядом. Вы, само собой, возразите, мол, "плохой менеджмент". Может, и плохой, — не мне оценивать. Но такую ситуацию я встречал во всех компаниях. От маленьких стартапов до интернациональных монстров.

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

Превосходно. Тогда, может, это и следует обсудить? Называйте, с вашей точки зрения, недостатки Agile и scrum. Я, в свою очередь, назову свои соображения на эту тему. Серебряной пули не существует, я это знаю. У скрам есть проблемы — в первую очередь, сложность его реализации: все простые вещи очень сложно реализовать. У него есть своя область применимости.
Но вы обо всем этом не пишете, ограничиваясь общими словами "в традиционном варианте у меня все работает, а вы неправы". Заметьте, вы даже конкретные примеры не приводите. Поэтому у меня и возникают сомнения в ваших словах.

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

Если вы не смогли этого добиться за несколько лет скрам — это 100% показатель СкрамНо.

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

Задам отвлеченный вопрос. Вы когда-нибудь играли в командные игры? Футбол, баскетбол, волейбол? Да хотя бы в какие-нибудь современные компьютерные онлайн-игры. В конце концов, в "зарницах" участвовали лет 20 назад? Неужели вас никогда не захватывал командный дух и азарт? Сочувствую. Вы действительно многое теряете в жизни.

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

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

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

А как же "индивидуальность разработчика"?

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

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

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

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

А что говорите вы? Просто оценки от балды? Или все-таки делаете какие-то формальные ТЗ, согласования и т.п.? Ведь это тоже занимает значительное время. Вам я тоже рекомедую погуглить по словам cone of uncertainty.

G> Где контроль? Скрам не содержит сосотяние проекта в тумане?

Контроль — каждую итерацию. Для начинающих команд раз в две недели, потом кто-то переходит на 3 или 4, зависит от команды.

Само собой, вы можете возразить — "все это можно реализовать и без скрам".

Можно.

Хотите очередной вариант СкрамНо — пожалуйста. Применяйте. Просто не жалуйтесь потом, что "оно не работает". Вас предупреждали.

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

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

Почти так. После 2х недель заказчику дается квартира. Без лифта, по лестницам надо топать. Шахта — открытая. Крыша — времянка. Если заказчик скажет "все, баста, мне 10 этажей уже не надо, давайте только два" — за следующую итерацию крыша перекрывается на production grade, устанавливается лифт нужной конструкции, дом сдается.

По вопросам оплаты — читайте все ту же Agile Estimating and Planning, там ажно целая глава на тему финансовой приоретизации. Краткий смысл — заказчик может платить хоть за каждый реализованный сценарий.

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

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

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

SD>Почти так. После 2х недель заказчику дается квартира. Без лифта, по лестницам надо топать. Шахта — открытая. Крыша — времянка. Если заказчик скажет "все, баста, мне 10 этажей уже не надо, давайте только два" — за следующую итерацию крыша перекрывается на production grade, устанавливается лифт нужной конструкции, дом сдается.

А вот если заказчику нужно 10 этажей, то вдруг выясняется на 20 итерации скрама , что лифт работает только в демо -режиме и ездит только на второй этаж. А чтобы сделать нормальную крышу, надо снимать временную, разобрать весь дом и собрать заново

S>А вот если заказчику нужно 10 этажей, то вдруг выясняется на 20 итерации скрама , что лифт работает только в демо -режиме и ездит только на второй этаж.

Т.е. работа шла по СкрамНо, выходит.
Поскольку в scrum by the book при достройке каждого очередного этажа лифт переносят на этаж выше.

S>А чтобы сделать нормальную крышу, надо снимать временную, разобрать весь дом и собрать заново

Как вы прекрасно понимаете, сия ситуация отнюдь не специфична для Agile или SCRUM.

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

G>Здравствуйте, vpedak, Вы писали:
G>Квадратики в МS Project? Я думаю на этом можно завершить дискуссию...

hint: есть такая диаграмма в project, называется Диаграмма Ганта. А вам домашнее задание найти в ней квадратики...

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

ну т.е. fixed price проекты нам не нужны?

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

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

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

у них что с телепатией лучше? НЕТ одного такого в команде кто правильно за всех оценит сроки. Весь смысл что вся команда согласится при spring planing с объемом работ и сроками. И здесь есть элемент мотивации. Раз подписались — надо делать (проверено это работает)

А когда мне сверху сроки спускают (которые обычно сильно завышены, так как оценщик он же опытный у нас) то я ведь так и сделаю. Могу и за 3 дня, а могу и за 5 (хотя там если нормально попахать то и за 2 дня справишься).

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

Да, это так. Потому что это реальная оценка. Она важнее для бизнеса, чем какой-то проект сделанный в MS Project который и 50% реальности не показывает.
Если вам важен сам продукт который делается то вам и оценка реальная будет важна.

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

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

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

G>Что за бред?

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

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

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

SD>У меня было семь лет коммерческого опыта до внедрения скрам. И еще три — после ухода из той компании. Итого, более 10 лет вне скрам. Кстати, ни одной "вступительной лекции по скрам" я не посетил. Моё понимание предмета идет исключительно из практики.

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

SD>Под руководством в данном случае понимается бенефициар. Заказчик ли, или владелец софтостроительной компании. В общем, тот, кто заинтересован в реализации продукта. Это внешний по отношению к команде персонаж. Руководство может быть либо удовлетворено скоростью команды (независимо от того "по чайной ложке в год" это или Windows 8 за полгода), а может быть недовольно. Поскольку вся статистика скрам-команды доступна публично

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

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

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

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

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

SD>Превосходно. Тогда, может, это и следует обсудить? Называйте, с вашей точки зрения, недостатки Agile и scrum. Я, в свою очередь, назову свои соображения на эту тему.

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

SD>Задам отвлеченный вопрос. Вы когда-нибудь играли в командные игры? Футбол, баскетбол, волейбол? Да хотя бы в какие-нибудь современные компьютерные онлайн-игры. В конце концов, в "зарницах" участвовали лет 20 назад? Неужели вас никогда не захватывал командный дух и азарт?

В традиционной разработке тоже команда и командный дух, только у всех немного разные роли. Как футболе: тренер, капитан, нападающий, защитник, полизащитник, вратарь. Онлайн-игры: батлфилд: командир, скуадлидер, пулеметчик, медик, сапер, снайпер...
В скраме же команда без главного и ролей.

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

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

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

SD>А как же "индивидуальность разработчика"?

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

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

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

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

Ну вот вам и объясняют что с годами поняли насколько скрам бывает хорош. А вы не понимаете... Меня тоже это удивляет

SD>>Под руководством в данном случае понимается бенефициар. Заказчик ли, или владелец софтостроительной компании. В общем, тот, кто заинтересован в реализации продукта. Это внешний по отношению к команде персонаж. Руководство может быть либо удовлетворено скоростью команды (независимо от того "по чайной ложке в год" это или Windows 8 за полгода), а может быть недовольно. Поскольку вся статистика скрам-команды доступна публично

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

а что? такого не бывает?

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

в разработке софта ОЧЕНЬ много именно взаимодействия людей, а не только технологий. Почитайте на досуге — http://www.maxkir.com/sd/people_as_nonlinearRUS.htm
Похоже это вы — "слаще морковки ничего не видели"

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

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

ну если вы не можете после каждого спринта отгружать версию заказчику — то это не значит что другие не могут

G>недостатки:
G>1. ритмичность итераций. Следствие: архитектурные проблемы

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

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

ну да, никому не нужный абсурд (кроме заказчика который за все это платит и самой команжы которая начинает получать feedback сразу)

G>3. самоорганизация. Следствие: "лебедь, рак и щюка"

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

hint: самоорганизация != анархия

G>4. общее владение кодом и общая ответственность за код. Следствие: знаю обо всем помаленьку — не знаю ничего.

ну вот у нас продукт сейчас выходит версии 9.5. и никого уже нету кто его начинал. И что? Мы вынуждены иметь общую ответственность за код. Не умерли еще.

G>5. отсутствие распределения разработки функционала в зависимости от квалификации разработчика. Следствие: снижение качества и/или скорости разработки

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

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

Да, тут нету официального "архитектора" который сидит тут давно и его поэтому никто выгнать не может. Он уже нифига не понимает в новых технологиях, но ведь он хороший, давно работает, пусть сидит. Вам такое надо?

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

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

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

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

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

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

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

SD>>>Под руководством в данном случае понимается бенефициар. Заказчик ли, или владелец софтостроительной компании. В общем, тот, кто заинтересован в реализации продукта. Это внешний по отношению к команде персонаж. Руководство может быть либо удовлетворено скоростью команды (независимо от того "по чайной ложке в год" это или Windows 8 за полгода), а может быть недовольно. Поскольку вся статистика скрам-команды доступна публично

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

V>а что? такого не бывает?

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

V>в разработке софта ОЧЕНЬ много именно взаимодействия людей, а не только технологий. Почитайте на досуге — http://www.maxkir.com/sd/people_as_nonlinearRUS.htm
V>Похоже это вы — "слаще морковки ничего не видели"

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

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

V>ну если вы не можете после каждого спринта отгружать версию заказчику — то это не значит что другие не могут

G>>недостатки:
G>>1. ритмичность итераций. Следствие: архитектурные проблемы

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

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

V>ну да, никому не нужный абсурд (кроме заказчика который за все это платит и самой команжы которая начинает получать feedback сразу)

G>>3. самоорганизация. Следствие: "лебедь, рак и щюка"

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

V>hint: самоорганизация != анархия

G>>4. общее владение кодом и общая ответственность за код. Следствие: знаю обо всем помаленьку — не знаю ничего.

V>ну вот у нас продукт сейчас выходит версии 9.5. и никого уже нету кто его начинал. И что? Мы вынуждены иметь общую ответственность за код. Не умерли еще.

G>>5. отсутствие распределения разработки функционала в зависимости от квалификации разработчика. Следствие: снижение качества и/или скорости разработки

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

G>>В скраме же команда без главного и ролей.
V>Есть в скраме роль скрам мастера который "следит за правилами игры". И роли есть внутри команды, просто у них незвания не "протокольные". Вон например Вася, он спец по базам, на него обычно все сложные задачи по базам валим и к нему за советом ходим. А вот Петя, тот самый старый работник на поекте, он больше всех про код знает и т.д.

V>Да, тут нету официального "архитектора" который сидит тут давно и его поэтому никто выгнать не может. Он уже нифига не понимает в новых технологиях, но ведь он хороший, давно работает, пусть сидит. Вам такое надо?

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

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

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

Слава, я устал отвечать на ваш феерический бред в оправдание скрама. Бесконечная тема может быть пересена в "священные войны". Адиос.

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

G>Слава, я устал отвечать на ваш феерический бред в оправдание скрама. Бесконечная тема может быть пересена в "священные войны". Адиос.

Я хоть пытаюсь аргументировать свою позицию. Привожу ссылки на мнение уважаемых в индустрии людей...

А в ответ только — бред, какие-то "сферические" архитектурные проблемы.

Грустно...

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

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

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

G>>Слава, я устал отвечать на ваш феерический бред в оправдание скрама. Бесконечная тема может быть пересена в "священные войны". Адиос.

V>Я хоть пытаюсь аргументировать свою позицию. Привожу ссылки на мнение уважаемых в индустрии людей...

V>А в ответ только — бред, какие-то "сферические" архитектурные проблемы.

V>Грустно...

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

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

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

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

О! Потрясающе. А при чем здесь скрам то? Он ведь по-другому работает. Там же нет разбиения на двухнедельные итерации с самого начала. Зато на каждой итерации выделяется несколько задач (от оставшегося куска) и реализуются. Заодно по факту выполнения начальных задач корректируется текущая скорость и можно примерно оценить, сколько еще осталось пилить оставшуюся часть. Есть еще очень важный момент. Нужно быть честным и вместо попытки "на костылях" успеть в двухнедельный срок признавать, что "не успели". Это приведет к переносу реализации фичи на следующую итерацию, коррекции velocity и общих "прогнозов". Но никаких костылей, полностью рабочий продукт (да, в меньших объемах, чем выбрали на итерацию, но все равно рабочий). И в коде остаются не костыли, а предусмотренная архитектурой реализация функциональности.

Кстати, не говорите, что в scrum'е нет архитектуры. Высокоуровневая архитектура есть. И делается она на самом деле тогда же, когда и в BDUF'е (Big Design Upfront) — на этапе анализа задачи. Это выполняется до того, как вы сказали заказчику "мы будем делать проект три месяца" и получили какие-то деньги. Просто потому, что иначе сложно получить хоть какие-то правдоподобные сроки. А вот уже детализация дизайна выполняется в разное время. В Agile — по мере необходимости. Во BDUF'е — сразу после начала проекта, со всеми вытекающими отсюда рисками (она может не понадобиться, могут потребоваться переделки и т.п.).

P.S. Я немного обобщу ваше утверждение. Нельзя разделить любой проект на части и сдавать полностью работающий функционал фиксированные промежутки времени. Или будет страдать качество, или будет "заметаться мусор в уголок" и ставиться костылики, которые всплывут через несколько частей. В общем, водопад и прочие подходы с априорным планированием не работают. Agile не пытается делать подробное априорное планирование. Большая часть планирования/приоретизации и т.п. выполняется в процессе работы.

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

H>Мне неясно как это уменьшает вероятность того, что "ближе к концу
H>проекта начинаются постоянные рефакторинги, скорость и качество падают
H>потому что первые итерации говнокодили в основном для демо". Ну заменим
H>слово "демо" на "полноценный программный продукт с урезанной (может быть
H>— очень сильно) функциональностью."
Не, не то. Нужно слово "говнокодили" убирать. Если "говнокодили", это было СкрамНо. Нельзя ухудшать качество с целью достижения сроков. Вот "вылететь" за срок и перенести задачу на следующую итерацию — можно. Это скажется на velocity и дальнейших оценках. Но говнокода не будет. Ага, честным быть тяжело. Но без этого scrum не будет работать.

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

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

H>Речь про стоимость добавления фич, превращающих "то, что вообще можно
H>где-нибудь развернуть" в то, "что имеет для заказчика бизнес-смысл". Или
H>вы хотите сказать, что этого в среднем можно достичь за месяц-полтора?
H>SkyDance тут рассказывал что-то про полгода что ли, после которого
H>решили, что пора завязывать — ничего не выходит.

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

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

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

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

G>И? Скрам как эти проблемы решает? Не срабатывает подход решения задачи, вместо 1 ~~"енота"~~SP задача будет внезапно весить 16 ~~"енотов"~~ SP. Отлично, все что посчитали ранее по велосити и SP можно считать недействительным. В чем разница эпического фейла с менежерской точки зрения на эту проблему?

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

Да и какая проблема со SCRUM'ом? Оценку проекта мы не давали (он не оперирует со сроками реализации фичей, только с размером итерации). Да, чуть поплыла velocity. Да, фича улетела на следующую итерацию. Да, получили продукт без фичи А на итерации. Бывает, рабочий процесс. Если фейл однократный, velocity подкорректируется обратно. Если подобные фейлы частые — так и останется низкой, что окажется полезным для оценки перспектив всего проекта.

G>Именно демонстрацией какой-либо фичи (натянутой за уши как готовой) заказчик всегда и ограничивался на практике.
Это от заказчиков зависит. Конечно, если заказчик не хочет убедиться, что его поняли правильно и делают то, что ему нужно, ему будет достаточно демо. Такую необходимость нужно объяснять, заказчик про это может даже не пдозревать. Но если после объяснения он все равно не хочет тестировать, вероятно, программа ему вообще не нужна.

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

. А в scrum'е такой номер не пройдет.

G>1. Фича очень часто зависит от другой, которая будет готова в след. итерации.
Ух ты! Почему тогда она попала в текущую итерацию? Сначала должна была идти фича, которая будет в следующей итерации. В конце концов, она "важнее" (без нее не будет двух фичей, а с ней будет по крайней мере одна). А вот для предварительного планирования такая ситуация как раз характерна. В плане фичи стояли "параллельно" и одна из них задержалась. Поэтому и интеграция задержалась.

G>2. Даже полнофункциональная фича часто теряет смысл в практическом применении в технологическом процессе, пока не будет готова большая часть продукта.
Ну не применяйте пока в техпроцессе. Хотя бы проверьте, что фича делает то, что нужно. Можно будет на следующей итерации устранить какие-то недоделки, недопонимания и т.п.

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

G>Сладкая утопия из книжек по скраму.ки сдохнут под тяжестью проекта, почти никто расстраиваться не будет (ну да, разработчики во главе с менеджером меньше денег получат).
Не читал книжек по скраму. Из-за скрама в данном случае проект не сдохнет. Он сдохнет из-за завышенных ожиданий до начала проекта. И сдохнет он быстрее, чем при "предварительном планировании". Что хорошо для заказчика (он потратил меньше денег). Да и для команды неплохо — они пойдут к другому заказчику. Какая проблема то? Времени потратили меньше. Денег получили меньше, чем за выполненный проект. Но вот с fixed cost и penalty (за просрочку/качество) команда бы вылетела в два раза по срокам и тоже получила меньше денег, чем планировалось. Никаких проблем не вижу.

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

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

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

G>Ну вот вы сами и ответили, как одно компенсирует другое

Не компенсирует. Объясните мне, о какой прдесказуемости проекта идет речь в upfront planning? Вот у вас проект сначала стал отставать на один человекомесяц, а затем вдруг взял и опять вошел в норму. SCRUM не делает долгосрочных прогнозов. В краткосрочных же (на итерацию) станет видно, что за итерацию получится меньше функциональности, чем с полным составом команды. Он не дает иллюзий, что "все идет по плану и продукт будет в срок"

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

G>"сроки/качество/функционал" — в чем разница баллансирования в других видах разработки?

А как вы собираетесь балансировать "сроки/качество/функционал", когда у вас все заранее распланировано? Ну да, на этапе интеграции вы начнете фичи резать. Потому что раньше вроде все было хорошо. А там уже проделано много лишней работы по данным фичам. Вот в примере выше, например, архитектор три дня потратил на детальный дизайн модуля Б, а потом библиотека вышла. В scrum модуль Б был бы сделан вместе с фичой, для которой требовался (и фича была бы доставлена пользователю раньше, чем при длительном планировании). Или библиотека вышла раньше и команда не потратила 3 человекодня на неиспользуемый дизайн.

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

G>Ну и в чем проблема? Захотел изменить функционал, вспомнил о важной фиче посередине проекта. Составляем изменение ТЗ, оговариваем сроки, деньги, едем дальше.
Дорого

. Особенно дорого, когда какие-то фичи станут ненужны, а для них уже началась разработка. В scrum'е ими хотя бы могли попользоваться до тех пор, пока она не стала ненужна (или бы фича еще не была реализована). И самая большая проблема — заказчик рассказал совсем не то, что ему было нужно на самом деле. Это достаточно часто бывает. Для команды хорошо — лишние деньги (хотя переделывать психологически некомфортно), а вот для заказчика не очнеь.

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

G><...в терминах "модулей", а в терминах "функциональность, реализуемая продуктом". Т.е. интеграция с самого начала.> — кхм... что это? как это увязать с выдачей фичи народу в пользование каздые три недели?
А в чем проблема то? Ведь на итерацию же не ставится задача "разработать инфраструктуру доступа к базе данных" (которая ставится Пете и он ее месяц пилит). Ставится задача "вывести прайс из базы данных". В рамках этой задачи придется и часть инфраструктуры доступа к базе написать, и часть инфраструктуры рендеринга (отображения). Может быть, еще какие-то сервисы. Все слои/компоненты/модули/библиотеки интегрируются в одно приложение с самого своего появления.

M>>В общем, не все так просто. Тот же scrum предполагаемое решение согласует на scrum-meeting'е и со сроками будет определенность.

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

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

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

G>Красиво пишете. Вы если дом строите, после 2х недель можете заказчику квартиру показать, в которую можно заезжать и жить? А шахту для лифта когда делать будете и на сколько этажей? А платить он будет как, после каждой готовой "квартиры", по чястям?
Да пускай, меня очень даже устроит! Я готов и по частям платить. Может, мне не нужна будет шахта лифта. Или после постройки пятого этажа я решу, что лифт нужен. И пусть строят лифт. Работающий лифт! После итерации у меня будет пятиэтажний дом с работающим лифтом. А не 10-этажная коробка без крыши, с нежилыми квартирами но зато с шахтой лифта.

И вообще аналогия неверная. Постройка дома — это construction. Аналог в IT — создание копий программы (цифровых, на дисках и т.п.). Аналогией создания ПО будет проектирование дома! И да, здесь тоже меня устроит сначала небольшой жилой дом (ну зачем мне 20-этажка без лифта). Затем к нему можно будет добавить лифт (с перепланировкой небольшой под шахту). Затем — еще несколько этажей (нужно проверять прочность дома и т.п.). А затем — по блэкджеку и бассейну на каждом этаже. Это лучше, чем если я закажу сразу 20-этажку со всеми возможностями, а мне через три месяца за мои же деньги скажут, что при существующих технологиях такое не строится или строится неоправданно дорого.

	От:	hrensgory
	Дата:	27.08.12 13:11
	Оценка:

	От:	goondick
	Дата:	27.08.12 13:16
	Оценка:

	От:	goondick
	Дата:	27.08.12 14:36
	Оценка:

	От:	SkyDance
	Дата:	28.08.12 00:34
	Оценка:

	От:	SkyDance
	Дата:	28.08.12 01:04
	Оценка:	9 (1)