Chào mọi người, hôm nay trong topic này mình xin chia sẻ một cách tổng quan cho mọi người về một tập con của Agile architecture, đó chính là LEAN method. LEAN method có thể được áp dụng cho cả quy trình phát triển phần mềm lẫn startup. Tuy nhiên trong khuôn khổ của topic này mình chỉ nói về LEAN method cho quy trình phát triển phần mềm.

Như đã biết, chìa khóa thành công chính là delivery cho khách hàng value tối đa có thể trong khi đó tối thiếu hóa sự lãng phí. LEAN method được xây dựng dựa trên concept này, nó tạo ra nhiều value hơn cho khách hàng với rất ích tài nguyên bỏ ra. Ta bắt đầu đi tìm hiểu về LEAN method, cũng như vì sao nó trở nên phổ biến và những benefits khi áp dụng LEAN method

LEAN là gì ?

LEAN được biết đến với một slogan : "think big, act small, fail fast, learn rapidly", ở đây mình tạm dịch như thế này "nghĩ lớn, hành động nhỏ, phát hiện thất bại sớm, rút kinh nghiệm nhanh chóng". LEAN hiểu thế nào là value đối với khách hàng và sẽ tập trung vào chìa khóa của quá trình để cố gắng liên tục tạo ra nhiều value hơn nữa cho khách hàng. Mục tiêu cuối cùng vẫn là cung cấp là mong muốn cung cấp giá trị hoàn hảo cho khách hàng thông qua một quy trình hoàn hảo và không có lãng phí. Và tất nhiên ý tưởng phía sau LEAN chính là việc cải tiến không ngừng.

Để hoàn thành được việc đó, LEAN thay đổi mindset về việc tập trung, cụ thể là chúng ta không tập trung vào bất cứ cái gì mà không mang lại value. Loại bỏ lãng phí chính là loại bỏ những buổi meeting, task, và document không cần thiết. Nhưng nó cũng có nghĩa là nên loại bỏ việc tốn thời gian, công sức để làm ra cái "chúng ta biết", tập trung vào việc làm ra cái "khách hàng cần" mới là ý nghĩa thực sự. Tất nhiên, cũng không việc loại bỏ mọi việc ngay một cách rập khuôn như vậy, chúng ta cần xem xét một vài khía cạnh khác, ví dụ như nếu tập trung vào việc chỉ mang lại value cho khách hàng thì chúng ta có thể hoàn thành được ngay hay không ? có risk/ khó khăn về mặt kĩ thuật không, hay đơn giản chỉ là việc này nó phụ thuộc vào một số việc khác (ít value hơn) cần được hoàn thành trước, vv... Mặt khác, chúng ta sẽ phải lãng phí nhân lực, công sức để làm lại một vài việc bởi một vài điều kiện đã thay đổi. Nó cũng có nghĩa là việc loại bỏ lãng phí không hiệu quả trong một vài trường hợp, ví dụ điển hình chính là multitasking.

Một ví dụ tiêu biểu cho một doanh nghiệp áp dụng LEAN thành công chính là Dropbox, sau khi áp dụng thì Dropbox đã tăng lượng user từ 100,000 lên 4,000,000 chỉ trong vòng 15 tháng.

Bảy nguyên tắc chính của quy trình phát triển phần mềm LEAN

Loại bỏ lãng phí

