Pull to refresh

Comments 27

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

Шутки? Так это все было шуткой?!

Бизнесу кажется, что ему нужно всё. На самом деле это не так, но ему кажется что нужно.

Это не так, но объяснить это бизнесу если не невозможно, то очень трудно. Проще забить и двигаться по вновь намеченному плану.

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

Всего-то? Дать номинальному "владельцу продукта" все полномочия по созданию продукта? Эх, мечты...

Если требования согласовываются до того, как команда разработки о них узнает, то это точно не Agile.

А можете объяснить почему?

Выглядит как карго-культ: "Чтобы был Agile, необходимо ознакомить команду разработки с требованиями до согласования требований. И тогда фичу получиться реализовать за один спринт, а не за 4 (или даже больше, если считать стабилизацию и тестирование)."

Что это за магия такая?

Что это за магия такая?

Agile это не про разработку, а про управление ожиданиями клиента. Разработчики здесь выступают в роли дрессированных животных. Але-оп, и все бросаются пилить важную-срочную-дешевую фичу. Але-оп - и уже пилят другую. Рассказывают, что сменились бизнес приоритеты, хотя по правде - просто зрители что-то заскучали или перестали доверять.

Agile это не про разработку, а про управление ожиданиями клиента.

У меня другая точка зрения. Agile - это тот процесс, без которого эффективная разработка невозможна в принципе.

Как без налаженного конвейра сложно собирать автомобили, так без налаженного Agile сложно пилить задачки.

Я бы даже сказал, что вся наша жизнь - Agile. Только в сфере личных проектов, которая гораздо шире сферы разработки ПО.

Знаю я людей у которых жизнь аджайл)

Женился, родил ребёнка, тут требования поменялись - развёлся, купил абонемент в спортзал - сходил два раза, ещё него естесна есть весь комплект для сноуборда хай класса, но кататься е у нельзя из-за коленки, купил хату в ипотек и через три месяца переехал в Австралию.

Аджайл в жизни – это скорее о гибкости и адаптации, а не о хаотичных изменениях без ретроспективы. Возможно, таким товарищам стоит ввести в свою жизнь роли Product Owner и Scrum Master, чтобы задачи и изменения были более осмысленными и приводили к устойчивому развитию, а не к вечному циклу "спринтов" без достижения "инкрементов" счастья.

Чем принципиально отличается от RUP? Напомню, что итерационность. И от итерации к итерации никто не мешает делать ретро и корректировки

Женился, родил ребёнка

А за премией в лимон баксов он обращался? :)

А если серьезно, то что в такой жизни плохого? Знакомому явно хватает на все его хотелки. Возможно, что он отлично умеет признавать свои ошибки (не отказывается от переезда в Австралию из-за ипотеки, не добивает коленку катанием только из-за наличия комплекта сноуборда хай-класса, не живет с нелюбимой женой ради ребенка).

Вот если бы он раза 3 подряд женился/стал отцом в браке/развелся - можно было бы задуматься о наличии системной ошибки.

Всё кто разводятся по умолчанию богатые? С чего вы так решили?

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

В Австралию улетал, одалживал деньги у родителей. Ему 35 - у него ваще ни чёрта нет, кроме долга по алиментам, наверно.

Ну ла ошибки он признаёт хорошо, вот только результат то где?

Я разве говорил, что ваш знакомый богат? Если он сам рожал, как вы сначала написали, то вполне мог получить премию в лимон баксов.

Вы ещё спросите, зачем совершать ошибки. Я вам отвечу, что без них невозможно жить. И вы, и я совершаем ошибки. Совершали и будем совершать. Пока живые.

Насчет результата вопрос открыт. Может его и нет. А может есть, но не видно. Или результат не материальный. Я с ситуацией не знаком, не могу ничего сказать.

Вопрос в том, что некоторые ошибки можно заранее просчитать и не совершать)

Как без налаженного конвейра сложно собирать автомобили, так без налаженного Agile сложно пилить задачки

Конвейер (manufacturing) это серийное производство, где каждая последующая деталь, выпадающая с конвейера, будет точно такой же как и десятки тысяч предыдущих.

