Артем, раз уж Вы ссылаетесь на ITIL не путайте пожалуйста понятия инцидент и проблема.
Инцидент - это незапланированное прерывание или снижение качества услуги (сервиса), а проблема - причина возникновения одного или нескольких инцидентов. Поэтому если по SLA у нас вход в систему 5 секунд, а окно авторизации висит уже 7 - это инцидент. Также как и сбой у одного только пользователя.
В продуктовом подходе, в отличие от сервисного, оперируют понятием баг. Вот тут два понятия заменяются одним.
Важно понимать также что разбор полетов (post mortem) ближе к практике управления проблемами, хотя и в управлении инцидентами применяется, но для критических инцидентов (major incidents), поскольку уводит от цели практики - скорейшее восстановление, а не предотвращение повторений (для управления проблемами).
Инцидент может быть закрыт как обходным решением (workaround), так и постоянным. Вот тут для сравнения с продуктовым подходом вместо будет упомянуть про технический долг, как совокупность этих обходных решений или компромиссов, которые важно фиксировать на досках в виде отдельных элементов работы. Т.е. при решении бага с помощью обходного решения здорово создавать связанную сущность, как тех. долг. В то время как при постоянном таких телодвижений не потребуется.
Если будет интерес продолжить, то мы друг в друга в контактах LinkedIn 😀
Зачем вам и "Оценка в часах" и "Размер"? Первая даёт вам экспертную оценку трудозатрат, а вторая - относительную оценку сложности работы. Но по тексту не заметил для чего вы проводили оценку в часах.
Артем, раз уж Вы ссылаетесь на ITIL не путайте пожалуйста понятия инцидент и проблема.
Инцидент - это незапланированное прерывание или снижение качества услуги (сервиса), а проблема - причина возникновения одного или нескольких инцидентов. Поэтому если по SLA у нас вход в систему 5 секунд, а окно авторизации висит уже 7 - это инцидент. Также как и сбой у одного только пользователя.
В продуктовом подходе, в отличие от сервисного, оперируют понятием баг. Вот тут два понятия заменяются одним.
Важно понимать также что разбор полетов (post mortem) ближе к практике управления проблемами, хотя и в управлении инцидентами применяется, но для критических инцидентов (major incidents), поскольку уводит от цели практики - скорейшее восстановление, а не предотвращение повторений (для управления проблемами).
Инцидент может быть закрыт как обходным решением (workaround), так и постоянным. Вот тут для сравнения с продуктовым подходом вместо будет упомянуть про технический долг, как совокупность этих обходных решений или компромиссов, которые важно фиксировать на досках в виде отдельных элементов работы. Т.е. при решении бага с помощью обходного решения здорово создавать связанную сущность, как тех. долг. В то время как при постоянном таких телодвижений не потребуется.
Если будет интерес продолжить, то мы друг в друга в контактах LinkedIn 😀
Доброго дня!
По тексту перепутали описание полей DoR и DoD.
И остался вопрос:
Зачем вам и "Оценка в часах" и "Размер"? Первая даёт вам экспертную оценку трудозатрат, а вторая - относительную оценку сложности работы. Но по тексту не заметил для чего вы проводили оценку в часах.
За ссылку на прощание отдельно благодарю, Макс!
Марк Твен "Приключения Тома Сойера"
Кайтен (https://kaiten.ru/)