Steve Denning đã có một số phân tích chi tiết về việc ban lãnh đạo Saleforce.com (một trong những công ty sáng tạo và có bước phát triển tốt nhất hiện nay) đã giới thiệu Scrum vào tổ chức như là một trong các thay đổi đột phá và căn bản để đạt được bước nhảy vọt trong đổi mới và phát triển. Theo đó ông nhận ra rằng, Marc Benioff – cùng Saleforce.com đã tránh được sáu lỗi thường gặp mà các công ty hay mắc phải:

#1: Giới thiệu Scrum chỉ đơn giản là một quy trình nghiệp vụ đơn thuần.

Thay vì thế, họ coi sự thay đổi này là bước chuyển đổi căn bản (fundamental transformation) về cách làm việc trong tổ chức. Với cách tư duy mới, giao tiếp kiểu mới và hành động kiểu mới ở cả cấp độ quản lí lẫn nhân viên.

#2: Nhà quản lí là chủ cuộc chơi

Thay vì áp đặt từ trên xuống, sự thay đổi sang Scrum cần cam kết chặt chẽ từ dưới lên để thay đổi công việc. Nhà quản lí đóng vai trò hỗ trợ cho sự chuyển đổi rộng khắp của tổ chức với tất cả nguồn lực và khả họ có thể dành cho sự thay đổi.

#3: Cứng nhắc áp dụng một phương pháp luận đã bám rễ và thành công ở đâu đó

Thay vào đó, Saleforce.com được xây dựng dựa trên những gì họ học được từ các tổ chức khác, nhưng thích ứng với các điều kiện và ràng buộc của họ.

#4: Quản lí vi mô sự thay đổi

Thay vì các kiểm soát chi tiết, Saleforce.com mô hình hóa tư tưởng quản lí kiểu định hướng-thiết lập và trao quyền.

#5: Giữ bí mật các quết định quản lí then chốt

Thay vào đó, họ minh bạch hóa thông tin ở mức tối đa.

#6: Dè xẻn trong huấn luyện và đào tạo

Thay vì tiết kiệm từng xu cho đào tạo và huấn luyện, Saleforce.com tập trung một nguồn lực khổng lồ cho các khóa huấn luyện và đào tạo cần thiết. Từ việc gửi đi đào tạo, mua sách, tạo lập wiki nội bộ cho toàn bộ quá trình chuyển đổi.

Nguồn: http://www.forbes.com/sites/stevedenning/2011/04/18/six-common-mistakes-that-salesforce-com-didnt-make/

____________

Xem thêm thêm chi tiết về việc chuyển đổi của Saleforce.com, được trình bày tại hội thảo Scrum Gathering tại Chicago 2008:

Steve Dening, tác giả của Radical Management khái quát cốt lõi của Scrum dưới mười gạch đầu dòng sau đây:

1. Tổ chức công việc trong các chu kỳ ngắn,
2. Nhà  quản lý không làm gián đoạn các nhóm trong một chu kỳ làm việc;
3. Nhóm  báo cáo cho khách hàng, không báo cáo người quản lý;
4. Nhóm ước tính cần bao nhiêu thời gian để làm việc;
5. Nhóm  quyết định bao nhiêu việc sẽ làm trong mỗi phân đoạn;
6. Nhóm  quyết định làm việc như thế nào trong mỗi phân đoạn;
7. Nhóm tự đo lường hiệu suất của riêng mình:
8. Xác định mục tiêu công việc trước khi mỗi chu kỳ bắt đầu;
9. Xác định mục tiêu công việc qua những câu chuyện của người sử dụng (user stories) ;
10. Loại bỏ những trở ngại một cách hệ thống.

Tất cả các điều trên không có gì mới. Sự mới mẻ là ở chỗ chúng được kết hợp với nhau một cách chặt chẽ và tài tình để hoàn thành công việc.

Trong buổi nói chuyện PMPTalks #3 sáng chủ nhật vừa rồi với các bác ở VietPMP, có một nhận định rất thú vị về Scrum management . Bác ấy (thật đáng tiếc là quên mất tên của bác, hình như bác Thắng) nhận thấy, Scrum tiếp cận management ở mức High-level, để từ đó tạo ra cơ hội tự do lựa chọn các biện pháp, phương thức quản lí cụ thể; do vậy nó rất linh hoạt.

Bác ấy là người mới nghe Scrum, mà đã có nhận định vô cùng sắc sảo như vậy. Thật khâm phục!

Hầu hết mọi người đều mong chờ Scrum là một silver bullet, hay ít ra là môt phương pháp đầy đủ chỉ cho nhà quản lí biết phải làm gì để thành công; một cái lí thuyết tốt là lí thuyết dễ áp dụng, thậm chí áp dụng máy móc vẫn được. Scrum rõ ràng không phải loại này rồi.

