Phương Pháp Agile

Tổng hợp các bài viết thuộc chủ đề Phương Pháp Agile xem nhiều nhất, được cập nhật mới nhất ngày 21/01/2021 trên website Cuocthitainang2010.com. Hy vọng nội dung bài viết sẽ đáp ứng được nhu cầu của bạn, chúng tôi sẽ thường xuyên cập nhật mới nội dung Phương Pháp Agile để bạn nhận được thông tin nhanh chóng và chính xác nhất. Cho đến thời điểm hiện tại, chủ đề này đã đạt được 9.009 lượt xem.

Có 7 tin bài trong chủ đề【Phương Pháp Agile】

【#1】Quản Lý Trong Doanh Nghiệp Theo Phương Pháp Agile

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


【#2】Phương Pháp Quản Lý Dự Án Agile

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


【#3】Phương Pháp Phát Triển Phần Mềm: Truyền Thống Và Agile

Published on

Phương pháp phát triển phần mềm: Truyền thống và Agile.

Cảm ơn anh Ngô Trung Việt chọn lọc, biên dịch và giới thiệu tới cộng đồng.

  1. 1. Phương pháp phát triển phần mềm : truyền thống và Agile Anthony Lattanze Câu hỏi đầu tiên trong tâm trí nhiều người có thể là: Khuôn khổ qui trình phát triển phần mềm là gì? Tất nhiên, câu trả lời cho điều này là “Điều này là tuỳ.” Qui trình phát triển là nghi thức chung mà các tổ chức tuân theo để phát triển sản phẩm. Trong khi điều này là áp dụng được nói chung cho bất kì miền chế tạo nào, chúng ta có thể an toàn mà nói rằng qui trình phát triển là nghi thức hay thủ tục chung mà các tổ chức tuân theo để phát triển hệ thống dùng nhiều phần mềm và sản phẩm. Trong phần lớn các năm 1980 cho tới nay, sự hội tụ của các cộng đồng cải tiến qui trình đã từng dồn vào qui trình phát triển phần mềm, cho dù sản phẩm và hệ thống tiến hoá nhiều hơn chỉ phần mềm. Mô hình thác đổ từ Khái MLISTD 2167 Phân niệm hệ tích yêu Phân thống cầu hệ tích yêu Thiết kế thống sơ bộ Thiết kế cầu phần chi tiết Viết mã mềm và kiểm thử đơn Kiểm thử triển vị khai Lẫn lộn chung khác là thuật ngữ vòng đời phần mềm, điều thường được dùng một cách đồng nghĩa để chỉ qui trình phát triển phần mềm. Vòng đời phần mềm có xu hướng rất trừu tượng, mô tả các giai đoạn chung của các dự án phát triển phần mềm. Vòng đời phần mềm còn nhiều hơn phát triển hệ thống hay sản phẩm; nó nói tới con đường từ cái nôi tới nấm mồ mà các yêu cầu được thu thập và phân tích, và phần mềm được phát triển, kiểm thử, triển khải, bảo trì, và cuối cùng cho nghỉ việc. Mô hình vòng đời tương tự, có tên là V-mô hình (Forsberg et al., 1996), tồn tại trong cộng đồng kĩ nghệ hệ thống. Tổ chức tạm thời chung của những pha tổng quát này thường định nghĩa loại vòng đời phần mềm mà một tổ chức dùng. Được tổ chức theo cách này, vòng đời có thể là thác đổ, và theo cách khác nó có thể là lặp hay xoáy ốc. Những vòng đời đa dạng này được mô tả trong Hình 1. Mỗi một trong những vòng đời này phục vụ cho các hoàn cảnh phát triển hệ thống và doanh nghiệp khác nhau. Qui trình thác đổ có thể được dùng trong những tình huống mà các yêu cầu sản phẩm hay hệ thống và các công nghệ được hiểu rõ. Các vòng đời lặp hay xoáy ốc thường được dùng trong hoàn cảnh doanh nghiệp nơi các yêu cầu là biến động, công nghệ không được hiểu rõ, hay cả hai. Theo lí thuyết, việc lặp giúp nhận diện và kiểm soát rủi ro do các yêu cầu biến động hay công nghệ thách thức sớm hơn là cách tiếp cận thác đổ giúp. Các vòng đời phát triển phần mềm lặp dường như là được ưa chuộng nhất ngày nay. 1
  2. 2. Xác định mục tiêu, phương án và ràng buộc, Đánh giá phương án nhận diện và giảm Phân tích nhẹ rủi ro rủi ro Phân tích rủi ro Phân tích rủi ro Bản mẫu 1 2 3 Lập kế hoạch yêu cầu Thiết kế Viết mã Lập kế hoạch phát triển Kiểm thử Phát triển và trắc nghiệm lần lặp sản phẩm tiếp Lập kế hoạch V- mô hình kĩ nghệ hệ thống cổ điển Yêu cầu hệ thống Kiểm thử hệ thống Yêu cầu phần mềm Kiểm thử chấp nhận Thiết kế sơ bộ Kiểm thử tích hợp Thiết kế chi tiết Phân tích và thiết kế Kiểm thử cấu phần Kiểm thử đơn vị Xây dựng Hình 1 Mô hình vòng đời tổng quát. 2 Kiểm thử và tích hợp Mô hình xoáy ốc của Boehm
  3. 3. Tuy nhiên, trong thực hành, nếu người ta xem xét kĩ càng điều tổ chức thực sự làm khi nó xây dựng hệ thống dùng nhiều phần mềm, một tổ hợp của vòng đời lặp và thác đổ thường được dùng. Một khi thiết kế kiến trúc ổn định, thời kì không chắc chắn qua đi, và cách tiếp cận hướng thác đổ trực tiếp hơn có thể được lấy, hay những lần lặp khác nhau có thể được dùng để xây dựng và triển khai các phiên bản đa dạng của sản phẩm hay hệ thống. Các khuôn khổ qui trình phần mềm cung cấp nhiều chi tiết hơn các mô hình vòng đời tổng quát cung cấp, nhưng dầu vậy vẫn cần được làm thể nghiệm hay điều chỉnh cho các dự án và các tổ chức đặc biệt. Các khuôn khổ qui trình phần mềm tổ hợp các mô hình vòng đời phần mềm tổng quát, nhưng qui định các vai trò, trách nhiệm, vật phẩm, thủ tục, phương pháp, vân vân mà phải được tạo ra khi tuân theo khuôn khổ qui trình này. Các tổ chức thường bắt đầu với một khuôn khổ qui trình phần mềm và điều chỉnh nó theo qui trình phát triển phần mềm đặc biệt của họ. Các qui trình phần mềm của tổ chức được làm thể nghiệm là các khuôn khổ qui trình đặc biệt hơn nhiều và mô tả đặc biệt điều được làm, điều được sản xuất ra, và bởi ai. Các qui trình phần mềm của tổ chức có thể xác định các vai trò đặc biệt, trách nhiệm, vật phẩm, thủ tục, dạng thức tài liệu, khuôn mẫu, chuẩn, vân vân. Xem xét kĩ lưỡng hơn về qui trình phát triển của tổ chức, chúng ta thấy rằng không có một sự liên tục của các hoạt động mà khêu gợi yêu cầu, phân tích các yêu cầu, và làm tài liệu các yêu cầu, thiết kế, vân vân mãi cho tới khi hệ thống hay sản phẩm chạy ra. Xây dựng hệ thống phức tạp dùng nhiều phần mềm không giống như chế tạo theo dây chuyền lắp ráp, điều ít nhiều là sự liên tục của các chất liệu thô đi vào từ đầu này của nhà máy chế tạo và sản phẩm chạy ra từ đầu kia. Các qui trình được tổ chức dùng để phát triển hệ thống dùng nhiều phần mềm giống nhiều với tập các qui trình tách rời nhưng có tương hỗ mà được dùng cùng nhau để phát triển sản phẩm hay hệ thống. Qui trình nặng cân so với nhẹ cân Các cộng đồng cải tiến qui trình truyền thống có nguồn gốc ở trong các mô hình vòng đời thác đổ, cải tiến chất lượng toàn bộ, mô hình hoá trưởng thành năng lực, ISO 9000, Six Sigma, và những vấn đề khác. Nhiều trong các phong trào này bắt đầu từ đầu những năm 1980 khi nhu cầu về phần mềm liên tục mất kiểm soát, và thất bại dự án tăng lên là qui tắc. Điều đó là hiển nhiên bởi việc đưa người thông minh vào một phòng để chọc ngoáy mã trong 12 giờ một ngày sẽ không tất yếu đưa tới hệ thống với chức năng và thuộc tính đặc tính chất lượng mong muốn. Truyền thống dùng các khuôn khổ qui trình để hướng dẫn công việc của người thiết kế và người phát triển, và để cải tiến thực hành, vẫn diễn ra ngày nay. Tính mau lẹ ngày nay là mục nóng trong qui trình phát triển phần mềm. Nếu từ mau lẹ (agile) không xuất hiện trong tiêu đều hay tiêu đề con của một khuôn khổ qui trình, dường như là nó bị khinh rẻ bởi thế hệ mới các kĩ sư xem như “trường phái cổ” và “quá nặng cân.” Tương tự, những người thuần khiết từ các cộng đồng qui trình truyền thống dường như hơi chút nghi ngờ về phong trào qui trình nhẹ cân. Trong thực hành, các cực đoan thường không bao giờ là câu trả lời tốt nhất, và đây chắc chắn là trường hợp trong các tranh cãi qui trình nặng cân và nhẹ cân vẫn nổi lên dữ dội ngày nay. Các cộng đồng cải tiến qui trình truyền thống có xu hướng lấy tài liệu làm trọng tâm và tuỳ thuộc vào các qui trình tổ chức được cấu trúc cao, được xác định nghiêm ngặt, và được tuân theo trung thành để xây dựng hệ thống dùng nhiều phần mềm. Khẳng định là ở chỗ các hệ thống được xây dựng theo cách này có chiều chi phí, lịch biểu và chất lượng sản phẩm dự đoán được nhiều hơn – và có nhiều dữ liệu để hỗ trợ cho khẳng định này. 3
  4. 4. Mặc dầu những kiểu các khuôn khổ qui trình truyền thống này đã đóng góp lớn cho cải tiến cách các hệ thống được xây dựng, chúng thường nặng nề nhiều hơn cần thiết trong nhiều tình huống và hoàn cảnh doanh nghiệp. Nhiều trong những khuôn khổ này về nguồn gốc được tạo ra với các dự án lớn của bộ quốc phòng Mĩ trong tâm trí và thường quá tốn kém và rắc rối để cho các tổ chức nhỏ có thể theo được trong xây dựng hệ thống và sản phẩm dùng nhiều phần mềm. Một biện luận khác, mới gần đây là ở chỗ các qui trình nghiêm ngặt có xu hướng làm xơ cứng tính sáng tạo của tổ chức, và có bằng chứng từ các trường hợp nghiên cứu của các tổ chức đa dạng để gợi ý rằng có tính đúng đắn nào đó cho luận cứ này. Một ví dụ tuyệt vời là trường hợp nghiên cứu (Hindo, 2007) mô tả cho thành công nổi bật của công ti 3M trong khả năng của nó để lợi dụng phát kiến công nghệ. Tổ hợp của phát minh doanh nghiệp và cấu trúc công ti lớn thường là sự trộn lẫn bất thường. Các công ti lớn điển hình thấy khó phát kiến, và các công ti nhỏ thường thấy khó đạt tới sản xuất qui mô lớn, dự đoán được, có chi phí-hiệu quả. Tuy nhiên, 3M là công ti đã 100 năm đã tận hưởng danh tiếng là một trong những công ti phát kiến nhất trên thế giới trên hành tinh này, với nhiều thu nhập của nó dựa trên các công nghệ phát kiến mới được phát triển bên trong 3M. Thành công này đã được qui cho môi trường khuyến khích nhận rủi ro và sự dung thứ nào đó cho thất bại như chất xúc tác cho khám phá. Bên trong tổ chức nghiên cứu và phát triển của 3M, các qui trình cực nhẹ cân cho phép các kĩ sư được tự do khám phá các ý tưởng mà không bị nặng gánh hay bị gây sức ép của việc đáp ứng cách đo thống kê và các mục đích hay hạn chót thời gian đưa ra thị trường. Một kĩ sư nghiên cứu của 3M khẳng định rằng 5,000 ý tưởng phải được khảo sát để tìm ra một ý tưởng sẽ sinh lời. Mặc cho bản ghi theo dõi về phát kiến, thay đổi trong cấp quản lí điều hành nảy sinh trong những thay đổi nền tảng cho nghiêng về nhẹ cân và các qui trình phát triển ở 3M. Ông CEO mới, người chủ trương mạnh mẽ về quản lí chất lượng toàn bộ (TQM) và Six Sigma – các khuôn khổ qui trình được dựa vào, đã quyết định thể chế hoá kiểm soát qui trình nghiêm ngặt để đo, quản lí, và cải tiến qui trình phát kiến của 3M. Qui trình kiểm điểm pha nghiêm ngặt được thể chế hoá để thúc đẩy nghiên cứu có hứa hẹn. Dưới qui trình này, nếu một dự án nghiên cứu không cho thấy dẫn đến sản phẩm sinh lời sau khi kiểm điểm, dự án này bị cắt bỏ. Mục đích của loại kiểm soát qui trình này là để tăng tốc, hệ thống hoá, và dịch chuyển phát kiến thành sản phẩm sinh lời được cho thị trường. Mục đích của cấp quản lí là làm phát kiến thành dự đoán được nhiều hơn và có chi phí-hiệu quả. Tuy nhiên, phát kiến và khám phá cần qui trình hỗn độn và không dự đoán được nơi cách đo thống kê thô không cho biết được toàn thể câu chuyện về phát kiến thành công. Chẳng hạn, Post-It Notes đã được phát minh tại 3M là ví dụ cổ điển về chất dính bị thất bại đã tìm thấy thành công trong ứng dụng hoàn toàn không được lập kế hoạch trong Post-It Notes. Post-It Notes đã được dùng một thời gian dài trong các phòng thí nghiệm của 3M trước khi ai đó trong tổ chức này đã hứng khởi đưa nó ra thị trường như một sản phẩm cho người tiêu thụ. Dựa trên mục đích nghiên cứu gốc, điều đã dự định để phát triển chất dính mới, con số thống kê đã chỉ ra chương trình nghiên cứu này là thất bại. Tuy nhiên, thực tại là ở chỗ Post-It Notes khéo léo đã làm nảy sinh thu nhập hàng tỉ đô la cho công ti 3M. Theo các kĩ sư ở 3M, dưới chế độ mới về nghiên cứu có kiểm soát, được giám sát chặt chẽ, chất dính cho Post-It Notes chắc đã bị cắt bỏ từ lâu trước khi Post-It Notes được phát minh và tiềm năng thương mại của nó được khảo sát. Dưới các qui trình mới, dự án nghiên cứu bị cắt bỏ, cái không cho kết quả trong khung thời gian nhất quán với các con số thống kê và bên trong khuôn khổ qui trình được xác định nghiêm ngặt. Mặc dầu thu nhập từ chế tạo sản phẩm hiện có tăng trưởng dưới kiểm soát qui trình nghiêm ngặt, thu nhập từ phát kiến mới tụt thẳng xuống. Việc áp dụng kiểm soát qui trình nghiêm ngặt cho các chức năng nghiên cứu và phát triển làm xơ cứng hiệu quả tính sáng tạo. Thất bại không được dung thứ, vì nó là xấu theo thống kế, và các chi phí khảo sát không 4
  5. 5. bị trói buộc mà các con số thống kê đã chỉ ra sẽ không dẫn tới sản phẩm sinh lời đã bị khử bỏ. Về truyền thống, 3M đã là nơi các nhà nghiên cứu được cho phạm vi rộng để theo đuổi nghiên cứu tới chỗ nó đưa tới. Tuy nhiên, nhiều nhà nghiên cứu giỏi nhất đã bỏ 3M để tìm đồng cỏ xanh tươi hơn nơi họ có thể theo đuổi chương trình nghiên cứu của họ trong môi trường không bị trói buộc. Hiệu quả của những thay đổi này là đáng ngạc nhiên. Năm 2004, 3M được xếp hạng thứ nhất trên danh sách các công ti phát kiến nhất của Boston Consulting Group. Nó đã tụt xuống thứ hai trong năm 2005, thứ ba trong năm 2006, và xuống thứ bẩy trong năm 2007. Trước khi chấp nhận kiểm soát qui trình nghiêm ngặt, một phần ba các sản phẩm của 3M đã dựa trên phát kiến mới. Sau khi chấp nhận kiểm soát qui trình nghiêm ngặt, con số này tụt xuống một phần tư. Theo trường hợp nghiên cứu này, kiểm soát qui trình nghiêm ngặt dường như phục vụ cho việc chế tạo các sản phẩm đã thiết lập tốt, nhưng tác động nghiêm trọng tới các tổ chức nghiên cứu và phát kiến bên trong 3M. Với một công ti như 3M, không phát kiến trong phân đoạn thị trường của nó có thể là án tử hình chậm. Xu hướng tiêu cực này tại 3M gần đây đã được CEO mới đề cập tới, người đã loại bỏ nhiều sự cứng nhắc trong các tổ chức nghiên cứu và phát triển bên trong 3M và đã thiết lập lại nhiều thực hành trước đây. Điều này đề cập tới câu hỏi: Tại sao các tổ chức cứ nhấn mạnh vào những cực đoan: nhẹ cân hay nặng cân, kiểm soát cao hay kiểm soát mặc kệ cho làm? Dường như là không có chỗ cho cả hai hay mảnh đất ở giữa. Trường hợp nghiên cứu này (và những trường hợp tương tự) sẽ dường như chỉ ra rằng kiểm soát cao, các qui trình nặng cân có thể có chỗ trong sản xuất thường lệ và môi trường chế tạo, nhưng không có chỗ trong môi trường động, hướng phát kiến. Sao không áp dụng cả hai? Sự nổi dậy nhỏ chống lại các khuôn khổ qui trình hướng thác đổ nguyên khối đã bắt đầu từ giữa những năm 1980, đặc biệt trong các tổ chức năng động nhỏ hơn. Nhưng cho dù các tổ chức này nhận ra rằng họ quá cần các qui trình có kỉ luật hơn nào đó, và vấn đề chọc ngoáy hệ thống không thể thức có thể là đơn thuốc cho thảm hoạ. Điều này dẫn tới việc thám hiểm các khuôn khổ qui trình thay thế mà có thể cung cấp đủ qui trình cho các tổ chức năng động, nhỏ hơn trong xây dựng hệ thống dùng nhiều phần mềm. Một xem xét quan trọng khác của nhiều người nghiên cứu là tạo ra khuôn khổ qui trình đảm đương được mà có thể dễ dàng được chấp nhận và rẻ. Phải tốn kém nhiều tiền, nỗ lực, thời gian, và tài nguyên để phát triển, thể chế hoá, dịch chuyển, đo và bảo trì các khuôn khổ qui trình kiểm soát cao, nặng cân. Những chi phí này đã là, và vẫn là vấn đề chính cho các tổ chức công nghệ cao nhỏ hơn. Một khuôn khổ qui trình đã nổi lên vào giữa những năm 1980 làm thay đổi cách các kĩ sư nghĩ về các khuôn khổ qui trình phát triển. Phát triển ứng dụng nhanh (RAD) bùng nở trên khung cảnh công nghệ vào những năm 1980 và là ông tổ của khuôn khổ qui trình agile (uyển chuyển) điều sinh sôi nảy nở ngày nay (Martin, 1991). Mặc dầu chỉ có một đám nhỏ những tín đồ và phần lớn không được các cộng đồng thời đó về qui trình trên máy tính lớn tin tưởng, RAD đã gieo hạt mầm mà vẫn đem lại kết quả ngày nay. Tại lõi của nó, RAD đã dùng mô hình vòng đời xoáy ốc mà đã được Boehm lí thuyết hoá trong bài báo bước ngoặt của ông ấy (Boehm, 1986). Tuy nhiên, RAD đã vận hành hoá khái niệm này trong một khuôn khổ cụ thể hơn mà các tổ chức có thể làm thể nghiệm và duy trì một cách nhanh chóng, dễ dàng và rẻ. Trong suốt cuối những năm 1980 và đầu những năm 1990, các mô hình như Mô hình trưởng thành năng lực (Paulk et al., 1995) đã chi phối, nhưng các khuôn khổ qui trình nhẹ cân dần dần và vững chắc thu được mảnh đất và nhiều uy tín hơn. Dịch chuyển này từ các khuôn khổ qui trình nặng cân sang nhẹ cân có thể được qui cho sự kiện là những nhà sản xuất và tiêu thụ phần mềm lớn nhất trên toàn thế giới trong những năm 1980 là chính phủ Mĩ, và nói riêng là Bộ quốc phòng Mĩ. Hệ thống dùng nhiều phần mềm thường phức tạp, siêu qui mô và được xây dựng bởi lực lượng lao động phân bố cao. Điều này cần việc dùng các qui trình rất 5
  6. 11. Thay vì tạo ra lịch biểu đầy đủ trước thời gian, tôi thích dùng cách tiếp cận lặp bằng viết thiết lập lịch biểu một tuần vào mỗi lúc, nơi các thành viên tổ đều tham gia để cho tôi biết họ có thể hoàn thành được cái gì vào tuần đó. Một khi họ đã đạt tới một cột mốc, đó là lúc ước lượng và lập kế hoạch sang cột mốc tiếp. Việc cả tổ tham gia vào ước lượng lịch biểu là tốt hơn nhiều so với ước lượng riêng của các cá nhân. Tôi đòi hỏi từng thành viên tổ phải đưa ra ước lượng riêng của họ và dùng cách tiếp cận “Delphi băng rộng” hay cách tiếp cận trung bình để đi tới lịch biểu toàn thể. Khi bạn cho phép mọi người tạo ra ước lượng riêng của họ, họ có xu hướng theo dõi mình, đi theo mình, và cố gắng làm cho nó được hoàn thành thành công bởi vì ước lượng của họ là một phần công việc của họ. Bởi vì các dự án agile đều nhỏ, bạn phải tích hợp các công việc liên tục, không thành vấn đề bạn đang làm cái gì (mã, kiểm thử, tài liệu, kế hoạch). Bạn phải có người làm quản lí cấu hình phần mềm để giúp thiết lập cấu hình và phiên bản đúng cho phần mềm của bạn vì công việc thường xuyên thay đổi. Khi phiên bản cuối cùng được kiểm đưa vào, và tôi biết trạng thái nó tới trong nó và tôi không phải nghĩ về nó. Ai đó hỏi tôi, nếu agile là hoạt động toàn tổ, có thực sự cần người quản lí dự án không? Câu trả lời của tôi là dứt khoát “Có.” Tuy nhiên, vai trò của người quản lí dự án trong phương pháp agile mang nhiều tính người lãnh đạo và thầy kèm chứ KHÔNG kiểm soát như được dạy trong hầu hết các giáo trình quản lí dự án. Bạn càng cung cấp nhiều hướng dẫn và hỗ trợ cho tổ, họ sẽ càng có kết quả hơn. Bạn càng thực hành cách tiếp cận cộng tác này, bạn càng linh hoạt hơn như một người quản lí dự án, điều làm cho bạn thành người quản lí giỏi hơn. Bạn KHÔNG ra lệnh cho họ, bạn KHÔNG chỉ đạo họ, bạn KHÔNG chỉ huy họ, bạn KHÔNG đe doạ họ mà bạn là người hướng dẫn họ, ai đó mà họ tin cậy và ai đó giúp cho họ làm công việc của họ. Về căn bản, bạn là người lãnh đạo của họ và người lãnh đạo KHÔNG phải là ai đó có thẩm quyền trên họ mà là ai đó họ sẵn lòng đi theo. Dự án agile thành công có hai yếu tố then chốt: Người lãnh đạo là người quản lí dự án và tổ có kinh nghiệm và có kỉ luật. Không có hai yếu tố này, nó sẽ là khó. Câu hỏi của tôi là “Là người quản lí dự án, bạn có sẵn lòng thay đổi để trở thành người lãnh đạo giỏi hơn không?” và “Là thành viên tổ, bạn có đủ kinh nghiệm và kỉ luật để áp dụng phương pháp agile vào công việc của bạn không?” 11


