Как agile выглядит на практике?

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

1). Что имеется в виду под кроссфункциональностью команды. "By the book" требуется, чтобы каждый работник мог взять и выполнить любую задачу. Но реально непонятно как это. Вот есть в реальной команде, допустим, фронтендер, бэкендер, специалист по базам и админ. Предлагается дать админу джаваскрипт код, а фронту потюнить базу? Так все развалится через неделю. Встречал уточнение, что на самом деле нужно добиваться того, чтобы команда в целом могла выполнить любую задачу по проекту, а специалисты внутри пусть будут узкими. Но это, понятно, накладывает серьезные ограничения на выбор задач из бэклога и на использование статистики.

2). Planning poker. Ситуация - два участника называют (и аргументируют) кардинально разные сроки. В "традиционном" менеджменте это решается так: Синьор Вася говорит "За 6 дней сделаем", джуниор Петя говорит "Хватит и 2 дней". Петя аргументирует, после чего Вася либо прислушивается в нему и корректирует оценку, либо говорит "Я старше[UPD: имеется в виду по должности], делаем как я сказал". На этом обсуждение завершается с некоторым результатом. В planning poker предлагается обсуждать, пока они не договорятся до какой-то совместной оценки. А если они за два часа не договорятся, что делать? Говорить, что задача "непонятная" и не брать на спринт? Тогда получается, что джуниор Петя заблокировал важную фичу. Во всех методиках переговоров есть план на случай, если компромисса не удастся достичь. Какой он в planning poker?

3). Нагрузочное тестирование. Это такой особенный вид тестирования, который может занимать, например, несколько суток и по его итогам может понадобиться значительная переделка архитектуры. При этом, когда разработчики реализовывают конкретные user stories они о роизводительности не думают, а в целом к системе требования по производительности должны предъявляться. Где место нагрузочному тестированию в scrum?

4). Парное программирование. Кто-нибудь вообще видел, чтобы такое применялось регулярно, а не в формате "джун смотрит через плечо синьора"? Если видели - скажите название компании, очень интересно.

5). Кто (какой человек) отвечает за факапы/срывы сроков и тэдэ. Ответ "вся команда" (= никто) вряд ли понравится заказчику из реального мира.

6) Кто принимает решения об увольнении и найме сотрудников?

Понятно, что на каждый из этих вопросов можно ответить "Примите душой Agile Manifesto и найдите ответы в себе", однако, хотелось бы узнать как это решается на практике. Понимаю, что тема несколько холиварная, но хотелось бы избежать ответов типа "Ты нифига не врубаешься в эджайл, иди в дворники" или "Все ответы есть в гугле/такой-то книжке". Вопросы понятно, заданы не ради троллинга, а ради знаний.
  • Вопрос задан
  • 3679 просмотров
Пригласить эксперта
Ответы на вопрос 7
@merzlyakovme
1. Ну вы же самите пишете: "Development Teams are cross-functional, with all of the skills as a team necessary to create a Product Increment."
Development Team, as a team и т.д.
Это значит то, что команду нужно грамотно подбирать под проект. Команда должна быть кросс-функциональной, а не каждый в ней. Если вы набрали 5 матерых бэкендщиков, то не нужно их потом винить, что они с фронтендом облажались.
2. Во-первых, если разработчики будут спорить 2 часа, или один другого "унижать", то у вас хватает проблем кроме скрам процессов.
3. Та же ситуация, что и с рефакторингом. Как вы объясните, что часть проекта надо переписать? Т.е. вы все время какое-то гуано ваяли, а теперь осознали? Если уж работаете по скраму, то и product owner должен хорошо в этом разбираться. В разработке всегда хватает задач, которые не дают видимого функционала, которого так хотят видеть на демо, но такие задачи необходимо включать в спринты. + если у вас подразумеваются высокие нагрузки, то необходимо заранее на планировании обсуждать это и вносить эту работу либо в стори, либо создавать новую в бэклоге на будущее.
4. На практике это скорее мозговой штурм. Вы просто садтесь с коллегой и думаете/пишете.
5. По факту отвечает вся команда. Если срыв из-за того, что неправильную эстимацию выставили, так все вместе играли в Planning poker или его альтернативу. Если кто-то пилил задачу весь спринт, а потом сказал перед демо, что не успел, то виноват он и скрам мастер, который не проследил , возможно, повесил слишком большой таск. Если заказчик попросил слишком большую задачу в спринт, а ему никто на это не возразил - ссзб, снова виноваты.
6. Проджет/деливери менеджер.
Ответ написан
@JSmitty
Небольшая ремарка по 2 пункту - скрам предполагает оценку не сроков, а сложности задачи (в попугаях, т.е. SP). Стратегия решения конфликтных оценок может быть такой - средняя оценка по всем карточкам, округленная вверх. Или мода. Максимальные и минимальные оценки объясняются их выставившими участниками, с учетом объяснений команда может переголосовать. Срок же выполнения задачи - варьируется от исполнителя, от его личной скорости (velocity, SP/sprint).
Ответ написан
Комментировать
petermzg
@petermzg
Самый лучший программист
Вы смешали в одну кучу бизнес и разработку программного обеспечения. Отсюда и непонимание.
1. "фронтендер, бэкендер, специалист по базам и админ" Админ точно только косвенно входит в разработку продукта. "специалист по базам" - очень узкая специализация, нужен ли такой для проекта, сможете ли его в полном обьеме загрузить работой на срок проекта? Поэтому Agile и предлагает использовать другой тип работников, более широкого профиля. Хотя при Agile возможно чтобы равномерно были загружены и фронтендер и бэкендер.
2. Ваш пример это скорее психологическая проблема в комманде. Синьор - с заниженной самооценкой, компенсирующий ее на подчиненных. Agile - подразумевает, как вы написали "чтобы каждый работник мог взять и выполнить любую задачу", значит в команде не будет ни Синьор, ни Джуниор.
3. В требованиях к User Story и нужно писать требования по нагрузке и архитектура должна строиться от этой нагрузки.
4. Опять же подразумевается работа программистов одного уровня.
5. Владельца бизнеса никто не отменял. Agile подразумевает "Ретроспектив" и на будущие спринты должны быть учтены срывы текущего, но если команда срывает постоянно, значит нужно смотреть извне команды, что за проблемы внутри. А перед заказчиком отвечает владелец бизнеса и никак иначе.
6. Владельца бизнеса
Ответ написан
k12th
@k12th
console.log(`You're pulling my leg, right?`);
На практике agile выглядит так: после планирования разрабы вежливо выпроваживают бизнес за дверь и начинают писать код. Он им нужен исключительно чтобы бизнес не подкидывал новые гениальные сверхсрочные хотелки, а так-то любой девелопер за исключением совсем уж новичков может организовать себя.

