Unlimited WordPress themes, graphics, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Code
  2. Editorials
Code

Từ Scrum đến Lean

by
Length:LongLanguages:

Vietnamese (Tiếng Việt) translation by Thai An (you can also view the original English article)

Trong khi mục tiêu chính của Scrum là quản lý và tổ chức dự án, thì Lean tập trung hơn vào việc tối ưu hóa các quy trình để nhanh chóng tạo ra các sản phẩm chất lượng. Đây có thể là bước đi đầu tiên của bạn trong việc áp dụng các nguyên tắc Agile hoặc có thể là điều mà đội ngũ của bạn đang hướng tới, khi Scrum không đủ đáp ứng. Xin mời bạn đọc story của đội ngũ của tôi và cách chúng tôi phát triển từ Scrum sang quá trình phát triển Lean.


Sơ lược

Lean là một tập hợp các nguyên tắc được xác định bởi ngành công nghiệp sản xuất ô tô Nhật Bản vào thập niên 1980. Kỹ sư lành nghề của Toyota, John Krafcik, đã đề ra thuật ngữ này khi quan sát các quy trình và công cụ được sử dụng để loại bỏ lãng phí trong sản xuất ô tô hàng loạt. Mãi đến năm 2003, Mary và Tom Poppendieck đã giới thiệu Lean như một quy trình phát triển phần mềm trong cuốn sách của họ, Lean Software Development: An Agile Toolkit.

Trong khi Scrum là tập hợp các quy tắc và vai trò thì Lean là tập hợp các nguyên tắc và khái niệm với một số ít các công cụ. Cả hai đều được coi là các kỹ thuật Agile và có chung hệ tư tưởng là thực hiện nhanh chóng, đồng thời giảm các nhược điểm và lỗi. Tôi luôn nhấn mạnh khả năng thích ứng của Agile, nhưng không thể bỏ qua thực tế là Scrum đóng vai trò một nhóm quy tắc bắt buộc. Trên thực tế, những người hâm tuân thủ ý thức của Scrum sẽ hét lên toáng lên về việc không tuân theo các quy tắc của Scrum.

Mặt khác Lean phóng khoáng hơn; những người theo dõi trình bày quá trình này như tập hợp các đề xuất có khả năng thích ứng cao.

Nó khuyến khích đội ngũ hoặc công ty đưa ra quyết định, và nó thích nghi với các quyết định và những bất ngờ hàng ngày mà đội ngũ và công ty của bạn phải đối mặt.

Khi đội ngũ của tôi thành thạo và khai thác Scrum, chúng tôi cảm thấy rằng một số khía cạnh của nó đã gắn kết chúng tôi. Chúng tôi đã trở thành một đội khá kỷ luật và đồng nhất. Một vài cuộc họp không còn phù hợp với chúng tôi nữa và chúng tôi bắt đầu nhận ra rằng các cuộc họp hàng ngày không hiệu quả. Chúng tôi đã học được rằng các vấn đề nên được giải quyết nhanh hơn và chúng tôi cảm thấy cần phải tránh các thủ tục này đã vướng bận chúng tôi.

Chúng tôi đã thay đổi.


Hai khái niệm chính của Lean

Lean đưa ra hai khái niệm chính, nhưng cốt lõi là: loại bỏ sự lãng phí và cải thiện công việc.

Loại bỏ sự loãng phí

Nếu một cái gì đó sẽ suy yếu, nó sẽ như thế vào thứ Sáu.

Điều làm vướng bận quá trình sản xuất chính là sự lãng phí. Lãng phí này bao gồm mất thời gian, vật liệu còn sót lại và lực lượng lao động không được sử dụng. Thiếu sót trong sản phẩm cuối cùng là sự lãng phí; tốn thời gian để sửa chúng, tốn tiền để thay thế chúng và lãng phí tài nguyên để tìm giải pháp khác.

Khái niệm về sự lãng phí đáo hiện hữu trong thế giới phát triển phần mềm. Lãng phí có thể được mô tả qua việc phân phối trễ hạn, các lỗi và lập trình viên không có gì để làm (đừng nhầm lẫn với "lập trình viên nên lập trình tám giờ một ngày mà không nghỉ và xem youtube").

Cải thiện tiến trình công việc

