Во-первых огромное спасибо, что классно и на пальцах рассказали!!!

> Scrum и Kanban.

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

В интернетах куча инфы и сравнений двух методик.

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

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

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

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

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

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

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

А если продукт "свой", то и ПО должен быть из фирмы.

Пока увидел два критерия:

- тип проекта(ов). Для большого количества проектов методика неэффективна

- размер команды. Для малых размеров (границы?) методика неэффективна

нп.

у нас от скрама только такое: раз в неделю сгоняются все на митинг (человек 30) и каждый по очереди говорит чего сделал за неделю или чего сейчас делает. Редко кто скажет больше чем "писал юнит тесты для..." или "занимался исправлением ошибок" - короче - более одного предложения.

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

А зачем тогда баг треккер? Всё видно кто, что делал и сколько времени потратил. Туда же и "новое" загоняется.

Поэтому то непонятен смысл регулярных митингов.

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

Если фирма более или менее крупная, то такое представить совсем не сложно. Напимер на роль продакт онера отлично подходит аналитик (у нас в одной из фирм этот человек назывался product manager). Это человек, который собирает хотелки у клиентов и формирует из них user stories (в той фирме product manager писал Plichtenheft на каждую фичу). Человек этот, не был частью команды и фактически исполнял роль продакт онера (все это было в доскрамовое время :D)

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

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

Ну и, как я говорил, такие люди есть в любой фирме, скажем, от 100 человек. Да даже в более мелких фирмах, есть либо сейлы, либо маркетологи-аналитики, которые фактически и являются заказчиками.

- тип проекта(ов). Для большого количества проектов методика неэффективна

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

- размер команды. Для малых размеров (границы?) методика неэффективна

Я бы сказал, что наоборот :) Для команд из более, чем 10 человек скрам легко превратится в кучу скучных собраний. Да даже уже 10 - много. Граница наверное где-то в районе 5-7 человек.

Если фирма более или менее крупная

То бишь еще одно ограничение?

Накладывается похоже и еще одно одно - один проект на 5-7 человек

Еще раз, скрам - это методика управления временем

Со множеством ограничений...

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

Совершенно не важно сколько там проектов Важно, чтобы можно было выделить небольшие задачи.

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

То бишь еще одно ограничение?

Не совсем. Дело в том, что в более или менее крупной фирме проще найти человека, который бы мог исполнять роль продакт онера и при это не был бы частью команды. Впрочем, сейлы есть (почти) везде :) Но в каком-нибудь стартапе будет трудно разделать роли. Только и всего. Впрочем, некоторые части скрама вполне можно применять. Например task board + stand up, как мне кажется, очень сильный инструмент, который дает прозрачность и контроль работы.

Накладывается похоже и еще одно одно - один проект на 5-7 человек

Ну вот команда из 5-7 человек - это пожалуй ограничение. Опять же, это ограничение позволяет повысить эффективность работы по скраму. Но это не означает, что нельзя сделать скрам в команде из 30 человек ;)

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

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

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

Угу. А автомобиль это средство передвижения. Быстрее чем пешком. Но тоже со множеством ограничений. По тротуару кататься нельзя, права получать надо, телефоном пользоваться нельзя...

Это не ограничения, это "параметры, при которых методика эффективна". Если у вас один разработчик в проекте вам не нужен скрам. Если у вас 50 человек в проекте (и они реально не разделены на группы и подгруппы, а все взаимозаменяемы) и у вас до это как-то работает - вам не нужен скрам. Вы только на ежедневный стэндап (daily) будете часа 2 тратить.

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

Смотря что вы понимаете под "эффективностью". Станут ли 2 человека программировать быстрее? Нет. Ускорится ли весь цикл разработки (time to market)? А кто его знает, зависит от того, как это организовано сейчас. Если сейчас клиент звонит напрямую разработчику и тот через 15 минут разговора начинает кодить, как только написал - сразу деплоит, то всё станет значительно медленнее. Но появится документация хотя бы кто когда и какие хотелки клиента реализовал. Станет код "лучше"? Смотря как вы определите DoD (definition of done) и насколько строго будете проверять на соответствие.

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

Осторожно, образное сравнение! :)