Разработка (development) - штучное производство под конкретные нужды. Здесь требования сильно варьируются и каждое приложение по-своему уникально.

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

Говоря про Agile, часто имеют ввиду Scrum, который пытается натянуть процессы управления конвейером на разработку. Фактически он сводит любую интеллектуальную деятельность к некоему общему знаменателю - таскам, story points, и дедлайнам.

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

Лучше и не скажешь. Хотят прелести одного инструмента, но не учитывают, что он подходит тоже не для всего. И, как пишут в комментариях, натягивают сову на глобус.

Я знаю, что серийное производство и разработка - это разные процессы.

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

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

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

Поэтому для серийного производства важен налаженый (работающий) конвейр, а для разработки - налаженый процесс Agile.

Только я не понял, что вы хотели сказать.

И за что мне слили карму, кстати, тоже не понял. Но слили явно после того, как я отметился в комментариях под этой статьей.

Согласен с тем, что Agile тесно связан с управлением ожиданиями клиента. Часто вижу следующую картину: в рамках водопадной модели все требования прорабатываются до мелочей, а затем их передают команде с предложением "давайте в Agile-формате найдем способ сделать это подешевле". Естественно, команда что-то придумает, но не сможет сделать функционал дешевле, чем это возможно в принципе. Ситуация бы изменилась, если бы команде дали возможность предлагать изменения в функционале, чтобы решить проблему иным, более эффективным с точки зрения баланса функционала и технологий. Это не гарантирует нахождение решения, так что магии нет. Но если требования заранее зафиксированы, шансы решить проблему "побыстрее" стремятся к нулю.

Часто вижу следующую картину: в рамках водопадной модели все требования прорабатываются до мелочей, а затем их передают команде с предложением "давайте в Agile-формате найдем способ сделать это подешевле".

Побуду занудой: в таком процессе предлагаемое вами изменение не изменит сути процесса разработки. Как процесс не был Agile-ом, так он им и не станет.

Agile - это не про поиск самого дешевого решения. Он больше про гибкость (менять продукт в соответствии с новыми требованиями) и возможность добавлять функционал небольшими порциями.

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

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

Детализация требований командой является необходимым, но не достаточным условием

Простите, что? Я никак не могу вас понять, т.к. вы каждый раз говорите о разном.

Смотрим заголовок

Хочешь искоренить Agile? Сформулируй требования

Т.е. заголовок звучит так: Если ты пришел к команде со своими требованиями к продукту, то Agile невозможен.
Но это не так. Контрпример: Аналитик может формулировать прекрасные требования. И дальше команда может реализовывать эти требования по спринтам максимально быстро. И это будет Agile.

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

Дальше вы пишете про согласование (не про формулировку!):

Если требования согласовываются до того, как команда разработки о них узнает, то это точно не Agile.

Это неверно, т.к. выше я уже привел контрпример с нормальным аналитиком и нормальными требованиями.

Дальше в комментарии вы пишете

Часто вижу следующую картину: в рамках водопадной модели все требования прорабатываются до мелочей

Это совсем другая ситуация. Когда на одном планировании распланировали сразу несколько спринтов. 2-6 или больше. И отказываются заниматься перепланированием после завершения первого спринта. Тут я с вами соглашусь, что это не Agile, а имитация. Так как нет гибкости в планировании. Но это совсем о другом. Не то, что вы писали в заголовке. К сформулированным (и согласованным!) требованиям отношения не имеет. И вот здесь я начинаю подзревать, что вы натягиваете сову на глобус.

А вот это совсем из другой оперы:

Ситуация бы изменилась, если бы команде дали возможность предлагать изменения в функционале

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

Детализация требований командой является необходимым, но не достаточным условием.

Детализировать можно после того, как требования согласованы. С моей точки зрения вы опять говорите не о том, что у вас сформулировано в заголовке и в статье. Детализировать и согласовывать - это совершенно разные процессы.

Поэтому у меня и возник вопрос: что это за магия?

Можете еще раз сформулировать с примером, что вы хотели сказать статьей?

Итак, чтобы внедрение Agile/Scrum не превратилось в водопад с частыми итерациями, необходимо вовлечь команду в решение проблем бизнеса.

