“In Iowa today, Secretary of Education Arne Duncan unveiled the Obama administration’s new vocational education plan. The president proposes to revise the Carl D. Perkins Career and Technical Education Act by investing an additional $1 billion to increase partnerships between high schools, colleges and employers, with the goal of directing students toward high-need industries such as engineering and healthcare.”

Giá mà có một tỉ đồng cho việc kết nối nhà trường + các doanh nghiệp phần mềm thôi nhỉ, ra khối trò hay 🙂

Fulltext: The Future of Vocational Education

Theo một khảo cứu do Quỹ Bill & Melinda Gates năm 2006 tài trợ, khoảng 1/3 học sinh rời trường trung học mà không có bằng. Nghiên cứu này đã được dùng như là dữ liệu quan trọng để kí giả Nathan Thornburgh gióng lên hồi chuông cảnh tỉnh nước Mĩ trong bài viết “Quốc gia Bỏ học” trên tờ Time cùng năm ấy.

Có chi tiết đáng quan tâm ở nghiên cứu này là những lí do khiến học sinh bỏ học:

1.  do lớp học không thú vị
2. nghỉ học nhiều, không theo kịp
3. do sinh viên được tự do quá, thiếu quy tắc
4. bỏ học vì trượt
5. nghỉ học để kiếm tiền
6. không được động viên để làm việc chăm chỉ

Ảnh: Boston.com

Một báo cáo khác đăng trên trang online của The Sydney Morning Herald cho thấy chỉ có chưa đến 1/3 số sinh viên hoàn tất được khóa học nghề nghiệp (vocational training). Họ dự đoán nguyên nhân chính nằm ở chỗ có một khoảng cách quá lớn giữa kì vọng của sinh viên và sự đáp ứng của nhà trường. Báo cáo đề nghị cần phải có ‘võ’ để gia tăng độ hài lòng của sinh viên.

Như thế chứng tỏ Tây bỏ học  “hơi bị nhiều”, chả giống Việt Nam tí nào. Hầu như bạn sẽ chẳng thể có được chỉ 10% bỏ học chứ đừng nói đến 1/3 hay 2/3 như Tây (con số chính thống năm 2010-2011, rơi vào khoảng dưới 5%). Học sinh sẽ đi hết các niên khóa, và cuối cùng sẽ được cấp bằng. Giới trẻ sẽ tiêu xài hết thời gian cấp phép mà không phải lo ngại mình rơi vào trạng thái “vô học” như ở xứ Tây. Hay là nền giáo dục của ta vượt trội so với Mĩ\Úc?

Một chi tiết thú vị khác, trong hội nghị lãnh đạo Aptech Việt nam vừa diễn ra tại Đà Nẵng, một quan chức của Aptech Ấn Độ dẫn một khảo sát thị trường của McKinsey năm 2012, cho biết có độ vênh khá lớn giữa lí do bỏ học của sinh viên với lí giải của các đơn vị đào tạo về lí do bỏ học của sinh viên. Khoảng 39% nhà cung cấp được hỏi cho rằng sinh viên bỏ học chủ yếu là vì khó, trong khi chỉ 9% số sinh viên được hỏi xác nhận lí do bỏ học vì Khó. Đúng là “mỗi người một phách”!

Liệu mình có học được gì từ những dữ liệu gì trên đây không nhỉ?

Trong bài “Cá nhân và tương tác” nhân lúc suy tưởng về “Agile Education“, tôi từng viết

“Công cụ chỉ là công cụ. Nó chỉ cho hiệu quả tương ứng với quy trình, nội dung và phương pháp (và xa hơn nữa là định hướng, triết lí). Việc thay cái bảng bằng trình chiếu PowerPoint và máy chiếu không giải quyết được vấn đề chất lượng nào.”

Mới đây nhà giáo Phạm Toàn có đề cập tới mấy cái chuyện công cụ trong bài viết trên báo Lao Động số Tết:

“Một máy chiếu overhead thực chất có khi cũng chỉ ngang bằng cái bảng cho giáo viên đỡ bẩn vì bụi phấn, để giáo viên càng thêm thì giờ thao thao bất tuyệt vì đỡ công đi lại xóa bảng và viết bảng.

