Уменьшить длину итерации.

По крайней мере это уменьшит вероятность появления таких проблем в будущем. Хотя раз на раз не приходится.

Кстати а Agile -проекте всегда должен присутствовать "представитель заказчика". По правилам он должен всегда находиться в помещении где сидят программисты на расстоянии не более 5м от самого дальнего ;)))

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

Нельзя вводить agile с середины проекта.
Проект должен быть рождён в agile.

Это ограничение ставит крест на вводе скрама во всех существующих проектах :)

Согласен.

Но нельзя использовать Agile в проектах, начатых не в Agile. Категорически!

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

1. никогда ранее не работали по водопаду

2. Желательно чтобы не работали ранее в торговой фирме.

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

Это ограничение ставит крест на вводе скрама во всех существующих проектах :)

Мало того, оно ещё и высосано из пальца и не обосновано...

Категорически!

------

Ну и слава богу - все что начиналось до игила - всякие Винды, Никсы и прочее - и весь приклад под них под игилом делать никак ниЗЗЗя!!!

Но нельзя использовать Agile в проектах, начатых не в Agile. Категорически!

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

Скрам - это методология управления временем и не больше.

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

У нас обысно под новый проект нанимают отдельную команду.

:) А прокты у вас все вечные? Или как потом эту команду увольняют? Или нанимают команду консалтеров? :) Ты наверное работаешь где-то, где совсем не считают деньги :)

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

Т.е. берете студентов без опыта? ;)

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

:) Хорошо, когда не надо считать деньги :D

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

Кстати, студенты без опыта -- не самый плохой вариант. Потому что ты их будешь учить "под себя". А человека "с опытом" надо ещё ПЕРЕучивать, а он ещё будет сопротивляться...

то решение вообще-то простое. Мы не знает что происходило, делаем три (5,7) подзадач

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

FocusFactor -- это отношение реально затраченных часов к запланированным.

Ну путем простой логики мы и увеличили этот самый FocusFactor даже не считая. Путем уменьшения запланированных. Путем регулярного уменьшения.

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

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

Ну, это вам просто с адекватным менеджментом работать не приходилось.

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

Нельзя, не считая. Ритуалы Agile надо исполнять точно. Иначе не работает.

Тут важен не результат, а процесс.

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

Тут важен не результат, а процесс.

Гм. Или я тупой или лыжи не едут. Разборка полетов. Запланировали 50 пунктов. Пунктов, Карл!, не часов. Пролетели, сделали 25. Не проблема, на следующий раз планируем 25 пунктов. Прирост производительности в 100%. Нужно срочно поощрять. И команда слаженная, на следующий раз запланируем 15 пунктов.

С какого перепугу? Команда не выполнила план, зачем ее поощрять? И какие нафиг пункты?

Есть задачи, которые разберемся впются на подзадачи. Для каждой подзадачи выделяются часы.

Итого: задачи, подзадачи и часы.

Где здесь "пункты"? Это ж не Agile, а какое-то другое творчество!

С какого перепугу?

-----

Ну как с какого?

первый раз взяли - пролетели. Тут - понятно - мимо.

второй раз взяли - попали в 100%. Тут - понятно - надо поощрять.

третий раз взяли - попали в 140%. Бля, гении - срочно стимулировать...

Пример:

В первый день итерации:
1. Считаем число доступных человеко-часов.
2. Умножаем на фокус-фактор с предыдущей итерации и получаем реальное число часов
3. Приступаем к планированию. Планирование заканчиваем, когда израсходуется реальное число часов.
4. Добавляем одну или две "бонусных" задачи.
5. Расходимся по домам. Программирование в день планирования строжайше запрещено.

Второй день интерации:
... Программируем...

....

Предпоследний день итерации
... Программируем...

Последний день итерации:
Демонстрируем результат заказчику.
Проводим ретроспективу.

На ретроспективе считаем, все ли задачи сделаны. Если все, то вычисляем фокус фактор. Если были сделаны ещё и бонусные задачи, то пересчитываем фокус-фактор.

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

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

Проектыу нас имеют начало и конец. По окончании проекта программистов переводят на другой agile-проект. Некоторых не принимают в новый проект (голосованием самих программистов). Если программиста голосованием не принимают ни в один проект, то его увольняют.

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

4 программиста, 2 тестировщика, 1 scrum-мастер, один "представитель заказчика" (итого 8 человек). Был выполнен за 4 месяца.

При этом в конце второго месяца заказчик полностью оплатил весь проект.

2. Желательно чтобы не работали ранее в торговой фирме.

А это почему? Я уже 10 лет работаю в торговой фирме, если что...

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

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

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

Считается, что человек, работавшей в торговой фирме программистом, уже "испорчен как программист" и для agile непригоден. Дело в том, что в торговых фирмах не принято думать над кодом. Начальник даёт задание, которое надо сделать за 20 минут потому что "клиент уже в пути, через 20 минут все должно быть готово". Поэтому программисты в таких компаниях пишут такой код, который поддерживать _в_принципе_ невозможно.

А развивать -- тебя паче.

Эту психологию искоренить невозможно. Поэтому руководители agile- проектов внимательно отслеживают предыдущие места работы соискателей. По крайней мере так в России. Как в Германии -- не знаю.

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

Согласен. Но это мера вынужденная, бытие определяет, так сказать... Вот есть у меня 4 больших проекта, которые я поднял с нуля, и развиваю, тем не менее. Так вот, самый проблемный проект - это первый, начатый мною. Там я неопытный был, и сваял симпатичную такую иерархию классов под поставленную задачу. А потом начались проблемы, все время необходимо было срочно вносить изменения, очень скоро потребовались такие, которые ни разу не совместимы с заложенной иерархией классов, и это все на испытательном сроке, и когда проект уже в деле... При этом никого не волнует качество кода, важен только функционал. Время на переделку не дают, работает и ладно, никто не знает сколько еще проект бабло приносить будет (а этот проект тогда находился под угрозой из-за планировавшегося налога на финансовые транзакции), типа лучше сделай другой проект, чем этот переделывать, тем более что в итоге будет тот же функционал. В итоге такой мутант получился, что мама не горюй, правда он и сейчас живее всех живых. Я поначалу психовал из-за этого, а потом плюнул, смотрю на это как на Kündigungsschutz.:)) Теперь умный стал, иерархий классов в проектах по-минимуму, готов к любым сюрпризам, так сказать...

Эту психологию искоренить невозможно.

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

Кстати, а у кого нибудь считается агиль с удалённой работой?