Scrum - Origins of scrum

Origins Of Scrum

Xin được phép mở đầu câu chuyện về Scrum ngày hôm nay cũng bằng một câu chuyện. Tất nhiên, câu chuyện này được lấy trong quyển sách Scrum của Jeff Sutherland. Chuyển kể về một buổi gặp gỡ của tác giả với một giáo sư ngành Trí Tuệ Nhân Tạo tại MIT là Rodney Brooks. Jeff đã rất ấn tượng với sản phẩm mà Brooks cùng các cộng sự của mình đã phát triển được, đó là 1 con robot 6 chân, nhỏ bằng con mèo có khả năng di chuyển linh hoạt, và thậm chí có thể đuổi theo Jeff ngay tại bàn làm việc của ông. Ông có hỏi Brooks: làm thế nào con robot di chuyển được vậy.

Brooks trả lời: "Hàng thập kỉ qua chúng tôi đã cố gắng để tạo ra những cỗ máy thông mình", "Bằng cách vung tiền, đốt thời gian, xây những thứ vĩ đại ảo diệu, nhưng rồi thì chúng tôi làm ra được một con siêu máy tính hạ gục con người ở môn cờ vua". Lần này, mọi thứ đã khác, con robot này có 6 chân, mỗi chân tương ứng với một bộ não, nối với nhau bởi một cái xương sống. Cái xương sống này chỉ có mỗi việc là làm theo các rules sau: tiến lên, lùi lại và không va các chân vào nhau. Một con neural-network chip ở não (đến con robot còn có não, haizz) sẽ là trọng tài cho việc này, đảm bảo các rule này được tuân thủ nghiêm ngặt. Đồng thời nó cũng "giao tiếp" với cái chân về các thông tin nó "nhìn" thấy qua camera. Không có database, không super chip, không biggest machine. Con robot sẽ học tập như một đứa trẻ: làm, sai, sửa chỉ với vài "rule" đơn giản.

Jeff nói: "Nếu chúng ta có thể tạo ra các rule y như vậy, các thành viên trong team hoàn toàn có thể hợp tác giống như những cái chân. Họ sẽ tự tổ chức, tự tối ưu". "Tôi không biết, sao anh không thử rồi cho tôi biết nó sẽ như thế nào". Và đúng là Jeff đã làm được, thứ đó gọi là Scrum.

Scrum ra đời

Jeff cùng team của mình tại công ty Easel đã nghiên cứu rất nhiều tại liệu, một trong số đó, bản phác thảo đầu tiên cho scrum, chính là paper Havard Business Review năm 1986, được viết bởi 2 giáo sư Hirotaka Takeuchi và Ikurio Nonaka. 2 vị giáo sư này đã nghiên cứu các team phát triển từ các công ty hàng đầu như Honda, Fuji-Xerox, 3M, Hewlett Packard, ... và họ nhận ra một vài điểm chung ở các team tốt nhất là: họ sử dụng các development stage gối chồng lên nhau thay vì tách biệt nhau như waterfall. Team có đầy đủ các thành phần và các thành viên đều có hiểu biết nhất định về lĩnh vực chuyên môn của người khác. Ví dụ như này, team dev viblo chẳng hạn, phần backend có nodejs, php, laravel, Elasticsearch, docker, ... thì mỗi technique đó đều có ít nhất 2 người có thể take care, như vậy họ có thể hỗ trợ, trao đổi cùng nhau. Ngoài ra team phải có được sự tự trị (autonomy), tức là họ phải được ra quyết định và thực hiện quyết định đó, những role còn lại như Product Owner hay Scrum master không được can thiệp vào. Những đặc điểm trên cũng chúng là những mục đích mà scrum, hay Jeff Sutherland hướng tới, vì vậy các bạn sẽ còn thấy những dòng này lặp lại xuyên suốt các bài viết của tôi.

Các nguyên tắc, nguyên lý trong scrum

Như đã đề cập ở trên, chúng ta cần phải có vài rules trước khi cho con robot 6 chân hoạt động. Những nguyên tắc như Observe - Orient - Decide - Act hay Plan - Do - Check - Act cycle, Shu-ha-ri đều là những nguyên tắc xương sống giúp scrum hoạt động và hoạt động tốt. Ở đây, tôi sẽ gộp OODA và PDCA vào làm một, vì tôi thấy chúng khá giống nhau.

OODA & PDCA

