Phương pháp Agile (hay mô hình Agile) là một mô hình phát triển mạnh có độ biến động cao. 

Phương pháp Agile 

Phương pháp Agile được hình thành từ những kinh nghiệm trong những dự án thực của những kỹ sư phần mềm hàng đầu trong quá khứ. Phát triển phần mềm linh hoạt (agile software development – gọi tắt là Agile) là một triết lý cùng với nhóm các phương pháp và phương pháp luận phát triển phần mềm dựa trên các nguyên tắc phát triển phân đoạn lặp (iterative) và tăng trưởng (incremental), theo đó nhu cầu và giải pháp tiến hóa thông qua sự hợp tác giữa các nhóm tự quản và liên chức năng. Agile thường sử dụng cách lập kế hoạch thích ứng (adaptive planning), việc phát triển và chuyển giao theo hướng tiến hóa; sử dụng các khung thời gian ngắn và linh hoạt để dễ dàng phản hồi lại với các thay đổi trong quá trình phát triển. Ngày nay, Agile đã vượt xa khỏi khu vực truyền thống của mình là phát triển phần mềm để đóng góp sự thay đổi trong cách thức làm việc, quản lý, sản xuất ở các ngành khác như sản xuất (manufacturing), dịch vụ, sales, marketing, giáo dục v.v.

Do vậy, những thách thức và giới hạn của các phương pháp phát triển truyền thống đã được loại bỏ.  Chính vì thế, phương pháp Agile được tiếp nhận rộng rãi trong ngành như một giải pháp tốt hơn để phát triển phần mềm. Gần như mọi Developer đã từng sử dụng Agile ở một dạng nào đó (các ngành nghề khác có thể áp dụng phương pháp Agile)

Phương pháp Agile đảm bảo rằng giá trị được tối ưu hóa trong quá trình phát triển. Việc lên kế hoạch một cách có tương tác và liên tục phản hồi tạo ra một nhóm có thể liên tục đưa ra một sản phẩm thỏa mãn yêu cầu của người dùng. Nó có thể thích nghi trong một môi trường của yêu cầu liên tục thay đổi trong suốt quá trình bằng cách đo lường và đánh giá trạng thái của dự án. Hai việc này còn giúp tiến trình của dự án trở nên dễ theo dõi sớm và chính xác hơn.

Có thể nói rằng Agile giúp các công ty xây dựng một sản phẩm đúng. Thay vì cố gắng quảng cáo về một phần mềm trước khi nó được viết ra, phương pháp Agile giúp nhóm có thể tối ưu việc phát hành sản phẩm trong quá trình phát triển. Điều này làm cho sản phẩm trở nên cạnh tranh nhất có thể trong thị trường. Nó bảo toàn tính tương thích tới những thị trường quan trọng, và bao đảm rằng nhóm không tốn công sức lãng phí.

Cũng có nhiều chỉ trích với phương pháp Agile; tuy nhiên. phương pháp này tạo ra sản phẩm mà khách hàng có thể tin cậy. Mặc dù dự án có thể không tạo ra chính xác một sản phẩm mà khách hàng ban đầu hình dung, sản phẩm sẽ đưa đến đúng hạn mà nó cần. Trong suốt quá trình, khách hàng và nhóm liên tục thay đổi yêu cầu để tạo ra chất lượng cần thiết. Khách hàng thỏa mãn với kết quả, và nhóm làm thỏa mãn nhu cầu khách hàng. Sự thay đổi liên tục xảy ra đôi khi tạo ra những thứ vượt qua cả mong muốn ban đầu của nhóm và khách hàng. Phương pháp Agile thực sự là một giải pháp hấp dẫn đối với tất cả những ai có tham gia vào quá trình phát triển phần mềm.

Scrum à quy trình phát triển theo phương pháp Agile và tuân thủ nguyên tắc Agile. 5 cách Scrum có thể giúp bất kỳ đội nhóm(team) & phát huy khả năng làm việc nhóm hiệu quả:

1. Biết từng nhiệm vụ của mình đóng góp như thế nào trong mục tiêu chung