【#4】Agile Là Gì Và Các Phương Pháp Kiểm Thử Agile

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


【#5】Phương Pháp Quản Lý Dự Án Scrum

Bài viết này mong muốn cung cấp cho người đọc một cái nhìn thực tế về phương pháp quản lý dự án Agile-Scrum (Scrum Agile Methodology). Sau khi đọc bài viết, hy vọng bạn sẽ hiểu được những điều cơ bản của công cụ quản lý dự án phần mềm hiệu quả này.

Agile-Scrum là gì?

Phương pháp phát triển phần mềm Agile-Scrum là một giải pháp linh hoạt trong việc sản xuất phần mềm, Scrum cung cấp một nền tảng để phát triển sản phẩm và nó cũng có thể được áp dụng bên ngoài lĩnh vực công nghệ thông tin, truyền thông (ICT-Information & Communication Technologies).

Scrum là một nhánh của phương pháp quản lý dự án Agile, cha đẻ của nó là Hirotaka Takeuchi và Ikujiro Nonaka – 2 nhà tư tưởng quản trị lỗi lạc người Nhật Bản.

Tại sao gọi là Scrum?

Thuật ngữ “Scrum” xuất phát từ môn rugby, một môn thể thao dựa trên sự phối hợp, tính ăn ý, tốc độ và tính kỉ luật của mỗi thành viên.

