Tin tức mới
Home » Quy trình » Tích hợp liên tục trong phương pháp phát triển linh hoạt (agile)

Tích hợp liên tục trong phương pháp phát triển linh hoạt (agile)

Tìm hiểu các phương pháp agile, tích hợp liên tục và hướng kiểm thử giúp ích cho việc thiết kế và phát triển các hệ thống phức tạp như thế nào

Martin R. Bakal, Quản lý cung ứng toàn cầu, Công nghiệp điện lực, IBM

Jennifer Althouse, Trưởng nhóm bán các sản phẩm hệ thống, IBM

Paridhi Verma, Quản lý thị trường, Công nghiệp điện lực và di động, IBM

 Tóm tắt:  Bài viết này tìm hiểu phương pháp phát triển linh hoạt (agile development), tích hợp liên tục (continuous integration – CI), và phát triển theo hướng kiểm thử (test-driven development-TDD) được sử dụng trong phát triển phần mềm nhúng. Khi áp dụng các phương pháp này vào kiến trúc dự án thì đạt được hiệu quả chất lượng cao và tính linh hoạt.

Từ hơn một thập kỷ nay, các nhóm phần mềm đã được hưởng những lợi ích từ các phương pháp phát triển agile. Họ đã kế tục các phương pháp phát triển tăng cường và theo vòng lặp, ở đó các giải pháp được hình thành và phát triển thông qua những sự hợp tác. Các phương pháp tiếp cận truyền thống không linh hoạt thường tạo ra phần mềm bằng cách phát triển tuần tự theo từng phân đoạn. Ví dụ như quy trình thác nước (waterfall process), trong đó từng hoạt động như phân tích yêu cầu, thiết kế, phát triển và kiểm thử được thực hiện một cách tuần tự.

Mặc dù trước đây, quy trình phát triển thác nước là tiêu chuẩn để phát triển các hệ thống lớn, phức tạp trong nhiều năm, nó cũng có những hạn chế đáng lưu ý. Đầu tiên là nó khiến lãng phí công việc khi phải cố gắng hoàn thiện các tài liệu trước khi thiết kế và hoàn thiện các thiết kế trước khi viết mã, mặc dù ta đã biết rõ rằng các yêu cầu sẽ thay đổi theo thời gian. Hơn nữa, khi để quá trình kiểm thử và triển khai tích hợp đến phân khúc cuối cùng thì các vấn đề thường được phát hiện quá muộn để có thể được giải quyết mà không làm trễ dự án. Nếu mà chúng ta đang sống trong một thế giới mà ở đó mọi thứ đều di chuyển chậm chạp thì có thể bỏ qua 2 bước đó được. Nhưng trước áp lực phải tăng cường tạo ra các hệ thống mang tính sáng tạo thì các tổ chức lại giảm đi nhu cầu sử dụng phương pháp này.

Mặc dù chúng được phổ biến rộng rãi trong các nhóm phát triển hệ thống công nghệ thông tin, các phương pháp agile cũng có thể áp dụng tốt để phát triển sản phẩm phần cứng, điện tử và phần mềm. Phát triển phần mềm nhúng khác với việc phát triển các ứng dụng công nghệ thông tin chủ yếu ở chỗ nó bị hạn chế khi triển khai ở các thiết bị cuối cùng, chẳng hạn như hiệu năng bộ xử lý và bộ nhớ. Phần mềm nhúng thường thực hiện các hoạt động thời gian thực phức tạp trong những điều kiện ràng buộc. Hãy suy nghĩ về hệ thống điều khiển bằng máy tính giống như một túi khí bảo vệ chứa trong xe hơi. Chúng cần phải đáp ứng ngay lập tức (những khi gặp tai nạn), và cũng cần phải hoạt động một cách đáng tin cậy. Các phương pháp agile ban đầu được thiết kế cho các đội dự án nhỏ, ở cùng một chỗ, trong các ngành công nghiệp không chính quy. Cần phải mất nhiều năm phát triển để phương pháp agile có thể tiếp nhận được các dự án lớn và phức tạp hơn.

