Năm năm trước tôi đã tự mình thiết kế và triển khai khóa Scrum đầu tiên: Scrum Foundation. Khóa học diễn ra ở Viện tin học Pháp ngữ. Lúc đó, rất nhiều anh em đã động viên tổ chức các khóa học tiếp theo vì tính hữu ích của nó. Nhưng cũng chỉ làm được thêm vài khóa nữa rồi dừng vì không có điều kiện về thời gian.

Phải đến năm 2016 này, chúng tôi mới trở lại với một khóa học Scrum được nâng cấp toàn diện: Pragmatic Scrum. 

Chúng tôi thiết kế với thời gian dài hơn gấp đôi: 2 ngày, đủ để người học vừa lĩnh hội khung khái niệm, vừa đủ để học được các kĩ năng thực hành cơ bản nhất khi một nhóm làm việc với Scrum. Nó cũng vừa đủ để cả những người đã từng học Certified ScrumMaster vẫn hài lòng vì tính thực tiễn cao, và khả năng “giải ảo” Scrum. Đây cũng là khóa học đầu tiên tại Việt Nam áp dụng phương pháp eduScrum vào giảng dạy. Chúng tôi cố gắng thiết kế khóa học có tính trải nghiệm tối đa, và đề cao tính thực dụng trong nội dung học tập.

Scrum đọc thì dễ, nhưng làm cho đúng cho đến thành thục thì không dễ. Do vậy, chúng tôi đầu tư rất nhiều để những ai đi học Pragmatic Scrum thấy mình đã chọn lựa thật đúng đắn. Cho đến giờ, hầu hết mọi người đi học Pragmatic Scrum đều hài lòng với kết quả từ khóa học. Những phản hồi từ các học viên khi rời lớp học để mang Scrum về áp dụng tại công ty có thể nói là hết sức tích cực. Đó là một niềm vui không nhỏ đối với đội ngũ của Học viện Agile non trẻ.

Hè này, chúng tôi lại khai giảng thêm một khóa nữa. Tôi lại rất háo hức mong chờ để được đồng hành cùng các Scrummer tiếp theo.

Xem thêm: http://hocvienagile.com/pragmatic-scrum/

Đến với các doanh nghiệp nhỏ, tôi thấy họ gặp quá nhiều vấn đề về quản lí, quy trình nghiệp vụ, đảm bảo chất lượng và tầm nhìn trong tương lai.
Các lãnh đạo cả trẻ cả già không thiếu khát vọng, cũng không thiếu nỗ lực nhưng không có thời gian để tìm hiểu những know-how cần thiết.
Nhân viên thì quay cuồng với các deadline, có muốn học hành thêm tí để nâng cao nghiệp vụ cũng chịu chết!

AgileBreakfast sẽ là người bạn thân thiết của mỗi người học, thực hành, quản lí theo triết lí Agile. Bài viết phong phú, đa dạng, hữu ích, chất lượng về các góc cạnh của Agile, Scrum, Kanban, Lean, Lean Startup… Từ triết lí tới công cụ và thủ thuật.

Tất tần tật, tại đây:

Lục lọi một hồi, hóa ra cái mindset của agilist giản dị kinh người, quy giản về một chữ: học.

Tư tưởng nó đơn giải thế này:

• Cá nhân phải học liên tục để có mastery trong chuyên môn của mình và khả năng thích nghi liên tục.
• Nhóm phải học cách trở thành một team hiệu quả, có khả năng cải tiến liên tục và thích ứng trong hoàn cảnh mới.
• Công ty phải học để tri thức không ngừng được sinh ra, phát huy hiệu quả và thích ứng trong mọi hòa cảnh mới.
• Nền văn hóa Agile là nền văn hóa vun trồng (cultivation).

Giới thiệu sách “Lean Mindset: Ask the right questions” của Tom Poppendieck và Mary Poppendieck

