Як ви розробляєте програмне забезпечення без критеріїв прийняття?

Як ви спільно розробляєте програмне забезпечення в команді 4-5 розробників без критеріїв прийняття, не знаючи, на що тестують тестери, і з кількома (2-3) людьми, які виступають власником продукту.

Все, що ми маємо, - це схематична «специфікація» з деякими знімками екрана та кількома кулевими точками.

Нам сказали, що це буде легко, тому такі речі не потрібно.

Я в збитку, як діяти далі.

Додаткова інформація

Нам дали жорсткий термін.

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

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

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

Ітераційний процес буде досягти цього добре, без докладних специфікацій.

Просто створіть схематичний прототип, попросіть зворотного зв’язку у замовника, внесіть зміни на основі зворотного зв'язку та повторіть цей процес, поки заявка не буде завершена.

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

Само собою зрозуміло, що ви не збираєтесь працювати таким чином, щоб укласти контракт з фіксованою вартістю або з фіксованим часом.

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

1. Прочитайте ескізи та "схематичні" характеристики, які вам дали.
2. Напишіть власну специфікацію до рівня, достатнього для того, щоб ви могли кодувати. Можливо, доведеться скласти тонну здогадок.
3. Покажіть свою специфікацію замовнику на огляд. Зверніть увагу на деталі, які їм подобаються, та отримайте більше інформації про ті частини, де вони думають, що ви неправильно зрозуміли.
4. Повторіть кроки 2 та 3, поки ви та замовник не синхронізуються.
5. Тепер у вас є відповідна специфікація.

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

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

Власник продукту передав вам прототип; поверніть йому кращих (поки ви не закінчите)

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

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

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

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

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

Зустріч свій термін

Зауважте, що ваші наступні зусилля не будуть класичними "прототипами", як усі, оскільки вони не будуть одноразовими (інакше їх частин не буде). Остання, найбільш спроможна, ітерація, яку ви завершите до завершення терміну, стане вашим результатом.

Ваш термін - найкраще визначена вимога. Майте щось повне і цілісне, що ви зможете доставити вчасно.

Співпрацюйте зі своїми тестерами

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

Дізнайтеся, чи є у тестувальників щось тверде, що їм потрібно надати, як-от документація про тестування, яку ви можете «повернути».

Спробуйте перший дизайн

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

Отримати собі швидкоплинне знайомство з Test First Design і / або тест - розробки на основі і дати вказівки ваших тестерів на процес по мірі необхідності. Для швидкого подібного проекту, вам не потрібно бути експертом у процесі. Але використання перевіреної методики добре відобразиться на вас та ваших тестерів.

Дотримуйтесь стандартів, особливо для інтерфейсу користувача

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

Виберіть стандартний інтерфейс користувача для свого веб-сайту і не налаштовуйте його, якщо / доки не буде доручено. Я не знаю, для якої платформи ви розробляєте, але Bootstrap або Google Material Design - два приклади.

Спілкуйтеся, але не домагайтесь

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

Якщо у вас є питання, опишіть, як ви будете діяти, якщо не отримаєте вказівки. Наприклад:

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

Не панікуйте

Я брав участь у багатьох проектах для людей, які не знали поняття «вимога». Більшість були успішними. Власники рукотворних продуктів дають вам можливість створювати чудові рішення.

Зауважте, деяким власникам проектів у цих проектах було неможливо догодити і ховались за виправданням "Я занадто зайнятий ..." за їх некомпетентність. Але більшість були "в захваті" від кінцевих результатів.

Проект - це акт зменшення невизначеності до досягнення визначеності :

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

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

Це проблема?

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

Відповідь на ці два питання повинна бути у договорі. Або буде предметом переговорів. І замовник повинен прийняти додаткову участь (головний аргумент - це "сміття, сміття поза", хоча я б радив вам настійно представити його більш дипломатично ;-))

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

Крім того, я дуже, дуже, дуже рекомендую вам вести докладний журнал прийняття рішень . Як мінімум ви записуєте все, що хтось вирішив, з датою та списком людей, які були присутніми, коли було прийнято рішення. Ще краще, якщо ви зможете записати, ЧОМУ щось було вирішено таким, яким воно було. Не має значення, чи це файл на вашому ПК, сторінка у вашій інтранет-вікі чи ноутбук на вашому столі. Журнал захищає вас і проект: коли тестер каже, що якийсь предмет "провалюється", ви можете вказати, що таким чином було вирішено з цими людьми, і це не ваша проблема, а між ними та тестувальниками. Якщо це призведе до зміни технічних характеристик, то це добре, але в цей момент вони не можуть сподіватися на те, щоб виконати будь-який термін, який вони мали на увазі, - або вони повинні скоротити область десь в іншому місці.

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

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

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

Не вірте нікому, коли вони скажуть вам, що це буде легко . Іноді це справді так просто, як це звучить, і я можу повірити в це, якщо (і тільки якщо ) я знаю власників продуктів досить добре, щоб повністю вірити, що вимоги дійсно такі ж прості, як вони кажуть, і те, що я був надаються роз'яснення (якщо ні, я запланую сеанс запитань та записів і документую його) Я був у занадто багатьох ситуаціях, коли легко з точки зору операцій надзвичайно важкоз точки зору розвитку, або ви думаєте, що ви повністю зробили, і чуєте слова відчаю («О, до речі, ми про це забули ...»). Приклад ... "Все, що вам потрібно зробити, - це прочитати ці файли PDF із сховища документів", яке під час тестування прийняття перетворюється на "О, ми забули, що деякі з них були прочитані збоку абсолютно непослідовно, і деякі мають неправильний розмір сторінки, а деякі потребують додавання цих трьох сторінок, і нам потрібні всі вони для того, щоб відображати однакові. Це дуже просто виправити, правда? ".

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

Без специфікації у вас командна робота. Іди спритний.

Сядьте з PO та виведіть тіло / кілька невеликих початкових історій. "Ми збираємося доставити саме цей екран, із лише цією кнопкою, яка переходить на" bing! "". Встановіться на деяких змінного струму. Розкажіть історію. Продемонструйте історію. Виходить кнопки повинні бути червоного кольору. Підняти помилку чи нову історію. Доставте ґудзики, котрі гулять і нахиляються. І так далі.

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

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

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

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

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

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