Khi nói đến “Lean” thì phần lớn chúng ta nghĩ ngay đến Lean đã và đang được áp dụng rộng rải trong các ngành công nghiệp sản xuất, đặc biệt là hảng sản xuất xe hơi Toyota, một doanh nghiệp dẫn đầu về áp dụng Lean từ những năm 80.

Lean trong sản xuất tập trung vào việc bảo tồn giá trị với sự chi trả sức lực ít nhất. Lean trong sản xuất dựa trên việc tối ưu hoá chu trình làm việc, tăng hiệu suất công việc, giảm rác, và sử dụng các phương pháp thực nghiệm để quyết định những vấn đề gì cần cải tiến.

Lean software development được Mary Poppendieck và Tom Poppendieck dịch từ Lean manufacturing và kết hợp với một số nguyên lý trong ngành phát triển phần mềm ở năm 2003. Lean software development có 7 nguyên lý và 22 công cụ hướng dẫn thực hành.

Bài viết này chúng ta tập trung vào thảo luận về nguyên lý “Loại bỏ rác – Eliminate Waste”.

1) Thế nào là rác trong chu trình phát triển phần mềm?

Thế nào là rác? Rác là tất cả những thứ trong sản phẩm không mang lại giá trị (theo cảm nhận của khách hàng). Phản nói thêm là “Giá trị – Value” là những những thứ mà khách hàng sẵn sàng bỏ tiền để mua.

Cụ thể rác trong chu trình phát triển phần mềm là:

• Những thứ không mang lại giá trị cho khách hàng
• Những chức năng hoặc những đoạn mã không cần thiết
• Những yêu cầu nghiệp vụ không rõ ràng
• Sự chậm trễ trong giao tiếp nội bộ, chu trình phát triển
• Sự quan liêu của đội ngũ

Dưới đây là bảy loại rác được được Mary Poppendieck và Tom Poppendieck dịch lại từ dịch từ Lean manufacturing.

2) Làm sao để xác định rác và loại bỏ rác?

Loại rác loại số 1: Một phần công việc hoàn thành (Partially work done)

Là công việc không hoàn thành đúng như điều kiện cam kết nghiệm thu (Definition of Done) như lúc lên kế hoạch cho Sprint hoặc kế hoạch phát hành (Release Planning), sản phẩm không thể demo hoặc phát hành đúng kế hoạch.

Những lý do có thể là:

• Vấn đề kỹ thuật phức tạp chưa được phân tích kỹ bởi đội phát triển (Development Team) ở thời điểm lên kế hoạch cho sprint
• Các mối quan hệ phụ thuộc với giữa yêu cầu đang triển khai với các yêu khác không được nhìn thấy rõ ở thời điểm lên kế hoạch
• Các tính năng mới trong sprint không thể tích hợp với các tính đã được phát hành trước đó
• Các tính năng mới không hoàn thành triển khai code hoặc không hoàn thành công đoạn kiểm thử trước thời hạn (timebox của sprint hoặc release)
• Các tính năng hoàn thành nhưng deploy trên server thất bại

Hướng loại bỏ rác:

• Đội phát triển chủ động tương tác vởi Product Owner về tính năng của user story để hiểu được giá trị có thể mang lại cho sản phẩm. Dựa trên giá trị và mà đưa ra độ ưu tiên sao cho phù hợp. Những user story có độ mang lại giá trị cao nhất thì ưu tiên làm trước.
• Đánh giá độ phức tạp của kỹ thuật ở thời điểm story time (hay gọi bằng tên backlog grooming) trước khi đưa ra ước lượng kích thước phù hợp
• Product owner phát triển và quản lý story mapping và chia sẻ với team về muối quan hệ phụ thuộc giữa các story. Điều này giúp đội phát triển hình dung rõ ràng về kế hoạch release và xác định các ràng buộc, giới hạn về kỹ thuật cần chuẩn bị tốt hơn trước khi tính năng được triển khai
• Development team tập trung chia nhỏ task của user story có thể hoàn thành trong 1 ngày và có thể tích hợp source code ở cuối giờ chiều, nếu có lỗi phát sinh thì có thể sửa ngay
• Ở thời gian cuối sprint planning, team cần dành ít thời gian để sắp xếp độ ưu tiên cho các task trong một user story hoặc độ ưu tiên giữa các user story trong sprint board để đảm bảo

Loại rác loại số 2: Giấy tờ hoặc tài liệu dư thừa (Paperwork or excess documentation)

Trong một số dự án cụ thể thì yêu cầu viết yêu cầu nghiệp vụ, viết tài liệu thiết kế trước khi triển khai code. Với đòi hỏi đó tài liệu phải trải qua nhiều công đoạn viết, review, duyệt của người quản lý, và nhiều khi cần baseline trước khi phát triển. Với sự đòi hỏi phức tạp trong chu trình khiến đội phát triển phải tối thời gian chờ đợi, thủ tục giấy tờ nhiều dẫn đến gây ra lảng phí nguồn lực và tạo cơ hội cho tính quan liêu tồn tại.

Những lý do có thể là:

• Quy trình thực hiện cồng kềnh và phải qua nhiều bước duyệt
• Giữa quản lý và đội ngũ phát triển thiếu niềm tin về nhau
• Cơ chế quản lý quá xem trọng tài liệu thay vì xem xét giá trị ở mỗi công đoạn trong chu trình

Hướng loại bỏ rác:

• Scrum Master cần phân tích xem công đoạn nào là cần thiết, có giá trị và tìm ra những công đoạn đang gây lãng phí và thảo luận với Product Owner và Development team, kể cả lãnh đạo trong công ty để loại bỏ trong dự án
• Scrum Master huấn luyện team thực hành face-to-face tương tác nhiều hơn thay vì tập trung quá nhiều về tài liệu và giúp đội phát triển điều chỉnh quy trình làm việc

Loại rác loại số 3: Bổ xung tính năng (Extra features)

Tâm lý chung của development team thường thích làm nhiều hơn kết quả kỳ vọng và bổ xung tính năng thừa trong chức năng mà không xem xét cẩn thận tính năng bổ xung có thật sự mang lại giá trị cho khác hàng hay không? Chính tâm lý và cách làm này có thể tạo ra rác.

Những lý do có thể là:

• Development team thiếu tầm nhìn về sản phẩm
• Không xác định rõ ràng đối tượng khách hàng mục tiêu của sản phẩm
• Độ ưu tiên các chức năng của sản phẩm không phù hợp
• Sự cầu toàn của nhóm phát triển

Hướng loại bỏ rác:

• Product Owner cần phân tích kỹ đối tượng khách hàng mục tiêu của sản phẩm để đưa các giá trị người dùng cụ thể trong mỗi user story. Sau đó Product Owner cần chia sẻ và đảm bảo development team hiểu rõ các giá trị kỳ vọng mà khách hàng muốn đạt được
• Product Owner có trách nhiệm phân tích kỹ giá trị nhận được cho chi phí đầu tư (ROI). Product Owner cũng quản lý tầm nhìn của sản phẩm, và cũng cần hài hoà giữa lộ trình phát hành sản phẩm phù hợp với các user story có độ ưu tiên cao trong product backlog. Product Owner cần chia sẻ và đảm bảo development team hiểu rõ tầm nhìn của sản phẩm và lộ trình phát hành sản phẩm
• Các độ ưu tiên của phát triển các chức năng cần cố gắng làm đúng ở thời điểm lên kế hoạch phát hành. Độ ưu tiên cần các user story cần hài hoà giữa giá trị nhận được, chi phí đầu tư và các rũi ro có thể gặp phải

Loại rác loại số 4: Chuyển công việc (Task Switching)

Khi một thành viên của đội phát triển đang thực thi một công việc mà gặp trở ngại phải chuyển sang làm công việc khác.

Những lý do có thể là:

• Task trên sprint board có thời gian ước lượng thực hiện quá dài
• Các vấn đề kỹ thuật phức tạp xuất hiện ở thời điểm thực hiện và chưa có hướng giải quyết
• Độ ưu tiên tích hợp source code không rõ ràng
• Product owner không sẵn sàng trả lời các thắc mắc của đội phát triển, với thông tin nghi ngờ thì thành viên của đội sẽ dừng công việc hiện tại và chuyển sang công việc khác

Hướng loại bỏ rác:

• Đội phát triển chủ động khai phá những vấn đề kỹ thuật phức tạp và tìm kiếm sự hỗ trợ từ các chuyên gia bên ngoài đội nếu thấy cần thiết để hình dung rõ cách thức triển khai thiết kế
• Đội phát triển tập trung chia nhỏ công việc dưới 1 ngày làm việc bình thường, và tích hợp source code ở cuối ngày, nếu phát hiện lỗi thì fix luôn trước khi trở về nhà và ngày mai bắt đầu một công việc mới
• Cả đội cần sắp xếp độ ưu tiên hợp lý để công việc thiết kế, triển khai code và kiểm thử phối hợp một cách nhiệp nhàng
• Product owner tập trung vào chia sẻ giá trị người dùng kỳ vọng đạt được cho mỗi chức năng, user story, và dẫn dắt đội phát triển đưa ra ý tưởng thiết kế và làm lộ ra những khó khăn trong từng giải pháp thiết kế sớm nhất có thể
• Các thành viên của đội cần ý thức rõ giá trị của việc chia nhỏ công việc trong một user story để giảm thiểu các trở ngại về kỹ thuật, và hình dung rõ việc chuyển đổi task nhiều sẽ ảnh hưởng độ ưu tiên các task trên sprint board và gây xáo trộn cho cả đội

Loại rác loại số 5: Chờ đợi thông tin (Waiting for the information)

Là thời gian chờ đợi xác nhận thông tin của khách hàng, thời gian chờ trả lời của Product Owner, thời gian chờ tích hợp hệ thống, thời gian chờ đợi hỗ trợ môi trường làm việc.

Những lý do có thể là:

• Khách hàng và Product Owner không sẵn sàng tương tác với đội phát triển
• Các thành viên trong đội không chủ động tương tác face-to-face và dùng công cụ giao tiếp gián tiếp qua nhiều
• Độ ưu tiên tích hợp hệ thống không hợp lý

