ли проблема, что у них нет никакой документации и тесты , или что они не реализуют всю методологию Scrum? Это две разные проблемы в моем сознании.
Я бы предпочел организацию, которая потратила время и силы на поиск и соответствие процессу разработки, который соответствует их стилю разработки, а не к тому, чтобы возлагать надежды на высокий истинный процесс. Поэтому я не был бы обеспокоен, если бы они использовали процесс, который они назвали Scrum, но который не соответствовал всем «официальным» рекомендациям. Попытайтесь определить, почему процесс такой, каким он есть.Скорее всего, если они нашли время, чтобы адаптировать его, команда будет восприимчива к вашим идеям, особенно если вы нашли время, чтобы определить, почему все так, как они есть. Если вы просто подходите к нему так: «это не Scrum, и поэтому не так», вы, вероятно, не будете продвигаться вперед, но, будучи прагматичным в отношении преимуществ, вы, вероятно, можете внести некоторые существенные улучшения.
В качестве альтернативы, если они не проводят тестирование и не имеют документации, я бы счел это довольно плохим знаком. И по документации я беру минималистский взгляд здесь - список функций, отслеживание ошибок и т. Д. - меня бы очень беспокоило отсутствие этих предметов, менее обеспокоенное отсутствием элементов выше списка абстракций. В отсутствие поддержки со стороны руководства я предлагаю вам привести пример. Возьмите на себя настройку простой системы отслеживания ошибок (есть несколько - в крайнем случае, простые текстовые списки в центральном месте также работают). Не объявляйте свои функции законченными, пока кто-то еще не проверил это. Это может быть так же просто, как перейти к другому разработчику и попросить их попробовать его перед вами. Если кто-то утверждает, что функция завершена, найдите несколько минут, чтобы ознакомиться с ней. Если вы найдете ошибку, вежливо сообщите об этом ответственному разработчику. Медленно создавайте среду, в которой команда может увидеть преимущества запуска тестов и отслеживания функций и ошибок.
Большинство команд действуют таким образом просто из-за ошибочного убеждения, что у них нет времени, чтобы «сделать это правильно» или что они доберутся до него позже. Часто это происходит, когда простая доказательная концепция, сделанная разработчиком или двумя в качестве побочного проекта, превращается в полномасштабное развитие. Показывая, что это может сэкономить время и силы и сократить первоначальные затраты для остальной части команды, вы часто обнаружите, что она становится укоренившейся как часть процесса, даже когда-либо официально не одобряемая или принятая.
Если у вас есть поддержка в управлении, это будет намного проще, но всегда будьте осторожны, чтобы убедиться, что команда восприимчива к изменениям. Это может означать, что это занимает больше времени, чем вы хотите, но так оно и есть, без поддержки команды какой-либо санкционированный процесс потерпит неудачу при первом знаке давления, когда вам нужен этот процесс больше всего.
* Отказ от ответственности - В моем последнем проекте я возглавил движение, чтобы адаптировать процесс SCRUM в соответствии с нашей средой. «Официальный» процесс был просто несостоятельным для нашего клиента, но он по-прежнему оставался неоценимым руководством при пошиве нашего процесса.