Một máy chiếu dùng công cụ powerpoint để giảng bài bằng các slide soạn sẵn hoặc dùng những đoạn phim minh họa có khi càng làm cho học sinh hết cơ hội suy nghĩ. Đúng thế, vì kết luận nằm sẵn ở slide cuối cùng chắc hẳn cũng là kết luận định sẵn trong đầu người rao giảng – nhờ thiết bị dạy học hiện đại mà có được một sự áp đặt ngọt ngào, mềm mại như quả đấm thép bọc nhung.”

Điều này nhắc nhở một số người chớ có lòe bịp thiên hạ và  chính mình về sức mạnh vạn năng của công nghệ: cứ áp dụng đồ công nghệ mới vào giáo dục là có thể nâng cao ngay chất lượng giáo dục, mua cái máy tính và nội dung tiên tiến là có thể đưa nền giáo dục tiến ngay lên hiện đại, cứ gắn lấy một cái mác ‘hot’ nào đó là thành hiện đại. Hiện đại hóa nằm ở tư duy và cách làm chứ không phải ở cái máy tính hay cái bảng trắng.

Cách làm ấy là gì, là  “thời của hoạt động”, là “học trò tự tìm lấy tri thức, tự mở mang trí tuệ của mình”.

Cái điều thứ 2 trùng với định hướng “khả năng tự học hơn là điểm số và bằng cấp” trong agile education. Thành tích học tập phải được đo bằng năng lực học trò tự học được hay không trong lĩnh vực (chuyên sâu hoặc phổ thông) của mình, chỉ có bồi dưỡng năng lực học tập tự định hướng mới có thể giúp học trò tự vươn lên chiếm lấy tri thức cho chính mình.

From: T

To: Các nhà giáo

Message: Tránh xa Powerpoint ra, càng nhiều càng tốt 😀

Đọc được bài báo cũ từ 2011 trên PC World VN, tôi đoán là nhân dịp tổ chức hội thảo kiểm thử và tự động hóa VISTACON,  có mấy nhận định của hai “đại ca” mà mình yêu mến khi học testing: GS Kaner và ông Hacket. Đáng tiếc là  những nhận định này đều là những ngộ nhận thường gặp khi thảo luận về Agile:

1.”Một trong những yêu cầu tiên quyết trong dự án PTPMLH là các thành viên tham gia phải có trình độ cao và tương đối cân bằng, có tinh thần làm việc tích cực và kỷ luật cá nhân cao để đáp ứng nhu cầu liên tục tự sáng tạo và cải tiến”

— Nhận định kiểu này nếu xuất hiện từ 1995 thì còn được nhiều người ủng hộ, vì thiếu thông tin, cũng vì khi đó XP đang phổ biến, mà tư tưởng XP thì cái gì cũng extreme, nên dễ gây ngộ nhận.

Thực tế là Agile không có khuyến cáo nào cản trở team hỗn tạp, gồm đủ trình độ làm việc tốt với nhau. Không những thế Agile\Lean còn hỗ trợ mạnh mẽ cho việc học tập. Một trong những chính sách bắt buộc mà Joe Justice ở WIKISPEED dùng để phát triển đội ngũ của mình là ghép cặp nhân viên: một nhân viên học việc sẽ cùng làm việc với một nhân viên già nghề hơn, chỉ một thời gian ngắn họ sẽ thạo nghề và bắt đầu có đóng góp vào thành quả chung của nhóm. Một team Agile không cần toàn siêu nhân! Ken Schwaber nói “Scrum is for idiots”. Làm gì mà phải yêu cầu trình độ cao!?

2. “Những hướng phát triển sai sẽ tiêu tốn nguồn lực của dự án, nhất là quỹ thời gian. Theo phương pháp này, thường phải đợi đến khi kết thúc các chu kỳ nhỏ mới xác định được hướng phát triển có phù hợp không. Do đó, nếu phải tiêu tốn thời gian liên lạc giữa nhóm phát triển gia công offshore và khách hàng thì dự án kéo lùi tiến độ. Trong thực tế, nếu khách hàng ở nước ngoài thì quá trình liên lạc rất khó khăn do khác biệt địa lý và múi giờ. Khi đó, phương pháp PTPMLH sẽ là không hợp lý”

