Pull to refresh

Comments 27

поскольку product owner у вас не является частью команды, это не scrum. вы можете и дальше называть все эти активности словом «скрам», если видите в этом какую-то пользу, но это какой-то другой процесс. насколько он адекватен? очевидно, что решение инженерной задачи не сводится только лишь к написанию кода. поэтому вопрос не в наличии «активностей», как таковых, а в их эффективности. попробуйте для начала оценить хотя бы это.
Приветствую. Если хотите конструктивно обсудить, разъясните, пожалуйста, что Вы вкладываете в фразу «po является частью команды»?

Что касается терминологии, может, у нас и не скрам, но мы эффективно доставляем пак фичей к сроку. В этом и есть посыл моих статей. Книжная методология — не панацея и не решение всех проблем. Каждая организация должна найти свои активности и свои процессы, которые позволяют максимально эффективно доставить продукт конечным пользователям в срок и с нужным качеством.
если вы изучали scrum, наверно должны это помнить. как вы понимаете, что ваш процесс не просто достаточно эффективен, чтобы укладываться в сроки (которые по предыдущей статье выставляют сами разработчики, и вероятно с учетом всех этих «активностей»), а в самом деле эффективен максимально?
С PO как частью команды вопрос тогда снимается.

Позвольте мне провести аналогию с Вашим вопросом. Это очень похоже на такую критику: бизнес работает с маржинальностью в 40%. Участники бизнеса всем довольны. Приходит критик и говорит, ваша эффективность не максимальна! Так и не надо, если только Вы не хотите поупражняться в решении математической задачи оптимизации «эффективности процессов agile» :)

В этом-то и суть. Баланс между затрачиваемыми на процесс усилиями и выхлопом в виде прозрачности, повышения качества архитектуры кода и т.д. Мы не пытаемся найти максимальную эффективность, мы решаем задачи, которые перед нами ставит бизнес. И решаем их с эффективностью, достаточной для успешного закрытия бизнес-планов.
Может я чего-то не понимаю, но Ваш комментарий вызывает у меня жуткий разрыв шаблона.
В Scrum'е product owner как раз не может быть частью команды.
Team, product owner и scrum master — это три разные роли, и если team и scrum master ещё можно совмещать (scrum master может быть в команде)…

А, упс, вру, я перепутал: это product owner и scrum master не могут быть одним человеком; а product owner может быть в команде и scrum master теоретически может быть в команде.
Но в любом случае, это отнюдь не обязательно — совмещать роли.
Интересно, или что-то недоговариваете, или уже в полном объеме описывайте чем вы там и как занимаетесь.

Кроме этого, благодаря присутствию продуктовых аналитиков, можно изменить приоритеты разработки. Например, одна команда не успевает выпустить функциональность к релизу. Другая команда также не успевает, но аналитик понимает, что бизнес-значимость (business-value) работы первой команды выше, поэтому вторая команда откладывает функциональность, запланированную к релизу и помогает первой команде закончить работу в срок.


не понимаю, если спринт 10 дней, в него входит одна фича/группа фич…

4 человека говорят: мы сделаем определенный пул задач/фич к релизу…

скорее всего были рассуждения и т.п. в кругу этих 4х человек (одна группа разработчиков), они определяли структуры фич, с чего да как фича должна рождаться и как в результате выглядеть…

план построили, начали делать, пройдя пол-пути поняли: мы это и это не успеем…

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

где у меня пробелы после прочтения? )
Вы абсолютно правы!

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

На следующий день, вторая команда-помощник собирается обсуждать аналитику фичи (как бы второй раз), но уже без аналитика, — только тим лид от первой команды. Обсуждают требования, как на груминге (как бы второй раз). И вот тут Вы абсолютно правы. Новая команда смотрит свежим взглядом и тут же находит пару непонятных моментов, которые уточнили у аналитика. В этом как раз видится большой плюс.