Bởi vì Scrum cho phép bạn chia các công việc phức tạp thành các nhiệm vụ nhỏ hơn, nó buộc bạn phải suy nghĩ về những hành động cụ thể cần thiết để đạt được một mục tiêu, và Scrum khuyến khích xem xét và sửa đổi từng hoạt động của bạn với các thành viên khác trong nhóm. Các thành viên trong nhóm rõ ràng là sẽ có những ý kiến khác nhau, dẫn đến những tình huống xung đột. Để đạt được mục tiêu chung, cần có trọng tâm rõ ràng. Vì vậy, điều quan trọng là cần nhận thức được những mục tiêu của cả tổ chức thay vì chú trọng quan điểm của từng cá nhân và cùng nhau làm việc để cùng nhau đạt được mục tiêu chung. Cả nhóm cần hiểu rõ mục tiêu và cam kết phấn đấu vì mục tiêu đó. Có định hướng và thống nhất rõ ràng về sứ mệnh và mục đích là điều rất quan trọng để làm việc nhóm một cách hiệu quả. Nếu cả nhóm đều có kỳ vọng rõ ràng về công việc, mục tiêu, trách nhiệm và kết quả, hoạt động nhóm sẽ trở nên suôn sẻ hơn.

2. Theo dõi công việc của team

Scrum khuyến khích sự minh bạch, nhưng không ở mức độ quản lý vi mô. Team của bạn cần phải biết những gì bạn đang làm và biết khi nào bạn thực hiện xong nhưngbạn có thể kết thúc bất kì lúc nào bạn muốn. Không có bất kì “Boss” nào trong một Scrum Team, nhưng mọi người phải chịu trách nhiệm cho ra sản phẩm cuối cùng hoàn chỉnh. Bên cạnh đó, Scrum cũng khuyến khích sự tự chủ trong tổ chức . 

Giao tiếp hiệu quả

Các thành viên trong nhóm nên giao tiếp thoải mái với nhau một cách trực tiếp và hướng tới mục tiêu đạt được thành công cho dự án. Việc giao tiếp giữa các thành viên với nhau và với trưởng nhóm nên là một quá trình hai chiều. Điều này sẽ giúp họ hiểu nhau hơn đồng thời giải quyết những vấn đề nảy sinh một cách nhanh chóng nhất.

Giao tiếp cởi mở, trung thực và tôn trọng. Các thành viên tự do bày tỏ suy nghĩ, ý kiến và các giải pháp tiềm năng để giải quyết vấn đề. Mọi người cảm thấy được lắng nghe và thấu hiểu. Các thành viên nên hỏi các câu hỏi để làm rõ ý kiến chứ không nên tìm cách phản bác đồng nghiệp của họ.

3. Xây dựng thành phẩm

Hay nói cách khác “Hoàn thành công việc trước deadline thật xa”. Ví dụ điển hình như sau: “Tôi sẽ xuất bản một bản eBook ngày 15 tháng 8″. Đó là một mục tiêu, nhưng bạn phải xác định được cần làm gì để hoàn thành nhiệm vụ và khi nào hoàn thành chúng? Trong mỗi Sprint, các hạng mục của bạn sẽ được hiểu như: “Tôi sẽ hoàn thành một bản thảo của eBook của tôi và được duyệt bởi cấp trên vào ngày 01 tháng 8″. 

Sự tin tưởng vào con người và vào sản phẩm

Trong bất kỳ mối quan hệ nào hoặc trong môi trường làm việc theo nhóm, sự tin tưởng là yếu tố rất quan trọng. Không nên tiết lộ những bí mật cá nhân, chi tiết dự án mới hoặc bất kỳ ý tưởng phát kiến mới trừ khi đó là vì lợi ích của tổ chức.

Môi trường làm việc nhóm hiệu quả là nơi mọi người thoải mái chấp nhận rủi ro hợp lý trong giao tiếp, ủng hộ các quan điểm và thực thi hành động. Các thành viên trong nhóm tin tưởng lẫn nhau và lắng nghe ý kiến của nhau.

4. Tổ chức

