10 qui tắc đơn giản

Tháng giêng, năm 2011, trên tạp chí “Harvard Business Review ” xuất hiện một bài báo có tiêu đề ‘Chiến lược là các quy tắc đơn giản’. Tác giả của nó – Kathleen Eisenhardt đã mô tả làm thế nào một công ty thông minh phát triển mạnh trong môi trường kinh doanh phức tạp bằng cách thiết lập một tập hợp các quy tắc đơn giản để định hướng mà không giới hạn nó. [2] Bà đề nghị rằng thay vì quy trình phức tạp, sử dụng những quy tắc đơn giản trong chiến lược truyền thông là cách tốt nhất để trao quyền cho mọi người. Điều này giúp họ nắm bắt cơ hội chớp nhoáng trong sự thay đổi nhanh chóng của thị trường.

Những năm 1980 là thời gian có sự thay đổi sâu sắc trong sản xuất ở Mỹ, và sự thay đổi đã được hướng dẫn bởi một tập các quy tắc đơn giản. Quy tắc đơn giản đưa ra hướng dẫn cho tất cả các cấp của tổ chức, và đã khiến cho tất cả mọi người “hòa cùng bản nhạc” (same sheet og musics). Các quy tắc đó trao quyền cho những người ở tất cả các cấp của tổ chức, bởi vì chúng cung cấp các hướng dẫn cho việc thực hiện các quyết định hàng ngày. Với quy tắc đơn giản, các nhóm làm việc có thể tiếp tục cải tiến các quy trình và các sản phẩm mà không cần có những hướng dẫn chi tiết hoặc quy trình phức tạp.

Các thực hành cơ bản của Lean Manufacturing (Sản xuất Tinh gọn) và TQM trong năm 1980 có thể được tóm tắt trong những quy tắc đơn giản sau:

• Loại bỏ lãng phí
• Giảm thiểu tồn kho
• Tối đa hóa luồng
• Kéo từ nhu cầu
• Trao quyền cho người lao động
• Đáp ứng yêu cầu của khách hàng
• Làm đúng ngay từ đầu
• Bãi bỏ Tối ưu hóa Địa phương (Local Optimization)
• Quan hệ đối tác với nhà cung cấp
• Tạo ra văn hoá cải tiến liên tục

Những quy định này của Lean Manufacturing đã được thử nghiệm và chứng minh qua hai thập kỷ qua. Chúng đã được ứng dụng ở lĩnh vực Logistics, dịch vụ khách hàng, chăm sóc sức khỏe, tài chính, và thậm chí cả xây dựng. Việc áp dụng các quy tắc có thể thay đổi một chút từ ngành này sang ngành khác, nhưng các nguyên tắc cơ bản đã được kiểm chứng theo thời gian trong nhiều lĩnh vực của nền kinh tế.

Lập trình tinh gọn

Nghiên cứu gần đây đối với các phương pháp Agile (Phát triển Linh hoạt), Adaptive Software Development (Phát triển Phần mềm Thích ứng), và eXtreme Programming (XP) đều có áp dụng các quy tắc đơn giản của Lean Manufacturing trong phát triển phần mềm. Kết quả là, chúng ta có một thuật ngữ gọi là Lập trình Tinh gọn (Lean Programming), cũng kịch tính như những cải tiến trong sản xuất đã mang về các phong trào Just-in-Time và Total Quality Management (Quản Lý Chất Lượng Tổng Thể) của những năm 1980.

Quy tắc 1: Loại bỏ lãng phí

Nguyên tắc đầu tiên của Lập trình Tinh gọn là: Loại bỏ lãng phí. Đó là, loại bỏ bất cứ điều gì mà không tạo ra giá trị gia tăng cho sản phẩm cuối cùng. Trong Lean Manufacturing, dư thừa được xác định thông qua việc phân tích chuỗi giá trị – một quá trình trong đó xác định tất cả các hoạt động trong chuỗi giá trị và xác định ra hoạt động nào tăng thêm giá trị cho sản phẩm cuối cùng. Quá trình phân tích chuỗi giá trị sau đó cố gắng tìm kiếm sự khác biệt, cách thức hiệu quả hơn để thêm những giá trị gia tăng cho sản phẩm.

Tất cả những tài liệu, bản vẽ, mô hình là một phần của dự án phát triển phần mềm, giúp cho dự án hoàn thành, tuy nhiên lại là thành phần không nhất thiết của sản phẩm cuối cùng. Một khi sản phẩm cuối được bàn giao, người sử dụng cuối ít khi quan tâm đến những tài liệu đó. Các nguyên tắc Lean đề nghị rằng tất cả những phụ liệu đó là một đối tượng để phân tích. Việc phân tích phải đảm bảo được rằng nó không chỉ mang lại các giá trị gia tăng cho sản phẩm mà nó cũng chính là cách làm hiệu quả nhất để đạt được những giá trị đó.

