You are using an outdated browser. For a faster, safer browsing experience, upgrade for free today.
Thiết kế website
9 lượt xem

Đừng chạy theo Waterfall, hãy gắn bó với Agile

Đừng chạy theo Waterfall, hãy gắn bó với Agile

Có khá nhiều điểm khác biệt giữa phương pháp quản lý dự án truyền thống kiểu Waterfall và phương pháp quản lý dự án Agile.

Theo nhiều cách, Agile hiệu quả hơn Waterfall rất nhiều. Nhưng điều đó có đồng nghĩa với việc Agile sẽ phù hợp với dự án tiếp theo của bạn không?

Hãy cùng tìm hiểu thêm về Agile trong bài viết này.

Agile: Nơi sản phẩm được bàn giao cho khách hàng theo từng phần nhỏ, đều đặn

Project Manager — quản lý dự án, chúng ta có nhiều lựa chọn khi quyết định sử dụng phương pháp nào cho dự án của mình.

Agile, LeanWaterfall đều là những lựa chọn phổ biến. Mỗi phương pháp đều có vị trí riêng trong lĩnh vực quản lý dự án, đặc biệt với phát triển website và phần mềm.

Nhiều agency kết hợp các phương pháp này theo dạng hybrid — lai ghép, nhằm đáp ứng nhu cầu cụ thể của từng dự án, thay vì chỉ thuần Agile hoặc thuần Waterfall.

Trong bài viết này, chúng ta sẽ tập trung vào Agile Developmentphát triển theo Agile và các lợi ích của việc sử dụng phương pháp này cho các dự án phát triển tùy chỉnh.

Agile hướng đến việc cung cấp các bản phát hành nhỏ, thường xuyên và có tính lặp lại trong suốt dự án. Điều này cho phép các thành viên trong nhóm và khách hàng kiểm tra, đánh giá tiến độ trong toàn bộ vòng đời dự án.

Mục tiêu là đảm bảo một dự án lành mạnh, đồng thời duy trì mối quan hệ tốt giữa khách hàng và đội ngũ phát triển trong suốt quá trình thực hiện cũng như sau khi dự án hoàn tất.

Trước tiên, hãy nhìn nhanh qua một số thuật ngữ

Tất cả chúng ta đều biết rằng các stakeholdersbên liên quan không thật sự muốn làm cuộc sống của Project Manager trở nên khổ sở.

Việc hiểu đầy đủ quy trình sẽ giúp duy trì mối quan hệ khách hàng lành mạnh và đảm bảo mọi người cùng thống nhất với các kỳ vọng đã đặt ra.

Bảo Minh Ân - Thiết kế website và Digital Marketing

Scrum: Hãy ngắn gọn và đừng trễ giờ!

Hãy lặp lại theo tôi: “Nhóm của chúng ta sẽ scrum đúng 8:42 mỗi sáng và kết thúc đúng 8:57.”

Scrum không chỉ là một cuộc họp mà các thành viên trong nhóm không ngồi xuống. Đúng là họ thường đứng trong suốt buổi trao đổi ngắn, nhưng Scrum còn quan trọng hơn thế.

Scrum là một quy trình quan trọng, thậm chí có thể nói là thiết yếu trong Agile.

Mục tiêu của việc sử dụng khung làm việc nhẹ này là tối đa hóa nỗ lực của đội dự án, tận dụng tốt nhất thời gian có sẵn và tạo ra một môi trường làm việc tinh gọn, hiệu quả.

Việc đứng giúp cả nhóm duy trì sự tập trung và củng cố tinh thần rằng Scrum cần phải ngắn gọn, đi thẳng vào vấn đề.

Scrum thường được giới hạn tối đa trong 15 phút — quá đủ cho các phát biểu ngắn nhằm giữ mọi người có trách nhiệm và tiếp tục tiến về phía trước.

Một cách để giữ sự tập trung vào thành viên đang nói là chuyền một quả bóng quanh nhóm. Khi quả bóng Scrum được ném đến bạn, đó là lượt của bạn.

Trong mỗi buổi Scrum, có ba câu hỏi được đặt ra:

  • Hôm qua bạn đã làm gì?
  • Hôm nay bạn sẽ làm gì?
  • Có trở ngại nào đang cản bạn hoàn thành mục tiêu không?