Quản lý dự án hiệu quả yêu cầu một tổ chức rõ ràng, và yêu cầu phải giao tiếp đối thoại mở và theo dõi tiến trình. Đây thực sự là điểm nội bật của Scrum (quản lý dự án hiệu quả nói chung). Bạn sẽ vẽ ra một bản đồ lộ trình hợp lý để thực hiện công việc. Cho dù bạn sử dụng Scrum framework hay bất kì framework nào, đặt nhiêm vụ lên hàng đầu là chìa khóa để thành công.

Phân công hiệu quả

Phân công trách nhiệm cũng quan trọng như đảm bảo hoàn thành mọi việc. Vì vậy cần phân công công việc dựa trên năng lực của các thành viên trong nhóm. 

Đảm bảo phân công rõ ràng về trách nhiệm của từng cá nhân trong nhóm

Đây là một trong những điều tiên quyết giúp quá trình làm việc nhóm trở nên công bằng và thuận lợi. Cố gắng tránh tình trạng chồng chéo thẩm quyền. Ví dụ nếu như có nguy cơ là hai thành viên trong nhóm sẽ phải cạnh tranh để kiểm soát trong một khoảng công việc nhất định, hãy cố gắng phân chia khu vực đó thành hai phần riêng biệt và phân công quyền kiểm soát từng khu vực cho từng thành viên dựa trên điểm mạnh và khuynh hướng cá nhân của từng người.

Tôn trọng

Để hợp tác hiệu quả, các thành viên trong nhóm cần hiểu và tôn trọng những thành viên khác. Tôn trọng năng lực, quan điểm và hành động của nhau để giảm thiểu xung đột, đảm bảo hoạt động suông sẻ và nâng cao năng suất

5. Linh hoạt nhưng tập trung

Scrum đôi khi có vẻ như có rất nhiều “quy tắc”, nhưng điều quan trọng là: Scrum là một khuôn khổ nhanh nhẹn (agile framework). Nó được thiết kế để cung cấp những sản phẩm tốt hơn và nhanh hơn. Điều này có nghĩa là bạn phải rời khỏi khuôn khổ Sprints cho những việc bất ngờ, nhưng bạn phải ưu tiên công việc để nói “từ chối” với nhưng việc có sức ảnh hướng thấp bất ngờ xảy ra. Scrum Master (hoặc tương đương) giúp bạn tìm ra những trở ngại và tìm ra cách tốt nhất để xử lý nó rất quan trọng hơn việc đạt được mục tiêu của team. 

Lãnh đạo vững mạnh

Tốc độ của người lãnh đạo là tốc độ của cả nhóm. Một người trưởng nhóm làm việc có hiệu quả là người có thể làm tấm gương gương mẫu cho cả nhóm. Một trưởng nhóm giỏi là người có thể đặt tầm quan trọng của mục tiêu nhóm trên mục tiêu cá nhân và có thể đưa ra định hướng, đảm bảo các thành viên trong nhóm giữ vững sự tập trung vào việc đạt được mục tiêu đó. 

Quản lý xung đột

Một trong những điều của kỹ năng làm việc nhóm cần có là phải giải quyết xung đột trong nhóm. Ngay cả đối với những vấn đề quan trọng, nếu biết xử lý một cách chuyên nghiệp sẽ ít gây ra tổn hại cho người khác hơn. Không nên để những ý kiến bất đồng gây ảnh hưởng đến kết quả làm việc nhóm.

Nhóm cần thỏa thuận quy trình xem xét, phân tích, đánh giá và giải quyết các vấn đề trong nhóm cũng như những xung đột. Không nên ủng hộ những xung đột cá nhân hoặc chia bè kết phái khi xảy ra xung đột. Thay vào đó, các thành viên nhóm cần hướng đến một giải pháp chung.

Tránh tiêu cực

Tránh cảm xúc tiêu cực, đố kỵ hoặc ác ý. Không nên tham gia vào những cuộc thảo luận không hiệu quả hoặc không lành mạnh. Khuyến khích những sáng tạo, đổi mới và các quan điểm khác nhau. Không nên sử dụng những ngôn từ mang tính chỉ trích, đổ lỗi cho người khác.

 