Khi được dùng như một phần của phương pháp tiếp cận dựa trên kiến trúc, sự tích hợp liên tục (Continuous Integration – CI) và phát triển theo hướng kiểm thử ( Test-Driven Development – TDD) mở rộng phương pháp agile cơ bản đủ để cung cấp cả chất lượng cao lẫn tính linh hoạt của dự án. Bài viết này tìm hiểu cách phương pháp agile, CI và TDD có thể được sử dụng như thế nào trong việc phát triển phần mềm nhúng. Bài viết cũng mô tả những lợi ích của sự kết hợp này.


Bằng cách nào mà sự tích hợp liên tục và phát triển theo hướng kiểm thử phù hợp với phương pháp agile

Giờ dây hầu hết mọi người đã nghe qua về phương pháp agile. Các khái niệm mà chúng mang đến cho việc phát triển phần mềm đã thay đổi cách thức mà các đội nhóm tổ chức công việc của họ, cách thích ứng với các yêu cầu luôn thay đổi và cách thức phát hành phần mềm. Tích hợp liên tục (CI) được tạo ra cho quy trình phát triển agile, vì vậy cách tiếp cận phương pháp này là chủ đề cho bất kỳ cuộc thảo luận nào về tích hợp liên tục. Nó tổ chức việc phát triển theo các nhóm chức năng của người dùng. Những nhóm chức năng này được chia thành các nhóm hay các chặng công việc nhỏ.

Ý tưởng là không cố gắng giải quyết tất cả vấn đề ngay từ ban đầu, mà tập trung vào những gì bạn đã biết. Vì vậy, nhóm nghiên cứu thiết kế, xây dựng, và kiểm thử những gì họ biết về các chức năng mong muốn. Điều này tạo ra một sản phẩm làm việc dựa trên tập hợp con các yêu cầu của sản phẩm hoàn chỉnh. Sau đó, cả nhóm sẽ làm việc tiếp với các yêu cầu có độ ưu tiên cao tiếp theo và cứ thế quá trình được lặp lại. Tất nhiên, nhìn thì thấy rất đơn giản, và quy trình này cũng có nhiều biến thể khác nhau, nhưng có một điều cốt lõi là: Từng bước xây dựng sản phẩm và dần dần cải thiện mọi thứ trong quá trình xây dựng đó.

Theo Martin Fowler của công ty tư vấn ThoughtWorks, tích hợp liên tục (IC) là phương pháp phát triển phần mềm đòi hỏi các thành viên trong nhóm tích hợp công việc thường xuyên. Mỗi ngày, các thành viên đều phải theo dõi và phát triển công việc của họ ít nhất một lần. Việc này sẽ được một nhóm khác kiểm tra tự động, nhóm này sẽ tiến hành kiểm thử truy hồi để phát hiện lỗi nhanh nhất có thể. Cả nhóm thấy rằng phương pháp tiếp cận này giúp giảm bớt vấn đề về tích hợp hơn và cho phép phát triển phần mềm gắn kết nhanh hơn.

Điều này dẫn đến thành công của quá trình tích hợp liên tục. Nếu ý tưởng tích hợp liên tục là để tìm ra các vấn đề một cách nhanh chóng thì nó mang lại cho nhà phát triển các thông tin phản hồi về công việc của mình, sau đó sử dụng một phương pháp đánh giá công việc nhanh chóng. phát triển theo hướng kiểm thử lấp đầy khoảng cách đó. Với phương pháp phát triển theo hướng kiểm thử, bạn xây dựng bài kiểm thử và sau đó phát triển chức năng cho đến khi mã vượt qua được bài kiểm tra đó. Khi có những bổ sung, bài kiểm thử cho đoạn mã đó có thể được thêm vào khi bạn cố gắng build đoạn mã đó. Điều này đảm bảo rằng những bổ sung mới không phá vỡ công việc đã hoạt động trước đó, và những đoạn mã nào “mang tính nguy hiểm” sẽ được cảnh báo ngay. Sự kết hợp điển hình của tích hợp liên tục và sự phát triển theo hướng kiểm thử được minh họa trong hình 1.

Hình 1. Phương pháp agile sử dụng tích hợp liên tục và phát triển theo hướng kiểm thử
Phương pháp agile sử dụng tích hợp liên tục và phát triển theo hướng kiểm thử

Về đầu trang

Các loại dự án được hưởng lợi từ tích hợp liên tục

Các nhóm phát triển có ít hơn 50 người làm việc trên các dự án có độ phức tạp không cao thì phù hợp với phương pháp phát triển agile lẫn tích hợp liên tục. Tuy nhiên, vì các sản phẩm ngày càng “thông minh hơn”, nên chúng cũng ngày càng phức tạp hơn.

