Bản tuyên ngôn kiến trúc: Chấp nhận phát triển nhanh, Phần 3

Vai trò của các bên liên quan về phát triển nhanh

Trong phần 3 của loạt bài này, tìm hiểu về vai trò của các bên liên quan trong một quy trình nhanh. Bài viết này thảo luận về các loại vai trò truyền thống khác nhau, cũng như các loại vai trò trong các quy trình nhanh về lập trình cường độ cao và Scrum.

Mikko Kontio, Giám đốc, Softera

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.



30 10 2009

Giới thiệu

Phần 1 của loạt bài này giới thiệu các quy trình nhanh, các lợi ích của việc sử dụng chúng và các yêu cầu đặt trong tổ chức có sử dụng chúng. Phần 2 thảo luận về các loại tổ chức khác nhau, chẳng hạn như các công ty bắt đầu hoạt động, các công ty sản xuất và các tổ chức nhỏ và lớn, thích ứng với sự phát triển nhanh như thế nào.

Trong bài này, tôi sẽ thảo luận về các loại bên liên quan khác nhau trong một quy trình nhanh và những thứ mà vai trò của các bên đòi hỏi. Các bên liên quan trong quá trình Srum được nhấn mạnh.

Trong phát triển phần mềm, bên liên quan (stakeholder) là một bên có ảnh hưởng đến hoặc có thể bị ảnh hưởng bởi các hành động của một tổ chức. Các bên liên quan là những thực thể bên trong hay bên ngoài của một tổ chức tài trợ cho dự án, quan tâm đến hoặc thu lợi nhuận từ các kết quả dự án. Các khách hàng và các thành viên của tổ chức phát triển là tất cả các bên liên quan.

Tôi sẽ mô tả các vai trò truyền thống trong một dự án phát triển phần mềm, sau đó sẽ mô tả sự giống nhau trong một quá trình nhanh, như là lập trình cường độ cao (XP). Tôi sẽ giới thiệu các cơ sở của Scrum và giải thích các bên liên quan (hoặc các vai trò) trong một dự án Scrum. Cuối cùng, tôi sẽ so sánh với các trạng thái đối kháng của nhóm về quy trình truyền thống và quy trình Scrum.


Các vai trò truyền thống

Tổ chức phát triển phần mềm truyền thống, sau đây gọi là nhà cung cấp (provider), có một số vai trò. Trong các quy trình chi tiết hơn, có một số vai trò cho tất cả các nhiệm vụ có thể và kiến thức cần thiết, chẳng hạn như kiến trúc sư phần mềm, nhà phân tích các yêu cầu, nhà thiết kế phần mềm, kỹ sư kiểm tra, v.v. Nhưng nếu bạn xem xét tất cả các vai trò theo một cách tổng quát hơn, bạn sẽ không có nhiều loại khác nhau đó.

Môi trường của khách hàng bên ngoài
Trong môi trường của khách hàng bên ngoài, phía khách hàng có những người ra quyết định nghiệp vụ và nhân viên kỹ thuật. Nhà cung cấp (tổ chức phát triển phần mềm) có nhân viên bán hàng, một nhân viên quản lý dự án và các thành viên của nhóm phát triển. Các vấn đề nghiệp vụ thực đầu tiên được truyền từ nhân viên kinh doanh của khách hàng tới cho nhân viên bán hàng của nhà cung cấp. Sau đó, nhân viên bán hàng truyền nó tới nhóm phát triển, nhóm này dần dần cố gắng để hiểu được vấn đề sao cho họ có thể đưa ra một đề xuất. Thông thường, nhóm phát triển và nhân viên kinh doanh của khách hàng không bao giờ gặp nhau; các yêu cầu kinh doanh được truyền đi theo các văn bản.

Truyền thông giữa hai bên có thể rất phức tạp. Các vấn đề phần mềm càng phức tạp, thì càng có nhiều khả năng đề xuất không phải là những gì mà nhân viên kinh doanh của khách hàng mong muốn.
Môi trường của khách hàng bên trong
Trong môi trường của khách hàng bên trong, phía khách hàng có nhân viên kinh doanh (hoặc nhân viên quản lý dự án) và tổ chức phát triển cung cấp các mặt kỹ thuật. Trong nhóm phát triển, nhân viên quản lý dự án có một vai trò then chốt bởi vì nhân viên quản lý dự án liên lạc với nhân viên quản lý kinh doanh và giải thích những khả năng. Trong tình hình này, các bên không mâu thuẫn, nhưng không theo cách làm việc cùng nhau. Họ chỉ làm việc về cùng một vấn đề

