Sơ đồ xương cá học tiếng Anh

Sơ lược về biểu đồ xương cá và sử dụng biểu đồ xương cá trong quản lý chất lượng dự án test.

• Báo cáo

I. Giới thiệu về biểu đồ xương cá

1. Biểu đồ xương cá là gì

・ Biểu đồ xương cá, hay còn gọi là biểu đồ Ishikawa hay biểu đồ nguyên do – tác dụng ( Fishbone diagram, Ishikawa diagram, Cause-and-effect diagram ) là 1 trong 7 công cụ trấn áp chất lượng cơ bản như liệt kê dưới đây, là một chiêu thức nhằm mục đích nhận diện yếu tố và đưa ra giải pháp, một trong những yếu tố cốt lõi để kiến thiết xây dựng – bảo vệ – nâng cao chất lượng .Nội dung chính

• Sơ lược về biểu đồ xương cá và sử dụng biểu đồ xương cá trong quản lý chất lượng dự án test.
• I. Giới thiệu về biểu đồ xương cá
• II. Sử dụng biểu đồ xương cá trong quản lý chất lượng dự án test
• Video liên quan

a. Fishbone diagram (Cause-and-effect diagram, Ishikawa diagram): biểu đồ xương cá

b. Check sheet : phiếu ( biểu ) kiểm tra
c. Control charts : biểu đồ trấn áp
d. Histogram : biểu đồ phân bổ
e. Pareto chart : biểu đồ Pareto
f. Scatter diagram : biểu đồ phân tán
g. Flow charts : biểu đồ dòng chảy
・ Công cụ này do giáo sư Kaoru Ishikawa – một giáo sư chuyên ngành kỹ thuật của trường ĐH Tokyo sáng tạo vào thập niên 50 .
・ Đây là một biểu kỹ thuật đồ họa, có hình dạng giống xương cá, lấy cơ sở là kim chỉ nan thống kê, tích lũy những tài liệu theo mục tiêu đã định, nghiên cứu và phân tích những tài liệu để xử lý hoặc nâng cấp cải tiến yếu tố. Nó được gọi là cơ bản vì 1. ngay cả những người ít được giảng dạy về thống kê cũng hoàn toàn có thể sử dụng được và 2. nó hoàn toàn có thể được sử dụng để xử lý hầu hết những yếu tố tương quan đến chất lượng .
・ Công cụ này đã được vận dụng hiệu suất cao từ những năm 1960 s và đã được người Nhật sử dụng rất thành công xuất sắc .

2. Tác dụng của việc sử dụng biểu đồ xương cá

• Đưa ra một cấu trúc, khuynh hướng cho việc xác lập nguyên do. -> Giúp cho việc xác lập nguyên do nhanh gọn và hiệu suất cao .
• Khi vận dụng biểu đồ này, người dùng sẽ có năng lực tìm ra những nguyên do tiềm tàng và nguyên do cốt lõi gây nên yếu tố .
• Nhìn vào biểu đồ xương cá này, người đọc sẽ cóhình dung rất đầy đủ nguyên do của một yếu tố. Việc lập biểu đồ sẽ chỉ rõ từng nguyên do, từ đó hoàn toàn có thể đưa ra hướng giải pháp đơn cử cho từng nguyên do một .

3. Cách tạo một biểu đồ xương cá

Bước 1 : Xác định yếu tố. Vấn đề này chính là hệ quả của nguyên do sẽ xác lập .
Bước 2 và bước 3 là xác lập nguyên do chính và nguyên do phụ. Có thể thực thi theo 1 trong 2 cách sau .
Cách 1 :

• Bước 2 : Động não, tâm lý tỷ mỉ kỹ lưỡng để tìm ra tổng thể những nguyên do hoàn toàn có thể có của yếu tố. Ở bước này chưa phân biệt nguyên do chính và nguyên do phụ .
• Bước 3 : Sắp xếp, tổ chức triển khai lại tổng thể những tác dụng đã động não được. Nhóm những nguyên do phụ lại vào trong 1 nguyên do chính .

