расскажите, как это у вас выглядит, и как "переходили на скрам", и как тепеь выглядят яйца?

У меня на прошлом проекте был скрам. Но что-то пошло не так, и в результате 20-25% рабочего времени тратилось на митинги :)

А на предпредыдущей работе ввели скрам и там было все эффективно.

Сейчас у нас от скрама только стэндапы.

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

Короче говоря, если у вас думают, что введение скрама улучшит качество кода, то этого не произойдет :D

Мы бились где-то полтора года пока не начало получаться. Проблема часто встречается - совмещение должностей. Тимляйтер играл ПО. Первого скрам мастера он выжил, второй был экстерн, которому платил тимляйтер. Пока мы не эскалировали до уровня руководителя всего IT, всё шло хм... Хреново. Потос нам дали третьего мастера, который наконец-то не зависел от ПО, и мог его поставить на место. С тех пор потихоньку всё стало лучше. Теперь у нас почти всегда выполняются DoD, истории не впихиваются посередине спринта, пока не будут готовы критерии, истории в спринт не включаются... В общем теперь нормально. Покрытие тестами растет, У нового кода почти всегда > 80%, ошибки не так часто лезут. На чём еще экономят - на документации. Я продавил чтобы хотя бы Changelog писали, а потом меня ПО с проекта таки сдвинул :) Так что другой документации нет...

Могу сказать что код у нас читаемей чем у отлелов, которые по водопаду с 120-и страничными "Pflichtheft"-ами пишут (из которых страниц 90 - кто его написал, с кем согласовал и сколько часов запланировал на реализацию

Простите, что встреваю,

пожалуйста, если не лениво, разъясните что конкретно скрам-мастер делает? Я много гуглил, и не понял, но ни разу воочию не видел и совершенно не могу понять чем он от Project Manager, Product Owner и Software Architect отличается, вернее зачем он при наличии оных нужен.

Спасибо!

понятно, что на качество кода сильнее влияют другие факторы, а не название "новейшей технологии".

многоие манагеры покупаются на то, что это - agile development, а кто ж откажется от того, чтобы разработка занимала только половину отведенного времени? : )

давайте себе представим некий проект, который выполняют 5 человек. допустим, все - на полное время. они должны решать по ходу дела какие-то задачи, принимать какие-то решения, и даже если они никогда не слыхали слова СКРАМ, задачи у них - те же, и кто-то должен выполнять ту же работу, которую в классическом скраме предписано выполнять определенным ролям. но если нас пятеро, то получается, что одного мы должны держать за стэйк холдера, одного - скрам-манагера, остаются трое на разработку. совмещать роли - это как играть в шахматы/шашки самому с собой: в какой-то момент забываешь, и начинаешь за кого-то играть в поддавки.

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

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

оунэр - некто, кто пытается видеть задачу глазами заказчика (неужели остальным нас*рать, будет ли клиент доволен?), и проталкивает его интересы. хотя платим ему мы : )

Ну продакт онер не должен быть частью команды разработки :) Это очень важно именно это у нас в предыдущей конторе нарушалось.

В принципе, никто не зартавляет брать весь скрам в том виде, как он описан в книжках ;) Возьмите часть. Например, стэндап - очень полезная штука. Желательно, чтобы была реальная доска с задачами на спринт.

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

скрам-мастер - буфер между командой и "внешним миром". Т.е. все враимодействите между командой и всеми остальными должно быть только через скрам-мастера.

Product Owner - человек, который заказывает разработку и этот человек не должен быть частью команды.

Ага, а все так просто оказалось! Спасибо большое, moose и Программист, что просто и понятно разъяснили. Про оунера - я как-то слышал, даже однажды в его шкуре был, но вот факт, что еще есть скрам - для меня всегда было загадкой, ведь по сути Project Manager управляя, Software Architect наставляя, и секретарша поднося всегда и во все времена выполняли задачу скрама.

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

Большое спасибо за простое и понятное объяснение!

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

> формализация задач (где это возможно) - всегда полезная весчь.

это верно, и в умелых руках приносит реальную пользу, спасибо большое за классное сравнение!

Мы бились где-то полтора года пока не начало получаться.

То бишь хотите сказать что теперь довольны?

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

Все что мне запомнилось - это регулярные бессмысленные митинги и прочая дребедень вроде доски в комнате с бумажками.

> Мне вот только интересно какие условия должны выполнятся, что бы агильная методика была эффективной.

опять я со своим дурацким вопросом... можно???

Скажите, пожалуйста, правильно ли я понимаю, что агильная методика очень хорошо ложится на R&D, когда есть грубо говоря примерный бюджет, есть рабочие руки, есть желание что-то получить, но что именно, и как именно получать никто еще не знает, только есть критерий - "хорошо", то бишь получилось, или так себе?

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

