Издательство: Вильямс, 2011 г.
Твердый переплет, 576 стр.
От издателя
Эта книга представляет собой авторитетное, реалистичное и имеющее большое практическое значение руководство по быстрому освоению Scrum и гибкой методологии разработки и последующему закреплению достигнутых результатов на длительное время. Ведущий консультант и практик в области гибкой методологии разработки Майк Кон предоставляет подробные рекомендации, эффективные советы и практические примеры из реальной жизни. Залогом надежности этих рекомендаций и советов является богатый практический опыт автора, который помог не одной сотне организаций, занимающихся разработкой программного обеспечения, успешно внедрить у себя Scrum и гибкую методологию разработки.
Данная книга предназначена для прагматичных специалистов в области разработки программного обеспечения, которые хотят получить надежные, заслуживающие доверия ответы на большинство трудных вопросов, с которыми им приходится сталкиваться в процессе внедрения Scrum. В своей книге Кон описывает все аспекты процесса внедрения: запуск процесса, оказание людям помощи в освоении ими своих новых ролей, структуризация коллективов, увеличение охвата, работа с рассредоточенным коллективом и, наконец, внедрение эффективных показателей и непрерывное совершенствование.
В книге Кона то там, то здесь встречаются врезки под заголовком "Попробуйте прямо сейчас", включающие наиболее эффективные советы Кона. Во врезках под заголовком "Возражения" автор воспроизводит типичные дискуссии с теми, кто сопротивляется переменам, и дает практические рекомендации, которые позволят вам аргументированно ответить на подобные возражения и развеять сомнения людей.
В книге освещаются следующие вопросы.
Практические способы немедленного начала внедрения — а также быстрого повышения вашей квалификации и получения желаемых результатов.
Способы преодоления индивидуального сопротивления переменам, которых требует Scrum.
Кадровое обеспечение Scrum-проектов и формирование эффективных коллективов.
Формирование сообществ в поддержку усовершенствования организации из энтузиастов.
Выбор технических приемов гибкой методологии разработки, которыми следует воспользоваться (или как минимум поэкспериментировать).
Руководство деятельностью самоорганизующихся коллективов.
Как добиться максимальной эффективности от Scrum-спринтов, планирования и методов повышения качества.
Распространение Scrum на проекты с рассредоточенными коллективами и на проекты, предполагающие использование нескольких коллективов.
Применение Scrum к проектам со сложными последовательными процессами или к проектам, которые должны отвечать требованиям различных стандартов.
Влияние Scrum на вопросы кадров, технического обеспечения и управления проектами.
Независимо от того, выполнили ли вы лишь несколько спринтов или даже несколько проектов с применением гибкой методологии разработки, и от того, какова ваша нынешняя роль (менеджер, разработчик, наставник, руководитель Scrum-проекта, владелец продукта, аналитик, лидер коллектива или лидер проекта), эта книга поможет вам добиться еще большего успеха в вашем следующем проекте. Но она поможет вам и в гораздо более важном и ответственном деле: преобразовать всю вашу организацию.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>http://www.ozon.ru/context/detail/id/6241964/ LVV>Майк Кон LVV>Scrum. Гибкая разработка ПО LVV>Succeeding with Agile: Software Development Using Scrum
Здравствуйте, bkat, Вы писали:
B>больше 500 страниц о скраме B>И после этого они критикуют "неподъемный" RUP
А это, на самом деле, интересный парадокс. В SCRUM минимальное количество формальных правил и процедур, но это только кажущаяся простота. Успешное внедрение скрама, при котором, собственно, и получается обещанный профит — требует очень глубокого понимания стоящей за описанием процесса философии, того, какую задачу решает тот или иной компонент процесса, и как они между собой взаимодействуют. В противном случае, чаще всего, имеем либо SCRUM-butt, либо, что ненамного лучше, "ортодоксально-религиозный" скрам строго по книжке. Обоснованно предполагаю, что 500 страниц книги Кона и посвящены в основном вопросам понимания того, как скрам работает на самом деле и как правильно его "готовить".
У RUP обратная проблема — "из коробки" процесс излишне формализован, и пресловутые 500 страниц были бы в основном посвящены описанию ролей, процедур и т.п. И внедрение RUP "по книжке" точно так же может не дать желаемого эффекта. Руководство же по адаптированию RUP под условия конкретного проекта (если таковое существует, без сарказма — я действительно не в курсе) на 500 страниц — было бы не менее ценным.
Здравствуйте, DmytroL, Вы писали:
DL>Здравствуйте, bkat, Вы писали:
B>>больше 500 страниц о скраме B>>И после этого они критикуют "неподъемный" RUP
DL>А это, на самом деле, интересный парадокс. В SCRUM минимальное количество формальных правил и процедур, но это только кажущаяся простота. Успешное внедрение скрама, при котором, собственно, и получается обещанный профит — требует очень глубокого понимания стоящей за описанием процесса философии, того, какую задачу решает тот или иной компонент процесса, и как они между собой взаимодействуют. В противном случае, чаще всего, имеем либо SCRUM-butt, либо, что ненамного лучше, "ортодоксально-религиозный" скрам строго по книжке. Обоснованно предполагаю, что 500 страниц книги Кона и посвящены в основном вопросам понимания того, как скрам работает на самом деле и как правильно его "готовить".
Да, это парадокс, но очень легко объясняемый.
То, что дается на курсах, презентациях и т.п. рассчитано прежде всего на менеджеров, принимающих решения.
Для них должно быть все предельно упрощено и понятно.
Ну плюс все это дело усиленно разбавляется свойственной американцам показным задором и верой в собсвенную правоту.
Короче маркетинг в чистом виде.
О best practices говорят мало. Если о них начинают говорить,
то тут же всплывают нестыковки с формальными правилами (к примеру 3-мя ролями никак не обойтись).
Если ты опытный и тебе удалось таки сварить кашу из топора,
то это приписывают исключительно скраму. Если не удалось, то тебе будут говорить,
что это ты скрам не так приготовил (scrum but).
Еще забавно наблюдать, как они меняют свои презентации.
Еще не так давно Нокия была показательным примером.
Теперь о Нокия не упоминают...
Понятно, что врядли там все рухнуло только из-за скрама,
но установленные процессы еще как влияют на успех/неуспех компании.
Здравствуйте, bkat, Вы писали:
B>Здравствуйте, LaptevVV, Вы писали:
LVV>>Твердый переплет, 576 стр.
B>О ёёёё... B>больше 500 страниц о скраме B>И после этого они критикуют "неподъемный" RUP
Скрам — мрак полный. До чего он только Нокию довел, то подумать страшно. Вот если он во всем мире расплодятся... Не вольно верится в сказки о конце света.
B>О ёёёё... B>больше 500 страниц о скраме B>И после этого они критикуют "неподъемный" RUP
В те 500 страниц поместился вагон философствования на тему "что такое хорошо, и что такое плохо". А также всякие примеры, к собственно скраму отношения не особо имеющие. Ну те же вопросы финансов. Не помню, в RUP там вообще есть ли об этом речь, кроме как в условных "ресурсах".
Ну и верно было отмечено, что скрам нельзя просто "взять и внедрить", ничего хорошего из этого не выйдет. Нужен человек, хорошо понимающий тонкости процесса. Уже наступавший на грабли, и обязательно видевший примеры успешного и неуспешого применения. Я видел и то, и другое. И видел совсем занятный fail скрама благодаря стараниям менеджмента В общем, книжки можно писать сколь угодно большой длины, но заработает скрам только тогда, когда будет ЖЕЛАНИЕ иметь открытый и контролируемый процесс. Причем желание — со стороны менеджмента. Мой опыт показывает, что в большинстве случаев "линейному менеджменту" в России выгоднее иметь очень мутный, сложный и странный процесс разработки, по которому ничего нельзя сказать без вопросов непосредственному начальнику проекта. Поэтому любые попытки ввести прозрачный процесс (неважно, скрам или что угодно еще) будут пофейлены.
Здравствуйте, shrecher, Вы писали:
S>Скрам — мрак полный. До чего он только Нокию довел, то подумать страшно. Вот если он во всем мире расплодятся... Не вольно верится в сказки о конце света.
Сам по себе скрам вполне можно юзать.
Для небольших команд (5-6 человек) вполне применим даже в том виде,
как его подают на курсах/презентациях и прочих "рекламных" акциях.
Главное не забывать о многих других, не менее важных чем daily scrum, практиках
B>Сам по себе скрам вполне можно юзать. B>Для небольших команд (5-6 человек) вполне применим даже в том виде, B>как его подают на курсах/презентациях и прочих "рекламных" акциях.
Если команда является частью "чего-то бОльшего", да еще и с какой-нибудь "традиционной" (С) иерархической структурой, контролируемой по принципу "я начальник — ты дурак", то тоже ничего не выйдет.
Рамки применения SCRUM все-таки достаточно узкие. Он пойдет только в том случае, если целью является предсказуемный процесс и результат.
Здравствуйте, SkyDance, Вы писали:
B>>Сам по себе скрам вполне можно юзать. B>>Для небольших команд (5-6 человек) вполне применим даже в том виде, B>>как его подают на курсах/презентациях и прочих "рекламных" акциях.
SD>Если команда является частью "чего-то бОльшего", да еще и с какой-нибудь "традиционной" (С) иерархической структурой, контролируемой по принципу "я начальник — ты дурак", то тоже ничего не выйдет. SD>Рамки применения SCRUM все-таки достаточно узкие. Он пойдет только в том случае, если целью является предсказуемный процесс и результат.
Ты еще забыл добавить scrum is all about FUN!!!
На словах все процессы говорят о предсказуемых процессах и результатах.
Никто не декларирует своей целью хаос и банкротство.
Это потому, что фан идет первый десяток итераций, дальше начинается тупое ломилово
B>На словах все процессы говорят о предсказуемых процессах и результатах. B>Никто не декларирует своей целью хаос и банкротство.
Ага. "Но есть один нюанс" (С). Со scrum процесс действительно предсказуем — видна velocity и виден scope. Любое изменение в scope сразу же наглядно показывает съезжание сроков. Любые изменения в составе команды — аналогично. Практически realtime planning. Настоящий.
Разумеется, все (в т.ч. waterfall) методологии в теории обеспечивают то же самое. Вот только на практике всего этого добиться невозможно. Можно рассмотреть типовый примеры. Прибегает восхищенный менеджер, и говорит, что все классно, но! Надо вот там еще пимпочку, а тут — крутилку. В scrum — пишутся user stories, оцениваются — и попадают в нужное место backlog'а. В зависимости от того, идет ли time-driven или scope-driven, что-то меняется (scope или time соответственно).
В других моделях — кто что предлагает. Но в столь любимом "военном" RUP'е надо будет проводить change request — менять (апдейтить) спецификации. Проталкивать через все стадии согласований. Я уж не говорю про то, что мегатонны спек читать невозможно (been there, done that — да, если с системой только знакомишься, удобнее читать полную доку, но если ты уже "живешь" в системе — то хочется только краткие diff'ы, апдейты).
Не буду удлиннять и без того длинный пост. Для меня разница есть лишь в одном: я видел предсказуемый процесс и результат с помощью scrum. А вот с другими метОдами — только что-то одно: результат без процессов (зачастую — вопреки "процессам"), либо "процесс", но без результата.
Охотно верю, что у кого-то получился успех с "тяжеловесными" методами. Просто я ни разу не видел реально работающего тяжелого процесса в конторе, производящей коммерческий коробочный софт. Но ведь в НАСА (или где-то около) применяли RUP, значит, можно же. Если бюджет такой как у них, и по времени нет проблем, почему нет
Если кто-то участвовал — поделитесь опытом. Реально ведь интересно!
Здравствуйте, SkyDance, Вы писали:
SD>Ага. "Но есть один нюанс" (С). Со scrum процесс действительно предсказуем — видна velocity и виден scope. Любое изменение в scope сразу же наглядно показывает съезжание сроков. Любые изменения в составе команды — аналогично. Практически realtime planning. Настоящий.
Построить burn-up и burn-down chart по задачам несложно при абсолютно любом процессе, скрам для этого не нужен. Таким образом люди спокон веков выпуск maintenance release, состоящих их ошибок и доработок, отслеживают.
G>Построить burn-up и burn-down chart по задачам несложно при абсолютно любом процессе, скрам для этого не нужен. Таким образом люди спокон веков выпуск maintenance release, состоящих их ошибок и доработок, отслеживают.
Можно. Только придется тогда притащить еще кое-что — в частности, гранулярность сценариев (user stories — сильно отличаются от traditional use-cases) и методы оценки в относительных величинах (да, planning poker тоже был известен до скрам).
И "утренние летучки" (stand-up) придумали газетчики-журналисты еще в XIX веке. Оценивать задачи относительно друга (а не выдавать заведомо неверные оценки — см. mythical man-month) тоже уже предлагалось. Но только в scrum эти простые практики собраны и разумным образом увязаны.
"Все уже украдено до нас". Но я повторю свой вопрос: кто (и в каких условиях) участвовал в успешном проекте, выполненным с применением, например, RUP или чего-то еще такого? Расскажите, интересно же. Где вы срезали углы и почему. Сколько тысяч копий было продано (обсуждать софт, проданный единицами-десятками экземпляров, я не готов, и вообще смысла в этом не вижу — другая епархия).
SD>В scrum — пишутся user stories, оцениваются — и попадают в нужное место backlog'а. В зависимости от того, идет ли time-driven или scope-driven, что-то меняется (scope или time соответственно).
Это все так если разработка-фабрика: потоковое шлепанье формочек и фичек. Очевидно, что разработка программного продукта далеко не фабрика (конечно, если не аутсорс). Это исследования, творчество, сложные проблемы и пр. Да, Scrum удобен для менеджмента, но полностью душит творческое начало. Отсюда и проблемы.
Если посмотреть как работают истинно инновационные компании (dropbox, google и пр.), то там предоставлена свобода программистам самим решать как им работать (и даже "что" собственно делать). В результате он выдают новинки на гора.
Как пример, Нокия (активный апологет скрама) за последнии 10 лет так и не смогла сделать ничего инновационного, с другой стороны пришел Гугл и за три года сделал конкурента, который вышиб Нокию с рынка. Тут, конечно, не только виноват Скрам, но то, что он душит творчество это факт.
S>Это все так если разработка-фабрика: потоковое шлепанье формочек и фичек. Очевидно, что разработка программного продукта далеко не фабрика (конечно, если не аутсорс).
Подавляющая часть разработки — именно фабрика. И неважно, "формочки" это или виртуальные машины. "Творческое начало" работает только на, прошу прощения за тавтологию, начальной стадии проекта. Когда пишется прототип, или еще что-то этакое.
Но как только появились заказчики, обещания, сроки, scope и прочие, как вы выразились, "удобные для менежмента" штуки — так сразу все вырождается в фабрику.
S>Если посмотреть как работают истинно инновационные компании (dropbox, google и пр.), то там предоставлена свобода программистам самим решать как им работать (и даже "что" собственно делать). В результате он выдают новинки на гора.
И за это их ненавидят. Особенно гугл, эту империю зла. За то, что от них — ничего: ни обещаний сроков, ни понимания, когда случится релиз. Такое поведение себе могут позволить только очень обеспеченные компании-монополисты, еще не повязшие в партнерских соглашениях. Вот, к примеру, Microsoft так поступить не может — у них есть сроки, релизы и т.п.. А Apple — может (пусть и в некоторых рамках), потому что является тем самым богатым монополистом. И, отмечу, это именно Apple, а вовсе не гугл, потеснила Нокию. Только виноват в том не скрам, а совсем другие причины (в первую очередь — изначально идиотскую Psion OS -> Symbian, которую бы ничто не спасло). Продавались Нокии как телефоны. Именно как телефоны. Но на этом поприще ее съели подтянувшиеся китайцы.
Про "душаший творчество скрам" — это сильно Зато RUP, надо думать, творчество просто поощряет! В вашем понимании не душит творчество только один процесс, bardak его называют. Мечта любого стартапа: чтобы денег давали, но никаких обещаний не требовали, сроки не зажимали и вообще не лезли.
Re[7]: Вышла книжка по SCRUM
От:
Аноним
Дата:
21.06.11 08:31
Оценка:
Здравствуйте, SkyDance, Вы писали:
SD>Если кто-то участвовал — поделитесь опытом. Реально ведь интересно!
Да полно таких проектов.
Сколько лет скраму, и сколько лет уже разрабатывают софт?
Противопоставлять тот же RUP скраму нет смыла.
Проблема скрама в том, что это тупик, из которого нету нормального выхода.
Что я имею ввиду?
Если взять тот же RUP, то его всегда надо адаптировать под реалии (это важный пункт).
В итоге по RUP'у может получится и водопад, и скрам и любой другой разумный процесс.
RUP это допускает.
Скрам — это как религия. Из скрама ничего кроме скрама получится в принципе не может,
несмотря на вроде бы встроенные механизмы рефлексии (sprint retrospective).
Re[5]: Вышла книжка по SCRUM
От:
Аноним
Дата:
21.06.11 21:18
Оценка:
Здравствуйте, SkyDance, Вы писали:
B>>Сам по себе скрам вполне можно юзать. B>>Для небольших команд (5-6 человек) вполне применим даже в том виде, B>>как его подают на курсах/презентациях и прочих "рекламных" акциях.
SD>Если команда является частью "чего-то бОльшего", да еще и с какой-нибудь "традиционной" (С) иерархической структурой, контролируемой по принципу "я начальник — ты дурак", то тоже ничего не выйдет. SD>Рамки применения SCRUM все-таки достаточно узкие. Он пойдет только в том случае, если целью является предсказуемный процесс и результат.
Практики — это что-то из области йоги. А здесь — работа. Для средних и больших проектов scrum & agile только мешают. Невозможно сначала делать, а потом думать. А если будем сначала думать, а потом делать, то получим классический водопад, столь ненавидимый шарлатанами от agile. Говорю это, как человек испытавший на своей шкуре разрушение софтверной фирмы. Если Вам скажут иначе — не верьте, ведь они на внедрении методик-практик всяких, продаже планер-покер-карт и книг по скраму денежку зарабатывают, и на эти два прОцента и живут.
Вы не могли бы представиться? А то с Анонимом (да еще и с разными) сложновато общаться.
А>Да полно таких проектов.
Вот-вот. Проектов полно, но почему-то никто так ни про один и не рассказал. Что это за проекты такие? Все секретные, сдается мне.
А>Противопоставлять тот же RUP скраму нет смыла.
Так противопоставления и нет. Я пишу, что работающий скрам я видел (и участвовал). В попытке работать по RUP — тоже. В некотором смысле попытка была успешной, софт все-таки зарелизили, но, скорее, вопреки, чем благодаря. Само собой, где-то уже с середины проекта все возможные углы срезАлись по максимуму, иначе бы вообще ничего не выпустили.
А>Если взять тот же RUP, то его всегда надо адаптировать под реалии (это важный пункт). А>В итоге по RUP'у может получится и водопад, и скрам и любой другой разумный процесс. А>RUP это допускает. А>Скрам — это как религия. Из скрама ничего кроме скрама получится в принципе не может, А>несмотря на вроде бы встроенные механизмы рефлексии (sprint retrospective).
Гм. Все слова вроде понимаю, но что вы хотели сказать — нет. Да, RUP нужно адаптировать. И в этом его огромный недостаток — внедрение чего-то RUP'о-подобного, если вообще получается, занимает столько ресурсов, что всегда встает вопрос его окупаемости. Бюджет, уходящий на "адаптацию" и на обучение всех, может с лёгкостью перекрыть бюджет разработки
Нет, из RUP'а не может получиться скрам — потому что RUP не описывает штуки вроде приоретизации записей backlog'а или "утренних time-boxed летучек" (stand-up meeting). Если пытаться его под это подогнать — будет совсем уже никакой не RUP.
Про "недостаток" скрама — извините, непонятно. Да, из скрама RUP не получится (потому что это принципиально разные подходы, описывающие разные стороны работы компании). Только зачем это может быть кому-то нужно?
А> Для средних и больших проектов scrum & agile только мешают.
Конечно, мешают. Чаще всего мешают "манагерам", которым прозрачность в проекте вовсе ни к чему. Такой процесс я тоже наблюдал: применение скрам наглядно показало, что scope проекта с существующими ресурсами ни под каким соусом не может быть выполнен в спущеные сверху сроки.
Как это выглядело до скрам: манагер рапортовал "вроде успеваем", по мере приближения очередного срока релиза оказывалось, что надо отложить, но совсем на чуть-чуть, буквально на месяц-полтора. И так в течение целого года (!!!). После реализации скрам подобный фокус тупо не прошел: было видно, сколько чего сделано, виднА реальная скорость работы (основанная на статистике работы, а не на тех оценках, которые все те же манагеры заставляли (да, именно так, — заставляли) давать. Если интересно, могу описать (хотя я уже несколько раз писал про антипаттерн lie to me).
Естественно, в варианте со скрамом по шапке попало манагерам Потому что свалить на плохих разработчиков, которые давали заниженные сроки, уже не катило. А дальше я с горечью наблюдал титанический труд по обвинению скрам (разумеется, со стороны тех самых манагеров) во всех грехах. Провалы заведомо нереалистичных ожиданий по проектам списали на... внедрение скрама Вот такая жизненная история. В крупной и уважаемой компании. С хорошими, интересными проектами и вполне разумными зарплатами.
A >А если будем сначала думать, а потом делать, то получим классический водопад, столь ненавидимый шарлатанами от agile.
Да нет никакой ненависти к водопаду Есть любопытство: кто же все-таки первый расскажет и покажет проект, РЕАЛЬНО подготовленный с помощью "водопада" или подобной метОдики. С полным и настоящим соблюдением правил: с реальным разделением ролей, с реальным получением approve'ов, с отсутствием правки спецификаций "задним числом". Разумеется, с соблюдением сроков и бюджетов проекта. Ну хоть кто-нибудь, расскажите же, какой реально существующий продукт хотя бы с пароу сотен инсталляций так сделан? Поделитесь же тайным знанием! Как адаптировали. Как решали проблему ответственности начальства (когда затягиваются или вовсе игнорируются запросы на формальные review созданных документов). Как решали проблему с постоянно идущими change request, когда ближе к релизу чтение первых вариантов спецификаций "доставляло не по-детски": там ВСЕ было СОВСЕМ не так, как пойдет в реальном софте.
Заметьте — я не стесняюсь рассказывать обо всем про скрам. Потому что я видел и участвовал. Но вот противники "шарлатанов от agile" сами почему-то либо молчат, либо рассказывают свои фантазии на тему (например, про то, как у них вдруг неожиданно появляется чудесный "заказчик", который всегда знает, чего хочет, и всегда официально-формально подписывает все положенные документ).
SD>Да нет никакой ненависти к водопаду Есть любопытство: кто же все-таки первый расскажет и покажет проект, РЕАЛЬНО подготовленный с помощью "водопада" или подобной метОдики. С полным и настоящим соблюдением правил: с реальным разделением ролей, с реальным получением approve'ов, с отсутствием правки спецификаций "задним числом". ...
Водопад, в точности соответствующий приведенному Вами описанию, в результате которого получилось поиметь 300 инсталляций, здесь вряд-ли кто-либо покажет. Да Вам это и не нужно, я думаю .
SD>Заметьте — я не стесняюсь рассказывать обо всем про скрам. Потому что я видел и участвовал. ...
Только конкретики-то вроде особо не было: что за проекты, какая специфика, как делали, какие проблемы были, как решали и пр. Или я плохо читал ?
Могу сказать точно также: все проекты, в которых участвовал за много лет, делались по BDUF/ГОСТ. Один из них имеет "базу инсталляций" в районе 10000 копий в течение 3-х лет после релиза. А один полностью провален, в том числе благодаря попытке использовать XP (как раз тогда книжка Кента Бека вышла). И что? Начнем флейм?
Здравствуйте, SkyDance, Вы писали:
B>>Ты еще забыл добавить scrum is all about FUN!!!
SD>Это потому, что фан идет первый десяток итераций, дальше начинается тупое ломилово
B>>На словах все процессы говорят о предсказуемых процессах и результатах. B>>Никто не декларирует своей целью хаос и банкротство.
SD>Ага. "Но есть один нюанс" (С). Со scrum процесс действительно предсказуем — видна velocity и виден scope. Любое изменение в scope сразу же наглядно показывает съезжание сроков. Любые изменения в составе команды — аналогично. Практически realtime planning. Настоящий.
Эх...
Если бы все так было просто
Велосити видна, но scope на самом деле не виден.
Backlog не претендует на полноту и точность в любой момент времени.
Наиболее приоритетные вещи на ближайшие пару спринтов более менее оценены и детализированы,
а все остальное в весьма смутном состоянии. Что означает такую же неопределенность как и без скрама.
Насчет самих PBI (Product Backlog Items)...
Если писать их действительно как user story (взгляд на систему конечного пользователя),
то очень многие из них получаются слишком большими (не влезают в один спринт для одной команды).
Поэтому их приходится дробить. В результате дробления получаются довольно разумные штуки,
которые хорошо оцениваются, но user story уже по сути не являются. Получаются довольно технические PBI.
Это приводит к тому, что в реалии в Product Backlog полнейшая каша из по сути
функциональных требований, use case'ов и технических спецификаций.
Product Backlog в котором соседствуют настоящие юзер стори и вещи типа
"я как девелопер мечтаю реализовать интерфейс IFTF"" — это суровая реальность.
Бедный Product Owner...
Он должен быть и жнец и на дуде игрец, чтобы этот хаос контролировать.
В классических процессах все эти вещи чесно разделяют и прямо говорят, жизнь сложна.
Нужны спеки, чтобы понять что надо делать и нужен desing, чтобы описать как все это дело надо реализовать.
Все это дело разносится по разным документам и для работы с этим делом нужны разные люди.
Ты спрашиваешь про примеры, где это реально работает.
У меня лично есть такой опыт. Только тебе все же придется разрешить итеративность и для того же RUP.
Никто не запрещает менять спеки.
Классические процессы просто рекомедуют с кем это надо согласовывать и оценивать.
По тому же RUP'у запрос на изменение будет либо отвергнут, потому что нету времени,
либо проект будет продлен на нужное время. Как это работает видел множество раз.
Более того...
У меня сейчас есть уникальная возможность сранить 2 компании, разрабатывающие по сути одно и то же.
Одна работает по скраму, а другая — V model с итерациями.
Скрамная команда в 2 раза больше и делает в 2 раза меньше.
Зато велосити меряется и менеджемент за год вперед знает, что не успеваем
Куча энергии расходуется впустую именно из-за скрама.
Детальный анализ всего этого уже выходит за рамки поста на форуме.
B>Велосити видна, но scope на самом деле не виден.
Виден, вполне виден.
B>Backlog не претендует на полноту и точность в любой момент времени. B>Наиболее приоритетные вещи на ближайшие пару спринтов более менее оценены и детализированы, B>а все остальное в весьма смутном состоянии. Что означает такую же неопределенность как и без скрама.
Не соглашусь. Во-первых, нормальный backlog как раз содержит scope хотя бы на уровне очередного релиза (в реальности, там еще зачастую столько же item'ов, которые в традиционном подходе называются nice-to-have, и идут они глубоко в конце бэклога). Во-вторых, все, повторюсь, ВСЕ сценарии из бэклога оценены — относительно друг друга. Т.е. общую сумму story points на очередной релиз известна с достаточной точностью.
B>Насчет самих PBI (Product Backlog Items)... B>Если писать их действительно как user story (взгляд на систему конечного пользователя), B>то очень многие из них получаются слишком большими (не влезают в один спринт для одной команды).
Это ошибка начинающего PO. Когда я не понимал сути user stories, и получались те самые "очень большие стори, не влезающие в итерацию". Но было это лишь оттого, что они не были атомарными. Меж тем, это важнейшее свойство — атомарность. Поясню на примере: "пользователь хочет список серверов, сортируемый по Х, Y, Z, T, чтобы выбирать те из них, которые будут перезагружены". С точки зрения начинающего — вполне нормальный кусок законченной функциональности: форма, в которой есть таблица со списком серверов, с возможностью multiselect'а, с сортировкой таблицы по разным свойствам этих серверов, и кнопка 'reboot', которая перезагружает указанные серверы.
Вполне допускаю, что такую неверно сформулированную user story за одну итерацию маленькой командой не написать. А все потому, что в той стори минимум 4 _реальных_ user story. Первая — базовая — выбор одного сервера из несортируемого списка. Вторая — "пользователь хочет сортировать серверы по их IP-адресам, потому что он часто не помнит их по именам". Каждая из этих story несет added value. А значит, может идти "за отдельные деньги" (С)
B>Product Backlog в котором соседствуют настоящие юзер стори и вещи типа B>"я как девелопер мечтаю реализовать интерфейс IFTF"" — это суровая реальность. B>Бедный Product Owner... B>Он должен быть и жнец и на дуде игрец, чтобы этот хаос контролировать.
Должен, конечно. Кто ж спорит. Но мы речь ведем о команде профессионалов? С какого бодуна РО допустит появление в бэклоге записи о желаниях девелопера? Такая запись нарушает INVEST-свойство (букву "V", в частности). РО в скраме шишек достается больше всех. И найти хорошего РО ничуть не проще, чем хорошего скраммастера. Даже, пожалуй, сложнее.
B>У меня лично есть такой опыт. Только тебе все же придется разрешить итеративность и для того же RUP.
RUP разрешает итеративность (кроме самых первых редакций, но они уже давно неинтересны).
B>Классические процессы просто рекомедуют с кем это надо согласовывать и оценивать.
Верно. Вот мой вопрос: как решается проблема согласования? Сколько согласантов? В моём опыте, при количестве более 2, процесс согласования превращается в бесконечный циклический бардак, либо в полную формальность, когда согласанты на 3й раз уже даже и не вчитываются.
B>По тому же RUP'у запрос на изменение будет либо отвергнут, потому что нету времени, B>либо проект будет продлен на нужное время. Как это работает видел множество раз.
Как вы решаете проблему разницы между ideal (estimation-based) и real man-hour? Ведь то, что наоценивали, с тем, как будет делаться, никогда не сходится. Даже с полнейшими спецификациями
B>У меня сейчас есть уникальная возможность сранить 2 компании, разрабатывающие по сути одно и то же. B>Одна работает по скраму, а другая — V model с итерациями. B>Скрамная команда в 2 раза больше и делает в 2 раза меньше.
Уровень сотрудников, надо полагать, одинаков? Или в первой команде 10 студентов, во второй — 5 профессионалов? А как оценивается "сделано"? В скрам продукт готов к выходу в конце каждой итерации (в идеале), либо с гарантией к завершению в течение 1-2 следующих итераций (в реале — стабилизационные спринты). Что с V-model, не получится ли так, что к релизу окажется, что требования изменились, все надо переписывать, плюс в багзилле — 800 багов, из которых 400 надо _реально_ фиксить, и требуется еще полгода на доработку?
Все ли затраты учтены в V-model? В смысле, кто пишет спецификации, кто верифицирует, какое количество людей в этом _реально_ вовлечено.
Ах да, еще, вдвое больше людей — вчетверо больше затраты на коммуникации. Не забывайте про это. Неспроста 5 профессионалов всегда вдвое быстрее 10 середнячков.
B>Зато велосити меряется и менеджемент за год вперед знает, что не успеваем
Так ведь это и есть важнейшее свойство! Заранее знать — успеваем, не успеваем. Знать статус проекта! Для этого скрам и затевается. Для того он и нужен — обеспечить прозрачность и понятность процесса. Как я и писал, именно этим он и неудобен всяческим "менеджерам проектов". И именно потому эти "менеджеры" так стараются избавиться от скрам всеми силами
B>Куча энергии расходуется впустую именно из-за скрама.
Угу. То есть для вас понимание, что происходит с проектом, это "впустую потраченное время". Странно. Обычно это, напротив, дорогого стоит. А спецификации — это не впустую? А вы сравнивали, сколько ушло на V-model (напоминаю — включайте туда создание спецификаций, долгие митинги и согласования, все-все-все, иначе сравнение странное выходит).
PS: кажется, я чуть-чуть вас понял. У скрам-команды нет нормального РО, их бэклог представляет из себя кучу малу. При этом во второй (v-model) команде уже есть (откуда?) хорошие спецификации продукта, который надо сделать. Первая команда работает, очевидно, медленнее. И виноват в этом, барабанная дробь, разумеется, скрам а вовсе не бездарный РО. Вы, случаем, не бывший "менеджер проекта нумер 1" ?
Здравствуйте, SkyDance, Вы писали:
B>>Велосити видна, но scope на самом деле не виден.
SD>Виден, вполне виден.
B>>Backlog не претендует на полноту и точность в любой момент времени. B>>Наиболее приоритетные вещи на ближайшие пару спринтов более менее оценены и детализированы, B>>а все остальное в весьма смутном состоянии. Что означает такую же неопределенность как и без скрама.
SD>Не соглашусь. Во-первых, нормальный backlog как раз содержит scope хотя бы на уровне очередного релиза (в реальности, там еще зачастую столько же item'ов, которые в традиционном подходе называются nice-to-have, и идут они глубоко в конце бэклога). Во-вторых, все, повторюсь, ВСЕ сценарии из бэклога оценены — относительно друг друга. Т.е. общую сумму story points на очередной релиз известна с достаточной точностью.
Но она может очень сильно плавать по мере переоценки PBI в ходе проекта.
Точность получается такой же как и в проектах без скрама.
B>>Насчет самих PBI (Product Backlog Items)... B>>Если писать их действительно как user story (взгляд на систему конечного пользователя), B>>то очень многие из них получаются слишком большими (не влезают в один спринт для одной команды).
SD>Это ошибка начинающего PO. Когда я не понимал сути user stories, и получались те самые "очень большие стори, не влезающие в итерацию". Но было это лишь оттого, что они не были атомарными. Меж тем, это важнейшее свойство — атомарность. Поясню на примере: "пользователь хочет список серверов, сортируемый по Х, Y, Z, T, чтобы выбирать те из них, которые будут перезагружены". С точки зрения начинающего — вполне нормальный кусок законченной функциональности: форма, в которой есть таблица со списком серверов, с возможностью multiselect'а, с сортировкой таблицы по разным свойствам этих серверов, и кнопка 'reboot', которая перезагружает указанные серверы. SD>Вполне допускаю, что такую неверно сформулированную user story за одну итерацию маленькой командой не написать. А все потому, что в той стори минимум 4 _реальных_ user story. Первая — базовая — выбор одного сервера из несортируемого списка. Вторая — "пользователь хочет сортировать серверы по их IP-адресам, потому что он часто не помнит их по именам". Каждая из этих story несет added value. А значит, может идти "за отдельные деньги" (С)
Речь именно об атомарных и неделимых юзер стори.
Одна юзер стори может вылеться в несколько человеко лет.
На новых проектах таких примеров — кажный второй.
B>>Product Backlog в котором соседствуют настоящие юзер стори и вещи типа B>>"я как девелопер мечтаю реализовать интерфейс IFTF"" — это суровая реальность. B>>Бедный Product Owner... B>>Он должен быть и жнец и на дуде игрец, чтобы этот хаос контролировать.
SD>Должен, конечно. Кто ж спорит. Но мы речь ведем о команде профессионалов? С какого бодуна РО допустит появление в бэклоге записи о желаниях девелопера? Такая запись нарушает INVEST-свойство (букву "V", в частности). РО в скраме шишек достается больше всех. И найти хорошего РО ничуть не проще, чем хорошего скраммастера. Даже, пожалуй, сложнее.
B>>У меня лично есть такой опыт. Только тебе все же придется разрешить итеративность и для того же RUP.
SD>RUP разрешает итеративность (кроме самых первых редакций, но они уже давно неинтересны).
B>>Классические процессы просто рекомедуют с кем это надо согласовывать и оценивать.
SD>Верно. Вот мой вопрос: как решается проблема согласования? Сколько согласантов? В моём опыте, при количестве более 2, процесс согласования превращается в бесконечный циклический бардак, либо в полную формальность, когда согласанты на 3й раз уже даже и не вчитываются.
Даже в сраме согласантов больше 2.
Хотя тут надо уточнить, что ты понимаешь под согласовнием и какова его цель.
Согласовать — это убедиться, что все кому надо понимают, что имеется ввиду,
соглашаются это сделать и дают оценки, когда это будет сделано.
Согласовывать надо прежде всего с заказчиками (или тем, кто его представляет), разработчиками и тестерами.
В скраме это происходит постоянно и принимают в этом участие PO и команда.
PO создает новые PBI, команда их читает, обсуждает, оценивает.
В результате PBI может быть перефорулировать или выброшен на помойку.
Все это и есть согласование.
Но на интердисциплинарных проектах часто даже непонятно, кто и как будет делать некую вещь.
Т.е. фича очень четко формулируется, но реализовать ее можно и в софте,
и в железе и еще бог знает как.
B>>По тому же RUP'у запрос на изменение будет либо отвергнут, потому что нету времени, B>>либо проект будет продлен на нужное время. Как это работает видел множество раз.
SD>Как вы решаете проблему разницы между ideal (estimation-based) и real man-hour? Ведь то, что наоценивали, с тем, как будет делаться, никогда не сходится. Даже с полнейшими спецификациями
B>>У меня сейчас есть уникальная возможность сранить 2 компании, разрабатывающие по сути одно и то же. B>>Одна работает по скраму, а другая — V model с итерациями. B>>Скрамная команда в 2 раза больше и делает в 2 раза меньше.
SD>Уровень сотрудников, надо полагать, одинаков? Или в первой команде 10 студентов, во второй — 5 профессионалов? А как оценивается "сделано"? В скрам продукт готов к выходу в конце каждой итерации (в идеале), либо с гарантией к завершению в течение 1-2 следующих итераций (в реале — стабилизационные спринты). Что с V-model, не получится ли так, что к релизу окажется, что требования изменились, все надо переписывать, плюс в багзилле — 800 багов, из которых 400 надо _реально_ фиксить, и требуется еще полгода на доработку? SD>Все ли затраты учтены в V-model? В смысле, кто пишет спецификации, кто верифицирует, какое количество людей в этом _реально_ вовлечено. SD>Ах да, еще, вдвое больше людей — вчетверо больше затраты на коммуникации. Не забывайте про это. Неспроста 5 профессионалов всегда вдвое быстрее 10 середнячков.
B>>Зато велосити меряется и менеджемент за год вперед знает, что не успеваем
SD>Так ведь это и есть важнейшее свойство! Заранее знать — успеваем, не успеваем. Знать статус проекта! Для этого скрам и затевается. Для того он и нужен — обеспечить прозрачность и понятность процесса. Как я и писал, именно этим он и неудобен всяческим "менеджерам проектов". И именно потому эти "менеджеры" так стараются избавиться от скрам всеми силами
B>>Куча энергии расходуется впустую именно из-за скрама.
SD>Угу. То есть для вас понимание, что происходит с проектом, это "впустую потраченное время". Странно. Обычно это, напротив, дорогого стоит. А спецификации — это не впустую? А вы сравнивали, сколько ушло на V-model (напоминаю — включайте туда создание спецификаций, долгие митинги и согласования, все-все-все, иначе сравнение странное выходит).
SD> Вы, случаем, не бывший "менеджер проекта нумер 1" ?
Похоже бывший "менеджер проекта нумер 1" — это ты. Ты так много деталей про этот проект знаешь
B>Речь именно об атомарных и неделимых юзер стори. B>Одна юзер стори может вылеться в несколько человеко лет. B>На новых проектах таких примеров — кажный второй.
На этом месте хорошо бы пример привести. Чтобы я понимал, о чем идет речь. Вы пишете Google Maps, причем обязательно со своими спутниками, своей обработкой, всем-всем-всем своим? Напоминаю, user story — это НЕ use-case.
B>Хотя тут надо уточнить, что ты понимаешь под согласовнием и какова его цель.
Под согласованием я подразумеваю review/approve из waterfall/RUP.
B>Согласовывать надо прежде всего с заказчиками (или тем, кто его представляет), разработчиками и тестерами. B>В скраме это происходит постоянно и принимают в этом участие PO и команда. B>PO создает новые PBI, команда их читает, обсуждает, оценивает. B>В результате PBI может быть перефорулировать или выброшен на помойку. B>Все это и есть согласование.
Вот и замечательно. Всё просто и понятно. А в RUP, однако ж, согласантов может быть сколь угодно больше количество, и зачастую туда входят всякие бизнес-аналитики, менеджеры проекта (проектов), менеджены компонентов и просто всякие левые менеджеры.
B>Похоже бывший "менеджер проекта нумер 1" — это ты. Ты так много деталей про этот проект знаешь
Всяко может быть я на своем жизненном пути успел достаточно грабель собрать. Это сейчас я уже соображаю, что к чему, а раньше молодой был, горячий шибко. Всё хотел сделать как лучше для проекта и продукта. Ан нет, неправильный это подход в долгосрочном плане, ибо заведомо сталкивается с личными амбициями и карьерными планами других людей (см. баталии на тему "корпоративных паразитов").
Здравствуйте, SkyDance, Вы писали:
B>>Речь именно об атомарных и неделимых юзер стори. B>>Одна юзер стори может вылеться в несколько человеко лет. B>>На новых проектах таких примеров — кажный второй.
SD>На этом месте хорошо бы пример привести. Чтобы я понимал, о чем идет речь. Вы пишете Google Maps, причем обязательно со своими спутниками, своей обработкой, всем-всем-всем своим? Напоминаю, user story — это НЕ use-case.
Примеры из личной практики слишком сложны что их так просто объяснить.
Предметная область специфична.
Ну скажем так понадобилось вычислять новую кривую.
Для юзера все очень просто. Он просто на экране будет иметь новую кривую,
смысл которой очень четок и однозначно понятен любому, с соответствующей подготовкой.
Для юзера дробить нет никакого смысла.
Реализация вылилась в 1.5 человека года.
Технически это дело удалось разбить на независимые подзадачи для нескольких людей
и через 4 месяца все работало. Просто поверь мне, что в один спринт для одной команды это невпихаемо.
В один спринт запросто впихиваются технические подзадачи, которые кстати, удается сформулировать
только после продолжительного анализа и дизайна. Куда этот анализ будем впихивать?
Какой PBI ты предложишь сформулировать, чтобы отдать этот анализ для разработчика?
По хорошему, никакой, потому что INVEST
B>>Хотя тут надо уточнить, что ты понимаешь под согласовнием и какова его цель.
SD>Под согласованием я подразумеваю review/approve из waterfall/RUP.
B>>Согласовывать надо прежде всего с заказчиками (или тем, кто его представляет), разработчиками и тестерами. B>>В скраме это происходит постоянно и принимают в этом участие PO и команда. B>>PO создает новые PBI, команда их читает, обсуждает, оценивает. B>>В результате PBI может быть перефорулировать или выброшен на помойку. B>>Все это и есть согласование.
SD>Вот и замечательно. Всё просто и понятно. А в RUP, однако ж, согласантов может быть сколь угодно больше количество, и зачастую туда входят всякие бизнес-аналитики, менеджеры проекта (проектов), менеджены компонентов и просто всякие левые менеджеры.
Ну здравый смысл никто не отменял. Точно так же просто и понятно это делается и с RUPом.
Просто ты говорил что больше 2-х согласантов — это много, а реальность оказалась другой.
Но ничего, в скраме игнорирование реальности и непонимание что на самом деле происходит — это норма.
С ролями такая же фигня. Формально ролей типа только 3-х, но на практике куча псевдоролей.
Здравствуйте, SkyDance, Вы писали:
G>>Построить burn-up и burn-down chart по задачам несложно при абсолютно любом процессе, скрам для этого не нужен. Таким образом люди спокон веков выпуск maintenance release, состоящих их ошибок и доработок, отслеживают.
SD>Можно. Только придется тогда притащить еще кое-что — в частности, гранулярность сценариев (user stories — сильно отличаются от traditional use-cases) и методы оценки в относительных величинах (да, planning poker тоже был известен до скрам).
Не придется. Для того, чтобы метод прогноза основанный на velocity нормально сработал, требуется, чтобы единиц планирования было достаточно много, они не были слишком длинными (длительность не должна многократно превышать шаг чарта по времени). И сразу начинает работать статистика.
Это необходимые и достаточные условия. Все остальное — ересь и лапша.
SD> И "утренние летучки" (stand-up) придумали газетчики-журналисты еще в XIX веке. Оценивать задачи относительно друга (а не выдавать заведомо неверные оценки — см. mythical man-month) тоже уже предлагалось. Но только в scrum эти простые практики собраны и разумным образом увязаны.
Эти "простые практики" во-первых, ничего толком не решают, и во-вторых — совершенно прекрасно работают по отдельности. Нет ровным счетом никакой реальной необходимости их увязывать.
Те же методы, основанные на velocity прекрасно работают вообще без каких-либо оценок срока и летучек, в чем и состоит их прелесть.
SD>"Все уже украдено до нас". Но я повторю свой вопрос: кто (и в каких условиях) участвовал в успешном проекте, выполненным с применением, например, RUP или чего-то еще такого? Расскажите, интересно же.
На моей памяти подавляющее большинство успешных проектов, в которых я участвовал или наблюдал, по странному стечению обстоятельств организовывалась из соображений опыта и здравого смысла, а не по букварю с названием RUP, Scrum, или другому варианту культа Карго.
Глупо относить успех или не успех проекта на счет "методологий", не имеющих к целям, задачам, и проблемам проектов никакого отношения. От того, что ты burn-up чарт нарисуешь, или начнешь двигать на доске цветные бумажки, или следовать другим ритуалам — у тебя в реальности ничего не изменится.
SD>Где вы срезали углы и почему. Сколько тысяч копий было продано (обсуждать софт, проданный единицами-десятками экземпляров, я не готов, и вообще смысла в этом не вижу — другая епархия).
B>Примеры из личной практики слишком сложны что их так просто объяснить. B>Предметная область специфична.
... B>Реализация вылилась в 1.5 человека года.
... B>Какой PBI ты предложишь сформулировать, чтобы отдать этот анализ для разработчика? B>По хорошему, никакой, потому что INVEST
Если у вас действительно такая сложная наукоёмкая ситуация, когда принципиально половина (по вашим же словам) user stories именно такая — нет уверенности, что вам вообще нужен формализуемый процесс. А что если реализация вылилась бы в 3.5 человеко-года? 6.5? 10.5?
Строго говоря, скрам допускает "высасывание из пальца" некоего value для юзера (к примеру, переделывание каких-нибудь особо глючных кусков кода часто идет как "повышение стабильности работы", суть исправление некоторых багов).
Но в вашей ситуации, когда половина (!) user stories такие длинные и непредсказуемые (реально непредсказуемые — не надо мне сказок про планы на 4-6 месяцев вперед, которые не корректируются по ходу дела), то вам действительно ничего не надо. И RUP и любой waterfall тоже. Банального "прогноз-отчётность" хватит.
B>Просто ты говорил что больше 2-х согласантов — это много, а реальность оказалась другой.
Это действительно много. Команда — это ОДИН согласант, т.к. она действует, гм, уже согласованно. А вот два отдельных менеджера, все из себя очень занятые, всегда имеют разные мнения (на то они и менеджеры), и на очную ставку друг с другом не соглашаются, потому что спорить друг с другом уже зарекались.
Плюс хороший РО разбирается в теме, в том, как написан софт, в его архитектуре — и, по сути, сам уже в значительной степени понимает нужды команды. Соответственно, ему остаются коммуникации с "внешним миром". Опять же, не надо про "заказчиков", это только в заказном софте есть заказчик, а я про этот софт речь сейчас не веду, там "законы откатов" могут влиять сильнее, чем любые методологии.
B>Но ничего, в скраме игнорирование реальности и непонимание что на самом деле происходит — это норма.
Видать, такой у вас скрам был. Скрамбат Но ничего, это не у всех так.
Зато RUP, надо думать, творчество просто поощряет! 
