Чему может научиться один разработчик из Scrum? [закрытый]


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

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

5 12

5 ответов:

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

Ваши индивидуальные рабочие продукты получат те же преимущества, что и команды в scrum:

  • вы получите что-то сделанное каждый {период итерации спринта здесь}, что-то, что вы можете передать и сказать: "это теперь готово".
  • ваша методика оценки начнет улучшаться с отражением и ретроспективы
  • Вы начнете планировать свой день и брать на себя обязательства по выполнению дел, так что ваша оценка ваших возможностей снова увеличится
  • Ретроспективы формализуют улучшение вашего личного рабочего процесса. Вы начнете активно совершенствоваться, устранять и приспосабливаться к вашим индивидуальным потребностям.

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

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

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

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

Для меня самым большим ключом было получение бай-ина от моего руководителя. Это может быть трудно попробовать и иметь какой-то спринт только для того, чтобы он прерывался несколько раз (предположительно, команды XP справляются с этим лучше, но я не думаю, что это делает какой-либо разработчик.). Кроме того, не забудьте включить опытных пользователей (они могут быть тестерами) или сотрудников других отделов, которые могут быть использованы в качестве владельцев продукта. Мне нравится сидеть с другими пользователями и делать тип парного программирования (хорошо, что они не кодируют), где я могу попросить вопросы во время кодирования и делать быстрые демонстрации, чтобы получить обратную связь. Это помогает, когда я изо всех сил пытаюсь создать спецификации, потому что те, кто запрашивает приложение, с трудом говорят мне, что они хотят.

Даже если это только вы в ежедневном противостоянии, это может быть scrum.

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

Добрый день,

Для лучшего результата обучения Scrum-это концепция раннего и частого вовлечения клиента. Таким образом, нет неприятных моментов "это на самом деле не то, что мы хотели", когда вы доставляете клиенту после шести месяцев напряженной работы.

HTH

Ура,