Trong Agile có một nguyên tắc quan trọng đó là tránh làm việc theo từng giai đoạn. Trong một dự án Agile, không có việc triển khai theo trình tự các giai đoạn từ phân tích, tới khâu thiết kế, theo sau là viết mã và cuối cùng là công đoạn kiểm thử. Thay vào đó, các công việc được thực hiện chồng lấp, đan xen lẫn nhau thường được gọi là Concurrent Engineering (CE) – hay còn được gọi là kĩ thuật làm việc đồng thời.
Ví dụ, trong khi một thành viên nhóm đang thiết kế giao diện người dùng, thì đồng thời thành viên khác cần bắt đầu viết mã những tính năng của giao diện đó. Nhằm tránh việc sau này phải làm lại, lập trình viên sẽ bắt đầu lập trình một phần trong toàn bộ các tính năng, lưu ý rằng các phần này sẽ không được ảnh hưởng nhiều tới công việc thiết kế.
Nhóm cần cảm thấy thoải mái với những điều không chắc chắn
Để thực hiện được CE, nhóm phải thấy thoải mái nhất khi có những điều không chắc chắn xảy đến. Để khâu viết mã bắt đầu trước khi việc thiết kế hoàn thành, nhóm cần có tâm lý sẵn sàng với các vấn đề có thể bất ngờ xảy ra.
Hãy nhớ rằng trước khi một hạng mục Product Backlog được hoàn thành thì những vẫn đề này cần được giải quyết bằng các hành động cụ thể. Nhưng công việc có thể bắt đầu bằng một hạng mục Product Backlog mà không cần giải quyết tất cả những điều chưa chắc chắn.
Hãy cùng xem một ví dụ, giả sử một nhóm đang làm việc trên một user story có nội dung như sau: “Là một người dùng, tôi muốn đăng xuất sau n phút không hoạt động”. Chúng ta biết được rằng, cần có ai đó quyết định “n” ở đây là bao nhiêu thì user story mới được xem là xong. 30 phút? Hay 12 tiếng?. Nhưng có một điều chắc chắn rằng lập trình viên có thể bắt đầu viết mã mà chưa cần có câu trả lời cho giá trị đó.
Chúng ta cần một đáp án nhưng có thể VẪN CHƯA dùng tới nó
Một điều quan trọng mà các thành viên nhóm cần hiểu là họ có thể cần một đáp án, nhưng không phải luôn cần đáp án ngay lập tức ở thời điểm trước khi bắt đầu làm việc. Một số thứ có thể được giải quyết trong Sprint, giả dụ như khoảng thời gian mà người dùng không hoạt động.
Một khi các thành viên nhóm biết được rằng có những đáp án có thể tìm ra trong Sprint họ sẽ sẵn sàng để đối mặt với những thứ không chắc chắn. Đây là điều cần thực hành để triển khai đan xen công việc trong kĩ thuật đồng thời.
Các thành viên có thể làm việc độc lập nhưng cần cán đích cùng nhau
Khi các thành viên nhóm bắt đầu làm việc với cùng một hạng mục Product Backlog, điều quan trọng là tất cả các thành viên cần hoàn thành hạng mục đó cùng nhau. Trong một Sprint 10-ngày, với một user story lập trình viên nên bắt đầu vào ngày thứ 6, kiểm thử viên bắt đầu vào ngày thứ 8. Mục tiêu của nhóm là hoàn thành cùng nhau ở ngày thứ 10.
Tôi muốn so sánh việc này với một cuộc thi chạy 400 mét ở Olympic. Trên đường chạy, chúng ta thấy các làn chạy ở ngoài cùng bao giờ cũng dài hơn các làn ở bên trong, vì vậy các người chạy ở những làn này sẽ có vị trí xuất phát xa hơn trên đường đua của mình. Điều này để đảm bảo rằng mỗi người sẽ chạy một quãng đường là như nhau và họ sẽ hoàn thành ở cùng một vị trí, khiến cho việc đánh giá người thắng cuộc dễ dàng hơn.
Nhà thiết kế của bạn có thể đang ở làn ngoài cùng
Một nhóm Agile có thể coi nhà phân tích, thiết kế của nhóm đang ở những làn ngoài trong cuộc đua này. Họ sẽ cần khởi đầu sớm hơn một chút (Dĩ nhiêu là tôi biết rằng ở các cuộc thi chạy trong thực tế mọi người bắt đầu chạy ở cùng một thời điểm. Nhưng vạch xuất phát dành cho làn ngoài cùng cần hiểu là “sớm hơn” so với làn bên trong)
Nhiệm vụ của các nhà phân tích là xác định cần phải thiết lập những gì, còn nhà thiết kế thì cần tạo ra các công cụ trực quan, phác thảo hay các “điểm xuất phát” tương tự cho nhóm nếu nhóm có bất cứ cơ hội nào để xây dựng một kiểm thử tính năng ở trong một sprint.
Khi chúng ta nghĩ về các nhà phân tích và nhà thiết kế ở các vòng ngoài, chúng ta sẽ thấy việc họ bắt đầu sớm hơn các thành viên khác sẽ cho phép nhóm cán đích cùng một thời điểm.
Vậy họ cần bắt đầu sớm hơn bao lâu?
Không quá sớm mà cũng không quá muộn. Ở mức cần thiết là vừa đủ. Hãy nhớ rằng mục tiêu là sắp xếp đan xen các công việc với kĩ thuật đồng thời.
Tôi không nói rằng một nhà thiết kế phải làm việc riêng rẽ, hay bắt đầu trước 3 Sprint so với kế hoạch. Nhà thiết kế chắc chắn phải làm việc cùng với nhóm, nhiệm vụ ưu tiên của nhà thiết kế chính là giúp đỡ cho nhóm có thể hoàn thành công việc ở Sprint hiện tại. Nhưng thậm chí cả khi làm như vậy, hầu hết các nhà thiết kế đều có thời gian để chuẩn bị trước cho các công việc tương lai.
Với một Product Owner tốt cũng không có sự khác biệt. Một nhóm sẽ gặp rắc rối nếu như Product Owner chìm ngập trong khối lượng công việc lớn ở Sprint hiện tại, và khả năng cao rằng anh ta sẽ không biết làm gì ở các cuộc họp lập kế hoạch tiếp theo.
Trong khi đó, một số công việc nhất định sẽ cần được chú ý và thực hiện sớm hơn so với số còn lại. Sớm ở đây là ở mức “cần thiết” cũng cần được lưu ý ngang hàng như những công việc của Product Owner, nhà phân tích, hay nhà thiết kế.
Mục tiêu ở đây chính là bắt đầu với lượng thông tin vừa đủ mà nhóm cần để có thể hoàn thành mỗi hạng mục Product Backlog. Trong trường hợp có quá nhiều câu hỏi mở trong cùng một Sprint, họ sẽ không thể hoàn thành được hạng mục Product Backlog đó.
Nguồn: mountaingoatsoftware.com
