спасиб

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

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

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

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

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

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

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

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

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

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

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