Trong cả hai trường hợp, kiến trúc sư phần mềm trong nhóm phát triển có một vai trò rất lớn trong việc chuyển các yêu cầu nghiệp vụ thành các giải pháp kỹ thuật. Sự thành công của dự án phụ thuộc vào kiến trúc sư phần mềm đã hiểu rõ các yêu cầu hiện tại và môi trường có thể có trong tương lai của dự án như thế nào.

Các quy trình truyền thống có vẻ khá quan liêu. Nhưng đối với các dự án lớn hoặc những tình huống với các chuỗi phức tạp của các nhà cung cấp hay phần cứng hệ thống, chúng có thể là các quy trình hợp lý duy nhất để sử dụng.


Các bên liên quan trong các quy trình nhanh

Các phương thức nhanh khác nhau có các loại giải pháp khác nhau tập trung vào mối quan hệ khách hàng-nhà phát triển. Điển hình các vai trò này đơn giản và chỉ có một vài thứ trong số chúng. Phía khách hàng rất đơn giản, tập trung vào cơ hội gặp những người hiểu rõ những yêu cầu nghiệp vụ và có thể đưa ra quyết định ngay tại chỗ, thay vì chờ đợi nhiều ngày hoặc nhiều tuần.


Lập trình cường độ cao (XP)

Lập trình cường độ cao cần một khách hàng tại chỗ. Một hoặc nhiều người — hầu như là thành viên toàn thời gian của nhóm phát triển — làm việc chặt chẽ với nhau để cung cấp thông tin gay cấn về ngữ cảnh nghiệp vụ của ứng dụng và đưa ra quyết định một cách kịp thời. Trong Scrum, người ra quyết định là chủ sở hữu sản phẩm mà nhóm phát triển đi gặp để có các thông tin quan trọng.

Ở phía phát triển, XP tập trung vào việc lập kế hoạch, thiết kế, mã hóa và thử nghiệm. XP cũng nhấn mạnh những người di chuyển xung quanh, do đó, các vai trò trong nhóm không tĩnh. Tất cả các nhà phát triển trong nhóm có thể và phải thực hiện nhiều hơn một vai trò. Bởi vì tất cả mã sản xuất phải được thực hiện theo cách lập trình hai phần, các vai trò pha trộn nhiều. Mỗi thành viên trong nhóm đều liên quan ít nhiều đến hầu hết các hoạt động. Tuy nhiên, có một số vai trò quy định cố định, ngoài các khách hàng tại chỗ, trong XP. Các vai trò đó là:

Vai tròMô tả
Lập trình viênTrung tâm của nhóm XP.
Nhân viên thử nghiệmChắc chắn khách hàng biết và có thời gian để viết và chọn, các cuộc thử nghiệm chức năng chính xác.
Nhân viên theo dõiGiữ bản ghi về thời gian ước tính và thực tế dùng cho việc phát triển để cho nhóm đó tìm hiểu đánh giá chính xác hơn.
Huấn luyện viênChắc chắn rằng quy trình đó đang hoạt động.
Ông chủ lớnCổ vũ và tin tưởng nhóm và đôi khi khẳng định rằng nhóm thực hiện những gì họ sẽ làm.

Những phần sau mô tả Scrum và các vai trò của các bên liên quan trong một quy trình Scrum.


Tổng quan về Scrum

Phần này chỉ cung cấp một tổng quan có mức độ rất cao về Scrum. Xem Tài nguyên để biết thêm thông tin.

Scrum là một quá trình phát triển phần mềm lặp, thường được sử dụng với sự phát triển nhanh. Scrum nhằm mục đích phân phối giá trị kinh doanh cao nhất trong thời gian ngắn nhất. Do các chu kỳ lặp ngắn, nên doanh nghiệp có thể nhanh chóng và liên tục kiểm tra phần mềm làm việc.

Scrum bao gồm một bộ các bài thực hành đồng bộ với dự án và xác định trước các vai trò mà chúng thiết lập các quy tắc về những ai làm gì trong quá trình phát triển. Mỗi một trong các công việc lặp, được gọi là một lần chạy nước rút (sprint), thường kéo dài từ 15 đến 30 ngày. Dự án này bao gồm một hoặc nhiều sprints.