— Thực tế là phân đoạn trong Agile ngắn nên dễ dàng phát hiện nếu hướng đi có sai và dễ dàng điều chỉnh để quay lại đường đúng đắn.  Một phương án hoạch định dài hạn kiểu prescriptive mới rủi ro hơn trong dự đoán. Xem các bài học thất bại nhãn tiền ở đây, và ở đây. Về nỗi lo sợ lệch múi giờ và đa văn hóa, rõ ràng đó là khó khăn. Nhưng làm phương pháp gì thì cũng gặp phải khó khăn kiểu ấy. Điều quan trọng là agile team vẫn có thể vượt qua được để cán đích. Hãy xem đội Xebia, họ có đội phân tán trên bốn châu lục, thực hiện trên quy mô lớn mà vẫn thành công với năng suất cực cao. Trong sprint ngắn 1 tuần mà còn không biết được đúng hay sai, thì làm sao biết được cái đúng sai của 1 năm hay dài hơn? Còn khi phân tích ROI, tôi không dám chắc là những chi phí cho việc liên lạc\giao tiếp lại là lãng phí. Communication là một chương lớn trong lí thuyết quản lí dự án. Chỉ có một nhà quản lí tồi mới không bỏ nỗ lực và chi phí thích đáng cho communication.

3. “Các chuyên gia trong lĩnh vực PM cũng đồng ý rằng PTPMLH thường khó mở rộng quy mô, không phù hợp với các dự án PM lớn có nhiều nhân lực.” 

Lời này là của nhà báo “gắp chữ bỏ mồm chuyên gia” rồi. Làm gì có chuyện các chuyên gia đều đồng ý thế. Nếu tính chỉ ba vị trong bài báo là GS Kaner, GS Trần, và Mr. Hacket thì có khi đúng là họ đồng ý thật. Nhưng đó là mới chỉ có 3 người là chuyên gia thôi. Nhưng họ đều có background là testing, perspective của họ còn lâu mới tương đồng với phần nhiều những chuyên gia phát triển phần mềm, phát triển sản phẩm và các “chuyên gia phần mềm” khác.

Thực tế là các ‘sách’ về Scaling Agile (xem Bas Vodde, Mike Cohn, Hendrik Kniberg, Jeff Sutherland và Ken Schwaber ..) đã có từ hơn một thập kỉ, nay không có gì là bí mật cả. Ngay cả cái đội Xebia lấy ví dụ ở trên có lúc lên đến 500 người, dự án như thế đã được gọi là đủ lớn chưa? Hay như team mới nổi WIKISPEED, vận hành theo Agile, đã có ở gần (hay trên, tôi chưa kịp cập nhật) 20 thành phố trên thế giới, vẫn cộng tác tốt với nhau.

Những kĩ thuật scaling nay trở thành cơ bản, để Agile không những phát huy tối đa năng lực cho các nhóm nhỏ, nó còn có thể giúp các nhóm lớn đạt hiệu suất cao hơn nhiều.

Năm 2011, vẫn có những nhận định ngô nghê như vậy, có vẻ như vẫn còn mấy người trong giới software testing vẫn thích đứng từ xa, không cùng hội cùng thuyền với “bọn” development. Là do không chịu học, hay thích nói lấy được, hay nhà báo trích dẫn sai?

Thấy bài này đăng trên mục “Kinh doanh – Giải pháp”. TƯ VẤN KIỂU NÀY THÌ CHẾT!

_____________________________________________

Dễ cải tiến…

Đa số các phương pháp PTPMLH đều nhắm đến tối thiểu rủi ro bằng cách phát triển phần mềm (PM) trong thời gian ngắn, gọi là các bước lặp. Mỗi bước lặp giống như một dự án PM thu nhỏ, bao gồm tất cả các tác vụ cần thiết để cho ra nâng cấp. Do mức độ tự do sáng tạo cao trong từng bước lặp, kết quả thu được có thể rất khác biệt. Điều này tùy thuộc vào định hướng phát triển xác định tại đầu mỗi bước lặp, và những chuẩn mực yêu cầu (requirements) nhất định được phía khách hàng hoặc chính nhóm phát triển đặt ra tại thời điểm thành lập dự án.

