Case study: Dự án Scrum phân tán cho đường sắt Hà Lan

Scrum cung cấp một nền tảng đã được chứng minh cho việc thực thi các dự án. Tuy nhiên, trong mọi dự án quy trình scrum phải được điều chỉnh để phù hợp với các yêu cầu và hoàn cảnh khác nhau. Việc đó được thực hiện thế nào đóng vai trò lớn trong sự thành công hay thất bại của một dự án. Trong bài viết này, chúng tôi mô tả cách chúng tôi thực hiện thành công một dự án Scum lớn (20 man-years, 100.000+ dòng code), mà đã bị loại bỏ dưới cách tiếp cận truyền thống và bao gồm các developer ở cả Ấn Độ và Hà Lan. Vì mong muốn độc giả chạy thành công các dự án lớn, chúng tôi chia sẻ ở đây các bài học về: project startup, chọn đúng product owner, tầm quan trọng của estimate, giao tiếp hiệu quả, testing và documentation.

Giới thiệu

Đường sắt Hà Lan được sử dụng rộng rãi trên khắp thế giới, cung cấp phương tiện di chuyển cho 1.2 triệu hành khách mỗi ngày. Đường sắt Hà Lan xây dựng một hệ thống thông tin mới để cung cấp cho người lữ hành thông tin du lịch chính xác hơn, yêu cầu ít thao tác bằng tay hơn. Như một phần của chương trình này, chúng tôi xây dựng hệ thống PUB (publish) mà kiểm soát hiển thị thông tin một cách tập trung và hệ thống phát audio trong tất cả các nhà ga.

Sự cố gắng ban đầu để xây dựng hệ thống PUB được thực hiện sử dụng cách tiếp cận phương pháp waterfall truyền thống. Các đặc tả yêu cầu chi tiết được chuyển giao cho nhà cung cấp IT, mong đợi một hệ thống được xây dựng đầy đủ để hiện thực hóa mà không liên quan nhiều đến khách hàng. Sau 3 năm, dự án bị dừng lại do nhà cung cấp gặp thất bại trong việc bàn giao một hệ thống chạy được. Sau đó, khách hàng ký kết với công ty chúng tôi xây dựng một hệ thống PUB từ đầu. Chúng tôi đã giới thiệu cách tiếp cận Agile sử dụng Scrum, tập trung vào việc hợp tác gần gũi với khách hàng, giao tiếp cởi mở và làm việc trong sự tăng trưởng nhỏ.

Thiết lập các giai đoạn

Chúng tôi bắt đầu dự án với thời gian kick-off để thiết lập mọi thứ cần thiết trước khi sprint đầu tiên bắt đầu. 3 tuần kick-off này được hoàn thành bởi một project manager, một kiến trúc sư và một scrum master.

Sự lựa chọn một Product Owner mới đúng là một thử thách. Chúng tôi không thể tìm được một người nào vừa có thời gian, vừa có kiến thức chuyên môn và ủy thác để ưu tiên các yêu cầu. Chúng tôi giới thiệu hai business analyst để làm vai trò product owner. Họ có thể sẵn sàng và vì sự liên quan của họ trong sự cố gắng sớm để xây dựng PUB nên họ đã xây dựng rất nhiều kiến thức nghiệp vụ để trở thành một Product owner đại diện tốt cho một vài nhóm customer stakeholders. Quyết định cấp cao về độ ưu tiên và phạm vi được tạo bởi một project manager được chỉ thị bởi khách hàng, nhưng người đó có giới hạn trong sự sẵn sàng và có ít kiến thức chi tiết về yêu cầu. Nhìn chung, mô hình này làm việc ổn nhưng trong một vài trường hợp project manager đó đã thay đổi các sự ưu tiên mà đã thiết định trong suốt cuộc họp lên kế hoạch (mà anh ấy vắng mặt) và cuộc họp đã phải tiến hành lại. Lý tưởng thì người quyết định cuối cùng về độ ưu tiên nên có mặt ở cuộc họp lên plan sprint.

