Чи є написання програмного забезпечення за відсутності вимог навиком володіння або ситуації, якої я повинен уникати?

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

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

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

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

Це дуже неоднозначно ...

Я можу сказати дві речі:

1. Є багато дуже обдарованих технічних людей, чия кар’єра припиняється, оскільки вони чекають досконалих вимог. Або вони грають: "Вибачте, не можу цього зробити, не було в вимогах". Реальність вимагає написання дуже складно. Точність, необхідна для забезпечення хороших вимог, на відміну від усього, що більшість ділових людей коли-небудь створювали. Між технологією та бізнесом існує міст, і люди, які змушують інших прийти на 100% шляху їх зустрічі, зазвичай втрачають.

2. Є люди з програмного забезпечення, які вивчають домени настільки ж добре чи краще, ніж їхні клієнти. Ці люди варті своєї ваги золота, навіть якщо вони не на 100% найкращі розробники. Я бачив, як люди із програмного забезпечення передбачають кількісні потреби в маркетингу кращих бренд-менеджерів країни. Вони не були найкращими в кодуванні всіх рішень, але вони були героями, оскільки вони могли перетнути міст.

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

Вимоги - це кроки в подорожі, бачення - напрямок

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

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

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

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

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

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

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

Однак програмні компанії постійно постачають програмне забезпечення, незважаючи на ці недосконалості в процесі. Специфікація ніколи не буде ідеальною. Спеціалізація також неприродна і застаріла. Специфікація на прототип схожа на таблицю логарифмів - це єдиний графік - специфіка є, по суті, нудною брошурою, призначеною для друку, тоді як ви могли замість цього взаємодіяти з інструментом / графіком. Перегляньте http://www.i-programmer.info/news/112-theory/3900-a-better-way-to-program.html для натхнення.

Тепер специфікація хороша, якщо у вас повинен бути контракт на покриття дупи. Але специфіка все ж повинна прийти за прототипом, а не раніше. Ваша робота - розібратися, як зробити прототипи дешевими.

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

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

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

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

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

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

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

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

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

Неможливо написати програму без вимог. Навіть "Hello World" має вимогу: виробляти продукцію. Отже, я думаю, що ви запитуєте про формальні вимоги у вигляді великого стека чогось подібного до UML. А щодо них я зустрічав 2 види людей:

1) Люди, які потребують формальних вимог. Їм потрібно точно сказати, що робити, і в кращому випадку, як це зробити. Вони люблять речення, як-от Процедура А, яка бере аргумент В, виводить C , і вони ненавидять такі: Програма повинна зробити роботу нашого департаменту більш ефективною . Вони, як правило, корпоративні тварини.

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

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

Ви можете НЕ розвивати оперативне програмне забезпечення , не знаючи вимоги; але, у вас може бути приємно хороший удар при розробці того, що ваш досвід говорить вам, що Вимоги є ймовірнимибути. Agile розробка використовує поєднання "інтуїтивних" прийомів, включаючи Правило 80:20 та "відкриття" Вимог шляхом прототипування. Іншими словами, досвідчена команда розробників найкраще здогадується, що потрібно, і виробляє прототип програмного забезпечення. Правило 80:20 говорить, що вони будуть правильними на 80%. Зацікавлені сторони проекту переглядають відчутний прототип. Їх відгуки починають заповнювати 20% пробіл у нашому розумінні Вимог. Отже, по суті, Agile не полягає в написанні програмного забезпечення без будь-яких вимог, а в тому, щоб використовувати свій попередній досвід, щоб сказати: "Ви хочете чогось подібного?" Що в 80% випадків дозволить вам скочити вперед і підтвердити те, що дійсно потрібно швидше, ніж розгортання традиційних процесів вимог.

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