【#1】Sự Khác Biệt Giữa Phương Pháp Agile Và V (Model)

Phương pháp Agile vs V (Model)

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

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

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

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

Nhanh nhẹn là gì?

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

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

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

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

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

【#3】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

【#4】Sự Khác Biệt Giữa Phương Pháp Thác Nước Và Agile

Phương pháp thác nước vs Agile

Có một số phương pháp phát triển phần mềm khác nhau được sử dụng trong ngành công nghiệp phần mềm ngày nay. Phương pháp phát triển thác nước là một trong những phương pháp phát triển phần mềm sớm nhất. Phương pháp phát triển phần mềm thác nước là một mô hình tuần tự, trong đó, mỗi giai đoạn được hoàn thành đầy đủ và theo một thứ tự cố định. Mô hình Agile là một mô hình phát triển phần mềm gần đây được giới thiệu để giải quyết các thiếu sót được tìm thấy trong các mô hình hiện có. Trọng tâm chính của Agile là kết hợp thử nghiệm càng sớm càng tốt và phát hành phiên bản hoạt động của sản phẩm từ rất sớm, bằng cách chia nhỏ hệ thống thành các phần phụ rất nhỏ và có thể quản lý được.

Phương pháp thác nước là gì?

Phương pháp thác nước là một trong những mô hình phát triển phần mềm sớm nhất. Như tên cho thấy, đó là một quá trình tuần tự, trong đó tiến trình chảy qua một số giai đoạn từ trên xuống dưới, tương tự như một thác nước. Các giai đoạn của mô hình Waterfall là phân tích yêu cầu, thiết kế, phát triển, thử nghiệm và thực hiện. Ở đây, mỗi giai đoạn được hoàn thành đầy đủ trước khi chuyển sang giai đoạn tiếp theo. Mô hình này là kết quả trực tiếp của việc đơn giản thích ứng phương pháp phát triển định hướng phần cứng (được tìm thấy trong các ngành sản xuất và xây dựng), tại thời điểm đó không có mô hình chính thức để phát triển phần mềm.

Nhanh nhẹn là gì?

Agile là một phương pháp phát triển phần mềm rất gần đây dựa trên bản tuyên ngôn nhanh. Điều này đã được phát triển để giải quyết một số thiếu sót trong phương pháp phát triển phần mềm truyền thống. Các phương pháp nhanh nhẹn dựa trên việc ưu tiên cao cho sự tham gia của khách hàng sớm trong chu kỳ phát triển. Nó khuyến nghị kết hợp kiểm tra bởi khách hàng sớm và thường xuyên nhất có thể. Kiểm tra được thực hiện tại mỗi điểm khi có phiên bản ổn định. Nền tảng của Agile dựa trên việc bắt đầu thử nghiệm từ khi bắt đầu dự án và tiếp tục trong suốt đến cuối dự án.

Giá trị quan trọng của Agile là chất lượng của Wap là trách nhiệm của nhóm, điều này nhấn mạnh rằng chất lượng của phần mềm là trách nhiệm của cả nhóm (không chỉ nhóm thử nghiệm). Một khía cạnh quan trọng khác của Agile là chia nhỏ phần mềm thành các phần có thể quản lý nhỏ hơn và cung cấp chúng cho khách hàng rất nhanh. Cung cấp một sản phẩm làm việc là vô cùng quan trọng. Sau đó, nhóm tiếp tục cải tiến phần mềm và cung cấp liên tục ở mỗi bước chính. Điều này đạt được bằng cách có các chu kỳ phát hành rất ngắn gọi là chạy nước rút và nhận phản hồi để cải thiện vào cuối mỗi chu kỳ. Những người đóng góp không có nhiều tương tác của nhóm như nhà phát triển và người thử nghiệm trong các phương thức trước đó, giờ đây hoạt động cùng nhau trong mô hình Agile.

Sự khác biệt giữa Phương pháp thác nước và Agile là gì?

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

【#5】Tìm Hiều Phương Pháp Quản Lý Theo Agile

Agile là gì?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【#6】So Sánh Phương Pháp Scrum Và Kanban Trong Agile

Phương pháp Scrum

Định nghĩa về Scrum

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

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

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

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

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

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

Phương pháp Kanban

Định nghĩa về Kanban

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3. Bảng quản trị

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

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

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

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

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

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

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

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

【#7】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

【#8】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

【#9】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

【#10】So Sánh Các Phương Pháp Quản Lý Dự Án Phổ Biến Nhất Hiện Nay

“Quản lý dự án” nằm ở đâu trong bức tranh tổng thể của doanh nghiệp?

Cách đây ba năm, Hội đồng Quản trị của Siemens (Đức) triển khai một chương trình toàn cầu để cải tiến công tác quản lý dự án của mình. Tập đoàn điện tử này đã phát hiện rằng phân nửa doanh thu của mình xuất phát từ những hoạt động có tính chất giống dự án, và tính toán rằng nếu toàn bộ những dự án này có thể hoàn tất đúng hạn và đúng dự toán, lợi nhuận của hãng có thể tăng thêm 3 tỉ euro (3,7 tỉ đô-la Mỹ) trong ba năm. Họ nhận ra bất kỳ một mục tiêu, thay đổi hay cải tiến lớn nào trong tổ chức đều khó có thể hiện thực thành công nếu thiếu vai trò của quản lý dự án.

Chính xác là vậy! Quản lý dự án luôn đóng một vai trò không thể thiếu trong quản lý chiến lược toàn diện. Bất kỳ tổ chức nào cũng cần trang bị cho ban lãnh đạo và đội ngũ điều hành trong tổ chức những công cụ, phương pháp về quản lý dự án nhằm thực hiện các mục tiêu, sự cải tiến và sự thay đổi trong tổ chức.

Là một nhà quản lý, nếu bạn đang chuẩn bị đảm nhiệm những dự án có quy mô vừa và nhỏ (ví dụ như dự án của agency hoặc các dự án thuộc ngành dịch vụ, mô hình phát triển sản phẩm,…) thì không gì phù hợp với bạn hơn nội dung này.

I. Dự án và cách xác định quy mô dự án

II. Cách xác định phương pháp quản lý dự án phù hợp

III. Phân tích các phương pháp:

Định nghĩa

Ưu – nhược điểm

Phù hợp với loại dự án nào?

IV. Cách ứng dụng phương pháp quản lý

I. Dự án và cách xác định quy mô dự án

Dự án là gì?

Theo Viện Quản lý Dự án (PMI), Dự án là một nỗ lực tạm thời được thực hiện để tạo ra một sản phẩm, dịch vụ hay kết quả duy nhất.

Đặc điểm của một dự án

  • Có một hoặc một số mục tiêu rõ ràng: Thông thường người ta cố gắng lượng hoá mục tiêu thành ra các chỉ tiêu cụ thể. Mỗi dự án là một quá trình tạo ra một kết quả cụ thể. Nếu chỉ có kết quả cuối cùng mà kết quả đó không phải là kết quả của một tiến trình thì kết quả đó không được gọi là dự án.
  • Có một thời hạn nhất định: Nghĩa là phải có thời điểm bắt đầu và thời điểm kết thúc. Dự án được xem là một chuỗi các hoạt động nhất thời. Tổ chức của dự án mang tính chất tạm thời, được tạo dựng lên trong một thời hạn nhất định để đạt được mục tiêu đề ra, sau đó tổ chức này sẽ giải tán hay thay đổi cơ cấu tổ chức cho phù hợp với mục tiêu mới.
  • Sử dụng nguồn lực bị hạn chế. Nguồn lực gồm: nhân lực, nguyên vật liệu, ngân sách.

