Як швидко працює під час заміни робочої системи?

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

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

Як ви застосовуєте Agile, коли "найменше корисне підмножина" - це "все це"?

13
Користувачі можуть показувати інтерес або ніколи не отримувати нову функціональність. Це їхній вибір, але в деяких бізнес-налаштуваннях вони можуть мати керівників, які думають інакше.
додано Автор bstpierre, джерело
У мене є запитання, чи ця нова система є прямим дзеркалом існуючого набору функцій, і якщо так, то чому ти міняеш це?
додано Автор Thomas, джерело

7 Відповіді

Різке рішення може бути не , щоб замінити все за один раз, але поступово замінити його.

Поступово введіть нову систему поступово, тримаючи частину старої системи. Стара система не вимикається все за один раз, вона просто зникає. Нові частини забезпечують нову функціональність або інші переваги, тому користувачі з задоволенням використовують їх. Це також менш ризиковано, оскільки у вас завжди є робота 100%.

13
додано
@SteveBennett: Так, це робиться. Це, звичайно, є компромісом. Але виграш значно знижується ризик, і вам потрібно тільки повторити ту частину, яка потребує переробки.
додано Автор Julien Hoarau, джерело
+1 навіть не бачила вашої відповіді тут, перш ніж сказати практично те саме. Великі розум і все;)
додано Автор herbrandson, джерело
@pap Так, рухливий (TM) був збуджений так сильно, що існує небезпека сліпої використання однієї фіксованої методології, не замислюючись про вашу конкретну ситуацію.
додано Автор tim, джерело
+1, щоб показати, що Agile не може бути ідеальним підходом для певних видів реальних реалізацій.
додано Автор pap, джерело
Збереження частин старої системи, що працює, означає витрачати зусилля на розвиток інтеграції зі старою системою, чи не так?
додано Автор Steve Bennett, джерело
Це наш підхід. Проблема з гнучкою в нашому сценарії - спадщина коду - успадкований безлад. Неможливо точно визначити складність історії, коли вони сильно впливають на спадщину. Команда не може легко зірвати спринт завдяки цьому. Ми намагаємося визначити, як боротися з цим у скрамі.
додано Автор toothygoose, джерело

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

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

5
додано

Звільнення невеликих кроків у світі може працювати для проектів greenfield, але навіть тоді невелика кількість функцій може виявитися не надто корисною.

Scrum виступає за те, що після кожного сприту продукту "Потенційно Shippable". Він не повинен бути відправлений, але повинен мати якість передаваного продукту.

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

Ви можете виявити, що нові функції додаються, а старі - знижуються, якщо ви використовуєте відгуки від користувачів.

4
додано
@KrisVanBael це теоретично краще (і безумовно ідеальний), але це ще один із цих "залежить" від питань - деякі старі рішення є дійсно старі (так що хтось дивиться на зміни платформи) або процес проводовий/інтегрований в систему з кінця до кінця, і "біти" можуть бути досить великими.
додано Автор 8128, джерело
Я працював десь там, де оригінал був відправлений на ринок дуже швидко, і тому дизайн був досить поганий. Ми мали ідею розпочати з кращого уявлення про те, що робити, і, сподіваємось, краще кодувати. Це ніколи не йшло вперед, яке було зроблено на краще, тому що витрати на вигоду не були життєздатними. Якщо існуюча система працює, то внесіть невеликі удосконалення в ній за понаднормовий час.
додано Автор Jan Tomka, джерело
+1 це саме те, як ми звернулися до нього. Хоча вся ідея "почати" дуже неподільна. Наскільки важко ви спробували розглянути можливість заміни старого рішення трохи?
додано Автор NoChance, джерело

Я працював над величезною лінією заміни бізнес-додатків для основної національної мережі кабельного телебачення. Розробку нової системи було зроблено за допомогою SCRUM, це було близько 18-24 місячного проекту розвитку для відновлення практично всіх основних підсистем; які наближалися до 10 років.

