Việt Nam vô địch. Vâng, rất xin lỗi các bạn, tôi viết bài này 1 ngày sau trận thắng tuyệt vời của đội tuyển U23 Việt Nam trước U23 Qatar, trong tâm trạng phấn khích và phần nào bất ổn. Và nói thật là tôi cũng chẳng hiểu Under the hood là gì. Căn bản thấy nhiều authors dùng nên tôi cũng cho vào title cho nó dài thêm chút.

Quay trở lại với nội dung của bài viết. Với mục tiêu đọc 50 cuốn sách trong tủ sách Framgia trong năm nay (một trong các mục tiêu mà trong lúc tâm trạng bất ổn đã nảy ra trong đầu tôi), đồng thời cũng là để chia sẻ, thảo luận những kiến thức mà mình đã đọc và học được với mọi người. Tôi đã bắt đầu với quyển đầu tiên là Scrum - The art of doing twice the work in half the time của tác giả Sutherland. Scrum thì tôi tin là đã trở nên phổ biến rất nhiều trong lĩnh vực IT, nhưng đa phần chúng ta lại chỉ biết được phần What tức là làm thế nào, còn phần How thì lại chưa được học hành một cách tử tế, vậy nên tôi mạn phép viết một series về Scrum, dựa trên cuốn sách Scrum. Có một điều mà tôi luôn muốn nhắc nhủ các bạn ở các bài viết dựa trên các cuốn sách mà tôi đọc. Là nếu có cơ hội, hãy tìm bản gốc của cuốn sách để đọc. Những kiến thức tôi chia sẻ đều sẽ bị ảnh hưởng bởi kiến thức và tư tưởng của bản thân tôi, chứ không phải là đi dịch lại lời tác giả cho các bạn. Vậy nên muốn đón nhận những kiến thức tốt nhất và tinh túy nhất, hãy đọc sách. Cũng hãy yên tâm là cuốn sách nào tôi đã dồn tâm huyết cho việc viết Monthly Report thì đều đáng để đọc cả.

ok, đi lướt qua phần lịch sử hình thành của Scrum một chút. Scrum được Jeft Sutherland và Ken Schwaber "tạo ra" hơn 20 năm về trước, cái thời mà đa phần các project đều đi theo lối mòn của phương thức waterfall. Project sẽ được chia thành các stage riêng biệt, và kết thúc tất cả các stage thì customer được nhìn thấy sản phẩm. Nhược điểm của phương pháp này là chậm chạm, khó dự đoán, chi phí lớn và thường không đáp ứng đúng nhu cầu khách hàng. Đấy là nguyên nhân năm 1993, Scrum ra đời. Cái tên Scrum lấy ý tưởng từ môn bóng bầu dục (rugby, scrum), nó cũng ám chỉ cách một team làm việc cùng với nhau để hoàn thành mục tiêu (ở trong bóng bầu dục là đứa bóng càng sâu sân đối phương càng tốt 😄 ). Và cũng không phải ngẫu nhiên mà tác giả xếp team là yếu tốt quan trọng nhất trong scrum.

Trong thế giới hiện đại, thật khó để làm gì khi chỉ có một mình. Đa phần mọi công việc đều đỏi hỏi hợp tác: xây nhà, buôn bán, phát triển sản phẩm, nấu ăn, ... Nền tảng của một sản phẩm tốt sẽ bắt nguồn từ một team, một group, một screw tốt. Với Scrum, nó tập trung rất nhiều vào Team, luôn hướng tới việc nâng cao năng suất của các thành viên trong team, đồng thời vẫn chấp nhận những nhược điểm của mỗi thành viên.

Bên cạnh đó, là một điểm làm nên sự khác biệt thực sự giữa Scrum với waterfall, đó chính là sprint, đó chính là những buổi demo cho customer, stakeholder về sản phẩm mà họ sẽ nhận được, lấy feedback, sửa đổi ngay tức thì, giảm thời gian hoàn thành, giảm budget cho sản phẩm, lại vừa ý khách hàng. Một minh chính tiêu biểu cho việc này, mà tôi nghĩ là ai học Agile/Scrum căn bản đều còn nhớ, đó là project Sentinel của FBI. Nếu ai chưa biết thì có thể đọc thêm về Sentinel tại đây. Sentinel là một hệ thống quản lý các vụ án, vụ điều tra, xét xử của FBI Mỹ, với mục đích hỗ trợ cho quá trình điều tra của cảnh sát. Từ trước vụ 11/9 (Vụ khủng bố rất nổi tiếng ở Mỹ) họ đã nghĩ về 1 hệ thống như vậy, nhưng xây dựng không thành. Và sau này người ta đã rất hối hận vì đã không hoàn thành sentinel sớm hơn, bởi nếu hoàn thành sớm hơn thì Mỹ hoàn toàn có thể ngăn chặn vụ án thành công. Còn lý do tại sao không thành công lần đầu, và thậm chí lần thứ 2, thì các bạn hãy xem bức ảnh dưới đây. Ở lần 1 và lần 2, mọi thứ đều đúng, đều tốt, trừ cách họ thực hiện. 10 năm, hơn 600 triệu $$ra đi, và chưa có 1 sentinel nào ra hồn. Nhưng lần thứ 3, mọi thứ đã khác, chi phí còn một phần sáu, thời gian còn một phần ba, và quan trọng hơn, một sản phẩm thực sự đã ra đời.

Tôi biết, rằng đa phần những người đọc bài viết này, sản phẩm mà các bạn đang thực hiện chẳng thể đạt đến mức trăm triệu đô như vậy, nhưng điều đó không có nghĩa là project của bạn sẽ không fail nếu còn tiếp tục áp dụng những stage và chart đẹp đẽ từ waterfall. Và mong rằng sau khi đọc những bài viết trong series Scrum của tôi, các bạn sẽ hiểu hơn về Scrum, có thể áp dụng tốt hơn nó cho team của mình, hoặc là tự refine lại chính bản thân mình để phù hợp hơn với project, với Scrum.

Bài mở đầu của series của mình đến đây là kết thúc. Chúng ta mới chỉ có cái nhìn sơ qua về Scrum, tiểu sử hình thành, ích lợi mà nó mang lại. Trong phần tiếp theo của series, chúng ta sẽ đi sâu hơn về Scrum, scrum là gì, các yếu tố quan trọng nhất trong Scrum, ích lợi so với thiệt hại mà nó mang lại, có nên áp dụng scrum vào các project outsource không, hay scrum sinh ra là cho product. Hãy cùng đón chờ nhé.