Con người team hiệu suất

Tuân thủ integrity: 

  Thông qua việc bạn coi trọng lời hứa của mình, tuân thủ commitment của team trong sprint, bạn sẽ cố gắng hết sức để giữ lời hứa của mình, cùng giúp team đạt commitment 

  Ví dụ: 

•  Lời hứa của bạn là trước 18h ngày X tôi sẽ hoàn thành tính năng B, bạn cần giữ lời hứa của mình, cố gắng hết sức để đạt được lời hứa ấy với chất lượng chấp nhận, khi bạn cảm thấy đã cố gắng hết sức mà ko đạt được, cần phải thông báo và đưa ra lời hứa mới, cũng như giải quyết hậu quả .

• Team bạn đưa ra commitment hoàn thành sprint goal, bạn cần cố gắng cùng team để thực hiện lời hứa ấy, thực hiện các chiến thuật như focus, support together để cùng nhau hoàn thành ticket nhanh nhất với chất lượng được định nghĩa theo Definition of Done 

Supportive: 

    Thông qua việc bạn sẵn sàng giúp đỡ những thành viên khác trong team cùng giải quyết bài toán của team, cùng nhau thực hiện lời hứa của team  cũng như bạn sẵn sàng giúp đỡ các team khác giải bài toán chung của công ty. Các thành viên là đồng đội cộng tác cùng nhau hiện thực hóa plan thành những value cho người dùng. 

•  Bạn sẵn sàng và chủ động giúp đỡ ngay khi nhận ra vấn đề  sẽ gây ảnh hưởng tới commitment hay chất lượng sản phẩm.

•  Khi một thành viên làm chậm hơn dự kiến, là vị trí nào bạn sẵn sàng nhảy vào cùng giải quyết. Ví dụ như tester gặp vấn đề về nhiều ticket, nếu bạn là dev hay ba bạn hoàn toàn có thể vào làm cùng bằng cách verify checklist hoặc hãy cố gắng nâng cao chất lượng khi chuyển test, nếu dev có vấn đề khó khăn về hiểu tài liệu, là ba và tester bạn cố gắng truyền tải clear nhất và có thể define những case người dùng gặp phải phổ biến hoặc không nhận ra, nếu pe có vấn đề về định lượng effort làm, dev test sẵn sàng join vào cùng để đưa ra 

• Bạn cộng tác, phối hợp với các đồng đội của mình để đưa sản phẩm nhanh hơn được golive, mang tới value cho người dùng. 

• Bạn thường xuyên lưu lại và chủ động sharing các knowledge qua từng sprint cho các thành viên khác 

• Bạn tôn trọng đồng đội của mình và luôn tìm cách giúp đỡ cải thiện đồng đội cùng vì mục tiêu chung 

Ownership:

 Tính làm chủ, sở hữu sản phẩm.Chúng ta cùng nhau làm trên các sản phẩm để mang lại value cho người dùng. 

•   Thông qua việc bạn sẵn sàng đóng góp vào sản phẩm, đóng góp vào các tính năng cung cấp giá trị cho người dùng,  tham gia tích cực vào sản phẩm, cùng tham gia vào quá trình làm đề bài với bên PO, PE ngay từ giai đoạn đầu 

•   Nếu sản phẩm có lỗi, hãy xem mình là gốc rễ của vấn đề, tận tâm tận lực và luôn sẵn sàng để giải quyết lỗi 

•   Luôn quan tâm tới tiến độ sản phẩm so với kế hoạch thông qua từng sprint từ đó luôn đưa ra action để cải thiện và cùng đồng đội của mình đạt được kết quả đề ra   