Thế nào là một dự án vừa và nhỏ?

Xác định quy mô dự án là điều đầu tiên trước khi bắt tay xây dựng kế hoạch và lựa chọn phương án quản lý phù hợp. Quy mô của dự án sẽ ảnh hưởng trực tiếp tới những trở ngại và khó khăn trong việc đạt được mục tiêu ban đầu của dự án, tuy nhiên, các dự án lớn không nhất thiết phải kéo theo sự phức tạp hay rắc rối. Như đã đề cập, bài viết này thích hợp với những dự án có quy mô vừa và nhỏ. Vậy làm thế nào để xác định được quy mô của một dự án?

II. Cách lựa chọn phương pháp quản lý dự án

Chọn phương pháp đúng rất quan trọng vì nó định hướng cách chúng ta tiếp cận mục tiêu ngay từ ban đầu – hay có thể nói, nó quyết định sự thành công hay thất bại của dự án. Thế nên đứng trước mỗi một dự án, việc dành thời gian để lựa chọn một phương pháp phù hợp với bối cảnh của mình là điều vô cùng quan trọng.

Ở phần này, chúng ta sẽ tìm cách hiểu đúng về định nghĩa “phương pháp quản lý dự án” và cách đi tìm phương pháp quản lý dự án hoàn hảo nhất.

Trước hết, quản lý dự án là gì?

Project Management – Quản lý dự án, theo Viện Quản lý Dự án (PMI) là việc áp dụng kiến thức, kỹ năng, công cụ, kỹ thuật vào các hoạt động của dự án, nhằm đáp ứng các yêu cầu chung của dự án. Việc Quản lý dự án được thực hiện thông qua ứng dụng phù hợp, tích hợp các quy trình quản lý được xác định cho dự án một cách hiệu quả.

Một phương pháp quản lý dự án là gì?

Theo PMI, phương pháp quản lý dự án là một hệ thống các thông lệ, kĩ thuật, phương thức và luật lệ được xây dựng và ứng dụng trong các bộ máy vận hành của doanh nghiệp. Mỗi hệ phương pháp quản lý dự án được xây dựng để phục vụ một mục tiêu chiến lược cụ thể của doanh nghiệp, nên chúng cũng có các cách tiếp cận khác nhau.

Đâu là phương pháp quản lý hoàn hảo nhất?

Chẳng phải việc so sánh các phương pháp quản lý và trả lời câu hỏi trên chính là mục đích chính của bài viết này hay sao?

Trước hết thì hãy nhớ lại: Một dự án nghĩa là gì?

Theo như những định nghĩa về dự án ở Phần I, việc trồng một vườn hoa cũng được coi là một dự án, vậy ta có thể áp dụng phương pháp Agile để quản lý nó hay không? Hay áp dụng các phương pháp quản lý rủi ro và chất lượng thì sao? Hoàn toàn có thể. Việc này thậm chí có thể áp dụng được với quy trình 6 Sigma. Tuy nhiên, phương pháp Waterfall lại có vẻ không phù hợp trong trường hợp này, đặc biệt là đối với sản phẩm đầu ra. Chúng ta vẫn có thể áp dụng được phương pháp này để trồng một vườn hoa, với điều kiện việc quản lý sự thay đổi đã được đưa vào trong quy trình.

Điều quan trọng là: “Phương pháp nào phù hợp với việc trồng hoa nhất?” chứ không phải “Phương pháp nào tốt nhất cho tất cả mọi dự án?”.

5 bước xác định phương pháp quản lý dự án

Bước 1: Xem xét độ phức tạp của các yếu tố trong dự án

Bao gồm dự án, khách hàng, các nguồn lực sẵn có và các ràng buộc của dự án, thời gian, công cụ và con người. Liệt kê các yếu tố này và đánh dấu chúng theo sự đơn giản hoặc phức tạp.

Bước 2: Độ linh hoạt của môi trường làm việc như thế nào?

Nếu đang quen làm việc trong một môi trường năng động, nơi luôn tìm kiếm sự thay đổi và phát triển – Agile sẽ dành cho bạn. Nếu thường làm việc cùngi các yêu cầu, kế hoạch, thời gian và ngân sách cố định, có thể sẽ hiệu quả hơn nếu bạn sử dụng Waterfall.

Bước 3: Điều gì mang lại nhiều giá trị nhất?

Bước 4: Mục tiêu của bạn là gì?

Rõ ràng, phương pháp quản lý chính là phương tiện để đưa bạn tới mục tiêu của dự án. Một phương pháp tốt là phương pháp giúp bạn đạt được mục tiêu chiến lược một cách trực tiếp nhất với nhiều lợi ích và ít tác động tiêu cực nhất.

Bước 5: Giá trị nào của doanh nghiệp mà bạn đề cao?

Đến cuối cùng thì một phương pháp vẫn phải được thực hiện bởi nhân viên của bạn – những người có ý kiến, giá trị hay thói quen. Thay vì tìm ra một phương pháp có vẻ như đang “hot” và ném nó cho nhân viên thực hiện, hãy sử dụng nguồn nhân lực sẵn có, cùng làm việc, thống nhất và xây dựng một phương pháp thích hợp, dựa trên năng lực thực tế chứ không phải những mớ lý thuyết – đó mới là điều bền vững và có thể duy trì lâu dài

III. Các phương pháp quản lý dự án phổ biến nhất hiện nay

Quản lý dự án là ngành khoa học nghiên cứu về việc lập kế hoạch, tổ chức và quản lý, giám sát quá trình phát triển của dự án, nhưng trên thực tế bạn đang quản lý con người. Vì vậy, mỗi phương pháp quản lý dự án nên được lựa chọn và áp dụng một cách cẩn thận đối với

từng loại dự án.

1. AGILE – Dự án nhanh nhẹn

Khái niệm Agile (viết tắt của Agile Software Development) có nghĩa là phương thức phát triển phần mềm linh hoạt, được ứng dụng trong quy trình phát triển phần mềm với mục tiêu là đưa sản phẩm đến tay người dùng càng nhanh càng tốt.

Rất nhiều nơi định nghĩa Agile như một phương pháp. Thực chất, Agile giống như một phương pháp luận, một triết lý dựa trên hơn nguyên tắc phân đoạn vòng lặp (iterative) và tăng trưởng (incremental).

Ngày nay, triết lí 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, dịch vụ, sales, marketing, giáo dục… và trở thành một phương thức quản lý dự án phổ biến nhất hiện nay với nhiều đại diện được gọi là các phương pháp “họ Agile”.

Ưu điểm của Agile:

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

Agile phù hợp với dự án như thế nào?

Agile phù hợp với các dự án đòi hỏi sự linh hoạt và có mức độ phức tạp hoặc không chắc chắn. Chẳng hạn, một sản phẩm hoặc dịch vụ chưa từng được nhóm xây dựng.

