@catwatcher

Как 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 и найдите ответы в себе", однако, хотелось бы узнать как это решается на практике. Понимаю, что тема несколько холиварная, но хотелось бы избежать ответов типа "Ты нифига не врубаешься в эджайл, иди в дворники" или "Все ответы есть в гугле/такой-то книжке". Вопросы понятно, заданы не ради троллинга, а ради знаний.
  • Вопрос задан
  • 1173 просмотра
Пригласить эксперта
Ответы на вопрос 4
  • @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, очень похож на коммунизм. Имхо, обе идеи крайне утопичны, не учитывают эволюционную психологию, этологию и кучу других аспектов. Управление разработкой ПО включает в себя дикое количество переменных, которые не реально учесть. А заказчики зачастую не понимают во что ввязываются. Будем наблюдатьс куда же это все приведет.
    Ответ написан
Ваш ответ на вопрос

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

Войти через TM ID
Похожие вопросы
Вакансии с Моего Круга Все вакансии
Заказы с Фрилансим Все заказы