Trong bài viết trước của tôi, tôi đã bắt đầu thảo luận về những thói quen được giáo dục kém trong một nhóm scrum sẽ sớm dẫn đến thất bại trong việc giao hàng. Trong bài viết này, tôi muốn mở rộng lại chủ đề này và bây giờ tập trung vào các quy trình chức năng trong nhóm.
Họ cũng quan trọng như sự xuất sắc về mặt kỹ thuật của đội. Ngay cả khi những người bên trong có trình độ siêu cao cho công việc mà họ phải làm, vẫn có những lĩnh vực có thể phá hỏng nỗ lực đạt được sự hoàn hảo của họ. Và đó phần lớn không phải là lỗi của họ vì đó sẽ là trách nhiệm trực tiếp của họ đối với các quyết định quản lý dự án và khả năng phục vụ nhóm với các quy trình phù hợp với mục đích nhằm hỗ trợ nhóm có ý định rõ ràng và hành động có thể dự đoán được.
Nhóm có tính tách biệt cao với bộ kỹ năng riêng biệt
Hãy tưởng tượng nhóm có các nhà phát triển lành nghề, hoàn toàn độc lập và có thể giữ lời hứa cũng như cung cấp nội dung chạy nước rút đã thống nhất kịp thời trước khi kết thúc nước rút. Ngay cả trong kịch bản lý tưởng này (dù sao điều này khó xảy ra), nhóm sẽ phải vật lộn để theo kịp các chức năng tồn đọng (không ngừng phát triển) nếu các kỹ năng được phân bổ chặt chẽ giữa các thành viên trong nhóm.
Vài ví dụ
- Đội có 1 hoặc 2 Các kỹ sư DevOps có khả năng thực hiện các thay đổi tùy ý đối với quy trình tự động hoặc đảm nhiệm các dịch vụ bên trong nền tảng, nhưng những người còn lại trong nhóm không biết gì về những điều đó. Sau đó, việc thảo luận những câu chuyện này tại các buổi lễ scrum như sàng lọc sẽ khiến phần lớn nhóm lãng phí thời gian do chỉ tập trung vào cuộc họp mà không có sự tham gia nào, và ngược lại – nhà phát triển DevOps sẽ không quan tâm đến phần còn lại của tính năng định hướng những câu chuyện và thời gian gặp gỡ cũng sẽ bị lãng phí.
- Có một chuyên gia cơ sở dữ liệu cho toàn bộ nhóm. Tùy thuộc vào mức độ phức tạp và cách sử dụng các giải pháp dữ liệu trong hệ thống mà nhóm đang thực hiện, người này có thể liên tục bị quá tải với những câu chuyện không có cơ hội hoàn thành kịp thời, đặc biệt là đối với những ưu tiên của họ. Tệ hơn nữa, các story khác cũng sẽ phải chờ vì chúng phụ thuộc vào nguồn dữ liệu do các story cơ sở dữ liệu cung cấp.
- Khi một sản phẩm chủ yếu được định hướng phát triển phụ trợ, nhà phát triển giao diện người dùng duy nhất sẽ có mặt để đề phòng (vì đôi khi cần có một chút thay đổi ngay cả trong ứng dụng giao diện người dùng). Một lần nữa, hầu hết các buổi lễ scrum đều lãng phí thời gian đối với thành viên nhóm này vì kiến thức của anh ta chỉ giới hạn ở front-end và không có gì khác quan trọng.
nó kết thúc ở đâu
Trong mỗi trường hợp trên, kết quả là mọi người hoặc lãng phí thời gian hoặc không thể bắt kịp. Họ ngăn cản những người còn lại trong nhóm bắt đầu làm việc trên nhiều câu chuyện hơn hoặc họ làm giảm hiệu quả tổng thể của nhóm scrum một cách hiệu quả vì có quá nhiều thời gian chưa sử dụng trong sprint.
Tuy nhiên, nhóm vẫn có số lượng nhà phát triển này. Nhìn từ bên ngoài (thậm chí không muốn lộ ra) không có vẻ gì là những người trong nhóm không thể đảm nhận một số câu chuyện nhất định chỉ vì họ quá tập trung vào một bộ kỹ năng cụ thể. Vì vậy, họ không thể giúp đỡ các thành viên khác trong nhóm bằng các câu chuyện, ngay cả khi khả năng của họ cho phép và mức độ ưu tiên của các câu chuyện cũng sẽ ưu tiên điều đó.
Ngay cả chủ sở hữu sản phẩm cũng gặp khó khăn trong việc soạn nội dung chạy nước rút có ý nghĩa cho nhóm, bởi vì chủ sở hữu sản phẩm phải luôn xem xét có bao nhiêu người có thể làm việc trên mỗi câu chuyện và liệu có nhiều câu chuyện tương tự hơn được đưa vào nước rút cùng một lúc hay không, cuối cùng là Năng lực của nhóm đang tràn đầy, ngay cả khi thực tế có những người có thể thực hiện những câu chuyện này nhưng không có đủ kỹ năng để bắt đầu với chúng.
Giải quyết vấn đề nan giải
Đây là một vấn đề nan giải cần giải quyết và các nhà quản lý dự án nên biết nên đi theo con đường nào. Cụ thể là sự lựa chọn giữa:
- Có nhiều nhà phát triển toàn thời gian có khả năng làm việc trên nội dung rộng hơn nhưng không phải là chuyên gia về nhiều chủ đề. Vì vậy, họ có thể đi rộng nhưng không sâu. Sau đó việc giao hàng có thể được tiến hành nhanh chóng nhưng chất lượng có thể bị ảnh hưởng.
- Có chuyên gia tận tâm cho từng công nghệ nhưng sau đó chấp nhận những hạn chế và nỗ lực hơn nữa để tạo ra nội dung phù hợp hơn cho in ấn. Khi đó mọi người có thể đào sâu hơn và tạo ra những câu chuyện hay, nhưng họ sẽ phải tiếp cận một cách tuần tự, việc này sẽ mất nhiều thời gian hơn.
Chủ sở hữu sản phẩm kém
Theo định nghĩa, đây không hẳn là một “vấn đề về quy trình”, nhưng tôi chỉ xử lý nó theo cách đó vì việc xây dựng những câu chuyện mạnh mẽ có thể được hiểu là một quy trình mà nhóm mong muốn có được mạnh mẽ và tương thích với nhóm phát triển.
Ý tôi là yếu không nhất thiết liên quan đến thuộc tính kiến thức của một người, mà là khả năng của chủ sở hữu sản phẩm trong việc xử lý các câu chuyện của nhóm mà các nhà phát triển có thể hiểu và có ý nghĩa rõ ràng từ góc độ lộ trình sản phẩm. Cả hai yếu tố này đều rất quan trọng đối với một nhóm scrum thành công.
Nếu câu chuyện thiếu chi tiết để nhà phát triển có thể hiểu rõ mục đích, giá trị chức năng hoặc kỳ vọng về mặt kỹ thuật thì về cơ bản có hai tình huống có thể xảy ra:
- Các nhà phát triển sẽ xây dựng thứ gì đó khác với những gì chủ sở hữu sản phẩm thực sự mong muốn. Ngay cả trong thời gian chạy nước rút, rất khó để nắm bắt vì hầu hết chủ sở hữu sản phẩm không có khả năng theo dõi tiến trình của các câu chuyện ở mức độ chi tiết như vậy và thường thì PO sẽ chỉ mong đợi điều gì đó xảy ra (một cách kỳ diệu) .
- Các nhà phát triển sẽ dành quá nhiều thời gian để giải thích các câu chuyện và thảo luận nhiều lần thay vì bắt tay vào xây dựng chúng. Điều này liên quan đến rất nhiều cuộc gọi bổ sung, nhiều lần đối chiếu và trì hoãn công việc cho đến cuối giai đoạn chạy nước rút. Nó đạt đến điểm mà ước tính câu chuyện ban đầu không còn được coi là chính xác nữa và các câu chuyện không thể đóng được trong một lần chạy nước rút và chuyển sang các lần chạy nước rút tiếp theo. Trong trường hợp xấu nhất, tình huống này sẽ lặp lại ở những lần chạy nước rút tiếp theo.
Thời gian để tự suy ngẫm
Điều này thường khó thừa nhận, nhưng chủ sở hữu sản phẩm nên dành thời gian để suy ngẫm, xem xét các câu chuyện tồn đọng đã tạo và cuối cùng so sánh chúng với tầm nhìn của lộ trình sản phẩm, liệu có còn mối quan hệ có ý nghĩa nào giữa hai điều này – nếu có bất kỳ lộ trình nào cả. Nếu không, đây là điều đầu tiên cần giải quyết. Đôi khi giải pháp là thừa nhận rằng chủ sở hữu sản phẩm ở quá xa nhóm và quá xa mục tiêu của chính họ.
Trong trường hợp này, bộ phận sở hữu sản phẩm phải được giải quyết. Hơn nữa, đưa một nhà phân tích kinh doanh giỏi vào nhóm, người thiên về nội dung nhóm hơn là nội dung kinh doanh (chúng tôi đã có chủ sở hữu sản phẩm trong trường hợp này) có thể là một lựa chọn tốt, ngay cả khi phải trả giá bằng việc tăng tổng chi phí của nhóm.
Kiểm thử quy trình không có mốc thời gian cố định
Điều gì sẽ xảy ra nếu các hoạt động kiểm thử không liên quan chặt chẽ đến lịch trình cụ thể trong Scrum Sprint?
Thoạt nhìn, điều này có vẻ như là điều tốt cho một nhóm Agile/scrum. Tính linh hoạt luôn được chào đón và bề ngoài nghe có vẻ tốt.
Theo kinh nghiệm của tôi, sự tự do này dẫn đến nhiều hỗn loạn hơn là linh hoạt. Điều này không có nghĩa là giải pháp cho vấn đề này phải là tạo ra các “thác nước chạy nhanh” với các giai đoạn thử nghiệm chuyên dụng diễn ra ngay sau khi phát triển. Đây không phải là cách tiếp cận đúng đắn trong trường hợp này. Bạn có thể đọc thêm về điều này trong các bài đăng của tôi về chiến lược thử nghiệm scrum và vòng đời thử nghiệm linh hoạt.
Chúng tôi vẫn có thể cho phép sự linh hoạt nhất định và chọn lịch thử nghiệm có vẻ phù hợp nhất với nhóm phát triển hiện tại và dữ liệu thuộc tính sản phẩm mà nhóm cung cấp. Tuy nhiên, có hai mục tiêu chính cần đạt được khi lựa chọn này:
Nếu những điều kiện này được đáp ứng, nhóm sẽ tự nhiên thích ứng với quy trình đối sánh và tiến độ phân phối sẽ không bị ảnh hưởng bởi các hoạt động thử nghiệm kéo dài và đột xuất.
Sau cùng, điều quan trọng nhất là một bản phát hành chạy nước rút đáng tin cậy và có thể dự đoán được, điều này đưa tôi đến điểm cuối cùng của blog này.
Quá trình phát hành không xác định
Bây giờ đó là một điều hiển nhiên đối với bất kỳ nhóm scrum nào. Tuy nhiên, điều thú vị là nó cũng thường là một trong những quá trình bị đánh giá thấp nhất.
Nhóm scrum thường chỉ nói rằng việc phát hành sẽ diễn ra sau mỗi lần chạy nước rút, nhưng điều này không được hỗ trợ bởi một quy trình mạnh mẽ. Trên thực tế, có rất nhiều hành động hỗn loạn, khó lường sẽ xảy ra trong quá trình ra mắt. Đột nhiên, tất cả mọi người đều bận rộn với “nhiệm vụ phát hành” và không ai có thể tập trung phát triển thêm các câu chuyện chạy nước rút mới. Các chỉ số của Sprint bị vô hiệu hóa và việc phát hành trông giống như hoạt động ngẫu nhiên, không thể đoán trước từ góc độ của người thứ ba (thường là khách hàng).
Mọi người quá tập trung vào tồn đọng, nội dung chạy nước rút, phát triển, thử nghiệm và cuối cùng là hiển thị kết quả đến nỗi họ quên rằng một khi họ đã hoàn thành tất cả, lần chạy nước rút tiếp theo đã được tiến hành và họ đang lãng phí thời gian.
Bạn đang tìm kiếm một thời điểm tốt để phát hành
Vậy chính xác khi nào nhóm nên phát hành bản sản xuất thực tế? Điều quan trọng duy nhất cuối cùng là quan trọng.
Câu trả lời cho câu hỏi này đang được thực hiện, giả sử bạn có nó. Phụ thuộc:
- mức độ phức tạp của nội dung do nhóm tạo ra trong các lần chạy nước rút,
- thời gian chạy nước rút,
- số lượng thành phần bị ảnh hưởng trong hệ thống
- số người sử dụng và yêu cầu thay đổi,
một quy trình phát hành nhiều lần phải được thiết lập và tuân theo trong tương lai. Các quy tắc chính xác của quy trình lại có thể linh hoạt trong việc xác định. Nhưng cũng giống như việc kiểm tra, việc biến nó thành một thói quen lâu dài, có thể dự đoán và lên lịch cho những ngày cụ thể trong tương lai, khiến nó trở nên đáng tin cậy và có thể tham khảo.
Lựa chọn để lựa chọn
Các hình thức có thể có của quá trình như vậy có thể là bất kỳ hình thức nào sau đây hoặc các hình thức khác:
- Hoàn tất việc thử nghiệm các tính năng của lần chạy nước rút hiện tại trong lần chạy nước rút tiếp theo và xuất bản nội dung vào cuối lần chạy nước rút đó (sau khi quá trình thử nghiệm hoàn tất). Điều này có nghĩa là mỗi số sẽ không chứa bất kỳ nội dung nào từ sprint trước mà sẽ chứa các câu chuyện từ hai sprint trước.
- Lần chạy nước rút cuối cùng trước khi phát hành luôn dành riêng cho việc thử nghiệm nội dung từ hai lần chạy nước rút trước đó.
- Điều này không có nghĩa là quá trình phát triển trong quá trình “chạy nước rút thử nghiệm” sẽ dừng lại; nó chỉ nói rằng nội dung được phát triển trong lần chạy thử nghiệm này sẽ chưa được đưa vào bản phát hành tiếp theo.
- Nếu bạn đã có đủ hoạt động kiểm tra tự động tại chỗ, hãy thử chạy bản phát hành vào cuối mỗi lần chạy nước rút. Sau đó, đó phải là một quy trình rất nghiêm ngặt trong đó những người liên quan tập trung 100% vào vài ngày đó. Nó vẫn không ảnh hưởng đến phần còn lại của nhóm phát triển dưới bất kỳ hình thức nào.
- Bạn cũng có thể chọn phát hành mỗi tháng một lần hoặc N tháng một lần, chủ yếu là nếu điều đó đồng ý với người dùng cuối. Điều này sẽ làm tăng nỗ lực thử nghiệm cho mỗi lần chạy nước rút (vì nội dung sẽ lớn hơn cho mỗi lần phát hành). Nhưng mặt khác, điều đó sẽ có nghĩa là các hoạt động lặp đi lặp lại ít hơn theo thời gian, điều này trong trường hợp này có thể mang lại lợi ích cho nhóm. Do đó, nó có thể cho phép nhóm tạo ra nhiều tính năng mới hơn giữa các lần phát hành, mặc dù những tính năng đó thực sự sẽ được đưa vào sản xuất với nhịp độ chậm hơn.
Nhưng như đã đề cập nhiều lần trước đây, việc chọn quy trình nào trong số những quy trình này không quá quan trọng. Điều quan trọng hơn nhiều là nhóm sẽ tuân thủ quy trình tốt như thế nào và biến nó thành thói quen lâu dài.
Bạn cũng có thể đọc hướng dẫn này về quy trình và cách thực hành quản lý phiên bản.