Cách 2 :

• Bước 2 : Liệt kê list toàn bộ những nguyên do chính của yếu tố. Có thể vận dụng 5W 1H, vấn đáp cho những câu hỏi What : yếu tố gì, Who : những ai tương quan, When : xảy ra khi nào, Where : Xảy ra ở đâu, Why : Tại sao xảy ra, How : xảy ra như thế nào … để đưa ra nguyên do chính
• Bước 3 : Tiếp tục động não tâm lý những nguyên do đơn cử hơn, trực tiếp gây ra nguyên do chính ( Nguyên nhân cấp 1 ). Nếu cần nghiên cứu và phân tích sâu hơn thì liên tục tìm ra những nguyên do khác nhỏ hơn, trực tiếp gây ra nguyên do cấp 1 .

Bước 4 : Xây dựng một biểu đồ xương cá, hiển thị đúng chuẩn mối quan hệ giữa những data trong mỗi category như những bước dưới đây
+ Vẽ 1 ô vuông ở ngoài cùng bên tay phải của tờ giấy
+ Vẽ 1 mũi tên nằm ngang, hướng đầu mũi tên về phía ô vuông ở trên
+ Bên trong ô vuông trên, viết miêu tả yếu tố đang nỗ lực xử lý
+ Từ trục chính nằm ngang này, vẽ những nhánh chính và viết tên của những category ở phía trên và phía dưới của đường mũi tên nằm ngang trên ( Đây như thể những cành to của một thân cây chính )
+ Từ những nhánh chính này, vẽ những nhánh phụ và viết nguyên do chi tiết cụ thể cho mỗi category ( Đây như thể những cành nhỏ và những nhánh con )
Mỗi biểu đồ xương cá sẽ có rất nhiều nhánh con. Nếu biểu đồ không có nhiều nhánh con thì nó biểu lộ rằng việc hiểu yếu tố còn đang rất hời hợt, chưa hiểu rõ thực chất của yếu tố. Có thể phải cần có sự giúp sức của người khác tương hỗ để hiểu yếu tố, ví dụ như người mà tương quan trực tiếp đến yếu tố .

4. Khi lập biểu đồ xương cá thì cần chú ý các vấn đề sau

• Cần có sự tham gia của toàn bộ những người có tương quan đến yếu tố, từ người quản trị đến người tương quan trực tiếp và tương quan gián tiếp đến yếu tố. Vấn đề cần được xem xét, nghiên cứu và phân tích, cần có sự trao đổi quan điểm giữa những bên tương quan trực tiếp và gián tiếp .
• Cần nhìn yếu tố một cách toàn diện và tổng thể tổng lực để hoàn toàn có thể tìm ra rất đầy đủ toàn bộ những nguyên do hoàn toàn có thể có .
• Người thiết kế xây dựng biểu đồ cần biết lắng nghe, tiếp thu quan điểm mà những người có tương quan trực tiếp cũng như gián tiếp đến yếu tố đã đưa ra, tổng hợp, tóm gọn những quan điểm lại .
• Sau khi kiến thiết xây dựng, cần đưa biểu đồ ra để hàng loạt những thành viên review lại, bổ trợ và chỉnh sửa nếu cần. Ngoài ra hoàn toàn có thể hỏi thêm quan điểm của một vài người khác có kỹ năng và kiến thức về hoạt động giải trí của quy trình .

II. Sử dụng biểu đồ xương cá trong quản lý chất lượng dự án test

Đối với 1 dự án Bất Động Sản ứng dụng, việc bảo vệ chất lượng của đợt test, không để bỏ sót bug là rất là quan trọng. Ngay khi phát hiện ra tester đã để lọt bug ( kể cả quy trình tiến độ đang test và tiến trình đã release cho người mua ) thì tất cả chúng ta cần phải tìm ra nguyên do vì sao để sót lỗi để có hướng ngăn ngừa cho những lần test sau .
Khi tìm hiểu nguyên do vì sao để sót lỗi, tôi thấy hoàn toàn có thể xảy ra những trường hợp sau :