Đầu năm 2013, trong thời gian công du vòng quanh thế giới để thực hiện một loạt các workshop có tên Lean Mindset (trong đó cả Hà Nội và Tp.Hồ Chí Minh đều là điểm dừng chân, may mắn thay!), Tom và Marry đang hoàn tất cuốn sách cùng tên của mình: Lean Mindset. Có vẻ như đây là cuốn sách cuối cùng trước khi nghỉ hưu của hai “tư tưởng gia” (thought leader) của cộng đồng Agile quốc tế.

Bìa sách Lean Mindset

Trong khi phần nhiều sách Agile dạy “chiêu” (practices), với hàng loạt những “cách làm việc A, cách làm việc B, để làm việc C v.v.” thì thật hiếm có những sách dạy cách tư duy (mindset) làm “bánh lái” cho các “chiêu thức” đó. Bộ sách của nhà Poppendieck lúc nào cũng được săn đón bởi nó luôn khơi gợi và nuôi dưỡng tư duy cho những người người thực hành Agile, từ người tập tọe, tới lãnh đạo và các chuyên gia Agile khác.

Khi mới viết cuốn sách đầu tay rất nổi tiếng năm 2003, Tom&Mary vẫn còn xếp Lean Software Development (LSD) vào cùng họ với Agile Software Development (như tựa đề đã ám chỉ – Lean Software Development: An Agile Toolkit). Tuy nhiên, sau một thập kỉ, nhiều thứ đã thay đổi. Một số tác giả khác cũng đã cố gắng tiếp cận LSD theo cách thức độc lập với Agile, xếp nó như là bộ phận con của Lean Product Development. Bản thân Mary & Tom cũng đã có thời gian trải nghiệm đủ dài với LSD để nhận thấy những gì là khiếm khuyết, thiếu sót của Agile. Sau bộ ba cuốn sách với phạm vi được giới hạn trong thế giới phần mềm (lần lượt là: “Lean Software Development”,  “Implementing Lean Software Development” và “Leading Software Development”), Mary & Tom tự nhận thấy họ không thể viết thêm về phần mềm nữa, như lời bạt của cuốn sách thứ tư này đã đề cập. Do vậy, cuốn “Lean Mindset” xuất bản tháng 9 năm 2013 như là điểm kết thúc một chặng đường dài với Phần mềm để trở về với tư duy tinh gọn “thuần khiết” hơn, không bị ảnh hưởng bởi lĩnh vực hẹp và trào lưu Agile ồn ào như trước.

Ở Lean Mindset, hai tác giả muốn nêu bật đặc tính “là một tư duy” của Lean, chứ không phải là một “phương pháp” hay “chiêu thức”. Do đó, như tựa nhỏ của cuốn sách đã gợi ý, tác giả tập trung vào “hỏi các câu hỏi đúng đắn”. Việc này không chỉ là nội dung của bản thân cuốn sách, mà còn là phong cách xuyên suốt của quyển sách mỏng nhưng giàu ý tứ. Ngoài các câu hỏi chính yếu của từng chương như “Mục đích của kinh doanh là gì?”, “Bạn đang làm việc để làm gì?”, “Điều gì khiến con người làm việc hiệu quả”, “Năng suất là gì?” và nó có quan trọng không?, “vai trò của thiết kế là gì?” hay “vì sao phải cách tân đột phá?”; các tác giả còn liệt kê một danh sách dài những câu hỏi để bạn đọc động não, suy tư (reflect) kĩ thêm về tất cả các phương diện của một công việc có ý nghĩa. Với danh sách câu hỏi quý hơn vàng này, thời gian tương tác thực sự với cuốn sách có thể dài và sâu hơn rất nhiều so với số trang ngắn ngủi và lượng thông tin ít ỏi có chọn lọc của cuốn sách. Đó quả là một cách tiếp cận tốt để “tấn công” vào tư duy và thúc đẩy sự thay đổi tích cực.

