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

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

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

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

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

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

• Читайте більше від Мартіна Фаулера .
• Стратегії в ефективній роботі Майкла Пера можуть бути корисними

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Швидкі прийоми та процеси все ще можуть досягти вас там більш ефективно.

Наприклад:

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

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

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

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

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

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

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

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

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

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

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

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

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

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