Agile
Уменьшить длину итерации.
По крайней мере это уменьшит вероятность появления таких проблем в будущем. Хотя раз на раз не приходится.
Кстати а Agile -проекте всегда должен присутствовать "представитель заказчика". По правилам он должен всегда находиться в помещении где сидят программисты на расстоянии не более 5м от самого дальнего ;)))
Именно представитель проекта как правило является автором проблем подобного типа
Согласен.
Но нельзя использовать Agile в проектах, начатых не в Agile. Категорически!
У нас обысно под новый проект нанимают отдельную команду. При этом очень важным считается нанять разработчиков, которые
1. никогда ранее не работали по водопаду
2. Желательно чтобы не работали ранее в торговой фирме.
Потом первый месяц все пишут абсолютно ненужный проект (но не знают об этом) . Цель первого месяца -- сформировать команду. Ну, а со второго месяца начинается реальная работа в порядке, прописанном в Agile.
Но нельзя использовать Agile в проектах, начатых не в Agile. Категорически!
Я не знаю от куда взялось это утверждение и не понимаю на чем оно основано.
Скрам - это методология управления временем и не больше.
Более того, в одной из предыдущих фирм разработка была переведена на скрам-подобную методологию по указке начальства. И все прошло очень хорошо. Да и вообще, новых разработок не так много (во всяком случае на моем пути).
У нас обысно под новый проект нанимают отдельную команду.
:) А прокты у вас все вечные? Или как потом эту команду увольняют? Или нанимают команду консалтеров? :) Ты наверное работаешь где-то, где совсем не считают деньги :)
При этом очень важным считается нанять разработчиков, которые
1. никогда ранее не работали по водопаду
2. Желательно чтобы не работали ранее в торговой фирме.
Т.е. берете студентов без опыта? ;)
Потом первый месяц все пишут абсолютно ненужный проект (но не знают об этом) . Цель первого месяца -- сформировать команду. Ну, а со второго месяца начинается реальная работа в порядке, прописанном в Agile.
:) Хорошо, когда не надо считать деньги :D
Кроме студентов без опыта есть уйма народу с опытом. Например, одиночки, способные вообще самостоятельно весь проект с нуля и под ключ собрать.
Кстати, студенты без опыта -- не самый плохой вариант. Потому что ты их будешь учить "под себя". А человека "с опытом" надо ещё ПЕРЕучивать, а он ещё будет сопротивляться...
то решение вообще-то простое. Мы не знает что происходило, делаем три (5,7) подзадач
Вообще то я не собирался углублятся в конкретную задачу. Просто скажу, что решал ее не я, функционал отключать было нельзя, потому что в тестовой среде проблема не наблюдвлась, а отключить функционал у клиентов и заставить их платить за это это даже по моим меркам наглость. Проблему нашли через 3 месяца и три месяца исполнителя переодически ставили в различные положения - это не просто баг. Это датеншуц. А мы работали на серьезные организации, не мелкорозничная торговля. Это был просто пример жопы. Кстати именно на этой фирме была именно команда. И мы помогали, чем могли.
Такого в скраме быть не может.User Story уже обсуждена, принята командой в работу, никаких обсуждений больше нет
Кодревью не прошел. Программист настаивает, что решение корректное. Ревьюеру не нравится и он заблокировал пуллреквест. Как минимум есть тема обсудить. В обсуждение обычно вовлекается арбитер.
Ну, это вам просто с адекватным менеджментом работать не приходилось.
Ну сколько я фирм видел, каждый менеджер имеет свою команду. С ней он решает задачи и зарабатывает пункты. Решенные вовремя задачи это премии и карьера. А без определенного программиста дуля с маком. И скрам мастер тоже должен в этом непотребстве участвовать, что бы скрам мастер отличников в Берлин ездил? Ну может я еще встречу свою идеальную команду
Нельзя, не считая. Ритуалы Agile надо исполнять точно. Иначе не работает.
Тут важен не результат, а процесс.
Делается это в конце итерации на "ре роспективе". Формат проведения "ретроспективы" (разбор ошибок, разбор препятствий, выработка правил, подсчет фокус-фактор) -- все это обязательно должно иметь место. Иначе Вы никогда не получите слаженную команду. Если фокус -фактор в конце итерации увеличивается _значительно_, то это может быть. поводом для пощрения команды. Хотя, где как.
Тут важен не результат, а процесс.
Гм. Или я тупой или лыжи не едут. Разборка полетов. Запланировали 50 пунктов. Пунктов, Карл!, не часов. Пролетели, сделали 25. Не проблема, на следующий раз планируем 25 пунктов. Прирост производительности в 100%. Нужно срочно поощрять. И команда слаженная, на следующий раз запланируем 15 пунктов.
С какого перепугу? Команда не выполнила план, зачем ее поощрять? И какие нафиг пункты?
Есть задачи, которые разберемся впются на подзадачи. Для каждой подзадачи выделяются часы.
Итого: задачи, подзадачи и часы.
Где здесь "пункты"? Это ж не Agile, а какое-то другое творчество!
Пример:
В первый день итерации:
1. Считаем число доступных человеко-часов.
2. Умножаем на фокус-фактор с предыдущей итерации и получаем реальное число часов
3. Приступаем к планированию. Планирование заканчиваем, когда израсходуется реальное число часов.
4. Добавляем одну или две "бонусных" задачи.
5. Расходимся по домам. Программирование в день планирования строжайше запрещено.
Второй день интерации:
... Программируем...
....
Предпоследний день итерации
... Программируем...
Последний день итерации:
Демонстрируем результат заказчику.
Проводим ретроспективу.
На ретроспективе считаем, все ли задачи сделаны. Если все, то вычисляем фокус фактор. Если были сделаны ещё и бонусные задачи, то пересчитываем фокус-фактор.
Если бонусные задачи подняли фокус-фактор _значительно_, то можно говорить
о поощрении.
Обратите внимание: премирование возможно только при выполнении бонусных задач.
Проектыу нас имеют начало и конец. По окончании проекта программистов переводят на другой agile-проект. Некоторых не принимают в новый проект (голосованием самих программистов). Если программиста голосованием не принимают ни в один проект, то его увольняют.
Один из последних проектов (Система управления бизнес центром на базе умного дома), довольно обширный проект с большой степенью детализации проработки деталей.
4 программиста, 2 тестировщика, 1 scrum-мастер, один "представитель заказчика" (итого 8 человек). Был выполнен за 4 месяца.
При этом в конце второго месяца заказчик полностью оплатил весь проект.
2. Желательно чтобы не работали ранее в торговой фирме.
А это почему? Я уже 10 лет работаю в торговой фирме, если что...
Например, одиночки, способные вообще самостоятельно весь проект с нуля и под ключ собрать.
Ну да, это именно то, чем я все 10 лет и занимаюсь, и коллеги, кстати, тоже.
В торговых фирмах есть одна особенность, начальство панически боится утечки технологий отжатия бабла на сторону, поэтому "команд разработчиков" торговых систем не существует в принципе. Ну вот, практически сам и ответил на вопрос.:))
Считается, что человек, работавшей в торговой фирме программистом, уже "испорчен как программист" и для agile непригоден. Дело в том, что в торговых фирмах не принято думать над кодом. Начальник даёт задание, которое надо сделать за 20 минут потому что "клиент уже в пути, через 20 минут все должно быть готово". Поэтому программисты в таких компаниях пишут такой код, который поддерживать _в_принципе_ невозможно.
А развивать -- тебя паче.
Эту психологию искоренить невозможно. Поэтому руководители agile- проектов внимательно отслеживают предыдущие места работы соискателей. По крайней мере так в России. Как в Германии -- не знаю.
Поэтому программисты в таких компаниях пишут такой код, который поддерживать _в_принципе_ невозможно. А развивать -- тебя паче.
Согласен. Но это мера вынужденная, бытие определяет, так сказать... Вот есть у меня 4 больших проекта, которые я поднял с нуля, и развиваю, тем не менее. Так вот, самый проблемный проект - это первый, начатый мною. Там я неопытный был, и сваял симпатичную такую иерархию классов под поставленную задачу. А потом начались проблемы, все время необходимо было срочно вносить изменения, очень скоро потребовались такие, которые ни разу не совместимы с заложенной иерархией классов, и это все на испытательном сроке, и когда проект уже в деле... При этом никого не волнует качество кода, важен только функционал. Время на переделку не дают, работает и ладно, никто не знает сколько еще проект бабло приносить будет (а этот проект тогда находился под угрозой из-за планировавшегося налога на финансовые транзакции), типа лучше сделай другой проект, чем этот переделывать, тем более что в итоге будет тот же функционал. В итоге такой мутант получился, что мама не горюй, правда он и сейчас живее всех живых. Я поначалу психовал из-за этого, а потом плюнул, смотрю на это как на Kündigungsschutz.:)) Теперь умный стал, иерархий классов в проектах по-минимуму, готов к любым сюрпризам, так сказать...
Эту психологию искоренить невозможно.
Это не психология, а адаптация, я точно так же могу переобуться в воздухе, и начать писать нормальный код, при наличии нормального техзадания, естественно. И, это самое, я ведь умею дохера, поскольку все сам. :))
