Заголовок питання, де інновація стосується менших масштабів творчого прогресу в команді, яка вже успішно працює в Agile.
Найкраща відповідь узагальнена в цій статті про «Дні золотої картки» .
Короткий огляд (перефразоване, і мої власні інтерпретації, які можуть не відображати намірів автора) :
- Розробники можуть визначити цікаві (інтелектуально стимулюючі) цілі розтягування, пов'язані з роботою, над якими вони хотіли б працювати.
- Ці розтягувальні цілі після затвердження колективом (включаючи власника товару) стають «золотими картами».
- Команді рекомендується взяти день для роботи над цими «золотими картами».
- Зазвичай це буває по п’ятницях, тому він стає «днем золотої картки».
- Щодо Scrum, Золоті Картки плануються та відслідковуються так само, як і будь-які інші затримки; команді потрібно буде продемонструвати свої результати.
Щодо застосування "золотих карток" є деякі інші моменти (не в цій статті):
- Не дозволяйте жодному члену команди прийняти все задоволення. Кожного члена команди слід заохочувати витрачати трохи творчого часу, проводячи «день золотої картки» раз на час.
- В той же самий план спробуйте зробити «золоту карту» зусиллями команди (на відміну від сольного завдання) і використайте це завдання як момент соціалізації (побудови команди).
По суті питання, коли інновація стосується досліджень (місяці до років жахливої роботи), які мають реальний ризик не знайти корисного рішення.
Це попереднє питання: Які методи екстремального програмування доцільно використовувати в дослідницькому середовищі? висвітлює значну частину цього питання.
(Відмова: Я написав одну з відповідей на це питання, хоча не вибрану.)
Підсумок полягає в тому, що робота з дослідження програмного забезпечення може бути швидкою; він вимагає від своїх учасників визначити пріоритет на основі нової інформації (поглинаючи відкриті / вивчені ідеї та синтезуючи нову). Це дає вигляд "повільного" лише тому, що "повільно показувати плоди успіху, і лише в тому випадку, якщо це було успішно".
Це питання щодо бета-версії управління проектами - які плюси та мінуси включення менеджера проектів у дослідницьку команду? - також охоплює ті ж підстави.
Духом, так.
Як зазначається у відповіді мувівієля , дух досліджень програмного забезпечення відповідає духу маніфесту Agile. Далі я буду заперечувати, чи можна дослідження високого ризику вписати в Agile як організацію чи методологію управління ("Agile на практиці").
На практиці вам доведеться відповісти на кілька запитань.
Цей список не є вичерпним ...
Ми повинні трохи відстежити, як з'являється Agile Methodology.
Agile Methodology зазвичай використовується, коли є спонсор проекту. Крім того, готовність спонсора фінансувати проект обмежена; Очікується, що деяке програмне забезпечення корисної якості (потенційно доступне для доставки) буде регулярно поставлятися після фінансування проекту протягом певного часу.
Вид дослідницької роботи в цьому питанні стосується "потенційно нерозв'язних починань". Іншими словами, сама природа цього виду роботи передбачає ризик того, що він може в кінцевому рахунку зазнати невдачі, незважаючи на всі наміри та старанність залучених людей.
Це не контрольний список ScrumButt.
Це більше контрольного списку перед польотом, який передбачає, чи краще відмовитись від "Que Sera, Sera"
1. Прозорість вперед. Чи спонсору проекту спонсорують правду про ризиковий характер проекту?
2. Готовність спонсора. Чи спонсор усвідомлює ризик та готовий продовжувати фінансування?
Спонсору необхідно прийняти ризик, який перевищує типові бізнес-проекти або типові проекти Software / IT / Agile. Не кожен спонсор відповідає цим критеріям. Якщо це не підходить, було б добре професіоналу відмовитися від проекту.
3. Прозорість впродовж проекту. Чи спонсор регулярно інформується про справжній статус проекту?
Це полягає в тому, щоб запобігти спробам приховати невдачі або невдалі помилки в проекті шляхом неправильного проміжку часу між оновленнями статусу.
4. Активна участь спонсора. Чи спонсор зацікавлений у тому, щоб дізнатися про тонко-дрібні деталі, злети та падіння, обіцянки та обмеження кожної спроби?
Проблема в дослідженні програмного забезпечення полягає в тому, що може бути багато помилкових приводів - як помилкових позитивних результатів (вважаючи, що підхід спрацює, але він виявився невдалим), так і помилкових негативів (стверджувати, що щось неможливо, лише щоб це спростували хтось інший) .
Agile проекти дозволяють команді (включаючи спонсорів та зацікавлених сторін) брати обчислені ризики. "Розрахований" означає, що особи, які приймають ризик, отримують повну інформацію. Якщо спонсор не бажає дізнатися тонко-дрібні деталі проекту, то спонсор не матиме повної інформації для розрахунку (судження) ризику самостійно.
Навіть якщо спонсор готовий взяти на себе фінансовий ризик, якщо він не бажає також брати на себе ризики прийняття рішень (і приймає наслідки для власного вибору), він також непридатний для таких науково-дослідних проектів з високим ризиком.
5. Чи може дослідницька група показати (продемонструвати) свій прогрес у формі запущеного програмного забезпечення на відміну від слайдів презентації?
Це питання підходить для дослідницьких проектів, де очікується, що кінцевим результатом буде програмне забезпечення. Слайди презентацій можуть бути корисними для пояснення теорій CS, однак вони також можуть неправильно приховувати недоліки в реалізації програмного забезпечення (або повна їх відсутність). Демонстрація програмного забезпечення призначена для запобігання подібним зловживань.
6. Чи може дослідницька група доставити частково цінний програмний продукт, навіть якщо спонсор вирішить припинити фінансування в будь-який час проекту?
Це питання є актуальним лише у кожному конкретному випадку. Деякі дослідницькі проекти є поступовими; вони можуть мати кілька етапів і результатів. Він вимагає, щоб дослідницька група визначила пріоритетність своїх підходів для вибору "перших фруктів з найнижчими звисаннями" або "підходу з найменшими витратами на демонстрацію життєздатності".
Деякі дослідницькі проекти не є поступовими: досягти єдиного, дуже специфічного технологічного прориву. Це хіт чи промах. Для цього типу проектів єдиними додатковими результатами є науково-дослідницька робота та складання прототипів, а може бути й наукові публікації. Ці «неспоживаючі» додаткові результати є, однак, цінними для деяких видів спонсорів, а саме: університетів, агентств з фінансування досліджень та корпорацій з великими іменами, які сподіваються створити академічну доброзичливість.
Однак дослідницькі проекти, що мають такі характеристики, можуть також сприяти підходу "ковбойське кодування", про що йдеться нижче. Це влучно називають "хаками", і вони трапляються в наукових закладах.
Через часовий масштаб більшості академічних досліджень, фінансування наукових досліджень, як правило, забезпечується зобов'язанням одного або декількох років; Фінансування медичних досліджень (академічних та комерційних) може здійснюватися ще довше. З іншого боку, типові дослідження, що фінансуються комерційно, можуть бути припинені без попереднього повідомлення, або ж їхні ресурси (робоча сила) повністю перерозподіляються під інші проекти.
7. Як дослідницька група вимірює шкалу силосу проти крос-функціоналу?
Деякі типи дослідницької групи є висококваліфікованими. Часто це трапляється в «мультидисциплінарних» проектах - бере участь рівно один член з кожної дисципліни. Як результат, жоден член не може взяти на себе завдання іншого члена, навіть не дуже малого, оскільки їхні знання та вміння не перетинаються. Складність також поширюватиметься на комунікації та визначення завдань.
Надзвичайно складені команди все ще отримають користь від деяких ритуалів Scrum, таких як щоденні зустрічі, що проводяться, але окрім "ритуалу", можливо, не буде багато взаємодії. Треба було б дуже товариського спритного тренера, щоб команда розмовляла та вибудовувала довіру.
8. Якщо присутній спритний тренер, чи призначає тренер короткі цикли ітерації, бокс за часом та надання часових оцінок?
Кожна з цих спритних практик створює труднощі для певних типів дослідницьких проектів. Тим не менш, повідомлялося, що деякі кваліфіковані дослідницькі групи змогли застосувати ці практики в передових дослідженнях . Оскільки немає деталей про те, як відбувається спритний тренерський курс у цих командах експертів, ми можемо не знати, як можна було б подолати кожну з цих труднощів.
9. Чи одностайно дослідницька команда голосує за прийняття індивідуального стилю розробки за будь-яку іншу методологію?
Відредаговано: у більш ранній версії використовується фраза «ковбойське кодування», яка натякає на недостатній професіоналізм. Однак існує різниця між розробкою соло та кодуванням ковбоя, і обставини цього пункту контрольного списку можуть зробити сольну розробку законним вибором.
Це запитання показує, що є програмісти, які вважають за краще володіти великою частиною розвитку. Якщо дослідницька група в основному складається з програмістів такого типу, враховуючи, що набір навичок членів команди є незамінним (маючи на увазі попередній пункт силосного силосу), то членам команди, можливо, доведеться надавати те, що вони хочуть, в обмін за їх вміння та працю.
Основна відмінність соло-розробки від кодування ковбоя полягає в тому, що в розробці соло можна застосувати практику, перелічену в тесті Joel: 12 кроків до кращого коду , такі як використання контролю версій, автоматизація побудови та виправлення помилок перед додаванням нових функцій. .
Деякі обставини сприятливі для кожного члена, який здійснює соло-розробку, тоді як деякі обставини сприяють ковбоєвому кодуванню.
Кодовому кодуванню вигідно, якщо кінцевою метою є «зробити крапку», показавши, що щось технологічно можливо. Немає жодних вимог щодо доставки - ні якості - окрім хорошої презентації наступного DEF CON ® .
Заключне питання. Якщо обставини не дозволяють команді Agile провести новаторські дослідження, то як вони використовувати інноваційні технології?
Бізнес як завжди. Нехай інші компанії (або науковці, особи чи команди хакерів , стартапів тощо) спочатку вирішують важку проблему, а потім купують / ліцензують технологію у них. Програма програмного забезпечення працює на цих принципах протягом багатьох десятиліть.
Акцент на демонстрації ранніх дослідних зразків методології Agile змушує команду спочатку шукати існуючі рішення, що добре, адже це може врятувати команду від зайвої роботи.