Так что не похоже, что остались какие-то пробелы :) С другой стороны, и цикл статей не окончен!
Мне кажется, или статьи пытаются высказать такую мысль: «Менеджеры — это плохо?». Мне лично кажется, выстраиванием командных взаимодействий без менеджера вы решаете какую-то проблему, например, проблему отсутствия в природе нужного количества адекватных менеджеров. Их долго и дорого искать, и на рынке труда очень много самозванцев.
Приветствую. Скорее, посыл статьи: «И без менеджеров возможно». В современном IT мире большинство книг и методологий настаивают на том, что обязательно должен быть в IT структуре *отдельный* человек с функциями менеджера. Я же пытаюсь показать, что возможно организовать эффективную работу без такого человека. Я могу быть не прав, готов спорить. Но пока что спор никак не завязывается :)
Ну а о чем тут спорить… Берем толпу умных ребят, оставляем их в покое — они все равно сделают что-то хорошее. Например, будут писать идеальные программы. Но менеджер нужен для того, чтобы бить их по рукам, не позволяя писать идеальные программы, т.к. это долго, дорого и для бизнеса губительно.
Интересное у Вас восприятие. Продукт овнер поставляет бэклог, команда оценивает. И Вы считаете, что без менеджеров команда будет выходить за сроки? Или менеджер, по вашему, урежет качество взамен большей скорости? В Вашем мире разработчик хочет сидеть и писать идеальные программы, а не доставлять результат конечному пользователю?
У меня специфическое восприятие, но оно коррелирует с реальной действительностью, где за программистами обязательно нужно следить, чтобы дров не наломали. Я не в плохом смысле, я в хорошем — у некоторых бывает такая производительность, что не успеешь отвернуться — вырастают архитектурные монстры с блэкджеком и прочими удовольствиями. За такими нужно приглядывать, чтобы энергия шла в нужное русло. И точно так же про качество — бывают люди, которые хотят добиться наивысшего качества — хорошей производительности, красоты кода, да мало ли чего. За ними тоже нужно присматривать, чтобы они не занимались этим тогда, когда другие вещи горят. Да есть еще куча психологических моментов — неуверенность в себе, или в выбранном подходе, или, как вы уже сказали, банальное непонимание разницы между программой и продуктом. В таком случае иногда нужно просто сказать: «ты справишься» или «не делай этого, это не приведет к хорошему результату». Программа может быть идеальной, но продукт должен доставлять. Поэтому кто-то все равно, так или иначе, принимает эту роль менеджера — человека, который «склеивает» команду, вырабатывает правильные паттерны взаимодействия, пресекает неэффективные/ненужные трудозатраты, поддерживает психологически. Иногда дает «пинка», причем на полном серьезе, некоторые люди мне прям так говорили, что им этого не хватает. В любом случае, человек — существо стадное, идет за лидером. Поэтому кто-то должен вести.
А к чему спорить?

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

Ни для кого не секрет, что в любом проекте и продукте должен выполняться ряд активностей для успешного достижения цели. При этом часть активностей вполне может быть делегирована менеджером другим ролям.
Product owner в данном случае, возможно, стоит называть менеджером по продукту, являющимся внутренним заказчиком для самоорганизующихся команд.

Не заметил в тексте статей, выделена ли у Вас роль scrum master? Лично я воспринимаю эту роль как интегратора/администратора, который мониторит протекающие процессы, проводит изменение процессов, фасилитирует процессы планирования и ретро (с учетом зафиксированных наблюдений) и тем самым разгружает команду для повышения индивидуальной продуктивности.

Если у Вас все так красиво как написано, то можно только порадоваться за реализацию ценностей компании в виде работающих в данный момент процессов, обеспечивающих достаточный уровень качества для удовлетворения ожиданий всех заинтересованных лиц :)
Без менеджеров вполне возможно. Особенно, если команда подобралась ответственная и увлеченная своим делом. Есть только один нюанс — кто крайний? Все?
Интересный Вы вопрос поставили! Но что означает этот вопрос? Кто должен быть наказан в случае ошибки?
Приветствую. Спасибо за статью. Интересный заголовок, сознание невольно продолжает его — с менеджерами могло быть хуже. Из своего скромного опыта могу сказать так. Когда рядом есть опытный менеджер, то возлагаешь на человека определенные надежды, на опыт, разум. И они могут не оправдаться, только и всего. Если такого координатора и опытного человека нет рядом, то нет и надежд, и возможного разочарования. Мне пока везло. И менеджеры помогают.

