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


13

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

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

Можливо, інші більш конкретні питання:

  1. Який відсоток часу проекту зазвичай витрачається на етапах планування до розробки?

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

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

Будь-який досвід, який ви готові поділитися, був би приголомшливим!

Відповіді:


10

Буквальна відповідь на "як правильно визначено?" є

Досить чітко визначений, що можна почати.

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

Досить чітко визначений, що ви можете визначити пріоритет спринтів.

Я маю на увазі визначення випадків використання,

Завжди корисний. Але не всі . Ви повинні розставити пріоритети та висвітлити важливі випадки використання. Інші випадки використання будуть висвітлені у наступних випусках. Деякі випадки використання будуть настільки низькими пріоритетними, що їх ніколи не буде виконано.

аналіз ризику,

Взагалі марна трата часу.

малювання схем класу тощо.

Якщо це допомагає.

Який відсоток часу проекту зазвичай витрачається на етапах планування до розробки?

Вона дуже варіюється. Купіть хорошу книгу, як-от Software Engineering Economics, щоб отримати "авторитетні" номери.

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

"вимірюваний". Це майже неможливо визначити.

"кишки". Погана політика.

Питання в тому, "чи ти розумієш, що ти робиш?"

Це не справа. Це питання "Так / Ні".

Це не "вимірювально", оскільки це питання "так / ні".

І, далі, ви повинні розставити пріоритети. Ви не робите все. Досить просто обробити перші кілька спринтів.

Діаграмуєте ви всі класи перед тим, як почати кодувати, або в основному намагаєтесь створити динамічний дизайн з самого початку, очікуючи, що все зміниться?

Ви не можете все знати заздалегідь.

Не намагайся.


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

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

@Tim Post: Гарна пропозиція. Це спосіб визначити "наскільки чітко визначений" у питанні. Це "допоможе вам визначити масштаб та повзучість функції". Не набагато більше, правда?
S.Lott

@Tim Post: "визначити область" вводить в оману. Це означає, що на початку проекту вам доступні певні знання про «сферу застосування», що не відповідає дійсності. Обсяг буде змінюватися протягом усього життєвого циклу проекту, оскільки бізнес потребує змін, оскільки жоден ринок не є статичним.
Рейн Генріхс

@Rein Henrichs: Я трохи змінив відповідь, щоб включити вашу думку. Визначення обсягу достатньо для початку роботи. Мені спокуса додати "і не більше".
С.Лотт

2

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

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

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


"Представник замовника" (роль, яку ви пропонуєте клієнту) - найважливіша роль у всій команді. Якщо ваша команда не може отримати відповіді на питання про товари та бізнес, як вони повинні прийняти правильне рішення?
Рейн Генріхс

Це чудовий момент, дякую! Я не розглядав, як участь клієнта може настільки різко змінити те, що найкраще працює для даного проекту. Однозначно щось, що я маю пам’ятати. Крім того, я ніколи не чув про "Планування покеру", і, схоже, це було б справді цінно.
drewag

2

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

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

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

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

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

Словом, нічого не повинно бути ідеальним. Додайте кілька ідей, поділіться з товаришами і подивіться, чи є те, що написано, має сенс відповідати затребуваним вимогам до товару. Якщо так, то ви в! Щоб зрозуміти, я перейду з простим продуктом для управління клієнтами. Що потрібно?

As a user, I may manage the Customers;
As a system, I persist changes to the underlying data store;
As a user, I need to enter my credentials to be able to manage customers;
As a system, I have to authenticate the user against the Active Directory;

Ваш перший проект може бути таким же простим! Тоді ми можемо побачити, що безпека є важливою складовою нашої системи, чи достатньо важливою є остаточний пріоритет (Y / N)? Це залежатиме від вимог, яким ви повинні відповідати. Скажімо, що тут є найважливіше управління клієнтами. Отже, у наступному спринті нам потрібно вміти керувати клієнтами базовим, але прийнятним способом. Що таке управління клієнтами?

As a user, I may manage Customers;
    -> As a user, I add a customer to the system;
    -> As a user, I change a customer details;
    -> As a user, I delete a customer;
    -> As a system, I flag a deleted customer as being inactive instead of deleting it;
    -> As a user, I need to list the customers;
    -> As a user, I search the customers data bank for a given customer;
    -> ...

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

Я сподіваюся, що це допомагає! =)


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

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

1

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

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

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

Чорт, іноді я навіть не знаю, як це зробити правильно, поки не зроблю це неправильно. Я будую його один раз, зриваю і роблю це знову, тепер, коли знаю як. На цьому етапі я можу скласти досить детальну дорожню карту та перезапустити.


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

1

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

Деякі мови, як-от Java та C ++, потребують більш початкової структури, ніж такі, як Common Lisp чи Python (C ++ більше, ніж Java, тому що рефакторинг у Java простіший). Лео Броді (я думаю, що в «Думаю далі») дав дві поради щодо того, коли розпочати кодування: швидше, ніж у Forth почуватиметься комфортніше, пізніше, ніж хочеться на іншій мові.

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

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


Дякую за перспективу Я не розглядав, як мова та платформа можуть впливати на кращі практики щодо управління проектами. Я, звичайно, кажу в основному про Objective-C, UIKit та AppKit. Однак я також працюю в купі інших мов (C, C ++, C #, Java, Python тощо). Це означає, що я повинен бути обережним, щоб не припустити, що певний метод буде найкращим для всіх проектів, я повинен скоригувати свою методологічну базу на цільовій платформі та мові (і, можливо, вибрати мову, виходячи з цього, якщо у мене є вибір).
drewag

1

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

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


Це якась справді чудова термінологія, дякую! Це, безумовно, найкраще, щоб придумати щось вимірюване. Звичайно, це не ідеально, але, схоже, буде досить легко вирішити, чи є функція товарною та / або додає продукту цінність.
drewag
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.