Trước khi bắt đầu, tôi cần đưa ra lời xin lỗi trước:
Rất có khả năng một số thuật ngữ / từ vựng tôi sử dụng trong bài viết này hoàn toàn sai cũng có một cơ hội tốt để tôi giải thích sai một số khía cạnh chính. Tôi chưa quen với điều này vì vậy đừng quá quan trọng, hơn cả những phản hồi mang tính xây dựng;)
Lý lịch
Chúng tôi hiện đang chuyển một bộ phận phát triển gồm 200 người từ đa phương pháp sang "Agile". Các whys, wherefores, ưu và nhược điểm của điều này là vượt quá phạm vi của câu hỏi này.
Bộ phận phát triển này chứa một nhóm Dịch vụ Kiến trúc gồm 10 người được chính thức gọi là "Kiến trúc sư giải pháp". Trong thực tế, họ không chỉ là giải pháp, đây là những người kỹ thuật bao quát mọi khía cạnh kiến trúc kỹ thuật của một dự án (ví dụ như phần cứng, phần mềm, bảo mật, quản trị, v.v.). Họ cũng cung cấp các chức năng đặc biệt cho nhóm phát triển (đánh giá mã, hướng dẫn tiêu chuẩn, v.v.) và kinh doanh rộng hơn (đầu vào kỹ thuật vào đấu thầu, xem trước kỹ thuật hợp đồng trước yêu cầu của khách hàng)
Là một phần của quá trình chuyển đổi này, tôi đã được giao nhiệm vụ tạo một bảng Kanban cho mục đích có được cái nhìn về các hoạt động công việc mà nhóm Dịch vụ Kiến trúc chịu trách nhiệm. Có vô số bảng ví dụ cho các nhóm phát triển / mã hóa, nhưng không có bảng nào tôi có thể tìm thấy cho Kiến trúc. Vì vậy, tôi đã lấy từ nhiều nguồn khác nhau và tạo ra "một cái gì đó", tôi thực sự sẽ đánh giá cao phản hồi chân thực về nó.
Cũng cần lưu ý rằng điều này sẽ được trình bày cho nhóm như một điểm khởi đầu / công việc đang tiến triển. Đó là hội đồng quản trị của họ và tôi muốn họ sở hữu nó, tất cả những gì tôi đang làm là thiết lập nền tảng cho các chàng trai xây dựng (và thay đổi nếu cần thiết)
Cho đến nay tôi có một cái gì đó như thế này
Ban chính
Bảng chính là nơi chúng tôi tổ chức tất cả các dự án đang hoạt động / tồn đọng - tất cả các công việc đang hoạt động sẽ nằm trên bảng này. Điều này sẽ được xem xét ngắn trong scrum kiến trúc hàng ngày với một đánh giá sâu hơn vào cuối mỗi tuần.
------------------------------------------------------------------------
| Evaluation | Implementation | Ad- Hoc |
| Todo | Doing | Done | Todo | Doing | Done | Todo | Doing | Done |
-------------------------------------------------------------------------------
Person | | | | | | | | | |
-------- ----------------- ---------------- -----------------
Person | | | | | | | | | |
-------- ----------------- ---------------- -----------------
Person | | | | | | | | | |
-------- ----------------- ---------------- -----------------
Person | | | | | | | | | |
-------------------------------------------------------------------------------
Các mô tả / mục đích cột là:
Đánh giá : Các dự án mà người đó đang thực hiện phân tích kỹ thuật ban đầu, tức là chạy qua các tùy chọn kỹ thuật với chủ sở hữu sản phẩm, xác định quy mô của dự án. Ví dụ, một dự án Đánh giá có thể là Kiến trúc sư đánh giá một công nghệ mới hoặc làm việc với khách hàng để tạo ra một giải pháp kỹ thuật được hai bên thống nhất.
Triển khai : Các dự án đang tích cực phát triển (mã hóa, thử nghiệm, v.v.) và người này đang thực hiện chức năng SA cho nhóm dự án rộng hơn. Ví dụ, đây có thể là sự phát triển các khía cạnh mã hóa của "giải pháp kỹ thuật được hai bên thống nhất" đã đề cập ở trên, đồng thời nó cũng có thể được giám sát về mặt kiến trúc khi thực hiện một số phần cứng mới.
Ad-Hoc : Tất cả những thứ kỳ lạ và tuyệt vời xuất hiện không thể đưa vào hai cột khác. Như một ví dụ trong một thế giới đệ quy kỳ lạ, có một thẻ cho tôi trong cột ad-hoc để tạo một bảng KanBan :).
Người : Khá tự giải thích, người "sở hữu" các thẻ trong hàng đó. Để làm cho mọi thứ vui hơn một chút, điều này thực sự chứa một hình đại diện của sự lựa chọn của người đó.
Todo : Có hiệu quả tồn đọng của chúng tôi, các thẻ ở đây được sắp xếp ưu tiên từ trên xuống dưới. Khi không gian trong một người làm tế bào trở nên có sẵn, chúng tôi lấy từ đầu công việc.
Làm : Khá tự giải thích
Xong : Các mục đã được hoàn thành kể từ lần đánh giá đầy đủ cuối cùng (chiều thứ sáu hàng tuần)
Giới hạn WIP
Thay vì làm những gì chúng ta làm bây giờ (nghĩa là đưa ra công việc cho đến khi ai đó ré lên), tôi muốn ban chính làm việc với các giới hạn WIP dựa trên mục tiêu / bằng chứng. Mục đích là để kích thước mỗi thẻ hội đồng với:
- XS (Thêm nhỏ): 3 điểm
- S (Nhỏ): 5 điểm
- M (Trung bình): 8 điểm
- L (Lớn): 13 điểm
- XL (Cực lớn): 21 điểm
Kích thước rất nhiều từ góc độ khối lượng công việc của Kiến trúc sư, ví dụ một dự án cần 1 năm mã hóa cho 10 người nhưng đầu vào Kiến trúc tối thiểu sẽ là XS hoặc S. Tuy nhiên, một dự án có đầu vào Kiến trúc lớn nhưng mã hóa tối thiểu có thể là XL.
Theo thời gian, chúng tôi sẽ có thể đưa ra giới hạn WIP cho mỗi người. Vì vậy, chúng ta biết rằng Jonny Smith có thể làm việc với vận tốc 42 điểm và do đó phân bổ các dự án lên đến mức đó.
Vì chúng tôi chưa thực hiện điều này trước khi tôi có ý định đặt giới hạn ban đầu lên cao, ý tưởng là khi một người ré lên, chúng tôi có thể (như một đội) nhìn vào điều này một cách khách quan và xác định xem nó có thực sự quá nhiều hay là do quá trình của chúng tôi vv là quá nặng nề và nên được sắp xếp hợp lý.
- LƯU Ý : Trong tất cả mọi thứ ở đây, các tính toán WIP này là bit "cảm thấy" ít đúng nhất *
Ban phễu
Để theo dõi tất cả những điều ngẫu nhiên bay qua đội, chúng tôi cũng có một bảng phễu. Đây là một bảng tương đối đơn giản trông như thế này:
------------------------------------------------------------------------
| Evaluation | Implementation | Ad- Hoc |
------------------------------------------------------------------------
| | | |
| | | |
| | | |
| | | |
| | | |
------------------------------------------------------------------------
Vì nhóm đã biết về một "dự án" nhưng điều này chưa được xử phạt chính thức (tức là có thể được đưa vào các cột Todo trên Bảng chính), sau đó nó đi lên bảng phễu. Các mặt hàng ở đây không được phân bổ cho một người. Ý tưởng là chúng ta có thể theo dõi những điều ngẫu nhiên đi qua và đảm bảo chúng không bị lãng quên. Ngoài ra, khi người đó hoàn thành một dự án đánh giá, điều này sau đó chuyển từ Đánh giá Ban chính được thực hiện sang bảng phễu triển khai (trừ khi ngay lập tức trở thành dự án triển khai)
Thỉnh thoảng, một thành viên của nhóm sẽ được giao nhiệm vụ theo dõi mọi thứ trên bảng phễu, tức là gọi điện thoại nhanh cho chủ sở hữu sản phẩm để hỏi liệu điều này có còn phù hợp không (đây sẽ là một dự án đặc biệt trên bảng chính)
Ban thành công
Đây chỉ là một bảng đơn giản để theo dõi những gì chúng tôi đã làm trong X tháng qua. Nó chứa các thẻ đã được thông qua Kênh và / hoặc Bảng chính
------------------------------------------------------------------------
| Successes |
------------------------------------------------------------------------
| |
| |
| |
| |
| |
------------------------------------------------------------------------
Ý tưởng là đôi khi chúng ta có thể đi vòng quanh bảng này và trao cho nhau những cái vỗ vai nhau :)
Thẻ hội đồng
Các thẻ trên bảng chứa thông tin sau:
------------------------------------------------------------------------
| SIZE (XS,S,M,L,XL) | OWNING TEAM MEMBER | RAG |
------------------------------------------------------------------------
| |
| PROJECT TITLE |
| |
------------------------------------------------------------------------
| | |
| DEPENDENTS | DEPENDENCIES |
| | |
------------------------------------------------------------------------
| |
| MISC INFORMATION |
| |
------------------------------------------------------------------------
| WIDER PROJECT TEAM (AS APPLICABLE) |
| Other Architects, Project Manager, Principal Developer, Business |
| Analyst, Scrum Master |
------------------------------------------------------------------------
Vì bạn sẽ nhận thấy mức độ chi tiết của thẻ ở mức "Dự án" khá cao, tôi không có kế hoạch thực hiện một bảng kiểu nhà phát triển được chia thành các nhiệm vụ (suy nghĩ về sự chào đón này). Cũng đáng đề cập rằng tùy thuộc vào nơi thẻ không phải là tất cả các phần sẽ được áp dụng. Tôi cũng đang lên kế hoạch mã hóa màu cho các thẻ, như một cú đâm đầu tiên tôi có:
Màu vàng: Bất kỳ thứ gì là hợp đồng của khách hàng Màu hồng: Bất kỳ thứ gì là nội bộ (tức là không phải người dùng cuối phải đối mặt) Màu xanh lá cây: Bất kỳ thứ gì là một dự án của nhóm công ty
Các thẻ sẽ có từ tính chứ không phải sau đó, tôi hy vọng tìm thấy một số giống như bảng trắng nhỏ vì điều này sẽ làm cho cuộc sống dễ dàng hơn khi mọi thứ thay đổi
Những thứ khác
- Nếu nó không có trên thẻ trên bảng thì theo như đội có liên quan thì nó không tồn tại
- Bản thân các bảng là Bảng trắng có Bánh xe, chúng tôi có thể mang chúng đi bất cứ nơi nào chúng tôi muốn
- Chúng tôi có thể xem xét việc chuyển sang bảng trắng ảo trong tương lai (bảng trắng vật lý dễ thay đổi hơn khi chúng tôi quyết định rằng cột X là tốt nhất ở bên trái của Y không phải bên phải)
Câu hỏi
- Sau khi đọc newbie Kanban War and Peace, suy nghĩ của bạn là gì? (làm ơn đi dễ dàng với tôi :))
