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

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

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

)

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

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:

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ụ.

Phần mềm làm việc thông qua các tài liệu đầy đủ

Sự hợp tác của khách hàng thông qua việc thương thuyết hợp đồng

Đá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

Mô hình đối tượng tên miền

Phát triển theo tính năng

Sở hữu thành phần/lớp

Nhóm tính năng

Kiểm tra

Quản lý cấu hình

Xây dựng chung

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:

Loại bỏ dư thừa

Khuếch trương việc học

Trì hoãn cam kết (quyết định càng muộn càng tốt)

Phát hành sớm

Trao quyền cho nhóm

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

Tối ưu hóa toàn bộ

All Rights Reserved

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

Agile Là Gì? Cách Thực Hiện Phương Thức Agile

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

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

Quản Lý Dự Án Theo Phương Pháp Truyền Thống Hay Phương Pháp Agile

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

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?

🌟 Home
🌟 Top