Bởi vì sự cố gắng sớm để xây dựng PUB, tài liệu chi yêu cầu chi tiết cho các phần của hệ thống đã sẵn sàng. Họ đã làm theo tiêu chuẩn MIL[1]. Form này không thích hợp để sử dụng trong planning và estimate [2] bởi vì chúng không được nhóm trong các phân đoạn nhỏ mà có thể được xây dựng, kiểm thử và làm rõ trong một sprint. Các Product Owner không có kinh nghiệm trong việc viết user story. Để xử lý việc này, Scrum Master giúp họ tạo product backlog ban đầu bao gồm các user story nhỏ và có thể estimate cho một vài iteration đầu tiên.

Phần mềm mà chúng tôi đã xây dựng là một phần của một chương trình lớn liên quan đến nhiều hệ thống phần mềm, xây dựng các hiển thị và cài đặt các hiển thị trong các nhà ga. Để có thể sắp xếp effort nhiều quy tắc này, các deadline họp hành rất quan trọng. Do đó, chúng tôi cần cung cấp một bức tranh hoàn thiện của việc lập kế hoạch. Chúng tôi đã tìm ra vấn đề sau vài iteration bằng việc tạo estimate "best-effort" cho các vùng chức năng này của hệ thống. Nhân tiện chúng tôi cũng cho thấy kiến thức chính xác về velocity của chúng tôi. Do đó, chúng tôi có thể theo dõi và giao tiếp rất tốt sử dụng release burndown chart. Bài học ở đây là bất kỳ estimate nào đều tốt hơn là ko estimate gì cả, thậm chí khi chỉ có rất ít thông tin.

Tăng cường các team phân tán

Sau khi kick-off, sự án bắt đầu với đội 7 người làm việc trong các iteration 2 tuần một. Từ đầu dự án, nó đã được lên kế hoạch để tăng cường sử dụng người ở tại n độ. Vì lý do đó, 2 người phát triển Ấn độ tham gia dự án từ sprint đầu tiên đến về sau. Họ làm việc bên phía khách hàng 6 tuần trước khi quen với lĩnh vực ứng dụng, sự hiện diện của khách hàng chính và phần còn lại của đổi phát triển.

Một trong những bước đầu tiền để trở thành một đội là thống nhất cách làm việc với nhau. Để thuận tiện chúng tôi có tổ chức cuộc họp về quy tắc và đặc quyền [3] với tất cả thành viên nhóm, bao gồm đồng nghiệp của chúng tôi từ Ấn độ. Trong cuộc họp này, chúng tôi quyết định các practice như pair programming, sử dụng công cụ, mục tiêu chất lượng, số giờ chủ chốt … ra sao và ghi lại chúng trong trang wiki. Đạt sự đồng thuận được chia sẻ bởi toàn bộ nhóm đã chứng tỏ rất hiệu quả đối với chúng tôi. Khi thay đổi các thứ đã được đồng thuận, ví dụ trong suốt một retrospective, các practice nên được cập nhật vậy chúng được cập nhật khi các thành viên mới tham gia nhóm.

Trong iteration đầu tiên, team đã chứng tỏ rằng có thể xây dựng, kiểm thử và làm rõ các user story mà định hình nên trái tim của hệ thống. Điều đó làm hài lòng khách hàng, đặc biệt bởi vì so sánh với sự nỗ lực trước kia, tiến trình được làm rõ sớm hơn nhiều và khách hàng có nhiều sự kiểm soát với diễn biến của dự án.

Sau một vài iteration chúng tôi tăng cường dự án: người phát triển Ấn Độ trở về nhà và chúng tôi thêm nguồn tại Ấn Độ và Hà Lan để tạo ra các nhóm Scrum với 5 nhà phát triển mỗi nhóm, chung một người kiểm thử. Cuối sự tăng cường đó là tăng 3 nhóm phát triển với 3 người kiểm thử. Chìa khóa trong cách tiếp cận của chúng tôi là mỗi nhóm Scrum bao gồm nguồn từ cả Ấn độ và Hà Lan. Phương thức này đã chứng tỏ rất thành công trong việc duy trì tốc độ cao và chất lượng [4]

