guide root cause analysis steps
Aquest tutorial explica què és l’anàlisi de la causa arrel i les diferents tècniques d’anàlisi de la causa arrel, com ara l’anàlisi de l’espina de peix i la tècnica de 5 per què:
RCA (Anàlisi de la causa arrel) és un procés estructurat i eficaç per trobar la causa arrel dels problemes en un equip de Projectes de programari. Si es realitza de manera sistemàtica, pot millorar el rendiment i la qualitat dels lliuraments i dels processos, no només a nivell d’equip, sinó també a tota l’organització.
Aquest tutorial us ajudarà a definir i racionalitzar el procés d’anàlisi de les causes arrel del vostre equip o organització.
Aquest tutorial està pensat per a gestors de lliurament, mestres Scrum, gestors de projectes, gestors de qualitat, equip de desenvolupament, equip de proves, equip de gestió d'informació, equip de qualitat, equip d'assistència, etc. .
Què aprendreu:
- Què és l'anàlisi de les causes fonamentals?
- Procés d’anàlisi de la causa arrel
- Tècniques d’anàlisi de la causa arrel
- Factors que causen defectes
- Conclusió
Què és l'anàlisi de les causes fonamentals?
RCA (Anàlisi de la causa arrel) és un mecanisme d’anàlisi dels defectes per identificar-ne la causa. Fem una pluja d’idees, llegim i excavem el defecte per identificar si el defecte es deu a “ proves de miss ',' desenvolupament miss 'O era un' requisit o dissenys miss '.
Quan RCA es fa amb precisió, ajuda a prevenir defectes en les versions o fases posteriors. Si ho trobem, es va deure a un defecte senyoreta de disseny , podem revisar els documents de disseny i prendre les mesures adequades. De la mateixa manera, si trobem que es va produir un defecte proves de miss , podem revisar els nostres casos de prova o mètriques i actualitzar-los en conseqüència.
El RCA no s’ha de limitar només a provar els defectes. També podem fer RCA en defectes de producció. Basant-nos en la decisió de RCA, podem millorar la nostra Llit de proves i incloure els tiquets de producció com a casos de proves de regressió. D’aquesta manera s’assegurarà que no es repeteixin el defecte o defectes similars.
Procés d’anàlisi de la causa arrel
RCA no només s’utilitza per a defectes reportats des d’un lloc del client, sinó també per a defectes UAT, defectes de proves d’unitats, problemes de nivell empresarial i operatiu, problemes de la vida quotidiana, etc. Per tant, s’utilitza en diverses indústries com Sector del programari, fabricació, sanitat, sector bancari, etc.
La realització de l’anàlisi de la causa arrel és similar a la feina del metge que tracta un pacient. El metge primer entendrà els símptomes. Després es referirà a proves de laboratori per analitzar la causa arrel de la malaltia.
Si encara es desconeix la causa arrel de la malaltia, el metge remetrà a proves d’anàlisi per entendre-ho més. Continuarà el diagnòstic i l’estudi fins que es redueixi a la causa arrel de la malaltia del pacient. La mateixa lògica s’aplica a l’anàlisi de causes fonamentals realitzada en qualsevol indústria.
Per tant, RCA té com a objectiu trobar la causa arrel i no tractar el símptoma, seguint un conjunt específic de passos i eines associades. És diferent de l'anàlisi de defectes, la resolució de problemes i altres mètodes de resolució de problemes, ja que aquests mètodes intenten trobar la solució per al problema específic, però RCA intenta trobar la causa subjacent.
Origen del nom Anàlisi de la causa fonamental:
(imatge font )
Les fulles, el tronc i les arrels són les parts més importants d’un arbre. Les fulles (Símptoma) i el tronc (Problema) que es troben sobre el terra són visibles, però les arrels (Causa) que es troben sota el terreny no són visibles i les arrels creixen més profundament i es poden estendre més del que esperem. Per tant, el procés d’excavació al final del problema s’anomena Anàlisi de la causa arrel.
Avantatges de l'anàlisi de la causa arrel
A continuació, es detallen alguns dels avantatges que obtindreu:
- Eviteu que es repeteixi el mateix problema en el futur.
- Finalment, reduïu el nombre de defectes notificats al llarg del temps.
- Redueix els costos de desenvolupament i estalvia temps.
- Millorar el procés de desenvolupament de programari i, per tant, facilitar el lliurament ràpid al mercat.
- Millora la satisfacció del client.
- Augmentar la productivitat.
- Cerqueu problemes ocults al sistema.
- Ajudes a la millora contínua.
Tipus de causes arrel
# 1) Causa humana: Error humà.
Exemples:
- Sota hàbil.
- Instruccions no degudament seguides.
- Ha realitzat una operació innecessària.
# 2) Causa organitzativa: Un procés que la gent utilitza per prendre decisions que no eren adequades.
Exemples:
- Es van donar instruccions vagues del cap d’equip als membres de l’equip.
- Triar la persona equivocada per a una tasca.
- No existeixen eines de control per avaluar la qualitat.
# 3) Causa física: Qualsevol element físic ha fallat d'alguna manera.
Exemples:
- L’ordinador continua reiniciant-se.
- El servidor no s’inicia.
- Sorolls estranys o forts al sistema.
Passos per fer l'anàlisi de la causa arrel
Es requereix un enfocament estructurat i lògic per a una anàlisi eficaç de la causa arrel. Per tant, cal seguir una sèrie de passos.
# 1) Formeu l'equip RCA
Tots els equips haurien de tenir un dedicat Gestor d'anàlisis de causes arrelades (Gestor RCA) qui recollirà els detalls de l'equip d'assistència i iniciarà el procés d'inici de RCA. Coordinarà i assignarà els recursos que necessitin assistir a les reunions de RCA en funció del problema indicat.
Els equips, que assisteixen a la reunió, han de comptar amb personal de cada equip (Requisits, Disseny, Proves, Documentació, Qualitat, Suport i Manteniment) que estigui més familiaritzat amb el problema. L’equip també hauria de tenir persones que estiguin directament relacionades amb el defecte. Per exemple, l’enginyer d’assistència que va donar una solució immediata al client.
Comparteix els detalls del problema amb l’equip abans d’assistir a la reunió perquè puguin fer una anàlisi inicial i estar preparats. Els membres de l'equip també recopilen informació relacionada amb el defecte. Depenent de l’informe d’incidents, cada equip rastrejarà el que ha fallat en aquest escenari en les seves respectives fases. Estar preparat augmentarà l’eficiència del proper debat.
# 2) Definiu el problema
Recopileu els detalls del problema, com ara informes d’incidents, evidències del problema (captura de pantalla, registres, informes, etc.) i, a continuació, estudieu / analitzeu el problema fent les següents preguntes:
- Quin és el problema?
- Quina és la seqüència d'esdeveniments que va conduir al problema?
- Quins sistemes hi participaven?
- Quant de temps va existir el problema?
- Quin és l'impacte del problema?
- Qui hi va participar i va determinar qui ha de ser entrevistat?
Utilitzeu les regles 'SMART' per definir el vostre problema:
- S PECÍFIC
- M FÀCIL
- A ORIENTAT A LA ACCIÓ
- R ELEVANT
- T NOMBRE
# 3) Identifiqueu la causa arrel
Realitzeu el PLUJA D'IDEES sessió formada per l'equip RCA per identificar les causes. Utilitzar el Diagrama d’os de peix o bé 5 Per què l'anàlisi mètode o tots dos per arribar a la causa / s arrel.
El gerent de RCA hauria de moderar la reunió i establir les regles per a la sessió de pluja d’idees. Per exemple, les regles poden ser:
- No s’ha de permetre criticar / culpar els altres.
- No jutgeu les idees dels altres. Cap idea és dolenta, fomenta idees salvatges.
- Aprofiteu en les idees dels altres. Penseu en com podeu basar-vos en les idees dels altres i millorar-les.
- Doneu a cada participant el temps necessari per compartir les seves opinions.
- Fomenteu el pensament fora de caixa.
- Mantindre la concentració.
Totes les idees s’han de registrar. El gerent de RCA hauria d’assignar un membre per registrar l’acta de la reunió i l’actualització de les plantilles RCA.
# 4) Implementar l'acció correctiva de la causa fonamental (RCCA)
L’acció de correcció consisteix a solucionar la solució identificant la causa arrel real. Per facilitar-ho, ha de ser present un gestor de lliuraments que pot decidir en quines versions s’ha d’implementar la solució i quina ha de ser la data de lliurament.
RCCA s'hauria d'implementar de manera que aquesta causa arrel no es torni a produir en el futur. La correcció donada per l'equip d'assistència serà temporal per al lloc del client on s'informa del problema. Quan aquesta solució es combina en una versió en curs, feu una anàlisi d'impacte adequada per assegurar-vos que no es trenca cap característica existent.
Doneu els passos per validar la solució i supervisar la solució implementada per comprovar si la solució és efectiva.
# 5) Implementar una acció preventiva de causa fonamental (RCPA)
L’equip ha de plantejar-se com es pot prevenir un problema tan similar en el futur. Per exemple, Actualitzeu el manual d’instruccions, milloreu el conjunt d’habilitats, actualitzeu la llista de comprovació de l’avaluació de l’equip, etc. Seguiu els documents adequats d’accions preventives i controleu si l’equip s’adhereix a les accions preventives realitzades.
Consulteu això treball de recerca sobre 'Anàlisi i prevenció de defectes per a la millora de la qualitat de processos de programari' publicat al Revista Internacional d'Enginyeria i Aplicacions de Programari per fer-se una idea dels tipus de defectes reportats en cada fase del programari i suggerir-los accions preventives.
La informació obtinguda de RCA pot entrar com a entrada Mode d'error i anàlisi d'efectes (FMEA ) per identificar punts on la solució pot fallar.
Implementar Anàlisi de Pareto amb les causes identificades durant RCA durant un període, per exemple, semestralment o trimestralment, que ajudaran a identificar les principals causes que contribueixen als defectes i a centrar-se en l'acció preventiva per a ells.
Tècniques d’anàlisi de la causa arrel
# 1) Anàlisi de l'espina de peix
El diagrama Fishbone és una eina visual d’anàlisi de la causa arrel per identificar les possibles causes dels problemes identificats i, per tant, també s’anomena diagrama de causa i efecte. Us permet arribar a la veritable causa arrel del problema en lloc de resoldre el seu símptoma.
També s’anomena Diagrama Ishikawa tal com va ser creat per Dr. Kaoru Ishikawa (un estadístic japonès de control de qualitat). També es coneix com a diagrama de Herringbone o Fishikawa.
L'anàlisi de les espines de peix s'utilitza en la fase d'anàlisi de sis sigma’s DMAIC enfocament per a la resolució de problemes. És un dels 7 eines bàsiques de control de qualitat .
Passos per crear un diagrama de Fishbone:
El diagrama de l’os de peix s’assembla a l’esquelet d’un peix amb el problema que forma el cap dels peixos i causa la formació de la columna vertebral i els ossos del peix.
Seguiu els passos següents per crear un diagrama d'os de peix:
- Escriu el problema al cap del peix .
- Identifiqueu el fitxer categoria de causes i escriure a extrem de cada os (causa categoria 1, causa categoria 2 ... causa categoria N)
- Identifiqueu el fitxer causes principals a cada categoria i marqueu-la com a causa principal 1, causa principal 2, causa principal N.
- Amplieu les causes a secundària, terciària i més nivells segons correspongui.
Un exemple d’aplicació d’un diagrama d’os de peix a un defecte de programari (vegeu més avall).
Hi ha moltes eines gratuïtes i de pagament disponibles per crear un diagrama de peix. El diagrama Fishbone d’aquest tutorial s’ha creat amb ‘ Creately ' eina en línia . Més detalls sobre les plantilles i les eines d’os de peix s’explicaran al nostre proper tutorial.
# 2) La tècnica dels cinc per què
5 Why Technique va ser desenvolupat per Sakichi Toyoda i es va utilitzar a Toyota en la seva indústria manufacturera. Aquesta tècnica fa referència a una sèrie de preguntes on cada resposta es respon amb una pregunta Per què. Es pot relacionar amb com un nen farà preguntes als adults. Basant-se en la resposta que donen els adults, faran preguntes sobre 'Per què' una i altra vegada fins que estiguin satisfets.
5 Per què s’utilitza la tècnica de manera autònoma o com a part de l’anàlisi de l’os de peix per aprofundir en la causa principal del problema. El nombre de passos no es limita a 5. Pot ser inferior o superior a 5 fins que no arribi el diagnòstic del problema. 5 Per què són una tècnica relativament més senzilla i una forma més ràpida d’arribar a les causes fonamentals. Facilita un diagnòstic ràpid per descartar els símptomes i arribar a la causa principal.
L’èxit de la tècnica depèn del coneixement de la persona. Hi pot haver diferents respostes a una mateixa pregunta Per què. Per tant, és important seleccionar la direcció i el focus adequats a la reunió.
Passos per crear un diagrama de 5 Per què
Comenceu la discussió de pluja d’idees definint el problema. A continuació, seguiu el Per què posterior i les seves respostes.
Un exemple de com s'aplica el diagrama 5 Per què a un defecte de programari:
5 Per què es dibuixen les plantilles i les imatges mitjançant el programari en línia Creately.
Factors que causen defectes
Hi ha molts factors que provoquen que es produeixin els defectes:
- Requisits poc clars / que falten / són incorrectes
- Disseny incorrecte
- Codificació incorrecta
- Proves insuficients
- Problemes ambientals (maquinari, programari o configuracions)
Aquests factors sempre s’han de tenir en compte durant la realització del procés RCA.
RCA comença i continua amb una pluja d'idees sobre el defecte. L'única pregunta que ens fem mentre fem RCA és 'PER QUÈ?' i què?' Podem aprofundir en cada fase del cicle de vida a seguir, on persisteix el defecte.
Comencem per 'PER QUÈ?' preguntes (la llista no està limitada). Podeu començar des de la fase exterior i avançar cap a la fase interna de SDLC.
Preguntes i respostes de l'entrevista de loadrunner per a persones experimentades
- 'PER QUÈ' no s'ha detectat el defecte durant el Prova de seny en producció?
- 'PER QUÈ' no s'ha detectat el defecte durant les proves?
- 'PER QUÈ' no s'ha detectat el defecte durant la revisió del cas de prova?
- 'PER QUÈ' no s'ha detectat el defecte? Proves unitàries ?
- 'PER QUÈ' no s'ha detectat el defecte durant la 'Revisió del disseny'?
- 'PER QUÈ' no s'ha detectat el defecte durant la fase de requisits?
La resposta a aquesta pregunta us donarà la fase exacta, on existeix el defecte. Ara, una vegada que identifiqueu la fase i el motiu, apareix la part 'QUÈ'.
“QUÈ faràs per evitar-ho en el futur?
La resposta a aquesta pregunta 'QUÈ', si s'implementa i es té cura, evitarà que es pugui tornar a produir el mateix defecte o el tipus de defecte. Preneu les mesures adequades per millorar el procés identificat de manera que no es repeteixi el defecte o el motiu del defecte.
Segons els resultats de RCA, podeu determinar quina de les fases té àrees problemàtiques.
Per exemple, si determina que la major part de l’RCA dels defectes es deu requisit senyoreta , podeu millorar la fase de recollida / comprensió de requisits introduint més ressenyes o sessions completes.
De la mateixa manera, si trobeu que la majoria dels defectes es deuen a proves de miss , heu de millorar el procés de proves. Podeu introduir mètriques com Mètriques de traçabilitat de requisits , Mètriques de cobertura de proves, o bé podeu comprovar el procés de revisió o qualsevol altre pas que creieu que milloraria l'eficiència de les proves.
Conclusió
És responsabilitat de tot l’equip seure i analitzar els defectes i contribuir a la millora del producte i del procés.
En aquest tutorial, teniu una comprensió bàsica de RCA, els passos que cal seguir per fer un RCA eficient i diferents eines que s’utilitzaran, com ara l’anàlisi de Fishbone i 5 Why Why Technique. Als propers tutorials, hi haurà cobertura sobre diferents plantilles RCA, exemples i casos d’ús sobre com implementar-lo.
Lectura recomanada
- Anàlisi i informes de resultats de proves: proves de càrrega amb LoadRunner
- Les millors eines de prova de programari 2021 (Eines d'automatització de proves de control de qualitat)
- Proveu les vostres capacitats d'anàlisi i poder de pensament: exercicis de prova de programari (part 2)
- Què és la tècnica de proves basades en defectes?
- Què és l'anàlisi del valor límit i el particionament d'equivalència?
- Prova de descàrrega de llibres electrònics
- Què és el cicle de vida de defectes / errors en les proves de programari? Tutorial del cicle de vida de defectes
- Prova de càrrega amb tutorials HP LoadRunner