Gắn kết

Gắn kết nhóm trở thành một đơn vị thống nhất, nhóm cần làm việc dựa trên nền tảng chung. Cả tổ chức cần có những sáng kiến và tổ chức các buổi đóng góp xây dựng ý kiến, và các buổi họp, buổi giao lưu hằng tháng để tăng cường kết nối trong nhóm.

Tại sao các công ty thường làm việc nhóm khi tiếp cận các dự án, phát triển sản phẩm và mục tiêu? Trên thực tế, trong nhóm càng đưa ra những quan điểm khác biệt, khả năng thành công của các dự án càng cao hơn.

 

=========Đọc thêm:

Lợi ích của Agile. Ứng dụng Scrum. Nâng cao tinh thần đồng đội. Gia tăng tỷ suất hoàn vốn đầu tư. Tăng mức độ hài lòng của khách hàng

Ứng dụng Scrum vào dự án kế hoạch. Lợi ích của Agile và Scrum. “Khách hàng là thượng đế” hay “khách hàng luôn luôn đúng". Trước tiên tìm hiểu Agile là gì ? Scrum là gì ?

Agile là gì ?

Trong các dự án, đặc biệt là các dự án phần mềm chúng ta sẽ gặp rất nhiều khó khăn trong việc thu thập đầy đủ và chính xác các yêu cầu của sản phẩm để lập kế hoạch tốt ngay từ đầu. Có quá nhiều vấn đề gây ảnh hưởng đến việc phát triển phần mềm. Trong khi đó có quá nhiều vấn đề mà chúng ta không lường trước được. Những vấn đề này có thể đến từ những yếu tố như kinh doanh, kỹ thuật, con người ….

Trong giai đoạn những năm 1990 trên thế giới xảy ra cuộc khủng hoảng của quá trình phát triển phần mềm. Những phương pháp phát triển phần mềm theo cách truyền thống ngày càng bộc lộ nhiều nhược điểm và tỷ lệ các dự án thật bại cao. Từ đó các cá nhân và công ty riêng lẻ đã đưa ra các phương pháp phát triển phần mềm khác nhau để thích ứng với tình hình mới khiến cho phương pháp phát triển truyền thống đã không còn phù hợp

Agile Method (Phương pháp Agile)

Những phương thức phát triển phần mềm này giúp phần nào giải quyết được một số vấn đề nhưng lại nảy sinh vấn đề khác về sự chia sẻ, cộng tác, kỹ thuật, công cụ, hướng phát triển …. Do vậy năm 2001, nhóm 17 người có uy tín trong nghề phát triển phần mềm thời điểm đó đã gặp nhau và đi đến thống nhất cho ra đời 1 bản tuyên ngôn Agile:

1.“Cá nhân và sự tương tác hơn là quy trình và công cụ”
2.“Phần mềm chạy tốt hơn là tài liệu đầy đủ”->Kế hoạch hoàn mỹ là tài liệu đầy đủ.
3.“Cộng tác với khách hàng hơn là đàm phán hợp đồng”
4.“Phản hồi với sự thay đổi hơn là bám theo kế hoạch”


1) Cá nhân và sự tương tác hơn là quy trình và công cụ

Ý tưởng là đặt trọng tâm vào con người và sự tương hỗ giữa những thành viên trong nhóm. Cơ bản là nếu dự án có những thành viên có năng lực, chịu làm việc cùng nhau thì sẽ mang đến thành công cho dự án. Nếu dự án của bạn có quy trình làm việc tốt, được hỗ trợ những công cụ tốt nhất nhưng những thành viên không “cùng nhìn về một hướng” thì khả năng dự án thất bại là rất lớn. Nói điều này không có nghĩa là phủ nhận tầm quan trọng của quy trình và công cụ nhưng trong Agile nó được đặt sau yếu tố con người. Có một câu bằng tiếng Anh khá phổ biến nói về điều này là “a fool with a tool is just a fool”

2) Phần mềm chạy tốt hơn là tài liệu đầy đủ