Nguyên tắc này nhấn mạnh vào việc bạn phải làm được một cái gì đó đã, không cần biết là nó hoàn hảo hay không, bạn phải có kế hoạch, bạn phải làm gì đó, cho ra một thứ gì đó cũng được, rồi thử xem nó hoạt động hay không, sai ở đây, mấy trăm bug, sau đó, ta sẽ từ từ cải thiện. Ở mỗi bức tường ở trụ sở Facebook họ đều treo 1 slogan như thế này "Hoàn thiện hơn hoàn hảo", vâng, đúng như vậy. Scrum là như vậy, mục tiêu của nó không phải là tạo ra 1 sản phẩm hoàn hảo, mục tiêu của nó, là tạo 1 sản phẩm phù hợp, đúng deadline, không vượt budget, và không ai phải OT cả.

PDCA là cách thức hoàn hảo để bạn thực hiện điều đó, Plan-lên kế hoạch bạn sẽ làm những gì, và hãy làm những việc, đó, kiểm tra sai sót, lỗi ở đâu, cải thiện liên tục, Act ở đây chính là thay đổi cycle này dựa trên môi trường, điều kiện, tình trạng mà bạn đang gặp phải. Đừng khó chịu vì khách hàng đổi requirement 5 phút một lần. Hãy vả vỡ mặt nó. Đùa thôi, thay đổi là điều tất yếu mà. Cũng đừng cảm thấy bất ngờ nếu backlog mất gần 2 tuần để làm của bạn bị thay đổi từng chút một sau mỗi tuần, đó là điều bình thường trong scrum. Cứ vài tháng laravel, nodejs hay react lại update một lần, không sao, improvement là bắt buộc trong scrum. Nhưng improve kiểu gì nếu Retrospective Meeting 1 tháng mới diễn ra 1 lần. Tôi không biết bạn lấy cái idea hay lý thuyết đấy ở đâu ra, nhưng improvement hoàn toàn có thể diễn ra từng ngày trong mỗi sprint (đừng hiểu nhầm ý tôi), và Retrospective Meeting có thể được diễn ra 1 tuần 1 lần. Miễn là chúng ta thấy cần, chúng ta sẽ phải làm.

Shu-ha-ri

Shu ha ri là 3 từ, với 3 nghĩa riêng biệt. Shu - gìn giữ, ha - phá bỏ, ri - rời khỏi. Trong văn hóa Nhật thì rất nhiều thứ liên quan đến học tập, vỡ thuật, kiếm thuật, trà đạo, ... được áp dụng Shu ha ri. Đây là các bước cơ bản của sự phát triển và sáng tạo, là thước đo của sự phát triển kĩ năng cá nhân. Giả dụ thế này, tôi áp dụng Shu ha ri vào dota (hay lol, dota2). Ban đầu tôi mới tập chơi, tôi sẽ lên mạng và search thế này "làm thế nào chơi giỏi dota", "hướng dẫn chơi dota đơn giản", "hướng dẫn first blood". Ở trạng thái này, tôi đang bắt đầu với Shu, chúng ta từ chưa biết gì, học tập theo các quy tắc của trò chơi và tuân theo nó. Với Ha, chúng ta đã chơi trò chơi đó hàng trăm lần, đã gần master tất cả các thủ thuật, cách chơi, chúng ta bắt đầu sáng tạo ra một vài thứ mới, chúng ta trộn lẫn các típs & tricks, lên đồ theo tình trạng trận đầu chứ không theo hướng dẫn. Và sau khi đã thực hành, sáng tạo cả trăm lần và dần dần quen thuộc, chúng ta đến với ri, lúc này, chính chúng ta là người tạo nên các tutorial kia, chúng ta sẽ phát triển ra các chiến thuật riêng mà mọi người muốn làm theo. Thay vì ăn roshan ở lúc quyết định để kết thúc trận đấu thì vừa vào trận đấu phát ăn luôn để tạo lợi thế lớn, đồng thời đánh 1 đòn phủ đầu vào ý chí, tinh thần của đối thủ.

Kết luận

Vậy là chúng ta đã cùng nhau đi hết bài viết, thực chất tôi đã đình hoàn thành bài viết này ngay 1 tuần sau bài đầu tiên của seri. Nhưng vì quá bận với các dự định cá nhân nên chưa thể nhanh chóng hoàn thành bài viết. Từ giờ tôi sẽ cố gắng mỗi tuần 1 bài để có thể kết thúc series này và chuyển sang 1 vài cuốn sách khác khá hay mà tôi đang đọc.