Гибкий подход разработки ПО – Scrum
Алексей КривицкийОпубликовано 17.07.2008 в Управление проектами, статьи
И как всё это касается меня – разработчика?
Вам нравится разрабатывать фичи, которые никто не будет использовать?
Вам нравится работать по проектному плану, в который вы не верили с самого начала?
Вам нравится кодировать архитектуру, которую кто-то продумал до вас, и в которой вы видите множество недостатков?
Вам нравится работать в группе людей, где вы чувствуете себя одиночкой?
Я пишу это для тех, кто отрицательно ответил на перечисленные вопросы.
В Рунете вы можете найти множество статей и обзоров гибкой разработки, в частности XP и Scrum. Это ещё одна. Чем же она отличается?
Отличается она тем, что нацелена на аудиторию разработчиков, которым как мне подсказывает мой опыт объяснить выгоды от применения гибких подходов (или agile software development) намного сложнее, чем менеджерам проектов или представителям стороны заказчиков.
Ещё она отличается тем, что написана по просьбе моих друзей специально для developers.org.ua.
Так, хватит воды. Перехожу к сути.
Кстати, на счёт воды… Подходы ведения проектов, которые ставят в сравнение с гибкими подходами называют водопадными (или каскадными). Их так называют потому, что артефакты таких проектов перетекают от отдела к отделу как вода на каскадах водопада. Очевидно, что пересогласование требований или перерисовка архитектуры в таком проекте тем сложнее, тем больше утекло воды с момента написания такого документа. Признаками такого проекта являются горы документов, функциональная разбивка компании (отдел разработки, отдел тестирования…), заранее принятые решения и далеко идущие (и уже возможно устаревшие) планы.
Всё это не так плохо, если помогает эффективной работе. Часто же ей это вредит. Лучшее враг хорошего?
Давайте теперь разберёмся с аджайлом и в частности Скрамом.
Скрам – это подход управления проектами (при чём не только по разработке ПО), который предлагает каркас, в рамках которого вы можете строить свой agile процесс, адаптирую его части по ваши нужды. Это не конструктор, но цельный набор хороших практик, с которого часто легче начать, нежели с нуля.
Приходилось ли вам учить новый язык программирования или какой-то API, начиная с примера в мануале и переделывая его по ходу под ваши нужды? В итоге в конечном коде возможно не останется ни одной строки, которая была в начальном примере. Тем не менее использовать за основу простой работающий пример было удобно. То же самое и со Скрамом. Примените, отладьте, поломайте, почините, потом смело меняйте на ваш вкус.
Итак, Скрам – это термин из регби, означающий так называемую «свалку», когда все члены команды собираются в кучу.
Гибкая разработка ПО по принципу свалки….
Давайте лучше называть это Скрамом или «командным подходом».
Правила просты для озвучивания (но зачастую не так просты в реализации):
1. У вас должен быть один человек в проекте, который уполномочен принимать решения о том, какую фичу стоит разрабатывать раньше, какую позже.
«Кто платит, тот и музыку заказывает».
Обычно этот человек работает на стороне заказчика. Или является бизнес аналитиком. Или быть может синхронизирует взгляды различных заинтересованных в разрабатываемом продукте заказчиков.
В любом случае разработчикам проще, если такой человек есть, он доступен, и он такой один на проект (во избежание конфликтов).
Его называют «Product Owner» (оставим без перевода)
2. Product Owner поддерживает список требований-пожеланий к продукту. Этот список он сортирует (приоритезирует) по принципу «ценное сверху, менее ценное снизу».
Такой список называется «Product Backlog» (без перевода).
3. Собираясь на планирование короткой фазы проекта (итерации или «спринта» – дословно забега на короткую дистанцию), команда (а это все те, кто влияют на разрабатываемый продукт – архитекторы, дизайнеры, разработчики, тестировщики) выбирают из Product Backlog ту верхнюю часть, которую они считают, что реально начать и закончить (!) за этот короткий выделенный период.
Так как часто для принятия подобных решений требуется пожертвовать детализацией фич, Product Owner принимает активное участие в подобном планировании.
Таким образом заказчик и команда принимают удовлетворяющие всех решения: заказчик ожидает получить некий ценнейший набор функционала за довольно короткое время, команда же получает план, в который верит.
4. По истечению оговоренного срока команда и заказчик встречаются для просмотра и обсуждения результатов. Это называется демонстрацией («де-монстрация» – изгонение монстров из софта).
На выходе такого митинга мы имеем а) уменьшенные риски, за счёт доказательства работоспособности команды, технологий и требований; б) новые идеи по развитию нашего продукта (вряд ли он готов к продаже после двухнедельной работы); в) доверие заказчика и команды к друг другу.
5. После всей перечисленной тяжёлой работы команда собирается и обсуждает серию экспериментов и задач, которые она думает ей помогут более эффективно работать в течение следующей итерации (спринта).
Это называется ретроспектива (дословно «просмотр прошедшего»; или что-то в этом роде – лингвисты поправят).
6. Забыл сказать – во время спринта членам команды скорее всего придётся синхронизировать свои усилия и помогать друг другу для более слаженной работы и достижения общего результата. Говорят, что хорошо это делать раз в день в течение 10-15 минут в присутствии всех членов команды. Это и называется Скрамом.
7. Во время подобного обсуждения члены команды могут пожаловаться на проблемы, которые они не в силах устранить (падает сервер, пропадает интернет, слишком тёплое пиво…) Эти проблемы помогает устранить так называемый ScrumMaster – человек, который понимает принципы и тонкости Скрама, командной работы и «нежного лидерства». Он делает всё, чтобы команда максимально эффективно общалась с заказчиком, между собой и достигла своих обещаний и целей.
Такие вот правила. Или скорее хорошие практики, которые, работая вместе, помогают достичь отличных результатов, построить хорошие и честные отношения с заказчиками и в команде, получить удовольствие и удовлетворение от работы. Они, как мне кажется, дают шанс каждому разработчику подняться на ещё одну ступеньку профессионализма.
Вам нравится разрабатывать фичи, которые никто не будет использовать?
У нас нет такой проблемы. В Скраме мы разрабатываем только наиболее важные с точки зрения заказчиков и конечных пользователей фичи. Очень вероятно, что наш проект успешно завершится до того момента, когда в беклоге останутся только низкоприоритетные фичи. Тем лучше!
Вам нравится работать по проектному плану, в который вы не верили с самого начала?
У нас нет такой проблемы. В Скраме мы работаем по плану, который мы сами обговорили с заказчиками и в который сами верим. К тому же, мы строим наши планы на довольно короткие интервалы. Так что если что-то и пойдёт не так, как мы думали, то у нас будет возможность внести коррективы и успешно сдать проект. Да, кстати, разработчики у нас на проекте сами выбирают задачи, над которыми им работать.
Вам нравится кодировать архитектуру, которую кто-то продумал до вас, и в которой вы видите множество недостатков?
У нас нет такой проблемы. В нашем Scrum-проекте наш архитектор постоянно доступен и сидит с нами в одной комнате, так что у нас всегда есть возможность повлиять на принятие решений. К тому же, благодаря таким практикам как refactoring и unit-testing, нам не приходится продумывать все архитектурные решения наперёд – мы знаем, что сможем ввести в код практически любые изменения без поломок продукта и существенных задержек в отладке.
Вам нравится работать в группе людей, где вы чувствуете себя одиночкой?
У меня нет такой проблемы. Мне всегда готовы прийти на помощь, как в прочем и я. Мы все ежедневно обсуждаем чем друг другу помочь. У нас же общая цель! Какие там одиночки.
9 июля 2008
Алексей Кривицкий для developers.org.ua
alexey@scrumguides.com
www.scrumguides.com – тренинги и эффективное внедрение Scrum
(18 голосов, средний: 4.44 из 5)
Загрузка ...Понравилась статья? Подпишись на обновления по RSS/E-mail
Спасибо за статью, каркас Скрам объяснен четко и доступно. Чего в статье мне не хватило, так это пояснений откуда выросли такие правила. Кто, как, когда, почему пришел к мнению что это нужно делать именно таким образом? Некоторые пункты достаточно очевидны, но всё равно интересно услышать подробней.
Также интересно можете ли вы рассказать о недостатках системы. Я думаю вы согласитесь что у всего есть цена, поэтому те или иные преимущества получаются в обмен на что-то еще, что это в случае Скрам?
На стадии обучения конечно все так делают, но в продакшн не должно идти ни строки кода получившихся таким образом (если не согласны, могу объяснить свою точку зрения). Какие сроки внедрения Скрам для разных размеров организаций и какие потери на первых стадиях? После скольких проектов вы считаете команды овладевают методикой в достаточной степени чтобы она перестала быть liability?
Правила выросли в процесе имплементации на практике принципов(ценностей) XP,библией которых является Extreme Programming Explained Кента Бека, того самого, которого так усиленно поливали д@рьмом глубокоуважаемые Yossi Kreinin и Phillip J. Eby.
Движимоя сила скрума - Кен Шваббер и Майк Кон.
Вот минибука, по которой я пробовал внедрять скрум в своих палестинах. Ее уникалькость в минимуме теории и максимуме практики - идеальный How-to
http://www.infoq.com/minibooks/scrum-xp-from-the-trenches
Сергей, спасибо за комменты.
Ярослав, спасибо за ответы и ссылку на книгу Хенрика Книберга (кстати, собираюсь его привезти в Киев в декабре)
Эти правила, как и многое другое, что мы используем в современном мире, пришли с востока - из наработок японских компаний, таких как Toyota, которые уже не первый десяток лет разрабатывают свои продукты по похожим правилам. Первое упоминание о Scrum. Вот немного больше информации от одного из американских адоптеров Scrum Джеффа Сазерленда.
Позже эти правила были названы Scrum (термин из регби) и вышла в свет первая книга и потом две другие.
Конечно, у всего есть недостатки. И за все преимущества нужно платить. В Agile мы платим за позволения принимать поздние решения тем, что нам приходится поддерживать код в хорошей форме. Это достигается тренировками кода, которые называются рефакторинг - это частые улучшения внутренней структуры кода, без изменения его функциональности. Бок о бок с рефакторингом идёт юнит-тестирование - как практика автоматической проверки работоспособности системы. Обе эти практики небесплатны - требуют немалых инвестиций. В обмен вы получаете software, который правда настолько soft, что его можно изменять без слишком дорогой платы за сами изменения.
отвечаю дальше…
Как и всё на свете “it depends”. Это зависит от размера проекта, готовности заказчиков и команды опробовать новые подходы. От фазы проекта. Новый небольшой проект (скажем, 2-6 человеко-месяцев) можно запустить за пару дней, при условии, что есть видение разрабатываемого продукта.
Для большего проекта, который уже находится в фазе активной реализации этот процесс может занять пару месяцев при несогласованной работе команды и заказчика. А может и никогда не закончиться…
Но, я скажу, что шансы внедрить эти подходы есть всегда. И обычно они больше, чем думают компании.
Как раз сейчас я провожу тренинг в Полтаве, в компании, которая пытается внедрить Scrum на одном крупном проекте. Это будет нелегко, но у них есть шансы. Всё зависит от того, на сколько важно для них получить те выгоды, которые им обещает Scrum.
Удач!
Спасибо за ответы. Если позволите еще несколько вопросов:
Правильным ли будет предположение что Scrum больше подходит для проектов реализуемых на динамических языках? (Я исхожу из того что в этом случае цена рефакторинга и тестов значительно ниже).
Как адаптируется методика для разработок новых продуктов, т.е. как выбирать “хозяина” (project owner)? Есть ли вообще какие-то рекомендации по этому поводу в том числе для выбора со стороны заказчика, когда такой есть?
Есть ли опыт применения методики в частично или полностью распределенных командах?
http://www.infoq.com/minibooks/scrum-xp-from-the-trenches
там все описано
По моему по такой технологии сейчас работают все 1С программисты.
как раз трейню группу 1С-ников, я бы не сказал, что именно так они и работают…
прошу не путать отсутствие планов и дисциплины с аджайлом. аджайл требует очень высокой степень дисциплины. как от команды так и от заказчика. и само по себе это не случается.
а жаль!
Классная статья!
Де-монстрация особенно порадовала
Пара мелких вопросов/комментариев
ИМХО стоило бы упомянуть, что PO основывает приоритезацию не только на бизнес-ценности “требований”, но и на основе оценки сложности (читай - размера) имплементации, предоставляемой коммандой.
В п. 3 читаем:
Что значит “жертвовать детализацией”? Уменьшать ее? Кажется, происходит наоборот: уточнение требование, разделение их на элементы или жертвование деталями в пользу достижимости.
to Щетинин Сергей
Боюсь, что нет. Если исходить из гипотезы “…на динамических языках…цена рефакторинга и тестов значительно ниже”, то как раз при разработке на статическом языке намного важнее следовать agile принципам, так как они нацелены на “приветствование изменений” (embrace change) путем поощрения таких полезных практик как эволюционирующая архитектура (в т.ч. рефакторинг), автоматическое тестирование и др. А изменения, как мы знаем, будут
Т.е. и динамическим не противопоказано, но статическим полезнее.
По поводу самой гипотезы, рискуя выйти за рамки темы спрошу: а на чем она основана? И какие языки Вы называете “динамическими” в данном случае? Языки со слабой типизацией? Как это помогает рефакторингу? Мне всегда казалось, что как раз рефакторинг-то и намного легче в статических языках типа Java по сравнению со скажем Python, т.к. в большинстве случаев можно достаточно точно вычислить тип => IDE или другая тулза может достаточно безопасно его (рефакторинг) проделать.
На динамических языках рефакторинг проще потому что меньше кода, нужно делать изменения в меньшем количестве мест и потому что шире инструментарий (сделать proxy обьект легче, есть возможность адаптации, лучше дела с интроспекцией). Тестирирование проще опять же потому что нужно меньше бойлерплейта, промежуточных шагов и не нужна поддержка со стороны IDE.
Вообще в Python цена начала рефакторинга практически нулевая, и я не верю что он где-то может быть проще. Это нужно попробовать и ощутить на себе, обьяснить не возьмусь.
По-моему, очевидно, что динамические языки - это языки с динамической типизацией. А слабая типизация - это ортогональная штука. Вот у С слабая типизация, например.
Ответили отрицательно на вопросы - значит вы еще не выросли. Значит вы получаете удовольствие от самого процесса программирования. Это существенно отличается от решения поставленных задач.
Это означает, что вы не сможете работать в больших командах и действительно крупных проектах.
Спасибо, Алексей.
Хорошая статья, супер ответы на вопросы.
Очень порадовало “it depends”
Так держать! Be creative!
кому интересно в августе будет ряд мероприятий по agile в киеве
Agile Club
31 июля
Встреча аджалистов
Тренинг Базовые концепции Agile и SCRUM
15 августа
Тренер Алексей Кривицкий
Тренинг Automated Acceptance Testing
16 августа
Тренер Николай Алименков
SCRUM, как процесс, немного напоминает принцип генетических алгоритмов. Однако, в отличие от них, SCRUM только создает иллюзию поиска оптимального решения. Я вкратце попытаюсь объяснить почему.
Те, кто хотя бы в общих чертах знакомился с дисциплиной проджект менеджмента, знают, что в любом проекте всегда присутствует Baseline - (Scope, Cost, Schedule, Quality, Risk). Часто сюда добавляют еще и Customer Satisfaction и еще некоторые критерии, но на мой взгляд базовыми в проекте являются именно эти пять артефактов. То есть менеджер проекта в любой момент дня или ночи может всегда сказать 5 вещей: что входит в объем работ проекта, какой у проекта бюджет, когда проект закончится, какой уровень качества проекта и продукта, перечислить ключевые риски и планы по ним.
И, если для управления Scope SCRUM и предлагает инструменты (Backlog), то сроки и бюджет проекта в нем не контролируются никак. Этими параметрами не управляет менеджер (SCRUM-мастер), их диктует команда, что само по себе катастрофический риск для проекта. Сегодня команда говорит одно, завтра другое, послезавтра кто-то уходит и в итоге никто не виноват. Вообще говоря, урезанная роль менеджера (SCRUM-мастера), размытая мотивация и ответственность команды делают процесс крайне неэффективным для выполнения проектов в срок и в бюджет.
Мое мнение, SCRUM это вырождающийся инструмент, который используют, если денег в компании никто особо не считает. Нет проблемы превысить Cost проекта в 3 раза, если цена часа на выходе 50 долларов, а внутри 10, а понятие “недополученная прибыль” это мистика. К сожалению, цена часа снаружи падает, а внутри растет, поэтому необходимо посмотреть в глаза реальности и потратить деньги и время на внедрение гораздо более грамотных процессов. Таких, например, как RUP.
полемика с № 17.
мне кажется, в комментарии Вадима наблюдается попытка расмотреть некоторые, фрагментарные, практики одного из agile подходов ( в данном случае – Scrum), механически перенесенные в рамки привычной водопадной модели с жестко фиксированными требованиями (объем работ), ресурсами (бюджет), и графиком. Естественно, это не может не привести к путанице.
Не буду задерживаться на грехах водопадности, полагаю все здесь хорошо их себе представляют. Хотел бы лишь вкратце напомнить, что agile философия построена на win-win модели взаимодействия участников процесса, предполагающей наличие таких вещей как: взаимное доверие, мотивация и профессионализм членов комманды.
О “Baseline”. Одним из основных методов agile является ативное вовлечение заказчика в процесс разработки продукта на всем его протяжении. Это дает возможность варьировать такими параметрами, как scope, cost, schedule и даже не побоюсь сказать – качеством продукта в зависимости от реальных требований безнеса и текущей ситуации, а не той, которая виделась где-то в начале пути. Конечно, есть риск микроменеджмента, для минимизации которого и задаются правила, видимо смутившие Вадима (в Скраме – изоляция комманды на время итерации от “вредных” воздействий заказчика, перенаправление некоторых из них на Product Owner). Но это лишь на протяжении итерации, которая не должна быть длиннее месяца, на уровне же планирования релизов заказчик имеет и должен использовать полный контроль над scope, но “полный” рамках объективной реальности: хочешь и А и Б и Е – ну тогда прийдется ВГД перенести на позже. Нужно еще и В, по-любому и сейчас? Можно, по-правде сказать, пожертвовать качеством, но технический долг растет быстро и бьет сильно.
Теперь о рисках. Самые полезные задачи (с точки зрения заказчика) приоритезируются Product Ownerом в начало проекта, и при следовании требованию Скрама “что сделано – работает и может использоваться” (что при комманде с техническим уровнем не ниже среднего вполне реально), заказчик вообще имеет абсолютный контроль над временной составляющей – он может просто остановить проект и остаться с тем что есть в любой удобный ему момент. Кстати, и итерацию в Скраме заказчик может прервать, но за это прийдется платить ценой внеочередного планирования следующей (читай – временем) и пивом. Очевидно: риски для участников проекта - ниже, причем для всех (win-win!).
Легко заметить, что в реальности как раз Скрам и подобные подходы наиболее полезны когда деньгам идет счет. Это как со строительством: есть бабло и нету времени – покупай под ключ, нет – изволь явиться и вникнуть, а то как всегда – получится совсем не то, что нужно.
Надеюсь, вышеприведенное показывает, что об упомянутых baseline items никто не забыл, и они вовсе не иллюзия. Кстати, очень характерно ИМХО то, что Customer Satisfaction Вадим после колебания не отнес к базовым “артефактам”! А ведь для agile это и есть основное мерило успешности и цель максимизации, см. например положение в списке принципов (http://agilemanifesto.org/principles.html). Скрам, в частности, заявляет о нацеленности на максимизацию ROI.
Не буду останавливаться и на
, т.к. это уже детали, о которых до понимания сути говорить рано.
О вырождении скрама можно много плодотворно философствовать, но не в рамках этой дискуссии; противоставление же RUPу вообще выглядит очень малоубедительно, ибо судя по многим источникам, при большом желании Scrum спрягается даже с адекватным CMM, что уж там про UP. Говоря о цене как внедрения, так и изучения, Скрам – это light-weight процесс, который выгодно отличается от того же RUP (особенно в негибких применениях “по книжке”) по накладным расходам и ROI как для заказчика так и для практика.
А генетика - не без нее. В смысле ускоренного, по сравнению с тепличными, темпами отмирания непригодных к выживанию организмов
Mykola.
1. Почему я могу считать, что расходы на проект не превысят его Cost? (который, конечно, может меняться, если в процессе реализовано управление изменениями, в RUP это есть)
2. Аналогично, почему я могу считать, что расписание проекта соответствует реальности?
3. Говоря о Customer Satisfaction, где гарантия что смена заказчика (это нормальная практика) не завалит проект?
4. Где гарантия, что смена нескольких (или всех) членов команды не завалит проект?
5. КТО виноват если проект завален (ответ “все” = ответ “никто”)
6. “предполагающей наличие таких вещей как: взаимное доверие, мотивация и профессионализм членов комманды” говорить о таких вещах как о само собой разумеющихся более чем неосмотрительно. Где в процессе инструменты, обеспечивающие это?
У меня пока еще нет сертификата по SCRUM и я действительно буду рад если он ответы на эти вопросы дает. В любом случае, я планирую пройти сертификацию и по этому процессу, так что не хочу чтобы вы подумали что я отношусь к нему как-то предвзято. Тем более, что тут я вижу уже целый SCRUM-институт
to #19
Вадим,
) не претендует на звание “silver bullet”, тем более он считается легковесным фреймворком (даже не процессом). Боюсь, я не смогу хорошо ответить на вопросы, в частности потому что они мало релевантны моему опыту и реальности. В любом случае – попытаюсь, а с конструктивным отношением Вы и сами скоро разберетесь 
для начала – не существует идеального подхода на все случаи жизни, и Скрам (не SCRUM, ибо не аббревиатура
Контест вопросов №1 и 2 мне совершенно непонятен, что такое “я”, что такое cost и что – расписание?
3. Не скажу, что смена заказчиков такая уж и нормальная практика; опять же не очень понятен контекст. Может пример? Смена заказчика - это в общем случае достаточно радикальная перемена, уверен что абсолютных гарантий быть не может. Но за счет изначального подхода “embrace change” любой адекватный agile процесс будет явно не в проигрыше. В конце концов, новый заказчик может сразу резко поменять курс и это будет оставаться в рамках процесса.
4. В мотивированных и профессиональных коммандах это редко большая пробема. Тем не менее, немного гарантии таки есть. Самое главное – при следовании принципу “сашими” (или emergent architecture + YAGNI), в любой момент на руках остается законченый срез приложения, а не разрозненные модули, “архитекторы” которых не стали дожидаться часа интеграции. Хорошо бы помогли другие механизмы (автоматическое тестирование и т.п.), но они за рамками чисто Скрама.
5. Таки да – все. Какой смысл искать козла отпущения? Может лучше раньше диагностировать и предотвратить проблему? В этом и цель Скрама.
6. Эти вещи не само собой разумеющиеся, и действительно очень важны. Если у Вас команда лоботрясов или одних зеленых студентов, Вы не умеете ею управлять (точнее, направлять) без коммандного окрика, то Скрам лучше не внедрять. Если проект завалится, то это будет не по вине процесса. Скрам, опять же, это легкий процесс, он не вводит специальных инструментов для управления, он лишь дает намек: “Скрам мастер – это не менеджер, а коуч, наставник, помощник и слуга комманды; дай комманде самой справиться с проблемой, и подскажи как можно бы лучше”. Если не умеешь работать с людьми без специальных “звездочек на погонах”, процедур и отчетов, и главное не хочешь уметь, то Скрам – это наверное пока рановато.
По поводу института – это наверное на ажиль юкрейн к Леше и Ко: http://www.agileukraine.org/
Николай,
спасибо за ответы, вы подвели меня к тому, что я хотел сказать. Действительно, мир не идеален, это касается и людей и процессов и технологий. И моя позиция относительно Скрама (пусть будет так
имеет следующие корни:
1. Я считаю, что в любом проекте всегда должен быть один человек, несущий ответственность за успех всего проекта. Подход “виноваты все” не годится, я даже не хочу тратить время на объяснения почему.
2. (это очень важно) Мое мнение, именно в менеджменте заключается успех проекта. Верите или нет, но можно делать очень серьезные вещи с командой лоботрясов и зеленых студентов, грамотно следуя процессу, управляя качеством, рисками и т.д. В то же время, очевидно, можно завалить проект имея армию профессионалов, это очень легко и это наблюдается повсеместно.
3. Моя позиция, это позиция менеджера, возможно в этом и разница наших взглядов. Я прекрасно понимаю позитивность этого процесса с точки зрения разработчика. Ты в команде, все молодцы, стараются, никто над тобой не нависает, выбираешь себе работу по душе, оцениваешь как тебе угодно, не получилось? - ты не виноват, проект не вписался в бюджет и сроки? - бывает, главное что заказчик еще проект не закрыл… Это классно, я не спорю. Никто не хочет работать много, качественно и быстро, это человеческая природа. Именно поэтому процесс, ориентированный на разработчика проигрывает с точки зрения менеджмента. Проект, который зависит от компетенции программистов, настроения заказчиков и еще ряда условий - это кораблик в океане и его “менеджер” не более чем матрос на вышке, который может разве что констатировать крушение. Такие проекты живут постольку, поскольку заказчикам они обходятся дешево. Представьте, что перерасход 10 человеко-часов в проекте вашей компании это уже убытки, вы бы поставили Скрум? А если опоздание на день это закрытие проекта? А с такими реалиями придется работать и очень скоро.
Подводя итог. Как и своим первым, так и этим постом, я хочу донести всего одну идею - со временем разработчики будут все более дорогие и все менее качественные, ничего личного, это диктует рынок. Это очень важно понимать. Уже сейчас компании вынуждены брать студентов без опыта на 1000$, не заметить это очень трудно.
Уже сейчас все теснее на рынке и эта тенденция будет продолжаться, а значит падать цена спроса. При таких перспективах, ставить процессы, в которых ответственность лежит на разработчиках (читай ни на ком) это очень рискованно и очень дорого в конечном итоге.
Нужно делать упор на качество менеджмента и грамотные процессы, это ключ к развитию.
к сожалению нет времени вдаваться в полемику.
я знаю, что скрам работает. есть сотни сотен компаний по всему миру, в которых agile - это основной процесс. множественные подтверждения этому я получил на конференции agile2008. так что доказывать лишний раз что-то кому-то я не буду.
в конечном итоге, если вам нравится быть тем единственным, кто несёт ответственность за успех или неуспех проект человеком - это ваш выбор. если вам нравится угнетать ваших сотрудников нереальными сроками - это ваш выбор. если вам нравится получать на выходе низкокачественный продукт (из-за той же спешки и отсутствия групповой ответственности) - это ваш выбор.
на счёт сертификаций по скрам.
на октябрь ещё есть немного мест. записывайтесь и приходите. там интересно.
На мой взгляд, Скрам просто отражает бессилие нашей отрасли перед лицом реальной действительности
Мы называем себя инженерами, но при этом в отличие от настоящих инженеров (машиностроителей, например) - мы не можем гарантировать заказчику ни сроки, ни качество разрабатываемого продукта. Поэтому отрасль придумала Скрам в рамках которого честно говорит клиенту - мы тебе ничего не обещаем, кроме того, что мы будем стараться 
.
На мой взгляд есть только два фактора, наличие которых гарантирует успех проекта:
1. Человеческий. У Вас должна быть правильно подобрана команда и правильно организованы отношения между людьми. Если это есть - то какой у Вас при этом процесс, совершенно не важно. Команда может выбрать и Скрам, если он ей удобен, может RUP, а может процесс под названием “анархия - мать порядка”, главное чтобы он подходил данной конкретной команде. Когда я говорю команда выберет - я имею в виду, что грамотный проджект менеджер построит процесс под команду, не пытаясь навязать команде практики, которые данная команда все равно не готова выполнять.
2. Наличие у заказчика проекта ясного понимания того, что он хочет получить. Оно может быть не формализовано, оно может существовать в виде, который понятен только заказчику (тогда менеджер должен организовать вытягивание из клиента этих знаний и перевод их на язык понятных команде), но это понимание должно быть в каком то виде. Отсутствие понимания что нужно было делать - это причина провала большинства проектов. Скрам - это попытка отложить получение этого понимания в целом на потом. Как если бы пилили доски для постройки дома, при этом длину каждой доски мы бы определяли методом проб и ошибок, а потом еще бы и пытались собрать из этих индивидуально напиленных досок какой то дом, который мы себе до этого не представляли.
До моды на Скрам была точно такая же мода на RUP и другие такие же “технологии”. Всего лишь 7-8 лет назад я наблюдал такой же энтузиазм в отношении RUP-а, как сейчас в отношении Скрама :). Я понимаю, что те кто это придумал и продвигает - зарабатывает на этом деньги. Через пару лет появится следующая серебряная пуля. Но пока менеджеры не поймут, что именно человеческий фактор стоит во главе угла, а процесс - даже не вторичен, ситуация в отрасли не изменится. Не согласны? - Тогда подождем еще пару лет и посмотрим, что будет собирать толпу энтузиастов в то время
Андрей,
разделяю вашу позицию относительно Скрама, и аргумент “я знаю, что скрам работает” звучит не особо убедительно
Уверен, что он работает в компаниях по производству “сайтов за 15 минут”, но мы вроде о других проектах ведем речь.
С “факторами успеха” я не совсем согласен. Обьясню почему:
1. Представьте себе, что вы менеджер проекта по созданию самолета. От качества продукта будут зависеть жизни людей. Можете ли вы позволить, чтобы крепление крыльев было выполнено некачественно, потому что ответственный за эту задачу человек обиделся на вас или, скажем, просто он балбес? Или что команда посреди проекта бросит работу потому что ее не устраивают условия труда? Ответ - нет. Избежать этого вам поможет только правильный процесс, который сводит человеческий фактор к минимуму, практически к нулю. Процессу неважно кто именно выполняет задачу по стыковке крыльев, но он гарантирует уровень качества при соблюдении требований к документации архитектуры, peer review, тестированию итд. Процессу неважно насколько сейчас мотивирована команда, но он потребует от вас грамотной работы с риском “команду прийдется менять” и смена команды пройдет для проекта безболезненно. Я абсолютно уверен, что грамотный менеджер, следуя процессу, может создать самолет пригласив в команду одного-двух квалифицированных инженеров и бригаду студентов.
2. Объем работ должен быть зафиксирован. Нельзя начинать работать, имея на входе “сделайте мне сайт” - это обречь себя на бесконечный scope creep. Другой вопрос, что в процессе должен проводиться Integrated Change Control - управление изменениями в проекте. Это несложно, и в том же RUP это есть.
Вобщем, как и в предыдущем посте, моя формула: менеджмент + процесс = успешный проект
Вадим,
Мне приходилось иметь дело, например, с медицинскими проектами - то есть такими, от ошибки в которых может зависеть жизнь людей. Я согласен, что там процесс действительно очень важен. Но согласится с тем, что процесс является главным фактором в любом проекте я не могу. На самом деле, производство для медицины отличается от обычной разработки софта еще и тем, что непределенность с тем, что нужно сделать отсутствует практически полностью. Если Вы делаете предположим аппарат искуственного дыхания - то какая то неопределенность будет присутствовать только первый раз. Для всех следующих моделей аппарата вы будете повторять те же самые шаги которые могут быть описаны в виде технологической карты - то есть по сути вы получаете процесс как в машиностроении
.
Но большинство проектов не таковы. Основную проблему как я уже сказал я вижу в том, что мы не являемся строго инженерной дисциплиной. Дайте 10 токарям одной квалификации один и тот же чертеж - получите 10 одинаковых (в пределах допуска) деталей. Дайте 10 программистам одну спецификацию - получите 10 разных программ. Все потому что машиностроение (и электроника, кстати, появившаяся почти одновременно с ИТ) имеют свой формальный язык проектно-конструкторской документации, а ИТ - нет и пользуется для тех же целей обычным языком, который всегда может быть понят неоднозначно. Какое все это отношение имеет к человеческому фактору? Самое прямое. Ваша команда должна быть мотивирована закрывать вот эту проблему отсутствия однозначного описания, а оно отсутствует по определению отрасли, хоть с применением Скрама, хоть без этого применения. Если люди не мотивированы - они легко скатываются на позицию: делаем так как написано и если непонятно, то никого ни о чем не спрашиваем ибо это не наше дело, сами виноваты что так написали. Кстати, и в строгоформализованном медицинском проекте при отсутствии мотивации можно тоже натворить дел.
Скрам, на мой взгляд, скорее вреден чем полезен, потому что вместо признания существования проблемы понимания требований клиента, которая вообще говоря довольно сложна, требует для своего решения специальных умений и знаний, которыми рядовой програмист, как правило не обладает, создает иллюзию того, что эта сложная задача может быть решена путем всеобщих митингов и собраний.
Согласен с Вами, что используя Скрам, непонятно каким образом я смогу обозначить для клиента хотя бы сроки проекта. Конечно, даже названные сроки часто не соблюдаются, но если я скажу клиенту, что я вообще никакого срока не могу назвать для всего проекта и только могу сказать, что клиент получит после ближайшего спринта … . Возможно, что это как то работает в случае продуктовых компаний - вроде бы Микрософт использует Скрам.
Я согласен и с тем, что за результаты проекта не может отвечать команда - если за что-то отвечает больше одного человека, то по сути не отвечает никто
Я спрашивал идеологов Скрама, не является ли СкрамМастер псевдонимом для ПМ-а и не есть ли он то лицо, что несет ответственность за успех проекта - мне сказали, что не является и не несет 
2 Андрей
+100
Программирование вроде бы уже вылезло из коротких штанишек и стало индустрией с миллионами людей и триллионами бюджетов, а по сути осталось кустращиной.
Все проблемы производственных процессов (и даже изобретательской деятельности) давно уже формализованы и отработаны. Построены 100-этажные дома, трансатлантические лайнеры и космические станции. А программисты очередной раз изобретают велосипед.
Андрей, Евгений,
согласен с вами и считаю что причина того, что так обстоят дела - в недостатке знаний. Программист, тестер знает свою технологию, получает по ней сертификаты, таких специалистов хватает. Архитектор, тест аналитик - людей с такими сертификатами меньше, но тоже встречаются.
А сколько среди ваших знакомых сертифицированных системных аналитиков? Уверен, что мало, а именно эти люди знают и умеют писать однозначное и полное ТЗ, которое дашь 10 программистам и получишь 10 одинаковых систем.
Скажите, много ли вы знаете людей с сертификатом PMP? Лично я знаю всего двоих, сомневаюсь что на всю Украину их больше 50. А именно эти люди знают и умеют сдавать проекты в срок и в бюджет.
Ну и говоря о процессах, много ли специалистов в нашей индустрии имеют сертификаты RUP, MSF, PRINCE2, тот же Scrum..?
Ответ - катастрофически мало.
PMP + RUP сертифицированный менеджер творит чудеса, и это стоит того времени на подготовку что он потратил. Классический украинский “менеджер” разглагольствует о пользе скрама и валит вину на команду.
Вобщем, учиться, учиться и еще раз учиться
2 Вадим
А вы никогда не задумывались, какие сертификаты имеют менеджеры в других областях?
От администратора зала в ресторане, до прораба на стройке? И прекрасно справляются со своей работой.
А прогеры умудряются запутать до невозможности простенький сайт из десятка страниц.
Принципы просты - декомпозиция задач, четкое разделение зон ответственности, технологические карты.
А самое главное - никто не берется за работу, до получения полного комплекта документации.
Программисты прекрасно знают эти принципы, но с завидным упорством игнориуют
Скрам прикольнее.
ЗЫ
Сознательно избегаю слова ИТшники - у связистов и хардварщиков таких проблем не наблюдается.
Евгений,
Посмотрите что такое “проект” в вики и вы узнаете почему. Кстати, непонимание понятий “проект” и “менеджмент” присуще 90% отечественных IT производителей, многие путают “проект” с “операциями”, а “менеджера” с “опытным программистом”.
администратора зала в ресторане и прораб на стройке это не менеджеры проектов
Остальное не хочу даже комментировать, поможет та же вики, по запросу project management, например.
Скрам, безусловно прикольнее с точки зрения программиста, выше я описывал почему. Но для проекта, цель которого - быть выполненным успешно в бюджет и в срок он не годится.
Про суть “проекта” в #29 - это хорошо. Можно пойти чуть дашьше и вспомнить, что более менее серьезная разработка ПО (т.е. не “сайт” за 15 минут) – это создание нового продукта, а не конвейерный процесс. Плачущимся о ущербности программисткой инженерности по сравнению с машиностроением, советую для начала почитать о разработке новых моделей в Тойота. Это ближе к нашей теме, чем вытачивание на токарном станке. Компилятор вытачивает
Ага, у нас сплошное создание атомных бомб, трансатлантических лайнеров и новаторских ОС
Господа! Давайте посмотрим правде в глаза! Что есть 99% украинского (и не только) ИТ?
1. Сайтоклепство
2. Оболочки на базы данных
3. Багфиксинг
4. Прикручивание нового функционала, к старым буржуйским поделкам.
Оставшийся процент приходится на создание продуктов с нуля, но это опять well-known компоненты и технологии, где все хорошо предсказуемо, требуется только внимательность и аккуратность.
Поверьте вечер в крупном ресторане несет для менеджера значительно больше неожиданностей и рисков.
А если уж говорить об уникальных проектах в ИТ, они скорее присущи комплексной деятельности вроде автоматизации предприятий или созданию сетей передачи данных.
to #31
Ну зачем же останавливаться на таком разнообразии ИТ задач? Их всего две: правка “оболочек баз данных” и багфиксинг. Багфиксинг тоже можно для простоты рассматривать как новый функционал. так что вообще одна. И все можно сделать на машине Тюринга. Только клиентам не говорите!
И где это же это такие компоненты водятся. что все предсказуемо при отходе от проторенных use case? Вот сегодня например, хотел зарепортить баг к одной open source библиотеке с достаточно активной пользовательской средой. При попытке сделать сравнение с наиболее распостраненными броузерами (задача связана с отображением HTML), оказалось что данный аспект рендерится совсем не так как я бы ожидал в FireFox и IE. Safari оказался ближе к моему идеалу, но еще не достаточно хорош для конечного пользователя с типографскими наклонностями. И все в рамках стандартов W3C, текущих и будущих. Про JavaScript в IE6 я вообще молчу…
Сайтоклепательство и оболочки данных. Смешно
Mykola Gurov говорит:
“более менее серьезная разработка ПО (т.е. не “сайт” за 15 минут) – это создание нового продукта, а не конвейерный процесс”
и много Вы знаете таких по настоящему новых продуктов? Новые продукты требуют неких специальных знаний. Типичный програмист на Украине кладет контролы на форму и связывает их с базой данных, при этом уверен в том, что занимается очень интеллектуальной работой. Я что то не слышал про разработку здесь компиляторов, баз данных и т.п. Я как то собеседовал людей для проекта сервера по передаче потокового видео - я не смог собрать в Харькове команду, которая смога бы его сделать, может быть я плохо искал?
Про менеджмент тойоты я читал, история интересная, только они начинали с элементарного наведения у себя порядка, а не сразу с тех вершин на которых они сейчас находятся. нам бы сейчас просто от кустарной мастерской перейти хотя бы к плохонькому заводику, а Вы сразу тойоту собиратесь строить.
to #32
так вот что такое по настоящему креативная программистская работа - поиск багов в опен-соурсе библиотеке
Одни пишут библиотеки, другие ищут в них баги, потом те искал пишут свои библиотеки, и новые программисты ищут в них новые баги. В мире сотни кем то написанных библиотек и компонентов. Завтра новые программисты вооружившись новой модной “технологией” менеджемента пришедшей на смену Скрам напишут еще более новые библиотеки и компоненты (решающие те же самые задачи) и содержащие новые баги. За занятость программистов можно не беспокоиться. Только чем это круче сайтоклепательства мне - непонятно. 
to Андрей #34
мсье никак все пишет с нуля, или обходится стандартными библиотеками? А оупен соурс брезгует даже если платные аналоги просто не по карману совсем не бедному заказчику?
А простор для творчества можно найти везде. Даже не в гугле или НАСА.
to Андрей # 33
Типичные украинцы программисты, с которыми мне приходилось работать в адекватных (не совковых) конторах, очень сильно отличаются от Вашего типажа, который не программист суть, а кодер. Попадались и такие, но все реже.
2 Mykola Gurov
А чем Вы занимаетесь любезнеший? Андрей озвучил две достаточно интересные темы работы. А у Вас? Мне послышалось HTML?
PS Во избежание недоразумений. Моя область - системное программирование и эмбед.
Зачастую на принципиально новом железе, обязательно 24*7.Колдовством свою работу не считаю - обычная инженерия, не хуже и не лучше других.
to #35,36
Вы пишите в ветке в которой обсуждается нужность и полезность процесса Скрам для разработки ПО. Вроде бы как Вы выступили моим оппонентом - хотя из Ваших постов очень трудно понять против чего конкретно Вы выступаете.
Я сделал, как мне кажется вполне допустимое (исходя из темы дискуссии) предположение о том, что Вы мне приводите пример разработки (то есть поиск багов в опен-соурсе библиотеки) как нечто, что сравнимо по своей сложности с задачами, который решает менеджмент компании Тойота и для которых нам нужны новаторские подходы в управлении проектами. Если я неправ - то для чего Вы вообще все это тут написали и что Вы хотели сказать?
Про мой типаж Вам рассуждать, по моему, все-таки не стоит. Вы делаете скоропалительные выводы
2 eugene_n #37
интересность - это категория субъективная. Мне вот озвученные темы лично не очень интересны, но это ничего не значит.
HTML Вам послышался в контексте разработки системы автоматизации деятельности маркетинговых и рекламных отделов и агенств. Web-based, java server side.
Т.е. старые добрые оболочки для БД на этот раз в веб-исполнении
to Eugen_n №40
ага, все этим пользователям неймется, не хотят SQL консолькой довольствоваться
А вообще БД или web специфика -– это весьма малая часть данной конкретно системы. Основная тяжесть на разного рода конфигурируемых workflow, обработке медиа-данных, средствах кастомизации, интеграции с другими системами (ERP etc.). Тоже никакого колдовства.
Алексей,
Каким образом в случае ведения проекта Scrum методологией в аутсорсе решается вопрос о стоимости разработки в контракте?
Пока я вижу вариант что никак - т.е.
заказчик должен заключить Time and material договор (оплата не за проект, а за работу, до тех пор пока она не будет сделана.) И первая ( и возможно основная) задача компании-разработчика должна заключаться в том чтобы “продать” Scrum (и Time and Material контракт) клиенту.
Или же есть возможность использовать Scrum для Fixed cost проектов?
на #42 Adler
конечно, оплата по факту намного органичнее укладывается в agile. Но есть пара work-arounds и для проектов с Fixed cost, при условии того, что заказчик готов идти на большее вовлечение в проект, чем в случае “под ключ”.
Самый очевидный – это разбивка на этапы, с фиксацией их цены и результатов. В лучшем случае, эти этапы могут быть размером со спринт, что достаточно близко к оплате по факту. Риски таким образом уменьшаются соразмерно отношению длины этапа к длине всего проекта; клиент вовлекается в планирование итераций или релизов (фаз), получает возможность варьировать приоритетами и с большой вероятностью становится более “гибким” в дальнейшем. Одна из сложностей – первые итерации нового проекта, когда зачастую имеет место достаточно много инфраструктурной деятельности, недемонстрируемой заказчику. С другой стороны, фокус на необходимости показать законченный, работающий кусок функциональности хорошо ограничивает построение излишних архитектурных решений (ivory towers) на этом этапе. Впрочем, в такой фазе мне лично по Скраму работать не приходилось, так что знаю больше по наслышке и из теории.
Вторая возможность - это сам объем работ (scope). Если он не зафиксирован, то вообще проблемы (теоретически) нет – можно идти по бек-логу согласно приоритетам заказчика и остановиться по исчерпанию бюджета. Но речь, скорее всего, о fixed cost/fixed scope (и date) контрактах. Тут вопрос в том, насколько жестко заданы критерии “готовности”. Если они достаточно описательны, т.е. заданы ближе к user story, чем к формальной спецификации, то можно варьировать этим параметром, т.е. подписываться на базовую функциональность, а рюшечки – если останется время или за отдельную плату. По такому принципу организация, в которой я в данный момент занят, зачастую и работает. Впрочем, есть риски разночтения и конфликтов, особенно если не установлен определенный уровень доверия между сторонами.
Если же заказчик не идет на сотрудничество в разбиении или гибком описании задач, то все равно можно использовать Скрам внутри организации-исполнителя, заказчиком в данном случае могут выступать Project Manager или бизнес-аналитики. Конечно, это не так эффективно, как в случае активного вовлечения заказчика, но все равно дает ряд преимуществ:
* раннее обнаружение проблем. Намного проще договариваться об изменениях в контракте в середине проекта, чем за день до дедлайна.
* работающая функциональность, приносящая максимум пользы. Опять же, если все плохо и нужно передоговариваться с клиентом, продукт построенный по принципе сашими “то что есть – полностью готово к употреблению”, усиливает позицию по сравнению с “работающей на 90%” системой, что в терминах водопада зачастую значит 10% недостающей функциональности размазанной везде и делающей продукт 100% непригодным с точки зрения конечного пользователя.
* Ну и когда Скрам работает в таком режиме, его можно наглядно продемонстрировать тому же заказчику, возращаясь к вопросу Time&Material.
P.S. аутсорс в вопросе, это любая не внутренняя (”in-house”) разработка, вне зависимости от географической топологии, я полагаю?
P.P.S. во второй книге Кена Швабера, “Agile Project Management with Scrum”, есть трехстраничный аппендикс Д, посвященный вопросу “Fixed-Price, Fixed-Date Contracts”, в котором предлагается стратегия включения гибкого, итеративного подхода (Скрама, конечно) в RFP bid как конкурентного преимущества.
Mykola,
Спасибо, очень четкий ответ на поставленный вопрос, не часто сейчас такие встретишь
Аутсорс - да, именно так. Книгу обязательно почитаю.
To Алексей, Mykola и прочие апологеты Scrum
К полному своему неудовольствию, я чувствую как мне все время что то мешает разделить с Вами оптимизм по поводу Скрама. Делаю последнюю попытку не отстать от мейнстрима
. Господа, может ли кто-то из Вас четко объяснить мне, что такого может делать Скрам, чего нельзя было делать в рамках других подходов к организации процесса девелопмента? Ну хотя бы в рамках RUP. Кто мешает в рамках RUP быть столь же гибким? Например, сделать итерации по 2 недели продолжительностью, (да хоть по 2 дня) после каждой итерации выдавать клиенту билд для просмотра (назовите это словом “демо”) и так далее?
Андрей,
не очень ИМХО правильная постановка вопроса. Скрам – это не религия, для перехода в которую нужно полностью порвать со всем другим. К гибкости можно прийти разными путями, даже,как говорят, из обновленного CMMI. Вопрос в том, насколько длинным и дорогим будет путь. Теоретически, можно быть гибким и в рамках адекватного RUP, пожалуйста, можно даже, если получилось, назвать это имплементацией Скрама. Или не называть, если не нравится.
To Андрей #45:
Я попробую ответить на вопрос:
“Господа, может ли кто-то из Вас четко объяснить мне, что такого может делать Скрам, чего нельзя было делать в рамках других подходов к организации процесса девелопмента?” С РУП знаком скорее теоретически, т.к. мы по нему не работали, но зато видел, как он работает в другой компании.
Два слова о себе: я был проджект-менеджером команд с хорошо налаженным MSF. Сейчас переходим на Скрам (одна из команд уже перешла), разница и достоинства очевидны.
1) Скрам создаёт среду, которую НИКОГДА не содаст РУП. Особенности:
а) очень-очень свободные комуникации. Все общаются непосредственно со всеми, т.к. для этого специально создаются каналы, процедуры и за этим следит специально обученный человек. В РУПе это делается с помощью бумажек-артефактов, что менее эффективно, более долго и вообще суть мусор (muda);
б) делегирование ответственности вниз к девелоперам. В РУП опять-таки такого нету, вместо этого есть очень-очень подробно прописанные процедуры кто что делает и в какой последовательности;
из чего следует
в) на любое изменение в ходе проекта реакция в Скраме будет намного лучше, чем в РУПе, в плане: народ быстрее разберётся и прийдёт к согласию, и количество бумажек-артефактов, которые нужно будет переписывать, будет существенно меньше;
и г) команда разработчиков в Скраме растет несравненно быстрее, чем в РУПе. Потоу что б), потому что поощряется инициатива и самостоятельное решение проблем.
и наконец д) работать в Скрам-команде намного более приятно, чем в МСФ. Отношения теплее, а давления сверху и поисков виноватых намного меньше. При этом все в команде работают намного напряженнее(!), чем до этого по МСФ.
Итого, с моей точки зрения, принципиальное различие: Скрам позволяет быстро и эффективно реагировать на изменения, чего не делает РУП. РУП пытается бороться с изменениями окрущающей среды с помощью контрактов и хорошо отлаженных процедур. Скрам пытается адаптироваться под любое изменение.
“Что мешает РУП быть столь же гибким?”.
С моей точки зрения, РУП мешают быть столь же гибким подход, который он использует. “Чтобы