Khái niệm Lean của Toyota tập trung vào tiến trình sản xuất. Trong một nhà máy sản xuất, dòng chảy là một chuỗi các quy trình biến đổi nguyên liệu thô thành sản phẩm cuối cùng của họ. Các quy trình này có thể rất khác nhau và mất nhiều thời gian để hoàn thành, nhưng chúng có thể được cải thiện để hiệu quả hơn. Đó là một cuộc chiến dai dẳng tìm kiếm và cải thiện các vướng mắt trong quá trình này.

Một tiến trình lý tưởng thì trong đó mỗi bước cần dùng cùng một quãng thời gian và công sức để tạo ra cùng một số lượng sản phẩm.

Điều này không có nghĩa là mỗi quy trình nên tiêu tốn cùng một số tiền, nhưng mỗi quy trình sẽ có thể hoàn thành với cùng mức độ dễ dàng như nhau.

Trớ trêu thay, Scrum là công cụ khiến chúng tôi cuối cùng nhận ra sự lãng phí trong dự án của mình. Mặc dù chúng tôi tuân thủ Scrum thuần túy trong một số lĩnh vực sản xuất, chúng tôi đã bắt đầu xác định các lỗi và (hoặc) sự chậm trễ mà chúng tôi có thể dễ dàng tránh được bằng cách thử một cách tiếp cận khác.

Chúng tôi biết rất ít về Lean tại thời điểm đó. Chúng tôi đã đọc một vài bài viết về chủ đề này, nhưng chúng tôi đã làm sai và phớt lờ chúng, bởi vì chúng tôi quá tập trung vào quá trình Scrum của chúng tôi. Chúng tôi gần như đã bị thuyết phục rằng Scrum là Chén Thánh, nhưng "cây súng máy Scrum" của chúng tôi bắt đầu gặp vấn đề. Chúng tôi cần phải mở mang đầu óc.


Những nguyên tắc của Lean

Để phát triển phần mềm, các nguyên tắc của Lean đã được điều chỉnh thành 7 nguyên tắc sau.

1 - Loại trừ sự lãng phí

Việc thay đổi từ Scrum sang Lean đã thực sự giải phóng.

Trong phát triển phần mềm, bạn có thể tìm và loại bỏ lãng phí bằng cách nhận ra những thứ cần được cải thiện. Theo nghĩa thực dụng, bất cứ điều gì không phải là giá trị trực tiếp cho khách hàng đều là sự lãng phí. Để cung cấp một vài ví dụ: sự lãng phí có thể là một lỗi, một comment trong code, một tính năng không được sử dụng (hoặc hiếm khi được sử dụng), các nhóm đang chờ đợi các nhóm khác, gọi điện cá nhân ... bạn hiểu rồi đấy. Bất cứ điều gì kiềm hãm bạn, đội ngũ của bạn hoặc sản phẩm của bạn là một sự lãng phí và bạn nên triển khai các hành động thích hợp để loại bỏ nó.

Tôi nhớ một trong những vấn đề của chúng tôi là nhu cầu thường xuyên phản ứng nhanh hơn 2 sprint. Phát triển trong các sprint và tôn trọng các quy tắc của Scrum ngăn bạn thay đổi các story được gán cho sprint hiện tại. Một đội ngũ cần điều chỉnh khi người dùng tìm thấy lỗi và cần sửa lỗi hoặc khi khách hàng quan trọng nhất muốn một tính năng có thể dễ dàng hoàn thành trong hai ngày. Chỉ là Scrum không đủ linh hoạt trong những trường hợp này.

2 - Mở rộng việc học

Đẩy mạnh giá trị trong việc giáo dục.

Bạn có lãng phí, và một cách tự nhiên bạn sẽ muốn ít lãng phí hơn trong tương lai. Nhưng tại sao lại có lãng phí? Có thể là từ một thành viên trong đội ngũ không biết cách tiếp cận một vấn đề cụ thể. Ổn thôi; không ai biết mọi thứ. Hãy đẩy mạnh giá trí của giáo dục.

Xác định các lĩnh vực cần cải thiện nhất (kiến thức tham khảo) và bắt đầu đào tạo. Bạn và đội ngũ của bạn càng biết nhiều thì càng dễ giảm thiểu lãng phí.

Ví dụ: học phương pháp Test Driven Development (TDD) có thể giảm số lượng lỗi trong code của bạn. Nếu bạn gặp vấn đề với việc tích hợp các mô-đun của các đội ngũ khác nhau, bạn có thể muốn tìm hiểu Continuous Integration là gì và triển khai một phương pháp phù hợp.