Craig Larman, tác giả của nhiều đầu sách nổi tiếng về Agile có dùng một từ rất đắt về Scrum: nó là một “silent framework”. Nó im lặng trong việc thể hiện các “điều cần làm”, “cách nên làm” đối với hầu hết các đầu việc trong phát triển phần mềm: từ thu nhận và phân tích, tài liệu hóa các yêu cầu, cho đến thiết kế, cài đặt và kiểm thử cũng vậy. Người dùng Scrum có quyền tối đa để lựa chọn các cách thức phù hợp. Về các practice, Scrum hầu như không nói gì cả.

Nó High-level như vậy đấy.

Là người dịch Scrum Guide ra tiếng Việt qua ba phiên bản, tôi đã trực tiếp thấy việc các tác giả SCrum đã cố gắng gỡ bỏ các yếu tố “mô tả” như thế nào khỏi đặc tả Scrum. Những “công cụ” và “kĩ thuật” rất tốt như “burndown\up chart”, “release planning” v.v. là những thứ rất lợi hại trong thực tiễn thi hành Agile\Scrum; nhưng không phải vì thế mà nó có chân trong Scrum Guide. Họ đã dỡ bỏ chúng đi để Scrum framework ngày càng trở nên đơn giản, ngày càng “lặng lẽ” hơn.

Cũng chính vì sự lặng lẽ vậy mà Scrum trở nên linh hoạt và thành công, bởi lẽ nhờ đó, người dùng có cơ hội thử, rồi kiểm nghiệm cách thức phù hợp nhất với họ. Có nhóm sẽ thấy User Story rất hữu ích, nhưng có công ty  thấy use case mới phù hợp v.v. Đây là tinh thần thực nghiệm (empirical) vốn là nền tảng cơ bản của Scrum. Phải dựa trên điều kiện thực tiễn ta mới biết được nên làm như thế nào tiếp theo. Scrum không mô tả trước (prescriptive) điều gì, mà để rộng cửa cho người dùng bồi da đắp thịt vào một cái khung sườn tuy đơn giản mà vững chắc. Cùng với ba chân (Minh bạch, Thanh tra, Thích nghi) hỗ trợ đắc lực cho tiến trình quản lí thực nghiệm (empirical process control), cái khung Scrum như là một nền móng kiến trúc vững chắc cho các ngôi nhà quản lí hiệu quả trong thực tiễn.

Có thể chính sự im lặng đó là chất “vàng” đáng giá nhất của Scrum.

#1.

Ảnh: IEEE

Đây là một vụ rất ồn ào, tốn giấy mực của báo chí: Dự án Sentinel của FBI

• Mục đích: số hóa các dữ liệu điều tra của FBI, dùng cho 30.000 nhân viên FBI
• Ước tính ban đầu: 451M, hoàn thành và cài đặt vào 2009.
• Đơn vị phát triển: Lockheed Martin.
• Mô hình: waterfall-based.
• Khởi công: 2006

Đến tháng 8-2010, đã chi 405M/451M nhưng mới chỉ đạt được 50% tiến độ; chưa dùng được gì.

Do tốn kém và trì trệ, FBI kết thúc hợp đồng với Lockheed Martin, thay CIO, để lại 50% công việc dang dở.

Công ty kiểm toán độc lập Mitre ước tính FBI cần thêm 35M nữa, cùng với 6 năm nữa để hoàn thành dự án.

Thời điểm đó CTO mới quyết định chuyển dự án sang Scrum, và họ hoàn tất khối lượng công việc với chỉ 30M trong vòng 1 năm, tiết kiệm 90% chi phí.

Nguồn: Ken Schwaber và Jeff Sutherland, “Software in 30 days”.

***

Biên tập viên John Foley của Information Week có bình luận về vụ này (tại đây), và rút ra năm bài học:

1. Chuyên gia ở khu vực tư nhân rất đáng giá

2. Agile rất được việc

3. Các phần mềm thương mại đóng vai trò quan trọng

4. Agile rất tiết kiệm

5. Đừng cài đặt phần mềm mới lên phần cứng đã lạc hậu

tiếp #2

Là tác giả của  tài liệu Scrum trong Nhà thờ, tôi [Arline Sutherland] đã được mời tới nói chuyện về cách sử dụng Scrum trong các khu vực ngoài IT. Thật khó để tìm thấy một khu vực nào khác biệt phát triển phần mềm hơn là một nhà thờ!

