Я начал работать в биржевом брокере, который нанял меня и еще двух разработчиков для создания программного обеспечения, чтобы помочь им. Я новый член команды разработчиков. Мой друг, еще один разработчик в команде, попросил меня создать модель разработки программного обеспечения для применения в проекте, потому что способ, которым они занимаются сейчас, не работает. У них нет конкретной модели для подражания, они просто решают, что делать устно, два владельца биржевого брокера (которые в данном случае являются клиентами) просят их разработать функцию, поэтому разработчики просто прекращают то, что они делали. и начать работать над ним, у них нет конкретного списка реквизитов или функций, которыми должен обладать продукт...
Первоначально моя идея состояла в том, чтобы попытаться внедрить и адаптировать Scrum в следующих терминах:
Создавайте бэклог продукта как можно скорее. Роль владельца продукта будет выполняться владельцами компании. Я и другой разработчик будем Скрам-командой. Один из разработчиков будет скрам-мастером. У нас будет один спринт в неделю. Встречи каждую пятницу, чтобы подвести итоги последнего спринта и спланировать следующий. (Обзор спринта, ретроспектива и планирование) Я не вижу необходимости в ежедневном обзорном совещании. Я подумал, что мы могли бы проводить спорадические встречи во время спринтов, когда кто-то из участников чувствует себя нужным. Возможно ли, что это сработает? Что я могу сделать, чтобы сделать его лучше?
Возможно ли, что это сработает?
Это довольно основано на мнении. Если вам интересно мое мнение, то ответ "может быть". Томас упоминает о потенциальных трудностях, но в зависимости от команды они могут быть легко преодолимы. Что приводит меня к...
Что я могу сделать, чтобы сделать его лучше?
— Не знаю, попробуй и увидишь. Самый ценный инструмент в Scrum (и, возможно, во всем Agile) — это Ретроспектива. Попробуйте что-нибудь. Проверьте, насколько хорошо это сработало. Адаптировать. Предписания Agile не обязательно должны применяться только к продукту. Они могут (и должны) применяться и к процессу.
Так что не тратьте слишком много времени на размышления о том, что попробовать. Просто выберите процесс и попробуйте. Затем (всей командой) усовершенствуйте его или полностью откажитесь от него и попробуйте что-нибудь другое.
Не используйте Scrum — он не подходит для данной ситуации. На сайте Software Engineering Stack Exchange я написал ответ о минимальном количестве людей для реализации Scrum. Прямо сейчас вы описываете минимальное количество людей для формирования Скрам-команды (владелец компании в качестве владельца продукта, 3 разработчика, один из которых является скрам-мастером).
Я вижу несколько заминок в этом плане. Во-первых, скрам-мастер должен быть коучем как для Владельца Продукта, так и для всей организации. Может ли человек, которого вы выбрали на эту роль, иметь необходимое влияние на владельца, который выступает в качестве Владельца Продукта, и остальных сотрудников? организация? Во-вторых, есть ли у выбранных вами людей необходимое время, знания и опыт для работы в качестве владельца продукта и скрам-мастера?
Вместо Scrum я бы начал с рассмотрения подхода, созданного по образцу Kanban.
Сначала создайте доску для рабочих элементов. Работайте с командой и людьми, управляющими продуктом, чтобы определить, какая информация необходима команде для выполнения работы. Это иногда называют определением готовности . Вместо того чтобы заставлять владельцев прерывать работу, они начинают формулировать рабочий элемент, соответствующий определению готовности. Однако для этого им может понадобиться помощь команды — регулярно выделяйте время для этого. Вы можете получить некоторые рекомендации на сеансах «ухода» или «улучшения невыполненной работы» от Scrum о том, как управлять определением готовности и следить за тем, чтобы работа была в хорошем состоянии.
Затем расставьте приоритеты в рабочих элементах. Я бы постарался сделать так, чтобы последнее слово в распределении приоритетов оставалось за одним человеком. Порядок рабочих элементов определяет порядок работы разработчиков. Как только разработчик завершает рабочий элемент, он просматривает верхнюю часть списка невыполненных работ и выбирает самый верхний элемент, который он может выполнить, переводя его из состояния «сделать» в состояние «выполнено». Важно установить и обеспечить соблюдение лимитов незавершенного производства (WIP).
Как правило, принципы бережливой разработки программного обеспечения должны быть полезными. Ваши действия по планированию, обзору и ретроспективе должны происходить надлежащим образом. Вы можете выбрать подход, больше похожий на Scrum, где это происходит регулярно. Или вы можете выбрать подход, при котором они происходят по мере необходимости.
Если у вас есть приличный бэклог, хорошие определения «готово» и «готово» для историй и хорошие привычки в отношении планирования, обзора и ретроспективы, вы сможете масштабировать свой процесс. Если ваша команда растет, вы можете рассмотреть возможность внедрения такой структуры, как Scrum. Если вы начнете расширяться до нескольких команд, вы можете рассмотреть другие фреймворки, такие как Nexus или LeSS, для масштабирования Scrum. Вы также можете узнать из Disciplined Agile Delivery, как адаптировать и развивать свой процесс.
Алан Лаример