×Закрыть

Гибкий подход разработки ПО — Scrum

И как всё это касается меня — разработчика?

Вам нравится разрабатывать фичи, которые никто не будет использовать?

Вам нравится работать по проектному плану, в который вы не верили с самого начала?

Вам нравится кодировать архитектуру, которую кто-то продумал до вас, и в которой вы видите множество недостатков?

Вам нравится работать в группе людей, где вы чувствуете себя одиночкой?

Я пишу это для тех, кто отрицательно ответил на перечисленные вопросы.

В Рунете вы можете найти множество статей и обзоров гибкой разработки, в частности 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

70 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Сергей, спасибо за совет. Там их уже нету, но я нашел через http://www.monova.org/details/... и так далее.

Коллеги, простите за дурацкий вопрос. Посоветуйте, где бы заполучить (скачать, или торрент) книги Mike Cohn особенно интересует «User Stories Applied». Третий день ищу — и увы: (Заранее признателен!

2Алексей.com: — по поводу мотиваций. Тут тема для диссертаций психологов. Встречал людей сидящих за копейки, но в спокойной обстановке и полностью располагая своим временем годами... Встречал других, прыгающих по работам, только где больше заплатят... Работал на фирму, слова директора которой запомнились: «Не надо нам автоматизация производства, вот девочка в бухгалтерии получает 100 банкнот — пусть работает, а то нажмет кнопку и гулять будет»...Встречал также тех, кто по трупам пройдет ради карьеры... А есть еще липовые заказы для отмыва бабулек, и там мотивация заказчика и исполнителя совсем не в качестве, дешевизне и своевременности продукта...) — по существу СКРАМА. Мне все больше кажется, что эта форма срабатывает в командах имеющих сильного неформального лидера (ов). Дочитываю книгу Фредерика Брукса «Мифический человекомесяц», полностью с ним согласен, что проектированием и архитектурой должно заниматься очень ограниченное количество профессионалов. И что вообще ней нужно целенаправленно заниматься. Почему-то не все у нас архитекторы зданий, режиссеры и выдающиеся менеджеры. А СКРАМ говорит, что все. Так не бывает. Поэтому СКРАМ и срабатывает там, где команде просто по зубам решить задачу в лоб, сама задача вполне тривиальна, очень ограничена по объему, времени разработки, расширению и поддержке.

Возможно мой комментарий будет не уместен среди профессиональных PM. Поэтому выражаю только свое мнение как разработчик.Я считаю что надо спуститься на уровень мотиваций участников процесса и проанализировать. В команде не бывает только одни профессионалы, всегда есть разный уровень подготовки и опыта поэтому мотивация для юниора как правило — увеличить свой профессиональный потенциал, что бы продать себя в дальнейшем дороже.Опытный разработчик мотивируется в основном количеством зарплаты и спокойной атмосферой работы.Менеджер проекта мотивируется количеством успешных проектов и также для того чтобы продать себя подороже.Фирма, а точнее руководство вероятней всего мотивируется уровнем доходности своего бизнеса.Еще надо добавить заказчика — желание получить качественный продукт за меньшее время и за минимальные затраты.Первый жесткий сценарий. Цена и время проекта утверждены и не пересматриваются (в разумных пределах).Это идет в разрез с мотивацией команды разработчиков — обычно вешают ярлык «лень и не профессионализм».В таком сценарии менеджер проекта не может себе позволить быть либералом, он будет крайне напрягать команду для достижения своей мотивации.Если команду формируют под проект то вероятнее всего будет проблема и обсуждаемая методология не поможет.Если команда слажена и возможности всех учтены изначально — SCRUM удовлетворит мотивацию нижнего звена, но не удовлетворит амбиции PM — он лишний.Идельная среда для SCRUM — это STARTUP! В этом случае все увлечены конечным продуктом с коммунистическим лозунгом — от каждого по способностям — каждому по потребностям.Если предположить сценарий продажи конечного продукта какому нибудь гиганту IT — то любые расходы времени и средств даже оправданы, так как любая фитча только добавит очередной плюс умноженный на 100.SCRUM подобные методологии уж больно демократичные в системе виников и шпунтиков, когда разработку сопоставляют с постройкой автомобиля, где 80% это дело техники, а 20% подготовка проекта. В IT индустрии все наоборот — ценится знание и опыт, что доказывает высокие зарплаты. SCRUM ближе к человеку, RUP к бизнесу.

2krivitsky: спасибо за коммент и приглашение. Очень хотел поучаствовать, для меня как для начинающего ПМ много интерессных тем. Понятно, что за 45 минут они не раскроются, но понятия прибавилось бы, в частности куда копать. Но к сожалению руководство отказало: (По сути СКРАМа: — как эта схема организации труда решает вопросы архитектуры? У кого эта роль? Кто должен ее планировать и следить за ее выдерживанием? Кто должен продумывать архитетурные требования к реализации. Это очень важно, а в презентациях по СКРАМу я этого не нашел. Теперь варианты: а) эта роль у ProductOwnera. Сомневаюсь, что заказчику есть дело, где строки, в харкоде или в ресурсах.б) эта роль у Scram Mastera. По теории вроде нет. У нас SM даже не работал в команде.в) команда «самонаводящаяся». Т.е. сама все продумает и придержится.Опять сомневаюсь. Возможно я не с теми людьми за свои 30 лет сталкиваюсь:), но суть большинства ничего не делать, ни за что не отвечать и обязательно получать при этом многА денеХ. Ну на кой им продумывать, брать на себя ответственность, потом окажется, что ошибся, окажется, то как хочешь писать нельзя:)...У нас так было: один предлагает в лоб, чтоб меньше париться, другой наоборот, чтоб два дня потерять, но потом за пол-часа долететь, остальные невнятно пытаются примкнуть к одному из. Прошу учесть психологию, хватит уже нескольких «друзей», чтобы лобировать любые [ленивые] решения! При равности голосов разрулить некому. Даже если на митинге к чему-то пришли, туча моментов возникает по ходу работы: как этот функционал реализовывать, куда этот в проекте расположить и т.д... Пытаемся решить командой по ходу работ: три разных мнения, форсировать некому, каждый делает по своему. Все время нужно следить: то неправильно понял, то забыл и т.д. Про кодревью в курсе, это не одно и то же, вот таких два «забыл/непонял» друг друга отревьювят будь здоров.в) есть выделенный архитектор в команде. Это многое меняет. По сути при разговоре с заказчиком команда тогда не нужна.Она ему будет только мешать. В любом случае если он есть, то будет существенно влиять на декомпозицию фичей, требования и сроки выполнения.У меня было такое чувство при всем этом, как-будто собрали плотника, штукатурщика, маляра, каменьщика и т.д. и дали задание без подробного плана строить дом. И на вопрос почему «поколодник не вровень со стеной», и почему «куда-то исчезают маляры и штукатуры» (http://newradio.by.ru/new_page...) ответить некому, т.е.есть — всей команде. А всех не уволят, так что и фиг с ним.

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 на наш доклад по этой темеплатное мероприятие (расчитанное на то, чтобы заработать за счет того, что у многих компаний есть бюджет обучения, который нужно куда-то девать)

Я видел команды, которые ВО ВРЕМЯ проекта наполнялись идеями, видением и мотивацией. И именно благодаря той командной алхимиии, которую предлагаю скрам. Желаю всем когда-нибуть это испытать.Я видел команды, которые говорили «у нас не работает Скрам». Но на деле скрамом там не пахло. Мне понадобилось 3 года, чтоб понять как работает Скрам и почему он такой какой он есть. В течение этих трех лет я делал многое неправильно. Учусь до сих пор, но успех таких команд и проектов как iDOM доказывает мне, что я на правильном пути.Желаю Александру, его проекту и команде успехов. Буду рад уделить его проекту пару часов личного времени.Удач!

2krivitskyпіар скрума заради еджайла.Скрум еджайл і тому подібні штучки кльові, коли збурається кучка народу, які мають в голові ідею, а потім пробують її імплементитиа це буває дуже рідко.Насправді набагато ліпше, коли є специфікація на продукт, а далі — розбиваєм слона на кусочки і ковтаєм.п.с.олександр якраз взявся «виводити титаніка» з крутого піке скрума

Привет, Александр.Классика руководства проектом конечно работает, если руководитель обладает умениями, навыками и талантами. Дело лишь в том, что такой подход может вести к следующим проблемам управления: 1. выращивание узкоспециализированных специалистов (это происходит постепенно, когда PM оптимизирует раздачу задач, так чтоб росла локальная продуктивность: люди делают схожие задачи тем, которые они делали раньше); 2. это в свою очередь приводит к мышлению в рабочей группе типа «я свое сделал...», это не командна, со всеми вытекающими; 3. у PM-a растет число задач по микроменедженту своей группы, так как он является единственным человеком, который видит «всю картину»; 3. подключение новых людей становится задачей PM-a, текущие работники не заинтересованы в обучении новеньких — что им с того? 4. когда в итоге новых людей подключают, у PM-а работы только прибавляется; 5. в итоге PM (а это особенные люди) занимается задачами ниже своего уровня компетенциивместо этого они могли бы заниматься: а) развитием продутка; б) формированием команды и устранением пряпятствий на её пути; в) высокоуправленческой функцией на уровне предприятия.и т.д.теперь о проблемах по задачам и прогрессу проекта: 1. так как члены рабочей группы работают над своими задача (частями функционала), размеры задач и темпы работы людей разняться, то какая-то часть фич оказывается сделана частично; 2. что такое частично сделанная работа (фича) — это вливания инвестиций, которые не вернулись; 3. эти фичи нельзя потестировать и, если их много, то проект оказывается в состоянии «мы на половине проекта» или «50% фич сделаны наполовину»; 4. это непрозрачно и рискованно для инвесторов, заказчиков, подрядчиков — всех заинтересованных сторон.это неуправляемый проект. титаник.есть ещё проблемы, которые могут вытекать из классической модели управления., но даже, если их удается контролировать, такой подход не дает возможность людям (командам) раскрыть весь свой потенциал., а команды — это ценнейший фонд компаний, которые занимаются интеллектуальными разработками.это как ехать на машине на второй передаче. ехать, конечно можно, но предел скорости весьма ощутим. плюс это неэкономно, гудит, да и другие машины обгоняют.приходите на PM-labs на наш доклад по этой теме

