PMA – Professional Management Academy

10 điều nên làm để chuyển đổi Agile thành công (Phần 2)

chuyển đổi agile

Cập nhật lần cuối vào 20/07/2022 bởi Phạm Mạnh Cường

Bạn có thể xem qua phần 1 tại đây.

Có một Agile coach chuyên nghiệp và đào tạo đội ngũ

Phát triển phần mềm Agile thể hiện một sự thay đổi lớn trong cách các tổ chức quản lý các sáng kiến ​​kinh doanh và CNTT. Như với bất kỳ sự thay đổi nào, con đường khó đi; cố gắng thực hiện với những nguồn lực không có kinh nghiệm sẽ ảnh hưởng rất nhiều đến khả năng thành công của bạn. Bạn nên có một Huấn luyện viên Agile giàu kinh nghiệm, ScrumMaster và ít nhất 20% trong nhóm có kinh nghiệm Agile sẽ cải thiện đáng kể cơ hội thành công .

Trong cách tiếp cận Waterfall, thường có các đầu mối đảm bảo chất lượng hoặc các kỹ sư quy trình để quản lý và giám sát rằng các quy trình được tuân thủ một cách chính xác. Trong cách tiếp cận nhanh nhẹn, một Huấn luyện viên Agile được sử dụng để quản lý và giám sát các quy trình. 

Các huấn luyện viên nhanh nhẹn giàu kinh nghiệm mang lại:

  • Kiến thức sâu sắc về Agile – Kinh nghiệm với cả các kỹ thuật và nguyên tắc đằng sau chúng.
  • Kinh nghiệm rộng – Một Huấn luyện viên Agile nên mang lại kinh nghiệm với một số tổ chức và đã trải qua các vấn đề và thành công.
  • Quan điểm Công bằng – Thay đổi tổ chức không dễ dàng. Có thể khó khăn hơn để một người trong cuộc thoát khỏi vai trò cũ của họ và bị coi như một tác nhân thay đổi.
  • Kỹ năng huấn luyện – Agile không chỉ mang lại các công cụ và quy trình mới mà còn mang đến một nền văn hóa cộng tác mới. Một Huấn luyện viên Agile có thể hỗ trợ các cá nhân và nhóm cố gắng đến với nhau lần đầu tiên.
  • Học tập củng cố – Trong khi nhiều chương trình Agile bắt đầu bằng việc đào tạo, việc tăng cường kỹ năng của OTJ giúp thể chế hóa các quy trình.

Như đã nêu ở trên, một huấn luyện viên nhanh nhẹn có kinh nghiệm là không đủ, đội cần truyền kinh nghiệm ở các cấp độ khác nhau và đào tạo cho những người khác. Agile Coaching là một nghề đã được thành lập. Tất cả các tổ chức nên cân nhắc việc thuê một Huấn luyện viên Agile có kinh nghiệm trong quá trình chuyển đổi; sau quá trình chuyển đổi, trách nhiệm thường được giao cho ScrumMaster.

Hiện nay có nhiều loại hình đào tạo và cấp chứng chỉ quốc tế. Việc đào tạo nên diễn ra ở cả quản lý và nhóm. Có thể kể đến các chương trình chứng nhận Agile như Scrum Alliance, PMI, Scrum.org , DSDM.org , v.v. rất hữu ích. 

Vì Agile là điều mới mẻ đối với nhiều tổ chức, điều quan trọng là phải cung cấp đào tạo cho càng nhiều người thực tế càng tốt, những người sẽ tham gia vào quá trình này. Điều này có thể bao gồm từ đào tạo nhận thức (một cái gì đó đơn giản như một video YouTube dài 10 phút) đến đào tạo chứng nhận chính thức đầy đủ. 

Bắt đầu từ quy mô nhỏ và gặt hái thành công sớm

Suy nghĩ thông thường đối với bất kỳ thay đổi nào trong tổ chức là bắt đầu nhỏ với các thí điểm, học hỏi từ chúng, và sau đó dần dần đưa sự thay đổi vào phần còn lại của tổ chức. Việc giới thiệu Agile vào tổ chức của bạn cũng không khác gì.