Trong một số quy trình phát triển phần mềm, việc tạo ra và cập nhật các tài liệu về sản phẩm là bắt buộc.

a.Nhóm Dev không thể hoặc không đồng ý tiến hành công việc nếu không có tài liệu đặc tả về yêu cầu, thiết kế hệ thống. b.Nhóm Test thì yêu cầu tài liệu về sản phẩm để có thể viết trường hợp kiểm thử và kiểm thử được.

c.Nhóm QA đòi tất cả các tài liệu phải được viết trước khi sản phẩm được giao cho khách hàng nếu không thì không đủ điều kiện, chuẩn để giao sản phẩm cho khách hàng.

Thực ra đứng với góc độ khách hàng thì khách hàng chỉ quan tâm đến sản phẩm có hoạt động được và tốt hay không. Trong khi việc tạo và cập nhật tài liệu mất nhiều thời gian và được cho là buồn tẻ. Vậy tại sao mình phải tập trung quá nhiều cho việc không cần thiết mà không dành thời gian đó để trao đổi để hiểu thêm về công việc phải làm. Mọi người đừng hiểu lầm là làm Agile là không viết tài liệu. Ý tưởng là chỉ viết những gì mà mọi người cần đọc.

3) Cộng tác với khách hàng hơn là đàm phán hợp đồng

“Khách hàng là thượng đế” hay “khách hàng luôn luôn đúng”. Tuy nhiên thì khách hàng có đủ loại khách hàng. Có khách hàng am hiểu về công nghệ, có người không. Có người suy nghĩ nhất quán có người thay đổi xoành xoạch, có người lạnh lùng có người cười nói suốt ngày, v.v và cách duy nhất để có thể làm việc tốt là phải cộng tác với khách hàng để hiểu được khách hàng muốn gì và cần gì để có thể tư vấn và điều chỉnh thay vì chỉ dựa vào những điều đã quy định trong hợp đồng.

4) Phản hồi với sự thay đổi hơn là bám theo kế hoạch

Có một điểm chung mà mình thấy trong hầu hết những dự án mình đã trải qua đó là không có dự án nào không có sự thay đổi điều chỉnh khi thực thi. Sự thay đổi đó có thể là thay đổi về yêu cầu, thay đổi công nghệ, thay đổi nhân sự, thay đổi deadline, thay đổi phương thức làm việc, v.v mặc dù kế hoạch đã được định ra rõ ràng từ đầu. Agile không khuyến khích cho sự thay đổi nhưng khuyến khích chúng ta tập thích nghi với thay đổi.

Có một điều thú vị là đa số trong chúng ta đều cơ bản đồng ý với 4 tuyên ngôn của Agile. Nhiều người hiểu tầm quan trọng của “cá nhân” hay “cá nhân là tài sản quý giá nhất công ty” nhưng sẵn sàng thay đổi nhân lực để tương thích với quy trình/công cụ hiện có. Nhiều người hiểu “khách hàng là thượng đế” và “phải thích nghi với sự thay đổi” nhưng sẵn sàng tuyên bố “Dẹp, không làm nữa” vì khách hàng thay đổi yêu cầu liên tục. Hay như “sản phẩm xài được là quan trọng “ nhưng vẫn cố gắng viết thêm tài liệu với ý nghĩ rằng “biết đâu/lỡ sau này có ai cần thì có cái mà cung cấp”.

4 tuyên ngôn của Agile nói dễ hơn làm nhưng khi bạn theo Agile thì bạn hãy chuẩn bị tinh thần để “làm” chứ không phải để “nói”.

Ví dụ: Cá nhân và sự tương tác hơn là quy trình và công cụ. Agile hướng sự tập trung vào Cá nhân và sự tương tác mà không hệ phủ nhận quy trình và công cụ cũng như các phương thức truyền thống. Đó là lý do tại sao sử dụng từ hơn là chứ không phải thay vì hay bất kỳ từ nào khác với mục đích phủ định, loại bỏ cái cũ. Cách hiểu này cũng áp dụng cho các tuyên ngôn còn lại.
 

12 nguyên tắc của phương pháp Agile

