QUY TRÌNH DMADV LÀ GÌ?
DMADV là một phương pháp quản lý chất lượng Six Sigma được sử dụng để thiết kế các quy trình mới, với mục tiêu cung cấp sản phẩm cuối cùng cho khách hàng một cách chính xác. Mục tiêu của Quy trình DMADV là tạo ra một sản phẩm chất lượng cao, luôn chú trọng đến khách hàng và nhu cầu của khách hàng trong mỗi giai đoạn của dự án.
Mỗi chữ cái của từ viết tắt DMADV là một trong năm giai đoạn chính của quá trình cải tiến dự án.
Agile đã từng chỉ là lĩnh vực lập trình và phát triển phần mềm. Nó đã được sử dụng rộng rãi trong quân đội Hoa Kỳ, đặc biệt là Không quân, nhưng nó đã được chuyển sang quản lý dự án vào khoảng năm 2000. Vì hầu hết các sáng kiến chất lượng được quản lý dưới dạng dự án, có nghĩa là Agile bắt đầu chuyển sang quản lý chất lượng vào khoảng năm 2010. Dựa trên ý tưởng của lập kế hoạch thích ứng, phát triển theo hướng cải tiến, phân phối sớm và cải tiến liên tục, Agile khuyến khích phản ứng nhanh chóng và linh hoạt với sự thay đổi.
Nó trở thành giao dịch ở chỗ Agile cũng tập trung vào việc quản lý con người và các tương tác của họ hơn là các quy trình hoặc công cụ của phương pháp mà họ đang tuân theo. Agile tìm cách liên tục cộng tác với khách hàng trong quá trình phát triển sản phẩm, đồng thời đáp ứng các thay đổi — ngay lập tức. Các thuật ngữ bên ngoài / khu vực / quân sự cũng đã được kết hợp, khiến việc giao tiếp trong Agile đôi khi trở nên khó khăn.
Một cái nhìn về Agile
Bản thân Agile khác với các triết lý quản lý thay đổi khác là không chấp nhận sự thay đổi phạm vi hoặc thậm chí đầu vào của khách hàng (sau khi thu thập thông số ban đầu). Agile có nghĩa là sử dụng lặp đi lặp lại và thích ứng nước rút, tạo ra một làn sóng cuộn các cột mốc có thể lướt (cưỡi sóng lăn tăn) với một lấy (hướng dòng chảy) nhưng để lại sự linh hoạt cho nhóm thực hiện các yêu cầu. Điều này ngược lại với thác nước nơi mà một khi bạn đã đi qua một điểm nhất định, rất khó để quay lại ngược dòng ngay cả khi có công tắc tìm nạp (thay đổi hướng dòng chảy). Một phần của ma trận rủi ro phải xem xét tiềm năng giày dép (có công việc chồng chất vào cuối dự án yêu cầu tài nguyên bị hỏng) hoặc sự xuất hiện của đường sức từ (các chuyển động từ nhiều hướng kết hợp để tạo ra một kịch bản trong đó luồng quá lớn đến mức không thể xử lý được bất kể số lượng tài nguyên được sử dụng) dẫn đến odzi hoặc là anine (điểm thất bại hoặc hủy dự án) hoặc Tất cả Pau (tiêu cực hơn).
Thuật ngữ Agile đã thay đổi qua nhiều năm liên quan đến các cuộc thảo luận về vận tốc và quán tính của một dự án cũng như cách dự báo đúng quy trình làm việc. Ngôn ngữ Agile đã thay đổi nhiều hơn khi phương pháp luận được tích hợp vào quản lý chất lượng và cơ sở người dùng của nó được mở rộng. Ví dụ, một số thuật ngữ được đánh dấu ở trên là từ cộng đồng lướt sóng, tàn dư của những người nói chuyện mật mã của quân đội Mỹ bản địa với một chút tiếng Hawaii xen lẫn.
Một nhiệm vụ quan trọng đối với học viên cải tiến liên tục là đảm bảo rằng khi một thuật ngữ được sử dụng, mọi người trong nhóm đều hiểu những gì đang được thảo luận! Như bạn có thể thấy trong phần này ở trên, thuật ngữ này có thể sẽ làm quen một chút.
Là một quy trình quản lý chất lượng, Agile có thể được sử dụng dễ dàng nhất bên trong dự án DMADV (Xác định, Đo lường, Phân tích, Thiết kế, Xác minh). Nó có thể được sử dụng để giải quyết các nhu cầu phát sinh khi việc sử dụng phần mềm hoặc tự động hóa là yếu tố quan trọng trong việc đáp ứng mong muốn của khách hàng – thường xảy ra nhất khi chuyển từ xử lý thủ công sang cơ giới hóa hệ thống / quy trình được thiết kế riêng.
Sprint là gì?
Từ góc độ quản lý chất lượng, sprint là một công việc lặp đi lặp lại và tương tự như cam kết Kaizen / Kaikaku trong đó có một tập hợp cụ thể các yếu tố đầu vào và đầu ra dự kiến để thực hiện một mục đích riêng. Tuy nhiên, trong một giai đoạn nước rút, có rất nhiều nỗ lực được thực hiện (tương tự như trong quản lý dự án để làm một dự án bị hỏng) và phải tuân theo một mốc thời gian khó và nhanh (hộp thời gian). Thời gian chạy nước rút thường là 30 ngày nhưng có thể ngắn nhất là một tuần hoặc dài nhất là sáu tuần. Nhưng sự khác biệt lớn nhất là trong khi Kaizen tạo ra sự cải tiến gia tăng, kết quả của một sprint có thể là một thứ gì đó được sử dụng lại hoặc một thiết kế hoàn toàn mới.
Kết hợp Scrum hàng ngày
Trong phát triển phần mềm, một cuộc họp Scrum dự kiến sẽ diễn ra vào mỗi buổi sáng để đảm bảo rằng mọi người đều ở trên cùng một trang và dòng thời gian về 1) quy trình làm việc và 2) những gì đang được nhắm mục tiêu để hoàn thành trong ngắn hạn. Cuộc họp Scrum hàng ngày không được kéo dài hơn 15 phút. Scrum hàng ngày không chỉ là một bản cập nhật trạng thái; đó là một kiểm tra xung sẽ làm sáng tỏ bất kỳ trở ngại nào đang làm chậm tiến độ của nhóm.
Trong Scrum hàng ngày, mỗi thành viên của nhóm phát triển nên trả lời ngắn gọn các câu hỏi sau:
- Bạn đã làm gì ngày hôm qua?
- Bạn sẽ làm gì hôm nay?
- Có bất kỳ trở ngại nào trên đường đi không?
Mỗi người tham gia cuộc họp Scrum này nên lắng nghe những người khác và vẫn có mặt trong toàn bộ cuộc họp. Thông thường, các thành viên của nhóm phát triển sẽ xác định các cơ hội làm việc cùng nhau trong ngày dựa trên các cuộc thảo luận trong Scrum hàng ngày.
Trong quản lý chất lượng, Scrum có thể chỉ diễn ra hàng tuần hoặc vào cuối chu kỳ nước rút. Scrum Master sẽ thiết lập tiến độ tần suất của các cuộc họp Scrum và các kết quả mong muốn. Scrum Master sử dụng thông tin về các thông số tổng thể của dự án và kiến thức về tốc độ xử lý và lịch trình chạy nước rút để thúc đẩy tiến độ tổng thể.
Cuộc họp Scrum là cuộc họp thiết lập cấp độ được sử dụng để đảm bảo rằng tất cả các thành viên trong nhóm đều bắt kịp trạng thái hiện tại của dự án và thực hiện một cuộc họp Scrum để xác định xem dự án đã sẵn sàng để tiếp tục hay chưa hoặc nếu công việc bổ sung phải được hoàn thành trước khi chuyển tiếp động lượng được nối lại.
Scrum là một sự tương tác trong đó những thành viên trong nhóm mong muốn tiến lên phía trước phải đối mặt với những người tin rằng sản phẩm chưa sẵn sàng cho lần lặp tiếp theo. Điều này tương tự như phân tích trường lực nhưng được thực hiện nhanh chóng bằng lời nói với Scrum Master đưa ra quyết định cuối cùng. Bên có lập luận mạnh mẽ hơn thường thắng. Nếu có vấn đề cần được làm lại để hoạt động bình thường, Scrum Master có thể yêu cầu những người chống lại việc tiến lên thực hiện một cuộc chơi song song ngắn hoặc chạy nước rút song song để hoàn thành các mối quan tâm, trong khi phần còn lại của nhóm thực hiện nước rút tiếp theo. (Nước rút tiếp theo đó thường được quyết định thông qua một Scrum và được chọn từ một công việc tồn đọng được ưu tiên.)
Tỷ lệ Burndown dựa trên số lượng nhân lực được giao cho dự án (dựa trên kiến thức-kỹ năng-hoạt động [KSA] và cấu trúc công việc [WBS] và được phân bổ ban đầu thông qua phân tích chuyển ngược về các nhiệm vụ đã biết) sau đó có thể được phân bổ để hoàn thành các nhiệm vụ. Các nhiệm vụ (tồn đọng hoặc tập hợp các nhiệm vụ đang chờ) thường được thiết lập trong một hệ thống kanban từ WBS (một số người gọi nó là scrumban) trong đó các tác vụ tuần tự được kéo vào hàng đợi để công việc được hoàn thành theo thứ tự. Những công việc phải thực hiện song song được kéo cùng lúc để bắt đầu công việc, mặc dù chúng có thể được hoàn thành với tốc độ khác nhau. Kanban dựa trên các biến và sự phụ thuộc được kết nối với nhau và đây là lý do tại sao quyết định Scrum lại quan trọng đến vậy – cũng như kiến thức / chủ đề chuyên môn của Scrum Master.
Agile Scrum
Agile Scrum là Lean vì nó được xây dựng từ trạng thái hiện tại, nơi giá trị được ánh xạ để đáp ứng trạng thái trong tương lai thông qua mô hình kết quả theo hướng câu chuyện, như chúng đã được biết đến. Mô hình thay đổi theo kiểu Agile với mỗi đầu vào để suy ra trạng thái trong tương lai. Câu chuyện dựa trên việc khách hàng mong muốn trải nghiệm của họ với hệ thống sẽ như thế nào, điều này thường thay đổi (sự biến động trong đó công việc tồn đọng được tinh chỉnh). Sau đó, hệ thống được thiết kế, phát triển, chế tạo, thử nghiệm và triển khai để cung cấp trải nghiệm đó. Điều này được thực hiện bằng thử nghiệm khám phá thông qua áp dụng hoặc các bài tập chạy vượt qua hoặc chạy thất bại trong đó mỗi lần thất bại trở thành một “bài học” thúc đẩy một cầu nối hoặc sự hoàn thành để thu hẹp khoảng cách.
Một phép tính giá trị kiếm được đang chạy (thường được sử dụng trong quản lý dự án) có thể được sử dụng để thông báo cho Scrum Master về lượng tài nguyên được phân bổ của mình đã được sử dụng trong khi theo dõi thời gian, chi phí và chất lượng vào cuối mỗi chu kỳ chạy nước rút. Sau đó, chi phí thực tế có thể được so sánh với giá trị kế hoạch tại thời điểm đó và giá trị thu được của dự án đã biết. Tỷ lệ burndown rate và tồn đọng lịch trình dự án (danh sách xác định nhiệm vụ của các nhiệm vụ từ WBS) cho biết liệu một dự án có đang đi đúng hướng hay không và liệu Scrum Master có đủ nguồn lực để hoàn thành công việc hay không hoặc chi phí sẽ là bao nhiêu nếu cần thêm nguồn lực. Nếu dự án hoặc các phân đoạn của dự án đang chạy chậm tiến độ, Scrum Master có thể phải “phá vỡ” dự án bằng các nguồn lực bổ sung để đưa nó trở lại đúng tiến độ trước khi bắt đầu nước rút tiếp theo. Điều này chỉ có thể được xác định trong các cuộc họp Scrum và đó là lý do tại sao chúng thường được tổ chức hàng ngày để các vấn đề có thể được khắc phục trước khi hoàn tất quá trình lặp lại sprint hiện tại.
Khi kết thúc dự án, một Scrum of Scrums sẽ xảy ra để xác định xem tất cả các tham số của dự án đã được đáp ứng và đang hoạt động hay chưa. Điều này tương tự như trạm thu phí theo giai đoạn Kiểm soát / Xác minh trong Six Sigma, nhưng có thể yêu cầu trình diễn hệ thống cho các bên liên quan và khách hàng để đảm bảo xác minh và xác nhận hệ thống hoặc nếu cần hành động hồi tố.
Dễ dàng nhận thấy lợi ích của việc sử dụng Agile trong công việc chức năng quản lý chất lượng của bạn. Nếu bạn chưa sử dụng Agile trong DMADV, hãy thử! Nó có thể mang lại kết quả tích cực.
