Analyst

Với kiến ​​thức sâu sắc về sản phẩm và kỹ năng giao tiếp mạnh mẽ, một số analyst sẽ có xu hướng chuyển sang vai trò product owner. Điều này đặc biệt phổ biến trên các dự án lớn sử dụng hệ thống phân cấp gồm nhiều product owner. Ví dụ, một product manager có thể đóng vai trò là Chief product owner cho toàn bộ sản phẩm, dành phần lớn thời gian của mình để hướng về người dùng và thị trường. Mặt khác, một analyst có thể đóng vai trò là product owner cho một vài feature team khác nhau, làm việc với product manager để biến tầm nhìn của product manager trở thành các product backlog cho các feature team đó.

Nhiều nhóm dự án nhận thấy rằng việc có một analyst trong nhóm rất có lợi, mặc dù cách thức làm việc của analyst sẽ phải thay đổi. Các dự án được quản lý theo kiểu truyền thống, nhiệm vụ của analyst dường như phải vượt xa nhóm dự án càng xa càng tốt. Trong một dự án Scrum, phân tích một cách kịp thời trở thành mục tiêu. Mục tiêu mới của analyst là cần đi trước nhóm dự án chỉ một chút, ít nhất có thể, trong khi vẫn có thể cung cấp thông tin hữu ích cho nhóm về các tính năng hiện tại và trước mắt trong ngắn hạn.

Các analyst có thể đóng vai trò quan trọng để giúp chuyển trọng tâm từ viết tài liệu yêu cầu sang nói về các yêu cầu. Bởi vì các analyst không phải đi xa trước đội dự án như kiểu cũ đã quen thuộc, họ cần làm quen với việc chia sẻ thông tin yêu cầu với nhóm dự án một cách không chính thức hơn là thông qua một tài liệu yêu cầu đồ sộ. Càng nhiều thông tin càng tốt nên được chia sẻ thông qua thảo luận bằng lời nói, nhưng các analyst sẽ vẫn cần ghi lại một số yêu cầu, đặc biệt là khi làm việc trong một nhóm dự án phân tán (distributed team). Nhưng những gì analyst viết sẽ không chính thức (formal) như là một tài liệu yêu cầu có chữ ký.

