Издательство: Вильямс, 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 (как раз тогда книжка Кента Бека вышла). И что? Начнем флейм?
Зато RUP, надо думать, творчество просто поощряет! 