Quy tắc 2: Giảm thiểu tồn kho (Giảm thiểu thành phần trung gian)

Trong nhà máy của chúng tôi, chúng tôi luôn truyền nhau một thông điệp: Hàng tồn kho là chất thải. Tại sao vậy? Hàng tồn kho tiêu tốn các nguồn tài nguyên, làm chậm thời gian phản ứng. Hàng tồn kho ẩn đi các vấn đề về chất lượng, dễ bị mất, giá trị thấp và dễ lỗi thời. ‘Lợi ích’ của hàng tồn kho là luôn có nhiều hàng để bán. Nhưng ‘chi phí’ của hàng tồn kho lại luôn luôn cao hơn ‘lợi ích’ mà nó mang lại.

‘Hàng tồn kho’ của phát triển phần mềm là những tài liệu cái không là một phần của sản phẩm cuối cùng. Giống như hàng tồn kho, những tài liệu này cũng cần phải phân tích giá trị. Ví dụ như tài liệu yêu cầu và thiết kế, thực sự chúng tăng được bao nhiêu giá trị cho sản phẩm cuối cùng? Và chúng quan trọng như thế nào cho sản phẩm? Nếu chúng ta so sánh các tài liệu đó với hàng tồn kho, thì điểm nổi bật cần lưu ý là thời gian cần thiết để tạo ra các tài liệu thiết kế gần bằng với thời gian của chu kỳ dự án. Cũng như hàng tồn kho phải được giảm tối đa để tăng cường một cách tối đa lưu lượng sản xuất, các tài liệu phân tích, thiết kế cũng cần được giữ ở mức tổi thiểu để tối đa hóa luồng phát triển phần mềm.

Có rất nhiều sự lãng phí ở những tài liệu này. Lãng phí thời gian để viết ra các tài liệu. Lãng phí thời gian để xem xét, rà soát chúng, và các công việc liên quan đến thay đổi các yêu cầu, thiết lập ưu tiên và thay đổi hệ thống. Nhưng sự lãng phí lớn nhất đến từ việc xây dựng ra các hệ thống sai nếu các tài liệu không mô tả và phân tích chính xác các yêu cầu của khách hàng.

Phương pháp tốt nhất để giảm thiểu các công việc trung gian là nâng cao mức độ trừu tượng của các tài liệu. Thay vì viết 100 trang tài liệu mô tả chi tiết, hãy viết 10 trang thiết lập các quy tắc và hướng dẫn, và chỉ mô tả chi tiết những trường hợp ngoại lệ. Thay vì viết các đặc tính, hãy tạo ra một ma trận 25 trang tóm tắt các nỗ lực.

Chúng ta biết rằng người dùng ít khi hình dung các chi tiết của hệ thống từ các tài liệu kỹ thuật, thậm chí ít có khả năng để nhận thức một cách chính xác làm cách nào hệ thống hoạt động trong môi trường của họ cho đến khi họ thật sự bắt tay vào sử dụng nó. Thậm chí nếu người dùng có thể dự đoán chính xác hệ thống hoạt động thế nào ở thời điểm hiện tại, cũng khó có khả năng nó hoạt động giống như người ta trông đợi trong cả phần đời còn lại của hệ thống. Tất cả những điều đó phải được xem xét khi chúng ta xác định những tài liệu đó có thật sự mang lại giá trị gia tăng cho sản phẩm hay không.

Quy tắc số 3: Tối đa hóa luồng (Giảm thời gian phát triển)

Trong những năm 80, chúng tôi đã học được cách tạo ra sản phẩm trong vòng vài giờ thay vì vài ngày hay vài tuần như trước đây. Chúng tôi thấy được rằng, dòng sản phẩm nhanh chóng là kết quả của chu kỳ nhanh gọn, thường là thấp hơn từ 1 đến 2 bậc so với trước đây. Trong những năm 90, những dự án e-commerce thường được hoàn thành chỉ trong vài tuần thay vì vài tháng hoặc vài năm như trong thế giới phần mềm truyền thống trước đây. Có thể có một vài trường hợp gian dối, nhưng mấu chốt là, có một số lượng rất lớn các phần mềm được phát triển trong thời gian 5 năm trở lại đây với thời gian phát triển cực ngắn theo tiêu chuẩn truyền thống.