Agile được sinh ra trong lĩnh vực phát triển phần mềm. Các giai đoạn trong mô hình Agile phù hợp với phát triển và kiểm thử phần mềm. Tuy nhiên ngày nay, triết lí Agile đã vượt xa khỏi khu vực truyền thống của mình và đóng góp sự thay đổi trong cách thức làm việc, quản lí, sản xuất ở bất kỳ ngành công nghiệp hoặc kinh doanh nào như sản xuất, dịch vụ, sales, marketing, giáo dục và đạt được hiệu quả cao.

Tuy nhiên, không phải doanh nghiệp nào cũng phù hợp với mô hình Agile. Để áp dụng thành công mô hình này cần một số điều kiện tiên quyết trong tổ chức:

  • Thứ nhất, các thành viên phối hợp, giao tiếp hiệu quả trong nội bộ. Kỹ năng giao tiếp tốt giúp nhóm làm việc thấu hiểu khách hàng, hợp tác tốt với nhau đảm bảo chất lượng và tốc độ.
  • Thứ hai, tính tự chủ của mỗi thành viên phải được đảm bảo để các nhóm tự quản lý có thể vận hành một cách chủ động, trơn tru thay vì chỉ tuân thủ theo chỉ dẫn cấp trên như trong các mô hình truyền thống.
  • Thứ ba, các hoạt động được modul hóa thông qua những nhóm liên chức năng. Những nhóm này có khả năng làm việc với tốc độ và chất lượng cao, với khách hàng là trung tâm

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

Là một trong những mô hình quản lí dự án dễ hiểu và dễ quản lí nhất hiện nay, mô hình thác nước là phương pháp quản lí dự án dựa trên qui trình thiết kế tuần tự và liên tiếp.

Theo Waterfall, sau khi phạm vi dự án được xác định, các nhóm sẽ được phân công công việc với mục tiêu và lịch trình thực hiện cụ thể. Mỗi nhóm đảm nhiệm một phương diện hoặc một bộ phận của dự án. Các bộ phận này được vận hành tuần tự theo quy trình, các giai đoạn của dự án được thực hiện lần lượt và nối tiếp nhau, giai đoạn mới chỉ được bắt đầu khi giai đoạn trước nó đã được hoàn thành.

6 giai đoạn của quản lý dự án Waterfall

Ưu điểm của Waterfall:

  • Waterfall rất tuyệt vời nếu bạn có thể đưa ra một kế hoạch, quy trình chặt chẽ và những dự trù phát sinh ngay từ đầu.
  • Là phương pháp đơn giản, dễ sử dụng và dễ hiểu.
  • Quy trình thực hiện rõ ràng, phân phối dự án dễ và nhanh, dễ dàng phân bổ chi phí hợp lý.
  • Phù hợp với dự án nhỏ và không phát sinh nhiều yêu cầu mới trong quá trình triển khai
  • Dễ dàng quản lý và theo dõi tiến độ dự án đang đi đến đâu do mỗi giai đoạn đều có quá trình cụ thể, danh sách nhiệm vụ rõ ràng và kết quả nằm trong tầm dự đoán.

Nhược điểm của Waterfall:

  • Thích ứng kém: Thiếu sót quan trọng nhất của Waterfall là khả năng thích ứng trước thay đổi trong toàn bộ vòng đời phát triển. Nó không cho phép bạn đi lệch khỏi kế hoạch đã đặt ra. Đây là một vấn đề rất lớn khi các nhóm dự án 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.
  • Bỏ qua phản hồi người dùng ở các giai đoạn sau: Vì có một quá trình nghiêm ngặt từng bước một, Waterfall rất khó để xử lý các nhu cầu phát sinh của khách hàng trong khi dự án đã đi vào các giai đoạn triển khai thực hiện. Đương nhiên có thể đưa quá trình về các giai đoạn trước nhưng điều này sẽ vô cùng tốn kém và ngốn thời gian cho cả nhóm phát triển và khách hàng.
  • Thử nghiệm chỉ bắt đầu khi quá trình thực hiện kết thúc: Trong khi phần lớn các mô hình hiện đại luôn tích hợp kiểm thử là một phần tất yếu và luôn luôn xuyên suốt mọi quá trình trong quá trình phát triển, Waterfall để kiểm thử vào cuối vòng đời. Nếu bước đánh giá cuối cùng cho thấy dự án không hiệu quả, dễ là bạn sẽ phải làm lại tất cả từ con số 0.

Waterfall phù hợp với dự án như thế nào?

Phương pháp Waterfall phù hợp với các dự án lớn yêu cầu duy trì các giai đoạn và thời hạn nghiêm ngặt, hoặc các dự án đã được thực hiện nhiều lần mà cơ hội xảy ra phát sinh trong quá trình thấp. Đặc biệt phù hợp trong sản xuất và xây dựng tạo ra các sản phẩm vật lý và tuân theo các đơn đặt hàng lắp ráp chính xác, có thể dễ dàng áp dụng các kế hoạch từ các dự án trước đó vào công việc hiện tại với rất ít hoặc không cần điều chỉnh.

Việc áp dụng mô hình Waterfall được khuyến khích khi người thực hiện nắm rõ yêu cầu của dự án tốt nhất, đòi hỏi về tính rõ ràng và tính ổn định cao như:

  • Waterfall chỉ nên sử dụng khi mà đội dự án đã có kinh nghiệm làm việc, trình độ chuyên môn và kỹ thuật cao bởi mô hình này đòi hỏi sự chính xác ngay từ đầu.
  • Waterfall hợp với những dự án mà khách hàng xác định được yêu cầu cụ thể, chính xác ngay từ đầu và ít có khả năng thay đổi, loại bỏ được những yêu cầu mập mờ, không rõ ràng.
  • Đối với những khách hàng lớn mà phong cách làm việc của họ chủ yếu theo mô hình truyền thống hoặc những khách hàng lo ngại có nhiều thay đổi trong dự án.
  • Nắm vững được công nghệ và sự phát triển của công nghệ.

3. LEAN – Quản trị tinh gọn

Lean là một mô hình bao gồm các nguyên tắc và công cụ cải tiến có hệ thống, tập trung vào việc tạo giá trị từ góc nhìn của khách hàng và loại bỏ những lãng phí trong quá trình sản xuất hoặc cung cấp dịch vụ của một tổ chức.

Lean là một triết lý làm việc hơn là một phương pháp – tập trung vào loại bỏ lãng phí (bất cứ thứ gì không mang lại giá trị), cải tiến hệ thống, học hỏi và tính toàn vẹn của quy trình. Lean giúp tăng khả năng sử dụng các nguồn lực, rút ngắn thời gian chu trình sản xuất và cung cấp dịch vụ nhằm cung cấp sản phẩm, dịch vụ đáp ứng yêu cầu của khách hàng mà không có bất kỳ sự lãng phí nào thông qua cải tiến liên tục quá trình.