Trong các dự án truyền thống, các analyst thường trở thành người trung gian để qua đó các thành viên khác trong team và product owner giao tiếp. Trong một dự án Scrum, analyst sẽ trở thành người hỗ trợ thảo luận (facilitator) giữa product owner với team hơn là một người trung gian. Các thành viên trong nhóm và product owner cần nói chuyện trực tiếp. Thay vì là kênh truyễn dẫn cho tất cả các cuộc trò chuyện, analyst của một dự án agile tập trung vào việc đảm bảo các cuộc hội thoại đó có hiệu quả nhất có thể. Ví dụ một analyst có thể hướng product owner và nhóm nói về một user story này hơn là đi lệch sang một user story khác. (Bởi vì đây là nơi có nhiều nguy cơ thảo luận bị lạc lối). Hoặc analyst có thể truyền đạt sự hiểu biết ở mức khái quát (high-level) về một tính năng mới cho team trước khi  team và product owner thảo luận chi tiết. Trong một dự án truyền thống, một analyst có thể nói với nhóm “Tôi đã nói chuyện với các bên liên quan chính, hiểu những gì họ muốn và tôi đã viết ra tài liệu này mô tả chi tiết các yêu cầu của họ.” Ngược lại, trong một dự án Scrum, cùng là analyst đó sẽ nói: “Tôi đã nói chuyện với Product owner và có cảm nhận về những gì anh ấy muốn. Tôi đã viết sáu user story này để cho các bạn bắt đầu và tôi đã có một loạt các câu hỏi bổ sung để chúng ta hỏi kỹ thêm Product owner. Nhưng tôi muốn sẽ đi cùng một vài người của team khi thảo luận với Product owner.” Bạn có thể nghĩ rằng các analyst luôn làm việc ở và nhìn thấy trước một sprint ở sau sprint hiện tại của team. Thực ra không phải. Gregory Topp, một analyst của hãng Credit Services của Mỹ, nói rằng sử dụng Scrum đã cho phép anh ta tập trung làm việc cho sprint hiện tại. “Trước khi áp dụng Scrum, tôi phải tập trung vào các yêu cầu mà sẽ không được phát triển trong vài tuần tới, hoặc thậm chí không phát triển trong vài tháng tới. Bây giờ với Scrum, tôi tập trung vào sprint hiện tại (độ dài hai tuần), vì vậy tôi có thể dành nhiều thời gian hơn cho làm chi tiết các user story, cũng như làm công việc phát triển và thử nghiệm.” Ưu tiên hàng đầu của analyst là đạt được các mục tiêu của sprint hiện tại. Một analyst trong team Scrum sẽ hỗ trợ kiểm tra,  trả lời các câu hỏi, hoặc theo dõi câu trả lời cho các câu hỏi, về các tính năng đang được phát triển, và do đó các hoạt động như vậy sẽ không tiêu tốn 100% thời gian của analyst. Thời gian còn lại của anh ta analyst có thể sử dụng để nghĩ trước về những sprint sắp đến. Tuy nhiên, là một phần của team trong sprint hiện tại và dành một chút thời gian để nhìn về phía trước không giống như làm việc ở một sprint tương lai. Topp giải thích rằng việc đi trước team quá xa thực sự đã kéo lùi anh ta lại: “Tôi đã cố gắng đi trước team một hoặc hai sprint, xác định chi tiết của các user story. Tôi thấy rằng điều này làm cho sprint hiện tại bị ảnh hưởng. Nhiều lần các chi tiết về user story đã thay đổi ngay khi team thực sự bắt đầu làm việc với user story.” Một câu hỏi phổ biến là liệu các nỗ lực công việc mà analyst bỏ ra nhằm “nhìn thấy trước” một sprint tương lai có nên được đưa vào sprint backlog hiện tại hay không. Đề nghị của tôi là hãy đưa vào sprint backlog bất kỳ nhiệm vụ phân tích cụ thể nào có thể được xác định trong quá trình làm sprint planning. Ví dụ: giả sử team đang làm việc trên một ứng dụng phê duyệt hoặc từ chối các đơn xin cấp tín dụng. Nếu product owner và team đồng ý rằng sprint tiếp theo sẽ bao gồm công việc tính điểm tín dụng của ứng viên, thì các nhiệm vụ phân tích sơ bộ liên quan đến vấn đề tính điểm tín dụng đó cần được xác định, ước lượng và đưa vào sprint backlog. Mặt khác, nếu không biết rõ công việc của sprint tiếp theo, không có nhiệm vụ cụ thể nào liên quan đến sprint tiếp theo nên được đưa vào sprint backlog hiện tại.

Nhìn chung, nhiều analyst thích sự thay đổi của Scrum mặc dù họ phải từ bỏ vai trò “phiên dịch viên duy nhất” để giải thích mong muốn của khách hàng. Hai năm sau khi áp dụng Scrum, Topp đã nhận xét về mối quan hệ của anh ấy với những người khác trong nhóm đã thay đổi. “Bởi vì tất cả chúng tôi đều trong cùng một nhóm và đều làm việc trên cùng một user story cùng một lúc, nên nhóm có nhiều sự thống nhất hơn. Trước khi sử dụng Scrum, dường như từng chức năng (analyst, developer, người kiểm thử, DBA) đã được thực hiện trong một silo riêng. Bây giờ sử dụng Scrum, nhóm phát triển cùng nhau tập trung vào một tập hợp nhỏ các user story.”

Developer

Các developer làm gì trong một nhóm Scrum? Họ lập trình. Họ kiểm thử. Họ phân tích. Họ thiết kế. Họ làm bất cứ điều gì cần thiết để giúp nhóm hoàn thành công việc đã cam kết cho một sprint. Mặc dù có thể có các chuyên gia trong nhóm Scrum nhưng các chuyên gia cần sẵn sàng làm việc bên ngoài các chuyên môn của họ bất cứ khi nào cần thiết cho lợi ích lớn hơn của nhóm. Có những ngoại lệ. Một dự án phát triển trò chơi có thể, ví dụ, được hưởng lợi từ các chuyên gia về lập trình trí tuệ nhân tạo. Do tính chất chuyên môn cao của sản phẩm, các chuyên gia này có thể không làm gì ngoài chuyên môn của họ. Tuy nhiên, phần lớn các developer trong nhóm Scrum nên sẵn sàng đóng góp theo bất kỳ cách nào để tối ưu hóa năng suất lao động (throughput) của toàn bộ nhóm. Điều này có nghĩa là họ sẽ làm việc kiểm thử khi cần thiết, đôi khi sẵn lòng chuyển sang lập trình bằng một ngôn ngữ không sở trường, v.v…