Các tính năng trở nên được triển khai thực hiện trong một lần chạy nước rút đến từ một công việc tồn đọng của sản phẩm (product backlog) và các tính năng trở nên được chọn trong cuộc họp lập kế hoạch chạy nước rút. Trong cuộc họp này, nhóm phát triển bắt đầu nói về những thứ của các tính năng mong muốn mà họ nghĩ rằng họ có thể triển khai thực hiện tại lần chạy nước rút tiếp theo. Trong thời gian chạy nước rút này, công việc tồn đọng cho lần chạy nước rút được đóng băng lại — không ai có thể thay đổi các yêu cầu (trừ khi lần chạy nước rút được hủy bỏ và bắt đầu lại với một mục tiêu mới).


Các bên liên quan và các vai trò trong Scrum

Với Scrum các bên liên quan được gọi là "các vai". Có ba vai: chủ sở hữu sản phẩm, ScrumMaster và nhóm. Các vai khá giống như XP, giá như nó đơn giản hơn một chút.

Chủ sở hữu sản phẩm
Chủ sở hữu sản phẩm đại diện cho lợi ích của mọi người có phần vốn trong dự án đó và kết quả của nó. Vai trò này cung cấp kinh phí (hoặc chịu trách nhiệm về quỹ tài trợ) trong vòng đời của dự án và tạo ra các yêu cầu tổng thể ban đầu, các mục tiêu ROI và các kế hoạch phát hành. Danh sách các yêu cầu là công việc tồn đọng của sản phẩm. Chủ sở hữu sản phẩm có trách nhiệm dành ưu tiên cho công việc tồn đọng của sản phẩm để đảm bảo các tính năng có giá trị nhất được xây dựng lần đầu tiên.
ScrumMaster
ScrumMaster chịu trách nhiệm cho quá trình Scrum, chắc chắn tất cả mọi người trong nhóm biết về Scrum và đảm bảo chắc chắn Scrum được cài đặt theo một cách thích hợp nhất với tổ chức. Vai trò cũng chịu trách nhiệm đảm bảo mọi người làm theo các quy tắc và thực hành Scrum.

ScrumMaster loại bỏ những mọi trở ngại mà nhóm có thể gặp và đảm bảo chắc chắn các câu hỏi liên quan đến nghiệp vụ đến tận chủ sở hữu sản phẩm. Và ScrumMaster trợ giúp chủ sở hữu sản phẩm xây dựng và dành ưu tiên cho công việc tồn đọng của sản phẩm.
Nhóm phát triển
Nhóm phát triển chịu trách nhiệm phát triển các chức năng để triển khai thực hiện các tính năng. Các nhóm tự tổ chức, tự quản lý và có chức năng chéo. Các thành viên của nhóm có trách nhiệm chuyển các yêu cầu trong công việc tồn đọng chạy nước rút sang phần mềm làm việc.

Các thành viên trong nhóm đều chịu trách nhiệm phân phối kết quả. Không có các kiến trúc sư, các nhà quản lý kiểm tra, các lập trình viên cụ thể, v.v. Nhóm phát triển nên hòa trộn tốt các chuyên gia tài năng, có kinh nghiệm, những người có kiến thức về tất cả các nhiệm vụ. Nhóm tự quản lý các nhiệm vụ và quyết định ai làm gì và khi nào làm.

Ở mức độ khác, có hai nhóm người trong Scrum: những người tham gia vào dự án (gà con) và những người chỉ có quan tâm đến dự án hoặc kết quả (lợn con). Các tên con vật có từ một câu chuyện cổ thường được nói đến trong khi mô tả Scrum và nó cũng minh họa các nhóm:

Gà con và lợn con đang đi bộ xuống đường. Gà hỏi "Bạn có muốn mở nhà hàng với tôi không?" Lợn nghĩ về điều đó một lát rồi trả lời, "Vâng, tôi nghĩ là tôi cũng muốn như vậy. Bạn muốn gọi nó là gì?" Gà trả lời, "Thịt đùi lợn muối và những quả trứng!" Lợn đứng lại, nghĩ lại một lát và nói, "Tôi không nghĩ rằng muốn mở nhà hàng với bạn. Tôi muốn được cam kết, nhưng bạn chỉ muốn được tham gia."

Trong Scrum, những người được hứa hẹn (lợn con) với dự án là các thành viên trong nhóm, ScrumMaster và chủ sở hữu sản phẩm. Những người này đã đồng ý về các tính năng mà họ sẽ xây dựng trong lần chạy nước rút đó và họ có trách nhiệm về kết quả. Những người khác (như các nhà quản lý, các nhà cung cấp, những người sử dụng) là những con gà, những người có thể quan tâm đến các dự án, kết quả và ROI — nhưng họ không phải chịu trách nhiệm.

