Скрам несовместим с публичными тендерами?

43

Общественная организация попросила меня провести неофициальный семинар по 101 гибкой разработке, объясняющий термины и концепции Scrum, Kanban и тому подобное. Я работаю в гибкой среде около пяти лет, но я не считаю себя евангелистом Scrum.

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

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

Scrum просто несовместим в такой среде?

Что бы вы порекомендовали этой организации?

bakoyaro
источник
1
Если результат, цена и сроки могут быть сделаны заранее, зачем возиться с гибким процессом?
JeffO
3
Скрам совместим со всем по определению. Парадигма «Команда владеет процессом» позволяет радикально изменить процесс, поэтому Scrum может стать при необходимости водопадом. Быть «проворным» означает НЕ то, что вы должны следовать некоторому процессу с нулевым отклонением. Это означает, что процесс может быть адаптирован к потребностям. Обратите внимание, что этот пункт ЧРЕЗВЫЧАЙНО непопулярен в управлении - им нужны фиксированные процессы, и они будут называть что-либо «гибким», если они подключены к Agile / Scrum / Whзами.
Клоус
3
FWIW, IME, я никогда не видел ничего подобного Sebazzz. В контракте конкретно указано, что должно быть доставлено. Если он не соответствует требованиям, значит, вы еще не закончили. И в этом вся проблема гибких методов «доставь то, что у тебя есть, когда закончатся средства». Это редкий случай, когда вы можете доставить продукт, который выполняет лишь часть того, что нужно клиенту, и на самом деле он имеет ценность для клиента. Обычно это то же самое, что вообще не работает. Отклонения могут быть запрошены, но если это отклонение лишает функциональности, то это почти наверняка сочетается с меньшими средствами
Dunk
2
@ CortAmmon-То, что я видел, правительство делает "умным", но не очень гибким. Они по-прежнему в основном следуют за водопадом, они заключают контракт поэтапно, а не в процессе разработки полного жизненного цикла, как это было в прошлом. Они также более склонны нанимать более одного подрядчика, особенно на этапе проектирования, поскольку это позволяет им на конкурентной основе выбирать лучшее решение, которое они хотят перейти на производственный продукт. Последний этап самый дорогой. Они хотят увидеть, что они получают, прежде чем принять решение о производстве. Частично работающий продукт не победит.
Данк

Ответы:

38

Скрам, вероятно, не подходит для этой организации.

Из руководства Scrum «Scrum - это основа для разработки, предоставления и поддержки сложных продуктов». Он также предназначен для группы из 3–9 членов команды разработчиков, работающих над продуктом, владельца продукта и мастера Scrum (которые могут входить или не входить в группу разработчиков), что в общей сложности составляет 4–11 человек.

Что касается внутренней разработки, вы упоминаете, что у них есть только несколько разработчиков. Если не достаточно большой команды для формирования Scrum Team, то нет смысла использовать весь Scrum. Однако некоторые методы Scrum могут быть полезны для организации.

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

Томас Оуэнс
источник
Отличный ответ. Очень трудно, хотя и не невозможно, заставить организации, подобные описанной ОП, перейти к гибкому подходу.
Мистер Позитив
1
@MisterPositive Вам может не понадобиться исследовательский институт, чтобы стать гибким. Тем не менее, им, вероятно, понадобится иметь возможность взаимодействовать с внешними субъектами, которые являются гибкими при заключении контракта. Они могут видеть преимущества гибкой, наверняка.
Томас Оуэнс
Действительно хорошая часть этого ответа - ИМХО, что он не попадает в ловушку споров о Scrum, не подходящем, потому что «результат, цена и сроки» фиксированы.
Док Браун
1
@DocBrown Может быть, потому что Scrum можно использовать там, где цена и сроки установлены. По моему опыту, когда вы быстро доставляете и демонстрируете вещи заинтересованным сторонам, они понимают, что то, что они изначально думали, что им нужно, и то, что им действительно нужно, это две разные вещи. И тогда они изменят желаемый результат в пределах первоначальной цены и временных рамок.
Томас Оуэнс
Согласен. Программное обеспечение не похоже на то, как архитектор проектирует здание. По сути, это движущаяся цель, земля всегда скользит под вашими ногами. В следующем году прошлогодние усилия выглядят устаревшими.
22

