PHÁT TRIỂN PHẦN MỀM LINH HOẠT AGILE(BÁO CÁO TỔNG HỢP)

Là sinh viên của khoa công nghệ thông tin, chúng em sớm đã được tiếp cận với môn công nghệ phần mềm và tìm hiểu khá nhiều quy trình hỗ trợ và nâng cao chất lượng phần mềm. Chúng em đã nhận thức được tầm quan trọng của các quy trình phát triển phần mềm. Mỗi quy trình có những mặt vượt trội riêng và nhìn chung mục đích chính của chúng cũng để nâng cao chất lượng sản phẩm và hạn chế rủi ro cho phần mềm làm ra. Tuy nhiên, trong những quy trình ấy chúng em nhận thấy phát triển phần mềm theo Agile là khá tiềm năng. Chính vì vậy, chúng em đã chọn đề tài báo cáo là “quy trình phát triển phần mềm linh hoạt theo Agile”.

Sự ra đời của mô hình Agile

Ngày nay, các phần mềm mà con người ra càng phức tạp Các thuật toán ngày càng phức tạp khó xây dựng và quản lý Chính vì vậy, những nhà quản lí phần mềm đã không ngừng học hỏi và tìm kiếm để tạo ra phương thức phát triển phần mềm tốt hơn So với trước đây, con người đã không ngừng tạo ra những chiếc máy tính rẻ hơn nhanh hơn, nhiều ngôn ngữ lập trình mạnh mẽ ra đời, số lượng nhiều hơn cần thiết phải có những công cụ hỗ trợ và có những hiểu biết sâu sắc hơn về lý thuyết phần mềm Máy tính đã làm thay đổi cả thế giới, thúc đẩy sự trao đổi thông tin và thay đổi một cách triệt để kỳ vọng của con người về cách thức mà phần mềm làm việc.

Chúng ta có rất nhiều phương pháp giúp xác định con đường phát triển phần mềm ví dụ như một số quy trình:

- Mô hình hướng đối tượng.

- Mô hình làm bản mẫu.

Các phương pháp truyền thống kể trên cố gắng trang bị một khả năng dự đoán trước cho quy trình phát triển phần mềm Vì vậy, chúng có thể tạo ra một bản kế hoạch từ thời điểm đầu dự án và xác định được thời gian hoàn thành của dự án. Nhưng vấn đề quan trọng nhất vẫn là “sự thay đổi yêu cầu người dùng” Bởi vì một phần mềm tốt là phần mềm mà đem lại cho khách hàng sự hài lòng Tuy vậy những phương pháp truyền thống đang hạn chế sự thay đổi yêu cầu từ khách hàng Điều này giúp duy trì kế hoạch dự án ban đầu nhưng không đem lại sự thỏa mãn hoàn toàn cho khách hàng.

Chính sự hạn chế từ những phương pháp truyền thống mà cần có một phương pháp hay quy trình phát triển phần mềm mới ra đời Và quy trình phát triển phần mềm linh hoạt Agile đã phần nào đáp ứng được yêu cầu ấy.

Agile thực chất là một triết lý hay một khung tư duy để nhanh chóng thích ứng và phản hồi với thay đổi, từ đó đạt được thành công trong một môi trường liên tục biến động và không chắc chắn

Phát triển phần mềm linh hoạt Agile là gì?

Agile là một triết lí cùng với nhóm các phương pháp và phương pháp luận phát triển phần mềm dựa trên các nguyên tắc phát triển phân đoạn lặp (iterative) và tăng trưởng (incremental), theo đó nhu cầu và giải pháp tiến hóa thông qua sự hợp tác giữa các nhóm tự quản và liên chức năng.

Phát triển phần mềm linh hoạt (Agile software development hay Agile programming) là một phương pháp dựa trên triết lý Agile thực hiện triển khai các dự án công nghệ phần mềm, phương pháp này khuyến khích sự thay đổi khi phát triển dự án và đưa sản phẩm đến tay người dung sao cho nhanh nhất.

Phương pháp Agile là một cách tiếp cận tập trung vào con người, tập trung vào kết quả để phát triển phần mềm, tôn trọng thế giới đang thay đổi nhanh chóng của chúng ta Nó tập trung vào việc lập kế hoạch thích ứng, tự tổ chức và thời gian giao hàng ngắn Nó linh hoạt, nhanh chóng và nhằm mục đích cải tiến liên tục về chất lượng

Agile software development (phương thức phát triển phần mềm linh hoạt) với mục tiêu là phần mềm phải có khả năng biến đổi, phát triển và tiến hóa theo thời gian mà không cần phải làm lại từ đầu Phương thức này tập chung vào tính đơn giản: tạo ra một phần mềm thật đơn giản đáp ứng đúng yêu cầu của khách hàng hôm nay và sẵn sàng cho những thay đổi vào ngày mai.

Phương pháp Agile cố gắng cực tiểu hoá rủi ro bằng cách phát triển phần mềm trong những khung thời gian ngắn và sự cộng tác chặt chẽ với khách hàng Mỗi bước lặp (iteration) giống như phát triển một phần mềm hoàn chỉnh cũng gồm có lấy yêu cầu, làm phân tích thiết kế, code, test, viết tài liệu Điểm nổi bật là khả năng sửa chữa biến đổi phần mềm ngay cả khi dự án đã bắt đầu. Điểm quan trọng làm lên sự khác biệt của Agile so với các mô hình truyền thống đó là: các mô hình truyền thống là mô hình theo kế hoạch, còn mô hình agile thì không nhất thiết phải tuân theo kế hoạch, nó có thể có những bước đột phá để tạo ra một phần mềm hiệu quả nhất.

Agile thường sử dụng cách lập kế hoạch thích ứng (adaptive planning), việc phát triển và chuyển giao theo hướng tiến hóa; sử dụng các khung thời gian ngắn và linh hoạt để dễ dàng phản hồi lại với các thay đổi trong quá trình phát triển Ngày nay, 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 (manufacturing), dịch vụ, sales, marketing, giáo dục v.v.

Lịch sử hình thành và phát triển

Phương pháp phát triển phần mềm linh hoạt Agile (Agile development Method) ra đời từ đầu những năm 90, với ý tưởng khắc phục những nhược điểm của mô hình truyền thống cụ thể là mô hình thác nước Agile là tên gọi chung để chỉ các phương pháp phát triển nhanh “Agile” có nghĩa là nhanh nhẹn, khéo léo trong hành động. Nhưng chính thức thì nó bắt đầu vào mùa xuân năm 2000, khi một nhóm 17 nhà phát triển phần mềm, bao gồm Martin Fowler, Jim Highsmith, Jon Kern, Jeff Sutherland, Ken Schwaber và Bob Martin gặp nhau ở Oregon để thảo luận về cách họ có thể tăng tốc thời gian phát triển theo thứ tự đưa phần mềm mới ra thị trường nhanh hơn.

Tháng 2 năm 2001 tại Snowbird Utah 17 nhà phát triển lại tiếp tục có một cuộc họp Sau cuộc họp kéo dài ba ngày đó, nhóm 17 nhà lãnh đạo đã sẵn sàng cho chương tiếp theo trong lịch sử của Agile: Thuyết phục thế giới về giá trị của mọi thứ mà họ nêu ra trong Tuyên ngôn Agile

Năm 2003, Liên minh Agile chính thức trở lại Utah để tổ chức hội nghị Agile hàng năm đầu tiên - một cột mốc quan trọng trong lịch sử của Agile Nhóm mô tả sự kiện này là "dành riêng cho việc thúc đẩy các nguyên tắc Agile và cung cấp một địa điểm để mọi người và ý tưởng phát triển." Hội nghị thường niên này, được đặt tên là Agile 20XX, vẫn tiếp tục cho đến ngày nay.

Từ năm 2012 đến năm 2015, các thước đo thành công trong cuộc sống thực bắt đầu đi kèm với câu chuyện đó Do khả năng chứng minh sự thành công trong Agile vào thời điểm đó, nên không thể phủ nhận lợi ích của việc áp dụng phương pháp luận gọn nhẹ Điều đó không có gì ngạc nhiên khi trong khoảng thời gian ba năm này, thế giới đã chứng kiến Agile vượt mốc 50% trong việc áp dụng, thực sự đưa thế giới phát triển đi như vũ bão.

Ngay sau đó, Agile bắt đầu bùng nổ, lần này bằng cách vượt ra ngoài sự phát triển Vào năm 2017 các nhà phát triển đưa ra định nghĩa ngắn gọn đầu tiên về Thử nghiệm Agile Định nghĩa này phác thảo các hoạt động thử nghiệm hợp tác tập trung vào việc phân phối thường xuyên các sản phẩm chất lượng, ưu tiên việc ngăn ngừa lỗi hơn là phát hiện lỗi.

Triết lí Agile cho đến ngày nay không chỉ đã làm thay đổi diện mạo nền công nghệ thế giới nói riêng mà đang lan tỏa mạnh mẽ và thể hiện giá trị trong rất nhiều lĩnh vực như: Quản lý dự án (với Agile Project Management), nhân sự (với Agile

HR và Agile People), marketing (với Agile Marketing), hay quản trị và lãnh đạo(với Agile Management, Agile Leadership)

Lợi ích khi sử dụng phương pháp Agile

Các lợi ích chung

Sự cam kết và sự hài lòng của các bên liên quan:

Quy trình nhanh tạo ra nhiều cơ hội trong suốt mỗi cuộc họp nước rút cho sự tham gia thực sự giữa nhóm và các bên liên quan Vì khách hàng tham gia tích cực vào toàn bộ dự án, nên có mức độ cộng tác liên tục giữa tất cả các bên Điều này giúp nhóm có cơ hội hiểu đầy đủ tầm nhìn của khách hàng Bằng cách cung cấp phần mềm chất lượng cao, hoạt động thường xuyên, các bên liên quan nhanh chóng phát triển mối quan hệ tin cậy và xác thực với nhóm Điều này cũng thúc đẩy hơn nữa sự tương tác giữa khách hàng và nhóm.

Tính minh bạch của dự án:

Phương pháp tiếp cận nhanh tích cực liên quan đến khách hàng trong toàn bộ dự án bao gồm lập kế hoạch lặp lại, các phiên đánh giá và xây dựng tính năng mới trong phần mềm Tuy nhiên, khách hàng phải hiểu rằng trong quá trình minh bạch của dự án, họ đang nhìn thấy một công việc đang được tiến hành chứ không phải sản phẩm cuối cùng.

Chuyển giao sớm và có thể trực tiếp chỉnh sửa phần mềm theo ý muốn:

Sprint được tổ chức theo lịch trình cố định trong thời gian từ 1 đến 4 tuần Bằng cách sử dụng phương pháp đóng hộp thời gian này, khả năng dự đoán là cao vì các tính năng mới có thể được cung cấp cho các bên liên quan một cách nhanh chóng và thường xuyên Nó cũng cho phép nhóm thử nghiệm beta hoặc phát hành phần mềm sớm hơn nếu nó có đủ giá trị kinh doanh.

Chi phí dự đoán và lịch trình:

Vì Sprint diễn ra theo một lịch trình cố định, chi phí được giới hạn và có thể dự đoán được và dựa trên khối lượng công việc đã thực hiện Bằng cách kết hợp các chi phí ước tính trước mỗi Sprint, khách hàng sẽ hiểu rõ hơn về chi phí ước tính của từng tính năng Điều này mang lại nhiều cơ hội ra quyết định được cải thiện hơn khi ưu tiên các tính năng hoặc thêm các lần lặp lại. Ưu tiên linh hoạt:

Các phương pháp luận của Scrum cho phép linh hoạt hơn bằng cách ưu tiên các tính năng hướng đến khách hàng Nhóm có nhiều quyền kiểm soát hơn trong việc quản lý các đơn vị công việc có thể chuyển đổi với mỗi ranh giới nước rút; đang tiếp tục tiến tới mốc sản phẩm cuối cùng Để nhận được RIO nhanh chóng từ bộ phận kỹ thuật, công việc cần được chuyển sớm cho khách hàng để họ nhận ra giá trị từ các tính năng.

Trong khi trọng tâm phải là cung cấp tập hợp con đã thống nhất về các tính năng của sản phẩm, các quy trình Agile tạo ra cơ hội để liên tục tái định vị và tinh chỉnh các sản phẩm tồn đọng Những thay đổi này có thể được thêm vào lần lặp tiếp theo để những thay đổi mới có thể được giới thiệu trong vòng vài tuần.

Tập trung vào giá trị doanh nghiệp:

Nhóm hiểu rõ hơn điều gì là quan trọng nhất đối với doanh nghiệp của khách hàng và có thể cung cấp các tính năng mang lại nhiều giá trị nhất cho doanh nghiệp. Tập trung vào người dùng:

Câu chuyện của người dùng thường được sử dụng để xác định các tính năng của sản phẩm vì chúng liên quan đến các tiêu chí chấp nhận tập trung vào doanh nghiệp.Bằng cách tập trung vào nhu cầu của người dùng, mỗi tính năng mang lại giá trị thực chứ không chỉ là một thành phần CNTT Nó cung cấp cơ hội tốt hơn để nhận được phản hồi có giá trị thông qua thử nghiệm beta phần mềm sau mỗi Sprint Điều này cung cấp phản hồi quan trọng trước đó trong dự án để có thể thực hiện các thay đổi khi cần thiết.

Cải thiện chất lượng sản phẩm:

Các dự án được chia thành các đơn vị có thể quản lý, giúp nhóm dễ dàng hơn hoặc tập trung vào phát triển, thử nghiệm và cộng tác chất lượng cao Bằng cách tạo các bản dựng và tiến hành các bài kiểm tra hoặc đánh giá trong suốt quá trình lặp lại, các lỗi và sự không phù hợp có thể được tìm thấy và khắc phục sớm, giúp cải thiện chất lượng toàn diện.