Bạn cũng có thể học hỏi từ phản hồi của người dùng; việc này cho phép bạn tìm hiểu cách người dùng sử dụng sản phẩm của bạn. Một tính năng thường xuyên được sử dụng chỉ có thể được truy xuất bằng cách đi đến 5 menu. Đó là dấu hiệu của sự lãng phí! Ban đầu bạn có thể đổ lỗi sự lãng phí như vậy cho các lập trình viên và nhà thiết kế (và bạn có thể đúng), nhưng người dùng có xu hướng sử dụng phần mềm của bạn theo những cách mà bạn không bao giờ nghĩ đến. Việc học hỏi từ người dùng của bạn giúp loại bỏ loại lãng phí này. Nó cũng giúp bạn loại bỏ các yêu cầu sai hoặc không đầy đủ. Phản hồi của người dùng có thể dẫn sản phẩm đi trên những đường hướng mà bạn chưa bao giờ xem xét.

Ở một vài thời khắc, đội ngũ của tôi xác định rằng các mô-đun nhất định có thể được viết tốt hơn nếu chúng tôi biết nhiều hơn về lĩnh vực đó lúc đầu. Tất nhiên, không có cách quay ngược thời gian và việc viết lại một lượng code lớn là phi thực tế. Chúng tôi quyết định đầu tư thời gian để tìm hiểu về lĩnh vực khi được giao nhiệm vụ cho tính năng phức tạp hơn. Việc này có thể lấy đi vài giờ hoặc thậm chí vài tuần, tùy thuộc vào mức độ phức tạp của vấn đề.

3 - Quyết định càng muộn càng tốt

Mỗi quyết định đều giá trị riêng. Có thể không phải là ngay lập tức và hữu hình nhưng chi phí thực sự có. Việc trì hoãn các quyết định giúp bạn chuẩn bị đầy đủ cho các vấn đề mà bạn cần phải đối mặt. Có lẽ ví dụ phổ biến nhất về quyết định trì hoãn là thiết kế cơ sở dữ liệu.

Các quyết định không phải thuộc về mặt kỹ thuật; việc giao tiếp với khách hàng giúp bạn đưa ra quyết định tác động đến cách bạn tiếp cận các tính năng của sản phẩm.

Nhưng không phải lúc nào người dùng cũng biết họ muốn gì. Bằng cách trì hoãn các quyết định về tính năng cho đến khi người dùng thực sự cần tính năng này, bạn sẽ có thêm thông tin về vấn đề và có thể cung cấp các chức năng cần thiết.

Chọn phương pháp Agile phù hợp nhất với bạn và đội ngũ của bạn.

Mười bốn năm trước, đội ngũ đã quyết định lưu trữ cấu hình của ứng dụng trong cơ sở dữ liệu MySQL. Họ đã đưa ra quyết định này khi bắt đầu dự án, và bây giờ đội ngũ hiện tại (đội ngũ của tôi) mang theo một gánh nặng. May mắn thay, sản phẩm đó không còn được thực sự phát triển, nhưng chúng ta vẫn phải bảo trì qua thời gian. Chỉ một tác vụ đơn giản mà lại trở thành cực lớn.

Mặt tốt là chúng tôi đã học được từ những sai lầm của người tiền nhiệm. Chúng tôi đưa ra các quyết định về lập trình, kiến trúc và dự án càng muộn càng tốt. Trên thực tế, chúng tôi đã học được bài học khắt nghiệt này trước khi ứng dụng Lean. Viết code mở và tách rời, và tạo một thiết kế bền bỉ - và bất kể cấu hình. Việc này chắc chắn khó thực hiện hơn, nhưng suy cho cùng giúp bạn tiết kiệm rất nhiều thời gian trong tương lai.