18F, агентство цифровых услуг при правительстве США, проделало большую работу над тем, как правительство может писать контракты, позволяющие использовать гибкие методологии в соответствии с законом, определяя общие результаты, а не подробные требования к тому, как работать должно быть сделано. Некоторые из их ресурсов включают в себя:

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

Понимая эту проблему, Управление по управлению и бюджету и Управление федеральной политики в области закупок дали указание учреждениям прекратить использование SOW и перейти к использованию отчета об эффективности работы (PWS) для приобретения услуг. PWS «должен формулировать требования в общих чертах относительно того, что (результат) должен быть сделан, а не как (метод) это делается». Хорошие сотрудники по контрактам советуют агентствам, что, покупая экспертные услуги, это подразумевает, что вы не самый осведомленный в «как» работа сделана. Как владелец миссии, вы - эксперт в том, «что», должно быть выполнено, но сочетание этих двух факторов ставит под угрозу вашу миссию и усложняет контракт для обеспечения ценности.

По сути, этот подход больше похож на наем поставщика услуг для совместной работы с вами для разработки решения, а не на распечатку страниц подробных спецификаций заранее. Учреждение не будет нанимать архитектора для проектирования нового здания, перечисляя «проект должен быть четырехэтажным с уклоном крыши 37º. На третьем этаже должна быть кухня площадью 237 кв. Футов с четырьмя люминесцентными светильниками, управляемыми движением светочувствительный выключатель, в подвесном потолке. " Скорее, у них был бы контракт с архитектором на предоставление дизайнерских услуг в консультации с клиентом, и он полагался на своего поставщика, эксперта в этой области, для получения конечных результатов.

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

Зак Липтон
источник
3
Это отличный ответ, особенно последние два абзаца. Это действительно отличный способ соединить вещи, которые я не смог собрать в связном виде.
Томас Оуэнс
1
Да, это ответ. Контракт и как он был написан, это проблема. Я не могу ни подтвердить, ни опровергнуть, что в какой-то момент своей жизни я работал на такую ​​организацию или на организацию, похожую на нее, и когда они переключились на более ориентированный на результат контракт, гибкое развитие стало распространяться, как лесной пожар.
Грег Бургардт
Похоже, что «архитектор» должен прежде всего помочь в написании тендера, прежде чем он будет заложен в бюджет и предоставлены временные рамки. Это двухэтапный процесс, вторая фраза которого
12

Звучит типично. Как только тендер был написан, предложения поступили, и один из претендентов получил контракт ... Что касается представителей общественной организации, проект завершен.

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

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

Таким образом, нет никакого конфликта с Agile или Scrum вообще. Это люди, не подбирающие свои роли. Именно так работает правительство.

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

Нет. Это похоже на то, что «наша демократия решила, что к тому времени у нас будет эта система». Что не оставляет места между 100% успеха с одной стороны и 100% неудачей с другой. Обречен с самого начала.

Это также приглашение на рынок, чтобы попросить смешные цены. Не делать проект, потому что это слишком дорого, не вариант, решение сделать это уже было принято до того, как был объявлен тендер.

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

Мартин Маат
источник
5
Это не совсем ответ на вопрос. Что бы вы порекомендовали этой организации?
Филипп
9
Разве это не клише против правительств, которые будут нести ответственность за все неудачи, а не просто конструктивный ответ? Я не знаю в вашей стране, но в моей стране много успешных государственных проектов. Я не смогу передумать, но вот интересная статья, основанная на объективных фактах и ​​независимых наблюдениях: mckinsey.com/industries/public-sector/our-insights/…
Christophe
6
«Вот почему многие из этих проектов терпят неудачу. После того, как они вышли за рамки бюджета». Этот трофей постоянно востребован людьми, продвигающими гибкие процессы. И все же, есть множество успешных компаний-разработчиков, которые не используют ни один из предложенных гибких методов. Они, как правило, делают это без проблем. Во всяком случае, настоящей проблемой является практика найма самого дешевого претендента и не уделяя достаточного внимания прошлой производительности и экспертизе предметной области. Виноват этот процесс - красная сельдь. Успех может быть достигнут любой компетентной командой, используя любой разумный процесс, с которым у них есть навыки.
Данк
ОК, я немного увлекся. Я бы по-прежнему рекомендовал следить за прогрессом и взять на себя эту роль заинтересованных сторон после подписания контракта, полагая, что это в интересах всех. И я не утверждаю, что Agile - это ключ, я утверждаю, что нет конфликта с Agile принципами, и указал на общую основную проблему.
Мартин Маат
Re: «при условии, что это в интересах каждого»: там, где я живу, у нас был очень дорогой долгосрочный проект (для расширения коммунальных услуг), с банкротством строителя (всемирного столетнего мегаполиса). компания) и государственное агентство, принявшее потенциально незаконное законодательство, и клиенты ожидали, что все выручат. В правительстве такого рода вещи не должны происходить, все заинтересованы в том, чтобы все стороны оставались жизнеспособными, этичными и выполняли свои обещания. Не уверен, что процессы могут помочь с этим или нет.
12

