Giới thiệu

Do sự phát triển nhanh đã lớn mạnh trong cộng đồng vài năm qua, nhiều công ty đang xem xét cách tận dụng lợi thế của các quy trình và các kỹ thuật phát triển nhanh. Mặc dù tôi không phải là một nhà truyền giáo về sự nhanh, các kỹ thuật phát triển nhanh đã chứng tỏ là có ích trong một số loại tổ chức và dự án.

Trong các quy trình phát triển và xử lý các vấn đề liên quan đến phát triển, sự nhanh đã trở thành một chủ đề nóng, bởi vì:

• Các doanh nghiệp muốn có khả năng phản ứng nhanh hơn trước các thay đổi của thị trường.
• Các bộ phận CNTT muốn cung cấp các vấn đề không theo chu kỳ phát hành sáu tháng chính thức (hoặc bình thường).
• Các nhà phát triển muốn có một môi trường phát triển ổn định, ở đó họ hoàn toàn có thể tập trung vào các tính năng và chất lượng của phần mềm mà họ đang xây dựng.

Phát triển nhanh không phải dành cho tất cả các tổ chức, các dự án hay các khách hàng. Có vài tiêu chuẩn làm sự phát triển nhanh phù hợp với một số tổ chức tốt hơn so với các tổ chức khác. Và, như mọi khi, chính con người đã khiến quy trình này xảy ra (và là người hợp với tất cả các loại).

Trong mục này tôi sẽ thảo luận về các tiêu chí để giúp bạn đánh giá liệu sự phát triển nhanh có phù hợp với tổ chức của bạn không. Tìm hiểu thế nào là lợi ích của sự phát triển nhanh và khía cạnh con người ("people") của quy trình phát triển nhanh.

Về đầu trang

Ý nghĩa của nhanh

Đầu tiên cho phép chúng tôi định nghĩa điều muốn nói gì về từ "nhanh" này. Có rất nhiều các phương thức phát triển nhanh khác nhau. Tất cả chúng đều tập trung vào truyền thông mặt đối mặt và chu kỳ phát hành nhanh và chúng nhằm mục đích cung cấp một đoạn phần mềm làm việc trong khoảng thời gian ngắn. Các phương thức nhanh này là một nỗ lực giảm bớt tệ quan liêu trong quy trình phát triển để giải phóng công việc phần mềm sẽ thực hiện các đòi hỏi quan trọng nhất của khách hàng. Một số người có thể nói rằng sự phát triển nhanh có hơi hướng giữa tệ quan liêu quá mức, quy trình phát triển tư liệu hóa, nhưng đó không hoàn toàn chính xác. Tất cả đều phụ thuộc vào hoàn cảnh.

Trái với một số quan điểm, các nhà phát triển nhanh không phải là các chính khách không liên kết, viết ra các mã không có các quy tắc hay các hạn chế nào. "Mã hóa vô trách nhiệm" (Cowboy coding) là một dấu hiệu của sự thiếu kỷ luật, quản lý kém và không chuyên nghiệp. Nếu có mã hóa vô trách nhiệm ở người trong công ty của bạn hoặc thậm chí tệ hơn — trong nhóm của bạn — hãy làm mọi thứ có thể để thay đổi những thứ đó vì lợi ích của khách hàng.

Phát triển nhanh thường được mô tả với câu chuyện điển hình về một dự án hai năm được phát triển bởi một nhóm dự án nhỏ (có năm người). Nếu nhóm này sử dụng một phương thức dạng thác nước truyền thống, như trong Hình 1, thì nhóm đó sẽ mất 2 đến 3 tháng để ghi lại chi tiết tất cả yêu cầu. Sau đó, nhóm sẽ phân tích các yêu cầu. Tiếp theo việc phân tích các yêu cầu sẽ là các thiết kế hệ thống, gồm kiến trúc. Vào lúc này, khách hàng muốn đưa ra thay đổi đầu tiên, để đưa quy trình quản lý thay đổi. Quy trình quản lý thay đổi tự nó sẽ yêu cầu một bản sửa các yêu cầu nhỏ, một phân tích khác và các thiết kế có khả năng hơn.

Sau sáu hoặc bảy tháng, nhóm này cuối cùng sẽ sẵn sàng triển khai thực hiện. Như bạn có thể dự đoán, khách hàng sẽ cần các thay đổi bổ sung, sẽ lại đến quy trình quản lý thay đổi. Bây giờ đừng hiểu lầm — có những trường hợp có thể có một quy trình duy nhất — như là các hệ thống của nhiệm vụ gay cấn, hay hệ thống trợ giúp vòng đời.