Trong một trận đấu rugby, hai đội đều cố gắng ghi bàn và giành chiến thắng. Ngoài việc phối hợp với nhau, các cầu thủ còn phải nhanh chóng thích nghi với sự thay đổi của diễn biến trận đấu. Đó là một ví dụ minh hoạ về Scrum.

Ứng dụng của Scrum

Scrum đã đạt được nhiều thành tựu trong giới phát triển phần mềm. Ngày nay, phương pháp này được áp dụng trong nhiều tập đoàn lớn, các công ty đa quốc gia và cả các doanh nghiệp vừa và nhỏ. Tuy nhiên, mỗi doanh nghiệp sẽ áp dụng Scrum một cách khác nhau, từ các dự án đơn giản đến phức tạp.

Chính bởi tính minh bạch, dễ hiểu, phương pháp này có thể dễ dàng được kết hợp với các phương pháp quản lý khác như Prince2, CMM và ITIL .

Do phương pháp này bảo đảm được sự tối giản về thời gian chuyển giao và các thủ tục, nên nó có thể sẽ đạt được những hiệu quả cao hơn khi kết hợp với những phương pháp khác.

Scrum thường được sử dụng trong việc phát triển những sản phẩm mà người dùng vẫn chưa xác định được mục tiêu cuối cùng. Bằng phương pháp này, các nhu cầu và đòi hỏi về sản phẩm ngày càng được mô tả chi tiết hơn để tạo ra một sản phẩm hoàn thiện và hữu ích.