Một trong những nét chấm phá thú vị của cuốn sách là sự xuất hiện của hai nhân vật giả tưởng Otto – một thanh niên có trực giác nhanh nhạy và Anna – một cô gái rất lí tính, lúc nào cũng đòi hỏi phân tính tỉ mỉ và chu đáo. Thỉnh thoảng họ lại hiện lên và làm nổ ra những đoạn hội thoại vô cùng hữu ích, có khi rất dài, cũng có lúc thật ngắn gọn, giúp cho bạn đọc vừa được thư giản, vừa tăng thêm chiều sâu tư duy cho nội dung được bàn tới. Có thể rất nhiều câu hỏi quan trọng của bạn sẽ được Otto và Anna trả lời hoặc khơi mào giúp.

Một đặc sắc nữa cuốn cuốn sách có lẽ là nằm ở các tình huống nghiên cứu được chọn lựa. Là một cuốn sách đậm tính triết lí, Lean Mindset vẫn có thể thu hút người đọc với những phân tích đa chiều và sâu sắc ở rất nhiều tình huống thực tiễn, như trường hợp của Intel, WIKISPEED, CareerBuilder, hay của Spotify. Những phân tích này thậm chí có thể gợi ý những quy trình công việc thực thụ cho những nhà lãnh đạo và quản lí doanh nghiệp.

Bất chấp nhiều ưu điểm như nhận xét bên trên, bạn đọc có thể gặp một số khó khăn nhất định nếu chưa một lần tìm hiểu qua Tinh gọn là gì. Cuốn sách này không tập trung định nghĩa nó, hay giúp người đọc có thể “triển khai” tư tưởng tinh gọn vào công việc (như ba tập sách trước từng làm). Vì vậy, có thể cuốn sách này sẽ kén người đọc hơn, vớt ít kì vọng “sát mặt đất” hơn.

Để kết thúc việc giới thiệu một cuối sách còn mới, còn chờ thời gian thẩm định độ hay/dở, chúng ta cùng nhau “thưởng thức” một vài câu hỏi hay được rút ra từ trong sách:

1. Bạn đang làm công việc gì? Mục đích của công ty bạn là gì? Điều gì tạo cảm hứng để bạn làm việc mỗi sáng sớm? Nó có tạo cảm hứng cho người khác không?
2. Thử tưởng tượng tuần sau tất cả mọi người trong nhóm của bạn trúng xổ số. Liệu họ có tiếp tục đi làm không? Điều gì khiến môi trường làm việc của bạn hấp dẫn mọi người làm việc hết mình, ngay cả khi họ đã trúng số độc đắc?
3. Nếu được chọn chỉ một thử thách để tạo cảm hứng cho tất cả tổ chức làm việc tốt nhất, nó sẽ là cái gì?
4. Có bao nhiêu phần trăm nhân viên trong công ty bạn được xếp vào dạng “đầy năng lượng”? Làm gì để họ được như thế?
5. Thử tưởng tượng công ty bạn sẽ có một CEO mới trong nay mai, theo bạn thì cô ấy nên làm gì trước tiên?
6. Thử tưởng tượng bạn được đề nghị thiết kế lại sản phẩm lõi của công ty. Nó sẽ trông như thế nào?
7. Năng suất” có ý nghĩa như thế nào trong công ty của bạn? Bạn đo nó như thế nào? Nó có mối liên hệ như thế nào với “hiệu suất” tổng thể của công ty?

Xin mời!

PS. Trên TapChiLapTrinh.vn có một số tổng hợp về Tinh gọn, bạn có thể tìm hiểu thêm sơ bộ về tinh gọn (Lean) là gì: ở đây. 

Giới thiệu sách “Agile for Dummies”

Bìa sách “Agile for Dummies”

Viết sách cho kẻ ngốc (thể loại ‘For Dummies’) có thể là thể loại khó viết bậc nhất, vì luôn phải giữ sự đơn giản và dễ hiểu tối đa, trong khi không được làm mất đi tính đúng đắn của các khái niệm (đôi khi rất phức tạp).

