В настоящее время мы используем JIRA для отслеживания наших разработок. Мое руководство хочет отформатировать и классифицировать все как «Пользовательские истории», включая задачи, не связанные с разработкой программного обеспечения. Например:
«Как менеджер по тестированию, могу ли я проводить тестирование приложения, используя только автоматические тесты и не проводя ручное тестирование, чтобы я мог протестировать приложение максимально эффективно?
Критерии приемки: 1. Преобразовать 50 существующих ручных тестов в полностью автоматизированные тесты. 2. Тесты должны быть выполнены менее чем за 1 час ».
Я хочу получить представление от сообщества, если имеет смысл использовать «пользовательские истории» для работы, которая поддерживает процесс разработки программного обеспечения, не выполняется программистами и не приводит непосредственно к выдающемуся коду. Или это следует обрабатывать / классифицировать по-разному (например, в JIRA)?
Обновлено 7 июня 2011 г. - Перефразированный вопрос, чтобы сосредоточиться на термине «пользовательская история».
Ответы:
да
любая заинтересованная сторона, любая функция, которая улучшает систему
[пусть пуристские откаты начнутся!]
источник
«Мое руководство хочет использовать Agile для всего, включая задачи, не связанные с разработкой программного обеспечения».
Это не означает написание пользовательских историй для каждой функции.
Если вы хотите писать истории для каждой функции, вы не обязательно должны быть гибкими. Вы просто пишете пользовательские истории для каждой функции.
Пользовательские истории! = Agile.
Пользовательские истории - это способ собрать и понять требования. Они могут быть использованы совершенно водопадным способом, если хотите. Некоторые люди делают это.
Agile - это способ управления проектами. Вы можете использовать пользовательские истории или нет в гибком проекте.
Пользовательские истории для управления техническим долгом и внутренними задачами - опять же - не имеют ничего общего с гибкостью.
Многие люди совершенно счастливы, добавляя «технические» или «вспомогательные» функции в спринт, не тратя время на написание фальшивой «пользовательской истории» для чисто внутренних пользователей с ограниченной добавленной стоимостью, не заинтересованных сторон.
Если QA не получит свою историю, сколько реальных потерь бизнеса?
Если реальные заинтересованные стороны не получают их истории, бизнес действительно страдает.
источник
Это не имеет смысла для меня. По сути, «пользовательская история» - это просто пользовательская история, а не история менеджера проекта, не история разработчика, не история инженера по обеспечению качества.
На этой ноте программное обеспечение:
Улучшения процесса носят открытый характер и, как правило, субъективны.
Как вы оцениваете улучшение тестирования? Для этого нет определенного контракта.
И на несвязанной ноте я искренне надеюсь, что ваш пример, приведенный выше,
... это просто пример, потому что в этом так много неправильного, что я даже не могу описать.
источник
Технический долг может быть обработан аналогично истории пользователя, но иногда это может быть довольно уродливо. Например, для такой истории, как «Как разработчик, я хочу иметь работающие модульные тесты, чтобы иметь уверенность в том, что тесты смогут проверить, не нарушают ли другие изменения что-либо», владелец продукта не имеет большой ценности но для команды может быть хорошей идеей сделать это как часть собственного рефакторинга, который является частью работы в спринте.
Мне нравится идея иметь задачи, которые отделены от пользовательских историй, так как задачи не будут чем-то, что вы покажете конечному пользователю системы, но могли бы помочь улучшить обслуживание и время, которое может потребоваться для разработать новую функцию. В зависимости от того, сколько заданий, с точки зрения общего количества баллов, так как некоторые задачи могут составлять 2 минуты, а другие - 2 недели, может быть построено, это может быть тем, что определяет, берет ли команда спринт и не вводит новые функции, но работает на задачах по уборке вещей, которые я видел несколько раз, когда я работаю.
источник
По моему скромному мнению, да, вы можете использовать пользовательские истории для проектов, не связанных с разработкой программного обеспечения, а не только для задач по улучшению процессов. Например, 3 года назад я был лучшим мужчиной на свадьбе моего друга и использовал методологию Agile и пользовательские истории для планирования свадьбы. Все задачи, которые мы должны были выполнить, были написаны как пользовательские истории с персоной, намерением, обоснованием и критериями успеха для каждой пользовательской истории. Все вовлеченные стороны приняли участие в нашей ежедневной ссоре, чтобы обсудить, что мы делали в предыдущий день и что мы будем делать в этот день. Все были географически рассредоточены, поэтому мы проводили конференц-звонки для наших ежедневных встреч, планирования спринтов, ретроспектив, сессий написания историй и оценки ... вы называете это, мы сделали это. В общей сложности у нас было 6 спринтов (3 месяца), и свадьба имела поразительный успех, не оставив камня на камне.
источник
У вас есть серьезная проблема, когда вы помещаете внутренние «пользовательские истории» в смесь с реальными пользовательскими историями.
Пожалуйста, перечитайте столько определений заинтересованных лиц, сколько сможете найти.
http://en.wikipedia.org/wiki/Scrum_(development )
http://wiki.openbravo.com/wiki/Scrum/Pigs_and_Chicken
http://www.testertroubles.com/2009/04/scrum-pigs-and-chickens.html
Прочитайте их очень, очень внимательно, чтобы вы могли увидеть разницу между цыплятами и свиньями.
Внутренние «пользовательские истории» написаны цыплятами.
Актуальные пользовательские истории написаны свиньями.
Ваши "ориентированные на курицу" пользовательские истории не очень важны. Независимо от того, насколько руководство хочет отслеживать их, как если бы они были реальными пользовательскими историями с реальной ценностью, они не являются реальными пользовательскими историями и не создают ценности одинаково.
На размытом краю аргумента - проблема QA. QA важен и без него ничего не работает.
Это волшебным образом не делает QA внезапно свиньей. Это делает их все еще не заинтересованными сторонами. Они обеспечивают поддержку, инфраструктуру и необходимую основу для остальной части работы. Но они «пользовательские истории» существенно отличаются от реальных пользовательских историй.
Если QA не показывает тестирование улучшения в тестировании, никто не выходит из бизнеса. Деньги не потеряны.
Если пользователь не может вести бизнес в первую очередь, значит, вы вне бизнеса. Деньги потеряны. Вся операция является полным провалом.
Не смешивайте внутренние («куриные») и реальные («свиньи») заинтересованные стороны.
источник
Комментарий «куры и свиньи» не соответствует действительности. Внутренние заинтересованные стороны - это куры, когда речь идет о разрабатываемом продукте (если только он не разрабатывается для них), но они свиньи, когда речь идет о процессе разработки.
Вопрос, который вы задаете, заключается ли в формуле предложения «Как Я хотел бы иметь возможность _ , так что я могу __ "было бы полезно для определения и улучшения бизнес-процессов, где улучшения не требуют написания нового программного кода. Я натолкнулся на эту тему, потому что я думаю о том же и ищу лучшую практику, но Моя сильная интуиция заключается в том, что ответом на ваш вопрос является «да». Цель структуры предложения в действительности состоит в том, чтобы заставить автора абстрагироваться от решений, которые он / она уже может иметь в виду, и сосредоточиться на том, что пользователь - в этом В этом случае пользователь процесса хочет это сделать. Я не вижу причин, по которым история пользователя не будет полезна при применении к процессу.
Вопрос о критериях приемлемости является хорошим, но он не должен быть догматичным (в любом случае это Agile). При разработке любого бизнес-процесса полезно задаться вопросом: «Как я узнаю, что изменение процесса достигло моей цели?». Это правда, что вы не всегда можете запустить автоматический тест для ответа на этот вопрос, но это не повод дисквалифицировать пользовательскую историю как инструмент.
источник