Theo giả thiết trong các phương pháp phát triển PM truyền thống (mà tiêu biểu là mô hình thác đổ – waterfall), các yêu cầu ban đầu thường ít thay đổi so trong suốt quá trình phát triển và sử dụng. Tuy nhiên, trên thực tế – nhất là môi trường ứng dụng Internet – thì các yêu cầu thay đổi rất thường xuyên. Từ đó có thể ảnh hưởng đến chất lượng và tiến độ công việc, thậm chí có khi phải thiết kế lại toàn bộ cấu trúc PM cho phù hợp với yêu cầu mới. Ở giai đoạn Web 2.0, các ứng dụng Internet cũng phải liên tục thay đổi để thích ứng với nhu cầu chia sẻ thông tin đa dạng của cộng đồng sử dụng. Đó cũng chính là lý do khiến mô hình PTPMLH đang ngày một phổ biến, do khả năng thay đổi yêu cầu mang tính tiến hóa.

Một lĩnh vực khác cũng có tiềm năng rất lớn để ứng dụng cách quản lý dự án PTPMLH là ngành kiểm thử. Dự án kiểm thử thường được thiết kế làm nhiều cấp hay nhiều giai đoạn khác nhau. Cấu trúc dự án gắn liền với cấu trúc thiết kế của PM được kiểm thử. Việc ứng dụng khái niệm “linh hoạt” trong từng giai đoạn sẽ cho phép đơn vị kiểm thử tự kiểm tra và cải tiến tính năng của hệ thống kiểm thử nhanh chóng. Xa hơn nữa, quá trình cải tiến liên tục qua các bước lặp giúp các công ty thiết lập hệ thống PM kiểm thử tự động với cơ sở dữ liệu đa dạng. Từ đó, thời gian và công sức thực hiện dự án kiểm thử sẽ giảm bớt….

“Phương pháp PTPMLH chỉ phát huy tác dụng tốt nhất đối với các dự án yêu cầu nhóm nhân lực không lớn, và đặc biệt thích hợp để phát triển ứng dụng trên Internet”.

… nhưng dễ phí phạm tài nguyên

Không có phương pháp nào luôn tối ưu. Một trong những yêu cầu tiên quyết trong dự án PTPMLH là các thành viên tham gia phải có trình độ cao và tương đối cân bằng, có tinh thần làm việc tích cực và kỷ luật cá nhân cao để đáp ứng nhu cầu liên tục tự sáng tạo và cải tiến. Ngoài ra, mô hình nhóm gia công không cùng vị trí địa lý với chủ dự án (offshore) thường yêu cầu phải có một đại diện khách hàng có mặt cùng địa điểm với nhóm phát triển. Người này có thể kịp thời giải đáp các thắc mắc ngay khi có vấn đề phát sinh và duy trì PM phát triển đúng hướng. Nếu tốc độ sáng tạo nhanh nhưng phản hồi chậm cũng dẫn tới phí phạm tài nguyên dự án và có thể chuyển sang hướng phát triển không phù hợp.

Ông Cem Kaner, Giáo sư ngành Công nghệ PM – Học viện Kỹ thuật Florida ở Mỹ, cho rằng ưu điểm lớn nhất của phương pháp PTPMLH là khả năng đưa ra và theo đuổi nhiều hướng đi trong quá trình phát triển. Nhưng đây cũng chính là khuyết điểm của nó. “Những hướng phát triển sai sẽ tiêu tốn nguồn lực của dự án, nhất là quỹ thời gian. Theo phương pháp này, thường phải đợi đến khi kết thúc các chu kỳ nhỏ mới xác định được hướng phát triển có phù hợp không. Do đó, nếu phải tiêu tốn thời gian liên lạc giữa nhóm phát triển gia công offshore và khách hàng thì dự án kéo lùi tiến độ. Trong thực tế, nếu khách hàng ở nước ngoài thì quá trình liên lạc rất khó khăn do khác biệt địa lý và múi giờ. Khi đó, phương pháp PTPMLH sẽ là không hợp lý”.

Ông Cem Kaner, Giáo sư ngành công nghệ phần mềm

Khó áp dụng trong dự án lớn?

Các chuyên gia trong lĩnh vực PM cũng đồng ý rằng PTPMLH thường khó mở rộng quy mô, không phù hợp với các dự án PM lớn có nhiều nhân lực. Các dự án lớn thường được chia làm nhiều phần nhỏ, cấu trúc tương đối chặt chẽ và không có chỗ cho sai sót. Các nhóm phát triển cần thống nhất rất cao về định hướng và hầu như không còn nhiều chỗ cho sáng tạo, dù nó cũng cần qua nhiều thảo luận để đưa vào ứng dụng thực tế. Với các dự án này, các nhóm gia công nếu có sẽ là một phần của kiến trúc lớn, dưới sự kiểm soát chặt chẽ khách hàng.

