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

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

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

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

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

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

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

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

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

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

• Улучшение результатов правительства с помощью гибкого формата контракта
• Соглашение о покупке гибкого одеяла
• Модульный контракт (разделение крупных проектов на более мелкие с гибкой разработкой)
• Использует ли ваш проект «agilefall»?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Это трудно.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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