Ngày càng nhiều các sản phẩm có sử dụng phần mềm nhúng. Bạn thấy những chiếc xe mới bây giờ được tiếp thị về mã lực của nó thì ít mà về công nghệ phần mềm nhúng thì nhiều (Ví dụ: Tự vào chỗ đỗ xe, các cảnh báo an toàn tiên tiến, hiệu quả sử dụng nhiên liệu và hệ thống thông tin giải trí). Số lượng các dòng mã được viết để tạo ra một chiếc xe mới nhiều hơn so với số lượng các dòng mã được viết cho một máy bay phản lực chiến đấu F16.

Với nhu cầu gia tăng độ phức tạp đồng thời các sản phẩm phải được sản xuất nhanh để đáp ứng cho thị trường. Và việc thịnh hành của các phần mềm nhúng kết hợp với yêu cầu thời gian chặt chẽ hơn đã mang lại sự lựa chọn cho các nhà phát triển về các phương pháp agile và tích hợp liên tục (IC).

Về đầu trang

Sử dụng các phương pháp agile để phát triển các hệ thống nhúng

Phương pháp agile cho phép các nhóm làm phần mềm và hệ thống đáp ứng sự thay đổi một cách nhanh chóng. Cách tiếp cận linh hoạt này giúp giảm nguy cơ trễ dự án, điều mà trước đây đã gắn liền với quy trình phát triển phần mềm truyền thống, trong đó việc tích hợp từng thành phần lại với nhau được coi là nỗ lực ở giai đoạn cuối cùng. Giai đoạn này thường là nguyên nhân gây nhầm lẫn so với đặc tả thiết kế ban đầu nhưng lại được phát hiện quá muộn để có thể sửa chữa cho kịp thời hạn.

Tuy nhiên, đối với các nhóm phát triển hệ thống, họ là những người phải tạo ra nhiều thứ hơn là phần mềm, thì lại hoài nghi về một số điểm ở phương pháp agile này. Họ nói rằng nếu bỏ qua quá nhiều yếu tố khi lên kế hoạch từ ban đầu, thì cuối cùng bạn sẽ có những phần mềm kém chất lượng và không tương thích với phần cứng. Nếu không tiến hành checkpoint (kiểm tra) sớm và thường xuyên để xác nhận tiến độ so với kế hoạch chi tiết về kiến trúc, thì nhóm dự án có thể thất bại, không thể sản xuất ra thành phần hoạt động được trong các hệ thống lớn. Hơn nữa, đối với các nhà phát triển hệ thống phức tạp, những người đang tìm kiếm khả năng tái sử dụng của thiết kế hoặc khả năng mở rộng cho các yêu cầu của dự án lớn hơn thì các phương pháp agile lại tỏ ra hạn chế.

Những lo ngại này cũng dễ hiểu, bởi vì mô hình hóa và kiến trúc không phải là điểm trọng tâm của các kỹ thuật agile. Nhưng cách tiếp cận tích hợp liên tục đối với quá trình phát triển hệ thống cung cấp một số cải tiến so với những phương pháp agile thuần túy. Sự tích hợp liên tục giúp các nhóm phát triển hệ thống linh hoạt và đáp ứng với những thay đổi nghiệp vụ nhanh chóng, đồng thời cũng đảm bảo rằng các phần cứng và phần mềm thực tế được phát triển đồng bộ liên tục. Sự tích hợp liên tục cho phép các thành viên trong nhóm làm việc hiệu quả trong lĩnh vực của mình, tập trung vào các nhiệm vụ mà họ đang hoàn thành một cách tốt nhất. Vào cuối mỗi ngày, họ biết rằng những đóng góp của họ được tích hợp vào dự án và các bộ phận thành phần làm việc với nhau. Và nếu có gì đó không được tích hợp thì nó sẽ nhanh chóng được phát hiện.

Hãy xem xét một số các thành phần thiết yếu trong phát triển và phân phối hệ thống phức tạp và khám phá việc tích hợp liên tục (CI) giúp đáp ứng những thách thức đó như thế nào.


Kiến trúc

