Khi bạn bắt đầu mở rộng quy mô Agile trong công ty của mình, ý nghĩ phải tập hợp nhiều nhóm Agile lại với nhau trong một phòng có thể khiến bạn nản lòng.
Hoặc có thể bạn đã lập kế hoạch PI được một thời gian nhưng nó hoạt động không tốt và cần cải thiện nhưng không biết cụ thể là ở đâu.
Chúng tôi đã tổng hợp Hướng dẫn căn bản về cách Lập kế hoạch PI vào năm 2022. Chúng tôi sẽ giúp phá bỏ những lầm tưởng và giải mã để triển khai các phiên Lập kế hoạch SAFe PI thành công và hiệu quả.
Trong hướng dẫn này, chúng tôi trả lời một loạt Câu hỏi thường gặp về Lập kế hoạch PI để bạn có thể cảm thấy đủ tự tin khi tham gia sự kiện này và sử dụng thuật ngữ có liên quan.
Hướng dẫn căn bản về lập kế hoạch PI này khá toàn diện, vì vậy bạn có thể tìm thấy một số phần phù hợp hơn với mình và muốn tìm hiểu về nó trước.
Chúng ta sẽ nói đến các nội dung sau:
PI Planning là viết tắt của Program Increment Planning.
Các phiên Lập kế hoạch PI là các sự kiện được lên lịch đều đặn được tổ chức trong suốt cả năm, nơi nhiều nhóm trong cùng một Agile Release Train (ART) gặp nhau để thống nhất tầm nhìn chung, thảo luận về các tính năng, lập kế hoạch lộ trình và xác định sự phụ thuộc giữa các nhóm.
Dưới đây là các yếu tố thiết yếu của Lập kế hoạch PI:
Nếu bạn áp dụng SAFe lần đầu, rất có thể bạn sẽ bắt đầu với Lập kế hoạch PI. Đó là bởi vì nó tạo thành nền tảng của SAFe.
Như Scaled Agile có câu, “nếu bạn không thực hiện Lập kế hoạch PI, tức là bạn không làm SAFe”.
Định nghĩa nhanh: SAFe hay Scaled Agile Framework™ là một chuỗi các nguyên tắc và thực hành được thiết kế nhằm giúp mang lại sự linh hoạt cho các tổ chức lớn hơn, ở tất cả các nhóm và các cấp của doanh nghiệp. Khung làm việc này hướng tới việc cải thiện khả năng hiển thị trực quan, sự đồng bộ và cộng tác, cũng như sẽ mang lại năng suất cao hơn, kết quả tốt hơn và chuyển giao nhanh hơn.
>> Xem thêm về lợi ích của Scaled Agile Framework tại đây !
Cho dù bạn đang áp dụng tất cả 5 cấp độ hay chỉ là SAFe thiết yếu, nền tảng và động lực cho sự chuyển đổi của bạn chính là buổi Lập kế hoạch PI.
Covid-19 đã thay đổi hoàn toàn cách chúng ta làm việc. Mặc dù Lập kế hoạch PI trực tiếp đã từng là tiêu chuẩn nhưng giờ đây chúng tôi hiểu rằng việc sắp xếp các nhóm để ngồi cùng một chỗ không phải lúc nào cũng khả thi.
Thay vì ở cùng một phòng, nguyên tắc bao trùm là đảm bảo rằng các nhóm đang tham gia vào công việc có thể ‘hiện diện’ trong phiên lập kế hoạch. Điều này có nghĩa là chúng tôi ưu tiên các nhóm có thể lập kế hoạch trong cùng một khoảng thời gian nếu không thể ngồi trực tiếp.
Tất nhiên, điều này có thể yêu cầu một số điều chỉnh về bộ khung của Lập kế hoạch PI; agenda trong hai ngày, thời gian và tất nhiên là công nghệ cần thiết để hỗ trợ sự kiện quan trọng này.
Nếu nhóm của bạn không thể thực hiện Lập kế hoạch PI trực tiếp hàng quý, bạn sẽ cần xem xét việc tổ chức một sự kiện Lập kế hoạch PI từ xa. Đừng lo lắng – điều này rất khả thi và lý tưởng cho các tổ chức với các nhóm phân tán hoặc sắp xếp công việc linh hoạt. Ngoài ra, nó rẻ hơn rất nhiều so với chi phí di chuyển để triển khai phiên Lập kế hoạch PI trực tiếp vài tháng một lần.
Nếu bạn có các công cụ và công nghệ phù hợp, bạn có thể triển khai phiên Lập kế hoạch PI và cho phép mọi người tham gia, cho dù họ ở trong cùng một phòng hay ở bên kia thế giới.
Dưới đây là một số mẹo giúp bạn triển khai phiên này hiệu quả:
Sắp xếp cùng địa điểm
Thay vì yêu cầu mọi người tham gia cuộc họp từ các địa điểm khác nhau, hãy sắp xếp các nhóm sao cho càng nhiều người có thể tập trung tại một địa điểm càng tốt. Bạn có thể thiết lập một trụ sở chính để tổ chức nhóm lãnh đạo và các nhóm lân cận, sau đó đưa mọi người phân bổ đến địa điểm gần nhất của họ. Bằng cách đó, mọi người vẫn có thể cộng tác trực tiếp.
Tận dụng điện toán đám mây
Sử dụng các công cụ lập kế hoạch chia sẻ trực tuyến để cho phép nhóm của bạn truy cập và tương tác với thông tin sớm nhất có thể – thậm chí có thể trong thời gian thực. Đảm bảo mọi người tham gia đều có khả năng hiển thị trực quan thông tin ngay lập tức giúp việc lập bản đồ các phần phụ thuộc chéo dễ dàng hơn và tránh lưu trữ thông tin ở hơn 10 vị trí khác nhau.
Phát trực tiếp sự kiện
Gặp mặt trực tiếp là lý tưởng nhất, nhưng khi không thể, điều tốt nhất bạn có thể làm là phát trực tiếp âm thanh và video từ sự kiện, cũng như từ những người tham gia. Điều đó có nghĩa là bạn sẽ cần khuyến khích tất cả các nhóm làm việc từ xa hoặc phân tán bật camera và mic trong suốt sự kiện. Nó không thể hoàn toàn giống như việc họ ở trong phòng với bạn, nhưng sẽ tạo ra cảm giác khá gần gũi.
Ghi lại sự kiện
Lý tưởng nhất là mọi người sẽ tham gia trực tiếp vào phiên lập Kế hoạch PI. Nhưng cho dù nhóm của bạn được phân bổ ở nhiều múi giờ khác nhau hay một vài thành viên trong nhóm không thể có mặt trong ngày do bị ốm hay lý do nào khác thì bạn cũng nên ghi lại sự kiện. Ngoài ra, việc có một bản ghi âm để tham khảo lại có thể hữu ích cho những người tham dự muốn xem lại bất kỳ điều gì đã được thảo luận.
Thích nghi
Một số nhóm sẽ thay đổi agenda của phiên Lập kế hoạch PI tiêu chuẩn để phù hợp với nhiều múi giờ, điều này có nghĩa là bắt đầu sự kiện sớm hơn hoặc muộn hơn đối với một số nhóm hoặc thậm chí kéo dài sự kiện trong 3 ngày thay vì 2 ngày.
Đề ra quy tắc
Một vấn đề phổ biến có thể phát sinh khi các nhóm phân tán họp từ xa qua video và audio là có quá nhiều tiếng ồn nhiễu. Trước khi phiên đầu tiên bắt đầu, hãy trao đổi về thời điểm có thể nói chuyện và khi nào các nhóm cần sử dụng nút tắt tiếng. Bằng cách đó, nhóm của bạn sẽ tránh bị phân tâm mà vẫn đảm bảo mọi người đều có thể tham gia.
Dù làm việc phân tán hay trực tiếp, nếu nhóm của bạn lập Kế hoạch PI đúng cách, điều đó sẽ khiến mọi thứ trong phần Tăng trưởng tiếp theo trở nên dễ dàng hơn rất nhiều.
Lập kế hoạch PI cực kỳ có lợi cho các tổ chức linh hoạt quy mô lớn.
Để hiểu rõ tác động, chúng ta hãy nhìn vào một vài con số. Ví dụ: một số tổ chức lớn hơn có thể có 200-300 nhóm và 10.000 Developer. Theo cách làm việc cũ, các nhóm này chưa bao giờ nói chuyện với nhau trước đó (cho đến khi có một vấn đề nghiêm trọng buộc họ phải nói chuyện).
Trước đây, sự đồng bộ sẽ diễn ra ở cấp độ nhóm lãnh đạo và họ sẽ có nhiều cấp quản lý ở giữa, những người truyền đạt thông tin xuống bên dưới, nhưng những thành viên trong nhóm sẽ không bao giờ nói chuyện với nhau. Sẽ luôn có một cuộc chiến về nguồn lực, ngân sách và cơ hội để thực hiện những dự án hấp dẫn nhất.
Nói về các dự án, những dự án này thường xảy ra xung đột – một nhóm sẽ đưa ra một thứ gì đó và sau đó nó sẽ phá vỡ một thứ gì đó trong dự án của nhóm khác.
Lập kế hoạch PI là lần đầu tiên nhiều công ty thực sự lớn này tập hợp các nhóm của họ trong một phòng hoặc trong một cuộc gọi để nói chuyện với nhau. Họ có cơ hội tạo ra những cuộc đối thoại quan trọng về việc ai đang làm việc gì.
Tại sao điều này có thể quan trọng?
Lập kế hoạch PI cho phép:
Kết quả là, các nhóm có thể hoàn thành công việc hiệu quả hơn, phát hành nhiều tính năng hơn trong thời gian ngắn hơn và duy trì ngân sách.
Tất cả những lý do rất chính đáng để thực hiện Lập kế hoạch PI. Nhưng chúng ta cũng hãy nhìn vào bức tranh lớn…
Lập kế hoạch PI là một phần thiết yếu của SAFe, một khung làm việc được thiết kế để mang lại sự linh hoạt cho các công ty lớn có nhiều nhóm.
Lập kế hoạch PI SAFe giúp các nhóm trong Agile Release Train (ART) đồng bộ, cộng tác và đồng bộ trong quy trình công việc, mục tiêu, phát hành,…
Mặt khác, nếu không có phiên Lập kế hoạch PI, các nhóm sẽ không có được giao tiếp có cấu trúc. Họ có thể không biết các nhóm khác đang làm gì, điều này có thể gây ra nhiều vấn đề. Ví dụ: hai nhóm có thể đang làm việc trên các tính năng khác nhau mà không nhận ra rằng có sự phụ thuộc có thể cản trở việc phát hành hoặc yêu cầu phải làm lại đáng kể phần code.
Vì vậy, mục tiêu của Lập kế hoạch PI là giúp tất cả các nhóm đồng bộ về mặt chiến lược và cho phép cộng tác giữa các nhóm để tránh những vấn đề tiềm ẩn này.
Bây giờ chúng ta đã giải quyết xong câu hỏi “tại sao”, hãy tìm hiểu sâu hơn một chút về “cái gì”. Cách tốt nhất để có được bức tranh toàn cảnh về những gì diễn ra trong quá trình Lập kế hoạch PI là xem qua một agenda.
Đây là mẫu agenda phiên Lập kế hoạch PI tiêu chuẩn do website SAFe đề xuất:
Ngày 1 | |
8h-9h sáng | Bối cảnh kinh doanh |
9h-10h30 sáng | Tầm nhìn sản phẩm/giải pháp |
10h30-11h30 sáng | Tầm nhìn kiến trúc & các thực hành phát triển |
11h30-1h chiều | Bối cảnh lập kế hoạch & ăn trưa |
1h-4h chiều | Chia nhóm |
4h-5h chiều | Rà soát bản nháp kế hoạch |
Ngày 2 | |
8h-9h sáng | Điều chỉnh kế hoạch |
9h-11h sáng | Chia nhóm |
11h-1h chiều | Rà soát kế hoạch cuối cùng & ăn trưa |
1h-2h chiều | Bối cảnh lập kế hoạch & ăn trưa |
2h-2h15 chiều | Bỏ phiếu tín nhiệm |
2h15-Xh chiều | Điều chỉnh kế hoạch (nếu cần) |
Khi sẵn sàng | Lập kế hoạch Cải tiến & tiến về phía trước |
Nguồn: http://scaledagileframework.com/pi-planning
Agenda này có thể hoàn hảo đối với bạn hoặc bạn cũng có thể điều chỉnh nó dựa trên nhu cầu của nhóm mình. Các nhóm phân tán, các ART rất lớn và các yếu tố khác có thể yêu cầu bạn phải sáng tạo với lịch trình. Bạn có thể thấy rằng một số phiên cần nhiều thời gian hơn, trong khi những phiên khác có thể được rút ngắn hoặc agenda của phiên Lập kế hoạch PI có thể cần kéo dài hơn 3-4 ngày để phù hợp với nhiều múi giờ. Nếu đây là sự kiện Lập kế hoạch PI đầu tiên của bạn, hãy thử agenda tiêu chuẩn, nhận phản hồi từ nhóm của bạn và thử nghiệm các hình thức khác nhau vào lần tới.
Bây giờ, hãy tìm hiểu cụ thể hơn một chút về các mục trong agenda – cụ thể là những gì xảy ra trong vài giờ đầu tiên của phiên Lập kế hoạch PI vào ngày đầu tiên.
Ngày 1 thường bắt đầu bằng bài thuyết trình của Giám đốc điều hành cấp cao hoặc Chủ doanh nghiệp. Trong agenda có một giờ để nói về thực trạng của doanh nghiệp. Họ sẽ nêu bật những nhu cầu cụ thể của khách hàng, cách các sản phẩm hiện tại giải quyết những nhu cầu này và những khoảng trống tiềm năng.
Sau đó, nhóm Quản lý sản phẩm sẽ chia sẻ tầm nhìn hiện tại của sản phẩm hoặc giải pháp của bạn. Họ sẽ nói về bất kỳ thay đổi nào đã diễn ra kể từ phiên Lập kế hoạch PI gần nhất (thường là khoảng 3 tháng trước đó). Và họ sẽ đề cập đến những gì sắp xảy ra, bao gồm các cột mốc quan trọng và 10 tính năng tiếp theo sắp ra mắt. Phiên này sẽ mất khoảng 1,5 giờ.
Phần đầu tiên của phiên Lập kế hoạch PI là về bức tranh toàn cảnh, đưa ra bối cảnh quan trọng cho việc lập kế hoạch cần thực hiện tiếp theo.
Việc bỏ phiếu tín nhiệm là một phần tưởng chừng nhỏ nhưng lại rất quan trọng của phiên Lập kế hoạch PI diễn ra cuối sự kiện.
Điều quan trọng là nhóm phải tự tin cam kết thực hiện công việc đã lên kế hoạch và đáp ứng các mục tiêu. Release Train Engineer sẽ yêu cầu các nhóm bỏ phiếu về vấn đề này.
Mọi người trong phòng cần biểu quyết bằng cách giơ tay (và các ngón tay).
Nếu số phiếu bầu trung bình trong phòng ít nhất là 3 ngón tay thì kế hoạch sẽ được tiến hành. Nếu ít hơn thì cần phải làm lại (cho đến khi đạt mức độ tin cậy cao). Ngoài ra, nếu bất kỳ ai bỏ phiếu chỉ bằng một hoặc hai ngón tay, họ sẽ có cơ hội chia sẻ lý do.
Việc bỏ phiếu tín nhiệm nhằm đảm bảo rằng những người tham dự đều đồng thuận và họ đồng ý rằng kế hoạch hiện tại là có thể thực hiện được trong khung thời gian nhất định. Nhắc đến thời gian, tiếp theo hãy nói thử xem Lập kế hoạch PI thực sự phù hợp với lịch công ty của bạn ở đâu và như thế nào.
Nhiều công ty nhận thấy rằng 8-12 tuần (tổng cộng lên tới 4-6 lần lặp 2 tuần) là khoảng thời gian thích hợp cho một phần Tăng trưởng.
Một số công ty tổ chức Lập kế hoạch PI hàng quý, ví dụ:
Tuy nhiên, thời gian và tần suất sẽ phụ thuộc vào độ dài của mỗi phần Tăng trưởng của chương trình theo kế hoạch và có thể bao gồm cả các ngày nghỉ lễ nếu cần.
Điểm hay của các sự kiện Lập kế hoạch PI là chúng diễn ra thường xuyên theo một lịch trình cố định, điều đó có nghĩa là bạn có thể lên kế hoạch từ trước. Điều đó có nghĩa là các nhóm và Chủ doanh nghiệp nhận được nhiều “thông báo” để đảm bảo họ có thể có mặt tại sự kiện.
Điều này có nghĩa là những gì diễn ra trong quá trình chuẩn bị cho phiên Lập kế hoạch PI cũng có thể quan trọng như chính sự kiện.
Một sự kiện lập kế hoạch trước – riêng biệt với Lập kế hoạch PI – được tổ chức để đảm bảo rằng ART đồng bộ với Solution Train rộng hơn trước khi họ thực hiện Lập kế hoạch PI. Tất cả là về việc đồng bộ với các ART khác để đảm bảo giải pháp và tổ chức cùng đi đúng hướng.
Bạn sẽ cần tổ chức một sự kiện trước Lập kế hoạch PI nếu bạn đang hoạt động ở cấp độ Large Solution, Portfolio hoặc Full SAFe. Essential SAFe cơ bản hơn và không có Solution Train, vì vậy nếu bạn đang hoạt động ở cấp độ này, bạn sẽ không cần Lập kế hoạch PI trước một cách chính thức.
Điều thường xảy ra là những người chủ chốt tập hợp lại từ Solution Train, cùng với các đại diện của ART và các nhà cung cấp liên quan. Dưới đây là một số “người quen” sẽ tìm thấy tại sự kiện lập kế hoạch:
Họ sẽ xem xét các khả năng hàng đầu từ Solution Backlog, Solution Intent, Vision và Solution Roadmap. Nó thực sự rất giống với Lập kế hoạch PI nhưng ở cấp độ cao hơn, xuyên suốt giải pháp tổng thể chứ không chỉ ART riêng lẻ.
Sự kiện bắt đầu bằng việc mỗi ART tóm tắt phần Tăng trưởng và thành tích của chương trình trước đó để thiết lập bối cảnh. Tiếp theo, giám đốc điều hành cấp cao sẽ thông báo ngắn gọn cho những người tham dự về thực trạng trước khi Quản lý Giải pháp thảo luận về tầm nhìn giải pháp hiện tại và mọi thay đổi so với những gì đã được chia sẻ trước đó. Những phần khác thường được thảo luận hoặc hoàn thiện bao gồm:
Trong phần tiếp theo, chúng ta sẽ xác định một số thuật ngữ chính đã được đề cập đến.
Như đã đề cập trước đó, SAFe là viết tắt của Scaled Agile Framework.
SAFe là khung làm việc hàng đầu thế giới về mở rộng quy mô Agile trên toàn doanh nghiệp. (Báo cáo Hiện trạng Agile)
Scrum và Kanban cũng là các khung làm việc Agile (mà bạn có thể cảm thấy quen thuộc hơn) và các khung làm việc này trước đây đã rất hiệu quả ở cấp độ nhóm cá nhân. Nhưng SAFe đang cố gắng lấp đầy khoảng trống ở cấp độ linh hoạt trên quy mô lớn, nơi nhiều nhóm cùng làm việc trên cùng một sản phẩm, mục tiêu và kết quả.
SAFe phác thảo những gì sẽ xảy ra ở mỗi cấp độ của tổ chức để đảm bảo rằng scaled Agile thành công. Nó vượt xa cấp độ nhóm nên bao gồm mọi bên liên quan.
Ý tưởng là nếu một công ty làm theo SAFe, điều đó sẽ mang lại sự đồng bộ tốt hơn giữa các nhóm và khả năng hiển thị trực quan công việc, điều này sẽ dẫn đến kết quả kinh doanh dễ dự đoán hơn.
Điều này ngày càng quan trọng khi môi trường của các tổ chức tiếp tục thay đổi và khách hàng kỳ vọng nhiều tính năng hơn sẽ được cung cấp trong thời gian nhanh hơn. Các phương pháp tiếp cận truyền thống kiểu Waterfall không còn hiệu quả bởi vì sự chậm chạp và thiếu hiệu quả.
Các công ty lớn hơn (thường có hàng nghìn Developer) không thể theo kịp sự đổi mới của các công ty khởi nghiệp nhỏ hơn, linh hoạt hơn. Cùng với các nhóm lớn hơn, các tổ chức lớn hơn thường có các yêu cầu chặt chẽ hơn về quản trị và sự tuân thủ, điều này có thể khiến việc phát triển nhanh chóng trở nên khó khăn hơn.
Có thể mất 3-4 năm để các công ty lớn hơn, phức tạp hơn này ra mắt một tính năng mới, điều này làm chậm quá trình chuyển giao đến khách hàng. Thêm vào đó, họ thường gặp khó khăn trong việc quản lý và tổ chức (nhiều!) nhóm Developer, điều đó cũng khiến họ không thể khởi động dự án đúng thời hạn.
Họ cần thực hiện thay đổi để đẩy nhanh tiến độ, tận dụng tối đa nguồn lực và giảm thiểu thất thoát ngân sách. Các công ty này đang tìm kiếm những cách mới để tổ chức mọi người vào các dự án và giới thiệu những cách làm việc hiệu quả hơn. Nếu không, họ sẽ không thể tồn tại được.
SAFe là một cách để các công ty này bắt đầu chuyển sang hướng linh hoạt hơn (nếu không sẽ tiếp tục mắc kẹt theo cách cũ).
Đây chính là nơi Lập kế hoạch PI xuất hiện.
Lập kế hoạch PI là một yếu tố quan trọng của SAFe. Đó là một sự kiện tập hợp đại diện đến từ mọi nhóm để giúp họ làm việc cùng nhau, quyết định các tính năng hàng đầu cần thực hiện tiếp theo, xác định các yếu tố phụ thuộc và lập kế hoạch cho Program Increment tiếp theo. Kết quả là tất cả các nhóm đều có tầm nhìn rõ ràng hơn, các thay đổi diễn ra thường xuyên hơn và các nhóm làm việc với nhau – chứ không phải chống lại nhau. Từ đó, những công ty lớn này có thể tăng tốc các quy trình, làm việc hiệu quả hơn, cạnh tranh với các công ty mới hơn, linh hoạt hơn và sống sót.
SAFe và Lập kế hoạch PI là những công cụ hỗ trợ mạnh mẽ cho sự linh hoạt của tổ chức.
Và mặc dù SAFe là một khung làm việc dành cho các tổ chức lớn hơn, nhưng cũng không có lý do gì khiến các công ty nhỏ hơn không thể thực hiện một phiên bản Lập kế hoạch PI. Tất cả những gì bạn cần là có nhiều hơn một nhóm Agile để làm cho nó có giá trị.
Bạn cũng có thể sử dụng Lập kế hoạch PI bên ngoài SAFe như một phần của phương pháp Scrum đơn giản.
Sơ đồ Mô hình Scrum cho thấy thời điểm và cách thức các nhóm Scrum có thể triển khai Lập kế hoạch PI
Scrum là một khung làm việc Agile giúp các nhóm hoàn thành công việc. Đó là cách để các nhóm lập kế hoạch và sắp xếp công việc của riêng họ cũng như giải quyết các User story và hạng mục công việc trong khoảng thời gian ngắn hơn. Điều này thường được gọi là Sprint.
Nếu nhiều nhóm Scrum muốn làm việc cùng nhau tốt hơn (nhưng không nhất thiết phải hoạt động theo SAFe), họ có thể áp dụng phiên bản của Lập kế hoạch PI.
Ví dụ: các nhóm Scrum này có thể:
Tin tốt ở đây là đối với việc Lập kế hoạch PI, không có cách tiếp cận nào có thể phù hợp cho tất cả, vì vậy hãy nghĩ về cách bạn có thể áp dụng các ý tưởng và nguyên tắc để mang lại hiệu quả cho tổ chức và bối cảnh của bạn.
Đầu vào quan trọng của Lập kế hoạch PI là Lộ trình và lộ trình này cũng được cập nhật dựa trên những gì đã học được trong sự kiện Lập kế hoạch PI. Một câu hỏi phổ biến mà chúng tôi nhận được là:
Có một số loại lộ trình khác nhau trong SAFe, vì vậy điều quan trọng là phải hiểu được sự khác biệt và ý nghĩa của từng lộ trình.
Lộ trình PI của bạn được tạo trước sự kiện Lập kế hoạch PI, đồng thời cũng được Quản lý sản phẩm xem xét và cập nhật sau khi sự kiện kết thúc. Nó thường sẽ bao gồm ba Program Increment:
Nếu bạn lập kế hoạch PI hàng quý, nó sẽ phác thảo khoảng 9 tháng làm việc. Phần Tăng trưởng thứ hai và thứ ba trong Lộ trình PI của bạn có thể sẽ thay đổi khi các ưu tiên thay đổi, nhưng chúng vẫn là một phần quan trọng của lộ trình khi chúng dự báo hướng đi tiếp theo của sản phẩm.
Vậy Lộ trình Giải pháp có nội dung gì?
Lộ trình giải pháp là công cụ lập kế hoạch và dự báo dài hạn cho một sản phẩm hoặc dịch vụ cụ thể.
Nó thường bao trùm một vài năm, với nhiều chi tiết cụ thể hơn có sẵn cho năm thứ nhất (như các tính năng và khả năng hàng quý) và nhiều thông tin tổng quát hơn (như mục tiêu) cho năm thứ hai trở đi.
Chương trình là nơi một tập hợp các nhóm Agile nhỏ hơn được nhóm lại với nhau để tạo thành một nhóm hoặc chương trình lớn hơn. Điều này thường được gọi là cấp độ “nhóm chồng nhóm” (team-of-teams).
Khi bạn nghe mọi người nói về tập hợp nhiều nhóm (team-of-teams) hoặc scaled Agile, thì ý là đưa Agile vượt ra ngoài một nhóm duy nhất và yêu cầu nhiều nhóm hơn tham gia.
Ví dụ, có thể có 4 nhóm làm việc phục vụ sứ mệnh đưa tàu vũ trụ của NASA tới Sao Hỏa.
NASA quyết định họ muốn xem liệu Agile có thể giúp các nhóm này làm việc tốt hơn hay không. Vì vậy, để bắt đầu, nhóm Oxy chuyển từ làm việc theo các phương pháp quản lý dự án Waterfall truyền thống sang áp dụng các nguyên tắc Agile.
Sau một vài tháng, NASA quyết định rằng cách thức hoạt động của nhóm Oxy đang diễn ra tốt đẹp, vì vậy ba nhóm còn lại cũng áp dụng các phương pháp linh hoạt hơn:
Mỗi nhóm trong số 4 nhóm này đều tự tổ chức, nghĩa là họ chịu trách nhiệm về công việc của mình.
Tuy nhiên, hiện tại các nhóm này đều đang làm việc theo cùng một cách, nên họ có thể được nhóm lại với nhau thành một chương trình.
Vì vậy, nói một cách đơn giản, chương trình là tập hợp các nhóm Agile. Và khi bạn thêm chủ doanh nghiệp, nhóm quản lý sản phẩm, kiến trúc sư/kỹ sư hệ thống và Release Train Engineer, bạn sẽ có tất cả các vai trò cần thiết để liên tục cung cấp hệ thống hoặc giải pháp thông qua Agile Release Train.
Bảng Chương trình là một phần quan trọng của SAFe và Lập kế hoạch PI và là đầu ra chính của Lập kế hoạch PI.
Thông thường, đây là một bảng vật lý được gắn trên tường, với các cột được vẽ lên để đánh dấu các vòng lặp của phần Tăng trưởng, với mỗi hàng cho một nhóm. Các nhóm thêm sticky note mô tả các tính năng mà họ sẽ làm.
Sau khi tất cả các tính năng được thêm vào, các nhóm sẽ cùng làm việc để xác định các phần phụ thuộc (các tính năng sẽ ảnh hưởng đến các tính năng khác) và đánh dấu bằng cách nối chúng với sợi dây màu đỏ.
Tuy nhiên, bảng chương trình SAFe không nhất thiết phải là bảng vật lý. Có rất nhiều lợi ích khi sử dụng bảng chương trình số như Easy Agile Programs, tích hợp trực tiếp với Jira. Chúng tôi sẽ nói nhiều hơn về cách bạn có thể sử dụng Jira cho Lập kế hoạch PI ở cuối hướng dẫn này. Nhưng bây giờ, hãy đi tiếp và nói về những vai trò liên quan đến Lập kế hoạch PI.
Có 5 vai trò chính trong sự kiện Lập kế hoạch PI:
Chúng ta hãy xem xét kỹ hơn mỗi vai trò này chịu trách nhiệm gì trong sự kiện.
Release Train Engineer là người lãnh đạo phục vụ và huấn luyện viên cho ART. Vai trò của họ chủ yếu tập trung vào việc lập kế hoạch và điều phối sự kiện Lập kế hoạch PI. Điều này có nghĩa là họ giúp:
Với tư cách là người điều phối sự kiện kéo dài 2 ngày, Release Train Engineer trình bày quy trình lập kế hoạch và kết quả mong đợi cho sự kiện, đồng thời điều phối phiên Đánh giá Quản lý, Giải quyết vấn đề và Cải tiến.
Công việc của Product Manager là thấu hiểu nhu cầu của khách hàng và xác thực các giải pháp, đồng thời hiểu rõ và hỗ trợ công việc liên quan đến danh mục đầu tư.
Vậy vai trò của Product Manager trong Lập kế hoạch PI là gì?
Họ trình bày tầm nhìn của Chương trình (hay còn gọi là 10 Tính năng hàng đầu sắp ra mắt) cùng với bất kỳ Cột mốc quan trọng sắp tới. Họ xem xét bản kế hoạch Nháp và mô tả mọi thay đổi đối với kế hoạch và phạm vi dựa trên phiên Đánh giá Quản lý & Giải quyết vấn đề. Bằng cách đó, họ có thể quản lý và xác định độ ưu tiên luồng công việc. Sau khi sự kiện Lập kế hoạch PI kết thúc, họ sử dụng Mục tiêu chương trình từ Release Train Engineer để cập nhật Lộ trình.
Điều đáng nói là Product Manager cũng tham gia vào việc Lập kế hoạch PI trước và sau.
Trước khi phiên Lập kế hoạch PI diễn ra, một cuộc họp Lập kế hoạch PI trước sẽ được tổ chức, trong đó Product Manager và các đại diện ART khác thuộc cùng một Solution Train thảo luận và xác định đầu vào, mục tiêu và các mốc quan trọng cho các sự kiện Lập kế hoạch PI tiếp theo.
Lập kế hoạch PI sau bao gồm việc tập hợp các đại diện ART để thảo luận về các sự kiện Lập kế hoạch PI đã diễn ra như thế nào và tóm tắt mọi phát hiện về Mục tiêu Giải pháp PI. Product Manager đóng một vai trò quan trọng trong việc truyền đạt các phát hiện và tạo ra các mục tiêu.
Product Owner chịu trách nhiệm duy trì và sắp xếp mức độ ưu tiên của Backlog nhóm cũng như Lập kế hoạch Iteration. Họ có quyền ra quyết định ở cấp độ User story trong các phiên tách nhóm trong Lập kế hoạch PI.
Product Owner giúp Nhóm xác định các story, ước tính và sắp xếp trình tự, cũng như soạn thảo các Mục tiêu PI của Nhóm và tham gia Cuộc bỏ phiếu tín nhiệm của Nhóm. Họ cũng chịu trách nhiệm truyền đạt tầm nhìn và mục tiêu từ quản lý cấp cao đến nhóm, cũng như:
Scrum Master là người lãnh đạo phục vụ cho nhóm Phát triển và Product Owner, nghĩa là họ quản lý và lãnh đạo các quy trình, đồng thời giúp nhóm hoàn thành công việc theo những cách thực tế.
Họ điều phối việc chuẩn bị cho các sự kiện (bao gồm cả Lập kế hoạch PI) và chuẩn bị Bản demo hệ thống. Họ giúp nhóm ước tính khả năng cho các Vòng lặp, hoàn thiện Mục tiêu PI của nhóm và quản lý khung thời gian, sự phụ thuộc cũng như những điểm không rõ ràng trong các phiên Tách nhóm. Scrum Master cũng tham gia vào Cuộc bỏ phiếu tín nhiệm để giúp nhóm đạt được sự đồng thuận.
Developer chịu trách nhiệm nghiên cứu, thiết kế, triển khai, thử nghiệm, bảo trì và quản lý hệ thống phần mềm.
Trong quá trình Lập kế hoạch PI, họ tham gia vào các phiên Tách nhóm để tạo và tinh chỉnh các User story cũng như tiêu chí chấp nhận (cùng với Product Owner) và điều chỉnh kế hoạch làm việc. Developer giúp xác định rủi ro và sự phụ thuộc, đồng thời hỗ trợ nhóm soạn thảo và hoàn thiện Mục tiêu PI của Nhóm trước khi tham gia Cuộc bỏ phiếu tín nhiệm Nhóm.
Tại thời điểm này, bạn đã có tất cả các định nghĩa chính, bạn biết điều gì cần diễn ra trong sự kiện Lập kế hoạch PI và ai cần tham gia.
“Không chuẩn bị nghĩa là bạn đang chuẩn bị cho thất bại.” – Benjamin Franklin
Nếu bạn muốn thành công tại phiên Lập kế hoạch PI, hãy đảm bảo rằng bạn không bỏ qua giai đoạn chuẩn bị.
Mọi sự kiện Lập kế hoạch PI đều dựa vào sự chuẩn bị kỹ lưỡng để tổ chức và những người tham dự tận dụng tối đa sự kiện và đạt được mục tiêu của mình.
Những gì liên quan đến việc lập kế hoạch?
Bản thân những người tham gia (cộng với các bên liên quan chính và Chủ doanh nghiệp) phải sẵn sàng bằng cách giao bất kỳ vai trò chính nào, đảm bảo có sự đồng bộ trong chiến lược và mọi người đều hiểu rõ quy trình lập kế hoạch.
Bất kỳ người thuyết trình nào cũng sẽ cần chuẩn bị sẵn nội dung cho bài thuyết trình của mình.
Ngoài ra, bạn cần đảm bảo cơ sở vật chất đã sẵn sàng – đặc biệt khi bạn có thể có hàng trăm người tham dự. Điều này liên quan đến tất cả công việc chuẩn bị sự kiện thông thường, nhưng tập trung đặc biệt vào công nghệ (bao gồm kết nối âm thanh, video và Internet), để đảm bảo mọi nhóm phân tán đều có thể tham gia vào sự kiện Lập kế hoạch PI. Đừng quên lập kế hoạch để đảm bảo mọi người đều có đầy đủ đồ ăn và thức uống (lập kế hoạch là công việc tiêu tốn rất nhiều năng lượng đó).
Vì vậy, tại thời điểm này, chúng ta có một bức tranh rõ ràng về những gì xảy ra trước và trong một sự kiện Lập kế hoạch PI, nhưng sau đó thì sao?
Sau khi lập kế hoạch PI, các nhóm thực hiện một phiên Cải tiến kế hoạch và liệt kê ra:
Và sau đó sẽ có cuộc trò chuyện về các bước tiếp theo. Các bước này có thể bao gồm những thứ như:
Một điều khác thường xảy ra sau các sự kiện Lập kế hoạch PI là sự kiện sau Lập kế hoạch PI.
Những sự kiện này tương tự như các sự kiện trước Lập kế hoạch PI mà chúng ta đã nói đến. Chúng liên quan đến việc tập hợp các bên liên quan của ART trên tất cả các Solution Train để đảm bảo sự đồng bộ.
Lập kế hoạch PI sau diễn ra sau khi tất cả các ART đã hoàn thành Lập kế hoạch PI cho đợt tiếp theo. Họ trình bày kế hoạch, giải thích mục tiêu và chia sẻ các cột mốc quan trọng cũng như dòng thời gian dự kiến.
Giống như các sự kiện Lập kế hoạch PI, Lập kế hoạch PI sau liên quan đến việc sử dụng bảng lập kế hoạch, nhưng thay vì các tính năng, nó phác thảo các khả năng, sự phụ thuộc và các cột mốc quan trọng cho mỗi vòng lặp và ART. Các vấn đề và rủi ro tiềm ẩn được xác định, thảo luận và xử lý, giải quyết, chấp nhận hoặc giảm thiểu. Và tương tự như các sự kiện Lập kế hoạch PI thông thường, các kế hoạch sẽ trải qua cuộc bỏ phiếu đầu tiên trong số năm cuộc bỏ phiếu tín nhiệm để đảm bảo chúng đáp ứng các mục tiêu của giải pháp và việc này lặp lại cho đến khi số người tham dự đạt biểu quyết trung bình nhiều hơn 3 ngón tay.
Lập kế hoạch PI không phải lúc nào cũng suôn sẻ, đặc biệt là lần đầu tiên. Và bản thân khung làm việc này có thể là một thách thức đối với một số tổ chức. Dưới đây là một số sai lầm và thách thức phổ biến cần ghi nhớ (và tránh, nếu có thể):
Một trong những nhược điểm chính của Lập kế hoạch PI là agenda được đề xuất bao gồm một số phiên họp dài và nặng nề ngay từ đầu. Có thể bạn nên xem xét các cách sáng tạo để làm cho những phiên này trở nên hấp dẫn hơn, cung cấp thông tin về bối cảnh kinh doanh theo một dạng khác hoặc điều chỉnh thời gian ngắn hơn. Bằng cách đó, sẽ có nhiều thời gian hơn cho việc lập kế hoạch và cộng tác nhóm.
Bất kỳ sự kiện nào cũng dễ gặp rủi ro về mặt công nghệ, nhưng nếu bạn đang truyền âm thanh và video cho một nhóm phân tán thì điều này thực sự có thể ảnh hưởng đến diễn biến của sự kiện. Bạn nên kiểm tra cẩn thận tất cả các thiết bị và kết nối trước để giảm thiểu các sự cố tiềm ẩn.
Một số người tham gia phiên Lập kế hoạch PI đã phải vật lộn với việc bỏ phiếu tín nhiệm trong quá khứ. Mọi người có thể cảm thấy áp lực khi có cơ hội bỏ phiếu cho một kế hoạch để được tiến hành tiếp, thay vì được lên tiếng về mối lo lắng của mình.
Khi bạn có một ART lớn gồm 12 nhóm, thì sẽ có rất nhiều kế hoạch nháp cần trình bày và xem xét. Rất có thể khi này phản hồi sẽ có chất lượng kém hơn so với ART nhỏ hơn với 8 đội.
SAFe không hoàn hảo và Lập kế hoạch PI cũng vậy. Nhưng quá trình này đã được chứng minh là có hiệu quả đối với nhiều tổ chức. Điều quan trọng là phải tuân theo mô hình và triển khai sự kiện Lập kế hoạch PI theo các đề xuất. Sau đó cam kết làm theo quy trình đó.
Nếu có điều gì đó không hiệu quả, hãy sửa nó. Ví dụ: có quá nhiều nhóm bám vào Bảng Chương trình SAFe truyền thống mặc dù chúng không phải lúc nào cũng thực tế. Nếu bạn thấy các ghi chú bị thất lạc, dữ liệu được nhập vào Jira có vẻ hơi sai lệch hoặc bạn có một nhóm phân tán muốn phương pháp số trở thành một phần của sự kiện Lập kế hoạch PI… thì đã đến lúc nâng cấp lên bảng chương trình số như Easy Agile Programs. Nhắc về phần mềm, (cuối cùng) đã đến lúc nói về Jira!
Jira là công cụ quản lý dự án phổ biến nhất dành cho các nhóm Agile, vì vậy nếu bạn là người thực hành Agile, rất có thể bạn đã sử dụng nó ở cấp độ nhóm.
Jira rất phù hợp cho các đội nhóm đơn lẻ.
Nhưng khi bạn cần triển khai Agile ở cấp độ mở rộng như một phần của ART, có thể sẽ khó hình dung chính xác công việc đang diễn ra ở nhiều nhóm. Cách duy nhất bạn có thể làm điều đó trong ứng dụng gốc của Jira là tạo một bảng gồm nhiều dự án, điều này khá rắc rối.
Vậy, Jira phù hợp với SAFe và Lập kế hoạch PI như thế nào?
Lập kế hoạch PI tập hợp các nhóm đó để lên kế hoạch công việc cho phần Tăng trưởng tiếp theo dựa trên các mục tiêu chung. Trong quá trình Lập kế hoạch PI, các nhóm sử dụng Bảng Chương trình để lập kế hoạch công việc và sắp xếp các phần phụ thuộc. Thông thường, việc này được thực hiện bằng cách sử dụng một bảng vật lý với sticky note và dây. Sau khi phiên họp kết thúc, các ghi chú và dây được tạo lại trong Jira cho cả nhóm. Việc này có thể rườm rà, tốn thời gian và thường bỏ sót trong nhiều bối cảnh.
Cách tốt nhất để sử dụng Jira cho Lập kế hoạch PI là sử dụng một ứng dụng như Easy Agile Programs để giúp bạn điều hành các phiên Lập kế hoạch PI. Các tính năng tích hợp có nghĩa là bạn có thể:
Nguồn: https://www.easyagile.com/blog/the-ultimate-guide-to-pi-planning-2023-safe-edition/
Bài viết liên quan:
Khóa học liên quan:
Bạn đã đăng ký thành công
Xin cảm ơn bạn đã đăng ký nhận tư vấn
Xin cảm ơn bạn đã đăng ký
Mời bạn kiểm tra Email để tải tài liệu.