Как вы разрабатываете программное обеспечение без критериев приемлемости?


70

Как вы совместно разрабатываете программное обеспечение в команде из 4-5 разработчиков без критериев приемлемости, не зная, что тестируют тестеры, и с множеством (2-3) человек, выступающих в качестве владельца продукта.

Все, что у нас есть, это отрывочные «спецификации» с некоторыми снимками экрана и несколькими пунктами с маркерами.

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

Я в недоумении, как поступить.

Дополнительная информация

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

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

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

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


33
Я бы сказал, развивай как хочешь. Пока вы чувствуете себя комфортно, отправляясь на встречу и демонстрируя, как ваш продукт соответствует отрывочным «спецификациям» и скриншотам, я думаю, вы в порядке. Конечно, вы всегда можете спросить у создателя спецификации более подробную информацию ...
FrustratedWithFormsDesigner

10
В основном это автономная разработка или «Ковбойское кодирование». Разработчики заполняют детали. Разработчики контролируют большинство. По сути, у вас никогда не будет формальных требований. Разработка, демонстрация стека (ов), сбор отзывов, промывка и повторение.
Джон Рейнор

11
Понимает ли владелец продукта, что это отличный способ обеспечить рост затрат и времени? Не-компьютерные ученые, часто не понимают важность хорошо написанных четких спецификаций. Например, правительство США часто сталкивается с подобными проблемами, когда они меняют ожидания в отношении новой военной техники. Это одна из нескольких причин, почему военная техника часто перегружена и отстает от графика. joelonsoftware.com/2000/10/02/…
nickalh

35
«Нам сказали, что это будет легко, поэтому эти вещи не требуются. ... Нам дали жесткий срок. ... Владельцы продукта не всегда готовы ответить на вопросы или оставить отзыв. никаких регулярных встреч или звонков с ними, и обратная связь может занять несколько дней. " Вы имеете мое сочувствие. Это отличительные признаки: «Не знаю, как работает написание программного обеспечения. Вообще».
jpmc26

13
Вы были настроены на неудачу. Это та вещь, которую нужно перевести в управление. Если у вас не было жестких сроков, вы можете выполнять итерации, пока не добьетесь успеха. Если заинтересованные стороны были доступны для обратной связи, вы могли бы выполнять итерацию достаточно быстро, чтобы (возможно) уложиться в срок. То же самое для того, чтобы на самом деле иметь достаточно подробную спецификацию. Но что-то должно дать . Это та часть, где вы очень мило просите своего босса вытащить свой @ $$ из огня.
Джаред Смит

Ответы:


130

Итерационный процесс будет достичь этого хорошо, без подробных спецификаций.

Просто создайте схематичный прототип, запросите обратную связь от клиента, внесите изменения, основанные на обратной связи, и повторяйте этот процесс до тех пор, пока приложение не будет завершено.

Является ли клиент достаточно терпеливым, чтобы сделать это таким образом, это другой вопрос. Некоторые клиенты и разработчики действительно предпочитают этот процесс; так как клиент всегда практичен, он (в конце концов) получит именно то, что хочет.

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


114
Нужно добавить: «просто убедитесь, что вам платят за час», а не «платят только тогда, когда у клиента заканчиваются идеи, которых не хватает».
Док Браун

22
Также не забудьте документировать то, что думает клиент, так что это, по крайней мере, отражено в заметках. Это может быть не формальный критерий принятия, но это очень важно иметь, когда вы пытаетесь на самом деле сделать следующие шаги ..
enderland

4
@Doc Браун: OP отредактирован, чтобы добавить "Клиент - внутренний" - таким образом, оплата за час, мы надеемся, не проблема.
слеске

8
+1 Следовали этому процессу для многих внутренних проектов и обнаружили, что он работает очень хорошо и, кроме того, в целом экономит время. Один совет - сделать итерации короткими: неделю или две.
Боб Tway