Vậy làm thế nào để chúng ta có thể cùng làm việc từ những địa điểm khác nhau? Trước tiên, chúng tôi sử dụng skype nhiều. Chúng tôi có webcams, điện đài, míc tốt và màn hình lớn. Theo cách này, chúng tôi có thể thực hiện một buổi họp cùng với nhiều bên. Tất cả điều này sử dụng với các công cụ cá nhân và phần mềm miễn phí. Chúng tôi không cần bất kỳ khoản đầu tư đặc biệt nào hơn là nâng cao chức năng mạng kết nối ở Ấn Độ sử dụng UPS để đảm bảo chúng ta có thể tiếp tục dùng skype trong khi mất điện. Thứ hai, chúng tôi chọn chỉ pair-programming trong cùng một địa bản. Có nghĩa rằng chúng tôi có các cặp ở n Độ và các cặp ở Hà Lan. Theo kinh nghiệm của chúng tôi, tác động của pair programming vẫn yêu cầu bạn phải có cùng vị trí địa lý, không thể sử dụng các công cụ có sẵn.

Cuối cùng, chúng tôi đã sử dụng Phương pháp Scrum như một công cụ để kiểm soát xem ai làm việc gì và sprint thực hiện ra sao. Bởi các đội phân tán của chúng tôi, công việc diễn ra tốt hơn là một chiếc bảng trắng. Làm việc scrum cũng tốt khi thảo luận product backlog với các Product Owner.

Để thực hiện mô hình phân tán này chúng tôi phải vượt qua một vài thử thách. Ví dụ, product owner không cảm thấy thoải mái khi nói tiếng Anh. Theo Scrum, cuộc họp lên kế hoạch sprint gồm 2 phần: phần đầu, product owner sàng lọc user story với team và thiết lập độ ưu tiên cho sprint. Bởi vì rào cản ngôn ngữ, chúng tôi chọn tổ chức cuộc gặp này ở Hà Lan mà không có liên quan đến phần của bên Ấn Độ trong đội. Phần thứ hai của cuộc họp lên kế hoạch thường bao gồm việc xác định và estimate các task để thực hiện các user story. Phần này được thực hiện bằng tiếng Anh cùng với người phát triển Ấn Độ sử dụng skype, nhưng không có product owner. Chúng tôi sử dụng thêm thời gian để truyền đạt nội dung của cuộc họp đầu tiên. Chúng tôi tổ chức một Sprint demo chỉ trong nội địa và ở Hà Lan. Để cập nhật các thành viên tại Ấn Độ, thành viên team Hà Lan đã viết một bức thư về demo, cũng đã được phân phát cho các đơn vị còn lại của công ty. Bức thư trở thành một thứ phổ biến giữa tất cả các đồng nghiệp.

Chia team với sự tập trung vào kiến trúc

Dự án của chúng tôi là một phần trong chuỗi các ứng dụng, và phải phù hợp với cơ sở IT đã có của khách hàng. Trong khi các product owner của chúng tôi có nhiều kiến thức về các yêu cầu chức năng cốt lõi, họ lại không có nhiều hiểu biết về những yêu cầu trong bảo mật, ghi log, khả dụng, hiệu suất … Thật khó để có những yêu cầu đấy từ tổ chức của khách hàng vì nó đòi hỏi sự gặp mặt với nhiều người từ nhiều bộ phận. Công việc nghiên cứu kiểu này làm phá hỏng nhịp điệu lặp lại của Scrum. Để ngăn chặn vấn đề đó, chúng tôi quyết định lập ra một nhóm riêng biệt tập trung vào kỹ thuật kiến trúc. Công việc của họ là đưa ra các yêu cầu phi chức năng giúp chúng tôi có thể chuyển đổi chúng đến user story cho backlog. Chúng tôi thiết lập các cuộc họp “Scrum of Scrum” để đồng bộ với các nhóm chức năng. Chúng tôi thích làm việc trong mô hình này vì nó cho phép các nhóm chức năng làm việc công suất. Một vài người của chúng tôi đang làm việc trong nhóm kỹ thuật xây dựng có thể phát triển để thay đổi tốt.

Tài liệu

