Mr. X là một kiến trúc sư ngành dầu khí, ông ta thường nhận vẽ ( trên giấy) các bản vẽ liên quan tới việc xây dựng và lắp đặt các giàn khoan nhưng mỗi ngày ông ấy chỉ có thể vẽ được 3-4 bản vẽ cho khách hàng và ông ấy mong có cái gì đó giúp ông ấy có thể vẽ nhanh hơn và bán nó cho các khách hàng của mình thay vì tư tay vẽ.
Ông ấy muốn có một phần mềm cung cấp sẵn toàn bộ các chi tiết bản vẽ để ông ấy có thể gắp thả và sắp đặt nó cho việc tham dò giàn khoan và ông ấy có thể dùng nó để hướng dẫn cho đối tác dùng.....
Tuyệt vời ông ấy là một PO đúng nghĩa. Ông ấy còn hơn thế nữa là một Business Analyst trong ngành của ông ấy. Có thể mô tả những vấn đề(problem) mà ông ấy cần giải quyết, ông ấy mô tả được key business.
Problem đã có và nếu ngồi trên bàn họp. Lúc này mà nói mọi người đều bình đẳng. Nó chưa có gì liên quan tới lập trình, chưa có gì liên quan đến công nghệ. Nghĩa là QA lúc này không phải thi một cuộc thì trên sân nhà của Dev. Không có chuyện diễn ra một cuộc thi mà con cá phải trèo cây giỏi hơn con cọp.
Việc của chúng ta lúc này là đưa ra các examples, các patterns và cùng nhau thảo luận, đừng quên đưa ra ý kiến trái chiều để làm rõ hơn vấn đề, để đảm bảo chúng ta cùng nhau hiểu vấn đề đang bàn bạc và quyết định xem giải pháp ( Solution) sẽ được lựa chọn để tiến hành xây dựng.
Bây giờ chúng ta chuyển qua một domain (lĩnh vực) khác. Không phải là giàn khoan nữa là chứng khoán, là ngân hàng, là Logistics... ?
Dev có hiểu về những domain này không ? Lĩnh vực chuyên môn của họ là lập trình. Đưa ý tưởng hoặc giải pháp ngoài đời vào bên trong máy tính.
QA có hiểu về những domain này không ? Hên xui. Vì nhân lực QA đến từ nhiều nguồn. Chẳng may ra QA lại học đại học mà chuyên ngành của họ đúng với domain của sản phẩm thì không phải vậy là quá tốt sao.
Nhưng đứng trước domain không phải cái mình học, không phải chuyên môn của mình. Mọi người đều bình đẳng.
Chúng ta cùng nhau đưa ra sơ đồ chức năng, vẽ biểu đồ mẫu các chức năng dưới nhiều hình thức khác nhau... để mọi người cùng hiểu nghiệp vụ cái đã.
Như vậy mọi người cùng nhau hiểu thì khó có thể ông nói gà, bà nói vịt hay cãi nhau là 6 hay 9. QA sẽ tập trung chính xác vào cái cần kiểm tra sau khi dev implement xong solution.
Bạn thấy đó. BA đưa **problem**, key business
BA+QA+Dev: Bàn để cùng nhau đưa ra **solution**
Dev: Hiểu rõ solution sau đó dùng khả năng lập trình để **implement** thứ right thing.
QA: Hiểu rõ solution để **test** chính xác những thứ dev impelemeted.
Mr. X là một kiến trúc sư ngành dầu khí, ông ta thường nhận vẽ ( trên giấy) các bản vẽ liên quan tới việc xây dựng và lắp đặt các giàn khoan nhưng mỗi ngày ông ấy chỉ có thể vẽ được 3-4 bản vẽ cho khách hàng và ông ấy mong có cái gì đó giúp ông ấy có thể vẽ nhanh hơn và bán nó cho các khách hàng của mình thay vì tư tay vẽ.
Ông ấy muốn có một phần mềm cung cấp sẵn toàn bộ các chi tiết bản vẽ để ông ấy có thể gắp thả và sắp đặt nó cho việc tham dò giàn khoan và ông ấy có thể dùng nó để hướng dẫn cho đối tác dùng.....
Tuyệt vời ông ấy là một PO đúng nghĩa. Ông ấy còn hơn thế nữa là một Business Analyst trong ngành của ông ấy. Có thể mô tả những vấn đề(problem) mà ông ấy cần giải quyết, ông ấy mô tả được key business.
Problem đã có và nếu ngồi trên bàn họp. Lúc này mà nói mọi người đều bình đẳng. Nó chưa có gì liên quan tới lập trình, chưa có gì liên quan đến công nghệ. Nghĩa là QA lúc này không phải thi một cuộc thì trên sân nhà của Dev. Không có chuyện diễn ra một cuộc thi mà con cá phải trèo cây giỏi hơn con cọp.
Việc của chúng ta lúc này là đưa ra các examples, các patterns và cùng nhau thảo luận, đừng quên đưa ra ý kiến trái chiều để làm rõ hơn vấn đề, để đảm bảo chúng ta cùng nhau hiểu vấn đề đang bàn bạc và quyết định xem giải pháp ( Solution) sẽ được lựa chọn để tiến hành xây dựng.
Bây giờ chúng ta chuyển qua một domain (lĩnh vực) khác. Không phải là giàn khoan nữa là chứng khoán, là ngân hàng, là Logistics... ?
Dev có hiểu về những domain này không ? Lĩnh vực chuyên môn của họ là lập trình. Đưa ý tưởng hoặc giải pháp ngoài đời vào bên trong máy tính. QA có hiểu về những domain này không ? Hên xui. Vì nhân lực QA đến từ nhiều nguồn. Chẳng may ra QA lại học đại học mà chuyên ngành của họ đúng với domain của sản phẩm thì không phải vậy là quá tốt sao.
Nhưng đứng trước domain không phải cái mình học, không phải chuyên môn của mình. Mọi người đều bình đẳng.
Chúng ta cùng nhau đưa ra sơ đồ chức năng, vẽ biểu đồ mẫu các chức năng dưới nhiều hình thức khác nhau... để mọi người cùng hiểu nghiệp vụ cái đã.
Như vậy mọi người cùng nhau hiểu thì khó có thể ông nói gà, bà nói vịt hay cãi nhau là 6 hay 9. QA sẽ tập trung chính xác vào cái cần kiểm tra sau khi dev implement xong solution.
Hình ảnh được lấy từ quyển DBB in action của John Ferguson Smart.
Cốt lõi là phải cùng nhau tìm ra giải pháp. chứ không phải "bịt mắt" QA rồi bắt khám phá sản phẩm, tìm bug như chơi trò trốn tìm với Dev.