13
Мой опыт показывает, что это хорошо работает, когда причиной отсутствия формальных критериев приемлемости является то, что никто еще не уверен, чего они действительно хотят. Прототипы помогают им формировать мнения, и вы признаете, что перед вами стоит большая неопределенная задача. Но это работает довольно плохо, когда причина в том, что заинтересованные стороны не находят время, чтобы подумать / поговорить / написать о том, что они хотят, или когда заинтересованные стороны сталкиваются с противоречивыми требованиями, которые по политическим причинам они не считают очевидными. Затем прототип просто пинает банку по дороге, и ничего не улучшится, пока вы не найдете крепкую палку.
Стив Джессоп

58

Если то, что вы говорите, является правдой, и спецификация далеко не достаточно хороша для того, чтобы вы даже начали (и вы честны в этой оценке), я рекомендую этот подход:

  1. Прочитайте эскизы и «отрывочные» спецификации, которые вам дали.
  2. Напишите свою собственную спецификацию до уровня, достаточного для того, чтобы вы могли писать код. Возможно, вам придется сделать тонну догадок.
  3. Покажите свою спецификацию клиенту для обзора. Обратите внимание на те части, которые им нравятся, и получите больше информации о тех частях, где, по их мнению, вы ошиблись.
  4. Повторяйте шаги 2 и 3, пока вы и клиент не будете синхронизированы.
  5. Теперь у вас есть адекватная спецификация.

Если ваш клиент был прав, когда он сказал: «Это будет легко», тогда это упражнение должно быть простым.

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


27
Иногда вы можете обмануть клиента, назвав вашу спецификацию «графиком работы» (который его мозг непрограммиста принимает как дружественную и полезную вещь для проекта) вместо «спецификации» (которая, в случае клиентов как этот, кто враждебен всем основным принципам участия в процессе разработки, их мозги непрограммиста думают как утомительный кусок педантичной бумажной работы, которую программисты заставляют их делать без уважительной причины).
Стив Джессоп

Во-вторых, я бы предложил вам написать только техническую спецификацию для разработчика. В противном случае разработчик не сможет начать свою работу. Таким образом, вы можете параллельно сотрудничать с бизнес-командой относительно характера работы, которая будет разработана. Таким образом, как команда разработчиков, так и бизнес синхронизируются друг с другом по требованиям.
Каран

3
your draft specification will quickly illustrate the problem and communicate to them that they were wrong (....) since it will be right in front of them and obvious- Я хотел бы отметить, что клиенты, которые осознают, насколько все это очевидно, являются именно теми клиентами, с которыми у вас никогда не возникнет этой проблемы с самого начала. Или, если выразить это более кратко: решение подразумевает отсутствие проблемы (это парадокс, который я все чаще и чаще признаю во всех сферах жизни) ...
Раду Мурзеа,

1
Есть некоторые люди, которые никогда не «получат это», но по моему опыту это часто помогает показать им пример уровня детализации, который вам нужен, и показать им вид «неправильных» решений, которые вы можете принять, когда требования неоднозначный.
Джон У

18

Владелец продукта вручил вам прототип; верните ему лучшие (пока не закончите)

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

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

Treehouse имеет отличное руководство для этого, в котором делается вывод:

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

Вы можете также предоставить формальную спецификацию, особенно если вы по-прежнему беспокоитесь о том, что вас обвинят в плохом результате. Но вы, вероятно, получите больше отзывов от прототипов.

Соблюдай свой срок

Обратите внимание, что ваши последующие усилия не будут классическими «прототипами», как все, так как они не будут одноразовыми (или их части не будут). Последняя и наиболее эффективная итерация, которую вы выполняете до истечения срока, становится вашим результатом.

Ваш крайний срок - это лучшее из ваших требований. Иметь что-то полное и связное, что вы можете доставить вовремя.

Сотрудничайте с вашими тестерами

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

Выясните, есть ли у тестировщиков что-то твердое, что им нужно предоставить, например, документация для проверки, которую вы можете «вернуть».

Попробуйте протестировать первый дизайн

