Home cách thức Agile Hiểu cố kỉnh nào mang lại đúng về Cross-Functional vào nhóm làm việc theo tiến trình Scrum
*

Nhóm Scrum có hai sệt điểm cực kì quan trọng là: tự tổ chức triển khai (self-organizing) cùng liên công dụng (cross-functional). Về tự tổ chức, từ bỏ quản, tự triết lý thì dễ dàng hiểu, nhưng cụ nào là “liên chức năng”? bài xích này mong muốn chỉ ra một vài hiểu lầm hay gặp, tương tự như đào sâu thêm về quan niệm này trong phạm vi Scrum Framework để bạn học và thực hành Scrum đỡ bị lâm vào tình thế những nghịch lí khi nỗ lực cố gắng đối lập Scrum với đều gì hiện tại có.

Bạn đang xem: Cross functional team là gì

Bài Viết: Cross functional team là gì

Có người bảo “cá nhân trong team liên công dụng biết làm toàn bộ mọi việc, trong đội Scrum không ai là tester hết, không cần designer trong nhóm Scrum nữa, chỉ gồm developer thôi”.

Có fan lại bảo “nhóm liên tính năng có nghĩa là người nào cũng có thể có tác dụng được việc thay thế người khác, không đề xuất phân vai rõ ràng, một người dân có vấn đề sẽ không còn liên quan bao gồm cả nhóm”.

Có tín đồ thì có hứng phát biểu “một nhóm mà liên tác dụng thì khôn xiết năng suất”.

Những đánh giá trên trên những không ổn, và chúng là những nổi bật về phần đa ngộ nhấn khi đề cập đến nhóm Scrum.


Vậy đội liên chức năng là gì?

Đây chưa hẳn là khái niệm mớ lạ và độc đáo gì, và về cơ bạn dạng nó chưa có nhiều biến đổi trong cách thức định nghĩa: đó là một đội kể cả nhiều cá nhân với phần đa nghiệp vụ không giống nhau được kết hợp lại cùng làm việc hướng tới một kim chỉ nam chung.


*

Trong nhóm dự án, những cá nhân có thể tới từ khá nhiều phòng ban công dụng khác nhau, cũng hoàn toàn có thể xuất phát từ ngoài trời (quý khách, những cá thể có liên quan, chuyên viên tư vấn v.v.). Nhưng lại khi đang thành một đội nhóm (team), thì những cá nhân làm việc tập trung cho team như là một đơn vị chức năng (unit) để hoàn tất phương châm chung. Phía bên trong nhóm liên tính năng không bao gồm nhóm bé dại khác. Ví dụ: một nhóm Scrum “Alpha” được thành lập với một sản phẩm Owner, một Scrum Master, 2 Tester, 5 Developer, 1 Architect, 1 UX Designer sẽ không còn phân chia công dụng thành số đông nhóm nhỏ tuổi khác như team Testing (2 người), nhóm Developement (5 người) … nữa, mà chỉ có một nhóm duy nhất “Alpha” với những cá nhân có những nhiệm vụ khác nhau, vừa lòng thành một nhóm thống nhất để gia công việc hướng về sản phẩm bắt buộc phát triển. Trong cách tiến hành nói của Ken cùng Jeff, tester xuất xắc analyst … hồ hết là developer, bọn họ là nhà cải tiến và phát triển nhưng có nghiệp vụ đặc thù là kiểm thử giỏi phân tích; developer trong trường hợp này không có ý nghĩa sâu sắc là coderprogramer. Bài toán xóa nhòa phần lớn title này còn có mục đích là nhằm gom mọi tín đồ vào một mục tiêu chung, không sáng tỏ “nhãn mác” (title): cách tân và phát triển ứng dụng.


Khác với đội liên chức năng, nhóm chức năng (functional team) thường xuyên chỉ phụ trách một loại việc làm quánh thù. Ví dụ, phòng xây cất thì ko code, phòng demo thì không ai design. Vấn đề làm của nhóm chức năng thường sẽ sở hữu tính cô lập cao.

Có bắt buộc cứ “liên chức năng” thì nhóm đã năng suất xuất xắc không?