Trong bài báo gần đây có tiêu đề “Giảm thời gian chu kỳ” (Reducing Cycle Time), [2] Dennis Frailey đề xuất giảm thời gian chu kỳ phát triển phần mềm bằng cách sử dụng kỹ thuật tương tự được sử dụng để giảm thời gian chu kỳ sản xuất. Ông đề nghị tìm kiếm và giảm việc chồng chéo của WIP (Work in process). Cũng giống như trong sản xuất, nếu WIP được giảm, thì chu kỳ sản xuất cũng giảm theo. Để giảm WIP, Frailey khuyến cáo sử dụng khái niệm “Small Batch” (Lô nhỏ) và “Smooth Flow Principle” (Nguyên tắc dòng chảy êm ái), những khái niệm trực tiếp từ Lean Manufacturing.

Phát triển lặp về cơ bản là việc áp dụng những nguyên tắc này để lập trình. Tiền đề cơ bản của phát triển lặp là “phần nhỏ nhưng đầy đủ” của hệ thống được thiết kế và bàn giao trong suốt chu kỳ phát triển. Với mỗi lần lặp, lại thêm một tập hợp các tính năng bổ sung. Thời gian chu kỳ từ khi bắt đầu đến khi kết thúc của mỗi lần lặp là từ một vài tuần đến một vài tháng. Với mỗi lần lặp, lại thực hiện các bước từ thu thập yêu cầu đến kiểm thử chấp nhận (acceptance testing).

Quy tắc 4: Kéo từ nhu cầu (Quyết định càng muộn càng tốt)

Trong nhà máy sản xuất băng hình của chúng tôi, chúng tôi từng nghĩ rằng sẽ là lý tưởng nếu phòng marketing có thể dự báo chính xác nhu cầu của thị trường. Rất nhiều công việc đã đi vào kỹ thuật dự báo tinh vi để dự đoán chính xác hơn trong tương lai. Rồi một ngày, chúng tôi nhận ra rằng, chúng tôi đã cố gắng để làm sai. Việc dự đoán chính xác không phải là lý tưởng, mà lý tưởng là ở chỗ chúng ta có thể giảm sự phụ thuộc vào các dự báo bằng cách giảm một cách đáng kể thời gian đáp ứng hệ thống để hệ thống có thể đáp ứng với thay đổi thay vì dự đoán nó.

Trong thị trường công nghệ dễ bay hơi, đòi hỏi phải liên tục nâng cấp sản phẩm, Dell Computer có một lợi thế rất lớn so với đối thủ cạnh tranh bởi vì nó không dự báo nhu cầu mà nó phản ứng lại với nhu cầu bằng cách làm theo đơn đặt hàng trung bình trong 6 ngày. Trong khi Dell chỉ nắm giữ trung bình của 6 ngày hàng tồn kho, đối thủ cạnh tranh phải duy trì đến 6 tuần của hàng tồn kho. Khả năng quyết định càng muộn càng tốt của Dell tạo cho Dell một lợi thế cạnh tranh rất lớn trong một thị trường chuyển động nhanh.

Trong thực hành phát triển phần mềm, bàn giao hệ thống càng gần với sự thay đổi của yêu cầu càng tốt, có thể cung cấp một lợi thế cạnh tranh đáng kểtrong một thị trường thay đổi. Trong môi trường kinh doanh biến động, người sử dụng không có khả năng dự báo tương lai của họ một cách chính xác. Đóng băng các thiết kế ban đầu trong dự án phát triển phần mềm có tính chất đầu cơ như trong dự báo. Hệ thống phần mềm nên được thiết kế để đáp ứng với sự thay đổi, chứ không phải dự đoán nó. Trong phát triển phần mềm, giống như việc sản xuất máy tính, khả năng quyết định càng muộn càng tốt là một lợi thế cạnh tranh.

Quy tắc số 5: Trao quyền cho người lao động (Quyết định ở cấp càng thấp càng tốt)

Một nguyên tắc cơ bản của Lean Manufacturing trao quyền quyết định xuống mức thấp nhất có thể, cung cấp các công cụ và thẩm quyền cho những người “trên sàn” (on the floor) để đưa ra quyết định. Khi Toyota tiếp quản nhà máy sản xuất của GM ở Fremont, California vào năm 1983, họ phải thừa hưởng những người lao động với năng suất và văn hóa xin nghỉ tồi tệ nhất trong ngành công nghiệp. Cũng những người lao động đó đã có năng suất lao động và chất lượng gấp đôi trong vòng hai năm sau đó. Điều này được thực hiện thông qua việc hình thành của các đội được đào tạo về các kỹ thuật cải thiện và đo lường công việc, và được kỳ vọng để tự phát triển và liên tục cải tiến các tiêu chuẩn làm việc của bản thân. [4]

