Five Tips for a More Productive Team

https://blog.codeship.com/five-tips-for-productive-team/

Hãy tưởng tượng, nếu bạn có thể tiết kiệm 30 phút mỗi ngày cho mỗi thành viên trong team của bạn với các công cụ và quy trình tốt hơn. Đối với team có 6 thành viên, chúng ta sẽ có thêm 15 giờ mỗi tuần, và với 15 giờ đó chúng ta có thể sử dụng nó để optimize các phần khác của hệ thống, làm nó tốt hơn. Chúng ta hãy xem làm thế nào để chỉ với mỗi một vài thay đổi nhỏ có thể dẫn đến một team hiệu quả hơn (productive team).

1. Làm code review hiệu quả hơn (Make code review more effective)

Quá trình review được dùng để chúng ta có thể chia sẻ kiến thức và phát hiện, tìm thấy các issues. Nó không phải là vấn đề nếu chúng ta làm việc về quản lý cấu hình (configuration management), hay là với phần mêm trung gian nào đó, hoặc là frontend, code reviews là một phần thiết yếu trong quy trình làm việc của chúng ta ngày hôm nay, vì vậy chúng ta hãy xem làm so để có thể cải thiện chúng.

Checking out code để review có thể coi là việc tẻ nhạt. Nếu mọi người không sử dụng cùng một origin, bạn sẽ phải tự thêm mỗi fork để review. Forks rất phổ biến ở cả dự án mã nguồn mở và dự án private. May mắn là chúng ta có một cách dễ dàng hơn để làm việc đó. Bằng cách thêm một dòng vào file cấu hình .git/config trong một repository, chúng ta có thể dễ dàng check out pull requests như sau:

$ git fetch
$ git checkout pr/8

Và chúng ta đã có PR#8 ở trong chính máy của chúng ta.

2. Giảm sự lặp lại

Hầu hết các team đêu đang vận hành theo workflow sau để tiến hành review:

1. Bob mở một pull-request ngay sau khi anh ấy nghĩ rằng mã code của anh ấy đã sẵn sàng để merged và deploy.
2. Bob đã thông báo cho Alice rằng anh ấy cần được review.
3. Alice ngừng suy nghĩ về task hiện tại của mình và chuyển sang review cho Bob. Cô ấy add công việc review vào schedule của mình và tiếp tục với công việc của cô ý. Nếu Alice đang làm việc trên một vấn đề phức tạp, thì sẽ phải mất một thời gian để Alice có thể đạt được tốc độ như trước.
4. Trong suốt 1 ngày sau đó, Alice chạy mã code từ pull-req trên máy tính cá nhân của cô ấy. Alice đã phát hiện ra một số issues khi cô đọc mã code. Cô đã comment trên pull-req và trở về với task của mình. Một lần nữa lại spent một số thời gian để trở về công việc đang dang dở trước đó.
5. Bob fix những issues.
6. Workflow lại bắt đầu từ bước 2 cho đến khi tất cả các issues được giải quyết bao gồm tất cả những gì có trong process.

Một quá trình review cần 2 người phối hợp thời gian của họ. Mỗi lần lặp lại có nghĩa là bối cảnh chuyển sang cho người review, họ phải dành khá nhiều thời gian sau mỗi lần gián đoạn để có thể đạt được tốc độ một lần nữa.

Để thực hiện review một cách hiệu quả hơn, chúng ta có thể cố gắng tránh lặp lại không cần thiết. Một cách để giảm sự lặp lại là viết các mã code để unit, integration test có thể kiểm tra trước khi review pull-req. Style guides là một ví dụ tốt nơi là automatic tests có thể làm được, và bằng cách nào đó chúng ta có thể kiểm tra chúng. (tương tự với việc check CI trước khi review).

Bằng cách này công việc review gọn gàng hơn. Team có thể merged dễ dàng hơn, và người mới không cần phải nhớ tất cả specs mà không một ai có thể nhớ khi họ là một thành việc mới trong project. Việc automatic check giúp bạn fix code trong khi chúng ta viết nó.

3. Giới hạn gián đoạn

Sự gián đoạn là kryptonite cho developers. Sau mỗi lần gián đoạn, một developer cần 20 phút để quay lại với khu vực của mình. 4 lần gián đoạn trong 3 giờ dẫn đến việc mất 80 phút. Rõ ràng việc limit gián đoạn là chìa khóa để hoàn thành công việc.

Tất nhiên, việc đó không có nghĩa là bạn ẩn đi trong 1 tháng và chỉ đơn giản là bạn không avaliable. Định nghĩa một makers time có thể giúp đỡ; một khối thời gian dành cho năng suất với việc không bị gián đoạn.

Đối với một số người, nó đủ để tắt chat, các ứng dụng email client trong một vài giờ. Một số công việc tại phòng khác nơi mà họ sẽ không bị gián đoạn. Một số người khác thích tạo ra một khoảng thời gian của họ bằng cách đi đến quán cafe nào đó và ngồi trong góc yên tĩnh nào đó. Không phải là hoàn toàn avaliable với phần còn lại trong team có thể giúp cũng ta hiệu quả hơn.

4. Tận dụng thời gian

Ngày càng có nhiều người làm việc trong distributed teams, nhưng làm việc từ xa có thể là một thử thách. Có thể một vài thành viên của nhóm được đặt tại châu Âu, nhưng một nửa khác lại ở phía Tây. May mắn thay chúng ta có thể biến điểm yếu đó thành điểm mạnh.

Một mô hình sản xuất cho các đội từ xa được bàn giao. Hãy tưởng tượng một team với đội design ở San Francisco và team developers ở châu Âu. Trong khi các nhà thiết kế ở San Francisco ngủ thì các developers ở châu Âu bắt đầu applies design. Trong những giờ mà cả 2 cùng online thì họ cùng chia sẻ thông tin phản hồi. Trong khi chờ đợi calling từ team developers, team design sẽ có nguyên một ngày để làm việc với design tiếp theo. Khi member team developers thức dậy họ đã thấy các mẫu mới được cập nhật. Việc lặp lại như vậy sẽ khiến mọi người đều vui vẻ với kết quả đạt được.

5. Lắng nghe từ đồng nghiệp

Đồng nghiệp và cộng sự chính là những nguồn tuyệt với giúp chúng ta cải thiện tốt. Chúng ta có thể nghe thấy một câu hỏi như "tại sao CI lại chạy lâu như vậy?". Hay các cuộc thảo luận watercooler như là "Nó chạy 2 lần, và tôi không biết tại sao."

Đó thật sự là một câu hỏi tốt. Tại sao CI lại chạy 2 lần? Tiếp tục điều tra, nghiên cứu sẽ tiết lộ rằng, hai lần chạy là mặc định của CI để test cho cả 2 trường hợp, merged master và trên chính pull-req đó. Và vô hiệu hóa chúng sẽ tăng lên 100% tốc độ của nó, đó là tất cả kết quả của cuộc trò truyện.

Hãy quan tâm đến những gì mà đồng nghiệp của bạn đang gặp phải. Đôi khi chỉ là những fix từ một góc nhỏ nào đó, nhưng có thể cả team sẽ thu được lợi ích từ nó.

Những thay đổi nhỏ sẽ có những tác động lớn

Có nhiều cải tiến có thể hỗ trợ năng suất của một team, và khá thường xuyên họ ẩn trong công việc hằng ngày của chúng ta. Bằng cách quan sát và phản ánh trên workflow và processes, chúng ta có thể tạo ra các note của các cơ hội đơn giản mà không cần những tool đắt tiền hoặc nhiều thời gian phát triển.