1. Đã có testcase để check cho trường hợp đó. => Ở đây chúng ta cần phải tìm nguyên nhân Vì sao bug đó đã không được raise lên cho khách hàng ?

1.1 Đã làm đúng hàng loạt những điều kiện kèm theo phát sinh bug : môi trường tự nhiên, thao tác v.v, bug có xảy ra nhưng lại không report cho người mua do :

• Tester không nhận thức đó là bug nên đã không report lên .
• Tester nhận thức đó là bug nhưng lại lack không report lên. Ví dụ tester note lại trong testcase bản cứng hoặc bản mềm, sau đó quên không log trong file defect gửi cho người mua .
• Bug đã chỉ phát sinh đúng 1, 2 lần. Sau đó làm lại thì bug không xảy ra nên Tester đã không report. Hoặc để tái hiện, tìm hiểu thì mất thời hạn chuẩn bị sẵn sàng thiên nhiên và môi trường, thời hạn test không còn nhiều nên đã không có đủ thời hạn tìm hiểu và khám phá lại, nên không report .
• Tester nhận thức là bug, có report lên nhưng bị team leader reject .
• Tester nhận thức là bug, có report lên nhưng team leader đã để sót bug này khi tổng hợp để report cho người mua .

1.2 Đã không có rất đầy đủ những điều kiện kèm theo phát sinh bug nên khi test, bug đã không xảy ra. Vì thế không phát hiện ra được. TH1 ： Thao tác test đúng, nhưng môi trường tự nhiên test không đúng ( Trường hợp lỗi chỉ xảy ra trên 1 thiên nhiên và môi trường đặc định ) .

• Khách hàng có require test trên thiên nhiên và môi trường đó nhưng lại để sót thiên nhiên và môi trường .
• Khách hàng có require test trên môi trường tự nhiên đó nhưng khi dựng môi trường tự nhiên lại làm không đúng theo require .

• Windows không được update theo đúng require của khách hàng.
• Môi trường không sạch: ví dụ như trước đó đã thực hiện install, uninstall nhiều lần rồi.
• Thiếu không cài 1 số phần mềm mà khách hàng đã yêu cầu.
• Cài sai version của 1 số phần mềm mà khách hàng đã yêu cầu.

• Khách hàng không require cụ thể mà cho chọn môi trường, và khi test testcase đó thì đã test trên môi trường khác.

  Xem thêm: Download 214 bộ thủ chữ Hán tiếng trung qua thơ lục bát [pdf]

• Khách hàng không chỉ định test trên thiên nhiên và môi trường đó .

TH2 ： Môi trường test đúng, nhưng thao tác test chưa đúng ( Trường hợp lỗi chỉ xảy ra khi thực thi đúng theo những bước XYZ ) .

• Testcase đã ghi thao tác đơn cử và nếu thực thi theo đúng testcase thì sẽ ra bug. Tuy nhiên tester đã đọc sót testcase, dẫn đến sót thao tác .
• Testcase đã ghi thao tác đơn cử và nếu thực thi theo đúng testcase thì sẽ ra bug. Tuy nhiên tester đã hiểu sai 1 số thao tác nên đã triển khai thao tác khác .
• Testcase đã ghi thao tác đơn cử và nếu thực thi theo đúng testcase thì sẽ ra bug. Tuy nhiên tester đã triển khai không theo đúng tuần tự những bước đã ghi, ví dụ như thực thi bước 3 -> bước 2
• Testcase đã ghi thao tác đơn cử và nếu triển khai theo đúng testcase thì sẽ ra bug. Tuy nhiên trong quy trình thực thi những bước theo testcase, tester đã thực thi thêm 1 bước nào đó không ghi trong testcase. Tuy nhiên tester lại nhận thức rằng đáng lẽ phải có thêm bước đó, và cũng không confirm lại với người mua khi thấy testcase không ghi bước đó .
• Testcase đã ghi thao tác đơn cử và nếu thực thi theo đúng testcase thì sẽ ra bug. Tuy nhiên trong quy trình thực thi những bước theo testcase, tester đã vô tình triển khai thêm 1 bước nào đó không ghi trong testcase .
• Testcase không ghi thao tác đơn cử, và tester có thể thao tác theo nhiều kiểu khác nhau đều sẽ ra tác dụng xác nhận. Và trong thực tiễn thì thao tác mà tester đã thực thi không đúng với thao tác để hoàn toàn có thể sinh ra bug .

