Scrum, но без тестирования или документации

Question

Что вы делаете, когда присоединяетесь к команде, которая говорит, что использует Scrum, но использует ее только как инструмент управления временем, а не весь процесс? Как восстановить повторное тестирование и документацию?

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

Answer 1

ли проблема, что у них нет никакой документации и тесты , или что они не реализуют всю методологию Scrum? Это две разные проблемы в моем сознании.

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

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

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

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

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

Answer 2

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

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

Answer 3

«добавление пользовательских историй специально для тестирования и документирования»

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

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

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

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

IT не делает ничего, кроме принудительного. Итак, познакомьтесь с пользователями и узнайте, почему они не требуют тестирования. Тренер должен требовать тестирования. Скажите им последствия и слова для использования.

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

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

Answer 4

Обратите внимание, что ни тестирование, ни документация на самом деле не являются частью Scrum. Scrum - это чистый подход к управлению проектами. Предполагается, что требуемые инженерные практики, такие как те, которые вы упоминаете, «появятся» во время проекта. И, в частности, они должны быть идентифицированы во время ретроспективных изменений сердцебиения, которые вы делаете в конце каждого спринта. Вы это делаете? Можете ли вы рассказать о своих проблемах, и действительно ли они являются самыми большими проблемами, которые испытывает команда?