Nguyên tắc đầu tiên trong quy trình phát triển phần mềm (QTPTPM) LEAN chính là loại bỏ lãng phí. LEAN cho rằng mọi thứ không mang lại value cho khách hàng đều là lãng phí. Một vài lãng phí như : chỉ hoàn thành một phần công việc, phần mở rộng trong quy trình làm việc, các chức năng mở rộng, thời gian chuyển giao giữa các phần của công việc(multitasking), chờ đợi(chờ phân tích yêu cầu, chờ design, ...), chờ đợi chuyển giao sản phẩm, những lỗi không lường trước được... Để có thể thực hiện được việc ngăn ngừa lãng phí, việc đầu tiên phải dám công nhận nó. Nếu một phần code nào đó được hoàn thành mà cuối cùng lại bị bỏ qua, đó rõ ràng lãng phí. Những process phụ như: báo cáo công việc hằng ngày, hay là các tính năng không thường xuyên được sử dụng bởi khách hàng là một sự lãng phí. Chuyển đổi con người giữa các tác vụ là một sự lãng phí. Chờ đợi các hoạt động, nhóm và quy trình khác là lãng phí. Khiếm khuyết và chất lượng thấp là một sự lãng phí. Chi phí quản lý không tạo ra giá trị thực sự là một sự lãng phí.

Đầu tiên ta cần mapping các kĩ thuật và dòng giá trị được sử dụng của nó để xác định lãng phí. Bước thứ hai là chỉ ra các nguồn lãng phí và loại bỏ chúng. Quá trình loại bỏ lãng phí sẽ diễn ra lặp đi lặp lại cho đến khi chỉ còn các quy trình và thủ tục dường như cần thiết.

Không ngừng học hỏi kiến thức

Nguyên tắc thứ hai của LEAN là không ngừng học hỏi. LEAN là một quá trình học tập liên tục dựa trên lặp đi lặp lại.Thay vì thêm vào nhiều tài liệu hoặc kế hoạch chi tiết, những ý tưởng khác nhau có thể được thử bằng cách viết code và build. Quá trình thu thập yêu cầu/ ý kiến của end-user có thể được đơn giản hóa bằng cách trình bày demo của sản phẩm cho end-user, và rồi tiếp nhận feedback. Quá trình học tập được thúc đẩy bởi việc sử dụng các chu trình với vòng lặp ngắn, với mỗi vòng lặp là sự kết hợp của việc refactor và kiểm thử tích hợp liên tục. Thông tin feedback có thể dùng để xác định giai đoạn phát triển hiện tại và điều chỉnh những nỗ lực để cải tiến trong tương lai. Trong vòng lặp ngắn này (thông thường là 1 sprint), cả khách hàng và nhóm phát triển sẽ tìm hiểu thêm về vấn đề và tìm ra giải pháp khả thi cho những vòng lặp tiếp theo tiếp theo.

Đưa ra quyết định trễ, càng trễ càng tốt

Nguyên tắc này thoạt nghe thì có vẻ vô lý, tuy nhiên vì việc phát triển phần mềm luôn gắn liền với sự không chắc chắn, nên đạt được kết quả tốt hơn bằng cách tiếp cận dựa trên lựa chọn, trì hoãn các quyết định càng nhiều tất nhiên sẽ càng tốt, miễn là cho đến khi chúng có thể được thực hiện dựa trên các sự kiện chứ không phải dựa trên những giả định và dự đoán không chắc chắn. Như một câu ông bà ta thường nói : "chậm mà chắc"

Cách tiếp cận lặp đi lặp lại thúc đẩy khả năng thích ứng với những thay đổi và sai lầm, cái mà có thể rất tốn kém nếu được phát hiện sau khi phát hành toàn bộ phần core. Cách tiếp cận của LEAN có thể giúp xây dựng các lựa chọn sớm hơn cho khách hàng, do đó trì hoãn các quyết định quan trọng nhất định cho đến khi khách hàng nhận ra được nhu cầu của họ tốt hơn. Điều này tránh được những quyết định có giới hạn về công nghệ tốn kém trước đây khi chúng không thực sự cần thiết. Điều này không có nghĩa chúng ta không có planning, các hoạt động planning cần được tập trung vào các lựa chọn khác nhau và thích ứng với tình hình hiện tại, cũng như làm rõ các vấn đề khó hiểu bằng. Nó giúp đạt được mục đích cuối cùng tổn thất tối thiểu.

Delivery càng nhanh càng tốt

