Cross-Functional Là Gì

trang chủ Pmùi hương pháp Agile Hiểu cầm làm sao đến đúng về Cross-Functional vào team thao tác làm việc theo tiến trình Scrum

*

Nhóm Scrum có nhì Điểm lưu ý cực kỳ đặc trưng là: từ tổ chức triển khai (self-organizing) cùng liên tác dụng (cross-functional). Về từ bỏ tổ chức triển khai, tự cai quản, từ kim chỉ nan thì dễ hiểu, mà lại chũm làm sao là “liên chức năng”? Bài này ước muốn đã cho thấy một vài hiểu lầm hay gặp mặt, tương tự như đào sâu thêm về khái niệm này trong phạm vi Scrum Framework nhằm bạn học tập với thực hành Scrum đỡ bị lâm vào các nghịch lí khi nỗ lực trái chiều Scrum với phần nhiều gì hiện nay tất cả.

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

Có tín đồ bảo “cá nhân trong nhóm liên tác dụng biết có tác dụng tất cả phần đông vấn đề, trong nhóm Scrum không một ai là tester không còn, không đề xuất designer trong đội Scrum nữa, chỉ gồm developer thôi”.

Có bạn lại bảo “team liên công dụng có nghĩa là ai cũng có thể làm được việc thay thế bạn không giống, không đề nghị phân vai rõ ràng, một người dân có vụ việc sẽ không tác động tới cả nhóm”.

Có fan thì có hứng tuyên bố “một đội nhóm nhưng liên công dụng thì hết sức năng suất”.

Những đánh giá trên bên trên hồ hết bất ổn, và bọn chúng là các điển hình về các ngộ nhấn Lúc đề cùa đến team Scrum.


Vậy nhóm liên công dụng là gì?

Đây chưa phải là định nghĩa mới mẻ gì, cùng về cơ bản nó chưa có nhiều biến đổi trong biện pháp định nghĩa: đó là một team bao gồm những cá thể với các chuyên môn khác biệt được phối hợp lại cùng làm việc nhắm tới một kim chỉ nam chung.

*

Trong nhóm dự án công trình, các cá thể có thể cho từ khá nhiều cơ sở công dụng không giống nhau, cũng hoàn toàn có thể xuất phát từ bên phía ngoài (quý khách hàng, những cá nhân gồm tương quan, chuyên gia support v.v.). Nhưng khi đã thành một nhóm (team), thì các cá nhân thao tác tập trung đến đội nhỏng là một đơn vị (unit) để hoàn chỉnh kim chỉ nam bình thường. Bên vào đội liên tính năng không có những nhóm nhỏ dại không giống. Ví dụ: một Nhóm Scrum “Alpha” được Thành lập và hoạt động với cùng 1 Product 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 những team bé dại khác ví như nhóm Testing (2 người), đội Developement (5 người) … nữa, mà chỉ tất cả một nhóm độc nhất “Alpha” với những cá thể gồm những trình độ chuyên môn khác nhau, phù hợp thành một đội nhóm thống tuyệt nhất để triển khai việc nhắm tới sản phẩm yêu cầu phát triển. Trong giải pháp nói của Ken và Jeff, tester tuyệt analyst … hầu như là developer, họ là bên phát triển mà lại tất cả trình độ tính chất là kiểm demo tuyệt phân tích; developer vào trường hòa hợp này không tồn tại ý nghĩa sâu sắc là coderprogramer. Việc xóa nhòa những title này có mục đích là để gom đều người vào trong 1 mục tiêu phổ biến, không phân biệt “nhãn mác” (title): phát triển ứng dụng.

Khác cùng với đội liên tác dụng, nhóm chức năng (functional team) hay chỉ prúc trách một các loại công việc tính chất. lấy một ví dụ, chống kiến thiết thì không code, phòng thử nghiệm thì không người nào kiến thiết. Công câu hỏi của group tác dụng thông thường có tính cô lập cao.

Xem thêm: Lux Guide Mùa 9

Có phải cứ “liên chức năng” thì team đã năng suất tuyệt không?