Tính linh hoạt là một ưu điểm nổi trội của Scrum, thêm vào đó là việc dễ sử dụng khiến phương pháp này trở nên phổ biến.

Các đội ngũ đa ngành

Scrum nằm trong khuôn khổ phát triển phần mềm Agile, được sử dụng để phát triển phần mềm trong một nhóm. Điểm mạnh của nó nằm ở chỗ nhiều lĩnh vực khác nhau có thể cùng hợp tác trong một dự án.

Phương pháp này giả định rằng tất cả các thành viên đều có những kiến thức cần thiết bởi mọi người đều phải tham gia vào việc lập kế hoạch, xác định những tồn đọng và phân chia công việc.

Sprints (Chu kỳ công việc)

Scrum được cấu thành bởi các chu kỳ sprint ngắn. Mỗi sprint là một khoảng thời gian cố định từ 1 đến 4 tuần, trong đó phần mềm vận hành được cung cấp bởi nhóm phát triển.

Với mỗi sprint, sản phẩm cuối cùng sẽ tiếp tục được mở rộng và cải tiến bởi nhóm phát triển. Những khung thời gian cố định này sẽ đảm bảo một đầu ra thường xuyên và điều tiết nhịp điệu làm việc của cả nhóm.

Phương pháp này tạo điều kiện quản lý công việc thông qua dự án. Tuy nhiên, phải dựa trên các giá trị cốt lõi sau:

