Проворное развитие с точки зрения разработчика

Недавно я присоединился к консалтинговой компании Agile по разработке программного обеспечения в качестве своего единственного разработчика интерфейса.

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

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

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

Ответ 1

Райан, прежде всего, это действительно хорошая тема/вопрос. Спасибо, что отправили его на Stack Overflow!

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

Ну, в прошлом я был разработчиком Front End и Scrum Master в организации, которая следовала за Scrum Framework и Agile Principles, но, к счастью, у меня никогда не было такого опыта, который вы описали. Но я могу представить, что это должно быть болезненно для вас. К сожалению, некоторые люди используют Agile и Lean процессы и рамки как инструмент, чтобы продвигаться в политической игре, предлагая использовать его, но то, что они действительно волнует, это их собственное имя и известность, и что в итоге происходит, они не следуют и не отчитываетесь перед Agile, и команда следит за ним. Мне кажется, что это либо политическая стратегия от кого-то выше, либо отсутствие понимания и опыта Agile-принципов. Я думаю, что вашей организации нужен "настоящий" полный рабочий день Agile Coach, не зависящий от более высоких полномочий в вашей организации.

"Было бы интересно получить еще один взгляд на это".

В моем последнем проекте я был Scrum Master из Enterprise Project Team около 30 инженеров. И у меня также есть опыт веб-разработчиков. Мы следовали структуре Scrum и работали в течение 2-недельных итераций. На каждой итерации был список отставаний продуктов, которые были не чем иным, как кучей пользовательских историй, написанных и приоритетных для Владельца продукта. Истории пользователей всегда должны представлять вертикальные срезы продукта, а не горизонтальные. Представьте себе многослойный торт, если вы разрезаете его по горизонтали, вы просто получите один слой за раз или, может быть, два, но вы никогда не получите все слои в куске, но когда вы разрезаете его по вертикали, вы наверняка получите все слои, точно так же, как ваше приложение или веб-сайт или инструмент или что-то еще, возможно, работает на технической архитектуре, которая должна обладать несколькими уровнями, такими как графический интерфейс, уровень безопасности, сервер, база данных, среднее программное обеспечение и т.д. В соответствии с успехом Agile Manisfesto измеряется рабочим программным обеспечением, а работающее программное обеспечение не представляет собой набор статических передних экранов без заднего конца и не представляет собой набор таблиц базы данных без какого-либо внешнего интерфейса. Таким образом, правило, которое я узнал, что вы могли бы предложить или помнить, всегда работает на вертикальных срезах, так что у вас есть потенциально поставляемые продукты на полке для продвижения на производство.

Вкратце - я думаю, что решение вашей проблемы - это правильные истории пользователей, чьи критерии должны быть более похожими на маленькие вертикальные срезы конечного продукта и не строить один горизонтальный срез за раз. Например, это должно быть основано на функциях, например, например, создание функции входа в систему, а не просто создание login.jsp!!

Помните, всегда вырезайте маленькие вертикальные кусочки торта, это на вкус лучше!;)

Ответ 2

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

Вы точно здесь. То, что они просят, противоречит Agile.

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

Как было предложено в его ответе (которое я поддержал), команда Agile должна работать на небольших вертикальных срезах.

Чтобы это хорошо работало, вы должны быть " обобщающие специалисты". Каждый член команды может иметь сильные стороны в определенной области, но должен выполнять определенную работу во всех частях, получая помощь от других членов команды в любой необходимой области.

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

Ответ 3

То, что вы описываете, это не Agile, его кто-то, кто хочет обойти Agile, потому что они не доверяют ему.

Ответ 4

Ответ sjt превосходный, обсудите с вашим мастером/командой, что он/они думают, СОВЕРШЕННО и потенциально может быть передано ему?

Ваша цель в Scrum/XP - создать потенциально поставляемый товар до или до конца спринта, чтобы это означало, что ваши истории пользователей отражают вертикальный срез или трассирующую пулю через продукт, как описано в sjt.