Khách hàng yêu cầu các tài liệu mở rộng theo chuẩn mực tài liệu MIL. Hơn nữa nó phải được viết bằng tiếng Hà lan. Rõ ràng rằng việc viết các tài liệu này có thể được thực hiện bởi người Hà lan. Tuy nhiên, những nhà phát triển và kiểm thử không quen với chuẩn MIL và viết ra các tài liêu như một hướng dẫn người sử dụng mà không phải là sự cạnh tranh chính của họ. Do vậy, chúng tôi quyết định thuê một người viết kỹ thuật có kinh nghiệm trong việc viết các tài liệu MIL. Điều đó giúp cho người phát triển và người kiểm thử trong các đội tập trung giải quyết công việc và đưa các phần mềm kiểm thử. Phương thức này đã được chứng minh thành công, nhưng chúng tôi cũng phát hiện ra rằng nó đòi hỏi sự liên kết giữa người viết kỹ thuật và các thành viên trong đội, điểu đó cần sự chú ý vì các nhà phát triển chỉ “muốn thuận lợi cho công việc của họ”.

Các yêu cầu

Product Owner, là nhà phân tích nghiệp vụ, thường viết các tài liệu yêu cầu mở rộng ở Hà Lan. Cho tiến trình của chúng tôi chỉ những user story trong một backlog và giải thích của Product Owner trong suốt cuộc họp lập kế hoạch là đủ. Tuy nhiên, tổ chức khách hàng yêu cầu tài liệu mở rộng. Để nó phù hợp với tiến trình Scrum của chúng tôi, chúng tôi quyết định chuyển yêu cầu thành các user story trong tổ chức với Product Owner. Kết quả là các yêu cầu đó được giữ ở hai chỗ: tài liệu yêu cầu và backlog. Điều đó thỉnh thoảng dẫn đến vấn đề khi các yêu cầu được cập nhật. Cần rất nhiều huấn luyện để đảm bảo Product Owner bắt đầu nhận trách nhiệm đối với backlog thay vì chỉ với các tài liệu yêu cầu.

Danh sách các user story cộng thêm giải thích của Product Owner đã đủ để xây dựng và kiểm thử phần mềm trong đội Scrum của chúng tôi. Chúng tôi không thật sự cẩn thêm tài liệu yêu cầu. Mặc dù, tài liệu yêu cầu có giá trị cho đội kiểm thử độc lập để kiểm thử lại, mặc dù trong một số iteration, nó khó để “map” các user story mà chúng tôi đã thực hiện với các phần trong tài liệu yêu cầu.

Nhìn lại, chúng tôi không có một tiến trình quản lý xử lý yêu cầu. Chúng tôi chỉ làm hết sức có thể trong hoàn cảnh chúng tôi phải đổi diện với những xung đột nhu cầu: nhu cầu chúng tôi là user story có thể được làm việc lặp lại và nhu cầu của khách hàng là làm việc với các tài liệu yêu cầu chi tiết.

Kiểm thử

Chúng tôi áp dụng kiểm thử tự động trong suốt dự án cho phép chúng tôi đưa ra phần mềm đã được kiểm tthử vào cuối mỗi sprint mà không có các lỗi hồi quy. Thậm chí khi hệ thống phát triển lên, chúng tôi thực hiện chỉ với một người kiểm thử trên một nhóm Scrum 8 người trong khi vẫn duy tri được chất lượng cao: đội kiểm thử độc lập phát hiện được ít hơn 1 sai sót trên mỗi KLOC.

Chúng tôi kiểm thử tự động trên hai cấp độ: unit test và acceptance test. Theo chuẩn, chúng tôi sử dụng JUnit và đo lường độ bao phủ code sử dụng Clover, sử dụng mục tiêu độ bao phủ code phía server là 80%. Acceptance test là tự động sử dụng Fitnesse. Đối với mỗi user story được thực hiện, một tập các acceptance test được viết bằng Fitnesse. Có một bộ kiểm thử mở rộng, lỗi hồi qui thường được tìm ra và sửa chữa trong Sprint. Mặt lợi khác của cách tiếp cận này là người kiếm thử có thể làm việc hiệu quả từ lúc bắt đầu Sprint, tạo các test case trước khi user story được thực hiện.

