Văn hóa học nhóm trong ngành phần mềm

Bài viết này được tham khảo từ:

http://searchsoftwarequality.techtarget.com/definition/Whole-team-approach

http://www.scrumexpert.com/knowledge/are-you-a-whole-team/

Bạn đã theo nghiệp phần mềm thì bạn phải luôn luôn mài giũa kỹ năng của bản thân. Tất nhiên, kỹ năng là điều cần thiết đối với bất kỳ ngành nghề nào nhưng chắc các bạn cũng hiểu đối với kỹ sư phần mềm thì nó đặc biệt quan trọng.

Một phần của công việc đó là không ngừng theo đuổi những công nghệ mới nhất đang liên tục được tạo ra, việc bắt kịp xu hướng công nghệ rất quan trọng và thú vị. Nhưng không chỉ có vậy, quan trọng hơn là bạn cần phải nắm được cách suy nghĩ, cách làm cơ bản, biến nó thành của mình và tiếp tục duy trì cách làm, cách suy nghĩ đó. Khi bạn thực hiện được cả hai việc đó thì có thể nói bạn đã đang mài giũa kỹ năng của bản thân rồi?

Trước hết, hãy chọn một trong hai việc. Vì chỉ bản thân mỗi cá nhân thì không thể học được hết tất cả các chiều hướng phát triển phần mềm trên thế giới hiện nay.

Ở đây tôi muốn đề cập đến hai vấn đề để các bạn hiểu rõ hơn về nội dung mà tôi đang đề cập đến.

Thứ nhất: Phương pháp tiếp cận toàn đội

Các phương pháp tiếp cận toàn đội, còn gọi là phương pháp tiếp cận theo nhóm, là một phong cách quản lý dự án, trong đó tất cả mọi người trong nhóm dự án được tổ chức đều chịu trách nhiệm về chất lượng và sự thành công của dự án. Thuật ngữ này thường được sử dụng trong phát triển phần mềm linh hoạt , sản xuất tinh gọn và các nhóm sáng tạo trong quảng cáo và các phương tiện khác.

Cách tiếp cận toàn đội chỉ ra rằng để cho các đội để thành công, các thành viên không thể hoạt động một cách độc lập. Mỗi thành viên trong nhóm phải biết và đánh giá cao những điểm mạnh và những kỹ năng mỗi thành viên của nhóm nghiên cứu khác. Mỗi thành viên trong nhóm cũng phải sẵn sàng đổi vai khi có nhu cầu và vẫn tập trung vào sự thành công của dự án, làm bất cứ điều gì là cần thiết hay không đó là kỹ thuật "their job." Trong mô hình phát triển Agile, điều này có nghĩa là tất cả mọi người trong nhóm phát triển có trách nhiệm như nhau về chất lượng. Trọng tâm của mô hình phát triển Agile là sản xuất ra phần mềm chất lượng cao trong một khung thời gian nhằm tối đa hóa giá trị của nó đối với doanh nghiệp. Đây là công việc của toàn đội, không chỉ design hoặc chuyên gia đảm bảo chất lượng. Mỗi người trong đội được “Test-infected”. Các hoạt động kiểm tra phần mềm là từ cấp độ Unit trở lên, hay là viết code, giúp đội biết cách ứng dụng nên làm việc như thế nào, và cho chúng tôi biết khi nào task được Done.

Thứ 2: Bạn có thấy một mình mình có phải là một team không?

Phần này đưa ra bốn lý do cho thấy rằng bạn không tối ưu thực hành phương pháp tiếp cận toàn đội trong dự án phát triển phần mềm Scrum của bạn.

1. Nhấn mạnh vào chức danh

Tôi nhớ lại một đội làm việc theo mô hình Agile, và một trong những thành viên trong nhóm cương quyết chỉ vào sơ đồ tổ chức để chứng minh rằng tester không được phép tham gia vào dự án cho đến khi các lập trình viên đã kết thúc phần việc của họ. Nhưng chức danh không phải là một dạng để hạn chế tiếp cận toàn đội. Khi một thành viên trong nhóm khẳng định rằng tình trạng của anh ta hay cô ta là có ưu thế hơn; và của tòan team là sai để chỉ ra vai trò của họ; hoặc team mong đợi các tester có thể làm tất cả các hoạt động test, như vậy sẽ dẫn đến rủi ro cho toàn team.

Biện pháp khắc phục: Tách vai trò của hoạt động

Khi bạn nhìn vào công việc đơn giản như các hoạt động được thực hiện cùng với nhau, bạn phá vỡ vai trò ranh giới và cho phép thành viên trong nhóm để thêm giá trị trong nhiều lĩnh vực. Ví dụ, giải phóng các lập trình viên để thăm dò thử nghiệm.Tương tự như vậy, chúng ta hãy đưa QA vào mã ứng dụng khi họ tìm thấy một lỗi họ có thể sửa chữa.

2. Văn hóa Anh hùng

Tất cả chúng tôi đã gặp ông ta: Bạn biết anh chàng trong nhóm người mà ở lại muộn tối nay hoặc làm việc cả vào cuối tuần này để có thể release sản phẩm rồi mới trở về nhà. Ông đã làm nó lần cuối cùng, và anh ta sẽ làm điều đó lúc này.