Khi bạn xây dựng hệ thống phức tạp, thì bạn không thể liên tục thêm các tính năng mà không cần bản thiết kế chi tiết. Nếu không có bản thiết kế, thì có khả năng bạn sẽ phải làm lại những gì đã làm. Cho dù bạn gọi nó là thiết kế chi tiết, mô hình hoặc kiến trúc, nó đều cung cấp một nền tảng vững chắc mà ở đó quy trình vòng lặp được bắt đầu.

Kiến trúc có thể hữu ích trong các dự án có nhóm 50 thành viên hoặc ít hơn, nhưng khi bạn phát triển vượt quá kích thước này, bạn chắc chắn phải có công đoạn làm sẵn trước này để hiểu cách chia thành phần, tái sử dụng và sự biến đổi. Sự phân tích sẵn trước này cho phép bạn chia thành các nhóm nhưng vẫn có thể kết họp lại để đưa ra sản phẩm. Điều này cũng đúng khi bạn có các nhà phát triển phần mềm và phần cứng làm việc cùng nhau, vì bạn làm cho các hệ thống phức tạp với phần mềm nhúng.

Mô phỏng

Bằng cách nắm bắt kiến trúc trong mô hình mô phỏng, nhóm phát triển có thể thấy cách hệ thống sẽ đáp ứng với các đầu vào khác nhau. Hình thức kiểm thử sớm này cho phép xác nhận rằng hệ thống thực hiện như dự định, do vậy nó đáp ứng các yêu cầu. Nó cũng cho phép nhà thiết kế hình dung bất kỳ hậu quả không lường trước nào của thiết kế. Những hậu quả không lường trước rất khó thấy khi xem xét mã dưới dạng văn bản. Chúng trở nên rõ ràng hơn khi xem mô hình của hệ thống và thậm chí còn rõ ràng hơn khi hệ thống đó đang hoạt động.

Bằng cách này, việc mô hình hóa và mô phỏng cho phép bắt đầu kiểm thử và tích hợp ngay sau khi công việc thiết kế bắt đầu, điều này loại bỏ sự chậm trễ có thể gặp phải nếu phần cứng nhúng chưa có sẵn. Nó có thể tiết kiệm khoản đầu tư đáng kể trong việc tạo sản phẩm mẫu sớm không cần thiết với kiến trúc không khả thi. Ngay cả khi bạn có sẵn phần cứng, tích hợp liên tục đòi hỏi phải xây dựng liên tục.

Nếu bạn mong muốn xem kết quả càng sớm, thì môi trường xây dựng của bạn càng trở nên đắt. Bởi vì mục đích chính của tích hợp liên tục là cung cấp kết quả càng nhanh càng tốt, việc mô phỏng cho phép bạn kiểm thử mà không cần chi phí phần cứng quá cao. Nó cũng cung cấp một cách dễ dàng hơn để trao đổi thông tin về chức năng của thành phần, cách này chính là pair programming (lập trình theo cặp đôi) và “code review (rà soát mã)”, rất phổ biến trong phát triển agile.

Tự động hóa quá trình build

Tích hợp liên tục đòi hỏi phải tự động hóa quá trình build, tức là khả năng phần mềm được tự động biên dịch và liên kết thành tệp thực thi. Tốc độ là quan trọng bởi vì quá trình build một ứng dụng lớn có thể mất một thời gian dài. Nếu không có công cụ build lớn, nhanh chóng, đáng tin cậy, thì bạn sẽ thiếu những thông tin cần thiết để giải quyết các vấn đề tích hợp phát sinh. Khi build, nếu có các xung đột hay lỗi thì trình build sẽ tự động thông báo. Vì vậy, nếu phát hiện vấn đề thì các nhà phát triển cùng làm việc để giải quyết xung đột thông qua việc kiểm tra bản build trước đó trên một mô phỏng phần cứng mà không làm trì hoãn các nhà phát triển khác. Nhưng để đạt được hiệu quả này, việc xây dựng tích hợp phải diễn ra liên tục, phải tạo ra bản build mới ngay sau khi kết thúc bản build trước đó. Điều này rất khác với cách build hàng ngày hoặc hàng tuần mà các quá trình khác sử dụng.