Mang lại mục đích, mục tiêu làm việc cho nhóm:

Hầu hết các quy trình nhanh đều tập trung vào việc tạo ra cảm giác sở hữu và mục tiêu chung cho tất cả các thành viên trong nhóm Điều này mang lại cho nhóm của bạn mục đích hơn là tạo ra cảm giác khẩn cấp sai lầm Các nhóm có mục đích làm việc hiệu quả hơn và thử thách bản thân để nhanh hơn và hiệu quả hơn.

Các giá trị lợi ích riêng

Các nhà cung cấp giảm lãng phí bằng cách tập trung nỗ lực phát triển vào các tính năng có giá trị cao và giảm thời gian đưa ra thị trường so với quy trình thác nước do giảm chi phí và tăng hiệu quả Sự hài lòng của khách hàng được cải thiện đồng nghĩa với việc giữ chân khách hàng tốt hơn và nhiều lượt giới thiệu tích cực hơn về khách hàng.

- Lợi ích đối với nhóm phát triển

Các thành viên trong nhóm thích công việc phát triển và thích thấy công việc của họ được sử dụng và đánh giá cao Scrum mang lại lợi ích cho các thành viên trongNhóm bằng cách giảm bớt công việc phi năng suất (ví dụ: viết thông số kỹ thuật hoặc các hiện vật khác mà không ai sử dụng) và cho họ nhiều thời gian hơn để làm công việc mà họ yêu thích Các thành viên trong nhóm cũng biết công việc của họ được coi trọng, bởi vì các yêu cầu được lựa chọn để tối đa hóa giá trị cho khách hàng.

- Lợi ích đối với người quản lý sản phẩm

Giám đốc sản phẩm, những người thường đảm nhiệm vai trò Chủ sở hữu sản phẩm, chịu trách nhiệm làm cho khách hàng hài lòng bằng cách đảm bảo rằng công việc phát triển phù hợp với nhu cầu của khách hàng Scrum làm cho việc liên kết này trở nên dễ dàng hơn bằng cách cung cấp các cơ hội thường xuyên để sắp xếp lại thứ tự ưu tiên công việc, nhằm đảm bảo mang lại giá trị tối đa.

- Lợi ích đối với người quản lý dự án

Người quản lý dự án (và những người khác) đảm nhiệm vai trò ScrumMaster nhận thấy rằng việc lập kế hoạch và theo dõi dễ dàng hơn và cụ thể hơn so với các quy trình thác nước Việc tập trung vào theo dõi cấp độ nhiệm vụ, sử dụng Biểu đồBurndown để hiển thị tiến độ hàng ngày và các cuộc họp Scrum Hàng ngày, tất cả đều mang lại cho Người quản lý dự án nhận thức sâu sắc về trạng thái của dự án mọi lúc Nhận thức này là chìa khóa để giám sát dự án, đồng thời nắm bắt và giải quyết các vấn đề một cách nhanh chóng.

Tầm quan trọng của phương pháp Agile

Thành công ở mức công ty

Agile tạo ra giá trị cho công ty trong khi làm giảm chi phí Đồng thời, Agile giúp sớm xác định các kì vọng đối với sản phẩm đang được phát triển Nhờ đó phương pháp phát triển phần mềm linh hoạt Agile những dự án không mang lại giá trị như mong đợi sẽ được phát hiện sớm, tiết kiệm chi phí cho công ty.

Theo phương pháp Agile, các chuyên gia về nghiệp vụ (business) sẽ làm việc trực tiếp cùng với đội dự án Các chức năng quan trọng nhất của sản phẩm được tập trung phát triển trước và được đưa vào vận hành sớm nhất có thể Các phiên bản mới với các tính năng mới sẽ lần lượt được đưa thêm vào Agile giúp tăng cường khả năng giao tiếp giữa các thành viên trong nhóm Chất lượng mã nguồn được cải tiến liên tục Tiến độ dự án cũng được xem xét và đánh giá một cách thường xuyên.

1.5 2 Thành công về mặt kĩ thuật

Trong Extreme Programming, một phương pháp tuân theo triết lí Agile, các lập trình viên làm việc cùng nhau Nhờ vậy, các chi tiết quan trọng sẽ không bị bỏ sót, mỗi đoạn code sẽ được kiểm tra bởi ít nhất hai người Các lập trình viên liên tục tích hợp những đoạn code vừa viết vào hệ thống, cho phép một phiên bản mới của phần mềm được “ra lò” Hơn nữa, toàn bộ đội dự án tập trung hoàn thành một chức năng trước khi chuyển sang chức năng tiếp theo Bởi vậy, tiến độ công việc được kiểm soát tốt hơn và dự án có thể dễ dàng “chuyển hướng” khi có những thay đổi từ phía khách hàng.

+zgoài ra, Extreme Programming cũng đề xuất những quy tắc giúp tạo ra các thiết kế và các đoạn mã tốt Chẳng hạn, quy tắc “phát triển dựa trên kiểm thử” (test- driven development) trợ giúp lập trình viên viết các chương trình thực hiện đúng chức năng mong muốn.

Thành công về mặt cá nhân

Mỗi thành viên trong dự án Agile, dù ở bất kì cương vị nào, cũng đều cảm nhận được một cách rõ ràng sự thành công của bản thân Các lập trình viên nhận thấy trình độ kĩ thuật cũng như tầm ảnh hưởng của mình đối với dự án được nâng cao,chẳng hạn trong việc ước lượng và lập kế hoạch Quyền tự chủ của đội dự án cũng được tăng cường Các tester nhận thấy họ có ảnh hưởng lớn đến chất lượng sản phẩm, đồng thời giảm được các công việc lặp lại một cách nhàm chán.

Nhờ phương pháp pháp phát triển phần mềm linh hoạt Agile quản lí dự án hài lòng vì kiểm soát được tiến độ công việc, dự án thực hiện đúng các cam kết và làm thỏa mãn khách hàng Khách hàng, người sử dụng, các chuyên gia nghiệp vụ cảm thấy hài lòng vì điều khiển được hướng đi của dự án và các ý kiến được lắng nghe.Các nhà lãnh đạo cao cấp sẽ cảm thấy hài lòng vì dự án mang lại lợi nhuận lớn cho công ty

ĐẶC ĐIỂM CỦA AGILE

Tuyên ngôn Agile

Tuyên ngôn Agile được viết như sau: “Chúng tôi tìm kiếm những phương pháp tốt hơn để phát triển và giúp người khác phát triển phần mềm Qua hoạt động đó, chúng tôi sẽ trân trọng: cá nhân và sự tương tác hơn là quy trình và công cụ; phần mềm hoạt động được hơn là việc thu thập tư liệu phát triển; hợp tác với khách hàng hơn là thương thuyết về hợp đồng; phản ứng theo sự thay đổi hơn là theo sát kế hoạch Nghĩa là, mặc dù có những giá trị cố hữu ở ‘cánh hữu’ (truyền thống), nhưng chúng tôi trân trọng các giá trị ‘cánh tả’ (của đổi mới) nhiều hơn”.

Cá nhân và tương tác hơn là quy trình và công cụ: Câu đầu tiên này cho ta thấy không phải lúc nào cũng có giải pháp cho mọi thứ, mà giải pháp chính là nằm bên trong của công việc Và đề tìm được giải pháp, thì không chỉ dựa vào các lý thuyết mà phải trực tiếp làm công việc phát triển phần mềm Tất nhiên quy trình và công cụ cũng là điều quan trọng Sẽ không thể có một phần mềm tốt nếu như quy trình và công cụ không tốt Nhưng điều mà bản tuyên ngôn nhấn mạnh là vai trò của từng cá nhân và mối quan hệ giữa các cá nhân trong đội ngũ phát triển phần mềm Ý nghĩa quan trọng nhất của Agile là mọi người cùng làm việc trong nhóm, chia sẻ thông tin thoải mái với nhau hơn là tập trung theo sát một quy trình hay công cụ nào đó.

Phần mềm hoạt động được hơn là việc thu thập tư liệu để phát triển: Điều này không có nghĩa là chúng ta không phải thu thập lại tư liệu để phát triển, chỉ là ít nhấn mạnh thu thập tư liệu và tập trung nhiều hơn cho việc hoàn tất công việc Bởi vì đối với một dự án muốn thành công thì phải thu thập tài liệu đầy đủ Nhưng bản thân tài liệu cũng không thể giúp được gì nếu không có một sản phẩm phần mềm thực sự Vì thế, việc tạo ra sản phẩm phần mềm quan trọng hơn, và tài liệu chỉ đóng vai trò hỗ trợ phần mềm, mô tả phần mềm một cách chính xác.

Hợp tác với khách hàng hơn là thương thuyết hợp đồng: Việc ký kết hợp đồng là quan trọng nhưng không đủ Một môi trường hợp tác tốt sẽ giúp cho những người phát triển đưa ra giải pháp tốt nhất cho khách hàng Các hợp đồng định nghĩa những điều khoản ràng buộc mà trong đó cả hai bên đối tác phải tuân theo, những người phát triển cần hợp tác với khách hàng để có thể hiểu rõ yêu cầu cũng như những gì cần phải đưa ra Agile tập trung vào việc khuyến khích khách hàng cùng tham gia vào dự án hơn là chỉ viết hợp đồng để rồi khách hàng sẽ chẳng làm gì với nhóm dự án phần mềm.

Phản ứng theo thay đổi hơn là theo sát kế hoạch: Việc lập kế hoạch cho phát triển phần mềm là không thể thiếu Kế hoạch giúp công việc định hướng tốt hơn. Tuy nhiên thực tế có rất nhiều thay đổi, và cứ nhất nhất tuân theo kế hoạch sẽ dễ dẫn đến thất bại Do đó cần đáp ứng với thay đổi để có sự điều chỉnh sao cho phù hợp Chính vì vậy, nhóm phát triển luôn sẵn lòng đón nhận thay đổi hơn là chỉ làm theo kế hoạch dự án (có trước) vì thay đổi luôn diễn ra và cả kế hoạch dự án cũng sẽ thay đổi khi yêu cầu thay đổi.

Nguyên tắc Agile

Khách hàng nên tham gia chặt chẽ trong suốt quá trình phát triển Vai trò của họ là cung cấp và quy định mức độ ưu tiên các yêu cầu mới về hệ thống, và đánh giá hệ thống tại các lần lặp (iterations of the system).

Phần mềm được phát triển một cách tăng dần từng đợt (increment), trong đó khách hàng chỉ ra các yêu cầu cần được đưa vào mỗi đợt.

Con người thay vì quy trình

Kĩ năng phát triển của đội cần được ghi nhận và khai thác Các thành viên của đội cần được tự do phát triển cách làm việc của riêng mình mà không cần đến các quy trình quy phạm định trước.

Hiểu rằng hệ thống sẽ thay đổi nên thiết kế hệ thống sao cho nó có thể chấp nhận được thay đổi đó.

Gìn giữ tính giản dị dễ hiểu

Chú trọng vào tính giản dị dễ hiểu của phần mềm đang được phát triển cũng như của quy trình phát triển Chủ động nỗ lực loại bỏ sự phức tạp ra khỏi hệ thống bất cứ khi nào có thể.

Cụ thể quy trình phát triển phần mềm theo hướng Agile có 12 nguyên tắc như sau:

1 Ưu tiên cao nhất của dự án là thỏa mãn khách hàng bằng việc bàn giao sản phẩm sớm và liên tục.

2 Hoan nghênh các thay đổi từ phía khách hàng, kể cả các thay đổi vào giai đoạn cuối.

3 Bàn giao sản phẩm theo chu kì từ vài tuần đến vài tháng Chu kì ngắn tốt hơn chu kì dài.

4 Các nhân viên hiểu nghiệp vụ và các lập trình viên phải làm việc cùng nhau hàng ngày.

5 Tổ chức dự án xoay quanh những cá nhân tích cực Hỗ trợ và tin tưởng họ.

6 Phương pháp giao tiếp tốt nhất trong đội dự án là gặp mặt trực tiếp.

7 Các chức năng đã họat động là thước đo chính cho tiến độ dự án.

8 Khuyến khích phát triển bền vững: Lập trình viên, người dùng, nhà quản lí…phải có khả năng tham gia dự án một cách liên tục.

9 Liên tục cải tiến chất lượng thiết kế và mã nguồn.

10 Tính đơn giản giữ vai trò cốt yếu Làm càng ít càng tốt.

11 Những yêu cầu và thiết kế tốt nhất được nảy nở từ những nhóm làm việc tự chủ.

12 Sau những khoảng thời gian nhất định, đội dự án xem xét cách thức cải tiến hiệu quả công việc.

Đặc trưng của mô hình Agile

Dự án sẽ được thực hiện trong các phân đoạn lặp đi lặp lại Các phân đoạn (được gọi là Iteration hoặc Sprint) này thường có khung thời gian ngắn (từ một đến bốn tuần) Trong mỗi phân đoạn này, nhóm phát triển thực hiện đầy đủ các công việc cần thiết như lập kế hoạch, phân tích yêu cầu, thiết kế, triển khai, kiểm thử (với các mức độ khác nhau) để cho ra các phần nhỏ của sản phẩm Các phương pháp agile thường phân chia mục tiêu thành các phần nhỏ với quá trình lập kế hoạch đơn giản và gọn nhẹ nhất có thể, và không thực hiện việc lập kế hoạch dài hạn.

2.3.2 Tính tiệm tiến(Incremental) và tiến hoá(Evolutionary)

Cuối các phân đoạn, nhóm phát triển thường cho ra các phần nhỏ của sản phẩm cuối cùng Các phần nhỏ này thường là đầy đủ, có khả năng chạy tốt, được kiểm thử cẩn thận và có thể sử dụng ngay (gọi là potentially shippable product increment of functionality) Theo thời gian, phân đoạn này tiếp nối phân đoạn kia, các phần chạy được này sẽ được tích lũy, lớn dần lên cho tới khi toàn bộ yêu cầu của khách hàng được thỏa mãn Khác với mô hình phát triển Thác nước – vốn chỉ cho phép nhìn thấy toàn bộ các chức năng tại thời điểm kết thúc dự án, sản phẩm trong các dự án agile lớn dần lên theo thời gian, tiến hóa cho tới khi đạt được trạng thái đủ để phát hành.