Cách đây một thời gian, chúng tôi đã bổ sung một tính năng cho sản phẩm của mình để nén dữ liệu trên đĩa. Chúng tôi biết rằng nó sẽ hữu ích và muốn bổ sung nó vào sản phẩm của chúng tôi càng nhanh càng tốt. Chúng tôi bắt đầu với chức năng đơn giản, tránh các quyết định liên quan đến các tùy chọn và cấu hình cho đến một thời gian sau. Người dùng bắt đầu phản hồi sau một vài tháng và chúng tôi đã lấy thông tin đó để đưa ra quyết định về các tùy chọn và cấu hình của tính năng. Chúng tôi đã sửa đổi tính năng này trong vòng chưa đầy một ngày và không một người dùng nào phàn nàn hoặc yêu cầu thêm chức năng nào. Đó là một thay đổi được thực hiện dễ dàng; chúng tôi đã viết code và biết rằng chúng tôi sẽ tiến hành sửa đổi trong tương lai.

4 - Cung cấp càng nhanh càng tốt

Chúng ta sống trong một thế giới không ngừng thay đổi. Các chương trình chúng tôi viết hôm nay cho các máy tính sẽ bị lỗi thời trong hai năm. Định luật Moore vẫn có hiệu lực, và sẽ tiếp tục như vậy.

Tốc độ triển khai là cốt lõi trong thế giới phát triển rất nhanh này.

Mang đến một sản phẩm trong ba năm đặt bạn đi sau thời đại, do đó điều quan trọng là cung cấp giá trị cho khách hàng của bạn càng sớm càng tốt. Lịch sử đã chứng minh rằng một sản phẩm không hoàn chỉnh với số lỗi chấp nhận được vẫn tốt hơn không có gì. Ngoài ra bạn nhận được phản hồi vô giá từ người dùng.

Công ty chúng tôi đã có một giấc mơ: phân phối sau mỗi sprint. Đương nhiên, điều đó không thực tế trong đa số các trường hợp. Người dùng của chúng tôi không muốn một sản phẩm được cập nhật hàng tuần hoặc hàng tháng. Vì vậy, trong khi chúng tôi cố gắng phát hành từng phiên bản code của mình, chúng tôi không làm như vậy. Chúng tôi đã học được rằng "nhanh" là điều người dùng nhận thức được - không phải là điều chúng tôi có thể làm được. Trong ngành công nghiệp sản phẩm của chúng tôi, nhanh có nghĩa là cập nhật thường xuyên sau mỗi vài tháng và sửa các lỗi nghiêm trọng trong vài ngày. Đây là cách người dùng của chúng tôi nhận thức về "nhanh"; các loại sản phẩm và ngành công nghiệp khác có định nghĩa khác nhau về "nhanh".

5 - Trao quyền cho đội ngũ

Các lập trình viên từng những tài nguyên được bao bọc trong những căn phòng kín , âm thầm thực hiện các nhiệm vụ cho công ty của họ. Đây là hình ảnh nổi bật của một lập trình viên vào cuối những năm 1990, nhưng giờ thì không phải như vậy nữa.

Lịch sử đã chứng minh rằng cách tiếp cận và quản lý dự án waterfall truyền thống không phù hợp với ngành phần mềm.

Điều đó thật tệ tại thời điểm mà chỉ có khoảng 5% tất cả các dự án phần mềm thực sự được phân phối. Các doanh nghiệp và sản phẩm triệu đô đã thất bại trong 95% thời gian, dẫn đến những tổn thất lớn.

Lean xác định rằng các lập trình viên không có động lực gây nên sự lãng phí đó. Vì sao họ thiếu động lực? Vâng, các lập trình viên và đội ngũ phát triển không được lắng nghe. Công ty đề ra các nhiệm vụ và quản lý vi mô những nhân viên, họ chỉ được coi là tài nguyên sản xuất mã nguồn.

Lean khuyến khích các cấp quản lý lắng nghe các lập trình viên và nó khuyến khích các lập trình viên dạy cho các nhà quản lý của họ quá trình sản xuất phần mềm. Nó cũng khuyến khích các lập trình viên trực tiếp làm việc với khách hàng và người dùng. Điều này không có nghĩa là các nhà phát triển làm tất cả mọi thứ, nhưng nó mang lại cho họ sức mạnh để thúc đẩy quá trình phát triển của sản xuất. Đáng ngạc nhiên, xuất hiện cảm giác đó, "Bạn có biết rằng tính năng tuyệt vời mà người dùng yêu thích không? Đó là ý tưởng của tôi!" là một yếu tố mang tính thúc đẩy lớn lao.