Tuy nhiên, không phải lúc nào cũng thế: các ý tưởng Agile vốn đã khá tự nhiên và dễ hiểu. Nhiều người chỉ cần bắt đầu tìm hiểu Agile với  gần 700 từ trong Agile Manifesto và một trang ‘đính kèm’ “Twelves Principles Behind the Manifesto”. Còn tác giả của Scrum, một phương pháp Agile thiên về quản lí phổ biến nhất, được mô tả trong hơn chưa đến 20 trang Scrum Guide (Hướng dẫn Scrum), Ken Schwaber từng nói “Scrum works for idiots” (“Đần mấy cũng dùng được Scrum”).

Nói là như vậy, nhưng như thế không có nghĩa là ngày nay chúng ta không cần có một quyển sách ngắn gọn giới thiệu tổng quan về Agile, vì lĩnh vực này đã có hơn hai chục năm phát triển với rất nhiều phương pháp, nhiều cách tiếp cận rất đa dạng như chính tinh thần của Agile vậy. Thật may là chúng ta có quyển sách mỏng chưa đến trăm trang với tựa đề “Agile cho kẻ ngốc” (Agile for Dummies) của Scott W. Ambler và Matthew Holitza do IBM ấn hành và phát miễn phí trên mạng.

Cuốn sách mỏng là tập hợp những cắt nghĩa hết sức ngắn gọn về các phương diện chủ yếu của Phát triển Phần mềm Linh hoạt (Agile Software Development): nó đến từ đâu, các vai trò chính yếu, vòng đời phát triển phần mềm, các kĩ thuật chính yếu của Agile.

Scott Ambler cũng kịp “quảng bá” cho cách tiếp cận Agile của riêng mình, có tên Disciplined Agile Development, trong cả một chương 5 và tản mát trong các chương khác. Dường như đó cũng là cách mà Scott Ambler và một số đồng nghiệp đã “thích ứng” để Agile giúp cho IBM “linh hoạt hóa” thành công. Câu chuyện về chuyển đổi linh hoạt của IBM hơi có mùi quảng cáo cho cuốn sách, nhưng cũng là một chương đáng chú ý. Nó nêu ra một ví dụ thực tiễn để những lãnh đạo ở các công ty có ý đồ áp dụng Agile nghiên cứu và suy xét.

Ở một cuốn sách “sơ lược”, tác giả lại dành cả 2 chương để nói về những sai lầm (Chapter 8: Ten common Agile Adoption Pitfalls) và hiểu lẩm (Chapter 9: Ten Myths about Agile). Thật là một dụng công hữu ích, bởi lẽ người ta hãy còn hiểu lầm (và cả “dụng lầm” nữa) Agile rất nhiều. Có thể đây sẽ là những chỉ dẫn rất thiết thực để giúp người mới đến với Agile tránh được những “đớn đau” không đáng có.

Một cuốn sách cô đọng, dễ hiểu nên đọc cho người mới bắt đầu, không phân biệt đó là developer hay manager.

NHỮNG HIỂU LẦM PHỔ BIẾN VỀ AGILE

1. Agile chỉ là mốt nhất thời

2. Agile rất vô kỉ luật

3. Agile có nghĩa là “không có kế hoạch”

4. Agile có nghĩa là “không có tài liệu”

5. Agile chỉ có nghĩa đối với các nhóm ngồi chung phòng thôi

6. Agile chỉ dành cho nhóm bé tí

7. Agile không phù hợp với môi trường bị pháp luật kiểm soát chặt chẽ

8. Agile có nghĩa là “tôi không biết sẽ chuyển giao cái gì”

9. Agile không phù hợp với chỗ tôi

10. Chỉ cần đội phát triển dùng Agile là được rồi

11. Agile chính là viên đạn bạc, bách phát bách trúng

Trích Chương 10.

