DƯƠNG TRỌNG TẤN - Agile Mindset for Better Life
  • Trang đầu
  • Building Modern Developers
  • Agile World
    • Sách mới: Linh hoạt và Tinh gọn
    • Cẩm nang Scrum cho người mới bắt đầu
    • AGILE BOOKSHELF
  • Xã hội tri thức
    • Tri thức và Nhận thức
    • Tổ chức học tập
  • Lean Startup
  • Giáo dục
    • Học cách học
    • Dạy & Học
    • Công nghệ Giáo dục
    • Tủ sách Giáo dục
  • Lính Tốt
  • Giới thiệu
DƯƠNG TRỌNG TẤN - Agile Mindset for Better Life
Trang đầu
Building Modern Developers
Agile World
    Sách mới: Linh hoạt và Tinh gọn
    Cẩm nang Scrum cho người mới bắt đầu
    AGILE BOOKSHELF
Xã hội tri thức
    Tri thức và Nhận thức
    Tổ chức học tập
Lean Startup
Giáo dục
    Học cách học
    Dạy & Học
    Công nghệ Giáo dục
    Tủ sách Giáo dục
Lính Tốt
Giới thiệu
  • Trang đầu
  • Building Modern Developers
  • Agile World
    • Sách mới: Linh hoạt và Tinh gọn
    • Cẩm nang Scrum cho người mới bắt đầu
    • AGILE BOOKSHELF
  • Xã hội tri thức
    • Tri thức và Nhận thức
    • Tổ chức học tập
  • Lean Startup
  • Giáo dục
    • Học cách học
    • Dạy & Học
    • Công nghệ Giáo dục
    • Tủ sách Giáo dục
  • Lính Tốt
  • Giới thiệu
Giáo dục

Viết vội mấy dòng về bài giảng “Innovative and inspirational engineering education” của GS Alison Halstead

Theo chương trình của Sterling Group, các Giáo sư từ UK đã có chuỗi bài giảng đầy ấn tượng trong khuôn khổ hoạt động của nhóm tại các trường đại học Việt Nam.

Thật thích khi được lắng nghe những thông tin thú vị từ GS Alison Halstead, trường Aston về đổi mới và truyền cảm hứng trong giáo dục. Bài thuyết trình của GS như là một câu truyện về những nỗ lực cải cách giáo dục UK do chính GS là một trong cách leader của chương trình này. Cách thức mà trường Aston, nhóm GS Halstead đang vận hành tại UK để tổ chức một trường học chất lượng cao cho học sinh từ 14-19 tuổi có thể là một case-study tuyệt vời cho các nhà quản lí giáo dục cũng như các nhà giáo tại Việt Nam.

Aston University Engineering Academy

Aston University Engineering Academy (ảnh: AUEA)

Tôi đặc biệt chú ý đến hai việc:

1. Tự do tái thiết từ triết lí đến cách làm để thay đổi tận gốc vấn đề

Làm sao để cho học sinh hứng thú với Toán, Lí, Hóa khi chúng toàn là các công thức chán ngắt? Làm sao để các sinh viên kĩ thuật chịu khó học các môn này?