Đây là vấn đề: chủ nghĩa anh hùng là một thiệt hại và rủi ro cho dự án, vì nó làm giảm số lượng xe buýt của bạn (ví dụ, số lượng người trong nhóm của bạn, người có thể bị trúng một xe buýt và nhóm vẫn hoạt động) và thường có dạng thông tin tích trữ (không phải luôn luôn có chủ ý). Đó là một nút cổ chai để tiến bộ và học tập. Bất cứ ai có thể mất một kỳ nghỉ bất cứ lúc nào? Làm thế nào ai đó có thể dễ dàng di chuyển ra khỏi dự án?

Biện pháp khắc phục: Đừng điều khiển

Nếu bạn là người duy nhất cập nhật bảng nhóm hoặc sửa lỗi, xem những gì sẽ xảy ra nếu bạn dừng lại. Ví dụ như bạn đi nghỉ mát.

Nếu bạn có thông báo rằng các thành viên của đội được chỉ đạo ý kiến của họ chỉ cho bạn (là người lãnh đạo), chứ không phải cho tất cả các đồng đội của mình, chỉ đơn giản là ngăn chặn ánh mắt của họ - họ sẽ tự nhiên phản ứng bằng cách giải quyết khác, bồi dưỡng một cam kết chung để quyết định và quyền sở hữu trong cuộc họp. Team leader tốt nhất người là không tích trữ thông tin nhưng là người chia sẻ thông tin, dạy cho những member của mình những gì họ biết.

3: Mọi người ngồi ở các vị trí tương tự mỗi ngày (hay còn gọi là hộp của tôi, chiếc ghế của tôi)

Có phải mọi người đi vào và ngồi ở cùng nơi mỗi ngày? Có vấn đề gì mà máy trạm bạn lựa chọn? Có mỗi máy trạm có tất cả các công cụ bạn cần và nó được cấu hình để bạn có thể hoàn thành tất cả nhiệm vụ của bạn? Nếu không, điều này có thể chỉ ra rằng bạn không thường ghép nối và chuyển đổi cặp.

Biện pháp khắc phục: (Thực sự) ghép lại với nhau

Có hai thành viên trong nhóm ngồi lại với nhau tại một trạm làm việc để cộng tác trên một nhiệm vụ duy nhất được coi là cặp đôi. Ghép giúp giảm tích trữ thông tin và cải thiện số lượng xe buýt của đội, nhưng ghép nối và cặp chuyển đổi đòi hỏi kỷ luật. Nếu bạn không làm điều đó, nó có thể có nghĩa là bạn chỉ đơn giản là không tin rằng nó sẽ giúp. Để chia sẻ những kiến thức và kỹ năng, xây dựng trong thời gian cho việc học tập và cho phép một số slack trong lịch trình của bạn hoặc hệ thống Kanban. Bạn có thể cần phải đẩy lùi vào nhu cầu của khách hàng, nhưng sự mất mát ngắn hạn sẽ mang lại một mối lợi về lâu dài: Bạn sẽ di chuyển về phía thực hành cực-lập trình của quyền sở hữu mã tập và đi nhanh hơn bằng cách loại bỏ tắc nghẽn kiến thức liên quan. Hãy thử một biểu đồ ghép nối.

4. Người khác những người khác trong nhóm

Bạn đã gặp trong một cuộc họp quan trọng, có một thành viên trong nhóm rời khỏi cuộc họp chưa? Điều này có thể xảy ra khi có một sự chênh lệch lớn giữa các kỹ năng, một team có một nửa thời gian hoặc thành viên trong nhóm chia sẻ hoặc team lead nghĩ rằng tất cả mọi người trong team tham gia trong cuộc họp không phải là sử dụng tốt thời gian.

Biện pháp khắc phục: Sức mạnh của ba người.

Đội Agile có thể nhân kiến thức và ý tưởng thông qua sức mạnh của ba người. Khi bạn có một chính sách liên quan đến tester, lập trình viên và đại diện kinh doanh trong các cuộc họp quan trọng, bạn sẽ giúp team chia sẻ hiểu biết của các yêu cầu, giảm khoảng cách giao tiếp và nhận được nhiều nhất các kỹ năng và quan điểm duy nhất của mỗi người. Janet Gregory gọi điều này là sức mạnh của ba người, trong khi George Dinwiddie đề cập đến nó như ba amigos. Dù bạn gọi nó, nó là một phần cơ bản của phương pháp tiếp cận toàn bộ.

Vì vậy, lần sau khi bạn đang ngồi trong một retrospective bạn nên suy nghĩ làm thế nào bạn có thể cải thiện trong phiên bản kế tiếp hoặc chỉ đơn giản là tự hỏi nếu bạn là người duy nhất biết làm thế nào để fix hay bulid, hãy xem xét một số các quan điểm ở trên hoặc mô hình phương pháp tiếp cận toàn bộ. Hoặc tốt hơn nữa, dừng lại những gì bạn đang làm và thảo luận về nó với phần còn lại của đội bạn.

Thay cho lời kết, tôi muốn nhấn mạnh rằng “kiến thức cũng giống như các mối quan hệ, khi bạn càng chia sẻ thì kiến thức càng phát triển, các mối quan hệ được nhân rộng. Lòng tin được tạo dựng và cơ hội sẽ đến”. Để áp dụng các hình thức cùng học và cùng phát triển trên, các bạn có thể tham khảo từ các cuốn sách chỉ dẫn về hoạt động nhóm đang bán rất chạy trên thị trường như: The art of readable code; software estimation,… Nào, cùng bắt tay vào học nhóm các bạn nhé!

Chúc các bạn học nhóm thú vị và thành công!