Trong hai năm qua, tôi đã làm việc tại Scrum Inc., nơi chúng tôi không phát triển phần mềm và sử dụng Scrum để làm mọi việc. Nó thực sự không giống như một nhà thờ chút nào. Vì vậy, tôi đã thực sự ngạc nhiên, như khi tôi đã đọc lại Scrum trong Nhà thờ, để nhận ra rằng các giáo đoàn tôi phục vụ và Scrum Inc. có nhiều thử thách tương tự.

Một vấn đề tôi gặp phải trong mỗi giáo đoàn tôi phục vụ là: bởi vì các nhân viên làm việc bán thời gian và những người làm việc có lịch trình rất khác nhau, không thể có cuộc họp hàng ngày có mặt tất cả mọi người. Nhân viên làm việc ngày Chủ nhật, sẽ nghỉ vài ngày trong tuần. Những người khác làm việc từ 9:00-5:00, thứ Hai đến Thứ Sáu. Người làm việc Bán thời gian có nghĩa là không ở đó toàn bộ thời gian để làm việc.

Trong nhà thờ, chúng tôi quyết định tổ chức họp đứng hàng ngày (daily standup) mỗi sáng bất kể là có mặt những ai. Vì vậy, mỗi buổi sáng, từ Thứ Hai đến Thứ Sáu, tất cả các nhân viên trong tòa nhà tập hợp lại. Sau một thời gian, một số nhân viên toàn thời gian có ngày nghỉ trong tuần bắt đầu xuất hiện ở các buổi họp vào ngày nghỉ của họ.

Tại Scrum Inc., chúng tôi cũng vật lộn với việc làm sao để có đủ mọi người tại buổi họp đứng hàng ngày. Chúng tôi có hai nhân viên bán thời gian. Jeff di chuyển triền miên, chủ yếu là ở châu Âu. Một trong chúng tôi sống và làm việc ở Washingotn D.C., phần còn lại thì ở Boston.

Nhờ có Google Hangout và Skype, việc họp đối với nhiều người phân tán về lịch biểu hoặc địa lí trở nên dễ dàng hơn. Tuy nhiên, khi một hoặc nhiều người trong chúng tôi triển khai một khóa học hoặc tư vấn, chúng tôi không thể có được một cuộc họp hàng ngày, thậm chí chỉ 15 phút.

Scrum hoạt động tốt nhất khi Team ngồi chung địa điểm và tất cả mọi người làm việc cùng một lịch trình. Nhưng thế giới thực hiếm khi làm việc như thế. Không có quy định về việc làm thế nào để thích ứng với những hoàn cảnh như vậy, nhưng dưới đây là một số kỹ thuật chúng tôi thấy rất hữu ích:

1. Nếu một thành viên trong nhóm không thể họp hàng ngày, yêu cầu họ gửi email báo cáo đến Scrum Master để nó có thể được cập nhật, và sau đó gửi email về những điểm chính từ buổi họp hằng ngày cho cả nhóm. (Chỉ cần các điểm chính, không cần một “biên bản họp” dài dòng làm gì).

2. Lên lịch các cuộc họp mặt-đối-mặt định kì. Không có gì thay thế được việc ở trong cùng một không gian cùng một lúc, cho các cuộc đàm thoại với dòng nước mát lanh, để nghe những gì người ta đã làm cuối tuần qua, để chia sẻ một bữa ăn, và ghi nhận những sự kiện quan trọng như sinh nhật và dịp kỉ niệm ở công ty. Bố trí một ngân sách du lịch để mọi người sống và làm việc ở xa có thể xích lại với nhau một cách thường xuyên.

3. Sử dụng một bảng Scrum ảo. Trong khi chúng ta biết rằng các ghi chú dán trên tường là tốt nhất, ta vẫn có thể nghĩ tới công cụ linh hoạt tốt gần bằng thế để phục vụ công việc. Mỗi thành viên của nhóm có thể thể truy cập vào tất cả các ngày, mỗi ngày. (Chúng tôi thích Tracker Pivotal).

4. Hãy để ý đến sự mù thông tin. Khi gặp vấn đề gì, gửi email đến tất cả mọi người trong nhóm. Hãy chắc chắn rằng tất cả các công việc được ghi nhận trong backlog để mọi người biết những gì đang xảy ra. Nếu một tài liệu là kết quả của một story, hãy đính kèm nó vì vậy tất cả có thể đọc được. Nếu có một cuộc họp, hãy viết các bản tóm tắt ngắn gọn.

Trong bản chất, Scrum đặt con người lên ưu tiên số một, tạo ra một đội nhóm, về sự hoàn hảo, và niềm vui khi làm việc! Con người chúng ta có thể là một thứ khó tính dễ bị kích thích; chúng ta cũng có thể là một người vui vẻ hào phóng làm việc để làm cho cuộc sống của chúng ta và thế giới này một nơi tốt hơn.