Опыт Скрама более полугода. Не нравится! Сегодня делаем, не продумывая завтра и особо не смотря на вчера. Завтра видим, что для следующей задачи/фичи вообще половину переписать нужно или вообще невозможно. Может это и не проблема Скрама, а отсутствие проработки архитектуры. Т.е. эта форма организации без толкового прототипирования, проджект-менеджмента, QA ничего не даст. А оставлять все на суд команды это лажа — у нас было 5 человек и у всех свое мнение по поводу решения, решали голосованием, общего видения не было ни у кого. Во время спринта за командой никто особо не следил. Результат ужасный. Люди берут себе задания, какие считают привлекательными, в результате хороший базовик написал кривое ГУИ, а ГУЕвик сделал кривую базу. Никто не запрещает тебе брать задачи, на которые ты не способен. Это мегариск. Каждый придумывает время на таск — смех, да и только, одни (кто поопытнее) ухитряются раздуть проблему и выторговать больше времени для баклуш, а кто менее опытный берет задачу на день и попадает на неделю (учитывая также то, что проектирования не было). Внутри команды полная анархия, главного нет, никтно никого не слушает, каждый делает так как считает нужным. В результате система написанная раком, лебедем и щукой.Сейчас я ПМ в этом колективе, склоняюсь к классике, сам распределяю задачи, зная способности всех. Контролирую процесс разработки, какие человек принял решения по задаче и т.д., т.е. стараюсь делать все, чтобы проект был в хоть каких-то архитектурных рамках. Но народ уже разбалован жуткой анархией, так что прийдеться попотеть.Скрам считаю высшим пилотажем в слаженной команде мегапрофессионалов. Иначе как ничего не продумывая, отдавая все команде мы можем получить качественный и своевременный результат?

Прочитал «Время переосмысления» Я думал стиль"взвейся и развейся" гигнулся вместе с Ленинским Комсомолом. Ан нет:)

Спасибо, Fox.Сравнивать как по мне, тут и правда нечего. Кто-то готов, кто-то нет. Не для всех эффективность — это цель. Да и просто не всем по стилю работать в командом режиме. Мы все разные.Для меня эффективность — это выпуск решений, решающих задачи бизнеса. При чём в короткие сроки и с таким качеством кода, за который мне никогда не будет стыдно. У кого-то могут быть другие критерии успешности. Никто не прав. Никто не неправ.В своей статье Время переосмысления я попытался более подробно раскрыть выгоды от применения Agile с точки зрения конкурентной выгоды в условиях т.н. кризиса.У кого есть уши, тот услышит.

To DmytroL: 1. Предлагаю в дискуссии в дальнейшем не ссылаться на ситуацию с проектами в нашей компании, потому что совершенно случайно я работаю в той же самой компании:), ситуацию с проектами тоже знаю, однако имею на нее взгляд с твоим не совсем совпадающий, поэтому предлагаю ограничить дискуссию о проектах в нашей компании рамками нашей компании.:)

Это не совсем тождественно fixed-all. Fixed-all — это когда клиент говорит: вот вам спека, пропишите в контракте дату и стоимость, а затем подпишитесь кровью, что вы не потратите ни цента больше, не задержите релиз ни на один день, а спека станет для вас Священным Писанием, от которого вы не отступите ни на йоту. Вот именно в таком сценарии, как я писал выше, в чистом виде Agile не работает. К тому же, fixed-all напрямую противоречит классическому «iron triangle», поэтому подобные проекты весьма часто заканчиваются «некрологом».

Владельцем iron triangle никогда не является команда разработчиков. В лучшем случае можно подсказать клиенту что то сделать. Это прерогатива клиента — маневрировать iron triangle. Спеки, сроки и прочее нарушаются почти всегда как в софтверных, так и в любых других инженерных проектах, это жизнь. Поэтому расказывать о том, что только Аджайл дает возможность гибко все это менять — это мягко говоря литературное преувеличение.

Вопрос в другом — настроен ли клиент решать проблемы конструктивно, или предпочитает обложиться со всех сторон бумажками и общаться с позиции «я начальник — ты дурак»?

— Аджайл предполагает получение у клиента в начале проекта справки об адекватности?:) Клиенты бывают очень разные и работать приходится со всеми, если конечно компания хочет остаться в бизнесе.

В Agile cost фиксируется как минимум в пределах итерации.

Вот ты идешь на рынок, покупаешь 10 мешков картошки и расчитываешь уложиться в N денег. Продавец тебе говорит — у нас фиксирована стоимость только первого мешка картошки, остальные мы Вам будем доставлять по 1 в неделю, стоимость каждого нам будет ясна в процессе с учетом рисков доставки, стоимости погрузки и т.п. Как фиксация костов для итерации помогает ответить на вопрос сколько будет стоить весь проект (хотя бы с погрешностью 20%)?

А вот если команда на ошибках не учится и все равно лажает дальше, то как минимум заказчик потеряет меньше денег, так как облажалово станет очевидным гораздо раньше.

Почему то все апологеты Аджайла уверены в готовности и желании клиента их чему то учить на себе как на подопытном кролике. Задачи клиента более просты — получить в срок то на чем он сибирается заработать деньги.

«Скрам — это вообще не методология разработки ПО. Скрам — это на самом деле инструмент для быстрого выявления слабых мест в вашей организации.»

— согласен! Внедерение Скрама в организации показывает неспособность построить нормальный рабочий процесс:) Все основные приемы менеджмента известны со времен построения первого сложного инженерного объекта в истории человечества — то есть египетских пирамид. И только ИТ с упорством, достойным лучшего применения пытается изобрести свои велосипеды. Думаю, что это потому, что ИТ -шники просто не хотят быть инженерами:), настаивая на своей особенности:) Отрасль просто росла быстрее чем это было возможно, поэтому очень много случайных людей. Вся надежда — на кризис:)

To DmytroLРассуждения столь же правильные — сколь и абстрактные. Примерно как в анекдоте про математика и воздушный шар. Где мы, кто мы, для чего мы и где Scrum? Microsoft Visual Studio — это продуктовая разработка. Хозяин барин — сколько захотел итераций, столько и сделал, сколько захотел денег вложить — столько и вложил. Перенос сроков выхода продуктов в том числе и Microsoft является скорее правилом, чем исключением.Мы (то есть 90% ИТ Украины) работаем в аутсорсинге, что на практике означает — те самые абстрактные fixed all проекты, то есть клиент знает, (или думает, что он знает) что он хочет (fixed scope), знает сколько у него есть денег (fixed cost), знает когда ему это надо (fixed terms). Случаев когда бы клиент сказал — делайте что хотите и сколько хотите (то есть проявил бы то самое доверие к команде, о котором так много говорят певцы Аджайла — я в своей практике не встречал). Чтобы хоть как то клиенту гарантировать результат — мы должны составлять план работ на весь проект, а не на одну итерацию. Методик, которые позволяли бы это делать хотя бы с гарантией больше 50% — я не знаю, тем не менее — лучше иметь самый плохой план, чем вообще никакого. Кстати, мне известны случаи аутсорсинга разработки компанией Microsoft — демократией и доверием к команде в этих случаях и не пахло, был жесткий контроль сроков и планов.Возможно, что Scrum применим к проектам у которых не fixed scope, еще лучше он применим когда cost тоже не fixed и совсем хорошо — когда не fixed вообще ничего и ничто не сдерживает творчество комнады:), однако в реальном мире аутсорсинга — такие звери встречаются редко, (думаю, что во времена кризиса так вообще не будут встречаться).

> В случае, если работа ведется в соответствии с ГОСТ (например, 24-м или 43-м) Программерский ГОСТ, естественно, 34-й. Опечатка.

> Что значит «общее время и стоимость? » > Оценить время и стоимость мы можем на первой итерации. С каждой итерацией оценка становится всё более точной. Самую точную оценку мы можем дать на предпоследней итерации.Фраза про «общее время и стоимость» тебе непонятна, и требует пояснения? Удивительное рядом. Смотри — ты заключаешь контракт на условиях fixed cost. В данном случае, от тебя требуется дать разбивку проекта на этапы, стоимости этапов, и их даты. В случае, если работа ведется в соответствии с ГОСТ (например, 24-м или 43-м) — то это вообще является частью ТЗ, и кроме того фиксируется в план-графике.Если ты сильно ошибешься в данной оценке («общего времени и стоимости») — то твой проект будет провальным. Если ты это узнаешь ближе к концу или середине, то возможности что-либо переиграть у тебя будут весьма ограничены. Если ты предложишь свои короткие итерации без долгосрочного планирования (что есть фактически повременка), то ты c высокой вероятностью проиграешь тендер конкуренту, который умеет делать fixed cost. С удовольствием послушаю, каким именно образом ты будешь планировать и выполнять проекты fixed cost следуя «agile», и каким именно «agile» из всего этого зоопарка ты будешь пользоваться, и как это будет выглядеть.Кроме того, чрезвычайно интересно — какие сроки у твоих семи проектов, и какой размер команды на каждом из этих проектов. Наверняка мелочевка какая-нибудь, которую вообще без разницы, каким процессом делать. > Насколько такая оценка менее точна, чем традиционная с использованием СОСОМОII, PERT и иже с ними — не имею ни малейшего понятия. Если у Вас есть такая информация — поделитесь. Если нет — это Ваше личное ничем не подтвердженное мнение.Пока не понятно, как ты вообще оценку делать собираешься. А что касательно методов планирвоания, основанных на корелляциях метрик времени-объема — они позволяют уложить погрешность планирования в 10% при желании.