1.Tính cam kết

Các thành viên nên cởi mở để kết nối với nhau và sẵn sàng cùng làm việc dựa trên những mục tiêu thực tế và đầy thách thức với một thái độ đầy hứng khởi. Tính dân chủ và tính kỷ luật là 2 yếu tố quan trọng để đạt được mục tiêu trong một khung thời gian cố định.

2. Sự cởi mở

Giao tiếp mở và minh bạch truyền sự tự tin và loại bỏ những rào cản để giải quyết vấn đề chung và cuối cùng khuyến khích mọi người giúp đỡ lẫn nhau.

3. Lòng can đảm

Mặc dù có sự hợp tác trong nhóm, thì điều quan trọng vẫn là những cá nhân dũng cảm, có khả năng đưa ra các quyết định độc lập và cần thiết. Thể hiện sự can đảm thúc đẩy sáng tạo và giải quyết vấn đề xung quanh.

4. Sự tập trung

Nhóm quản lý dự án không được coi thường các mục tiêu chung và nên có động lực hợp tác với nhau một cách có hiệu quả.

5. Sự tôn trọng

Thông qua việc tôn trọng lẫn nhau, mọi người có thể động viên nhau cùng làm việc vì họ luôn sẵn sàng giúp nhau giải quyết vấn đề và không bao giờ đùn đẩy trách nhiệm cho người khác.

