Phát triển phần mềm Agile (Agile software development) đề cập đến các phương pháp phát triển phần mềm xoay quanh ý tưởng phát triển lặp đi lặp lại (iterative), trong đó các yêu cầu và giải pháp sẽ ‘tiến hóa’ thông qua sự hợp tác giữa các đội nhóm liên chức năng.

Giá trị tột đỉnh trong Agile development là nó cho phép các đội nhóm phân phối giá trị nhanh hơn, với chất lượng và khả năng dự đoán, cũng như khả năng phản ứng với thay đổi cao hơn.

Scrum và Kanban là hai trong số những phương pháp luận Agile được sử dụng rộng rãi nhất.

Dưới đây là những câu hỏi thường gặp nhất xung quanh Agile và Scrum, do các chuyên gia của chúng tôi trả lời.

Agile là gì?

Phát triển phần mềm Agile đề cập đến một nhóm các phương pháp phát triển phần mềm dựa trên sự phát triển lặp đi lặp lại, trong đó các yêu cầu và giải pháp phát triển thông qua sự hợp tác giữa các đội nhóm liên chức năng.

Nhìn chung, các phương pháp Agile hay quy trình Agile thể hiện một quy trình quản lý dự án có tính kỷ luật mà cổ vũ việc kiểm tra và điều chỉnh thường xuyên, một triết lý lãnh đạo khuyến khích làm việc nhóm, tự tổ chức và trách nhiệm, một tập hợp các thực tiễn kỹ thuật tốt nhất nhằm cho phép phân phối nhanh chóng phần mềm chất lượng cao, và một phương pháp kinh doanh gắn kết sự phát triển với nhu cầu của khách hàng và mục tiêu của công ty.

Phát triển Agile đề cập đến bất kỳ quy trình phát triển nào phù hợp với các khái niệm của Tuyên ngôn Agile (The Agile Manifesto).

Tuyên ngôn này được phát triển bởi một nhóm gồm 14 nhân vật hàng đầu ngành phần mềm và phản ánh kinh nghiệm của họ về những cách tiếp cận hiệu quả và không hiệu quả đối với phát triển phần mềm.

Scrum là gì?

Scrum là một tập hợp con của Agile. Đây là một khung quy trình (process framework) gọn nhẹ cho phát triển agile và là khung được sử dụng rộng rãi nhất.

“Khung quy trình” là một tập hợp các thực hành cụ thể phải tuân theo để một quy trình nhất quán với khung. (Ví dụ: khung quy trình Scrum yêu cầu sử dụng các chu trình phát triển được gọi là Sprint, khung XP yêu cầu lập trình cặp – pair programming,…)
“Nhẹ” có nghĩa là tổng chi phí của quy trình được giữ ở mức nhỏ nhất có thể, nhằm tối đa lượng thời gian hiệu quả để hoàn thành công việc hữu ích.

Quy trình Scrum được phân biệt với các quy trình agile khác bằng các khái niệm và thực hành cụ thể, được chia thành ba loại Roles (Vai trò), Artifacts (Tạo tác) và Time Boxes (Các hộp thời gian).

Scrum thường được sử dụng để quản lý việc phát triển phần mềm và sản phẩm phức tạp, sử dụng các phương pháp lặp đi lặp lại và tăng dần.

Scrum làm tăng năng suất và giảm thời gian đáng kể, nhiều lợi ích hơn so với quy trình “thác nước – waterfall” cổ điển.

Quy trình Scrum cho phép tổ chức điều chỉnh mượt mà theo các yêu cầu thay đổi chóng mặt và tạo ra sản phẩm đáp ứng các mục tiêu kinh doanh mới.

Một quy trình Scrum có tính agile mang lại lợi ích sau cho tổ chức:

Tăng chất lượng sản phẩm
Đối phó tốt hơn với sự thay đổi
Cung cấp các ước lượng tốt hơn trong khi tốn ít thời gian hơn
Kiểm soát tốt hơn lịch trình và trạng thái của dự án

Lợi ích của Agile là gì?

Lợi ích với Khách hàng

Khách hàng nhận thấy nhà cung cấp phản hồi nhanh hơn với các yêu cầu phát triển.

Các tính năng có giá trị cao được phát triển và phân phối nhanh hơn với chu kỳ ngắn, so với chu kỳ dài hơn của các quy trình “thác nước”.

Lợi ích với Nhà cung cấp

Nhà cung cấp giảm lãng phí bằng cách tập trung nỗ lực phát triển vào các tính năng có giá trị cao và giảm thời gian đưa ra thị trường nhờ việc giảm chi phí và tăng hiệu quả.

Sự hài lòng của khách hàng được cải thiện đồng nghĩa với việc giữ chân khách hàng tốt hơn và nhiều khách hàng được giới thiệu hơn.

Lợi ích với Đội ngũ phát triển

Các thành viên trong đội ngũ thích công việc phát triển và thích thấy sản phẩm của mình được sử dụng và đánh giá cao.

Scrum mang lại lợi ích cho các thành viên trong đội nhờ giảm bớt những việc không năng suất (ví dụ: viết thông số kỹ thuật hoặc các thứ mà không ai sử dụng) và cho họ thời gian làm công việc yêu thích.

Các thành viên cũng biết công việc của họ được coi trọng, bởi vì các yêu cầu được lựa chọn để tối đa hóa giá trị cho khách hàng.

Lợi ích với Product manager

Product manager chịu trách nhiệm làm cho khách hàng hài lòng bằng cách đảm bảo hoạt động phát triển phù hợp với nhu cầu của khách hàng.

Scrum làm cho sự liên kết này trở nên dễ dàng hơn bằng cách cung cấp các cơ hội thường xuyên để sắp xếp lại thứ tự ưu tiên công việc, nhằm đảm bảo mang lại giá trị tối đa.

Lợi ích đối với Project manager

Project manager đảm nhiệm vai trò ScrumMaster thấy việc lập kế hoạch và theo dõi dễ dàng và cụ thể hơn, so với quy trình thác nước.

Sự tập trung vào việc theo dõi ở mức tác vụ, sử dụng Burndown Charts để hiển thị tiến độ và các cuộc họp Scrum hàng ngày, đều mang lại cho Project manager nhận thức sâu sắc về trạng thái của dự án vào mọi lúc.

Nhận thức này là chìa khóa để giám sát dự án, đồng thời nắm bắt và giải quyết các vấn đề một cách nhanh chóng.

Lợi ích đối với PMO và Giám đốc cấp C

Scrum cung cấp khả năng hiển thị trạng thái hàng ngày của một dự án phát triển.

Các bên liên quan bên ngoài, chẳng hạn như giám đốc Cấp C và nhân sự thuộc Phòng quản lý dự án, có thể sử dụng khả năng này để hoạch định hiệu quả hơn và điều chỉnh chiến lược của họ dựa trên nhiều thông tin và ít mang tính suy đoán hơn.

Các yêu cầu Scrum là gì?

Scrum không chỉ xác định các yêu cầu biểu mẫu cần thực hiện mà còn tập hợp chúng vào Product Backlog (Nhật ký sản phẩm), và được gọi chung là “Product Backlog Items” hay viết tắt là “PBI”.

Với bản chất đóng hộp thời gian ‘time-boxed’ của Sprint, chúng ta có thể suy ra mỗi tập hợp cần ít thời gian thực hiện hơn so với thời lượng của Sprint.

Hầu hết các dự án Scrum đều mượn phương pháp “XP” (Extreme Programming) để mô tả một yêu cầu tính năng thành “Câu chuyện người dùng – User story”, mặc dù vẫn có số ít sử dụng khái niệm cũ hơn là “Use Case”.

Chúng ta sẽ bám theo quan điểm của đa số và mô tả ba yêu cầu tiêu chuẩn trong Product Backlog.

User story

User story mô tả một tính năng mong muốn (yêu cầu chức năng) ở dạng tường thuật. User story thường do Product Owner viết và là trách nhiệm của Product Owner.

Định dạng không được tiêu chuẩn hóa, nhưng thường có tên, nội dung mô tả, tham chiếu đến tài liệu bên ngoài (chẳng hạn như ảnh chụp màn hình) và thông tin về cách kiểm tra việc triển khai.

Một câu chuyện có thể giống như sau:

Tên: Người lập kế hoạch nhập thông tin liên hệ mới vào sổ địa chỉ, để có thể liên hệ với người đó sau này qua thư hoặc email
Mô tả: Planner nhập thông tin liên hệ chuẩn (họ và tên, địa chỉ, thành phố/tỉnh, mã zip / mã bưu chính, quốc gia, v.v.) vào màn hình nhập liên hệ. Nhấp vào “Lưu” để giữ dữ liệu và “Hủy” để hủy dữ liệu và quay lại màn hình trước đó.
Cách kiểm tra: Tester nhập và lưu dữ liệu, tìm tên trong sổ địa chỉ và nhấp vào đó. Sẽ thấy một chế độ xem read-only của màn hình nhập liên hệ, với tất cả dữ liệu đã được nhập trước đó.

Các yếu tố trong User story này là:

Tên

Tên là một cụm từ hoặc câu mô tả. Ví dụ trên sử dụng một cơ cấu cơ bản “Vai trò-Hành động-Lý do”.
Một kiểu khác, được phổ biến bởi Mike Cohn, theo mẫu “Là một <loại người dùng>, tôi muốn <mục tiêu> để <lý do>.”
Việc lựa chọn mẫu nào không quan trọng bằng việc có một loại tiêu chuẩn nào đó.

Mô tả

Đây là mô tả cấp độ cao (chi tiết thấp) về nhu cầu cần đáp ứng.
Với các yêu cầu về chức năng (hướng đến người dùng), mô tả thường ở dạng tường thuật. Với các yêu cầu phi chức năng, mô tả có thể được viết bằng bất kỳ hình thức nào dễ hiểu.
Trong cả hai trường hợp, điểm mấu chốt là mức độ chi tiết không quá cao, vì các chi tiết được giải quyết trong giai đoạn thực hiện, trong các thảo luận giữa các thành viên trong nhóm, product owner hay bất kỳ ai có liên quan.

Màn hình và tài liệu bên ngoài

Nếu story yêu cầu thay đổi giao diện người dùng (đặc biệt là những thay đổi không quan trọng), thì nó phải chứa hoặc liên kết đến nguyên mẫu của những thay đổi.
Bất kỳ tài liệu bên ngoài nào được yêu cầu để triển khai story cũng cần được liệt kê.

Cách kiểm tra

Việc triển khai một Story được xác định là hoàn thành nếu và chỉ khi, nó vượt qua tất cả các bài kiểm tra được phát triển cho nó.
Phần này cung cấp một mô tả ngắn gọn về cách story sẽ được kiểm tra.
Đối với bản thân tính năng, mô tả các phương pháp thử nghiệm hãy ngắn gọn, với các chi tiết sẽ được giải quyết trong quá trình thực hiện, nhưng chúng ta cần ít nhất một tóm lược để hướng dẫn quá trình ước tính.

Có hai lý do cho việc cần đưa thông tin về cách kiểm tra Story. Lý do rõ ràng là để hướng dẫn phát triển các test case cho story.

Lý do ít rõ ràng hơn, nhưng quan trọng, là team sẽ cần thông tin này để ước tính lượng công việc cần thiết để thực hiện story (vì thiết kế và thực hiện thử nghiệm là một phần của tổng thể công việc).

Story

Không phải tất cả các yêu cầu phát triển đều đại diện cho các tính năng hướng đến người dùng, mà đại diện cho công việc quan trọng phải được thực hiện.

Những yêu cầu này thường, nhưng không luôn luôn, đại diện cho công việc phải được hoàn thành để hỗ trợ các tính năng hướng tới người dùng. Chúng ta gọi những yêu cầu phi chức năng này là “Câu chuyện kỹ thuật – Technical Story”.

Technical story có các yếu tố tương tự như User story, nhưng không cần chuyển sang dạng tường thuật nếu không có ích lợi gì khi làm vậy.

Technical story thường được viết bởi các thành viên trong team và được thêm vào Product Backlog.

Product Owner phải quen thuộc với những story này và hiểu rõ mối quan hệ phụ thuộc giữa các story này và User story để xếp hạng (trình tự) tất cả các story cần triển khai.

Lỗi

Báo cáo lỗi (defect / bug report) là một mô tả về lỗi của sản phẩm. Các lỗi được lưu trữ trong hệ thống theo dõi lỗi, hệ thống này có thể giống hoặc không giống hệ thống thực tế được sử dụng để lưu trữ Product Backlog.

Nếu không, thì ai đó (thường là Product Owner) phải nhập từng Lỗi vào Product Backlog, để sắp xếp và lên lịch.

Các vai trò trong Scrum

Ba vai trò được xác định trong Scrum là ScrumMaster, Product Owner và Team (bao gồm các thành viên trong team).

Những vai trò này làm việc cùng nhau chặt chẽ hàng ngày để đảm bảo luồng thông tin được thông suốt và giải quyết các vấn đề một cách nhanh chóng.

ScrumMaster

ScrumMaster (đôi khi được viết là “Scrum Master”, mặc dù thuật ngữ chính thức không có khoảng trắng sau “Scrum”) là người quản lý quy trình Scrum.

ScrumMaster chịu trách nhiệm làm cho quy trình diễn ra suôn sẻ, loại bỏ các trở ngại ảnh hưởng đến năng suất và tổ chức, xúc tiến các cuộc họp quan trọng.

Các trách nhiệm của ScrumMasters bao gồm:

Hướng dẫn Product Owner cách tối đa lợi tức đầu tư (ROI) và đạt được các mục tiêu thông qua Scrum.
Cải thiện đời sống của Đội ngũ phát triển bằng cách tạo điều kiện cho sáng tạo và trao quyền.
Cải thiện năng suất của Đội ngũ phát triển theo bất kỳ cách nào có thể.
Cải thiện các công cụ và phương pháp kỹ thuật để mỗi khi gia tăng chức năng phần mềm đều có thể chuyển giao được.
Luôn cập nhật thông tin về tiến độ của team và hiển thị cho tất cả các bên.

Thực tế mà nói, ScrumMaster cần hiểu đủ về Scrum để đào tạo và cố vấn các vai trò khác, đồng thời giáo dục và hỗ trợ các bên liên quan khác tham gia vào quá trình này.

ScrumMaster nên duy trì nhận thức thường xuyên về tình trạng của dự án (tiến độ của dự án cho đến nay) so với tiến độ dự kiến, điều tra và tạo điều kiện giải quyết mọi rào cản cản trở tiến độ và đủ linh hoạt để xác định và giải quyết bất kỳ vấn đề nào phát sinh, theo bất kỳ cách nào được yêu cầu.

ScrumMaster phải bảo vệ team khỏi sự làm phiền từ những người khác bằng cách đóng vai trò là ‘giao diện’ giữa hai nhóm.

ScrumMaster không phân công nhiệm vụ cho các thành viên trong team, vì việc phân công nhiệm vụ là trách nhiệm của team.

Phương pháp chung của ScrumMaster đối với team là khuyến khích và tạo điều kiện cho khả năng ra quyết định và giải quyết vấn đề của họ, để họ có thể làm việc với hiệu quả ngày càng cao và giảm nhu cầu giám sát.

Mục tiêu là có một nhóm không chỉ được trao quyền để đưa ra các quyết định quan trọng mà còn thực hiện rất tốt và thường xuyên.

Product owner

*Product owner là gì? Vai trò và nhiệm vụ của Product owner. Ảnh: longnguyen.site*

Product owner là người lưu giữ các yêu cầu. Product Owner cung cấp “nguồn sự thật duy nhất” cho team về các yêu cầu và trình tự thực hiện theo kế hoạch của họ.

Trên thực tế, Product Owner là người giao tiếp giữa một bên là doanh nghiệp, khách hàng và các nhu cầu liên quan đến sản phẩm của họ và bên kia là team.

Product Owner hỗ trợ team từ các yêu cầu sửa lỗi và tính năng đến từ nhiều nguồn và là đầu mối liên hệ duy nhất cho tất cả các câu hỏi về yêu cầu sản phẩm.

Product Owner làm việc chặt chẽ với team để xác định các yêu cầu kỹ thuật và hướng tới người dùng, ghi lại các yêu cầu khi cần thiết và xác định thứ tự thực hiện.

Product Owner duy trì Product Backlog (là kho lưu trữ tất cả thông tin này), giữ cho nó được cập nhật ở mức độ chi tiết và chất lượng mà team yêu cầu.

Product Owner cũng lên lịch trình phát hành sản phẩm đã hoàn thành cho khách hàng và đưa ra quyết định cuối cùng về việc liệu các triển khai có các tính năng và chất lượng cần thiết để phát hành hay không.

Team

Team là một nhóm tự tổ chức và gồm nhiều chức năng, những người thực hiện công việc phát triển và thử nghiệm sản phẩm.

Vì team chịu trách nhiệm sản xuất sản phẩm, nên team cũng phải có quyền đưa ra quyết định về cách thức thực hiện công việc.

Do đó, team mang tính tự tổ chức: Các thành viên trong team quyết định cách chia công việc thành các nhiệm vụ và cách phân bổ cho các cá nhân trong suốt Sprint.

Quy mô team nên được duy trì trong khoảng từ năm đến chín người, nếu có thể. (Số lượng lớn hơn làm cho việc giao tiếp trở nên khó khăn, trong khi số lượng nhỏ hơn dẫn đến năng suất thấp và dễ banh.)

Lưu ý: Có một thuật ngữ tương tự là “Scrum Team”, dùng để chỉ team cộng với ScrumMaster và Product Owner.

Đo lường và báo cáo trong Agile

Cần đo gì trong agile là một câu hỏi không dễ trả lời. Có hai bộ lọc chính mà chúng ta nên tự hỏi trước khi đo lường bất cứ điều gì:

Liệu việc đo lường có thúc đẩy việc cung cấp giá trị không?, và
Việc đo lường có nâng cao sự tin cậy?

Dưới đây là ví dụ về đo lường.

Thông thường, một tổ chức sẽ đặt mục tiêu tăng tốc độ story point (thường dùng để ước lượng độ lớn, độ khó, độ phức tạp khi triển khai một User story) và điều này có vẻ hợp lý vì chúng ta luôn cố gắng cung cấp nhiều hơn nếu có thể.

Quan điểm này đang nhìn vấn đề từ một góc độ sai lầm vì cái chúng ta muốn là phân phối giá trị chứ không phải đầu ra cao hơn. 2 cái này không giống nhau; cái đầu tập trung vào kết quả và cái còn lại tập trung vào sản xuất.

Agile nhấn mạnh vào kết quả, tức là phân phối giá trị, không phải đầu ra.

Việc đánh đồng sự gia tăng trong tốc độ và đầu ra giả định một số điều: team làm việc không đủ chăm chỉ và đầu ra đó tương đương với giá trị. Trong đó, cả hai giả định thường không đúng sự thật.

Chúng ta nên sử dụng tốc độ để vận hành doanh nghiệp; tốc độ story point có thể được dùng để phân chia product backlog và lên kế hoạch kỹ càng về thời điểm các tính năng cụ thể sẽ khả dụng cho khách hàng.

Cái chúng ta cần làm là tốc độ ổn định, chứ không phải tốc độ thay đổi hoặc dao động.

Trong thế giới luôn có phần thưởng cho việc tăng tốc, các team sẽ chịu trách nhiệm và cung cấp tốc độ story point cao hơn. Họ sẽ thổi phồng các story point để đạt được sự gia tăng mong muốn, từ đó làm giảm khả năng vận hành doanh nghiệp vì vận tốc không còn ý nghĩa.

Một cách khác là đo lường lời nói / hành động của sprint. Đánh giá ước lượng của team về số story point họ sẽ cung cấp so với những gì họ thực hiện trong sprint. Phần thưởng tạo ra sự ổn định trong tốc độ story point, mang lại khả năng giúp doanh nghiệp dự đoán khi nào các tính năng sẽ phát hành ra thị trường.

Cái đầu tiên cho các team biết rằng họ không được tin cậy và làm hao mòn việc tạo ra giá trị phân phối, trong khi cái sau thúc đẩy cả hai.

Nó cũng khiến các team làm việc tốt khi các ước lượng của họ bắt đầu ‘hội tụ’ với hiệu suất, việc chuyển sang nói / làm mang lại cho doanh nghiệp khả năng đạt được tốc độ cũng như xây dựng lòng tin trong tổ chức. Win-Win: khách hàng, tổ chức và team.

Ví dụ Thang đo hoạt động:

Lead time (Thời gian sản xuất)
Cycle time (Thời gian chu kỳ)
Burndown Chart

Ví dụ Thang đo đầu ra:

Xuất lượng (Throughput)
Mô hình đánh giá sự nhanh nhẹn
Chất lượng kỹ thuật / đo lường lỗi / code coverage
Số lượng tính năng…

Ví dụ Thang đo kết quả / giá trị:

Tinh thần đồng đội
Sự hài lòng của khách hàng / NPS (Net Promotion Score)
Giá trị kinh doanh

SAFe là gì?

Agile development ở cấp độ đội nhóm hoặc tổ chức nhỏ đã xuất hiện trong 20 năm qua như một cách mạnh mẽ để cải thiện kết quả, sự tương tác và chất lượng.

Tuy nhiên, việc mở rộng agile thành công và lặp lại cho các tổ chức vừa và lớn lại là một vấn đề.

Scaled Agile Framework (SAFe) nổi lên như một giải pháp hàng đầu cho vấn đề đó.

SAFe là một tập hợp các nguyên tắc, cấu trúc và thực hành đã được chứng minh là có thể mở rộng các thực hànhAgile nhất quán và thành công và mang lại lợi ích của Agile cho các tổ chức hoạt động theo phương pháp thác nước hoặc ad-hoc.

Agile liên quan tới DevOps ra sao?

Mặc dù Agile và DevOps khởi đầu như các phong trào phương pháp luận độc lập, nhưng chúng có chung một số đặc điểm tập trung vào việc cải thiện hiệu quả và tốc độ của đội nhóm.

Khi các tổ chức trở nên Agile hơn và tinh chỉnh bộ kỹ năng quản lý dự án của mình, họ ngày càng phụ thuộc vào các team kỹ thuật để có thể theo kịp tốc độ và duy trì sự linh hoạt nhất định.

Đây là nơi DevOps xuất hiện với tư cách là “dương” đối với “âm” của Agile. Phương pháp DevOps giúp các nhóm phát triển sử dụng các công cụ mới, tự động hóa và các chiến lược văn hóa khác nhau để thay đổi không chỉ cách họ làm việc mà còn cả cách họ làm việc với những người khác.

Nó trở thành một mối quan hệ cộng sinh trong đó các product team (team làm sản phẩm) làm việc song song với các developer và tester và những thứ tương tự để đảm bảo mọi người có nhận thức về ngữ cảnh nhiều hơn.

Điều này thúc đẩy chất lượng tổng thể tốt hơn cho các sản phẩm trong khoảng thời gian ngắn hơn.

Nên sử dụng Scrum, Kanban hay ‘món khác’ của Agile?

Scrum là ‘món’ ưa thích của agile, nó đã hơn hai mươi năm tuổi và đã được thời gian thử thách. Kanban có nguồn gốc từ sản xuất và Toyota đã áp dụng nó vào năm 1953, một cách tiếp cận lâu đời khác. Sau đó, có nhiều loại khuôn khổ mở rộng khác nhau cần xem xét nếu quy mô tổ chức là một trong những bối cảnh của bạn.

Những nhu cầu thương mại nào thách thức doanh nghiệp của bạn? Quy mô tổ chức của bạn là gì? Công ty của bạn được tổ chức như thế nào? Team sản phẩm nòng cốt của bạn có bị phân tán ở nhiều vị trí không?

Do đó, các vấn đề thương mại thực tế mà doanh nghiệp của bạn phải đối mặt và cách bạn phản hồi với khách hàng là câu trả lời theo ngữ cảnh.

Đặt câu hỏi, “Scrum, Kanban hoặc một món agile khác” là bước đầu tiên và là nơi tuyệt vời để bắt đầu.

Việc cân nhắc chuyển đổi theo phương pháp agile là bước đầu tiên hướng tới sự bền vững. Như đã mô tả ở trên, agile là một yêu cầu cho sự thành công trong tương lai, nó không phải gì mới.

Những tổ chức không áp dụng một số hình thức agile sẽ không đáp ứng được nhu cầu của khách hàng và thị trường và bị thiệt thòi đáng kể.

Cách mở rộng sự áp dụng Agile

Mở rộng agile là một trong những vấn đề thách thức nhất cần giải quyết vì có rất nhiều biến thể về cách tổ chức được cấu trúc và nhu cầu thương mại của họ cũng đa dạng. Nhận thức này tập trung vào khái niệm ngữ cảnh.

Do sự khác biệt đa dạng đó, đã xuất hiện nhiều khung mở rộng và khái niệm “một size cho tất cả” là một tiền đề sai lầm.

Scrum là khung được sử dụng rộng rãi; do đó, hầu hết các khung mở rộng đều dùng Scrum làm cốt lõi. Sử dụng Scrum như cơ sở để giải quyết các vấn đề về mở rộng là điều hợp lý vì hầu hết chúng đều bổ sung như một kỹ thuật.

Ví dụ: các khung mở rộng SAFe sử dụng Kanban để vượt qua các thách thức mở rộng trong khi vẫn giữ Scrum làm nòng cốt.

Các vấn đề quan trọng cần xem xét khi việc mở rộng vượt ra ngoài phạm vi hoạt động của nhóm là: sự phối hợp, giao tiếp, công việc được chia sẻ hoặc phụ thuộc và làm việc từ xa của các nhóm hoặc các thành viên trong nhóm.

Những hạn chế này cũng chính là những ràng buộc khi nhóm triển khai Scrum; tuy nhiên, khi số lượng các team tăng lên, chúng khuếch đại và cực kỳ khó giải quyết.

Khi một tổ chức chuyển từ cấu trúc một nhóm sang nhiều nhóm, các vấn đề lớn hơn trở nên rõ ràng. Chúng có xu hướng trở thành lộ trình và tỷ suất đầu tư giữa các chương trình cạnh tranh để hỗ trợ tầm nhìn và mục tiêu của doanh nghiệp.

Quy mô tổ chức cũng ảnh hưởng đến việc thực hiện và áp dụng các nỗ lực mở rộng quy mô cũng như khung mở rộng được chọn.

Một doanh nghiệp có ba trăm nhân viên và một tổ chức có hàng chục ngàn nhân viên đòi hỏi các cách tiếp cận khác nhau. Lần nữa minh họa thành ngữ “một size cho tất cả”.

Hãy đảm bảo việc mở rộng mang tính tổ chức của Scrum là một hoạt động toàn công ty, không phải là một cái gì đó tách biệt với quản lý sản phẩm và kỹ thuật như thường xảy ra với việc triển khai Scrum.

Cách tiếp cận toàn diện nhất đối với sự áp dụng Agile

Thông thường, khi một tổ chức áp dụng Agile, trọng tâm được đặt vào nhóm dịch vụ kỹ thuật với một số hợp tác với bộ phận quản lý sản phẩm.

Hình mẫu này phổ biến và thường giải thích tại sao các doanh nghiệp không cảm thấy họ nhận được những lợi ích mà mình mong đợi từ việc áp dụng agile, càng làm tăng thêm phỏng đoán rằng agile không hiệu quả.

Nhu cầu thương mại, quy mô công ty, cơ cấu tổ chức và một loạt các cân nhắc khác tạo ra bối cảnh cần thiết để định hình cách tiếp cận với việc áp dụng agile.

Cho đến nay, hệ thống thành công hàng đầu đòi hỏi việc bao gồm tất cả các khía cạnh của doanh nghiệp.

Tư duy hệ thống nói rằng tất cả các lĩnh vực của công ty hoàn thành việc phân phối giá trị đều được liên kết và hoạt động cùng nhau.

Doanh nghiệp nhiều khả năng sẽ phải xem xét tái cấu trúc và chuyển đổi phong cách quản lý để đạt được sự liên kết của tổ chức.

Kết quả tốt nhất xảy ra khi đội ngũ lãnh đạo nỗ lực hết mình với tinh thần cởi mở với các khả năng khi họ cộng tác.

Cộng tác tập trung vào việc phân phối giá trị và làm việc theo cách hỗ trợ thừa nhận rằng tất cả họ sẽ điều chỉnh để hỗ trợ những khả năng đó.

Một số ví dụ là khi bộ phận kế toán chuyển đổi từ Kế toán Chi phí sang Kế toán Tinh gọn. Bộ phận nhân sự xem xét việc chuyển sang OKRs và loại bỏ MBO và KPI. Các thang đo của công ty tập trung vào những đo lường có liên quan đến giá trị phân phối hơn là đầu ra.

Cách khuếch đại tác động của Agile

Bằng việc phát triển một tổ chức học tập với lợi ích của một mục đích rõ ràng và cung cấp một môi trường nơi mọi người được tin cậy.

Tổ chức học tập

Việc trở thành một tổ chức học tập có nghĩa là gì hoặc ngụ ý gì?

Các nguyên tắc cơ bản của Scrum là kiểm tra, điều chỉnh và minh bạch. Được nhúng vào các nguyên tắc Scrum và có mặt trong mọi sự kiện dưới dạng các vòng phản hồi. Họ sẽ có nhiều cơ hội học tập và trải nghiệm thường xuyên nhất có thể.

Chúng ta cần thu hút toàn bộ công ty tham gia vào các nguyên tắc này vì lợi ích cao hơn từ agile phụ thuộc vào tư duy hệ thống. Tư duy hệ thống đi đôi với sự tập trung vào phân phối giá trị.

Chúng ta đều muốn các đo lường ảnh hưởng đến dịch vụ kỹ thuật phải nhất quán với những gì thúc đẩy hoạt động kinh doanh.

Mục đích rõ ràng

Tổ chức cần cung cấp một mục đích lớn hơn các cá nhân trong tổ chức, một mục tiêu lớn hơn bản thân tổ chức. Nó cần phải chạm đến mức độ cảm xúc của tất cả mọi người, và nó phải là lý do truyền cảm hứng để mọi người muốn đến làm việc.

Môi trường tin cậy

Mục đích là để mọi người có thể thử nghiệm và học hỏi. Thử nghiệm không chỉ đơn thuần là thất bại ở một thứ gì đó. Nếu chúng ta xây dựng một thử nghiệm, một số điều phải được xác định.

Trạng thái hiện tại, trạng thái mong muốn và bản thân thử nghiệm chuyển sang trạng thái mong muốn.

Với tập hợp các ràng buộc đó, thử nghiệm mang lại kết quả được hỗ trợ hoặc giả thuyết không. Và cả hai đều là những điểm dữ liệu quan trọng sẽ ảnh hưởng đến hành vi của chúng ta trong tương lai.

Tóm lại, agile là một môn thể thao toàn công ty và nó không chỉ đơn thuần là một hoạt động dịch vụ kỹ thuật. Nếu không có cả ba: tổ chức học tập, mục đích rõ ràng và môi trường tin cậy, tác dụng của agile sẽ bị giảm bớt.

Cách các tổ chức khác áp dụng agile thành công?

Bối cảnh là điều cần thiết, khuôn khổ cho một sự thay đổi mạnh mẽ như thay đổi cách thức hoạt động của một công ty đòi hỏi phải dẫn dắt nhân viên trong suốt hành trình thay vì lôi họ đi.

Một số lĩnh vực quan trọng để thành công là nhận ra rằng thay đổi là khó khăn và thừa nhận rằng nỗ lực này là nỗ lực của con người.

Chấp nhận các giá trị của Scrum về cam kết, can đảm, tập trung, cởi mở và tôn trọng. Và thể hiện chúng theo những cách mà công ty hoàn toàn chấp nhận chúng, để chúng trở thành những giá trị được chia sẻ về mặt tổ chức sẽ thúc đẩy thành công.

Một cách tiếp cận năng động để tìm kiếm tình nguyện viên sẽ giúp nhân viên tìm kiếm sự thay đổi tích cực và lọc ra những người phản đối sự thay đổi.

Chiến lược này sẽ loại bỏ các yếu tố cản trở tổ chức khỏi quá trình chuyển đổi vì chúng không nằm trong tiến trình hướng tới phương thức hoạt động mới.

Theo thời gian, sự thay đổi bắt đầu có những kết quả rõ ràng; nhân viên hạnh phúc hơn, sự đổi mới phát triển rõ rệt hơn và việc phân phối giá trị trở nên nhanh hơn.

Đột nhiên có động lực khi nhân viên, đội, phòng ban và các đơn vị kinh doanh sẽ kéo theo mô hình hoạt động mới của agile.

Do đó, vấn đề mở rộng agile là một thể, do đó bắt đầu từ nhóm, hoặc một vài nhóm là sự khởi đầu của cuộc hành trình là cần thiết. Thận trọng với việc áp dụng các khuôn khổ mở rộng quy mô vào ngày đầu tiên thường mang lại ít kết quả có lợi hơn về lâu dài.

Tham khảo: cprime.com

undefined undefined

1 Result agile found