Nhưng đừng nghĩ rằng điều này chỉ hiệu quả với các đội ngũ đông đảo; đội ngũ của chúng tôi nhỏ thôi. Công ty chúng tôi chỉ có một số ít các nhà phát triển, vì vậy chúng tôi luôn gần gũi với người dùng của mình. Mối quan hệ đó đã cho phép chúng tôi ảnh hưởng đến sản phẩm của chúng tôi vượt ra khỏi những điều các nhà quản lý của chúng tôi có thể đã hình dung ban đầu.

6 - Xây dựng tính toàn vẹn

Bất cứ điều gì cản đường trong sản xuất là sự lãng phí.

Tính toàn vẹn là về sự mạnh mẽ của sản phẩm của bạn và đó là cách khách hàng nhìn nhận sản phẩm của bạn như một tổng thể. Tính toàn vẹn là về tính đồng nhất của UI, độ tin cậy và bảo mật và người dùng cảm thấy an toàn khi sử dụng sản phẩm của bạn. Tính toàn vẹn là hình ảnh hoàn chỉnh mà người dùng tạo cho sản phẩm của bạn. Ví dụ: tính toàn vẹn của UI liên quan đến giao diện giữa các trang, màn hình, mô-đun hoặc thậm chí giữa giao diện người dùng của hệ thống của bạn và trang web của công ty.

Nhưng tính toàn vẹn cũng có thể được quan sát và thực hành ở cấp mã nguồn. Tính toàn vẹn có thể có nghĩa rằng các mô-đun, class và các phần khác của bạn được viết theo cách tương tự. Bạn sử dụng các nguyên tắc, pattern và kỹ thuật giống nhau trong toàn bộ code base của mình - ngay cả giữa các đội nhóm khác nhau. Tính toàn vẹn có nghĩa là bạn phải thường xuyên cấu trúc lại code của mình. Đó là nhiệm vụ liên tục và vô tận, và bạn sẽ phấn đấu cho nó, nhưng không bao giờ đạt được nó.

Duy trì tính toàn vẹn trong mã nguồn của chúng tôi là một nhiệm vụ khó khăn. Chúng tôi nhận ra rằng việc tìm code bị trùng lặp là điều khó thực hiện nhất và bằng cách sao chép, tôi không có ý là một vài dòng code trùng lặp trong cùng một cùng một phương thức hoặc một class.

Thậm chí đó không phải nói về việc tìm kiếm trong các mô-đun khác nhau cho cùng cùng một code; mà là về việc tìm ra những logic thông thường đó, trích xuất chúng vào các class riêng của chúng và sử dụng chúng ở vài nơi.

Việc tìm kiếm trùng lặp logic rất khó và đòi hỏi kiến thức sâu về mã nguồn.

Tôi đã làm việc trong một dự án trong hơn một năm và tôi vẫn ngạc nhiên khi thấy code bị trùng lặp. Nhưng đó là một điều tốt; chúng tôi đã đạt đến giai đoạn mà chúng tôi thực sự nhìn thấy những điều này và có hành động. Vì chúng tôi bắt đầu chủ động loại bỏ logic trùng lặp ở cấp cao, chất lượng code của chúng tôi tăng lên. Chúng tôi đang tiến bước gần hơn để đạt được sự toàn vẹn.

7 - Xem qua toàn bộ

Không phải lúc nào người dùng cũng biết họ muốn gì.

Khi bạn tạo ứng dụng của mình, bạn phải suy nghĩ về các thành phần bên thứ ba mà bạn dựa vào để phát triển sản phẩm của mình, cũng như các bên thứ ba khác mà sản phẩm của bạn giao tiếp. Ứng dụng của bạn cần tích hợp với thiết kế của một thiết bị hoặc hệ điều hành trên PC. Sẽ không dễ sử dụng ứng dụng tích hợp với hệ thống thông báo của điện thoại thông minh của bạn và UI phản ánh UI của hệ điều hành?

Vâng, việc nhìn thấy toàn bộ không dễ dàng. Bạn phải tách mình ra khỏi những chi tiết nhỏ và nhìn sản phẩm của bạn ở góc rộng hơn. Một trong những khoảnh khắc đáng nhớ của quá trình phát triển sản phẩm của chúng tôi là khi chúng tôi nhận ra rằng chúng tôi phải dựa vào những thứ mà các lập trình viên khác cho ra đời trong các dự án khác. Chúng tôi nhận ra rằng kernel của hệ thống, được lập trình bởi những người khác, là một trong những thành phần bên thứ ba mà chúng tôi phụ thuộc vào.

