Scrum, Возможно, сделано неправильно

Question

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

У нас есть обычное планирование Sprint, которое занимает около 30 минут при написании пользовательских историй сами, и все. В это 30-минутное время мы отвечаем на следующие вопросы:

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

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

Видение: Нам нужно приложение для выполнения модульных испытаний по X-приложению.

Пользовательские истории:

1. Журналы пользователя в
   • Создание таблицы БД (схема не была уточнена)
   • Создать Вход
   • Аутентифицировать пользователя к серверу Y.
2. Пользователь видит доступный блок тестирует
   • Создать представление для отображения блок тестирует
   • Read DB таблицу
   • Реализация операций CRUD
3. Пользователь выполняет модульные тесты.
   • Осуществить выбор для верхней точки зрения
   • Добавить выполнить операцию
   • отображения результата на новой странице

Что мои заботы были:

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

2. Нет фактического планирования.Мы не выяснили, что такое БД должно выглядеть так, как ее создать? Я могу создать БД для такой системы с 1 по N таблиц в зависимости от того, что проект должен достичь в будущем, но это не так серьезно, как DB можно легко расширить.

3. Основываясь на (2), мы начали работу с различными частями. Я создал БД, в то время как другие создали представления, а затем другие создали операции. У всех нас было другое понимание, и даже за один день мы закончили с несовместимыми моделями, которые просто невозможно интегрировать.

Что мы сделали неправильно:

• Нет планирования. Моя команда просто ненавидит планирование, они, как действовать сначала, и спрашивают позже. Я вроде: I.DO.NOT.DO.SOMETHING.TWICE.BECASE.YOU.ARE.LAZY.TO.DO.PROPER.PLANING.
• Отсутствие связи между членами команды, но даже я не ожидал, что только в один прекрасный день мы закончим так.

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

Answer 1

Я заинтригован, кто «они» в этой строке: «Это действительно расстраивает меня и они не будут слушать меня.»?

Он читается так, как будто вы имеете в виду остальную часть команды схватки. Если это так, я предлагаю вам как можно скорее добраться до «we» и работать с коммуникацией.

Что касается некоторых из пунктов в вашем посте, несколько вещей, которые приходят на ум сразу:

1. Если вы не один, вам нужен владелец продукта, чтобы иметь продукт, это видение и это отставание. Если у вас их есть, то они могут получить хорошую подготовку или коучинг

2. Вы абсолютно правы в том, что вам нужно Vision Vision. У вас, кажется, есть один, но вы заключаете, что он описывает некоторую функциональность, а не полное видение продукта. Если да, попытались ли вы обсудить это в своей команде?

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

Об ваши заботы, я хотел бы добавить:

1. Я думаю, что вы имеете в виду «Спринт», где вы пишете «весной '

2. Обычно в схватке, что элементы продукта отставание изменяются с учетом лучшего понимания

3. Вам не нужно подробно описывать базу данных при запуске проекта. Scrum лучше всего работает с нарождающейся архитектуры на основе реализованной функциональности

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

Answer 2

Я думаю, что вы,, должны получить это на ваших плечах. Будьте тем парнем, который пишет спецификацию и собирает всю необходимую информацию для выполнения функциональности или задачи. Планирование должно выполняться вместе, но в случае неопытных программистов вам может понадобиться сделать это самостоятельно. Почти каждая функциональность обращается к данным, поэтому определение интерфейса для этих моделей и операции является обязательным. Если у вас их еще нет в вашем отставании, тогда планируйте его на first meeting of the sprint

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

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