Phần 2

Mô hình Agile tại Microsoft: Visual Studio

Không có gì đáng ngạc nhiên, nhóm Visual Studio là nhóm đầu tiên tại Microsoft chọn phương pháp tiếp cận agile. Thậm chí ngay cả khi Microsoft bị mắc kẹt bởi mô hình thác nước, các lập trình viên bên thứ ba sử dụng Visual Studio là những người mà mong muốn sử dụng phương pháp agile, tạo áp lực đối với Bộ phận Lập trình viên để xây dựng sự hỗ trợ tốt hơn đối với phương pháp tiếp cận này. Trong tương lai, các lập trình viên này thường xem xét, chuyển sang các công cụ phát triển tốt hơn, được cập nhật thường xuyên hơn, do vậy có thể cung cấp các bản sửa lỗi và các tính năng mới thường xuyên hơn.

Phiên bản đầu tiên của Visual Studio cung cấp một số hỗ trợ vô cùng ý nghĩa cho sự phát triển Agile  là phiên bản Visual Studio 2010, được công bố vào tháng 4 năm 2010, và được phát triển trên 2 năm trước đó. Tuy nhiên, đội nhóm của họ đã nhanh chóng nhận được phản hồi rằng một số mẫu được thiết kế dành cho các lập trình viên agile thì không hữu dụng. Chúng còn quá chung chung, không hữu ích riêng cho từng nhóm đối tượng.

Bộ phận Lập trình viên đã đồng thời tạo ra những bước đi đầu tiên hỗ trợ cho mạng trực tuyến, lưu trữ phiên bản của Team Foundation Server (gọi tắt là TFS) được gọi là Team Foundation Service (cũng được gọi tắt là TFS). Lần đầu tiên dịch vụ điện toán đám mây này đã giúp cho Bộ phận có cơ hội tốt để thoát khỏi chu trình 2 đến 3 năm phát hành phiên bản, thay vì chuyển qua một quy trình lặp lại và nhanh chóng hơn. 

Có hai cách sau đây: chuyển giao sản phẩm đến khách hàng không phù hợp với mục đích và chuyển giao một dịch vụ trực tuyến mới có sự lặp lại nhanh chóng là có thể và được mong đợi thúc giục nhóm để tập trung vào cách làm mới với mục đích phát triển phần mềm của họ.

Động thái này đã không được điều khiển từ đầu. Trong Microsoft, mỗi đội tìm ra phương pháp tốt nhất để phát triển phần mềm và nhóm Visual Studio đã nhận ra điều đó cần được thay đổi. Họ đã có một giải pháp trên quy trình agile được gọi là quy trình Scrum. Aaron Bjork của Microsoft- Giám đốc Quản lý chương trình của TFS đã nói về cách mà quy trình đó được thực hiện.

Các nhóm Scrum là các nhóm đa ngành của khoảng một chục người, bao gồm các vị trí phát triển, kiểm thử, thiết kế và phân tích. Công việc phát triển của họ được chia dự án thành nhiều công đoạn nhỏ với độ lớn cố định được gọi là sprint. Độ lớn của một sprint dành cho một nhóm, nhưng nhìn chung mỗi sprint thường mất trong khoảng từ 1 đến 4 tuần để hoàn thành. Các cuộc họp hàng ngày được tổ chức để báo cáo về quy trình  và có những cuộc họp “đứng” mà tất cả mọi người đều phải đứng và để đảm bảo kết thúc trong thời gian ngắn. Một trong những thành viên của nhóm là chủ sở hữu sản phẩm đại diện cho khách hàng. Chủ sở hữu sản phẩm nói về những câu chuyện của người dùng, mô tả chi tiết công việc mà một người sử dụng phần mềm muốn thực hiện. Những câu chuyện này được ưu tiên và được thêm vào danh sách những công việc phải làm.