Chỉ vậy thôi.

Không tán gẫu. Không bàn chuyện cuối tuần. Không bàn thực đơn bữa trưa. Không trả lời dài dòng.

Hãy đi thẳng vào kế hoạch trong ngày của bạn, rồi chuyển sang câu hỏi tiếp theo hoặc chuyền bóng cho thành viên kế tiếp.

Một trở ngại có thể liên quan đến công việc, cá nhân hoặc cũng có thể không tồn tại.

Có một vài quy tắc trong buổi daily huddle hoặc Scrum hằng ngày cần được tuân thủ nghiêm túc:

  • Scrum luôn bắt đầu đúng giờ, vì vậy đừng chờ những thành viên đến muộn. Nếu họ thường xuyên trễ, rồi cuối cùng họ cũng sẽ hiểu vấn đề.
  • Đừng chia sẻ quá nhiều hoặc nói lan man về nhiệm vụ và vấn đề. Nếu phát hiện một vấn đề lớn hơn, hãy tách nó ra và lên một cuộc họp riêng để xử lý cụ thể.
  • Đừng ngắt lời thành viên khác. Ai đang cầm bóng thì người đó có quyền nói. Chấm hết.
  • Đừng đưa ý tưởng mới vào trong Scrum. Ý tưởng mới nên được trình bày trong các cuộc họp riêng.
  • Scrum không phải là một cuộc họp thông thường, vì vậy đừng đối xử với nó như một cuộc họp.

Sprint: Tiến lên từng chặng 2 tuần

Sprint là một khoảng thời gian cố định, trong đó các nhiệm vụ cụ thể cần được hoàn thành và sẵn sàng để review vào cuối sprint.

Một sprint có thể kéo dài 1 tuần, 2 tuần hoặc thậm chí 3 tuần. Lý tưởng với hầu hết dự án, một sprint thường kéo dài 2 tuần.

Trong một sprint, đội phát triển sẽ xây dựng và kiểm thử một phần của sản phẩm cho đến khi cả nhóm và khách hàng chấp nhận rằng phần đó đã được kiểm tra, hoạt động đúng và có thể được xem là một phần sản phẩm có thể bàn giao.

Phần này cũng được xem như một phần đã hoàn thành của MVP — Minimum Viable Product, tức sản phẩm khả dụng tối thiểu.

Khi một sprint kết thúc, sprint tiếp theo sẽ bắt đầu.

Các nhóm sẽ bàn giao từng phiên bản lặp lại — iterations — vào cuối mỗi sprint, cho đến khi sản phẩm được kiểm thử và hoàn thiện.

Tránh technical debt với Agile

Khi có thay đổi trong quá trình phát triển Agile, việc refactoring — tái cấu trúc mã nguồn nên được thực hiện song song để giữ technical debt — nợ kỹ thuật ở mức tối thiểu.

Technical debt hiểu đơn giản là phần công việc phát triển phát sinh thêm khi đội ngũ chọn cách viết mã nhanh, dễ triển khai trước mắt, thay vì áp dụng giải pháp tổng thể tốt nhất trong từng vòng lặp.

Việc dành thời gian để dọn dẹp code cruft — mã thừa, mã kém sạch, mã tích tụ theo thời gian trong từng vòng lập trình luôn tốt hơn là đợi đến cuối dự án, sau khi đã có rất nhiều thay đổi và nhiều lần lặp.

Về dài hạn, đầu tư thời gian ngay từ đầu để lập trình sản phẩm bằng giải pháp sạch nhất và hiệu quả nhất sẽ ít tốn kém hơn rất nhiều so với việc phải trả “nợ kỹ thuật” vào cuối dự án, bất kể quy mô hay phạm vi dự án lớn nhỏ ra sao.

Vì Agile được phát triển theo từng vòng lặp, nên việc tránh technical debt bằng phương pháp này dễ hơn nhiều so với Waterfall — nơi sản phẩm thường chỉ được trình bày với khách hàng sau khi phần lớn công việc phát triển đã hoàn tất.

User Story được xây dựng tốt

User story là phần mô tả một tính năng, hoặc một nhóm tính năng, từ góc nhìn của người dùng cuối.