Theo Arline Sutherland, ScrumInc.com

Brian Wernham đã viết một cuốn sách mới về kỹ năng lãnh đạo cho việc thực hiện các dự án quy mô lớn thuộc khu vực công chỉ trong phạm vi vài tháng, chứ không phải mất hằng năm như hiện nay. Đó là cuốn “Quản lý Linh hoạt cho các dự án nhà nước” (Agile Project Management for Government).

Gần đây, Bộ Quốc Phòng Mỹ đã hủy bỏ một dự án quản lí nguồn nhân lực (HR) sau 12 năm nỗ lực. 1 tỷ USD đã tiêu tùng. Tương đương với gần $100 cho mỗi người nộp thuế Mỹ. Thay đổi chuyên gia quản lý, Brian Wernham nghĩ rằng chính phủ nên làm nhiều điều hơn để các dự án công nghệ quy mô lớn có được hiệu quả chi phí tốt hơn thông qua việc sử dụng Agile.

“Quản lý Linh hoạt cho các dự án nhà nước” của Brian Wernham là một nghiên cứu chuyên sâu mới về việc lãnh đạo Agile có thể làm giảm nguy cơ thất bại của các dự án thuộc khu vực công cộng và giảm phần lớn những chi tiêu lãng phí.

Đây là cuốn sách nên đọc của các nhà lãnh đạo trong chính quyền trung ương, liên bang và địa phương cũng như trong khu vực tư nhân. Cuốn sách này cung cấp:

• lý do tại sao nhiều dự án có thay đổi lớn đã thất bại và làm thế nào để đảm bảo bạn không “dính” phải cái dớp đó.

• 9 hành vi Lãnh đạo Linh hoạt mà bạn cần phải biết

• bám sát các quy tắc, đạo luật và các chiến lược của chính phủ Mỹ và Anh

• làm thế nào để thích ứng với phương pháp linh hoạt trong khu vực công

• Các đặc điểm của hai phương pháp linh hoạt phổ biến: SCRUM & DSDM

Bình luận về lý do ông viết cuốn sách này, Brian nói, “Mặc dù có rất nhiều người ủng hộ ý tưởng quản lý linh hoạt ở Mỹ, sự tiếp nhận các ý tưởng này trong khu vực nhà nước là rất chậm chạp. Tôi tin rằng với cách thức linh hoạt hơn và tương tác hơn, quản lý linh hoạt (agile management) có thể mang lại thành công trong lĩnh vực công, nơi rất nhiều dự án thác nước truyền thống (waterfall) tiếp tục phải nhận các thất bại nặng nề”.

Nguồn: Kelly Waters, AllAboutAgile.com.

Sắp 20-11, người người lại có cớ để mua hoa, chúc tụng, và .. đưa phong bì.

Còn đội GS (Gà sống hay Giáo sư tùy cách gọi, cũng chả quan trọng lắm :)) lại có cớ để tổ chức hội họp và … “tọa đàm”. Nó có tên: Buổi tọa đàm “Đổi mới cách dạy” ở 1A Yết Kiêu chiều thứ 7, 17-11-2012.

Các GS có mặt đông đủ trong một hội trường ngổn ngang bàn ghế vì vừa được nhận thêm một lố bên Lê Đại Hành chuyển về. Để có được chỗ ngồi như vậy,  các bác Tú-Quân-Lực++ phải gồng mình suốt mấy ngày không nghỉ để dọn dẹp hết bàn ghế, sách vở, và cả ..rác rưởi nữa. GS Duẩn, khách mời từ FU đến có thể sẽ hơi ngạc nhiên vì không gian hơi bị bừa bộn một chút.

Layout được đổi vào phút chót, Tấn DT đóng góp một chút hơi tàn của ngày cuối tuần để đổi layout hình chữ I nằm ngang thành ra chữ U để mọi người có cơ hội nhìn mặt nhau khi nói. Thanks em Quỳnh và chị Dung đã hỗ trợ vào phút chót 😀

Bắt đầu đúng một giờ. Chả mấy khi đúng giờ như thế. Âu cũng là tín hiệu đáng mừng.

GS Tuân trưởng ban tổ chức đề từ ngắn gọn: “không có gì thay đổi nếu không có gì thay đổi” bằng tiếng Anh thì phải. Nói chung là triết lí thâm nho …

Rồi đến phiên đầu tiên của nữ GS Thi ĐK.