Tất nhiên, phương pháp này đòi hỏi tự động hóa quá trình build, bởi vì sẽ là không thực tế khi giao cho ai đó chỉ với một nhiệm vụ là ngồi build suốt cả ngày. Hơn nữa, quá trình build cần được thực hiện một cách nhanh chóng, điều này đòi hỏi phải chạy đa luồng (multithreaded). Quá trình multithreaded build chính là cách build nhiều thành phần song song cùng lúc, giúp giảm bớt thời gian build. Nó đòi hỏi nhiều phần cứng hơn và kịch bản phức tạp hơn. Kịch bản càng trở nên phức tạp, thì công cụ quản lý việc xây dựng càng trở nên giá trị hơn.

Quản lý công việc

Khái niệm agile là việc phân chia công việc thành những phần công việc nhỏ, dễ quản lý. Đây cũng là tiền đề cơ bản đằng sau phương pháp tích hợp liên tục: để sửa các lỗi của bạn ngay từ ban đầu. Điều này sẽ ngăn không cho chúng kết hợp thành các vấn đề lớn hơn, khó giải quyết hơn sau này.

Một trong những điều mà kỹ thuật này mang lại là khả năng cung cấp các bản phát hành nhỏ, hoạt động được, đã được xây dựng và kiểm thử nhiều ngày theo tiến độ của dự án. Mỗi bản phát hành giúp giảm rủi ro của dự án bằng cách xác thực kiến trúc, các yêu cầu và ước tính lịch trình của nhóm. Theo phương pháp agile, những công việc cần phải được hoàn thành được gọi là tồn đọng (backlog). Khi bạn bắt đầu chia công việc thành các phần nhỏ hơn, gọi là các chặng (sprints), công việc được phân bổ cho một sprint được gọi là sprint backlog. Phần công việc còn lại được phân bổ cho các sprint trong tương lai được gọi là product backlog. Mục tiêu là nhóm các hạng mục công việc thành một sprint để có thể hoàn thành được trong khoảng thời gian xác định của sprint.

Quy trình này phụ thuộc nhiều vào việc thu thập số liệu để đội có thể dự đoán chính xác lượng thời gian mà nhiệm vụ sẽ đòi hỏi và, do đó số lượng tác vụ có thể phù hợp với một sprint. Tuy nhiên, dù cho những số liệu này là bao nhiêu, thì việc thu thập dữ liệu là rất mệt mỏi ngay cả đối với nhóm nhỏ. Vì các nhóm nhỏ được gom lại với nhau để tạo ra sản phẩm phức tạp hơn, nên các tác vụ khó hoàn thành theo cách thủ công.

Có rất nhiều sản phẩm trên thị trường giúp tổ chức công việc, theo dõi hoàn thành công việc và thống kê các số liệu liên quan đến công việc đó như: công việc đã thực hiện được bao nhiêu, nhanh đến đâu, tốt đến mức nào vv… Khi theo đuổi phương pháp tích hợp liên tục, thì các lỗi về tích hợp được đánh dấu là high-priority (mức độ ưu tiên cao) và được thêm vào backlog (danh sách các công việc tồn đọng). Về mặt này, những sản phẩm tốt nhất trên thị trường cung cấp một số mức độ tích hợp giữa các hạng mục công việc mới và hệ thống quản lý quá trình build, do đó lỗi được xác định sau mỗi lần build có thể được sửa một cách nhanh chóng và tích hợp với các hạng mục công việc đang có, tăng dần theo mức ưu tiên và được chuyển đến nhóm phù hợp.

Quản lý chất lượng

Quản lý chất lượng là phương pháp phát triển vòng đời để đảm bảo rằng tất cả các yêu cầu cho sản phẩm của bạn đã được kiểm tra. Nỗ lực này cần được tổ chức và hiểu đúng để các bài kiểm thử chính xác có thể được cập nhật khi các yêu cầu thay đổi. Quản lý chất lượng giúp các nhà quản lý dự án trả lời những câu hỏi sau:

  • Nếu sản phẩm của tôi phải được phát hành vào tuần tới, phần nào sẽ có nguy cơ cao nhất?
  • Chúng ta có thể phát hành mà không có yêu cầu ở mức thấp hơn?
  • Đây có phải là bản phát hành có chất lượng cao hay không?

Trong khi đối mặt với áp lực thị trường rằng phải đáp ứng nhanh và tăng tốc chu kỳ sản phẩm, những câu hỏi này có thể giúp doanh nghiệp tự tin phát hành sản phẩm ra thị trường. Các nhà quản lý hiểu rõ sẽ biết cách bổ sung các tài nguyên nào, tính năng nào nên bỏ đi và thương lượng lại ngày giao hàng để đạt lợi thế tối đa nhất.