2 Артём> Аффтор составляет планы на год вперёд с оценкой кривой риска, трудозатрат на программирование и т.п.Ага.> В этом ему помогают наукообразные методики навроде ПЕРТа и КОКОМО2.PERT помогает, еще помогает PSP/TSP, а COCOMO2 автор по ряду причин не использует.Ничего наукообразного в этих методологиях нет, все очень просто.> За наличие этих методик он хвалит себя, а всех остальных обзывает шарлатанами. Ни припомню, чтобы за наличие этих методик автор «хвалил себя». И обзывал «шарлатанами» «всех остальных».> К сожалению, аффтар не рассказывает, насколько его запланированные на год вперёд проекты превышают бюджет и сроки, несмотря на трое- и четырёхкратные буфера. «Трехкратных» и «четырехкратных» буферов не бывает — две сигмы к матожиданию уже дают тебе 98%. Учи матчасть. А запланированный на год проект при нормальном планировании, контроле, и управлении требованиями сорвать очень сложно, хотя бы потому, что роль «буфера» помимо сигм также играют «опциональные» и «желательные» требования.> Что ещё интересно, аффтар ругает Си++ за недорост до промышленных стандартов;)) У аффтора вообще хорошо получается ругать. Боб ему, как говорится, в помощь.Это ты об этом посте из RSDN.Юмор?:) http://www.rsdn.ru/Forum/? mid=...Вот, зацени, а вот тут я еще очень серьезно про системное программирование пишу.http://www.rsdn.ru/Forum/? mid=...> К сожалению, из приведённого Вами поста видно, что аффтар не ни читал Бека, ни Швейбера, и теорий с моделями за аджайлом не видит. Что говорит плохо не об аджайле, а скорее об аффтаре;)). А они есть (как суслик), и годочков им под 50.К сожалению, по какой-то непонятной причине агилистам гораздо проще обсуждать личность собеседника, чем вести разговор по существу. Видать, по существу больно тяжело разговор им дается.> Что характерно, аффтар даже на РСДН своего имени-фамилии не указал;)) Ни рода занятий. А жаль.С какой стати мне делать свои персональные данные доступными каждому придурку в сети?:) Вот ты, например, в состоянии членораздельно объяснить — они тебе зачем?:)

2 Dmitry Yeskin: > Все конторы, которые его используют — это инвестиционные пузыри. Им бабки от инвесторов льются потоком поэтому конкретных сроков на реализацию не существует.Мы не пузырь, наши клиенты на нас очень давят в плане сроков. > Разботчики не заинтересованы в досрочном выполнении задач — их цель выполнить кусочек работы выделенный для них, а дальше заниматься своими делами.У меня сейчас 7 аджайл-проектов, которые я мониторю. Описанная Вами ситуация есть только на одном, сложилась потому, что тим лидер там так настроил команду. В остальных 6-ти народ честно добирает задачи, если справились раньше. Тяжело заниматься своими делами, если каждый день у тебя спрашивают: «Что ты сделал вчера и что сделаешь сегодня? »> Общее время и стоимость проекта можно определить только постфактум либо приблизительно на предпоследней итерации.Что значит «общее время и стоимость? » Оценить время и стоимость мы можем на первой итерации. С каждой итерацией оценка становится всё более точной. Самую точную оценку мы можем дать на предпоследней итерации. Насколько такая оценка менее точна, чем традиционная с использованием СОСОМОII, PERT и иже с ними — не имею ни малейшего понятия. Если у Вас есть такая информация — поделитесь. Если нет — это Ваше личное ничем не подтвердженное мнение.

2 Андрей: Почитал пост означенного аффтара. И блог почитал. Впечатления интересные. Аффтор составляет планы на год вперёд с оценкой кривой риска, трудозатрат на программирование и т.п. В этом ему помогают наукообразные методики навроде ПЕРТа и КОКОМО2. За наличие этих методик он хвалит себя, а всех остальных обзывает шарлатанами. К сожалению, аффтар не рассказывает, насколько его запланированные на год вперёд проекты превышают бюджет и сроки, несмотря на трое- и четырёхкратные буфера. Что ещё интересно, аффтар ругает Си++ за недорост до промышленных стандартов;)) У аффтора вообще хорошо получается ругать. Боб ему, как говорится, в помощь. К сожалению, из приведённого Вами поста видно, что аффтар не ни читал Бека, ни Швейбера, и теорий с моделями за аджайлом не видит. Что говорит плохо не об аджайле, а скорее об аффтаре;)). А они есть (как суслик), и годочков им под 50. Что характерно, аффтар даже на РСДН своего имени-фамилии не указал;)) Ни рода занятий. А жаль.

господа, я вас прошу. не пишите о том, в чём вы не разбираетесь. не портьте себе карму. она ещё вам пригодиться.мыльные пузыри были, есть и будут есть. и не важно каким подходом они управляются. суть от этого не меняется.agile — это не методология, как указано в грубой статье, на которую сослался Андрей. это всего лишь набор принципов, которые помогают ряду людей работать более эффективно. не более. к примеру: < ul> < li> Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. </li>< li> Business people and developers must work together daily throughout the project. </li>< li> Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. </li>< li> Working software is the primary measure of progress. </li></ul> и так далее... ни слова про пузыри, заметьте. если вы нашли нечто, что работает лучше в вашей ситуации — это просто отлично! делитесь опытом, пишите книги, проводите конференции и тренинги. я лично приду.на то вы и профессионалы, чтоб искать решения проблем. я ищу решения в поле agile и пока нахожу. перестану находить, стану искать подсказки в других источниках.каждому проекту своя методология — об этом написал ещё в начале нашего века один популярный автор. экспериментируйте! удач!

Все конторы, которые его используют — это инвестиционные пузыри. Мы не пузырь, пузырь не мы. Заказная разработка, финансовые и учетные системы.

Мое мнение, что Скрам — это все-таки мура.Все конторы, которые его используют — это инвестиционные пузыри. Им бабки от инвесторов льются потоком поэтому конкретных сроков на реализацию не существует.Разботчики не заинтересованы в досрочном выполнении задач — их цель выполнить кусочек работы выделенный для них, а дальше заниматься своими делами. Общее время и стоимость проекта можно определить только постфактум либо приблизительно на предпоследней итерации.Честно говоря — это просто всего-лишь еще один способ выкачивать деньги через никому не нужные сертификации и семинары.

http://gaperton.livejournal.co... — случайно набрел на эту заметку в блоге. Понятия не имею о том, кто этот парень, но он написал именно то, что я думаю об Agile и прочих «процессах» разработки. 5 баллов!!!

2 Вадим

1. давайте на примере.

вы неправильно поняли «мою логику». дома сторятся именно чтобы удовлетворить все интересы: если бы это было не интересно инвестору, он бы не инвестировал, не интересно подрядчику — не брался бы за подряд, бригаде — не работали бы, жильцам — не покупали бы. если хоть где-то в этой цепи пропадает интерес, то проект просто закроют. если на примере, предположим, что рядом со стройкой начал быть природный источник аммиака. проект завершить в срок и бюджет можно, но жильцам уже не интересно. вопрос — будет ли продолжен проект? так что без удовлетворения интересов никак.

В проектном менеджменте есть понятие Project Objectives. В которые входят те цели, по достижению которых проект считается завершенным.

завершённым, но не успешным., а толку?

2. Что касается быстрого устаревания требований, тут я с вами согласен, это проблема, но решение ее есть в любом худо-бедно поставленном процессе, будь то RUP, Scrum или что другое, называется это Integrated Change Control.

есть, но решается «худо-бедно», а гибкие методологии «заточены» под это. по крайней мере это декларирут:)

3. Scrum безусловно очень легко отвечает на вопрос «к какой дате будет готов этот функционал» и «какой функционал будет готов к такой-то дате» в рамках одного спринта, но не более.

ничего подобного. как раз в рамках одного спринта он ничего не гарантирует, а вот что будет в конце 5го, 10го или 20го спринта — говорит. повторюсь: с той же точностью, что и другии методологии.

P.S. мы говорим об одном и том же Строительные компании разгребают PMP именно потому, что текущие руководители сейчас не квалифицированы.

нет. я говорю о том, что несмотря на то, что там работает куча PMI-сертифицированных менеджеров, дома в срок не сдаются.это всё не аргументы противза Scrum. там совсем другие проблемы... основная — как получить «self-organized motivated cross-functional team». А если получили, то возникает вопрос «нафига скрамрупмсф? » такая команда любой проект сделает без всякой методологии

Сотона, 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 Вадим (№ 48)

Если же речь идет о ПРОЕКТНОМ менеджменте, то во главу ставятся в первую очередь интересы ПРОЕКТА. Которые, как мы с вами знаем, заключаются в том, чтобы быть успешно сданным в СРОК и в БЮДЖЕТ, с необходимым уровнем КАЧЕСТВА и при условии наличия ряда РИСКОВ.

я, как МП, не очень понимаю что такое «интересы проекта». проект есть ровно до тех пор, пока он удовлетворяет нужды стейкхолдеров — так вот если у проекта и есть интерес, так он в том, чтобы УДОВЛЕТВОРИТЬ НУЖДЫ СТЕЙКХОЛДЕРОВ. Да — в частном случае — это может быть «уложиться в срок и бюджет», но далеко не всегда. Есть ещё такие интересы как «заработать на разработке», «сделать нужный продукт» — если вы уложились в сроки и бюджет, но сделали никому не нужную фигню, то у меня назвать жто «успехом» язык не повернётся.основная проблема разработки сейчас в том, что между фиксацией требований и их реализацией проходит время, за которое требования устаревают. Я подчеркнул основная и сейчас потому, что основная масса разработок сейчас делаются для опережения конкурентов, которые тоже не стоят на месте, поэтому требования меняются очень часто. это касается не только интернет-сайтов:) ну и кстати, Scrum очень легко отвечает на вопрос «к какой дате будет готов этот функционал» и «какой функционал будет готов к такой-то дате». И ошибается примерно на столько же как и RUP, PMBOK и Павел Глоба:)