5 nguyên lý của Lean:

  • Giá trị: Giá trị (sản phẩm/dịch vụ) là do nhà sản xuất tạo ra – từ quan điểm của khách hàng. Trong Lean, nếu bạn xác định sai giá trị, tức là cung cấp sản phẩm/dịch vụ “sai” so yêu cầu của khách hàng, thì đó là Lãng phí. Kể cả việc bạn sản xuất/cung cấp sản phẩm/dịch vụ nhiều hơn so với mức yêu cầu của khách hàng cũng là lãng phí (thừa).
  • Chuỗi giá trị: Chuỗi giá trị là một quá trình bao gồm những hành động cần thiết để đưa một sản phẩm/dịch vụ nào đó tới tay khách hàng. Mục đích của bước này là để xác định từng khâu, từng bước trong chuỗi giá trị xem hoạt động nào tạo ra giá trị và hoạt động nào là lãng phí cần loại bỏ.

Quá trình này đi qua 3 nhiệm vụ quản trị thiết yếu của bất kỳ một doanh nghiệp nào:

– Giải quyết vấn đề của khách hàng: Từ ý tưởng cho đến thiết kế và công nghệ để đưa vào sản xuất.

– Quản lý thông tin: Từ nhận đơn hàng cho đến lập kế hoạch giao hàng chi tiết.

– Chuyển hóa vật chất: Từ nguyên liệu đầu vào đến sản phẩm/dịch vụ hoàn thiện tới tay khách hàng.

  • Dòng chảy: Sau khi loại bỏ các lãng phí ra khỏi Chuỗi giá trị, việc tiếp theo là đảm bảo các hoạt động còn lại trong chuỗi giá trị được lưu thông suôn sẻ mà không bị gián đoạn, trì hoãn hay tắc nghẽn. Điều này tạo ra một dòng chảy liên tục nhằm đảm bảo sản phẩm/dịch vụ đến tay khách hàng nhanh nhất có thể.
  • Kéo: Ví dụ trong sản xuất, khách hàng đặt hàng và bạn chỉ sản xuất vừa đúng theo đơn đặt hàng đó thì gọi là sản xuất theo nguyên lý “kéo”. Kéo – tức là khách hàng kéo bạn thông qua đơn đặt hàng – và bạn làm theo đúng yêu cầu đó. Nguyên lý kéo đem lại cho bạn một khoản tiền thông qua việc giảm hàng tồn kho và đẩy nhanh tốc độ thu hồi vốn đầu tư, đây có phải là một thành tựu mang tính cách mạng? Thật ra, đó là do khả năng thiết kế, lập kế hoạch và sản xuất/cung cấp chính xác những gì mà khách hàng cần vào đúng lúc họ muốn.

Ưu điểm của Lean:

  • Giảm chi phí tồn kho: Giảm thiểu chi phí tồn kho của các nguyên liệu thô đầu vào, bán thành phẩm và thành phẩm. Hơn nữa khi mua ít nguyên liệu thô, doanh nghiệp sẽ chi ít tiền hơn để thuê nhà kho, ít nhân công để quản lí.
  • Tăng năng suất và tính linh hoạt: Công nhân sẽ di chuyển từng bộ phận ngay khi hoàn thành thay vì chờ chuyển từng lô, giúp gia tăng năng suất và tính linh hoạt trong quy trình. Ngoài ra còn giúp doanh nghiệp giảm thiểu thời gian sản xuất để nhanh chóng đáp ứng nhu cầu của khách hàng
  • Loại bỏ hao phí : Tìm cách loại bỏ hao phí dưới mọi hình thức, chẳng hạn như chuyển động thừa, hàng tồn kho và thời gian chờ. Lean giúp loại bỏ các nút thắt gây lãng phí thời gian trong dây chuyền sản xuất.
  • Cải thiện chất lượng: Loại bỏ hao phí bằng cách giảm thiểu số lượng sản phẩm lỗi. Dây chuyền di chuyển từng bộ phận cho phép công nhân xác định những bộ phận lỗi trước khi số lượng lớn sản phẩm được sản xuất. Lean đưa ra quy trình sản xuất theo mô hình work cell – hoàn thành tất cả các hoạt động sản xuất một sản phẩm trong một khu vực.
  • Động viên tinh thần làm việc của nhân viên: Khi ứng dụng chiến lược Lean thành công, người lao động sẽ được trao quyền tham gia vào cải tiến chất lượng sản phẩm, điều đó thúc đẩy tinh thần cống hiến trong họ.
  • Cải thiện sự tương tác với khách hàng: Luôn giao tiếp với khách hàng, đáp ứng các mối quan tâm và trải nghiệm của họ với sản phẩm là một trong những động lực hàng đầu trong việc cắt giảm các lãng phí.

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

  • Vấn đề cung ứng: Bởi vì chỉ có một số lượng nhỏ của hàng tồn kho được dự trữ, Lean phụ thuộc rất nhiều vào các nhà cung ứng nhằm tránh gây gián đoạn. Nếu một trong các nhà cung ứng gặp vấn đề như không chấp nhận giao hàng số lượng ít hoặc tuân theo quy trình quá khắt khe hay những sự cố ngoài ý muốn xảy ra thì buộc toàn bộ dây chuyền phải dừng lại. Những vấn đề này tạo nên gánh nặng về chi phí và tạo ra những căng thẳng mà cuối cùng ảnh hưởng đến quá trình sản xuất hay thậm chí là phải thường xuyên thay đổi nhà cung ứng hoặc khó khăn để tìm ra nhà cung ứng phù hợp với lịch trình của doanh nghiệp.
  • Chi phí vận hành cao: Khi ứng dụng Lean có nghĩa là hoàn toàn tháo dỡ các thiết bị, hệ thống cũ ở nhà máy trước đó. Chi phí đào tạo nhân lực cao và kéo dài, chi phí thuê các nhà quản lý có kinh nghiệm cao hơn bình thường, vốn đầu tư mua máy móc thiết bị không nhỏ và các thiết lập của mô hình work cell được tính vào nợ dài hạn.
  • Thiếu sự đồng thuận của nhân viên: Lean thường đòi hỏi đại tu toàn bộ hệ thống sản xuất và có thể nhân viên từ chối vì họ thích cách làm cũ hơn. Hơn nữa, Lean đòi hỏi nhân viên phải liên tục kiểm soát chất lượng nhưng một số nhân viên sẽ thấy không hứng thú hoặc không đủ tiêu chuẩn để làm. Những nhân viên lớn tuổi có thể thích phương pháp trước đó và gây cản trở những người khác làm việc.
  • Khách hàng không hài lòng: Bất cứ gián đoạn nào chuỗi cung ứng đều ảnh hưởng đến khách hàng. Giao hàng trễ hay trì hoãn cũng là vấn đề cần được chú trọng xử lý trong quy trình này

Lean phù hợp với dự án như thế nào?

Một quan niệm phổ biến là Lean chỉ phù hợp với các doanh nghiệp sản xuất. Quan niệm này đã lỗi thời. Do bản chất là tập trung vào việc loại bỏ các lãng phí cùng với nỗ lực để tạo thêm giá trị cho khách hàng, nên phạm vi các đối tượng tổ chức có thể áp dụng Lean đã vượt ra khỏi ranh giới các ngành công nghiệp sản xuất truyền thống để mở rộng ra các lĩnh vực cung cấp dịch vụ, ví dụ chăm sóc sức khỏe, bán lẻ, du lịch, ngân hàng, văn phòng, bệnh viện, ngay cả các tổ chức phi lợi nhuận và chính phủ cũng áp dụng quản trị tinh gọn

