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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Не паникуйте

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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