Поскольку у вас нет формальных требований, получение тестовых примеров для разработки обеспечит некоторую структуру.

Познакомьтесь с Test First Design и / или разработкой, основанной на тестировании, и предоставьте рекомендации своим тестировщикам по мере необходимости. Для такого быстрого проекта вам не нужно становиться экспертом в этом процессе. Но использование проверенной методики хорошо отразится на вас и ваших тестировщиках.

Придерживайтесь стандартов, особенно для пользовательского интерфейса

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

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

Общайтесь, но не надоедайте

Я бы посоветовал отправлять одно письмо владельцу продукта в день. Отправляйте больше, только если это срочно.

Если у вас есть вопросы, опишите, как вы будете действовать, если не получите рекомендации. Например:

Нужно ли пользователям этого приложения получать к нему доступ с мобильных устройств? Сейчас мы предполагаем, что это будет система, предназначенная только для настольных компьютеров и ноутбуков.

Не паникуйте

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

Обратите внимание, что некоторых владельцев проектов в этих проектах было невозможно угодить, и они прятались за оправданием «Я слишком занят, чтобы ...» за свою некомпетентность. Но большинство было «в восторге» от конечных результатов.


Единственное, что не упомянуто, это жесткий крайний срок: будет важно, чтобы что- то было доставлено в эту дату и чтобы оно функционировало (проходило через движения), даже если бы отсутствовали колокольчики, свистки и более быстрые полосы. С этим ограничением все остальные замечания, которые делает @Tim, должны быть очень хорошими
Филип Окли

@PhilipOakley, спасибо за отзыв. Я добавил пункт о том, что процесс итеративного прототипирования должен создавать все более приемлемые «результаты», чтобы избежать пропущенного срока. Дайте мне знать, если это поможет.
Тим Грант

это улучшение. Может быть, даже изменить «Встреча» на «Встреча», чтобы быть более обязательным. Затем, возможно, также добавьте утверждение, что если они дали дату без других вещей, то это становится ключевым требованием, так что следующее «Примечание» имеет контекст. (часто клиенты заботятся только о времени и стоимости, остальное - это косметика и мода, как я уверен, вы знаете ;-)
Филипп Окли

10

Проект - это акт уменьшения неопределенности до тех пор, пока определенность не будет достигнута :

  • В начале всегда есть некоторая степень неопределенности. Иногда это немного двусмысленно в требованиях. Иногда это очень отрывочные. Вы должны будете работать как часть работы.
  • Хитрость заключается в том, чтобы итеративно уменьшить эту неопределенность (объединяя анализ, проектирование и реализацию), улучшая пользовательские истории и внедряя вашу систему.
  • Тестовые случаи / сценарии и критерии приемки должны быть разъяснены одинаково. Они будут способствовать снижению неопределенности в отношении качества и правильности (среди прочего).
  • В конце концов, достигается достаточная уверенность: клиент получает проверенный продукт, который соответствует его потребностям и может быть использован.

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

Это проблема?

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

Ответ на эти два вопроса должен быть в договоре. Или будет предметом переговоров. И заказчик должен принять дополнительное участие (основным аргументом будет «мусор в мусоре», хотя я бы посоветовал вам представить его более дипломатично ;-))


1
Я люблю первое предложение. Недостатком этого является то, что клиент может: 1) не быть уверенным в том, что он хочет, 2) изменить свое решение, 3) хотеть чего-то недостижимого. Но если это на самом деле простой проект, то у него есть все шансы на успех.

1
Это золото.
Бруно Гуардия

8

« Нет регулярных запланированных встреч ». Ну, а почему бы вам не начать планировать регулярные встречи ? Один только тот факт, что у вас есть несколько владельцев продуктов, гарантирует, что ваш проект НЕ будет легким, поскольку у каждого из этих людей будут противоречивые требования, которые ДОЛЖНЫ обсуждаться лично со всеми заинтересованными сторонами.

Кроме того, я действительно очень рекомендую вести подробный журнал решений . Как минимум, вы записываете все, что кто-то решил, с датой и списком людей, которые присутствовали, когда решение было принято. Еще лучше, если вы можете записать, ПОЧЕМУ что-то было решено так, как было. Неважно, файл ли это на вашем ПК, страница в вашей интранет-вики или записная книжка на вашем столе. Журнал защищает вас и проект: когда тестировщик говорит, что какой-то элемент «дает сбой», вы можете указать, что с этими людьми было принято такое решение, и это не ваша проблема, а между ними и тестерами. Если это приводит к изменению спецификаций, тогда все в порядке, но на данный момент они не могут ожидать, что уложатся в какой-то крайний срок, который они имели в виду - или они должны сократить область действия где-то еще.


8

Проект без четких требований, свободного руководства, без определения выполненного (DoD), никто не желает быть ответственным за то, чтобы убедиться, что у вас есть информация, необходимая для своевременного выполнения вашей работы и выполнения их сроков - это рецепт проекта отказ.

Итеративная разработка не является плохим предложением, но требует тесного сотрудничества между владельцами продукта и разработчиками. Постарайтесь привлечь кого-нибудь к себе, сказав: «Мы знаем, что у нас будут вопросы. Кто может регулярно быть на связи, чтобы на них отвечали, чтобы реализация проекта не задерживалась?» Запланируйте регулярное время с кем-то, чтобы рассмотреть прогресс и устранить препятствия. Если они не показывают, или отказываются, то проследите за вежливой письменной перепиской и задержкой документов или не полученными ответами. Если владельцы продукта не могут быть доступны, попросите их предоставить представителя, который может быть.

Кроме того, еще одним отличительным признаком итеративной разработки является то, что изменение требований требует изменения графика времени. Вы не можете взять на себя обязательство соблюдать крайний срок, если не можете разработать график, и вы не можете разработать график, если у вас нет четкого представления о том, что необходимо сделать. Вместо того, чтобы догматически запрашивать спецификацию, просмотрите текущую спецификацию, задокументируйте любые вопросы, которые у вас или команды есть относительно того, как она должна функционировать, назначьте время для обсуждения с владельцами продукта и задокументируйте ответы. Когда вы закончите, у вас будут свои спецификации, основанные на их решениях, с которыми вы затем можете получить согласие владельцев продуктов (в письменной форме). Целью спецификации является устранение неоднозначности и создание DoD, что в точности и может обеспечить сеанс вопросов и ответов. Если есть противопоставление спецификации, не называйте это спецификацией.

Не верьте никому, когда они скажут, что это будет легко . Иногда это действительно так просто, как кажется, и я мог бы в это поверить, если (и только если ) я достаточно хорошо знаю владельцев продуктов, чтобы полностью поверить, что требования действительно такие же простые, как они говорят, и спецификации, которыми я был при условии, что это не требует объяснений (если нет, я планирую сессию вопросов и ответов и документирую ее). Я был в слишком многих ситуациях, когда легко с точки зрения операций невероятно сложнос точки зрения развития, или вы думаете, что вы полностью закончили, и вы слышите слова отчаяния («О, кстати, мы забыли о ...»). Пример ... «Все, что вам нужно сделать, это прочитать эти PDF-файлы из хранилища документов», которое во время приемочного тестирования превращается в «О, мы забыли, что некоторые из них были прочитаны вбок совершенно непоследовательным образом, и у некоторых был определен неправильный размер страницы, а некоторые нуждаются в добавлении этих трех страниц, и нам нужно, чтобы все они отображались одинаково. Это действительно легко исправить, верно? ".

Дело в том, что это может быть действительно легко, и быстрая встреча может подтвердить это, позволяя вам задокументировать все предположения и получить подтверждение того, что они точны и верны. Я рекомендую встать, чтобы устранить препятствия, которые вы должны написать рабочий код, который соответствует их ожиданиям, потому что независимо от того, наступаете ли вы на ноги, кто-то, вероятно, в конечном итоге будет несчастлив. Если вы будете настойчиво отвечать на вопросы и кого-то раздражать, они забудут об этом, когда вы вовремя представите отличный продукт, отвечающий требованиям. Если вам не удастся получить разъяснения и не поставить, никто не вспомнит, что они сказали вам, чтобы они не доставали им ошибок.


3

Без спецификации у вас есть работа в команде. Сразу Agile.

Сядьте с ПО и уточните небольшую начальную историю. «Мы собираемся предоставить только этот экран, с этой кнопкой, которая называется« Bing! »». Поселитесь на некоторых УК. Доставь историю. Продемонстрировать историю. Оказывается, кнопки должны быть красными. Поднимите ошибку или новую историю. Доставьте кнопки, которые идут бонг и взрыв. И так далее.

Совместно укажите и доставьте небольшие вертикальные срезы, которые часто демонстрируются.

Если клиент не будет работать с вами таким образом, ищите выход.


-1

Я потратил несколько работ, делая проекты, как вы обрисовали. Пока ПО знает, какие дизайнерские решения вы принимаете и почему вы должны их принимать, у вас все будет хорошо. Если, с другой стороны, они не понимают проектные решения, то вам нужно нажать на них как минимум для получения письменного документа о приемочных испытаниях.


-2

Вам нужна подробная, проверяемая спецификация, прежде чем вы сможете начать писать код. Это факт, и обойти это невозможно.

Если никто не хочет писать эту спецификацию, разработчики должны написать ее. Таким образом, вы получите неполную спецификацию. Вы превращаете его в полную спецификацию (что означает «это то, что я собираюсь реализовать, если кто-то еще не скажет мне не делать этого»). Вы передаете эту спецификацию заинтересованным сторонам и даете им возможность изменить спецификацию. Только шанс изменить спецификацию - не исключая ее, например, говоря: «Мне это не нравится». В этот момент это ваша спецификация, или они могут предоставить другую спецификацию, но не удалить спецификацию.

Это может быть хорошей идеей, чтобы получить быстрый обзор от ваших коллег, которые могут улучшить спецификации. Но в любом случае у вас есть спецификация, вы пишете код соответственно, тестеры тестируют соответственно. И вы сделали свою работу: у вас была спецификация, и вы ее реализовали. Если спецификация не соответствует желанию клиента, то ответственность за это лежит на владельце продукта или на клиенте, который не мог бы написать хорошую спецификацию.


6
«Вам нужна подробная, поддающаяся проверке спецификация, прежде чем вы сможете приступить к написанию кода. Это факт, и с этим не обойтись». Мои коллеги и я сделали это во многих проектах, и у нас было много успехов и очень мало сбоев. Ваше требование не является абсолютным.
whatsisname

1
@whatsisname согласился. Я тоже написал код таким образом. Это происходит, когда задача имеет исследовательский аспект. Теперь есть недостатки в кодировании без спецификации, но иногда они более приемлемы, чем утверждение, что вы не можете достичь цели.
Корт Аммон

1
@whatsisname, формулировка может быть улучшена, но основная истина в том, что вы не можете выполнить запрос, не понимая, что это такое. Если я просто скажу: «Напишите мне программу на Java», вы не сможете написать эту программу. Вы можете составить свое собственное представление о том, что должна делать программа, другими словами, придумать свою собственную цель, а затем выполнить ее, но это абсолютно невозможная цель, о которой никто, включая вас, никогда не заявлял . Это относится к любым запросам, большим или маленьким; нужды и желания должны быть поняты до того, как вы сможете это сделать, произвести и / или представить.
Wildcard

Это сказало ... уровень детализации, который фактически требует запрос, чтобы быть понятым и выполненным, может быть резко переоценен. Она также может быть под оценками. Единственное решение этого - общение.
Wildcard

@Wildcard: да, я думаю, что формулировка может быть очень одобрена. То, что вы пытаетесь сказать, напоминает парадокс Зенона, но менее убедительно.
whatsisname
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.