Lean đã trở thành một thuật ngữ quản trị toàn cầu, được các doanh nghiệp trên toàn thế giới ứng dụng. Bạn có thể đã biết hoặc từng nghe nói đến các công cụ trong lean, như: 5S, Kaizen, Just in time, quản trị trực quan…

  • Hàng tồn kho tích lũy trong dự trữ bình ổn (buffer stocks)
  • Sản phẩm đang sản xuất (Work-in-process) bị tồn kho
  • Dòng chảy thông tin và chất lượng thông tin kém
  • Hiếm khi đạt được mục tiêu sản xuất
  • Nhiều chi phí phát sinh
  • Dịch vụ chăm sóc khách hàng kém
  • Dự đoán doanh thu sai lệch nhiều
  • Hồ sơ hàng tồn kho, thông số kỹ thuật sản phẩm, vận chuyển tài liệu có sai sót
  • Các nhà cung cấp trong chuỗi cung ứng có chất lượng sản phẩm thấp hoặc thanh toán chậm .
  • Tồn kho dư thừa một số nguyên vật liệu nhưng lại thiếu những nguyên liệu cần thiết khác
  • Chu kì sản xuất dài
  • Thủ tục hành chính quá phức tạp và phiền toái
  • Những khâu không cần thiết xuất hiện thường xuyên trong quy trình
  • Nhiều khách hàng chưa được giao hàng (backorders)
  • Di chuyển sản phẩm không cần thiết
  • Duy trì những khu vực khác để làm nơi chứa hàng tồn kho
  • Container còn nhiều không gian trống hoặc sản phẩm bị hư hại trong quá trình vận chuyển
  • Nhân việc làm việc riêng trong giờ làm việc hoặc làm những việc không mang lại giá trị cho doanh nghiệp

4. SCRUM – Quản lý dự án nước rút

Scrum xuất phát là một quy trình phát triển phần mềm theo Agile. Vì thế, nó tuân thủ các nguyên tắc của Agile.

Scrum là một khung quản lý dự án được áp dụng rất rộng rãi, bao gồm những dự án đơn giản với một nhóm phát triển nhỏ cho đến những dự án có yêu cầu rất phức tạp và kể cả những dự án đòi hỏi khung thời gian cố định.

Phương pháp Scrum là bộ khung làm việc 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à được hoà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 để theo dõi công việc của từng thành viên trong nhóm (luồng chảy công việc – flow of work).

Các đặc điểm của Scrum

Ưu điểm của Scrum:

  • Các thành viên trong nhóm có một bức tranh rõ ràng hơn về nhiệm vụ của họ. Họ biết phải làm gì và bất kỳ câu hỏi nào có thể được giải quyết trong lần chạy nước rút tiếp theo của họ.
  • Các dự án lớn được chia thành các phần nhỏ hơn để dễ quản lý và hoàn thành.
  • Scrum là một khung có thể giúp bạn quản lý dự án của bạn hiệu quả hơn và sử dụng thời gian và ngân sách tốt hơn.
  • Scrum là sự đảm bảo tính minh bạch của tất cả các giai đoạn của dự án.
  • Một trong những nguyên tắc của Scrum là tập trung vào việc giảm thiểu lỗi. Nhờ cách tiếp cận này (ví dụ như chạy nhiều thử nghiệm), bạn có thể chắc chắn rằng dự án được duy trì ở mức chất lượng cao nhất.
  • Scrum là một phương pháp rất linh hoạt. Nếu khách hàng muốn thực hiện bất kỳ thay đổi hoặc mở rộng sản phẩm với các chức năng mới, thường thì không có vấn đề gì với điều đó. Loại đàn hồi này được đảm bảo bằng nước rút.
  • Các cuộc họp hàng ngày giúp xác định các mối đe dọa và vấn đề mới nổi có thể được giải quyết nhanh chóng.
  • Scrum phù hợp với ngân sách, có thể thường xuyên kiểm soát tất cả các chi phí.

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

  • Scrum phụ thuộc vào việc có những người lao động có năng lực, tận tâm và sẵn sàng làm việc như một phần của một nhóm. Thành công của dự án của bạn có thể gặp rủi ro nếu một thành viên trong nhóm không tham gia hoặc làm công việc của một người chậm hơn những người khác.
  • Vai trò Scrum Master rất quan trọng. Nếu họ không thực hiện nhiệm vụ của mình một cách chuẩn chỉnh có thể dẫn đến sự chậm trễ trong dự án.
  • Scrum thường chỉ lý tưởng cho các nhóm 3-9 người. Với các nhóm dự án lớn hơn có thể gặp vấn đề về hiệu quả quản lý.
  • Các cuộc họp hàng ngày có thể gây khó chịu cho các thành viên trong nhóm.
  • Sự ra đi bất ngờ của một thành viên trong nhóm có thể gây tổn hại cho tiến độ của toàn bộ dự án.
  • Ngày giao sản phẩm và giới hạn thời gian chạy nước rút sẽ không áp dụng cho Scrum.

Scrum phù hợp với dự án như thế nào?

Scrum – từng đạt được nhiều thành tựu trong giới phát triển phần mềm – ngày nay đã được biến đổi linh hoạt để hoạt động với gần như bất kỳ thiết kế hoặc dự án sản phẩm phức tạp nào và được áp dụng trong nhiều tập đoàn lớn, các công ty đa quốc gia, cả các doanh nghiệp vừa và nhỏ. 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.

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. Những người sử dụng Scrum nhiều nhất là các nhà quản lý và trưởng nhóm phụ trách một số nhóm hoặc phòng ban; tức là những người có đầu được phục vụ cho các cổ đông nếu dự án không hoàn thành thành công.

Scrum vượt xa mô hình chỉ huy và kiểm soát quản lý tiêu chuẩn, và thay vào đó là một vai trò lãnh đạo tích cực. Người lãnh đạo của một đội sử dụng Scrum không giống như một huấn luyện viên đứng và chỉ đạo bên lề, và giống như đội trưởng trong trò chơi nhiều như mọi người khác.

5. KANBAN – Bảng và thẻ

Theo dịch nghĩa tiếng Nhật, Kanban là có nghĩa là thẻ thị giác (với từ kan là thị giác và từ ban là thẻ). 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.

Các yếu tố tạo nên Kanban:

  • Bảng Kanban : Là bảng chứa những việc cần làm của một dự án hoặc quy trình làm việc, trong công cụ quản lý truyền thống thì đây là “dự án” hoặc “không gian làm việc”.
  • Danh sách Kanban: Một danh sách chứa một tập hợp các thẻ, thường là những thẻ trong cùng một giai đoạn của quy trình; công cụ quản lý dự án truyền thống gọi đây là “danh sách việc cần làm” hoặc “danh sách công việc”.

Những nguyên lý nền tảng của Kanban:

Ưu điểm của Kanban:

  • Mọi người đều ở trên cùng một mặt phẳng: Tất cả các nhiệm vụ đều dễ dàng nhìn thấy, điều này mang lại sự minh bạch cho toàn bộ quá trình làm việc. Mỗi thành viên có thể cập nhật nhanh về trạng thái của mọi dự án hoặc nhiệm vụ.
  • Giảm trực tiếp chi phí và lãng phí: Hệ thống Kanban cải thiện lưu lượng và quản lý hàng tồn kho bằng cách trực tiếp hỗ trợ công ty theo đuổi các hệ thống hiện có của công ty, đảm bảo vận hành hàng tồn kho trơn tru hơn.
  • Kanban tiết lộ những vướng mắc trong quy trình làm việc: Khi bạn xây dựng một bảng kanban và bạn lấp đầy nó với các thẻ, bạn sẽ thấy rằng một số cột sẽ bị quá tải với các nhiệm vụ. Điều này sẽ giúp bạn làm nổi bật các tắc nghẽn trong quy trình làm việc của bạn và giải quyết chúng đúng cách.
  • Hệ thống đơn giản, dễ hiểu: Kanban đặc biệt linh hoạt ở chỗ có thể dễ dàng sử dụng ở bất kỳ đội nhóm trong ngành nghề hay quy mô nào vì nó dễ sử dụng.
  • Hệ thống phản ứng nhanh nhạy: Kanban giúp chúng ta dễ dàng đáp ứng các yêu cầu thay đổi liên tục của khách hàng. Nó cho phép thay đổi các ưu tiên, tổ chức lại hoặc chuyển nhiệm vụ trọng tâm thực sự nhanh chóng.
  • Yêu cầu tập trung vào các nhiệm vụ hiện tại cho đến khi hoàn thành: Điều này có thể nhờ vào khái niệm giới hạn công việc đang xử lý. Giới hạn WIP thúc đẩy các nhóm cộng tác để hoàn thành các mục công việc nhanh hơn, mặt khác giúp loại bỏ các phiền nhiễu như đa nhiệm.

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á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.
  • Không có khung thời gian của từng giai đoạn: Vì các cột chỉ được gắn nhãn với các giai đoạn (phải thực hiện, đang thực hiện, hoàn thành), nên có thể khó thấy khi nào mọi việc sẽ được thực hiện.
  • Phải cập nhật bảng: Các nhóm phải nhấn mạnh tầm quan trọng của việc cập nhật bảng, nếu không, họ có nguy cơ làm việc với thông tin không chính xác.
  • Đầu ra có thể không đảm bảo chất lượng: Kanban hoạt động giống như một cấu trúc giám sát giúp cho các luồng công việc trôi chảy hơn. Nếu bất kỳ công việc nào được thực hiện là không thỏa đáng, yêu cầu làm lại có thể làm tình hình tồi tệ hơn vì đòi hỏi nhiều thời gian và nguồn lực hơn để hoàn thành.

Kanban phù hợp với dự án như thế nào?

Mặc dù ban đầu được thành lập trong các ngành công nghiệp hàng hóa vật chất, nhưng hiện nay khung làm việc Kanban được yêu thích trong rất nhiều ngành nghề bởi mô hình đơn giản giúp cải tiến liên tục.

Kanban phù hợp nhất trong các dự án mà mức độ ưu tiên dao động ở mức độ cao, thậm chí mỗi ngày. Tuy nhiên, bạn nên xem xét các yếu tố sau khi đánh giá liệu Kanban có phải là phương pháp phù hợp với nhóm của bạn không:

  • Cần một hệ thống linh hoạt để thêm hoặc xóa các mục khi trong quá trình làm việc mà có thay đổi trong thời gian ngắn.
  • Dự án của bạn nhấn mạnh nhiều về quy trình làm việc liên tục hơn là những thời hạn hoàn thành đơn lẻ và quan trọng.
  • Không có nhiều áp lực về thời gian hoàn thành.
  • Cần cải tiến liên tục trong quá trình làm việc.
  • Bạn muốn nhóm có khả năng báo cáo kết quả bất cứ lúc nào.
  • Nhóm của bạn thích cải thiện gia tăng các quy trình hiện có hơn là áp đặt một hệ thống mới triệt để.
  • Hệ thống hiện tại dễ hiểu để áp dụng Kanban.
  • Ưu tiên hàng đầu là đáp ứng nhu cầu của khách hàng.
  • Đang gặp phải tồn đọng do công việc bị đình trệ, quy trình cơ bản đã ổn định nhưng hoạt động cần mượt mà và hiệu quả hơn.

6. 6 SIGMA – Quản lý chất lượng dự án

6 Sigma (Six Sigma, hay 6σ) là một hệ phương pháp cải tiến quy trình kinh doanh và quản lý chất lượng.

6 Sigma đo lường các khả năng gây lỗi chứ không phải các sản phẩm bị lỗi. Mục đích của 6 Sigma là cải thiện các quy trình để ngăn những vấn đề và lỗi xảy ra thay vì chỉ tìm ra các giải pháp ngắn hạn hoặc tạm thời để giải quyết vấn đề.

Hệ phương pháp này đem tới một tư duy mới cho các doanh nghiệp: thay vì tập trung vào xử lý các sản phẩm lỗi, hãy đầu tư cải thiện quy trình để ngăn lỗi xảy ra, tạo lập sự ổn định gần như hoàn hảo trong quá trình sản xuất và hoạt động kinh doanh.

6 Sigma sử dụng phương pháp thống kê để đếm số lỗi phát sinh trong một quá trình, sau đó tìm ra cách để khắc phục, đưa nó tới càng gần mức “không lỗi” càng tốt ở ngay công đoạn đầu tiên. Chỉ khi nào một quy trình không tồn tại hơn 3,4 lỗi trên mỗi một triệu cơ hội (sản phẩm), nó mới đạt được mức tiêu chuẩn của 6 Sigma.

Đặc trưng của 6 Sigma:

  • Tập trung vào lợi nhuận tài chính có thể đo lường và định lượng.
  • Lãnh đạo rất quan trọng.
  • Dữ liệu và số liệu thống kê là cơ sở của việc ra quyết định thay vì các giả định hoặc phỏng đoán.

Các giai đoạn của 6 Sigma:

Năm 2011, tổ chức Tiêu chuẩn hóa quốc tế ISO đã xuất bản Bộ tiêu chuẩn các phương pháp định lượng 6 Sigma nhằm nâng cao quy trình hoạt động. Quản lý chất lượng dự án theo Six Sigma dựa trên hai phương pháp của chu trình Kế hoạch – Thực hiện – Kiểm tra – Tác động do giáo sư Deming đưa ra. Những phương pháp này kết hợp 5 giai đoạn khác nhau, viết tắt là DMAIC và DMADV:

  • DMAIC sử dụng cho các dự án nhằm nâng cao chất lượng của những quá trình kinh doanh đã có.
  • DMADV sử dụng cho các dự án nhằm tạo ra sản phẩm mới hoặc quá trình thiết kế mới.