Ваш пример со строительством прекрасное тому подтверждение, я тоже не видел ни одного здания, построенного в срок. Уверен, причина в том, что менеджеры проектов не читали PMBOK, а зря — хорошая книга.

между прочим строительные компании разгребают PMI-сертифицированных менеджеров, так что читали.

To АртёмСкрам — отстойный процесс — я не говорил, что отстойный. Я говорил, что в нем нет ничего нового. Еще я говорил, что вся шумиха, которая он вокруг него поднята, создает как у клиента, так и у тех, кто на него молится — ложное ощущение решение проблемы. Я с Вами полностью согласен. Расскажите, пожалуйста, с помощью каких средств и процедур Вы в своей команде 2) делегируете разработчикам ответственность; 3) поощряете инициативу; 5) организуете «нормальные рабочие отношения» (а что значит нормальные, кстати?); 6) стимулируете их расти и учиться.Понимаете, я занимаюсь менеджментом уже более 11 лет. Люди всегда были самой интересной частью процесса разработки для меня, мне всегда было интересно изучать мотивы, которые ими движут. Люди до сих пор продолжают меня удивлять:). А процедур я Вам описать не могу — я противник процедур. Даже сама лучшая процедура не в состоянии предусмотреть всего что подкидывает реальная жизнь. Поэтому хороший менеджер — это творец. А плохому — процедуры служат только отмазкой в случае провала.Вы считаете, что «гибкость» обеспечивается только длиной итерации. — Это Вы за меня додумали, где я такое сказал, что «только длинной итерации»? Не знаю воспримите Вы это как возражение или нет -, но гибкость, на мой взгляд, обеспечивается прежде всего «качеством» вашей команды, а «качество команды» — это и есть человеческий фактор. У Вас может быть команда настроенная на победу (и тогда она сама включит в процесс по ходу проекта все нужные для успеха «процедуры» и даже придумает некоторые из них на ходу, а может быть команда настроенная на соблюдение процесса ( «процедур» ) -, а если процесс не подходит к данному конкретному случаю — то тем хуже для клиента. На фреймворке уже сделано несколько проектов. Определите критерии успешности — и давайте поговорим. — да вот Вадим Вам привел все критерии успешности — срок, бюджет и качество. Какие еще могут быть критерии? Спасибо за пример, интересно. А что мешает клиенту сейчас пустить систему в продакшн? Не все истории реализованы, или система нестабильна? Или вообще сделали не то, что хотелось? И система нестабильна — потому что меняли постоянно, и реализовано не все. Но главная проблема в том, что время упущено. 6−8 месяцев назад они были бы одними из первых в некоем сегменте рынка, а теперь там уже полно других людей. Потому и инвесторы разбежались.Спасибо, читал. Хорошая книга. Хотя лично как по мне, этому набору best practises не хватает системы, которая бы объясняля «почему именно так». — Почему наезды? Откуда я знаю читали Вы этот труд или нет? Системы нет — потому что ее в принципе не существует. Все люди разные. Когда мне нужно, условно говоря, мотивировать вкалывать одного человека — я применяю один прием, другого — другой. Я иногда сам не знаю, как я буду работать с конкретным человеком, пока не изучу его как следует. Спорим о терминах. Неинтересно. — Ну Вы же сами написали эту фразу «кодить без архитектуры». Потрудитесь тогда объяснить, что Вы имели в виду.Никогда такого не видел. Не знаю, как у Вас, а у нас аккаунт-менеджер и проджект менеджер — совсем разные люди. ПМ НИКОГДА не подписывается под контрактом. ПМ-у у нас была по барабану прибыль, ему было важно выпустить в срок, в бюджет и по спекам."К пуговицам претензии есть? — Нет":) Это плохо, что ПМ-ам прибыль по барабану. В этом одна из проблем украинского ИТ. Что Вы называете словом бюджет, кстати? Если речь идет о человеко-часах, то Вадим прав — это скорее работа координатора, чем менеджера. Настоящий менеджер влияет на прибыльность проекта для компании. Можно сделать проект более дешовыми, а можно более дорогими ресурсами. Даже если два разработчика носят титут сеньора — у них может быть разная зарплата. И так далее. А аккаунт менеджеры — даже самые лучшие, они в деталях тех. процесса разбираются слабо. Хороший ПМ очень много чего может им подсказать насчет того, что еще можно предложить клиенту чтобы с него денег получить побольше. А еще хороший ПМ способен помочь сейлзам на этапе переговоров с клиентом обосновать и отстоять эстимейт.Когда человек начинает мыслить категориями денег и прибыли — он сразу понимает, как на самом деле неважно, как именно называется процесс разработки, который он использует:)

To Андрей #49Я решил отделить мух от котлет. Вот что мы обсуждаем. Скрам — отстойный процесс

Я на первое место ставлю человеческий фактор и именно его считаю главным для успеха проекта. Чтобы работать с этим фактором — мне Скрам не нужен сейчас и 10 лет назад не был нужен.«

Я с Вами полностью согласен. Расскажите, пожалуйста, с помощью каких средств и процедур Вы в своей команде 2) делегируете разработчикам ответственность; 3) поощряете инициативу; 5) организуете «нормальные рабочие отношения» (а что значит нормальные, кстати?); 6) стимулируете их расти и учиться.

Подробно разобраться во всех деталях до начала разработки — это водопадная модель. РУП — так же как и MSF и много чего еще — процессы итеративные

«Все итеративные процессы разработки задумывались именно для того, чтобы дать возможность менять требования по ходу разработки».

Вы считаете, что «гибкость» обеспечивается только длиной итерации. Я, со своей стороны, считаю, что гибкость обеспечивается не только длинной итерации, но и «идеологией». В МСФ и РУП идеология «процедур» (бюрократия). Это противоречит быстрой реакции на изменения. В Скраме идеология «предпринимательства» — это способствует реакции на изменения. Именно это я имел в виду. Возразите что-нибудь на это? Скрам не ведёт к успеху.

«Про результаты — давайте поговорим с Вами когда Вы сдадите свой проект»

На фреймворке уже сделано несколько проектов. Определите критерии успешности — и давайте поговорим.

Я сейчас имею перед глазами только несколько неудачных примеров применения Скрама на проектах — не моих, я сторонний наблюдатель

Спасибо за пример, интересно. А что мешает клиенту сейчас пустить систему в продакшн? Не все истории реализованы, или система нестабильна? Или вообще сделали не то, что хотелось? Всяко-разно (наезды)

«Прочтите Марко и Листера «Человеческий фактор»

Спасибо, читал. Хорошая книга. Хотя лично как по мне, этому набору best practises не хватает системы, которая бы объясняля «почему именно так».

«„Как можно кодить без архитектуры“ — да никак нельзя».

Спорим о терминах. Неинтересно.

«у ПМ-а, как человека отвечающего за реализацию интересов конторы на проекте — интерес в том, чтобы заработать прибыль.»

Никогда такого не видел. Не знаю, как у Вас, а у нас аккаунт-менеджер и проджект менеджер — совсем разные люди. ПМ НИКОГДА не подписывается под контрактом. ПМ-у у нас была по барабану прибыль, ему было важно выпустить в срок, в бюджет и по спекам.

Вадим, проще значит лучше. Потому что KISS. Потому что затрат меньше. Потому что более простая работа может выполняться менее квалифицированным ресурсом, а значит риски ниже и затраты опять же меньше. Сомневаюсь, что менеджеры не читали PMBOK. Думаю это первая книга, коотрую читает любой менеджер по проектам. Постарайся аргументировать свои мысли, а не излагать их в виде саомочевидных фактов.

