Hiện tại Agile và Scrum đang dần là method và framework chủ đạo trong các dự án phát triển phần mềm. Với Agile điều dự án không thể thiếu đó chính là Cross functional Team theo một kiểu khác là Multidisciplinary team (thực ra term này xuất phát từ y học, một dạng của hội chẩn), trong đó mỗi người đều có một skill-set khá rộng và đó là một trong những thành phần quan trọng giúp nhóm scrum thành công và hiệu quả.
Có những điểm khác biệt nhỏ giữa 2 định nghĩa này, Multidisciplinary có vẻ thiên hướng mọi người sẽ là chuyên gia trong lĩnh vực của mình, còn Cross functional Team thì sẽ không cần đạt đến mức chuyên gia nhưng lĩnh vực hiểu biết của họ cần rộng hơn (T-shaped)và phù hợp với Agile team.
Như vậy T-shaped có vẻ phù hợp với Agile, trong đó Cross functional Team xem việc skill của mọi người trung nhau để giảm sự phụ thuộc vào thành viên (một trong những vấn đề nhức nhối), ngoài ra như mọi người cũng thấy hầu hết các thành viên trong nhóm đều cần tham gia và hỗ trợ các task khác.
Bản thân mình cũng là một dạng T-shaped, nếu trong một team làm một sản phảm full-stack, vừa có thể làm tester, đôi khi có thể làm BA, vừa có thể làm DEV hoặc quản trị dự án, nhưng phần lớn thời gian và kiến thức phát triển DevOps.
Vậy tại sao Agile team lại cần T-Shaped
Quay trở lại một chút với thời của I-Shaped
Mỗi người chỉ chuyên gia một lĩnh vực và chỉ biết về lĩnh vực đó mà thôi, như vậy team Agile sẽ có xu hướng phân nhỏ theo lĩnh vực và vận hành song song, thay vì như một team thống nhất.
Điều đó khá phổ biến trong các công ty phần mềm trước, nhất là các team outsource bởi nguồn lực không đồng đều. Việc này gần như không ảnh hưởng đến các team lớn, vì khi đó bộ máy cồng kềnh và team chuyên biệt là điều không thể tránh khỏi. Nhưng với các dự án nhỏ, team nhỏ với mô hình Agile, I-Shaped hạn chế khả năng của team, mặc dù chắc chắn họ là những người có năng lực và trình độ cao, nhưng chúng ta thấy rằng như vậy không hiệu quả đối với sự hợp tác giữa các nhóm chức năng.
Vậy chuyển từ I-shaped sang T-shaped gần như là xu thế và nhu cầu của developer hiện giờ
T-shaped, có lợi gì?
Lợi ích là có:
- Team toàn diện hơn: Các developer có chuyên môn và thường chia ra Front-end, Back-end, DevOps, hoặc thậm chí là stack công nghệ như MEAN. Nhưng T-shaped cũng cảm thấy thoải mái khi làm những công nghệ khác, ví dụ mình đã từng là người đầu tiên trong đơn vị làm về Xamarin, Golang, Cloud, …
- Điều đó có nghĩa là bạn sẽ được giúp đỡ nhiều hơn và mọi nơi: T-Shaped developer có thể tham gia và đóng góp cho mọi phần của dự án. Bạn có thể có một nhóm nhỏ mà mỗi thành viên có nhiều trách nhiệm hơn, vì họ có thể có nhiều kỹ năng.
- Hiểu người khác: T-shaped có skill-set rộng, vậy họ sẽ có kiến thức cơ bản của nhiều lĩnh vực, họ biết những gì họ muốn, hỏi những gì họ cần, hiểu độ khó của các task khác nhau, vậy nên họ sẽ hiểu bạn hơn. Khi Backend developer nói chuyện với một Frontend developer đơn thuần, sẽ phức tạp hơn khi nói chuyện với một T-shaped có hiểu biết về Frontend, Backend, Mobile.
- Open mind: T-shaped đã biết 4 công nghệ khác nhau, điều gì ngăn cản họ biết đến công nghệ thứ 5 hay thứ 6, rõ ràng đó là một yếu tố cần thiết vầ điều mà mọi nhà tuyển dụng cần.
- Có thể hỗ trợ hoặc thay thế người khác: Điều gì sẽ xảy ra nếu một system engineer nghỉ một tuần, dự án dừng chăng? Hay khi MU không đủ tiền vệ khi tiếp Arsenal, xin hoãn thi đấu? T-shaped và cầu thủ đa năng sẽ là điều cần thiết trong tình huống đó.
Trở thành T-shaped như nào?
- Tất nhiên là học thứ mới, bạn đang có chuyên môn, muốn mở rộng skillset vậy là cần học rồi, bất kì thứ gì bạn cho là quan trọng, nhưng đừng quên củng cố chuyên môn của mình nhé. Không cần một thứ gì đó đao to búa lớn, đôi khi chỉ là những artical nho nhỏ trên Medium hoặc chính techover.io.
- Thời gian: đó là điều cần thiết, bạn cần thời gian học, thời gian trải nghiệm, có thể là hàng tháng và hàng năm. Hãy nhớ Think Big, Start Small, Build Deep.
- Kiên nhẫn: không chỉ kiên nhẫn với mình mà kiên nhẫn với cả đồng nghiệp nữa, Agile team nên là một tổ chức học tập. Bạn có thể học nhanh nhưng người khác thì không, và mọi người đều đang không trong comfort zone cả.
- Chia sẻ: hoặc gọi là Traning cũng được, mỗi lần bạn traning là một lần bạn tiếp thu lại kiến thức từ chính mình cũng như tiếp thu các cái nhìn toàn diện hơn từ các developer khác.
Sau T-shaped là gì?
Agile hay trước đó là Lean đề ra : Small Change - Big Impact. Mục đích cuối cùng của Agile đó là mọi thứ đều tốt lên: từ sản phẩm, project team, khách hàng, … Vậy T-shaped sẽ tốt lên,