Ưu điểm của 6 Sigma:

  • Giảm thiểu và loại bỏ lãng phí: Các dự án 6 Sigma mang lại rất nhiều lợi ích về kinh tế thông qua việc nhận diện và loại bỏ các lãng phí trong công việc, các nguồn lực sử dụng không hợp lý, vật tư quá định mức, cải tiến phương pháp quản lý… Khi các quy trình làm việc được phân tích dưới góc độ chi phí, giá trị gia tăng từ quan điểm của khách hàng, các lãng phí sẽ đồng thời được nhận diện và loại bỏ, từ đó trực tiếp mang lại lợi ích cho doanh nghiệp.
  • Giảm thiểu lỗi và chi phí sửa hàng: Sản phẩm lỗi, chất lượng kém là nguyên nhân gây ra nhiều chi phí phát sinh sau này. Các chi phí có thể bao gồm thời gian, nhân lực, nguyên vật liệu, uy tín công ty… Việc áp dụng các dự án 6 Sigma giúp giảm thiểu các chi phí này thông qua việc cải tiến quy trình và chất lượng sản phẩm.
  • Xây dựng ổn đinh hệ thống quản lý doanh nghiệp: Để đạt được mục tiêu 3,4 lỗi trên một triệu cơ hội của tiêu chuẩn 6 Sigma, doanh nghiệp cần phải xây dựng cho mình một hệ thống quản lý quy chuẩn hoàn chỉnh hơn.
  • Giảm thiểu lỗi của con người và sự phụ thuộc vào con người: Một trong những lợi ích lớn nhất đạt được là giảm được chi phí nhân công thông qua việc tăng năng suất và giảm thiểu các công việc lãng phí do sản phẩm lỗi gây ra, ngoài ra còn giảm thiểu hoặc loại bỏ sự phụ thuộc vào các nhân sự có kỹ năng cao.
  • Xây dựng và phát triển nguồn nhân lực: Áp dụng hệ phương pháp 6 Sigma đòi hỏi phải có một nguồn nhân lực có kiến thức về hoạt động của công ty cũng như được đào tạo về cách thực hiện. Nguồn nhân lực vững mạnh sẽ là cơ sở để doanh thực hiện nhiều hơn những kế hoạch cũng như mục tiêu tham vọng hơn nữa.
  • Gia tăng sự hài lòng của khách hàng: Quyết định áp dụng 6 sigma cũng có nghĩa công ty đã nói không với việc để sản phẩm kém chất lượng đến tay khách hàng. Rât nhiều công ty không chỉ đạt được lợi ích về việc cắt giảm chi phí, mà lợi ích thông qua việc thị phần của họ gia tăng đáng kể do khách hàng tin tưởng sản phẩm của các công ty có áp dụng các chương trình cải tiến như 6 Sigma.

Nhược điểm của 6 Sigma:

  • 6 Sigma chú trọng cải tiến chất lượng chứ không cố gắng cắt giảm chi phí. Để đạt được 6 Sigma thường đòi hỏi thiết bị tốt hơn, đầu tư vào máy móc hệ thống kiểm tra được cải thiện, kiểm tra chất lượng hơn và dung sai chặt chẽ hơn. Điều này có thể tiêu thụ rất nhiều tài nguyên.
  • Không thích hợp trong các lĩnh vực ít lợi nhuận vì muốn đạt được các tiêu chuẩn chất lượng của 6 Sigma cần rất nhiều thời gian và chi phí.
  • 6 Sigma nhấn mạnh vào sự cứng nhắc của quy trình, về cơ bản mâu thuẫn với sự đổi mới và giết chết sự sáng tạo. Những cách tiếp cận sáng tạo như là một vài sai lệch trong sản xuất, sự dư thừa, các giải pháp bất thường, nghiên cứu không đầy đủ đều đi ngược với nguyên tắc 6 Sigma.
  • Dự án 6 Sigma đòi hỏi lực lượng nhân lực có tay nghề cao. Việc kiểm soát chất lượng và nâng cao năng lực của nhân viên yêu cầu phải được thực hiện thường xuyên.
  • Mặc dù phán đoán được các sai lầm, việc chuyển đổi các khái niệm lý thuyết thành ứng dụng thực tế có rất nhiều rào cản thời gian thực cần được giải quyết.

6 Sigma phù hợp với dự án như thế nào?

Các phương pháp quản lý dự án truyền thống được sử dụng rộng rãi và áp dụng trong tất cả các lĩnh vực và loại hình kinh doanh. Trong khi đó, phương pháp 6 Sigma ngày càng trở nên phổ biển hơn giữa các công ty có xu hướng tìm giải pháp kết hợp giữa phương pháp có thể cải tiến chất lượng mạnh mẽ với một quy trình quản lý dự án hợp lý.

Trước tiên để biết dự án có phù hợp với 6 Sigma hay không, bạn hãy đặt câu hỏi: “Mục đích của dự án là gì và phương pháp quản lý có thể giúp gì cho dự án của bạn?”. Nhớ rằng, 6 Sigma có thể làm được những điều này đối với dự án:

  • Xác định nguyên nhân gây ra vấn đề cản trở sự thành công của mục tiêu.
  • Sử dụng dữ liệu hiệu quả hơn để tăng hiệu quả và năng suất
  • Tăng sự hài lòng của khách hàng và nhân viên
  • Có nhu cầu nâng cao khả năng cạnh tranh thông qua loại bỏ lãng phí, rút ngắn thời gian sản xuất/ cung cấp dịch vụ và nâng cao chất lượng sản phẩm.
  • Thiết kế một quy trình mới hoặc thiết kế lại một quy trình không hiệu quả.

Phương pháp quản lý 6 Sigma phù hợp với các dự án:

  • Yêu cầu một quy trình cơ bản và thống nhất, không có nhiều thay đổi khi làm việc.
  • Dự án chú trọng quy trình chứ không phải về các mối quan hệ.
  • Đang gặp khó khăn trong quá trình sản xuất, kinh doanh do chi phí đầu vào tăng cao, giá bán giảm, cần tái cấu trúc hoạt động.
  • Sẵn sàng tiêu tốn thời gian và kinh phí để sửa chữa nếu phát hiện lỗ hổng trong quy trình, đầu tư máy móc thiết bị nếu cần thiết – tất cả phục vụ cho sự lâu dài.
  • Đội ngũ lãnh đạo và nhân viên có chuyên môn cao vì sự phức tạp trong triển khai, để dự đoán lỗi, sửa chữa quy trình và kiểm soát chất lượng sản phẩm.

IV. Làm thế nào để ứng dụng “chuẩn” phương pháp quản lý trong thời đại 4.0?

Khi đã lựa chọn cho dự án của mình một phương pháp quản lý thích hợp, bước tiếp theo của nhà quản lý là ứng dụng nó vào thực tế – chúng ta đều biết điều này là không hề đơn giản.

Và công cụ mà bất kỳ nhà quản lý thức thời nào cũng tìm đến nếu không muốn bị bỏ lại không gì khác chính là phần mềm quản lý dự án – các ứng dụng đem tới lợi thế tốc độ, năng suất vượt trội cho doanh nghiệp, và là trợ thủ đắc lực cho các nhà quản trị hiện đại.

Vì sao các nhà quản lý thức thời lại tìm đến phần mềm quản lý doanh nghiệp để hỗ trợ mình?

1. Nền tảng All-in-one:

Phần mềm quản lý dự án là một nền tảng all-in-one (tất cả trong một), ở đó các đội ngũ có thể lên kế hoạch cho dự án, phân công nhiệm vụ, theo dõi tiến trình công việc, quản lý thời gian, phân bổ tài nguyên, giao tiếp & hợp tác, và lưu trữ tài liệu, v..V. Các công ty cần phải nhất quán và theo dõi mọi khía cạnh của dự án trên một nền tảng duy nhất.