1.Ưu tiên cao nhất của chúng tôi là thỏa mãn khách hàng thông qua việc chuyển giao sớm và liên tục các phần mềm có giá trị.
2.Chào đón việc thay đổi yêu cầu, thậm chí rất muộn trong quá trình phát triển. Các quy trình linh hoạt tận dụng sự thay đổi cho các lợi thế cạnh tranh của khách hàng.
3.Thường xuyên chuyển giao phần mềm chạy tốt tới khách hàng, từ vài tuần đến vài tháng, ưu tiên cho các khoảng thời gian ngắn hơn.
4.Nhà kinh doanh và nhà phát triển 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 những cá nhân có động lực. Cung cấp cho họ môi trường và sự hỗ trợ cần thiết, và tin tưởng họ để hoàn thành công việc.
6.Phương pháp hiệu quả nhất để truyền đạt thông tin tới nhóm phát triển và trong nội bộ nhóm phát triển là hội thoại trực tiếp.
7.Phần mềm chạy tốt là thước đo chính của tiến độ.
8.Các quy trình linh hoạt thúc đẩy phát triển bền vững. Các nhà tài trợ, nhà phát triển, và người dùng có thể duy trì một nhịp độ liên tục không giới hạn.
9.Liên tục quan tâm đến các kỹ thuật và thiết kế tốt để gia tăng sự linh hoạt.
10.Sự đơn giản – nghệ thuật tối đa hóa lượng công việc chưa xong – là căn bản.
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.
12.Nhóm phát triển 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.
Scrum là gì ?

Là một thành viên của họ Agile. Scrum được xây dựng dựa trên lý thuyết quản lý tiến trình thực nghiệm (empirical process control), hay còn gọi là thực nghiệm luận (empiricism). Scrum chỉ ra rằng tri thức đến từ kinh nghiệm và việc ra quyết định được dựa trên những gì đã biết. Điều này sẽ giúp giảm thiểu rủi ro và tăng tính chính xác đặc biệt là trong môi trường phát triển phần mềm nhiều biến động.

Ví dụ đơn giản nhất cho khái niệm Scrum đó là những đàn chim di cư. Chúng không hề có kế hoạch chi tiết cho hành trình của mình. Nhưng vẫn vượt qua được hàng chục nghìn km mỗi năm qua những vùng đất xa lạ nhờ việc quan sát và thích nghi liên tục với điều kiện khí hậu thức ăn. Nơi trú ngụ của từng vùng ….
 


3 yếu tố nòng cốt tạo thành một mô hình quản lý tiến trình thực nghiệm gồm: sự minh bạch (transparency), thanh tra (inspection) và thích nghi (adaptation).

1) Minh bạch

Các khía cạnh quan trọng của tiến trình phải được hiển thị rõ ràng cho những người có trách nhiệm với thành quả của tiến trình đó. Sự minh bạch yêu cầu các yếu tố này cần được định nghĩa theo một tiêu chuẩn để những người quan sát có thể hiểu những gì họ thấy theo cùng một cách.

2) Thanh tra

Người sử dụng Scrum phải thường xuyên thanh tra các tạo tác và tiến độ đến đích để phát hiện các bất thường không theo ý muốn. Tần suất thanh tra không nên quá dày để khỏi ảnh hưởng đến công việc. Công tác thanh tra có ích nhất khi được thực hiện bởi người có kỹ năng tại các điểm quan trọng của công việc.

3) Thích nghi

Nếu một người thanh tra xác định được rằng có vấn đề nào đó vượt quá giới hạn cho phép, và hậu quả của vấn đề đó đối với sản phẩm là không thể chấp nhận được, thì quy trình hoặc các vật liệu được xử lý (processed material) phải được điều chỉnh. Sự điều chỉnh phải được tiến hành càng sớm càng tốt để giảm thiểu các sai sót khác có thể xảy ra.

Để đảm bảo việc triển khai Scrum mang lại lợi ích cao nhất thì bạn phải đảm bảo cả 3 trụ cột trên trong một thể thống nhất. Thiếu một trong số đó sẽ gây ra hậu quả nghiệm trọng và dễ dẫn đến thất bại.
 