1.3 Tester đã không test testcase đó

• Khách hàng có require test testcase đó nhưng do leader hiểu sai requirement nên đã không giao cho tester test
• Khách hàng có require test testcase đó nhưng trong quy trình giao testcase cho tester, leader đã bị giao sót testcase đó : ví dụ in sót, hoặc in bị lỗi, hoặc testcase đó vô tình bị bôi đen đi .
• Leader có giao testcase đó nhưng Tester đã bị bỏ sót không test testcase đó .
• Khách hàng được cho phép chọn testcase random và leader đã không chọn testcase đó .
• Khách hàng được cho phép chọn testcase random và leader để cho tester tự chọn. Bản thân tester đã không chọn testcase đó .
• Khách hàng đã không nhu yếu test testcase đó

2. Đã không có testcase check cho trường hợp đó => Ở đây chúng ta cần phải trả lời cho câu hỏi Vì sao testcase đó đã không được add vào ?

• Testcase do khách hàng cung cấp, khách hàng đã không tạo testcase đó.
• Testcase do dự án viết theo những chỉ định của khách hàng. Trong nội dung chỉ định thì đã không có nội dung đó.
• Testcase do dự án viết theo chỉ định của khách hàng. Trong nội dung chỉ định có trường hợp đó nhưng người viết đã bị bỏ sót.
• Testcase do dự án viết theo chỉ định của khách hàng. Trong nội dung chỉ định thì có nội dung đó, nhưng khi viết testcase đã không cover được hết các trường hợp thao tác.

=> => Từ việc tìm hiểu và khám phá những nguyên do như trên tất cả chúng ta hoàn toàn có thể đưa ra biểu đồ xương cá với những nguyên do chính và nguyên do phụ như sau .
Nhìn vào biểu đồ trên, ta hoàn toàn có thể thấy ở toàn bộ những quy trình tiến độ của quy trình test, nếu tất cả chúng ta không làm tốt từng tiến trình, không trấn áp ngặt nghèo chất lượng từng quá trình thì quá trình nào cũng hoàn toàn có thể là nguyên do dẫn đến bị bỏ sót bug. Ví dụ như ngay từ bước tạo file requirement thông tư nội dung test, nếu bản requirement có format khó đọc, khó nhìn, dễ gây hiểu nhầm, hay nội dung liên tục bị update lại thì sẽ làm cho người được thông tư dễ bị hiểu sai, sót requirement -> bỏ sót nội dung cần test -> để sót bug ( test lead hay tester ). Hoặc quy trình tiến độ report sau cuối, nếu việc quản trị file log bug không tốt, thì cũng dễ dẫn đến leader report sót bug cho người mua .
Trên đây mình đã đưa ra những nguyên do hoàn toàn có thể dẫn đến bỏ sót bug. Hi vọng nó sẽ giúp những bạn đang quản trị dự án Bất Động Sản test cũng như những bạn đang thực thi việc test có cái nhìn vừa đủ về tổng thể và toàn diện dự án Bất Động Sản, có giải pháp quản trị chất lượng cho từng quy trình tiến độ để bảo vệ chất lượng chung của cả dự án Bất Động Sản .

Thông thường khi xảy ra một yếu tố thì nguyên do thường được đổ lỗi lòng vòng. Điều này gây ra sự mẫu thuẫn trong nội bộ, cũng như sự thiếu trung thực, đổ lỗi lẫn cho nhau dẫn tới việc communication giữa những bên thất bại dẫn tới hoạt động giải trí hoặc dự án Bất Động Sản hoàn toàn có thể bị đổ vỡ. Cách tốt nhất xử lý việc này là cần xác lập được nguyên do cốt lõi ( root cause ) của yếu tố thay vì chỉ quan sát vẻ bên ngoài của yếu tố ( mà tất cả chúng ta gọi là hiện tượng kỳ lạ ) .