2. Khả năng dự báo:

Khi các dự án gần như hoặc thực sự vượt quá ngân sách và/hoặc thời hạn, hầu hết các công cụ sẽ cảnh báo cho công ty về các rủi ro, và giúp tối ưu hóa quá trình ra quyết định bằng cách đề xuất cách giải quyết để công ty có thể nhanh chóng sửa sai trước khi quá muộn.

3. Toàn cảnh:

Một trong những lợi thế lớn nhất nằm ở khả năng theo dõi và kiểm soát dự án từ quá trình lên kế hoạch cho tới giai đoạn kết thúc. Biết được phần của mình có khớp với tổng thể kế hoạch hay không, hay dự án có khớp với chiến lược công ty đề ra ban đầu hay không sẽ góp phần thúc đẩy mọi người hoàn thành nhiệm vụ nhanh hơn và hiệu quả hơn, thậm chí còn có thể ngăn chặn tình trạng vượt ngoài phạm vi dự án

4. Tăng cường hợp tác và trao đổi:

Các cá nhân có thể sử dụng công cụ giao tiếp tích hợp trong phần mềm để hợp tác xử lý vấn đề với những quản lý dự án cũng như các thành viên trong nhóm trong thời gian thực. Tất cả các thành viên trong nhóm đều có thể nhanh chóng truy cập vào ứng dụng, được cập nhật và nhanh chóng đối phó khi có vấn đề phát sinh.

5. Tương tác với khách hàng:

6. Trực quan và thông minh:

Tương tự những giải pháp công nghệ khác, phần mềm kỹ thuật số này được tạo ra để đơn giản hóa quá trình vận hành kinh doanh. Chúng phù hợp với tất cả mọi người, đặc biệt là lực lượng lao động am hiểu công nghệ, giúp tiết kiệm thời gian, công sức, giảm thiểu rủi ro và tối đa hóa năng suất và hiệu suất làm việc.

Nhược điểm của những công cụ này là gì?

Ưu điểm của việc sử dụng các phần mềm quản lý dự án là vô tận. Chúng là một trong những công cụ cực kỳ hữu ích mang lại cho công ty lợi thế cạnh tranh cùng cơ hội trở nên nổi bật hơn so với các đối thủ của mình. Tuy nhiên còn có những khía cạnh khác cần phải xem xét, tùy thuộc vào nhu cầu và ưu tiên của công ty.

Làm thế nào để đánh giá một phần mềm quản lý dự án?

Luôn có một mối quan hệ mật thiết giữa công cụ và kỹ thuật quản lý của nhà quản lý dự án. Chọn đúng cả phương pháp và công cụ hỗ trợ là nhiệm vụ hàng đầu của một nhà quản lý mỗi khi đứng trước một dự án.

Những tiêu chí cơ bản sau sẽ giúp bạn có một vài đánh giá sơ bộ xem liệu phần mềm này có phù hợp với tính chất dự án và đội nhóm của mình không, tất nhiên tùy vào mức độ phức tạp mà bạn có thể tự thêm những tiêu chí khác:

  • Giao diện người dùng: Nó có được thiết kế rõ ràng, dễ hiểu và điều hướng trực quan không?
  • Khả năng sử dụng: Phần mềm có dễ học không? Công ty cung cấp có đào tạo, hướng dẫn, hỗ trợ người dùng và công nghệ không?
  • Tính năng và chức năng: Nó có cung cấp các tính năng quản lý dự án chính như quản lý tác vụ, công cụ lịch biểu, báo cáo, phân quyền sử dụng, chia sẻ tệp, công cụ cộng tác không?
  • Tích hợp: Nó có dễ dàng đồng bộ hóa với các công cụ kinh doanh khác không?
  • Chi phí: Với những tính năng và dịch vụ đi kèm thì chi phí của nó có hợp lý không?

Một số phần mềm quản lý dự án phổ biến hiện nay

Giữa thời thế công nghệ lên ngôi, thị trường cạnh tranh khốc liệt, các phần mềm quản lý công việc ra đời đem tới lợi thế tốc độ, năng suất vượt trội cho doanh nghiệp, và là trợ thủ đắc lực cho các nhà quản trị hiện đại.

Trên thị trường có khá nhiều cái tên nổi bật như Trello, Asana, Wrike, Jira,… nhưng để các doanh nghiệp lựa chọn được một giải pháp hữu ích và phù hợp thì còn phải cân nhắc nhiều yếu tố bởi vì mỗi phần mềm lại có những ưu và nhược điểm khác nhau, phù hợp với tùy doanh nghiệp và dự án.

Một công cụ quản lý dự án lý tưởng trong thời đại 4.0 phải là một công cụ có thể linh hoạt ứng dụng các mô hình quản lý, giúp giải quyết triệt để hầu hết các bài toán mà doanh nghiệp gặp phải trong quá trình triển khai công việc.

Mỗi phần mềm quản lý dự án đều có ưu và nhược điểm riêng. Không hề khó cho các nhà quản lý nếu muốn tìm hiểu về chúng vì mỗi nhà cung cấp đều có bộ phận tư vấn và chăm sóc khách hàng rất chu đáo – điều quan trọng nhất ở đây là nhà quản lý có nhận ra việc tìm hiểu này là cần thiết ngay lúc này hay không. Nhìn xung quanh, có lẽ bạn sẽ thấy mình đang là số ít còn lại vẫn sử dụng những công cụ lỗi thời như Email, Excel hay qua các phần mềm chat cho các nhiệm vụ đòi hỏi tính chặt chẽ và yêu cầu chất lượng cao.

Lời kết: Thức thời và tụt hậu

Quả thực cho đến thời điểm hiện tại vẫn chưa có một mô hình quản lý nào giải quyết một cách hoàn hảo tất cả các trường hợp mà doanh nghiệp có thể gặp phải. Các phương pháp quản lý được xây dựng dựa trên những quan điểm khác nhau và được tối ưu cho những mục đích sử dụng khác nhau. Với cương vị là một nhà lãnh đạo, bạn cần thiết phải hiểu rõ cách thức vận hành của các mô hình này để từ đó đưa ra các sự lựa chọn phù hợp và đạt được sự hiệu quả tối đa trong quản lý các dự án hiện tại và tương lai của doanh nghiệp.

Vai trò của quản lý dự án thì khỏi bàn, nhưng tầm quan trọng công nghệ – mà ở đây là những phần mềm hỗ trợ – không phải ai cũng nhận ra sự bức thiết vào lúc này. Trong thời đại 4.0, công nghệ sẽ là thứ nắm giữ vai trò quyết định đối với sự thành bại của doanh nghiệp. Việc áp dụng những tiến bộ khoa học công nghệ vào trong doanh nghiệp, đặc biệt là trong khâu quản lý dự án sẽ tạo ra sự khác biệt lớn về năng lực cạnh tranh đối với các doanh nghiệp khác trên thị trường. Sự khác biệt đó cũng chính là nhân tố đào thải trực tiếp các doanh nghiệp đuối sức ở thời điểm này.

Còn bạn, với cương vị là một nhà quản lý, bạn chọn THỨC THỜI hay TỤT HẬU?