Diện một bộ đồ rất chỉn chu và đẹp đẽ, Thi ĐK hùng hồn trình bày các vấn đề về phương pháp có tên “Dạy cho nhau nghe”. Lí lẽ chắc chắn, bằng chứng đầy đủ, GS Thi lôi kéo mọi người vào một phương pháp hấp dẫn, hiệu quả để sinh viên có được sự thúc đẩy tự thân trong tiến trình học tập. Với phương pháp này, sinh viên sẽ tự học, tự giúp nhau học, không khí rất vui vẻ mà cực kì hiệu quả, các số liệu về điểm thi cùng với các feedback chính quy (GPA) lẫn phi chính quy (facebook) đều cho thấy điều đó. Điều đáng chú ý là cách làm của GS rất thận trọng và khoa học: Thăm dò > Thử nghiệm > Feedback > Mở rộng áp dụng. Điều này khiến cho việc sử dụng phương pháp mới không vướng phải sự phản kháng nào đáng kể, ngay từ đầu, đối với mỗi thay đổi.

Tuy sờ-lai hơi “xấu như con gấu”, GS Thi vẫn thuyết phục được gần hai chục GS khác ngồi dưới về tính hiệu quả và khả thi của phương pháp. Có vẻ như nhiều người sẽ mạnh dạn áp dụng phương pháp “Student Teaching” hơn nữa.

Rồi chàng công tử Cu-ba-nà xuất hiện với tiêu đề của bài thuyết trình rất dài (mình quên mất rồi), đại để là về “Học tập Tích cực”. Bài thuyết trình tương đối lộn xộn và không theo phương pháp lí luận cổ điển nào, nhưng nó lại để lộ ra cách thức sử dụng triệt để và hiệu quả các công cụ hiện đại để phục vụ việc giảng dạy và học tập. Với Facebook, GS đã tạo một không gian học tập kết nối liên tục, gia tăng thông lượng trao đổi học tập của sinh viên vượt lên nhiều lần so với số giờ trên lớp. Sự thành công nhất là các trao đổi đó đa dạng: từ sinh viên đến sinh viên (là chủ yếu), từ sinh viên tới giáo viên. Thời chưa có Facebook, thật khó tưởng tượng ra một kiểu trao đổi như vậy. Đó là Google Drive với khả năng chia sẻ vượt trội giúp các máy tính của SV và GS được kết nối và đồng bộ hóa liên tục, ở nhà cũng như ở trường, vượt qua các giới hạn về địa lí; dữ liệu được chia sẻ liên tục, tức thì và không tốn thời gian. GS Nhật cũng đã cho thấy một vấn đề nghiêm trọng của các hệ LMS\CMS hiện nay, chúng đã quá lạc hậu với mô típ upload-download-thông báo. Cần một hạ tầng mới cho việc học? Mặc dù bài thuyết trình hơn nửa tiếng về đủ các kiểu phương pháp, nhưng chỉ cần hai điểm đó thôi cũng đã khiến cho nhiều người phải nhìn lại cách thức tương tác và chăm sóc sinh viên của mình để giúp đỡ họ trưởng thành hơn trong học thuật.

Một chàng hoàng tử Cu-ba-nà khác là Đới PA xuất hiện để giới thiệu cách thức áp dụng DailyScrum vào việc dạy học. GS đã dùng 15 phút mỗi giờ để cho các học trò tự trả lời ba câu hỏi quan trọng theo mô típ của Scrum:

1. Từ hôm trước đến hôm nay đã làm được gì rồi?

2. Từ hôm nay đến mai sẽ làm gì?

3. Khó khăn gặp phải khi học là gì?

Việc tập trung tự trả lời ba câu hỏi đó trong một nhóm (lớn, gồm cả lớp 20 người) sẽ giúp SV được ít nhất ba việc:

1. Chú ý tới việc học, biết được việc cần làm là gì để học tốt

2. Là một icebreaker để tránh buồn ngủ lúc đầu giờ

3. Nói ra khó khăn để các bạn trợ giúp, hoặc thầy sẽ phục vụ

Đây là phiên nóng nhất vì các GS liên tục chất vấn với các câu hỏi hóc búa mà bản thân GS Đới cũng khó lòng trả lời hết được. Tuy vậy, có những câu hỏi dường như xoáy vào việc DailyScrum giải quyết được bao nhiêu việc cho học trò, gặp phải sự chống đối từ Sv thì làm thế nào, nếu SV lười học thì liệu ba câu hỏi kia liệu có vô ích, mười lăm phút có làm hết không ? v.v. và vân vân. Đó là các câu chất vấn rất điển hình của rất nhiều người chưa dùng Scrum và lo ngại tính hữu ích của nó. GS Đới cũng đã frame lại: Daily Scrum không nhằm giải quyết vấn đề gì cho sinh viên ngoài ba cái mục đích đã nêu ở trên. Các thảo luận sôi nổi giữa các đội quân “ném đá” gồm Vinh, Bình, Thế Anh v.v., khiến cho hoàng tử về từ Cuba đôi lúc nóng con mắt bên phải, đỏ con mắt bên trái 😛

Điều đáng chú ý là cả bốn diễn giả chính của buổi tọa đàm đều sử dụng DailyScrum cho việc giảng dạy của mình, và có đánh giá hết sức tích cực về hiệu quả của phương pháp. Không hiểu có ai muốn thử nữa không?

Phiên TeaBreak diễn ra vui vẻ trong không khí trao đổi sôi nổi đề tài của GS Đới vừa trình bày. Chủ tọa Tuân N phải mất công gào thét mới lôi mọi người về đúng chỗ ngồi để tiếp tục các phần trình bày tiếp theo.

Đến lượt Giang HH với “Học vải vui, vui thì mới học”, với đủ chiêu trò để học trò có niềm vui thích thú với việc học. Tất cả đều rất đáng để xem xét đưa ra áp dụng. GS đã gây bất ngờ cho tất cả mọi người với chiêu “Đổi gió”: cô trò cùng đến cà phê sách ngồi thuyết trình thay vì trong lớp, cô donate 100% chi phí trà nước 😛

Ngoài ra GS Giang cũng cung cấp một số kinh nghiệm xương máu về vấn đề “Chửi”, có nhiều bài học lí thú về vấn đề sư phạm nhạy cảm này, được mọi người tham gia góp ý rất sôi nổi.

Phần gần chốt, GS Dương và Hảo lên cung cấp các dữ liệu về mong đợi của SV đối với các thầy cô. Dữ liệu khảo sát từ gần một trăm sinh viên được tổng hợp lại đã để lộ rõ các mong muốn từ phía học trò đối với thầy cô, rất cụ thể và chi tiết: thầy cô phải tâm huyết, thân thiện, có chuyên môn vững, phương pháp giảng dạy tốt, v.v. Đây sẽ là dữ liệu quan trọng để các GS lưu tâm trong quá trình dẫn dắt và phục vụ của mình.

Trước khi tới phần thêm mắm thêm muối của Tấn, GS Vinh cung cấp một số chi tiết mới về cách thức cộng tác và hỗ trợ giữa đội giáo viên giúp cho sự sẵn sàng khi đứng lớp được tốt hơn.

Về phần mình, mình có nói nhanh gọn về một số từ khóa trong tiếp cận giảng dạy để dễ dàng thích nghi với sự đa dạng trong giảng dạy và học tập, như: empiricism, metacognition, individuals & interactions … và mình đã dẫn mọi người đến agile manifesto cho giáo dục, một chủ đề đã có dịp trình bày ở AgileTour vừa rồi tại HCM. Phần thuyết trình của mình dài vượt dự kiến mất 2 phút (12 phút thay vì 10 như “đã thề” :P)

Chủ tọa kiêm MC TuânN nói lời chốt hạ trong không khí phấn khởi chưa từng thấy: hiếm khi có một hội thảo hay hội họp ở FAT lại đúng giờ như vậy. Nhờ đó mọi người có mặt đông đủ ở quán Bia để “chào mừng sự thành công của cuộc họp”, như thường lệ. Và trong lúc bia đã dăm bảy cốc, GS Tuân cao hứng: “Hội thảo quốc gia cũng không được như thế này”. Thật là một buổi cuối tuần đầy cảm xúc! Nhất là khi 9h đêm hôm trước, mọi người còn phải vật lộn với đường truyền để kết nối với GS Vinh đang ở trong Viện Nhi (đưa con vào viện khám) để chốt nội dung trình bày ngày hôm sau 😛

Tấn ra về với sự khoan khoái lạ thường, nhất là khi nghe được GS Duẩn nhận xét: bổ ích thế này cần phải mở rộng cho nhiều người biết hơn. Vâng, nghe lời bác dặn, hôm nay em phải pót bằng được cái sự kiện này lên blog để nhiều người biết hơn 😀 Lần sau em xin hứa tổ chức ở chỗ to lớn đàng hoàng hơn với sự đóng góp rộng rãi hơn trong thành phần “báo cáo viên” và người tham dự.

Dưới đây là vài hình ảnh còn sót lại từ cuộc Tọa đàm (bấm to để xem hình lớn):

Đây là Agenda

Mình đã tìm ra cái hình GS Tuân dùng đây rồi:

MC kiêm chủ tọa Tuân N đương thuyết trình:

Chàng Đới đương chém:

Vì chủ đề là về cái vui nên cười trước đã:

Thi ĐK với ngổn ngang chữ:

Còn đây là MindMap của mình, theo dõi rất chăm chỉ đấy nhá

Alex, Nhân, Chris – The Organizers, hạt nhân của một kì AgileTour thành công rực rỡ

Rất nhiều nhà tài trợ, một cộng đồng được thực sự.

Câu hỏi của hay của Ken: Are you AGILE or FRAGILE? là một câu hỏi rất gợi hứng

Ken thuyết trình từ Boston, đường truyền thi thoảng tậm tịt, nhưng mọi người vẫn rất chú ý, vui vẻ.

Những câu hỏi để khai phá Asian values từ Peter

Một Kaizen workshop của Kiro: Tàu bay giấy.

Kiro đã giúp mình hiểu Lean ra đời trong bối cảnh lịch sử rất khắc nghiệt, lean ra đời vì người Nhật cần một cái gì đó để sống sót trong điều kiện không có tiền, không có công nghệ và máy móc thời hậu chiến.

Trước khi về Nhật, Kiro đã giới thiệu với mình Cynefin framework, một công cụ tốt cho Complex Problem. Amazing.

Joe Justice, super star của hội thảo. Mang đến đủ bộ các ý tưởng cho một Agile Enterprise: Agile Manufacturing, agile HR, Agile Marketing, Agile Sales.

Lúc nào Joe cũng bùng nổi. Chỗ nào có Joe chỗ đó bùng nổ.

Một điều thú vị: để vào được taxi, có vẻ Joe rất thích đi “cửa hậu” – tức là nhảy vào ghế sau của taxi từ cửa sau thay vì ngả ghế trước

Joe và chiếc the retrospective boat rất đẹp, thú vị & hiệu quả cho Retrospective.

Phút “chào hàng” của Alexandre Cuva. Alex đã giới thiệu cho mình Sonar, SpecFlow cùng hàng tá tool khác. Cả ScrumBeer nữa chứ.

Alex là người lắng nghe rất kĩ cái idea “agile education” của mình.

Ai đó đã chộp được mình?

Daniel Teng – vị chỉ huy. Thật vui được nói chuyện nhiều với Daniel về Cà phê Việt, về Thinking, về code retreat và con cái

Cảm ơn Daniel đã giới thiệu Gerrard Jerry Weinberg và Ayeconference, lại cả Code Retreat nữa.

Lắng nghe quy tắc hoạt động của OpenSpace

Một tác phẩm của Volunteer.

Rules. Chữ E của Daniel khá lạ

Chọn chủ đề đề cùng thảo luận trong OpenSpace

Đội số 8 có Joe ném đá

Đội này chơi kiểu “On the Floor”

Đội Thúy có vẻ rất FOCUS

Thuyết trình trong OpenSpace – cả nghĩa đen lẫn nghĩa bóng. Một phần cực chất.

Chụp trộm của chụp trộm

Không biết bác nào chụp được cái khoảnh khắc này. Trông mình và Alex thật … thê thảm

Vòng tròn Retrospective của Daniel được mọi người học rất nhanh, hào hứng.

Đây là chiếc áo của Joe, có đủ chữ kí của các Speakers.  Nó không ra khỏi VN được vì còn phải lo … phục vụ người nghèo.

Không hiểu Alex sẽ bán đấu giá cái áo này như thế nào đây ?

Kiro và Peter trong lúc chờ “Cà phê Chồn” sau hội thảo

Hoa ở khách sạn.

Những chiếc ghế ở lại. Good bye AgileTour 2012 HCM.

Tiếp theo hai bài:

• http://duongtrongtan.wordpress.com/2012/08/30/triet-li-moi-cho-thuc-hanh-giao-duc-hien-dai/
• http://duongtrongtan.wordpress.com/2012/07/12/ve-ca-nhan-va-tuong-tac-trong-giao-duc/

Bài này đã đăng trên Action.vn với một cái tít khác, kêu hơn: ““5 ý tưởng đột phá” từ Agile và những thành công đã được minh chứng”

Joe Justice, Founder\CEO của WIKISPEED, đã mang đến rất nhiều sự kinh ngạc và sửng sốt tới sự kiện Agile lớn nhất Đông Nam Á vừa diễn ra tại HCM trong hai ngày 8,9/11/2012 – AgileTour 2012 Ho Chi Minh –  với các chủ đề về xây dựng một tổ chức thế hệ mới với nhiều ưu điểm vượt trội từ các triết lí của Agile. Cùng với Agile, WIKISPEED của Joe và các đồng sự có thể sản xuất ra những ô tô với chất lượng và tốc độ đáng kinh ngạc. Ít ai có thể tin được việc một chiếc xe ô tô cực kì linh hoạt, có độ tin cậy cao, tiết kiệm nhiên liệu và tốc độ lại có thể sản xuất theo dạng mô-đun hóa, mỗi tuần đều có mẫu để thử, và có thể hoàn tất trong vòng 3 tháng thay vì 10 năm. Các ý tưởng đột phá cùng với sản phẩm của Joe đang lan nhanh với tốc độ ánh sáng tới các ngóc ngách trên thế giới, từ những hội thảo chuyên ngành của hiệp hội Agile lớn nhất thế giới là AgileAlliance, tới các buổi nói chuyện thu hút sự chú ý của TED ở Mỹ hay các nhóm công nghệ ở châu Á; từ những diễn đàn trên các mạng xã hội cho tới các tờ báo lớn như Forbes hay New York Times.