Gợi ý là: hãy cho họ tiếp xúc thật với điện tử, với iPad, với iPhone (những thứ không hề chán ngắt), rồi chỉ ra có “bài toán”, “công thức” nào trong đó. Điều này đòi hỏi phải vận hành lối học problem-based triệt để với thiết bị thật, người thật, bài toán thật v.v. Như Dewey từng mong ước: học sinh được trải nghiệm cuộc sống thật ngay khi học. Việc này đặt ra cả núi thách thức khác: làm sao để có thiết bị thật, công xưởng thật, kĩ sư thật, bài toán thật? rồi làm sao để lồng ghép các vấn đề cần dạy học trong đó, hay nói cách khác curriculum phải như thế nào? Họ có đầy đủ tự do để làm điều đó với một trường học hoàn toàn mới (xem tại: http://www.auea.co.uk/), với sự cải tổ cực kì quan trọng: gắn kết trường học – công ty.

2. Liên hệ education-industry cực tốt

Nhờ vào các chính sách CSR (Corpoprate-Social Responsibilities), họ đã kêu gọi được mạnh thường quân chính là cá big-players trong ngành engineering của UK (e-On, Royal Airforce, Goodrich, NationalGrid, v.v.) để hỗ trợ thiết bị, tutor, tiền tài, … đồng thời với việc học thực tập ngay tại công ty với thời gian 1 năm với các chuyên gia tại các công ty.

Ở Việt Nam, chỉ có FPT University là có chính sách rõ ràng cho việc này: học 3 năm đầu, thực tập (gần) 1 năm tại FSOFT, quay lại học  nốt năm cuối trước khi ra trường. Tuy nhiên, chính sách này vẫn có vẻ vướng phải vấn đề cố hữu của việc “thực tập” của SV:  sự kết nối trường-công ty có vẻ như chưa được “tới bến”, sự liên kết lỏng lẻo, giả tạo. Sinh viên chưa chắc chắn được đối mặt với “problem” thật, được tham gia giải quyết chúng với các “tutor” thật, cùng cho ra “sản phẩm” thật. Do vậy có thể nó chưa đạt được cái inspiration tốt như mong đợi. Tiếp cận của trường Aston thì khác hẳn về chất.

Trong phần thuyết trình này của GS Halstead, Mr. Trần Ngọc Tuấn có nêu vấn đề CSR gần như yếu hoặc không có ở hầu khắp các công ty Việt Nam khiến cho mối liên kết trường học – công ty là cực kì khó khăn. Tôi thì chưa có điều kiện nghiên cứu nhiều vấn đề này, nhưng có tự đặt ra một câu hỏi: liệu có thực sự khó khăn thế hay không? hay là do chúng ta chưa chịu ngồi với nhau? Ai cũng biết cái “gap” giữa trường học và công ty nó lớn, cần thu hẹp, nhưng liệu hành động đã đủ chưa? Có vẻ như chúng ta kêu ca nhiều hơn là bắt tay hành động thực sự kể cả với các nỗ lực tầm vĩ mô, cũng như ở tầm vi mô – vốn sát sườn với các trường học, đặc biệt là các trường tư. Với kinh nghiệm chủ quan, tôi thấy một số cơ sở giáo dục đã có sự kết nối rất tốt với các employer chủ chốt trong ngành để nâng cao chất lượng giáo dục, tăng  employability của người học. Câu trả lời có sẵn ở chỗ họ rồi.

September 12, 2012by Tấn Dương
FacebookTwitterPinterestGoogle +Stumbleupon
Đọc, Giáo dục

Người mình “không lo xa, dễ thoả mãn”

Tôi luận rằng người nước Nam ta khi túng thiếu thì lo lắng thở than, trong lúc đói lo một hồi mà thôi, chớ no không lo nữa.
Người nước của chúng ta, bởi không từng trải ít thấy rộng ít nghe xa (…) hễ vừa mới động nở nòi ra một thí (1) là đổi tính đổi nết, làm bề làm thế (2), muốn nghỉ mà ăn chơi. Bởi làm sao vậy? Bởi trong trăm người mới có một thì là trong một xóm ở chừng một trăm, người ấy đã đặng trên mấy bợm (3) khác. Có bạc chục bạc trăm, cho vô cho ra, đã có người thiếu nợ mình rồi; cho nên hết muốn ráng sức nữa. Vì vậy nhiều khi nghèo nàn khổ sở trở lại. Đến lúc nghèo rồi lại than thở trách trời, sanh mình sao mà vận xấu, mới cho khá rồi lại làm cho nghèo, tại trời không thương.
(1)     khá giả một tí
(2)     làm le, làm dáng, khoe mẽ
(3)     bợm đây không có nghĩa xấu mà chỉ có nghĩa bọn khác kẻ khác
 Lương Dũ Thúc,
Nông cổ mín đàm, 1902
Trích từ “Thói hư tật xấu người Việt”,Vương Trí Nhàn.
September 12, 2012by Tấn Dương
FacebookTwitterPinterestGoogle +Stumbleupon
Agile Mindset

Hiểu thế nào cho đúng về “liên chức năng”

Nhóm Scrum có hai đặc điểm cực kì quan trọng là: tự tổ chức (self-organizing) và liên chức năng (cross-functional). Về tự tổ chức, tự quản, tự định hướng thì dễ hiểu, nhưng thế nào là “liên chức năng”? Bài này mong muốn chỉ ra  một số hiểu lầm thường gặp, cũng như đào sâu thêm về khái niệm này trong phạm vi Scrum Framework để người học và thực hành Scrum đỡ bị rơi vào các nghịch lí khi cố gắng đối lập Scrum với những gì hiện có.

Có người bảo “cá nhân trong nhóm liên chức năng biết làm tất cả mọi việc, trong nhóm Scrum không có ai là tester hết, không cần designer trong nhóm Scrum nữa, chỉ có developer thôi”.

Có người lại bảo “nhóm liên chức năng có nghĩa là ai cũng có thể làm được việc thay thế người khác, không cần phân vai rõ ràng, một người có vấn đề sẽ không ảnh hưởng đến cả nhóm”.

Có người thì cao hứng phát biểu “một nhóm mà liên chức năng thì siêu năng suất”.

Những nhận định trên trên đều không ổn, và chúng là các điển hình về các ngộ nhận khi đề cập đến nhóm Scrum.

Vậy nhóm liên chức năng là gì?

Đây không phải là khái niệm mới mẻ gì, và về cơ bản nó chưa có nhiều thay đổi trong cách định nghĩa: đó là một nhóm bao gồm nhiều cá nhân với các chuyên môn khác nhau được kết hợp lại cùng làm việc hướng tới một mục tiêu chung.

Trong đội dự án, các cá nhân có thể đến từ nhiều phòng ban chức năng khác nhau, cũng có thể xuất phát từ bên ngoài (khách hàng, các cá nhân có liên quan, chuyên gia tư vấn v.v.). Nhưng khi đã thành một đội (team), thì các cá nhân làm việc tập trung cho đội như là một đơn vị (unit) để hoàn tất mục tiêu chung.  Bên trong nhóm liên chức năng không có các nhóm nhỏ khác. Ví dụ: một Nhóm Scrum “Alpha” được thành lập với một Product Owner, một Scrum Master, 2 Tester, 5 Developer, 1 Architect, 1 UX Designer sẽ không phân chia chức năng thành các nhóm nhỏ khác như nhóm Testing (2 người), nhóm Developement (5 người) … nữa, mà chỉ có một nhóm duy nhất “Alpha” với các cá nhân có các chuyên môn khác nhau, hợp thành một đội thống nhất để làm việc hướng tới sản phẩm cần phát triển. Trong cách nói của Ken và Jeff, tester hay analyst … đều là developer, họ là nhà phát triển nhưng có chuyên môn đặc thù là kiểm thử hay phân tích; developer trong trường hợp này không có ý nghĩa là coder\programer. Việc xóa nhòa các title này có mục đích là để gom mọi người vào một mục tiêu chung, không phân biệt “nhãn mác” (title): phát triển phần mềm.

Khác với nhóm liên chức năng, nhóm chức năng (functional team) thường chỉ phụ trách một loại công việc đặc thù. Ví dụ, phòng thiết kế thì không code, phòng test thì không có ai design. Công việc của nhóm chức năng thường có tính cô lập cao.

Có phải cứ “liên chức năng” thì nhóm sẽ năng suất hay không?

Hỏi cách khác, liệu cứ thành lập một nhóm Scrum với cách tổ chức liên chức năng như thế, thì nhóm sẽ ngay tức khắc sẽ gia tăng năng suất lao động?

Rõ là không dễ dàng như thế rồi.

Liên chức năng chỉ là một “cấu hình” trong các cách thức cấu tạo nhóm làm việc. Và cách cấu hình này cho phép hình thành một đội độc lập với đầy đủ các chuyên môn cần thiết để hoàn tất công việc, dưới dạng một ‘business unit’ ở mức tối giản. Sự độc lập này tạo điều kiện cho nhóm ra các quyết định kịp thời, chính xác và nhanh chóng mà không bị phụ thuộc các đơn vị khác. Ví như trong cách thức tổ chức các nhóm chức năng (functional teams), một công việc phải đi qua nhiều công đoạn, mỗi công đoạn lại do các nhóm [với các chức năng] khác nhau đảm nhiệm, và vì thế sự phụ thuộc (dependency) gia tăng, khiến cho sự linh hoạt giảm xuống, và có nguy cơ làm giảm sự hiệu quả cũng như năng suất của nhóm.

Về mặt lí thuyết, với cấu hình “liên chức năng”, Nhóm Scrum có khả năng trở thành một “work cell” và có được “luồng một sản phẩm” (thuật ngữ của Lean), từ đó vừa gia tăng năng suất, vừa gia tăng chất lượng sản phẩm; đồng thời tạo điều kiện để vận hành “hệ thống kéo” (cũng thuật ngữ Lean), giúp loại bỏ các lãng phí không cần thiết, tối ưu hóa giá trị.

Nhưng một nhóm bất kì đều phải trải qua các giai đoạn Hình thành>Bão tố>Ổn định>Hiệu suất>Thoái trào (theo Tuckman). Có nghĩa là nó không thể đạt được hiệu quả ngay khi mới thành lập được.

Mặt khác, về “hiệu suất”, Katzenbach và Smith chỉ ra rằng một nhóm phải mất khá nhiều nỗ lực mới đạt được thành quả thực sự. Nó sẽ phải trải qua các trạng thái  như là một “nhúm” các cá nhân rời rạc, cho tới khi trở thành một nhóm thực sự, rồi mới phát huy hiệu quả cao.

 

Đường cong Hiệu suất Nhóm, ảnh: Đại học Michigan.

Đường cong Hiệu suất Nhóm, ảnh: Đại học Michigan.

Hiệu suất hay không do nhiều nguyên nhân cấu thành. Hiệu suất thường là cái cuối cùng trong tất cả các nỗ lực, mà “cấu hình nhóm” là một trong các nỗ lực như vậy. Nếu coi “cấu hình nhóm” là phần “cứng”, thì còn nhiều yếu tố nữa quyết định nhóm có “hiệu suất” không, chính là các phần “mềm” của nhóm: cách vận hành nhóm, quy tắc, phương pháp, sự lãnh đạo v.v. Trong Scrum, các yếu tố “mềm” này được phân bố rải rác trong chính sách trao quyền để nhóm “tự tổ chức” (self-organizing), “tự quản” (self-managing), “tự định hướng” (self-directed); trong các phân bố vai trò trong nhóm (ai lãnh đạo việc gì, ai phụ trách việc gì); các quy tắc và công cụ cộng tác (các burndown chart, backlogs, events, metrics); cho đến nguyên lí và cơ chế đảm bảo sự minh bạch trong làm việc v.v. Tất cả các yếu tố đó kết hợp nhuần nhuyễn với “cấu hình” mới tạo nên một nhóm cộng tác chặt chẽ, mau trưởng thành, sớm đạt được trạng thái năng suất cao. Lấy ví dụ, việc một nhóm liên chức năng được trao quyền tự tổ chức sẽ phát huy được sự chủ động, giảm thiểu phụ thuộc vào bên ngoài (hay bên trên); cũng do một nhóm liên chức năng đã có đủ các kĩ năng cần thiết để giải quyết vấn đề nên hoàn toàn có thể trao quyền cho nó để tự nó phát huy năng lực tập thể giải quyết vấn đề theo cách tốt nhất; nhờ đó sự liên chức năng kết hợp với sự tự quản, tự tổ chức có thể thúc đẩy các sáng kiến từ dưới lên (bottom-up), trực tiếp, nhanh chóng và chính xác. Khi đó, lãnh đạo\quản lí  thực hiện công việc chủ yếu là xúc tiến quá trình cộng tác nhóm và tự quản của nhóm thông qua đảm bảo quy trình, loại bỏ trở ngại, thiết lập và duy trì môi trường thuận lợi, thúc đẩy tiến trình thanh tra-thích nghi, v.v. chứ không còn bám sát từng đầu công việc nữa. Việc này đã được quy định chặt chẽ trong “mô tả công việc” của từng vai trò (Scrum Master, Product Owner, DevTeam) rồi.

Thế còn chuyện “liên chức năng thì không bị ảnh hưởng bởi xáo trộn cá nhân”? Chuyện một cá nhân ra đi mà nhóm không có xáo trộn chỉ là ảo tưởng. Chỉ có robot mới có thể đáp ứng được yêu cầu đó. Theo hướng đó thì chỉ việc đề cao quy trình, quản lí thật chặt đầu công việc của member theo lối “công nhân” tay chân, giao cho các công việc cố định, xếp vào các vị trí và công đoạn được mô tả rõ ràng  Việc này khả thi ở chỗ khác, chứ tuyệt nhiên khó hiệu quả ở đội phát triển phần mềm vốn có bản chất phức tạp, và rất đa dạng trong từng công việc. Hơn thế nữa, việc gán chuyện “không xáo trộn” như vậy cho nhóm liên chức năng còn phản lại nguyên lí của Agile: “Cá nhân và tương tác hơn là quy trình và công cụ”. Cá nhân là tiền đề của nhóm, là nơi quyết định thành bại của nhóm. Nhưng cá nhân ấy là cá nhân đặt trong nhóm cộng tác, với các đòi hỏi cao về các “tương tác” có chất lượng thì mới giải phóng được năng lực của chính các cá nhân ấy. Còn “quy trình” chỉ là cái hỗ trợ cho việc phát huy năng lực của cả nhóm. Nhóm làm việc bao giờ cũng hướng tới sự gắn kết cao độ, càng gắn kết thì lại càng dễ bị xáo trộn bởi sự thay đổi của cá nhân trong nhóm. Nhóm liên chức năng có thể có một ưu điểm trong việc hỗ trợ nhau trong công việc (do đòi hỏi cộng tác chặt chẽ, sự minh bạch trong công việc, cũng như đó là một nhóm-học-tập liên tục), nên có thể giảm thiểu rủi ro của việc mất đi “chuyên gia”, nhưng việc xáo trộn, thậm chí sốc, là không thể tránh khỏi.

Cuối cùng, có phải trong Nhóm Scrum không còn tester, không còn QA nữa, mà chỉ còn developer? developer phải là dân “xịn” biết test ngon, biết code giỏi, biết design khéo? Cũng là ảo tưởng nốt! Và ảo tưởng này xuất hiện đơn giản là xuất phát từ việc hiểu nhầm khái niệm “cross-functionality” như đã nói ở bên trên.

September 12, 2012by Tấn Dương
FacebookTwitterPinterestGoogle +Stumbleupon

Tìm kiếm

Đăng kí nhận tin

Đăng ký để nhận được những thông tin hữu ích, kịp thời trong hộp thư của bạn.


Theo dõi và cập nhật

Đang được chú ý

Hiểu thế nào cho đúng về “liên chức năng”

Hiểu thế nào cho đúng về “liên chức năng”

Bí quyết đọc sách cho những kẻ thế mà đần

Bí quyết đọc sách cho những kẻ thế mà đần

10 điều ghi nhớ để làm lính cho ra trò

10 điều ghi nhớ để làm lính cho ra trò

[36 kế dạy học thụ động] #1: Cho sinh viên làm thầy

Bài viết mới

Quản trị tri thức dễ thất bại, nhưng thế nào là mới là thành công? 

Quản trị tri thức dễ thất bại, nhưng thế nào là mới là thành công? 

Đặt đề bài đào tạo: Sự khác nhau giữa doanh nghiệp và cơ sở đào tạo

Đặt đề bài đào tạo: Sự khác nhau giữa doanh nghiệp và cơ sở đào tạo

Dấu hiệu của một người đã biết tự học 

Dấu hiệu của một người đã biết tự học 

Những nền tảng cộng tác của nhóm startup

Những nền tảng cộng tác của nhóm startup

ScrumMaster – Nhà quản lí không quản lí

ScrumMaster – Nhà quản lí không quản lí

Sách của Dương Trọng Tấn và cộng sự

Sách: Linh hoạt và Tinh gọn

Categories

  • Agile Mindset
  • Chuyện đời
  • Công nghệ
  • Đọc
    • Sách
  • Giáo dục
    • Constructivism
    • Học cách học
  • Khác
  • Không phân nhóm
  • Lean Startup
  • Linh tinh xòe
    • Lan man
  • Tài nguyên
  • Xã hội tri thức
    • Tổ chức học tập
    • Tri thức và Nhận thức

Tags

36 kế dạy học thụ động active learning agile agile adoption agile education agile mindset agilemindset agileteaching agile transformation codegym complexity constructivism Cánh Buồm công nghệ và giáo dục dạy học education giáo dục hipster HỌC CÁCH HỌC học học tập học tập trải nghiệm kanban khởi nghiệp lean lean startup learning learning organization làm lính thật tốt MOOC PBL personal kanban reflection scrum seci sách sử kí thuyết kiến tạo trekking tích hợp tản mạn chuyện đọc tổ chức học tập tự học Đa Diện động viên

"CHI BẰNG TỰ HỌC"


© 2016 Copyright Dương Trọng Tấn.