Idea này của LEAN rất dễ hiểu, vì trong kỷ nguyên phát triển công nghệ hiện nay thì không phải lớn nhất là tồn tại, mà là nhanh nhất. Sản phẩm càng sớm được cung cấp mà không có các khiếm khuyết lớn, thì có thể nhận được phản hồi sớm hơn và công ty có cơ hội thành công cao hơn. Sự lặp đi lặp lại ngắn hơn trong từng sprint, cùng với việc không ngừng học hỏi, cải thiện và thông tin liên lạc tốt hơn trong team. Một lần nữa, tốc độ đảm bảo đáp ứng các nhu cầu hiện tại của khách hàng vì nó đánh giá việc cung cấp nhanh chóng một sản phẩm có chất lượng.

Trao quyền cho Team

Manager lắng nghe các dev, do đó họ có thể giải thích tốt hơn những gì họ có thể được thực hiện, cũng như cung cấp các đề xuất để cải tiến. Cách tiếp cận của LEAN tuân theo các nguyên tắc Agile: “find good people and let them do their own job,” ở đây mình tạm dịch "tìm người tốt và để họ tự làm công việc của họ," khuyến khích sự tiến bộ, tìm kiếm và sửa chữa, v.v.

Theo quan điểm của LEAN (cũng như Aglie) con người không phải là resource. Mọi người cần motivation và mục đích cao hơn để làm việc, một cái gì đó có thể vươn tới, với sự đảm bảo rằng team có thể chọn những cam kết riêng của mình. Dev phải được tiếp cận với khách hàng; Team Lead thì chỉ nên hỗ trợ và giúp đỡ trong các tình huống khó khăn, cũng như đảm bảo rằng team luôn có một tinh thần làm việc tốt, vậy là đủ.

Xây dựng sự vẹn toàn

Tính vẹn toàn ở đây có nghĩa là các thành phần riêng biệt của nền tảng này hoạt động tốt với nhau như một thể thống nhất với sự cân bằng giữa tính linh hoạt, tính bảo trì, hiệu quả và khả năng phản hồi. Một trong những để có thể đạt đến việc xây dựng sự vẹn toàn này chính là việc refactor liên tục. Khi ngày càng có nhiều tính năng được thêm vào phần core ban đầu, nó càng trở nên khó khăn để thực hiện các cải tiến khác. Refactor chính là để giữ sự đơn giản, rõ ràng và một số tính năng tối thiểu trong source code. Việc bị code duplicate rõ ràng là dấu hiệu của thiết kế code xấu và cần tránh, đây cũng chính là lúc refactor lên tiếng. Quá trình xây dựng hoàn chỉnh và tự động nên được đi kèm với bộ kiểm thử hoàn chỉnh và một cách tự động.

Có cái nhìn bao quát

Ngày nay, các software platform không chỉ đơn giản là tổng hợp của các phần nhỏ mà còn là sản phẩm của các tương tác ngắn và thường xuyên. Các khiếm khuyết trong phần mềm thường được tìm thấy và sửa ngay trong quá trình phát triển. Tác vụ lớn được chuyển thành nhiều tác vụ nhỏ hơn. Nền tảng càng lớn, càng có nhiều tổ chức hoặc những người tham gia vào sự phát triển của nó. Và càng có nhiều phần do các team khác nhau phát triển thì tầm quan trọng của việc có mối quan hệ tốt giữa các bên liên quan và các team để tạo ra một nền tảng có thể mở rộng trở nên cao hơn. Điểm mấu chốt là bạn có thể nhìn ra được vision hay epic của chính sản phẩm mình đang làm hay sao, dù cho mình chỉ tham gia vào một tác vụ nhỏ, hay một phần nào đó trong nó.

Tóm lược

Trên đây là toàn bộ tổng quan về LEAN method, thực sự nó cũng không có gì quá xa lạ vì nó chẳng qua là một tập hợp con của Agile architecture; và tất nhiên nó cũng không phải là quá khó để có thể áp dụng. Vì vậy, đừng ngần ngại thay đổi:)