Những điểm nói trên đi ngược với bản chất của PTPMLH. Sẽ rất khó quản lý khi dự án đạt quy mô vài ngàn nhân lực. Do đó, hiện tại phương pháp PTPMLH được áp dụng chủ yếu cho các dự án tầm trung trở xuống, ở các mảng ứng dụng web, ứng dụng trên di động (web applications, phone applications) và các dự án gia công kiểm thử trong và ngoài nước.

Khắc phục điểm yếu của PTPMLH Michael Hackett, Phó tổng Giám đốc Công ty Kiểm thử LogiGear: “Các nhóm gia công từ xa (offshore) muốn áp dụng PTPMLH cần có chuyên môn, kinh nghiệm, khả năng giao tiếp tốt, sự hiểu biết liên văn hóa, sự tin tưởng thông hiểu lẫn nhau giữa các thành viên và giữa các nhóm với nhau”. Quang Trần, Giáo sư CNTT, Đại học Quốc tế RMIT Việt Nam: “Yêu cầu đối với đại diện khách hàng làm việc chung với nhóm phát triển PM là khá cao. Đây phải là một người có đầy đủ kiến thức chuyên môn, hiểu rõ định hướng ban đầu của dự án, và quan trọng nhất là phải có đủ thẩm quyền đưa ra quyết định. Trong mô hình offshore, nếu đại diện dự án không thể theo sát tại chỗ với nhóm phát triển thì cần trực trong một khoảng thời gian ấn định trong ngày, giao tiếp qua mail, chat, VoIP(thoại trên nền Internet), điện thoại… để giải đáp thắc mắc tức thì”.

Bản chất của việc ứng dụng Scrum là tạo ra sự thay đổi trong cung cách làm việc.

ScrumAlliance có tôn chỉ “Transforming the world of work” – thay đổi cách làm việc.

Ken Schwaber, Jeff Sutherland, hay Mike Cohn ít khi dùng từ Agile Adoption (tức là dùng Agile như công cụ) mà là “Agile Transition” hay “Agile Transformation” – sự chuyển đổi mang tính căn cơ, dẫn đến sự thay đổi về văn hóa công ty. Mà việc này thì vượt ra khỏi phạm vi một vài practices, vài methods giúp ai đó năng suất hơn.

Agile cổ súy “thích ứng với thay đổi”, “sống chung với thay đổi” chứ không “quản lí sự thay đổi”.

Để đạt được kết quả như mong muốn, các lãnh đạo Agile phải biết lợi dụng sự thay đổi cho mục tiêu của công ty, định hướng nó để không những không cản trở mà còn nâng đỡ để đạt mục tiêu tốt hơn.

Đó là lí do tại sao Ken, Jeff hay Mike khuyến cáo mọi người nên đọc John Kotter.

Hôm nay tôi xin giới thiệu với các bạn cuốn sách hữu ích mà tôi ưa thích của vị GS nổi tiếng trường Havard này: Dẫn dắt sự thay đổi.

PS. Nhân tiện về chủ đề này, mời bạn đọc thêm vài dòng một bài biết trên trang nhà của Trường doanh Nhân Pace; chả liên quan gì đến Agile, nhưng cũng không vì thế mà xa lạ:

“DẪN DẮT SỰ THAY ĐỔI” – NĂNG LỰC “VÀNG” CHO THỜI KHỦNG HOẢNG

Trong phương thức sản xuất hàng loạt, nhà sản xuất dựa trên khảo sát thị trường rồi dự đoán sản lượng rồi tiến hành sản xuất, rồi đẩy ra thị trường tiêu thụ.

Trước khi lượng hàng này tiêu thụ hết, chúng nằm ở chỗ nào đấy, thường là trên đường đi hoặc trong kho lưu trữ. Vì thế tồn kho lớn.

Trong kinh doanh, tồn kho là nỗi kinh hãi của nhà sản xuất khi thị trường đi xuống hoặc biến động. Nếu như khách không mua nữa, toàn bộ hàng hóa thành ra “của nợ”. Tồn kho khi đó là dấu hiệu rõ ràng của lỗ to, và thậm chí .. phá sản.

Thế thì làm sao để tránh tồn kho lớn? Có ít nhất hai cách:

