Задать вопрос

Как 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 и найдите ответы в себе", однако, хотелось бы узнать как это решается на практике. Понимаю, что тема несколько холиварная, но хотелось бы избежать ответов типа "Ты нифига не врубаешься в эджайл, иди в дворники" или "Все ответы есть в гугле/такой-то книжке". Вопросы понятно, заданы не ради троллинга, а ради знаний.
  • Вопрос задан
  • 3704 просмотра
Подписаться 18 Оценить Комментировать
Пригласить эксперта
Ответы на вопрос 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. Проджет/деливери менеджер.
Ответ написан
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. Иногда этим занимаются ПМы. Однако, скрам-команда может "вытолкнуть" человека, если он в нее не вписывается. Если разговоры по душам не помогают, то человека перемещают в другую команду или в другую компанию :)

По книжкам скрам не внедряется. Если будут еще вопросы, пишите в личку.
Ответ написан
@MisterBirkin
Посмотрите на то, как строены современные таск трекеры, например WEEEK. В структуре и функциях как раз заложена agile - методология управления проектами. Вот так и выглядит)
Ответ написан
Комментировать
Ваш ответ на вопрос

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

Похожие вопросы