2.3.3 Tính thích ứng(hay thích nghi - Adaptive)

Do các phân đoạn chỉ kéo dài trong một khoảng thời gian ngắn, và việc lập kế hoạch cũng được điều chỉnh liên tục, nên các thay đổi trong quá trình phát triển (yêu cầu thay đổi, thay đổi công nghệ, thay đổi định hướng về mục tiêu v.v.) đều có thể được đáp ứng theo cách thích hợp Ví dụ, trong Scrum – phương pháp phổ biến nhất hiện nay – trong khi nhóm phát triển sản xuất ra các gói phần mềm, khách hàng có thể đưa thêm các yêu cầu mới, chủ sản phẩm (Product Owner) có thể đánh giá các yêu cầu này và có thể đưa vào làm việc trong phân đoạn (được gọi là Sprint trong Scrum) tiếp theo Theo đó, các quy trình agile thường thích ứng rất tốt với các thay đổi.

2.3.4 Nhóm tự tổ chức và liên chức năng

Cấu trúc nhóm agile thường là liên chức năng(cross-functionality) và tự tổ chức(self-organizing) Theo đó, các nhóm này tự thực hiện lấy việc phân công công việc mà không dựa trên các mô tả cứng về chức danh (title) hay làm việc dựa trên một sự phân cấp rõ ràng trong tổ chức Các nhóm này cộng tác với nhau để ra quyết định, theo dõi tiến độ, giải quyết các vấn đề mà không chờ mệnh lệnh của các cấp quản lý Họ không làm việc theo cơ chế “mệnh lệnh và kiểm soát” (command and control).

Nhóm tự tổ chức có nghĩa là nó đã đủ các kĩ năng (competency) cần thiết cho việc phát triển phần mềm, do vậy nó có thể được trao quyền để tự ra quyết định, tự quản lí và tổ chức lấy công việc của chính mình để đạt được hiệu quả cao nhất.

2.3.5 Quản lý tiến trình thực tiễn( Empirical Process Control)

Các nhóm agile ra các quyết định dựa trên các dữ liệu thực tiễn thay vì tính toán lý thuyết hay các tiền giả định (prescription) Việc phân nhỏ dự án thành các phân đoạn ngắn góp phần gia tăng các điểm mốc để nhóm phát triển thu thập dữ kiện cho phép điều chỉnh các chiến lược phát triển của mình Nói cách khác, Agile rút ngắn vòng đời phản hồi (short feedback life cycle) để dễ dàng thích nghi và gia tăng tính linh hoạt Theo thời gian, các chiến lược này sẽ tiến gần đến trạng thái tối ưu, nhờ đó nhóm có thể kiểm soát được tiến trình, và nâng cao năng suất lao động.

2.3.6 Giao tiếp trực tiếp(Face-to-face Communication)

Về yêu cầu của khách hàng, agile khuyến khích nhóm phát triển trực tiếp nói chuyện với khách hàng để hiểu rõ hơn về cái khách hàng thực sự cần, thay vì phụ thuộc nhiều vào các loại văn bản.

Trong giao tiếp giữa nội bộ nhóm phát triển với nhau, thay vì một lập trình viên (thực hiện việc code) và một kĩ sư (thực hiện việc thiết kế) giao tiếp với nhau thông qua bản thiết kế, agile khuyến khích hai người này trực tiếp trao đổi và thống nhất với nhau về thiết kế của hệ thống và cùng nhau triển khai thành các chức năng theo yêu cầu.

Bản thân các nhóm agile thường nhỏ để đơn giản hóa quá trình giao tiếp, thúc đẩy việc cộng tác hiệu quả Các dự án lớn muốn dùng agile thường phải phân thành nhóm nhỏ đồng thời làm việc với nhau hướng đến một mục tiêu chung Việc này có thể đòi hỏi một số nỗ lực đáng kể trong việc điều phối các mức ưu tiên giữa các nhóm.

Các nhóm phát triển thường tạo ra các thói quen và cơ chế trao đổi trực diện một cách thường xuyên Một trong các cơ chế thường thấy là các cuộc họp tập trung hằng ngày (daily meeting, Daily Scrum, standup meeting) Tại đây, tất cả các thành viên được yêu cầu nói rõ cho nhóm của mình biết mình đã làm gì, đang làm gì, sắp làm gì và đang gặp phải khó khăn nào trong quá trình làm việc Khi cơ chế này được thực hiện hiệu quả, nhóm luôn luôn nắm được tình hình công việc của mình, có các hành động thích hợp để vượt qua các trở lực để thực hiện thành công mục tiêu của dự án.

Phần mềm sẽ được trình chiếu hàng tuần và đưa cho khách hàng xem xét,góp ý.Nếu không có thay đổi thì tiến hành thực hiện và cuối cùng khi sản phẩm hoàn thành thì bàn giao cho khách hàng.

2.3.7 Phát triển dựa trên giá trị(Value-based development)

Một trong các nguyên tắc cơ bản của agile là “phần mềm chạy tốt chính là thước đo của tiến độ” Nguyên tắc này giúp nhóm dám loại bỏ đi các công việc dư thừa không trực tiếp mang lại giá trị cho sản phẩm. Để vận hành được cơ chế “làm việc dựa trên giá trị”, nhóm agile thường làm việc trực tiếp và thường xuyên với khách hàng (hay đại diện của khách hàng), cộng tác trực tiếp với họ để biết yêu cầu nào có độ ưu tiên cao hơn, mang lại giá trị hơn sớm nhất có thể cho dự án Nhờ đó các dự án agile thường giúp khách hàng tối ưu hóa được giá trị của dự án Một cách gần như trực tiếp, agile gia tăng đáng kể độ hài lòng của khách hàng.

QUY TRÌNH THỰC HIỆN MÔ HÌNH AGILE

Lập kế hoạch

Kế hoạch tổng thể của dự án được lập trong những tuần đầu tiên Đại diện của khách hàng và các lập trình viên cùng nhau chia dự án thành các phần tăng trưởng nhỏ, ước lượng thời gian và công sức thực hiện chúng và vạch ra lịch trình phát triển cho từng phần tăng trưởng Kế hoạch tổng thể sẽ được điều chỉnh tùy theo tình hình trong phần sau của dự án Mỗi phần tăng trưởng có một kế hoạch thực hiện cụ thể được vạch ra vào đầu mỗi vòng lặp Đội dự án sẽ họp mặt hàng ngày để cập nhật tình hình công việc.

Phân tích

Agile không dành riêng một khoảng thời gian cố định ban đầu cho việc phân tích yêu cầu Trái lại, đại diện của khách hàng sẽ ngồi làm việc chung với đội dự án. Người đại diện này không nhất thiết phải là khách hàng thật, chỉ cần là người hiểu rõ nhất các yêu cầu cho sản phẩm Khi cần thông tin, các lập trình viên chỉ việc đến trao đổi trực tiếp với người này Đối với những yêu cầu khó hiểu, đại diện khách hàng cùng với các tester tạo ra những ví dụ chi tiết gọi là “customer test” Đối với các giao diện đồ họa, đại diện khách hàng cùng đội dự án tạo ra các bản phác thảo trước khi bắt tay vào lập trình Một số dự án thuê người thiết kế giao diện riêng.

Thiết kế và lập trình

Trong một dự án, thiết kế của sản phẩm được cải tiến liên tục Hoạt động này được thực hiện nhờ phương pháp phát triển dựa trên test (test-driven development được viết tắt là TDD) TDD gắn kết chặt chẽ các công việc thiết kế, lập trình và test. Các lập trình viên phải làm việc theo cặp, một trong hai người viết các dòng lệnh cụ thể còn người kia suy nghĩ về thiết kế của chương trình Các lập trình viên tích hợp code vài giờ một lần và đảm bảo rằng phiên bản mới đủ tiêu chuẩn về mặt kĩ thuật để bàn giao ngay cho khách hàng Mã nguồn được coi là sở hữu tập thể Mọi người được yêu cầu sửa lỗi bất kể lỗi đó do ai gây ra.

Bàn giao sản phẩm

Phần mềm sẽ được trình chiếu hàng tuần và đưa cho khách hàng xem xét,góp ý.Nếu không có thay đổi thì tiến hành thực hiện và cuối cùng khi sản phẩm hoàn thành thì bàn giao cho khách hàng.

2.3.7 Phát triển dựa trên giá trị(Value-based development)

Một trong các nguyên tắc cơ bản của agile là “phần mềm chạy tốt chính là thước đo của tiến độ” Nguyên tắc này giúp nhóm dám loại bỏ đi các công việc dư thừa không trực tiếp mang lại giá trị cho sản phẩm. Để vận hành được cơ chế “làm việc dựa trên giá trị”, nhóm agile thường làm việc trực tiếp và thường xuyên với khách hàng (hay đại diện của khách hàng), cộng tác trực tiếp với họ để biết yêu cầu nào có độ ưu tiên cao hơn, mang lại giá trị hơn sớm nhất có thể cho dự án Nhờ đó các dự án agile thường giúp khách hàng tối ưu hóa được giá trị của dự án Một cách gần như trực tiếp, agile gia tăng đáng kể độ hài lòng của khách hàng.

CHƯƠNG III: QUY TRÌNH THỰC HIỆN MÔ HÌNH AGILE

Hình 1: Mô hình Agile tổng quát

Kế hoạch tổng thể của dự án được lập trong những tuần đầu tiên Đại diện của khách hàng và các lập trình viên cùng nhau chia dự án thành các phần tăng trưởng nhỏ, ước lượng thời gian và công sức thực hiện chúng và vạch ra lịch trình phát triển cho từng phần tăng trưởng Kế hoạch tổng thể sẽ được điều chỉnh tùy theo tình hình trong phần sau của dự án Mỗi phần tăng trưởng có một kế hoạch thực hiện cụ thể được vạch ra vào đầu mỗi vòng lặp Đội dự án sẽ họp mặt hàng ngày để cập nhật tình hình công việc

Agile không dành riêng một khoảng thời gian cố định ban đầu cho việc phân tích yêu cầu Trái lại, đại diện của khách hàng sẽ ngồi làm việc chung với đội dự án. Người đại diện này không nhất thiết phải là khách hàng thật, chỉ cần là người hiểu rõ nhất các yêu cầu cho sản phẩm Khi cần thông tin, các lập trình viên chỉ việc đến trao đổi trực tiếp với người này Đối với những yêu cầu khó hiểu, đại diện khách hàng cùng với các tester tạo ra những ví dụ chi tiết gọi là “customer test” Đối với các giao diện đồ họa, đại diện khách hàng cùng đội dự án tạo ra các bản phác thảo trước khi bắt tay vào lập trình Một số dự án thuê người thiết kế giao diện riêng.

3.3 Thiết kế và lập trình

Trong một dự án, thiết kế của sản phẩm được cải tiến liên tục Hoạt động này được thực hiện nhờ phương pháp phát triển dựa trên test (test-driven development được viết tắt là TDD) TDD gắn kết chặt chẽ các công việc thiết kế, lập trình và test. Các lập trình viên phải làm việc theo cặp, một trong hai người viết các dòng lệnh cụ thể còn người kia suy nghĩ về thiết kế của chương trình Các lập trình viên tích hợp code vài giờ một lần và đảm bảo rằng phiên bản mới đủ tiêu chuẩn về mặt kĩ thuật để bàn giao ngay cho khách hàng Mã nguồn được coi là sở hữu tập thể Mọi người được yêu cầu sửa lỗi bất kể lỗi đó do ai gây ra.

Tất cả các thành viên trong dự án đều có trách nhiệm đảm bảo chất lượng sản phẩm Các lập trình viên thực hiện unit test và integration test Đại diện khách hàng kiểm tra công việc của lập trình viên và trợ giúp họ bằng các customer test Khi các tester tìm ra lỗi, cả đội cùng nhau phân tích nguyên nhân và tìm cách cải tiến quy trình để ngăn ngừa lỗi tái diễn Tất cả các regression test đều được thực hiện tự động (bởi code mới được tích hợp vào hệthống một cách liên tục) và được chạy bởi các lập trình viên khi họ tích hợp code mới vào hệ thống Lập trình theo cặp góp phần làm tăng chất lượng công việc.

CHƯƠNG IV: NHỮNG VẤN ĐỀ CẦN XEM XÉT ĐỂ QUYẾT ĐỊNH CHỌN

Cần trả lời những câu hỏi sau

- Hệ được phát triển thuộc loại nào?

- Hệ có khả năng bị kiểm duyệt từ bên ngoài?

- Hệ được phát triển lớn hay nhỏ?

- Đội phát triển được tổ chức thế nào?

- Khả năng của người thiết kế và lập trình viên đến đâu?

- Có sẵn những công nghệ nào để hỗ trợ phát triển?

- Có cần phải đặc tả và thiết kế chi tiết trước khi cài đặt hay không?

- Chiến thuật bàn giao có tăng dần khả thi không?

- Có vấn đề văn hóa hay tổ chức nào có thể ảnh hưởng đến phát triển hay không?

Điều kiện áp dụng quy trình Agile

Agile là một phương pháp tốt, tuy nhiên không phải trường hợp nào cũng áp dụng được phương pháp này Trước khi quyết định áp dụng Agile cho dự án của mình, bạn phải trả lời được câu hỏi: đối với dự án này, điều kiện của công ty như thế này thì liệu phương pháp Agile có giúp bạn thành công hơn khi áp dụng các phương pháp khác hay không? Các dự án có đặc điểm sau đây có thể phù hợp với Agile:

Mức độ rủi ro thấp:

Mức độ rủi ro của dự án có thể được hiểu là khả năng thực hiện và mức độ thành công của dự án Dự án nào có tính khả thi thấp, tức là mức độ rủi ro cao thì không nên áp dụng mô hình này Bởi vì dự án theo agile sẽ tốn rất nhiều chi phí Ví dụ như khách hàng thường xuyên thay đổi yêu cầu thì bên làm dự án sẽ phải thực hiện lại cho phù hợp yêu cầu Như vậy, nếu như rủi ro cuối cùng dự án vẫn không thể hoàn thành thì rất tốn thời gian, công sức và tiền bạc.

Thành viên nhóm có kinh nghiệm:

Vì Agile tập trung cho các dự án nhỏ và có thời gian hoàn tất ngắn, do đó phương pháp này đòi hỏi có những cá nhân tài năng, những người sẵn lòng làm mọi chuyện và có năng lực tổng quát hóa, có thể làm qua nhiều công đoạn trong vòng đời truyền thống của sản phẩm Phương pháp Agile cần có các cá nhân đa năng, có động lực, biết nghiên cứu, biết phân tích, biết sáng tạo, và có các kỹ năng giao tiếp cần thiết để hiểu thấu các vấn đề của khách hàng Họ cũng phải là những người làm việc nhóm có tính kỷ luật, và là những kỹ sư phần mềm tài ba có thể cho ra đời sản phẩm đúng hạn thời gian cho phép Đặc biệt, họ phải có kĩ năng hoạt động theo nhóm tốt để thường xuyên trao đổi hợp tác với các thành viên trong nhóm.

Nhu cầu thay đổi thường xuyên

Khi thực hiện phương pháp này, các thành viên trong nhóm sẽ tiếp xúc thường xuyên với khách hàng, trao đổi thường xuyên để cùng hoàn thiện dự án Nếu bên khách hàng có thay đổi yêu cầu, cả hai bên sẽ cùng ngồi với nhau bàn bạc lại để tìm ra giải pháp tối ưu nhất Do vậy, đối với các dự án có tính ổn định cao, ít thay đổi thì áp dụng phương pháp này là không cần thiết.

Kích thước nhóm nhỏ, các thành viên làm việc cùng một địa điểm

Xuất phát từ yêu cầu trao đổi thông tin thường xuyên giữa các thành viên trong nhóm, nên phương pháp Agile đòi hỏi nhóm không cần quá nhiều thành viên, nếu quá nhiều thành viên sẽ làm cho sự quản lý nhóm, trao đổi giữa các thành viên trong nhóm trở nên không hiệu quả Mặt khác, yêu cầu quan trọng nữa là các thành viên phải cùng làm việc tại cùng một địa điểm, khi đó sự trao đổi thông tin mới có hiệu quả hơn.

Văn hóa công ty ưa thích sự “không trật tự”

Bởi vì có như thế các thành viên mới mạnh dạn đưa ra những chính kiến của mình trong quá trình làm việc nhóm Nhằm phát huy tính sáng tạo cao nhất của các thành viên.

CÁC PHƯƠNG PHÁP AGILE

Scrum

Scrum là một phương pháp luận được viết bởi Ken Schwaber và Mike Beedle. Thuật ngữ Scrum được đưa ra dựa trên một bài viết của Takeuchi và Nonaka (1986) mà trong đó giới thiệu một quy trình phát triển phần mềm nhanh có khả năng thích nghi.

Phương pháp phát triển phần mềm Scrum được biết đến như một phương pháp quản lý nâng cao, áp dụng cho các hệ thống hiện có Do đó, có thể áp dụng Scrum với các phương pháp phát triển phần mềm khác. Ý tưởng chính của Scrum là cho rằng việc phát triển một hệ thống cần phải quản lý một loạt các đại lượng như yêu cầu, thời gian, tài nguyên hay công nghệ dùng để phát triển, mà những đại lượng này hoàn toàn có thể thay đổi trong quá trình phát triển Từ đó cho thấy quá trình phát triển dự án mang tính không ổn định, phức tạp và khó đoán trước Do đó, cần phải có một quy trình phát triển có tính linh hoạt cao để có thể áp ứng được những thay đổi này, và sản phẩm đầu ra phải có tính ứng dụng cao đáp ứng nhu cầu khách hàng.

Phát triển phần mềm theo cách gia tăng dần thông qua việc thực hiện một danh sách công khai các yêu cầu hay sửa chữa cần thực hiện (backlog) Việc bàn giao với khách hàng diễn ra thường xuyên (4 tuần/1 lần) Mỗi lần khách hàng sẽ nhận một phần mềm với tính năng nhiều hơn và hoạt động tốt hơn.

- Họp hàng ngày: mỗi ngày, toàn đội sẽ tập trung trong vòng 15 phút vào đầu buổi sáng để tổng kết công việc ngày hôm qua, kế hoạch công việc sẽ làm trong ngày hôm nay và kiểm tra các tình huống có thể cản trở công việc trong ngày hôm nay.

- Họp lên kế hoạch: toàn đội sẽ tập trung để quyết định các tính năng cần thực hiện của Sprint sau và cập nhật danh sách chung.

- Họp kiểm tra lại công việc: trong cuộc họp này, mỗi người sẽ trình bày công việc đã làm trong thời gian thực hiện một sprint Việc chứng minh các tính năng mới hay trình bày kiến trúc sẽ được tổ chức Đây là một cuộc họp không chính thức kéo dài khoảng 2 giờ với sự tham gia của toàn đội.

- Họp tổng kết: mỗi khi kết thúc một sprint, toàn đội sẽ họp về những tính năng hoạt động tốt và những tính năng chưa tốt Trong cuộc họp khoảng 15 đến 30 phút này, môi người tham gia sẽ bỏ phiếu để xác định nhưng cải tiến cần có trong giai đoạn tiếp theo.

Scrum là phương pháp tiêu biểu trong các phương pháp nhanh với tính linh động cao, thời gian đáp ứng thay đổi nhanh và cộng tác chặt chẽ giữa các thành viên cũng như khách hàng Nó có một số các đặc trưng như sau:

- Linh động trong việc đưa kết quả- nội dung đưa ra phụ thuộc vào môi trường.

- Linh động trong lập lịch- việc đưa ra có thể sớm hơn hoặc muộn hơn kế hoạch.

- Đội ngũ phát triển phần mềm nhỏ- đội nhỏ được chia thành các nhóm nhỏ, một dự án phần mềm có thể có nhiều nhóm nhỏ cùng nhau phát triển.

- Thảo luận thường xuyên- quá trình thực hiện của từng nhóm thường xuyên được xem xét thảo luận.

- Tính cộng tác- Trong quá trình thực hiện dự án, việc cộng tác giữa các thành viên với nhau và với đối tác được coi trọng.

Scrum là một phương pháp hướng quy trình Quy trình Scrum chia thành 3 giai đoạn: Giai đoạn bắt đầu và lập kế hoạch, giai đoạn phát triển, và giai đoạn kết thúc và đưa ra sản phẩm.

Giai đoạn bắt đầu và lập kế hoạch (Sprint Planning):

- Trước khi dự án bắt đầu, tất cả các yêu cầu hệ thống được liệt kê và tập hợp dưới dạng các phiếu công việc (Backlog) Các yêu cầu có thể từ khách hàng, bộ phận bán hàng hay người phát triển phần mềm Tập hợp các phiếu công việc của toàn bộ dự án được gọi là Product Backlog Product Backlog cho ta cái nhìn tổng thể về các chức năng của sản phẩm cuối cùng Người tạo ra Product Backlog được gọi là Product Owner (người sở hữu) thông thường là khách hàng hoặc người quản lý trong công ty.

- Tiếp theo, các yêu cầu này được xác định độ ưu tiên và nhân lực tương ứng. Danh sách này sẽ luôn được cập nhập để công việc xác định độ ưu tiên, nhân lực và tài nguyên cho chính xác.

- Trong giai đoạn này cũng phải đưa ra được nhóm dự án, công cụ, tài nguyên cần thiết, đánh giá rủi ro và tiến hành đào tạo lại nếu cần thiết Ngoài ra, thiết kế tổng thể cũng được định nghĩa trong giai đoạn này.

- Trước khi tiến hành phát triển, người sở hữu chọn những công việc cần tiến hành trong vòng lặp đầu tiên của giai đoạn phát triển Các công việc này được tập hợp dưới dạng danh sách gọi là Sprint Backlog Trong khi đó, nhóm phát triển chuẩn bị những gì cần thiết và ước lượng thời gian sao cho công việc có thể hoàn thành trong 30 ngày là khoảng thời gian một vòng lặp được quy định bởi Scrum.

- Công việc cuối cùng của xác định mục tiêu là phải hoàn thành vòng lặp, gọi là Sprint Goal Việc xác định mục tiêu này để giúp đội phát triển thấy được lý do công việc mình phải làm.

Giai đoạn phát triển(Sprint ):

- Toàn bộ giai đoạn phát triển được phân thành các vòng lặp, mỗi vòng lặp kéo dài 30 ngày gọi là Sprint Mỗi vòng lặp, các thành viên dự án sẽ chọn công việc từ Sprint Backlog, làm việc sao cho đạt được mục tiêu đề ra trong Sprint Goal Trong vòng lặp các công việc lại được chia thành các khoảng thời gian nhỏ hơn:

+ Phát triển: Tiến hành phân tích, thiết kế, cài đặt, kiểm thử và viết tài liệu cho những chức năng được lựa chọn.

+ Đóng gói: Tạo bộ cài đặt của sản phẩm đến thời điểm hiện thời.

+ Xem lại: Tất cả các thành viên trong nhóm họp với nhau để cùng đưa ra cách giải quyết những vấn đề gặp phải.

+ Điều chỉnh: Tổng hợp các thông tin thu từ cuộc họp và tiến hành điều chỉnh.

Kanban

Kanban là phương pháp Agile và nguồn gốc Kanban được phát triển vào cuối những năm 1940 bởi một kỹ sư người Nhật tên là Taiichi Ohno Agile Kanban Framework tập trung vào việc trực quan hóa toàn bộ dự án trên các bảng nhằm tăng tính minh bạch của dự án và sự hợp tác giữa các thành viên trong nhóm.

Kanban là một phương pháp Agile nhưng không nhất thiết cần có tính lặp Các quy trình như Scrum có các lần lặp ngắn (Sprint) là vòng đời của dự án trên quy mô nhỏ, có điểm bắt đầu và kết thúc riêng biệt cho mỗi lần lặp Kanban cho phép phần mềm được phát triển trong một chu kỳ phát triển lớn Mặc dù vậy, Kanban là một ví dụ về một phương pháp Agile vì nó đáp ứng tất cả mười hai nguyên tắc đằng sau tuyên ngôn Agile, bởi vì mặc dù nó không có tính lặp, nhưng vẫn có tính tăng trưởng.

5.2.2 4 nguyên lý của Kanban ã Trực quan húa cụng việc

Bảng Kanban là công cụ để trực quan hóa công việc Bảng Kanban bao gồm các cột tương ứng với trạng thái của công việc Mỗi công việc khi ở trạng thái nào thì được đặt ở cột tương ứng Chúng ta có thể dùng một bảng vật lý hoặc một phần mềm hỗ trợ Kanban như Trello.

Giới hạn công việc đang làm (Limit WIP – Limit Work In Progress)

Số lượng công việc đang được làm đồng thời ở mỗi trạng thái cần được giới hạn. Nguyên lý này giúp giới hạn những việc chưa hoàn thành trong tiến trình, từ đó giảm thời gian mỗi công việc đi qua hệ thống Kanban Nguyên lý giới hạn WIP còn giúp cho nhóm làm việc tập trung, tránh lãng phí do phải việc chuyển qua lại giữa các công việc khác nhau.

Tập trung vào luồng làm việc

Việc áp dụng nguyên lý giới hạn WIP và phát triển những chính sách hướng theo nhóm giúp nhóm có thể tối ưu hóa hệ thống Kanban để cải tiến luồng làm việc trơn chu.

Nhóm đo mức độ hiệu quả bằng cách theo dõi chất lượng, thời gian làm sản phẩm, v.v để từ đó có những phân tích, thử nghiệm để thay đổi hệ thống nhằm tăng tính hiệu quả của nhóm

Bảng Kanban – là công cụ để trực quan hóa công việc Bảng Kanban bao gồm các cột tương ứng với trạng thái của công việc và các thẻ đại diện cho các nhiệm vụ.Mỗi công việc khi ở trạng thái nào thì được đặt ở cột tương ứng Chúng ta có thể dùng một bảng vật lý hoặc một phần mềm hỗ trợ Kanban như Trello.

Hình 4: Minh họa một bảng Kanban đơn giản 5.2.4 Thẻ Kanban

Thẻ Kanban là một hình ảnh đại diện cho một hạng mục công việc Được dịch từ tiếng Nhật, nó có nghĩa đen là thẻ (ban) trực quan (kan) Nó là yếu tố cốt lõi của hệ thống Kanban vì nó đại diện cho công việc đã được yêu cầu hoặc đang trong quá trình thực hiện Thẻ Kanban chứa thông tin có giá trị về nhiệm vụ và trạng thái của nó, chẳng hạn như tóm tắt về nhiệm vụ, người chịu trách nhiệm, thời hạn, v.v.

Lập kế hoạch linh hoạt

Một nhóm Kanban sẽ chỉ tập trung vào công việc đang được tiến hành Sau khi nhóm hoàn thành một hạng mục công việc, họ sẽ loại bỏ hạng mục công việc tiếp theo vào phần công việc đang làm Chủ sở hữu sản phẩm có thể tự do sắp xếp lại công việc đang tồn đọng mà không làm gián đoạn nhóm vì bất kỳ thay đổi nào bên ngoài các hạng mục công việc hiện tại đều không ảnh hưởng đến nhóm Miễn là chủ sở hữu sản phẩm giữ nguyên các hạng mục công việc quan trọng nhất trong số các công việc tồn đọng, nhóm phát triển được đảm bảo rằng họ đang mang lại giá trị tối đa cho doanh nghiệp Vì vậy, không cần lặp lại độ dài như Sprint cố định mà bạn thường thấy trong Scrum.

