В основном я работал над проектами, которые следовали модели Waterfall, и у нас было множество контрольных списков и аудитов во время SDLC, которые гарантировали, что мы сможем достичь целей в области качества.
Сейчас я работаю в организации, где большинство проектов используют Scrum или Kanban. Часто требования/истории предоставляются пользователями/клиентами напрямую. У нас очень мало приоритетов, которые мы делаем с клиентом. Размер проекта варьируется от 2 разработчиков до 20 разработчиков. Оценки, данные разработчиками для своих историй, иногда не учитывают модульное тестирование, проверку кода/переработку. Я их обучил, и теперь они начали правильно это оценивать.
Какие все процессы я могу внедрить, чтобы параметры качества, такие как скорость внедрения дефектов, эффективность проверки кода, эффективность разработки программного обеспечения, можно было контролировать? Я думаю, что многие разработчики путают Agile/итеративную модель с упрощенной разработкой. Поэтому их обучение — это первое, чем я занимаюсь.
Я хотел бы спросить здесь экспертов, есть ли какие-либо эмпирические правила, которые я могу использовать, или есть ли какие-либо передовые практики, которые я могу реализовать, чтобы все проекты следовали одинаковому процессу, проекты следовали более предсказуемому пути, количество рассказываемых историй было выше. и параметры качества могут быть достигнуты.
Я думаю, что в гибких методах вам, вероятно, понадобится другой набор показателей качества для отслеживания.
В agile-проекте, особенно в отношении проектирования, кодирования и тестирования, он является очень итеративным, и может не быть четкого разделения этих действий, поэтому метрики, основанные на фазах (например, измерение эффективности проектирования и проверки кода), становятся жесткий. Кроме того, поскольку тестирование обычно происходит одновременно и непрерывно, я не думаю, что вы получите типичные кривые появления дефектов.
Я думаю, вы захотите помнить об Agile-манифесте при разработке новых показателей для отслеживания качества. В частности, Agile Manifesto отдает предпочтение «людям и взаимодействиям» и «сотрудничеству с клиентами». Вы также должны помнить о принципах, лежащих в основе манифеста Agile , особенно о первом: «наш главный приоритет — удовлетворить клиента за счет ранней и непрерывной поставки ценного программного обеспечения».
Вашей первой метрикой должна быть удовлетворенность клиентов. Хорошей начальной мерой будут дефекты, о которых сообщают клиенты и конечные пользователи. Если вы отслеживаете заявленную серьезность или приоритет, это может быть частью этого измерения. Вы также можете отслеживать количество итераций для устранения дефектов (вероятно, в зависимости от приоритета и/или серьезности). Этот тип метрики относится к времени обработки дефекта (время между сообщением и проверкой) или времени реагирования на дефект (подтвержденные дефекты устраняются командой разработчиков). Вы даже можете построить цели вокруг этих точек данных, чтобы улучшить свою деятельность по обеспечению качества до уровня 0 «существенных» (на основе вашего определения «значительных») проблем, о которых сообщают клиенты в выпусках.
Хорошим гибким показателем удовлетворенности клиентов, возможно, будет количество или процент пользовательских историй, которые были приняты в конце спринта. В идеале вы должны закончить каждую запланированную историю, и каждая законченная история будет принята. Однако это не всегда так.
Поскольку вы также используете канбан, отслеживание распределения серьезности (от косметических дефектов до проблем с блокировкой) и распределения приоритетов (от низкого до высокого) вместе с дорожкой, в которой находится рабочий элемент, может дать интересные данные. Например, когда разработчик говорит, что история или задача завершены с разработкой, в ней не должно быть обнаружено блокирующих или высокоприоритетных проблем. Отслеживание того, что большое количество элементов попадает на приемочное тестирование с дефектами, превышающими определенный уровень серьезности или приоритета, может вызвать действия.
Немного ближе к команде разработчиков, хорошей метрикой может быть автоматизированное тестовое покрытие. Гибкие методы, как правило, отдают предпочтение непрерывной интеграции, а автоматизированные модульные, интеграционные, системные и регрессионные тесты хорошо поддерживаются в среде такого типа. Отслеживание охвата, особенно в новом коде, может быть полезным. Конечно, тестовое покрытие не является показателем качества (см. также: Как неправильно использовать покрытие кода) .), так как он не говорит о том, насколько хороши ваши тесты, но вы можете использовать его с другими отчетами о дефектах, обнаруженными во время тестирования или действий после выпуска, чтобы узнать, насколько хороши ваши тесты. Вы можете использовать его в качестве быстрой проверки, чтобы убедиться, что некоторые тесты пишутся для нового кода, и что по мере обнаружения проблем пишутся тесты для включения в наборы тестов, чтобы доказать проблему, а затем проблема была решена. .
С точки зрения требований, истории, включенные в спринт, должны быть относительно хорошо понятны и то, над чем вы будете работать. Хотя Agile признает тот факт, что требования могут меняться и действительно меняются, и вы должны принимать изменения, обычно вы не хотите серьезных изменений в историях, которые являются частью текущей итерации. Вам, вероятно, следует измерить изменчивость историй, которые вы привнесли в спринт — после того, как они пройдут процесс подготовки и будут приняты командой, отследите количество изменений в каком-либо аспекте истории (включая добавленные или добавленные истории). удаленный). Добавление или удаление истории видно на диаграмме выгорания или выгорания, но изменения в истории могут там не отражаться.
Помимо требований, меня беспокоит, когда вы говорите, что ваши пользователи и клиент напрямую предоставляют требования и истории, а с клиентом очень мало расставляются приоритеты. Если у вас нет локального пользователя или клиента, выступающего в роли владельца продукта , в вашей команде должен быть человек, который может действовать в этом качестве и хорошо понимает потребности и желания пользователей и клиента. Владелец продукта должен нести ответственность за определение приоритетов историй и предоставление четких критериев приемлемости. Расставленные по приоритетам истории и четкие критерии приемки будут видны в таких показателях, как изменчивость требований и дефекты, обнаруженные после выпуска.
Хотя это увеличивает накладные расходы, если вы работаете над контрактом, который уже требует отслеживания времени, рассмотрите возможность отслеживания времени для определенных задач. Это зависит от того, как вы разбиваете свою работу на задачи, но если вам нужно отслеживать отработанное время, вы можете отслеживать стоимость качества. На что следует обратить внимание, так это на то, сколько времени вы тратите на написание и выполнение тестов (ручных и автоматизированных), рецензирование проекта или кода экспертами, а также время на переработку дизайна или кода из-за неудачных тестов. Конечно, будьте осторожны, чтобы не добавить много накладных расходов — это может не подойти для проектов, не требующих отслеживания времени.
С точки зрения качества процесса проверьте, насколько хороши ваши оценки. Это немного сложнее с историями для каждой истории, но вы можете отслеживать общую скорость по спринтам. После нескольких итераций вы должны быть в состоянии последовательно сказать, сколько очков истории вы можете выполнить за один спринт, а затем достичь этого числа (возможно, с некоторыми незначительными вариациями). Ваши диаграммы выгорания и отслеживание скорости можно просматривать с течением времени, чтобы убедиться, что вы правильно оцениваете и выполняете свои рабочие элементы.
У меня есть последнее слово предостережения. Я бы порекомендовал придерживаться принципов бережливой разработки программного обеспечения . Убедитесь, что любые измерения и метрики, которые вы собираете, действительно приносят пользу клиенту, команде или организации. Когда ваши метрики или индикаторы указывают на проблему, дайте команде возможность принять решение о том, как двигаться дальше, и предпринять корректирующие действия.
джморт253