6. Tính phổ biến

Scrum là một phương pháp linh hoạt được áp dụng cho cả các lĩnh vực không phải là công nghệ thông tin và truyền thông (ICT-Information & Communication Technologies). Do tính đơn giản và định hướng kết quả, nó rất phổ biến với cả nhóm tự định hướng và khách hàng.

Để phương pháp này thành công, cần phải có đội ngũ làm việc cực kỳ minh bạch về tiến độ và liên tục tìm kiếm hiệu suất tốt nhất có thể.

Sau tất cả, đấy là lý do tại sao phương pháp này là nền tảng “thực tiễn tốt nhất” được sử dụng trong ngành công nghiệp Nhật Bản.


【#6】5 Phương Pháp Quản Lý Dự Án Bạn Nên Sử Dụng

Triển khai dự án cho khách hàng là công việc hàng ngày của tôi. Vì vậy, tôi luôn phải động não, hợp tác và giải quyết các vấn đề trong nhiều bối cảnh và kích cỡ khác nhau.

Bạn có thể đang gặp khó khăn với tiến độ và kết quả của dự án?

Nhưng hãy nhớ,

Chúng ta không đơn độc.

Hàng trăm năm qua, rất nhiều người đã tìm cách để làm chủ nghệ thuật lập kế hoạch, thực hiện và kiểm soát các dự án. Trong bài viết này, tôi chia sẻ với bạn 5 phương pháp phổ biến nhất, bao gồm:

  1. Agile – Dự án Nhanh nhẹn
  2. Mô hình Thác nước
  3. Lean – Dự án Tinh gọn
  4. Scrum
  5. Kanban

1. Agile – Dự án Nhanh nhẹn

Nhấn mạnh vào điểm kết thúc

Phương pháp này tập trung vào trạng thái kết thúc hoặc mục tiêu cuối cùng của dự án. Với cách tiếp cận này, Agile quản lý nhiều hơn vào cách suy nghĩ và sáng kiến.

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

  1. Hợp tác với khách hàng trong việc xác định yêu cầu của dự án.
  2. Có quy trình và công cụ trong việc tương tác giữa các thành viên.
  3. Sẵn sàng thay đổi kế hoạch khi thực hiện.

Như bạn có thể thấy, điểm nhấn mạnh ở đây là Tương tác và Sự linh hoạt. Agile ném tất cả các kế hoạch cứng nhắc và suy nghĩ truyền thống ra khỏi cửa.

Với Agile, dự án được hoàn thành bằng phương pháp thử nghiệm liên tục các sáng kiến, đánh giá hiệu quả của sáng kiến, và sau đó thích ứng nhanh với sáng kiến mới.

Hãy nghĩ về Agile như một dòng chảy liên tục của các sáng kiến.

Ưu điểm của Agile

    Agile hiểu rằng không có sự chắc chắn 100% trong kinh doanh, chính là hằng số duy nhất, và đòi hỏi các thành viên phải cởi mở để sẵn sàng thay đổi liên tục.

Nhược điểm của Agile

  • Đối với những người thích làm việc theo cấu trúc và kiểm soát chặt, phương pháp Agile có thể khó hiểu và khó chịu.
  • Agile nhanh nhẹn và thay đổi liên tục, gây ra cảm giác mất kiểm soát nếu không được cập nhật thông tin. Vấn đề này phải được bù đắp bằng việc trao đổi thông tin và cộng tác liên tục giữa các thành viên. Đôi khi, việc cập nhật quá thường xuyên gây khó chịu với khách hàng hoặc với các nhóm làm việc từ xa.

2. Mô hình thác nước

Lập kế hoạch từng bước cho kết quả chắc chắn

Mô hình thác nước là dễ hiểu nhất vì nó tiếp cận theo hệ thống chặt chẽ đi từ trên xuống dưới.

Các nhà quản lý dự án cố gắng loại bỏ bất kỳ sự không chắc chắn nào, bằng cách phác thảo tất cả các nhiệm vụ trong dự án (từ bước đầu tiên đến bước cuối cùng) và đóng đinh các chi tiết về phạm vi, ngân sách và lịch trình rất chặt chẽ.

Mô hình thác nước xuất phát từ các ngành công nghiệp sản xuất và xây dựng. Đơn giản là bạn liệt kê ra tất cả các nhiệm vụ cần thiết để đạt được mục tiêu cuối cùng của dự án.

