“Phương pháp cải tiến Agile” là cụm từ xuất hiện nhiều trong những năm gần đây. Các nhóm kỹ sư phần mềm khi sử dụng Agile thay cho các phương pháp truyền thống khiến cho công việc hiệu quả hơn rất nhiều. Họ khiến khách hàng hài lòng hơn. Bản thân họ cũng cảm thấy thích công việc của mình hơn. Agile đã góp phần không nhỏ trong sự phát triển các phần mềm, và nhiều chuyên gia tin rằng nó đang sẵn sàng để vượt qua biên giới ngành Công nghệ Thông tin (CNTT).
Nhưng trớ trêu thay, khởi điểm của Agile không phải là ngành CNTT.
Một số người tìm thấy dấu vết về các phương pháp luận của Agile ở phương pháp khoa học của Francis Bacon (nhà triết học, chính khách người Anh) từ năm 1620. Một phát hiện thú vị khác về nguồn gốc của Agile là mô hình PSDA (Plan-Do-Study-Act) được nhà vật lý học, nhà thống kê Walter Shewhart áp dụng vào cải tiến sản phẩm và quy trình sản xuất. Shewhart đã dạy lại mô hình vòng lặp và tăng trưởng cho học trò của mình – W. Edwards Deming, người đã sử dụng chúng rộng rãi ở Nhật Bản trong những năm sau Thế chiến II. Toyota đã thuê Deming đào tạo hàng trăm nhà quản lý của công ty, sau đó tận dụng những kinh nghiệm của mình để phát triển Hệ thống sản xuất nổi tiếng của Toyota – nguồn gốc của tư duy “tinh gọn” (“lean” thinking) hiện nay. Các phương pháp lặp lại và theo chiều hướng tăng tiến đóng vai trò quan trọng dẫn tới thành công trong việc chế tạo máy bay phản lực X-15 vào những năm 1950.
Vào năm 1986, hai tác giả Takeuchi và Ikujiro Nonaka đã viết một bài báo được in trên tạp chí Harvard Business Review (HBR) có tên gọi là “Trò chơi phát triển sản phẩm mới”. Nhiều nhà sản xuất có tốc độ đưa ra rất nhiều những sáng kiến mang tính đột phá nhanh hơn đối thủ cạnh tranh, tác giả đã chỉ ra rằng việc tất cả các cá nhân trong đội đều có quyền tham gia vào cả dây chuyền đã thay đổi quá trình thiết kế và phát triển cho các sản phẩm như máy photocopy tại Fuji-Xerox, động cơ ô tô tại Honda và máy ảnh tại Canon. Thay vì theo các phương pháp thông thường – khi một nhóm hoàn thành công việc của mình và chuyển sang cho nhóm khác, các công ty này đã sử dụng cái mà Takeuchi và Nonaka gọi là phương pháp “bóng bầu dục – cả đội cùng cố gắng tham gia vào tất cả các khâu trong cả quá trình”.
Năm 1993, Sutherland đã phải đối mặt với một trường hợp khó khăn: Easel Corporation, một công ty phần mềm, cần phát triển một sản phẩm mới để thay thế các sản phẩm kế thừa của chính nó trong vòng chưa đầy sáu tháng. Sutherland đã có một nền tảng vững chắc về các phương pháp như phát triển ứng dụng nhanh, thiết kế hướng đối tượng (object-oriented design), mô hình PDSA và skunkworks (thường là một nhóm nhỏ có trách nhiệm phát triển một cái gì đó trong một thời gian ngắn với những hạn chế quản lý tối thiểu. Đôi khi, skunkworks bí mật tập trung vào một sản phẩm mới, sau đó sẽ được phát triển theo quy trình thông thường). Ông hy vọng tạo ra nền văn hoá skunkworks ở ngay trong bản thân doanh nghiệp, pha trộn những lợi ích của việc phân bổ và tích hợp các chức năng/phòng ban trong doanh nghiệp. Vì vậy, ông bắt đầu bằng cách học tất cả mọi thứ có thể về tối đa hóa năng suất. Đọc hàng trăm bài báo và phỏng vấn các chuyên gia quản lý sản phẩm hàng đầu, ông thấy mình bị mê hoặc bởi nhiều ý tưởng mới lạ.
Một ý kiến khác cho rằng các cuộc họp nhóm ngắn hàng ngày làm tăng năng suất nhóm một cách đáng kể. Vay mượn nhiều ý tưởng chính của các bài báo HBR và đưa vào các thực tiễn hoạt động cụ thể, Sutherland đã tạo ra một cách tiếp cận mới mà ông gọi là “Scrum”. Scrum cho phép ông hoàn thành những dự án dường như không thể thực hiện đúng thời hạn, thiếu ngân sách, và gặp ít lỗi hơn bất kỳ phiên bản nào trước đó. Sau đó, ông cộng tác với đồng nghiệp lâu năm Ken Schwaber để soạn thảo cách tiếp cận này, và vào năm 1995, lần đầu tiên Scrum được giới thiệu với công chúng.
Dĩ nhiên, Sutherland và Schwaber không đơn độc trong việc tìm kiếm các phương pháp cải tiến. Khi đó thời đại thông tin bùng nổ. Các công nghệ mới nổi (disruptive technology) đã làm chao đảo vị thế của đối thủ cạnh tranh. Những người khởi nghiệp và những nhà chức trách cũng phải tìm cách thích nghi với môi trường không quen thuộc và hỗn loạn. Phần mềm ra đời nhằm đáp ứng mọi nhu cầu phát sinh của doanh nghiệp, và các nhà phát triển phần mềm sáng tạo đã làm việc chăm chỉ để đưa ra phương pháp lập trình tốt hơn, tăng khả năng thích ứng của phần mềm.
Năm 2001, 17 nhà phát triển đã gặp nhau ở Snowbird, Utah, để chia sẻ ý tưởng của họ. Sutherland và những người đề xướng cuộc tranh luận khác cũng nằm trong số đó. Nhưng nhóm cũng bao gồm những người ủng hộ một số phương pháp khác mang tính cạnh tranh với nhau, bao gồm lập trình XP (extreme programming); phát triển phần mềm thích ứng (ASD – adaptive software development); phát triển theo đặc tính (FDD – feature-driven development); và phương pháp phát triển hệ thống (DSDM – dynamic-systems-development method). Tất cả các phương pháp này dễ hiểu và dễ áp dụng hơn bởi vì chúng ít nguyên lý, điều này cho phép sự thích ứng nhanh chóng với những thay đổi từ môi trường xung quanh. Nhưng rất ít người cảm thấy sự “dễ hiểu và dễ dùng” này là một bước tiến.
Mặc dù họ bất đồng quan điểm trên nhiều phương diện, nhưng cuối cùng họ thống nhất được một cái tên chung: Agile. Từ này được đề xuất bởi một người tham dự đã đọc cuốn sách “Agile Competitors and Virtual Organizations: Strategies for Enriching the Customer”. Cuốn sách đã đưa ra 100 ví dụ về các công ty – bao gồm ABB, Federal Express, Boeing, Bose và Harley-Davidson – đây là những công ty đang tìm cách tạo ra những cách thích nghi mới trong tình hình thị trường ngày càng hỗn loạn. Những người tham dự sau đó đã tạo ra sự đồng thuận về một thứ gọi là “Bản tuyên ngôn phương pháp phát triển phần mềm Agile”, giải thích rõ ràng bốn giá trị quan trọng mà mọi người đồng ý. Trong vài tháng tiếp theo, họ đã phát triển 12 nguyên tắc hoạt động, được gọi là “Nguyên lý đằng sau Tuyên ngôn Agile”. Từ năm 2001, tất cả các khuôn khổ phát triển phù hợp với các giá trị và nguyên tắc này được gọi là các kỹ thuật Agile.
Sau khi cuộc họp Snowbird đã đặt ra nguyên lý phát triển cho phương pháp cách tân Agile, phương pháp này đã nhanh chóng lan rộng. Phần lớn các thành viên tham dự ban đầu, cùng với một số cộng sự mới, đã cùng họp lại vào cuối năm để thảo luận về cách phổ biến các nguyên tắc Agile ra công chúng. Tất cả đều đồng ý rằng họ sẽ viết và tổ chức những buổi diễn thuyết về Agile. Một số người muốn thành lập một nhóm làm việc thường trực hơn; vì vậy họ thành lập một tổ chức phi lợi nhuận gọi là Agile Alliance để hỗ trợ phong trào sử dụng phương pháp này. Ngày nay, Agile Alliance có gần 30.000 thành viên và người đăng ký.
Trong khi đó, các phương pháp luận Agile tiếp tục phát triển. Cuối những năm 1980 và đầu những năm 1990, các nhà nghiên cứu từ Viện Công nghệ Massachusetts (MIT) đã bắt đầu nghiên cứu hệ thống sản xuất của Nhật Bản, đặc biệt là hệ thống sản xuất của Toyota. Họ đã đặt ra khái niệm “Lean” (Tinh gọn) để mô tả các phương pháp cải thiện năng suất của hệ thống sản xuất bằng cách loại bỏ “muda” – sự lãng phí, hiệu quả thấp mà chi phí cao thông qua cắt giảm “mura” – sự không nhất quán, bất ổn định trong luồng công việc, và “muri” – sự quá tải. Mặc dù phương pháp luận Lean không được trình bày dưới dạng khuôn khổ Agile trong cuộc họp ở Snowbird, các hệ thống Lean và Kanban đã phát triển chính thức trong những năm 2000. Lúc đầu, một số nhà tư tưởng Agile thuần túy từ chối nhìn nhận những phương pháp này là Agile. Tuy nhiên, những người ủng hộ Lean đã tranh thủ được sự ủng hộ của người sử dụng, và cuối cùng, Lean, Kanban, Hybrid (như Scrumban và Lean Scrum) được chấp nhận như các ứng dụng hợp pháp của các giá trị và nguyên tắc Agile.
Nguyên tắc Agile có một quá trình phát triển đồ sộ trước khi được sử dụng rộng rãi như ngày nay. Trong khi các phương pháp phái sinh từ nguyên tắc Agile đôi khi tạo ra những cuộc tranh luận sôi nổi giữa những người thực hành Agile, thi hai điều rõ ràng nhất ở đây: đầu tiên, nguồn gốc của Agile vượt xa khỏi biên giới ngành công nghệ thông tin, và thứ hai, các chi nhánh của Agile sẽ tiếp tục lan rộng để cải tiến quy trình đổi mới trong hầu hết mọi chức năng của bất kỳ ngành công nghiệp nào.
Source: Saga