Trong Scrum Guide (Hướng dẫn sử dụng Scrum), có một mẩu thông ting đáng chú ý thế này nhưng ít người quan tâm:

Scrum được xây dựng dựa trên lý thuyết quản lý tiến trình thực nghiệm , hay “thực nghiệm luận”(empiricism, hay “duy nghiệm”). Lý thuyết này chỉ ra rằng tri thức đến từ kinh nghiệm và việc ra quyết định được dựa trên những gì đã biết. (“Scrum is founded on empirical process control theory, or empiricism. Empiricism asserts that knowledge comes from experience and making decisions based on what is known. “)

Điều này có hệ trọng gì không?

Người thực hành (practictioner) thường quan tâm đến các phương pháp thực hiện (practices) hơn là lí lẽ rườm rà. Chính vì thế đôi khi quên mất môt vài giả định lí thuyết quan trọng. Và lí thuyết EMPIRICISM (thực nghiệm luận), cái đặt nền móng cho các biện pháp thực hành của Scrum chính là một thứ hay bị bỏ quên như vậy.

Vậy, trước hết, thực nghiệm luận là gì?

Như trong phần trích dẫn Scrum Guide trên đây, triết thuyết này tin rằng mọi tri thức trên đời đều phát sinh từ kinh nghiệm, một nhận thức nào đó là đúng hay sai cần được kiểm định qua bằng chứng. Đi xa hơn, các nhà thực dụng luận (pragmatism) còn nói rõ hơn về sự liên hệ giữa các ý tưởng và kinh nghiệm. Một ý tưởng là đúng nếu nó có tác dụng. Các ý tưởng đúng là các ý tưởng chúng ta có thể tiếp thu, chứng minh giá trị, củng cố và kiểm chứng.

Thực nghiệm luận ra đời trong sự phê phán thuyết duy lí (rationalism, với dấu ấn lớn của của Descartes). Các nhà lí luận duy lí cho rằng lí trí của con người có khả năng nắm bắt chân lí cơ bản về thế giới mà không cần sự giúp đỡ của giác quan. Đây là thế giới quan nổi bật trong suốt một thời gian dài từ thời đại cách mạng công nghiệp, thời kì cơ giới hóa tại châu Âu. Quan điểm cơ giới hóa còn ảnh hưởng mạnh mẽ lên cách tư duy, làm việc suốt một thời gian dài sau đó tới đầu thế kỉ 20. Chủ nghĩa Taylor về quản lí (được biết tới với cái tên Scientific Management) là một đại diện tiêu biểu.

Các nhà sáng tạo Scrum chịu ảnh hưởng quan điểm của Nonaka, vốn quan niệm việc phát triển phần mềm là một công việc tạo tri thức mới (creating knowledge), một nhóm Scrum là một tổ chức kiến tạo tri thức (creating knowledge organisation), thì các nhóm Scrum cần phải tiến hành quản lí tiến trình thực nghiệm (empirical process control) để liên tục phát sinh tri thức mới qua thời gian thông qua các kinh nghiệm trực tiếp với công việc, các bằng chứng về tri thức đã được kiến tạo. Thay vì sử dụng cách thức quản lí tiến trình dưới hình thức võ đoán (predictive), việc quản lí tiến trình thực nghiệm rút ngắn các phân đoạn hoạt động để có được nhiều phản hồi về công việc đang làm hòng kiểm chứng việc nào là đúng, việc nào là hiệu quả để tính các bước tiếp theo. Các bước nhỏ này giúp cho quá trình phát triển vừa chắc chắn, vừa linh hoạt; đúng ngay từ sớm, và càng ngày càng đúng.