Quá trình này rất đơn giản:

  • Thực hiện các nhiệm vụ khác theo đúng thứ tự.
  • Mỗi nhiệm vụ phải được hoàn thành trước khi chuyển sang nhiệm vụ tiếp theo.

Ý tưởng ở đây là:

Bằng cách đầu tư thời gian cho việc lập kế hoạch, đảm bảo các nhiệm vụ phù hợp được đưa ra ngay từ đầu, sẽ giúp giảm thiểu các vấn đề và rủi ro phát sinh sau này.

  • Mô hình thác nước rất tuyệt vời nếu bạn có thể đưa ra một kế hoạch chắc chắn ngay từ đầu.
  • Danh sách nhiệm vụ rất rõ ràng và kết quả có thể dự đoán được.
  • Mô hình này cho phép bạn đạt được hiệu suất cao khi phương pháp thực hiện mục tiêu đã được kiểm chứng thành công.
  • Độ cứng của mô hình thác nước có thể là một vấn đề đối với một số phong cách làm việc. Bởi vì bạn không có cửa cho việc đi lệch khỏi bản kế hoạch đã lập ra.
  • Đối với nhiều nhóm dự án, đây là một vấn đề rất lớn khi họ phải đối mặt với những vấn đề xuất hiện bất ngờ, không có trong kế hoạch.

3. Lean – Dự án Tinh gọn

Nhiều kết quả hơn, với ít nỗ lực hơn

Quản lý dự án tinh gọn là về việc tạo ra nhiều kết quả hơn với ít người, tiền và thời gian hơn.

Tương tự như Agile, Lean quan tâm nhiều hơn đến cách suy nghĩ và sáng kiến.

Triết lý tinh gọn này xuất phát từ Hệ thống sản xuất của Toyota (TPS), tập trung vào việc loại bỏ các lãng phí để tăng giá trị.

Theo lean, có 3 loại lãng phí cần loại bỏ, bao gồm:

  • Muda : là những hoạt động không tạo ra giá trị.
  • Mura : là những yếu tố gây mất cân bằng. Ví dụ: đang sản xuất thì hết nguyên liệu, đang triển khai theo kế hoạch thì sếp thay đổi kế hoạch.
  • Muri : là các yếu tố gây quá tải tạo ra sự căng thẳng và kiệt sức.

Ưu điểm của Lean

Nhược điểm của Lean

    Với nguồn gốc xuất phát từ sản xuất, phương pháp này khó áp dụng cho các đội nhóm hiện đại ngày nay.

Các đội chức năng chạy nước rút để về đích

Scrum có lẽ là một trong những khung hiệu quả nhất được sử dụng trong thế giới SaaS – Software as a Service (dịch vụ phần mềm).

Với Scrum, mục tiêu cuối cùng đạt được thông qua – các khúc thời gian – có độ dài cố định, được gọi là chạy nước rút.

Các nhịp chạy nước rút này bao gồm các giai đoạn khác nhau, như:

  • Lập kế hoạch,
  • Báo cáo hàng ngày hoặc cuộc họp,
  • Bản demo, và
  • Đánh giá phản hồi.

Với Scrum, trọng tâm của bạn là những gì có thể đạt được trong một khoảng thời gian được xác định trước (ví dụ: 2 tuần).

Sau khi bạn xác định những gì mỗi thành viên có thể đạt được, trong một khoảng thời gian; thì việc còn lại, chỉ là cắm đầu chạy nước rút, thực hiện công việc cho đến khi hoàn thành.

Ưu điểm của Scrum

Nhược điểm của Scrum

    Có thể khó bổ sung thêm các nhiệm vụ bất ngờ mới vào một lần chạy nước rút, sau khi nó được lên kế hoạch, có nghĩa là khó có thể đáp ứng thêm các yêu cầu đặc biệt.

Minh bạch danh sách việc cần làm

Hãy nghĩ về bảng Kanban như một công cụ trực quan, nơi bạn có thể thấy nhìn thấy, bằng mắt, vị trí của từng tác vụ trong quy trình công việc.

Bảng được chia thành nhiều cột cho từng giai đoạn trong quy trình. Các cột này có thể được tùy chỉnh theo ý thích của bạn, tùy thuộc vào dự án bạn đang làm việc. Ví dụ:

Mỗi nhiệm vụ của bạn sau đó được hiển thị trên bảng Kanban, bằng cách sử dụng thẻ hoặc giấy note. Bạn có thể di chuyển các thẻ từ cột này sang cột khác.

Kanban rất dễ hiểu và thích nghi tốt với sự thay đổi, chuyển đổi các ưu tiên cũng đơn giản như việc di chuyển thẻ trên bảng kanban.

Ưu điểm lớn nhất là bạn có thể kiểm tra tiến độ chỉ bằng 1 cái liếc nhìn trực quan.

Nhược điểm của Kanban

Kanban thường tập trung vào các tác vụ hàng ngày, nó thúc đẩy việc thực thi nhiệm vụ, nhưng có thể gây rủi ro cho bức tranh lớn hơn là chiến lược và những kết quả quan trọng nhất. Cụ thể: Các nhiệm vụ nhỏ được hoàn thành, nhưng kết quả cuối cùng, chưa chắc đã đạt được.

Cuối cùng,

Mỗi phương pháp quản lý dự án đều có ưu nhược điểm riêng, điều quan trọng là, sự lựa chọn phù hợp với tình huống của bạn.


【#7】Phương Pháp Scrum Vs Phương Pháp Kanban