Cách thức mang tính hệ thống và có cơ cấu này người ta gọi làRoot Cause Analysis. Có nhiều công cụ ứng dụng để phát triển Root Cause Analysis thì cách phổ biến nhất được nhiều công ty sử dụng là mô hình 5 TẠI SAO ?(5 WHY?)của công ty TOYOTA. Cơ bản công cụ này được hiểu là việc sử dụng câu hỏi TẠI SAO nhiều lần cho đến khi tìm ra được yếu tố cốt lõi nhất (atomic-yếu tố hạt nhân) nhưng phải đảm bảo có thể xử lý được (actionable). Để mô hình hóa quy trình 5-WHY? người ta áp dụng mô hình xương cá(Fishbone Diagram hay Ishikawa diagram ).

Lịch sử

Biểu đồ xương cá( fishbone diagram ) hay biểu đồ nguyên nhân kết quả có tên gốc là phương pháp Ishikawa là 1 phương pháp nhằm nhận diện vấn đề và đưa ra giải pháp trong quản lý, lãnh đạo.

Được ông Kaoru Ishikawa đưa ra vào những năm 1960. Ông là người tiên phong về quản trị chất lượng tại nhà máy sản xuất đóng tầu Kawasaki và được xem là người có công với quản trị hiện tại .

Biểu đồ xương cá là gì?

Được xem là 1 trong 7 công cụ cơ bản của Quản lý chất lượng, gồm có Histogram, ParetoChar, checksheet, control chart, Flowchart và scatter diagram .Nó được gọi là xương cá vì biểu đồ này có hình dạng giống xương cá .

Mục đích

Phân tích biểu đồ nhân quả giúp tổ chức triển khai tưởng tượng xuyên suốt những nguyên do của một yếu tố, nó hoàn toàn có thể gồm có cả những nguyên do nền tảng mà không phải chỉ là những hiện tượng kỳ lạ .Phát triển những kế hoạch để xác nhận rằng những nguyên do tiềm ẩn là những nguyên do thực sự .Cung cấp cấu trúc cho nỗ lực xác lập nguyên do .

Thảo luận về biểu đồ cuối cùng

Khi lý giải một biểu đồ nhân quả, trách nhiệm chính của tổ chức triển khai là kiểm tra sự triển khai xong hay tính không thiếu của biểu đồ. Để làm tốt điều này, tất cả chúng ta hoàn toàn có thể xem xét những điểm sau :+ Chắc chắn rằng những câu hỏi theo dạng 4W s và 5M s hoặc 5P s đã được vận dụng cho tác động ảnh hưởng hoặc hiện tượng kỳ lạ .+ Thông thường, mỗi một nhánh chính của biểu đồ sẽ được thêm vào tối thiểu từ 3 đến 4 nhánh nhỏ .+ Xác minh lại rằng nguyên do ở cuối của mỗi chuỗi nhân quả là một nguyên do căn nguyên tiềm ẩn bằng cách kiểm tra tính logic trong mối quan hệ nhân quả, trải qua tổng thể những nguyên do trung gian tới ảnh hưởng tác động sau cuối .Biểu đồ nhân quả quan trọng ở chỗ, nó phân biệt giữa giả định và trong thực tiễn. Biểu đồ nhân quả bộc lộ những giả định, chi khi những giả định này được kiểm tra với số liệu tất cả chúng ta mới hoàn toàn có thể chứng tỏ được những nguyên do của hiện tượng kỳ lạ đã quan sát thấy .Gợi mở ra những hiện tượng kỳ lạ vượt ra ngoài số lượng giới hạn giúp tổ chức triển khai trong việc phát hiện những nguyên do nền tảng tiềm tàng .Xác định những nguyên do mà tổ chức triển khai cho rằng đây là những nguyên do then chốt nhất cho sự tìm hiểu tiếp theo. Đồng thời, ghi lại những nguyên do đó lại .Làm sáng tỏ những nguyên do căn nguyên bằng một hoặc nhiều những cách sau :+ Tìm những nguyên do mà Open lặp đi tái diễn tại những nhánh xương nguyên do chính .+ Tập hợp tài liệu trải qua những checksheet hoặc những dạng khác để xác lập mối quan hệ liên tục của những nguyên do khác nhau .

