Тут я последнее время, немножко с Scrumm’ом поработал.
Что мне понравилось, очень логичная и правильная система Backlog’а и Sprint’ов. Логично, записываем все задачи, выставляем им приоритеты, набираем задач на месяц с наибольшим приоритетом и делаем.
Что мне не понравилось. Уж очень методика рассчитана на гибкость, причем на гибкость направленную на конечного потребителя. То есть, возможность как можно раньше выдать пользователю наиболее полезное и как можно быстрее реагировать на изменения.
Сабо собой у всего самого положительного, есть отрицательные стороны. Так вот, мне на эту отрицательную сторону удалось наступить. В случае необходимости больших переделок проекта, которые не могут быть отданы по частям пользователю, а могут быть отданы только целиком, Scrumm откровенно сбоит, так как вместо оптимизации на длинном промежутке времени (всего проекта), он заточен на оптимизацию всего на скажем месячном промежутке. И получается не совсем уж оптимально.
В общем, сам не понял, что написал, но в целом, большие переделки без возможностей выпуска в середине, Scrumm поддерживает плохо, так как он как раз нацелен, на то, чтобы не было таких задач.
не всё так плохо. несмотря на то, что рекоммендуемая длина спринта 2-4 недели, можно спокойно спринтить и полгода.
Ну спринт пол года = waterfall 😉
не не.
с другой стороны конечно скрам заточен на response for a change. для системы управления спутником не канает, т.к. ченжей там не будет.
Да. Именно-именно.
Scrumm заточен на гибкость. А там где нужна не гибкость, а скажем точность, мощность или что-то другое, он работает уже не так эффективно.
Что мне не понравилось. Уж очень методика рассчитана на гибкость, причем на гибкость направленную на конечного потребителя. То есть, возможность как можно раньше выдать пользователю наиболее полезное и как можно быстрее реагировать на изменения.
Че тут плохого? Вижу только положительную сторону 🙂
Так вот, мне на эту отрицательную сторону удалось наступить. В случае необходимости больших переделок проекта, которые не могут быть отданы по частям пользователю, а могут быть отданы только целиком, Scrumm откровенно сбоит, так как вместо оптимизации на длинном промежутке времени (всего проекта), он заточен на оптимизацию всего на скажем месячном промежутке. И получается не совсем уж оптимально.
Честно говоря, даже представить не могу что это за оптимизация целиком длящаяся полгода 🙂 Те же самые юнит тесты должны отлично помогать в таких вещах
Да не, плохого особо ничего. Просто, оказалось очень не удобно с помощью резиного молотка забивать железные гвозди. А до того как в руки взял молоток, не знал, что он резиновый.
>Честно говоря, даже представить не могу что это за оптимизация целиком длящаяся полгода >:) Те же самые юнит тесты должны отлично помогать в таких вещах
Ну не обязательно пол года. Но просто есть проекты, которые хоть на подзадачи и можно поделить, но их нельзя поделить на части, которые по отдельности будут ценны.
О… Нашел хороший пример — постройка дома. На задачи делится на ура, но для постройки дома
а) не требуется гибкость по ходу
б) невозможно раз в месяц, что-то releas’ить (так как имеет смысл только 100% законченный проект).
Действительно пример вроде ничего вышел.
Scrumm хорош, для починки дома, но плох для постройки дома.
> Scrumm хорош, для починки дома, но плох для постройки дома.
А всегда ли приходится строить именно дом? Если строить комплекс сооружений, то их вполне можно сдавать по частям.
Я под постройкой дома имел в виду процесс заранее
а) Достаточно детально спланиваронный
б) Не подлежащий серьезным изменения в процессе создания
в) Не приносящий пользователю пользу до тех пор пока он 100% окончен весь.
Если комплекс сооружений подпадает под эти правила, будет таже проблема.
Условно говоря, если комплекс сооружений строиться на луне, до тех пор пока не будет все закончено и накрыто колпаком под которым будет воздух, сдать проект будет не возможно.
> Не подлежащий серьезным изменения в процессе создания
Это про многие проекты говорят. Но если сравнить готовое ПО с первоначальными спецификациями — расхождения есть почти всегда.
>Не приносящий пользователю пользу до тех пор пока он 100% окончен весь.
А почему не приносящий? Может быть потому, что пользователь просто не хочет попробовать использовать 20-40-60-80% функций ПО?
>Это про многие проекты говорят. Но если сравнить готовое ПО с >первоначальными спецификациями — расхождения есть почти всегда.
Да, так оно и есть, но тем не менее очень сильно отличаются проекты по тому насколько они отошли от изначальной идеи и спецификации.
Так, что расхождения есть всегда, но одно дело 10% расхождение, другое дело 70% расхождение.
>А почему не приносящий? Может быть потому, что пользователь просто не >хочет попробовать использовать 20-40-60-80% функций ПО?
Именно. Есть софт, который имеет смысл только когда он достигает определенного уровня функциональности и качества.
Условно говоря, например backup программа, которая умеет backup, но не умеет востанавливать пользователю будет не интересна.
Так, что milestone «теперь программа умеет делать backup» — чисто внутренний.
При постройке дома Scrum позволяет в середине проекта увидеть насколько действительно сползают сроки окончания строительства.
Отлично. Самому не надо отписывать 🙂
Кстати, waterfall тоже это позволяет.
Если уже за плечами 100 домов, и известно что 3 этаж должен был закончиться через 6 месяцев, а прошло 7.
Проблема в том, что при постройки дома (по уже готовым чертежам), если сроки сползли на месяц, то это не значит, что мы решим
— чуть поменять фундамент
— выкинуть из чертежей балконы
— построить на 4 этажа меньше
Строительство дома, процесс достаточно НЕ гибкий.
> Scrumm хорош, для починки дома, но плох для постройки дома.
да нельзя так говорить. он не плох, просто некоторые активности скрама (он кстате с одной М пишется) будут лишними, т.к. нет изменения требований. Ну так в духе скрама будет «лишние» активности убрать из процесса — именно поэтому Scrum не процесс, а фреймворк для построения процесса.
работа -> анализ -> адаптация -> работа -> анализ -> адаптация -> работа -> анализ -> адаптация …
ok. Если рассматривать scrum (c одной m 🙂 как фреймворк — то сложно будет обсуждать, так как каждый его может перекроить под себя.
>работа -> анализ -> адаптация -> работа -> анализ -> адаптация -> работа ->
Относительно постройки дома (одного дома).
Для него sprint оказывается длинной с проект, анализ и адоптация отпадает.
Как я и говорил, он тогда вырождается в waterfall.
А вот если он вырождается, то все таки о нем уже нельзя говорить как о agile.
ну так не надо ж мыслить так узко 🙂 процесс-то строится не для посторойки дома, а для организации. если у тебя атомарным действием есть постройка дома, то у тебя и спринт будет года 2-3.
а конкретное действие всегда вырождается в последовательность: понял что делать — сделал — проверил — (исправил — проверил) — оповестил
Мне вспоминается в этом смысле анекдот:
Урок закона Божьего в школе.
Священник — детям: — Что всего быстрее на свете?
Дети (в задумчивости, Вовочка тянет руку): — Х@й, батюшка!
Священник: -?! Обоснуй, однако.
Вовочка: — Не успел подумать — уже встает.
Священник: — Хмм. Хорошо.
А что всего тяжелее на свете? Вовочка (тот же): — Х@й, батюшка!
Священник: — Обоснуй, однако.
Вовочка: — Если не встает, так никакими силами не поднимешь!
Священник.: — Ладно. А что всего… (Вовочка аж прыгает от желания ответить) Остепенись, однако! Этак всю Божью науку к х@ям сведем!
Так вот, в таком случае любой процесс можно свести к указанной последовательности действий.
Но все же, agile методики именно заточены под короткие спринты, а не под длинные.
Постройка дома — это на самом деле очень хороший пример, где скрум рулит. Проект можно разбить на следующие спринты:
1) Создание архитектурной и прочей документации. Вход: выбранная типовая архитектура плюс специальные пожелания, типа вместо двух маленьких спален сделать одну большую со шкафом. Deliverable: папка со всеми бумагами, которые нужны строительной фирме и хозяину для улаживания формальностей.
2) Фундамент. Вход: купленный пустой участок земли. Deliverable: фундамент.
3) Коробка дома без внутренней отделки.
4) Отделка
5) подключение к газу
6) подключение к холодной воде и канализации
7) подключение к электричеству
8) установка котла и организация бойлерной, закачка отопительного мазута.
9) подключение к ТВ-кабелю, телефону и интернету.
Смысл разбивания на эти майлстоуны — возможность в каждом из них относительно безболезненно сменить исполнителя.
Архитектор, конечно, сам предложит какую-то «свою» фирму, но не факт, что она окажется оптимальной в плане цены-качества. А после закладки фундамента можно уже на практике оценить профессионализм строителей и качество коммуникации между ними и заказчиком. Некоторые семьи даже заказывают услугу независимого эксперта, который приходит и оценивает качество реализации фундамента.
Что же касается постройки этажей и крыши, то там на самом деле спринты длятся один день, т.к. заказчик приезжает каждый день вечером, смотрит и дает ЦУ. И если что-то совсем криво пойдет, то заказчик все эту бодягу просто замораживает и начинает консультации с строительной фирмой на тему как бы нам цивилизованно расстаться.
Далее, очень многие заказчики ради экономии денег договариваются о том, что внутреннюю отделку они сами делают, а стоительная фирма только при необходимости консультирует.
Ну а подключения заказчики обычно распределяют по независимым исполнителям и/или делают сами.
Т.е. с одной стороны да, фундамент сам по себе смысла для заказчика не имеет. Но это не значит, что он не хотел бы получить его как отдельный deliverable, протестировать качество и определиться с тем, будет ли он с Вами дальше работать.
В софтостроении есть, правда, заказчики, которые и 100% готовый-то продукт толком не тестируют и не смотрят. Обычно это вызвано политическими реалиями. Но в этих случаях им обычно нужен fixed price contract, т.е. уже сразу видно, что скрум тут бесполезен.
ok. В таком случае, какое отличие waterfall и scrum, в том как вы описали?
В waterfall тоже есть промежуточные milestone и тоже заказчик может глядеть и давать ЦУ. Также он может тоже заморозить стройку и т.п.
Отличий несколько. Во-первых, формально-юридическое оформление итераций.
В waterfall майлстоуны являются прежде всего инструментом контроля за сроками. Deliverables обычно не создаются и заказчику не передаются. Заморозка проекта или смена исполнителя рассматриваются как failure и являются ЧП.
В scrum в конце каждого спринта заказчик получает deliverable. С ним в руках он всегда может пойти в другому исполнителю и продолжить с ним. Конечно, заказчик понесет в этом случае определенные дополнительные траты времени и денег. Но с точки зрения исполнителя все идет по плану, т.к. с самого начала было ясно, что будет спринт, и будет релиз, и будет принятно решение, продолжать ли или нет и если да, то что именно делать в следующем спринте.
Во-вторых, порядок исполнения заказа в waterfall сначала вширь, потом вглубь, а в scrum наоборот. Т.е. в процессе отделки по waterfall грубо говоря сначала во всех комнатах проведут розетки, потом во всех комнатах покрасят потолок, повесят обои, а под конец настелят пол. Во scrum сначала «начерно», но полностью отделают спальню, чтобы хозяин уже мог въехать в дом и перестать, наконец, платить аренду за его текущее жилье. Затем сделают полностью туалет и кухню. А закончат прихожей, чердаком и подвалом. Конечно, при таком способе грязи в «законченные» комнаты натаскается дай боже. Зато тысяч пять можно на аренде сэкономить, а комнаты сначала «начерновую» отделывать, а потом второй раз косметически пройтись.
Вы правы, только что почитал в интернет. Похоже я под waterfall подразумевал одну из его разновидностей, в которой были добавленны пару вещей:
— deliverables таки передаются заказчику
— не идеальная waterfall схема (в смысле, что не идет концентрация на 100% окончании какой-то фазы).
Тем, не менее возвращаясь к примеру дома.
>Во scrum сначала “начерно”, но полностью отделают спальню, чтобы хозяин >уже мог въехать в дом и перестать, наконец, платить аренду за его текущее >жилье.
Я бы сказал, что это достаточно редкая ситуация (для домостроения), когда новый хозяин согласен въехать в дом (не дай бог еще с семьей и детьми), когда в доме активно продолжают идти работы.
Кстати, чаще всего при строительстве именно используют схему, делать одну операцию — везде. Ставить розетки сразу по всему дому и т.п.
Я бы сказал, что это достаточно редкая ситуация (для домостроения), когда новый хозяин согласен въехать в дом (не дай бог еще с семьей и детьми), когда в доме активно продолжают идти работы.
А вы приезжайте в провинциальную Россию — увидите такое на каждом шагу 🙂
Попрошу поправочку.
В провинциальной России — ремонт, это не процесс, а образ жизни. 🙂
О milestone, deliverables и бюджете и т.п. — говорить не приходится.
Я сам дом не строил, но судя по тому infotainment, что показывают по ТВ у нас в Германии, так поступают очень многие домостроители. Естественно, степень завершенности и порядок выполнения каждый выбирает под себя. В том числе показывали семью с двумя детьми, въехавшую в дом, где готова была только спальня. А че, уютненько. И совместные невзгоды сплачивают.
Но мысль Ваша, конечно, понятна. Преимущества есть и у вертикальной, и у горизонтальной разработки. И в общем случае имеет смысл поискать оптимальное сочетание. То же строительство дома — там явно имеет смысл поставить все этажи и крышу, завершив их на 100%, а не возвести сначала правый дальний угол, приклеить обои, а затем начать копать котлован для левого ближнего угла 🙂 Хотя теоретически и при грамотном просчитывании статики и подпорок и отсутствии дождя со снегом и такое возможно 🙂
А еще можно сравнить waterfall и scrum со слаболиквидными и рискованными, но сильнодоходными вложениями (например акциями) версус ликвидными, но слабодоходными call money.
Я бы сказал, что основная и главная задача тимлида, ведущего проект — отсмотреть возможные варианты разбиения задачи и выбрать оптимальный «портфеля».
С такой формулировкой полностью соглашаюсь.
Кстати, отличное сравнение с финансовыми аналогами. 🙂
Вообще Scrum есть подмножество Agile техник. А для них всегда указывают: очень плохо подходят для разработки продуктов, в которых требования определены заранее и (практически) неизменны, а также в случае очень жёстких требований к качеству. В качестве примеров приводят проекты в области медицины, военной и космоса. Так что всё логично.
нигде не видел, чтобы говорили «очень плохо подходят». всё дело в том, что как раз жёсткие подходы не подходят для условий постоянно меняющихся требований, а гибкие работают везде. на то они и гибкие 🙂
про качество вообще смешно. одним из основополагающих принципов гибких подходов как раз и есть внедрение качества в процесс.
quality is not negotiable. это из agaile.
Я думаю, имелось в виду, что качество в некоторых проектах не может быть итеративным.
Оно сразу должно быть не ниже X.
По agile по идее нужно постепенно повышать качество в каждом sprint до тех пор пока оно не станет нужного уровня.
не верно. качетсво в агайл всегда постоянно. а итеративно нарасчивается функционал.
при чём если функционал не дотягивает до определения «готово» (например немножко не качественный), то этот функционал просто не считается.
таким образом мы избавляемся от «готово на 75%». у нас или да или нет. при этом если некачественно, то нет.
ok. Тогда в случае если качество завязано на функционале.
Имеется в виду не качество кода (есть баги/нет багов), а качество всей системы.
Вполне возможно, что например 50% реализованного функционала, будут вести к тому, что система фактически будет бесполезна (ее качество как целой система для пользователя будет близко к нулю).
Возвращаяст к аналогии дома. Предположим все этажи достроены, но еще дом внутри не приведен в порядок. Общее качество дома (с точки зрения жилья) все еще равно 0.
но уже можно продавать 🙂 нам же не жить в нём, а деньги заработать.
Вообще написано в книжках. Навскидку нашёл обсуждение: http://www.rsdn.ru/Forum/message/2914631.flat.1.aspx
Гибкие — значит подстраивающиеся, это не значит, что они хорошо подходят везде. Процесс обеспечения качества в Agile: получить «достаточное» качество. Когда вы ваяете записную книжку или файловый менеджер — то получить достаточное качество легко постоянно выкидывая новые версии. Когда требования к качеству высокие (области применения см. выше) — тогда предварительное проектирования (а не рефакторинг и KISS — которые только всё испоганят) и потом разработка.
открою страшный секрет — тяжёлые методики тоже получают всего лишь «достаточное» качество. не больше не меньше.
просто агайл вводит чёткую белую линию — вот тут остановиться и перестать тратить время=деньги на ненужные оптимизации.
а вот где он её проведёт — в 2х шагах для записной книжки или 2 сотнях км для ПО по управлению спутником — зависит от проекта.
есть пример реализации embedded realtime system на С++ командой из _новичков_. Проект длился полтора года. Можно почитать тот же «Мифический человеко-месяц» — основной проблемой не-гибких подходов является нарастание стоимости поддержки большого ПО. Брукс даже говорит, что ПО надо раз в N лет выбрасывать и переписывать наново.
Агайл подходы с этим борются. И все эти короткие итерации, частые поставки и прочие практики — всё это только СРЕДСТВА, а цель — продлить цикл жизни разрабатываемого ПО.
===
но, опять же, не везде надо его продлевать — то же ПО для спутника не рассчитано на дальнейшую модификацию, т.к. этот спутник улетит, а новый будет совершенно другим.
===
и самое главное — при хорошей команде формальный процесс вообще не нужен 🙂 всё работает и так — как в сказке. Агайл типа пытается стимулировать кристаллизацию таких команд.
Согласен с первой частью.
>и самое главное — при хорошей команде формальный процесс вообще не нужен 🙂 всё >работает и так — как в сказке. Агайл типа пытается стимулировать кристаллизацию таких >команд.
А вот с этим коренным образом не согласен.
Хорошая команда уменьшит количество проблем и будет эффективнее плохой команды,
но хорошая комманда с хорошим процессом будет эффективнее хорошей команды без хорошего процесса.
Плюс, опять же, для команды из 3 человек — может формальный процесс и не нужен, для хорошей команды из 20 человек — он еще как нужен.
это уже буквоедство 🙂
хорошая команда тем и хороша, что с сама создаёт процесс под себя. поэтому можно с точки зрения манагера считать, что процесса нет, т.к. им не надо управлять.
так понятнее? 8\
ok. С этим я бы согласился 🙂
Нет, еще непонятнее 🙂
Хорошая команда в резко ухудшающихся условиях легко становится плохой командой, если вообще не исчезает. А руководитель как раз и отвечает за то, что бы условия подходили остальным участникам команды, и наоборот — команда подходила под условия. Гибко? 🙂
Команда (по крайней мере в R&D), которая создает процесс «под себя» (это словосочетание асоциируется с несколько иным случаем 🙂 ), и в которой нет руководителя, лидера — миф. Руководитель, кстати, вполне может быть неформальным 😉
какие-такие меняющиеся условия? 🙂 мы ж про сферических коней в вакууме…
но с другой стороны, лично я не видел, чтобы хорошая команда легко становилась плохой. то есть или её до того переоценивали (считали хорошей, а она была обычной, просто в тепличных условиях) либо её закрыли в концлагерь (условия уж очень поменялись). но это сугубо имхо.
Скорее соглашусь с Артуром.
Хорошая команда, редко складывается сама. Есть люди, которые по кусочкам ее складывают — выкидывают плохие части, чинят то, что можно починить и т.п.
То есть появление хорошей команды происходит не по мановению палочки, а планомерный процесс.
Естественно, также из хорошей команды, плохой — команда станет не по мановению палочки. Но например, плохой менеджер + пару плохих новых членов команды, могут быстренько все изменить.
Есть такая фраза «паршивая овца — все стадо портит». И это вполне происходит и с хорошими командами, особенно если нету человека, который контролирует эту ситуацию.
хорошая команда не примет «паршивую овцу», кстати она может быть и менеджером. проверенно неоднократно — находятся способы и от овцы избавляются.
надо достаточно долго целенаправленно разрушать хорошую команду, которая от невзгод даже бывает сильнее сплочается. опять же всё на личном опыте, так что ногами не бить :).
хорошую команду легче целиком потерять, чем перевести в разряд плохих.
>хорошая команда не примет “паршивую овцу”
>находятся способы и от овцы избавляются.
Что-то выходит всесильная и всепобеждающая хорошая команда.
Плохого менеджера обычно достаточно. Может они и смогут от него избавиться, но вероятнее всего к этому моменту из хорошей команды вполне начнут уходить люди, просто потому, что им интересно делать что-то интересное, а не бороться с плохим менеджером.
Особенно — это касается программистов. Программисты (я сам один из них) — народ достаточно капризный и не будут они до последнего бороться с невзгодами. Просто подымутся и уйдут где лучше.
> Что-то выходит всесильная и всепобеждающая
> хорошая команда.
мы ж про хорошую команду говорим? которая и правда команда, а не просто сборище програмистов, которые хорошо делают своё дело?
> Просто подымутся и уйдут где лучше.
да всё так 🙂 уже писал про это. но при чём тут «хорошая команда»? на самом деле даже просто в команде (в группе, которая прошла уровень norming), человек меняется, раскрывается. перестаёт капризничать, ищет конструктив. а те, которые вышли на режим performing, так они ваще жгут и друг-за-друга держаться.
они скорее уйдут все вместе, чем распадутся.
Не знаю. Может конечно феномен такой в природе встречается, но мне это больше напоминает, что-то из советских фильмов:
Люди, честные, добрые и с горящими глазами.
>которая и правда команда, а не просто сборище >програмистов, которые хорошо делают своё дело?
>человек меняется, раскрывается. перестаёт капризничать, >ищет конструктив. а те, которые вышли на режим >performing, так они ваще жгут и друг-за-друга держаться.
М… Мне кажется, что таких команд должно быть единицы в мире. Из тех, ну скажем десятка команд, что я видел, под эти принципы не подпадает ни одна.
Сначала они все люди и ничто человеческое им не чуждо (алчность, капризность, изменчивость), а уж потом они команда. Никак не в обратную сторону.
Получается, что «тяжелые методики» не определят качество 🙂
Провести линию в «2-х сотнях км» для Agile проблематично, т.к. его качество есть реакция от пользователя и может получится, что эта реакция может простираться на 10 — 20 км и не дальше. А сам подход Agile способствует тому, что используется «сиюминутное» архитектурное решение.
Насчёт спутника: сам говоришь, что Agile подходит не везде.
Любой команде нужен процесс. Даже идеальную команду (которая всё делает сама) нужно мотивировать 🙁 А обычно команда состоит не из идеальных людей.
> Получается, что “тяжелые методики” не определят качество 🙂
нет не получается. но странно, что именно этот параметр исторически не очень формализуется в тяже, а агайл без чёткого «definition of done» просто не мыслим.
> его качество есть реакция от пользователя
не верно. реакция от пользователя определяет функционал. а качество фиксируется явно в определении критерия готовности.
> Насчёт спутника: сам говоришь, что Agile подходит не везде.
не «не подходит», а там и ватерфол работает. надо только считать — стоит ли вкладываться в рефаткоринг или надо вкладываться в big design upfront. что дешевле, то и юзать. но сказать что дешевле в общем случае я не берусь… 🙂 надо смотреть конкретно.
> Любой команде нужен процесс.
да я ж не говорил, что он не нужен. просто хорошей команде не нужен «формальный процесс», т.к. они и так для себя выработали процесс, который даёт результат. пусть он и не зафиксирован.
мотивация это отдельная грустная песня 🙁
Попробуйте » В случае необходимости больших переделок проекта» использовать другое течение Agile — lean software development. Если Вы незнакомы (хотя сомневаюсь) с этим процессом, то рекомендую почитать эту вводную статью — http://www.poppendieck.com/pdfs/Lean_Software_Development.pdf
Оффтоп: я отвечала на Ваш вопрос в топике «Компанейская архитектура», но ответ почему-то не опубликовался. Если интересно, могу кинуть на мыло.
Спасибо погляжу.
Насчет неопубликовааности, я в spam загляну. Больная проблема, что если выключить спамосборник, то гигантская куча спама идет, если включить, то что-то попадает туда.
Ну и если не трудно, киньте на email.
Богатство ассоциаций не всегда свидетельствует о богатстве воображения…
http://victorronin.com/2008/10/23/ckrummnoe/…
Тот, кто, обращаясь к старому, способен открывать новое, достоин быть учителем…
http://victorronin.com/2008/10/23/ckrummnoe/…