Як дозволити інновації у спритній методології [закрито]


21

Одне сказати, що гнучкі методології є хорошими в умовах, коли вимоги погано вивчені, або що стосується значної новинки . Але чи слід застосовувати її там, де потрібна відверта інновація? Якщо так, то як?

Якщо те, про що ви думаєте, невідомо в галузі або навіть вважається неможливим, можливо, складно уявити користувацькі історії та пов'язані з ними завдання. Наприклад, чи принесло б користь Альберт Ейнштейн (або гіпотетичний роботодавець, про який він повідомляє), розробивши теорію загальної відносності, розбивши її на епоси, спринти та завдання? Якщо відповідь "так", то які спеціальні приміщення повинні бути включені, щоб допомогти спритному підходу найкращим чином співпрацювати зі способом Ейнштейна досягти революційного розуміння?

Для прикладу конкретного програмного забезпечення, уявіть, що це рік 2008, і ви хочете використовувати WCF для надання можливостей типу COMET або " довгого опитування ". У всіх ваших дослідженнях "попередньої роботи" нічого не виходить, і ви навіть читали блогера MSDN, говорячи, що це неможливо.

Знову ж, які коригування чи «аромат» можуть бути внесені в розповіді та завдання користувачів, щоб задовольнити винахідливість (чи зухвалість?) Цього починання? Або справді було б краще зробити висновок, що це так інноваційно (у 2008 р.), Що найкраще залишити його як ненаправлене тренування аналітичного центру?

Новатор, який працює у двотижневих спринтах, звичайно, не хоче, щоб його збивали кожного разу, коли він відмовляється від тупикової задачі і починає працювати над нещодавно виявленим завданням, яке не передбачалося, коли було визначено спринт. Так само, коли спринт закінчується і не виконується робочий код або робочі підходи, новатор не повинен збиватися керівництвом. Потрібен спосіб визначити зусилля "успішними" навіть у цих умовах. Можливо, в одному чи трьох спринтах подібного роду "глухих" пошуків новатор може, нарешті, вдаритися про щось, що працює.

Як спритний дозволити керівництву знати, що кожен спринт був "нормальним", незважаючи на інноваційні зміни? Як це вдається, щоб схема згоряння не виглядала безглуздо?


8
@Liath: Інновація часто потребує часу, щоб випробувати ідеї без тиску, щоб щось показувати кожні два тижні, тобто наприкінці спринту. Короткостроковий зворотний зв'язок часто ставить акцент на "показати щось, незважаючи ні на що" (адже це завжди можливо виправити в майбутньому спринті, якщо клієнт не задоволений), а не "намагайся робити це так, як ти думаєш, що ти повинен це зробити ". "Ви показуєте це, коли воно готове", а не "Ви готуєте його, коли вам доведеться його показати".
Джорджіо

4
Я думаю, що невимушене питання, яке може бути вирішене з цього питання, таке: "Чи має час бокс своє значення в дослідженні програмного забезпечення або високоінноваційних проектах?", А також "Чи є інноваційні проекти з високим ризиком, які не отримують користі від часу -бокс "? (Я читав це з спеціального пошуку Google: agile.conscires.com/2010/03/30/agile-for-research-projects )
rwong


1
Це посилання , приписуване Ксав'є Аматріаїну, також, як видається, пропонує повний пакет ("процес") щодо застосування методології Agile у дослідницьких проектах. Він відрізняється від Scrum, як ми його знаємо, але він дуже далеко вбачає сприйняття Agile цінностей та практик.
rwong

2
Інновації в розробці програмного забезпечення непрості, незалежно від методології, тому що людей навчають (з вагомою причиною, я думаю,) дотримуватися тих речей, з якими погоджується більшість людей. Я думаю, це тому, що інженерія програмного забезпечення не дуже наукова, порівняно з іншими інженерними дисциплінами, в яких ідеї оцінюються за їхніми достоїнствами, а не за їх конформізмом.
Майк Данлаве

Відповіді:


8

Заголовок питання, де інновація стосується менших масштабів творчого прогресу в команді, яка вже успішно працює в 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 змушує команду спочатку шукати існуючі рішення, що добре, адже це може врятувати команду від зайвої роботи.


6

Назад до маніфесту Agile :

  1. Індивіди та взаємодія над процесами та інструментами
  2. Працює програмне забезпечення над всеосяжною документацією
  3. Співпраця з клієнтами щодо укладання договорів
  4. Відповідаючи на зміни протягом наступного плану

Ніщо в цих цінностях не забороняє інновації. Власне, інновації мають краще гніздо з Agile, ніж з водоспадом.

