Cá nhân và tương tác hơn là quy trình và công cụ;
Khả năng tự học hơn là điểm số và bằng cấp;
Cộng tác đa phương hơn là tuân thủ khế ước;
Phản hồi với thay đổi hơn là tuân thủ kế hoạch.
Trong khi các điều bên phải vẫn còn nguyên giá trị, chúng tôi ưu tiên hơn cho các điểm ở bên trái.
***
In English:
Individuals and interactions over processes and tools;
Ability of self-directed learning over measurement and certification;
Stakeholder collaboration over constant contract;
Responding to change over following a plan.
That is, while there is value in the items on the right, we value the items on the left more.
Tôi đã từng nhiều lần phải hàm ơn cái trường MIT chưa từng đặt chân đến vì đã sử dụng rất nhiều học liệu của họ cho công việc học tập và giảng dạy của mình. Từ hồi đi học tôi đã rất “mết” cái kho học liệu quý hơn vàng của MIT. Sau này đi dạy, tôi rất thích lấy thiết kế của các khóa học của MIT làm chuẩn mực để tham chiếu cho các đề cương của mình. Sau này, một kho open courseware khác mà tôi cũng thi thoảng tham khảo, tuy không thích lắm, nhưng cũng giúp ích nhiều trong thiết kế các khóa học Java là từ JEDI (http://jedi.java.net/).
Bẵng đi một hai năm cho tới khi MIT và Havard bắt tay launching cái dự án eDx. Tôi mới lại có dịp ngó nghiêng trên mạng về các địa chỉ cung cấp các khóa học miễn phí chất lượng cao cho dân IT. Thực sự thấy choáng ngợp.
Dưới đây là danh sách một vài tên tuổi lớn rất đáng giá để mỗi người học và dạy IT tham khảo. Từ các tên tuổi lẫy lừng trong giới giáo dục, chất lượng tài liệu – khóa học tuyệt vời. Chỉ cần có một vốn English vừa đủ, một ý chí học tập mạnh mẽ, và chút ít thời gian đầu tư, tôi nghĩ rằng những người ở đất nước lạc hậu như Việt Nam có một cơ hội cực tốt để tiếp cận giáo dục đỉnh cao với chi phí gần như miễn phí. Xin cảm ơn Internet, cảm ơn công nghệ và đặc biệt cảm ơn các nhà giáo dục-hiệp sĩ của thế giới.
***
1. MIT
Địa chỉ: http://ocw.mit.edu/index.html
MIT là trường học hàng đầu thế giới về công nghệ. Đây được coi là xuất phát điểm của xu thế học liệu mở trên thế giới. Tôi hàm ơn MIT rất nhiều vì các học liệu của họ đã giúp tôi rất nhiều trong các bài giảng hằng ngày.
2. EdX Project
Địa chỉ: http://www.edxonline.org/
Sự đổi mới toàn diện của dự án OCW của MIT với đầu tư lớn hơn, và thêm các ngành học khác ngoài công nghệ với sự cộng tác từ hai ông lớn khác: Harvard và Berkely. Đây có thể sẽ là quả bom tấn trong lĩnh vực elearning chất lượng cao trên thế giới trong tương lai. Tuy nhiên, EDX cũng chỉ mới launching, còn ít khóa học. Hãy chờ xem.
3. Coursera.org
Địa chỉ: http://www.coursera.org/
Gần sớm như MIT, Standford – một ông lớn khác- cũng đã khởi đầu xu hướng học liệu mở từ thuở sơ khai. Gần đây họ cũng tập hợp thêm lực lượng đông đảo từ nhiều trường đại học có tiếng ở Mỹ để thúc đẩy thế mạnh của họ. Coursera như là một cú “nổ” lớn với cách tiếp cận elearning tiến bộ vượt bậc. Giờ người học có cơ hội học tập với những GS hàng đầu thế giới thông qua Internet. Hằng tuần tôi vẫn dõi theo các email thông báo các khóa mới trên Coursera. Một vài đồng nghiệp của tôi cũng đã hoàn tất các khóa học ở đó với feedback rất tích cực.
4. Khan Academy
Địa chỉ: http://www.khanacademy.org/
Ngôi sao sáng rực trong bầu trời elearning; và được coi là một Startup cực kì thành công trong những năm trở lại đây. Cách tiếp cận rất đơn giản nhưng hiệu quả. Giờ đây Khan Academy đã cung cấp một lượng khóa học rất phong phú từ toán học căn bản, khoa học máy tính, tài chính tới các môn học về khoa học xã hội và nhân văn.
5. Codecademy
Địa chỉ: http://www.codecademy.com/
Cũng là một startup thành công khác. Đây là nơi khiến thị trưởng nổi tiếng của New York cũng muốn học code.Với công nghệ tương tác vượt trội, người mới học lập trình sẽ có trải nghiệm tuyệt vời để lĩnh hội tri thức mới. Tuy vậy số lượng khóa học của Codecademy bị giới hạn trong phạm vi các môn về web.
Các địa chỉ cung cấp học liệu mở khác:
- Các trường đại học công nghệ của Pháp (ParisTech) http://graduateschool.paristech.org/?langue=EN
- John Hopkins University (http://ocw.jhsph.edu/)
- Utah State University (http://ocw.usu.edu/)
- Tokyo Institute of Technology (http://www.ocw.titech.ac.jp/index.php?lang=EN)
- Keio University (http://keio-ocw.sfc.keio.ac.jp/index_en.html)
- Osaka University(http://ocw.osaka-u.ac.jp)
- University of Tokyo (http://ocw.u-tokyo.ac.jp)
- Waseda University(http://www.waseda.jp/ocw/index.html)
- Open University of UK(http://oci.open.ac.uk/pressrelease.html)
- elearningeuropa.info
- Và nhiều nữa, bạn có thể nhờ Mr. Google giới thiệu giùm 🙂
Viết riêng cho các GV đồng nghiệp ở FAT.
Tuần vừa rồi tôi có thực hiện một buổi seminar tương đối thú vị về project-based learning để cùng các giảng viên thảo luận về các ngóc ngách của việc huấn luyện các lập trình viên non tay nghề, bằng việc cho họ trải nghiệm thực tế phát triển phần mềm một cách gần gũi và tiêu chuẩn thông qua các “dự án”. Thực tế đây là một reflection về quá trình chuyển đổi phương pháp luận, một số vấn đề, giải pháp và cải tiến liên quan. Tuy nhiên có một điều tôi vẫn muốn nói thêm về một số vấn đề mang tính “lịch sử”, có lẽ đây cũng là dữ liệu bổ ích nên tôi chép lại nội dung đó ra đây.
Đầu năm 2009, tôi có được giao nhiệm vụ tái thiết lại phương pháp luận triển khai môn dự án (Project) cho sinh viên năm cuối tai các trung tâm tại Hà Nội do một số vấn đề tồn tại dai dẳng trong quá trình triển khai môn học thú vị này suốt nhiều năm trước. Đơn cử một vài mắc mớ như:
- Các giảng viên hầu như không thống nhất trong phương pháp luận, mỗi người mỗi phách trong hướng dẫn sinh viên thực hiện dự án cũng như đánh giá kết quả. Phần nhiều do sự đa dạng về phương pháp và nền tảng của các giảng viên (người xuất thân từ công ty làm phần mềm khác nhau, người xuất thân từ trường học); lại thiếu tài liệu hướng dẫn chi tiết.
- Mô hình waterfall như mô tả “phương pháp” lúc đó gần như không có hiệu lực trong thực tiễn. Mặc cho đây là cách tiếp cận dễ hiểu, và … dễ dạy, cái “quy trình” ấy gần như không bao giờ hiện diện trong thực tế. Theo mô hình này, sinh viên phải phân tích chi tiết bài toán, thiết kế rồi mới code và test; từng bước một. Nhưng thường thì sản phẩm cuối cùng rất ít khi khớp với mô tả trong SRS lúc ban đầu. Điều này rất dễ lí giải vì vấn đề đặt ra trong các project thường phức tạp nên sinh viên chỉ có thể hiểu thấu đáo trong quá trình hoàn thiện sản phẩm, chứ không thể ngay lúc đầu planning. Do vậy thực tế này dẫn đến hầu hết các documentation chỉ mang tính “báo cáo”, làm cho đầy đủ quy trình chứ ít khi phản ảnh những gì thực sự đang có trong sản phẩm. Một số giảng viên nhìn ra vấn đề đó từ sớm và có nhiều nỗ lực để làm “chính xác hóa” cái mớ tài liệu ấy bằng các cơ chế review liên tục, trợ giúp kĩ thuật về viết lách, OOAD v.v.; nhưng kết quả chỉ tốt hơn chút đỉnh, chứ không giải quyết được nguồn ngọn vấn đề.
- Học trò cuối cùng vẫn không hiểu được thế nào là “quy trình phát triển phần mềm”, không thực sự làm chủ được một quy trình do thực tế không được trải nghiệm một quy trình nào cả. Sách dạy waterfall, thầy ép theo waterfall, nhưng thực tế sinh viên luôn thực hiện theo một “cách khác”. Ví dụ như: đọc xong đề tài, thay vì viết SRS, phân tích các use case, rồi thảo luận các class diagram, sequence diagrame (SV quan niệm đó chỉ là các “tài liệu để báo cáo”-không hơn) v.v., thì sinh viên sẽ thực hiện theo trình tự kiểu như: tạo GUI, làm DB, rồi sau đó vừa làm vừa viết “tài liệu”; hoặc theo một cách khác nữa cũng phổ biến không kém: đọc đề bài > phân tích rất sơ sài> làm DB > code > tài liệu.
- Không có một môi trường thực sự cho việc cộng tác nhóm phát triển do thiếu đầu tư vào công cụ bên cạnh quy trình.
Đứng trước bài tập khó nhằn này, tôi đã cố gắng tìm kiếm một mô hình làm dự án phù hợp với đối tượng và vấn đề đặc thù tại trung tâm. Một phương pháp được đề xuất phải thỏa mãn một số tiêu chí cơ bản như:
- Thực dụng và khả thi: nó phải thực sự thực thi (khả thi) được, thống nhất giữa phương pháp luận và thực tiễn. Để khả thi, nó phải dễ hiểu, và dễ làm.
- Hướng ngoại: tức nó phải tương thích với một quy trình ở “ngoài kia” (“các công ty”), thay vì tự mình đề xuất theo sách vở. Điều này hữu ích trong động viên bản thân sinh viên, vì họ cảm thấy có được cái cảm giác trải nghiệm một quy trình thật trong một môi trường phát triển phần mềm đầy đủ.
- Có tính giáo dục: dù gì thì mục đích của dự án ở đây cũng là để sinh viên được trải nghiệm và học hỏi các kĩ năng cần thiết trong phát triển phần mềm, không phải để sản xuất phần mềm. Nó phải đưa sinh viên tới các ngóc ngách, đối mặt với các thử thách cần thiết để học được các kĩ năng cần thiết cho việc hành nghề của họ.
Lúc ấy có vài gợi ý: 1.cải tiến waterfall với các practices và tài liệu hóa đầy đủ việc hướng dẫn triển khai môn học; 2. Scrum (khi đó tại trung tâm tôi cũng đã run hai dự án dùng Scrum: một với nhóm giảng viên, một với nhóm sinh viên); 3. Sử dụng tư tưởng iterative và RUP best practices với các tài liệu trợ giúp đầy đủ; 4. CMMI .
Do lúc đó tôi bị áp lực phải đưa nội dung OOAD vào chương trình (do chương trình chính quy thiếu sót mục này), nên tôi đã lựa chọn phương án (3). Các sự thay đổi quan trọng là:
- Định nghĩa quy trình phát triển phần mềm với định hướng Iterative, RUP-based approaches.
- Viết tài liệu hướng dẫn triển khai project cho các giảng viên, cùng với các lecture notes, evaluation form tương ứng và cả case study dưới dạng “showcase” để giảng viên dễ hình dung.
- Làm template cho các artifacts (plan, SRS, use case spec templates, design template, verification checklist v.v.) để định hướng cũng như trợ giúp cả sinh viên lẫn giảng viên hướng dẫn dễ dàng cộng tác cũng như quản lí. Lúc này các tài liệu không còn là “tài liệu báo cáo” thuần túy, mà là các artifacts trong quá trình phát triển, nó động và hữu ích.
- Cài đặt hệ quản trị dự án (PMS) với cái lõi Redmine và SVN server, kèm theo các test server cho từng kì để thiết lập môi trường cộng tác chuyên nghiệp.
- Vậy là xong phương pháp luận, tài liệu triển khai, quy trình và công cụ. Tôi đã có buổi báo cáo với các group leader để thảo luận về phương pháp mới. Sau một vài ý kiến góp ý nho nhỏ, tôi mang nội dung quy trình mới ra thảo luận với hầu hết các giảng viên trong khuôn khổ một seminar. Đồng thuận tuyệt đối. Bước đầu như thế là thuận lợi.
Tuy vậy, khó khăn chỉ phát sinh lúc ta thực sự bắt tay vào công việc chứ thường chưa phải là lúc chuẩn bị. Hơn một năm triển khai mang lại những tín hiệu không vui mừng lắm. Bên cạnh một số report thuận lợi từ các giảng viên có kinh nghiệm và cộng tác chặt chẽ với người đề xướng phương pháp, còn ra thì hầu hết vẫn không cải thiện triệt để. Các vấn đề được đề cập ở đầu bài viết này vẫn hiện hữu như những cái gai chọc thẳng vào mắt.
Qua thảo luận chi tiết và phản tỉnh tôi hiểu ra rằng tài liệu đầy đủ không giúp được mấy, việc training cũng sẽ không có tác dụng gì nhiều khi mà cái approach ngay từ đầu đã không đúng. Cái bọn tôi cần là một cách tiếp cận đơn giản, xuyên suốt, có khả năng thích nghi và tùy biến cao. Một phần do sự phức tạp trong việc triển khai đồng loạt, một phần do sự biến động không đoán được trong kĩ năng của sinh viên từng thời kì, việc cố định một quy trình cứng nhắc không có khả năng thích nghi sẽ dẫn đến hiệu lực kém và khó kiểm soát. Nhất là khi một quy trình đó lại đòi hỏi kĩ năng đặc thù tương đối toàn diện ở một đội ngũ thực thi (sinh viên) ít kĩ năng (vì họ đang luyện mà). Cách tiếp cận kiểu RUP hay waterfall đó đòi hỏi sinh viên phải “‘phân thân” do yêu cầu chuyên môn hóa (manager, architect, designer, coder, tester), và đòi hỏi nó phải “đạt” tại tất cả các kĩ năng đó (vì nếu không đạt phần design thì lấy gì mà code?) để đi đến đích là một sản phẩm đem đi bảo vệ trước hội đồng. Cách tiếp cận engineering như vậy về cơ bản là đổ vỡ ngay từ đầu, xét theo khía cạnh khả thi. Thế nên, dù nỗ lực nhiều nhưng kết quả không thể nói là hài lòng được.
Năm 2011 cũng là năm tôi có cơ hội để nhìn nhận sâu sắc hơn về agile và Scrum nhờ vào các hoạt động diện rộng cũng như chuyên sâu để tìm lời giải cho mình: tham gia khóa học của Scrum Alliance để hệ thống hóa những hiểu biết về Scrum, gặp gỡ các employers để hiểu requirement về developers, khởi xướng HanoiScrum, cộng tác chặt chẽ với AgileVietnam và tham gia AgileTour để học hỏi từ cộng đồng chuyên nghiệp, thành lập ScrumLab để đi sâu vào các ngóc ngách thực hành Scrum\XP và thử nghiệm trên các đối tượng khác nhau; tiếp tục đọc, thử nghiệm và thuyết trình và huấn luyện Agile, TDD, Simple Design, Testing, Scrum v.v. Những trải nghiệm đa dạng đó không chỉ tiếp thêm sinh lực cho công cuộc phổ biến agile\Scrum ra cộng đồng cùng với các bạn cùng chí hướng, mà còn tạo thêm niềm tin và xung lực mạnh mẽ cho phép tôi mạnh tay đề xuất tiếp cận mới cho các môn project tại các trung tâm: phải linh hoạt hóa triệt để công tác giáo dục. Và project là xuất phát điểm.
Lần “nâng cấp” về phương pháp luận này có mấy điểm mấu chốt:
- Đặt Project-Based Learning và Experimental Learning làm nền tảng giáo dục cho việc triển khai các khóa học project. Cần phải có lý thuyết giáo dục dẫn đường, vì đây là một nhiệm vụ giáo dục.
- Tái thiết các mục tiêu cốt lõi của các khóa học Project của từng kì, theo hướng rèn luyên khả năng tích hợp các kĩ năng thành phần (component skills) quan trọng đối với software developer. Định hướng hoạt động theo objective-oriented (huấn luyện, thực hành, đánh giá dựa vào mục tiêu).
- Tái thiết quy trình với cái lõi là agile\Scrum
- Đề cao tính thích nghi, tương tác, liên tục học hỏi và cải tiến trong thực tiễn triển khai. Liên tục cập nhật các tài liệu, best practices quan trọng.
- Tiếp tục hoàn thiện môi trường phát triển, nhấn mạnh các khâu phân vai, hạ tầng, và công cụ cho luyện tập.
Tiến trình này được khởi xướng được hơn nửa năm, và vẫn đang trong quá trình học hỏi (thực tế là đang rất lộn xộn). Nhưng tôi tin tưởng hướng tiếp cận mới rất đúng đắn, phù hợp với thực tiễn và xu thế chung. Hơn thế nữa, qua các thực tiễn sử dụng tư duy linh hoạt vào hoạt động không thuộc lĩnh vực phát triển phần mềm (như cung cấp dịch vụ, marketing, giáo dục chẳng hạn) được báo cáo tại Scrum Alliance, Agile Conference thì các giá trị agile rất phù hợp với các nguyên lý căn bản của giáo dục hiện đại như tính cá nhân hóa, tính tương tác, tính thích nghi, tính tùy biến, sự phát triển bền vững v.v. Có thể nói các giá trị và nguyên lí agile hỗ trợ thúc đẩy mạnh mẽ hiệu quả của các tiến trình giáo dục.
Cỗ xe tiếp tục lăn bánh, và tôi đang háo hức mong đợi các kết quả tốt vượt bậc từ phía triển khai. Đây quả là chặng đường thử thách và thú vị.
TPS – Toyota Production System- là kinh điển quản lí, xây dựng tổ chức trường tồn. Chính nó tạo nên và khuếch trương Tư duy Tinh gọn (Lean Thinking), Sản xuất Tinh gọn (Lean Manufacturing). Giờ đây Lean đã có ở mọi nơi: khởi sự, phát triển sản phẩm (đủ loại hình), dịch vụ. Dưới đây là tóm tắt 14 nguyên lí của nó:
Nguyên lí #1: Ra các quyết định quản lí dựa trên một triết lí dài hạn, dù phải hy sinh những mục tiêu ngắn hạn
- Trang bị một ý thức về mục tiêu có tính triết lí để thay thể bất kì một hình thức ra quyết định ngắn nhạn nào. Làm việc, phát triển và lèo lái theo mục đích chung lớn lao hơn là chỉ kiếm tiền.
- Tạo ra giá trị cho khách hàng, cho cộng đồng và cho nền kinh tế. Đó là khởi điểm.
- Có trách nhiệm
Nguyên lí #2: Tạo ra một chuối quy trình liên tục làm bộc lộ sai sót
- Tái thiết các quy trình nghiệp vụ để đạt được một luồng liên tục có giá trị gia tăng cao. Triệt tiêu thời gian chết trong các quy trình.
- Liên kết các thông tin, nhân sự, chu trình để phát hiện tức thì các trục trặc
- Làm chuỗi giá trị trở nên rõ nét trong văn hóa của công ty, làm chìa khóa cho quy trình cải tiến liên tục và phát triển nhân sự.
Nguyên lí #3: Sử dụng hệ thống kéo để tránh sản xuất quá mức
- Cung cấp đúng cái khách hàng cuối cần, đúng thời điểm, đúng số lượng họ mong muốn.
- Tối thiếu hóa khối lượng công việc trong qui trình (Work-In-Progress:WIP)
- Đáp ứng tốt với các thay đổi hằng ngày
Nguyên lí #4: Bình chuẩn hóa lượng công việc
- San bằng sự trồi sụt trong kế hoạch sản xuất
- Dàn đều khối lượng công việc tại tất cả các quy trình nghiệp vụ, thay thế hình thức sản xuất ngừng/chạy
Nguyên lí #5: Xây dựng thói quen biết dừng lại để giải quyết trục trặc, đạt đến chất lượng tốt ngay từ ban đầu
- Chất lượng là động cơ xác định giá trị
- Tự nhận biết trục trặc và tự dừng lại. Tự kiểm lỗi (Self-check) là nền tảng để xây dựng chất lượng.
- Thiết lập hệ thống phụ trợ để nhanh chóng giải quyết trục trặc
- Xây dựng văn hóa biết dừng lại và chậm rãi để có chất lượng ngay từ đầu
Nguyên lí #6: Chuẩn hóa các nghiệp vụ là nền tảng của sự cải tiến liên tục cùng việc giao quyền cho nhân viên
- Sử dụng biện pháp ổn định lặp lại thường xuyên tại mọi khu vực để duy trì khả năng phán đoán, nhịp dộ sản xuất cùng với thông lượng đều đặn của các quy trình. Đây là nền tảng của luồng một sản phẩm (one-piece-flow) và hệ thống kéo (pull system).
- Tiêu chuẩn hóa các thói quen làm việc tốt. Cải tiến các tiêu chuẩn không ngừng.
Nguyên lí #7: Quản lí trực quan để không có trục trặc nào bị che khuất
- Dùng chỉ dẫn hình ảnh để nhận biết sớm tình trạng công việc
- Thiết kế hệ thống bảng biểu hỗ trợ luồng một sản phẩm và hệ thống kéo
- Rút ngắn báo cáo xuống 1 trang giấy
Nguyên lí #8: Chỉ áp dụng các công nghệ tin cậy, đã được kiểm chứng toàn diện, để phục vụ cho các quy trình và con người của công ty.
- Công nghệ để hỗ trợ chứ không phải thay thế con người
- Kiểm nghiệm cẩn thận trước khi áp dụng
- Khuyến khích xem xét công nghệ mới, nhanh chóng triển khai nếu đã chín muồi
Nguyên lí #9: Phát triển những nhà lãnh đạo, người hiểu thấu đáo công việc, sống cùng triết lí và truyền đạt lại cho người khác
- Phát triển lãnh đạo từ bên trong công ty
- Lãnh đạo phải là hình mẫu cho triết lí và cách thức kinh doanh của công ty
- Lãnh đạo phải am tường nghiệp vụ, là mentor khi cần truyền dạt văn hóa công ty
Nguyên lí #10: Phát triển các cá nhân và tập thể xuất sắc có thể tuân thủ triết lí của công ty
- Tạo dựng văn hóa mạnh và ổn định
- Đào tạo trong khuôn khổ văn hóa công ty
- Sử dụng nhóm liên chức năng để cải thiện chất lượng và năng suất công việc
- Liên tục huấn luyện làm việc nhóm vì mục tiêu chung
Nguyên lí #11: Tôn trọng mạng lưới đối tác và các nhà cung cấp bằng cách thử thách họ và giúp họ cải tiến
- Thử thách đối tác để họ phát triển
- Đặt mục tiêu và hỗ trợ đối tác để đạt mục tiêu
Nguyên lí #12: Đích thân đi đến và xem xét hiện trường để hiểu tường tận tình hình (Genchi Genbutsu)
- Đi đến nguồn gốc vấn đề, đích thân quan sát thực địa. Kể cả lãnh đạo cao cấp.
- Chỉ nghĩ và nói dựa trên dữ liệu thực tiễn đã được kiểm chứng
Nguyên lí #13: Ra quyết định không vội vã thông qua sự đồng thuận và xem xét kĩ lưỡng mọi khả năng, rồi nhanh chóng thực hiện
- Xem xét tất cả các khả năng trước khi quyết định. Khi quyết định rồi thì nhanh chóng thực hiện.
- Quyết định chậm nhất có thể.
Nguyên lí #14: Trở thành một tổ chức học hỏi bằng việc không ngừng tự phê bình và cải tiến liên tục (Kaizen)
- Khi có quy trình ổn định, dùng các công cụ cải tiến liên tục.
- Thiết lập quy trình tối thiểu hóa tồn kho.
- Củng cố tri thức của doanh nghiệp.
- Sử dụng phản tỉnh (hansei, reflection) tại những giai đoạn then chốt để thoải mái nhìn nhận sai sót, tránh lặp lại.
- Học tập thông qua tiêu chuẩn hóa những thói quen làm việc tốt
Trích “Standards for What?The Economic Roots of K-16 Reform”, bởi Anthony P. Carnevale. & Donna M. Desrochers, ETS.
Nền kinh tế ngày nay không chỉ đòi hỏi một hệ thống kĩ năng mới mà còn bắt buộc các học sinh phải sử dụng chúng thành thạo.
Hệ thống kĩ năng đó bao gồm:
- Kĩ năng căn bản: đọc, viết, tính toán
- Kĩ năng nền tảng: biết cách tự học
- Kĩ năng giao tiếp: lắng nghe và nói chuyện
- Kĩ năng thích nghi: giải quyết vấn đề và tư suy sáng tạo
- Sự hiệu quả nhóm: các kĩ năng liên cá nhân, thương lượng, làm việc theo nhóm
- Khả năng gây ảnh hưởng: hiệu quả tổ chức và lãnh đạo
- Tự quản: tự trọng, động lực/đặt mục tiêu
- Thái độ: tư duy tích cực
- Kĩ năng ứng dụng: năng lực nghề nghiệp và chuyên môn.
Tôi đã gom lại một số principles và best practices đã được đề cập rải rác trong blog này vào một tài liệu Google Presentation cho dễ đọc, dễ tham khảo và tra cứu. Dành cho các nhà giáo luôn trăn trở và tìm kiếm phương cách để cải thiện chất lượng dạy và học. Cảm ơn chị Giang HH đã bỏ công tút lại cái slide, nom dễ đọc hơn hẳn 🙂
[googleapps domain=”docs” dir=”presentation/embed” query=”id=1jVMt0yrbh28XH_KzWBEhPlURzSWV8sbVgoLAiay3tE4&start=false&loop=false&delayms=3000″ width=”960″ height=”749″ /]
Đấy, bất kì người nào từng suy nghĩ về giáo dục hay bị lôi cuối vào đó, hay thậm chí đã đi học đều biết rằng hậu quả của nó là sau khi học xong hầu như không biết hoặc không hiểu gì cả. Tư tưởng vĩ đại như thế nào là không quan trọng, nếu chúng bị áp đặt vào các bạn từ bên ngoài và các bạn bị nhồi nhét hết những mớ kiến thức ấy từng bước một, sau khi các bạn học xong sẽ quên hết chúng. Ý tôi muốn nói, tôi chắc chắn các bạn đã học một số môn nào đó ở trường, các bạn làm bài tập ở nhà, các bạn thi đỗ, thậm chí các bạn nhận được điểm ‘A’ – nhưng một tuần sau đó thậm chí bạn không nhớ được môn học đó nói gì.
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.
Noam Chomsky
Tr. 339 – Nhận diện Quyền lực, Nxb Tri Thức, 2012.
Tạp chí Lập trình đã lên mạng được hai tuần, đạt 5000 view và gần ba chục bài viết. Đây là một sáng kiến theo chủ trương “làm việc nhỏ nhưng có ích” với mục tiêu là “là một kênh thông tin đa chiều về phát triển phần mềm do một nhóm các giảng viên công nghệ phần mềm có tâm huyết lập nên với mong muốn thúc đẩy việc học tập, giảng dạy và thực hành phát triển phần mềm”.
Điều vui nhất là nó đã được hiện thực hóa, chỉ sau một hai buổi nói chuyện. Và mọi người đã bắt tay vào làm luôn, không chờ đợi.
Điều vui thứ nhì là lượng view vượt mức chờ đợi. Ban đầu blog được định hướng là không cần câu view, chỉ làm những việc nhỏ có ích, viết các bài giải quyết các vấn đề nhỏ sát sườn của chính những blogger nghiệp dư – là các giảng viên đang giảng dạy, trợ giúp cho sinh viên của mình học tốt hơn. Có những điều không thể hiện được trên lớp, thì vào TCLT mà xem thêm. Còn bạn đọc trên mạng có thể sẽ tìm kiếm được vài thông tin có ích theo kiểu “nếu có duyên thì gặp”. Đại để đơn giản thế thôi.
Thời gian ngắn nên chưa có nhiều phản hồi. Tuy nhiên một số nhận xét ban đầu cho thấy blog đang đi theo hướng Journal chứ không phải unjournal (phi chính thống, informal). Không biết điều này có nguy hại gì không, nhưng chắc chắn là nó sẽ tiêu tốn thời gian nhiều hơn, và có vẻ lãng phí?
Con đường đi của TCLT dài ngắn, rộng hẹp thế nào còn phải tìm. Nhưng điều chắc chắn là nó sẽ phải lean, phải focus, và mang lại values tối đa trong khoảng thời gian và nguồn lực hạn hẹp của một nhóm nhỏ các nhà giáo và các cộng tác viên. Con đường còn ở phía trước …
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)