Tối thứ Năm tuần trước, ScrumCoffee tập trung thảo luận xoay quanh vấn đề “Đào tạo nhân sự” để làm tốt Agile. Đây là chủ đề được lựa chọn trong số hơn chục vấn đề được đặt ra vì mọi người cùng nhận thấy đó là vấn đề nòng cốt, và rất khó khăn để thực hiện.
Hỏi nhà bác học đại tài Google mới tá hỏa ra là người ta đang ầm ầm cổ súy cho cái Agile 2.0, thậm chí 2.1 (thử phát biết ngay: tìm).
Trong khi mình đang nỗ lực thúc đẩy mấy cái Agile 1.0 (nếu có thể gọi là như vậy). Lạc hậu quá chăng?
Cũng may là định thần lại được. Thử nhìn lại mấy cái số liệu xem thế nào?
Liệu có bàn tay ma thuật của những nhà cung cấp công cụ và những nhà tư vấn quy trình. Một cách để “làm hàng” chăng?
Nhớ lại câu chuyện của một số công ty mình đến gần đây, chả thấy anh nào đầu tư cho ALM và gọi mình Agile cả. Họ đã làm những gì để trở nên linh hoạt (và họ linh hoạt hơn thật, chứ không phải là dán mác lên): dán giấy lên bảng để làm taskboard với giá khoảng vài chục nghìn (công ty này đúng là siêu bủn xỉn), hay gửi cả chục nhân viên đi đào tạo Scrum (tức là chục nghìn đô đấy!) và mua sắm hàng loạt các bảng về làm kanban v.v. Họ không đầu tư vào tool. Họ đầu tư vào con người.
Thôi mình cứ cổ hủ. 1.0 cái đã.
Một lúc nào đó người ta không còn nhắc đến cụm từ “agile software development” nữa, mà chỉ nói “software development” thôi (nhưng để ám chỉ ASD), tức là Agile đã mainstream; khi đó có ai muốn nâng cấp lên 2.0 mình sẽ chịu. Hi hi.
Nhà bác học vĩ đại Chomsky có nói thế này về việc học:
Các bạn chỉ học được và học cách tư duy như thế nào nếu có một mục đích nào đó, một động cơ nào đó, một lí do nào đó xuất phát từ chính mình. Trên thực tế toàn bộ phương pháp luận trong giáo dục thực sự không nhiều hơn thế – bắt người học phải muốn học. Một khi họ muốn học thì họ sẽ học.
“Làm thế nào để động viên người học?” là một trong những câu hỏi trung tâm của giáo dục. Và thực tế, đó cũng là câu hỏi khó vào bậc nhất vì nó động tới những vấn đề rối rắm nhất về việc “cái gì thúc đẩy, còn cái gì thì cản trở con người làm việc gì đó?”. Đấy không phải là câu hỏi tầm thường cho ngay cả những nhà tâm lí học tài ba nhất.
Có quan điểm “giáo dục phải lấy người học làm trung tâm”. Nhất trí!
Có người hỏi “như thế nghĩa là thế nào?”. Bắt đầu bí.
Hỏi thêm “[thiết kế]bài giảng như thế nào thì là lấy người học làm trung tâm?”. Lần này thì bắt đầu rối tung lên.
Trong “Cách ta nghĩ”, Dewey chỉ rõ người lớn có mối quan tâm chuyên biệt hơn trẻ nhỏ, việc học bị chi phối rất nhiều bởi các kinh nghiệm và bối cảnh (địa vị xã hội, mục đích đi học, mục đích nghề nghiệp …) trước đó. Vì thế nếu biết được các kinh nghiệm trước đó, cùng với “mối quan tâm chuyên biệt” ấy là gì, ta có thể động viên được người học. Đây là một trong những nguyên tắc quan trọng nhất về việc học (xem thêm “How people learn”).
Một bài viết ngắn gọn về quy tắc 10.000 giờ (được đề xuất bởi Malcom Gladwell trong Outliers), ý nghĩa thực sự phía sau con số ấy.
Để “chín” được trong bất kì nghề nào, cần nỗ lực không ngừng nghỉ, liên tục và đúng cách.
Hai bạn đồng nghiệp Đới và Ngọc Anh đã kết hợp để cho ra bản tiếng Việt của một trong những bài viết rất quan trọng của Martin Fowler, một chuyên gia phát triển phần mềm linh hoạt (Agile). Một bài viết xóa bỏ những ngộ nhân về sự “cáo chung” của thiết kế trong Agile.
Mời bạn đọc kĩ bài viết rất hay này.
Tặng các bạn đồng nghiệp đã tham gia
Instructional Design Workshop
Giáo dục hiện đại xoay quanh từ Trải nghiệm\Kinh nghiệm (Experience) để hoạt động. Truyền thống này vốn có xuất xứ từ Dewey. Nay cũng đã quá trăm năm.
Một nghiên cứu của Edgar Dale cho thấy với các “học liệu” khác nhau, sự trải nghiệm của người học cũng rất khác biệt, và đạt được hiệu quả giáo dục theo nhiều mức độ không hề giống nhau, phân bổ theo dạng thức hình nón (Gọi là Nón trải nghiệm Dale):
Theo đó, những hoạt động học tập nghèo trải nghiệm gồm đọc chữ, nghe, xem hình tĩnh; những hoạt động giàu trải nghiệm gồm tham gia các tình huống bài học cộng tác trong lớp, trực tiếp thực hành, tham gia tình huống giả lập thực tiễn, và các kinh nghiệm trực tiếp có chủ đích (làm thật).
Dựa theo thang trí năng của Bloom, các mức độ trải nghiệm thấp như đọc, nghe, xem chỉ giúp người học đạt được các mức độ thấp của trí năng từ biết đến hiểu; chỉ có các bài học giàu trải nghiệm mới giúp người học đạt được các mức trí năng cao hơn như áp dụng, phân tích, tổng hợp và đánh giá.
Ứng dụng dễ thấy nhất của Nón Trải nghiệm Dale là dùng cho thiết kế các bài giảng: hãy đưa người học vào các tình huống giàu trải nghiệm. Sử dụng các bài tập tình huống, các trò chơi có chủ đích, các hoạt động kích não và thảo luận, các bài tập lớn thực hành trực tiếp trong phòng lab, và trực tiếp tham gia vào dự án. Sử dụng các bài toán thật và lôi người học vào các trải nghiệm trực tiếp sẽ giúp việc học có ý nghĩa nhất, hiệu năng nhất.
Bài liên quan:
Kinh nghiệm vừa có nghĩa là làm thử, vừa có nghĩa là kinh qua.
Khi một hoạt động được duy trì để biến thành sự kinh qua các hệ quả, khi sự thay đổi do hành động đem lại được phản ánh ngược trở lại để biến thành một sư thay đổi ở bên trong chúng ta, khi ấy tình trạng liên tục thay đổi sẽ chất đầy ý nghĩa.
Một lượng nhỏ kinh nghiệm còn tốt hơn cả một tấn lí thuyết đơn giản chỉ bởi vì chỉ có trong kinh nghiệm thì lí thuyết mới có được ý nghĩa sống động và có thể kiểm chứng. Một kinh nghiệm giản đơn, dù là một kinh nghiệm vô cùng tầm thường, cũng có thể sinh ra và chuyên chở mọi lí thuyết (hoặc nội dung trí tuệ), song một lí thuyết mà tách rời khỏi một kinh nghiệm thì dứt khoát không thể lĩnh hội được, ngay cả xét nó là lí thuyết.
Không có kinh nghiệm nào có ý nghĩa lại có thể tồn tại mà không có yếu tố nào đó của tư tưởng.
Tư duy tức là nỗ lực chủ tâm nhằm phát hiện các mối liên hệ cụ thể giữa điều chúng ta làm và hệ quả của việc làm đó, sao cho hai quá trình đó trở nên liên tục.
Người ta chỉ hoàn toàn biết chắc chắn điều gì đó khi nó đã được kết thúc, đã được hoàn thành.
Tư duy xuất hiện cùng với sự can dự vào các tình huống vẫn còn đang diễn ra và chưa hoàn thành.
Bởi chưng chúng ta không sống trong một thế giới mà mọi thứ đều được an bài và kết thúc, mà chúng ta sống trong một thế giới đang tiến triển liên tục, và công việc chính của chúng ta trong thế giưới đó bao giờ cũng mang tính chất tương lai và hồi tưởng – và cả mọi tri thức xét như để phân biệt với tư duy, bao giờ cũng là sự hồi tưởng – có giá trị ở chỗ nó đem lại sự vững chắc, an toàn và phong phú cho những mối quan hệ của chúng ta với tương lai.
Trích ra từ Dân chủ và Giáo dục.
Lâu lâu trên blog Tạp Chí Lập Trình mới lại có một bài hút khách như vậy. Anh bạn Mê Kim Dung đã có những phân tích khá sắc sảo về tính đơn giản của các thiết kế trong các sản phẩm công nghệ hiện đại.
Nguyên lí về sự đơn giản (Simplicity) được nhắc đến từ rất lâu. Ngay từ đầu thập kỉ trước, KISS (“Keep it Short and Simple”, hay “Keep It Simple, Stupid!”) đã là một nguyên lí căn bản của Extreme Programming, và của cả OSS (được đề cập đến trong kinh điển “The Cathedral and the Bazaar“).
Câu hỏi về “tại sao” được trả lời rất thuyết phục. Nhưng đến cái phần này thì mới ngại: HOW? Đặc biệt với các bạn làm phần mềm vốn quen với lối làm việc kiểu tuần tự Phân tích>Thiết kế>Mã hóa>Kiểm thử>Đóng gói.
Trong bài có nhắc tới một thống kê của Standish:
“Thống kê cho thấy trong một hệ thống thông thường có đến 45% số lượng chức năng không bao giờ dùng đến, 35% ít khi dùng, chỉ có 20% là thường sử dụng. Vậy đừng lo việc lược bớt chức năng sẽ làm phần mềm của bạn không đáp ứng được yêu cầu người sử dụng. Thực tế, nhiều chức năng chỉ làm đội chi phí và thêm bối rối cho phía khách hàng mà thôi.”
Tuy vậy, làm sao để cắt đi cái 45%+35% kia là cả một câu chuyện dài trong ngành phần mềm, cho đến giờ vẫn còn là vấn đề nổi cộm. Hơn thế, làm sao để có được một thiết kế cho phép việc đó (tức là cắt bỏ đi những cái dư thừa), làm sao để luôn giữ cho thiết kế thật đơn giản? Đó cũng là câu chuyện dài không kém. Vì nó động tới sự kiên trì và đòi hỏi nỗ lực để đạt được một trình độ kĩ năng nhất định.
Tôi có gợi ý cho bạn đọc bài này nhé: Go Agile 😉
Tiện đây xin chia sẻ hai tài liệu thuyết trình ngắn của tôi, một cái về Simple Design, một practice không thể thiếu của các nhà phát triển linh hoạt; một cái về nguyên lí tương đồng giữa Agile và Phần mềm Tự do Mã mở (FOSS) hòng cung cấp thêm một một vài ý tưởng để hiện thực hóa cái How ở trên.
Về Simple Design:
Về so sánh giữa Agile và FOSS, trong đó có nhiều quan điểm được nhắc lại trong bài viết của Mê Kim Dung:
Trong bài một tôi đã trình bày cách thức dùng giấy dán để quản lí công việc cá nhân. Ở bài hai, tôi đã lấy ví dụ về một công cụ quản lí trực tuyến hỗ trợ làm việc di động. Ở bài này tôi xin trình bày một ý tưởng đơn giản khác mà một số người thấy có vẻ “tiện hơn” để làm personal kanban. Các bước thực hiện khá đơn giản:
Một kanban trên desktop có thể sẽ trông như thế này:
Kanban trên Desktop
Ở đây tôi dùng phần mềm Stickies trên Windows để làm ví dụ.
Nếu bạn là coder, có thể bạn sẽ thích một cái desktop kiểu như vậy. Vì nó sạch sẽ, muốn ẩn đi rất dễ dàng. Hơn thế, nếu bạn dán trên desktop, tức là bạn không thể mang cái kanban theo (trừ khi công ty cho phép bạn remote control). Điều này giúp cho coder có thể “ngắt kết nối” với chuyện công việc sau khi rời khỏi nơi làm việc; tạm quên đi để nạp lại năng lượng cho ngày code tiếp theo.
Với kanban kiểu này, bạn vừa có được sự đơn giản, dễ dàng và trông analog như giấy dán; lại tiết kiệm và dễ làm, cho những người không thích giấy tờ, ghi ghi , chép chép.
Tới đây tôi xin dừng vệt bài về personal kanban theo hướng công cụ. Có thể tôi sẽ quay trở lại với các khía cạnh khác của chủ đề thú vị này.
Lời cuối, xin được nhắc lại cái ý quan trọng này trong Tuyên ngôn Agile:
“Cá nhân và tương tác hơn là quy trình và công cụ”. Personal kanban là công cụ, kể cả có lí thuyết Lean hỗ trợ thì độ nó cũng không quyết định được hiệu quả công việc hằng ngày của bạn. Nếu biết dùng một cách hữu hiệu, nó sẽ giúp ích; nếu không, nó chỉ làm phiền ta thêm thôi. Có người bảo càng ít công cụ càng dễ tự do. Cũng có ý đúng đấy 🙂