Какой метод передвижения эффективнее: пешком, на велосипеде, на машине, на поезде или на самолете? Смотря куда и как быстро вам надо добраться. В булочную - пешком, в магазин за большими закупками - на машине. В Таиланд - самолёт. Будет ли эффективно "передвижение на машине"? Смотря куда ехать собрались, сколько груза с собой, что важнее - скорость, комфорт, и те де и те пе.

Например task board + stand up, как мне кажется, очень сильный инструмент

Ежедневный митинг с доской что ли?

https://www.scrumdesk.com/daily-scrum/

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

А где же тогда митинги, доска, ПО, СМ и прочая атрибутика?

Хотя даже что понимать под "подзадачей" тоже не просто определить. Что будет являться результатом?

повысить эффективность работы по скраму

И как энто можно измерить?

Или по другому. Как мне узнать что использование Скрама в данной конкретной ситуации даст какой либо выигрыш?

Какой метод передвижения эффективнее: пешком, на велосипеде, на машине, на поезде или на самолете?

Так в этом то и проблема, это все и представить можно и пробовалось и хоть как то знаешь.

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

Например как "лиса" начала Скрам пользовать, так и захотелось на новый бровсер, достали эти постоянные обновы с незнанием будет ли все работать как раньше или нет.

Тут такое дело... Можно выделить... ну, назовём их "маркеры". Точный и полный список я нигде не видел, в разных статьях проскакивает. И из личного опыта. Может кто ещё что добавит, мне было бы интересно.

1. Гибкость. (пожалуй, самый главный) Как часто в процессе разработки будут вносится изменения в требования.

Если ваш клиент с самого начала твёрдо уверен в том, что ему нужно, или вы делаете одно и то же с небольшими косметическими изменениями в 100-й раз, скрам не нужен. Берите водопад / критический путь (critical path) / канбан.

Если клиент хочет "чтобы оно вот где-то тут так, а потом - вздыыышь! и всё сиреневое! И кнопку!" - скорее всего скрам вам сильно поможет.

2. Организация. Готовы ли вы к изменениям в организации. Если нет - забудьте про скрам, не взлетит. Про "правильный" размер команды уже говорили, что 5-7. Имхо, скорее 5, чем 7. 3 - мало. И надо будет менять организацию, чтобы создать такие команды. Без тим ляйтера! (сколько у нас было воплей по этому поводу...) Если одна команда должна работать одновременно с несколькими проектами, сможете ли вы найти ПО, который сможет отвечать за все эти проекты? Два и более ПО (бывает) это труба.

3. Личные качества. Готовы разработчики брать на себя ответственность и принимать решения? Многие программисты в скраме работать не могут. Они воспринимают только приказы сверху а обсуждать решения с коллегами и потом принимать решение не в состоянии (а чо он мной командует? да кто он такой чтобы решать!). У них этакая вера во всезнающего и безупречного тимлида. "Начальстворианство" :)

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

Готовы менеджеры отказаться от красивых графиков релизов "через 6 месяцев будут реализованы следующие фичи"?

4. Размер проекта. Если время разработки проекта 1-2-3 недели - не стоит затеваться со скрамом (но тут скорее противоречие с 1-м пунктом, так быстро делается то, что в начале хорошо известно).

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

6. Требования к качеству (понятный, легко изменять) кода / документации. В скраме есть Definition of Done (DoD). Можно задать требования к выполненной истории очень жёстко, прописать какую документацию надо править, какие тесты обязательно выполнять. Если вам всё это не надо - то и скрам вам может быть не нужен.

Имхо, важные - первые три пункта. Если они у вас выполняются, скрам поможет организовать разработку. От привычки обсуждать истории на рефайнменте (если ПО готов воспринимать критику, а не "я - начальник, ты - дурак") до чётко отработанного процесса деплоймента (с DevOps хорошо уживается). Программисты в команде через какое-то время действительно станут "взаимозаменяемыми" и не будет такого что спец по БД заболел/ушёл в отпуск, никто его базу не трогает, боится. Вырабатываются привычки делать ревью, проверять документацию коллеги - а понимаю ли я её, а вдруг он чего забыл.

"Щупать" удобно на каком-нибудь исследовательском проекте. Когда дают время месяцев 6, задачу в общих чертах (а напишите нам анализатор логов, а что конкретно он анализировать будет - посмотрим) и команда пробует а как оно будет - работать с микросервисами (например). Потому что нет давления "штоп к 1-му все блестело и переливалось!" и действительно часто меняется что же надо сделать.