Нет, SCRUM не является несовместимым с публичными тендерами. Вы должны четко указать, что вы покупаете в открытом тендере.

«Покупатель рассчитывает купить 10 двухнедельных спринтов разработки от опытной команды SCRUM, состоящей из 5 разработчиков и сертифицированного мастера SCRUM (покупатель будет выполнять роль заинтересованного лица). Спринты будут работать с марта 2018 года по июль 2018 года», - это вполне разумно начало тендера. Вам, конечно, нужно будет перечислить необходимые навыки команды и дать представление о проекте, над которым они будут работать, но вполне приемлемо провести тендер, чтобы нанять команду.

Конечно, вы отказываетесь от «фиксированной области» здесь. В конце концов, это типично для SCRUM. С чуть большим количеством формулировок в тендере (но мы здесь находимся на юридической территории), вы можете разрешить небольшое расширение объема, то есть небольшое количество дополнительных спринтов. Но если вы решите, что вам понадобятся дополнительные 10 спринтов после начальных 10 спринтов, вам, вероятно, потребуется повторный тендер.

MSalters
источник
3
В точку ! Это отличный и точный ответ. На этом вебинаре projectmanagement.com/videos/290684/… официальный представитель правительства США объясняет, как это работает, в деталях. Принцип переноса цели тендера с конечного продукта на услугу разработки также может быть организован в соответствии со многими другими законами о закупках аналогичным образом. Основная сложность заключается в том, что иногда некоторые стороны проявляют консервативное отношение, а не так называемую несовместимость.
Кристоф
1
Таким образом, они нанимают самую дешевую команду, которую они могут найти, и когда проекту требуется больше часов, они нанимают вторую самую дешевую команду, которая берет на себя среднюю разработку? Этот подход предполагает, что клиент оценивает качество команды программного обеспечения, которую он нанимает. Если у них есть такая экспертиза, мне интересно, что им нужно для аутсорсинга контракта?
Меритон - забастовка
@meriton: Большинство тендеров проводятся правительством, которое обычно требует использования самого дешевого квалификационного предложения. SCRUM не меняет этого. Тем не менее, SCRUM ставит владельца продукта в активную роль, что здесь помогает.
MSalters
Однако в случае заключения контракта, как вы предлагаете, SCRUM меняет стимулы для поставщика услуг. Они больше не могут нести ответственность за невыполнение требований, их единственным стимулом является снижение цены при соблюдении буквы квалификационных критериев, но не обязательно их духа. Покупателю легче оценить, соответствует ли программное обеспечение требованиям, чем вероятность того, что команда будет выпускать программное обеспечение, которое соответствует требованиям. Но да, ваш подход - один из лучших способов использования SCRUM в государственном секторе. Я просто хотел упомянуть, почему покупатели могут не захотеть принять его.
меритон
9

Это трудно.

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

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

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

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

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

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

Джереми Френч
источник
3
+1 Я не могу сосчитать, сколько раз работа выполнялась, потому что кто-то принимал явно плохой контракт, а затем использовал эту связь, чтобы продать контракт в нечто, что ближе к тому, что на самом деле хотел клиент.
Корт Аммон
1
Позвольте мне подчеркнуть это - этот ответ говорит не о том, что Scrum несовместим с публичными тендерами, а о разработке программного обеспечения на основе контрактов в целом . Не то чтобы я не согласен.
Док Браун
3

Это зависит, но, вероятно, да.

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

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

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

Cronax
источник
Я собирался написать комментарий как ваше последнее заявление в скобках, но я позволю вам получить кредит :)
3

Что бы вы порекомендовали этой организации?

На данный момент ничего.

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

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

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

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

candied_orange
источник