Існував етап планування, як за 6 місяців до початку розробки, але до нього також звернувся як SCRUM. Саме тут власник продукту пише висококласні магазини та епопеї після існуючого системного аналізу та інтерв'ю з клієнтами.

Існуюча система була надзвичайно стабільною, оскільки пішла в критичний режим технічного обслуговування; Виправлені лише шоу-стопери, виправлені всі, просто зареєстровані в історичних цілях і переконайтеся, що ті самі проблеми не з'являються в новій системі.

Нова система розвивалася, як описано в процесі Agile, це було надзвичайно гладким здебільшого. Коли система заміни досягла певної частки, вона не йшла у виробництво, а в паралельні виробничі випробування. Набір некритичних працівників почав використовувати як системи, щоб підтвердити, що нова система поводилася як стара; Зі старими помилками виправлено, звичайно.

Коли нова система досягла майже 100% нових функцій, вона була розгорнута для загальних паралельних виробничих процесів, що тривало пару місяців.

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

2
додано
Прохолодно Найважливішим у цій історії було наявність працівників, які готові працювати одночасно на обох системах.
додано Автор Steve Bennett, джерело

Я все ще думаю, що гейбіль додасть багато значення в цьому сценарії.

Ви просто визначили кінцеву мету "замінити поточну систему".

Ефективні методи та процеси можуть ще допомогти вам .

Наприклад:

Ви все ще можете доставити в систему ітераційно і в невеликих спринтах.

Ви можете використовувати гнучкі методи для визначення пріоритету роботи після спілкування з ключовими людьми.

Ви можете продовжувати використовувати гнучкий план для планування, спираючись на швидкість спостереження.

Ви все ще можете використовувати гнучкі методи та філософії, такі як поширення знань, TDD, чисте кодування для підвищення якості та внутрішнього дизайну проекту.

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

2
додано

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

Зробіть їм розуміння, що ви не хочете робити це таким чином, тому що ви думаєте, що це буде весело, і ви самотньо почуватиметесь, використовуючи процес водоспаду. Це дасть кращу програму в довгостроковій перспективі.

Ключовим пунктом продажу може бути реалізація цієї однієї зміни при створенні нового додатка, яке вони завжди хотіли, але ніколи не зможе потрапити у стару систему.

0
додано

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

Тоді дилер з доброю репутацією вирішить дати вам блок двигунів автомобілів, доки не заїде автомобіль, який ви замовили. Що ви маєте робити з двигуном автомобіля? Звичайно, я можу підключити деякі компоненти, щоб протестувати його і зробити це працювати, але це дійсно не допомагає мені працювати завтра, де старий рутифікований автомобіль робить.

Отримано, що існує далеко плач, який відрізняється від побудови автомобіля та створення користувальницького програмного забезпечення, але давайте ігнорувати це заради аргументів. Суть розповіді - не здивуватись тим, що клієнт не використовує для поступових змін, коли вони вже мають програмне забезпечення, яке є достатнім для того, щоб зробити роботу зараз. Вона вже заповнює свою потребу в даний час.

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

Може бути, як автомобільний клієнт ви просто хочете подивитися на двигун і оцінити його, щоб переконатися, що ви дійсно збираєтеся отримати те, що ви очікували. На жаль, я дійсно хотів 6-циліндровий двигун замість 4-циліндрового двигуна! Хіба я не казав тобі раніше? Немає проблем, дозвольте внести зміни до заводського замовлення.

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

0
додано
Так, але дотепер я мав на меті дотримуватися метафори, що клієнти автомобілів нічого не знають про двигуни та не можуть сказати вам нічого корисного, якщо дивитись на це. Коли вони перебувають у гіпотетичному режимі, зворотний зв'язок є досить поверховим "ой, схоже, що він буде робити те, що хочемо", і ви не отримуєте багато, поки вони насправді не використовують його вперше для вирішення реальної проблеми.
додано Автор Steve Bennett, джерело