Việc có quyền sở hữu đi kèm với việc chủ động. Chúng ta tạo ra quyền sở hữu cho mình khi chúng ta có lòng tin rằng việc hành động là việc của mình, chứ không phải trách nhiệm của ai khác. Khi bạn có quyền sở hữu một căn nhà, nó mà cháy thì hành động dập lửa là của bạn, không phải của người qua đường. Khi bạn có quyền sở hữu với kết quả của sản phẩm, thì bạn quan tâm như thể đó là kết quả của cá nhân bạn. Việc thúc đẩy sản phẩm  hay "chữa cháy" sản phẩm  đều là việc của cá nhân bạn. Khi bạn thể hiện quyền sở hữu với đội nhóm, tổ chức hay công ty, bạn làm việc như thế đấy là đội nhóm, tổ chức hay công ty của bạn.

Bạn là người làm chủ, không phải ai đó khác.

Điều này không có nghĩa là bạn bị bắt buộc phải làm tất cả mọi việc, hay không được phép kêu gọi sự tham gia của người khác. Điều đó có nghĩa là bạn có nghĩa vụ hành động để tạo ra ảnh hưởng tới kết quả mà bạn đang sở hữu. Ví dụ bạn có thể có ý tưởng hay để thúc đẩy kết quả, nhưng nó không nằm trong phạm vi công việc của bạn, hoặc nó quá tốn thời gian hay việc thay đổi cần phải tác động tới 1 phòng ban khác: việc thể hiện quyền sở hữu ở đây nghĩa là bạn sẽ đem ý tưởng tới cho người khác, và thuyết phục lôi cuốn để nó có thể được thực hiện và hoàn tất.

Một người thể hiện quyền sở hữu cũng có nghĩa là chúng ta có thể đặt lòng tin người đó sẽ làm việc "đúng".

Rất nhiều công ty coi Ownership như một giá trị văn hoá. Có thể tóm tắt lại các định nghĩa về Ownership trong mấy điểm sau đây:

• Chủ động với công việc, không chờ đợi

• Để tâm tới kết quả, nghĩ về điều có lợi nhất cho tổ chức

• Lãnh trách nhiệm, không đổ lỗi

Read More →

8/01/2022 03:41:00 PM

Agile, High Perfomance

Acceptance Criteria trong Agile

 

1. AC (Acceptance Criteria) là gì: 

 Trong Agile, AC là một tập các yêu cầu được define  cần phải đạt từ góc độ người dùng khi một user story được coi là Done .  Mỗi User story sẽ có  một hoặc nhiều  Acceptance criteria, nên tối đa là 3, nhiều hơn thì nên chia nhỏ user story 

 Thông thường, PO là người có trách nhiệm verify AC của user story, PO sẽ kết hợp với development team để thực hiện viết AC trước khi backoog item được đưa vào sprint planning

“Pre-established standards or requirements a product or project must meet.” _Google 

2. Mục đích của Accpetance Criteria: 

•  Quản lý được những mong muốn của  user story, giúp team hiểu rõ cái gì trong yêu cầu, cái gì nằm ngoài yêu cầu 
•  Xác định scope rõ ràng hơn và giảm thiểu những mơ hồ 
•  Hạn chế những thay đổi gây ảnh hưởng tới sprint khi sprint active 
•  Giúp QA có thể verify lại nếu như tính năng đúng với yêu cầu của người dùng 

3. Thời gian viết Acceptance Criteria:  

     Có thể bắt đầu càng sớm càng tốt, muộn nhất là trước khi quá trình thực thi ticket được bắt đầu, tức là trước planning 1, thậm chí khuyến khích trước cả Refinement. Trong khi planning, bạn có thể bổ sung, tuy nhiên sẽ không phải là sprint planning mới bắt đầu viết AC. Sau buổi planning thì AC sẽ không được tự động update mà không có thông báo tới các thành viên của team. 

4. Ai sẽ viết Accpetance Criteria: 

Trong một cross-functional team, mọi người đều có thể viết được AC. Thông thường PO  hoặc Manager sẽ chịu trách nhiệm viết AC trước, hoặc ít nhất là khởi tạo thảo luận để tạo AC, đây là những người hiểu rõ  và đúng nhất về nhu cầu của người dùng tính năng. Tuy nhiên không hạn chế việc các thành viên khác có thể viết để cùng hoàn thiện AC, để cung cấp các góc nhìn khác nhau về tính năng sản phẩm.

PO hoặc PE sẽ thực hiện verify lại AC đảm bảo backlog item được người dùng chấp nhận và cùng hiểu đúng về backlog item . 

5. Format cho AC: 

Không có một format nào đúng hoặc sai trong cách viết AC của một user story, hãy lựa chọn một format phù hợp 

 Có 2 format chính để viết AC:

      5.1. Hướng ngữ cảnh ( Given/ When/ Then) - Scenario oriented (GWT)

• Ngữ cảnh:  tên của hành vi ngữ cảnh
• Given: Trạng thái đầu của ngữ cảnh 
• When: Một hành động mà người dùng thực hiện
• Then: Outcome của hành động tại When 
• And:   Sử dụng khi mỗi thành phần GWT cần có nhiều hơn 1

        Ví dụ: 

              Như là một user, tôi muốn lấy  lại mật khẩu của tôi, để tôi có thể login lại tài khoản 

         AC của user story sẽ như sau: 

           Ngữ cảnh:  Quên mật khẩu

           Given:  User được điều hướng vào trang Login 

           When: Khi user click vào nút 'Forgot Password' , hiển thị ô nhập email,

           And:   User nhập email hợp lệ vào ô địa chỉ 

          Then: User nhận được email từ hệ thống tới email ở trên 

  

     5.2 Hướng theo rule  (Rule oriented) :

      Trong một số trường hợp, format theo hướng ngữ cảnh có thể không phù hợp như là AC cho 1 user story đòi hỏi về mặt UX hay design, hoặc một user story không cần check về mặt ngữ cảnh 

     Ví dụ: 

     User story: 

         Là 1 user, tôi muốn sử dụng phần ô search để input postal code của tôi, như vậy  tôi có thể tìm thấy những gian hàng  trong khu vực đó 

      Acceptance Criteria sẽ như sau: 

• Phần placeholders  biến mất khi user bắt đầu nhập kí tự 
• Phần tìm kiếm bắt đầu thực hiện khi user bấm vào phím Enter trên bàn phím hoặc bấm vào nút Tìm kiếm 
• Phần kí tự input chỉ chấp nhận chữ số 
• Số lượng kí tự input không được nhiều hơn 8 kí tự 
• ...

6. Một AC được coi là hiệu quả: 

•  Các AC có thể dễ dàng test được, kết quả có thể nhìn thấy ngay chứ không cần cài cắm hoặc diễn dải bằng những thuật ngữ, triết lý, tài liệu dài dòng hàn lâm, chỉ đơn giản là pass hoặc không pass khi follow theo AC 
  
  
•  AC cần rõ ràng và ngắn gọn, không nênđi kèm những từ phủ định như "không", vì sẽ gây ra nhiều case theo các cách hiểu khác nhau 
  ví dụ: "Form đăng nhập không nên nhấp nháy đỏ khi người dùng nhập kí tự sai"  nên  " Những ô input trong form đăng nhập sẽ được set border màu đỏ và có chú thích khi người dùng nhập sai kí tự" 
  
  
• Mọi người cần được hiểu được:  AC khi bạn viết mà developer không hiểu thì AC đó không hữu dụng, nếu từ bản thân người viết AC vẫn mơ hồ thì nên clear rõ ràng, tránh viết chung chung như kiểu, giống một chức năng nào đó ở đâu đó 
  
  
• Nên sử dụng ngôn ngữ hành động hành động  . Ví  dụ thay vì viết " Bộ lọc A cần được thực hiện trong chức năng search"  hãy cung cấp thêm thông tin  "Người dùng sử dụng bộ lọc A  để tìm kiếm  được những sản phẩm đạt tiêu chí..." 
  
  
• AC nên viết dưới góc nhìn của người sử dụng:  Nên viết dưới dạng hành vi sử dụng của người dùng, với tính năng đó hành vi của người dùng sẽ như nào, họ mong muốn ra sao 
  
  
• AC không nên quá hẹp cũng không nên quá rộng

Read More →

2/07/2022 05:09:00 PM

Agile