Nếu nhóm trong ví dụ này đã đang sử dụng tiếp cận nhanh, như trong Hình 2, nhóm sẽ phác thảo sơ bộ các yêu cầu, nhưng theo một cách để cho phép những người chủ dự án dành ưu tiên cho chúng. Sau đó, những người chủ dự án và các nhà phát triển cùng nhau lựa chọn một nhóm nhỏ các tính năng từ các yêu cầu, rồi thiết kế và thực hiện chúng trong một loạt các công việc lặp, kéo dài 2 đến 3 tuần mỗi lần. Với một cặp các công việc lặp lại, họ đã phát triển một phiên bản ứng dụng đang làm việc, hoạt động và những người chủ dự án có thể đã bắt đầu thử hoặc sử dụng ứng dụng đó. Sau một cặp các công việc lặp lại nhiều hơn, ứng dụng đã có các chức năng cơ bản của nó và sẵn sàng để khởi chạy.

Phương thức nhanh được mô tả trong Hình 2 cho ra phiên bản làm việc của ứng dụng nhanh hơn so với phương thức dạng thác nước, chỉ dùng cho thiết kế ứng dụng. Ứng dụng làm việc chỉ gồm các tính năng cơ bản, nhưng nó vẫn là một phiên bản làm việc. Thật có ích để có một phiên bản làm việc — mặc dù một phiên bản chỉ với các tính năng cơ bản — để bạn có thể bắt đầu sử dụng một ứng dụng nội bộ để làm cho quy trình nghiệp vụ nhanh hơn hoặc phát hành một phiên bản beta của một dịch vụ thương mại để bắt đầu thu hút khách hàng.

Phần tiếp theo sẽ bàn về các lợi ích của việc sử dụng các quy trình nhanh.

Về đầu trang

Các nguyên tắc và lợi ích

Nếu tổ chức của bạn không gặt hái được bất kỳ lợi ích nào từ các phương thức nhanh, thì không có nơi nào sử dụng chúng. Những lợi ích là dễ nhất để thảo luận theo danh sách các nguyên tắc nhanh, như sau:

Giao hàng nhanh chóng, liên tục

Đạt được sự hài lòng của khách hàng với việc giao hàng phần mềm có ích nhanh chóng, liên tục. Điều này có phải là quyết định đối với tổ chức của bạn không? Công ty của bạn đi vào hoạt động có muốn bắt đầu thu hút khách hàng bằng một phiên bản beta của một ứng dụng không? Ứng dụng của bạn sẽ tiết kiệm được các chi phí nội bộ bằng cách thay thế công việc thủ công không?

Nếu có, bạn có thể được hưởng lợi từ sự phát triển nhanh.

Giao hàng thường xuyên

Phần mềm làm việc có thể được gửi thường xuyên, theo tuần thay vì theo tháng. Nếu ứng dụng của bạn là một ứng dụng Web, bạn sẽ muốn thúc đẩy các bản cập nhật thường xuyên để bổ sung tính năng mới hoặc cải thiện các ứng dụng khi bạn nhận được phản hồi từ khách hàng. Bạn không phải lo lắng về việc kiểm soát phiên bản nặng nề hoặc duy trì các tệp để theo dõi khách hàng nào có phiên bản nào.

Nếu việc phát hành phiên bản của bạn có nghĩa là các thay đổi hoặc công việc tại phía khách hàng, bạn có thể không muốn thực hiện cập nhật thường xuyên. Tuy nhiên, lặp lại thường xuyên có thể là một ý tốt, vì bạn biết rằng bạn có thể thực hiện và phát hành các thay đổi theo tuần thay vì theo tháng.

Phần mềm làm việc

Độ đo chính của quy trình là phần mềm làm việc. Các tài liệu và phần chiếu slide (slideware) được viết ra không đủ đáp ứng hầu hết các yêu cầu nghiệp vụ — bạn cần phần mềm làm việc cho yêu cầu đó.

Nếu bạn đang làm công việc tư vấn, rồi có lẽ các tài liệu và các slide là đủ, nhưng việc triển khai phần mềm làm việc cuối cùng vẫn là mục tiêu cho hầu hết các tổ chức.

Quy trình điều chỉnh

Ngay cả những thay đổi cuối cùng theo các yêu cầu được tiếp nhận theo phương thức phát triển nhanh. Trong một thời gian dài, các chuyên gia phần mềm đã cố gắng làm tất cả những thứ mà họ có thể làm để tạo ra các thay đổi muộn màng không thể được hoặc rất tốn kém. Tuy nhiên, do các môi trường kinh doanh có thể thay đổi nhanh chóng, nên các yêu cầu về phần mềm phải theo kịp.

