Top #10 Phương Pháp Agile Xem Nhiều Nhất, Mới Nhất 8/2022 # Top Trend | Sansangdethanhcong.com

Phương Pháp Scrum Vs Phương Pháp Agile

--- Bài mới hơn ---

  • Quản Lý Dự Án Agile – Apmp
  • Phương Pháp Quản Lý Linh Hoạt (Agile) Và Chứng Chỉ Quốc Tế Pmi
  • Phân Tích Abc Trong Quản Lý Tồn Kho Mà Bạn Cần Phải Nắm Được
  • Phân Tích Abc Trong Supply Chain – Hoangthanghq55
  • Một Số Vấn Đề Về Mô Hình Hạch Toán Chi Phí Theo Hoạt Động (Activity
  • Những người mới biết đến Agile thường không hiểu rằng có nhiều loại phương pháp Agile khác nhau. Một trong những quy trình Agile phổ biến nhất là phương pháp Scrum.

    Nhiều doanh nghiệp nhận thấy rằng quy trình kinh doanh truyền thống không còn hiệu quả nữa vì ngày càng có nhiều thay đổi như là nhu cầu khách hàng, yêu cầu dự án hay các công việc hỗ trợ khác…khiến họ không nắm bắt kịp xu hướng

    Và nhiều quản lý dự án, quản lý sản phẩm và các nhóm phát triển phần mềm đang chuyển từ phương pháp truyền thống Waterfall sang phương pháp Agile.

    Phương pháp Agile

    Phương pháp Agile được giới thiệu lần đầu tiên vào năm 2011 trong “Agile Manifesto” được tổng hợp tại Utah. Agile Manifesto phác thảo 12 nguyên tắc quan trọng, bao gồm thông tin liên lạc (communication), hợp tác (collaboration), tầm quan trọng của phần mềm, cởi mở để thay đổi.

    Các phương pháp Agile cơ bản đặt cùng nhau như một giải pháp phá vỡ cạm bẫy được kết hợp với mô hình Thác nước (Waterfall). Là một khuôn khổ quản lý linh hoạt hơn, Agile cho phép các nhóm vượt qua mô hình tuần tự truyền thống và hoàn thành nhiều việc hơn (work done) trong một khoảng thời gian ngắn hơn.

    Nhóm Agile không nhận ra là có nhiều loại khác nhau của phương pháp Agile, một trong số đó và phổ biến nhất là Scrum.

    Phương pháp Scrum

    Hầu hết các nhóm chuyển từ Agile sang sử dụng Scrum vì nó đơn giản và linh hoạt. Định nghĩa trên trang Scrum chúng tôi “Scrum là duy nhất bởi vì nó giới thiệu ý tưởng về “kiểm soát quá trình thực nghiệm”. Vì Scrum sử dụng những tiến bộ thực tế của dự án – không phải là một dự đoán tốt nhất hoặc dự báo không rõ ràng – để lập kế hoạch và tiến độ phát hành”

    Phương pháp Scrum khác với các phương pháp khác?

    – Scrum có 3 vai trò: Product Owner, Team members, Scrum Master.

    – Dự án chia thành các giai đoạn gọi là Sprint, mỗi Sprint kéo dài từ 1-3 tuần

    – Lợi ích của Scrum là điều chỉnh hướng đi của dự án dựa vào các công việc đã hoàn thành chứ không dựa trên suy đoán hay dự đoán

    Quản lí dự án Scrum là gì?

    Scrum là một trong những phương pháp quản lý dự án linh hoạt – Agile hoặc framework được sử dụng chủ yếu cho các dự án phát triển phần mềm với mục tiêu cung cấp phần mềm mới mỗi 2-4 tuần. Nó là một trong các phương pháp được ảnh hưởng bởi Agile Manifesto, bao gồm một tập hợp các giá trị và nguyên tắc hướng dẫn làm thế nào để phát triển phần mềm chất lượng cao nhanh hơn, hiệu quả hơn.

    Ai sử dụng phương pháp Agile Scrum?

    Scrum được những nhà phát triển phần mềm sử dụng rộng rãi. Thực tế nó là phương pháp Agile phổ biến nhất, có khoảng 72% đội ngũ phần mềm sử dụng Scrum hoặc Scrum hybrid. Tuy nhiên, Scrum đã lan rộng đến các chức năng kinh doanh khác bao gồm IT và Marketing trong đó đặc biệt là Digital Marketing, khi phải phát triển những dự án mơ hồ và phức tạp. Đội ngũ lãnh đạo cũng dựa vào thực tiễn quản lý Agile của họ về Scrum, thường kết hợp với Lean và Kanban (phân nhóm quản lý dự án Agile).

    Phương pháp Scrum mang lại lợi ích gì?

    • Năng suất cao hơn
    • Sản phẩm có chất lượng tốt hơn
    • Giảm thời gian chờ ra thị trường
    • Hoạt động nhóm tốt hơn
    • Nhân viên hạnh phúc hơn

    Các thành phần của phát triển Srcum Agile là gì?

    Phương pháp Scrum được xác định bởi vai trò của nhóm, events, công cụ, và các quy tắc..

    Nhóm phát triển (Nhóm Scrum)

    Nhóm phát triển thường có 7 +/- 2 thành viên và không có nhóm trưởng để giao nhiệm vụ hoặc quyết định giải quyết vấn đề nào. Nhóm như một đơn vị độc lập quyết định đề cập và giải quyết vấn đề như thế nào. Mỗi thành viên của nhóm Scrum là một phần không thể thiếu trong việc đưa ra các giải pháp và dự kiến sẽ thực hiện một sản phẩm từ khi bắt đầu đến khi hoàn thành.

    Có 3 nguyên tắc chính trong Nhóm Scrum:

    Product Owner

    ScrumMaster

    ScrumMaster là người lãnh đạo tôi tớ cho Product Owner, Nhóm phát triển và Tổ chức, không có thẩm quyền trong nhóm nhưng khá nhiều người hỗ trợ, ScrumMaster đảm bảo rằng Nhóm luôn tôn trọng lý thuyết, practices và quy tắc Scrum. ScrumMaster bảo vệ Nhóm bằng cách làm bất cứ điều gì có thể để giúp Nhóm cho ra năng suất ở mức cao nhất. Điều này có thể bao gồm việc loại bỏ những trở ngại, tổ chức các cuộc họp và giúp các Product Owner chuẩn bị backlog.

    Nhóm phát triển 

    Nhóm phát triển là nhóm tự tổ chức, liên chức năng được trang bị tất cả các kĩ năng để sản xuất ra phần tăng trưởng chuyển giao được, phần mềm chạy được khi hoàn thành mỗi sprint. Scrum mở rộng định nghĩa của thuật ngữ “phát triển” vượt ra ngoài hoạt động lập trình để bao gồm bất cứ ai tham gia vào việc tạo ra các phần mềm chạy được. Không có chức danh trong Nhóm phát triển và không có ai, kể cả các ScrumMaster, nói với Nhóm phát triển phải làm như thế nào để biến các hạng mục product backlog thành các gói phần mềm hoàn chỉnh có thể chuyển giao được

    Họp Scrum

    Sprint

    Là một khung thời gian mà công việc cụ thể được hoàn thành và sẵn sàng thực hiện để đánh giá. Sprint thường kéo dài từ 2-4 tuần nhưng có thể ngắn như một tuần.

    Họp lên kế hoạch Sprint

    Là sự kiện có khung thời gian để xác định hạng mục product backlog sẽ được lựa chọn và làm sao để công việc đạt hiệu quả

    Họp Scrum hằng ngày

    Là buổi hội thoại ngắn (dưới 15 phút) để các thành viên theo kịp tiến độ nhanh chóng và minh bạch từ cuối buổi họp trước, lên kế hoạch cho buổi họp tiếp theo và giải quyết bất cứ trở ngại nào ngăn cản tiến độ

    Họp sơ kết Sprint

    Họp cải tiến Sprint

    Là buổi họp nhóm cuối cùng trong Sprint để xác định cái nào đã lảm tốt, cái gì chưa tốt và làm sao để Nhóm cải tiến trong Sprint tiếp theo. Nhóm phát triển và Scrum Master tham dự buổi họp quan trọng này giúp tập trung vào kết quả tổng kết và xác định chiến lược cho gia đoạn cải tiến kế tiếp

    Scrum Artifacts

    Product Backlog

    Là tài liệu quan trọng nhất vạch ra từng yêu cầu cho hệ thống, dự án hoặc sản phẩm. Product backlog có thể được dùng như một danh sách công việc phải làm bao gồm các hạng mục công trình, mỗi cái đều mang lại giá trị kinh doanh và được Product Owner định nghĩa

    Sprint Backlog

    Là danh sách cụ thể những hạng mục lấy từ product backlog phải được hoàn thành trong Sprint

    Phần tăng trưởng

    Là tổng hợp của tất cả các hạng mục product backlog đã được hoàn thành từ khi phát hành phần mềm mới nhất. Tùy thuộc vào Product Owner  quyết định khi nào phần tăng trưởng được phát hành, trách nhiệm của Nhóm là đảm bảo mọi thứ bao gồm phần tăng trưởng đã sẵn sàng được phát hành, đây cũng được gọi là Phần mềm hoàn chỉnh có thể chuyển giao được (PSI).

    Mối liên hệ của Srum với quản lý dự án Agile?

    Scrum là một tiểu nhóm Agile:

    • Agile là một bộ các giá trị và nguyên tắc mô tả sự tương tác và các hoạt động nhóm hằng ngày. Bản thân Agile không nguyên tắc hay cụ thể.

    Mặc dù được sử dụng để phát triển phần mềm linh hoạt, Agile Scrum đã trở thành framework thuận lợi nhất để quản lý dự án nói chung và đôi khi được gọi đơn giản là quản lý dự án Scrum hoặc phát triển phần mềm Scrum.

    Scrum là gì?

    Scrum là một cách để quản lý dự án, thường là phát triển phần mềm. Phát triển phần mềm Scrum thường được coi là một phương pháp luận. Nhưng thay vì xem Scrum là phương pháp luận, hãy xem nó như là framework để quản lý một quá trình.

    Nhóm phát triển Scrum chịu trách nhiệm cung cấp đầy đủ mô tả chi tiết thực hiện một dự án vì họ là người hiểu rõ nhất nên giải quyết vấn đề như thế nào.

    Nhóm Scrum có hai đặc điểm cực kì quan trọng là: tự tổ chức (self-organizing) và liên chức năng (cross-functional). Trong nhóm Scrum tự tổ chức sẽ không có trưởng nhóm hay người đưa ra quyết định phải làm gì và giải quyết vấn đề nào, vì đó là những vấn đề được quyết định bởi cả nhóm.

    Và trong nhóm liên chức năng Scrum, mọi người đều phải hiểu rõ công việc từ khi lên ý tưởng cho đến khi thực hiện.

    Trong agile development, nhóm Scrum được hỗ trợ bởi hai vai trò cụ thể. Đầu tiên là Scrum Master được xem như là một huấn luyện viên, giúp các thành viên trong nhóm sử dụng các quy trình Scrum thuần thục nhất.

    Vị trí còn lại là Product Owner (PO) có vai trò đại diện doanh nghiệp, khách hàng hay người dùng và hướng dẫn nhóm xây dựng sản phẩm

    Ai nên học Agile Scrum?

    Khóa học này có thể dành cho tất cả mọi người, bất kỳ ai giữ vai trò hỗ trợ về hiệu suất, hiệu quả, và cải tiến liên tục của nhóm Team Leader hay người chịu trách nhiệm về việc sử dụng và/hoặc giới thiệu Scrum trong một dự án hoặc doanh nghiệp

    Khóa học phù hợp cho tất cả thành viên làm phần mềm. Vai trò cụ thể phù hợp bao gồm các product managers và product analysts, Quản lý dự án, Team Leader, Kiến trúc sư, Software Developer, Software Tester, CIO và CTO

    Các công cụ Agile Scrum (Artifacts) tuy rất đơn giản nhưng hỗ trợ công việc rất hiệu quả. Chúng bao gồm Product backlog, Sprint Backlog và Product Increment.

    1. Product backlog

    Đây là danh sách ưu tiên các tính năng (feature) hoặc đầu ra khác của dự án, có thể hiểu như là danh sách yêu cầu (requirement) duy nhất của dự án. Product Backlog rất linh hoạt, nó liên tục thay đổi để xác định sản phẩm nào hữu ích hay mang tính cạnh tranh. Nó chứa các mô tả về tất cả các tính năng, chức năng, cải tiến, các hạng mục mong muốn, vv

    Các hạng mục Product Backlog được tạo nên trong quá trình lập kế hoạch phát hành (Release Planning). Sau đó họ được cập nhật trong buổi họp lên kế hoạch Sprint (Sprint Planning) hoặc  Backlog Groomings. Các hạng mục ưu tiên hàng đầu được chọn sẽ được phát triển trong Sprint và được xem xét trong buổi họp Sprint Review.

    Công cụ Agile Scrum này do Product Owner chịu trách nhiệm sắp xếp độ ưu tiên cho từng hạng mục (Product Backlog Item) trong  Product Backlog dựa trên các giá trị do Product Owner định nghĩa (thường là giá trị thương mại – business value). Các hạng mục ưu tiên hàng đầu thì rõ ràng hơn và có nhiều thông tin chi tiết hơn.

    2. Sprint backlog

    Loại công cụ Agile Scrum thứ hai là một loạt danh sách các hạng mục Product Backlog được chọn cho một Sprint; là kết quả dự đoán bởi Nhóm Scrum sau buổi họp lên kế hoạch (Sprint Planning); là những chức năng nào sẽ có mặt trong Incerment tiếp theo và các công việc cần thiết để cung cấp các chức năng đó.

    Với sự kết hợp của Product Owner, nhóm Scrum sẽ phân tích các yêu cầu theo độ ưu tiên từ cao xuống thấp để hiện thực hóa các hạng mục trong Product Backlog dưới dạng danh sách công việc (TO-DO list).

    Nhóm Scrum luôn phải cập nhật Sprint Backlog trong suốt một Sprint, có thể sử dụng biểu đồ Burndown Chart hay Task Board để dễ dàng nhìn thấy tình trạng hiện tại của công việc như “to do”, “in progress” hay “Done”

    3. Product Increment

    Là phần tăng trưởng mới phải sử dụng được và đáp ứng Định nghĩa của Done (DoD) của Nhóm Scrum vào cuối mỗi Sprint. Phần tăng trưởng này phải bao gồm mã đã được kiểm tra kỹ lưỡng, được xây dựng thành một file và sử dụng được trong tập tin trợ giúp (Help files) hoặc tài liệu hướng dẫn sử dụng.

    Nếu tất cả mọi thứ hoạt động tốt và Nhóm phát triển đã ước tính tốt, phần tăng trưởng bao gồm tất cả các hạng mục đã được lên kế hoạch trong Backlog Sprint sẽ được thử nghiệm và lưu thành tài liệu.

    Ban biên tập: Ecci

    5

    /

    5

    (

    1

    bình chọn

    )

    --- Bài cũ hơn ---

  • Kỹ Thuật Nhân Giống Cây Điều Bằng Phương Pháp Ghép Non Nối Ngọn
  • Cải Tạo Giống Cây Ăn Quả Bằng Phương Pháp Ghép Cành
  • Vận Dụng Phương Pháp Luận Biện Chứng Duy Vật Để Nâng Cao Năng Lực Tư Duy Cho Sinh Viên
  • 6 Nguyên Tắc Vàng Dạy Tiếng Anh Cho Trẻ Em Bạn Cần Ghi Nhớ
  • Phương Pháp Phản Xạ 2S
  • Agile Là Gì Và Các Phương Pháp Kiểm Thử Agile

    --- Bài mới hơn ---

  • Tổng Quan Về Nguyên Tắc Agile Và Cách Áp Dụng Agile Trong Quản Lý Dự Án
  • Agile Là Gì? Scrum Là Gì? Các Công Cụ Quản Lý Dự Án Theo Agile Mà Bạn Nên Biết
  • Phương Pháp Abc Activity Based Costing
  • Kế Toán Chi Phí Dựa Trên Hoạt Động (Abc
  • Là Gì? Bao Nhiêu Tiền? Có Tốt Không?
  • 1. Phương Pháp Agile Là gì?

    Phương pháp Agile là một cách chú trọng vào việc lặp lại liên tục sự phát triển và kiểm thử xuyên suốt vòng đời phát triển phần mềm của dự án. Cả 2 hoạt động phát triển phần mềm và kiểm thử của mô hình Agile đều hoàn toàn khác biệt với mô hình Waterfall.

    Sự phát triển phần mềm Agile nhấn mạnh vào 4 giá trị cốt lõi sau:

    1. Sự tương tác của cá nhân và nhóm thông qua các quy trình và công cụ.
    2. Phần mềm làm việc thông qua các tài liệu đầy đủ
    3. Sự hợp tác của khách hàng thông qua việc thương thuyết hợp đồng
    4. Đáp ứng để thay đổi nhằm theo sát các kế hoạch

    2. Phương Thức Agile Vs Waterfall

    Mô hình Agile and Waterfall là hai phương thức hoàn toàn khác biệt trong quy trình phát triển phần mềm. Tuy chúng khác biệt trong cách tiếp cận, nhưng cả 2 phương thức đều hữu dụng ở một thời điểm nào đó, phụ thuộc vào yêu cầu và đặc điểm của dự án.

    3. Phương Pháp Kiểm Thử Agile

    Trong Agile có những phương thức kiểm thử khác nhau như sau:

    3.1. Scrum

    Scrum là một quy trình quản lý và phát triển theo phương pháp phát triển linh hoạt (Agile) tập trung đặc biệt vào việc quản lý các công việc trong một môi trường phát triển theo nhóm. Về cơ bản Scrum được bắt nguồn từ các hoạt động xảy ra trong 1 vòng tuần hoàn. Scrum tin tưởng vào việc trao quyền cho nhóm phát triển và làm việc theo nhóm nhỏ (từ 7-9 người). Nó bao gồm ba vai trò với những trách nhiệm được giải thích như hình sau:

    • Scrum Master

      Master là người chịu trách nhiệm thiết lập nhóm, thiết lập cuộc họp trong các giai đoạn phát triển và loại bỏ các vật cản ảnh hưởng đến sự phát triển

    • Product owner

      Product owner tạo ra backlog sản phẩm, đưa ra thứ tự ưu tiên cho backlog và chịu trách nhiệm cho việc phát hành các tính năng ở mỗi giai đoạn

    • Scrum Team

      Team quản lý công việc của họ và tổ chức công việc nhằm hoàn thành các giai đoạn hoặc chu kỳ phát triển

    Product Backlog

    Đây là một kho lưu trữ các yêu cầu được theo dõi với chi tiết về yêu cầu không được hoàn thành trong mỗi lần phát hành. Nó phải được duy trì và được ưu tiên bởi Product owner, và nó sẽ được phân phối cho nhóm scrum. Nhóm cũng có thể bổ sung hoặc sửa đổi hoặc xóa yêu cầu mới.

    Process flow of Scrum Methodologies (Luồng xử lý của phương thức Scrum)

    Luồng xử lý của phương thức kiểm thử Scrum như sau:

    • Mỗi một giai đoạn lặp lại của một scrum được biết đến như là Sprint
    • Product backlog là một danh sách bao gồm các mô tả chi tiết để hoàn thành sản phẩm cuối cùng
    • Trong mỗi Sprint, các mục hàng đầu của Product backlog được chọn và chuyển thành Sprint backlog
    • Nhóm làm việc trên sprint backlog đã được mô tả
    • Nhóm kiểm tra cho công việc hàng ngày
    • Vào cuối các sprint, nhóm sẽ phát hành các tính năng của sản phẩm

    3.2. eXtreme Programming (XP)

    Kỹ thuật lập trình eXtreme Programming (XP) cực kỳ hữu ích khi có yêu cầu thay đổi liên tục từ khách hàng hoặc khi họ không chắc về chức năng của hệ thống. Với chủ trương “phát hành” sản phẩm thường xuyên trong các chu kỳ phát triển ngắn, sẽ cải thiện chức năng của hệ thống cũng như đưa ra các điểm quan trọng nơi mà bất kỳ yêu cầu nào từ khách hành đều có thể dễ dàng thực thi.

    Các yêu cầu kinh doanh được thu thập theo các story (câu chuyện). Ở phương pháp này, các bản phát hành sẽ dựa trên các vòng đời ngắn hơn được gọi là Iteration (sự lặp lại) với mỗi 14 ngày. Mỗi lần lặp lại bao gồm các giai đoạn như lập trình, kiểm thử đơn vị và kiểm thử hệ thống, nơi mà các chức năng nhỏ sẽ được xây dựng trong ứng dụng.

    Các giai đoạn lập trình eXtreme:

    Có 6 giai đoạn trong phương pháp Agile XP, và những giai đoạn được giải thích như sau:

    3.3. Crystal Methodologies

    Phương pháp Crystal dựa vào 3 khái niệm sau:

    Cyclic delivery (Phát hành theo chu kỳ):

    Giai đoạn phát triển chính bao gồm hai hoặc nhiều chu kỳ phát hành, trong đó sẽ bao gồm:

    • Nhóm sẽ cập nhật và chỉnh sửa kế hoạch phát hành
    • Triển khai một tập hợp các yêu cầu thông qua một hoặc nhiều lần kiểm thử tích hợp
    • Sản phẩm tích hợp được phân phối tới người dùng thực tế
    • Rà soát kế hoạch dự án và phương pháp phát triển đã được thông qua

    Các hoạt động thực hiện trong giai đoạn này sẽ được triển khai vào môi trường người dùng, các đánh giá sau khi triển khai được thực hiện.

    3.4. Dynamic Software Development Method (DSDM)

    DSDM là phương pháp phát triển ứng dụng nhanh (RAD) tiếp cận việc phát triển phần mềm và cung cấp nền tảng phát hành dự án nhanh gọn. Khía cạnh quan trọng của DSDM là người dùng được yêu cầu tích cực tham gia, và nhóm phát triển được trao quyền đưa ra các quyết định trong dự án. Thường xuyên phát hành sản phẩm trở thành trọng tâm hoạt động của DSDM. Các kỹ thuật được sử dụng trong DSDM gồm:

    Dự án DSDM bao gồm 7 giai đoạn:

    1. Trước khi bắt đầu dự án

    2. Nghiên cứu tính khả thi

    3. Nghiên cứu khả năng kinh doanh

    4. Lặp lại mô hình chức năng

    5. Thiết kế và xây dựng

    6. Thực hiện

    7. Dự án hoàn tất

    3.5. Feature Driven Development (FDD)

    Phương pháp này tập trung vào các tính năng “thiết kế và xây dựng”. Không giống như các phương thức Agile khác, FDD mô tả các giai đoạn công việc rất ngắn và cụ thể cần phải thực hiện cho từng tính năng. FDD phát triển sản phẩm bằng việc theo sát những mục tiêu sau

    1. Mô hình đối tượng tên miền
    2. Phát triển theo tính năng
    3. Sở hữu thành phần/lớp
    4. Nhóm tính năng
    5. Kiểm tra
    6. Quản lý cấu hình
    7. Xây dựng chung
    8. Hiển thị tiến độ và kết quả

    3.6. Lean Software Development

    Phương pháp phát triển phần mềm tinh gọn dựa trên nguyên tắc “Sản xuất tinh gọn” (đúng thời gian, đúng sản phẩm). Phương pháp này hướng tới mục tiêu tăng tốc độ phát triển phần mềm và giảm chi phí. Phát triển tinh gọn có thể được tóm tắt trong bảy bước sau:

    1. Loại bỏ dư thừa
    2. Khuếch trương việc học
    3. Trì hoãn cam kết (quyết định càng muộn càng tốt)
    4. Phát hành sớm
    5. Trao quyền cho nhóm
    6. Xây dựng tính toàn vẹn
    7. Tối ưu hóa toàn bộ

    All Rights Reserved

    --- Bài cũ hơn ---

  • Bài 1: Thế Giới Quan Duy Vật Và Phương Pháp Luận Biện Chứng
  • Phương Pháp Học Tiếng Anh Cho Người Mới Bắt Đầu Hoặc Mất Gốc
  • Phương Pháp Học Tiếng Anh Hiệu Quả Nhất Thế Giới Hiện Nay
  • Một Số Phương Pháp Học Tập Hiệu Quả Cần Tham Khảo
  • Phương Pháp Nghiên Cứu Khoa Học
  • Phương Pháp Quản Lý Dự Án Agile

    --- Bài mới hơn ---

  • Các Mô Hình Xác Định Chi Phí Logistics Đối Với Doanh Nghiệp
  • Phân Tích Abc Và Xyz Mang Lại Hiệu Quả Như Thế Nào Trong Quản Lý Hàng Tồn Kho
  • Activity Based Costing Là Gì? Phương Pháp Tính Abc?
  • Bài Tập Và Đáp Án Phương Pháp Abc
  • Tài Liệu Tập Huấn Phương Pháp Tiếp Cận Phát Triển Cộng Đồng Dựa Vào Nội Lực Và Do Người Dân Làm Chủ (Phương Pháp Tiếp Cận Abcd)
  • Quản lý dự án Agile là một phương pháp quản lý dự án phát triển nhanh chóng đến mức phổ biến, được sử dụng để hoàn thành công việc trong thế giới phức tạp, luôn thay đổi mà chúng ta đang sống.

    Quản lý dự án Agile là gì?

    Phương pháp quản lý dự án Agile là một cách tiếp cận hiện đại, linh hoạt để quản lý dự án. Nó cho phép bạn chia các dự án lớn thành các nhiệm vụ dễ quản lý hơn, được xử lý trong các lần lặp hoặc trong thời gian ngắn. Điều này cho phép nhóm của bạn thích ứng để thay đổi cũng như tạo ra kết quả nhanh chóng .

    Phương pháp Agile cho phép các nhóm được trang bị tốt hơn để nhanh chóng thay đổi hướng và sự tập trung. Các công ty phần mềm và các agency tiếp thị đặc biệt nhận thức được xu hướng thay đổi xảy ra từ tuần này sang tuần khác. Agile cho phép các nhóm đánh giá lại công việc họ đang làm và điều chỉnh theo mức tăng nhất định để đảm bảo rằng khi phạm vi công việc và khách hàng thay đổi, trọng tâm cho nhóm cũng cần thay đổi tương ứng.

    Nếu bạn mới sử dụng phương pháp quản lý dự án agile, nó có thể tạo ấn tượng ban đầu như một hệ thống phức tạp và khó quản lý. Nhưng, cho dù bạn có nhận ra hay không, bạn đã thực hiện nhiều thứ mà quản lý dự án Agile yêu cầu. Với một vài điều chỉnh, bạn sẽ tiếp tục các chu kỳ phát triển ngắn hơn và phát hành sản phẩm nhỏ hơn, thường xuyên hơn.

    Ai sử dụng quản lý dự án agile?

    Ban đầu được tạo ra để phát triển phần mềm, phương pháp quản lý Agile nhanh chóng được chấp thuận không chỉ bởi các nhóm CNTT. Các nhà tiếp thị, trường đại học, quân đội và thậm chí ngành công nghiệp ô tô cũng đang xem xét phương pháp Agile và các nền tảng Agile khác để tạo ra các sản phẩm sáng tạo trong môi trường không chắc chắn. Nhiều tổ chức có thể hưởng lợi từ việc quản lý dự án Agile, và đơn giản để thiết lập và sử dụng.

    Trong thế giới phần mềm, khi quyết định xây dựng hoặc phát triển hơn nữa một công nghệ hiện có, sản phẩm cuối cùng có thể khó xác định. Agile cho phép sự mơ hồ đó vì tính linh hoạt của nó trong thay đổi hướng tiếp cận cho một dự án khi công việc có các bước tiến trong tương lai.

    Mặc dù bạn có thể tận dụng lợi thế của phần mềm, sách hoặc huấn luyện viên Agile, mỗi nhóm Agile là duy nhất và hiểu những điều cơ bản có thể giúp bạn kết hợp một phương pháp quản lý dự án Agile phù hợp với bạn và nhóm của bạn.

    Bản tuyên ngôn Agile nêu ra 4 giá trị cốt lõi và 12 nguyên tắc hướng dẫn, đóng vai trò là một kim chỉ nam cho bất kỳ nhóm nào áp dụng phương pháp Agile.

    4 giá trị cốt lõi của Agile

    Cá nhân và tương tác qua các quy trình và công cụ

    Với sự phức tạp của công nghệ, yếu tố con người sẽ luôn đóng vai trò quan trọng trong bất kỳ loại hình quản lý dự án nào. Dựa quá nhiều vào các quy trình và công cụ dẫn đến việc không thể thích nghi với hoàn cảnh thay đổi.

    Phần mềm hoạt động so với tài liệu bao quát / dễ hiểu

    Phần mềm hoạt động quan trong hơn so với tài liệu đơn thuần. Giá trị này là về việc cung cấp cho các nhà phát triển chính xác những gì họ cần để hoàn thành công việc, mà không làm quá tải họ.

    Hợp tác với khách hàng trong thực hiện hợp đồng

    Khách hàng là một trong những tài sản mạnh nhất của bạn. Cho dù khách hàng nội bộ hay bên ngoài, có sự tham gia của họ trong suốt quá trình có thể giúp đảm bảo rằng sản phẩm cuối cùng đáp ứng nhu cầu của họ hiệu quả hơn.

    Đáp ứng với sự thay đổi so với thực hiện theo kế hoạch

    Giá trị này là một trong những sự tách biệt lớn nhất so với ​​quản lý dự án truyền thống. Trong lịch sử, thay đổi được coi là một chi phí, và là một điều cần tránh. Agile cho phép thay đổi liên tục trong suốt vòng đời của bất kỳ dự án nào. Mỗi lần “”sprint”” cung cấp một cơ hội để xem xét và chỉnh sửa dự án.

    12 nguyên tắc của Agile là gì?

    Các phương pháp quản lý dự án Agile có thể đa dạng và duy nhất như mỗi nhóm riêng lẻ, nhưng 12 Nguyên tắc của Agile phải luôn hướng dẫn các quyết định và phát triển sản phẩm của bạn.

    1. Ưu tiên cao nhất của chúng tôi là làm hài lòng khách hàng thông qua việc tung ra sớm và liên tục các phần mềm có giá trị (hoặc bất kỳ thứ gì khác mà bạn cung cấp).
    2. Chào mừng các yêu cầu thay đổi, thậm chí ở giai đoạn muộn trong phát triển. Quy trình Agile khai thác thay đổi cho lợi thế cạnh tranh của khách hàng.
    3. Bàn giao các dự án thường xuyên từ một vài tuần đến một vài tháng, với ưu tiên cho thời gian ngắn hơn.
    4. Các thành viên trong nhóm phối hợp phải làm việc cùng nhau hàng ngày trong suốt dự án.
    5. Xây dựng các dự án xung quanh các cá nhân có động lực. Cung cấp cho họ môi trường và hỗ trợ họ khi cần và tin tưởng để họ hoàn thành công việc.
    6. Trò chuyện trực tiếp là phương pháp hiệu quả nhất để truyền tải thông tin đến và trong các nhóm khác nhau.
    7. Sản phẩm cuối cùng là thước đo chính của sự tiến triển.
    8. Liên tục chú ý đến sự xuất sắc kỹ thuật và thiết kế tốt giúp tăng cường sự linh hoạt
    9. Tính đơn giản, nghệ thuật tối đa hóa số lượng công việc không được thực hiện, là điều cần thiết.
    10. Các kiến ​​trúc, yêu cầu và thiết kế tốt nhất xuất hiện từ các nhóm tự tổ chức.
    11. Tại những giai đoạn tạm nghỉ, nhóm suy nghĩ, trao đổi về cách thức trở nên hiệu quả hơn, sau đó điều chỉnh hành vi tương ứng.

    Các vai trò trong nhóm Agile

    Mỗi phương pháp quản lý dự án Agile có một danh sách riêng các thành viên và vai trò, và trong khi các chức danh có thể thay đổi.

    Có một vài vai trò phổ biến mà hầu hết các cấu trúc nhóm Agile nên có:

    1. Đa chức năng: Các thành viên đa chức năng có các kỹ năng bên ngoài các lĩnh vực bình thường của họ. Họ có thể biết một số nguyên tắc thiết kế đồ họa cơ bản và phân tích dữ liệu hoặc thậm chí một số HTML / CSS.
    2. Thích nghi: Có các kỹ năng đa dạng và biết cách sử dụng nó. Bất kể trong môi trường nào, kết quả bàn giao của họ vẫn nhất quán.
    3. Tò mò: Một phần của việc tối ưu hóa và trở nên hiệu quả hơn là đặt câu hỏi đúng và thách thức cách mọi thứ luôn diễn ra đến khi nó phù hợp.
    4. Chủ động: Người không chờ đợi để được nói phải làm gì. Họ sẵn sàng tham gia và phát triển các chiến dịch mà họ thấy cần.
    5. Định hướng theo nhóm: Những thành viên trong nhóm ưu tiên sự thành công của nhóm hơn vinh quang cá nhân của chính họ. Nếu mọi người đều bàn giao công việc đúng thời gian và kết hợp tốt với nhau, họ sẽ coi đó là một chiến thắng.
    6. Cam kết xuất sắc: Một trong những lợi ích chính của các dự án Agile là cung cấp công việc chất lượng, nhanh hơn. Các thành viên trong nhóm, những người cam kết xuất sắc không hướng đến kết quả trung bình. Họ không phải hướng đến sự hoàn hảo, nhưng họ đã tận tâm để luôn bàn giao sản phẩm tốt nhất.

    6 bước trong phương pháp Agile là gì?

    Mục tiêu của Agile là tạo ra các chu kỳ phát triển ngắn hơn và tung ra sản phẩm thường xuyên hơn so với quản lý dự án theo kiểu Waterfall (thác nước) truyền thống. Khung thời gian ngắn hơn này cho phép các nhóm dự án phản ứng với các thay đổi trong nhu cầu của khách hàng hiệu quả hơn.

    Như chúng tôi đã đề cập trước đây, bạn có thể sử dụng một vài cách thức quản lý dự án Agile khác nhau – Scrum và Kanban là hai trong số những cách thức phổ biến nhất. Nhưng mỗi phương pháp quản lý dự án Agile sẽ tuân theo cùng một quy trình cơ bản, bao gồm:

    Lập kế hoạch dự án

    Giống như với bất kỳ dự án nào, trước khi bắt đầu, nhóm của bạn nên hiểu mục tiêu cuối cùng, giá trị cho tổ chức hoặc khách hàng và cách thức đạt được.

    Bạn có thể phát triển phạm vi dự án ở đây, nhưng hãy nhớ rằng mục đích của việc sử dụng quản lý dự án Agile là để có thể giải quyết các thay đổi và bổ sung cho dự án một cách dễ dàng, vì vậy phạm vi dự án không nên được xem là không thể thay đổi.

    Tạo hành trình sản phẩm

    Hành trình là một sự chia nhỏ thành các tính năng sẽ tạo nên sản phẩm cuối cùng. Đây là một nội dung quan trọng của giai đoạn lập kế hoạch Agile, bởi vì nhóm của bạn sẽ xây dựng các tính năng riêng lẻ này trong mỗi lần “sprint”.

    Tại thời điểm này, bạn cũng sẽ phát triển một “backlog” sản phẩm, đó là danh sách tất cả các tính năng và sản phẩm bàn giao sẽ tạo nên sản phẩm cuối cùng. Sau này, khi bạn lên kế hoạch “sprint”, nhóm của bạn sẽ lấy các công việc (task) từ “backlog” này.

    Lên kế hoạch tung ra (release)

    Trong quản lý dự án waterfall truyền thống, có một ngày hoàn tất sau khi toàn bộ dự án đã được phát triển. Tuy nhiên, khi sử dụng một phương pháp quản lý dự án Agile, dự án của bạn sử dụng các chu kỳ phát triển ngắn hơn (được gọi là “sprint”) với các tính năng được tung ra vào cuối mỗi chu kỳ.

    Trước khi khởi động dự án, bạn sẽ lập một kế hoạch ở mức tổng thể cho các lần tung ra tính năng (feature releases) và vào đầu mỗi lần “sprint”, bạn sẽ xem xét lại và đánh giá lại kế hoạch tung ra cho tính năng đó.

    Lập kế hoạch “sprint”

    Bạn cũng sẽ cần phải ghi lại trực quan quy trình làm việc của mình để minh bạch hóa với nhóm, hiểu biết được chia sẻ trong nhóm, và xác định và loại bỏ các tắc nghẽn.

    Cuộc họp hàng ngày

    Các cuộc họp hàng ngày chỉ nên dài 15 phút. Chúng không nên bị chuyển thành các buổi giải quyết vấn đề hoặc có cơ hội nói về các mục tin tức chung. Một số nhóm thậm chí sẽ tổ chức các cuộc họp ở trạng thái “đứng” để giữ cho nó ngắn gọn.

    Xem xét và xem lại “sprint”

    Nếu nhóm của bạn chưa quen với quản lý dự án Agile, đừng bỏ qua cuộc họp cần thiết này. Nó giúp bạn đánh giá nhóm của bạn có thể giải quyết bao nhiêu trong mỗi “sprint” và thời gian “sprint” hiệu quả nhất cho các dự án trong tương lai.

    Chuyển sang áp dụng quản lý dự án Agile

    Khi bạn cảm thấy thoải mái với Agile, bạn sẽ muốn bắt đầu bằng cách giáo dục các nhóm Agile của mình về cách họ sẽ chuyển sang vai trò mới. Khi họ bắt đầu làm quen hàng ngày và cách họ sẽ chuyển công việc hiện tại của họ sang sử dụng phương pháp Agile.

    Sau khi bạn thiết lập các bước chuyển đổi và đảm bảo mọi người đều cảm thấy thoải mái với phong cách làm việc mới, bạn sẽ muốn theo dõi tiến trình và thành công của họ.

    Nếu họ đang khó khăn để chạy với cùng vận tốc như trước đây, điều gì có thể gây ra những vấn đề đó? Nếu nhóm không cập nhật công việc với trạng thái hiện tại của họ, những trạng thái đó đã được xác định rõ ràng chưa?

    Theo dõi sự tiến bộ hoặc thành công của một nhóm Agile mới sẽ rất có lợi để giúp nhóm tự tin vào những thay đổi. Ngoài ra, có các số liệu này sẽ giúp chứng minh lợi ích của việc chuyển đổi một nhóm tới sử dụng Agile trong các cuộc họp cấp cao hơn.

    Cuối cùng, điều quan trọng là cung cấp cho nhóm của bạn và các bậc thầy “scrum” mới với một hình thức phác thảo các câu hỏi hữu ích cho các buổi họp và xem lại hàng ngày. Điều này cung cấp một số tài liệu tuyệt vời để đánh giá các quy trình trong tương lai. Nó cũng sẽ cho phép nhóm xác định các khu vực cần cải thiện và giúp họ trả lời các câu hỏi mà họ có thể không nghĩ ra để đề cập nếu điều này là mới với Agile.

    Bắt đầu sử dụng Agile

    Đây là những phần cơ bản và quan trọng nhất của phương pháp Agile. Khi bạn chuyển nhóm của mình sang một phương pháp Agile, các quy trình, vai trò và nguyên tắc này sẽ giúp bạn thay đổi suy nghĩ và bắt đầu làm việc cùng nhau để linh hoạt hơn và thích nghi với những thay đổi khi chúng đến. Quản lý dự án Agile không dành cho tất cả mọi người, nhưng các nhóm sử dụng nó một cách chính xác sẽ trải nghiệm những lợi ích to lớn, bao gồm các quy trình làm việc hợp lý và đổi mới nhanh chóng.

    Hãy để lại thông tin liên hệ để Babuki có thể gửi đến bạn các bài viết hay hoặc hỗ trợ tư vấn về chiến lược và quản trị.

    Agile Project Management Methodology

    Babuki lược dịch và hiệu đính

    --- Bài cũ hơn ---

  • Phương Pháp Scrum Vs Phương Pháp Kanban
  • Phương Pháp Phát Triển Phần Mềm: Truyền Thống Và Agile
  • Kanban Calendar: Phương Pháp Quản Lý Công Việc Đơn Giản Nhất
  • Quản Lý Trong Doanh Nghiệp Theo Phương Pháp Agile
  • Agile Là Gì Và Cách Xây Dựng Nhóm Agile Development Thành Công
  • Tìm Hiều Phương Pháp Quản Lý Theo Agile

    --- Bài mới hơn ---

  • Quản Lý Dự Án Theo Mô Hình Linh Hoạt Agile Scrum
  • Phân Tích Abc Trong Quản Lý Tồn Kho
  • Phân Tích Abc Trong Supply Chain
  • Hãy Quên Cách Thực Hiện Theo Danh Sách Việc Cần Làm Đi, Thay Vào Đó Sử Dụng “phương Pháp Abcde”, Chắc Chắn Bạn Sẽ Thành Công Hơn Mỗi Ngày!
  • Ct, Mri And Dwi Features Of A Solid Organizing Hepatic Abscess
  • Agile là gì?

    Agile là một phương pháp quản lý dự án sử dụng các chu kỳ phát triển ngắn gọi là các sprint (nước rút) để tập trung vào việc cải tiến liên tục để phát triển một sản phẩm hoặc dịch vụ.

    Agile đã xuất hiện được bao lâu rồi?

    Mặc dù các phương pháp phát triển phần mềm đã gia tăng từ năm 1957, nhưng phải cho tới những thập niên 70 “Agile” mới lần đầu tiên được bàn luận sâu hơn bởi William Royce, người đã xuất bản một bài báo về việc phát triển các hệ thống phần mềm lớn. Sau này tới năm 2001, bản tuyên ngôn của Agile, “Tuyên bố chính thức bốn giá trị quan trọng và 12 nguyên tắc hướng dẫn cách tiếp cận lặp đi lặp lại và tập trung vào con người để phát triển phần mềm”, đã được 17 nhà phát triển phần mềm xuất bản. Các nhà phát triển này đã họp lại để bàn về các phương pháp phát triển hạng nhẹ dựa trên kinh nghiệm tổng hợp của họ. Đây là 12 nguyên tắc chính vẫn được đưa vào hướng dẫn quản lý dự án Agile cho tới ngày nay.

    1. Sự hài lòng của khách hàng luôn là ưu tiên hàng đầu; Thỏa mãn sự hài lòng của họ thông qua việc giao hàng nhanh chóng và liên tục.
    2. Sự thay đổi môi trường được chấp nhận ở bất kỳ giai đoạn nào của quy trình để cung cấp một lợi thế cạnh tranh cho khách hàng.
    3. Sản phẩm hoặc dịch vụ được phân phối với tần suất cao hơn.
    4. Trao đổi trực tiếp mặt đối mặt được coi là phương pháp hiệu quả và là cách thức tối ưu hóa sự thành công của dự án.
    5. Sản phẩm cuối cùng chính là thước đo thành công cuối cùng.
    6. Liên tục tập trung vào kỹ thuật chuyên môn xuất sắc và thiết kế phù hợp để cải tiến sự linh hoạt.
    7. Sự đơn giản là một yếu tố thiết yếu.
    8. Các đội nhóm tự tổ chức có nhiều khả năng phát triển các kết cấu, thiết kế và đáp ứng các yêu cầu một cách tốt nhất.
    9. Khoảng thời gian đều đặn được sử dụng để nâng cao hiệu quả làm việc nhóm thông qua việc điều chỉnh hành vi.

    Ai nên sử dụng phương pháp Agile?

    Tại sao cần dùng Agile?

    Agile ban đầu được tạo nên cho ngành công nghiệp phát triển phần mềm để giúp cho việc sắp xếp và cải tiến quá trình sản xuất. Qua đó, các nhà phát triển có thể nhận dạng, điều chỉnh các vấn đề và khiếm khuyết một cách nhanh chóng. Là một phương pháp thay thế cho cách tiếp cận Waterfall truyền thống, Agile cung cấp phương pháp quản lý giúp các kỹ sư phần mềm và các nhóm cho ra đời một sản phẩm tốt hơn, nhanh hơn thông qua các phiên ngắn và các phiên tương tác /các sprint. Với những kỳ vọng ngày càng gia tăng của khách hàng, việc cạnh tranh liên tục đòi hỏi phải tìm kiếm được những nhà lãnh đạo dự án có thể sử dụng phương pháp tiếp cận tốt nhất để thực hiện dự án.

    Agile được sử dụng như thế nào?

    Ưu điểm của Agile là gì?

    • Agile hỗ trợ triển khai giải pháp nhanh chóng hơn.
    • Giảm lãng phí thông qua giảm thiểu nguồn tài nguyên
    • Tăng tính linh hoạt và khả năng thích ứng để thay đổi.
    • Thành công ngày càng tăng nhờ nỗ lực tập trung hơn.
    • Thời gian quay vòng nhanh hơn.
    • Phát hiện sớm hơn các vấn đề và sai sót.
    • Là một quá trình phát triển tối ưu.
    • Khuôn khổ công việc gọn nhẹ hơn.
    • Kiểm soát dự án một cách tối ưu.
    • Tăng cường tập trung vào các mong muốn cụ thể của khách hàng.
    • Tăng tần suất cộng tác và phản hồi.

    Những nhược điểm của Agile là gì?

    Giống như bất kỳ phương pháp nào khác, Agile không phải lúc nào cũng phù hợp với tất cả các dự án mà cần phải có sự khảo sát đầy đủ để xác định ra phương pháp nào tốt nhất cho từng trường hợp cụ thể.

    • Trong suốt quá trình phát triển, Agile tạo thuận lợi cho các nhà phát triển, các nhóm dự án và những mục tiêu của khách hàng, nhưng không nhất thiết là trải nghiệm người dùng cuối.
    • Do các quy trình thiếu tính quy phạm mà lại nhấn mạnh vào tính linh hoạt hơn nên Agile không dễ được chấp thuận trong quy trình làm việc của các tổ chức lớn.

    Có thể kết hợp Agile với các phương pháp khác không?

    Có thể kết hợp Agile với các phương pháp khác chẳng hạn như Waterfall để tạo nên một giải pháp lai tạo. Việc hỗ trợ này sẽ giúp thích nghi được với nhiều ngành khác nhau hoặc phù hợp với tính chất độc nhất của một dự án, sản phẩm hoặc dịch vụ. Do đó, cần phải kiểm tra cẩn thận để xác định tính phù hợp và sự khác nhau của các phương pháp và quy trình có sẵn.

    Các phương pháp linh hoạt phổ biến hay được sử dụng là gì?

    • Scrum
    • Kanban
    • Lean (LN)
    • Mô hình phát triển hệ thống năng động, (DSDM)
    • XP (Extreme Programming) – Phương pháp phát triển phần mềm hướng đến việc nâng cao chất lượng phần mềm và khả năng đáp ứng với thay đổi yêu cầu người dùng.
    • Mô hình Pha lê
    • Phương pháp phát triển phần mềm tương thích (ASD)
    • Agile Unified Process (AUP)
    • Phương pháp Crystal Clear
    • Disciplined agile delivery
    • Phát triển theo tính năng (FDD)
    • Scrumban
    • RAD (Phát triển ứng dụng nhanh)

    Tương lai của Agile sẽ như thế nào?

    Trong môi trường kinh doanh, khi sự cạnh tranh thì liên tục tăng lên còn thời gian mua sắm ngày càng co lại, Agile mang lại rất nhiều lợi ích và có ít những hạn chế. Ứng dụng đa dạng trong nhiều ngành công nghiệp khiến Agile trở thành một phương pháp hấp dẫn, và chính bởi tất cả các lợi ích nó đưa ra đã giải thích lý do tại sao Agile được ưa chuộng đến vậy.

    --- Bài cũ hơn ---

  • So Sánh Phương Pháp Scrum Và Kanban Trong Agile
  • Scrum Là Gì Và Tại Sao Nên Dùng Scrum
  • Goodbye Orgchart! The Dual Operating System And Scale
  • Quản Lý Dự Án Theo Phương Pháp Truyền Thống Hay Phương Pháp Agile
  • Scrum Là Gì? Quy Trình Áp Dụng Mô Hình Scrum Hiệu Quả
  • Agile Là Gì? Cách Thực Hiện Phương Thức Agile

    --- Bài mới hơn ---

  • Aac Cho Lớp Học › Góc Chuyên Môn
  • Một Số Phương Pháp Trị Liệu Cho Trẻ Tự Kỷ
  • Phương Pháp Ăn Dặm Kiểu Truyền Thống Có Còn Phù Hợp?
  • Phân Tích Abc Và Phân Tích Xyz Trong Quản Lý Tồn Kho
  • Price Action Là Gì? Phương Pháp Giao Dịch Price Action Toàn Tập
  • Phương pháp Agile ngày càng được sử dụng rộng rãi trong công việc, giúp công việc trở nên dễ dàng và hoàn thiện nhanh chóng. Tuy nhiên, tại Việt Nam, nhiều doanh nghiệp vẫn chưa tiếp cận đến với Agile.

    1/ Agile là gì?

    Agile là một phương pháp phát triển phần mềm linh hoạt, là một hướng tiếp cận cụ thể cho việc quản lý dự án phần mềm. Nó gồm một quá trình làm việc tương tác và tích hợp để có thể đưa sản phẩm đến tay người dùng càng nhanh càng tốt.

    1.1. Ưu điểm của mô hình Agile

    + Phần mềm làm việc được bàn giao thường xuyên (vài tuần chứ không phải vài tháng).

    + Cuộc đối thoại trực tiếp (face-to-face) là hình thức giao tiếp tốt nhất.

    + Gần gũi với nhau hơn, hợp tác hàng ngày giữa các khách hàng và các lập trình viên.

    + Chú ý liên tục đến sự xuất sắc về kỹ thuật và bản thiết kế tốt.

    + Thường xuyên thích nghi với hoàn cảnh thay đổi.

    1.2. Nhược điểm của mô hình Agile

    + Các sản phẩm lớn khó để đánh giá những nỗ lực bắt buộc khi bắt đầu chu trình phát triển phần mềm.

    + Thiếu sự nhấn mạnh vào thiết kế và tài liệu cần thiết.

    + Dự án có thể dễ dàng off-track nếu đại diện khách hàng không rõ kết quả cuối cùng mà họ muốn.

    + Chỉ những lập trình viên cao cấp mới có thể đưa ra các quyết định cần thiết trong quá trình phát triển.

    2/ Các nguyên tắc cần tuân thủ trong phương pháp Agile

    Nguyên tắc #1: Ưu tiên sự hài lòng của khách hàng thông qua việc giao phần mềm sớm và liên tục.

    Nguyên tắc #2: Đáp ứng yêu cầu thay đổi trong suốt quá trình phát triển

    Nguyên tắc #3: Ra mắt thường xuyên phần mềm làm việc.

    Nguyên tắc #6: Cho phép tương tác trực tiếp

    Nguyên tắc #7: Phần mềm làm việc là thước đo chính của sự tiến bộ

    Nguyên tắc #8: Các quy trình cần nhanh chóng để hỗ trợ tốc độ phát triển nhất quán của nhóm

    Nguyên tắc #9. Chú ý đến chi tiết kỹ thuật và thiết kế giúp tăng cường sự nhanh nhẹn, linh hoạt

    Nguyên tắc #10: Sự đơn giản

    Nguyên tắc #11: Các kiến trúc tốt nhất, yêu cầu tốt nhất, và thiết kế tốt nhất sẽ được làm ra bởi các nhóm tự tổ chức.

    Nguyên tắc #12: Đội sản xuất sẽ thường xuyên suy nghĩ về việc làm sao để trở nên hiệu quả hơn, sau đó họ sẽ điều chỉnh và thay đổi các hành vi của mình cho phù hợp.

    3/ Cách thức thực hiện phương pháp Agile

    Quy trình thực hiện Phương thức Agile

    Cách thức thực hiện phương pháp Agile được vận hành theo quy trình sau:

    Giai đoạn #1. Phân tích, lập kế hoạch dự án Agile

    Kế hoạch tổng thể của dự án được vạch ra trong những tuần đầu tiên. Khách hàng và đội dự án sẽ cùng nhau bàn bạc để chia dự án thành các giai đoạn phát triển nhỏ, ước lượng thời gian, công sức và lịch phát triển cho từng giai đoạn phát triển nhỏ đó.

    Mỗi một giai đoạn phát triển nhỏ có một kế hoạch cụ thể được vạch ra vào đầu mỗi giai đoạn

    Đội dự án sẽ họp mặt hàng ngày để cập nhật tình hình công việc

    Giai đoạn #2. Thiết kế

    Sau khi phân tích yêu cầu và lập kế hoạch xong, việc tiếp theo là thiết kế dựa trên các yêu cầu, tạo ra các nguyên mẫu để tiếp tục chỉnh sửa, hoàn thiện bản thiết kế.

    Giai đoạn #3. Lập trình

    Sau khi đã thống nhất về thiết kế thì sẽ chuyển sang giai đoạn lập trình phát triển chức năng theo bản thiết kế. Giai đoạn này cần mọi thành viên cần tham gia sửa chữa bất kỳ lỗi nào phát sinh. Cho dù lỗi đó là do ai gây ra.

    Giai đoạn #4. Kiểm thử

    Tất cả các thành viên trong dự án đều có trách nhiệm đảm bảo chất lượng của sản phẩm. Khi có lỗi, cả đội cùng nhau phân tích nguyên nhân và cùng nhau xử lý.

    Giai đoạn #5. Deploy và Bàn giao sản phẩm

    Phần mềm sẽ được demo hàng tuần và đưa cho khách hàng xem xét, góp ý kiến

    4/ Ứng dụng phương pháp Agile vào quản trị công việc

    + Phương pháp ASD – Adaptive Software Development

    + Phương pháp Agile Modeling

    + Phương pháp AUP – Agile Unified Process

    + Phương pháp Crystal Clear

    + Phương pháp DSDM – Dynamic System Development Method

    + Phương pháp XP – Extreme Programming

    + Phương pháp FDD – Feature Driven Development

    + Phương pháp Lean Software Development

    Mỗi phương pháp đều có điểm nổi trội và chưa hoàn thiện, tùy vào đặc thù của doanh nghiệp và dự án mà chúng ta có thể lựa chọn cách tiếp cận phù hợp. Một trong những yếu tố gây trở ngại nhất hiện nay cho doanh nghiệp trong việc triển khai theo phương pháp Agile là cơ cấu tổ chức nhân sự chưa phù hợp.

    Có 3 yếu tố chính trong phương pháp quản lý dự án Agile:

    + Hợp tác với khách hàng trong việc xác định yêu cầu của dự án.

    + Có quy trình và công cụ trong việc tương tác giữa các thành viên.

    + Sẵn sàng thay đổi kế hoạch khi thực hiện.

    Như vậy, Agile ra đời góp phần tạo ra một phần mềm thật đơn giản đáp ứng đúng yêu cầu của khách hàng hôm nay và sẵn sàng cho những thay đổi vào ngày mai. Hiểu một cách đơn giản Agile là cách thức làm phần mềm linh hoạt để làm sao đưa sản phẩm đến tay người dùng càng nhanh càng tốt càng sớm càng tốt.

    Bài viết trên đã giúp chúng ta hiểu được Agile là gì? Hy vọng đây sẽ là thông tin hữu ích giúp bạn lựa chọn phương pháp Agile vào quản lý dự án sao cho phù hợp với công việc và đem lại hiệu quả tốt nhất.

    HỌC VIỆN ĐÀO TẠO CNTT NIIT – ICT HÀ NỘI

    Dạy học Lập trình chất lượng cao (Since 2002). Học làm Lập trình viên. Hành động ngay!

    Đc: Tầng 3, 25T2, N05, Nguyễn Thị Thập, Cầu Giấy, Hà Nội

    SĐT: 02435574074 – 0914939543 – 0353655150

    Email: hello@niithanoi.edu.vn

    Fanpage: https://facebook.com/NIIT.ICT/

    #niit #niithanoi #niiticthanoi #hoclaptrinh #khoahoclaptrinh #hoclaptrinhjava #hoclaptrinhphp #java #php #python

    --- Bài cũ hơn ---

  • Cách Giảm 10 Cân Trong 2 Tháng Bằng Phương Pháp Keto
  • Phương Pháp Steam Là Gì? Ý Nghĩa Và Vai Trò Của Phương Pháp Steam
  • Làm Cách Nào Để Xây Dựng Phương Pháp Học Tập Hiệu Quả Khi Du Học ?
  • 10 Bí Quyết Học Tập Hiệu Quả
  • 10 Cách Xây Dựng Phương Pháp Học Tập Đúng Đắn Cho Sinh Viên
  • So Sánh Phương Pháp Scrum Và Kanban Trong Agile

    --- Bài mới hơn ---

  • Tìm Hiều Phương Pháp Quản Lý Theo Agile
  • Quản Lý Dự Án Theo Mô Hình Linh Hoạt Agile Scrum
  • Phân Tích Abc Trong Quản Lý Tồn Kho
  • Phân Tích Abc Trong Supply Chain
  • Hãy Quên Cách Thực Hiện Theo Danh Sách Việc Cần Làm Đi, Thay Vào Đó Sử Dụng “phương Pháp Abcde”, Chắc Chắn Bạn Sẽ Thành Công Hơn Mỗi Ngày!
  • Phương pháp Scrum

    Định nghĩa về Scrum

    Scrum là một quy trình làm việc giúp cho công ty, tổ chức chia nhỏ công việc thành những phần nhỏ hơn. Nó nhấn mạnh vào làm việc theo nhóm và tiến trình lặp đi lặp lại của phần mềm. Mục tiêu của phương pháp này là cung cấp phần mềm mới sau 2-4 tuần (còn được gọi là sprint).

    Tại sao phải sử dụng Scrum

    Scrum có thể cung cấp quản lý dự án cho mọi doanh nghiệp, thậm chí trong cả cuộc sống. Sử dụng phương pháp Scrum, đội nhóm phát triển nhanh nhẹn hơn và khám phá ra cách phản ứng nhanh, ứng phó kịp thời với những thay đổi đột ngột.

    Thêm nữa, Scrum giải quyết sự phức tạp trong công việc bằng cách minh bạch hóa thông tin. Những điều này giúp nhóm kiểm tra và điều chỉnh dựa trên các điều kiện hiện tại, thay vì các điều kiện dự đoán. Điều này giúp các thành viên trong nhóm giải quyết những khó khăn thường gặp do các yêu cầu phải thay đổi liên tục.

    Khi nào nên sử dụng Scrum

    Với đặc điểm phải cải tiến liên tục, nên phương pháp Scrum được sử dụng trong các dự án có yêu cầu thay đổi liên tục.

    Phương pháp Kanban

    Định nghĩa về Kanban

    Kanban là một hệ thống trực quan để quản lý công việc, giúp các công ty tổ chức đạt hiệu quả cao trong công việc. Kanban là công cụ kiểm soát sản xuất, dùng nhiều màu sắc để chỉ định nguyên liệu và các công đoạn khác nhau.

    Giống như phương pháp Scrum, Kanban cũng dùng Bảng Kanban và chia công việc thành những phần nhỏ. Trong khi phương pháp Scrum giới hạn thời gian cho phép để hoàn thành một công việc cụ thể (sprint) thì Kanban giới hạn số lượng công việc cho phép trong một điều kiện nhất định (bao gồm nhiều task trên một thẻ Kanban và trên To do list – chỉ định rõ phải nhận bộ phận, chi tiết hay nguyên liệu nào từ trạm trước nó với số lượng bao nhiêu.

    Tại sao phải sử dụng Kanban

    Phương pháp luận Kanban được thiết kế để đáp ứng sự kháng cự tối thiểu. Vì vậy, nó cho phép các thay đổi nhỏ liên tục gia tăng và tiến hóa đối với quy trình hiện tại. Nó cũng giúp đạt được những cải tiến về thông lượng, thời gian dẫn và chất lượng.

    Khi nào nên sử dụng Kanban

    Kanban và Scrum giống nhau ở điểm nào?

    Đây là hai phương pháp đều được sử dụng trong các công ty phát triển phần mềm, nên sẽ có những đặc điểm giống nhau:

    • Cả hai phương pháp đều chia nhỏ các task lớn và phức tạp thành những đoạn nhỏ và hoàn thành theo một quy trình nhất định.
    • Scrum và Kanban thúc đẩy cải tiến liên tục, tối ưu hóa công việc và quá trình.
    • Hai phương pháp đều tập trung vào dòng chảy công việc để khuyến khích các thành viên tham gia vào quy trình.

    Sự khác nhau giữa Scrum và Kanban

    Phương pháp Scrum là giải pháp tốt nhất cho sản phẩm và phát triển dự án còn Kanban là giải pháp tốt nhất để hỗ trợ sản xuất. Sự khác nhau giữa phương pháp Scrum và Kanban có thể được lý giải bởi 3 điểm khác biệt lớn như sau:

    1. Lập kế hoạch, sự lặp lại

    Trong khi đó, nhóm Kanban không có khung thời gian hay quy trình lặp đi lặp lại. Sự cải tiến liên tục ​​sẽ diễn ra liên tục trong suốt quá trình hoàn thành sản phẩm. Sự giới hạn trong dòng chảy công việc sẽ được điều chỉnh ở nhóm hay trong tổ chức dựa trên phương pháp Kanban cho đến khi đạt được sự tối ưu của các điều kiện và điểm giới hạn đến để giữ cho dòng chảy công việc đều đặn và hiệu quả.

    2. Vai trò và trách nhiệm

    Trong một nhóm Scrum, có ít nhất ba bên được phép chỉ định xử lý công việc: PO, Scrum Master và nhóm phát triển. Mỗi bên bị ràng buộc bởi về trách nhiệm riêng biệt và họ phải làm việc cùng nhau để đạt được một sự cân bằng giữa yêu cầu và sản phẩm cuối. Nhóm Scrum bắt buộc là nhóm liên chức năng, hay nói cách khác nhóm Scrum phải có tất cả các nguồn lực cần thiết để hoàn thành công việc.

    Với phương pháp Kanban, không có quy định nào về vai trò. Có thể hiểu là một người sẽ đảm nhận vai trò như người quản lý dự án hoặc giám sát, đặc biệt là đối với các dự án Kanban có quy mô lớn và phức tạp thì không có bất cứ quy định về các vai trò. Một nhóm Kanban không nhất thiết phải là nhóm liên cá nhân như phương pháp Scrum.

    3. Bảng quản trị

    Trên một bảng Scrum, các cột được dán nhãn để phản ánh các giai đoạn của dòng chảy công việc. Các task lần lượt theo thứ tự, làm tất cả mọi việc mỗi sprint trong một vài tuần (khoảng thời gian thông thường cho sprint) và chuyển chúng sang trạng thái hoàn thành (cột Done) và cuối cùng sẽ xử lý hết những sprint còn ở trạng thái chờ.

    Tuy nhiên, trên một bảng Kanban, các cột tương tự được dán nhãn để hiển thị trạng thái flow of work. Điểm khác biệt ở chỗ có sự giới hạn về số lượng tối đa cho phép của mỗi cột tại bất kỳ thời điểm nào và hạn chế khả năng thực thi mỗi task. Vì mỗi cột có một số giới hạn khác nhau và không yêu cầu thời gian, nên không có lý do để lặp lại quy trình như phương pháp Scrum. Tiến trình sẽ tiếp tục chạy với những task mới được bổ sung khi cần thiết và được đánh giá lại nếu cần.

    Nên lựa chọn Scrum hay Kanban?

    Qua các phần mô tả ở bên trên có thể thấy về tính chất thì hai phương pháp này đều như nhau. Nhưng cách làm việc trong hai phương pháp này lại khác nhau. Bởi vậy, bạn có thể lựa chọn phương pháp Kanban hoặc Scrum sao cho phù hợp với chiến lược riêng của doanh nghiệp.

    Với Scrum, bạn sẽ sử dụng nó khi chia phạm vi của mình thành các khối logic để có thể hoàn thành trong khoảng sprint. Còn nếu bạn đang mong đợi sự thay đổi thường xuyên trong dự án của mình thì phương pháp Kanban sẽ là sự lựa chọn lý tưởng.

    Ngoài ra bạn cũng có thể thử phương pháp Scrumban, đây là sự kết hợp của phương pháp Scrum và Kanban. Scrumban được giới thiệu như một quy trình đơn giản để quản lý những dự án phức tạp. Hiện nay Scrumban được áp dụng tốt nhất khi phát triển website, phát triển phần mềm hoặc maintenance.

    Tham khảo nguồn: https://www.guru99.com/scrum-vs-kanban.html

    Các khoá học của PMA: http://pma.edu.vn/2020/09/21/khai-giang-khoa-luyen-thi-acp-thang-10/

    --- Bài cũ hơn ---

  • Scrum Là Gì Và Tại Sao Nên Dùng Scrum
  • Goodbye Orgchart! The Dual Operating System And Scale
  • Quản Lý Dự Án Theo Phương Pháp Truyền Thống Hay Phương Pháp Agile
  • Scrum Là Gì? Quy Trình Áp Dụng Mô Hình Scrum Hiệu Quả
  • Tìm Hiểu Về Phương Pháp Cấy Ghép Implant Là Gì?
  • Quản Lý Trong Doanh Nghiệp Theo Phương Pháp Agile

    --- Bài mới hơn ---

  • Kanban Calendar: Phương Pháp Quản Lý Công Việc Đơn Giản Nhất
  • Phương Pháp Phát Triển Phần Mềm: Truyền Thống Và Agile
  • Phương Pháp Scrum Vs Phương Pháp Kanban
  • Phương Pháp Quản Lý Dự Án Agile
  • Các Mô Hình Xác Định Chi Phí Logistics Đối Với Doanh Nghiệp
  • Tôi thường nghe các doanh nghiệp tuyên bố “Chúng tôi giờ là doanh nghiệp Agile…” hoặc một ai đó trong bộ phận quản lý nói với nhóm phát triển: “Hãy áp dụng phương pháp Agile…” mà chẳng cho họ một chương trình đào tạo nào. Một vài người trong ban lãnh đạo có thể rất hào hứng với ý tưởng này và nói “chúng ta cần phải “Agile” hơn…”, trong khi có người lại hoàn toàn nghi ngờ và tin rằng nếu không có các tài liệu thông thường thì không thể làm việc hiệu quả. Từ những ví dụ này, hẳn các bạn có thể thấy rằng một trong những thách thức lớn nhất khi áp dụng một mô hình mới như Agile chính là “quản lí” kì vọng của ban lãnh đạo.

    Với những lãnh đạo doanh nghiệp không thực sự hiểu phương pháp Agile là gì, họ thường nghĩ Agile đơn giản là làm việc nhanh hơn. Họ không hiểu hoặc quan tâm đến việc sẽ cần có những thay đổi trong cả quy trình và cách thức làm việc để phương pháp này có hiệu quả. Các lãnh đạo rất vui mừng với triển vọng công việc được hoàn thành nhanh hơn, nhưng họ vẫn muốn có biểu đồ Gantt trong Microsoft Project, báo cáo tiến độ, báo cáo ngân sách và một phạm vi công việc được trình ký đầy đủ. Chưa kể là khi họ cần xử lý một cuộc khủng hoảng, họ muốn có quyền được dừng dự án của bạn lại và phân bổ tài nguyên của bạn đến các dự án khác – nhưng bạn vẫn cần phải hoàn thành dự án trong thời gian sớm, vì giờ bạn đã áp dụng Agile! Để tránh gặp phải những điều này, cung cấp đào tạo và trao đổi thông tin từ sớm chính là chìa khóa thành công.

    Phân đoạn đầu tiên bao giờ cũng khó khăn nhất. Vì nhóm phát triển phải học cách ước tính công việc của mình theo theo một cách hoàn toàn mới là “story points” và đánh giá khối lượng công việc có thể đưa vào một khung thời gian đã được thiết lập sẵn. Thường thì nhóm phát triển hay đánh giá sai và không thể hoàn thành hết mọi công việc họ đã đề ra. Phải sau 1 hoặc 2 phân đoạn (iteration) thì nhóm phát triển mới ước lượng được đúng tốc độ (velocity) hoặc số lượng “story points” mà họ có thể hoàn thành trong một phân đoạn. Chỉ khi đó thì chúng ta mới nên đưa ra một kế hoạch cụ thể để xác định xem cần bao nhiêu phân đoạn để hoàn thành hết tất cả các tính năng được đưa ra trong bản kế hoạch.

    Một trong các lợi thế của Agile là sự linh hoạt trong việc thay đổi phạm vi công việc giữa các phân đoạn. Tuy nhiên có một nguyên tắc cơ bản mọi người cũng cần nhớ là một khi phạm vi hay “sprint” đã được thiết lập, không ai được can thiệp vào hoạt động của nhóm. Điều này đồng nghĩa với việc không lãnh đạo cấp cao nào có thể điều phối các thành viên nhóm phát triển chuyển sang làm một dự án khác. Đây là một trong những lí do tại sao các phân đoạn thường diễn ra trong thời gian ngắn – không quá 30 ngày hoặc ngắn hơn – để các thành viên có thời gian “đổi gió” và làm công việc khác. Nhưng cách này cũng có thể gặp vấn đề khi một đội vừa phải sửa lỗi, vừa phải phát triển tính năng mới cho sản phẩm. Một giải pháp cho vấn đề này là tạo ra trong mỗi phân đoạn một vài “buffer stories” cho việc sửa các lỗi chưa xác định được. Nếu có lỗi nghiêm trọng xảy ra, công việc này có thể được giao cho một thành viên trong nhóm.

    Trong một nhóm Agile, sẽ không có kiểu ra lệnh hay kiểm soát truyền thống. Cụ thể hơn, sẽ không có nhà quản lý theo kiểu truyền thống nào. Chuyên gia về Mô hình phát triển phần mềm Scrum – một quy trình của phương pháp Agile – không có quyền hạn trực tiếp mà có vai trò giống như một điều phối viên. Khi áp dụng Agile, các thành viên trong nhóm tự nhận nhiệm vụ từ danh sách công việc – đây là điều nhiều nhà quản lý không thích vì họ không tin là các thành viên có đủ động lực làm việc khi không có sự tồn tại của một người giám sát.

    Hầu hết các chuyên gia về Scrum lại không đồng tình với ý kiến này. Ngược lại, họ nghĩ khi theo Agile, họ còn phải “hãm” các thành viên trong nhóm để các thành viên không ôm đồm quá nhiều việc. Lí do là vì khi tự chịu trách nhiệm về công việc của mình, các thành viên thường luôn cố gắng nỗ lực hơn để chứng tỏ năng lực bản thân. Vai trò của một “scrum master” là huấn luyện các thành viên tập trung hoàn thành số lượng “story” phù hợp hơn là ôm quá nhiều việc mà chẳng hoàn thành được việc nào. Chỉ các “story” có khả năng demo cuối mỗi phân đoạn mới được coi là “story” hoàn chỉnh.

    Áp dụng Agile đồng nghĩa với việc sử dụng ít giấy tờ biểu mẫu hơn. Chúng ta thường chỉ có product backlog ( danh sách các tính năng mong muốn của sản phẩm công nghệ) với user story ( bản tóm tắt nhu cầu người dùng), iteration backlog và một vài biểu đồ theo dõi tiến độ công việc. Nếu có gì hơn thì điều này tùy thuộc vào yêu cầu doanh nghiệp. Khi doanh nghiệp và nhà phát triển phần mềm (developer) bắt đầu trao đổi về quy trình kỹ thuật, các yêu cầu chứng nhận (với những mô tả chi tiết) sẽ được xây dựng và đưa vào như là một phần trong quy trình phát triển dựa trên thử nghiệm – đây cũng là lúc các yêu cầu như vậy có giá trị nhất.

    Thử nghĩ xem, bạn đọc các tài liệu yêu cầu trên bao nhiêu lần sau khi chúng được soạn ra? Chắc chắn là, một khi một dự án mới được triển khai, các tài liệu này đã bị lỗi thời phần nào, kể cả khi có được lưu lại, thì cũng chẳng ai xem chúng cả. Và mọi nỗ lực dành vào đó đều lãng phí. Vậy nên, hãy cố gắng chọn được đúng người truyền tải các yêu cầu và tài liệu hóa các yêu cầu ấy khi cần để không gây lãng phí về thời gian và công sức.

    Tóm lại, trước khi áp dụng Agile, hãy đảm bảo là ban lãnh đạo / quản lý doanh nghiệp hiểu phương pháp làm việc của Agile và cách thức nhóm làm việc với các bộ phận khác. Chắc chắn ban lãnh đạo sẽ trân trọng những kiến thức bạn “dạy” họ và trợ giúp cho đội ngũ làm việc phát triển thành công.

    Theo SAGA

    --- Bài cũ hơn ---

  • Agile Là Gì Và Cách Xây Dựng Nhóm Agile Development Thành Công
  • Hướng Dẫn Từng Bước Triển Khai Agile Marketing
  • Scrum Là Gì? Agile Là Gì? Các Công Cụ Scrum Cần Biết
  • Những Lợi Ích Từ Phương Pháp Ghép Răng Implant Là Gì? Bạn Biết Chưa
  • Màng Ghép Phức Hợp Và Các Phương Pháp Ghép Màng
  • Quản Lý Dự Án Theo Phương Pháp Truyền Thống Hay Phương Pháp Agile

    --- Bài mới hơn ---

  • Goodbye Orgchart! The Dual Operating System And Scale
  • Scrum Là Gì Và Tại Sao Nên Dùng Scrum
  • So Sánh Phương Pháp Scrum Và Kanban Trong Agile
  • Tìm Hiều Phương Pháp Quản Lý Theo Agile
  • Quản Lý Dự Án Theo Mô Hình Linh Hoạt Agile Scrum
  • Trong vài năm qua, có một vài xu hướng mới khi nói đến cách khách hàng quản lý các dự án của họ. Ngay cả với những dự án không phải là phát triển phần mềm, xu hướng ổn định nhất vẫn là áp dụng phương pháp Scrum. Liệu xu hướng này là đúng đắn? Các công ty và nhà quản lý đã thực sự hiểu rõ con đường mình đang đi? Chúng ta sẽ tìm ra câu trả lời trong bài viết này.

    Để phục vụ cho bài viết, tôi đã xem qua những đặc điểm của phương pháp quản lý dự án truyền thống (TPM) trong cuốn Hướng dẫn về những kiến thức cốt lõi trong Quản lý dự án (PMBOK) do Viện Quản lý Dự án (PMI) công bố. Trong khi PMI không đưa ra một tên gọi cụ thể nào cho phương pháp quản lý dự án truyền thống, thì hầu hết các công ty vẫn thường gọi đó là waterfall (thác nước) – mỗi giai đoạn của dự án sẽ được chuyển đến giai đoạn tiếp theo (sau khi đã kết thúc hoàn toàn thành công công việc) giống như dòng chảy của thác nước và chỉ chảy theo một hướng, không thể quay lui về giai đoạn trước hay nhảy vượt giai đoạn (rõ ràng thì trong một thác nước nước không thể chảy ngược). Đó là một trong nhiều lý do khiến nhiều công ty ào ạt chuyển sang áp dụng phương pháp Agile – bởi với Agile, họ không thể chống lại được sự quyến rũ của kết quả công việc nhanh hơn, chi phí thấp hơn, và sẽ không có biểu đồ Gantt nữa!

    Bài học số 1: Agile/Scrum khác một dự án không có kế hoạch

    Để hiểu tại sao nhiều công ty phải vật lộn để chuyển đổi bằng được cách thức quản lý dự án, trước hết chúng ta cần phải hiểu được một vài điểm khác biệt cơ bản giữa TPM (Phương pháp quản lý dự án truyền thống) và Agile/Scrum cũng như những thách thức mà người quản lý phải đổi mặt. Phương pháp truyền thống chọn cách tiếp cận một kế hoạch theo định hướng và tập trung vào hoạt động để quản lý dự án. Điều này dẫn đến một loạt các quá trình có đầu vào và đầu ra khác nhau. Người quản lý phải đảm bảo rằng việc bàn giao dự án trung gian đều phải được lập kế hoạch và thực hiện ở các giai đoạn khác nhau của dự án. So sánh với quá trình phát triển Agile, thì trong suốt vòng đời của một dự án, Agile nhấn mạnh việc tạo ra những kết quả hữu hình càng sớm, càng thường xuyên thì càng hiệu quả và chú trọng việc quản lý mối quan hệ, tạo điều kiện tương tác giữa các thành viên trong nhóm quản lý dự án. Điều này có nghĩa là vai trò của một người quản lý dự án Agile hoàn toàn không giống với một người quản lý dự án TPM. Tuyên ngôn của Agile (The Agile Manifesto) thừa nhận sự cần thiết của việc chuyển giao kết quả trung gian, nhưng không nhấn mạnh vai trò của người quản lý trong việc tạo ra hoặc kiểm soát chúng.

    Quá trình chuyển đổi từ TPM sang Agile quả thực là một quá trình khó khăn đối với nhiều nhà quản lý dự án. Sự chuyển đổi này thường thì không thay đổi được bản chất (áp dụng phương pháp kế hoạch theo định hướng nhưng lại gọi nó là Scrum bởi các cuộc họp nhóm diễn ra hằng ngày thay vì một cuộc họp báo cáo tình hình dự án theo giai đoạn), hoặc họ mặc định Agile/Scrum nghĩa là không có kế hoạch. Có một sự khác biệt lớn giữa việc không có kế hoạch và lên kế hoạch cho những gì bạn biết và có thể thực hiện trong một thời gian nhất định.

    Bài học số 2: Biết được sự khác biệt

    1. Kế hoạch hóa so với tập trung vào giá trị

    Agile/Scrum đưa ra cách tiếp cận hướng tới giá trị trong khi TPM lại hướng tới mục tiêu để lên kế hoạch cho toàn bộ dự án. Điều này không có nghĩa là một dự án Agile/Scrum thì không có kế hoạch. Với Scrum, mỗi phân đoạn đều có một kế hoạch, nhưng các kế hoạch tập trung vào việc ưu tiên các tính năng mang lại giá trị nhất. Điều này hoàn toàn khác với TPM, nơi một kế hoạch hoàn chỉnh được tạo ra trước khi đi vào chi tiết hoạt động và nhiệm vụ cần thiết cho dự án.

    2. Tiên đoán so với Thực nghiệm

    Quản lý dự án truyền thống sử dụng phương pháp tiên đoán, có nghĩa là ban giám đốc sẽ dự đoán kết quả có thể đạt được dựa trên các giả định, để từ đó xây dựng một kế hoạch “trả trước” và một khi kế hoạch này được thiết lập, yêu cầu thay đổi phải được đánh giá theo từng trường hợp. Việc thiết kế được khuyến cáo là không nên thay đổi sau khi kế hoạch đã được chấp thuận, và việc sản xuất, phát triển không nên bắt đầu cho đến khi thiết kế hoàn tất. Điều này hoàn toàn khác biệt so với Scrum, theo Jeff Sutherland, đồng sáng tạo ra Scrum, ” Thực hiện một phương pháp thực nghiệm dựa trên lý thuyết kiểm soát quá trình”. Đó là cách mọi người ưa thích khi nói về việc các Scrum Master và nhóm nghiên cứu cần thích ứng với kết quả hiện tại và của các sprints trước đó để điều chỉnh các mục tiêu về năng suất và thực hiện thay đổi để tăng tốc độ dự án. Mỗi iteration (phân đoạn lặp) được điều chỉnh dựa trên dữ liệu từ sprint trước đó và phải tập trung làm thế nào để mang lại nhiều giá trị hơn trong sprint tiếp theo.

    3. Cấp trên quản lý so với nhóm tự quản

    Một trong những vai trò căn bản của một người quản lý dự án truyền thống là phải tích cực tổ chức và sắp xếp sao cho hợp lý đội ngũ của mình, phân công các vai trò và trách nhiệm cho mỗi thành viên trong dự án. Còn một Scrum Master sẽ lùi lại và cho phép nhóm tự tổ chức. Người quản lý dự án phải tạo điều kiện, cung cấp môi trường để nhóm tự giao tiếp và thực hiện công việc.

    5. Lập kế hoạch từ dưới lên so với trên xuống

    Quản lý dự án truyền thống theo hướng lập kế hoạch từ dưới lên, có nghĩa là một dự án được lên kế hoạch ngay từ đầu bằng cách lên chi tiết các công việc của mỗi cá nhân trong Cơ cấu phân chia công việc (Work Breakdown Structure – WBS), từ đó dẫn đến một kế hoạch dự án hoàn chỉnh trước khi bắt đầu dự án. Scrum thì ngược lại, nó theo hướng lập kế hoạch từ trên xuống, nghĩa là một lộ trình được phát triển trong giai đoạn đầu của dự án được xây dựng dần dần thành các phân đoạn release (bản phát hành) và sprint (phân đoạn).

    Bài học 3: Học cách để triển khai

    Có một vài thói quen và thủ tục của TPM dường như không thể phá vỡ được. Một người quản lý dự án sẽ cần phải loại bỏ những thói quen này nếu họ muốn đi tới thành công của quá trình chuyển đổi. Mặc dù việc này thì khá đơn giản, nhưng hầu hết các công ty lại không muốn từ bỏ thói quen này vì sợ hãi. Mặc dù đây là nguyên nhân khiến cho một dự án TPM không đem lại được hiệu quả, nhưng những thói quen này dường như rất dễ nhận thấy trong các giải pháp Agile mà nhiều công ty thực hiện. Việc loại bỏ những thói quen của cách quản lý truyền thống là điều cực kỳ quan trọng để các nhà quản lý dự án có thể xây dựng được lòng tin nơi tổ chức của mình. Giả pháp là nên thí điểm Agile ở một dự án nhỏ hoặc sử dụng một phương pháp tạm thời đã được cân nhắc kỹ lưỡng. Thông thường, ta không thể thoát khỏi những thói quen cũ cho đến khi toàn bộ đội ngũ đã hiểu các triết lý Agile và sẵn sàng đón nhận chúng.

    Thói quen #1 – Lập kế hoạch trước mọi thứ

    Thói quen #2 – Quản lý và quản lý

    Một dự án Scrum cơ bản là một dự án mà nhóm phát triển được trao quyền để đưa ra quyết định vì chủ sản phẩm cũng là một phần của quá trình. Bằng việc tước đi quyền tự ra quyết định và thay đổi của đội ngũ làm việc, nhiều tổ chức đang tự khiến cho dự án trở nên không có hiệu quả. Nếu một nhóm dự án không có quyền đưa ra quyết định, không đưa thêm một mục đề nghị cần thực hiện cho ban lãnh đạo vào tháng tới thì họ vẫn chưa được cho phép để thành công.

    Thói quen số #3 – Thời gian, Phạm vi hoặc Ngân sách

    Quản lý dự án truyền thống giới thiệu khái niệm về Bộ ba ràng buộc: Thời gian, Phạm vi và Ngân sách. Quản lý dự án “Tam giác sắt” phải được ban giám đốc quản lý chặt chẽ trong TPM. Trong một dự án Scrum, thời gian và chi phí được cố định (“time boxed”) trong mỗi chu trình sprint và phạm vi được xác định bởi chính nhóm quản lý và bị khoá ngay khi bắt đầu một sprint mới. Vai trò của người quản lý trong Scrum không phải là quản lý và thiết lập chúng. Đây sẽ là một cuộc vật lộn thật sự cho một số người quản lý dự án vì lợi ích các nhân để luôn cố mở rộng phạm vi, cắt giảm ngân sách hoặc rút ngắn thời hạn công việc. TPM cho phép quản lý dự án đánh giá những yêu cầu thay đổi và xử lý chúng, điều này thường dẫn đến những biện pháp chữa cháy và khoa trương, khiến cho kế hoạch dự án không còn được triển khai như ban đầu. Trong một dự án Agile/Scrum, chủ sản phẩm phải buông bỏ điều này và đồng ý cam kết phạm vi công việc trong quá trình lên kế hoạch sprint. Rủi ro sẽ giảm theo thời gian của chu trình sprint, do đó tiến trình có thể được thay đổi vào cuối chu trình sprint, thay vì quay lại giai đoạn thiết kế sau 6 tháng.

    Kết luận

    Các công ty đang cố gắng trở nên “Agile” hơn bằng cách áp dụng khái niệm Agile/Scrum cho dự án phát triển phi phần mềm. Mặc dù các khái niệm này có thể làm giảm nhiều điểm gây tổn thương mà họ đã phải giải quyết trong nhiều năm qua và Agile có vẻ rất minh bạch, thì điều quan trọng vẫ là đừng để bị lừa bởi tính đơn giản của cuốn Scrum Guide- Hướng dẫn áp dụng phương pháp Scrum (chỉ là 17 trang thôi mà!) hoặc nghĩ rằng bạn chỉ việc áp dụng các khái niệm dễ dàng mà không cần đánh giá chu đáo các nguyên tắc cơ bản. Các doanh nghiệp nên xem xét các vấn đề mà họ đang phải cố gắng giải quyết bằng cách chuyển sang áp dụng Agile / Scrum, liệu TPM có vấn đề hay vấn đề thực sự nằm ở nội bộ công ty? Nếu là lý do thứ hai, thì Agile/Scrum sẽ không phải là thần dược. Có rất nhiều cạm bẫy trên con đường chạm đến Agile/Scrum, việc bạn kém hiểu biết nhưng vẫn cố chấp áp dụng Scrum có thể sẽ tồi tệ hơn nhiều lần việc chưa làm tốt các phương pháp quản lý dự án truyền thống. Vậy hãy cẩn trọng với quyết định của mình.

    Source: chúng tôi

    --- Bài cũ hơn ---

  • Scrum Là Gì? Quy Trình Áp Dụng Mô Hình Scrum Hiệu Quả
  • Tìm Hiểu Về Phương Pháp Cấy Ghép Implant Là Gì?
  • Bao Bì Pp Ghép Giấy Là Gì?
  • Phương Pháp Cấy Ghép Implant Là Gì? 5 Ưu Điểm Của Phương Pháp Này Là Gì?
  • Phương Pháp Cấy Ghép Răng Implant Là Gì? Hiệu Quả Không?
  • Quản Lý Dự Án Theo Phương Pháp Truyền Thống Hay Phương Pháp Agile – Apmp

    --- Bài mới hơn ---

  • Tổng Quan Các Nghiên Cứu Về Chủ Đề “Quản Lý Dự Án Đầu Tư Xây Dựng Định Hướng Giá Trị” Ở Việt Nam Và Trên Thế Giới
  • Tổng Quan Về Quản Lý Dự Án Trong Đầu Tư Xây Dựng
  • 10 Bước Để Lưu Trữ Và Chuẩn Bị Dữ Liệu Đầu Vào
  • Tầm Quan Trọng Của Quản Lý Dữ Liệu (Data Management) (P.2)
  • Các Phương Pháp Tổ Chức Và Sắp Xếp Dữ Liệu Cần Phải Biết
  • Để phục vụ cho bài viết, tôi đã xem qua những đặc điểm của phương pháp quản lý dự án truyền thống (TPM) trong cuốn Hướng dẫn về những kiến thức cốt lõi trong Quản lý dự án (PMBOK) do Viện Quản lý Dự án (PMI) công bố. Trong khi PMI không đưa ra một tên gọi cụ thể nào cho phương pháp quản lý dự án truyền thống, thì hầu hết các công ty vẫn thường gọi đó là waterfall (thác nước) – mỗi giai đoạn của dự án sẽ được chuyển đến giai đoạn tiếp theo (sau khi đã kết thúc hoàn toàn thành công công việc) giống như dòng chảy của thác nước và chỉ chảy theo một hướng, không thể quay lui về giai đoạn trước hay nhảy vượt giai đoạn (rõ ràng thì trong một thác nước nước không thể chảy ngược). Đó là một trong nhiều lý do khiến nhiều công ty ào ạt  chuyển sang áp dụng phương pháp Agile – bởi với Agile, họ không thể chống lại được sự quyến rũ của kết quả công việc nhanh hơn, chi phí thấp hơn, và sẽ không có biểu đồ Gantt nữa!

    Bài học số 1: Agile/Scrum khác một dự án không có kế hoạch

    Để hiểu tại sao nhiều công ty phải vật lộn để chuyển đổi bằng được cách thức quản lý dự án, trước hết chúng ta cần phải hiểu được một vài điểm khác biệt cơ bản giữa TPM (Phương pháp quản lý dự án truyền thống) và Agile/Scrum cũng như những thách thức mà người quản lý phải đổi mặt. Phương pháp truyền thống chọn cách tiếp cận một kế hoạch theo định hướng và tập trung vào hoạt động để quản lý dự án. Điều này dẫn đến một loạt các quá trình có đầu vào và đầu ra khác nhau. Người quản lý phải đảm bảo rằng việc bàn giao dự án trung gian đều phải được lập kế hoạch và thực hiện ở các giai đoạn khác nhau của dự án. So sánh với quá trình phát triển Agile, thì trong suốt vòng đời của một dự án, Agile nhấn mạnh việc tạo ra những kết quả hữu hình càng sớm, càng thường xuyên thì càng hiệu quả và chú trọng việc quản lý mối quan hệ, tạo điều kiện tương tác giữa các thành viên trong nhóm quản lý dự án. Điều này có nghĩa là vai trò của một người quản lý dự án Agile hoàn toàn không giống với một người quản lý dự án TPM. Tuyên ngôn của Agile (The Agile Manifesto) thừa nhận sự cần thiết của việc chuyển giao kết quả trung gian, nhưng không nhấn mạnh vai trò của người quản lý trong việc tạo ra hoặc kiểm soát chúng.

    Quá trình chuyển đổi từ TPM sang Agile quả thực là một quá trình khó khăn đối với nhiều nhà quản lý dự án. Sự chuyển đổi này thường thì không thay đổi được bản chất (áp dụng phương pháp kế hoạch theo định hướng nhưng lại gọi nó là Scrum bởi các cuộc họp nhóm diễn ra hằng ngày thay vì một cuộc họp báo cáo tình hình dự án theo giai đoạn), hoặc họ mặc định Agile/Scrum nghĩa là không có kế hoạch. Có một sự khác biệt lớn giữa việc không có kế hoạch và lên kế hoạch cho những gì bạn biết và có thể thực hiện trong một thời gian nhất định.

    Bài học số 2: Biết được sự khác biệt

    1. Kế hoạch hóa so với tập trung vào giá trị

     

    Agile/Scrum đưa ra cách tiếp cận hướng tới giá trị trong khi TPM lại hướng tới mục tiêu để lên kế hoạch cho toàn bộ dự án. Điều này không có nghĩa là một dự án Agile/Scrum thì không có kế hoạch. Với Scrum, mỗi phân đoạn đều có một kế hoạch, nhưng các kế hoạch tập trung vào việc ưu tiên các tính năng mang lại giá trị nhất. Điều này hoàn toàn khác với TPM, nơi một kế hoạch hoàn chỉnh được tạo ra trước khi đi vào chi tiết hoạt động và nhiệm vụ cần thiết cho dự án.

    2. Tiên đoán so với Thực nghiệm

    Quản lý dự án truyền thống sử dụng phương pháp tiên đoán, có nghĩa là ban giám đốc sẽ dự đoán kết quả có thể đạt được dựa trên các giả định, để từ đó xây dựng một kế hoạch “trả trước” và một khi kế hoạch này được thiết lập, yêu cầu thay đổi phải được đánh giá theo từng trường hợp. Việc thiết kế được khuyến cáo là không nên thay đổi sau khi kế hoạch đã được chấp thuận, và việc sản xuất, phát triển không nên bắt đầu cho đến khi thiết kế hoàn tất. Điều này hoàn toàn khác biệt so với Scrum, theo Jeff Sutherland, đồng sáng tạo ra Scrum, ” Thực hiện một phương pháp thực nghiệm dựa trên lý thuyết kiểm soát quá trình”. Đó là cách mọi người ưa thích khi nói về việc các Scrum Master và nhóm nghiên cứu cần thích ứng với kết quả hiện tại và của các sprints trước đó để điều chỉnh các mục tiêu về năng suất và thực hiện thay đổi để tăng tốc độ dự án. Mỗi iteration (phân đoạn lặp) được điều chỉnh dựa trên dữ liệu từ sprint trước đó và phải tập trung làm thế nào để mang lại nhiều giá trị hơn trong sprint tiếp theo.

    3. Cấp trên quản lý so với nhóm tự quản

    Một trong những vai trò căn bản của một người quản lý dự án truyền thống là phải tích cực tổ chức và sắp xếp sao cho hợp lý đội ngũ của mình, phân công các vai trò và trách nhiệm cho mỗi thành viên trong dự án. Còn một Scrum Master sẽ lùi lại và cho phép nhóm tự tổ chức. Người quản lý dự án phải tạo điều kiện, cung cấp môi trường để nhóm tự giao tiếp và thực hiện công việc.

    5. Lập kế hoạch từ dưới lên so với trên xuống

    Quản lý dự án truyền thống theo hướng lập kế hoạch từ dưới lên, có nghĩa là một dự án được lên kế hoạch ngay từ đầu bằng cách lên chi tiết các công việc của mỗi cá nhân trong Cơ cấu phân chia công việc (Work Breakdown Structure – WBS), từ đó dẫn đến một kế hoạch dự án hoàn chỉnh trước khi bắt đầu dự án. Scrum thì ngược lại, nó theo hướng lập kế hoạch từ trên xuống, nghĩa là một lộ trình được phát triển trong giai đoạn đầu của dự án được xây dựng dần dần thành các phân đoạn release (bản phát hành) và sprint (phân đoạn).

    Bài học 3: Học cách để triển khai

    Có một vài thói quen và thủ tục của TPM dường như không thể phá vỡ được. Một người quản lý dự án sẽ cần phải loại bỏ những thói quen này nếu họ muốn đi tới thành công của quá trình chuyển đổi. Mặc dù việc này thì khá đơn giản, nhưng hầu hết các công ty lại không muốn từ bỏ thói quen này vì sợ hãi. Mặc dù đây là nguyên nhân khiến cho một dự án TPM không đem lại được hiệu quả, nhưng những thói quen này dường như rất dễ nhận thấy trong các giải pháp Agile mà nhiều công ty thực hiện. Việc loại bỏ những thói quen của cách quản lý truyền thống là điều cực kỳ quan trọng để các nhà quản lý dự án có thể xây dựng được lòng tin nơi tổ chức của mình. Giả pháp là nên thí điểm Agile ở một dự án nhỏ hoặc sử dụng một phương pháp tạm thời đã được cân nhắc kỹ lưỡng. Thông thường, ta không thể thoát khỏi những thói quen cũ cho đến khi toàn bộ đội ngũ đã hiểu các triết lý Agile và sẵn sàng đón nhận chúng.

    Thói quen #1 – Lập kế hoạch trước mọi thứ

    Thói quen #2 – Quản lý và quản lý

    Một dự án Scrum cơ bản là một dự án mà nhóm phát triển được trao quyền để đưa ra quyết định vì chủ sản phẩm cũng là một phần của quá trình. Bằng việc tước đi quyền tự ra quyết định và thay đổi của đội ngũ làm việc, nhiều tổ chức đang tự khiến cho dự án trở nên không có hiệu quả. Nếu một nhóm dự án không có quyền đưa ra quyết định, không đưa thêm một mục đề nghị cần thực hiện cho ban lãnh đạo vào tháng tới thì họ vẫn chưa được cho phép để thành công.

    Thói quen số #3 – Thời gian, Phạm vi hoặc Ngân sách

    Quản lý dự án truyền thống giới thiệu khái niệm về Bộ ba ràng buộc: Thời gian, Phạm vi và Ngân sách. Quản lý dự án “Tam giác sắt” phải được ban giám đốc quản lý chặt chẽ trong TPM. Trong một dự án Scrum, thời gian và chi phí được cố định (“time boxed”) trong mỗi chu trình sprint và phạm vi được xác định bởi chính nhóm quản lý và bị khoá ngay khi bắt đầu một sprint mới. Vai trò của người quản lý trong Scrum không phải là quản lý và thiết lập chúng. Đây sẽ là một cuộc vật lộn thật sự cho một số người quản lý dự án vì lợi ích các nhân để luôn cố mở rộng phạm vi, cắt giảm ngân sách hoặc rút ngắn thời hạn công việc. TPM cho phép quản lý dự án đánh giá những yêu cầu thay đổi và xử lý chúng, điều này thường dẫn đến những biện pháp chữa cháy và khoa trương, khiến cho kế hoạch dự án không còn được triển khai như ban đầu. Trong một dự án Agile/Scrum, chủ sản phẩm phải buông bỏ điều này và đồng ý cam kết phạm vi công việc trong quá trình lên kế hoạch sprint. Rủi ro sẽ giảm theo thời gian của chu trình sprint, do đó tiến trình có thể được thay đổi vào cuối chu trình sprint, thay vì quay lại giai đoạn thiết kế sau 6 tháng.

    Kết luận

    Các công ty đang cố gắng trở nên “Agile” hơn bằng cách áp dụng khái niệm Agile/Scrum cho dự án phát triển phi phần mềm. Mặc dù các khái niệm này có thể làm giảm nhiều điểm gây tổn thương mà họ đã phải giải quyết trong nhiều năm qua và Agile có vẻ rất minh bạch, thì điều quan trọng vẫ là đừng để bị lừa bởi tính đơn giản của cuốn Scrum Guide- Hướng dẫn áp dụng phương pháp Scrum (chỉ là 17 trang thôi mà!) hoặc nghĩ rằng bạn chỉ việc áp dụng các khái niệm dễ dàng mà không cần đánh giá chu đáo các nguyên tắc cơ bản. Các doanh nghiệp nên xem xét các vấn đề mà họ đang phải cố gắng giải quyết bằng cách chuyển sang áp dụng Agile / Scrum, liệu TPM có vấn đề hay vấn đề thực sự nằm ở nội bộ công ty? Nếu là lý do thứ hai, thì Agile/Scrum sẽ không phải là thần dược. Có rất nhiều cạm bẫy trên con đường chạm đến Agile/Scrum, việc bạn kém hiểu biết nhưng vẫn cố chấp áp dụng Scrum có thể sẽ tồi tệ hơn nhiều lần việc chưa làm tốt các phương pháp quản lý dự án truyền thống. Vậy hãy cẩn trọng với quyết định của mình.

    --- Bài cũ hơn ---

  • Phong Cách Quản Lý Đông Tây Kết Hợp Của William Ouchi
  • Học Thuyết Z – Trường Phái Quản Trị Đông Tây Kết Hợp
  • Công Cụ Quản Lý Chất Lượng 5S – Apmp
  • Bí Quyết Để Vinamilk Trở Thành Thương Hiệu Sữa Việt Có Trị Giá Tỷ Đô
  • Quản Lý Công Việc Hiệu Quả Với 5 Kỹ Năng Vàng Cần Ghi Nhớ
  • Sự Khác Biệt Giữa Phương Pháp Agile Và V (Model)

    --- Bài mới hơn ---

  • Sự Khác Biệt Giữa Phương Pháp Thác Nước Và Agile
  • Sự Khác Biệt Giữa Mực Xăm Và Mực Khắc Lông Mày.
  • Sự Khác Biệt Giữa Phun Thêu Thẩm Mỹ Và Phun Xăm
  • Sự Khác Biệt Giữa Máy X
  • Sự Khác Biệt Giữa Ct Scan Và X
  • Phương pháp Agile vs V (Model)

    Có một số phương pháp phát triển phần mềm khác nhau được sử dụng trong ngành công nghiệp phần mềm ngày nay. Phương pháp V (Mô hình V) là một phần mở rộng cho phương pháp phát triển Thác nước (là một trong những phương pháp sớm nhất). Trọng tâm chính của V-Model là mang lại trọng lượng tương đương cho mã hóa và thử nghiệm. Mô hình Agile là một mô hình phát triển phần mềm gần đây được giới thiệu để giải quyết các thiếu sót được tìm thấy trong các mô hình hiện có. Trọng tâm chính của Agile là kết hợp thử nghiệm càng sớm càng tốt và phát hành phiên bản hoạt động của sản phẩm từ rất sớm bằng cách chia nhỏ hệ thống thành các phần phụ rất nhỏ và có thể quản lý được.

    Phương pháp V (Mô hình) là gì?

    Phương pháp V (Mô hình V) là một mô hình phát triển phần mềm. Nó được coi là một phần mở rộng của mô hình phát triển phần mềm Waterfall điển hình. Mô hình V sử dụng cùng các mối quan hệ giữa các giai đoạn được xác định trong mô hình Thác nước. Nhưng thay vì giảm tuyến tính (như mô hình Thác nước), Mô hình V bước xuống theo đường chéo và sau đó di chuyển lên (sau giai đoạn mã hóa), tạo thành hình dạng của chữ V. Hình chữ V này được hình thành để hiển thị mối quan hệ giữa từng giai đoạn của sự phát triển / thiết kế và giai đoạn thử nghiệm tương ứng. Thời gian và mức độ trừu tượng được biểu thị bằng trục ngang và trục tương ứng.

    Việc kiểm tra (đường dẫn tăng dần, phía bên phải của V) được thực hiện để xác minh, trong khi các giai đoạn thiết kế tương ứng (đường dẫn giảm dần, phía bên trái của V) được sử dụng để xác thực. Trong Mô hình V, trọng lượng bằng nhau được trao cho mã hóa và thử nghiệm. V-Model khuyên bạn nên tạo tài liệu thử nghiệm cùng với các tài liệu / mã thiết kế. Ví dụ, các tài liệu thử nghiệm tích hợp nên được viết khi thiết kế cấp cao đang được ghi lại và các thử nghiệm đơn vị phải được ghi lại trong khi kế hoạch thiết kế chi tiết đang được thực hiện. Điều này có nghĩa là một kế hoạch thực hiện cho mỗi thử nghiệm phải được tạo trước, không phải đợi đến khi quá trình phát triển hoàn thành để nó có thể được bàn giao cho nhóm thử nghiệm.

    Nhanh nhẹn là gì?

    Agile là một phương pháp phát triển phần mềm rất gần đây dựa trên bản tuyên ngôn nhanh. Điều này đã được phát triển để giải quyết một số thiếu sót trong các phương pháp phát triển phần mềm V-Model và Waterfall truyền thống. Các phương pháp nhanh nhẹn dựa trên việc ưu tiên cao cho sự tham gia của khách hàng sớm trong chu kỳ phát triển. Nó khuyến nghị kết hợp kiểm tra bởi khách hàng sớm và thường xuyên nhất có thể. Kiểm tra được thực hiện tại mỗi điểm khi có phiên bản ổn định. Nền tảng của Agile dựa trên việc bắt đầu thử nghiệm từ khi bắt đầu dự án và tiếp tục trong suốt đến cuối dự án. Giá trị quan trọng của Agile là chất lượng của trách nhiệm là trách nhiệm của nhóm, điều này nhấn mạnh rằng chất lượng của phần mềm là trách nhiệm của cả nhóm (không chỉ nhóm thử nghiệm). Một khía cạnh quan trọng khác của Agile là chia nhỏ phần mềm thành các phần có thể quản lý nhỏ hơn và cung cấp chúng cho khách hàng rất nhanh. Cung cấp một sản phẩm làm việc là vô cùng quan trọng. Sau đó, nhóm tiếp tục cải tiến phần mềm và cung cấp liên tục ở mỗi bước chính. Điều này đạt được bằng cách có các chu kỳ phát hành rất ngắn gọi là chạy nước rút và nhận phản hồi để cải thiện vào cuối mỗi chu kỳ. Những người đóng góp không có nhiều tương tác của nhóm như nhà phát triển và người thử nghiệm trong các phương thức trước đó, giờ đây hoạt động cùng nhau trong mô hình Agile.

    Sự khác biệt giữa Phương pháp Agile và V (Mô hình) là gì?

    Mô hình Agile cung cấp phiên bản hoạt động của sản phẩm từ rất sớm so với V-Model. Khi nhiều tính năng được phân phối tăng dần, khách hàng có thể sớm nhận ra một số lợi ích. Thời gian chu kỳ thử nghiệm của Agile tương đối ngắn so với V-Model, vì thử nghiệm được thực hiện song song với phát triển. Agile là một mô hình chủ động (do chu kỳ rất ngắn của nó) so với Mô hình V phản ứng mạnh hơn nhiều. Mô hình V rất cứng nhắc và tương đối kém linh hoạt hơn mô hình Agile. Vì tất cả những ưu điểm này, Agile được ưa chuộng hơn mô hình V tại thời điểm này.

    --- Bài cũ hơn ---

  • Thôi Nhầm Lẫn Giữa Agile Và Agile
  • Những Khía Cạnh Quản Lý Phát Hành Nào Giúp Giải Thích Sự Khác Biệt Giữa Waterfall Và Agile?
  • Job Description (Jd) Là Gì? Cách Viết 1 Bản Mô Tả Công Việc
  • Sự Khác Biệt Giữa Điểm Phát Wifi Và 3G / 4G Là Gì?
  • Sự Khác Biệt Giữa Tết Ở Nhật Bản Với Tết Truyền Thống Của Việt Nam
  • Web hay
  • Links hay
  • Push
  • Chủ đề top 10
  • Chủ đề top 20
  • Chủ đề top 30
  • Chủ đề top 40
  • Chủ đề top 50
  • Chủ đề top 60
  • Chủ đề top 70
  • Chủ đề top 80
  • Chủ đề top 90
  • Chủ đề top 100
  • Bài viết top 10
  • Bài viết top 20
  • Bài viết top 30
  • Bài viết top 40
  • Bài viết top 50
  • Bài viết top 60
  • Bài viết top 70
  • Bài viết top 80
  • Bài viết top 90
  • Bài viết top 100