Có thời điểm, thành phần bên thứ ba đó đã thay đổi. Chúng tôi có thể vừa áp dụng các thiết bị hỗ trợ băng tần cho ứng dụng của mình hoặc chúng tôi có thể chọn con đường dễ dàng và đổ lỗi cho các lập trình viên đã tạo nên thành phần đó. Thay vào đó, chúng tôi đã xử lý vấn đề bằng sự quyết đoán và khắc phục sự cố trong kernel từ bên thứ ba. Việc nhìn ra toàn bộ và làm việc với nó có thể lộn xộn, nhưng có thể tạo ra sự khác biệt giữa một sản phẩm và một sản phẩm tuyệt vời.


Kanban - Một công cụ tuyệt vời

Có vài công cụ và kỹ thuật để làm cho Lean hiệu quả. Tôi thích Kanban, một công cụ dựa trên các bảng tương tự như bảng kế hoạch của Scrum. Hãy tưởng tượng một bảng Kanban như một bộ phễu đôi.

Bên trái là danh sách những story không bao giờ kết thúc mà chúng ta cần giải quyết. Tất cả các story đã hoàn thành xếp qua bên phải và manager hoặc product owner sẽ xác định khi nào sẽ xuất bản một bản phát hành mới, dựa trên danh sách này.

Ở giữa là quá trình hiệu quả của Kanban của chúng tôi. Sản phẩm phải ở tình trạng ổn định và sẵn sàng phát hành khi chúng tôi hoàn thành một story. Không nhất thiết là một tính năng đã được hoàn tất; sản phẩm có thể có một vài tính năng được thực hiện chỉ một phần. Nhưng sự ổn định, bảo mật và mạnh mẽ của sản phẩm phải là ở mức chất lượng cho sản xuất.

Các bản phát hành linh hoạt hơn

Chúng tôi đã làm khá tốt với sprint hiện tại của chúng tôi. Đó là một ngày thứ Hai bình thường, một ngày yên bình pha chút phấn khích, nhưng chúng tôi bắt đầu thấy một số vấn đề vào thứ Tư. Vẫn ổn, điều đó thường xảy ra. Tuy nhiên, việc khắc phục những khó khăn này cần thêm thời gian. Product owner của chúng tôi đã đồng ý để chúng tôi tiếp tục làm việc với tính năng hiện tại và kéo dài thời gian của sprint hiện tại khoảng ba hoặc bốn ngày nữa.

Thứ sáu có bất ngờ xảy ra. Bạn biết quy tắc: nếu thứ gì đó sắp hỏng, nó sẽ diễn ra vào ngày thứ Sáu. Một khách hàng quan trọng và tiềm năng yêu cầu một tính năng cụ thể trước khi ký hợp đồng với công ty. Chúng tôi đã phải phản ứng (và nhanh chóng!). Bắt buộc có một bản phát hành mới ... Nhưng chờ đã! Chúng tôi đang ở giữa một sprint. Sản phẩm nên được phát hành vào cuối sprint. Chúng ta làm gì đây? Scrum thì sẽ cho biết nên thực hiện tính năng mới trong sprint tiếp theo, nhưng chúng ta đã quá hạn với sprint hiện tại! Đó là lúc khi chúng tôi bắt đầu nhận ra rằng chúng tôi phải suy nghĩ nhỏ hơn là một sprint riêng lẻ. Chúng tôi cần có khả năng thích ứng nhanh hơn và chúng tôi cần phát hành sớm hơn nếu cần thiết.


Kaban board (bảng)

Một bảng Kanban trông khá giống với bảng kế hoạch Scrum, nhưng với một vài bổ sung để phù hợp hơn với quy trình Lean.

Cột đầu tiên bên trái là backlog đầy đủ: mọi thứ chúng ta cần làm vào một lúc nào đó. Ở phía bên phải, bạn có các kênh khác, chứa tất cả các story đã hoàn thành (nhưng chưa được phát hành).

Ở giữa là quá trình của chúng tôi. Các cột này có thể khác nhau tùy thuộc vào từng đội ngũ và quy trình. Thông thường nên có ít nhất một cột cho vài nhiệm vụ tiếp theo và một cột khác cho các story hiện đang được phát triển. Hình ảnh trên cho thấy một số cột khác để trình bày tốt hơn cho quá trình phát triển.