Một trong những vấn đề với tài liệu nặng nề, là nó cố gắng để ra các quyết định thay cho các lập trình viên, chứ không phải cho họ một bộ các hướng dẫn. Nói chung, nâng cao mức độ trừu tượng của tài liệu sẽ cung cấp cho các lập trình viên hướng dẫn cũng như sự tự do để họ tạo ra các thiết kế chi tiết và tự đưa ra các quyết định khi lập trình. Sẽ là tốt hơn nếu nói với các lập trình viên cần phải làm những gì, chứ không phải làm thế nào.

Lập trình viên cần phải hiểu rõ mục đích của công việc của họ và làm thế nào nó phù hợp với tổng thể dự án, những gì cần phải làm để đáp ứng yêu cầu của khách hàng. Họ cần hiểu được kiến trúc và giao diện tiêu chuẩn của hệ thống. Họ cũng cần phải biết những gì họ phải thực hiện, khi nào phải hoàn thành, và có thể dự đoán trước khi nào nó có thể sẽ kết thúc. Cuối cùng, công việc của họ có thể được nhìn thấy trong từng chu kỳ lặp để cung cấp các thông tin phản hồi cần thiết cho việc cải tiến liên tục.

Quy tắc số 6: Đáp ứng yêu cầu của khách hàng (Bây giờ và trong tương lai)

Trong cuốn “Chất lượng là miễn phí” (Quality is Free), Philip Crosby định nghĩa chất lượng là “đáp ứng yêu cầu của khách hàng”. Nghiên cứu của nhóm Standish Group vào năm 1994 [5] lưu ý rằng, nguyên nhân phổ biến nhất của các dự án bị thất bại là do bị thiếu, không đầy đủ hoặc không đúng yêu cầu. Thế giới phát triển phần mềm đã đối phó với nguy cơ này bằng cách khuếch đại việc thu thập yêu cầu người dùng một cách thật chi tiết trước khi hệ thống được thiết kế. Tuy nhiên đây là cách tiếp cận mắc sai lầm lớn trong việc xác định các yêu cầu của người dùng.

Tôi đã từng làm trong một dự án trong đó khách hàng muốn một hệ thống phức tạp trong vòng 10 tháng. Thời gian là điều tối quan trọng, 10 tháng hoặc là không gì hết. Và tất nhiên, là một cơ quan nhà nước, nên trong hợp đồng yêu cầu phải có một tài liệu thiết kế bên ngoài trước khi có thiết kế bên trong và viết mã nguồn. Rất nhiều người dùng đã phải tham gia, và rất khó khăn để có chữ ký của họ vào trong tài liệu thiết kế đó. Tại sao? Họ lo ngại rằng họ đang chấp thuận cho một thiết kế mà sau đó sẽ trở thành một sai sót của hệ thống. Bởi vì không hề là đơn giản để thay đổi các thiết kế sau khi nó được ký chấp thuận. Chúng tôi phải mất 2 tháng để hoàn thành bản thiết kế đó. Và làm sao có thể đổ lỗi cho họ đây? Công việc của họ là phụ thuộc vào việc làm sao để có sự chuẩn xác. Vì vậy, chúng tôi đã lãng phí hơn hai tháng làm việc và rất nhiều giấy tờ trong việc lấy chữ ký của những người sử dụng.

Thay vì khuyến khích sự tham gia của người sử dụng, việc ký vào các giấy tờ đó đã tạo ra một môi trường thù địch giữa các nhà phát triển phần mềm và người sử dụng. Người sử dụng bị yêu cầu phải ra quyết định sớm trong quá trình phát triển, và không được phép thay đổi nó, trong khi họ còn không biết hệ thống sẽ hoạt động ra sao, hoặc tình hình kinh doanh của họ có thể thay đổi như thế nào trong tương lai. Có thể dễ dàng hiểu được tại sao họ lại ngại ký vào các bản thiết kế đó, và muốn trì hoãn việc ký càng muộn càng tốt. Lưu ý rằng, bản năng này là phù hợp với quy tắc số 4 đã nêu ở trên.

Cách thức hiệu quả nhất để nắm bắt chính xác các yêu cầu của người sử dụng được tìm thấy trong phương pháp lặp của việc phát triển hệ thống. Bằng cách phát triển các tính năng cốt lõi sớm và có được các thông tin phản hồi của khách hàng trong một buổi demo của mỗi quá trình lặp, chúng ta có thể thu thập được các yêu cầu của khách hàng một cách chính xác hơn rất nhiều. Thêm vào đó, nếu chúng ta chấp nhận rằng các yêu cầu có thể thay đổi theo thời gian, chúng ta phải bắt đầu với những yêu cầu quan trọng nhất mà hệ thống cần phải được thiết kế để dễ dàng thích ứng với những thay đổi theo vòng đời của nó.

Quy tắc số 7: Làm đúng ngay từ đầu (Kết hợp với thông tin phản hồi)