Hợp tác hàng ngày, liên hệ thường xuyên

Người kinh doanh và các nhà phát triển phần mềm nên trao đổi hàng ngày và hợp tác về giải pháp. Các thay đổi muộn theo các yêu cầu có thể đến từ những người kinh doanh và các nhà phát triển cần cài đặt các đòi hỏi đó. Hợp tác hàng ngày là cần thiết, nếu quy trình này tính đến các yêu cầu thay đổi.

Đối với các ứng dụng cài đặt các giao diện hoặc các đặc tả, các yêu cầu cũng giống như các tài liệu đặc tả được người có quyền công bố. Các thay đổi cho tài liệu này nhiều hơn một thỏa thuận lớn, và chúng không xuất hiện ngay.

Những người có kĩ năng, nhiệt tình

Các dự án được xây dựng quanh những cá nhân có kĩ năng, nhiệt tình, đáng tin cậy. (Điều đó thực sự là cơ bản của bất kì tổ chức nào). Tôi có thể dễ dàng viết một mục khác về lí do một số người nhiệt tình còn một số khác thì không.

Bạn có đủ nguồn lực để làm việc nhiệt tình và đào tạo các công nhân, những người không nhiệt tình và không có kinh nghiệm không hoặc bạn cần phải tìm những người nhiệt tình và có kinh nghiệm để thuê không?

Các nhóm tự tổ chức

Các nhóm tự tổ chức không hiện thực đối với hầu hết các nỗ lực phát triển phần mềm. Họ đòi hỏi phải có nhiều kinh nghiệm về mặt phát triển và về quản lý. Một nhóm tự tổ chức sẽ quyết định được những phần của yêu cầu có thể thực hiện lặp lại nào đó, và sẽ quyết định người làm việc đó. Vai trò của các thành viên trong nhóm đều dựa trên lợi ích và tri thức của họ, thay vì bị ban quản lý sai khiến.

Một nhóm tự tổ chức kém sẽ chỉ chấp nhận một số các yêu cầu và không sản xuất nhiều. Để làm việc hợp lí, nhóm phải hiểu họ đang làm gì và ban quản lý phải tin tưởng họ.

Các nhóm tự tổ chức sẽ được đánh giá so với các nhóm khác, không phải so với các ước tính mơ hồ về công việc đòi hỏi. Tổ chức của bạn có những người có kinh nghiệm không? Bạn có cảm thấy, như là một thành viên của nhóm hoặc như là một người quản lý, lo sợ về việc thực hiện bất cứ điều gì không?

Vào lúc này, bạn có thể tự hỏi liệu các nguyên tắc nhanh hoặc một nhóm tự tổ chức, có thể làm việc trong tổ chức của bạn không. Sự không chắc chắn đó sẽ dẫn đến câu hỏi lớn tiếp theo.

Về đầu trang

Tổ chức của bạn đã sẵn sàng cho một quy trình nhanh chưa?

Thích nghi với các phương thức nhanh là dễ dàng hơn trong các tổ chức có các đặc điểm nhất định. Như Cohen và đồng nghiệp đưa ra lần đầu, những đặc điểm đó là:

• Một văn hóa đàm phán.
  
  Thảo luận cởi mở và trung thực rất quan trọng trong bất kỳ tổ chức nào, nhưng nếu bạn đang lập kế hoạch áp dụng các phương thức nhanh, các phần khác nhau của tổ chức của bạn phải giao tiếp tốt và có khả năng thỏa hiệp khi cần thiết.
• Tin tưởng vào những người làm việc.
  
  Nếu ban quản lý không tin tưởng vào các nhà phát triển hoặc các nhà phát triển không tin tưởng những người bán hàng, thì bạn đang có vấn đề.
• Nhân viên ít hơn, với trình độ năng lực cao hơn.
  
  Bạn có thể làm được nhiều việc chỉ với một số ít các nhà phát triển rất tốt, những người không phải đối phó với tệ quá quan liêu.
• Một môi trường tạo điều kiện liên lạc nhanh chóng giữa các thành viên trong nhóm.
  
  Các yêu cầu kinh doanh cần phải được đáp ứng ngay, không đợi tuần tới. Văn hoá tổ chức của bạn cần có một phản ứng nhanh chóng, hơn là một phản ứng nhận được trong hoàn cảnh khó khăn theo quy trình thực hiện.
• Quy mô của nhóm dự án nhỏ (ít hơn 20 hoặc 30 người).
  
  Theo quy mô phát triển, truyền thông mặt đối mặt trở nên khó khăn hơn.