Cột To-Do liệt kê các nhiệm vụ mà chúng ta cần hoàn thành. Sau đó, chúng tôi có Design, nơi các nhà phát triển làm công việc thiết kế các story hiện tại. Cột thứ tư là Development, phần code thực tế. Cuối cùng, cột Testing liệt kê các nhiệm vụ đang chờ xem xét bởi một thành viên khác trong nhóm.

Hạn chế công việc đang tiến hành

Chẳng ai biết tất cả mọi thứ.

Nếu bạn so sánh bảng Kanban này với bảng kế hoạch scrum, bạn sẽ nhận thấy ngay sự khác biệt rõ ràng. Đầu tiên, mỗi cột có một con số, biểu thị số lượng story tối đa được phép hiện diện trong cột đó. Chúng tôi có 4 to-do (việc phải làm), 4 trong design, 3 trong development và 2 trong testing. Backlog và nhiệm vụ đã hoàn thành không có giới hạn như vậy.

Mỗi giá trị của cột phải được xác định bởi đội ngũ. Trong hình trên, tôi đã gán các số tùy ý cho các cột; con số của bạn có thể khác nhau đáng kể. Ngoài ra, những con số này không phải con số cuối cùng. Hãy điều chỉnh các con số khi bạn xác định và loại bỏ các tắc nghẽn.

Phân bổ tài nguyên linh hoạt

Một trong những giá trị tuyệt vời nhất của Kanban và Lean là tầm quan trọng của việc hợp tác và tái phân bổ các nỗ lực. Như bạn có thể thấy trên bảng, mỗi cột trong quy trình của chúng tôi chứa các thẻ có tên người trên đó. Có 7 nhà phát triển trên bảng ví dụ - một đội ngũ khá lớn! Bảng luôn biểu thị tình trạng hiện tại của những người đang làm những gì tại bất kỳ thời điểm nào.

Theo bảng của chúng tôi, có ba cá nhân làm việc về design, hai cặp làm việc development và một đang làm testing. Story được chuyển sang cột tiếp theo, công việc của họ trong cột hiện tại đã hoàn tất và tùy thuộc vào kiểu phát triển và tổ chức của đội ngũ, một nhà phát triển có thể tiếp tục làm việc trên cùng một story khi nó di chuyển qua quy trình.

Hãy giả sử rằng chúng ta có những người chuyên biệt. Vì vậy, chức năng chính của 3 nhà thiết kế là thiết kế, 4 nhà phát triển viết code và người kiểm tra cô đơn chủ yếu kiểm tra tính năng sản phẩm. Nếu một nhà thiết kế (designer) hoàn thành một story, story sẽ chuyển sang development và một story khác từ to-do (việc cần làm) được chuyển vào vào design (thiết kế).

Đây là một quá trình bình thường. Một story đã được chuyển từ thiết kế sang phát triển, và bây giờ phần phát triển đạt mức tối đa các story của nó. Nhưng nếu một nhà thiết kế khác hoàn thành một story khác thì sao? Điều đó có nghĩa đội ngũ phát triển có 4 story - một tình huống không mong đợi.

Lean muốn tránh sự tắc nghẽn. Một story sẽ không được chuyển sang cột kế tiếp nếu số lượng trong cột đã tối đa. Trong trường hợp này, tài nguyên cần được phân bổ lại; người thiết kế đã hoàn thành nhiệm vụ của họ phải chọn xem họ sẽ làm gì tiếp theo. Lựa chọn đầu tiên của anh ta là lấy một nhiệm vụ khác từ cột to-do, nhưng anh ta không thể làm vậy vì anh ta cần chuyển nhiệm vụ mới hoàn thành của mình cho nhóm phát triển (anh ta không thể làm điều này). Lựa chọn duy nhất khác của anh là bắt đầu thực hiện một story trong phần phát triển. Anh ta có thể không phải là nhà phát triển tốt nhất, nhưng những nỗ lực của anh ta sẽ giúp duy trì luồng quy trình.

Nếu người thử nghiệm hoàn thành story cuối cùng trong cột của mình, anh ta có thể giúp nhà thiết kế thực hiện nhiệm vụ phát triển của mình.

Điều đó thật tuyệt! Đội ngũ có thể tổ chức lại nhanh chóng! Bạn có thấy sự lãng phí không? Bạn có thấy một tình huống bế tắc trong luồng công việc không? Hãy nhanh tay hành động đi!