Hỏi giải pháp không giống, liệu cứ đọng Ra đời một tổ Scrum cùng với cách tổ chức triển khai liên chức năng như thế, thì đội sẽ tức thì tức xung khắc đang gia tăng năng suất lao động?


Rõ là ko tiện lợi như vậy rồi.

Liên tính năng chỉ là một trong “cấu hình” trong những cách thức cấu trúc team thao tác làm việc. Và phương pháp thông số kỹ thuật này cho phép ra đời một tổ hòa bình cùng với không thiếu thốn các trình độ quan trọng để hoàn tất công việc, bên dưới dạng một ‘business unit’ ở mức buổi tối giản. Sự chủ quyền này tạo điều kiện cho nhóm ra các quyết định đúng lúc, đúng mực cùng mau lẹ mà lại không trở nên dựa vào những đơn vị khác. Ví như trong phương pháp tổ chức triển khai các nhóm công dụng (functional teams), một các bước phải đi trải qua không ít quy trình, mỗi quy trình lại vị các team khác nhau đảm nhiệm, với vì vậy sự dựa vào (dependency) ngày càng tăng, khiến cho sự linch hoạt sụt giảm, và bao gồm nguy cơ có tác dụng giảm sự kết quả cũng tương tự năng suất của group.

Về khía cạnh lí tmáu, với thông số kỹ thuật “liên chức năng”, Nhóm Scrum có công dụng biến một “work cell” cùng dành được “luồng một sản phẩm” (thuật ngữ của Lean), từ bỏ đó vừa tăng thêm năng suất, vừa ngày càng tăng unique sản phẩm; bên cạnh đó chế tạo điều kiện nhằm quản lý và vận hành “khối hệ thống kéo” (cũng thuật ngữ Lean), giúp thải trừ các tiêu tốn lãng phí không cần thiết, buổi tối ưu hóa quý giá.

Nhưng một nhóm bất kể hồ hết cần trải qua các quy trình Hình thành > Bão tố > Ổn định > Hiệu suất > Thoái trào (theo Tuckman). tức là nó quan trọng dành được công dụng ngay trong khi mới ra đời được.

Mặt không giống, về “hiệu suất”, Katzenbach cùng Smith chỉ ra rằng một tổ buộc phải mất khá nhiều nỗ lực mới giành được kết quả đó đích thực. Nó vẫn đề nghị trải qua những trạng thái nhỏng là 1 “nhúm” các cá thể tránh rộc, cho tới lúc đổi mới một tổ thực sự, rồi new đẩy mạnh công dụng cao.


*

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

Hiệu suất hay không vì chưng các nguyên ổn nhân cấu thành. Hiệu suất thường là mẫu sau cùng vào toàn bộ những nỗ lực cố gắng, cơ mà “cấu hình nhóm” là 1 trong trong các nỗ lực cố gắng những điều đó. Nếu coi “cấu hình nhóm” là phần “cứng”, thì còn nhiều nhân tố nữa ra quyết định team bao gồm “hiệu suất” không, chính là những phần “mềm” của nhóm: phương pháp vận hành nhóm, nguyên tắc, phương thức, sự lãnh đạo v.v. Trong Scrum, những nhân tố “mềm” này được phân bổ rải rác rưởi vào chính sách trao quyền để đội “từ bỏ tổ chức” (self-organizing), “từ quản” (self-managing), “tự định hướng” (self-directed); trong các phân bổ sứ mệnh trong team (ai chỉ đạo Việc gì, ai phú trách nát câu hỏi gì); các phép tắc cùng phương pháp hợp tác (những burndown chart, backlogs, events, metrics); cho đến nguyên lí cùng cách thức đảm bảo sự biệt lập vào thao tá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” new làm cho một đội hợp tác nghiêm ngặt, mau cứng cáp, nhanh chóng đạt được trạng thái năng suất cao. Lấy ví dụ, câu hỏi một nhóm liên tính năng được trao quyền trường đoản cú tổ chức đã phát huy được sự chủ động, sút thiểu phụ thuộc vào bên phía ngoài (tốt mặt trên); cũng bởi vì một đội nhóm liên chức năng đang có đủ những năng lực cần thiết để giải quyết sự việc yêu cầu hoàn toàn hoàn toàn có thể trao quyền mang đến nó nhằm từ bỏ nó phát huy năng lượng bè lũ xử lý vụ việc theo cách tốt nhất; nhờ kia sự liên chức năng kết hợp với sự từ quản lí, từ bỏ tổ chức hoàn toàn có thể thúc đẩy các sáng kiến từ bỏ bên dưới lên (bottom-up), thẳng, hối hả và chính xác. Khi đó, lãnh đạoquản ngại lí triển khai công việc đa số là xúc tiến quy trình hợp tác team cùng trường đoản cú quản lí của tập thể nhóm trải qua bảo đảm an toàn quy trình, thải trừ trsinh sống trinh nữ, tùy chỉnh cấu hình với duy trì môi trường thiên nhiên thuận tiện, can dự quá trình tkhô cứng tra-ham mê nghi, v.v. chđọng không còn bsát hại từng đầu quá trình nữa. Việc này đã có được cách thức ngặt nghèo trong “biểu lộ công việc” của từng mục đích (Scrum Master, Product Owner, DevTeam) rồi.