Đối lập với cách thức tổ chức công việc theo lối thực nghiệm này là hình thức mang nặng hình thức cơ giới (mechanism), theo đó việc phát triển phần mềm được coi là một quá trình cơ giới, có thể tự động hóa được(engineering). Kế hoạch sẽ được lập chi tiết, giải pháp được tính toán trước, mọi việc “thi công” theo sau là tự động, xếp đúng người đúng chuyên môn đúng việc, thì việc hoàn thành công việc được cho là sẽ hiển nhiên (plan-driven). Như Peter Drucker chỉ ra từ rất sớm, lối tiếp cận theo chủ nghĩa Taylor này gặp nhiều thử thách và bất ổn trong các công việc đòi hỏi sáng tạo (như phần mềm chẳng hạn).

Mô hình SECI về kiến tạo tri thức của Nonaka

Thế thì, giả định về “thực nghiệm” quan trọng như thế nào?

Điều quan trọng là thế này: nếu lấy “thực nghiệm” là gốc, ta sẽ phải từ bỏ các quán tính truyền thống về kế hoạch chi tiết và làm việc dựa theo kế hoạch dài hơi (plan-driven), cũng như từ bỏ các nỗ lực để đạt các thiết kế hoàn chỉnh ngay từ đầu (big design up-front). Thêm nữa, đã giả định là “thực nghiệm” thì các nỗ lực phát triển sẽ phải theo thiên hướng baby-steps, làm đến đâu kiểm thử đến đấy (TDD/BDD/ATDD), chuyển giao và phản hồi liên tục, phải chuyển giao theo hình thức tăng trưởng (increment) và tiến hóa (evolutionary)…Các định hướng này thể hiện bản chất việc phát triển phần mềm (nói cách khác: kiến tạo tri thức mới) là quá trình học hỏi, lập kế hoạch và thích ứng dựa trên các kinh nghiệm thực tiễn mà chính đội ngũ phát triển phải thực hiện.

Do vậy, những người nào làm Scrum mà vẫn bám lấy Waterfall thì thực ra là đang dùng động cơ V8 gắn vào một chiếc xe bò vốn không tương thích về cách vận hành. Những nỗ lực này chỉ giúp an ủi phần nào về tính hiệu quả hay linh hoạt ngắn hạn,  chứ không thể dẫn đến một hiểu biết và năng lực đầy đủ về Scrum.

Câu hỏi thử thách cuối cùng, giả định về duy nghiệm đó có thực sự cần giữ hay không khi mà cái người thực hành quan tâm là kết quả công việc? Scrum cũng chỉ là công cụ cho một business nào đó thôi, chứ có phải cái đích đâu? Tôi thấy ScrumBut là đủ chứ sao?

Vâng, giữa bạt ngàn các công cụ và phương pháp, bạn luôn có quyền lựa chọn. Nhưng hãy sử dụng cho đúng, nếu không thỉ chỉ tổ phí thì giờ.

1. Một năm sôi nổi

Cùng với AgileTour HCM đã thực hiện lần thứ 3, AgileTour Hà Nội 2013 đánh dấu thời điểm Việt Nam thành nơi đầu tiên ở Đông Nam Á có nhiều hơn 1 thành phố tổ chức AgileTour.

Cùng với các sự kiện đáng ghi nhận khác của cộng đồng Agile tại Việt Nam với sự dẫn dắt của Agile forum Vietnam và Hanoi Scrum (là hai phân nhánh của Agile Vietnam) như ScrumDay tại Hà Nội, Summer Coderetreat nối cầu truyền hình Hà Nội – SG, Kaizen Camp tại HCM, Lean Mindset workshop tại Hà Nội và Tp. HCM, và AgileRetreat ở Lâm Đồng hồi cuối tháng 9, có thể thấy Việt Nam đang là địa điểm sôi động nhất của Agile khu vực Đông Nam Á.

2. Nốt vui

Anh Thắng Founder của BraveBits – nhà tài trợ cho AgileTour HN – cho biết: “hoạt động workshop lần này cực kì ấn tượng, đánh mạnh vào tư duy làm mình thay đổi hoàn toàn”. Anh không quên nhắn lại “lần sau làm gì cứ gọi nhé”.

