Ƣu tiên

Một phần của tài liệu Nghiên cứu phương pháp Kanban và áp dụng phát triển phần mềm quản lý con dấu (Trang 39)

Để kéo công việc vào dòng chảy đúng thứ tự ta phải có một hệ thống phân phối phần mềm làm việc có khả năng phân phối tin cậy, không gặp khó khăn về chất lƣợng và thứ tự ƣu tiên. Nếu không có một hệ thống nhƣ vậy, nên dành nhiều thời gian để sữa chữa các vấn đề không thể phân phối đầu tiên. Trong mọi trƣờng hợp, không có lý do

gì để dừng lại cách ƣu tiên công việc hiện tại của chúng ta, vì vậy hãy làm điều đó và xem xét việc sử dụng các chiến lƣợc sau đây.

Làm thế nào để chúng ta ƣu tiên công việc tốt nhất có thể? Trong bƣớc 7, chúng ta sẽ xem làm thế nào các loại công việc khác nhau nền đƣợc xử lý khác nhau, nhƣng bây giờ, hãy xem xét ví dụ thứ tự ƣu tiên cho một loại công việc nhƣ “câu chuyện ngƣời dùng” (“user stories”):

* Chi phí trễ

Nguyên tắc mặc định là chi phí trễ (Cost of Delay - COD).Chi phí trễ mô tả doanh thu hoặc phí tiết kiệm bị mất bởi việc chọn không làm việc trên một hạng mục đã cho. Ƣu tiên cao nhất nên là một hạng mục với COD cao nhất. Trong thực tế, COD thông thƣờng đƣợc tính bằng chi phí của sự thực hiện (Cost of Implementation), thời hạn, thời gian và các yếu tố khác. Việc cần làm là tập trung vào khái niệm mất cơ hội và mọi thời điểm ta chọn để làm việc trên một cái gì đó, ta đang chọn lựa để chặn một vài cái khác. Tính toán COD chính xác gần nhƣ là không thể trong công nghệ thông tin, vì vậy chúng ta sẽ thƣờng phải làm việc với các dự đoán tốt nhất hiện tại dựa trên các dữ liệu có sẵn.

* Trực quan ưu tiên

Để đảm bảo chúng ta chọn đúng hạng mục để làm, hàng đợi đầu vào của chúng ta nên luôn luôn thể hiện sự ƣu tiên và công việc mới đƣợc kéo từ trên xuống. Lập kế hoạch một loạt các công việc chạy nƣớc rút, hoặc với cách dựa trên dòng chảy là liên tục kéo công việc có độ ƣu tiên cao nhất. Hình 3.11 là một ví dụ về vấn đề này.

Các yếu tố ƣu tiên quan trọng khác:

- Rủi ro và không ổn định. Mua thông tin sớm cho việc ra các quyết định rủi ro cao và ảnh hƣởng cao.

- Các nhu cầu cơ bản: Cơ sở hạ tầng của dự án, v.v

- Cân bằng kích cỡ: Pha trộn kích thƣớc câu chuyện (yêu cầu ngƣời dùng) để giữ dòng chảy ổn định.

- Cân băng các loại câu chuyện ngƣời dùng: Pha trộn các yêu cầu chức năng và phi chức năng để đảm bảo dòng chảy ổn định.

- Các phụ thuộc: Xử lý các phụ thuộc để chủ động làm việc mà không gặp các khó khăn.

Nếu đang làm việc với các danh sách công việc cần làm truyền thống hoặc 1 đặc tả yêu cầu giồng nhƣ mô hình thác nƣớc bao gồm hơn hơn 50 hạng mục, mọi ngƣời tự nhiên bắt đầu đặt câu hỏi có bao nhiêu hạng mục đƣợc mô tả trên bảng. Không có quy tắc chung; một vài nhóm tìm ra cách hƣu ích để hình dung đƣợc toàn bộ hàng đợi đầu

vào, trong khi những cái khác giữ danh sách trong một nơi riêng biệt/công cụ và dần dần kéo tầm 5 hạng mục quan trọng nhất vào bảng. Có thể mô tả chính sách này nhƣ một tảng băng trôi. Phần trên của tảng băng có thể nhìn thấy trên mặt nƣớc, ta có thể loại bỏ nó (kéo các mục vào hệ thống của chúng ta), băng ở dƣới nƣớc sẽ nổi lên tạo thành một phần mới. Giữ một giới hạn WIP rõ ràng trên hàng đợi đầu vào là một ý tƣởng tuyệt vời để giữ nó khỏi vƣợt ra khỏi tầm kiểm soát. Tôi luôn so sánh một danh sách công việc cần giải quyết là một tầng trên cùng không sử dụng của một ngôi nhà. Nếu đặt mọi thứ lên đó mà không muốn vứt bỏ, chúng ta có rất ít cơ hội để tìm thấy cái mà ta thực sự cần khi khi muốn dùng tới nó. Vì bậy giữ cho danh sách công việc cần giải quyết rõ ràng và chắc chắn nó phát triển trong tầm kiểm soát.

Hình 3.11 : Trực quan các chính sách ƣu tiên trên bảng

Một phần của tài liệu Nghiên cứu phương pháp Kanban và áp dụng phát triển phần mềm quản lý con dấu (Trang 39)

Tải bản đầy đủ (PDF)

(68 trang)