Chú ý:
Để làm được một biểu đồ xương cá hiệu quả không phải là một nhiệm vụ dễ dàng, có thể nói rằng, những ai thành công trong giải quyết vấn đề kiểm soát chất lượng là những người thành công trong việc tạo ra một biểu đồ nhân quả hữu ích.

Khi mối quan hệ giữa nguyên do nền tảng và ảnh hưởng tác động đã được xác lập, để hiểu được độ mạnh của mối quan hệ nhân quả này cần sử dụng những số liệu khách quan. Khi đó, đặc tính và những yếu tố có tính nguyên do cần được thống kê giám sát. Nếu không hề thống kê giám sát chúng, tổ chức triển khai cần nỗ lực làm chúng hoàn toàn có thể đo lường và thống kê được hoặc tìm những đặc tính thay thế sửa chữa tương thích .

Sự kiểm tra các yếu tố dựa trên những kinh nghiệm và kỹ năng của các thành viên trong nhóm là rất quan trọng, nhưng lại rất nguy hiểm để đưa ra những quyết định có tầm quan trọng thông qua sự nhận thức chủ quan hoặc mang tính cảm giác. Bởi vậy, việc xác định tầm quan trọng cho các yếu tố phải bằng cách sử dụng các dữ liệu khách quan bao gồm cả tính khoa học và logic.

Tổ chức hoàn toàn có thể sử dụng biểu đồ nhân quả như một dạng văn bản. Văn bản này sẽ được update song song với việc tổ chức triển khai thu thập dữ liệu hoặc thử nghiệm những giải pháp khác nhau nhằm mục đích xử lý yếu tố .

Các bước tạo một Biểu đồ Xương cá

1. Xác định vấn đề: ghi lại chính xác vấn đề một cách chi tiết ( áp dụng 5w: what, who, when, where, how). Viết vấn đề vào ô bên phải tờ giấy. Sau đó kẻ một đường ngang, chia giấy của bạn ra làm 2. Lúc này bạn đã có đầu & xương sống của con cá trong sơ đồ xương cá.
2. Xác định các nhân tố ảnh hưởng: ứng với mỗi nhân tố, vẽ một nhánh xương sườn. Cố gắng liệt kê càng nhiều nhân tố càng tốt, ví dụ hệ thống, cơ sở vật chất, máy móc, nguyên liệu, yếu tố bên ngoài ..v..v Nếu bạn có 1 nhóm để xử lý vấn đề thì đây là lúc cần áp dụng các kỹ thuật brainstorming.
3. Tìm ra nguyên nhân có thể có, thuộc về từng nhân tố (đã tìm ra trong bước 2), ứng với mỗi nguyên nhân, lại vẽ một nhánh xương con. Nếu nguyên nhân của bạn quá phức tạp, có thể chia nhỏ nó thành nhiều cấp.
4. Phân tích sơ đồ: sơ đồ đã xây dựng là một danh sách đầy đủ các nguyên nhân có thể xảy ra, bạn có thể kiểm tra, khảo sát, đo lường .v..v.. để xác định đâu là các nguyên nhân chính rồi từ có có những kế hoạch cụ thể để sửa chữa.

Ví dụ
Phân tích các nguyên nhân của vấn đề: Nhân viên không áp dụng những phương pháp mới đã được đào tạo. Sau khi thảo luận để tìm ra nguyên nhân, nhóm làm việc biểu diễn bằng 1 sơ đồ xương cá như sau: