Наскільки важливо знати функціональність перед кодуванням?

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

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

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

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

Моє запитання - як би ви працювали над розробкою, якщо ви не знаєте функціональності додатка повністю?

ОНОВЛЕННЯ

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

Коротка версія:

Знаючи, що робити ≠ знаючи свого клієнта.

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

Довга версія:

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

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

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

Ось чому функціональні та нефункціональні вимоги повинні писати люди, які повністю розуміють область. Загалом, збирання вимог передбачає одночасно:

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

2. Люди, що спеціалізуються на управлінні проектами,

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

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

Що стосується конкретного випадку, ви описуєте причину проблеми самостійно:

Ми боремося з проектним документом, оскільки вимоги не були б зрозумілими.

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

Знаючи це, ви повинні діяти інакше:

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

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

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

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

Використовуючи Водоспад, Ви зобов’язуєтесь:

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

Поміркуйте, якщо можливо, інший спосіб управління проектом. Agile Software Development має кілька функцій, розроблених для вирішення проблем, з якими стикаєтесь.

Гідне порівняння Водоспад проти Агіле було написане ще трохи назад, давайте взяти з нього пару цитат, які висвітлюють ваші проблеми:

Не вистачає позначки:

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

Прив'язаний...

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

... і неможливо перемістити

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

Де ти зараз - погано; ви не дотримуєтесь вимог замовника, і, якщо ви є винною частиною розробки програмного забезпечення, продуктивність збирається у вікно, недовіра зросте, і все, швидше за все, погіршиться, а не краще.

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

Це не так, як це працює. Одним із предметів моєї нинішньої освіти є аналіз та стосунки із замовником. Основний акцент робився на чіткому визначенні проекту. Уявіть собі це:

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

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

Ось декілька речей, які допоможуть подолати проблеми:

1. Поліпшити спілкування між двома командами. Попросіть іншу команду скласти вимогу до 3 слів, і тоді програміст точно реалізує ці слова. Слова просто повинні бути правильними. Нічого не буде реалізовано без цих слів. Кожне слово дає 2000 рядків коду. Впровадження починається, коли відомо нове слово.
2. Якщо вашим програмістам слово не зрозуміло відразу, вони можуть задати одне запитання . Питання знову має бути правильним. Йому потрібна негайна відповідь - відповідь не може чекати зворотного кроку з іншого боку світу, але це потрібно знати заздалегідь. Реалізація починається одразу після отримання відповіді, і відповідь буде виконана на лист.
3. Якщо під час імплементації існують незрозумілі або нечіткі вимоги, спосіб їх вирішити - спочатку подивитися на (існуючі) 3 слова. Якщо це все ще незрозуміло, тоді програміст робить найкращу здогадку . Будь-яка затримка цього процесу абсолютно заборонена; і звернутися за допомогою до іншої команди - це не правильний спосіб її вирішити - вони вже мали свій шанс змінити вимоги, вирішивши правильні 3 слова.
4. Якщо після цього вимога все ще незрозуміла або неможлива для виконання, правильний спосіб впоратися - це відхилити ті 3 слова, які спричинили неполадки, і перейти до наступних слів. Будь-які відхилені слова будуть зібрані та передані іншій команді, і їм потрібно буде змінити слова перед повторним введенням їх у систему. Відмова від слів завжди змінює термін, і реалізацію потрібно буде планувати заново.
5. Команди повинні бути оцінені на основі кількості відхилених слів. Після виконання вимоги вона фіксується назавжди і більше не може бути змінена . Будь-які спроби змінити вже реалізовані функції будуть відхилені.
6. Актуальною проблемою є те, що вона передбачає, що більше інформації полегшує реалізацію. Це не правда. Чим більше свободи у ваших програмістів, тим простіша реалізація . Стиснення вимог дозволяє передавати велику кількість інформації, не надто обмежуючи те, що дозволено робити програмістам.