Hỏi cách làm khác, liệu cứ xây dựng một tổ Scrum với phương thức tổ chức triển khai liên tính năng như vậy, thì nhóm đã ngay tức khắc sẽ gia tăng năng suất lao động?

Rõ là không thuận lợi như vậy rồi.

Liên chức năng chỉ là 1 “cấu hình” trong những phương thức thức kết cấu nhóm có tác dụng việc. Với phương thức cấu hình này được phép sinh ra một đội độc lập với không thiếu thốn những nghiệp vụ thiết yếu để hoàn tất vấn đề làm, dưới dạng một ‘business unit’ ở tại mức tối giản. Sự độc lập này tạo ra trường hợp đến nhóm ra những ra quyết định kịp thời, đúng mực và nhanh chóng mà ko bị phụ thuộc những đơn vị chức năng khác. Ví như trong cách tiến hành thức tổ chức triển khai những nhóm công dụng (functional teams), một vấn đề làm phải đi trải qua nhiều công đoạn, mỗi công đoạn lại bởi vì những team khác biệt đảm nhiệm, và chính vì vậy sự nhờ vào (dependency) gia tăng, khiến cho sự linh hoạt sút xuống, cùng có nguy hại làm giảm sự hiệu quả cũng như năng suất của nhóm.

Về mặt lí thuyết, với cấu hình “liên chức năng”, đội Scrum có công dụng trở thành một “work cell” và đã đạt được “luồng một sản phẩm” (thuật ngữ của Lean), từ đó vừa ngày càng tăng năng suất, vừa gia tăng quality sản phẩm; đồng thời tạo nên trường phù hợp để vận hành “hệ thống kéo” (cũng thuật ngữ Lean), giúp loại bỏ những lãng phí không thiết yếu, tối ưu hóa giá bán trị.

Nhưng một đội bất kì đều đề nghị trải qua những tiến trình Hình thành > Bão tố > Ổn định > hiệu suất > Thoái trào (theo Tuckman). Có nghĩa là nó quan trọng đạt được hiệu quả ngay khi bắt đầu xây dựng được.


Mặt khác, về “hiệu suất”, Katzenbach với Smith chỉ ra rằng một tổ phải mất không ít nỗ lực mới đạt được kết quả này thực sự. Nó sẽ ảnh hưởng phải trải qua phần đa trạng thái như là 1 “nhúm” những cá nhân rời rạc, tính đến khi trở thành một tổ thực sự, rồi mới phát huy tác dụng cao.


*

The team performance curve. Katzenbach và Smith (1993)

Hiệu suất hay không do nhiều nguyên nhân cấu thành. Công suất thường là cái sau cùng trong toàn bộ những nỗ lực, cơ mà “cấu hình nhóm” là trong những nỗ lực như vậy. Nếu coi “cấu hình nhóm” là phần “cứng”, thì còn các yếu tố nữa đưa ra quyết định nhóm có “hiệu suất” không, đó là phần đa phần “mềm” của nhóm: phương thức quản lý nhóm, quy tắc, phương pháp, sự chỉ huy v.v. Trong Scrum, đầy đủ yếu tố “mềm” này được phân bố rải rác rến trong chính sách trao quyền để nhóm “tự tổ chức” (self-organizing), “tự quản” (self-managing), “tự định hướng” (self-directed); trong số những phân bố vai trò trong đội (ai lãnh đạo vấn đề gì, ai phụ trách việc gì); phần lớn quy tắc và phương pháp cộng tác (những burndown chart, backlogs, events, metrics); cho tới nguyên lí và cơ chế bảo đảm sự rành mạch trong thao tác làm việc v.v.. Tất cả những yếu tố đó kết hợp thuần thục với “cấu hình” mới làm cho một nhóm hiệp tác chặt chẽ, mau trưởng thành, sớm có được trạng thái năng suất cao. Rước ví dụ, việc một tổ liên công dụng được trao quyền tự tổ chức sẽ phát huy được sự nhà động, giảm thiểu dựa vào vào bên cạnh trời (hay phía trên); cũng do một đội nhóm liên tính năng đã có rất nhiều đủ những năng lực thiết yếu để giải quyết và xử lý vấn đề cần tuyệt đối có thể trao quyền mang đến nó nhằm tự nó phân phát huy năng lực tập thể xử lý vấn đề theo phương thức tốt nhất; nhờ kia sự liên tính năng kết hợp với sự trường đoản cú quản, từ tổ chức có thể thúc đẩy những sáng kiến từ dưới lên (bottom-up), trực tiếp, lập cập và đúng chuẩn. Lúc đó, lãnh đạoquản lí triển khai việc cai quản yếu là xúc tiến quá trình cộng tác nhóm với tự quản của nhóm trải qua bảo vệ quy trình, đào thải trở ngại, thiết lập cấu hình và bảo trì môi trường xung quanh thuận lợi, thúc đẩy quá trình thanh tra-thích nghi, v.v. Chứ không còn bám gần cạnh từng đầu vấn đề làm nữa. Bài toán này đã được quy định chặt chẽ trong “mô tả vấn đề làm” của từng vai trò (Scrum Master, product Owner, DevTeam) rồi.