Trước khi Lean Manufacturing đến với nhà máy của chúng tôi vào đầu những năm 80 chúng tôi thường sản xuất ra những sản phẩm chất lượng biên (chất lượng được tạo ra từ sự so sánh giữa bad và good quality). Chúng tôi kiểm thử để tìm ra sản phẩm tốt và gia công lại những sản phẩm kém. Sau khi hiểu được nguyên tắc “Làm đúng ngay từ đầu”, chúng tôi đã đóng cửa các trạm gia công và thôi không kiểm tra chất lượng của sản phẩm nữa. Thay vào đó, chúng tôi đảm bảo rằng mỗi thành phần của sản phẩm được sản xuất ra đều tốt trước khi được bàn giao sang bộ phận khác. Điều này bao gồm việc kiểm tra và kiểm soát tại tất cả các điểm sản xuất để phát hiện ra các bộ phận lỗi và dừng ngay việc sản xuất của bộ phận đó lại khi lỗi được phát hiện.

“Làm đúng ngay từ đầu” không có nghĩa là “Đóng băng Thông số kỹ thuật”. Ngược lại, thông số kỹ thuật của sản phẩm thay đổi liên tục. Và nguyên tắc “lean” nghĩa là khả năng thích ứng một cách hoàn hảo với điều kiện thị trường thay đổi. Điều này được thực hiện thông qua việc tạo ra một kiến trúc sản phẩm sao cho nó cho phép cho sự thay đổi của sản xuất, và bằng cách giám sát các kỹ thuật phát hiện lỗi trước khi lỗi được tạo ra, và có thể kiểm tra ngay lập tức những thứ đã được thiết kế trước khi đưa vào sản xuất.

Vào năm 1987, Barry Boehm đã quan sát thấy rằng, chi phí để tìm và sửa lỗi sau khi phần mềm được phân phối đắt gấp 100 lần nếu lỗi được tìm và sửa trong giai đoạn thiết kế ban đầu. Sự quan sát này cùng với quy tắc “Làm đúng ngay từ đầu” đã được sử dụng rộng rãi để biện minh cho việc tăng chi phí thiết kế hệ thống chi tiết trước khi viết mã.

Vấn đề nằm ở chỗ, việc giả định rằng có thể tạo ra bộ tài liệu chi tiết để mô tả chính xác yêu cầu của khách hàng, và những yêu cầu này sẽ không thay đổi. Thực tế thì các yêu cầu thường xuyên thay đổi trong vòng đời của hầu hết các hệ thống. “Làm đúng ngay” đã bị diễn giải sai có nghĩa là “không cho phép thay đổi”. Một khi chúng ta thừa nhận thay đổi là một yêu cầu cơ bản của khách hàng, nó trở nên rõ ràng rằng “Làm đúng ngay” cần phải cung cấp và cho phép sự thay đổi.

Nếu chúng ta muốn đáp ứng yêu cầu của khách hàng, chúng ta phải thừa nhận rằng, khách hàng không thực sự biết họ muốn gì trong giai đoạn đầu của sự phát triển. Vì thế chúng ta cần phải kết hợp với phương pháp lấy phản hồi của khách hàng trong suốt quá trình phát triển. Thay vào đó, hầu hết các hoạt động phát triển phần mềm đều bao gồm một quy trình “Kiểm soát thay đổi”, cái này thực sự làm cho việc đáp ứng các phản hồi của khách hàng trở nên rất khó khăn, khiến cho các nhà phát triển rất ngại hỏi. Những thực hành này thực chất làm cản trở sự thay đổi, và không hề chú trọng đến việc đảm bảo chất lượng, đã khiến cho việc “Làm đúng ngay” bị hiểu sai.

Lean Programming sử dụng hai kỹ thuật quan trọng để cho việc thay đổi trở nên dễ dàng. Cũng như Lean Manufacturing xây dựng hệ thống kiểm thử vào trong từng quá trình để phát hiện lỗi, Lean Programming cũng xây dựng những thử nghiệm trong quá trình phát triển để đảm bảo rằng sự thay đổi sẽ không vô tình phá hỏng những mã nguồn đã viết trước. Thực tế, cách tốt nhất là viết các bài kiểm thử trước, và sau đó mới viết mã nguồn. Nếu kiểm thử đơn vị (Unit testing) và kiểm thử hồi quy (Regression testing) tốt sẽ tạo điều kiện cho những thay đổi trong yêu cầu ở cuối quá trình phát triển.

