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:
- Bạn cần một chương trình giả lập giấy dán trên máy tính (trên Windows, Ubuntu hay MacOS đều có cả).
- Dọn sạch desktop.
- Tạo ba (hay nhiều) cột như các cách làm ở bài trước
Một kanban trên desktop có thể sẽ trông như thế này:
Ở đâ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 🙂
Bài trước tôi đã giới thiệu với các bạn cách tạo lập một personal kanban với đồ rất analog. Bài này tập trung giới thiệu các công cụ kanban trên các thiết bị số: PC, laptop, iPad, smartphone.
Có rất nhiều công cụ giúp bạn tạo được personal kanban, tôi sẽ liệt kê ra một số ở phần 3 của bài này. Để cho dễ dàng, tôi chọn công cụ Trello để tiện giới thiêu cách làm. Trello là một hệ thống mạnh mẽ, dễ sử dụng. Và đặc biệt là nó hỗ trợ nhiều nền tảng. Bạn có thể tạo một kanban trên Trello và bảo trì nó từ PC, laptop hoặc sử dụng iPad hay một smartphone chạy Android. Rất tiện cho những người làm việc phải di chuyển nhiều. Trello dùng rất tốt cho nhóm (nhỏ lớn đều OK) nhưng điều đó không ngăn cản ta có thể dùng cho mục đích cá nhân 😉
Ý đồ là tạo lập một bảng công việc lưu trữ “trên mây”, có thể truy xuất ở mọi nơi, mọi lúc. Như hình dưới đây:
Bài này có ba bần: giới thiệu cách tạo kanban trên Trello bằng hình, sử dụng trên thiết bị di động; và phần cuối liệt kê các công cụ tạo kanban số.
Một: tạo kanban trên Trello
Theo dõi slideshow dưới đây:
Dễ như bỡn nhỉ 😉
Hai: dùng trên thiết bị di động
Lên chợ (Apple Apps Store, hoặc Google Play Store) tải về ứng dụng Trello. Cài vào máy, đăng nhập như trên. Và dùng như trên web.
Trên iPad bạn sẽ có giao diện giống như trên web. Nếu bạn dùng iPhone hoặc smartphone chạy Android thì mỗi màn hình của Trello chỉ chứa một cột. Lướt sang bên cạnh để xem cột tiếp theo. Các thao tác kéo thả và chỉnh sửa thì không có gì khác biệt.
Ảnh chụp màn hình Galaxy Tab 7 Plus
Ba: Các lựa chọn khác
Tôi chỉ lấy Trello làm ví dụ, bạn có thể lựa chọn rất nhiều tool để làm việc này. Quy tắc rất đơn giản: hỏi Mr. Google.
Xin kể ra đây vài cái mà mọi người hay nhắc tên: KanbanFlow, Pomodoro Daisuki, LeanKit, Kanbanery, JIRA, KanbanTool, PearlTrees, pharmaciepourhomme.fr…
Trên “chợ” ứng dụng cho smartphone cũng có rất nhiều. Dùng search engine và tìm kiếm với từ khóa kanban hoặc personal kanban sẽ có đủ “đồ chơi” cho bạn thử.
Bạn thử đi rồi xem cái nào vừa ý, vừa túi tiền thì dùng nhé. Tôi xin miễn bình luận về cái nào là tốt nhất.
Hãy để công nghệ nối dài cánh tay cho bạn, đừng bắt mình phải vác thêm một cánh tay nữa nhé 😉
Trở về từ buổi gặp mặt ScrumCoffee #1, đọc lại bài viết “Hãy tinh gọn trong công việc và cuộc sống” của chủ thớt FU Agile ở Hòa Lạc, Mr. Nguyễn Ngọc Anh, tôi chợt nhớ là phải viết cái gì đó đơn giản để ai đó cũng có thể làm được, giúp phần giảm đi những xì trét vì không thể kham nổi nhiều việc cùng một lúc.
Và đây sẽ là vệt bài về cách tạo ra các bảng công việc cá nhân (Personal Kanban – đây là phương pháp đơn giản lần đầu được để xuất bởi Jim Benson) sử dụng nguyên lí của Lean (tinh gọn) để quản lí công việc cá nhân. Đã có rất nhiều người làm thành công, và tôi mong muốn thật nhiều người thành công hơn nữa.
Ý tưởng rất đơn giản: Giới hạn khối lượng công việc (Limit Work-In-Progress) về khả năng của cá nhân (capacity), trực quan hóa đầu việc, và quản lí công việc theo luồng.
Bài 1 sẽ hướng dẫn bạn dùng mấy tờ giấy dán để làm một Kanban tại phòng làm việc, tại nhà hoặc trong một cuốn sổ ghi chép. Rất analog.
Bài 2 sẽ hướng dẫn bạn dùng một số công cụ số hóa để làm việc, dành cho những người bận rộn và hay làm việc di động
Bài 3 sẽ là một ý tưởng hơi “khùng khùng” một chút dành riêng các bạn lập trình viên
*****
Phần 1: Tạo Personal Kanban với giấy dán
Mời bạn xem hai cái Personal Kanban của hai người sau đây:
Rất dễ làm phải không?
Tạo ra ba cột: Cần làm (ToDo), Đang làm(Doing) và Xong (Done).
Khi có việc cần làm (việc tự nghĩ ra, việc được giao…), ta viết vào tờ giấy dán và đặt vào ToDo trước, phân tích kĩ lưỡng nên làm ngay hay để làm sau. Việc này có bản chất là “lập kế hoạch”, sẽ giúp ta có được trình tự và cách làm công việc có bài bản hơn. Nhiều người bắt tay vào làm ngay việc được giao mà không suy nghĩ, tính toán. Đó không phải là chiến lược tốt. Nếu ta có thể xếp độ ưu tiên theo giá trị (cái nào có giá trị thì làm trước), thì ta có thể mất ít công sức hơn mà làm được nhiều giá trị hơn (sử dụng quy tắc Pareto, 80-20).
Khi quyết định làm việc gì, ta sẽ chuyển công việc sang cột Doing. Có thể ghi ngày giờ bắt đầu làm lên giấy. Giới hạn số lượng thẻ ở cột này (ví dụ 3). Đừng để nhiều, vì nó sẽ khiển bạn phải nhảy từ công việc nọ sang công việc kia (task-switching), là nguồn cơn của thiếu hiệu quả và xì-trét. Con số 3 hay năm tùy thuộc giới hạn khả năng của từng người, chỉ bạn mới biết được. Khi bạn đặt con số 5 và thấy bắt đầu rối tung lên thì chắc là phải giới hạn con số đó xuống 4. Thực hiện trong một tuần rồi đánh giá lại con số đó. Qua một hai tuần ta sẽ có con số hợp lí. Nhưng khi khởi đầu, tôi gợi ý là nên để con số 3.
Khi làm xong việc gì thì đặt nó sang cột Done, có thể ghi ngày giờ kết thúc lên giấy để đánh giá về sau.
Việc đặt một công việc sang cột Done chứ không vứt đi sẽ giúp bạn nhìn thấy được tiến độ công việc, tạo giá trị thúc đẩy bản thân. Đó là giá trị của trực quan hóa (visualization).
Về tờ giấy dán, bạn có thể chọn nhiều màu, dùng nó tùy theo chủ ý. Ví dụ: các việc học tập để giấy xanh, các việc giấy tờ để giấy vàng, các việc liên quan đến khách hàng dùng giấy đỏ v.v. Tùy bạn. Nhưng hãy dùng có chủ ý. Việc này sẽ giúp cho bảng trực quan hơn, có sức sống hơn.
Bạn làm ngay được chứ?
Xin chào đón các góp ý và thảo luận của các bạn. Nếu thành công và có ích, nhắn lại cho tôi nhé 😉
Tiếp theo: Digital personal kanban, Dán Kanban lên desktop
Malcom Knowles: người lớn học tập (khoa nghiên cứu lĩnh vực này gọi là andragogy, đối lập với “sư phạm”- pedagogy tức là daỵ cho trẻ con) theo những nguyên lí quan trọng nhất sau đây:
- Người lớn cần phải được can dự vào quá trình lập kế hoạch và đánh giá kết quả học tập (self-concept).
- Trải nghiệm (Experience – gồm cả những sai sót) cung cấp nền tảng cho các hoạt động học tập.
- Người lớn quan tâm đến những nội dung học tập có liên hệ trực tiếp tới công việc hoặc trong đời tư của họ.
- Người lớn học theo kiểu lấy vấn đề làm trung tâm (problem-centered) hơn là hướng đến nội dung (content-oriented).
Continue reading
Jeff Sutherland yêu cầu bốn đặc điểm tối thiểu nhất của một Product Owner gồm:
- Có hiểu biết rộng (Knowledgeability) – về thị trường, sản phẩm, khách hàng, đối thủ..
- Sẵn sàng (Availability) – một nửa thời gian cho khách hàng, một nửa thời gian cho DevTeam
- Có khả năng ra quyết định (Decidability) – có khả năng đưa ra quyết định cuối cùng về Product Backlog
- Trách nhiệm (Accountability) – biết được mình đang làm vì lí do gì, tối đa hóa lợi ích ra sao cho công ty
Mike Cohn có đưa ra một danh sách khác với năm đặc điểm ABCDE (cho dễ nhớ):
- Sẵn sàng (Available) – như trên
- Thông hiểu nghiệp vụ (Business Savvy) – không hiểu biz thì không thể làm sản phẩm được
- Giao tiếp tốt (Communicative) – vì phải làm việc với đủ dạng các bên hữu quan (từ devteam đến khách hàng, nhà đầu tư v.v.)
- Có thể ra quyết định được (Decisive) – như trên
- Được trao quyền (Empowered) – không được trao quyền thì không ra quyết định được ( tính chất 4)
Ta thấy trong hai danh sách của hai “bố già” Agile, chỉ có hai điều trùng lặp là “Avalibility” và “Decisive”. Nếu PO là bán thời gian (dành rất ít thời gian cho sản phẩm và cho nhóm Scrum), hoặc không có quyền quyết định (phải chờ phê duyệt, hoặc không thể tự mình đưa ra quyết định nào) thì nhóm Scrum sẽ gặp phải khó khăn lớn.
Nhìn bộ “tiêu chuẩn” này, hẳn nhiều người có thể sẽ thấy băn khoăn. Bạn nghĩ sao?
Trong nghề lập trình, thật khó sống nếu thiếu framework (dịch thô là “khung làm việc”). Framework là cái khung với rất nhiều thứ được xây dựng sẵn để tái sử dụng cho từng nhóm chức năng\công việc nhất định. Ví dụ, Java Collection Framework giúp cho việc tạo ra và sử dụng các cấu trúc dữ liệu, một phần cực kì quan trọng của bất kì chương trình nào, trở nên nhẹ nhàng hơn. Nếu ai đã từng lập trình C hay Pascal mà không dùng framework để tạo danh sách liên kết, sẽ thấy được sự tiện lợi (không bàn đến các yếu tố khác) của cái lớp LinkedList trong Java Collection Framework. Gần như không phải làm gì thêm để có thể dùng ngay lớp ấy để tạo danh sách. Trong túi khôn của các lập trình viên, mỗi người thường có vài chục framework như vậy.
Nhưng framework không chỉ giới hạn trong giới lập trình. Tư duy chung của framework có thể áp dụng ở mọi nơi: có một chút lý thuyết hay mô hình về cái gì đó, xây dựng một số công cụ để hiện thực hóa cái mô hình đó để “người dùng” có thể sử dụng luôn để hữu ích trong việc gì đấy. ví dụ, Cynefine framework được dùng để hỗ trợ ra quyết đinh trong những tình huống phức hợp (complex) bao gồm ý tưởng về phân vùng các ngữ cảnh theo độ phức tạp như Đơn giản (Simple), Rắm rối (Complicated), Phức hợp (Complex), Hỗn độn (Chaotic) hay Vô định (Disorder); và một biểu đồ để phân vùng sự việc để hỗ trợ ra quyết định hay hoạch định chiến lược.
Trong các phương pháp luận về Agile Software Development, Scrum được gọi là framework cũng theo cái tư duy tương tự. Nó xây dựng một cái khung với một số “công cụ” dựng sẵn, có thể tái sử dụng ngay để tiết kiệm công sức cho những người muốn ứng dụng tư duy linh hoạt (agile) vào công việc của mình.
Rõ ràng là việc sử dụng framework đã giúp người mới bắt đầu dễ dàng tạo ra giá trị mà không cần phải nhọc công học hỏi lâu. Nếu phải học cách cấu trúc và tạo danh sách liên kết rồi mới dùng cho bài toán cụ thể thì có thể ta sẽ phải mất một ngày[cũng chưa chắc tạo ra cấu trúc dữ liệu tốt], trong khi với hỗ trợ của Java Collection Framework, ta chỉ cần một giờ [mà vẫn có một cấu trúc dữ liệu tương đối tốt]. Đây chính là một cách để đứng trên vài những người khổng lồ.
Tuy vậy, chúng ta sử dụng framework, chứ không tùy biến framework. Mỗi framework ẩn chứa bên trong nó là hàng tá lí thuyết và công sức lao động trí tuệ. Nó có lí do để “không hơn, không kém”. Cho nên việc một người mới toe khi nhìn thấy framework mà đã tính cách tùy biến nó, cắt bớt gia giảm nó thì chỉ có thể gọi bằng cái tên hồ đồ, tùy tiện.
Trong thế giới Agile, có một từ ScrumBut để ám chỉ việc này.
Bạn có thể thành thạo Scrum, rồi biến nó thành cái của riêng công ty bạn (tham khảo mô hình ShuHaRi), và gọi nó bằng một cái tên hoàn toàn khác (như Saleforce, IBM … đã làm ); nhưng nếu đó là lần đầu tiên bạn học cách dùng Scrum, và nghĩ rằng phải chế biến ngay ScrumBut thì thôi xin đừng gọi nó là Scrum nữa, đừng nói “tôi cũng dùng Scrum” nữa, tội nghiệp các bác Ken và Jeff. Vì Scrum nó là phờ-rêm-guấc-kờ.
Tìm kiếm
Sách mới: Tư duy thiết kế cho mọi người
Chuyên mục
- Agile Mindset (150)
- Chuyện đời (22)
- Công nghệ (14)
- Đọc (75)
- Sách (46)
- Giáo dục (200)
- Constructivism (5)
- Học cách học (35)
- Khai phóng Giáo dục (22)
- Tu thân (5)
- Khác (15)
- Lean Startup (17)
- Linh tinh xòe (53)
- Lan man (24)
- Quản trị mới (66)
- COVID19 (9)
- Tài nguyên (2)
- Tri thức và Nhận thức (18)
- Xã hội tri thức (24)
- Tổ chức học tập (20)
Thẻ
36 kế dạy học thụ động (7)
active learning (8)
agile (41)
agile adoption (6)
agilemindset (6)
agile mindset (7)
agile transformation (5)
codegym (36)
constructivism (16)
Cánh Buồm (5)
công nghệ và giáo dục (15)
dạy học (4)
dạy tốt hơn (24)
education (4)
giáo dục (26)
giáo dục khai phóng (7)
growth mindset (5)
HỌC CÁCH HỌC (9)
học (6)
học tập (4)
học tập trải nghiệm (4)
inamori_kazuo (5)
innovation (4)
kanban (6)
khởi nghiệp (5)
lean (14)
lean mindset (4)
lean startup (7)
learning (4)
làm lính thật tốt (21)
MOOC (5)
neomanager (8)
năng suất (5)
PBL (6)
personal kanban (4)
productivity (4)
reflection (5)
scrum (42)
seci (8)
sử kí (5)
thuyết kiến tạo (7)
tích hợp (10)
tản mạn chuyện đọc (10)
tổ chức học tập (7)
được việc (13)