2009-05-29 34 views
8

Có ai đang sử dụng Kanban (hoặc scrumban) để thực hành quản lý nhanh không? Kinh nghiệm của bạn với Kanban là gì? Làm thế nào nó hoạt động trong môi trường phức tạp lớn với sự phụ thuộc vào các dự án thác nước?Có ai đang sử dụng Kanban không?

Trả lời

9

Tôi biết BBC sử dụng nó khá rộng rãi. Xem blog của David Joyce để biết thêm chi tiết http://leanandkanban.wordpress.com/

Anh ấy có một bản chiếu khá nặng để rây qua.

Tôi nghĩ điều cần nhớ về suy nghĩ Lean là bạn phải xem xét luồng giá trị nói chung. Trong khi bạn có thể siêu tối ưu hóa nhóm phát triển bằng cách sử dụng các kỹ thuật như Kanban, điều quan trọng hơn là kết hợp cả hai luồng (Quản lý/Phân tích) và hạ lưu (QA/triển khai/hỗ trợ) để thu được toàn bộ phần thưởng.

Do đó, để hỏi cách điều này phù hợp với Thác nước hoặc quá trình phức tạp (ngoài hiệu ứng cá nhân của bạn), không phải là câu hỏi đúng. Câu hỏi quan trọng hơn là hỏi làm thế nào tôi có thể bắt đầu thực hiện toàn bộ luồng giá trị. Tôi biết điều này nghe có vẻ giống như sự khởi đầu của sự nhiệt tình của Lean tôn giáo, nhưng đó là cách bạn sẽ nhận ra giá trị thực sự của một quá trình nạc.

Ví dụ, hãy xem xét các tình huống sau cho một dự án tiêu biểu:

  • Phân tích thời gian: 18 tháng
  • Dev thời gian: 9 tháng
  • QA & thời gian phát hành: 4 tháng
  • chấp nhận khách hàng và làm lại: 12 tháng

Tổng cộng: 43 tháng

Nếu áp dụng Lean vào quy trình phát triển, bạn cải thiện 100%, tức là thời gian phát triển là 4,5 tháng, mang lại tổng cộng 38,5 tháng mới. Sau đó, bạn chỉ tăng tổng giá trị luồng lên hơn 10% ... không đáng kể !!

Bạn cần phải bắt đầu chiến đấu và đưa Lean nghĩ đến quản lý cấp trên và chứng minh nơi thành công thực sự nằm ... đó là trong thiết kế lại toàn bộ quá trình.

Hãy nhớ rằng Lean KHÔNG phải là quá trình phát triển, nó có thể được áp dụng cho mọi khía cạnh của doanh nghiệp.

Một số sách thú vị về cách thực hiện cuộc thảo luận này ngoài nhóm phát triển bao gồm;

+0

kể từ đó cuốn sách Kanban David Anderson đã được công bố, quá – Ingvald

5

Thứ nhất, điều quan trọng là nhận ra những vấn đề mà Kanban trong phát triển phần mềm cố gắng giải quyết:

  • Multi-tasking/quá tải công việc. Kanban giải quyết các vấn đề này theo hệ thống Chỉ trong thời gian và Hàng đợi. Có là đủ trong hàng đợi để giữ mọi người bận rộn, nhưng không quá tải (điều này đi kèm với thực hành với ước tính và vận tốc hiệu quả giám sát). Và JIT đảm bảo rằng mọi người không phải thực hiện nhiều tác vụ và do đó làm giảm năng suất.
  • Phiên bản hạ lưu không thể đoán trước. Nếu bạn làm việc trong một tổ chức phần mềm lớn, mảnh mà bạn đang phát triển có thể chỉ là một phần trong phần lớn phần mềm juxtaposition. Do đó, có thể có các nhóm hạ lưu có thể chờ đợi tính năng của bạn. Hệ thống xếp hàng của Kanban cùng với lịch trình phân phối theo thời gian của nó đảm bảo rằng có một số lượng dự đoán nhất định trong bản phát hành.

Chủ yếu, các thực tiễn nhanh nhẹn khác cũng cố gắng giải quyết các vấn đề tương tự với các kỹ thuật khác nhau.

môi trường phức tạp lớn với phụ thuộc vào dự án thác

này làm cho nó khó khăn nếu bạn có một sự phụ thuộc vào một dự án không tuân theo nhanh nhẹn như sau đó hàng đợi đầu vào của bạn sẽ không thể dự đoán được. Nếu một dự án không nhanh nhẹn phụ thuộc vào bạn, vấn đề có thể ít hơn - nhưng bạn có thể kết thúc sản xuất nhiều hơn có thể được tiêu thụ ('muda' trong thuật ngữ nạc). Vì vậy, lý tưởng bạn sẽ muốn tất cả các dự án phụ thuộc ít nhất là tuân theo một số thực hành nhanh nhẹn, nếu không kanban chính nó.

Bài viết hay về Kanban, Flow và Cadence có thể được tìm thấy here.

2

Có ai đang sử dụng Kanban (hoặc scrumban) để thực hành quản lý nhanh không?

Vâng, tôi đang sử dụng :-)

Làm thế nào nó hoạt động trong môi trường phức tạp lớn với phụ thuộc vào dự án thác nước?

Trong môi trường của chúng tôi, chúng tôi có> 500 nhà phát triển, vì vậy nó khá lớn. Nhóm của tôi là người đầu tiên, sử dụng Kanban, chủ yếu cho công việc bảo trì, và bây giờ để phát triển. Công việc hàng ngày của chúng tôi rất khó khăn, bởi vì các nhóm phụ thuộc khác đang theo dõi kỹ thuật quản lý và phát triển cổ điển và họ thích (họ vẫn làm) để đẩy công việc và Kanban là khoảng kéo.

Cách tiếp cận của chúng tôi là giao tiếp càng nhiều càng tốt làm cho công việc của chúng tôi minh bạch, nhưng do sự miễn cưỡng của môi trường, chúng tôi đã tập trung vào công việc nội bộ của mình. Giới hạn WIP đã giúp chúng tôi tập trung, và với công việc trực quan hóa, chúng tôi biết ai đang làm gì vào lúc này.

Thông lượng của chúng tôi trước Kanban là 90% (nói cách khác, khi 10 mục được đưa vào, chúng tôi chỉ phân phối 9) và sau Kanban chúng tôi có 100,4% và tăng lên. Như một kết quả bổ sung, các đội khác bắt đầu đến và hỏi về Kanban, bởi vì họ thích kết quả của chúng tôi, và muốn thực hiện hệ thống Kanban của riêng họ. Tại thời điểm này tôi biết về 5 đội, bắt đầu Kanban trong tổ chức của chúng tôi.

HTH,

Zsolt

Các vấn đề liên quan