Kỹ thuật thứ hai cho phép sự thay đổi muộn trong quá trình phát triển là tái cấu trúc (Refactoring), hay còn gọi là cải tiến thiết kế của những phần mềm đã có sẵn bằng một cách thức nhanh chóng và có kiểm soát. Trong khi refactoring là một cách thức được chấp nhận, những thiết kế ban đầu có thể tập trung vào những vấn đề có sẵn hơn là ngồi suy đoán những thành phần thiết kế bổ sung sẽ cần đến trong tương lai. Refactoring cho phép các tính năng bổ sung được thực sự thêm vào, và vì thế nó cung cấp một thiết kế mới, đơn giản để xứ lý những vấn đề thật mới xuất hiện. Một khi refactoring là một phần trong quy trình, chúng ta giảm được sự suy đoán ta sẽ cần những gì trong tương lai, bằng cách làm cho nó dễ dàng thích ứng với tương lai một khi nó là hiện tại.

Quy tắc số 8: Bãi bỏ tối ưu hóa địa phương (Đo lường tối ưu địa phương là kẻ thù)

Trong những năm 80, kẻ thù lớn nhất của Lean Manufacturing chính là bộ phận kế toán. Chúng tôi đã có những máy móc lớn và rất đắt tiền, và ý nghĩ rằng chúng không được sử dụng hết công suất là rất cực đoan (nói một cách nhẹ nhàng). Chúng tôi biên soạn các báo cáo hàng ngày của công việc kiểm kê (work-in-process inventory), và các kế toán viên không muốn những báo cáo đó bị bỏ xó chỉ vì đơn giản, họ không có bất cứ báo cáo nào về các công việc đang được thực hiện.

Cả một thế hệ kế toán đã phải nghỉ hưu trước khi các máy móc được phép hoạt động dưới công suất. Thiết kế ra các máy móc cho phép việc chuyển đổi nhanh chóng thay vì các máy cho phép tạo ra số lượng lớn sản phẩm là một vấn đề khó khăn, ngay cả trong ngày hôm nay. Sau 20 năm, Lean Manufacturing vẫn bị coi là phản trực quan đối với những người thiếu cái nhìn rộng trong môi trường kinh doanh.

Trong bối cảnh đó, chúng ta hãy xem xét vai trò của quản lý phạm vi (scope) trong dự án phát triển phần mềm. Những nhà quản trị dự án đã được đào tạo để tập trung vào việc quản lý scope, cũng giống như chúng ta được đào tạo để tập trung vào việc tối đa hóa năng suất thiết bị. Tuy nhiên, Lean Programming về cơ bản đã được thúc đẩy theo thời gian. Cũng như vậy, việc tối ưu hóa năng suất cục bộ tạo ra một quá trình để tất cả các bộ phận được tối ưu hóa, vì thế, nó cũng tập trung vào việc quản lý scope, tạo ra một quá trình để tối ưu hóa từng quá trình của dự án.

Khi nghĩ về điều đó, việc giữ các scope sao cho nó chính xác với những gì người ta hình dung về nó từ đầu thì ít có giá trị trong môi trường kinh doanh luôn thay đổi. Trong thực tế, việc này lại tăng thêm sự lo lắng và làm tê liệt việc ra quyết định. Nó không có nhiều giá trị cho hệ thống cuối cùng, mà những hệ thống đó thông thường đã bị lỗi thời trước chúng được hoàn thành. Việc quản lý những scope mà không còn giá trị sẽ là lãng phí thời gian và tạo ra một danh sách rất dài các vấn đề, tạo khó khăn cho sự thỏa hiệp, khó cho việc sửa chữa cuối cùng cho hệ thống để khiến cho hệ thống chạy đúng vào lúc cuối. Tuy nhiên, một khi đã giữ cho hệ thống chạy theo đúng scope ban đầu lại là một mục tiêu chủ chốt nhất của quản trị dự án, việc đo lường này sẽ vẫn tiếp tục được tối ưu hóa trong giá trị tổng thể mà dự án đem lại.

Scope sẽ biết tự điều chỉnh nếu miền của nó được hiểu cặn kẽ, và có một thỏa thuận cấp cao về những gì hệ thống sẽ làm trong các miền của nó. Scope sẽ tự điều chỉnh nếu như cả hai phía cùng tập trung vào việc phát triển nhanh và giải quyết các vấn đề thực tế của người dùng, và thông qua các phương pháp loại bỏ dư thừa để đạt được các mục tiêu đó.

Quy tắc số 9: Quan hệ đối tác với các nhà cung cấp (sử dụng mua sắm tiến hóa)