Cô Ane, vợ anh bạn Alexandre Cuva – một trong hai diễn giả chính của AgileTour HN, có khen: sinh viên của các bạn quá siêu vì có thể nghe và nói trực tiếp bằng tiếng Anh với hai diễn giả có tốc độ nói và accent khá khó nghe từ Thụy Sĩ và Nhật Bản. Trong số những người được khen này, có vài sinh viên đang học của FPT University (gồm cả FPT Aptech), thật là tín hiệu rất đáng khích lệ.

Gần ở phút cuối của công tác chuẩn bị, bạn Phương tình nguyện tham gia đóng góp sức mình vào công tác cộng đồng. Sự nhiệt tình và chất lượng công việc của cá nhân Phương cũng góp phần không nhỏ vào sự thành công của sự kiện. Có lẽ ông giời đã rất ưu ái vụ này cho bọn còn lại ở HanoiScrum đang lao đao vì núi việc. Ơn giời!

Những nụ tười xua tan giông bão (Ảnh: Tú NN):

3. Nốt trầm

Điều đáng tiếc lớn nhất có lẽ là ở VN chưa có một Certified Trainer/Coach nào. Tức là sự phát triển nghề nghiệp hãy còn ở mức phong trào, các cá nhân làm việc ở mức hobbies chứ chưa phải chuyên nghiệp.

Song song với điều đáng tiếc lớn nhất đó là một khoảng trống mênh mông về những hoạt động chuyên môn kĩ thuật Agile tại Việt Nam. Cách đây không lâu, một người bạn ở Tiki có nhận xét “cộng đồng startup hiện nay vẫn cứ quẩn quanh ở mức ý tưởng và chém gió, còn cái thực là năng lực làm sản phẩm, năng lực lập trình thì lại không để ý; các cuộc meetup chỉ là nơi quảng cáo và networking thì không thể nào có startup mạnh được, không thể nào có sản phẩm tốt được”. Kì này Hoàng Anh ở Officiene cũng có một nhận xét như thế về hai kì AgileTour mà cô ấy tham gia: thiếu vắng những hoạt động chuyên sâu về kĩ thuật. Quả đúng như vậy: phiên Mini Codetreat của Đới tại AgileTour SG lần này chỉ có chưa đầy 10 người tham dự, kì Summer Coderetreat với đầu cầu SG chỉ gồm ba lập trình viên. Ở Hà Nội, tình hình có khá hơn một tí xíu: Summer CodeRetreat thu hút gần 50 lập trình viên tham dự, CodingDojo tại sàn CocoDojo thu hút từ 10-20 lập trình viên mỗi hai tuần /1 lần. Đó là chưa kể đến các “sàn luyện code” khác ở công ty VNEXT hay ở Đại học FPT phân khu Hòa Lạc. Tuy thế, chỉ coding dojo và refactoring dojo vẫn chưa đủ.

Có lẽ cần thêm những hoạt động khác, theo hướng chuyên nghiệp hóa …

4. Nốt lặng

Bão Hayan đánh phá tan hoang Phillipines, uy hiếp các tỉnh duyên hải Việt Nam, làm thay đổi lịch trình bay của mình, và … làm chương trình AgileTour 2013 bắt buộc phải đổi ở phút chót vì Xu Yi cùng với Dieter Kaufhold không thể tham dự.

Kì này, ai cũng phải ứng phó với bão, cả AgileTour HN.

Hôm nay ngày HanoiScrum tròn 2 năm “lên sóng”.

Chúng tôi kỉ niệm bằng sự ra đời của phong trào“Nghề Thủ công Phần mềm” tại Việt Nam. Nghe lạ nhỉ, sao lại kết hợp cổ kim thế được. Các bác đọc ở trang liên kết nhé.

Còn tôi kỉ niệm bằng vài dòng này, không ảnh, không màu mè và một kỉ niệm liên quan đến phần mềm vĩ đại trong kỉ nguyên của Mai cờ rô xốp: Windows 8.

