Забавно. Я о вашем первом посте. Вы корректируете цитаты из статьи, добавляете туда свои выводы (нужен DoD кому-то или нет), но подаете все еще как цитату из статьи. И потом это комментируете и выводите «автора» на чистую воду. Не уверен, что вам вообще нужен оппонент для дискуссии, вы пока справляетесь и сами.

По сути.

1. Я так понимаю, ваш условный человек из бизнеса так много сталкивался с айти-проектами, попадал на неустойки и сталкивался с сорванными поставками, что технологию разработки знает лучше, чем профессиональная команда, которую он сам для разработки своего продукта нанял. Верно?

2. А условный программист писал так много непокрытого тестами кода и так мало рефакторил, что начал разбираться в бизнесе? И видел так много смертей от регрессии, что не удосужился объяснить, зачем нужно соблюдать технологию. Причем сам он тестов он не писал, получается, из-за рукожопости менеджмента. Все так?

3. Я не готов стать плакатом. Но этого и не требуется. Я готов работать в рамках своей зоны ответственности, НЕ определять бизнес-цели, но и НЕ позволять деформировать технологию человеку, который в ней НЕ разбирается. А еще я готов объяснять клиенту свой подход в области качества, а не жаловаться, как все ничего не понимают, не говорят по-английски, меняют требования и так далее.

4. Снова подмена понятий. Я не писал, что понимание ВСЕХ вещей должно исходить от Команды. Только той части, которая касается чистой технологии. И статья посвящена именно этому.

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

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

Не согласен. Правда, я поддержал Dmytro Lapshyn в вопросе о АГМ. На даже не зная, что имелось ввиду, деление на Человека КАК и ЧТО — оно не искусственное, это физика процесса. Есть человек из бизнеса, и есть команда, которая в бизнесе не разбирается. Она разбирается в производстве программного обеспечения.
Зачем мне DoD? Затем, что мы должны договориться до одинакового понимания одинаковых вещей. Какая разница, с какой стороны Продакт овнер? Конечно, бизнес-ситуации разные и продукты разные, но как это влияет на то, что технология должна быть ясна и ее надо придерживаться?

Я понял :)

Ну, строго говоря, целью проекта не есть сделать кому-то приятно или неприятно, но, конечно, довольный клиент — это крайне важный элемент. Просто иногда клиент по незнанию или непониманию может делать что-то, что может этому самому проекту навредить.
Я никогда не видел, чтобы клиент стал счастливым благодаря подходу «Делаем все, что он говорит и именно так, как он говорит». Задача клиента — бизнес, наша функция — технология.

А кто говорит про скрывать? Если клиента не расстраивают, как Винни-Пуха, длинные слова, всегда лучше донести до него наш подход. И показать, что мы занимаемся качеством системно.

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

В русском языке между сделано и готово нет никакой разницы. Да, в Scrum принято дифференцировать done и ready, но меня интересовало общее понимание проблемы, а не терминология Scrum.

Я ничего не писал об Acceptance criteria. Это часть требований, которая, по сути, содержит ожидаемую бизнес-ценность функционала. И это как раз не технология, а чистый бизнес. То есть, это тоже ЧТО, а не КАК. К примеру, если у вас стори на разработку модуля оплаты (извините за совершенно заезженный кейс), то Acceptance criteria будет, скажем, успешная оплата картами Visa и Mastercard. Но там ничего нет о том, КАК вы собираетесь проверять этот модуль, какие тесты и другие активности для этого нужны.
Мой акцент был на технологии процесса, а не его бизнес-составляющей, в первую очередь потому, что на практике бизнес очень часто пытается вмешиваться в технологию.

Не думаю, что ставить resolve статус rejected функционалу — это хорошая идея. Уберите ее в беклог или поставьте статус, которые показывает именно отмену.

Думаю, да. Это показывает подход команды в области качества, борьба за которое начинается не с QA, а с разработчика. То есть, качество является встроенным, это не что-то второстепенное сбоку. Мы начинаем о нем думать с самого начала.

Спасибо, для меня очень важна ваша оценка меня как ПМ. А по существу? Ездите на плетке? И как, успешно?

Если вы строите зону с вертухаями, то да. Плетка такой же хороший мотиватор, как клизма — средство от головной боли.

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

Пользоваться своими мозгами и переизобретать велосипед — это не синонимы. Все перечисленные плюсы никакого отношения к наличию или отсутствию спринтов фиксированной длины не имеют.

Мне кажется, цель фиксированного спринта — не только и не столько фиксированный темп разработки, сколько снижение рисков с одной стороны и гибкость с другой. Гибкость не размера спринта, а содержания работ. Даже если продукт внутренний, как в вашем случае, таким же неравномерным становится и фидбек после релизов. Кстати, при такой схеме должно обостряться желание передвинуть релиз на пару дней, если что-то не успели, не так ли?

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

Если релизы раз 5-7 дней, у вас большие организационные потери. Все равно нужно что-то как-то планировать, выкладывать и так далее, времени на саму разработку приходится мало. Если же релиз раз в две недели (близко к размеру спринта), то я вообще не вижу смысла. Каждый раз надо определять его размеры отдельно, это тоже потери и усложнение.

Все ИМХО, конечно.

Technical Excellence и наличие тестов, код ревю и рефакторинга — это не синонимы. Я не видел ни одного проекта за последние 20 лет, у которого возникли проблемы от переизбытка тестов, зато видел десятки, которые ставились под угрозу из-за их отсутствия.

Как можно создать никчемну команду, если вы не умеете пороть митинги?! Я бы добавил несколько советов.

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

2. Перенесите пару раз точное время. Если вовлечены люди из разных часовых поясов, лучше не указывать часовой пояс события вообще.

3. Ни в коем случае не объявляйте агенду заранее. Это может превратить многообещающий ивент в серое, скучное и заурядное событие, на котором нет места новым вызовам.

4. Проследите, чтобы хотя бы каждый третий участник смог подключиться только с плохого 3g. Если нужно, узнайте, кто когда собирался к врачу, на автомойку или в банк.

5. Чем больше участников — тем лучше. Это позволит не упустить ни одну важную деталь. Даже если она не имеет отношения к теме митинга.

6. Один из залогов успеха, в начале митинга все у всех должны поинтересоваться, как дела, и выслушать развернутые ответы.

7. Ни в коем случае не перебивайте спикера и не напоминайте о временных ограничениях. Это всегда звучит оскорбительно.

8. Постарайтесь не спешить с окончательными выводами, даже если они очевидны. Договоритесь о следующем митинге, желательно с другим составом участников, чтобы первые полтора часа через неделю аккуратно ввести всех в курс дела.

9. Никогда не шлите follow-up емейлов. Это архаизм. Все и так всё слышали.

10. Да прибудет с вами Agile!

Давайте посмотрим, что получается в сухом остатке.
У нас 3 продукта, 1 продакт овнер и одна команда. То есть, одна команда работает над несколькими продуктами. Для разнообразия. И для уменьшения количества неэффективных инженеров.
Спринты убрали, потому что начали планировать релизы. И потому что спринты — искусственные временные рамки. В отличие от релизов. Которые естественные.
Команда сама перераспределяет свои ресурсы. Исходя из целей BetterMe.
Один беклог на три продукта.
И елка зажглась! Потому что тестирование релиза — это хорошо, refinement — это хорошо, хорошие user stories — это хорошо, оценка инженерами функционала — это хорошо, и, наконец, аналитика — это тоже хорошо. А фиксированная длина спринта — плохо.
Я правильно уловил суть?

Если мы не говорим об edge кейсах (18 или 60+ лет), то возраст в большей степени категория ментальная, а не физиологическая. Человек может активно обрастать знаниями в 45, а может почивать на лаврах в 28

Сферический HR в вакууме:)

Это справедливо в том смысле, что сейчас доступна практически любая информация — соответственно, при желании получить знания может практически любой. Не нужно тратить время на доступ к ней. Однако и сами знания, и, уж тем более, способность быстро ими овладеть не стоили бы ничего, если бы человек не смог ими воспользоваться на практике.
И тут все упирается в возможность обработки полученных знаний (как 10, 20 и 50 лет назад) — можно за неделю выучить напамять PMBoK, Малкахи и Рубина, но быть совершенно бесполезным.
Безусловно, новые школы будут появляться, а старые терять свое место, однако впереди всегда буду те, кто сможет осознать и понять новые концепции, а не быстро их прочитать и запомнить. А получения качественного навыка без формирования четкой схемы в своей голове — это, мне кажется, утопия.