Có bốn Cuộc họp (4 Events) của Scrum
Scrum định nghĩa quy tắc cho bốn sự kiện chủ chốt (các cuộc họp) nhằm tạo môi trường và quy cách hoạt động và cộng tác cho các thành viên trong dự án. Các lễ nghi này diễn ra trước khi Sprint bắt đầu (Sprint Planning), trong khi Sprint diễn ra (Daily Scrum) và sau khi Sprint kết thúc (Sprint Review và Sprint Retrospective).

a. Sprint Planning (Họp Kế hoạch Sprint)
Nhóm phát triển gặp gỡ với Product Owner để lên kế hoạch làm việc cho một Sprint (xem thêm phần Sprint bên dưới). Công việc lập kế hoạch bao gồm việc chọn lựa các yêu cầu cần phải phát triển, phân tích và nhận biết các công việc phải làm kèm theo các ước lượng thời gian cần thiết để hoàn tất các tác vụ. Scrum sử dụng cách thức lập kế hoạch từng phần và tăng dần theo thời gian, theo đó, việc lập kế hoạch không diễn ra duy nhất một lần trong vòng đời của dự án mà được lặp đi lặp lại, có sự thích nghi với các tình hình thực tiễn trong tiến trình đi đến sản phẩm.

b. Daily Scrum (Họp Scrum hằng ngày)
Scrum Master tổ chức cho Đội sản xuất họp hằng ngày trong khoảng 15 phút để Nhóm Phát triển chia sẻ tiến độ công việc cũng như chia sẻ các khó khăn gặp phải trong quá trình phát triển phần mềm suốt một Sprint.

c. Sprint Review (Họp Sơ kết Sprint)
Cuối Sprint, nhóm phát triển cùng với Product Owner sẽ rà soát lại các công việc đã hoàn tất (DONE) trong Sprint vừa qua và đề xuất các chỉnh sửa hoặc thay đổi cần thiết cho sản phẩm.

d Sprint Retrospective (Họp Cải tiến Sprint)
Dưới sự trợ giúp của Scrum Master, nhóm phát triển sẽ rà soát lại toàn diện Sprint vừa kết thúc và tìm cách cải tiến quy trình làm việc cũng như bản thân sản phẩm.

Lợi ích mà Scrum mang lại

 

1) Cải thiện chất lượng phần mềm

Framework của Scrum giúp nhóm phát triển Scrum nhận phản hồi liên tục và nhanh chóng điều chỉnh để đảm bảo chất lượng phần mềm cao nhất, đồng thời đáp ứng đúng nhu cầu của thị trường luôn thay đổi. Bằng cách áp dụng các nguyên tắc nghiệm ngặt trong mô hình Scrum, nhóm phát triển Scrum có thể đưa ra thị trường các sản phẩm có chất lượng tốt nhất.

2) Rút ngắn thời gian phát hành phần mềm

Scrum đã được chứng minh là cung cấp sản phẩm đến tay khách hàng cuối cùng nhanh hơn 30%-40% so với phương pháp truyền thống. Vì mô hình Scrum làm việc với nguyên tắc chính là chia nhỏ phần mềm cần sản xuất ra thành các phần nhỏ để phát triển gọi là Sprint. Mỗi Sprint thường mất 2- 4 tuần để hoàn thành.

3) Nâng cao tinh thần đồng đội

Mô hình Scrum áp dụng cách thức tự quản và tự tổ chức (self-managing & self-organizing ), với mục đích các thành viên trong nhóm Scrum có thể vui vẻ làm việc cùng nhau, khơi dậy sự sáng tạo, chủ động trong họ. Cách thức tự quản lý cũng cho phép mọi thành viên trong nhóm Scrum đều có thể ra quyết định. Trong nhóm Scrum sẽ không có nhóm trưởng mà chỉ có Scrum Master, là người giúp nhóm vượt qua các trở ngại và che chắn cho nhóm khỏi những ảnh hưởng từ nội bộ hay bên ngoài.