Lean Manufacturing không chỉ duy trì trong nhà máy sản xuất. Một khi ý tưởng về việc hợp tác với các nhà cung cấp được kết hợp với sự hiểu biết về giá trị của dòng sản phẩm nhanh chóng (rapid product flow). Quản lý chuỗi cung ứng đã được ra đời. Người ta bắt đầu nhận ra rằng nó đã sử dụng hàng tấn giấy tờ cho việc di chuyển vật liệu giữa các công ty, và điều này không hề tạo thêm giá trị cho sản phẩm. Hơn nữa, các công việc giấy tờ đã thường tốn kém hơn nhiều so với người ta suy nghĩ, chưa kể đến sự chậm trễ trong dòng sản phẩm mà nó gây ra. Thậm chí ngày nay, dự đoán rằng hàng tỷ đô la có thể được tiết kiệm từ cổng thông tin kinh doanh dựa vào việc cắt giảm chi phí giao dịch cần thiết để di chuyển hàng hóa giữa các công ty.

Quản lý chuỗi cung ứng gây ra việc các công ty phải để ý hơn tới các hợp đồng với các công ty khác. Và các hợp đồng này thường xuyên dùng để giữ cho các công ty không gian lận lẫn nhau. Thêm vào đó, nó còn khiến cho nhà cung cấp đối đầu nhau để làm sao họ đạt được việc cung ứng với chi phí thấp nhất. Thêm một lần nữa, Lean Manufacturing biến đổi mô hình này. Demming đã dạy rằng, việc tin tưởng mối quan hệ với một nhà cung cấp duy nhất tạo ra một môi trường cho phép việc tối ưu hóa giá trị tổng thể cho cả hai công ty.

Trong suốt những năm 1980, các công ty đã đạt được các sản phẩm với chất lượng cao nhất và chi phí thấp nhất trong chuỗi cung ứng bằng việc giảm số lượng của các nhà cung cấp và chỉ làm việc với một số nhà cung cấp khác như là đối tác. Chất lượng và sự sáng tạo từ việc kết hợp với chuỗi cung ứng đã được chứng minh vượt xa những lợi ích đến từ môi trường tranh chấp và doanh thu nhanh chóng của các nhà cung cấp. Hợp tác với các công ty giúp cả hai bên cải thiện thiết kế sản phẩm và các dòng chảy sản phẩm. Chúng liên kết các hệ thống để cho phép sự vận chuyển hàng hóa ngay lập tức giữa các nhà cung ứng với rất ít các công việc liên quan đến giấy tờ. Những lợi ích lâu dài của việc quan hệ hợp tác với các nhà cung ứng đã được tài liệu hóa.

Các công ty khôn ngoan nhận ra rằng, các hợp đồng phát triển phần mềm truyền thống sinh ra các chất thải ẩn. Năm 1980, các nhà sản xuất phát hiện ra rằng các mối quan hệ đối tác với chỉ một vài nhà cung ứng có thể tạo ra rất nhiều lợi ích. Không có mối quan hệ thù địch được tạo ra bằng cách tập trung kiểm soát phạm vi và chi phí liên tục, các nhà cung cấp và phát triển phần mềm có thể tập trung vào việc cung cấp những phần mềm tốt nhất có thể cho khách hàng, sửa chữa yêu cầu càng muộn càng tốt trong quá trình phát triển và cung cấp ra rất nhiều giá trị với giá phải chăng.

Quy tắc số 10: Tạo ra văn hóa cải tiến liên tục

Khi việc phát triển phần mềm có vẻ như không kiểm soát nổi, một cách để giải quyết là tăng mức độ “trưởng thành phần mềm” của mỗi tổ chức. Điều này cũng giống như việc thực hành sản xuất tốt, khi mà chứng nhận ISO 9000 và giải thưởng Malcom Baldridge thỉnh thoảng bị đánh đồng với sự xuất sắc. Tuy nhiên những tài liệu này được xác định xuất sắc chỉ khi các quy trình được tài liệu hóa thực sự xuất sắc khi mang ra sử dụng.

Trong rất nhiều dự án phát triển phần mềm hiện tại, xuất sắc có nghĩa là khả năng thích ứng với chuyển động và sự thay đổi nhanh chóng của môi trường. Phương pháp tiếp cận các quá trình chuyên sâu như các cấp độ cấp cao của Viện Công nghệ Phần mềm (Software Engineering Institute – SEI) CMM (Capability Maturity Model) có thể thiếu sự linh hoạt để đáp ứng nhanh chóng với thay đổi. Trong một email tư vấn gần đây từ Cutter Consortium, Jim Highsmith đã nhấn mạnh sự căng thẳng giữa các phương pháp nặng nề và phương pháp nhẹ nhàng như Lean Programming. [6]

Câu hỏi là liệu có phải các chứng nhận về quy trình kiềm chế chứ không phải nuôi dưỡng một văn hóa cải tiến liên tục? Deming có lẽ sẽ suy nghĩ trong ngôi mộ của ông rằng các quy trình bằng văn bản thay thế cho phương pháp đơn giản của ông: Kế hoạch – Thực hiện – Kiểm tra -Hành động (Plan – Do – Check – Act).

