Гибкий подход разработки ПО – 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
(32 голосов, средний: 4.5 из 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);
б) делегирование ответственности вниз к девелоперам. В РУП опять-таки такого нету, вместо этого есть очень-очень подробно прописанные процедуры кто что делает и в какой последовательности;
из чего следует
в) на любое изменение в ходе проекта реакция в Скраме будет намного лучше, чем в РУПе, в плане: народ быстрее разберётся и прийдёт к согласию, и количество бумажек-артефактов, которые нужно будет переписывать, будет существенно меньше;
и г) команда разработчиков в Скраме растет несравненно быстрее, чем в РУПе. Потоу что б), потому что поощряется инициатива и самостоятельное решение проблем.
и наконец д) работать в Скрам-команде намного более приятно, чем в МСФ. Отношения теплее, а давления сверху и поисков виноватых намного меньше. При этом все в команде работают намного напряженнее(!), чем до этого по МСФ.
Итого, с моей точки зрения, принципиальное различие: Скрам позволяет быстро и эффективно реагировать на изменения, чего не делает РУП. РУП пытается бороться с изменениями окрущающей среды с помощью контрактов и хорошо отлаженных процедур. Скрам пытается адаптироваться под любое изменение.
“Что мешает РУП быть столь же гибким?”.
С моей точки зрения, РУП мешают быть столь же гибким подход, который он использует. “Чтобы начать разрабатывать, нужно сначала подробно-подробно во всём разобраться и донести это до всех”, внимание к деталям. Поправьте меня, если я ошибаюсь. С другой стороны, я знаю, что есть Agile RUP (OpenUP), например в Инфопульсе.
“Я чувствую как мне все время что то мешает разделить с Вами оптимизм по поводу Скрама”
Возможно, Вам мешает разделить наш оптимизм страх: как можно отдать власть девелоперам? Как можно позволить заказчику менять требования по ходу разработки? Как можно кодить без архитектуры? Я разделял Ваши опасения, именно поэтому мы пытались убедить CTO не переходить на Скрам почти два месяца. Однако перешли, и результатами я доволен.
To Eugen_n
#28:
Я искренне удивлён тем, что Вы говорите. У нас дома строятся ДО получения полного комплекта документации (сам видел). Кроме того, НИ ОДИН проект по постройке домов не был сдан в сроки и не уложился в бюджет. ЭТО вы называете успешным управлением проектов?
#26:
Я общаюсь с достаточно широким кругом бизнесменов (мелкий и средний бизнес), и всегда интересуюсь как у них поставлено производство и управление. Так вот, из того, что я видел, в программировании – самые продвинутые подходы в управлении и отладке производственных процессов. Остальные отрасли даже рядом не валялись (кроме очень редких исключений, которые внедрили чистый LEAN, LEAN в модификации Голдратта, системы “Результат” или любой другой).
Артем,
вы совершенно правы, скрам это прекрасно как для менеджера, так и для команды! А какой-нибудь подход в духе “делаю что захочу” – еще лучше, не так ли? Если у заказчика много денег и он никуда не торопится, то и такой “процесс” даст результат, почему нет?
Если же речь идет о ПРОЕКТНОМ менеджменте, то во главу ставятся в первую очередь интересы ПРОЕКТА. Которые, как мы с вами знаем, заключаются в том, чтобы быть успешно сданным в СРОК и в БЮДЖЕТ, с необходимым уровнем КАЧЕСТВА и при условии наличия ряда РИСКОВ. Скрам никогда не удовлетворит этот интерес, у него просто нет для этого возможностей. Это очень важно понимать, вполне возможно что вы не сталкивались с такими проектами, потому что, к сожалению, 99% наших компаний работают по простой схеме “перепродай программиста на запад”. В этих случаях менеджер проекта бесконечно далек от менеджмента проекта, он скорее координатор, а чаще просто роутер коммуникаций между заказчиком и командой.
Не смотрите на текущую ситуацию на рынке, говоря “скрам работает”, она временная. Это то же самое что сигареты тележкой в Польшу возить, вместо того чтобы наладить производство и экспорт. Не ищите легких путей, в случае проектного менеджмента “проще” не значит “лучше”. Ваш пример со строительством прекрасное тому подтверждение, я тоже не видел ни одного здания, построенного в срок. Уверен, причина в том, что менеджеры проектов не читали PMBOK, а зря – хорошая книга.
To Артём говорит: 26.09.2008 в 09:40
Для начала ремарка – я отношусь к RUP ничуть не лучше чем к Скраму и точно также не считаю его панацеей. Если Вам для того чтобы 1. наладить коммуникации в команде 2. научиться делегировать ответственность разработчикам 3. поощрять инициативу 4. понимать что любая архитектура будет неоднократно переделана в ходе проекта и Вы должны обеспечивать легкость этой самой переделки в процессе разработки постоянно и наконец 5. просто организовать нормальные рабочие отношения в коллективе – необходимо назвать все это каким то словом (Скрам, например
) а еще прочесть об этом слове в какой то книжке – тогда я Вас отлично понимаю, безусловно в таком случае Скрам для Вас – есть нечто принципиально новое. Если Вы прочтете мои реплики в начале этой дискуссии – то я там писал, что я на первое место ставлю человеческий фактор и именно его считаю главным для успеха проекта. Чтобы работать с этим фактором – мне Скрам не нужен сейчас и 10 лет назад не был нужен. Прочтите на этом сайте интервью с Игорем Ашмановым – ему Скрам тоже не нужен. Прочтите Марко и Листера “Человеческий фактор” – там тоже нет ни слова про Скрам, но зато всячески подчеркивается что при любом процессе разработки – люди играют решающую роль.
“С моей точки зрения, РУП мешают быть столь же гибким подход, который он использует. “Чтобы начать разрабатывать, нужно сначала подробно-подробно во всём разобраться и донести это до всех”, внимание к деталям. Поправьте меня, если я ошибаюсь. С другой стороны, я знаю, что есть Agile RUP (OpenUP), например в Инфопульсе. ” – подробно разобраться во всех деталях до начала разработки – это водопадная модель. РУП – так же как и MSF и много чего еще – процессы итеративные, а размер итерации – Ваше личное дело, хоть ежедневными их делайте.
“Я чувствую как мне все время что то мешает разделить с Вами оптимизм по поводу Скрама”
Возможно, Вам мешает разделить наш оптимизм страх: как можно отдать власть девелоперам? Как можно позволить заказчику менять требования по ходу разработки? Как можно кодить без архитектуры? Я разделял Ваши опасения, именно поэтому мы пытались убедить CTO не переходить на Скрам почти два месяца. Однако перешли, и результатами я доволен.
“Власть девелоперам” – это несерьезно. Так же как и власть тестерам или архитекторам или уборщицам. Я никогда не называю сроков не поговорив с девелоперами – иначе у меня не будет морального права с них спрашивать. Но назвав срок клиенту – за него отвечаю перед клиентом я, а не команда. Коллективная отвественность – это безответственность. В конце концов от имени конторы подпись под контрактом ставит конкретный человек, а не команда девелоперов. Тем более, что у девелопера интерес в разработке авторский (отсылка к интервью Ашманова), а у конторы – и в частности у ПМ-а, как человека отвечающего за реализацию интересов конторы на проекте – интерес в том, чтобы заработать прибыль.
. В каждом конкретном случае Вы все-таки будете какую то архитектуру реализовывать. Другое дело что Вам с большой вероятностью придется ее переделать и не раз. Для этого Вы должны с самого начала проектировать так, чтобы такое изменение стоило минимум усилий. Но это не значит что Вы кодите без архитектуры. Даже Скрам Вам этого не позволит 
“Менять требования по ходу разработки” – такое ощущение, что апологеты каждой новой технологии начинают с того, что думают, что до них было пустое место. Все итеративные процессы разработки задумывались именно для того, чтобы дать возможность менять требования по ходу разработки. Скрам тут далеко не пионер.
“Как можно кодить без архитектуры” – да никак нельзя
Про результаты – давайте поговорим с Вами когда Вы сдадите свой проект. Я сейчас имею перед глазами только несколько неудачных примеров применения Скрама на проектах – не моих, я сторонний наблюдатель, который может себе позволить бесплатно учиться и делать выводы
. Как пример, – один из проектов длился больше полутора лет. В начале клиент получал кайф от процесса скрам митингов и от того количества идей которые ему генерировали девелоперы для его продукта 
. Где то через год он, однако, начал нервничать и говорить: когда же наконец Вы закончите переделывать и я смогу выставить систему в продакшн? Ему расказывали, что в этом суть Скрама, что зато мы гибко реагируем на все его фантазии и даже придумываем свои, напоминать что ему же это нравилось 
. Мне кажется что теперь, он был бы совсем не против, если бы на каком то этапе ему бы жестко зафиксировали требования и сроки разработки – чтобы он получил что то с чем можно было бы выйти к инвесторам. Но поезд уже ушел – вместе с актуальностью его продукта и его инвесторами.
Вадим, проще значит лучше. Потому что KISS. Потому что затрат меньше. Потому что более простая работа может выполняться менее квалифицированным ресурсом, а значит риски ниже и затраты опять же меньше. Сомневаюсь, что менеджеры не читали PMBOK. Думаю это первая книга, коотрую читает любой менеджер по проектам. Постарайся аргументировать свои мысли, а не излагать их в виде саомочевидных фактов.
To Андрей #49
Я решил отделить мух от котлет. Вот что мы обсуждаем.
Скрам – отстойный процесс
Я с Вами полностью согласен. Расскажите, пожалуйста, с помощью каких средств и процедур Вы в своей команде 2) делегируете разработчикам ответственность; 3) поощряете инициативу; 5) организуете “нормальные рабочие отношения” (а что значит нормальные, кстати?); 6) стимулируете их расти и учиться.
Вы считаете, что “гибкость” обеспечивается только длиной итерации. Я, со своей стороны, считаю, что гибкость обеспечивается не только длинной итерации, но и “идеологией”. В МСФ и РУП идеология “процедур” (бюрократия). Это противоречит быстрой реакции на изменения. В Скраме идеология “предпринимательства” – это способствует реакции на изменения. Именно это я имел в виду. Возразите что-нибудь на это?
Скрам не ведёт к успеху.
На фреймворке уже сделано несколько проектов. Определите критерии успешности – и давайте поговорим.
Спасибо за пример, интересно. А что мешает клиенту сейчас пустить систему в продакшн? Не все истории реализованы, или система нестабильна? Или вообще сделали не то, что хотелось?
Всяко-разно (наезды)
Спасибо, читал. Хорошая книга. Хотя лично как по мне, этому набору best practises не хватает системы, которая бы объясняля “почему именно так”.
Спорим о терминах. Неинтересно.
Никогда такого не видел. Не знаю, как у Вас, а у нас аккаунт-менеджер и проджект менеджер – совсем разные люди. ПМ НИКОГДА не подписывается под контрактом. ПМ-у у нас была по барабану прибыль, ему было важно выпустить в срок, в бюджет и по спекам.
To Артём
Скрам – отстойный процесс – я не говорил, что отстойный. Я говорил, что в нем нет ничего нового. Еще я говорил, что вся шумиха, которая он вокруг него поднята, создает как у клиента, так и у тех, кто на него молится – ложное ощущение решение проблемы.
Я с Вами полностью согласен. Расскажите, пожалуйста, с помощью каких средств и процедур Вы в своей команде 2) делегируете разработчикам ответственность; 3) поощряете инициативу; 5) организуете “нормальные рабочие отношения” (а что значит нормальные, кстати?); 6) стимулируете их расти и учиться.
Понимаете, я занимаюсь менеджментом уже более 11 лет. Люди всегда были самой интересной частью процесса разработки для меня, мне всегда было интересно изучать мотивы, которые ими движут. Люди до сих пор продолжают меня удивлять
. А процедур я Вам описать не могу – я противник процедур. Даже сама лучшая процедура не в состоянии предусмотреть всего что подкидывает реальная жизнь. Поэтому хороший менеджер – это творец. А плохому – процедуры служат только отмазкой в случае провала.
Вы считаете, что “гибкость” обеспечивается только длиной итерации. – Это Вы за меня додумали, где я такое сказал, что “только длинной итерации”? Не знаю воспримите Вы это как возражение или нет – но гибкость, на мой взгляд, обеспечивается прежде всего “качеством” вашей команды, а “качество команды” – это и есть человеческий фактор. У Вас может быть команда настроенная на победу (и тогда она сама включит в процесс по ходу проекта все нужные для успеха “процедуры” и даже придумает некоторые из них на ходу, а может быть команда настроенная на соблюдение процесса (”процедур”) – а если процесс не подходит к данному конкретному случаю – то тем хуже для клиента.
На фреймворке уже сделано несколько проектов. Определите критерии успешности – и давайте поговорим. – да вот Вадим Вам привел все критерии успешности – срок, бюджет и качество. Какие еще могут быть критерии?
Спасибо за пример, интересно. А что мешает клиенту сейчас пустить систему в продакшн? Не все истории реализованы, или система нестабильна? Или вообще сделали не то, что хотелось? И система нестабильна – потому что меняли постоянно, и реализовано не все. Но главная проблема в том, что время упущено. 6-8 месяцев назад они были бы одними из первых в некоем сегменте рынка, а теперь там уже полно других людей. Потому и инвесторы разбежались.
Спасибо, читал. Хорошая книга. Хотя лично как по мне, этому набору best practises не хватает системы, которая бы объясняля “почему именно так”. – Почему наезды? Откуда я знаю читали Вы этот труд или нет? Системы нет – потому что ее в принципе не существует. Все люди разные. Когда мне нужно, условно говоря, мотивировать вкалывать одного человека – я применяю один прием, другого – другой. Я иногда сам не знаю, как я буду работать с конкретным человеком, пока не изучу его как следует.
Спорим о терминах. Неинтересно. – Ну Вы же сами написали эту фразу “кодить без архитектуры”. Потрудитесь тогда объяснить, что Вы имели в виду.
Никогда такого не видел. Не знаю, как у Вас, а у нас аккаунт-менеджер и проджект менеджер – совсем разные люди. ПМ НИКОГДА не подписывается под контрактом. ПМ-у у нас была по барабану прибыль, ему было важно выпустить в срок, в бюджет и по спекам.
“К пуговицам претензии есть? – Нет”
Это плохо, что ПМ-ам прибыль по барабану. В этом одна из проблем украинского ИТ. Что Вы называете словом бюджет, кстати? Если речь идет о человеко-часах, то Вадим прав – это скорее работа координатора, чем менеджера. Настоящий менеджер влияет на прибыльность проекта для компании. Можно сделать проект более дешовыми, а можно более дорогими ресурсами. Даже если два разработчика носят титут сеньора – у них может быть разная зарплата. И так далее. А аккаунт менеджеры – даже самые лучшие, они в деталях тех. процесса разбираются слабо. Хороший ПМ очень много чего может им подсказать насчет того, что еще можно предложить клиенту чтобы с него денег получить побольше. А еще хороший ПМ способен помочь сейлзам на этапе переговоров с клиентом обосновать и отстоять эстимейт.Когда человек начинает мыслить категориями денег и прибыли – он сразу понимает, как на самом деле неважно, как именно называется процесс разработки, который он использует
2 Вадим (№48)
я, как МП, не очень понимаю что такое “интересы проекта”. проект есть ровно до тех пор, пока он удовлетворяет нужды стейкхолдеров – так вот если у проекта и есть интерес, так он в том, чтобы УДОВЛЕТВОРИТЬ НУЖДЫ СТЕЙКХОЛДЕРОВ. Да – в частном случае – это может быть “уложиться в срок и бюджет”, но далеко не всегда. Есть ещё такие интересы как “заработать на разработке”, “сделать нужный продукт” – если вы уложились в сроки и бюджет, но сделали никому не нужную фигню, то у меня назвать жто “успехом” язык не повернётся.
основная проблема разработки сейчас в том, что между фиксацией требований и их реализацией проходит время, за которое требования устаревают. Я подчеркнул основная и сейчас потому, что основная масса разработок сейчас делаются для опережения конкурентов, которые тоже не стоят на месте, поэтому требования меняются очень часто. это касается не только интернет-сайтов
ну и кстати, Scrum очень легко отвечает на вопрос “к какой дате будет готов этот функционал” и “какой функционал будет готов к такой-то дате”. И ошибается примерно на столько же как и RUP, PMBOK и Павел Глоба
между прочим строительные компании разгребают PMI-сертифицированных менеджеров, так что читали.
Сотона,
1. давайте на примере. Есть проект – постройка дома. Стейкхолдеры: заказчик, генподрядчик, стройбригада и будущие жельцы. Если, следуя вашей логике, определить цель проекта как “удовлетворить интересы всех стейкхолдеров”, то проект лучше закрыть не открывая. Закачик хочет дешево построить, дорого продать, подрядчик – дорого построить с минимумом издержек, бригада хочет ничего не делать и получать зарплату, а жильцам нужны дворцы, каждому свой и практически даром. Я не рекомендовал бы никому браться за проект с такой постановкой цели, он обречен на неуспех.
В проектном менеджменте есть понятие Project Objectives. В которые входят те цели, по достижению которых проект считается завершенным. Эти цели ставятся четко, это SMART цели.
“сделать нужный продукт” это не цель, это самообман,
“сделать продукт удовлетворяющий всем требованиям из Scope проекта” это правильно поставленная цель
“заработать на разработке” это тоже что-то абстрактное и невыполнимое,
“завершить проект в рамках бюджета, указанного в документе Cost” – лучше формулировать так
“сделать качественный продукт ” – это тоже детский сад
“найти и исправить по закрытию проекта 1500 дефектов” – вот это другое дело.
В цели проекта всегда входит соответствие его Baseline и это САМЫЕ приортитетные цели в общем случае. Мне очень жаль стейкхолдеров fixed-cost проектов, которые преследуют другие цели.
2. Что касается быстрого устаревания требований, тут я с вами согласен, это проблема, но решение ее есть в любом худо-бедно поставленном процессе, будь то RUP, Scrum или что другое, называется это Integrated Change Control.
3. Scrum безусловно очень легко отвечает на вопрос “к какой дате будет готов этот функционал” и “какой функционал будет готов к такой-то дате” в рамках одного спринта, но не более.
Итог, Scrum безусловно хорош для Time&Material контрактов где никто толком не считает ни времени ни денег, но для fixed cost не годится он.
P.S. мы говорим об одном и том же
Строительные компании разгребают PMP именно потому, что текущие руководители сейчас не квалифицированы.
2 Вадим
вы неправильно поняли “мою логику”. дома сторятся именно чтобы удовлетворить все интересы: если бы это было не интересно инвестору, он бы не инвестировал, не интересно подрядчику – не брался бы за подряд, бригаде – не работали бы, жильцам – не покупали бы. если хоть где-то в этой цепи пропадает интерес, то проект просто закроют. если на примере, предположим, что рядом со стройкой начал быть природный источник аммиака. проект завершить в срок и бюджет можно, но жильцам уже не интересно. вопрос – будет ли продолжен проект?
так что без удовлетворения интересов никак.
завершённым, но не успешным. а толку?
есть, но решается “худо-бедно”, а гибкие методологии “заточены” под это. по крайней мере это декларирут
ничего подобного. как раз в рамках одного спринта он ничего не гарантирует, а вот что будет в конце 5го, 10го или 20го спринта – говорит. повторюсь: с той же точностью, что и другии методологии.
нет. я говорю о том, что несмотря на то, что там работает куча PMI-сертифицированных менеджеров, дома в срок не сдаются.
это всё не аргументы против\за Scrum. там совсем другие проблемы… основная – как получить “self-organized motivated cross-functional team”. А если получили, то возникает вопрос “нафига скрам\руп\мсф?” такая команда любой проект сделает без всякой методологии
http://gaperton.livejournal.com/17873.html – случайно набрел на эту заметку в блоге. Понятия не имею о том, кто этот парень, но он написал именно то, что я думаю об Agile и прочих “процессах” разработки. 5 баллов!!!
Мое мнение, что Скрам – это все-таки мура.
Все конторы, которые его используют – это инвестиционные пузыри. Им бабки от инвесторов льются потоком поэтому конкретных сроков на реализацию не существует.
Разботчики не заинтересованы в досрочном выполнении задач – их цель выполнить кусочек работы выделенный для них, а дальше заниматься своими делами. Общее время и стоимость проекта можно определить только постфактум либо приблизительно на предпоследней итерации.
Честно говоря – это просто всего-лишь еще один способ выкачивать деньги через никому не нужные сертификации и семинары.
Все конторы, которые его используют – это инвестиционные пузыри.
Мы не пузырь, пузырь не мы.
Заказная разработка, финансовые и учетные системы.
господа, я вас прошу. не пишите о том, в чём вы не разбираетесь. не портьте себе карму. она ещё вам пригодиться.
мыльные пузыри были, есть и будут есть. и не важно каким подходом они управляются. суть от этого не меняется.
agile – это не методология, как указано в грубой статье, на которую сослался Андрей. это всего лишь набор принципов, которые помогают ряду людей работать более эффективно. не более. к примеру:
и так далее… ни слова про пузыри, заметьте.
если вы нашли нечто, что работает лучше в вашей ситуации – это просто отлично! делитесь опытом, пишите книги, проводите конференции и тренинги. я лично приду.
на то вы и профессионалы, чтоб искать решения проблем. я ищу решения в поле agile и пока нахожу. перестану находить, стану искать подсказки в других источниках.
каждому проекту своя методология – об этом написал ещё в начале нашего века один популярный автор.
экспериментируйте!
удач!
2 Андрей:
Почитал пост означенного аффтара. И блог почитал. Впечатления интересные
.
Аффтор составляет планы на год вперёд с оценкой кривой риска, трудозатрат на программирование и т.п.
В этом ему помогают наукообразные методики навроде ПЕРТа и КОКОМО2. За наличие этих методик он хвалит себя, а всех остальных обзывает шарлатанами. К сожалению, аффтар не рассказывает, насколько его запланированные на год вперёд проекты превышают бюджет и сроки, несмотря на трое- и четырёхкратные буфера.
Что ещё интересно, аффтар ругает Си++ за недорост до промышленных стандартов
) У аффтора вообще хорошо получается ругать. Боб ему, как говорится, в помощь.
К сожалению, из приведённого Вами поста видно, что аффтар не ни читал Бека, ни Швейбера, и теорий с моделями за аджайлом не видит. Что говорит плохо не об аджайле, а скорее об аффтаре
). А они есть (как суслик), и годочков им под 50.
Что характерно, аффтар даже на РСДН своего имени-фамилии не указал
) Ни рода занятий. А жаль.
2 Dmitry Yeskin:
> Все конторы, которые его используют – это инвестиционные пузыри. Им бабки от инвесторов льются потоком поэтому конкретных сроков на реализацию не существует.
Мы не пузырь, наши клиенты на нас очень давят в плане сроков.
> Разботчики не заинтересованы в досрочном выполнении задач – их цель выполнить кусочек работы выделенный для них, а дальше заниматься своими делами.
У меня сейчас 7 аджайл-проектов, которые я мониторю. Описанная Вами ситуация есть только на одном, сложилась потому, что тим лидер там так настроил команду. В остальных 6-ти народ честно добирает задачи, если справились раньше. Тяжело заниматься своими делами, если каждый день у тебя спрашивают: “Что ты сделал вчера и что сделаешь сегодня?”
> Общее время и стоимость проекта можно определить только постфактум либо приблизительно на предпоследней итерации.
Что значит “общее время и стоимость?” Оценить время и стоимость мы можем на первой итерации. С каждой итерацией оценка становится всё более точной. Самую точную оценку мы можем дать на предпоследней итерации.
Насколько такая оценка менее точна, чем традиционная с использованием СОСОМОII, PERT и иже с ними – не имею ни малейшего понятия. Если у Вас есть такая информация – поделитесь. Если нет – это Ваше личное ничем не подтвердженное мнение.
2 Артём
> Аффтор составляет планы на год вперёд с оценкой кривой риска, трудозатрат на программирование и т.п.
Ага.
> В этом ему помогают наукообразные методики навроде ПЕРТа и КОКОМО2.
PERT помогает, еще помогает PSP/TSP, а COCOMO2 автор по ряду причин не использует.
Ничего наукообразного в этих методологиях нет, все очень просто.
> За наличие этих методик он хвалит себя, а всех остальных обзывает шарлатанами.
Ни припомню, чтобы за наличие этих методик автор “хвалил себя”. И обзывал “шарлатанами”
“всех остальных”.
> К сожалению, аффтар не рассказывает, насколько его запланированные на год вперёд проекты превышают бюджет и сроки, несмотря на трое- и четырёхкратные буфера.
“Трехкратных” и “четырехкратных” буферов не бывает – две сигмы к матожиданию уже дают тебе 98%. Учи матчасть. А запланированный на год проект при нормальном планировании, контроле, и управлении требованиями сорвать очень сложно, хотя бы потому, что роль “буфера” помимо сигм также играют “опциональные” и “желательные” требования.
>Что ещё интересно, аффтар ругает Си++ за недорост до промышленных стандартов
) У аффтора вообще хорошо получается ругать. Боб ему, как говорится, в помощь.
Это ты об этом посте из RSDN.Юмор?
http://www.rsdn.ru/Forum/?mid=1156694
Вот, зацени, а вот тут я еще очень серьезно про системное программирование пишу.
http://www.rsdn.ru/Forum/?mid=1653794
> К сожалению, из приведённого Вами поста видно, что аффтар не ни читал Бека, ни Швейбера, и теорий с моделями за аджайлом не видит. Что говорит плохо не об аджайле, а скорее об аффтаре
). А они есть (как суслик), и годочков им под 50.
К сожалению, по какой-то непонятной причине агилистам гораздо проще обсуждать личность собеседника, чем вести разговор по существу. Видать, по существу больно тяжело разговор им дается.
> Что характерно, аффтар даже на РСДН своего имени-фамилии не указал
) Ни рода занятий. А жаль.
С какой стати мне делать свои персональные данные доступными каждому придурку в сети?
Вот ты, например, в состоянии членораздельно объяснить – они тебе зачем? 
> Что значит “общее время и стоимость?”
> Оценить время и стоимость мы можем на первой итерации. С каждой итерацией оценка становится всё более точной. Самую точную оценку мы можем дать на предпоследней итерации.
Фраза про “общее время и стоимость” тебе непонятна, и требует пояснения? Удивительное рядом. Смотри – ты заключаешь контракт на условиях fixed cost. В данном случае, от тебя требуется дать разбивку проекта на этапы, стоимости этапов, и их даты. В случае, если работа ведется в соответствии с ГОСТ (например, 24-м или 43-м) – то это вообще является частью ТЗ, и кроме того фиксируется в план-графике.
Если ты сильно ошибешься в данной оценке (”общего времени и стоимости”) – то твой проект будет провальным. Если ты это узнаешь ближе к концу или середине, то возможности что-либо переиграть у тебя будут весьма ограничены. Если ты предложишь свои короткие итерации без долгосрочного планирования (что есть фактически повременка), то ты c высокой вероятностью проиграешь тендер конкуренту, который умеет делать fixed cost.
С удовольствием послушаю, каким именно образом ты будешь планировать и выполнять проекты fixed cost следуя “agile”, и каким именно “agile” из всего этого зоопарка ты будешь пользоваться, и как это будет выглядеть.
Кроме того, чрезвычайно интересно – какие сроки у твоих семи проектов, и какой размер команды на каждом из этих проектов. Наверняка мелочевка какая-нибудь, которую вообще без разницы, каким процессом делать.
> Насколько такая оценка менее точна, чем традиционная с использованием СОСОМОII, PERT и иже с ними – не имею ни малейшего понятия. Если у Вас есть такая информация – поделитесь. Если нет – это Ваше личное ничем не подтвердженное мнение.
Пока не понятно, как ты вообще оценку делать собираешься. А что касательно методов планирвоания, основанных на корелляциях метрик времени-объема – они позволяют уложить погрешность планирования в 10% при желании.
> В случае, если работа ведется в соответствии с ГОСТ (например, 24-м или 43-м)
Программерский ГОСТ, естественно, 34-й. Опечатка.
Gaperton:
В Agile этому примерно соответствует release planning. Более того, именно с fixed cost, и даже fixed cost & schedule проектами проблем как раз нет. Размер команды фиксирован, следовательно, стоимость итерации – тоже. Значит, длительность проекта (т.е. количество итераций) напрямую зависит от бюджета. Важно только не путать “fixed cost” с “fixed all”. В случае именно “fixed cost” функционал проекта остается переменной величиной. Как говорится, “сколько заплатили – на столько и споем”. Но это отнюдь не индульгенция, чтобы “петь” плохо – ведь заказчик соотносит затраты и полученный результат после каждой итерации, и имеет право нажать кнопку “стоп” после любой из них.
С другой стороны, никто не спорит с тем, что Agile в чистом виде НЕ работает для fixed-all проектов. Хотя бы потому, что желание заказчика настоять на fixed all есть, как правило, следствие недоверия к исполнителю. А для того, чтобы Agile работал, доверие между заказчиком и исполнителем должно быть.
Agile-подходы “заточены” под небольшие команды (7 плюс-минус 2 человека, как правило), при этом долгосрочное планирование делается на стратегическом уровне (в этом релизе у нас будут примерно такие и такие фичеры, а в следующем – такие и такие). Временные рамки одного релиза – навскидку, от силы 3-4 месяца. Хотя, Microsoft Visual Studio 2008 делала огромная команда, причем разные ее компоненты даже делались по разным Agile-процессам
И ничего, сделали ведь, и успешно продают.
Можно возразить, что есть заказчики, которым такой подход не годится, им нужно расписать детальный план на “пятилетку” вперед. Я не буду спорить с очевидным фактом наличия таких заказчиков
Но зато буду спорить с тем, что можно достичь погрешности в 10% при таком планировании, если только это не конвейерное производство (одна и та же предметная область, за плечами опыт нескольких успешных проектов, накоплены метрики времени-объема именно для этой команды и этой предметной области и т.п.)
Но, таким образом, мы опять возвращаемся к философскому спору “где нужен Agile?”. Так вот, для решения повторяющихся и хорошо известных задач Agile не нужен. Нужен он для другого – для создания инновационных продуктов, аналогов которым может и не быть на рынке. Собственно, вовлечение заказчика, частые релизы, принцип “Все. что сделано – готово к употреблению” – это все следствия принципа “Максимум результата за минимум средств и как можно быстрее”. Имеет ли место fixed cost в таких проектах? Скорее всего, да – объем инвестиций ограничен. Fixed schedule? Довольно часто, а если даже и не в чистом виде, то все равно важна скорость выпуска первых версий, чтобы “застолбить” рыночную нишу. Fixed scope? А вот это вряд ли. Разве что мы делаем приложение-”убийцу” некоего уже популярного продукта – но в таком случае менее критичными становятся сроки, так что мы можем позволить себе дополнительную итерацию-другую (если к тому времени команда оправдает вложенные в разработку деньги, разумеется).
В заключение – похоже, что вы и Вадим, скорее, говорите именно о “конвейерных”, крупномасштабных проектах. Но тогда спор не имеет смысла, я уже согласился с тем, что для таких проектов Agile может быть далеко не лучшим выбором, особенно если имеет место тендер. Тендер (если мы говорим о честном тендере и грамотном заказчике) выиграет тот исполнитель, у которого больше опыт и накатанней технология. При неграмотном заказчике тендер может выиграть предложивший самую низкую цену, но в результате пострадают оба.
To DmytroL
, однако в реальном мире аутсорсинга – такие звери встречаются редко, (думаю, что во времена кризиса так вообще не будут встречаться).
Рассуждения столь же правильные – сколь и абстрактные. Примерно как в анекдоте про математика и воздушный шар. Где мы, кто мы, для чего мы и где Scrum?
Microsoft Visual Studio – это продуктовая разработка. Хозяин барин – сколько захотел итераций, столько и сделал, сколько захотел денег вложить – столько и вложил. Перенос сроков выхода продуктов в том числе и Microsoft является скорее правилом, чем исключением.
Мы (то есть 90% ИТ Украины) работаем в аутсорсинге, что на практике означает – те самые абстрактные fixed all проекты, то есть клиент знает, (или думает, что он знает) что он хочет (fixed scope), знает сколько у него есть денег (fixed cost), знает когда ему это надо (fixed terms). Случаев когда бы клиент сказал – делайте что хотите и сколько хотите (то есть проявил бы то самое доверие к команде, о котором так много говорят певцы Аджайла – я в своей практике не встречал). Чтобы хоть как то клиенту гарантировать результат – мы должны составлять план работ на весь проект, а не на одну итерацию. Методик, которые позволяли бы это делать хотя бы с гарантией больше 50% – я не знаю, тем не менее – лучше иметь самый плохой план, чем вообще никакого.
Кстати, мне известны случаи аутсорсинга разработки компанией Microsoft – демократией и доверием к команде в этих случаях и не пахло, был жесткий контроль сроков и планов.
Возможно, что Scrum применим к проектам у которых не fixed scope, еще лучше он применим когда cost тоже не fixed и совсем хорошо – когда не fixed вообще ничего и ничто не сдерживает творчество комнады
Это не совсем тождественно fixed-all. Fixed-all – это когда клиент говорит: вот вам спека, пропишите в контракте дату и стоимость, а затем подпишитесь кровью, что вы не потратите ни цента больше, не задержите релиз ни на один день, а спека станет для вас Священным Писанием, от которого вы не отступите ни на йоту. Вот именно в таком сценарии, как я писал выше, в чистом виде Agile не работает. К тому же, fixed-all напрямую противоречит классическому “iron triangle”, поэтому подобные проекты весьма часто заканчиваются “некрологом”.
Не скажу за весь украинский аутсорсинг, но, слава Богу, среди наших клиентов именно такой сценарий встречается очень редко. Гораздо чаще фиксируется что-то одно: либо нужно успеть показать хоть что-то к такой-то дате, либо нужно сделать наиболее нужные фичеры за ограниченную сумму денег, либо нужно сделать все фичеры, но имеется определенная степень свободы в бюджете и сроках.
Доверять можно в разной степени. Ни один вменяемый клиент, только начиная работать с командой, разумеется, не скажет “делайте что хотите и сколько хотите”. Вопрос в другом – настроен ли клиент решать проблемы конструктивно, или предпочитает обложиться со всех сторон бумажками и общаться с позиции “я начальник – ты дурак”?
Agile предполагает (я бы даже сказал, требует) конструктивности и адекватности со стороны клиента, а взамен экономит клиенту деньги на change control и дает больше той самой гибкости в переигрывании требований и приоритетов.
То, что в Agile метдологиях нет долгосрочного планирования – это миф, причем почему-то очень устойчивый. Чего действительно нет в Agile, так это попыток предсказать будущее с нереальным уровнем детализации – например, расписать работу на год вперед на каждого члена команды на уровне тасков по несколько часов, а потом на основе Gantt-chart вычислять дату завершения проекта.
Поэтому, чтобы действительно не говорить о “сферических конях в вакууме”, нужно понять, какие уровень детализации плана и погрешность устроят заказчика на этапе начального планирования. Agile обеспечивает среднесрочное (временные рамки примерно 3-4 месяца) планирование на уровне user story (читай, фичера) и долгосрочное планирование (временные рамки примерно год) на уровне крупных кусков функционала (на примере MS Outlook это будут работа с e-mail, календарь, работа с тасками и т.п.). Планирование на уровне мелких тасков для конкретных людей действительно делается ТОЛЬКО для текущей итерации.
К тому же, Agile предполагает постоянное уточнение плана. И если в начале проекта гарантий будет не больше, чем в классическом планировании, то с каждой итерацией эти гарании будут увеличиваться, так как накапливается статистика о производительности команды, уточняется понимание сложности требований, рисков и т.п. Разумеется, ничто не мешает уточнять планы и в классическом менеджменте проектов, но слишком уж трудоемкая это работа – перерисовывать Gantt chart каждые две недели-месяц, кто пользовался MS Project – тот поймет
Ну это тоже что-то из разряда мифов. В Agile cost фиксируется как минимум в пределах итерации. Представь себе, что каждый фичер стоит сколько-то “попугаев”. Команда из X человек за Y дней в среднем производит фичеров на Z “попугаев”, работа этой команды в течении Y дней стоит N долларов. Причем, при стабильной команде, чем больше идет проект, тем меньше отклонения Z. В любом случае, заказчик рискует не более чем N долларами.
Причем, при Y в пределах двух недель-месяца, это самое N гораздо меньше той суммы, которую бы потерял заказчик, если бы команда облажала “классический” проект – потому что по классическому сценарию, облажалово становится очевидным только под конец проекта. И 2*N, и 3*N тоже гораздо меньше этих потенциальных потерь.
Так что “творчеству команды” (в плохом смысле этого слова) здесь не место. Извольте отработать вложенные в вас N долларов, потому что за них ожидается вполне конкретный результат. Да, для первой-второй итерации этот результат может не совсем совпадать с ожидаемым – здесь важно, чтобы:
а) Команда продемонстрировала заказчику готовность признавать свои ошибки и учиться на них
б) Заказчик понимал, что мы живем не в идеальном мире и ошибки случаются. Важно их не повторять.
Вот это и есть фундамент для того самого мифического доверия, кстати говоря. А вот если команда на ошибках не учится и все равно лажает дальше, то как минимум заказчик потеряет меньше денег, так как облажалово станет очевидным гораздо раньше.
Кстати, вчера прочитал очень умную мысль на эту тему: “Скрам – это вообще не методология разработки ПО. Скрам – это на самом деле инструмент для быстрого выявления слабых мест в вашей организации.”
To DmytroL:
, ситуацию с проектами тоже знаю, однако имею на нее взгляд с твоим не совсем совпадающий, поэтому предлагаю ограничить дискуссию о проектах в нашей компании рамками нашей компании. 
1. Предлагаю в дискуссии в дальнейшем не ссылаться на ситуацию с проектами в нашей компании, потому что совершенно случайно я работаю в той же самой компании
Владельцем iron triangle никогда не является команда разработчиков. В лучшем случае можно подсказать клиенту что то сделать. Это прерогатива клиента – маневрировать iron triangle. Спеки, сроки и прочее нарушаются почти всегда как в софтверных, так и в любых других инженерных проектах, это жизнь. Поэтому расказывать о том, что только Аджайл дает возможность гибко все это менять – это мягко говоря литературное преувеличение.
– Аджайл предполагает получение у клиента в начале проекта справки об адекватности?
Клиенты бывают очень разные и работать приходится со всеми, если конечно компания хочет остаться в бизнесе.
Вот ты идешь на рынок, покупаешь 10 мешков картошки и расчитываешь уложиться в N денег. Продавец тебе говорит – у нас фиксирована стоимость только первого мешка картошки, остальные мы Вам будем доставлять по 1 в неделю, стоимость каждого нам будет ясна в процессе с учетом рисков доставки, стоимости погрузки и т.п. Как фиксация костов для итерации помогает ответить на вопрос сколько будет стоить весь проект (хотя бы с погрешностью 20%)?
Почему то все апологеты Аджайла уверены в готовности и желании клиента их чему то учить на себе как на подопытном кролике. Задачи клиента более просты – получить в срок то на чем он сибирается заработать деньги.
– согласен! Внедерение Скрама в организации показывает неспособность построить нормальный рабочий процесс
Все основные приемы менеджмента известны со времен построения первого сложного инженерного объекта в истории человечества – то есть египетских пирамид. И только ИТ с упорством, достойным лучшего применения пытается изобрести свои велосипеды. Думаю, что это потому, что ИТ -шники просто не хотят быть инженерами 
, настаивая на своей особенности 
Отрасль просто росла быстрее чем это было возможно, поэтому очень много случайных людей. Вся надежда – на кризис 
Почитал комментарии. Было очень интересно. В этой переписке участвовали несколько руководителей проектов. Совершенно очевидно, что в этой переписки они одержали победу и это, похоже, как издевательство над детьми. Не понятно зачем только спорить, ведь scrum – это “советы” по созданию ПО. Советы хорошие, кстати. Но, например, провернуть в телекоме проект по переходу на новую биллинговую систему со сменой оборудования c помощью этих простых советов не получится в рамках срока, бюджета и целей. Потому что scrum-советы не для этого. А PMBOK вообще не завязан на ПО. Сравнивать даже нечего по сути.
“Скрам – это подход управления проектами” – это очень громкая фраза и очень несерьёзная. Будьте скромнее.
Спасибо, Fox.
Сравнивать как по мне, тут и правда нечего. Кто-то готов, кто-то нет. Не для всех эффективность – это цель. Да и просто не всем по стилю работать в командом режиме.
Мы все разные.
Для меня эффективность – это выпуск решений, решающих задачи бизнеса. При чём в короткие сроки и с таким качеством кода, за который мне никогда не будет стыдно. У кого-то могут быть другие критерии успешности. Никто не прав. Никто не неправ.
В своей статье Время переосмысления я попытался более подробно раскрыть выгоды от применения Agile с точки зрения конкурентной выгоды в условиях т.н. кризиса.
У кого есть уши, тот услышит.
Прочитал “Время переосмысления” Я думал стиль”взвейся и развейся” гигнулся вместе с Ленинским Комсомолом. Ан нет
Опыт Скрама более полугода. Не нравится! Сегодня делаем, не продумывая завтра и особо не смотря на вчера. Завтра видим, что для следующей задачи/фичи вообще половину переписать нужно или вообще невозможно. Может это и не проблема Скрама а отсутствие проработки архитектуры. Т.е. эта форма организации без толкового прототипирования, проджект-менеджмента, QA ничего не даст. А оставлять все на суд команды это лажа – у нас было 5 человек и у всех свое мнение по поводу решения, решали голосованием, общего видения не было ни у кого. Во время спринта за командой никто особо не следил. Результат ужасный. Люди берут себе задания, какие считают привлекательными, в результате хороший базовик написал кривое ГУИ, а ГУЕвик сделал кривую базу. Никто не запрещает тебе брать задачи, на которые ты не способен. Это мегариск. Каждый придумывает время на таск – смех, да и только, одни (кто поопытнее) ухитряются раздуть проблему и выторговать больше времени для баклуш, а кто менее опытный берет задачу на день и попадает на неделю (учитывая также то, что проектирования не было). Внутри команды полная анархия, главного нет, никтно никого не слушает, каждый делает так как считает нужным. В результате система написанная раком, лебедем и щукой.
Сейчас я ПМ в этом колективе, склоняюсь к классике, сам распределяю задачи, зная способности всех. Контролирую процесс разработки, какие человек принял решения по задаче и т.д., т.е. стараюсь делать все, чтобы проект был в хоть каких-то архитектурных рамках. Но народ уже разбалован жуткой анархией, так что прийдеться попотеть.
Скрам считаю высшим пилотажем в слаженной команде мегапрофессионалов. Иначе как ничего не продумывая, отдавая все команде мы можем получить качественный и своевременный результат?
Привет, Александр.
Классика руководства проектом конечно работает, если руководитель обладает умениями, навыками и талантами. Дело лишь в том, что такой подход может вести к следующим проблемам управления:
1. выращивание узкоспециализированных специалистов (это происходит постепенно, когда PM оптимизирует раздачу задач, так чтоб росла локальная продуктивность: люди делают схожие задачи тем, которые они делали раньше);
2. это в свою очередь приводит к мышлению в рабочей группе типа “я свое сделал…”, это не командна, со всеми вытекающими;
3. у PM-a растет число задач по микроменедженту своей группы, так как он является единственным человеком, который видит “всю картину”;
3. подключение новых людей становится задачей PM-a, текущие работники не заинтересованы в обучении новеньких – что им с того?
4. когда в итоге новых людей подключают, у PM-а работы только прибавляется;
5. в итоге PM (а это особенные люди) занимается задачами ниже своего уровня компетенции
вместо этого они могли бы заниматься:
а) развитием продутка;
б) формированием команды и устранением пряпятствий на её пути;
в) высокоуправленческой функцией на уровне предприятия.
и т.д.
теперь о проблемах по задачам и прогрессу проекта:
1. так как члены рабочей группы работают над своими задача (частями функционала), размеры задач и темпы работы людей разняться, то какая-то часть фич оказывается сделана частично;
2. что такое частично сделанная работа (фича) – это вливания инвестиций, которые не вернулись;
3. эти фичи нельзя потестировать и, если их много, то проект оказывается в состоянии “мы на половине проекта” или “50% фич сделаны наполовину”;
4. это непрозрачно и рискованно для инвесторов, заказчиков, подрядчиков – всех заинтересованных сторон.
это неуправляемый проект. титаник.
есть ещё проблемы, которые могут вытекать из классической модели управления. но даже, если их удается контролировать, такой подход не дает возможность людям (командам) раскрыть весь свой потенциал. а команды – это ценнейший фонд компаний, которые занимаются интеллектуальными разработками.
это как ехать на машине на второй передаче.
ехать, конечно можно, но предел скорости весьма ощутим. плюс это неэкономно, гудит, да и другие машины обгоняют.
приходите на PM-labs на наш доклад по этой теме
2krivitsky
піар скрума заради еджайла.
Скрум еджайл і тому подібні штучки кльові, коли збурається кучка народу, які мають в голові ідею а потім пробують її імплементити
а це буває дуже рідко.
Насправді набагато ліпше, коли є специфікація на продукт, а далі – розбиваєм слона на кусочки і ковтаєм.
п.с.олександр якраз взявся “виводити титаніка” з крутого піке скрума
Я видел команды, которые ВО ВРЕМЯ проекта наполнялись идеями, видением и мотивацией. И именно благодаря той командной алхимиии, которую предлагаю скрам. Желаю всем когда-нибуть это испытать.
Я видел команды, которые говорили “у нас не работает Скрам”. Но на деле скрамом там не пахло. Мне понадобилось 3 года, чтоб понять как работает Скрам и почему он такой какой он есть. В течение этих трех лет я делал многое неправильно.
Учусь до сих пор, но успех таких команд и проектов как iDOM доказывает мне, что я на правильном пути.
Желаю Александру, его проекту и команде успехов. Буду рад уделить его проекту пару часов личного времени.
Удач!
to krivitsky
Вы знаете, мне интересны многие вещи из agile подхода, и многие из них я считаю совершенно правильными.
Но, вот, маркетинговая пропаганда всегда вызывает желание поспорить. Попробу. его реализовать
> 1. выращивание узкоспециализированных специалистов (это происходит постепенно, когда PM оптимизирует раздачу задач, так чтоб росла локальная продуктивность: люди делают схожие задачи тем, которые они делали раньше);
Задача нахождения баланса между общими и специальными навыками у работников не специфична для разработки ПО. Но, согласитесь, в целом мир движется к большей специализации.
> 2. это в свою очередь приводит к мышлению в рабочей группе типа “я свое сделал…”, это не командна, со всеми вытекающими;
как раз задача PM сделать так, чтобы была команда, так ведь. И такое мышление — не самамя сложная проблема для решения.
>3. у PM-a растет число задач по микроменедженту своей группы, так как он является единственным человеком, который видит “всю картину”;
какая связь между микроменеджментом и всей картиной?
>3. подключение новых людей становится задачей PM-a, текущие работники не заинтересованы в обучении новеньких – что им с того?
это зависит от конкретной ситуации. Кто-то хочет работать с интересными людьми, еще какие-то соображения бывают. Также может быть и отсутствие заинтересованности к привлечению новых людей в скрам-команде.
>4. когда в итоге новых людей подключают, у PM-а работы только прибавляется;
Закон Брукса?
>5. в итоге PM (а это особенные люди) занимается задачами ниже своего уровня компетенции
какими имеено?
>вместо этого они могли бы заниматься:
>а) развитием продутка;
это функция менеджера продукта, а не менеджера проекта
>б) формированием команды и устранением пряпятствий на её пути;
как раз этим PM и должен заниматься. Что ему мешает?
>в) высокоуправленческой функцией на уровне предприятия.
а этим должен заниматься управленец соответствующего уровня. Для маленьких компаний, эта фнкция может оказаться совмещенной с функцией PM, но в общем случае, зачем?
>теперь о проблемах по задачам и прогрессу проекта:
1. так как члены рабочей группы работают над своими задача (частями функционала), размеры задач и темпы работы людей разняться, то какая-то часть фич оказывается сделана частично;
2. что такое частично сделанная работа (фича) – это вливания инвестиций, которые не вернулись;
3. эти фичи нельзя потестировать и, если их много, то проект оказывается в состоянии “мы на половине проекта” или “50% фич сделаны наполовину”;
4. это непрозрачно и рискованно для инвесторов, заказчиков, подрядчиков – всех заинтересованных сторон.
выход? да, частые релизы. Как это противоречит варианту, когда командой управляет PM?
>это неуправляемый проект. титаник.
если плохие руководители, то да. Но, это общемировая проблема. Качество менеджмента определяет всё. Скрам — серебряная пуля?
>есть ещё проблемы, которые могут вытекать из классической модели управления. но даже, если их удается контролировать, такой подход не дает возможность людям (командам) раскрыть весь свой потенциал. а команды – это ценнейший фонд компаний, которые занимаются интеллектуальными разработками.
почему не дает. А почему в футболе есть тренер, который направляет команду? Ведь там тоже это ценнейший фонд?
>это как ехать на машине на второй передаче.
ехать, конечно можно, но предел скорости весьма ощутим. плюс это неэкономно, гудит, да и другие машины обгоняют.
ну, Камазы не очень быстро ездяют, зато много возят, а вот у феррари вообще багажника нет. И что мы друг другу продемонстрировали этими примерами?
>приходите на PM-labs на наш доклад по этой теме
платное мероприятие (расчитанное на то, чтобы заработать за счет того, что у многих компаний есть бюджет обучения, который нужно куда-то девать)
2krivitsky: спасибо за коммент и приглашение. Очень хотел поучаствовать, для меня как для начинающего ПМ много интерессных тем. Понятно, что за 45 минут они не раскроются, но понятия прибавилось бы, в частности куда копать. Но к сожалению руководство отказало:(
По сути СКРАМа:
- как эта схема организации труда решает вопросы архитектуры? У кого эта роль? Кто должен ее планировать и следить за ее выдерживанием? Кто должен продумывать архитетурные требования к реализации. Это очень важно, а в презентациях по СКРАМу я этого не нашел. Теперь варианты:
а) эта роль у ProductOwnera. Сомневаюсь, что заказчику есть дело, где строки, в харкоде или в ресурсах.
б) эта роль у Scram Mastera. По теории вроде нет. У нас SM даже не работал в команде.
в) команда “самонаводящаяся”. Т.е. сама все продумает и придержится.Опять сомневаюсь. Возможно я не с теми людьми за свои 30 лет сталкиваюсь:), но суть большинства ничего не делать, ни за что не отвечать и обязательно получать при этом многА денеХ. Ну на кой им продумывать, брать на себя ответственность, потом окажется, что ошибся, окажется, то как хочешь писать нельзя)))…У нас так было: один предлагает в лоб, чтоб меньше париться, другой наоборот, чтоб два дня потерять, но потом за пол-часа долететь, остальные невнятно пытаются примкнуть к одному из. Прошу учесть психологию, хватит уже нескольких “друзей”, чтобы лобировать любые [ленивые] решения! При равности голосов разрулить некому. Даже если на митинге к чему-то пришли, туча моментов возникает по ходу работы: как этот функционал реализовывать, куда этот в проекте расположить и т.д.. Пытаемся решить командой по ходу работ: три разных мнения, форсировать некому, каждый делает по своему. Все время нужно следить: то неправильно понял, то забыл и т.д. Про кодревью в курсе, это не одно и то же, вот таких два “забыл/непонял” друг друга отревьювят будь здоров.
в) есть выделенный архитектор в команде. Это многое меняет. По сути при разговоре с заказчиком команда тогда не нужна.Она ему будет только мешать. В любом случае если он есть, то будет существенно влиять на декомпозицию фичей, требования и сроки выполнения.
У меня было такое чувство при всем этом, как-будто собрали плотника, штукатурщика, маляра, каменьщика и т.д. и дали задание без подробного плана строить дом. И на вопрос почему “поколодник не вровень со стеной”, и почему “куда-то исчезают маляры и штукатуры” (http://newradio.by.ru/new_page_5.htm) ответить некому, т.е.есть – всей команде. А всех не уволят, так что и фиг с ним.
Возможно мой комментарий будет не уместен среди профессиональных PM. Поэтому выражаю только свое мнение как разработчик.
Я считаю что надо спуститься на уровень мотиваций участников процесса и проанализировать.
В команде не бывает только одни профессионалы, всегда есть разный уровень подготовки и опыта поэтому мотивация
для юниора как правило – увеличить свой профессиональный потенциал, что бы продать себя в дальнейшем дороже.
Опытный разработчик мотивируется в основном количеством зарплаты и спокойной атмосферой работы.
Менеджер проекта мотивируется количеством успешных проектов и также для того чтобы продать себя подороже.
Фирма а точнее руководство вероятней всего мотивируется уровнем доходности своего бизнеса.
Еще надо добавить заказчика – желание получить качественный продукт за меньшее время и за минимальные затраты.
Первый жесткий сценарий. Цена и время проекта утверждены и не пересматриваются (в разумных пределах).
Это идет в разрез с мотивацией команды разработчиков – обычно вешают ярлык “лень и не профессионализм”.
В таком сценарии менеджер проекта не может себе позволить быть либералом, он будет крайне напрягать команду для достижения своей мотивации.
Если команду формируют под проект то вероятнее всего будет проблема и обсуждаемая методология не поможет.
Если команда слажена и возможности всех учтены изначально – SCRUM удовлетворит мотивацию нижнего звена но не удовлетворит амбиции PM – он лишний.
Идельная среда для SCRUM – это STARTUP!
В этом случае все увлечены конечным продуктом с коммунистическим лозунгом – от каждого по способностям – каждому по потребностям.
Если предположить сценарий продажи конечного продукта какому нибудь гиганту IT – то любые расходы времени и средств даже оправданы, так как любая фитча только добавит очередной плюс умноженный на 100.
SCRUM подобные методологии уж больно демократичные в системе виников и шпунтиков, когда разработку сопоставляют с постройкой автомобиля, где 80% это дело техники, а 20% подготовка проекта.
В IT индустрии все наоборот – ценится знание и опыт, что доказывает высокие зарплаты.
SCRUM ближе к человеку, RUP к бизнесу.
2Алексей.com:
- по поводу мотиваций. Тут тема для диссертаций психологов. Встречал людей сидящих за копейки, но в спокойной обстановке и полностью располагая своим временем годами… Встречал других, прыгающих по работам, только где больше заплатят… Работал на фирму, слова директора которой запомнились: “Не надо нам автоматизация производства, вот девочка в бухгалтерии получает 100 банкнот – пусть работает, а то нажмет кнопку и гулять будет”…Встречал также тех, кто по трупам пройдет ради карьеры… А есть еще липовые заказы для отмыва бабулек, и там мотивация заказчика и исполнителя совсем не в качестве, дешевизне и своевременности продукта…)
- по существу СКРАМА. Мне все больше кажется, что эта форма срабатывает в командах имеющих сильного неформального лидера(ов). Дочитываю книгу Фредерика Брукса “Мифический человекомесяц”, полностью с ним согласен, что проектированием и архитектурой должно заниматься очень ограниченное количество профессионалов. И что вообще ней нужно целенаправленно заниматься. Почему-то не все у нас архитекторы зданий, режиссеры и выдающиеся менеджеры. А СКРАМ говорит, что все. Так не бывает. Поэтому СКРАМ и срабатывает там, где команде просто по зубам решить задачу в лоб, сама задача вполне тривиальна, очень ограничена по объему, времени разработки, расширению и поддержке.
Коллеги, простите за дурацкий вопрос. Посоветуйте, где бы заполучить (скачать, или торрент) книги Mike Cohn особенно интересует “User Stories Applied”. Третий день ищу – и увы
Заранее признателен!
Книга на avaxhome.ws есть
Сергей, спасибо за совет. Там их уже нету, но я нашел через http://www.monova.org/details/919616/Agile%20collection.html и так далее.