Chu kì thời gian làm việc được rút ngắn lại:

Thời gian chu kỳ là lượng thời gian cần để một đơn vị công việc đi qua quy trình làm việc của nhóm – từ thời điểm công việc bắt đầu cho đến khi hoàn thành Bằng cách tối ưu hóa thời gian chu kỳ, nhóm có thể tự tin dự báo việc phân phối công việc trong tương lai

Trong Kanban, không phải mỗi người nắm giữ một kỹ năng, vì như vậy nếu người đó không hoàn thành tốt công việc thì sẽ sở thành điểm tắc nghẽn trong quy trình làm việc Vì vậy, nhóm Kanban luôn hỗ trợ và bổ sung kỹ năng cho nhau, đảm bảo các thành viên luôn được học hỏi và không chỉ tập trung vào kỹ năng nào Các kỹ năng được chia sẻ có nghĩa là các thành viên trong nhóm có thể đảm nhận công việc không đồng nhất, giúp tối ưu hóa hơn nữa thời gian chu kỳ Điều đó cũng có nghĩa là nếu có bản sao lưu công việc, toàn bộ nhóm có thể tập trung vào đó để quy trình diễn ra suôn sẻ trở lại

Ví dụ: thử nghiệm không chỉ được thực hiện bởi các kỹ sư QA Các nhà phát triển cũng tham gia Trong khuôn khổ Kanban, toàn bộ nhóm đều trách nhiệm đảm bảo công việc diễn ra suôn sẻ trong suốt quá trình. Ít tắc nghẽn hơn:

Việc đa nhiệm đôi lúc có thể gây ra sự thiếu hiệu quả trong công việc do có quá nhiều đầu việc khác nhau trong nhóm Đó là lý do tại sao một nguyên lý chính của Kanban là giới hạn số lượng công việc đang thực hiện (WIP) Giới hạn công việc đang tiến hành giúp tắc nghẽn và tăng dự phòng trong quy trình của nhóm do thiếu tập trung, con người hoặc kỹ năng

Ví dụ: một nhóm phần mềm điển hình có thể có bốn trạng thái quy trình công việc: Việc cần làm, Đang tiến hành, Đánh giá và Hoàn thành Họ có thể chọn đặt giới hạn WIP là 2 cho trạng thái xem xét mã Đó có vẻ là một giới hạn thấp, nhưng có lý do bởi các nhà phát triển thường thích viết mã mới hơn là dành thời gian xem xét công việc của người khác Giới hạn thấp khuyến khích nhóm đặc biệt chú ý đến các vấn đề ở trạng thái xem xét và xem xét hoạt động của những người khác trước khi nâng cao đánh giá mã của riêng họ Điều này sẽ làm giảm thời gian chu kỳ tổng thể.

Một trong những giá trị cốt lõi là tập trung vào việc liên tục cải thiện hiệu suất và hiệu quả của nhóm với mỗi lần lặp lại công việc Trong Kanban, công việc sẽ được theo dõi qua biểu đồ, biểu đồ này cung cấp một cơ chế trực quan cho các nhóm để đảm bảo rằng họ đang liên tục cải thiện Khi nhóm có thể xem dữ liệu, sẽ dễ dàng phát hiện ra các điểm nghẽn trong quy trình (và loại bỏ chúng) Hai báo cáo phổ biến mà đội Kanban sử dụng là biểu đồ kiểm soát và sơ đồ luồng tích lũy.

Scrumban

Scrumban hợp nhất cấu trúc và khả năng dự đoán của Scrum với tính linh hoạt và quy trình làm việc liên tục của Kanban Khi được triển khai đúng cách, Scrumban có thể giúp một nhóm hưởng lợi từ cả bản chất quy định của Scrum và sự tự do của Kanban để cải thiện quy trình của họ.

Scrumban liên quan đến việc áp dụng các nguyên tắc Kanban — hình dung quy trình làm việc và các quy trình linh hoạt — vào khung Scrum của nhóm Tuy nhiên, Scrumban đã loại bỏ một số khía cạnh cứng nhắc hơn của Scrum và để mỗi nhóm tạo ra một cách tiếp cận tùy chỉnh để phát triển.

Dưới đây là hướng dẫn từng bước để phát triển khung Scrumban cho nhóm của bạn.

Bước 1: Phát triển bảng Scrumban

Một bảng Scrumban tương tự như một bảng Kanban Bởi vì bạn sẽ sử dụng nó làm công cụ quy trình làm việc chính của mình, hãy thêm nhiều cột vào bảngScrumban của bạn tùy theo nhóm của bạn cần để đánh dấu từng giai đoạn tiến triển rời rạc Nhưng hãy cẩn thận đừng tạo quá nhiều cột khiến bảng trở nên lộn xộn và khó xem.

Bước 2: Đặt giới hạn công việc đang tiến hành của bạn

Hãy nhớ rằng, Scrum đặt ra cả giới hạn thời gian và nhiệm vụ cho mỗi sprint. Ngược lại, Kanban tập trung vào quy trình làm việc liên tục Bạn sẽ cần thiết lập giới hạn về lượng công việc mà nhóm của bạn có thể đảm nhận tại bất kỳ thời điểm nào Đối với Scrumban, giới hạn đó sẽ là tổng số thẻ trên bảng tại bất kỳ thời điểm nào Đặt ra một giới hạn thực tế để giúp nhóm của bạn không bị quá tải và thất vọng.

Bước 3: Sắp xếp thứ tự ưu tiên của nhóm trên bảng

Bước này minh họa sự khác biệt chính khác giữa Scrum và Kanban (và Scrumban) Với Scrum, bạn sẽ chỉ định nhiệm vụ cho các cá nhân cụ thể trong nhóm nhà phát triển của mình cho mỗi sprint Mặt khác, theo Scrumban, trọng tâm của bạn sẽ là thiết lập thứ tự ưu tiên của tất cả các dự án trong hội đồng quản trị. Nhóm của bạn sẽ quyết định người nào sẽ giải quyết nhiệm vụ nào.

Bước 4: Bỏ thẻ bài poker lên kế hoạch của bạn

Bởi vì mỗi sprint có một giới hạn thời gian nghiêm ngặt và nhóm chỉ có thể làm việc trên một nhóm dự án được xác định trước trong bất kỳ sprint nào, nên nhóm Scrum cần ước tính thời gian mỗi nhiệm vụ phát triển sẽ mất Vì vậy, họ đã nghĩ ra các phương pháp như lập kế hoạch chơi poker để ước tính số điểm cốt truyện (cho biết thời gian và độ khó) cho mỗi nhiệm vụ Với Scrumban, công việc diễn ra liên tục và không giới hạn thời gian, vì vậy nhóm của bạn sẽ không ước tính điểm câu chuyện Bạn sẽ chỉ tập trung vào việc ưu tiên các dự án quan trọng nhất.

Bước 5: Đặt các cuộc họp hàng ngày của bạn

Mặc dù bạn sẽ không có hầu hết các cuộc họp điển hình của khuôn khổ Scrum — lập kế hoạch sprint, đánh giá sprint, hồi cứu — Các cuộc họp Scrumban có thể bao gồm các cuộc họp ngắn để nhóm thảo luận về kế hoạch và thách thức của họ cho ngày sắp tới Các cuộc họp ngắn này cũng là một cách tốt để khuyến khích sự liên kết và gắn kết nhóm vì các nhà phát triển của bạn sẽ dành nhiều thời gian làm việc riêng cho các nhiệm vụ của họ và có thể không có nhiều thời gian để tương tác

Lập kế hoạch poker tập hợp các bên liên quan từ các bộ phận trong tổ chức để đạt được sự đồng thuận về nỗ lực ước tính cần thiết cho một số sáng kiến tồn đọng.Đối với một tổ chức phần mềm linh hoạt, các bên liên quan có thể bao gồm chủ sở hữu sản phẩm, nhà phát triển, nhà thiết kế UX, người kiểm tra chất lượng và người quản lý sản phẩm, trong số những người khác.

Những người tham gia đều được phát một bộ bài (hoặc chip) giống hệt nhau, mỗi bộ có một số khác nhau Một trình tự phổ biến dựa trên việc nhân đôi mỗi số: 1, 2,

4, 8, 16, 32, 64 Trình tự được đề xuất bởi Mike Cohn của Mountain Goat Software, người đã phổ biến việc lập kế hoạch chơi poker để phát triển nhanh nhẹn, là 0, 1, 2,

Các bộ bài có giới hạn, với số lần tăng vọt đáng kể, vì mục tiêu là để tất cả những người tham gia đạt được số lượng đồng thuận cho mỗi câu chuyện Cung cấp cho người tham gia quá nhiều lựa chọn — ví dụ, mỗi số từ 1 đến 50 — sẽ làm cho quá trình không hiệu quả.

Tiếp theo, chủ sở hữu sản phẩm (hoặc có thể là giám đốc sản phẩm) sẽ đọc to từng câu chuyện cho cả nhóm nghe.

Bây giờ mọi người đã nghe hết câu chuyện rồi, cả nhóm cùng thảo luận nhé. Những người tham gia sẽ mô tả cách họ hình dung việc xử lý công việc, số lượng người mà họ ước tính sẽ tham gia, bộ kỹ năng nào sẽ được yêu cầu và nếu có bất kỳ trở ngại nào họ hình dung ra việc chậm tiến độ Nhóm cũng sẽ sử dụng thời gian này để đặt câu hỏi về câu chuyện.

Bước 4: Ước tính và chia sẻ

Sau khi mọi người đã nói và nhận được câu trả lời bất kỳ câu hỏi nào, mỗi người sẽ bí mật chọn một thẻ từ bộ bài để đại diện cho ước tính của họ về điểm câu chuyện Khi tất cả mọi người đã sẵn sàng, tất cả những người tham gia sẽ tiết lộ thẻ của họ cùng một lúc.

Thẻ của người tham gia càng cao, người tham gia đó ước tính câu chuyện sẽ hoàn thành càng khó.

Bước 5: Làm việc hướng tới sự đồng thuận

Nếu tất cả những người tham gia đều tiết lộ cùng một thẻ, thì số đó sẽ trở thành đồng thuận Nhóm có thể chuyển sang câu chuyện tiếp theo.

Nhưng nếu các thẻ khác nhau, thì nhóm tiếp tục thảo luận về câu chuyện Những người có ước tính cao hơn (hoặc thấp hơn) so với phần còn lại của nhóm sẽ giải thích lý do của họ và cố gắng thuyết phục đồng nghiệp thấy vị trí của họ.

Khi nhóm đã kết thúc vòng thảo luận mới này, mọi người sẽ lại xem xét các thẻ của mình và giữ nguyên lựa chọn trước đó hoặc chọn một bài mới Tất cả những người tham gia sẽ lại tiết lộ thẻ của họ cùng một lúc.

Lập kế hoạch Poker bắt nguồn từ đâu?

Extreme Programming

Extreme Programming (XP) là một trong những phương pháp phát triển nhanh tiêu biểu nhất Phương pháp này được đề xuất và áp dụng từ khi các phương pháp phát triển theo Agile còn chưa được phổ biến rộng rãi Xp đã khắc phục những vấn đề gặp phải trong cách tiếp cận truyền thống có chu kì dài không đáp ứng được yêu cầu khách hàng Dựa trên những kinh nghiệm thực tế sẵn xó, cộng với những thành công trong quá trình thử nghiệm, XP đã được tổng quát lên thành lý thuyết với một loạt các nguyên lý và bài học thực tiễn.

- Phản hồi nhanh: Nhanh chóng nhận phản hồi, xử lý và áp dụng sẽ làm tăng tính thích nghi với thay đổi và sửa lỗi nhanh hơn Xử lý phản hồi càng chậm thì việc sửa lỗi hoặc đáp ứng thay đổi càng tốn kém và chứa nhiều rủi ro.

- Giải pháp đơn giản: Coi mọi vấn đề như thể có thể giải quyết nó 1 cách đơn giản nhất Trên thực tế, hầu hết các vấn đề đều có thể giải quyết 1 cách đơn giản. Đôi khi, người ta hay phức tạp hóa vấn đề mà không nghĩ rằng nó có thể giải quyết bằng cách đơn giản hơn.

- Thay đổi dần dần: Cố gắng giữ cho mọi thứ thay đổi từ từ, tránh sự thay đổi lớn tại một thời điểm Một thay đổi lớn có thể được thực hiện qua nhiều thay đổi nhỏ.

- Đối mặt với sự thay đổi: Chấp nhận sự thay đổi là một trong những ưu điểm của Xp so với các phương pháp khác Các yêu cầu sẽ được xem xét và thay đổi để thỏa mãn nhu cầu khách hàng nhằm tạo ra phần mềm tốt nhất

- Chất lượng công việc: Một thành viên được tạo điều kiện để phát huy khả năng của mình một cách tốt nhất Nhấn mạnh làm việc theo nhóm (teamwork) Nhà quản lý, khách hàng,lập trình viên tất cả phải kết hợp với nhau để tạo ra một phần mềm chất lượng

5.4.3 Quy trình phát triển phần mềm XP

- Trước khi phát triển dự án, nhóm phát triển cần đánh giá các yếu tố như nhân lực, công nghệ, thời gian để đảm bảo thực hiện dự án Về phía khách hàng, họ sẽ viết ra những yêu cầu mà họ muốn có trong phiên bản đầu tiên Mỗi yêu cầu tương ứng một chức năng trong chương trình.

- Các thành viên trong dự án cũng làm quen các công cụ và công nghệ mà họ sẽ làm trong dự án.