Тим не менш, може статися, що звичайні впровадження Agile покладають певні обмеження на програмний проект, що обмежує інновації, наприклад, терміни (терміни спринту - це термін) або вартість. Але це не проблема з Agile, це проблема з нинішніми робочими організаціями.


3
+ Я думаю, що ти це отримав. Я думаю, що проблема полягає в книгах, які розповідають людям, як це зробити. (Я виявив, що писати дуже важко, не складаючи речі.) Наша команда слідкує за "Agile", і що це означає нескінченні зустрічі. Один учасник просто сказав: "Порахуй мене. Це просто остання примха. Якщо ти мені не потрібен, це добре".
Майк Данлаве

@MikeDunlavey - Мені подобається, як ваша: Наша команда слідує за "Agile" резонує з: Відповісти на зміни, випливаючи за планом .
mouviciel

1
@mouviciel: Я погоджуюся з вашою відповіддю, але тоді я не розумію, що насправді нового про спритні значення: я слідкував за пунктами 1, 2, 4 у всіх своїх проектах задовго до того, як я навіть почув слово спритний, і більшість з людьми, з якими я працював, робили те саме. Ми називали це здоровим глуздом. Отож, термін "спритний" - це лише нове слово для "не бути рабом вашого процесу та використовувати здоровий глузд"? З іншого боку, єдиною реальною різницею, яку я спричинив у моїй роботі, є більше зустрічей та дотримання правил.
Джорджіо

@Giorgio - Так, це я бачу. Найкращі проекти водоспадів, над якими я працював, - це коли керівник команди підтримував здоровий глузд серед розробників і розповідав замовнику гарну історію "V-модель / ISO9001 / величезна документація". Що нового у цінностях Agile полягає в повноваженнях, наданих авторами Маніфесту.
mouviciel

Agile спочатку був маніфестом щодо розробки програмного забезпечення; його вирощували (або мутували) для вирішення широкого спектру ведення бізнесу. Зустрічі - це форма спілкування віч-на-віч, хоча це було б менш ефективно, ніж спілкування один на один через політику та особистий стиль.
rwong

6

Я не думаю, що це робить. Agile - це поїдання шоколадних слонів - прийняття великого завдання та розбиття його на керовані шматки, які можна не тільки доставити, але доставляти регулярно.

Проекти типу досліджень не вписуються в це - якщо тільки ваш проект не може бути розбитий на невеликі шматки, які можна демонструвати кожні два тижні (або довше - нікуди Agile не каже, що 2 тижні - це час, коли ваш спринт повинен пройти, найкращий спритний проект, який я коли-небудь працював над 6-тижневими спринтами)

Я б не спробував цього. Я б взяв шматочки гнучких інструментів, які, на вашу думку, працювали б для вас, і ігнорував би ті, які цього не роблять. Занадто багато людей думають, що Agile означає "ви повинні робити все, що в підручнику з scrum сказано, що ви повинні робити, і жоден розсуд не дозволяється ніколи", такий підхід дуже не спритний.


1
Розбивати великі завдання на невеликі шматки - це не спритна річ. Він використовувався з початку інженерних робіт ще в стародавній Месопотамії та Єгипті, і широко використовується у проектах водоспаду. Якщо він використовується в проектах Agile, це не через його спритний характер, а через розум, успадкований за століття успішних досягнень.
mouviciel

@mouviciel: Правда, але спритний змушує вас розбивати проблеми на шматки, які повинні вписатися в єдиний спринт. Якщо вони цього не роблять (як це часто трапляється в дослідницьких проектах), ви накручуєтесь ... якщо тільки ви не зробите свої спринти набагато довше. Працюючи над складною дослідницькою проблемою, ви не можете передбачити, скільки часу знадобиться, щоб розбити її на досить маленькі шматки: наявність невеликих шматочків означає, що ви в основному вже вирішили проблему.
Джорджіо

@rwong: Чи є якісь гнучкі процеси, окрім Scrum, які не потребують якнайшвидшого зворотного зв'язку та коротких циклів розвитку?
Джорджіо

4
"Занадто багато людей думають, що Agile означає" ви повинні робити все, що в уроці scrum сказано, що ви повинні робити, і жоден розсуд не дозволяється ніколи ", такий підхід дуже не спритний.": Правда, моя попередня команда була набагато спритнішою, коли ми робили водоспад: ми брали потрібні нам шматки і підганяли їх під наші потреби. Потім прийшов спритний коучинг, і нам довелося працювати над книгою: ми втратили більшу частину спритності. ;-)
Джорджо

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.