Який робочий процес з помилками у вашій спритній / Scrum команді?

Який робочий процес з помилками у вашій спритній / Scrum команді?

Ось наше: - Якщо помилка пов'язана з історією в поточному спринті, ми її виправляємо. - Якщо помилка не пов’язана з історією у поточному спринті та вона не є критичною, вона надсилається власнику продукту для визначення пріоритетності. - Якщо помилка не пов'язана з історією у спринті, і вона є критичною, ми її виправляємо.

Все, що стосується роботи в поточному спринті, виправлено, ми навіть не вважаємо їх помилками і не записуємо їх як такі. Ми вважаємо щось помилковим, лише якщо воно є частиною чогось, що ми вже вважали Готовим.

Коли виникає нова помилка, ми додаємо її до відставання, і вона надає пріоритет нашим зацікавленим сторонам. Якщо у нас залишився час у спринті, ми схильні вирішувати більш прості помилки, які можуть мати нижчий пріоритет, але є чимось, що ми можемо виконати за час, що залишився.

Я завжди думав, що помилка - це лише історія, яка вже має невдалий тест, тому її краще визначити, ніж типовий перший проект історії для особливостей.

Тож якщо ви переконані, що помилки - це історії, ви ставитесь до них так само, як і до інших історій щодо оцінок та пріоритетів.

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

Багато розробників не вважатимуть те, що не працює так, як задумано, над тим, як вони зараз працюють, не як помилку, оскільки це, чесно кажучи, не помилка. Якщо ви зараз працюєте над чимось, і у нього все ще є дефекти, конкретна помилка насправді не є повною, тому немає фактичного дефекту. Зворотне стосується завершених робіт, якщо ви визначили, що щось завершено і готове до тестування / випуску / виробництва, і пізніше ви знайдете дефект у коді чи використанні, тоді ви обов'язково маєте помилку.

Моя компанія використовує таку методологію, щоб визначити, коли потрібно виправити помилку:

Якщо помилка критична, вона додається до поточного спринту, пов'язаного з цим продуктом, за відповідним пріоритетом. Як правило, ми плануємо приблизно в 10% додатковий час, щоб дозволити це в спринті, а також мати додаткові речі, які ми насправді не плануємо виконувати, але якщо у нас немає помилок або щось було завершено швидше, ніж ми очікували, то можемо завершено.

Якщо помилка не є критичною, ми просто додаємо її до відставання та зазвичай завершуємо її в наступному спринті.

чому це ідеальний потік, є явна протікання цього, і іноді речі, які не є "критичними" з точки зору програмування, можливо, потрібно буде негайно завершити, якщо керівництво вирішить, що його потрібно завершити раніше, ніж ми думаємо, що має бути. завершено.

Убік я думаю, що найкраще зробити - це вибрати структуру, а потім дотримуватися її. Деякі з найбільших втрат продуктивності починають виникати, коли ви починаєте робити речі без структури. Після того, як ви почнете деградувати свою структуру, їй дуже легко піти вниз.

Це, можливо, надто відповідало на ваше запитання, але це лише мої думки щодо того, як з цими речами слід поводитися.

Ми робимо постійні роботи з дефектами. Подібно до вашої установки, якщо є критична проблема, пов’язана з поточною роботою, ми вирішуємо її як частину роботи. Зрештою, не можна назвати історію "виконаною", якщо з цим є дефект.

Щодо інших помилок, ми зазвичай їх виправляємо так, як дозволяє час. Якщо виникають нагальні проблеми, ми відтягуємо деякі історії та витрачаємо час на виправлення помилок, перш ніж повернутися до нормальної роботи з функціями.

Знайдені помилки під час спринту - лише частина розробки.

Помилки, знайдені після закінчення спринту, переходять у Блокування товарів. Ми ніколи не сперечаємось із користувачами, якщо щось є помилкою чи розширенням чи зміною. Якщо користувач хоче назвати це помилкою, то добре, але він все одно переходить в ПК лише будь-яку іншу нову роботу.