1. Làm tốt khâu dự báo, để có số lượng sản xuất khớp với lượng tiêu thụ. Đồng thời phải có hệ thống tiêu thụ tốt để làm ra hao biêu tiêu thụ hết bấy nhiêu.

2. Đừng sản xuất hàng loạt nữa, để giảm thiểu tồn kho ngay từ đầu

Cách thứ nhất thì đòi hỏi phải có hệ thống dự báo tốt (dữ liệu, chuyên gia). Nhưng điều này thường là bất khả khi hệ thống (thị trường) phức tạp (complex). Khi đó, mọi dự đoán dài hạn thường trật lất. Đặc biệt trong hoàn cảnh thị trường luôn biến động (như thời kì chúng ta đang sống đây chẳng hạn).

Cách thứ hai loại bỏ tư duy hướng-nhà-sản-xuất (manufacture-centric) để cho khách hàng quyết định lượng hàng cần sản xuất (customer-centric). Có bao nhiêu đơn đợt đặt hàng thì sản xuất bấy nhiêu, sẽ không tồn kho.

Vận hành theo kiểu thứ nhất, ta có một hệ thống đẩy (Push System); theo kiểu thứ hai, ta có một hệ thống kéo (Pull system).

***

Thử xem một ví dụ về hệ thống kéo trong một nhóm phát triển phần mềm sử dụng Scrum và một bảng công việc kiểu Kanban.

Như bạn đã biết, các yêu cầu phần mềm được đặt trong một danh sách ưu tiên: Product Backlog, người được ưu tiên là Product Owner, tức là người thuộc “phe khách hàng”

Scrum Framework, ảnh: Bas Vodde et al.

Nhóm Scrum sẽ căn cứ năng lực hiện tại của mình (capacity) để lựa chọn số lượng yêu cầu  cho phù hợp để đưa vào sản xuất trong một Sprint để có chức năng chạy tốt ở cuối Sprint đó. Tại thời điểm Sơ kết Sprint (Sprint Review), chức năng đó có thể dùng ngay được (potentially shippable increment). Vậy là không hề có chức năng nào là “tồn kho”. Khách hàng (PO) trực tiếp đặt hàng, với số lượng vừa phải để nhóm Scrum sản xuất.

Trong cách làm truyền thống, toàn bộ các yêu cầu sẽ được “giao” cho nhóm sản xuất, làm xong tất cả các chức năng rồi mới đóng gọi lại (trong toàn bộ thời gian phát triển của dự án), tức là khách hàng (thực ra là cấp quản lí) ĐẨY yêu cầu cho đội sản xuất, còn ở đây, đội sản xuất KÉO các “đơn đặt hàng” từ khách hàng.

Việc KÉO cũng được áp dụng trong công việc nội bộ của đội sản xuất (Development Team). Sau buổi Họp kế hoạch Sprint, các công việc được đặt trong Sprint Backlog. Căn cứ vào yêu cầu công việc và năng lực cá nhân, các developer (có thể có chuyên môn khác nhau: coder, designer, tester …) sẽ KÉO công việc từ SprintBacklog để hoàn thành nhiệm vụ chứ không đợi cấp quản  lý ĐẨY việc cho mình. Nói thêm, vì yêu cầu công việc, các nhân sẽ phải thực hiện việc kéo rất thông mình trong tinh thần cộng tác. Ví dụ như, cả nhóm sẽ phải tạo ra LUỒNG MỘT SẢN PHẨM để cùng nhau kéo các công việc sao cho giải quyết dứt điểm từng yêu cầu (tức là đánh dấu DONE cho nó) trước khi kéo các công việc khác để làm. Để có thể triển khai được luồng một sản phẩm, đội sản xuất phải liên chức năng. Đội liên chức năng có đầy đủ kĩ năng cần thiết để không phải chờ ai (bên ngoài nhóm ) làm xong việc mới đưa ra được chức năng chạy tốt.

Thực tế đã cho thấy, một hệ thống kéo –  một trong những kĩ thuật chủ chốt trong sự thành công của các phương pháp tinh gọn và Agile (như Lean Software Development, Lean Manufacturing, Kanban, Scrum, v.v.), giúp cho các nhóm làm việc đạt hiệu quả cao hơn nhờ tinh giảm được lãng phí, giới hạn luồng công việc (WIP) để đạt được chất lượng cao hơn cho sản phẩm, thích ứng tốt hơn với sự biến động khó lường của môi trường.