To Артём говорит: 26.09.2008 в 09: 40 Для начала ремарка — я отношусь к RUP ничуть не лучше чем к Скраму и точно также не считаю его панацеей. Если Вам для того чтобы 1. наладить коммуникации в команде 2. научиться делегировать ответственность разработчикам 3. поощрять инициативу 4. понимать что любая архитектура будет неоднократно переделана в ходе проекта и Вы должны обеспечивать легкость этой самой переделки в процессе разработки постоянно и наконец 5. просто организовать нормальные рабочие отношения в коллективе — необходимо назвать все это каким то словом (Скрам, например:)), а еще прочесть об этом слове в какой то книжке — тогда я Вас отлично понимаю, безусловно в таком случае Скрам для Вас — есть нечто принципиально новое. Если Вы прочтете мои реплики в начале этой дискуссии — то я там писал, что я на первое место ставлю человеческий фактор и именно его считаю главным для успеха проекта. Чтобы работать с этим фактором — мне Скрам не нужен сейчас и 10 лет назад не был нужен. Прочтите на этом сайте интервью с Игорем Ашмановым — ему Скрам тоже не нужен. Прочтите Марко и Листера «Человеческий фактор» — там тоже нет ни слова про Скрам, но зато всячески подчеркивается что при любом процессе разработки — люди играют решающую роль.«С моей точки зрения, РУП мешают быть столь же гибким подход, который он использует. «Чтобы начать разрабатывать, нужно сначала подробно-подробно во всём разобраться и донести это до всех», внимание к деталям. Поправьте меня, если я ошибаюсь. С другой стороны, я знаю, что есть Agile RUP (OpenUP), например в Инфопульсе. " — подробно разобраться во всех деталях до начала разработки — это водопадная модель. РУП — так же как и MSF и много чего еще — процессы итеративные, а размер итерации — Ваше личное дело, хоть ежедневными их делайте."Я чувствую как мне все время что то мешает разделить с Вами оптимизм по поводу Скрама«Возможно, Вам мешает разделить наш оптимизм страх: как можно отдать власть девелоперам? Как можно позволить заказчику менять требования по ходу разработки? Как можно кодить без архитектуры? Я разделял Ваши опасения, именно поэтому мы пытались убедить CTO не переходить на Скрам почти два месяца. Однако перешли, и результатами я доволен. «Власть девелоперам» — это несерьезно. Так же как и власть тестерам или архитекторам или уборщицам. Я никогда не называю сроков не поговорив с девелоперами — иначе у меня не будет морального права с них спрашивать. Но назвав срок клиенту — за него отвечаю перед клиентом я, а не команда. Коллективная отвественность — это безответственность. В конце концов от имени конторы подпись под контрактом ставит конкретный человек, а не команда девелоперов. Тем более, что у девелопера интерес в разработке авторский (отсылка к интервью Ашманова), а у конторы — и в частности у ПМ-а, как человека отвечающего за реализацию интересов конторы на проекте — интерес в том, чтобы заработать прибыль. «Менять требования по ходу разработки» — такое ощущение, что апологеты каждой новой технологии начинают с того, что думают, что до них было пустое место. Все итеративные процессы разработки задумывались именно для того, чтобы дать возможность менять требования по ходу разработки. Скрам тут далеко не пионер."Как можно кодить без архитектуры" — да никак нельзя:). В каждом конкретном случае Вы все-таки будете какую то архитектуру реализовывать. Другое дело что Вам с большой вероятностью придется ее переделать и не раз. Для этого Вы должны с самого начала проектировать так, чтобы такое изменение стоило минимум усилий. Но это не значит что Вы кодите без архитектуры. Даже Скрам Вам этого не позволит:) Про результаты — давайте поговорим с Вами когда Вы сдадите свой проект. Я сейчас имею перед глазами только несколько неудачных примеров применения Скрама на проектах — не моих, я сторонний наблюдатель, который может себе позволить бесплатно учиться и делать выводы:). Как пример, — один из проектов длился больше полутора лет. В начале клиент получал кайф от процесса скрам митингов и от того количества идей которые ему генерировали девелоперы для его продукта:). Где то через год он, однако, начал нервничать и говорить: когда же наконец Вы закончите переделывать и я смогу выставить систему в продакшн? Ему расказывали, что в этом суть Скрама, что зато мы гибко реагируем на все его фантазии и даже придумываем свои, напоминать что ему же это нравилось:). Мне кажется что теперь, он был бы совсем не против, если бы на каком то этапе ему бы жестко зафиксировали требования и сроки разработки — чтобы он получил что то с чем можно было бы выйти к инвесторам. Но поезд уже ушел — вместе с актуальностью его продукта и его инвесторами.

Артем, вы совершенно правы, скрам это прекрасно как для менеджера, так и для команды! А какой-нибудь подход в духе «делаю что захочу» — еще лучше, не так ли? Если у заказчика много денег и он никуда не торопится, то и такой «процесс» даст результат, почему нет? Если же речь идет о ПРОЕКТНОМ менеджменте, то во главу ставятся в первую очередь интересы ПРОЕКТА. Которые, как мы с вами знаем, заключаются в том, чтобы быть успешно сданным в СРОК и в БЮДЖЕТ, с необходимым уровнем КАЧЕСТВА и при условии наличия ряда РИСКОВ. Скрам никогда не удовлетворит этот интерес, у него просто нет для этого возможностей. Это очень важно понимать, вполне возможно что вы не сталкивались с такими проектами, потому что, к сожалению, 99% наших компаний работают по простой схеме «перепродай программиста на запад». В этих случаях менеджер проекта бесконечно далек от менеджмента проекта, он скорее координатор, а чаще просто роутер коммуникаций между заказчиком и командой.Не смотрите на текущую ситуацию на рынке, говоря «скрам работает», она временная. Это то же самое что сигареты тележкой в Польшу возить, вместо того чтобы наладить производство и экспорт. Не ищите легких путей, в случае проектного менеджмента «проще» не значит «лучше». Ваш пример со строительством прекрасное тому подтверждение, я тоже не видел ни одного здания, построенного в срок. Уверен, причина в том, что менеджеры проектов не читали PMBOK, а зря — хорошая книга.:)

To Андрей #45: Я попробую ответить на вопрос: «Господа, может ли кто-то из Вас четко объяснить мне, что такого может делать Скрам, чего нельзя было делать в рамках других подходов к организации процесса девелопмента? » С РУП знаком скорее теоретически, т.к. мы по нему не работали, но зато видел, как он работает в другой компании. Два слова о себе: я был проджект-менеджером команд с хорошо налаженным MSF. Сейчас переходим на Скрам (одна из команд уже перешла), разница и достоинства очевидны. 1) Скрам создаёт среду, которую НИКОГДА не содаст РУП. Особенности: а) очень-очень свободные комуникации. Все общаются непосредственно со всеми, т.к. для этого специально создаются каналы, процедуры и за этим следит специально обученный человек. В РУПе это делается с помощью бумажек-артефактов, что менее эффективно, более долго и вообще суть мусор (muda); б) делегирование ответственности вниз к девелоперам. В РУП опять-таки такого нету, вместо этого есть очень-очень подробно прописанные процедуры кто что делает и в какой последовательности; из чего следует в) на любое изменение в ходе проекта реакция в Скраме будет намного лучше, чем в РУПе, в плане: народ быстрее разберётся и прийдёт к согласию, и количество бумажек-артефактов, которые нужно будет переписывать, будет существенно меньше; и г) команда разработчиков в Скраме растет несравненно быстрее, чем в РУПе. Потоу что б), потому что поощряется инициатива и самостоятельное решение проблем. и наконец д) работать в Скрам-команде намного более приятно, чем в МСФ. Отношения теплее, а давления сверху и поисков виноватых намного меньше. При этом все в команде работают намного напряженнее (!), чем до этого по МСФ. Итого, с моей точки зрения, принципиальное различие: Скрам позволяет быстро и эффективно реагировать на изменения, чего не делает РУП. РУП пытается бороться с изменениями окрущающей среды с помощью контрактов и хорошо отлаженных процедур. Скрам пытается адаптироваться под любое изменение. «Что мешает РУП быть столь же гибким? ».С моей точки зрения, РУП мешают быть столь же гибким подход, который он использует. «Чтобы начать разрабатывать, нужно сначала подробно-подробно во всём разобраться и донести это до всех», внимание к деталям. Поправьте меня, если я ошибаюсь. С другой стороны, я знаю, что есть Agile RUP (OpenUP), например в Инфопульсе. "Я чувствую как мне все время что то мешает разделить с Вами оптимизм по поводу Скрама«Возможно, Вам мешает разделить наш оптимизм страх: как можно отдать власть девелоперам? Как можно позволить заказчику менять требования по ходу разработки? Как можно кодить без архитектуры? Я разделял Ваши опасения, именно поэтому мы пытались убедить CTO не переходить на Скрам почти два месяца. Однако перешли, и результатами я доволен. To Eugen_n #28: Я искренне удивлён тем, что Вы говорите. У нас дома строятся ДО получения полного комплекта документации (сам видел). Кроме того, НИ ОДИН проект по постройке домов не был сдан в сроки и не уложился в бюджет. ЭТО вы называете успешным управлением проектов? #26: Я общаюсь с достаточно широким кругом бизнесменов (мелкий и средний бизнес), и всегда интересуюсь как у них поставлено производство и управление. Так вот, из того, что я видел, в программировании — самые продвинутые подходы в управлении и отладке производственных процессов. Остальные отрасли даже рядом не валялись (кроме очень редких исключений, которые внедрили чистый LEAN, LEAN в модификации Голдратта, системы «Результат» или любой другой).

To Алексей, Mykola и прочие апологеты ScrumК полному своему неудовольствию, я чувствую как мне все время что то мешает разделить с Вами оптимизм по поводу Скрама. Делаю последнюю попытку не отстать от мейнстрима:). Господа, может ли кто-то из Вас четко объяснить мне, что такого может делать Скрам, чего нельзя было делать в рамках других подходов к организации процесса девелопмента? Ну хотя бы в рамках RUP. Кто мешает в рамках RUP быть столь же гибким? Например, сделать итерации по 2 недели продолжительностью, (да хоть по 2 дня) после каждой итерации выдавать клиенту билд для просмотра (назовите это словом «демо» ) и так далее?

разработки системы автоматизации деятельности маркетинговых и рекламных отделов и агенств.

Т.е. старые добрые оболочки для БД на этот раз в веб-исполнении:)

to #35, 36Вы пишите в ветке в которой обсуждается нужность и полезность процесса Скрам для разработки ПО. Вроде бы как Вы выступили моим оппонентом — хотя из Ваших постов очень трудно понять против чего конкретно Вы выступаете.:) Я сделал, как мне кажется вполне допустимое (исходя из темы дискуссии) предположение о том, что Вы мне приводите пример разработки (то есть поиск багов в опен-соурсе библиотеки) как нечто, что сравнимо по своей сложности с задачами, который решает менеджмент компании Тойота и для которых нам нужны новаторские подходы в управлении проектами. Если я неправ — то для чего Вы вообще все это тут написали и что Вы хотели сказать? Про мой типаж Вам рассуждать, по моему, все-таки не стоит. Вы делаете скоропалительные выводы:)

Mykola GurovА чем Вы занимаетесь любезнеший? Андрей озвучил две достаточно интересные темы работы. А у Вас? Мне послышалось HTML? PS Во избежание недоразумений. Моя область — системное программирование и эмбед.Зачастую на принципиально новом железе, обязательно 24*7.Колдовством свою работу не считаю — обычная инженерия, не хуже и не лучше других.

