Làm cách nào tôi có thể theo dõi các thuộc tính chất lượng trên Kanban của nhóm?

Nhóm của tôi sử dụng hệ thống Kanban để theo dõi tiến trình hàng ngày và nó hoạt động rất tốt để hiểu tiến trình trên các tính năng (được ghi lại dưới dạng câu chuyện của người dùng). Chúng tôi phần lớn đã cho phép thiết kế hệ thống của chúng tôi xuất hiện khi chúng tôi phát triển các tính năng hoạt động tốt cho đến gần đây. Trong hai tuần qua, chúng tôi đã có một vài cuộc thảo luận về sự đánh đổi kiến ​​trúc liên quan cụ thể đến các thuộc tính chất lượng hiệu suất và có thể sửa đổi.

Tôi nghĩ những gì đang xảy ra là khi chúng tôi triển khai các tính năng và thiết kế hệ thống, chúng tôi hoàn toàn đưa ra quyết định về kiến ​​trúc nhưng không xem xét các quyết định đó theo các yêu cầu thuộc tính chất lượng đã biết. Sẽ thật tuyệt nếu tôi có thể theo dõi / chụp / mô tả trực quan cách các quyết định thiết kế quan trọng này được đưa ra để các thành viên trong nhóm có cơ hội tốt hơn để không tạo thêm căng thẳng với kiến ​​trúc của hệ thống khi nó được triển khai. Và tất nhiên, để làm phức tạp mọi thứ hơn, các tính năng trên bảng của chúng tôi không chỉ có chức năng và đôi khi che giấu sự phức tạp về kiến ​​trúc!

Làm cách nào tôi có thể theo dõi tiến trình về các thuộc tính chất lượng (hoặc các quyết định liên quan đến kiến ​​trúc khác) một cách trực quan trên kanban của nhóm tôi?

chúng tôi hoàn toàn đưa ra quyết định về kiến ​​trúc nhưng không xem xét các quyết định đó theo các yêu cầu thuộc tính chất lượng đã biết của chúng tôi.

Tôi nghĩ bạn có thể hình dung điều này bằng cách tạo một bước "đánh giá kiến ​​trúc" trong quy trình làm việc của bạn. Bước này sẽ được biểu thị bằng một cột bảng Kanbad với giới hạn WIP riêng. Giới hạn WIP sẽ phụ thuộc vào số lượng kiến ​​trúc sư / nhà thiết kế bạn phải tham gia vào các đánh giá này.

Nhóm phát triển chịu trách nhiệm cho các câu chuyện của người dùng theo chiều ngang, từ trái sang phải. Trong hầu hết các trường hợp, kiến ​​trúc sư sẽ chỉ chạm vào những câu chuyện khi chúng ở trong cột đánh giá kiến ​​trúc / kỹ thuật. Giao điểm của cột với một phao bơi nằm ngang trực quan hóa cuộc họp của nhà phát triển và kiến ​​trúc sư.

Một trong những nhóm nơi tôi làm việc có một bước tương tự trong đó họ thực hiện đánh giá lược đồ cơ sở dữ liệu với kiến ​​trúc sư dữ liệu trưởng. Họ không sử dụng Kanban, nhưng nếu có, họ rất có thể có cột này trên bảng của họ.

Các thuộc tính chất lượng đã biết sau đó có thể được biểu diễn dưới dạng:

• định nghĩa thực hiện cho bước xem xét kiến ​​trúc.
• kiểm tra chấp nhận xung quanh các câu chuyện người dùng đã thực hiện đại diện cho các yêu cầu phi chức năng. Sau đó, định nghĩa được thực hiện cho một câu chuyện người dùng mới sẽ bao gồm việc không phá vỡ các thử nghiệm đó.

THÊM : Bước công việc "xem xét kiến ​​trúc" có thể bị nghi ngờ đối với một vấn đề gọi là bi kịch của chung . Đây là một bài đăng blog tuyệt vời về cách trực quan hóa Kanban có thể giúp đối phó với nó và các giải pháp khả thi.

Có hai phần thực sự cho câu hỏi này. Một phần là: Làm thế nào để chúng ta biết khi nào kiến ​​trúc được thay đổi. Phần thứ hai là: Làm thế nào để chúng ta biết rằng kiến ​​trúc vẫn còn tốt.

Đối với phần đầu tiên này: Làm thế nào để bạn biết khi nào kiến ​​trúc được thay đổi?

Mục tiêu ở đây là lấy một cái gì đó đang được thực hiện hoàn toàn và làm cho nó rõ ràng

• Đề nghị của Alexei là một lựa chọn. Tạo một cột trên bảng để xem xét kiến ​​trúc. Sau đó di chuyển một thẻ ở đó nếu nó sẽ yêu cầu quyết định kiến ​​trúc
• Một tùy chọn khác là tạo một chính sách rõ ràng về cách xử lý việc này: "Nếu chúng ta cần thay đổi kiến ​​trúc thì chúng ta phải ghép với người khác" là một ví dụ về một chính sách như vậy. Trong một dự án, chúng tôi đã có chính sách thay đổi mã cho các mô-đun chuyên biệt nhất định phải được thực hiện bằng cách ghép nối với những người cụ thể. Khi ai đó muốn thay đổi mã ở đó, họ sẽ gọi một cặp và lập nhóm. Phần còn lại của công việc đã được thực hiện solo. Bạn có thể làm một cái gì đó tương tự với kiến ​​trúc.

