5 руководящих принципов применения гибкой методологии в ресурсоемких программных средах

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

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

«Подходит ли гибкая методология для исследовательских программных сред?»

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

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

1. Это не все или ничего

В чисто функциональных функциях есть два важных аспекта: правильность и инженерное качество. Команда, как правило, не выполняет функцию, если она не может быть предоставлена ​​правильно и с достаточным качеством. В функциональных особенностях правильность обычно хорошо определяется.

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

Рассмотрим, например, аналитическую функцию, которая включает модель прогнозирования. Без модели предсказание является случайным. В «оптимальной» модели точность прогноза может составлять, например, 95%. Однако концепция оптимальной модели носит чисто теоретический характер, поскольку на самом деле мы не можем оценить точность оптимальной модели, и чтобы приблизиться к этим 95%, требуется много усилий. Часто бывает так, что очень быстро опытный специалист по данным может предложить модель, которая может обеспечить точность 85% или даже 90%. Если предположить, что эта модель реализована с высоким инженерным качеством, остается вопрос правильности: оптимизировали ли мы решение уже полностью или нет?

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

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

2. Создайте буфер, чтобы уменьшить влияние неопределенности.

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

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

3. Создавайте разнородные команды

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

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

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

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

4. Постоянное улучшение (ретроспектива)

Ретроспектива - один из самых сильных аспектов гибкой разработки. Выделение времени на обсуждение способа выполнения работы, а не на саму работу, и адаптация методологии в соответствии с потребностями и желаниями команды в конечном итоге побуждают команды становиться более заинтересованными и самостоятельными и просто улучшают методы работы. С разнородными командами (см. Руководящий принцип № 3) agile становится еще сложнее и имеет более высокие степени свободы. Различная терминология, методы работы, результаты и даже менталитет должны обсуждаться и изучаться всеми сторонами с большим уважением и терпением друг к другу. Чем разнообразнее команда, тем важнее становится глубокая непредвзятая ретроспектива. Переход к гибкости в среде с интенсивным исследованием требует больше времени и итераций по усовершенствованию, а отсутствие необходимого пространства для ретроспективы ставит под угрозу уровень удовлетворенности команды от изменения, вероятность найти какой-нибудь приятный метод реализации и, в конечном итоге, общий успех изменения.

5. Все дело в бизнесе

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

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