Thế còn chuyện “liên tác dụng thì không trở nên tác động bởi xáo trộn cá nhân”? Chuyện một cá nhân ra đi mà lại team không tồn tại xáo trộn chỉ là mộng tưởng. Chỉ có robot mới có thể đáp ứng được thử dùng đó. Theo phía kia thì chỉ vấn đề đề cao quá trình, quản ngại lí thật chặt đầu quá trình của thành viên theo lối “công nhân” thủ công, giao cho những các bước cố định, xếp vào các vị trí với quy trình được diễn tả cụ thể Việc này khả thi ở vị trí khác, chứ hay nhiên khó khăn kết quả làm việc nhóm trở nên tân tiến ứng dụng vốn tất cả bản chất phức hợp, và rất đa dạng và phong phú vào từng công việc. Hơn cầm cố nữa, vấn đề gán cthị trấn “không xới trộn” điều này đến đội liên tính năng còn bội nghịch lại ngulặng lí của Agile: “Cá nhân với can hệ hơn là quy trình cùng công cụ”. Cá nhân là tiền đề của nhóm, là chỗ quyết định thành bại của nhóm. Nhưng cá thể ấy là cá thể đặt trong nhóm cộng tác, cùng với những đòi hỏi cao về những “tương tác” gồm chất lượng thì mới giải pngóng được năng lực của chủ yếu những cá thể ấy. Còn “quy trình” chỉ nên chiếc cung cấp mang lại Việc phát huy năng lực của cả đội. 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 bởi vì sự biến hóa của cá thể vào nhóm. Nhóm liên công dụng hoàn toàn có thể bao gồm một ưu điểm vào Việc cung cấp nhau trong công việc (vị đòi hỏi hiệp tác chặt chẽ, sự sáng tỏ vào công việc, tương tự như đó là 1 nhóm-học-tập liên tục), nên có thể bớt tphát âm khủng hoảng rủi ro của Việc thiếu tính “siêng gia”, mà lại việc đảo lộn, thậm chí là sốc, là tất yêu rời khỏi.

Cuối cùng, bao gồm yêu cầu trong Nhóm Scrum không thể tester, không thể QA nữa, cơ mà chỉ còn developer? developer cần là dân “xịn” biết kiểm tra ngon, biết code xuất sắc, biết design khéo? Cũng là ảo tưởng nốt! Và mộng ảo này xuất hiện thêm đơn giản và dễ dàng là căn nguyên từ các việc phát âm nhầm khái niệm “cross-functionality” nhỏng đã nói sinh hoạt bên trên.

Nguồn Hiểu gắng làm sao mang lại đúng về “liên chức năng” – Agile Breakfast


Kiến thức cai quản dự án / Mô hình phát triển phần mềm / Mô hình cải cách và phát triển ứng dụng linh hoạt / Quy trình scrum
*