• Plan: Chọn một vấn đề, phân tích nó để tìm ra nguyên nhân có thể
• Do: Chạy một thử nghiệm để điều tra nguyên nhân có thể xảy ra
• Check: Phân tích dữ liệu từ thí nghiệm để kiểm chứng nguyên nhân
• Act: Tinh chỉnh và chuẩn hóa dựa trên kết quả.

Phát triển lặp cho phép sử dụng phương pháp Plan-Do-Check-Act trong một dự án. Trong suốt lần lặp đầu tiên, việc chuyển giao từ thiết kế sang lập trình hoặc từ lập trình đến kiểm thử có thể chưa được trơn tru. Điều đó không vấn đề gì nếu như lần lặp đầu tiên cung cấp một kinh nghiệm học tập cho các nhóm dự án, bởi vì có những lần lặp tiếp theo, cả nhóm có thể cải tiến quy trình. Theo một cách nào đó, một môi trường dự án lặp trở thành một môi trường hoạt động, bởi vì quá trình này được lặp lại trong kỹ thuật cải tiến quy trình của Deming có thể được áp dụng từ một lần lặp này đến lần sau.

Cải tiến sản phẩm cũng có thể lặp đi lặp lại, đặc biệt nếu áp dụng refactoring (tái cấu trúc). Trong thực tế, tái cấu trúc cung cấp một chiếc xe rất lớn để áp dụng các nguyên tắc cải tiến liên tục vào trong môi trường lập trình.

Tuy nhiên, việc cải tiến cần được thực hiện ra ngoài phạm vi một dự án. Chúng ta phải cải tiến các dự án trong tương lai bằng cách học từ các dự án đã thực hiện. Một lần nữa, Lean Manufacturing có thể chỉ đường. Trong suốt những năm 80, một bộ các phương pháp thực hành đã được tổng kết lại trong 10 quy tắc của Lean đã được áp dụng rộng rãi trên hầu hết các nhà máy ở phương Tây. Những phương pháp này sau đó lây lan sang các tổ chức dịch vụ, đến các tổ chức logistics, đến chuỗi cung ứng, và xa hơn nữa. Chúng đã được thử thách trong rất nhiều lĩnh vực.

Các quy tắc đơn giản của Lean Manufacturing đã mang lại những cải tiến đáng kể trong những ngành công nghiệp ứng dụng chúng. Những quy tắc này có thể và nên được ứng dụng trong phát triển phần mềm. Thực hành phát triển phần mềm theo Lean sẽ mang lại những phần mềm chất lượng cao nhất, chi phí thấp nhất, thời gian triển khai ngắn nhất có thể.

Phụ lục 1:  14 quan điểm của W. Edwards Demming

1. Tạo sự nhất quán về mục đích.
2. Áp dụng triết lý win-win.
3. Không phụ thuộc vào khối lượng thanh tra; Xây dựng sẵn chất lượng.
4. Không khuyến khích việc kinh doanh dựa vào giá; Giảm tối thiểu chi phí. Xây dựng mối quan hệ lâu dài của lòng tin và trung thành với một nhà cung cấp duy nhất.
5. Liên tục cải tiến hệ thống sản xuất, dịch vụ, lên kế hoạch, v.v.
6. Đào tạo các kỹ năng.
7. Chứng tỏ khả năng lãnh đạo: giúp mọi người làm việc tốt hơn.
8. Thoát khỏi sự sợ hãi và xây dựng lòng tin để tất cả mọi người có thể làm việc tốt hơn.
9. Xóa bỏ hết rào cản giữa các phòng ban, loại bỏ cạnh tranh và xây dựng một hệ thống hợp tác win-win.
10. Loại bỏ các khẩu hiệu, những lời hô hào và những mục tiêu lí tưởng (zero defect targets). Nguyên nhân của phần lớn các vấn đề nằm ở trong hệ thống, và nó vượt quá khả năng của công nhân để họ có thể sửa chữa.
11. Loại bỏ hạn ngạch, các mục tiêu bằng các con số và Quản lý bằng mục tiêu; Thay thế lãnh đạo.
12. Loại bỏ các rào cản mà đã lấy đi niềm vui của mọi người trong công việc. Xóa bỏ hệ thống đánh giá hoặc khen thưởng hàng năm.
13. Giáo dục và cải tiến từng cá nhân.
14. Lôi kéo toàn bộ tổ chức tham gia.
    

Có rất nhiều phiên bản tóm tắt về 14 điểm của Demming bởi vì nó đã được chỉnh sửa theo thời gian với tinh thần cải tiến liên tục. Bản tóm tắt ở trên được dựa vào phiên bản cuối cùng.

Bài viết được dịch từ leanessays.com

Người dịch: Phạm Thùy Dương | Nguồn: Tạp chí Lập trình