Ну или идти в уже существующую команду, смотреть сможете ли втянутся.

В одиночку "щупать" - бессмысленно.

P.S. Сейчас перечитал, как-то сумбурно у меня ночью получилось... Ну, если б ребёнка спат не укладывал бы то вообще не написал бы.

Ежедневный митинг с доской что ли?

Он самый.

А где же тогда митинги, доска, ПО, СМ и прочая атрибутика?

Все 20 подзадач на доске. Каждый день эти подзадачи во время стэнд апа переходят из одного состояния в другое.

ПО, СМ и прочее можно в маленькой команда опустить, все равно один человек не сможет грамотно совмещать.

Хотя даже что понимать под "подзадачей" тоже не просто определить. Что будет являться результатом?

Что является результатом определяет команда. Для этого придумали целый термин - DoD (Definition of Done).

И как энто можно измерить?
Или по другому. Как мне узнать что использование Скрама в данной конкретной ситуации даст какой либо выигрыш?

Можешь ввести какой-нибдуь KPI (ну там количество новых строк в день или можешь следить за тем, чтобы burn chart постоянно убывал) ...

В конце-концов, в скраме предусмотрена ретроспектива, где команда может решить, что можно изменить и как улучшить процесс, ну или что стало хуже и скрам надо нахрен убрать :D

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

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

Готовы менеджеры отказаться от красивых графиков релизов "через 6 месяцев будут реализованы следующие фичи"?

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

Ну и в остальном. Все таки скрам - это управление временем, поэтому его можно реализовать не только при разработке ПО.

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

Аналогично. Но меня обвиняли в том что я ПО хочу в плохом свете выставить.

Надо сказать не без причин. Если человек пишет критерий выполнения / Akzeptanzkriterium как "muss wie erwartet funktionieren" а на вопрос "и что это должно означать" округляет глазки и отвечает "ну это же очевидно!" и это не в первом и не десятом спринте, то кто он после этого?

Но мой пример вдохновил одного коллегу. Меня из команды выдавили, теперь он "плохие" вопросы задает и "замедляет процесс ненужными дискуссиями". :)

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

Выделенное - главное. Невозможно за 3 или 6 месяцев обещать что будет в релизе (commitment). Можно предположить. Основываясь на актуальной скорости спринта и на бэклоге. Но! В бэклоге может быть много неоцененных, зависящих друг от друга историй. Могут быть еще не прошедшие рефайнмент. Да просто "декларации о намерениях" даже без критериев. И тогда предположения становятся совсем шаткими. А высказывания вроде "наверное сможем" менеджеры не воспринимают и махом переделывают в "команда обещала". Каждый раз призодится в письмах начальству такое отлавливать.

Менеджеры с удовольствием воспринимают что теперь можно каждые 2(3, 4, смотря какая длина спринта) недели меять задания, приоритеты, вносить что-то новое. Что каждые 2 недели у них будет новый релиз. Но когда им объясняешь что именно из-за этого я не могу гарантировать никаких сроков реализации конкретной фичи - "не понимают как так может быть". Изображают дурачка, ведь "если надавить посильнее то всё эти программисты в срок напишут".

Пожалуй самое толковое для меня, спасибо.

Если клиент хочет "чтобы оно вот где-то тут так, а потом - вздыыышь! и всё сиреневое! И кнопку!" - скорее всего скрам вам сильно поможет.

чем?

2. Организация. Готовы ли вы к изменениям в организации.

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

обсуждать решения с коллегами и потом принимать решение не в состоянии

Относительно обсуждений, тоже как когда. ПМ был в большом удивлении когда в первый раз услышал наше обсуждение - мол руготня одна.

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

Готовы будущие ПО понимать что их постановку задач могут (и будут) обсуждать, задавать вопросы вроде "а зачем это вообще"

Вот это скорее отрицательно чем положительно, достаточно непросто найти адекватного человека.

5. Срок жизни проекта. Если лепится страничка

Подобных проектов, как то не попадалось.

6. Требования к качеству (понятный, легко изменять) кода / документации.

