Đặc thù làm việc của nhóm Agile trong SAFe so với Scrum trên thực tế

Sau khi công bố với bạn bè bài viết đầu tiên về Burn Down Chart, trong phần bình luận, câu hỏi đầu tiên được đặt ra là: "Sẽ rất thú vị khi biết chi tiết hơn về kinh nghiệm của bạn với SAFe". Vì vậy, trong bài viết này, tôi sẽ cố gắng làm rõ đặc thù làm việc trong SAFe so với Scrum trên thực tế của chúng tôi. Tôi chắc chắn không tự nhận mình là chân lý sơ thẩm và sẽ vui mừng với mọi sửa chữa và làm rõ từ phía đồng nghiệp.

Đầu tiên, tôi sẽ liệt kê ngắn gọn những điều cơ bản nhất phân biệt làm việc trong SAFe với SCRUM, theo tôi.

• Increment trong Scrum và Program Increment trong SAFe
• ART - Agile Release Train
• Số lượng các nhóm tương tác
• PIPE
• SOS
• PO - không phải chủ sở hữu doanh nghiệp
• RTE
• Sprint thứ năm để đào tạo
• System Demo

Increment trong Scrum và Program Increment trong SAFe. Thực ra là các thuật ngữ khác nhau, nhưng rất dễ nhầm lẫn vì không ai trong chúng tôi sử dụng thuật ngữ Program Increment, mọi người chỉ nói Increment - mà đó lại là một thuật ngữ khác được sử dụng trong SCRUM. Nhưng nhìn chung chúng khá giống nhau về ý nghĩa, theo tôi. Increment trong SCRUM - về cơ bản là sản phẩm hiện tại + các câu chuyện đã lên kế hoạch cho sprint ở trạng thái hoàn thành (đã qua DOD của nhóm). Program Increment - là khoảng thời gian trong đó đoàn tàu (Agile Release Train) cung cấp giá trị tăng dần vào sản xuất. Về thời lượng, của chúng tôi là 4 sprint 2 tuần để phát triển và một sprint để đào tạo.

Agile Release Train - là một nhóm các nhóm làm việc trên một dòng tạo giá trị. Chúng tôi gọi đây là đơn giản là đoàn tàu, nhưng theo framework thì đúng ra nên gọi là "Solution". Trong trường hợp của chúng tôi, quy tắc này không hoàn toàn được tuân thủ và các nhóm thường làm việc trên các sản phẩm khác nhau từ góc độ kỹ thuật, vì phần lớn các tính năng kinh doanh được thực hiện một cách tổng hợp và ảnh hưởng đến nhiều sản phẩm. Đây là từ phía kỹ thuật. Nhưng, tôi chắc chắn rằng ai đó coi tất cả các hệ thống IT là một sản phẩm của công ty và, có thể, thậm chí điều đó còn đúng hơn.

Số lượng các nhóm tương tác trong SAFe của chúng tôi lớn hơn đáng kể, tổng cộng khuyến nghị lên đến 125 người trong một đoàn tàu. Chúng tôi có 3 đoàn tàu và không phải đoàn tàu nào cũng tuân thủ quy tắc này, có những đoàn tàu với số lượng hơn 125 người. SCRUM không mô tả cách tương tác với các nhóm khác, theo tôi biết, khác với SAFe, nơi có những khuyến nghị rất rõ ràng về vấn đề này. Theo tôi, artifact nổi bật nhất cho việc này là Program Board.

Trên đó hiển thị các mối quan hệ giữa các nhóm của đoàn tàu và, khi thảo luận về nó, các sự kiện hàng tuần Scrum Of Scrums (SOS) của chúng tôi diễn ra.

Khoảng mỗi 2,5 tháng (mỗi 5 sprint) diễn ra sự kiện PIPE - Programm Increment Planning Event. Đây là khi tất cả các nhóm phân tán tập trung tại một hội trường trong 2 ngày và lên kế hoạch công việc của họ cho 2,5 tháng tiếp theo. Trong quá trình sự kiện này, các artifact như Program board xuất hiện, ví dụ, trên đó hiển thị tất cả các phụ thuộc giữa các nhóm với nhau cho từng đoàn tàu, ở trên tôi đã chỉ ra nó trông như thế nào. Nhiệm vụ của Scrum Master của mỗi nhóm tại sự kiện này là điều phối việc phát hiện số lượng tối đa các phụ thuộc, sau đó nếu có thể, loại bỏ chúng (bằng cách truyền đạt năng lực bằng lời, ví dụ, từ nhóm sang nhóm hoặc bằng cách chuyển phụ thuộc từ nhóm này sang nhóm khác để nhóm có thể tự chủ thực hiện tính năng của mình mà không phụ thuộc vào ai). Trên thực tế, của chúng tôi diễn ra đúng như vậy. Đầu tiên, các tính năng được phân rã thành User Story, User Story được phân bổ cho 4 sprint. Các tính năng được đặt trên Program Board và các phụ thuộc từ các nhóm khác được đặt ra. Trong suốt sự kiện, điều này được thảo luận, điều chỉnh.

