10 qui tắc đơn giản của lập trình tinh gọ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 – Lập trình Cực hạn) đề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), và cũng ấn tượng 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 Toàn diện) 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. 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. 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ị đó.

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, chúng 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 hoàn chỉnh đượ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 khuyến nghị rằng tất cả những phụ liệu đó là ứng viên để đưa ra phân tích. Việc phân tích phải đảm bảo không chỉ mang lại các giá trị gia tăng cho sản phẩm mà còn 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.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à những 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ì đưa ra các đặc tả dày cỡ vài inch, hãy cung cấp 25 trang gồm các bảng tóm tắt một cách súc tính các ứng suất.

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 rất nhanh dẫn tới thời gian chu kỳ rất ngắn, thường là thấp hơn một hai cấp 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 các 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), [3] 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ự như đã đượ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 Progress). 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 (Iterative development) 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 phân đoạn (iteration), 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 cần đưa vào kỹ thuật dự báo tinh vi để có những tiên lượng 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 đang cố gắng làm những điều sai. Việc dự đoán chính xác không phải là lý tưởng, mà lý tưởng là chúng ta có thể giảm sự phụ thuộc vào các dự báo bằng cách làm giảm đáng kể thời gian phản ứ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ệ thay đổi nhanh, đò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, hãy giữ sự thay đổi yêu cầu càng gần thời điểm bàn giao sản phẩm 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 biến động. 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 sớm các thiết kế trong dự án phát triển phần mềm là một sự đầu cơ cho việc dự báo. 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ế về 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 là 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 “trong cuộc” (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 đề của các tài liệu đồ sộ đó là chúng cố gắng đưa ra tất cả các quyết định thay cho các lập trình viên, thay vì cung cấp cho họ một bộ các hướng dẫn. Nói chung, việc tăng cường mức độ trừu tượng của tài liệu sẽ cung cấp chỉ dẫn cho các lập trình viên cũng như cho họ sự tự do để tạo ra các thiết kế chi tiết và 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 những gì cần phải làm, chứ không phải cách để làm chúng.

Lập trình viên cần phải hiểu rõ mục đích của công việc và cách thức để nó phù hợp với luồng công việc chung. Họ cần biết những gì phải làm để đáp ứng yêu cầu của khách hàng và 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 khi nào nó có thể sẽ kết thúc. Cuối cùng, công việc của họ cần được nhìn thấy trong các phân đoạn nhỏ để cung cấp những 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 các yêu cầu bị thiếu, không đầy đủ hoặc không đúng. Thế giới phát triển phần mềm đã đối phó với nguy cơ này bằng cách mở rộng 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 tiến hành thiết kế hệ thống. Tuy nhiên việc xác định các yêu cầu của người dùng theo hướng này có những khiếm khuyết sâu sắc.

Tôi đã từng tham gia một dự án trong đó khách hàng muốn một có 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ế sơ bộ trước khi có thiết kế chi tiết 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ì sẽ không đơ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ờ để lấy chữ ký của những người dùng.

Thay vì khuyến khích sự tham gia của người 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 họ với các nhà phát triển phần mềm. Người 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 phát triển hệ thống theo cách thức lặp. 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 phân đoạn, 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. [6] 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ỗ, người ta giả định rằng có thể tạo ra bộ tài liệu mô tả chi tiế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. Nhưng 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 phần mềm. “Làm đúng ngay” đã bị diễn giải sai thành “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, điều này trở lên rõ ràng rằng “Làm đúng ngay” đòi hỏi chúng ta cần chuẩn bị cho 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 công việc 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 đưa 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 kiểm thử 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 phương pháp đã được chấp nhận, những thiết kế cần tập trung từ sớm vào những vấn đề có sẵn hơn là ngồi suy đoán những thành phần mở rộng sẽ cần đến trong tương lai. Khi các tính năng bổ sung được thực sự đưa vào, refactoring cung cấp một thiết kế mới, đơn giản để xứ lý những vấn đề mới xuất hiện. Một khi refactoring trở thành một phần trong quy trình, chúng ta sẽ giảm bớt sự suy đoán về những gì cần thiết trong tương lai bằng cách làm cho những thứ sẽ đến trong tương lai dễ dàng thích ứng với hệ thống.

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 trong nhà máy, 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 soạn ra các báo cáo kê khai công việc hàng ngày, và các kế toán không muốn những báo cáo đó bị bỏ xó bởi vì ở đó không có bất cứ một WIP (Work in Progress) để báo cáo.

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ế các máy móc để cho phép việc chuyển đổi nhanh chóng thay vì công suất cao nhất cao nhất vẫn còn là một vấn đề khó thuyết phục thậm chí là đến tận bây giờ. 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ý phạm vi, 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 và các phản hồi. 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ý phạm vi, tạo ra một quá trình để quản lý dự án tổng thể của những tối ưu nhỏ.

Khi nghĩ về điều đó, việc giữ các phạm vi 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 khi chúng được bàn giao. Việc quản lý những mục tiêu 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 đề, gây khó khăn cho sự thỏa hiệp, và khó khăn cho việc sửa chữa hệ thống để nó đáp ứng đúng vào giai đoạn cuối. Tuy nhiên, việc giữ cho hệ thống chạy theo đúng phạm vi 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.

Phạm vi 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ó. Phạm vi 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 (Supply Chain Management) đã đượ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 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 dẫn tới 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 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 lãng phí ẩ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 tổ chức. Dường như điều này cũng giống như việc có cách thức để 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 chương trình tài liệu hóa quy trình này được xác định xuất sắc chỉ khi trong thực tế áp dụng chúng thực sự xuất sắc.

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 biến động và sự thay đổi nhanh chóng của môi trường. Các phương pháp Tiếp cận Quá trình Chuyên sâu (Process-intensive) như các cấp độ cao trong CMM (Capability Maturity Model của Software Engineering Institute – SEI) 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.[7]

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ẽ nằm trong mộ xem xét và viết những pho sách về quy trình 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 phân đoạn đầ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ư phân đoạn đầ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òn có những phân đoạn 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ừ phân đoạn này tới phân đoạn khác.

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 phương tiện 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 vượt 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 đã qua. Một lần nữa, Lean Manufacturing có thể chỉ ra con đườ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 nguyên 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 đó lan sang các tổ chức dịch vụ, các tổ chức logistics, 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 nguyên 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 nguyên 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

Tạo sự nhất quán về mục đích.
Áp dụng triết lý win-win.
Không phụ thuộc vào khối lượng thanh tra; Xây dựng sẵn chất lượng.
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.
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.
Đào tạo các kỹ năng.
Chứng tỏ khả năng lãnh đạo: giúp mọi người làm việc tốt hơn.
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.
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.
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.
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.
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.
Giáo dục và cải tiến từng cá nhân.
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. [8]

Nguồn leanessays.com | Người dịch: Phạm Thùy Dương

———————————-
Tham khảo:

[1] The Machine That Changed the World : The Story of Lean Production, by Womack, James P., Daniel T. Jones, and Daniel Roos, New York: Rawson and Associates; 1990

[2] Strategy as Simple Rules, by Eisenhardt, Kathleen M and Donald N. Sull, Harvard Business Review, Volume 79, Number 1, January 2001, pp 107- 116

[3] Reducing Cycle Time, by Frailey, Dennis, Software Development Magazine, August, 2000

[4] Time-and-Motion Regained, by Paul Adler, Harvard Business Review, January-February 1993 pp 97-108

[5]Charting the Seas of Information Technology – Chaos, by The Standish Group International, 1994

[6] Industrial Software Metrics Top 10 List, by Boehm, Barry, IEEE Software, Volume 4 Number 5, September, 1987, pp 84-85

[7] E-Projects in India, by Jim Highsmith, e-Project Advisor, Cutter Consortium’s e-Project Management Advisory Service, March 1, 2001.

[8] Gone But Never Forgotten, by Brad Stratton, editor, Quality Progress Magazine, March 1994