4) Gia tăng tỷ suất hoàn vốn đầu tư (ROI)

Giảm thời gian sản xuất là lí do chính yếu nhất giúp các dự án Scrum đạt được ROI cao hơn. Bởi vì doanh thu và các mục tiêu khác đến sớm hơn, nên tổng lợi nhuận cao hơn theo thời gian. Đây là một nguyên lý cơ bản của giá trị hiện tại thuần (NPV)

5) Tăng mức độ hài lòng của khách hàng

Nhóm Scrum cam kết sản xuất ra các sản phẩm hoặc dịch vụ có thể khiến khách hàng hài lòng. Sở dĩ như vậy vì nhóm Scrum xem khách hàng là đối tác và giữ khách hàng tham gia vào dự án; thành phần tham gia dự án Scrum còn có Product Owner là người hiểu rõ các yêu cầu (requirements) của dự án và nhu cầu của khách hàng; thời gian cung cấp sản phẩm nhanh hơn

6) Kiểm soát dự án tốt

Tất cả các thành viên của nhóm dự án Scrum, Product Ower, Scrum Master và các bên liên quan có rất nhiều cơ hội để kiểm tra và điều chỉnh sản phẩm trong suốt dự án và cuối cùng tạo ra sản phẩm tốt nhất. Vì các framework của mô hình Scrum cho phép nhận các phản hồi liên tục và qua đó có thể nhanh chóng điều chỉnh.

7) Giảm thiểu rủi ro

Mô hình Scrum giúp giảm thiểu rủi ro thất bại hoàn toàn khi mất một số tiền đầu tư khổng lồ và thời gian dài để triển khai dự án mà không thu lại được ROI. Vì như đã trình bày, Scrum làm việc theo từng giai đoạn, từng Sprint, nên nhóm dự án có thể thực hiện từng bước, sau đó rút kinh nghiệm hoặc tiếp tục phát huy các ưu điểm của Sprint trước để cải thiện hơn sản phẩm trong Sprint sau tránh gây thất thoát quá lớn trong suốt dự án.

Lưu ý: Agile là phương pháp hiện đại có thể áp dụng cho ngành nghề khác (không nhất thiết Agile áp dụng trong ngành công nghệ phần mềm). Ví dụ điển hình Agile hay Scrum áp dụng cho ngành khác dựa trên các nguyên tắc cơ bản của Agile và 3 cột trụ của Scrum.v.v.

Điển hình áp dụng Scrump trong hội nhóm. 1. Phát triển can đảm dấn thân (không sợ thất bại) 2. Tập trung vào chuyên nhất 3. Hoàn tất đúng hạn kỳ (1 năm, 3 năm, 5 năm, 10 năm .v.v.) 4. Tôn trọng nhau. 5. Cởi mở và chân thành vì mục tiêu chung.

Ví dụ Scrump áp dụng ngành Marketing.

Người kiểm soát  (Scrum Master) là người hướng dẫn cho một nhóm phát
triển nhanh nhẹn. Scrum là một phương pháp cho phép một nhóm tự tổ chức và thực hiện thay đổi nhanh chóng, phù hợp với các nguyên tắc nhanh gọn. Người kiểm soát quản lý quy trình trao đổi thông tin.Người kiểm soát là người hướng dẫn cho một nhóm phát
triển nhanh nhẹn. Scrum là một phương pháp cho phép một nhóm tự tổ chức và thực hiện thay đổi nhanh chóng, phù hợp với các nguyên tắc nhanh gọn. Người kiểm soát quản lý quy trình trao đổi thông tin.Người quản lý hỏi đồng đội 3 câu hỏi:
1. Các bạn đã làm gì hôm qua?
2. Các bạn làm gì hôm nay?
3. Các bạn có gặp trở ngại gì?
 

Business Owner = chủ tiệm hay chủ doanh nghiệp. Stakeholders = cổ đông hay nhà tài trợ. Product Owner = người trách nhiệm hoàn tất sản phẩm hay dịch vụ theo mục tiêu định ra. Dev Team = đồng đội, nhân viên làm việc.


 

 

Theo Doanh nghiệp

Share this: