1. Giới thiệu về phần mềm Planning Poker
Hình 3.1 Planning Poker
Phần mềm tên là Planning Poker với mục đích tạo ra một cách để đánh giá độ phức tạp của một công việc một cách nhanh chóng và thú vị. Trong bối cảnh đa số phải làm việc remote thì công cụ này sẽ giúp việc đánh giá trở nên ít căng thẳng và không bị ảnh hưởng bởi ý kiến của một người khác. Công cụ này thường được sử dụng trong agile để có thể xác định được một cách nhanh chóng giá trị của một công việc và giải quyết các ý kiến không đồng thuận.
Các task này sẽ được lấy từ Azure DevOps để có thể vote ngay trên các công việc được giao một cách nhanh chóng mà không cần phải gõ lại công việc ngay khi bắt đầu vote.
3.1 Cách chơi planning poker.
Planning Poker sẽ có một bộ bài với các giá trị khác nhau được in trên mặt lá bài bao gồm số là các số trong dãy Fibonacci (0, 1, 2, 3, 5, 8, 13, 20, …) và một số ký tự khác.
Ký tự Ý nghĩa
0 Task này đã được hoàn thành
1/2 Task này quá nhỏ
1, 2, 3 Task này nhỏ
5, 8 ,13 Task này có giá trị tương đối
20, 40 Task này lớn
100 Task này rất lớn
∞ Task này là khổng lồ
? Không biết task này có giá trị bao nhiêu Nghỉ giải lao (Coffee break)
Các giá trị đó thể hiện số điểm (story point), lý tưởng là theo số ngày, hoặc bất cứ đơn vị nào mà nhóm dự tính. Các thành viên của nhóm cùng thảo luận về tính năng đó, đặt các câu hỏi với Product Owner nếu cần thiết. Khi tính năng này đã được thảo luận kỹ lưỡng, mỗi thành viên sẽ tự chọn một lá bài để đưa ra ước tính của mình. Tất cả các là bài sẽ được lật lên cùng nhau. Nếu tất cả các lá bài đó có giá trị như nhau thì giá trị đó được chấp nhận là ước tính của tính năng vừa thảo luận. Nếu không, các thành viên của nhóm cùng thảo luận về các ước tính mà mình đưa ra. Đặc biệt, những thành viên có ước tính cao và thấp cần đưa ra những cơ sở cho ước tính của mình. Sau một hồi thảo luận, mỗi thành viên chọn một lá bài để ước tính lại và các lá bài của họ lại đồng thời được lật lên.
Quy trình này sẽ lặp đi lặp lại cho tới khi đạt được sự đồng thuận của các thành viên hoặc họ quyết định rằng ước tính về tính năng này cần hoãn lại cho tới khi có thêm các thông tin bổ sung.
Hình 3.2 Quá trình chơi
3.2 Lý do xây dựng chương trình.
Sử dụng sức mạnh của tập thể, tránh trường hợp một thành viên chưa nhìn thấy hoặc có vấn đề không rõ về vấn đề được đồng đội bổ sung và đưa ra estimation thêm chính xác.
Sau đó toàn bộ team clear hoàn toàn với các vấn đề có thể gặp phải đối với vấn đề này.
Không cần phải sử dụng phần mềm từ bên thứ 3 để tiết kiệm chi phí đồng thời thêm các tính năng cần thiết và thuận tiện với yêu cầu của mình (như lấy thông tin task từ Azure DevOps và cập nhật lại thông tin trên đó).
Trong công ty sẽ có sẵn một chương trình để việc dự đoán giá trị một cách nhanh chóng mà không cần các thanh viên tham gia phải sử dụng phần mềm bên thứ 3.
2. Thực hiện
Do lúc tham gia thực tập bên KMS thì thời gian bắt đầu thực tập của các bạn khác nhau nên trong quá trình tiếp tục phát triển Planning Poker chỉ có làm việc với một bạn khác và các anh/chị bên team mentors.
Thành viên:
● Phạm Phúc Nguyên
● Đỗ Phi Long
Và các anh/chị bên team mentors.
3. Kế hoạch Tìm hiểu:
● Tìm hiểu các công nghệ cần thiết: MySQL, ReactJS, Typescript, Websocket, GraphQL, GraphQL Codegen, ASP.NET, C#, Hot Chocolate và EF Core.
● Đọc codebase phần frontend.
● Đọc codebase phần backend.
Chọn công việc (ticket):
● Chọn trước các ticket nằm gọn trong frontend.
● Chọn ticket sửa lỗi.
● Chọn ticket refactor code lại.
Thực hiện:
● Thực hiện sửa đổi front end.
● Refactor code ở front end lại ra thành nhiều component nhỏ hơn.
● Sửa lỗi Synchronize clock, thay đổi database và cập nhật model ở frontend và backend.
● Đưa tính năng thông báo người đăng nhập về backend.
● Loại bỏ các lần mở websocket không cần thiết.
● Loại cập nhật thông tin qua websocket không cần thiết.
● Refactor code kết nối websocket.
Kết quả: Đã hoàn thành toàn bộ ticket đã chọn và loại bỏ các bug bắt gặp trong lúc thực hiện các ticket trên. Áp dụng được các kiến thức đã học trong toàn bộ quá trình thực tập và cái thiện một ứng dụng có trước.