User story mô tả loại người dùng, điều họ muốn và lý do vì sao họ muốn điều đó.

Nó giúp tạo ra một mô tả đơn giản hóa cho yêu cầu sản phẩm.

Một mẫu user story phổ biến là: Là một ________, tôi muốn _______, để ________.

User story giúp làm rõ các câu hỏi sau:

Là một… Ai là người dùng? Chúng ta đang xây dựng sản phẩm này cho ai?

Tôi muốn… Chúng ta đang xây dựng điều gì và mục tiêu là gì?

Để… Giá trị mà chúng ta mang lại cho người dùng là gì?

Đây là một khung định hướng tốt khi bắt đầu viết user story.

Bạn sẽ trả lời những câu hỏi cuối cùng giúp định nghĩa sản phẩm và mục đích tồn tại của nó.

Tăng mức độ tham gia và sự hài lòng

Mục tiêu cuối cùng dễ đạt được hơn thông qua phát triển Agile: gia tăng sự hài lòng của khách hàng nhờ sự thấu hiểu chung, phản hồi nhanh hơn và quản lý kỳ vọng rõ ràng hơn.

Sự hài lòng của khách hàng chỉ có thể đạt được khi chúng ta tạo ra sản phẩm tốt nhất có thể, sẵn sàng bàn giao, đồng thời duy trì mối quan hệ tốt khi cùng nhau đi qua hành trình phát triển sản phẩm.

Một số lý do cơ bản khiến Agile trở thành phương pháp tốt hơn cho các dự án lành mạnh gồm:

  • Tốc độ và sự linh hoạt
  • Quản lý kỳ vọng rõ ràng hơn
  • Tính minh bạch
  • Kiểm soát chi phí
  • Giảm thiểu rủi ro thất bại của dự án
  • Linh hoạt trước thay đổi, biến thay đổi thành một phần tích cực của luồng dự án
  • Phản hồi nhanh hơn
  • Sản phẩm cuối cùng có chất lượng cao
  • Nhận diện vấn đề từ sớm
  • Cam kết và trách nhiệm của đội ngũ
  • Sự tập trung

Một chút chuyện bên lề về Agile

Ai đã phát minh ra Scrum?

Một số người tin rằng Jeff Sutherland, John ScumniotalesJeff McKenna đã phát minh ra Scrum vào năm 1993.

Một số khác lại cho rằng Hirotaka TakeuchiIkujiro Nonaka mới là những người phát minh ra Scrum vào năm 1986.

Để mọi thứ thêm phần rối rắm, khi Jeff Sutherland tạo ra phiên bản quy trình Scrum của mình vào năm 1993, ông đã mượn thuật ngữ “scrum” từ một phép so sánh được Takeuchi và Nonaka trình bày trong một nghiên cứu năm 1986, đăng trên Harvard Business Review.

Trong bài viết đó, Takeuchi và Nonaka so sánh các đội nhóm đa chức năng, hiệu suất cao với đội hình scrum trong môn bóng bầu dục Rugby. Phép so sánh này đã ảnh hưởng đến Sutherland.

Có nhiều hội nghị trên khắp nước Mỹ bàn về Agile Methodologiescác phương pháp Agile, chẳng hạn như sự kiện Keep Austin, nơi Ron Quartel từng phát biểu tại Agile 2017.

Nguồn:: 📝 TMĐT Bảo Minh Ân | 📸 Unsplash

Quý anh/chị đang tìm kiếm một doanh nghiệp uy tín cung cấp dịch vụ Công Nghệ Thông Tin như Thiết kế và lập trình website, Digital Marketing, hoặc dịch vụ Bảo trì và chăm sóc hệ thống máy tính, ...? Đừng ngần ngại hãy liên hệ với The ÂN qua số điện thoại (+84).326.418.478 để được tư vấn cụ thể, hoặc liên hệ qua mẫu tin.

Các thông tin nổi bật khác:

Bài viết khác
Lợi ích của Phòng IT thuê ngoài?
Lợi ích của Phòng IT thuê ngoài?

Phòng IT thuê ngoài, hay còn gọi là dịch vụ IT dựa trên mô hình outsource, mang lại nhiều lợi ích cho các doanh nghiệp, nhất là đối với những công ty không chuyên về công nghệ thông tin. ...