Hướng loại bỏ rác:

• Cần đảm bảo cả đội bảo gồm Product Owner, khách hàng hiểu được phương thức làm việc của team và cam kết hỗ trợ kiệp thời
• Scrum Master cần đảm bảo chu trình làm việc thuộc sở hữu của đội để và đội có trách nhiệm bảo trì và cải thiện những rào cản trong chu trình phát triển
• Đội phát phát triển cần hình dung rõ kế hoạch tích hợp hệ thông cho từng user story và các chức năng đã cam kết hoàn thành trong sprint
• Cần đảm bảo cả đội có tính kỹ luật và sẵn sàng chia sẻ rào cản trong chu trình ở thời điểm restrospective

Loại rác loại số 6: Động tác thừa (Motion)

Là những động tác thừa thải trong chu trình phát triển mà không mang lại giá trị cho khách hàng

Những lý do có thể là:

• Tổ chức hoặc khách hàng đòi hỏi quá nhiều công việc tài liệu hoá hoặc cơ chế kiểm soát quá khắt khe
• Tốn quá nhiều thời gian để kiểm thử lại chức năng có điều chỉnh

Hướng loại bỏ rác:

• Đội dự án cần đưa ra quy trình phù hợp để tối đa hoá giá trị, những động tác nào không mang lại giá trị nhiều cho khách hàng thì nên thương thảo để cắt giảm. Ví dụ như: Nếu dự án đòi hỏi tất cả các chức năng phải có thiết kế mã giả, nhưng với những tính năng đơn giản như thiết lập master data thì cần xem xét bỏ qua bước này
• Cần đưa ra chiến thuật áp dụng automation test, và trong tương lại nếu một chức năng có tinh chỉnh và trường dữ liệu thì chúng ta chỉ tốn ít thời gian để xem lại bộ test case và tiến hành chạy toàn bộ test script thay vì ngồi test manual toàn bộ tính năng.

Loại rác loại số 7: Lỗi (Defects)

Kết quả ẩn phẩm đầu ra có lỗi

Những lý do có thể là:

• Nhóm phát triển không hiểu rõ ràng yêu cầu nghiệp vụ
• Thiếu sót điều kiện nghiệm thu trên user story
• User story không thoả mãn kỹ thuật INVEST
• Team không thực hiện Unit test và component test một cách đầy đủ
• Team dồn quá nhiều công việc test và tích hợp về cuối sprint
• Chiến thuật triển khai automation test chưa phù hợp

Hướng loại bỏ rác:

• Đội phát triển không nên nhảy vào triển khai cho đến khi cả đội đã hiểu một cách đầy đủ về yêu cầu và giá trị người dùng đang kỳ vọng. Đó là lý do tại Product Owner phải có trách nhiệm đảm bảo đội đã hiểu thay vì chỉ trình bày yêu cầu một cách chúng chung. Đó là cách tối đa hoá những công việc không hoàn thành.
• Cả đội phải đảm bảo thực hành INVEST cho các user story để đảm bảo các user story vừa đủ nhỏ để triển khai, nếu không đủ nhỏ thì tiến hành phân rã để thoả mãn INVEST.
• Cần đảm bảo có Coding Standard và những hướng dẫn code, tích hợp và thực hiện kiểm thử, và cả hướng dẫn viết code đảm bảo tính bảo mật
• Thực hiện công việc pair review source code để những đoạn code chứa lỗi tìm ẩn được phát hiện sớm và quan trọng hơn là đào tạo, hướng dẫn team viết những đoạn code trong sáng
• Cần có chiến lược áp dụng automation test ngày từ những sprint đầu tiên. Với một bộ test case bổ xung theo thời gian và đủ độ bao phủ sẽ giúp giảm lỗi và tiết kiệm thời gian ở giai đoạn bảo trì và tinh chỉnh chức năng đã có trước đó
• Danh sách các lỗi phát hiện trong sprint cần phân tích nguyên nhân gốc (root cause analysis), cần tổng hợp để cả đội cùng nhìn nhận và đưa ra hướng khắc phục ở sự kiện restrospective

Việc áp dụng tư duy và hướng dẫn thực hành của Lean vào dự án Agile giúp bạn tối đa hoá giá trị từ quá trình làm việc của team. Giúp team tăng năng suất lao động và trưởng thành theo thời gian. Khi Lean và Agile có được sự kết hợp nhip nhàng thì bạn sẽ thấy team thực hành cải tiến liên tục ở mỗi ngày làm việc.

APEX Learning Content Development Team 

APEX Global thường xuyên tổ chức khoá đào tạo về Agile Project Management Professional. Bạn có thể tham khảo lịch đào tạo ở link Public Training Schedule. Hoặc đọc thêm các bài viết chuyên đề về kỹ năng nghề, kỹ năng mềm, kỹ năng quản lý, xu thế công nghệ,… liên quan đến CNTT ở link APEX Global News.

Để được tư vấn thêm về các khoá đào tạo của APEX Global, bạn hãy gọi hoặc email đến:  (+84-8) 62 718 187; [email protected]