Як швидке прототипування вписується у спритну методологію?

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

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

Моє запитання полягає в тому, чи швидке прототипування (викидний код) вписується у спритну філософію Наприклад, я люблю Python та його широкий асортимент пакетів. Я бачу можливість втілення багатьох наших ідей дуже швидко за допомогою робочого процесу на основі Python. Однак я думаю, що буде багато уявлень про те, що Python не є «корпоративної якості», і значну частину цієї роботи потрібно буде переписати на Java або, можливо, на C ++.

Однак створення прототипів Python дало б нам багато зусиль для долара, що дозволить нам швидко досягти реальних результатів.

Чи вдалося вам включити швидке складання прототипів - сподіваємось в Python - на міцний спритний робочий процес у корпоративному середовищі?

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

Існують різні випадки, які потрібно вивчити:

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

2. Чи є прототип чимось, що потрібно побудувати для того, щоб краще зрозуміти проблемний простір? Тоді його слід охопити як шип , і зберігаються лише його результати (вихідний код є тимчасовим).

3. Чи є прототип версією 0.x? Mininimum життєздатний продукт ? Потім використовуйте для цього гнучку процедуру. Якщо вам потрібно відновити його іншою мовою, вам, ймовірно, буде краще, якщо ви ставитеся до іншого продукту. Зауважте, що іноді це трактується як спосіб швидкого введення тексту у специфікацію ("це має робити те саме, що і прототип!"). Це дійсно поганий спосіб документування товару, але це, мабуть, краще пояснено як окреме запитання та відповідь :-)

Чи не швидке прототипування (тобто ітераційне та інкрементальне розвиток) не є цілим принципом Agile?

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

І Python не є (якщо це колись було) іграшковою мовою. НАСА та її підрядники використовують Python , і якщо це досить добре для них, це для мене досить добре.

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

Наведене посилання містить достатньо інформації про добрі практики, підводні камені шипів.

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

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

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

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

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

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

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

1) Сприяти спілкуванню

2) Залучайте користувачів до інтерв'ю з рішенням та отримуйте зворотній зв'язок

Caveat:

Прямий зв'язок між UX та інженерами НІКОЛИ не повинен замінюватися артефактами прототипування. Якщо можливо, з'єднання з інженером працює набагато краще, ніж спілкування через посередника (прототип).

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

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

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