Giai đoạn sprint ngắn gọn mang lại sự linh hoạt và có khả năng nhanh chóng đáp ứng các yêu cầu của khách hàng mới. Quy trình Scrum có một nguyên tắc, sau mỗi sprint, phần mềm có thể biên dịch và sử dụng, có thể triển khai sự phát triển và phản hồi nhanh chóng.

Nhóm Scrum của Visual Studio để cho mỗi thành viên nắm giữ một trong ba vai trò trong Microsoft: Quản lý chương trình (người trở thành chủ sở hữu sản phẩm ); một nhóm các lập trình viên với một người đứng đầu và một quản lý chất lượng (QA)với một trưởng nhóm QA. Mỗi nhóm riêng quản lý một đặc điểm của sản phẩm (backlog) trong đơn đặt hàng . Bắt đầu một quy trình sprint, một vài danh mục trong danh sách đặc điểm của sản phẩm (backlog) được chọn theo thứ tự ưu tiên, và cuối mỗi quy trình sprint, những danh mục này được hoàn tất sau khi được kiểm thử.

Điều đó đủ dễ dàng, mặc dù nó yêu cầu nhiều sự điều chỉnh. Bjork nói với chúng tôi rằng ban đầu các nhóm không thực sự có khái niệm sprint. Họ thử 5 lần cho giai đoạn phát triển sprint, trong đó có hai giai đoạn sprint “ổn định”. Trong khi chi trả cho dịch vụ agile với các sprint,về cơ bản nó giống như một quy trình thác nước cũ.  Nó cũng có các vấn đề tương tự. 

Giáo dục và kỷ luật áp dụng cho vấn đề này, các nhóm công nhận sự quan trọng của việc xây dựng quá trình sửa lỗi và chất lượng công việc trong các sprint quan trọng hơn việc đối xử với họ cũng như những nhiệm vụ khác mà họ thực hiện trong quá khứ. Sửa lỗi và đảm bảo các sản phẩm luôn luôn đạt chất lượng để có thể chuyển hàng là cần thiết để được tích hợp vào quy trình phát triển thường xuyên. 

Thậm chí với những việc nhỏ như độ dài của một sprint phải được học từ việc thử nghiệm và từ các sai sót. Nhóm Visual Studio giải quyết giai đoạn sprint trong vòng 3 tuần, đối với họ đó được gọi là độ dài Goldilocks.

Quy mô

Tuy nhiên, đó chỉ là khó khăn. Sự phức tạp thực sự của Microsoft là quy mô. Nhiều phương pháp này được xây dựng cho các đội nhóm nhỏ. Không có gì ngạc nhiên, hầu hết các nhóm phát triển trong nhà tại các công ty phi phần mềm thì không phải là điều lớn lao. Nhưng mà Microsoft là một công ty phần mềm, có hàng ngàn lập trình viên (khoảng 3000 người trong DevDiv) và hàng trăm đội nhóm, học cách làm việc linh hoạt trong khi vẫn còn được phối hợp thông qua quy mô của một tổ chức được yêu cầu sự thử nghiệm. 

Các nhóm hình thành các quan điểm theo thời gian khác nhau. Ngoài sprint, có một mùa “6 tháng” và  một tầm nhìn trong vòng “18 tháng”. Theo thời gian ngày một phát triển, sự chắc chắn của mỗi quan điểm giảm bớt dần. Một đội nhóm có một sự hiểu biết rõ ràng về những gì sẽ phải làm và những gì sẽ được chuyển giao trong giai đoạn sprint kế tiếp. Mỗi mùa ít phức tạp hơn trong khi nhìn chung nó sẽ nhận được sự ưu tiên nhiều hơn, tầm nhìn của một mùa là vẫn dễ thay đổi hơn. Nó có thể bị gián đoạn bởi cuộc cách mạng “Internet” hay “điện thoại thông minh” trong thời gian tới, nhưng vẫn thiết lập các mục tiêu rõ ràng hướng tới các sự chỉ đạo cho tổ chức.