А при чём здесь скрам? Задать и так всё можно. Только сроки всегда были важнее всего остального

DevOps хорошо уживается

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

Ну или идти в уже существующую команду, смотреть сможете ли втянутся.

менять работу ради Скрама? - спасибо не надо.

Программисты в команде через какое-то время действительно станут "взаимозаменяемыми"

Как то очень сомневаюсь. В любую "большую часть" нужно вначале "въехать", а для этого нужно время.

Пока так и не увидел ни единого преимущества Скрама для себя

ПО, СМ и прочее можно в маленькой команда опустить, все равно один человек не сможет грамотно совмещать.

А как же тогда определить - "Я работю по скраму"

Все 20 подзадач на доске. Каждый день эти подзадачи во время стэнд апа переходят из одного состояния в другое.

зачем еще на это время тратить?

Что является результатом определяет команда. Для этого придумали целый термин - DoD (Definition of Done)

Зачем мне новые термины, нужен конкретный пример. Не вижу я адекватного определения.

Можешь ввести какой-нибдуь KPI (ну там количество новых строк в день

реально что то высчитать достаточно затруднительно.

Даже такой бессмысленный показатель как строки в день - отчего он будет зависеть от применения/не применения Скрама?

Если клиент хочет "чтобы оно вот где-то тут так, а потом - вздыыышь! и всё сиреневое! И кнопку!" - скорее всего скрам вам сильно поможет.
чем?

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

Как поможет скрам? 1. Цикличностью и постоянным общением с заказчиком (как минимум на ревью). и 2. тем что скрам это "модно".

Подробнее:

1. Спринты короткие, по результатам спринта, которые демонстрируются клиенту можно уточнить предыдущие хотелки и получить новые. И внезапно из "и всё сиреневое!" получается "когда пользователь нажимает кнопку 'Отправить данные', появляется диалоговое окно, запрашивающее подтверждение, а вся рабочая область приложения становится неактивной. Гравичеки это отображается в "затемнении" рабочей области, наложении "сиреневой дымки".

Такое уже попроще обсуждать и реализовывать, да? Но клиент в состоянии выродить такое (в беседе с ПО) тольео когда уже видит перед собой окошко программки с кнопкой "Отправить данные". До этого он уверен что всё и так понятно.

Т.е. наша задача упрощается - из клиента надо выбить достаточно информации чтобы создать "ходячий скелет" (walking skeleton) приложения. А потом ему демонстрируется результат разработки, и он может внести свои "сверхважные" замечания (вроде "перенести кнопочку налево", "сделать заголовок больше", "а тут не красный а оранжевый") и чувствовать себя влияющим и командующим всем и все. И это делает его счастливым до одури :) А пока он счастливый, расслабившийся и тепленький, его пытает ПО на тему "а теперь давайте уточним что вы имели в виду под "вздыщь!". И сразу на бумажку. (Ну, или в тикет в джире). Через две (3,4) недели всё повторяется но уже с новыми фичами. Снова собираем сверхценные замечания, меняем оранжевый обратно на красный, кнопочку пхаем посередине, и выясняем а что должно происходить когда пользователь нажмёт на эту кнопочку. Причес через пару спринтов клиент может и передумать что же будет происходить при нажатии, потому что увидит что он по-другому себе всё представлял.

По умному "fast feedback loops". Мы получаем новую информацию от клиента как реакцию на нашу проделанную работу намного раньше (в каждом спринте).

В водопаде у такого клиента, после того как он напишет даже самой подробное ТЗ, остаётся слишком много времени чтобы у него в голове всё переделалось на новый лад. А ТЗ он сам читать никогда не будет, не барское это дело. Чукча писатель а не читатель. В результате, через год разработки ему показывают что-то, пусть даже на 100% соответствующее ТЗ, а клиент жутко обижен и недоволен - это совсем не то что он имел в виду (потому что то, что он имел в виду за этот год в его голове поменялось раза 3). Всё, проект прошел плохо, клиент недоволен, деньги платить не хочет, потому как уверен что его непрвильно поняли ("что вы мне тычете этим ТЗ, всем понятно что под `удаление аккаунта` я имел в виду что он пропадает из таблички с результатом поиска") и те де и те пе.