Đến giờ phút này thì tôi có thể yên tâm mà dùng Windows 8 trên chiếc Vaio SA đã mua từ năm ngoái sau một tuần ròng rã backup, restore, upgrade, patch và cài cắm. Một tuần cơ đấy! Vừa cài vừa lầu bầu…

Mới sáng nay thôi, bấm phải chuột trên desktop phải đợi gần 1 phút cái trình đơn mới hiện ra. Bụng bảo dạ: các chú MS dạo này điên thật rồi, 5000 tester mà chỉ có thế thôi ư? Không biết các chú có ngó sang xem bọn Android nó làm ăn thế nào mà thao tác upgrade chỉ mất có hai ba tiếng là xong, không mất một chút dữ liệu nào, không phải cài lại cái App nào mà vẫn có hệ điều hành hoàn toàn mới để dùng? MS ra cái nông nỗi thế rồi à?

Nhưng nghĩ lại có khi khác: có thể tại các chú MS chủ ý dùng khổ nhục kế. Bằng chứng là mình đây: sau một tuần cặm cụi cài cắm và tổ chức lại dữ liệu thì có cho thêm tiền mình cũng chẳng dại gì restore về Win7 để dùng.

Là một cách để giữ khách chăng? Ai mà biết được hehe.

Đầu thế kí trước, nhà bác học đa năng đại tài Poincaré từng kinh ngạc khi nghiên cứu bài toán ba vật thể: không thể đoán được quỹ đạo chuyển động của chúng khi chạm nhau. Ông là người khai sinh tư duy về phức hợp (complex) và lí thuyết hỗn độn (chaos theory).

Có ba vật mà đã thế, con người gồm hàng tỉ tỉ các thành tố thì sao?

Một nhóm người thì sao?

Một xã hội thì sao?

Chúng đều phức hợp đến không đoán định nổi. Rất hỗn độn. Đừng có ảo tưởng về một trật tự tất định trong các hoạt động của con người (và cả tự nhiên). Khả năng tiên đoán dài hạn là một thứ liên quan đến niềm tin nhiều hơn là kĩ thuật.

Giờ thì tôi triệt để nghi ngờ tất cả các kĩ thuật tiên lượng cái gì đó tính theo đơn vị năm. “Năm năm nữa chúng ta sẽ …” là một mệnh đề không nên quan tâm.

Cách duy nhất để biết được phần nào là “làm đi” rồi thì biết hittad på den här sidan. Và cũng chỉ tiên lượng trong chu kì rất ngắn. Mối nhân quả ngắn hạn.

***

Lí thuyết về phức hợp vậy ra cũng đã có lịch sử trên một thế kỉ. Như hình dưới đây tôi đã từng kể ra trong một buổi thuyết trình rất rắm rối và khó hiểu với mọi người:

Các nghiên cứu về hệ phức hợp, ra quyết định phức hợp, tư duy phức hợp hiện chưa nhiều lắm. Người ta vẫn dự cảm là “tư duy phức hợp” liên ngành, “tích hợp” sẽ là tư duy của thì .. tương lai, chứ không phải của thì hiện tại.

Mặc dù có nhiều khuôn khổ (framework) cho công việc được vận hành phần nào đó theo tư duy phức hợp (như self-organizing team trong Scrum chẳng hạn). Từ phức hợp là điều gì đó còn rất lạ lẫm với mọi người.

Kể cả góc nhìn về sự phức hợp cũng còn rất khác xa nhau. Như hai hình dưới dưới đây cho thấy có ít nhất hai hình dung về các phân vùng với “độ phức hợp” khác nhau mà tôi đã có dịp đăng rải rác trong blog này.

Cynefine Framework (Ảnh: Wikipedia) – về sự phức hợp

Stacey Graph – Về sự phức hợp

Câu hỏi là: phức hợp là gì nhỉ?