to #32так вот что такое по настоящему креативная программистская работа — поиск багов в опен-соурсе библиотеке:) Одни пишут библиотеки, другие ищут в них баги, потом те искал пишут свои библиотеки, и новые программисты ищут в них новые баги. В мире сотни кем то написанных библиотек и компонентов. Завтра новые программисты вооружившись новой модной «технологией» менеджемента пришедшей на смену Скрам напишут еще более новые библиотеки и компоненты (решающие те же самые задачи) и содержащие новые баги. За занятость программистов можно не беспокоиться. Только чем это круче сайтоклепательства мне — непонятно.:)

Mykola Gurov говорит: «более менее серьезная разработка ПО (т.е. не „сайт“ за 15 минут) — это создание нового продукта, а не конвейерный процесс» и много Вы знаете таких по настоящему новых продуктов? Новые продукты требуют неких специальных знаний. Типичный програмист на Украине кладет контролы на форму и связывает их с базой данных, при этом уверен в том, что занимается очень интеллектуальной работой. Я что то не слышал про разработку здесь компиляторов, баз данных и т.п. Я как то собеседовал людей для проекта сервера по передаче потокового видео — я не смог собрать в Харькове команду, которая смога бы его сделать, может быть я плохо искал? Про менеджмент тойоты я читал, история интересная, только они начинали с элементарного наведения у себя порядка, а не сразу с тех вершин на которых они сейчас находятся. нам бы сейчас просто от кустарной мастерской перейти хотя бы к плохонькому заводику, а Вы сразу тойоту собиратесь строить.

Ага, у нас сплошное создание атомных бомб, трансатлантических лайнеров и новаторских ОС:) Господа! Давайте посмотрим правде в глаза! Что есть 99% украинского (и не только) ИТ? 1. Сайтоклепство2. Оболочки на базы данных3. Багфиксинг4. Прикручивание нового функционала, к старым буржуйским поделкам.Оставшийся процент приходится на создание продуктов с нуля, но это опять well-known компоненты и технологии, где все хорошо предсказуемо, требуется только внимательность и аккуратность.Поверьте вечер в крупном ресторане несет для менеджера значительно больше неожиданностей и рисков.А если уж говорить об уникальных проектах в ИТ, они скорее присущи комплексной деятельности вроде автоматизации предприятий или созданию сетей передачи данных.

Евгений, администратора зала в ресторане и прораб на стройке это не менеджеры проектов:) Посмотрите что такое «проект» в вики и вы узнаете почему. Кстати, непонимание понятий «проект» и «менеджмент» присуще 90% отечественных IT производителей, многие путают «проект» с «операциями», а «менеджера» с «опытным программистом». Остальное не хочу даже комментировать, поможет та же вики, по запросу project management, например. Скрам, безусловно прикольнее с точки зрения программиста, выше я описывал почему. Но для проекта, цель которого — быть выполненным успешно в бюджет и в срок он не годится.

ВадимА вы никогда не задумывались, какие сертификаты имеют менеджеры в других областях? От администратора зала в ресторане, до прораба на стройке? И прекрасно справляются со своей работой.А прогеры умудряются запутать до невозможности простенький сайт из десятка страниц.Принципы просты — декомпозиция задач, четкое разделение зон ответственности, технологические карты.А самое главное — никто не берется за работу, до получения полного комплекта документации.Программисты прекрасно знают эти принципы, но с завидным упорством игнориуют: (Скрам прикольнее.ЗЫСознательно избегаю слова ИТшники — у связистов и хардварщиков таких проблем не наблюдается.

Андрей, Евгений, согласен с вами и считаю что причина того, что так обстоят дела — в недостатке знаний. Программист, тестер знает свою технологию, получает по ней сертификаты, таких специалистов хватает. Архитектор, тест аналитик — людей с такими сертификатами меньше, но тоже встречаются. А сколько среди ваших знакомых сертифицированных системных аналитиков? Уверен, что мало, а именно эти люди знают и умеют писать однозначное и полное ТЗ, которое дашь 10 программистам и получишь 10 одинаковых систем. Скажите, много ли вы знаете людей с сертификатом PMP? Лично я знаю всего двоих, сомневаюсь что на всю Украину их больше 50. А именно эти люди знают и умеют сдавать проекты в срок и в бюджет.Ну и говоря о процессах, много ли специалистов в нашей индустрии имеют сертификаты RUP, MSF, PRINCE2, тот же Scrum...? Ответ — катастрофически мало. PMP + RUP сертифицированный менеджер творит чудеса, и это стоит того времени на подготовку что он потратил. Классический украинский «менеджер» разглагольствует о пользе скрама и валит вину на команду.Вобщем, учиться, учиться и еще раз учиться:)

Андрей+100Программирование вроде бы уже вылезло из коротких штанишек и стало индустрией с миллионами людей и триллионами бюджетов, а по сути осталось кустращиной.Все проблемы производственных процессов (и даже изобретательской деятельности) давно уже формализованы и отработаны. Построены 100-этажные дома, трансатлантические лайнеры и космические станции. А программисты очередной раз изобретают велосипед.

Вадим, Мне приходилось иметь дело, например, с медицинскими проектами — то есть такими, от ошибки в которых может зависеть жизнь людей. Я согласен, что там процесс действительно очень важен. Но согласится с тем, что процесс является главным фактором в любом проекте я не могу. На самом деле, производство для медицины отличается от обычной разработки софта еще и тем, что непределенность с тем, что нужно сделать отсутствует практически полностью. Если Вы делаете предположим аппарат искуственного дыхания — то какая то неопределенность будет присутствовать только первый раз. Для всех следующих моделей аппарата вы будете повторять те же самые шаги которые могут быть описаны в виде технологической карты — то есть по сути вы получаете процесс как в машиностроении:). Но большинство проектов не таковы. Основную проблему как я уже сказал я вижу в том, что мы не являемся строго инженерной дисциплиной. Дайте 10 токарям одной квалификации один и тот же чертеж — получите 10 одинаковых (в пределах допуска) деталей. Дайте 10 программистам одну спецификацию — получите 10 разных программ. Все потому что машиностроение (и электроника, кстати, появившаяся почти одновременно с ИТ) имеют свой формальный язык проектно-конструкторской документации, а ИТ — нет и пользуется для тех же целей обычным языком, который всегда может быть понят неоднозначно. Какое все это отношение имеет к человеческому фактору? Самое прямое. Ваша команда должна быть мотивирована закрывать вот эту проблему отсутствия однозначного описания, а оно отсутствует по определению отрасли, хоть с применением Скрама, хоть без этого применения. Если люди не мотивированы — они легко скатываются на позицию: делаем так как написано и если непонятно, то никого ни о чем не спрашиваем ибо это не наше дело, сами виноваты что так написали. Кстати, и в строгоформализованном медицинском проекте при отсутствии мотивации можно тоже натворить дел.Скрам, на мой взгляд, скорее вреден чем полезен, потому что вместо признания существования проблемы понимания требований клиента, которая вообще говоря довольно сложна, требует для своего решения специальных умений и знаний, которыми рядовой програмист, как правило не обладает, создает иллюзию того, что эта сложная задача может быть решена путем всеобщих митингов и собраний.:) Согласен с Вами, что используя Скрам, непонятно каким образом я смогу обозначить для клиента хотя бы сроки проекта. Конечно, даже названные сроки часто не соблюдаются, но если я скажу клиенту, что я вообще никакого срока не могу назвать для всего проекта и только могу сказать, что клиент получит после ближайшего спринта... Возможно, что это как то работает в случае продуктовых компаний — вроде бы Микрософт использует Скрам. Я согласен и с тем, что за результаты проекта не может отвечать команда — если за что-то отвечает больше одного человека, то по сути не отвечает никто:) Я спрашивал идеологов Скрама, не является ли СкрамМастер псевдонимом для ПМ-а и не есть ли он то лицо, что несет ответственность за успех проекта — мне сказали, что не является и не несет:)

Андрей, разделяю вашу позицию относительно Скрама, и аргумент «я знаю, что скрам работает» звучит не особо убедительно:) Уверен, что он работает в компаниях по производству «сайтов за 15 минут», но мы вроде о других проектах ведем речь. С «факторами успеха» я не совсем согласен. Обьясню почему: 1. Представьте себе, что вы менеджер проекта по созданию самолета. От качества продукта будут зависеть жизни людей. Можете ли вы позволить, чтобы крепление крыльев было выполнено некачественно, потому что ответственный за эту задачу человек обиделся на вас или, скажем, просто он балбес? Или что команда посреди проекта бросит работу потому что ее не устраивают условия труда? Ответ — нет. Избежать этого вам поможет только правильный процесс, который сводит человеческий фактор к минимуму, практически к нулю. Процессу неважно кто именно выполняет задачу по стыковке крыльев, но он гарантирует уровень качества при соблюдении требований к документации архитектуры, peer review, тестированию итд. Процессу неважно насколько сейчас мотивирована команда, но он потребует от вас грамотной работы с риском «команду прийдется менять» и смена команды пройдет для проекта безболезненно. Я абсолютно уверен, что грамотный менеджер, следуя процессу, может создать самолет пригласив в команду одного-двух квалифицированных инженеров и бригаду студентов.2. Объем работ должен быть зафиксирован. Нельзя начинать работать, имея на входе «сделайте мне сайт» — это обречь себя на бесконечный scope creep. Другой вопрос, что в процессе должен проводиться Integrated Change Control — управление изменениями в проекте. Это несложно, и в том же RUP это есть.Вобщем, как и в предыдущем посте, моя формула: менеджмент + процесс = успешный проект:)