SOS - Scrum Of Scrum. Sự kiện này diễn ra mỗi tuần một lần cho từng đoàn tàu riêng biệt. Scrum Master của tất cả các nhóm của đoàn tàu tập trung trực tuyến, Program Board của đoàn tàu được truyền và thảo luận về trạng thái của tất cả các phụ thuộc và tính năng của các nhóm của đoàn tàu cụ thể. Về cơ bản, sự kiện này cần thiết cho việc đồng bộ hóa tập trung các nhóm trong đoàn tàu. Một cái gì đó giống như standup, nhưng mỗi tuần một lần và không phải cho nhóm, mà cho Scrum Master.

PO (Chủ sở hữu sản phẩm) - không phải chủ sở hữu doanh nghiệp. Có Product Manager - anh ấy làm việc với Business Owner của các lĩnh vực kinh doanh tương ứng và về cơ bản phân phát các tính năng cho Chủ sở hữu sản phẩm. Chủ sở hữu sản phẩm làm việc trực tiếp trong nhóm - chia các tính năng thành User Stories (trong trường hợp của chúng tôi là cùng với nhóm) và không phải lúc nào cũng chia, nhưng chúng tôi liên tục tiến bộ theo hướng này.

RTE (Release Train Engineer - người lái tàu. Scrum Master của các Scrum Master. Điều hành các sự kiện SOS của đoàn tàu mình. Tương tác với Product Manager ở cấp tính năng. Điều phối PIPE.

Sprint thứ năm dành cho học tập - đúng vậy, khác với Scrum, ở đây đội được dành trọn một sprint vào cuối increment để học tập. Trên thực tế, chúng tôi thường dùng nó trước hết để tham dự các khóa đào tạo nội bộ, trong đó có cả về SAFe, nhưng không chỉ vậy. Các khóa học riêng và meetup chúng tôi cố gắng lên kế hoạch vào thời gian này nếu có thể. Ngoài ra chúng tôi còn có các lập trình viên mở rộng bộ kỹ năng của mình trong suốt sprint thứ 5, để có thể bù đắp năng lực của ai đó trong đội (hỗ trợ khi cần thiết).

System Demo. Kết quả của PIPE là mỗi đội có một danh sách mục tiêu cho increment và mỗi mục tiêu trong số đó được Business Owner của đoàn tàu đánh giá theo thang điểm 10. Đây được gọi là Business Value. Các mục tiêu này được chia thành mục tiêu chính và mục tiêu mở rộng. Mục tiêu chính là những mục tiêu mà đội không thấy rủi ro nào trong việc đạt được. Mục tiêu mở rộng là những mục tiêu có rủi ro đạt được. Tất cả các mục tiêu đều bắt buộc và khối lượng công việc được lên kế hoạch cho tất cả các mục tiêu. Tại System Demo, Business Owner nghiệm thu kết quả công việc của increment. Giả sử một đội có 3 mục tiêu chính với điểm số 10, 6, 8 và 2 mục tiêu mở rộng với điểm số 10, 3. Hãy tưởng tượng Business Owner đưa ra các đánh giá tương ứng như sau: 8, 6, 4, 2, 0. Bây giờ có thể tính phần trăm đạt được mục tiêu: lấy 100% là tổng điểm ban đầu của các mục tiêu chính, trong trường hợp của chúng ta là 10+6+8=24. Điểm đạt được tính có xét đến các mục tiêu mở rộng (tức là đội đạt 20 trên 24), vậy kết quả là phần trăm đạt mục tiêu của đội sẽ là (20*100)/24 = 83,3%. Kết quả bình thường được coi là đạt từ 80% đến 100%.

Về mọi mặt còn lại, chúng tôi làm việc theo SCRUM. Hoặc gần như mọi mặt :) Về kinh nghiệm của chúng tôi: tôi có thể nói rằng, theo quan điểm của tôi, sự tiến hóa là rõ ràng. Sau một năm làm việc, các đội đã lớn mạnh đáng kể, trở nên tự tổ chức, một số đội, đúng là, đã tan rã, nhưng ngay cả trong đó cũng thấy được một sự tiến hóa nhất định. Vẫn còn chỗ để phát triển thêm.

Bình luận của đồng nghiệp từ facebook

«Zhenya, chào bạn! Thật tuyệt khi bạn viết, giỏi lắm! Tôi xin chỉnh lại một chút về các đoàn tàu - chúng không được tập hợp quanh sản phẩm, mà quanh dòng chảy tạo giá trị. Còn trong lĩnh vực bán lẻ của chúng tôi, theo quan điểm SAFe thì không phải đoàn tàu mà là Solution. Chỉ là để tiện giao tiếp và đơn giản hóa việc hiểu, chúng tôi vẫn tiếp tục gọi nó là đoàn tàu)»

– Konstantin Voronin (đại diện văn phòng dự án của Ingosstrakh)

«Và có thể ai đó sẽ để ý rằng theo quan điểm SAFe, việc đánh giá mục tiêu diễn ra tại I&A; (nơi SD tham gia như một phần, nhưng không liên quan trực tiếp đến việc đánh giá) còn bản thân các SD phải diễn ra mỗi sprint (sau demo của các đội). Nhưng chúng tôi còn xa điều đó, nên có ý thức gọi mọi thứ như được viết trong bài của bạn)»

– Konstantin Voronin (đại diện văn phòng dự án của Ingosstrakh)

«Zhenya, hãy tiếp tục nhé, rất hữu ích!»

– Alexey Ionov (Huấn luyện viên được chứng nhận về SAFe)