Ну попробуйте :) Только есть одна проблема, мааааленькая. Команда на 99% вообще не в курсе даже мало мальских деталей бизнеса. А чтобы быть в курсе, иногда надо проработать в домене не один год, и не разработчиком.

Все, приехали. Или вы реально думаете, что взяв условного програмиста, вы мгновенно (ну "тыжпрограмист") получите бизнес-процесс, который подходит всем участникам и не нарушает требования "регуляторов"? Тогда я вас рассстрою. Это часто не так.

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

--------------

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

Продавцам было необходимо видеть в CRM контактные данные потенциальных клиентов, которые можно было найти во внешней системе. Команде разработчиков была поставлена задача доработать CRM для синхронизации данных из этой системы. Однако, после общения с продавцами и понимания их реальных потребностей, команда решила отказаться от первоначально предложенного плана и разработала расширение для Google Chrome. Это расширение позволяло автоматически отображать необходимые данные прямо в формах CRM без манипуляции с данными, упрощая процесс и сокращая время на разработку в несколько раз.

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

--------------------

Пример

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

тоже вызывает вопросы. А с чего бы команда помогла как-то в этой ситуации? Понятно, что можно поговорить, тем более что UI/UX часто рисует выделенный дизайнер, который обязательно советуется с фронт либом. Но я вот не могу понять, причем тут Agile либо его отсутствие. Если дизайн система не очень - это просто потому что она такая, а не потому что методология неверная. Вот и все

----------------

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

Это вообще прекрасно. Давайте каждый раз для фичи решать, какой вариант дизайна компонент использовать.

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

Тем не менее, я добавлю чуточку информации.

Что касается программистов и аналитиков, то действительно, не каждый программист стремится быть аналитиком, и это нормально. Главное – уметь принимать и учитывать обратную связь от разработчиков. Когда они указывают на невозможность реализации того или иного решения, необходимо вести диалог и быть готовым к изменениям требований, а не оказывать давление. К тому же, в команде всегда найдутся те, кто хочет и может влиять на требования, и это ценно.

Пример с расширением для Google Chrome иллюстрирует, что команда может предложить альтернативные решения, которые могут быть более эффективными, даже если они не имеют долгосрочной перспективы. В мире быстрых изменений и неопределённости бизнес-процессов, решения с коротким жизненным циклом могут быть более предпочтительными, чем дорогостоящие и сложные системы, требующие значительных ресурсов для поддержки и модификации. В том примере был именно такой случай: писать дорого или быстро. Время жизни - несколько месяцев. Причем ценность была именно в скорости получения первого результата. Владелец продукта пришел с идеей сделать как в прошлый раз, т.к. технически даже не задумывался о варианте с расширением. Но команда преложила свое, Владелец продукта, хоть и бы не совсем уверен изначально, но в итоге поддержал команду.

Что касается примера с ненужным функционалом выбора региона, он опять же иллюстрирует предыдущий абзац, не более. То, как такое не допустить - отдельная тема и вы немного упомянули.

Так у вас выводы, скаже так, не очень верные :)

Ну смотрите

Итак, чтобы внедрение Agile/Scrum не превратилось в водопад с частыми итерациями, необходимо вовлечь команду в решение проблем бизнеса. Следует исключить из должностной инструкции владельца продукта пункт о необходимости согласования требований с заинтересованными сторонами и предоставить ему полномочия для самостоятельного согласования этих требований на основе диалога с командой. Для бизнеса, не так важно, как будет решена та или иная проблема.

Суть не вовлечение команды, это очень абстрактный посыл

Есть product, которые отвечает за успешность продукта на рынке перед спонсором. Он определяет общее направление куда, согласовывает с внешними игроками. Если его нет - у вас проблема.

Есть аналитик. Он помогает строить продукт, пишет сторьки или как оно там у вас построено, контролирует скоуп. Если его нет - у вас проблема.

Есть архитектор/тимлид, который отвечает за выполнение нефункционалыных требований. Он "не вовлекается", а делает свою работу. Если его нет - у вас проблема.