Kế hoạch tổng thể của dự án được lập trong những tuần đầu tiên Đại diện của khách hàng và các lập trình viên cùng nhau chia dự án thành các phần tăng trưởng nhỏ, ước lượng thời gian và công sức thực hiện chúng và vạch ra lịch trình phát triển cho từng phần tăng trưởng Kế hoạch tổng thể sẽ được điều chỉnh tùy theo tình hình trong các phần sau của dự án đang thực hiện

Mỗi phần tăng trưởng có một kế hoạch thực hiện cụ thể được vạch ra vào đầu mỗi vòng lặp Đội dự án sẽ họp mặt hàng ngày để cập nhật tình hình công việc. Phân tích:

XP không dành riêng một khoảng thời gian cố định ban đầu cho việc phân tích yêu cầu Trái lại, đại diện của khách hàng sẽ ngồi làm việc chung với đội dự án. Người đại diện này không nhất thiết phải là khách hàng thật, chỉ cần là người hiểu rõ nhất các yêu cầu cho sản phẩm Khi cần thông tin, các lập trình viên chỉ việc đến trao đổi trực tiếp với người này. Đối với những yêu cầu khó hiểu, đại diện khách hàng cùng với các tester tạo ra những ví dụ chi tiết gọi là “customer test” Đối với các giao diện đồ họa, đại diện khách hàng cùng đội dự án tạo ra các bản phác thảo trước khi bắt tay vào lập trình. Một số dự án thuê người thiết kế giao diện riêng.

Thiết kế và lập trình:

Trong một dự án XP, thiết kế của sản phẩm được cải tiến liên tục Hoạt động này được thực hiện nhờ phương pháp phát triển dựa trên test (test-driven development hay TDD) TDD gắn kết chặt chẽ các công việc thiết kế, lập trình và test Các lập trình viên phải làm việc theo cặp, một trong hai người viết các dòng lệnh cụ thể còn người kia suy nghĩ về thiết kế của chương trình.

Các lập trình viên tích hợp code vài giờ một lần và đảm bảo rằng phiên bản mới đủ tiêu chuẩn về mặt kỹ thuật để bàn giao ngay cho khách hàng.

Mã nguồn được coi là sở hữu tập thể Mọi người được yêu cầu sửa lỗi bất kể lỗi đó do ai gây ra.

Tất cả các thành viên trong dự án XP đều có trách nhiệm đảm bảo chất lượng sản phẩm Các lập trình viên thực hiện unit test và integration test Đại diện khách hàng kiểm tra công việc của lập trình viên và trợ giúp họ bằng các customer test Khi các tester tìm ra lỗi, cả đội cùng nhau phân tích nguyên nhân và tìm cách cải tiến quy trình để ngăn ngừa lỗi tái diễn.

Tất cả các regression test đều được thực hiện tự động (bởi code mới được tích hợp vào hệ thống một cách liên tục) và được chạy bởi các lập trình viên khi họ làm công việc là tích hợp code mới vào hệ thống dự án đang thực hiện.

Lập trình theo cặp góp phần làm tăng chất lượng công việc.

Hệ thống được trình diễn nội bộ hàng tuần và được bàn giao cho khách hàng theo kế hoạch đã định trước hoặc theo nhu cầu của khách hàng. e Nhận xét

Lean Software Development (LSD)

Lean Software Development (LSD) hay còn gọi là phát triển phần mềm tinh gọn là một trong các phương pháp agile phổ biến nhất trên thế giới Đây là một khuôn khổ linh hoạt dựa trên việc tối ưu hóa thời gian và tài nguyên phát triển, loại bỏ lãng phí và cuối cùng chỉ cung cấp những gì sản phẩm cần Sử dụng cách tiếp cận Lean thường được gọi là chiến lược Sản phẩm khả thi tối thiểu (MVP), trong đó một nhóm phát hành phiên bản tối thiểu nhất của sản phẩm ra thị trường, học hỏi từ người dùng những gì họ thích, không thích và muốn trở thành đã thêm, và sau đó lặp lại dựa trên phản hồi này.

LSD thực sự vay mượn triết lý của mình từ ngành công nghiệp sản xuất, nơi khởi nguồn của quá trình phát triển tinh gọn như một cách để tối ưu hóa dây chuyền sản xuất và lắp ráp nhằm giảm thiểu lãng phí và tối đa hóa giá trị của khách hàng Trên thực tế, ban đầu nó được gọi là Hệ thống sản xuất Toyota, bởi vì nhà sản xuất ô tô

Toyota đã phát minh ra cách tiếp cận này vào giữa thế kỷ XX như một cách để hợp lý hóa việc sản xuất ô tô và loại bỏ thời gian và nguồn lực lãng phí (Bất kỳ hành động nào không ảnh hưởng đến chức năng của chiếc xe đang được chế tạo và giao hàng đều bị coi là lãng phí theo hệ thống này và do đó bị loại bỏ khỏi quy trình.) Cuối cùng, các tổ chức sản xuất khác trong nhiều ngành đã bắt đầu sử dụng hệ thống này và tên gọi sau đó đã thay đổi sang Lean Phương pháp này lần đầu tiên được áp dụng cho việc tạo ra phần mềm vào năm 2003 với việc xuất bản cuốn sách nổi tiếng hiện nay là Lean Software Development.

5.5.2 Nguyên tắc của Learn Software Development

Nguyên tắc 1: Eliminate waste - loại bỏ sự dư thừa

Triết lý tinh gọn coi mọi thứ không gia tăng giá trị cho khách hàng đều là chất thải (muda) Lãng phí đó có thể bao gồm:

1 Công việc đã hoàn thành một phần

2 Các quy trình bổ sung

8 Hoạt động quản lý (Management activities)

Nghiên cứu ngành cho thấy những lãng phí phát triển phần mềm này:

1 Xây dựng sai tính năng hoặc sản phẩm

2 Quản lý sai công việc

3 Làm lại các giải pháp phức tạp không cần thiết

4 Tải trọng nhận thức không liên quan

8 Giao tiếp không hiệu quả. Để loại bỏ lãng phí, người ta phải có thể nhận ra nó Nếu một số hoạt động có thể bị bỏ qua hoặc kết quả có thể đạt được mà không có nó thì thật lãng phí Mã hóa được thực hiện một phần cuối cùng bị bỏ rơi trong quá trình phát triển là lãng phí Các quy trình bổ sung như thủ tục giấy tờ và các tính năng không được khách hàng thường xuyên sử dụng là lãng phí Chuyển đổi mọi người giữa các nhiệm vụ là lãng phí Chờ đợi các hoạt động, nhóm, quy trình khác là lãng phí Chuyển động cần thiết để hoàn thành công việc là lãng phí Những khiếm khuyết và chất lượng thấp hơn là chất thải Chi phí quản lý không tạo ra giá trị thực là lãng phí Kỹ thuật lập bản đồ dòng giá trị được sử dụng để xác định lãng phí Bước thứ hai là chỉ ra các nguồn chất thải và loại bỏ chúng Việc loại bỏ chất thải phải được thực hiện lặp đi lặp lại cho đến khi các quy trình và thủ tục dường như thiết yếu được thanh lý. Nguyên tắc 2: Amplify learning – Khuyếch đại học tập

Phát triển phần mềm là một quá trình học hỏi liên tục dựa trên các lần lặp lại khi viết mã Thiết kế phần mềm là một quá trình giải quyết vấn đề liên quan đến việc các nhà phát triển viết mã và những gì họ đã học được Giá trị phần mềm được đo lường phù hợp với việc sử dụng và không phù hợp với các yêu cầu Thay vì thêm nhiều tài liệu hoặc lập kế hoạch chi tiết, có thể thử các ý tưởng khác nhau bằng cách viết mã và xây dựng Quá trình thu thập yêu cầu của người dùng có thể được đơn giản hóa bằng cách hiển thị màn hình cho người dùng cuối và nhận thông tin đầu vào của họ Sự tích tụ các khuyết tật nên được ngăn chặn bằng cách chạy các bài kiểm tra ngay sau khi mã được viết Quá trình học tập được đẩy nhanh bằng cách sử dụng các chu kỳ lặp lại ngắn - mỗi chu kỳ được kết hợp với kiểm tra tích hợp và tái cấu trúc Việc tăng cường phản hồi thông qua các phiên phản hồi ngắn với khách hàng giúp xác định giai đoạn phát triển hiện tại và điều chỉnh nỗ lực để cải thiện trong tương lai Trong các phiên họp ngắn đó, cả đại diện khách hàng và nhóm phát triển đều tìm hiểu thêm về vấn đề miền và tìm ra các giải pháp khả thi để phát triển thêm Do đó, khách hàng hiểu rõ hơn nhu cầu của họ, dựa trên kết quả hiện có của các nỗ lực phát triển, và các nhà phát triển học cách đáp ứng tốt hơn những nhu cầu đó Một ý tưởng khác trong quá trình giao tiếp và học hỏi với khách hàng là phát triển dựa trên thiết lập - điều này tập trung vào việc truyền đạt những hạn chế của giải pháp tương lai chứ không phải các giải pháp khả thi, do đó thúc đẩy sự ra đời của giải pháp thông qua đối thoại với khách hàng

Nguyên tắc 3: Quyết định càng muộn càng tốt

Vì phát triển phần mềm luôn gắn liền với một số sự không chắc chắn, nên đạt được kết quả tốt hơn với cách tiếp cận dựa trên tập hợp hoặc dựa trên tùy chọn, trì hoãn các quyết định càng nhiều càng tốt cho đến khi chúng có thể được đưa ra dựa trên sự kiện chứ không phải dựa trên các giả định và dự đoán không chắc chắn Hệ thống càng phức tạp thì càng phải xây dựng nhiều khả năng thay đổi, do đó có thể tạo điều kiện trì hoãn các cam kết quan trọng và cốt yếu.

Cách tiếp cận lặp đi lặp lại thúc đẩy nguyên tắc này - khả năng thích ứng với những thay đổi và sửa chữa sai lầm, có thể rất tốn kém nếu được phát hiện sau khi phát hành hệ thống Với phát triển dựa trên bộ: Ví dụ: nếu cần một hệ thống phanh mới cho ô tô, ba đội có thể thiết kế các giải pháp cho cùng một vấn đề Mỗi nhóm tìm hiểu về không gian vấn đề và thiết kế một giải pháp tiềm năng Như một giải pháp được cho là không hợp lý, nó đã được cắt giảm.

Vào cuối một giai đoạn, các thiết kế còn tồn tại được so sánh và một thiết kế được chọn, có lẽ với một số sửa đổi dựa trên việc học hỏi từ những thiết kế khác - một ví dụ tuyệt vời về việc trì hoãn cam kết cho đến thời điểm cuối cùng có thể. Các quyết định về phần mềm cũng có thể được hưởng lợi từ thực tiễn này để giảm thiểu rủi ro do thiết kế trước lớn mang lại

Ngoài ra, sau đó sẽ có nhiều triển khai hoạt động chính xác, nhưng lại khác nhau (triển khai nội bộ, khôn ngoan) Chúng có thể được sử dụng để triển khai các hệ thống chịu lỗi kiểm tra tất cả các đầu vào và đầu ra về tính đúng đắn, trên nhiều triển khai, đồng thời Một cách tiếp cận phát triển phần mềm nhanh có thể di chuyển việc xây dựng các tùy chọn sớm hơn cho khách hàng, do đó trì hoãn một số quyết định quan trọng nhất định cho đến khi khách hàng nhận ra nhu cầu của họ tốt hơn Điều này cũng cho phép thích ứng sau này với những thay đổi và ngăn ngừa các quyết định tốn kém về công nghệ trước đó. Điều này không có nghĩa là không nên tham gia vào việc lập kế hoạch - ngược lại, các hoạt động lập kế hoạch nên được tập trung vào các lựa chọn khác nhau và thích ứng với tình hình hiện tại, cũng như làm rõ các tình huống khó hiểu bằng cách thiết lập các mẫu cho hành động nhanh chóng Việc đánh giá các lựa chọn khác nhau có hiệu quả ngay khi nhận ra rằng chúng không miễn phí, nhưng cung cấp sự linh hoạt cần thiết cho việc đưa ra quyết định muộn.

Nguyên tắc 4: Cung cấp càng nhanh càng tốt

Trong thời đại công nghệ phát triển nhanh chóng, nó không phải là lớn nhất tồn tại, mà là nhanh nhất Sản phẩm cuối cùng được giao càng sớm mà không có khuyết tật lớn, thì phản hồi càng sớm có thể nhận được và kết hợp vào lần lặp tiếp theo Thời gian lặp lại càng ngắn thì khả năng học hỏi và giao tiếp trong nhóm càng tốt Với tốc độ, các quyết định có thể bị trì hoãn Tốc độ đảm bảo đáp ứng nhu cầu hiện tại của khách hàng chứ không phải những gì họ yêu cầu ngày hôm qua Điều này giúp họ có cơ hội trì hoãn việc quyết định về những gì họ thực sự yêu cầu cho đến khi họ có được kiến thức tốt hơn Khách hàng coi trọng việc cung cấp nhanh chóng một sản phẩm chất lượng Tư tưởng sản xuất đúng lúc có thể được áp dụng cho phát triển phần mềm, nhận biết các yêu cầu và môi trường cụ thể của nó Điều này đạt được bằng cách trình bày kết quả cần thiết và để nhóm tự tổ chức và phân chia nhiệm vụ để đạt được kết quả cần thiết cho một lần lặp cụ thể Khi bắt đầu, khách hàng cung cấp thông tin đầu vào cần thiết Điều này có thể được trình bày đơn giản trong các thẻ hoặc câu chuyện nhỏ - các nhà phát triển ước tính thời gian cần thiết để thực hiện mỗi thẻ Do đó, tổ chức công việc thay đổi thành hệ thống tự kéo - mỗi sáng trong cuộc họp trực tiếp, mỗi thành viên trong nhóm đánh giá những gì đã làm ngày hôm qua, những gì phải làm hôm nay và ngày mai, và nhắc nhở mọi đầu vào cần thiết từ đồng nghiệp hoặc khách hàng Điều này đòi hỏi sự minh bạch của quy trình, điều này cũng có lợi cho giao tiếp của nhóm.