Với phương pháp phát triển theo hướng kiểm thử, việc kiểm thử trở thành vấn đề trung tâm hơn với các nỗ lực phát triển. Theo phương pháp phát triển theo hướng kiểm thử, bạn viết bài kiểm thử dựa trên yêu cầu, và sau đó bạn phát triển mã cho đến khi nó vượt qua bài kiểm thử đó. Điều này đảm bảo rằng không có chức năng bổ sung nào được tạo ra, đó sẽ là thứ mà nhóm phát triển gọi là “mạ vàng (gold plating)”. Thậm chí nếu bạn có một ý tưởng về một tính năng hay chức năng mới cho sản phẩm nhưng những điều này không có trong yêu cầu thì việc thêm vào sẽ làm mất thời gian và có thể bị trễ dự án. Đồng thời khiến cho khách hàng không hài lòng.

Tự động hóa kiểm thử

Khi bạn thực hiện quá trình build nhiều lần, thì nhóm phát triển được yêu cầu kiểm thử lại các chức năng đã làm việc trong các phiên bản trước. Quá trình kiểm thử lại này, trước đây được biết đến là “mã tốt (good code)”, thì nay được gọi là kiểm thử truy hồi (regression testing). Nó đảm bảo rằng những đoạn mã trước đây sẽ không bị lỗi khi bạn thêm vào một tính năng mới nào đó. Với phương pháp tích hợp liên tục, kiểm thử truy hồi tự động được viết thành kịch bản lệnh để chạy ở bước cuối cùng của mỗi lần build. Điều này cho phép các nhà phát triển có được các thông tin phản hồi ngay lập tức về các lỗi được tìm thấy trong lần build mới. Đó là những cảnh báo cho nhà phát triển biết rằng mã mới mà họ đã tạo ra có làm việc (hoặc không làm việc) như yêu cầu hay không. Nếu không có kiểm thử truy hồi, các nhà phát triển sẽ chỉ biết rằng họ đã build thành công. Bởi vì dù sao thì cũng phải thực hiện các bài kiểm thử, cho nên nếu ban đầu bạn sử dụng phương pháp phát triển theo hướng kiểm thử thì sẽ không phát sinh thêm công việc này. Nó đơn giản chỉ là đảo ngược trật tự của công việc bằng cách trước tiên tạo ra các bài kiểm thử, sau đó mới tạo mã.

Dự án phát triển theo quy trình nước truyền thống có thể sống sót mà không thực hiện bất kỳ việc kiểm thử tự động nào. Dự án có thể được mô tả, xây dựng và sau đó được kiểm thử không ngừng bởi rất nhiều người. Nhưng khi bạn phát hành sản phẩm một cách thường xuyên thì lúc này mới phát sinh vấn đề. Đó là không thể kiểm thử thủ công các hệ thống đang được build nhiều lần trong một ngày.

Sự cộng tác

Tổ chức phần mềm IBM Rational từ lâu đã là một người ủng hộ sự cộng tác như là yếu tố quan trọng cho sự phát triển và phân phối thành công hệ thống. Nhưng trong phương pháp tích hợp liên tục, nơi mà cả hai nhóm phần mềm và phần cứng đều tham gia, sự cộng tác không chỉ là việc kết hợp nhuần nhuyễn sản phẩm của các đội, mà còn là sự hiểu biết đầy đủ về các yêu cầu, tính năng và thời hạn.

Đối với những kiến trúc tốt thì cho phép kiểu cộng tác này một phần vì mọi người có thể hiểu tốt hơn các phụ thuộc giữa các thành phần khác nhau mà họ đang xây dựng. Với việc quản lý danh mục dự án, bạn có thể hiểu các tính năng, việc tái sử dụng và phân bổ tài nguyên. Nhưng trong các dự án mà phần cứng và phần mềm cùng phát triển, đó cũng là điều quan trọng để quản lý các yêu cầu và đưa ra quyết định thông minh khi nào những yêu cầu có thể thay đổi và khi nào chúng không được thay đổi.

