Одно дело сказать, что гибкие методологии хороши в условиях, когда требования плохо поняты, или в этом значительная новизна . Но следует ли применять его там, где требуются прямые инновации? Если да, то как?
Если то, что вы рассматриваете, неизвестно в отрасли или даже считается невозможным, может быть трудно представить истории пользователей и связанные с ними задачи. Например, было бы полезно Альберту Эйнштейну (или гипотетическому работодателю, о котором он сообщает) разработать теорию общей теории относительности, разбив ее на эпосы, спринты и задачи? Если ответ «да», то какие специальные условия должны были быть включены, чтобы помочь гибкому подходу лучше всего работать с эйнштейновским способом достижения революционного понимания?
Чтобы привести конкретный пример программного обеспечения, представьте, что это 2008 год, и вы хотели бы использовать WCF для предоставления возможностей типа COMET или « длинного опроса ». Все ваши исследования «предыдущей работы» ничего не дают, и вы даже читаете блоггер MSDN, что это невозможно.
Опять же, какие корректировки или «вкус» могут быть внесены в пользовательские истории и задачи, чтобы приспособиться к изобретательности (или смелости?) Этой попытки? Или действительно было бы лучше сделать вывод, что эти усилия настолько новаторские (в 2008 году), что лучше их оставить в качестве неориентированного аналитического центра?
Новатор, который работает в режиме двухнедельного спринта, безусловно, не хочет, чтобы его сбивали каждый раз, когда он отказывается от тупиковой задачи и начинает работать над недавно обнаруженной задачей, которая не была предусмотрена при определении спринта. Аналогичным образом, когда спринт заканчивается, а рабочий код или рабочие подходы не предоставляются, руководство не должно быть сбито с толку. Должен быть способ обозначить усилие как «успех» даже в этих обстоятельствах. Возможно, в одном или трех других спринтах такого рода «тупиковых» занятий новатор может, наконец, наткнуться на то, что работает.
Как Agile позволяет руководству узнать, что каждый спринт был «в порядке», несмотря на инновационные неудачи? Как это сделать так, чтобы график выгорания не выглядел нелепо?
Ответы:
Заглавный вопрос, где инновация относится к мелкомасштабным творческим достижениям в команде, которая уже преуспевает в Agile.
Лучший ответ суммирован в этой статье о «Золотых карточных днях» .
Резюме (перефразировано, и с моими собственными интерпретациями, которые могут не отражать намерения автора) :
Есть несколько других моментов (не в этой статье), связанных с применением «золотых карт»:
Существенный вопрос, где инновация относится к исследованиям (от месяцев до лет ужасной работы), которые имеют реальный риск не найти никакого полезного решения.
Этот более ранний вопрос, какие методы экстремального программирования целесообразно использовать в исследовательской среде? охватывает большую часть основания этого вопроса.
(Отказ от ответственности: я написал один из ответов на этот вопрос, но не выбранный.)
Суть в том, что работа по исследованию программного обеспечения может быть ускорена; он требует от своих участников расставлять приоритеты на основе новой информации (поглощая обнаруженные / изученные идеи и синтезируя новые). Это выглядит как «медленный» только потому, что «медленно показывает плоды успеха, и только если он был успешным».
Этот вопрос о бета-управлении проектами - каковы плюсы и минусы включения менеджера проекта в исследовательскую группу? - также охватывает те же основания.
По духу да.
Как указывалось в ответе Мувисиэля , дух исследований программного обеспечения соответствует духу Agile Manifesto. Далее я буду утверждать, можно ли вписать исследования с высоким уровнем риска в Agile как организацию или методологию управления («Agile на практике»).
На практике вы должны ответить на несколько вопросов.
Этот список не является исчерпывающим...
Мы должны немного рассказать о том, как появилась методология Agile.
Agile методология обычно используется, когда есть спонсор проекта. Кроме того, готовность спонсора финансировать проект ограничена; Ожидается, что какое-то программное обеспечение пригодного к использованию (потенциально отправляемого) качества будет поставляться на регулярной основе после финансирования проекта в течение некоторого времени.
Вид исследовательской работы в этом вопросе относится к «потенциально неразрешимым усилиям». Другими словами, сама природа этого вида работы сопряжена с риском того, что он может в конечном итоге потерпеть неудачу, несмотря на все намерения и усердие вовлеченных людей.
Это не контрольный список в стиле ScrumButt.
Это больше предварительный контрольный список, который предсказывает, будет ли лучше "Que Sera, Sera"
1. Прозрачность заранее. Говорят ли спонсору проекта правду о рискованной природе проекта?
2. Готовность спонсора. Знает ли спонсор о риске и готов продолжать финансирование?
Спонсор должен иметь принятие риска, которое выше, чем типичные бизнес-проекты или типичные проекты Software / IT / Agile. Не каждый спонсор соответствует этим критериям. Если это не подходит, для профессионала было бы хорошо отказаться от проекта.
3. Прозрачность на протяжении всего проекта. Регулярно ли информируют спонсора об истинном статусе проекта?
Это должно предотвратить попытки скрыть неудачи или надвигающиеся сбои в проекте за счет неправильного использования промежутка времени между обновлениями статуса.
4. Активное участие спонсора. Заинтересован ли спонсор в знании мельчайших деталей, взлетов и падений, обещаний и ограничений каждой попытки?
Проблема с исследованиями программного обеспечения заключается в том, что может быть много ложных выводов - как ложных срабатываний (полагая, что подход будет работать, но в итоге он не увенчался успехом), так и ложных отрицаний (утверждение, что что-то невозможно, может быть опровергнуто кем-то другим) ,
Agile проекты позволяют команде (включая спонсоров и заинтересованные стороны) брать на себя рассчитанные риски. «Рассчитано» означает, что принимающие риск полностью информированы. Если спонсор не желает изучать мельчайшие детали проекта, он не будет располагать полной информацией для самостоятельного расчета (оценки) риска.
Даже если спонсор желает взять на себя финансовый риск, если он не желает также принимать на себя риски принятия решений (и принимает последствия по своему выбору), спонсор также не подходит для таких исследовательских проектов с высокой степенью риска.
5. Может ли исследовательская группа показать (продемонстрировать) свой прогресс в виде запущенного программного обеспечения, в отличие от слайдов презентации?
Этот вопрос подходит для исследовательских проектов, в которых ожидается, что конечным результатом будет запуск программного обеспечения. Презентационные слайды могут быть полезны для объяснения теорий CS, но также могут быть использованы неправильно, чтобы скрыть недостатки в реализации программного обеспечения (или полное отсутствие). Демонстрация программного обеспечения предназначена для предотвращения подобных злоупотреблений.
6. Может ли исследовательская группа предоставить частично ценный программный продукт, даже если спонсор решит прекратить финансирование в любой момент проекта?
Этот вопрос актуален только в каждом конкретном случае. Некоторые исследовательские проекты являются дополнительными; они могут иметь несколько этапов и результатов. Требуется, чтобы исследовательская группа расставила приоритеты в своих подходах, отдавая предпочтение «в первую очередь низко висящие плоды» или «подход с наименьшими затратами для демонстрации жизнеспособности».
Некоторые исследовательские проекты не носят постепенного характера: обеспечить единый, очень специфический технологический прорыв. Это хит или мисс. Для проектов такого типа единственными дополнительными результатами являются исследовательская работа и прототипирование, и, возможно, академические публикации. Эти «не расходуемые» дополнительные результаты, тем не менее, ценны для некоторых типов спонсоров, а именно для университетов, агентств по финансированию исследований и крупных корпораций, надеющихся создать академическую доброжелательность.
Тем не менее, исследовательские проекты, имеющие такие характеристики, могут также способствовать подходу «Ковбойское кодирование», как будет обсуждаться ниже. Их удачно называют «хаки», и они происходят в научных кругах.
Из-за временных масштабов большинства академических исследований финансирование научных исследований, как правило, предоставляется на один или несколько лет; финансирование медицинских исследований (академических и коммерческих) может осуществляться на более длительные периоды. С другой стороны, типичные исследования, финансируемые из коммерческих источников, могут быть прекращены без предварительного уведомления, или их ресурсы (рабочая сила) могут быть полностью переназначены для других проектов.
7. Как исследовательская группа измеряет шкалу бункера и кросс-функциональность?
Некоторые виды исследовательской команды очень разрозненные. Часто это происходит в «междисциплинарных» проектах - в них участвует ровно один участник из каждой дисциплины. В результате ни один участник не может взять на себя задачу другого члена, даже очень маленьких, потому что его знания и навыки не пересекаются. Сложность также будет распространяться на связи и определения задач.
Чрезвычайно разрозненные команды по-прежнему получат выгоду от некоторых ритуалов Скрама, таких как ежедневные встречи, но, помимо «ритуала», взаимодействие может не происходить. Потребовался бы очень общительный проворный тренер, чтобы заставить команду говорить и строить доверие.
8. Если присутствует гибкий тренер, назначает ли тренер короткие циклы итерации, боксирование времени и предоставление оценок времени?
Каждая из этих гибких практик создает трудности для определенных типов исследовательских проектов. Тем не менее, сообщалось, что некоторые экспертно-квалифицированные исследовательские группы смогли применить эту практику в передовых исследованиях . Поскольку нет подробностей о том, как происходит гибкое обучение в этих группах экспертов, мы не можем знать, как преодолеть каждую из этих трудностей.
9. Голосует ли исследовательская группа единогласно за принятие стиля разработки Solo над любой другой методологией?
Отредактировано: более ранняя версия использует фразу «кодирование ковбоя», что намекает на отсутствие профессионализма. Тем не менее, существует различие между индивидуальной разработкой и ковбойским кодированием, и обстоятельства в этом элементе контрольного списка могут сделать индивидуальную разработку законным выбором.
Этот вопрос показывает, что есть программисты, которые предпочитают иметь большой кусок разработки. Если исследовательская группа в основном состоит из программистов этого типа, учитывая, что набор навыков членов команды незаменим (ссылаясь на предыдущий пункт бункера навыков), тогда членам команды может быть предоставлено то, что они желают, в обмен за их навыки и труд.
Основное различие между индивидуальной разработкой и ковбойским кодированием заключается в том, что в индивидуальной разработке можно принять методы, перечисленные в «Тесте Джоэла»: 12 шагов к лучшему коду , такие как использование контроля версий, автоматизации сборки и исправления ошибок перед добавлением новых функций. ,
Некоторые обстоятельства будут благоприятствовать каждому участнику, занимающемуся соло-разработкой, тогда как некоторые обстоятельства будут благоприятствовать кодированию ковбоя.
Ковбойское кодирование предпочтительнее, если конечной целью является «поставить точку», показав, что что-то технологически возможно. Нет никаких требований к доставке - ни к качеству - кроме хорошей презентации на следующем DEF CON ® .
Последний вопрос Если обстоятельства не позволяют Agile-команде проводить инновационные исследования, то как они используют инновационные технологии?
Бизнес как обычно. Пусть другие компании (или ученые, отдельные лица или команды хакеров , стартапы и т. Д.) Сначала решают сложную проблему, а затем покупают / лицензируют технологию у них. Индустрия программного обеспечения работает на этих принципах в течение многих десятилетий.
Акцент на показ ранних рабочих прототипов в методологии Agile вынуждает команду сначала искать существующие решения, и это хорошо, потому что это может спасти команду от некоторой избыточной работы.
источник
Вернуться к Agile Манифест :
Ничто в этих ценностях не запрещает инновации. На самом деле, у Agile лучше инновация, чем у Waterfall.
Тем не менее, может случиться, что обычные реализации Agile накладывают некоторые ограничения на программный проект, которые ограничивают инновации, такие как сроки (срок выполнения спринта - крайний срок) или стоимость. Но это не проблема Agile, это проблема текущих рабочих организаций.
источник
Я не думаю, что это так. Agile - это съесть шоколадных слонов - взять на себя большую задачу и разбить ее на управляемые куски, которые можно не только доставлять, но и доставлять регулярно.
Проекты исследовательского типа не вписываются в это - нет, если ваш проект не может быть разбит на маленькие порции, которые можно демонстрировать каждые две недели (или дольше - нигде не сказано, что Agile говорит, что 2 недели - это время, которое требуется вашему спринту, лучший проворный проект, который я когда-либо делал работал на спринте 6 недель)
Я бы не стал это пробовать. Я бы взял кусочки гибких инструментов, которые, как вы думаете, будут работать на вас, и проигнорировал бы те, которые не работают. Слишком много людей думают, что Agile означает «вы должны делать все, что говорится в учебнике по Scrum, и никакое усмотрение не допускается никогда», такой подход очень негибкий.
источник