Scrum và Kanban là hai từ thường được sử dụng thay thế cho nhau hoặc được mọi người hiểu sai nó là cặp từ đồng nghĩa. Trong thực tế, hai phương pháp Scrum và Kanban là khác nhau và thường được kết hợp với nhau Scrumkanban. Hiểu được những sự khác biệt của hai phương pháp sẽ giúp bạn chọn được phương pháp tốt nhất và phù hợp nhất cho công ty của bạn. Như vậy, Ecci vietnam sẽ giúp bạn hiểu rõ hơn.

Khái niệm cần nắm

Về cơ bản, phương pháp Scrum là bộ khung làm việc (framework) giúp các công ty, tổ chức chia nhỏ công việc thành những phần nhỏ hơn, để quản lý dễ dàng hơn và đượchoàn thành bởi một nhóm liên chức năng (cross-function) trong một khoảng thời gian quy định (còn gọi là sprint trong 2-4 tuần).

Nhóm Scrum thường sử dụng Bảng Scrum để theo dõi công việc của từng thành viên trong nhóm (dòng chảy công việc – flow of work). Mỗi nhiệm vụ (task) được chia thành các đoạn nhỏ gọi là “stories”, mỗi stories chuyển giao trong Bảng gọi là “backlog” (những việc phải làm), trở thành “work-in-progess” (việc đang triển khai)

Đó là một quy trình phát triển phần mềm theo mô hình linh hoạt (agile), cung cấp rất nhiều phương pháp luận, quy trình và các thực nghiệm để cho việc phát triển phần mềm trở nên nhanh chóng và dễ dàng. 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. Sprint phải độc lập và release được), lấy ý kiến khách hàng (Product Owner) và thay đổi cho phù hợp ngay trong quá trình phát triển để đảm bảo sản phẩm release đáp ứng những gì khách hàng mong muốn.

Mô hình Scrum vận hành dựa trên đặc tính tư nhiên của người phát triển nên rất dễ hiểu, dễ áp dụng, tạo nên tính tương tác cao giữa những thành viên trong nhóm thay vì chịu sự áp đặt từ bên ngoài.

Ưu điểm của mô hình Scrum là gì?

– Thời gian hoàn thành dự án linh hoạt, không bị cố định từ đầu

– Thời gian tạo ra sản phẩm dựa vào mô hình Scrum nhanh, tốc độ phát triển nhanh, tiết kiệm thời gian

– Phân phối sản phẩm mềm dẻo: nội dung sản phẩm chuyển giao được xác định linh hoạt theo môi trường sử dụng thực tế.

– Mỗi thành viên phụ trách một “sprint” nên hiệu quả công việc cao hơn, năng suất cao hơn và tính chính xác cao hơn

– Khách hàng tham gia vào quá trình phát triển phần mềm để đảm bảo sản phẩm đầu ra đáp ứng đúng nhu cầu phát triển.

– Kiểm soát quá trình thực nghiệm vì nhóm Scrum có thể điều chỉnh và sửa chữa các practice bằng cách sử dụng hướng dẫn thực tế nhất từ các thử nghiệm và báo lỗi

– Các bugs (lỗi) và các vấn đề trong mô hình Scrum được phát hiện sớm hơn rất nhiều so với các phương pháp truyền thống

– Chất lượng sản phẩm tốt và giảm rủi ro sản xuất, chi phí thấp. Khả năng trao đổi giữa khách hàng và nhà phát triển, giữa những thành viên trong đội được đặt lên mức cao.

Mô hình Agile Scrum mang lại lợi ích gì?

Agile Scrum đang ngày trở nên phổ biến và được sử dụng rộng rải bởi những nhà phát triển phần mềm. Vậy vì những lợi ích gì mà mô hình Agile Scrum lại được ưa chuộng như vậy?

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

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

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.

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.

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)

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

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

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.

Phương pháp Kanban là gì?

Kanban cũng là một công cụ được sử dụng để 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)

Scrum và Kanban khác nhau ở điểm gì?

  • Cả hai phương pháp Scrum và Kanban đề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.
  • Cả hai phương pháp thúc đẩy cải tiến liên tục, tối ưu hóa công việc và quá trình.
  • Cả 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

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. 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 là triết lý đằng sau và các ứng dụng thực tế của Scrum và Kanban. Có rất nhiều lí do khác nhau tuy nhiên có 3 điểm khác biệt lớn như sau:

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

Phương pháp Scrum đề cao tầm quan trọng về lịch trình. Các nhóm Scrum sẽ được cung cấp một danh sách ưu tiên của các task cần được hoàn thành, hoàn chỉnh chức năng và sẵn sàng chuyển giao (shippable) cho khách hàng. Các nhóm phải quyết định nhận task nào mà họ nhận thấy có thể được hoàn tất trong vòng một sprint.

Nhóm Kanban không có khung thời gian (time box) 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.

Bất kỳ hoặc tất cả các nhóm đều có thể tham gia dự án. Do đó, một nhóm chuyên gia hay một một riêng biệt đều có thể làm việc trên các khía cạnh khác nhau của dự án Kanban tương tự từ cùng một bảng Kanban.

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ờ

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. Tuy nhiên 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 (như sprint), 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.

Phương pháp nào tốt hơn?

Đây là một câu hỏi khó và không ai có thể trả lời câu hỏi này ngoài doanh nghiệp của bạn. Tùy vào nhu cầu, điều kiện và chiến lược riêng của từng doanh nghiệp để lựa chọn cho mình phương pháp Scrum hay Kanban.

Ngoài ra doanh nghiệp cũng có thể thử phương pháp Scrum-Kanban – 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.


Bạn đang xem chủ đề Phương Pháp Agile trên website Cuocthitainang2010.com. Hy vọng những thông tin mà chúng tôi đã chia sẻ là hữu ích với bạn. Nếu nội dung hay, ý nghĩa bạn hãy chia sẻ với bạn bè của mình và luôn theo dõi, ủng hộ chúng tôi để cập nhật những thông tin mới nhất. Chúc bạn một ngày tốt lành!