Không gì có thể giúp một chương trình Agile đạt được nhiều sức hút hơn việc thể hiện những thành công hữu hình ban đầu. Và ngược lại, không gì có thể làm xáo trộn một quá trình mới nhanh hơn việc thực thi nó trước khi nó chín muồi. 

Sau khi quy trình đã trưởng thành, chỉ khi đó, việc thử thách quy trình với những công việc khó khăn hơn mới có ý nghĩa. 

Đây là một vài lợi ích khi bạn bắt đầu từ quy mô nhỏ:

  • Ít tốn kém hơn – Các sáng kiến ​​mới thường chạy với tốc độ chậm hơn ban đầu và sau đó thu được lực kéo. Việc cam kết ít nguồn lực hơn ban đầu giúp kiểm soát chi phí bằng cách cho phép nhóm tập trung và học hỏi từ thử nghiệm và sai sót trên cơ sở hạn chế về chi phí. Các dự án trong tương lai sẽ nhận ra lợi ích nhanh hơn dựa trên các bài học kinh nghiệm được đúc kết từ những sáng kiến ​​ban đầu này.
  • Thành công ban đầu gần như được đảm bảo – Bằng cách lựa chọn cẩn thận dự án ban đầu và các thành viên trong nhóm sẽ làm việc với nó, đồng thời duy trì phạm vi nhỏ, bạn có thể mong đợi thành công nói chung.
  • Rủi ro thấp hơn – Việc toàn bộ tổ chức của bạn bắt đầu sử dụng một quy trình chưa hoàn thiện có thể dẫn đến nhầm lẫn và cuối cùng là thất bại. Nếu bạn bắt đầu chuyển đổi tổ chức của mình quá sớm và bạn mắc sai lầm, bạn sẽ tăng cơ hội phản kháng.
  • Ít căng thẳng hơn – Có nguồn lực với kinh nghiệm Agile như đã mô tả ở trên, nên giảm bớt mối quan tâm của những người khác trong tổ chức. Các quy trình mới vốn đã căng thẳng; khiến toàn bộ tổ chức cảm thấy rằng tránh được căng thẳng bằng cách bắt đầu từ việc nhỏ.
  • Có thể được thực hiện mà không cần tổ chức lại. Chỉ có một vài người tham gia đội thí điểm sẽ ít gây xáo trộn hơn cho một tổ chức. Sau khi nhận ra những lợi ích và thành công của các phương pháp Agile, có thể cần hoặc không cần tổ chức lại.

Bắt đầu từ quy mô nhỏ cũng có thể tiết lộ những thách thức mới. 

Ví dụ: Nếu một nhóm Agile cần sự hỗ trợ từ các nhóm non-Agile, các buổi lập kế hoạch chung cần được tổ chức để sớm giải quyết những phụ thuộc này trong quá trình. Mối quan hệ tiền nhiệm / người kế nhiệm và các yêu cầu từ mỗi nhóm (Agile / non-Agile) phải được hiểu rõ, liên kết và lên kế hoạch để đạt được thành công.

Thiết lập các cách đo lương hiệu suất Agile

Một điểm khác biệt chính giữa các phương pháp Agile và truyền thống là các phương pháp truyền thống tập trung vào việc cung cấp danh sách các yêu cầu cơ bản, trong khi Agile liên tục đánh giá, định hướng lại và lập kế hoạch lại các yêu cầu cần thực hiện cho mỗi lần lặp lại. 

Trọng tâm của Agile là làm việc dựa trên các ưu tiên kinh doanh hiện tại thay vì tuân thủ một loạt các yêu cầu cơ bản có thể không phản ánh hướng kinh doanh hiện tại. Dựa trên những khác biệt này, các kỹ thuật quản lý và đo lường mới được giới thiệu trong Agile.

Sử dụng cách tiếp cận truyền thống, các ràng buộc về chi phí, phạm vi và lịch trình thường được cố định trên phạm vi với sự cân bằng giữa các biến chi phí và lịch trình. Nhiều biện pháp xoay quanh việc cung cấp một nhóm yêu cầu cố định. 

Với phạm vi cố định và thời lượng nói chung dài hơn, các biện pháp phân tích giá trị kiếm được rất dễ áp ​​dụng. Với Agile, lịch trình là cố định còn chi phí và phạm vi trở thành các biến số vì phạm vi được ưu tiên lại với mỗi sprint.

Agile giới thiệu các thuật ngữ mới để đo lường hiệu suất: Story Point, Velocity và “The Definition of Done”. 

Trọng tâm của Agile là một Story Point. Story Point là một quy mô tương đối về nỗ lực mà nhóm yêu cầu để triển khai câu chuyện của người dùng. Agile Scrum không sử dụng thời gian (1 giờ, v.v.) để ước tính công việc; nó sử dụng các số liệu được trừu tượng hóa tương đối để định lượng nỗ lực. Quan trọng là nhóm chia sẻ sự hiểu biết về thang đo mà họ sử dụng, để mọi thành viên trong nhóm cảm thấy thoải mái với các giá trị của thang đo.

Trước khi xác định ước tính, các chuyên gia khuyến nghị rằng user story nên đã được “groom” từ trước. Grooming là một quá trình cho phép toàn bộ nhóm xem xét câu chuyện và đi đến thống nhất rằng mục đích và tiêu chí chấp nhận đã được hiểu rõ để có thể ước tính. 

Nếu bạn chuẩn bị kỹ lưỡng, thì việc ước tính sẽ trở nên dễ dàng hơn nhiều và đạt được sự đồng thuận sớm hơn. Như với tất cả các cuộc họp, các buổi Grooming phải được tạo điều kiện để duy trì sự tập trung và hiệu quả.

Sau khi Grooming, quá trình ước lượng sẽ được tiếp tục. Product Owner rất quan trọng đối với cả việc chuẩn bị và ước tính. Họ phải sẵn sàng trả lời các câu hỏi để giúp nhóm xác định ước tính. 

Các câu chuyện được xem xét dựa trên thang điểm đã chọn ở trên và đồng thời mỗi thành viên trong nhóm thể hiện ước tính nỗ lực của họ. Nếu có sự khác biệt, chúng sẽ được thảo luận và áp dụng một số liệu.

Vì phạm vi được ưu tiên lại trong suốt vòng đời, làm thế nào để một người biết khi nào bạn hoàn thành ? “Hoàn thành” là một cân nhắc chính cho các chương trình Agile. Nó cần được thương lượng trước và hoàn thiện theo thời gian. Với sự khác biệt tiềm ẩn trong các chương trình Agile, mỗi nhóm sẽ cần phải phát triển “Hoàn thành” của riêng mình. Mỗi giai đoạn có thể yêu cầu “Hoàn thành” của riêng mình. Những cân nhắc chính cho việc này có thể bao gồm:

  • Tất cả các tiêu chí chấp nhận câu chuyện của người dùng đều được đáp ứng
  • Code đáp ứng Tiêu chuẩn mã hóa của tổ chức
  • Code được xem xét hoặc tạo ra bằng phương pháp lập trình cặp
  • Tài liệu bắt buộc đã được phát triển và đánh giá ngang hàng
  • Các bài kiểm tra chức năng được thực hiện độc lập bởi các thành viên trong nhóm khác với những người làm việc về việc triển khai tính năng đó
  • Kiểm tra chấp nhận tự động được chuẩn bị cho tính năng này
  • Các bài kiểm tra tích hợp được tiến hành và vượt qua

Khi các quy trình tiêu chuẩn mới xuất hiện và các quy trình khác được thay thế, định nghĩa về việc đã hoàn thành cần được cập nhật để phản ánh trạng thái hiện tại.

Tạo hợp đồng Agile 

Như đã mô tả ở trên, phát triển phần mềm Agile là thích ứng và liên tục thay đổi. Bạn nên phát triển một danh sách ngoài các sản phẩm và dịch vụ công việc để tạo điều kiện thuận lợi cho các quá trình trưởng thành và thay đổi. 

Vì vậy, thay vì tập trung vào “cái gì” sẽ được phân phối, hãy mô tả rõ ràng và rõ ràng nhất có thể “cách thức” giải pháp sẽ được xác định và phân phối. Tương tự như mã hóa các quy tắc kinh doanh bên ngoài phần mềm cốt lõi. Danh sách yêu cầu và các thành phần khác có thể được quản lý tốt hơn bên ngoài hợp đồng cốt lõi.

Phát triển Agile tạo ra một số hiện vật có thể có giá trị hơn trong một kho lưu trữ khác với một tài liệu MS Word chính thức. Chúng có thể bao gồm các tạo tác kỹ thuật, thiết kế tạo tác, code và thử nghiệm hiện vật hoặc các sản phẩm quản lý. 

Quan trọng là nắm lấy các công nghệ hỗ trợ các quy trình và thông tin bằng cách tập trung vào nội dung được yêu cầu và cung cấp, thay vì vùng chứa. Điều này sẽ dẫn đến việc sử dụng tài nguyên hiệu quả hơn vì mọi người đang phát triển nội dung thay vì chuẩn bị các tài liệu bên ngoài. 

Việc kiểm soát phiên bản, tái sử dụng và thời gian quản trị cũng nên được xem xét trước khi yêu cầu sản phẩm được sản xuất dưới dạng một tài liệu duy nhất nếu thông tin có sẵn và được sử dụng tốt hơn ở dạng khác.

Áp dụng các công cụ ALM để tạo thuận lợi cho tương tác

Các công cụ Quản lý vòng đời ứng dụng (ALM) hỗ trợ các quy trình vòng đời ứng dụng từ lập kế hoạch và quản trị, thông qua phát triển và bảo trì. 

Các công cụ ALM Agile tích hợp các quy trình Agile và cấu trúc quản trị dựa trên các yếu tố cân nhắc mà các công cụ ALM truyền thống tích hợp. Một số công cụ ALM cũng tích hợp xây dựng với giám sát sản xuất và quản lý vấn đề và lỗi.

Agile được coi là động lực chính cho việc chuyển sang ALM – đặc biệt là để mở rộng Agile đến các dự án lớn hơn và các nhóm khác. Các yếu tố Agile bao gồm bảng tác vụ, burn-down, velocity và các báo cáo khác, user story và tích hợp liên tục. Các nhóm Agile thuần túy thường tìm kiếm các công cụ tập trung hỗ trợ các thực hành phổ biến trong phát triển Agile và các nhà cung cấp hàng đầu cũng hỗ trợ mạnh mẽ thông qua các tài liệu đào tạo và giáo dục. Cũng như tất cả các lựa chọn công cụ, điều quan trọng là phải hiểu môi trường phát triển, ngôn ngữ, công cụ đã có và các yếu tố khác khi chọn công cụ ALM.

Tích hợp lập kế hoạch và phát triển là một khía cạnh quan trọng của phát triển Agile. Do tích hợp và phân phối liên tục, các chương trình Agile thường có nhiều “phần dịch chuyển” hơn các chương trình truyền thống. Do các công việc tồn đọng liên tục được định hướng lại và tốc độ phát triển, bắt buộc các sản phẩm quản lý cấu hình và lập kế hoạch phải được điều chỉnh và tích hợp. Vì Agile coi trọng các cá nhân và sự tương tác hơn các công cụ và quy trình, nên một công cụ ALM cho Agile cũng phải làm như vậy.

Các công cụ tốt nhất cho ALM Agile phải hỗ trợ năm phương pháp tổ chức chính và phải:

  • Cho phép các nhóm khám phá và phát triển quy trình của họ nhanh chóng
  • Hỗ trợ các nhu cầu riêng của mọi dự án, cũng như các nhu cầu nhất quán của tổ chức
  • Tạo điều kiện cho sự hợp tác liên tục giữa các học viên và các bên liên quan ở tất cả các cấp
  • Tự động hóa thử nghiệm và triển khai để cho phép phân phối liên tục
  • Cung cấp sự minh bạch hoàn toàn và khả năng hiển thị cho các nhà lãnh đạo mà không cần tạo công việc cho các nhóm dự án

Các tổ chức áp dụng ALM cho Agile và cung cấp các công cụ thích hợp để hỗ trợ họ tăng cường sự Agile và khả năng cạnh tranh của họ. Họ tạo ra phần mềm tốt hơn, thú vị hơn và đến tay người dùng nhanh hơn. Thông qua phần mềm tốt hơn, họ khám phá ra những cách mới để tương tác và tạo ra giá trị cho khách hàng của mình. Họ nhanh chóng thử nghiệm các ý tưởng mới và liên tục điều chỉnh phù hợp với phản hồi của khách hàng, sự thay đổi trên thị trường và những thay đổi trong chiến lược kinh doanh.