На мой взгляд, Скрам просто отражает бессилие нашей отрасли перед лицом реальной действительности:) Мы называем себя инженерами, но при этом в отличие от настоящих инженеров (машиностроителей, например) — мы не можем гарантировать заказчику ни сроки, ни качество разрабатываемого продукта. Поэтому отрасль придумала Скрам в рамках которого честно говорит клиенту — мы тебе ничего не обещаем, кроме того, что мы будем стараться:). На мой взгляд есть только два фактора, наличие которых гарантирует успех проекта: 1. Человеческий. У Вас должна быть правильно подобрана команда и правильно организованы отношения между людьми. Если это есть — то какой у Вас при этом процесс, совершенно не важно. Команда может выбрать и Скрам, если он ей удобен, может RUP, а может процесс под названием «анархия — мать порядка», главное чтобы он подходил данной конкретной команде. Когда я говорю команда выберет — я имею в виду, что грамотный проджект менеджер построит процесс под команду, не пытаясь навязать команде практики, которые данная команда все равно не готова выполнять.2. Наличие у заказчика проекта ясного понимания того, что он хочет получить. Оно может быть не формализовано, оно может существовать в виде, который понятен только заказчику (тогда менеджер должен организовать вытягивание из клиента этих знаний и перевод их на язык понятных команде), но это понимание должно быть в каком то виде. Отсутствие понимания что нужно было делать — это причина провала большинства проектов. Скрам — это попытка отложить получение этого понимания в целом на потом. Как если бы пилили доски для постройки дома, при этом длину каждой доски мы бы определяли методом проб и ошибок, а потом еще бы и пытались собрать из этих индивидуально напиленных досок какой то дом, который мы себе до этого не представляли. До моды на Скрам была точно такая же мода на RUP и другие такие же «технологии». Всего лишь 7−8 лет назад я наблюдал такой же энтузиазм в отношении RUP-а, как сейчас в отношении Скрама:). Я понимаю, что те кто это придумал и продвигает — зарабатывает на этом деньги. Через пару лет появится следующая серебряная пуля. Но пока менеджеры не поймут, что именно человеческий фактор стоит во главе угла, а процесс — даже не вторичен, ситуация в отрасли не изменится. Не согласны? — Тогда подождем еще пару лет и посмотрим, что будет собирать толпу энтузиастов в то время:)

к сожалению нет времени вдаваться в полемику.я знаю, что скрам работает. есть сотни сотен компаний по всему миру, в которых agile — это основной процесс. множественные подтверждения этому я получил на конференции agile2008. так что доказывать лишний раз что-то кому-то я не буду.в конечном итоге, если вам нравится быть тем единственным, кто несёт ответственность за успех или неуспех проект человеком — это ваш выбор. если вам нравится угнетать ваших сотрудников нереальными сроками — это ваш выбор. если вам нравится получать на выходе низкокачественный продукт (из-за той же спешки и отсутствия групповой ответственности) — это ваш выбор. на счёт сертификаций по скрам. на октябрь ещё есть немного мест. записывайтесь и приходите. там интересно.

Николай, спасибо за ответы, вы подвели меня к тому, что я хотел сказать. Действительно, мир не идеален, это касается и людей и процессов и технологий. И моя позиция относительно Скрама (пусть будет так:) имеет следующие корни: 1. Я считаю, что в любом проекте всегда должен быть один человек, несущий ответственность за успех всего проекта. Подход «виноваты все» не годится, я даже не хочу тратить время на объяснения почему.2. (это очень важно) Мое мнение, именно в менеджменте заключается успех проекта. Верите или нет, но можно делать очень серьезные вещи с командой лоботрясов и зеленых студентов, грамотно следуя процессу, управляя качеством, рисками и т.д. В то же время, очевидно, можно завалить проект имея армию профессионалов, это очень легко и это наблюдается повсеместно.3. Моя позиция, это позиция менеджера, возможно в этом и разница наших взглядов. Я прекрасно понимаю позитивность этого процесса с точки зрения разработчика. Ты в команде, все молодцы, стараются, никто над тобой не нависает, выбираешь себе работу по душе, оцениваешь как тебе угодно, не получилось? — ты не виноват, проект не вписался в бюджет и сроки? — бывает, главное что заказчик еще проект не закрыл... Это классно, я не спорю. Никто не хочет работать много, качественно и быстро, это человеческая природа. Именно поэтому процесс, ориентированный на разработчика проигрывает с точки зрения менеджмента. Проект, который зависит от компетенции программистов, настроения заказчиков и еще ряда условий — это кораблик в океане и его «менеджер» не более чем матрос на вышке, который может разве что констатировать крушение. Такие проекты живут постольку, поскольку заказчикам они обходятся дешево. Представьте, что перерасход 10 человеко-часов в проекте вашей компании это уже убытки, вы бы поставили Скрум? А если опоздание на день это закрытие проекта? А с такими реалиями придется работать и очень скоро.Подводя итог. Как и своим первым, так и этим постом, я хочу донести всего одну идею — со временем разработчики будут все более дорогие и все менее качественные, ничего личного, это диктует рынок. Это очень важно понимать. Уже сейчас компании вынуждены брать студентов без опыта на 1000$, не заметить это очень трудно. Уже сейчас все теснее на рынке и эта тенденция будет продолжаться, а значит падать цена спроса. При таких перспективах, ставить процессы, в которых ответственность лежит на разработчиках (читай ни на ком) это очень рискованно и очень дорого в конечном итоге. Нужно делать упор на качество менеджмента и грамотные процессы, это ключ к развитию.

to #19Вадим, для начала — не существует идеального подхода на все случаи жизни, и Скрам (не SCRUM, ибо не аббревиатура:)) не претендует на звание «silver bullet», тем более он считается легковесным фреймворком (даже не процессом). Боюсь, я не смогу хорошо ответить на вопросы, в частности потому что они мало релевантны моему опыту и реальности. В любом случае — попытаюсь, а с конструктивным отношением Вы и сами скоро разберетесь:) Контест вопросов № 1 и 2 мне совершенно непонятен, что такое «я», что такое cost и что — расписание? 3. Не скажу, что смена заказчиков такая уж и нормальная практика; опять же не очень понятен контекст. Может пример? Смена заказчика — это в общем случае достаточно радикальная перемена, уверен что абсолютных гарантий быть не может. Но за счет изначального подхода «embrace change» любой адекватный agile процесс будет явно не в проигрыше. В конце концов, новый заказчик может сразу резко поменять курс и это будет оставаться в рамках процесса. 4. В мотивированных и профессиональных коммандах это редко большая пробема. Тем не менее, немного гарантии таки есть. Самое главное — при следовании принципу «сашими» (или emergent architecture + YAGNI), в любой момент на руках остается законченый срез приложения, а не разрозненные модули, «архитекторы» которых не стали дожидаться часа интеграции. Хорошо бы помогли другие механизмы (автоматическое тестирование и т.п.), но они за рамками чисто Скрама.5. Таки да — все. Какой смысл искать козла отпущения? Может лучше раньше диагностировать и предотвратить проблему? В этом и цель Скрама. 6. Эти вещи не само собой разумеющиеся, и действительно очень важны. Если у Вас команда лоботрясов или одних зеленых студентов, Вы не умеете ею управлять (точнее, направлять) без коммандного окрика, то Скрам лучше не внедрять. Если проект завалится, то это будет не по вине процесса. Скрам, опять же, это легкий процесс, он не вводит специальных инструментов для управления, он лишь дает намек: «Скрам мастер — это не менеджер, а коуч, наставник, помощник и слуга комманды; дай комманде самой справиться с проблемой, и подскажи как можно бы лучше». Если не умеешь работать с людьми без специальных «звездочек на погонах», процедур и отчетов, и главное не хочешь уметь, то Скрам — это наверное пока рановато.По поводу института — это наверное на ажиль юкрейн к Леше и Ко: http://www.agileukraine.org/:)

:) без философии, не увидел ответа ни на один из своих вопросов. Если я внедряю SCRUM, то: 1. Почему я могу считать, что расходы на проект не превысят его Cost? (который, конечно, может меняться, если в процессе реализовано управление изменениями, в RUP это есть) 2. Аналогично, почему я могу считать, что расписание проекта соответствует реальности? 3. Говоря о Customer Satisfaction, где гарантия что смена заказчика (это нормальная практика) не завалит проект? 4. Где гарантия, что смена нескольких (или всех) членов команды не завалит проект? 5. КТО виноват если проект завален (ответ «все» = ответ «никто» ) 6. «предполагающей наличие таких вещей как: взаимное доверие, мотивация и профессионализм членов комманды» говорить о таких вещах как о само собой разумеющихся более чем неосмотрительно. Где в процессе инструменты, обеспечивающие это? У меня пока еще нет сертификата по SCRUM и я действительно буду рад если он ответы на эти вопросы дает. В любом случае, я планирую пройти сертификацию и по этому процессу, так что не хочу чтобы вы подумали что я отношусь к нему как-то предвзято. Тем более, что тут я вижу уже целый SCRUM-институт:)