Một trong những thay đổi nổi bật nhất đối với các developer trong nhóm Scrum là họ không còn có thể ngồi trong tổ của mình và chờ đợi để được hướng dẫn một cách chính xác những gì cần lập trình. Họ cần trở thành người tham gia tích cực để hiểu các yêu cầu sản phẩm. Quả thực có nhiều người chỉ đơn giản muốn được bày cho những gì phải làm. Tôi đã nghe nhiều developer nói kiểu như: “nếu tôi đã làm đúng những gì được chỉ bảo thì tôi sẽ không thể bị sa thải”. Các developer trong nhóm Scrum, giống như tất cả những người khác trong nhóm phải cùng chia sẻ trách nhiệm cho thành công chung của sản phẩm. Khi trách nhiệm này được cảm nhận đầy đủ, sẽ dễ dàng để thực hiện những điều vượt ra ngoài mô tả công việc bình thường.

Các developer cũng sẽ được nói chuyện với khách hàng và người dùng. Lượng công việc này có thể được điều chỉnh tăng hoặc giảm dựa trên khả năng của developer, đặc điểm của tổ chức, điểm mạnh của các thành viên khác trong nhóm và tính chất của dự án. Các developer không cần phải có phẩm chất của một nhân viên bán hàng vui vẻ. Nhưng đôi khi họ cần phải cảm thấy thoải mái khi nói chuyện với người dùng hoặc khách hàng, dù chỉ qua điện thoại. Tương tự như vậy, các developer được kỳ vọng sẽ dành nhiều thời gian hơn để tương tác với đồng nghiệp của họ. Developer không được phép đến lúc 11h và cứ thế đeo tai nghe cho đến khi lặng lẽ rời đi lúc 19h. Thay vào đó, các developer sẽ ngồi trong một không gian chung của nhóm, tham gia vào thảo luận, giúp đỡ người khác khi có vấn đề và tham gia thực hành pair programming.

Những thay đổi này có thể gây khó chịu cho nhiều developer bao gồm cả bản thân tôi, người đã tham gia vào lĩnh vực này bởi vì chúng tôi nghĩ rằng chúng tôi có thể ngồi một mình trong tổ của chúng tôi cả ngày. Khi làm công việc lập trình đầu tiên, tôi đã làm việc trong một căn phòng tối hoàn toàn khép kín để phát triển hình ảnh cả ngày. Tôi chỉ ra khỏi phòng để nghỉ ngơi và ăn trưa rồi lại quay về một mình trong bóng tối cả ngày và yêu thích công việc. Di chuyển đến thế giới ánh sáng và ra khỏi “tổ” là một thay đổi lớn. Chuyển từ không gian hộp kín sang một nền văn hóa năng động và nói nhiều là một sự thay đổi thậm chí còn lớn hơn. Các developer trong nhóm Scrum sẽ được yêu cầu thực hiện quá trình chuyển đổi này. May mắn thay, hầu hết chúng ta có khả năng thay đổi. Chúng ta có thể thích ở một mình, nhưng chúng ta thấy việc tham gia vào các cuộc trò chuyện có cấu trúc (như trong các cuộc họp và thảo luận ra quyết định về dự án Scrum) dễ dàng hơn nhiều so với các cuộc hội thoại không có cấu trúc như trong một bữa tiệc cocktail.

Ngoài những thay đổi về giao tiếp và tương tác, các developer gần như chắc chắn sẽ trải nghiệm những thay đổi trong cách họ làm công việc của họ. Nhiều thực hành kỹ thuật được khuyến khích áp dụng như test-driven development, pair programming, continuous integration sẽ là mới đối với họ. Nhóm có thể không chọn áp dụng tất cả các thực hành này ngay lúc đầu (hoặc trong một số trường hợp nhất định), nhưng tôi đề nghị tất cả nên được xem xét và thử.

Theo Mike Cohn

Succeeding with Agile