Бизнес думает, что agile ему нужен для контроля, но на самом деле он нужен для -понимания, что нельзя получить все сразу и уже вчера- расстановки приоритетов, котов пасти все равно невозможно.
Ответ написан
@Agranatmark
Agile, очень похож на коммунизм. Имхо, обе идеи крайне утопичны, не учитывают эволюционную психологию, этологию и кучу других аспектов. Управление разработкой ПО включает в себя дикое количество переменных, которые не реально учесть. А заказчики зачастую не понимают во что ввязываются. Будем наблюдатьс куда же это все приведет.
Ответ написан
Комментировать
serega011
@serega011
Как говорят умные люди, agile - узаконенный беспорядок. Примерно так оно и выглядит к сожалению (в наших реалиях, ибо все его неправильно и бездумно делают), с опытом и годами вменяемые люди это прекрасно понимают. Agile, это когда "Хуяк-хуяк, и в продакшн", нормальные методологии они другие:)
Ответ написан
Andrey_Pletenev
@Andrey_Pletenev
Pletenev.com
1) На практике это означает a) Людей в команду желательно подбирать более универсальных, владеющих разными технологиями и без амбиций типа "яжпрограммист, я не буду тестить". b) Если выбирать не приходится и вам достались узкие специалисты и при этом команда постоянная, то занимайтесь ее развитием, расширяя их компетенции. Это долго, но стоит того. с) Если специалисты узкие и даны на короткое время, тогда обходитесь без кроссфункциональности. Это не догма, как и все остальное в скраме.
2) В planing poker не могут участвовать 2 человека. Участвует вся команда. Кроме того на практике джуниор обычно не спорит с сеньором, а прислушивается к нему. По времени планирование спринта - ограничено. (мах 8 часов для больших и сложных спринтов) Скрам-мастер должен следить за тем, чтобы обсуждение шло конструктивно и не буксовало. Если кто-то уперся рогом в землю, не может убедить других и не слушает их аргументы - это не командное поведение. А команда - это основа agile. С ним нужно проводить воспитательную работу. Если это регулярно - возникает вопрос, действительно ли его место в этой команде.
3) Все необходимые виды тестирования должны проходить в рамках спринта. Желательно использовать Continuous Integration и тесты, включая нагрузочные гонять регулярно. Разработчики, реализуя user stories должны думать о производительности, как и о многом другом. Разумеется, требования к производительности должны быть им озвучены.
4) Это не скрам, а одна из практик экстремального программирования. Применял в компании SiberLogic. В случаях, когда было критически важно, несмотря на затраты, быстро и качественно запилить задачу за часы.
5) Коммуникацию с заказчиком в скраме обычно осуществляет продакт. Он же и отвечает перед ним. Команда отвечает перед продактом. На практике в некоторых компаниях перед заказчиком отвечает ПМ, который находится снаружи скрам-команды.
6) За найм и увольнение отвечают те же люди, что и без скрама. Это может быть директор или HR. Иногда этим занимаются ПМы. Однако, скрам-команда может "вытолкнуть" человека, если он в нее не вписывается. Если разговоры по душам не помогают, то человека перемещают в другую команду или в другую компанию :)

По книжкам скрам не внедряется. Если будут еще вопросы, пишите в личку.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы