Заглавный вопрос, где инновация относится к мелкомасштабным творческим достижениям в команде, которая уже преуспевает в Agile.
Лучший ответ суммирован в этой статье о «Золотых карточных днях» .
Резюме (перефразировано, и с моими собственными интерпретациями, которые могут не отражать намерения автора) :
- Разработчики могут определить интересные (интеллектуально стимулирующие) растягивающие цели, связанные с работой, над которыми они хотели бы работать.
- Эти растянутые цели, после одобрения командой (включая владельца продукта), становятся «золотыми картами».
- Команде рекомендуется взять день, чтобы поработать над этими «золотыми карточками».
- Обычно это происходит по пятницам, поэтому он становится «Днем золотой карты».
- Что касается Scrum, то золотые карты планируются и отслеживаются так же, как и любые другие элементы невыполненных работ; команда должна будет продемонстрировать свои результаты.
Есть несколько других моментов (не в этой статье), связанных с применением «золотых карт»:
- Не позволяйте ни одному члену команды получить все удовольствие. Каждого члена команды следует поощрять тратить некоторое творческое время, время от времени проводя «день золотой карты».
- В том же духе попробуйте сделать «золотую карту» командным усилием (в отличие от одиночной задачи) и использовать эту задачу как момент общения (тимбилдинга).
Существенный вопрос, где инновация относится к исследованиям (от месяцев до лет ужасной работы), которые имеют реальный риск не найти никакого полезного решения.
Этот более ранний вопрос, какие методы экстремального программирования целесообразно использовать в исследовательской среде? охватывает большую часть основания этого вопроса.
(Отказ от ответственности: я написал один из ответов на этот вопрос, но не выбранный.)
Суть в том, что работа по исследованию программного обеспечения может быть ускорена; он требует от своих участников расставлять приоритеты на основе новой информации (поглощая обнаруженные / изученные идеи и синтезируя новые). Это выглядит как «медленный» только потому, что «медленно показывает плоды успеха, и только если он был успешным».
Этот вопрос о бета-управлении проектами - каковы плюсы и минусы включения менеджера проекта в исследовательскую группу? - также охватывает те же основания.
По духу да.
Как указывалось в ответе Мувисиэля , дух исследований программного обеспечения соответствует духу 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 вынуждает команду сначала искать существующие решения, и это хорошо, потому что это может спасти команду от некоторой избыточной работы.