Cụ Phạm Toàn, thủ lĩnh của nhóm Cải cách Giáo dục hiện đại Cánh Buồm có gợi ý ba việc nên làm trước trong công cuộc “dời non lấp bể” nền giáo dục nước nhà như sau:

1) Việc một, trước khi đạt tới việc “đi trước một bước”, hãy kiên trì nghiên cứu thay đổi cách học của trẻ em kể từ độ tuổi thấp nhất có thể, nhưng ít nhất cũng phải từ khi các em vào lớp Một.

Xưa nay hễ nghĩ đến Cải cách Giáo dục, người ta thường nghĩ nhiều đến thay đổi mục đích, mục tiêu của Giáo dục hướng vào phục vụ nhiệm vụ chính trị. Phương diện tâm lý học của việc học rất ít được quan tâm nghiên cứu. Nay cần đề cao những công trình  nghiên cứu cách học của trẻ em để từ việc thay đổi cách học này mà chuyển sang nghiên cứu cách nhà giáo tổ chức việc học của trẻ em.

2) Việc hai, công tác thực nghiệm và triển khai rộng dần công việc thực nghiệm, giúp xác định tính đúng đắn của sản phẩm nghiên cứu trong việc một trên đây. Công việc nghiên cứu thực nghiệm này phải mang tính chất tự do và dân chủ.

Tự do, là các nhóm nghiên cứu thi thố tài năng để có sản phẩm mang nặng tính chất địa phương. Ngay dạy Tiếng Việt, giữa Hà Nội và Sài Gòn cũng có thể có cách học khác nhau, chưa nói đến so sánh giữa các thành thị lớn này và những người học ở các miệt vườn xa xôi, các vùng núi cao heo hút.

Dân chủ, là các nhóm nghiên cứu của các trường sư phạm phải được đối xử ngang nhau, cùng chịu những quy chế như nhau, cùng được hưởng kinh phí như nhau.

Mục tiêu giai đoạn làm việc hai này là chọn ra được những bộ sách và chương trình thích hợp hơn cả, có đủ khả năng đem dùng đại trà.

3) Việc ba, sau khi đã xác định được sản phẩm nghiên cứu tốt hơn cả, những sản phẩm (chương trình và sách giáo khoa) đã được trẻ em chấp nhận có khả năng nhân rộng thì sẽ tiến hành huấn luyện mới và huấn luyện lại các nhà giáo đứng lớp vốn được tuyển từ rất nhiều nguồn.

Công việc huấn luyện này cần được coi như là giai đoạn thực nghiệm sư phạm nhờ đã tìm ra được cách học của trẻ em.

Phạm Toàn – “Xoay hướng đình“