Есть замечание про книжный Scrum. Не так давно коллега посоветовал прочесть книгу «Scrum и XP: заметки с передовой» m.habrahabr.ru/post/47910. Возможно, Вы читали книгу. В ней подчеркивается, что менеджер не должен вмешиваться в работу команды во время спринта. Роль менеджера раскрывается во время планирования, при расстановке приоритетов. Также менеджер проявит себя если будет обнаружен серьёзный дефект, и одной из команд нужно будет поручить заняться им, в ущерб фичам. Ваши менеджеры, вероятно, так и работают, по книжному — как в этой книге. На других проектах менеджеры могут проявлять интерес к работе команд чаще, чем раз в две недели, и не замыкать на себя работу — наблюдать и помогать. Это же их право, зачем запрещать
А вы не боитесь, что получиться как у Райкина?
… Ребята кто сшил этот костюм?
Выходят 100 человек, становятся в боксерскую стойку и говорят, МЫ!
Все хорошо, пока не нужно будет кому то отвечать за все…
На синхронизации 7 команд стоят по стойке смирно и на вопрос: «Кто сделал?», — отвечают: «Я!», как в Гайдаевском фильме :) Не помню, чтобы кто-то замалчивал ответственность.
Вы не совсем точно поняли мысль.
1. Ситуация когда всем выгодно говорить я
2. Ситуация когда главному выгодно когда говорят я.
3. Ситуация когда никому не выгодно говорить я.
4. А если кому то нужно навредить, или просто сделать назло!
Вы все идеализируете, и всё равное есть тот кто отвечает за ВСЁ и он и есть менеджер!
У вас не отсутствие менеджеров, у Вас КАЖДЫЙ менеджер, то есть все!
:(

Не думаю что напишу что-то новое, но менеджмент присутствует всегда, можно выделить одного человека на эту роль, в небольшой команде роль менеджера будет размазана по всей команде.


Но как правило менеджментом в команде разработки ПО обычно занимается опытный разработчик которому близка эта роль(тим.лид).

1000 человека-часов в месяц? Да ещё по цене разработчика. Да ещё в расчете только чистое время. Это около 10 менеджеров, которы работают фуллтайм на проекте, при этом, так как есть аналитики — менеджеры реально занимаются только управлением. Поэтому реально нужно 2-3 менеджера. Вот и считайте разницу.
Понятно, что менеджеры не заменят спринты, но выгода спорна, и спорно есть ли она вообще
Не очень понял Ваши расчеты. Откуда взялись 1000 человеко-часов работы в месяц? Если это неправильная арифметика из приведенных в статье расчетов, то готов поспорить. Конкретно, как менеджер уменьшит участие команд в активностях вроде стендапов, ретро, демо и синхронизациях? Или при участии менеджера необходимость в этих активностях пропадет?
Можно по подробнее про «Ретро релиза». Понял что это выполнение определенных заданий, но каких именно? И как выглядят результаты от заданий? Как они оцениваются?
Спасибо.
Спасибо за интерес. Постараюсь осветить в отдельной заметке.

Если коротко. Ретро релиза — это как ретро спринта, только для всех команд разом в огромном зале с "+" и "-", которые берутся решать не только члены команды-автора минусов, но и другие могут помочь. Кроме этого, "+" берут на заметку другие команды, т.о. обмениваемся опытом положительным и отрицательным. А еще благодарим коллег за помощь на протяжении релиза :)
Спасибо за ответ! Само понятние «ретро» пришло из методологии Scrum, я так понимаю?

Я бы статью назвал — "как мы вместо одного выделенного менеджера заставили весь отдел разработки и продуктологов заниматься организацией труда"

Sign up to leave a comment.