Các dự án như vậy thường dính líu đến nhiều bên liên quan ở nhiều cấp độ của việc ra quyết định. Cộng tác tốt sẽ giúp làm thỏa mãn các bên liên quan. Nó đảm bảo rằng sản phẩm tốt phải được tạo ra và rằng các sai lệch so với các mục tiêu rộng lớn hơn được xác định một cách nhanh chóng. Điều này tạo ra một sản phẩm thỏa mãn tốt hơn nhu cầu của khách hàng.

Về đầu trang

Tóm tắt

Từ góc độ kỹ thuật, tích hợp liên tục (Continuous Integration – CI) giúp các nhóm làm việc hiệu quả hơn. Các nhóm này có thể có chức năng liên quan nhau, tạo ra phần cứng và phần mềm làm việc cùng nhau. Họ có thể làm việc ở những nơi khác nhau, bởi vì công việc tích hợp không ngừng sẽ đảm bảo rằng bạn không đi lệch các thiết kế. Mọi người có thể làm việc trong các nhóm lớn, bởi vì các thành phần khác nhau của hệ thống phức tạp sẽ làm việc cùng nhau đảm bảo hơn. Nó giải quyết nhiều vấn đề sớm mà các nhóm phát triển theo phương pháp agile có thể đã trải qua nếu không tích hợp liên tục. Việc phối hợp phương pháp tích hợp liên tục với phương pháp phát triển theo hướng kiểm thử đã bổ trợ cho phương pháp agile, bởi vì nó cho phép phương pháp agile làm việc hiệu quả hơn.

Từ góc độ kinh doanh, phương pháp tích hợp liên tục cung cấp các kết quả nghiệp vụ tốt hơn bằng cách cho phép cho các nhóm đều tham gia. Nghĩa là, họ có thể đưa sản phẩm ra thị trường nhanh hơn, bằng cách tìm ra các vấn đề khi chúng còn mới và nhỏ, không phải chờ đợi cho đến khi chúng trở nên lớn và khó sửa chữa. Họ cũng có thể đáp ứng tốt hơn yêu cầu đưa thêm tính năng mới vào sản phẩm trong lúc đang phát triển. Điều này tạo ra một sản phẩm tốt hơn cho khách hàng, đó là hứa hẹn thực sự của sự linh hoạt.

Tài nguyên

Học tập

Lấy sản phẩm và công nghệ

Thảo luận

Đôi nét về các tác giả

Martin R. BakalMarty đã có hơn 10 năm kinh nghiệm làm việc với nhiều vai trò khác nhau trong các hệ thống nhúng và ngành công nghiệp phần mềm, có mối quan hệ rộng rãi với khách hàng trên toàn thế giới trong nhiều ngành bao gồm ngành tiêu dùng, viễn thông, ô tô và y tế. Ông hiện là quản lý cao cấp sản phẩm toàn thế giới trong ngành công nghiệp điện tử tại trung tâm IBM Rational với vai trò dẫn dắt các ý tưởng.

Jennifer AlthouseJennifer Althouse đã có hơn 10 năm kinh nghiệm làm việc trong nhiều lĩnh vực phát triển hệ thống phức tạp và các dự án phần mềm. Cô có mối quan hệ khách hàng rộng rãi trong nhiều ngành công nghiệp bao gồm cả ngành hàng không vũ trụ, điện tử và thiết bị y tế. Jennifer hiện đang là Chuyên gia công nghiệp điện tử tại IBM Rational.


Paridhi VermaParidhi Verma là nhà quản lý thị trường ngành công nghiệp điện tử và di động tại IBM Rational, có nhiệm vụ sáng tạo các sản phẩm thông minh hơn để phù hợp với các làn sóng mới phát triển. Cô đã có 15 năm kinh nghiệm làm việc tại Trung tâm nghiên cứu của IBM. Mười năm cô làm việc với tư cách là kỹ sư phần mềm bảo mật và mạng lưới. Năm năm còn lại cô phát triển các đề xuất về trao đổi thông điệp chiến lược và giá trị khách hàng cho khu vực công nghiệp. Paridhi có bằng Thạc sĩ khoa học về kỹ thuật điện tại đại học New York Poly. Cô cũng có bằng sáng chế cho hệ thống cảnh báo khẩn cấp trên internet.

Nguồn: https://www.ibm.com

Hãy tham gia nhóm Học lập trình để thảo luận thêm về các vấn đề cùng quan tâm.

admin

Leave a Reply

Your email address will not be published. Required fields are marked *

© Copyright 2013-2021 Kiến thức Lập trình. All rights reserved.