Залежить від проекту, якщо ви працюєте окремо над невеликим проектом, це може мати ідеальний сенс проводити ваші наукові дослідження та дослідження як частину розробки. І хоча це не є частиною Agile, звичайно, методологія Agile може бути використана, щоб додати деякий контроль до цього. Однак це робить процес дуже важким для передбачення / або часового проміжку. Це може бути добре, навіть швидше, якщо ви працюєте самотужки над невеликим проектом, який повністю ваш, нехай ваші вимоги розгортаються, коли ви їх вивчаєте. Використовуйте хороші принципи на цьому шляху, будьте послідовними, і вам не потрібно так багато переосмислювати.
У роботі ми використовуємо Kanban, Scrum та більш традиційні підходи до водоспаду. Залежно від проекту, я вважаю, що складні розробки з чітко визначеними передніми вимогами не найкраще підходять для спритного, хоча багато хто не погодиться.
Перш ніж ми розпочнемо роботу навіть над гнучким проектом (все, крім самого простого, що є), ми створюємо деяку документацію. У нас є макет вгору (якщо орієнтований інтерфейс користувача), набір вимог та функціональна специфікація.
Розробці буде запропоновано створити технічну специфікацію з функціональної специфікації, і під час цього процесу ми визначимо технологію та виконаємо будь-які попередні дослідження, які нам потрібні. Цей процес здається мені таким важливим, оскільки він дає можливість побачити прогалини у вимогах / функціональних характеристиках - і дає великі технологічні рішення наперед перед людьми, які мають досвід та системні знання для прийняття таких рішень.
Важливим, однак, є те, що функціональна характеристика може бути переліком точок кулі, а технічні характеристики зазвичай будуть моделлю, з деякими точками кулі та технологічними кермами, можливо, у деяких випадках лише 3 чи 4 сторінки.
Навіть під час виконання спритного проекту ми створюємо документацію:
- Вся документація має вартість.
- Розробка проти рухомих та неправильно визначених вимог високого рівня вимагає витрат.
- Правильний баланс до вищезазначеного залежить від вашого проекту, культури та людей.
- Ми документуємо Тільки вчасно, документи застаріли.
- Ми документуємо ледве чи достатньо.
- Ми не підтримуємо і не оновлюємо ці документи, ми не докладаємо до них великих зусиль. Вони маленькі. Ми розраховуємо викинути їх.
- Ми вигадуємо великі невідомі, такі як технологічні рішення, туманні вимоги та архітектура.
- Ми знаємо, що ми розвиваємо, перш ніж починати.
- Ми довіряємо розробникам приймати обгрунтовані рішення навколо документації та обговорювати будь-які проблеми.
- Ми цінуємо спілкування за допомогою документації, тому ми очікуємо, що всі учасники спілкуються часто.
- Ми документуємо системи (огляд) після розробки, а не протягом, не раніше.
Ви бачите, що в нашому спритному процесі є невеликий водоспад.
Якщо ви працюєте в поодинці, створіть передову модель (схему!), Грайте з і вибирайте технологію, а тоді, коли у вас є ця концепція вимог високого рівня, побігайте вперед і розвивайтесь в гнучкому ітеративному шляху, але враховуйте хороші принципи та послідовність, коли ви йдете, і вам потрібно буде переорієнтовувати менше, більше пере-фактор, як ви йдете.
Але в цілому, якщо є реальна вартість (не хобі), знайте, що ви розвиваєте, перш ніж писати код, але не витрачайте занадто багато часу на написання документації, яка швидко стане зайвою, оскільки ви передумаєте, і повинні передумайте під час розвитку, коли ви станете краще обізнаними. І ваш проект міг би змінити курс, але почати з хорошої, чітко визначеної основи.