Để theo dõi tất các những điều này, ba sprint một lần, các nhóm nói chuyện trực tiếp với PM, dev và QA. Các báo cáo này không thông qua sự phân cấp PM, dev hay QA, thay vì mỗi nhóm báo cáo trực tiếp. Các nhà lãnh đạo không quan tâm đến chi tiết cụ thể của các đặc điểm của sản phẩm (backlog) của mỗi đội nhóm nhưng lại quan tâm đến sự định hướng tổng quan của họ, các ưu tiên và bất kỳ vấn đề gì mà họ gặp phải. Sự giao tiếp, liên hệ này tạo cơ hội hòa đồng, phối hợp dễ dàng giữa các nhóm với nhau.

Thêm vào đó, tại mỗi thời điểm bắt đầu và kết thúc mỗi sprint, các nhóm gởi đi các email để cho biết những gì họ hoạch định phải làm và những gì họ cần phải hoàn thành. Sự liên lạc này tạo sự dễ dàng hơn để làm việc với bên thứ ba đó là những gì mà các đội hướng tới.

Có thể một trong các thay đổi quan trọng nhất là những gì mà nhóm Visual Studio thực hiện để tạo ra một môi trường làm việc nơi công sở. Theo cách truyền thống Microsoft để cho mỗi lập trình viên là một văn phòng riêng. Có một hệ thống phần cấp bậc. Ở mức thấp,  bạn sẽ bắt đầu tại một cơ quan nội thất không có cửa sổ (có thể thấy rằng chúng vô cùng ảm đạm và buồn tẻ). Được thăng tiến lên, bạn chuyển đến một văn phòng có cửa sổ, tiếp tục như vậy bạn có một góc văn phòng.

Có rất nhiều cơ quan riêng như đã nói. Việc phát triển có thể có nhiều phức tạp và các phiền toái trong suốt những công việc phức tạp không được hoan nghênh, mở các văn phòng lập kế hoạch là biện pháp ít hiệu quả nhất. Nhưng sự hợp tác của họ gặp nhiều khó khăn. Dưới một hệ thống cũ, không có bất kỳ sự bảo đảm nào cho rằng một PM sẽ gần gũi với các lập trình viên để làm việc cùng nhau, tương tự như đối với các kiểm thử viên phần mềm. Các cuộc thảo luận mặt đối mặt thông thường như việc đi dạo trên hành lang hay đi lên đi xuống cầu thang hay thậm chí như di chuyển giữa các tòa nhà, để các đội làm việc cùng nhau ở cùng một nơi.

Quy trình phát triển agile là một rào cản lớn. Sự cộng tác trực tuyến thì tốt, nhưng sự cộng tác trực tiếp giữa người với người với nhau thì tốt hơn. Trong mỗi người dấu hiệu đơn giản mà hiệu quả, như việc bạn nhìn thấy một lập trình viên đang đeo tai nghe, tức là họ không muốn bị làm phiền. Nhưng điều này thật khó có thể nhận biết qua trực tuyến.

Bjork cho chúng ta thấy không gian văn phòng mới của nhóm Visual Studio, nó rất khác biệt. Thay vì các văn phòng riêng tư, có các phòng nhóm rộng lớn đó là ngôi nhà mà mỗi thành viên của một nhóm trong một vài cụm với những chiếc bàn không vách ngăn. Phòng nhóm làm việc có một buồng điện thoại riêng nhỏ và không gian họp để thảo luận mà không làm phiền đến người khác. Các phòng đều có cửa sổ. Anh ấy cho biết có rất nhiều các lập trình viên từ bỏ các văn phòng tư nhân, và vị trí của mỗi người được sắp xếp theo thứ tự cho các góc văn phòng như mong muốn. Nhưng tổng quát, môi trường mới này thì thành công hơn. Là nơi diễn ra các cuộc thảo luận thông thường, để dễ dàng hơn cho các PM, các lập trình viên và các QA để chia sẻ  sự hiểu biết cho nhau là những gì mà họ đang cố gắng để đạt được.

Phần 4

Nguồn bài viết : arstechnica.com