Joe và chiếc xe WIKISPEED mẫu tại hội thảo Agile 2012 tại Dallas, 7-2012 (ảnh: WIKISPEED)

Joe bật mí, đằng sau sự thành công của WIKISPEED là “5 ý tưởng đột phá” từ Agile, đó là:

–          luôn luôn chuyển giao một phiên bản mới của sản phẩm mỗi tuần

–          chào đón sự tham gia của khách hàng và đối thủ tham gia vào đội của bạn, sử dụng IP của bạn, và cùng làm việc với phiên bản tiếp theo của sản phẩm

–          lựa chọn công việc để làm cho thế giới tốt đẹp hơn, làm những việc thực sự có giá trị, tập trung vào giá trị của người dùng cuối hơn là việc sinh lời

–          nhìn nhận tất cả các “đối thủ cạnh tranh” như là những đối tác trong tương lai

–          cam kết với sự minh bạch triệt để –  xuất bản tất cả những gì bạn học được bất cứ khi nào bạn có thể theo cách rõ ràng nhất có thể, bất kể tốt hay xấu.

Những “bật mí trên” là cách hiểu của Joe về Bốn Giá trị Agile, và 12 Nguyên lí Agile. Joe cùng nhóm của mình luôn tự đánh giá công việc của mình dựa trên các triết lý và nguyên tắc đó để liên tục cải tiến công việc của nhóm, 7 ngày một lần.

Trong ảnh: Joe Justice đang thuyết trình về “Agile Manufacturing” tại AgileTour HCM 2012

Sau những thành công đã được minh chứng với việc sản xuất ô tô, Joe tin tưởng chắc chắn “Agile cần thiết và khả thi cho mọi ngành nghề”, từ ngành sản xuất, tới giáo dục, marketing, sales v.v.

WIKISPEED là một trong rất nhiều minh chứng cho sự ảnh hưởng mạnh mẽ và rộng khắp của Agile tới sự cách thức làm việc trong thế kỉ XXI. Bắt đầu từ một sự kiện quan trọng tại Utah, Mỹ năm 2001, Tuyên ngôn Agile đã ra đời, chính thức đánh dấu một chặng đường phát triển vượt bậc của Agile Software Development, một triết lí mới để giúp ngành phát triển phần mềm phát triển nhanh chóng và bền vững. Theo thống kê của Forrester Research, 1/3 doanh nghiệp phần mềm đã áp dụng Agile vào công việc của họ; tỉ lệ này được dự báo là sẽ còn tiếp tục tăng lên trong những năm tới. Xuất phát từ giới phát triển phần mềm, ngày nay, các giá trị của Agile đã lan tỏa ra ngoại phạm vi khác, và mang lại mang lại giá trị lớn hơn cho các dự án cộng đồng, sản xuất, truyền thông và giáo dục, v.v.

Ở Việt Nam, eXtreme Programming, một trong các phương pháp Agile phổ biến nhất, theo chân những lập trình viên và công ty “có yếu tố nước ngoài” du nhập vào Việt Nam từ rất sớm (khoảng đầu những năm 2000), nhưng chưa bao giờ giới sản xuất phần mềm tiếp cận Agile một cách có hệ thống cho tới khóa học đầy đủ và tiêu chuẩn đầu tiên của hiệp hội Scrum thế giới (ScrumAlliance) tại thành phố Hồ Chí Minh đầu năm 2011,và ngay sau đó là sự ra đời của hai tổ chức cộng đồng Agile tại Việt Nam gồm Agile Forum Vietnam  và Hanoi Scrum với các hoạt động đa dạng nhằm phổ biến tri thức, chuyển giao công nghệ và kết nối cộng đồng phát triển phần mềm lại để gia tăng sức mạnh cạnh tranh cho. Với hai kì AgileTour thành công và sắp tới là ScrumDay Vietnam 2012 vào ngày 9/12/2012 tại Hà Nội, cộng đồng Agile Việt Nam cho thấy sự phát triển nhanh chóng và được chuyên gia nước ngoài kì vọng về sự phát triển đột phá trong những năm tới đây. Việt Nam đã chủ động tiến trình hòa nhập sâu hơn với cộng đồng Agile thế giới.