Khi một story trong cột phát triển được hoàn thành, người thử nghiệm quay lại thử nghiệm, người thiết kế quay lại phần thiết kế và người phát triển chọn story mà người thiết kế và người thử nghiệm đã làm việc. Nhưng hãy nhớ rằng bạn không phải tuân theo quy định chính xác đó; nhà phát triển có thể bắt đầu thiết kế khi người thiết kế và người thử nghiệm hoàn thành việc phát triển story của họ. Điều đó tùy thuộc vào bạn!

Bảng của của chúng tôi đã trở lại bình thường.

Chào mừng đến Scrum-Ban

Story không được chuyển sang cột tiếp theo nếu cột đã chứa tối đa.

Tôi hoài niệm khi scrum master của chúng tôi tháo dỡ tấm bảng của chúng tôi. Từng mảnh một, anh xé tấm bảng yêu dấu của chúng tôi, rồi nó trở thành một núi giấy nhàu nát.

Một đồng nghiệp khác bước vào phòng với vài tờ giấy trắng lớn trong tay anh ta. Bảng của chúng tôi sắp được tái sinh thành một cái gì đó khác biệt, phù hợp hơn cho nhu cầu của chúng tôi. Sau khi các tờ giấy được dán lên tường, chúng tôi bắt đầu một cuộc họp không chính thức để xác định các cột cần cho quy trình của chúng tôi. Sau đó, chúng tôi đã tranh luận về số lượng story mỗi cột nên có. Sau khi mọi thứ được vẽ cẩn thận và sắp xếp trên tường, chúng tôi đã nếm trải cảm giác kỳ lạ đó ... nỗi buồn cho người cũ nhưng hạnh phúc cho người mới.

Chúng tôi đã làm một cái gì đó mà nhiều người gọi là Scrum-Ban. Chúng tôi giữ lại một số khái niệm scrum, chẳng hạn như scrum master và vai trò của product owner, và chúng tôi vẫn ước tính và đánh giá các story. Nhưng bây giờ chúng tôi tập trung vào Lean và Kanban, bảo toàn tiến trình, phát hiện và điều chỉnh sự lãng phí và bế tắc.

Việc thay đổi từ Scrum sang Lean thực sự giải phóng. Các thành viên trong đội ngũ trở nên thân thiện với nhau hơn nhiều và chúng tôi hiểu rằng nên đề xuất giúp đỡ ngay khi không có gì trong cột của chúng tôi. Cảm giác mà các nhà phát triển bận tâm khiến chúng tôi nghĩ về dự án như một tổng thể; chúng tôi quan tâm đến dự án nhiều hơn bao giờ hết.


Tổng kết

Lean không phải lúc nào cũng được coi là Agile. Thậm chí ngày nay, một số người tuân thủ Agile từ chối công nhận nó là một phương pháp Agile. Nhưng càng ngày, các lập trình viên chấp nhận Lean là một trong những phương pháp Agile tối thượng.

Như một trong số đồng nghiệp thông thái của tôi đã chỉ ra, Lean và Kanban cho phép bạn làm theo phương pháp này theo cách của bạn. Vì vậy, nếu bạn là một nhà phát triển đơn lẻ và cần một số công cụ khiến cuộc sống của bạn dễ dàng hơn, hãy thử một số công cụ Kanban miễn phí.

AgileZen là website cung cấp một tài khoản miễn phí, cho phép bạn theo dõi một dự án riêng lẻ.

Tôi thấy đó là một trong những công cụ Kanban trực tuyến miễn phí tốt nhất; Tôi thậm chí sử dụng mỗi ngày để theo dõi và lập kế hoạch tiến trình của các bài viết và khóa học mà tôi cung cấp cho Tuts+. Tất nhiên, bạn luôn có thể nâng cấp tài khoản AgileZen của mình, nếu bạn cần theo dõi nhiều dự án hơn.

Trong bài viết này, chúng tôi đã xem xét Lean và Kanban như một tiến hóa của Scrum. Điều này có nghĩa là Lean tốt hơn Scrum? Dĩ nhiên là không! Điều này phụ thuộc vào các dự án và những người bạn cùng làm việc. Hãy luôn chọn phương pháp Agile phù hợp nhất cho bạn và đội ngũ của bạn.

Advertisement
Advertisement
Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.