Bạn có thể sẽ đi với người trước, nếu nhiều thẻ yêu cầu đánh giá hoặc nếu kiến ​​trúc sư không phải là thành viên của nhóm và cần phải bàn giao, hoặc đánh giá sẽ đủ chi tiết để bạn dành thời gian theo dõi bảng. Cái sau là một tùy chọn nếu chỉ có vài thẻ chạm vào kiến ​​trúc và dễ dàng tìm thấy một cặp theo yêu cầu.

Bây giờ đến câu hỏi thứ hai: Làm thế nào để chúng ta biết rằng kiến ​​trúc vẫn còn tốt?

Tôi là một fan hâm mộ lớn của hình dung. Bạn có thể có một biểu đồ trên bảng trắng với các ghi chú sau mô tả các thành phần và kiến ​​trúc.

Ngoài ra còn có các máy phân tích tĩnh sẽ phân tích cơ sở mã và tạo ra một hình ảnh với biểu đồ phụ thuộc của các thành phần khác nhau. Bạn có thể chạy nó, lấy một bản in ra và dán nó lên tường mỗi tuần một lần hoặc lâu hơn. Có lẽ hai bản in mới nhất có thể ở trên tường, vì vậy bạn có thể xem liệu có gì thay đổi trong tuần trước không.

Những gì chúng cho phép bạn làm là làm cho kiến ​​trúc và thiết kế của bạn hiển thị. Các thành viên trong nhóm sẽ thỉnh thoảng nhìn vào nó và nhận xét về nó nếu có thể thay đổi hoặc tái cấu trúc hoặc thực hiện theo cách tốt hơn.

Tôi đã thấy vấn đề này quá. Ra quyết định ngầm! Nếu nhân chứng là vấn đề, liệu làm cho nó rõ ràng nhất có thể giải quyết vấn đề? Những gì tôi đề nghị là điều chỉnh quy trình kiến ​​trúc một chút để 'bắt đầu khám phá' ra những suy nghĩ ngầm tiến triển để trở thành quyết định. Mục đích của bước bổ sung trong quy trình là làm cho các thành viên trong nhóm hiểu rằng mọi người đều có xu hướng đưa ra các quyết định kiến ​​trúc ngầm. Bước này sẽ chỉ giữ cho quyết định ngầm ra khỏi đường đua.

Giữ "Giải thích các quyết định ngầm" như một phần của kanban cho mỗi tình huống có thể giúp ích.

Những gì tôi sẽ đề nghị có thể là cồng kềnh. Nhưng nếu quy trình được ánh xạ tới một tập hợp các mục kanban và nếu điều này được đưa lên bảng cho từng kịch bản vòm, nó sẽ không giúp bạn theo dõi nó. Tôi đề nghị bạn cũng có thể ánh xạ chúng vào mẫu kịch bản sáu phần và ứng biến bảng kanban để phù hợp với các phát hiện, QAs có thể được theo dõi.

Vikram.

Đó là một trong những rủi ro của việc trì hoãn các quyết định kiến ​​trúc đối với các nhóm Agile. Rõ ràng điều có trách nhiệm nhất để nhanh nhẹn là trì hoãn các quyết định kiến ​​trúc cho đến giây phút chịu trách nhiệm cuối cùng . Nhưng cơ hội là khoảnh khắc có trách nhiệm cuối cùng có thể (hoặc phải) xảy ra sớm.

Một điều có ích là phân định rõ ràng sớm các yêu cầu lái xe chính của bạn; những thứ mà bạn biết rõ là bạn phải có (nhưng không nhất thiết phải thực hiện ngay bây giờ.) Kiến trúc phát triển của bạn (cố gắng tối giản và linh hoạt) sẽ đáp ứng hỗ trợ hiện tại hoặc tương lai cho các yêu cầu đó.

Tuy nhiên, quan trọng hơn, kiến ​​trúc đang phát triển của bạn KHÔNG PHẢI triển khai các tạo tác nhận được (hoặc có thể nhận) theo cách hỗ trợ các yêu cầu lái xe chính đó, ngay cả khi các tạo tác đó có nghĩa là để giải quyết các yêu cầu hiện tại. Chúng ta có thể gọi các vật phẩm như là tạo tác can thiệp , tạo tác mang lại giá trị thực (khi chúng thực hiện giải pháp cho các yêu cầu hiện có) nhưng sự hiện diện của nó gây khó khăn / tốn kém khi thực hiện yêu cầu lái xe chính trong tương lai.

Trong trường hợp khi bạn phải thực hiện một vật phẩm gây nhiễu, nhiệm vụ của bạn sẽ là lập kế hoạch loại bỏ nó tại một số điểm (để bạn có thể thực hiện yêu cầu lái xe chính đang bị can thiệp.)

Rõ ràng đây là tất cả bí truyền mà không có bối cảnh thực tế, hữu hình (như một dự án thực sự). Nhưng ít nhiều mô hình quá trình phát triển của bạn và kiến ​​trúc phát triển của bạn phải tính đến những cân nhắc này.

Các yêu cầu tiềm ẩn là điểm chết của kiến ​​trúc. Mọi thứ phải được làm rõ ràng, cả các yêu cầu lái xe chính và các yêu cầu phụ trợ. Bạn không cần phải thực hiện một yêu cầu sớm. Bạn chỉ cần có thể tính đến nó.

Tái bút Theo yêu cầu, tôi có nghĩa là các yêu cầu kiến ​​trúc cấp hệ thống và không nhất thiết là các yêu cầu cấp ứng dụng phù du có thể được cung cấp mà không có thay đổi đáng kể đối với kiến ​​trúc. Hy vọng nó giúp.