SCRUM, как процесс, немного напоминает принцип генетических алгоритмов. Однако, в отличие от них, SCRUM только создает иллюзию поиска оптимального решения. Я вкратце попытаюсь объяснить почему.Те, кто хотя бы в общих чертах знакомился с дисциплиной проджект менеджмента, знают, что в любом проекте всегда присутствует Baseline — (Scope, Cost, Schedule, Quality, Risk). Часто сюда добавляют еще и Customer Satisfaction и еще некоторые критерии, но на мой взгляд базовыми в проекте являются именно эти пять артефактов. То есть менеджер проекта в любой момент дня или ночи может всегда сказать 5 вещей: что входит в объем работ проекта, какой у проекта бюджет, когда проект закончится, какой уровень качества проекта и продукта, перечислить ключевые риски и планы по ним.И, если для управления Scope SCRUM и предлагает инструменты (Backlog), то сроки и бюджет проекта в нем не контролируются никак. Этими параметрами не управляет менеджер (SCRUM-мастер), их диктует команда, что само по себе катастрофический риск для проекта. Сегодня команда говорит одно, завтра другое, послезавтра кто-то уходит и в итоге никто не виноват. Вообще говоря, урезанная роль менеджера (SCRUM-мастера), размытая мотивация и ответственность команды делают процесс крайне неэффективным для выполнения проектов в срок и в бюджет.Мое мнение, SCRUM это вырождающийся инструмент, который используют, если денег в компании никто особо не считает. Нет проблемы превысить Cost проекта в 3 раза, если цена часа на выходе 50 долларов, а внутри 10, а понятие «недополученная прибыль» это мистика. К сожалению, цена часа снаружи падает, а внутри растет, поэтому необходимо посмотреть в глаза реальности и потратить деньги и время на внедрение гораздо более грамотных процессов. Таких, например, как RUP.

кому интересно в августе будет ряд мероприятий по agile в киевеAgile Club31 июляВстреча аджалистовТренинг Базовые концепции Agile и SCRUM15 августаТренер Алексей КривицкийТренинг Automated Acceptance Testing16 августаТренер Николай Алименков

Спасибо, Алексей.Хорошая статья, супер ответы на вопросы.Очень порадовало «it depends»:) Так держать! Be creative!

Ответили отрицательно на вопросы — значит вы еще не выросли. Значит вы получаете удовольствие от самого процесса программирования. Это существенно отличается от решения поставленных задач.Это означает, что вы не сможете работать в больших командах и действительно крупных проектах.

И какие языки Вы называете «динамическими» в данном случае? Языки со слабой типизацией?

По-моему, очевидно, что динамические языки — это языки с динамической типизацией. А слабая типизация — это ортогональная штука. Вот у С слабая типизация, например.

На динамических языках рефакторинг проще потому что меньше кода, нужно делать изменения в меньшем количестве мест и потому что шире инструментарий (сделать proxy обьект легче, есть возможность адаптации, лучше дела с интроспекцией). Тестирирование проще опять же потому что нужно меньше бойлерплейта, промежуточных шагов и не нужна поддержка со стороны IDE. Вообще в Python цена начала рефакторинга практически нулевая, и я не верю что он где-то может быть проще. Это нужно попробовать и ощутить на себе, обьяснить не возьмусь.

to Щетинин Сергей

Правильным ли будет предположение что Scrum больше подходит для проектов реализуемых на динамических языках? (Я исхожу из того что в этом случае цена рефакторинга и тестов значительно ниже).

Боюсь, что нет. Если исходить из гипотезы «...на динамических языках...цена рефакторинга и тестов значительно ниже», то как раз при разработке на статическом языке намного важнее следовать agile принципам, так как они нацелены на «приветствование изменений» (embrace change) путем поощрения таких полезных практик как эволюционирующая архитектура (в т.ч. рефакторинг), автоматическое тестирование и др. А изменения, как мы знаем, будут:) Т.е. и динамическим не противопоказано, но статическим полезнее.По поводу самой гипотезы, рискуя выйти за рамки темы спрошу:, а на чем она основана? И какие языки Вы называете «динамическими» в данном случае? Языки со слабой типизацией? Как это помогает рефакторингу? Мне всегда казалось, что как раз рефакторинг-то и намного легче в статических языках типа Java по сравнению со скажем Python, т.к. в большинстве случаев можно достаточно точно вычислить тип => IDE или другая тулза может достаточно безопасно его (рефакторинг) проделать.

Пара мелких вопросов/комментариев

2. Product Owner поддерживает список требований-пожеланий к продукту. Этот список он сортирует (приоритезирует) по принципу «ценное сверху, менее ценное снизу».

ИМХО стоило бы упомянуть, что PO основывает приоритезацию не только на бизнес-ценности «требований», но и на основе оценки сложности (читай — размера) имплементации, предоставляемой коммандой. В п. 3 читаем:

Так как часто для принятия подобных решений требуется пожертвовать детализацией фич

Что значит «жертвовать детализацией»? Уменьшать ее? Кажется, происходит наоборот: уточнение требование, разделение их на элементы или жертвование деталями в пользу достижимости.

Классная статья! Де-монстрация особенно порадовала:)

как раз трейню группу 1С-ников, я бы не сказал, что именно так они и работают...прошу не путать отсутствие планов и дисциплины с аджайлом. аджайл требует очень высокой степень дисциплины. как от команды так и от заказчика. и само по себе это не случается.а жаль!

По моему по такой технологии сейчас работают все 1С программисты.

Спасибо за ответы. Если позволите еще несколько вопросов: Правильным ли будет предположение что Scrum больше подходит для проектов реализуемых на динамических языках? (Я исхожу из того что в этом случае цена рефакторинга и тестов значительно ниже).Как адаптируется методика для разработок новых продуктов, т.е. как выбирать «хозяина» (project owner)? Есть ли вообще какие-то рекомендации по этому поводу в том числе для выбора со стороны заказчика, когда такой есть? Есть ли опыт применения методики в частично или полностью распределенных командах?

отвечаю дальше...

Какие сроки внедрения Скрам для разных размеров организаций и какие потери на первых стадиях?

Как и всё на свете «it depends». Это зависит от размера проекта, готовности заказчиков и команды опробовать новые подходы. От фазы проекта. Новый небольшой проект (скажем, 2−6 человеко-месяцев) можно запустить за пару дней, при условии, что есть видение разрабатываемого продукта.Для большего проекта, который уже находится в фазе активной реализации этот процесс может занять пару месяцев при несогласованной работе команды и заказчика. А может и никогда не закончиться...Но, я скажу, что шансы внедрить эти подходы есть всегда. И обычно они больше, чем думают компании.Как раз сейчас я провожу тренинг в Полтаве, в компании, которая пытается внедрить Scrum на одном крупном проекте. Это будет нелегко, но у них есть шансы. Всё зависит от того, на сколько важно для них получить те выгоды, которые им обещает Scrum.Удач!

Сергей, спасибо за комменты.Ярослав, спасибо за ответы и ссылку на книгу Хенрика Книберга (кстати, собираюсь его привезти в Киев в декабре)

Чего в статье мне не хватило, так это пояснений откуда выросли такие правила. Кто, как, когда, почему пришел к мнению что это нужно делать именно таким образом?

Эти правила, как и многое другое, что мы используем в современном мире, пришли с востока — из наработок японских компаний, таких как Toyota, которые уже не первый десяток лет разрабатывают свои продукты по похожим правилам. Первое упоминание о Scrum. Вот немного больше информации от одного из американских адоптеров Scrum Джеффа Сазерленда.Позже эти правила были названы Scrum (термин из регби) и вышла в свет первая книга и потом две другие.

Также интересно можете ли вы рассказать о недостатках системы. Я думаю вы согласитесь что у всего есть цена, поэтому те или иные преимущества получаются в обмен на что-то еще, что это в случае Скрам?

Конечно, у всего есть недостатки. И за все преимущества нужно платить. В Agile мы платим за позволения принимать поздние решения тем, что нам приходится поддерживать код в хорошей форме. Это достигается тренировками кода, которые называются рефакторинг — это частые улучшения внутренней структуры кода, без изменения его функциональности. Бок о бок с рефакторингом идёт юнит-тестирование — как практика автоматической проверки работоспособности системы. Обе эти практики небесплатны — требуют немалых инвестиций. В обмен вы получаете software, который правда настолько soft, что его можно изменять без слишком дорогой платы за сами изменения.

Если я правильно понимаю, SCRUM без XP на практике нежизнеспособен.

Верно?

Если мы говорим о Скраме в принение к софту — то да. Скрам — это pull для XP практик. Без налаженного continuous integration, code review, unit-testing делать регулярные билды очень сложно.

пояснений откуда выросли такие правила. Кто, как, когда, почему пришел к мнению что это нужно делать именно таким образом

Правила выросли в процесе имплементации на практике принципов (ценностей) XP, библией которых является Extreme Programming Explained Кента Бека, того самого, которого так усиленно поливали д@рьмом глубокоуважаемые Yossi Kreinin и Phillip J. Eby.Движимоя сила скрума — Кен Шваббер и Майк Кон.Вот минибука, по которой я пробовал внедрять скрум в своих палестинах. Ее уникалькость в минимуме теории и максимуме практики — идеальный How-tohttp://www.infoq.com/minibooks...

Спасибо за статью, каркас Скрам объяснен четко и доступно. Чего в статье мне не хватило, так это пояснений откуда выросли такие правила. Кто, как, когда, почему пришел к мнению что это нужно делать именно таким образом? Некоторые пункты достаточно очевидны, но всё равно интересно услышать подробней.Также интересно можете ли вы рассказать о недостатках системы. Я думаю вы согласитесь что у всего есть цена, поэтому те или иные преимущества получаются в обмен на что-то еще, что это в случае Скрам?

Приходилось ли вам учить новый язык программирования или какой-то API, начиная с примера в мануале и переделывая его по ходу под ваши нужды? В итоге в конечном коде возможно не останется ни одной строки, которая была в начальном примере. Тем не менее использовать за основу простой работающий пример было удобно. То же самое и со Скрамом. Примените, отладьте, поломайте, почините, потом смело меняйте на ваш вкус.

На стадии обучения конечно все так делают, но в продакшн не должно идти ни строки кода получившихся таким образом (если не согласны, могу объяснить свою точку зрения). Какие сроки внедрения Скрам для разных размеров организаций и какие потери на первых стадиях? После скольких проектов вы считаете команды овладевают методикой в достаточной степени чтобы она перестала быть liability?

Подписаться на комментарии