Thế còn chuyện “liên tính năng thì không biến thành liên quan vày xáo trộn cá nhân”? Chuyện một cá thể ra đi nhưng mà nhóm không tồn tại xáo trộn chỉ là ảo tưởng. Chỉ có robot mới rất có thể đáp ứng được yêu cầu đó. Theo hướng đó thì chỉ việc tôn lên quy trình, quản lí thiệt chặt đầu vấn đề làm của member theo lối “công nhân” tay chân, giao mang lại những câu hỏi làm vắt định, xếp vào số đông vị trí và quy trình được mô tả ví dụ Việc này khả thi tại vị trí khác, chứ hay nhiên khó hiệu quả ở đội cải tiến và phát triển ứng dụng vốn có thực chất phức tạp, với rất nhiều chủng loại trong từng bài toán làm. Hơn thế nữa, câu hỏi gán chuyện “không xới trộn” vậy nên cho đội liên tính năng còn làm phản lại nguyên lí của Agile: “Cá nhân và tác động hơn là quy trình và công cụ”. Cá nhân là tiền đề của nhóm, là nơi ra quyết định thành bại của nhóm. Nhưng cá nhân ấy là cá nhân đặt vào nhóm cộng tác, với phần nhiều yên ước cao về mọi “tương tác” có quality thì mới giải phóng được năng lực của chính những cá thể ấy. Còn “quy trình” chỉ là cái cung cấp cho vấn đề phát huy năng lực của cả nhóm. Nhóm làm việc bao giờ cũng nhắm tới sự gắn kết cao độ, càng gắn kết thì lại càng dễ dẫn đến xáo trộn vì chưng sự chuyển đổi của cá thể trong nhóm. Nhóm liên tính năng có thể bao gồm một ưu thế trong việc cung ứng nhau trong vấn đề làm (do yên ước cộng tác chặt chẽ, sự phân biệt trong việc làm, cũng giống như đó là 1 trong nhóm-học-tập liên tục), nên có thể giảm thiểu rủi ro khủng hoảng của việc mất đi “chuyên gia”, nhưng bài toán xáo trộn, thậm chí còn sốc, là quan trọng tránh khỏi.

Xem thêm: Tra Từ Đền Bù Tiếng Anh Là Gì


Cuối cùng, gồm phải trong đội Scrum không hề tester, không thể QA nữa, mà chỉ với developer? developer đề xuất là dân “xịn” biết chạy thử ngon, biết code giỏi, biết kiến thiết khéo? Cũng là mộng ảo nốt! Và ảo mộng này xuất hiện đơn giản là xuất phát từ việc hiểu nhầm định nghĩa “cross-functionality” như đã nói sinh hoạt phía trên.

Nguồn Hiểu ráng nào cho đúng về “liên chức năng” – Agile Breakfast

Kiến thức quản ngại trị dự án / Quy mô cải tiến và phát triển ứng dụng / Quy mô cải cách và phát triển ứng dụng linh hoạt / các bước scrum


*

Bài Viết: Cross Functional Team Là Gì, Hiểu cầm cố Nào cho Đúng Về Cross

Thể Loại: LÀ GÌ

Nguồn Blog là gì: https://ionianisia-region.com Cross Functional Team Là Gì, Hiểu ráng Nào mang lại Đúng Về Cross