Nguyên tắc 5: Trao quyền cho nhóm Đã có một niềm tin truyền thống trong hầu hết các doanh nghiệp về việc ra quyết định trong tổ chức - các nhà quản lý nói với người lao động cách thực hiện công việc của họ Trong "kỹ thuật Work-Out", các vai trò sẽ được thay đổi - các nhà quản lý được dạy cách lắng nghe các nhà phát triển, để họ có thể giải thích rõ hơn những hành động có thể được thực hiện, cũng như đưa ra các đề xuất để cải tiến.

Cách tiếp cận tinh gọn tuân theo Nguyên tắc Agile "tìm những người giỏi và để họ làm công việc của riêng họ", khuyến khích sự tiến bộ, bắt lỗi và loại bỏ những trở ngại, nhưng không quản lý vi mô Một quan niệm sai lầm khác là coi con người là tài nguyên Mọi người có thể là nguồn lực từ quan điểm của một bảng dữ liệu thống kê, nhưng trong phát triển phần mềm, cũng như bất kỳ doanh nghiệp tổ chức nào, mọi người cần một thứ gì đó hơn chỉ là danh sách các nhiệm vụ và đảm bảo rằng họ sẽ không bị xáo trộn trong quá trình hoàn thành của các nhiệm vụ

Mọi người cần động lực và mục đích cao hơn để làm việc vì mục đích trong thực tế có thể đạt được, với sự đảm bảo rằng nhóm có thể lựa chọn các cam kết của riêng mình Các nhà phát triển nên được cung cấp quyền truy cập vào khách hàng; trưởng nhóm cần hỗ trợ và giúp đỡ trong những tình huống khó khăn, cũng như đảm bảo rằng sự hoài nghi không làm hỏng tinh thần của nhóm.

Nguyên tắc 6: Xây dựng toàn vẹn trong trọng tâm

Khách hàng cần có trải nghiệm tổng thể về Hệ thống Đây là cái gọi là tính toàn vẹn được nhận thức: cách nó được quảng cáo, phân phối, triển khai, truy cập, cách sử dụng trực quan, giá cả và cách nó giải quyết các vấn đề Tính toàn vẹn về mặt khái niệm có nghĩa là các thành phần riêng biệt của hệ thống hoạt động tốt cùng nhau với sự cân bằng giữa tính linh hoạt, khả năng bảo trì, hiệu quả và khả năng đáp ứng Điều này có thể đạt được bằng cách hiểu miền vấn đề và giải quyết nó cùng một lúc, không phải tuần tự Thông tin cần thiết được nhận theo từng đợt nhỏ - không phải trong một đoạn lớn - tốt nhất là bằng cách trao đổi trực tiếp chứ không phải bất kỳ tài liệu nào bằng văn bản Luồng thông tin phải liên tục theo cả hai hướng - từ khách hàng đến nhà phát triển và ngược lại, do đó tránh được lượng lớn thông tin căng thẳng sau quá trình phát triển dài cô lập Một trong những cách lành mạnh hướng tới kiến trúc tích hợp là tái cấu trúc Khi nhiều tính năng được thêm vào cơ sở mã ban đầu, thì việc bổ sung các cải tiến hơn nữa càng trở nên khó khăn hơn Tái cấu trúc là giữ cho sự đơn giản, rõ ràng, số lượng tính năng tối thiểu trong mã Sự lặp lại trong mã là dấu hiệu của thiết kế mã xấu và nên tránh Quá trình xây dựng hoàn chỉnh và tự động phải đi kèm với một bộ kiểm tra nhà phát triển và khách hàng hoàn chỉnh và tự động, có cùng phiên bản, đồng bộ hóa và ngữ nghĩa như trạng thái hiện tại của Hệ thống Cuối cùng, tính toàn vẹn cần được xác minh bằng thử nghiệm kỹ lưỡng, do đó đảm bảo Hệ thống thực hiện những gì khách hàng mong đợi Các bài kiểm tra tự động cũng được coi là một phần của quá trình sản xuất, và do đó nếu chúng không tạo thêm giá trị thì chúng sẽ bị coi là lãng phí. Kiểm tra tự động không nên là một mục tiêu, mà là một phương tiện để kết thúc, cụ thể là giảm thiểu các khuyết tật.

Nguyên tắc 7: Nhìn toàn bộ

Hệ thống phần mềm ngày nay không chỉ đơn giản là tổng thể các bộ phận của chúng mà còn là sản phẩm của các tương tác giữa chúng Các khiếm khuyết trong phần mềm có xu hướng tích tụ trong quá trình phát triển - bằng cách phân chia các nhiệm vụ lớn thành các nhiệm vụ nhỏ hơn và bằng cách tiêu chuẩn hóa các giai đoạn phát triển khác nhau, nguyên nhân gốc rễ của các khiếm khuyết cần được tìm ra và loại bỏ Hệ thống càng lớn, càng có nhiều tổ chức tham gia vào quá trình phát triển của nó và càng có nhiều bộ phận được phát triển bởi các nhóm khác nhau, thì tầm quan trọng của việc xác định rõ mối quan hệ giữa các nhà cung cấp khác nhau, để tạo ra một hệ thống với các thành phần tương tác nhịp nhàng Trong thời gian phát triển dài hơn, mạng lưới nhà thầu phụ mạnh hơn có lợi hơn nhiều so với việc tối ưu hóa lợi nhuận ngắn hạn, điều này không cho phép các mối quan hệ đôi bên cùng có lợi Tư duy tinh gọn phải được hiểu rõ bởi tất cả các thành viên của một dự án, trước khi thực hiện trong một tình huống cụ thể, thực tế "Nghĩ lớn, hành động nhỏ, thất bại nhanh; học hỏi nhanh chóng" - những khẩu hiệu này tóm tắt tầm quan trọng của việc hiểu lĩnh vực này và sự phù hợp của việc thực hiện các nguyên tắc tinh gọn trong toàn bộ quá trình phát triển phần mềm Chỉ khi tất cả các nguyên tắc tinh gọn được thực hiện cùng nhau, kết hợp với “ý thức chung” mạnh mẽ về môi trường làm việc, thì mới có cơ sở để thành công trong phát triển phần mềm.

5.5.3 Điểm mạnh và điểm yếu của Learn Software Development Điểm mạnh:

Phương pháp tiếp cận hợp lý cho phép cung cấp nhiều chức năng hơn trong thời gian ngắn hơn.

Loại bỏ hoạt động không cần thiết và do đó có thể giảm chi phí.

Trao quyền cho nhóm phát triển để đưa ra quyết định, điều này cũng có thể thúc đẩy tinh thần Điểm yếu:

Phụ thuộc nhiều vào nhóm tham gia, khiến nó không có khả năng mở rộng như các khuôn khổ khác.

Phụ thuộc vào tài liệu mạnh và nếu không làm như vậy có thể dẫn đến sai lầm khi phát triển

Có nên học tập và ứng dụng LSD trong phát triển phần mềm?

Crystal

5.6.1 Giới Thiệu Được giới thiệu bởi Alistair Cockburn, Crystal Method, là một tập hợp các phương pháp phát triển phần mềm Agile, tập trung chủ yếu vào con người và sự tương tác giữa họ trong khi họ làm việc trong một dự án phát triển phần mềm. Ngoài ra còn có trọng tâm là kinh doanh-trọng yếu và ưu tiên kinh doanh của hệ thống đang phát triển Không giống như các phương pháp phát triển truyền thống, Crystal không cố định các công cụ và kỹ thuật phát triển, mà giữ con người và quy trình làm cốt lõi của quá trình phát triển Tuy nhiên, không chỉ con người hay quy trình mới là quan trọng, mà sự tương tác giữa hai bên mới là quan trọng nhất.

Theo cách nói của Cockburn, "Crystal là một nhóm các phương pháp phát triển phần mềm 'thích ứng, siêu nhẹ,' do con người cung cấp."

Vậy, "sức người, khả năng thích ứng, siêu nhẹ," co giãn để vừa vặn "" có nghĩa là gì?

 Crystal là “do con người cung cấp” —Điều này có nghĩa là con người là khía cạnh quan trọng nhất của Crystal, và tất cả các quy trình và công cụ đều liên quan đến chúng Crystal tin rằng phát triển phần mềm về cơ bản là một hoạt động của con người, vì vậy những người tham gia vào hoạt động này là rất quan trọng trong khi các quy trình phải được mô hình hóa để đáp ứng các yêu cầu của nhóm chứ không phải ngược lại Crystal nhấn mạnh rằng các nhóm phát triển có khả năng tự cung cấp và tự tổ chức, vì vậy họ có khả năng sắp xếp hợp lý các quy trình khi quá trình phát triển tiến triển và trở nên có tổ chức và năng lực hơn.

 Crystal là “thích nghi” —Trước hết, cần nhớ rằng Crystal không phải là một tập hợp các công cụ và kỹ thuật được quy định để phát triển phần mềm; đúng hơn, nó là một cách tiếp cận Vì vậy, các quy trình và công cụ không cố định mà phải được điều chỉnh cho phù hợp với yêu cầu và đặc điểm của dự án Nói cách khác, Crystal là một phương pháp luận “kéo dài để phù hợp”, bởi vì mỗi dự án là duy nhất và yêu cầu các phương pháp phù hợp với yêu cầu kinh doanh và đáp ứng các yêu cầu kỹ thuật của dự án.

 Tinh thể là “siêu nhẹ” —Crystal được biết đến như một “phương pháp luận nhẹ” Điều này là do Crystal không ủng hộ quá nhiều tài liệu, quản lý chi phí và báo cáo Thay vào đó, nó tin vào việc giữ mọi thứ nhẹ nhàng và tập trung vào việc phát triển phần mềm chức năng và có giá trị kinh doanh Đối với điều này, các nhóm theo phương pháp Crystal làm việc hướng tới việc tăng cường giao tiếp tự do và cởi mở giữa các thành viên trong nhóm cũng như thiết lập luồng thông tin minh bạch giữa các nhà phát triển và các bên liên quan.

Như đã nêu ở trên, Crystal không phải là một tập hợp các công cụ và phương pháp phát triển được quy định, mà là một nhóm các phương pháp phát triển khác nhau Khi bắt đầu dự án, các quy trình và công cụ không cố định mà được quyết định bằng cách xem xét các yêu cầu kinh doanh và nhu cầu kỹ thuật của dự án Khi quyết định xem Crystal có phải là phương pháp luận phù hợp cho một dự án hay không, hãy cân nhắc sự thoải mái, tiền bạc tùy ý, tiền bạc và cuộc sống thiết yếu cùng với quy mô của nhóm làm việc trong một dự án cụ thể Các phương pháp luận khác nhau trong họ Pha lê được gọi là các “trọng số” khác nhau của phương pháp Tinh thể và được biểu thị bằng các màu sắc khác nhau của quang phổ.

Do đó, họ phương pháp luận Pha lê bao gồm các biến thể sau: Crystal Clear, Crystal Yellow, Crystal Orange, Crystal Orange Web, Crystal Red, Crystal Maroon, Crystal Diamond và Crystal Sapphire Để làm rõ, Crystal Clear thích hợp hơn cho các dự án tương đối ngắn hạn được quản lý bởi một nhóm sáu nhà phát triển làm việc trong một không gian làm việc duy nhất, trong khi Crystal Orange phù hợp cho các dự án yêu cầu một nhóm từ 10 đến 40 thành viên và có tuổi thọ 1-2 năm Mặt khác, phương pháp Crystal Sapphire hoặc Crystal Diamond được sử dụng trong các dự án lớn có nguy cơ tiềm ẩn đến tính mạng con người Do đó, trọng số của phương pháp Crystal được xác định bởi môi trường dự án và quy mô nhóm.

Các phương pháp chính được Crystal đề xuất là gì?

Crystal chính xác về một số thực hành nhất định bởi vì đây là những yếu tố quan trọng để thực hiện thành công phương pháp Crystal cho bất kỳ dự án nào Những thực hành này bao gồm:

 Phương pháp tiếp cận phát triển lặp đi lặp lại và gia tăng — Dự án được phát triển theo các bước lặp lại thường được đóng hộp thời gian Tính năng được cung cấp vào cuối một lần lặp được tích hợp vào hệ thống tổng thể Phản hồi của người dùng được thực hiện khi kết thúc một lần lặp được sử dụng để lập kế hoạch cho lần lặp tiếp theo; và, các tính năng mới và bổ sung được thêm vào mỗi lần lặp lại tiếp theo Tất cả điều này dẫn đến việc tinh chỉnh và hoàn thiện phần mềm tổng thể.

 Sự tham gia tích cực của người dùng — Đây là điều bắt buộc vì Crystal là cách tiếp cận lấy con người làm trung tâm và nhấn mạnh tính minh bạch Vì vậy, người dùng không chỉ tích cực tham gia mà còn thường xuyên được thông báo về tiến độ của dự án.

 Thực hiện đúng cam kết — Nhóm nỗ lực để đảm bảo cung cấp thường xuyên các chức năng được khách hàng đánh giá cao, có thể thay đổi được Đó là kết thúc mà Crystal tuân theo một cách tiếp cận phát triển lặp đi lặp lại và gia tăng.

Phương pháp Crystal xác định một số vai trò: Nhà tài trợ dự án, Nhà thiết kế / Lập trình viên cao cấp, Nhà thiết kế / Lập trình viên (Nhà thiết kế hạng thương gia, Lập trình viên, Nhà tài liệu phần mềm và Người kiểm tra đơn vị) và Người dùng. Ngoài ra, còn có một số vai trò khác như Kiến trúc sư, Điều phối viên, Người thu thập yêu cầu, Chuyên gia kinh doanh, Nhà phân tích / nhà thiết kế kinh doanh, Quản lý dự án, Cố vấn thiết kế, Chuyên gia sử dụng, Lập trình viên thiết kế chính, Nhà thiết kế giao diện người dùng, Người hỗ trợ kỹ thuật và Người viết kỹ thuật.

SO SÁNH

So sánh Scrum với mô hình phát triển phần mềm truyền thống

So sánh phát triển theo mô hình truyền thống và phát triển theo Agile:

Phát triển theo kế hoạch Phát triển theo agile

Phát triển theo kế hoạch đã dự định trước: Hạn chế sự thay đổi từ khách hàng.

Bởi nếu thay đổi thì sẽ tốn nhiều chi phí, thời gian và sức lực.

Phát triển không nhất thiết phải theo kế hoạch mà có thể thay đổi nếu hợp lí Khuyến khích khách hàng thay đổi để tạo ra phần mềm tốt hơn Quan trọng nhất vẫn là chất lượng phần mềm. Ít cho khách hàng xem trước sản phẩm.

Thường khách hàng chỉ được xem phần đặc tả yêu cầu, nếu khách hàng đồng ý thì tiến hành các giai đoạn khác Thông thường khách hàng chỉ được tiếp xúc với sản phẩm khi đã hoàn thiện Chính vì vậy, lúc đó nếu không phù hợp với yêu cầu khách hàng sẽ rất khó thay đổi.

Thường xuyên cho khách hàng xem trước sản phẩm Bên thực hiện dự án sẽ trao đổi bàn giao với khách hàng 1 tuần 1 lần để dễ dàng đáp ứng với thay đổi Khi khách hàng có yêu cầu thay đổi cả hai bên sẽ cùng bàn bạc.

Các giai đoạn phát triển tách biệt: Sản phẩm của mỗi giai đoạn được lập kế hoạch từ trước.

Các hoạt động phát triển được thực hiện xen kẽ

Các thành viên trong nhóm thực hiện dự án làm việc độc lập, ít trao đổi với nhau.

Các thành viên trong nhóm thường xuyên trao đổi thông tin và giúp đỡ lẫn nhau.Thậm chí, khi lập trình còn có lập trình theo đôi, một người phác thảo ý tưởng, còn một người sẽ viết code.

Không nhất thiết chỉ dành cho mô hình thác nước, mô hình phát triển tăng dần cũng sử dụng được Nghĩa là có thể tận dụng mô hình này cho mô hình khác

Sản phẩm cần thực hiện được quyết định bởi thương thuyết trong quá trình phát triển

Phương pháp phát triển phần mềm theo hướng Agile đôi khi bị đánh giá là thiếu tính kỉ luật so với các phương pháp truyền thống Nhưng nhận xét như vậy là không chính xác và thể hiện sự thiếu hiểu biết tường tận vê mô hình Để hiểu về vấn đề một cách đúng đắn, ta có thể hình dung rằng những phương pháp phát triển phần mềm hiện có nằm trên một trục đi từ “ khả năng thích ứng” tới “khả năng dự đoán trước” thì phương pháp linh hoạt hướng đến khả năng thích.

6.1.2 Scrum và Mô hình thác nước (Waterfall)

Là một nhà quản lí dự án, chắc hẳn bạn không còn xa lạ gì với 2 phương pháp phổ biến Waterfall và Scrum (Agile) Tuy nhiên, bạn có chỉ mới nghe tên về chúng hay bạn thực sự hiểu rõ bản chất của chúng Hãy cùng đọc các thông tin dưới đây để hiểu được ưu, nhược điểm của mỗi phương pháp, cũng như chúng sẽ thích hợp với những loại dự án nào:

Các nhà quản lí dự án đã tranh luận rất nhiều về chủ đề "Phương pháp quản lí dự án nào vượt trội hơn?" và lí do đằng sau đó là gì Mặc dù thực sự thì, không có cái gọi là "Phương pháp quản lí dự án tốt nhất".

Xuất phát điểm của mọi phương pháp quản lí dự án đều có mục đích là để giải quyết một vấn đề cụ thể của một dự án cụ thể với những yêu cầu cụ thể, cần được xem xét trên cả đặc thù và tuổi thọ của dự án này Điều này nghĩa là phương pháp được sử dụng để xử lý một dự án sẽ dựa trên các yêu cầu, vòng đời và mục đích cuối cùng của dự án đặc thù nào đó.

Hôm nay, chúng ta sẽ cùng so sánh hai phương pháp quản lí dự án là Waterfall và Agile, tìm hiểu ưu, nhược điểm của mỗi phương pháp, cũng như chúng sẽ thích hợp với những loại dự án nào.

“WATERFALL” Đối với các nhà quản lí dự án, phương pháp Waterfall là phương pháp đơn giản nhất để tiếp cận một dự án bất kỳ Waterfall là phương pháp quản lý dự án liên tiếp, trong đó mỗi giai đoạn của dự án (như nghiên cứu tính khả thi, lập kế hoạch, thiết kế, xây dựng, kiểm tra, sản xuất và bảo trì) phải được hoàn thành trước khi chuyển sang giai đoạn kế tiếp, giống như một thác nước vậy Ý tưởng của phương pháp này bắt nguồn từ quy trình công việc tiêu chuẩn trong ngành xây dựng và ngành sản xuất, vì các dự án trong hai ngành này đều có cách tiếp cận cố định, theo cấu trúc và theo từng giai đoạn một.

Waterfall được biết đến và yêu thích nhờ vào tính đơn giản và dễ sử dụng. Phương pháp này được dùng chủ yếu cho các dự án đơn giản, không thay đổi trong suốt quá trình thực hiện. ƯU ĐIỂM CỦA PHƯƠNG PHÁP WATERFALL:

Dễ dàng theo dõi và quản lý: Vì Waterfall rất đơn giản, có cùng cấu trúc và cách tiếp cận ở mọi giai đoạn, nên dù dự án bạn đang thực hiện là gì, bạn vẫn thấy dễ hiểu, dễ theo dõi và dễ quản lý Bạn không cần phải có kiến thức hay hiểu biết trước nào về một trong các phương pháp quản lý dự án hàng đầu trước khi bắt đầu làm việc với Waterfall Nó cũng rất cứng nhắc trong vấn đề về các thành phẩm và bản sửa đổi (mỗi giai đoạn đều có một danh sách cụ thể các công việc / hoạt động / cột mốc cần được thực hiện trước khi chuyển sang giai đoạn tiếp theo), vì vậy dự án rất dễ để kiểm soát. Ít rủi ro hơn – Mỗi giai đoạn của Waterfall đều đòi hỏi một lượng công việc nhất định cần hoàn thành và kiểm tra lại, nhờ đó bạn sẽ có thêm cơ hội để tìm kiếm, sửa chữa các sai sót / vấn đề và khắc phục chúng tại chỗ, trước khi sang đến giai đoạn kế tiếp.

Tài liệu hóa mọi thứ - Waterfall chú trọng vào tài liệu trong từng giai đoạn, giúp bạn dễ dàng truyền đạt cách tiếp cận của mình đến khách hàng và các bên liên quan. Hơn nữa, khách hàng có thể tham khảo tài liệu mỗi khi họ cần thêm thông tin chi tiết (như các thông tin về chi phí, qui mô, thời gian, v.v ).

NHƯỢC ĐIỂM CỦA PHƯƠNG PHÁP WATERFALL:

Không thể thực hiện thay đổi dễ dàng – Một khi giai đoạn của dự án đã hoàn thành, rất khó khăn, tốn kém để quay lại và thay đổi giai đoạn đó khi cần thiết Ví dụ, khi một nhóm phát triển phần mềm thiết kế ra một sản phẩm, họ nhận thấy rằng một tính năng bị thiếu, do đó họ bị buộc phải quay lại, bắt đầu lại từ đầu để thêm vào tính năng này.

So sánh Scrum với 1 số phương pháp Agile khác

6.2.1 So sánh Scrum và Kanban

Giống như phương pháp Scrum, Kanban cũng dùng Bảng Kanban và chia công việc thành những phần nhỏ Trong khi phương pháp Scrum giới hạn thời gian cho phép để hoàn thành một công việc cụ thể (sprint) thì Kanban giới hạn số lượng công việc cho phép trong một điều kiện nhất định (bao gồm nhiều task trên một thẻ

Kanban và trên To do list – chỉ định rõ phải nhận bộ phận, chi tiết hay nguyên liệu nào từ trạm trước nó với số lượng bao nhiêu)

Scrum và Kanban giống nhau ở điểm gì?

 Cả hai phương pháp Scrum và Kanban đều chia nhỏ các task lớn và phức tạp thành những đoạn nhỏ và hoàn thành theo một quy trình nhất định.

 Cả hai phương pháp thúc đẩy cải tiến liên tục, tối ưu hóa công việc và quá trình.

 Cả hai phương pháp đều tập trung vào dòng chảy công việc để khuyến khích các thành viên tham gia vào quy trình

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

Phương pháp Scrum là giải pháp tốt nhất cho sản phấm và phát triển dự án. Kanban là giải pháp tốt nhất để hỗ trợ sản xuất Sự khác nhau giữa phương pháp Scrum và Kanban là triết lý đằng sau và các ứng dụng thực tế của Scrum và Kanban Có rất nhiều lí do khác nhau tuy nhiên có 3 điểm khác biệt lớn như sau:

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

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

Bất kỳ việc nào ngoài phạm vi công việc mà họ đã cam kết sẽ được đưa vào sprint sau Sau đó, mỗi hai tuần (hoặc tùy theo giai đoạn sprint) các nhóm sẽ cho ra một sản phẩm hoàn thiện sẵn sàng chuyển giao cho khách hàng Sau đó các biên sẽ họp cải tiến (một trong những đặc điểm của phương pháp Scrum) để thảo luận về việc tối ưu hóa quá trình, và chuyển sang sprint tiếp theo Quá trình này được lặp đi lặp lại và cho phép ước tính chính xác dòng chảy công việc và quản lý dự án hiệu quả.

Nhóm Kanban không có khung thời gian (time box) hay quy trình lặp đi lặp lại.

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

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

Trong một nhóm Scrum, có ít nhất ba bên được phép chỉ định xử lý công việc:

PO, Scrum Master và nhóm phát triển Mỗi bên bị ràng buộc bởi về trách nhiệm riêng biệt và họ phải làm việc cùng nhau để đạt được một sự cân bằng giữa yêu cầu và sản phẩm cuối Nhóm Scrum bắt buộc là nhóm liên chức năng, hay nói cách khác nhóm Scrum phải có tất cả các nguồn lực cần thiết để hoàn thành công việc.Với phương pháp Kanban, không có quy định nào về vai trò Có thể hiểu là một người sẽ đảm nhận vai trò như người quản lý dự án hoặc giám sát, đặc biệt là đối với các dự án Kanban có quy mô lớn và phức tạp thì không có bất cứ quy định về các vai trò Một nhóm Kanban không nhất thiết phải là nhóm liên cá nhân như phương pháp Scrum.

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

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

Trên một bảng Kanban, các cột tương tự được dán nhãn để hiển thị trạng thái flow of work Tuy nhiên khác biệt ở chỗ có sự giới hạn về số lượng tối đa cho phép của mỗi cột tại bất kỳ thời điểm nào và hạn chế khả năng thực thi mỗi task.

Vì mỗi cột có một số giới hạn khác nhau và không yêu cầu thời gian (như sprint),nên không có lý do để lặp lại quy trình như phương pháp Scrum Tiến trình sẽ tiếp tục chạy với những task mới được bổ sung khi cần thiết và được đánh giá lại nếu cần.

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

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

6.2.2 So sánh Scrum và Extreme Programming (XP)

Scrum & Extreme Programming (XP) đều là các Agile framework, đều hướng tới việc xây dựng sản phẩm với release cycle ngắn hơn, chất lượng sản phẩm tốt hơn, & tăng khả năng tự quản lý (self-managed) của development team dựa trên các nguyên tắc cơ bản của Agile.

Cả 2 framework đều phát triển dựa trên các sprint, mỗi sprint có độ dài cố định, có sprint backlog, sprint goal & bao gồm các hoạt động Agile như daily meeting,sprint planning, sprint retro, sprint review Tuy nhiên, XP củng cố chất lượng sản phẩm bằng việc áp dụng nhiều development practices trong quy trình phát triển,như TDD, pair programming, refactoring.

 Các khác biệt cơ bản

Sự khác biệt cơ bản giữa Scrum & XP có thể được tổng hợp như sau

Một sprint có thể kéo dài 1-4 tuần

Một sprint chỉ kéo dài 1-2 tuần.

XP chú trọng việc release nhanh & liên tục

Khả năng thay đổi sprint backlog

Hạn chế tối đa các thay đổi xảy ra sau khi đã kết thúc Sprint Planning & Sprint Goal đã được đề ra

Sprint backlog item có thể thay đổi, thêm/bớt, miễn sao development team chưa làm tới; backlog item được thêm mới phải có độ lớn tương đương với backlog item cũ Độ ưu tiên của

Story ảnh hưởng tới thứ tự thực hiện

PO đưa ra độ ưu tiên cho từng User Story, nhưng development team sẽ tự quyết định thứ tự thực hiện trong Sprint, miễn đạt được Sprint Goal

Thứ tự phát triển phải theo đúng thứ tự ưu tiên của User Story do PO/Khách hàng đề ra Áp dụng program ming practices

Không yêu cầu bắt buộc development team phải tuân theo bất cứ programming practices nào cụ thể

Yêu cầu chặt chẽ về việc tuân thủ programming practices để đảm bảo chất lượng sản phẩm & khả năng deliver liên tục (Continuous