Có một vùng nơi chúng tôi đấu tranh với kiểm thử tự động. Phần của hệ thống là một ứng dụng với giao diện người dùng đa dạng và phức tạp. Kiểm thử tự động trong trường hợp này khó hơn kiểm thử tự động phía server. Do vậy, chúng tôi hầu như phụ thuộc vào kiểm thử thủ công cho giao diện người dùng-chức năng đặc biệt. Khi hệ thống phát triển, kiểm thử hồi qui mất càng nhiều thời gian. Tệ hơn, những người kiểm thử độc lập tìm ra lỗi hồi qui chỉ trong phần này của hệ thống. Kiểm thử tự động có thể tránh được điều đó. Bài học ở đây là, mặc dù kiểm thử tự động có thể thình thoảng rất khó, nhưng sẽ phải trả giá khi nó được tính đến muộn trong dự án.

Kết quả

Khách hàng cảm thấy hài lòng với sản phẩm mà chúng ta cung cấp. Nhận thấy rằng, hầu hết các dự án, chức năng yêu cầu, thời gian và ngân sách luân phiên thay đổi trong tiến trình dự án, làm cho việc “đúng thời điểm, đúng ngân sách” trở thành một thước đo mập mờ của sự hoàn thành. Điều quan trọng hơn là nhân tố thành công thường xuyên được thảo luận với khách hàng khi công việc đang tiếp tục và họ thể hiện sự hài lòng với kết quả. Không may, sự triển khai diện rộng trên quốc gia có thể tiềm tàng những vấn đề trong hệ thống khác mà đó là một phần của sự tráo đổi.

Khách hàng đã yêu cầu công ty kiểm toán độc lập vào kiểm toán phần mềm. Kết luận của họ là:

• Sự duy trì hệ thống là tốt
• Chất lượng source code cao

Theo báo cáo của họ, các kiểm toán bình luận họ chưa bao giờ có dự án có nhiểu điểm tích cực như dự án này.

Tóm lại

Một số những bài học quan trong mà chúng ta đã học từ dự án này:

• Rất khó có thể tìm ra một product owner vừa có những kiến thức chi tiết về yêu cầu vừa có ủy nhiệm lên độ ưu tiên. Thường thì không thể tránh khỏi việc nhiều người đảm nhiệm product owner đặc biệt là với các dự án lớn.
• Để hoàn thành đúng tiến độ, điều quan trọng là đảm bảo product backlog phải được hoàn thành và estimate. Theo yêu cầu, bất kỳ sự estimate nào cũng tốt hơn là không estimate, mặc dù có ít thông tin. Kết hợp với tốc độ của đội, việc này đưa ra những thông tin cần thiết cho việc đề ra kế hoạch release.
• Phương pháp scrum rất phù hợp với sự thực hiện của nhiều đội phân tán. Có mỗi đội Scrum bao gồm các nguồn ở cả Hà Lan và Ấn Độ cũng tốt cho tinh thần của đội và thúc đẩy chúng tôi làm việc trong sự giao tiếp hiệu quả. Về giao tiếp, phần cứng có sẵn và phần mềm miễn phí làm chi phí thực hiện thấp như thế này.
• Rất có ích khi bắt đầu một dự án phân tán với một buổi họp khởi tạo tại cùng địa điểm để tiến tới sự đồng thuận trong team practice.
• Những việc mà không phù hợp trong một Scrum Sprint (ví dụ: theo đuổi những người quan trọng, giao tiếp với các phòng ban khách hàng khác) có thể được kiểm soát hiệu quả hơn bởi một team riêng biệt. Việc này cho phép các team chức năng tập trung vào xây dựng phần mềm. Sử dụng một nhà viết kỹ thuật cống hiến cũng giúp trong khía cạnh này, thậm chí nếu nó làm thêm phí giao tiếp.
• Mặc dù không cần quy trình phát triển phần mềm nhưng tài liệu yêu cầu mở rộng có thể vẵn được yêu cầu bởi khách hàng. Trong một dự án Scrum, tuy nhiên, điều này không thể thay thế việc sử dụng user story. Nếu cả hai đều được sử dụng thì tổng phí của các yêu cầu hài hòa trong hai nơi nên được xem như một nhân tố trong khi lập kế hoạch.
• Việc kiểm thử tự động là việc sống còn trong tăng chuyển giao phần mềm, không bị cản trở bởi lỗi hồi qui. Trước khi dự án kết thúc, sự thu về phải nhiều hơn chi phí.