Есть дизайнер, который определяет дизайн систему, и макеты конкретных экранов. Если его нет - у вас проблема.

Нет команды. Есть конкретные люди и роли, которые должны быть закрыты. Или у вас проблема.

--------------------

Если же коммуникация где-то построена по принципу "я начальник - ту дурак", ну такое - это скорее свойство конкретных людей

-------------------

Про "исключить из должностной инструкции владельца продукта пункт о необходимости согласования требований с заинтересованными сторонами" - даже сказать нечего. Попробуйте что-то выпустить в большо enterprise без согласования, а я посмотрю

Дело не в примерах, а дело в ваших советах. В большинстве случаем они будут скорее вредніми, чем полезными :(

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

Это именно то, о чем вы говорите. Где-то нельзя. А что касается "Попробуйте что-то выпустить в большо enterprise без согласования, а я посмотрю", то я работал с PO, которые умеют даже в таких случаях проявить гибкость и даже на госзаказах гибко (причем реально закрывать, что не придерешься) закрыть требования. Мы с таким, закрыли гос заказ который все считали провальным. Причем заказ делался не под нас, так что к проверке подходили со всей строгостью. Конечно, главный функционал у нас работал как надо, а вот "заградительные" требования, которые пишутся, чтобы не допустить других участников, мы закрыли. И заказчику пришлось их принять. Опять же, не везде и не всегда такое возможно.

Встречный вопрос к "Если его нет - у вас проблема.". Допустим, проблема. Вот все остальные роли ок, а с PO, проблема. Что делать? Вопрос открытый. Я думаю, если вы напишите об этом статью и поделитесь своим опытом, то с удовольствием почитаю. И, думаю, не только я буду благодарен, если раскроете вопрос.

Допустим, проблема. Вот все остальные роли ок, а с PO, проблема. Что делать? Вопрос открытый

Есть практический опыт, когда PO был заменен по причине своей неадекватности. Да, понадобилось определенное время, но оно того стоило.

Секрет успеха был в том, что ПМ обладал внушительным кредитом доверия спонсора и смогла доказать, что PO - главный тормоз прогресса. Понятно, без этапа сбора доказательств это не работает, так как голосовно обвинять бесперспективно

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

UFO just landed and posted this here

Автор забыл, что а) для формирования требований есть бизнес аналитики (иные специалисты) + маркетологи, которые и обсуждают с заказчиками/продакт оунерами, что можно, что не можно, что нужно, что не нужно. Люди, которые не имеют соответствующих знаний и опыта (в данном случае команда, разрабатывающая продукт), не могут сами решать, как делать, какие требования там должны быть - как предлагает автор сей статьи. Если что-то сделать технически не возможно или можно сделать лучше/проще, то это все обсуждается на пленнингах/рифайнментах - то бишь, команда в некоторой степени может "управлять содержанием"; б) продакт оунер это не мальчик на побегушках, ему не нужно каждый раз бегать к своему руководству, чтобы одобрить те или иные требования.

Вы абсолютно верно подметили, что даже в крупных структурах, где продакт-оунеру необходима поддержка аналитиков и маркетологов, можно наладить процесс таким образом, чтобы команда не только выполняла задачи, но и активно влияла на проект, внося свои предложения и получая возможность для обсуждения. В статье я действительно акцентирую внимание на ситуациях, когда требования предъявляются как непреложные истины, "прибитые гвоздями к стенке". Это противоречит не только принципам Agile, но и общепринятым методикам управления разработкой. Например, PMI ясно указывает на необходимость обсуждения требований с командой, что подтверждает важность совместной работы и гибкости в процессе разработки.

А то, что вы пишете про продуакт-оунера, это верно. В моём примере человека наняли, но по факту руководитель этого PO ввёл какой-то неадекватный менеджмент и жёсткие процессы, где не предоставлял PO необходимых полномочий. Собственно, мы c CEO это и исправили впоследствии.

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

ох и тонкая грань. Скорость поставки, конечно же, в моменте возрастет. Но потом будут прибегать юристы, безопасники и прочие корпоративные хранители с выпученными глазами "Вы что тут наворотили!?!?"

Sign up to leave a comment.

Articles