PDF:

Bản tuyên ngôn kiến trúc: Chấp nhận phát triển nhanh,
Phần 1
Phát triển nhanh có đúng cho tổ chức của bạn không?
Mikko Kontio ([email protected])
Giám đốc
Softera
30 10 2009
Mikko Kontio trở lại với mục bài tuyên ngôn kiến trúc của ông. Hãy tìm hiểu cách một tổ chức có
thể dịch chuyển theo hướng sử dụng các quy trình nhanh và về các vấn đề có liên quan đến tạo
nên sự thay đổi. Trong bài viết đầu tiên về chủ đề này, hãy khám phá các quy trình nhanh là gì,
các lợi ích của việc sử dụng chúng và các yêu cầu đặt ra cho tổ chức triển khai thực hiện chúng.
Tháng tới, Phần 2 sẽ thảo luận về sử dụng các quy trình nhanh trong các loại các công ty khác
nhau, bao gồm cũ và mới và cách các dự án nhỏ và lớn tác động đến kinh nghiệm của khách
hàng và của người bán.
Xem thêm bài trong loạt bài này
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).
© Copyright IBM Corporation 2009
Bản tuyên ngôn kiến trúc: Chấp nhận phát triển nhanh, Phần 1
Nhẫn hiệu đăng ký
Trang 1 của 7
developerWorks®
ibm.com/developerWorks/vn/
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.
Ý 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.
Hình 1. Phát triển dạng thác nước truyền thống
Tôi sẽ thảo luận các dự án lớn chi tiết hơn trong Phần 2 của mục này.
Bản tuyên ngôn kiến trúc: Chấp nhận phát triển nhanh, Phần 1
Trang 2 của 7
ibm.com/developerWorks/vn/
developerWorks®
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.
Hình 2. Công việc lặp lại đầu tiên trong một quy trình phát triển nhanh
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.
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.
Bản tuyên ngôn kiến trúc: Chấp nhận phát triển nhanh, Phần 1
Trang 3 của 7
developerWorks®
ibm.com/developerWorks/vn/
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ọ.
Bản tuyên ngôn kiến trúc: Chấp nhận phát triển nhanh, Phần 1
Trang 4 của 7
ibm.com/developerWorks/vn/
developerWorks®
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.
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.
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ộ.
Bản tuyên ngôn kiến trúc: Chấp nhận phát triển nhanh, Phần 1
Trang 5 của 7
developerWorks®
ibm.com/developerWorks/vn/
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.
Bản tuyên ngôn kiến trúc: Chấp nhận phát triển nhanh, Phần 1
Trang 6 của 7
ibm.com/developerWorks/vn/
developerWorks®
Đôi nét về tác giả
Mikko Kontio
Mikko Kontio có một nền tảng về phát triển và tư vấn phần mềm. Ông hiện là Giám
đốc tại Softera, một công ty phát triển phần mềm tập trung vào các cổng kinh doanh
và giải pháp tính cước viễn thông.
© Copyright IBM Corporation 2009
(www.ibm.com/legal/copytrade.shtml)
Nhẫn hiệu đăng ký
(www.ibm.com/developerworks/vn/ibm/trademarks/)
Bản tuyên ngôn kiến trúc: Chấp nhận phát triển nhanh, Phần 1
Trang 7 của 7