Cuộc họp Scrum hàng ngày là một phần quan trọng của lần chạy nước rút. Mọi người đều được chào đón, người đến muộn bị phạt và chỉ có những người được hứa hẹn (ScrumMaster, thành viên trong nhóm và chủ sở hữu sản phẩm) được phép nói chuyện. Các con gà có thể đến và lắng nghe, nhưng họ không được phép tham gia. Cuộc họp ngắn. ScrumMaster có hỏi mỗi thành viên trong nhóm ba câu hỏi:

  • Hôm qua bạn đã làm gì?
  • Hôm nay bạn sẽ làm gì?
  • Có bất kỳ điều gì theo cách của bạn không?

Cuộc họp Scrum hàng ngày không phải để giải quyết hoặc thảo luận về các vấn đề chi tiết. Các thành viên trong nhóm có thể đồng ý tổ chức một cuộc họp sau đó để bàn về các vấn đề. Chú ý rằng các câu hỏi không nhất thiết phải cung cấp hiện trạng cho ScrumMaster. Thay vào đó, chúng được hứa hẹn với các thành viên nhóm khác.


Kết luận

Trong bài viết này, bạn đã học về các vai trò và các bên liên quan trong các quá trình phát triển nhanh. Các vai trò đơn giản hơn nhiều so với trong các quá trình truyền thống hơn, khác. Các quá trình truyền thống thường phức tạp hơn và chúng tập trung vào việc xác định tất cả các vai trò khác nhau trong dự án phát triển. Với các dự án lớn mà có thể làm việc tốt — nếu bạn có một hoặc nhiều người làm việc toàn thời gian đối với mỗi vai. Mặc dù các quá trình truyền thống có vẻ khá quan liêu, đôi khi chúng có thể là quá trình hợp lý duy nhất để sử dụng.

Các dự án nhỏ hơn có ít hơn 20 người, các phương thức đơn giản hơn là có thể, và chúng có thể tạo ra quy trình quản lý và phát triển dễ dàng hơn và hiệu quả hơn.

Các vai trong các quy trình nhanh là đơn giản hơn nhiều và các nhóm có chức năng chéo. Trong Scrum chỉ có ba vai (chủ sở hữu sản phẩm, ScrumMaster và nhóm phát triển), mà chúng tạo ra công việc theo các quy tắc và các bài thực hành Scrum khá đơn giản. Các nhóm tự tổ chức và các thành viên trong nhóm có thể nhận các nhiệm vụ mà họ muốn tiếp tục thực hiện, do đó nhiệm vụ quản lý dự án truyền thống về theo dõi các nhà phát triển được giảm thiểu.

Tài nguyên

Học tập

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

Bình luận

developerWorks: Đăng nhập

Các trường được đánh dấu hoa thị là bắt buộc (*).


Bạn cần một ID của IBM?
Bạn quên định danh?


Bạn quên mật khẩu?
Đổi mật khẩu

Bằng việc nhấn Gửi, bạn đã đồng ý với các điều khoản sử dụng developerWorks Điều khoản sử dụng.

 


Ở lần bạn đăng nhập đầu tiên vào trang developerWorks, một hồ sơ cá nhân của bạn được tạo ra. Thông tin trong bản hồ sơ này (tên bạn, nước/vùng lãnh thổ, và tên cơ quan) sẽ được trưng ra cho mọi người và sẽ đi cùng các nội dung mà bạn đăng, trừ khi bạn chọn việc ẩn tên cơ quan của bạn. Bạn có thể cập nhật tài khoản trên trang IBM bất cứ khi nào.

Thông tin gửi đi được đảm bảo an toàn.

Chọn tên hiển thị của bạn



Lần đầu tiên bạn đăng nhập vào trang developerWorks, một bản trích ngang được tạo ra cho bạn, bạn cần phải chọn một tên để hiển thị. Tên hiển thị của bạn sẽ đi kèm theo các nội dung mà bạn đăng tải trên developerWorks.

Tên hiển thị cần có từ 3 đến 30 ký tự. Tên xuất hiện của bạn phải là duy nhất trên trang Cộng đồng developerWorks và vì lí do an ninh nó không phải là địa chỉ email của bạn.

Các trường được đánh dấu hoa thị là bắt buộc (*).

(Tên hiển thị cần có từ 3 đến 30 ký tự)

Bằng việc nhấn Gửi, bạn đã đồng ý với các điều khoản sử dụng developerWorks Điều khoản sử dụng.

 


Thông tin gửi đi được đảm bảo an toàn.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=70
Zone=Rational
ArticleID=441874
ArticleTitle=Bản tuyên ngôn kiến trúc: Chấp nhận phát triển nhanh, Phần 3
publish-date=10302009