2. Модность помогает продать скрам. Убедить клиента что ему НАДО найти время на то, чтобы участвовать в ревью после каждого спринта и на то что ему НАДО обсуждать истории с ПО. "Вы же знаете насколько лучше становится результат разработки, если применяется скрам, а в нём предписано что вы обязательно должны участвовать, чтобы контролировать соответствие разработки вашим представлениям и пожеланиям".

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

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

Относительно обсуждений, тоже как когда. ПМ был в большом удивлении когда в первый раз услышал наше обсуждение - мол руготня одна.

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

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

Вот это скорее отрицательно чем положительно, достаточно непросто найти адекватного человека.

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

А при чём здесь скрам? Задать и так всё можно. Только сроки всегда были важнее всего остального

Вооот! Вот именно этому скрам и противодействует. 1. Какие фичи в каком релизе выйдут не прописваетя. 2. Тикеты с невыполненым DoD нельзя включать в релиз. И команда может послать ПО, когда он начнёт что-то требовать, вроде "не пишите тесты, и так всё понятно". И нормальный мастер их поддержит.

Но это работает только если, как я раньше писал, менеджеры и руководство понимает что скрам даёт, и от чего при сраме надо отказаться. Иначе ПО идёт жаловаться к руководству и руководство "разрешает" команде "не выполнять DoD для истории X". Но потом то же руководство не хочет понимать - а чо это у нас ошибки попёрли. А потому что ПО понравилось такое классное решение. И теперь в каждой задерживающейся задаче "разрешает" не выполнять DoD. И команда уже не спорит, потому что знает что спор ничего не даст. Простейшее противодействие со стороны команды - тупо начать оценивать "стоимость" историй выше. Чтобы в спринт вошло меньше историй и реже "разрешали" не выполнять DoD.

Как то очень сомневаюсь.

Дело ваше. Есть люди, которые в том что земля круглая сомневаются. Бывает. Конечно, кто-то больше любит в графике ковыряться, кто-то БД. Но внедрённые ими в проекте решения будет понимать вся команда.

Пока так и не увидел ни единого преимущества Скрама для себя

Ну так он вам,может, и не нужен. Это нормально.

Как поможет скрам? 1. Цикличностью и постоянным общением с заказчиком (как минимум на ревью). и 2. тем что скрам это "модно".

А почему это должен быть именно скрам?

На модность абсолютно плевать.

А потом ему демонстрируется результат разработки

ну так это и так можно сделать. Это был вроде главный аргумент у Ralf Westphal-а, когда он пытался мне доказать необходимость Скрама.

По умному "fast feedback loops". Мы получаем новую информацию от клиента как реакцию на нашу проделанную работу намного раньше (в каждом спринте).

Каждый день по малому кусочку? Никогда таких клиентов еще не попадалось. Клиенту нужна работающая "фича", а какие то малые кусочки, которые соответствуют нашим выдуманным ДОД ему нафиг не нужны.

Ну и что можно выдумать для ДОД, если на реализацию нужна допустим неделя, а без всех законченных частей ничего работать не будет. Ведь и так каждая часть делается по кусочкам. Ведь проект не пишется с головы 8 часов каждый день, целую неделю, а после все компилируется и отлаживается.

В водопаде у такого клиента, после того как он напишет даже самой подробное ТЗ

В принципе мне по барабану водопад, скрам или еще что.

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

Пока что приходится для каждого конкретного случая использовать что "то специализированное".

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

у скрам мастера прибавляется седых волос. Он каждый день будет отбиваться

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

И это бесит. А когда такое происходит постоянно, настроение в команде падает ниже плинтуса

безусловно - это реалии. Только как Скрам в этом помогает так и не доходит.

Не важно как вы будете проводить обсуждения

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

Вооот! Вот именно этому скрам и противодействует

Ну так тогда он будет на фирме просто запрещен. Ведь главная задача сдать продукт в срок. (Возникающие при этом проблемы пока касаться не будем.)

понимает что скрам даёт, и от чего при сраме надо отказаться

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

Но внедрённые ими в проекте решения будет понимать вся команда.

отчего - из-за постоянных обсуждений?

Ну так он вам,может, и не нужен. Это нормально.

Вот именно это и непонятно, отчего он мне ни разу не понадобился. Что именно я не понимаю? Или просто проекты были какие то особенные?