Một vài năm trước đây, tôi đã làm việc trong một công ty mà ở đó chúng tôi đã áp dụng một phiên bản đơn giản hóa của IBM Rational® Unified Process (RUP®). Các đặc điểm của quy trình này khá nhanh, mặc dù chúng tôi đã không gọi nó là nhanh. Tôi đã đang nói về các công việc lặp, cách chúng đã được sử dụng và tại sao chúng tốt. Do vài nguyên nhân, mọi người đã không thực sự hưởng ứng. Một người quản lý dự án sau này giải thích rằng mọi người hiểu "công việc lặp" có nghĩa là làm cùng một việc lặp đi lặp lại do các yêu cầu đã không rõ ràng. Các kinh nghiệm trước đây của họ đã làm cho họ bịt chặt tai mình lại để không nghe tôi nói. Tôi biết được rằng bất kể cách bạn được chuẩn bị, đó là những người thực hiện các quy trình, và những người có lịch sử đáng để biết.

Về đầu trang

Theo dõi tiếp

Tiếp theo tôi sẽ thảo luận về các phương thức phát triển nhanh trong các loại các tổ chức khác nhau, chẳng hạn như các hãng bắt đầu đi vào hoạt động, các hãng phát triển nội bộ và các công ty lớn. Các dự án nhỏ và lớn sẽ được trình bày. Tôi cũng sẽ xem xét sự phát triển nhanh từ quan điểm của khách hàng, các trường hợp mà việc phát triển được mua ở ngoài và cách các dự án giá cố định và các dự án tính theo giờ ảnh hưởng đến sự đãi ngộ.

Tài nguyên

Học tập

• "Một bài giới thiệu về các Phương thức nhanh" (David Cohen, Mikael Lindvall, Patricia Costa, 2004) thảo luận nhanh (agile) có nghĩa là gì, vai trò của quản lý, các phương thức nhanh phổ biến và các hướng dẫn cho việc quyết định một cách tiếp cận nhanh được áp dụng ở đâu.
  
  
• Đọc cuộc thảo luận của Wikipedia về phát triển phần mềm nhanh.
  
  
• Tìm hiểu về Scrum, một quy trình nhanh, có thể được sử dụng để quản lý và kiểm soát phần mềm phức tạp và việc phát triển sản phẩm bằng cách sử dụng các bài thực hành lặp lại, tăng dần.
  
  
• "Tại sao bỏ thầu cố định là xấu cho các khách hàng" (ScrumAlliance, 09.2007) luận về dự án nhanh và bỏ thầu giá cố định,
  
  
• "OpenUP In a Nutshell" (developerWorks, 09. 2007) khám phá OpenUP, một khung công tác của quy trình được phát triển gần đây cho việc phát triển phần mềm tập trung vào các công việc thực hành nhanh xuất phát từ Rational Unified Process (Quy trình thống nhất Rational).
  
  
• Đọc "Phân phối nhanh hiệu quả theo hướng toàn cầu hóa" (developerWorks, 10.2007) nếu bạn có các thị trường ở nước ngoài có yêu cầu quy hoạch đáng kể về chu kỳ phát triển để thích nghi với sự khác biệt văn hóa và ngôn ngữ.
  
  
• Các cuộc phỏng vấn của DeveloperWorks: Scott Ambler về phát triển nhanh (developerWorks, 04.2007) giải thích cách tiếp cận lặp lại và tăng dần này để phát triển, đưa ra các trường hợp nghiệp vụ của chúng, và xua tan một số chuyện hoang đường trong tiến trình này.
  
  
• Hãy sử dụng đoạn chương trình giới thiệu quảng cáo theo yêu cầu của IBM để tìm hiểu về các sản phẩm phần mềm khác nhau và các công nghệ của IBM.
  
  
• Theo sát với developerWorks Live! webcasts.
  
  
• Xem developerWorks Live! các sự kiện và các chỉ dẫn kỹ thuật.
  
  

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

• Tải về phiên bản đánh giá sản phẩm IBM và nhận được các bài thực hành của bạn trên các công cụ phát triển ứng dụng và các sản phẩm phần mềm trung gian từ IBM DB2®, IBM Lotus®, IBM Rational®, IBM Tivoli® và IBM WebSphere®.
  
  

Thảo luận

• Đọc những gì mà mọi người đang nói trong developerWorks blogs và dành tâm trí cho cộng đồng developerWorks.
  
  

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

Chấm điểm bài này

Bình luận

Về đầu trang

Mục lục

• Giới thiệu
• Ý nghĩa của nhanh
• Các nguyên tắc và lợi ích
• Tổ chức của bạn đã sẵn sàng cho một quy trình nhanh chưa?
• Theo dõi tiếp
• Tài nguyên
• Đôi nét về tác giả
• Bình luận