Dạy cách học đúng là mấu chốt. Dạy được cách học thì việc học của trẻ em sẽ tự nhiên đâu vào đấy. Bên cạnh đó, cách tiệp cận đúng cho các bước thay đổi nên là thực nghiệm (emprical) – bước đi nhỏ, lấy dữ liệu thực tiễn để xác định các bước đi tiếp theo hợp thực tế; không phải là cứ vẽ ra một viễn cảnh xa vời với những chương trình “khủng” (cả tiền, và thời gian dài khủng khiếp), đem học sinh ra làm chuột bạch, rồi khi phát hiện ra sai hỏng ai lại về nhà nấy, chẳng xi nhê gì (mà xác suất để hỏng là lớn lắm, có nhiều lí do mà ai ai cũng biết nó là gì), chỉ có dân tộc này là không ngóc nên được vì cái ngành trồng người nó cứ ngoi lên được tí lại reset, lên tí rồi lại reset, sau vài lần có khi nó không những không về mo mà còn “liên tục xuyên đáy” – nói theo kiểu Thị trường Chứng khoán :(. “Nước bốn ngàn năm vẫn trẻ con” là vì lẽ này chăng?

Ảnh chỉ mang tính chất minh họa

***

PS. Tôi đã nói khá nhiều về meta-cognition, về khả năng tự học (ở khối sau phổ thông) trong các diễn đàn khác nhau (ví dụ: ở đây). Một trong những cốt lõi tôi đề xuất trong thực hành giáo dục  là:

” Năng lực tự học hơn là điểm số và bằng cấp “.

Trui rèn năng lực học tự định hướng, hướng đến một việc học tự giác, tự động –  là mấu chốt! Và việc này cần phải làm sớm càng tốt, như cụ Toàn đề xuất là nên ngay từ lớp Một. Các cấp tiếp theo sẽ có những đặc trưng và yêu cầu quan trọng hơn về học-tự-định-hướng. Nhưng cần phải bắt đầu “ngay, và luôn”! Khi đó, nhà giáo sẽ phải dứt điểm từ bỏ lối dạy kiến thức kiểu “truyền thụ thông tin”, thầy nói-trò nghe, thầy đọc-trò chép (hay copy); để chuyển sang việc trợ giúp và bồi dưỡng năng lực tự học cho người học; tổ chức việc học (thiết kế) để sinh viên tự chiếm lĩnh lấy tri thức và kĩ năng.

Hôm thứ bảy vừa qua (19-1) chương trình Agile4U bắt đầu khởi động với buổi nói chuyện của Tấn ở FPT University (FU) Hòa Lạc về “Đường vào Agile”.

Lọt thỏm trong không gian có phần quê kiểng của Hòa Lạc, một địa điểm cách xa chốn ồn ào của Hà Nội khoảng 40 cây số, Đại học FPT tuy còn mới đang trong quá trình hoàn thiện nhưng đã khá khang trang và có phong cách. Các bạn sinh viên ở đây có phần thuận lợi khi trải nghiệm một nơi khá cách biệt để tĩnh tâm suy nghĩ và học tập.  Xây dựng theo mô hình campus, rất có thể quần thể FU HL sẽ sớm là ‘điển hình’ cho các trường khác ‘noi theo’.

AgileTour đã đến FU HCM từ hai năm trước, năm ngoái ScrumDay tại FU Mỹ Đình cũng đã tạo một hiệu ứng tốt cho cộng đồng. Còn Tấn và đồng bọn đã xây dựng không khí Scrum từ trước đó rất lâu tại FPT-Aptech, một đơn vị thành viên của khối Giáo dục của FPT. Nay thì Agile sẽ tiếp tục lan rộng trong cung cách làm việc, học tập, giảng dạy của nhiều đơn vị và cá nhân  trong khối FptEducation. Mới cuối tuần trước thôi, Văn phòng FPT Polytechnic Vietnam đã cùng  HanoiScrum nói chuyện về phong cách quản lí kiểu Scrum. Tại đây lãnh đạo cao cấp nhất đã bắt đầu nhận ra các giá trị to lớn của một lý thuyết quản lí kiểu mới, giúp cho một tổ chức còn non trẻ có thể có những bước đột phá nhưng vững chắc trong business của tổ chức. Họ đã quyết định sẽ dùng Scrum có phần lớn các dự án của mình: phát triển hệ thống thông tin, quản lí các dự án phi-tin …

Agile4U sẽ hứa hẹn là một chương trình đinh trong năm nay của HanoiScrum, với một Board Member mới: Nguyễn Văn Hiển của FU.

Lúc chưa bắt đầu, những người đến sớm ‘chit chat’ với nhau

Nội dung được trình bày theo phong cách “Agile for Dummies”

Gánh hát rong: Hiển, Tấn, Khoa, Tú.

Mời bạn xem thêm Tài liệu thuyết trình:

The WordPress.com stats helper monkeys prepared a 2012 annual report for this blog.

Here’s an excerpt:

600 people reached the top of Mt. Everest in 2012. This blog got about 12,000 views in 2012. If every person who reached the top of Mt. Everest viewed this blog, it would have taken 20 years to get that many views.

Click here to see the complete report.

Trong khảo sát về hiện trạng sử dụng Agile trên thế giới năm 2011 của VersionOne, bên cạnh các dữ liệu hết sức “có lợi” cho người ủng hộ Agile, có những dữ liệu cực kì đáng nghi ngại cho những người mới chân ướt chân ráo vào lĩnh vực mới mẻ này.

Quan sát bảng dưới đây:

Nhìn vào bảng trên, có một sự thật ẩn sau đó là:

Chỉ 16% số người được hỏi là thành công mĩ mãn với Agile.

Còn lại 84% vấp phải những rắc rối, hoặc sai lầm, hoặc thất bại thảm hại, kể cả khi chuyển sang Agile.

Làm sao để tránh đây?