чтобы лучше понимать работу в команде

а понимание дает кому?

тому кто рассматривает это всё согласно гипотезе

т.е. для абстрактного несуществующего человека в вакууме?

почему ?

для себя же. тоесть меня

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

ок хорошо какую проблему решает парное ?

тупой человеческий фактор

вопрос: должен ли ПМ расписывать детально задачи в JIRA разработчикам?

или тока заголовка достаточно?))

ПМ? задачи? расписывать? это мы про агиле еще? )

если ПМ, то должен)

спеки у нас пишет Бизнес аналитик, потом ПМ должен расписать из спеки, на задачи декомпозировать и назначить на разрабов?

причем тут agile?

а что я оффтоплю?

или в аджайле нет ПМов простите?

просто давно в чат не заходил, думал может поменялось что

классическим пиэмам в агиле места нет

расходимся)

ну в аджайле все сами берут че есть

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

я хочу выработать какоето хотябы

ребят а как быть если команда не хочет проявлять инициативу?) значит не жить нам по аджайлу?

или можно как-то "вылечить"?

уволить парочку самых безинициативных

😁👍

"классическим пиэмам в агиле места нет" Т.е. никак нельзя оформить паспорт проекта, согласовать scope и везти, монтировать железки по вотерфолу, а ПО для железок делать по Scrum, так чтобы они встретились в какой-то точке?

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

Боюсь, что этот переход завершится только тогда, когда будет гибкость на уровне партнеров.

если нет ПМа то кто с разрабами работает по поводу когда готово, следит все ли ок?

про скрам почитайте что-нибудь

ну разрабы же сами не знают сделали они или нет

и кто спеки спишет по скраму? продукт овнер?

должен быть пм который разраба спрашивает ты сделал ?

нет) кароче плохо все у нас чувствую. В полноценно агильной среде мне не приходилось работать.

принципы и манифесты я читал это одно

а реальная практика это другое

нет) кароче плохо все у нас чувствую. В полноценно агильной среде мне не приходилось работать.

так её нигде нет

Дмитрий, серьезно, прочитайте например Scrum Guide, всего 17 страниц и многие вопросы отпадут сами собой) http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-RUS.pdf

спасибочки

почитаю

и кто спеки спишет по скраму? продукт овнер?

Технически Product Owner рассказывает команде чего бы он хотел увидеть. Значит его роль может быть исполнена Бизнес-Аналитиком. что вполне уклаывается в практику "Customer In Team" С другой стороны Компания подписывается под контрактом, а значит у проекта есть сроки. А если есть сроки, то команда может подписаться под сроками. Но находясь внутри команды сложно видеть внешние риски и проблемы. Чтобы увидеть систему в целом нужно быть в надсистеме. Руководитель проекта находится в надсистеме, и может увидеть проблемы. Архитектор мжет выйти за прделы системы и увидеть проблемы. Но они не находятся в команде. В гибком подходе тлко одна роль вне команды: Наставник. Но Наставник не может делать что-то самостоятельно, его задача наставлять команду на путь истинный и помогать команде иногда выходить за рамки системы. Значит, РП может взять роль Наставника. И роль Владельца Продукта. Но есть конфликт: если РП будет применять силовое воздействие он будет плохим Наставником, а если он будет применять молча наблюдать он будет плохим РП. Но если РП будет Лидером, то он сможет быть и тем и другим. главное надевать правильный пиджак.

"Технически Product Owner рассказывает команде чего бы он хотел увидеть" - нет, не он, а клиент

ПМ нет в скраме. В аджайл в вакууме - вполне может быть ПМ.

Задачи подробно в идеале расписывают те, кто их хорошо понимает.

а расписывание задачи входит в половину решения(опять от меня пять копеек мимо кассы)

"Технически Product Owner рассказывает команде чего бы он хотел увидеть" - нет, не он, а клиент

Продакт ограничивает хотелки клиента и приоритезирует

Product Owner может подробно расписать user story, а задачи, для ее реализации может расписать сама команда, если в этом есть необходимость.

о как, спасибо

книгу осилил

на одном дыхании

а теперь вопрос: тестировщики в скрам команде, аля должны быть как разработчики? но выполняют только тестирование?

Тестировщики и есть разработчики

ок

Помогают команде достигать целей, в основном логично - тестированием

Но как полноценные члены команды - и всем другим, чем могут помочь.

а теперь вопрос: тестировщики в скрам команде, аля должны быть как разработчики? но выполняют только тестирование?

В идеальном XP нет тестировщиков, есть техника TDD, BDD всё покрывается автотестами До разработки.

это все конечно идеально) но как показывает практика даже в крупных многих компаниях все далеко не идеально

Как хорошо, что никому идеальный ХР не нужен:)

😁

это все конечно идеально) но как показывает практика даже в крупных многих компаниях все далеко не идеально

это лежит в определении идеального

идеально еще T-Shaped people, которых не найти почти или стоят они дорого

но реально если посмотреть все вообще не так

идеальное это грубо говоря цель

Тестирование не заканчивается покрытием автотестами.

"Технически Product Owner рассказывает команде чего бы он хотел увидеть" - нет, не он, а клиент

В идеальном процессе Клиент это Владелец продукта, он же "Customer In Team". То есть кто-то со стороны Клиента общается с командой, приоритизирует, торгуется о приоритетах, принимает демо. (ворчание) Но кто ж про идеальный процесс то читал? Книжки по XP не переиздаются с 2003 года.

у нас условно есть такой человек

Тестирование не заканчивается покрытием автотестами.

Согласен, Демо = примочное тестирование. И по тем же самым пользоватесльким историям.

но выглядит немного иначе: это некий человек, который общается с клиентом и все его требования анализирует и передает нам

XP - это about programming, как название говорит.

но выглядит немного иначе: это некий человек, который общается с клиентом и все его требования анализирует и передает нам

Если он играет за Клиента, значит он для вашей команды Клиент и Заказчик

А software development - это как минимум about analysis, design, programming, testing. (плюс почти всегда - delivery, monitoring, maintenance). Идеальный XP (возможно) решит задачи программирования и слегка затронет дизайн и тестирование. Но не решит все задачи разработки.

Привет. Есть кто из Минска? Напишите в личку, хотел бы поговорить каково там живется изнутри? А то сделали оффер с релокацией хотелось бы понять как там вправду все.

Как хорошо, что никому идеальный ХР не нужен:)

Сам по себе никому не нужен. Собственнику нужна прозрачноть и высокая скорость разработки. Практики XP это обеспечивают. Коммуникацинная часть обеспечивает прозрачность, а инженерные практики - высокую скорость разработки даже для продуктов с длинным циклом.

А software development - это как минимум about analysis, design, programming, testing. (плюс почти всегда - delivery, monitoring, maintenance). Идеальный XP (возможно) решит задачи программирования и слегка затронет дизайн и тестирование. Но не решит все задачи разработки.

"все" это какие? Определение границ проекта, управление рисками, Управлние заинтересованными сторонами? или что-то иное?

Тестирование хотя бы)

Тестирование хотя бы)

TDD, User story

TDD - это вообще не тестирование. Это инженерная практика программиста.

а тестирование это не инженерная практика программиста ?

Вообще все современные идеи отказа от роли тестировщика сводятся в результате к тому, что "если <...> будут тестировать, то нам не нужна будет роль тестировщика". И "будут тестировать" не равно "будут писать автотесты", разумеется.

Оксюморонная мысль.