1) Скрам-мастер должен быть с железными яйцами :) (ну или продакт онер должен понимать свою роль и не вмешиваться в процесс работы команды)

2) Продакт онер должен быть вне команды и не должен быть начальником над скрам-мастером и над командой.

Все что мне запомнилось - это регулярные бессмысленные митинги и прочая дребедень вроде доски в комнате с бумажками.

Вот доска с бумажками мне как раз нравится. Считаю ее полезной придумкой. А митинги - это уже завсит от скрам-мастера, если он ни рыба ни мясо, то получится х*ня.

Еще раз, скрам - это методика управления временем. И ничего больше. Скрам хорошо ложится везде, где надо распределять время.

Спасибо, уважаемый Программист, что отетили, но мы тут уже про агильность говорили?

Скрам, как много в этом слове.... и как его можно извращать...

Видел "Скрам" на разных фирмах и разных проектах.

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

Самый ужасный Скрам:

Был внедрен новым начальником IT просто "с ноги", чтобы ему было, что предъявить. Сам начальник в разработке не участвовал, но играл частично роль скрам-мастера и просто пиздобола, которому везде надо было профилироваться.

Скрам-мастером был один из разработчиков, никаких прав фактически не имел, кроме как вести стэндап. Стэндап проходил до 1,5 часов каждый день, с присутствием ПО и вечными дискуссиями, а что именно нам надо делать.

ПО было сразу 3! Три, Карл! У каждого свои интересы. В зависимости от нужд фирмы задания из спринтов вынимались и добавлялись, спринты при нужде продлевались на неделю, иногда две.

Параллельно со спринтом всегда было дохрена саппорта по другим проектам. В общем был кромешный звездец.

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

Самый разумный Скрам:

Новый проект, никакого саппорта по старым проектам. Скрам-мастер - не участвует в разработке и вообще не программист. ПО один и с конкретными задачами. Спринты соблюдаются. Вообще все шоколадно.

Были и несколько промежуточных вариантов и даже "Scrumban" - как нечто среднее между Scrum и Kanban.

В целом из своего опыта могу сказать, что все сильно зависит от фирмы и проекта.

Если проектов несколько, то скорее всего скрам накроется постоянной борьбой приоритетов.

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

Если агильно работает только отдел разработки, а вся остальная фирма как-то другому, отдел скорее всего будет инородным телом во всем процессе.

Не стоит моды ради вводить Scrum для внутренних отделов разработки, Kanban гораздо лучше вписывается в процессы, когда у тебя регулярно меняются приоритеты.

Хорошо иметь архитектора, который помогает ПО проработать все его хотелки технической поддержкой. Редко бывает ПО, который сам понимает все тонкости и возможные варианты.

Agile - это всего лишь модное слово, за которым скрываются разные методолории управления проектом (aka временем). Это ни секунды не золотой грааль, с появлением которого все сразу станет хорошо.

Надо четко понимать зачем вводится та или иная методология.

Например, в моем текущем проекте agile'ные методологии (например скрам) работать не будут, т.к. никакого планирования просто нет, а появляющиеся процессы нарушаются потому что "мы всегда так работали".

Но это не значит, что процессы эти нельзя вводить где-то в других местах. Также и в R&D, где-то аджайльные методики будут работать, а где-то нет. И зависит это пожалуй не столько от темы R&D, сколько от вводящего и от участников.

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

а еще более отвратительное - что фраза "у нас скрам" действует в определенной среде (на клиента) положительнее, чем "а мы голову подключаем".

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

То бишь хотите сказать что теперь довольны?

Почти. Не хватает документации (ПО не даёт на нее время, давит на разработчиков) и UI-Тестов (по той же причине). Из-за чего временами насинают не так работать фильтры, сортировка или вообще кнопка не то делает. Упс, не то зарефакторили.

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

Яростно плюсую "ПО не должен быть руководителем разработчиков и мастера".

Мастер должен уметь общаться, вести дискуссию. Иначе да, всякие ретроспективы превращаются в скучное бесполезное времяпровождение.

Разработчики должны уметь (банально) работать в команде. Спрашивать и отвечать. Договариваться. Находить устраивающие всех компромиссы (а мастер им помогает). Иначе все сидят по углам, делают по своему и скрипят зубами друг на друга.

И (по-моему самое важное, ну или такое же важное как ПО) менеджеры (stakeholder) должны понимать что такое скрам. Что он им дает и чего лишает. Иначе не взлетит. Будут прожирать всё время - "а составьте мне отчет какие фичи будут реализованы к 01.06, а какие к 01.12".