Cách estimate user story trong Agile theo points

I. Bối cảnh: 

 Trong buổi planning hay refinement team tiến hành estimate user story theo các ticket. Tuy nhiên team thường không rõ để estimate sẽ dựa vào những yếu tố nào để đưa ra số points cho mỗi user story

                                                        Minh họa: estimate thời gian làm các phương tiện

II.  Cách thức thực hiện: 

1. Các bước thực hiện: 

Bước 0: Lựa chọn khoảng estimation:  Lựa chọn dãy số Fibonanci 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144 

 Sẽ bao gồm 2 group: 

• 1, 2, 3, 5, 8, 13:  Những số nhỏ hơn đại diện cho thấy team đã rõ ràng về cách làm, mức độ phức tạp thấp hoặc quen, và đã rõ ràng 
• 21, 34, 55, 89, 144: Những con số này thường đi với những stories cần phải chia ra nhỏ hơn với mức độ phức tạp, rủi ro và mơ hồ cao 

Bước 1:  Lựa chọn và đồng thuận reference PBI ( project backlog items) 

Khi start những sprint từ sprint 2 trở đi, team có thể define được các ticket đã hoàn thành để làm reference,  lựa chọn ticket theo các story point theo mức độ effort ít nhất tới effort rất nhiều, đề xuất lựa chọn 3 mức.( khoảng nhỏ, khoảng trung bình, khoảng lớn) 

Khi team trưởng thành hơn, cải tiến hơn về estimation thì sẽ là thời điểm thích hợp để điều chỉnh lại tham chiếu ticket 

Bước 2: Với  product backlog items  tham chiếu này, sẽ cùng đi estimate với 1 ticket mới thì sẽ ở mức độ như thế nào so với những done items được lựa chọn ở bước 1, thực hiện estimation tool là Planning Poker trong buổi Planning meeting. Để so sánh tương quan hãy đi từ story có point nhỏ nhất, sau đó x2, x4 lần và tiếp tục x n lần tương ứng với effort cần bỏ ra ( độ phức tạp, mức độ rủi ro) để tìm ra được con số phù hợp trong chuỗi fibonanci cho story 

 Tips:

 - lúc lựa chọn point nếu phân vân giữa 2 con số, hãy chọn con số lớn hơn. 

 - Sau khi các thành viên cùng đưa ra số point cho story, pick point lớn nhất và nhỏ nhất để lắng nghe các góc nhìn khác biệt  ==> re-vote 

2. Cách thực hiện trong buổi planning meeting:

Technical sử dụng Planning Poker

1. Sau khi PE hay 1 thành viên nào đó trong team diễn giải về ticket, các thành viên đặt câu hỏi để làm rõ 

2. Sau khi đã clarify, các thành viên đồng loạt đưa ra con số mình chọn cho effort phải làm story ( mức độ phức tạp + độ rủi ro mơ hồ) 

3. Khi có sự khác biệt trong điểm thành viên đưa ra, lắng nghe ý kiến của thành viên đưa ra point lớn nhất và point nhỏ nhất 

4. Re-vote

3. Các qui tắc trong việc estimation: 

 -  Khi estimate cần kết hợp các yếu tố mức độ phức tạp và độ mơ hồ rủi ro 

 -  Không lấy điểm trung bình của các thành viên khi thực hiện planning poker 

 -  Không điều chỉnh story point khi sprint đang chạy 

 -  Không điều chỉnh tham chiếu story, tickets để tham khảo khi estimate ở mỗi sprint 

 -  Không nên cho điểm sub task, story point chỉ áp dụng cho parent, không cho điểm những bugs phát sinh do ticket đang phải done trong sprint gây ra  ( bugs trong quá trình phát triển) 

-  Không cho điểm lại những ticket chưa done còn dang dở từ sprint trước, nếu có extra cần tạo ticket khác 

4. Vậy làm sao để estimate tốt hơn: 

 Cách tốt nhất là cố gắng chia nhỏ story lớn thành các story nhỏ hơn, để nâng cao chất lượng estimate, khi retro luôn có tâm thế cần cải thiện estimate cần tốt hơn

Một số câu hỏi cần member tham gia estimate hỏi và nhận câu trả lời : 

•   Value mang lại của ticket cho khách hàng là gì ?   ( tránh lãng phí về tính năng mở rộng không cần thiết + biết được mục đích của ticket ) 
•  Tiket đã đủ rõ để estimate chưa ( giải pháp kĩ thuật đã có chưa, Acceptance Criteria  có đủ hiểu và đủ  để triển khai chưa), có cần chia nhỏ ticket ra  ngay không ? 
• Tester đã nắm được cách test chưa, những moduel nào ảnh hưởng ?

Read More →

8/19/2021 11:25:00 AM

Agile, home

Velocity trong Agile

Velocity trong Agile là gì ? 

  Như đã được học trong nhà trường, để đo tốc độ của 1 chiếc xe, ta dùng velocity (vận tốc). Tuy nhiên hãy tưởng tượng bạn lái xe và đồng hồ đo tốc độ bị hỏng. Bạn lái xe trong 2 giờ, bạn đi được 160 km, vậy bạn biết được trung bình bạn đi được 80 km trong 1 giờ

  Nếu mục đích của bạn đi được 200 km:
   - Bạn sẽ đi tiếp trong 30 phút nữa, hoặc
   - Bạn sẽ dừng lại ở đây sau khi đi được 160km  hoặc
   - Bạn không cần tiếp nhiên liệu và đi cho tới khi hết trong vòng 15 phút, tính thời điểm này bạn đi được 180km


Với project cũng tương tự như vậy: Vận tốc của team được đánh giá với số lượng stories từ product backlog.  Nếu bạn biết về tốc độ của team bạn, bạn sẽ biết được:
    - Khối lượng công việc có giá trị của team bạn đã hoàn thành và chuyển tới cho user sử dụng tính tới thời điểm hiện tại ( số lượng stories hoàn thành)
    - Khi nào team bạn có thể  hoàn thành tất cả các stories ở product backlog
    - Bao nhiêu stories sẽ được chuyển cho user, product owner vào 1 ngày định trước.

Đo vận tốc của team như thế nào ? 

 Chúng ta đơn giản dùng các biểu thức toán học 

 Ta có kịch bản như sau: Team của bạn hoàn thành 3 user stories. Tổng điểm cho 3 stories này là 20. Như vậy vận tốc của team là 20. Nếu ở vòng lặp tiếp theo ( sprint trong scrum, team của bạn hoàn thành được 30 điểm, chúng ta có vận tốc trung bình là 25 hay (20 SP +30SP) chia cho 2 vòng lặp = 25 SP 

  Vận tốc của team chính là số tổng điểm của các stories được hoàn thành bởi team trong 1 vòng lặp phát triển sản phẩm ( iteration hay sprint) 

Tại sao chúng ta phải làm như vậy : 

 Chúng ta cần biết vận tốc để làm :
      -  Đoán trước bao nhiêu công việc được hoàn thành và chuyển giao ở một thời điểm nhất định.
      -  Đoán trước ngày để hoàn thành và chuyển giao một khối lượng công việc bắt buộc phải hoàn thành
      -  Hiểu được giới hạn của team khi đề ra khối lượng công việc được hứa hoàn thành cho 1 vòng lặp ( sprint) 

Những yếu tố nào phụ thuộc tác động vào vận tốc: 

Giống như bạn lái 1 chiếc xe :
      - Chướng ngại vật  -- Những khó khăn thực hiện Agile và phát triển sản phẩm ví dụ như vấn đề về technical, vấn đề về con người, cách thức làm việc
      - Xăng xe -- Động lực trong phát triển sản phẩm
      - Kinh nghiệm của người lái xe -- Sự hiểu biết, kinh nghiệm của các thành viên trong team ví dụ như developer
      - Tình trạng của xe -- Môi trường làm việc của team
      - Những thứ nhìn thấy -- Sự trong suốt trong phát triển sản phẩm ( ví dụ: thông báo update cả team cùng biết)
      - Hướng đi  -- Những function sản phẩm
      - Giao thông/ luật  -- Qui trình
      - Đích tới -- Sản phẩm được bàn giao 

Chính vì vậy, nếu những yếu tố  trên không được định nghĩa đúng, đủ, và tuân thủ vận hành, vận tốc của team bạn sẽ giảm xuống. Điều này hoàn toàn đúng cho việc phát triển sản phẩm của team bạn 

Chúng ta có nên đếm cả những stories chưa hoàn thành ?

Câu trả lời là không. Vận tốc là những stories đã được hoàn thành và bàn giao. Sau đây là một vài lý do bạn không nên đếm cả stories chưa hoàn thiện:
       - Trong Agile sản phẩm luôn được thay đổi nếu bạn đếm số lượng chưa hoàn thành thì sẽ không có ý nghĩa, chúng ta chỉ nên tập trung vào những stories hoàn thành để biết được team đang tới đâu.         - Tỉ số giữa hoàn thành và chưa hoàn thành là con số tương đối nên nếu nhìn vào đó sẽ đưa ra đánh giá và hướng đi không đúng.
      - Chưa hoàn thành có nghĩa là storie chưa mang lại giá trị nào cho khách hàng

Vậy chúng ta nên làm gì với những stories : 

Hãy chia nhỏ những stories ra có thể. Đây là cách thức dễ dàng và hiệu quả khi đưa chúng vào các sprint và quản lý. Giống như phép chia để trị và gói gọn theo dạng cuốn chiếu

QA- Teams và vận tốc 

Lỗi và  những vấn đề bảo trì có được đưa vào trong tính toán vận tốc ? 

Có, nếu bạn estimate 1  số điểm cho 1 story. Sau khi đã sửa chữa các lỗi, nâng cấp bảo trì, sản phầm tiếp tục được bàn giao tới người dùng. Mặc dù có thể không có giá trị mới với người dùng, những bugs, bảo trì có liên hệ trực tiếp với giá trị, chất lượng sản phầm hiện có. Vậy để kiểm soát vấn đề về lỗi, chúng ta nên làm gì ? Có vài cách để kiểm soát chúng. "Không tạo ra lỗi". Sử dụng luật zero-bugs và ưu tiên 1-fix-bugs. Bất kể khi nào có lỗi, hãy hoàn thành nó ngay lập tức. 

Có nên so sánh vận tốc giữa các team khác nhau ?

Không. Bởi vì chúng ta làm việc dựa trên điểm cho mỗi story. Điểm này tuỳ vào từng team định nghĩa, nó không fix cố định cho tất cả các team. Nếu so sánh chúng ta sẽ tạo ra sự  bất công bằng cho các team. Điểm cho story có thể tham chiếu từ nhiều yếu tố.  ví dụ: độ khó của 1 story. Một team có thể khẳng định rằng stories có điểm là 400 SP hoặc với team khác chỉ là 2 SP.  Ước lượng điểm cho story chỉ mang tính chất tương đối.


Vây, làm thế nào để so sánh vận tốc làm việc giữa các team với nhau ?

Team A bàn giao được 800 SP, team B bàn giao được 30 SP. Điều đó có nghĩa là team A tốt hơn team B ?

 Thực sự chúng ta không cần biết rõ và cũng không cần quan tâm tới điều đó. Mỗi team thì tự thân có cách so sánh bên trong ứng với  các sprints. Vận tốc không dùng để đánh giá. Vận tốc chỉ giúp chúng ta cải thiện vấn đề thời gian -- giúp chúng ta trở nên tốt hơn, tốt hơn và tăng tốc, cũng như điều chỉnh cho phù hợp với nguồn lực vốn có từ đó thúc đẩy tinh thần team, nhìn nhận các vấn đề yếu kém gây vận tốc chậm


Nếu nhiều team làm việc trong cùng 1 project backlog thì sẽ ra sao  ?

Đây là 1 trường hợp khác biệt với trường hợp trên. Sẽ là bất hợp lý nếu các teams này sử dụng những tham chiếu khác nhau để tính điểm cho story. Chúng ta sử dụng điểm (story point) để dự đoán bao nhiêu khối lượng công việc được bàn giao tại 1 ngày nhất định, hoặc để dự đoán khi nào chúng ta có thể bàn giao được toàn bộ yêu cầu khách hàng. Vậy nếu chúng ta có nhiều hơn 1 team đang làm việc trên cùng 1 backlog, và nếu mỗi team lại có số điểm khác nhau cho 1 story, thì chúng ta không thể nào dự đoán được khối lượng công việc hoàn thành.
 Trong trường hợp này, team phải cùng nhau xác định mối liên hệ giữa các stories ( ví dụ như mức độ khó của các story), cùng định nghĩa số điểm cho story dựa trên cùng một tham số. Sau đó, mọi quá trình phát triển, thay đổi, team sẽ dùng đơn vị này để ước lượng thời gian, khối lượng, resource ( nhân sự- tài chính) để hoàn thành.
Lấy ví dụ như sau: Ta có 2 story là story A và story B. Story B có mức độ khó theo team phát triển và các chuyên gia gấp đôi story A, sử dụng thời gian nhiều hơn với story A. Story A sẽ làm trong 2 SP, như vậy story sẽ có số điểm là 4 SP



Sau cùng, với trường hợp sử dụng chung về kích thước số điểm của story, chúng ta có nên so sánh các team với nhau :

Không. Bởi vì có thể một team hoàn thành và bàn giao được ít số điểm story hơn bởi vì do story đó chưa được ước lượng đúng. Hoặc có thể team đó giúp team khác hoặc team đó dành nhiều thời gian cho việc kiểm thử, tối ưu code, tái cấu trúc code cho chuẩn tắc... Chúng ta chỉ nên so sánh nội bộ team, đào sâu tìm hiểu lý do tại sao team lại làm chậm. Làm như vậy bạn có thê tìm ra được vài  vấn đề cản trở team làm, và có biện pháp kịp thời để khắc phục và loại bỏ, phục hồi team.


Mỗi chiếc xe đều có đặc tính của nó. Chúng ta cần khai thác những đặc tính tốt nhất, cộng với bảo trì, sửa chữa. Nếu chúng ta bắt chúng làm việc quá với công suất hiện có, có thể bạn sẽ làm hỏng động cơ của chiếc xe.

Hãy giúp team bạn giỏi hơn, tiến xa, đừng chỉ có nhìn vào những điểm yếu cá nhân.

Con người thì vẫn là con người, chúng ta mỗi người lại có sự khác biệt. Chúng ta luôn có hiệu suất công việc khác nhau giữa các thành viên. Chúng ta luôn luôn cần giữ một môi trường bền vững, nhiệt huyết và giúp cho các thành viên của team tiến xa, để chèo lái và phát triển công ty của bạn.


                                                                                                                              Theo Scrumalliance

Read More →

12/11/2015 10:30:00 AM

Agile, ahome, home

Khi chuyển đổi sang Agile, bản thân và công ty bạn sẽ cảm thấy thế nào ?

Chuyển đổi cách thức làm việc từ truyền thống (waterfall) sang mô hình Agile luôn là giai đoạn cần có những thử thách và gian khó. Các cá nhân, tập thể sẽ cảm thấy tốt hơn, tồi tệ hơn,  hay cảm thấy rất khó khăn để chuyển đổi sang Agile. Có một số công ty thực sự không đạt được nhiều ý nghĩa lắm khi thực hiện quá trình chuyển đổi sang Agile.

 Viết stories, công việc được hoàn thiện trong các sprints, các cam kết và các cơ hội cho các cá nhân. Các team phát triển dường như đang làm đúng đắn... những vẫn còn thứ gì đó không đúng. Tàn dư của mô hình cũ vẫn kéo dài và tồn tại. Điều này có ý nghĩa là công ty đang có vấn đề khi chuyển đổi sang Agile. Để tìm ra nguyên nhân, ta hãy đặt các câu đơn giản sau ' Khi chuyển đổi sang Agile, bản thân và công ty bạn sẽ cảm thấy thế nào ?' Có những câu trả lời ' Thực sự công ty tôi không thấy sự khác biệt so với trước kia' hoặc là 'Nó tệ hơn cả trước kia, chúng tôi nghĩ công ty nên quay lại mô hình cũ'

Vậy nếu một tổ chức chuyển đổi đúng theo mô hình Agile sẽ cảm thấy ra sao ?

1.  Cảm giác về sự tường minh: Khi thực hiện chuyển đổi sang Agile, tổ chức sẽ phát hiện ra những bất cập, những yếu kém vốn có của tổ chức. Ví dụ như thói quen làm việc overtime của những cá nhân trong tổ chức. Mà chúng ta đều biết rằng, trong Agile làm việc overtime tức là hiệu quả làm việc của bạn có vấn đề, overtime sẽ phát sinh ra nhiều issue hơn là làm việc đúng giờ. Những cơ hội để cải tiến bộ máy, cách thức làm việc, qui trình mang lại hiệu quả cao luôn được đề cao và khuyến khích trong agile. Việc cho phép cải tiến và mắc lỗi sẽ  tìm ra được những vấn đề yếu kém của tổ chức. Đây thực sự là một điều có lợi. Ban đầu có thể có nhiều sự không hài lòng, nhưng cứ cải tiến tổ chức sẽ phát triển tốt.

2. Cảm giác về tính quyết định: Quyết định được quyết nhanh chóng không quan liêu. Tư duy chỉ tay làm việc không còn tồn tại trong Agile. Quyết định gần như ngay lập tức để xử lý các vấn đề gặp phải trong quá trình sản xuất và phát triển sản phẩm

3. Cảm giác về sự  kết nối: Giao tiếp là luồng xuyên suốt của bất kì một  tổ chức nào đó. Ví dụ về 1 mối quan hệ trong Agile,  mối quan hệ giữa technical và business chặt chẽ, không có sự phân biệt, làm technical chính là business và business chính là technical. Technical và business nếu là 2 cá thể độc lập phải luôn luôn kết nối trao đổi với nhau xuyên suốt quá trình phát triển. Các cá thể trong team là 1 thể thống nhất, đều có quan hệ chặt chẽ với nhau.

4. Cảm giác về tính tự làm lành: Đây là điều mà team mà tổ chức nhận ra những điểm yếu, những sai lầm và sửa đổi ngay lập tức. Không cần đợi từ phía leader thông báo về sự sai lầm và cách sửa đổi. Các thành viên chủ động hơn trong việc ra quyết định và sửa chữa những sai lầm phát sinh

5. Cảm giác về tính tự hồi phục: Tái cơ cấu và thay đổi tạo ra sự phát triển trong  Tính tự hồi phục giúp chúng ta chủ động hơn đối phó với những vấn đề không lường trước.

6. Cảm giác về tính sản phẩm: Khi chuyển đổi đúng với tư tưởng Agile, chúng ta sẽ cảm nhận được các tính năng sản phẩm được release nhanh hơn. Điều đó có được bời vì chúng ta loại bỏ những tính năng không bao giờ hoàn thiện hoặc đã lỗi thời bằng cách tập trung vào key của sản phẩm. Các thành viên với tính đa zi năng trong công việc cùng tập trung để release sản phẩm cho khách hàng. Với tính đa năng một thành viên có thể vừa làm ở vị trí này vẫn có thể đảm nhận ở vị trí khác. Từ đó ta không cần assign một người làm quá nhiều dự án hoặc team trong 1 thời điểm.

7. Cảm giác về không khí hoà đồng, thân thiện và thoải mái : Trong một tổ chức thực hiện chuyển đổi sang Agile tốt, tinh thần làm việc trong team vừa tập trung vừa đạt hiệu quả cao, từ đó team thật sự thoải mái cống hiến vì đã mang lại giá trị cho khách hàng và khách hàng happy về điều đó





                                                                               Edit from author: Len Lagestee - ProjectsAtworks

Read More →

11/04/2015 04:24:00 PM

Agile, ahome, home

Một số vấn đề gặp phải khi estimate trong Agile sử dụng kĩ thuật Planing Poker

                                                        image source  from : Wiki

Nếu đã từng làm việc với Scrum method trong Agile, chắc hẳn bạn có biết tới kĩ thuật estimation - Planing Poker. Đây là một kĩ thuật  đơn giản và hiệu quả trong việc estimation, giúp cho team thoả mãn tiêu chí transparent cho toàn team, thể hiện tính commitment của từng cá nhân với tập thể.

 Tuy nhiên hầu hết các Scrum team luôn có những vấn đề gặp phải dẫn tới hiệu quả cũng như tính chính xác trong estimation không cao


 Planing Poker :
 Thời gian:    Thường trong buổi họp estimation sau khi đã có tương đối (chưa cần hoàn thiện) các stories  trong project's backlog, hoặc buổi họp planing meeting sẽ define chi tiết hơn, chúng ta sẽ sử dụng Planing Poker để estimate. Tôi thường có một buổi general estimation và buổi planning meeting để break down thêm với team và nhận được sự confirm và commitment từ phía các thành viên trong scrum team.

 Phương thức: Team sẽ có các lá bái, mỗi là bài tương ứng với 1 con số, 0, 1/2 và  trong dãy Fibonacci : 1, 2, 3, 5,8, 13,... tương ứng với các story point sẽ được gán - estimate cho từng story
Trong quá trình estimation, với mỗi story, scrum master sẽ đóng vai trò dẫn team, team member sẽ đưa lên lá bài mà a ta cho rằng sẽ mất thời gian như vậy để làm xong story đó. Quá trình cứ diễn ra theo từng vòng cho tới khi thống nhất được lá bài tương ứng với story đó. Quá trình đảm bảo ở mỗi vòng mọi thành viên liên quan đều được đưa ra estimation.

Lợi ích: 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ề story đượ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 story này



Sau đây là một số vấn đề mà các Scrum team có thể gặp phải và cách có thể tránh được những vấn đề này.

1.  Estimation của bạn bị phụ thuộc người khác ngay từ vòng estimation đầu tiên.

Giả sử bạn phân tích và đưa ra estimation cho story là 21, tuy nhiên trước khi scrum master đề nghị các bạn bắt đầu vote, một thành viên trong team có năng lực báo rằng:'ok chúng ta bắt đầu vote, tuy nhiên tôi thấy đây là 1 function nhỏ, đơn giản, chắc sẽ không tốn thời gian'. Bạn bỗng trở nên phụ thuộc vào và có khả năng đưa ra nhận định cho story sai lầm, vì bạn sợ trở nên ngớ ngẩn trước mắt mọi thành viên.
Để khắc phục tình trạng này scrum master nên để công bằng với hết mọi người, mọi người sẽ chỉ phát biểu và thảo luận sau vòng estimation thứ  nhất 


2. Không phân tích tại sao lại có estimation thấp nhất và cao nhất

Xin đưa ra 1 ví dụ
  An đưa ra estimation là 5
  Bình đưa ra estimation là 1
  Hải đưa ra estimation là 8
  Chung đưa ra estimation là 21

Trước khi bắt đầu vòng tiếp theo Scrum master cần phải bàn luận với team tại sao chúng ta đưa ra estimation lại khác biệt như vậy, trường hợp An và Chung.

Sau khi clear thì mới bắt đầu vòng estimation tiếp theo cho tới khi các estimation gần về với nhau nhất

3. Bạn chỉ estimate công việc của bạn:

Trong scrum team luôn có sự mix giữa các vị trí, tuy nhiên trong thực tế ở một thời điểm thì bạn sẽ có 1 vai trò. Khi estimation, bạn chỉ estimation cho phần công việc của mình mà không quan tâm tới ảnh hưởng với toàn team hoặc bạn biết đã làm 1 story tương tự như vậy với một vị trí , nhưng bạn không có nói ra trong buổi họp estimation. Scrum team đòi hỏi sự đoàn kết, cộng tác giữa các thành viên trong team. Điều đó giúp team estimate các story ngày một chính xác hơn
Thực tế sẽ có estimation cho developer, estimation cho QA và tester.

4. Bạn không định nghĩa Done rõ ràng:

Đây là một lỗi rất cơ bản mà các team thường bị miss, ngay cả trong quá trình phát triển các sprint, team cũng cần luôn re define lại định nghĩa này cho phù hợp.
Bàn đến quá trình estimation, team cần đưa ra một định nghĩa Done phù hợp nhất với ban đầu để đưa ra estimation. Với định nghĩa Done như vậy, team sẽ xác định và không nhập nhằng khi đưa ra estimation.

Hi vọng 4 quan điểm được nêu ra sẽ giúp ích được bạn trong quá trình estimation của Agile sử dụng kĩ thuật Planing Poker.


Nguồn tài liệu tham khảo:

Benjamin Day

Scrum Coach, Trainer, Developer

Read More →

4/27/2015 11:46:00 AM

Agile, ahome, home

Hành trình 2 năm trên đỉnh Muối

Sau bao ngày tháng mong đợi, ngày chúng tôi quyết tâm thực hiện chuyến đi trek đỉnh Muối trên đường leo lên đỉnh Bạch Mộc Lương Tử. Trước khi đi được những bạn đi trước đánh giá mức độ khó 1.5 cung Cát Cát của Fan nên trong lòng cũng có hơi chút lo lắng. Nhưng đã quyết tâm rồi, mức độ khó càng tăng, thì càng phải làm cho kì được.

Ngày 31/12 là ngày cuối cùng của năm dương lịch 2014, sau khi vội vã hoàn thành những công việc của ngày cuối năm, tôi và 2 bạn  trong đoàn  cùng lên tàu đến Sapa. Đây là lần đầu tiên tôi đón tết dương lịch trên tàu, cũng có chút phấn khích. Nhưng sự phấn khích ấy bị dập tắt ngay vì đi tàu là một phương tiện quá ồn ã, khoang ghế ngồi không tài nào chợp mắt được, đi lại các khoang với nhau cứ bồng bềnh chông chênh. Cứ chợp mắt được lúc lại thức dậy, cũng may mắn là đến 12 giờ thức để nói câu "Welcome, new year, 2015 ! " và  nói ra vài plan được. Giấc ngủ cứ chập chờn cho tới 3h sáng, ngồi bắt chuyện với a người Lào Cai cho tới khi tàu dừng.

Tàu dừng, không khí ở Lào Cai cũng không khác biệt mấy so với HN, nên cảm giác chênh lệch về nhiệt độ không thể hiện rõ nét.

Tiếp theo một chuyến bus từ Sapa lên LC. Giờ từ LC lên Sapa thật tiện lợi với xe bus.

Một nét Sapa ngày trở lại

Porter của chúng tôi là nhà Tủa 1, chúng tôi hay gọi thân mật là ông già, hay bố già, tên thực là Vừng a Sáng. Đoàn chúng tôi thuê tổng cộng 3 porters , thêm  con trai của bố già a Phụng và Mỉ. Cả đoàn xác định đã đi chơi là vừa trải nghiệm vừa thưởng thức. Chúng tôi sẽ trải nghiệm cảm giác đi trên những con đường mòn, những địa hình khác biệt, chèo đèo, lội suối, băng rừng đủ cả, thưởng thức cảnh núi non hùng vĩ khi nhìn từ những đỉnh núi xuống thung lũng, thưởng thức món ăn của núi rừng, lợn cắp nách, gà chạy đồi.


Hành trình bắt đầu là quảng đường chạy xe  4km đường đèo từ nhà bố già đến chân núi. Gửi xe dưới chân núi và chúng tôi bắt đầu hành trình của những thợ săn mây và ý chí kiên định của những trekkers

Vạn sự khởi đầu nan, 2 trong số 6 xe của chúng tôi đi lạc thẳng xuống phía dưới cách vị trí rẽ trái 10km, sau khi gửi xe và đợi. Thời gian dự kiến là 1h giờ đã là hơn 2h chiều, nên chúng tôi quyết định chia thành các tốp nhỏ, để những người có thể lực yếu hơn đi trước.




Qua con dốc đầu tiên cũng không mấy khó khăn chỉ một chút chưa quen với việc leo và không khí loãng, mồ hôi túa ra, nóng phừng phừng. Chúng tôi quyết định dừng lại và sử dụng  gậy để đi tiếp. Leo lên dốc, những cây gậy sẽ làm điểm tựa để cho phần trọng lực cơ thể được nâng lên.

Tuy nhiên đó chỉ mới là đầu bản, bản nằm theo con dốc là lối mòn dẫn vào bìa rừng. Ở vùng núi nếu nói rừng không giống như  rừng ở đồng bằng. Điều đó có nghĩa là càng đi vào rừng bạn càng phải lên cao.

Những đứa trẻ vùng cao ở đây đáng yêu một cách lạ kì, chúng hồn nhiên và dễ thương, nhưng  cũng rất đáng thương dưới cái rét của mùa đông trên Sapa.

Xuất phát muộn, đến 6h tối chúng tôi mới bắt chỉ vượt qua được bãi chăn dê đầu tiên. Cả đoàn rừng lại trên một mỏm đá để tiếp sức bằng bánh mì và chuẩn bị vượt chặng đường nguy hiểm nhất, trên đường trở về buổi sáng chúng tôi mới nhìn rõ nó nguy hiểm thế nào. Đêm tối đèn pin bật lên chúng tôi bám sát và lần theo con vực để bước từng bước đi. Dựa vào kinh nghiệm leo núi, bám sát vào bất cứ thứ gì từ phía chắc chắn  để bước đi, bên phải là vực chỉ cần một sơ xuất là chúng tôi sẽ tụt xuống, nếu rớt xuống với cái lạnh 0 độ và ẩm, thì sẽ không biết thế nào. Người bạn đồng hành của tôi là một bạn nữ lúc đó thực sự đã rất  mệt với việc leo bộ hơn 4 giờ liên tục trong cái lạnh của rừng núi.  Tốp chúng tôi là tốp cuối cùng. Chân tay mệt rã rời nhưng vẫn cố bước tiếp.

 Nhắc đến 2 cô bạn đồng hành cùng chúng tôi, tuy thể lực yếu nhưng ý chí không hề yếu, cũng là một phần tôi cảm nhận và tiếp thêm sức lực cho chính mình.

Cái rét đã xuống rất sâu, tôi có thể cảm nhận được hơi lạnh buốt vào da thịt, đã có thể nhìn rõ hơi thở của mình, tưởng chừng tôi có thể nghỉ lại bất cứ lúc nào. Vẫn phải đi tiếp khoảng 4h như vậy nữa. Băng qua con vực, chúng tôi nghe thấy tiếng suối, cây cầu khỉ và cả đoàn chúng tôi ở trước mặt, thực sự mừng rớt nước mắt. Trong sự mệt nhọc, việc đi qua cái cầu khỉ bắc qua con suối là một thú vui và tiếp thêm động lực  cho cả đoàn.  Trên người có 2 chiếc balo, đi qua cầu chòng chành, đi qua rồi mà chỉ nghĩ lúc đấy cầu có làm sao rơi xuống suối thì cũng coi như xong câu chuyện ở đây. Nhìn những người bạn đồng hành, tiếng cười nói, cái mệt của mọi người cũng lắng xuống đôi chút. Chúng tôi lại tiếp tục quãng hành trình tới địa điểm nghỉ chân. Cuộc hành trình cứ lên rồi xuống những ngọn núi. Dường như thời gian lúc này không có ý nghĩa, chúng tôi chỉ có bước tiếp lên phía trước, mong sao cho đến điểm nghỉ đêm thứ nhất thật nhanh.  Đi giữa rừng trong đêm với thời tiết khắc nghiệt là điều không trekker nào mong muốn. Buổi tối làm chúng tôi đi chậm lại  rõ rệt.

Những con dốc càng trở nên dốc hơn, và càng trở nên khó đi vào đêm tối. Lên cao hơn chúng tôi nhìn thấy trăng, và rất nhiều sao đầy cả một bầu trời. Bầu trời núi rừng sáng kì lạ, tạo cho tôi cảm giác như lạc vào một câu truyện, nơi đó, tôi ngắm nhìn bầu trời, ánh trăng cạnh tôi toàn cây là cây, ánh trăng bạc, cái lạnh cắt da, đó là một cảm nhận không thể quên.

Vì là tốp tiếp tục đi cuối, tôi, 2 bạn đồng hành và bố già rừng lại ở một khoảng và nhóm  cỏ và củi khô để sưởi ấm,  quyết định lưu lại cái khoảnh khắc, cái không khí này. Nó cũng là kỉ niệm đáng nhờ của chuyến đi.

 Khi chúng tôi gần lên tới nơi, tôi phát hiện, chiếc  điện thoại yêu quý gắn bó với mình và có vô số thứ quan trọng bên trong đã không còn nằm yên trong vị trí. Vậy là một mình xuống núi bắt đầu thực hiện. Cái cảm giác lạc trong rừng giữa đêm và cái không khí lạnh lạnh của rừng thiêng làm tôi sản gai ốc. Đi mãi khoảng 10 phút tôi không còn nghe được tiếng gì ngoài tiếng gió của rừng, cũng không ngờ khoảng cách lại xa như vậy, cảm giác mách bảo là ở nơi đốt củi đó chứ không phải nơi nghỉ chân nào khác, cứ đi mãi miết, bỗng nhận ra mọi thứ thật yên ắng chỉ có tiếng bước chân và tiếng thở dốc của chính mình. Vì một phần lo đoàn sẽ lo cho mình, một phần lớn vì không yên tâm với sức khoẻ của người bạn cùng đoàn. Tôi quyết định quay trở lại, nhưng quay lưng lại thì chỉ thấy bóng tối, cũng may là lúc lên tôi có nhìn thấy chùm sao đại hùng. Cứ đi theo hướng đó thì sẽ lên được vị trí nghỉ lúc trước và quyết định bước theo.  Vừa đi vừa nghĩ nếu có đi nhầm sang ngọn núi bên cạnh xuống rồi quay lại chắc cũng chết. Còn điện thoại đành để đó để sáng sớm hôm sau quay lại tìm.


Đêm đầu tiên ngủ lại tại bãi bằng chăn dê là đêm khó quên, nó không lạnh buốt hơi lạnh từ đất như đêm ngủ trên Tây Tiến, nhưng nó lại có  sương muối của rừng, sương thấm qua cả lều ngủ. Đến 4h sáng tôi không tài nào ngủ tiếp được dưới cái lạnh này dù đã dán miếng nhiệt, quyết định dậy. Bầu trời đêm gần đỉnh muối nhiều sao vô cùng. Do ở lưng chừng núi nên tầm view rất rộng. Tôi có thể tận mắt nhìn thấy những chòm sao mà chỉ có nhìn qua film ảnh, rất nhiều, rất nhiều chòm sao hiện ra. Giá như máy ảnh ghi được cái cảm giác ấy thì thật tuyệt vời. Đây cũng  là nơi đầu tiên được ngắm sao băng ở tầm view rộng như vậy.

Lạnh, nhưng ngồi cạnh bếp lửa thì ấm vô cùng, làm một chén rượu mà cái cảm giác rét co ro trong lều tan biến đi đâu rồi, ngồi bếp lửa và đón bình mình sáng sớm. Bình minh thứ 2 của năm 2015.

Từ chỗ ngủ tới đỉnh muối, chúng tôi đi thêm 3 h đồng hồ leo núi nữa. Cũng có nhiều những đoạn dốc phải leo bằng tay nhưng so với những vất vả mà tối hôm trước chúng tôi trải qua thì không thấm vào đâu. Tuy nhiên khi leo tới đây, chúng tôi đã có thể nhìn thấy những dải mây ngang tầm mắt với mình. Những công sức của chúng tôi bắt đầu được núi rừng đền đáp.

10h chúng tôi lên tới đỉnh muối, cắm trại và chuẩn bị bữa trưa đầu tiên trên đỉnh muối. Đi quanh quanh tôi hiểu tại sao ở đây người ta gọi là Bạch Mộc. Những thân gỗ theo tháng năm trắng theo sương muối nơi đây. Đến những cây gỗ cũng có vẻ đẹp của thiên nhiên.

Khi lên được một lát, mây bắt đầu tràn xuống nơi cắm trại, những lớp sương mù, nếu trèo lên đỉnh Bạch Mộc lúc đó bạn sẽ thấy một biển mây trắng phía dưới

Bữa ăn trưa thịnh soạn, và là một bữa trưa ngon nhất trong những chuyến đi trek của mình. Ngoài ra còn món nấm xào tuyệt vời, một những món ăn ấn tượng của chuyến đi, những lần sau lên Sapa nhất định phải mua nấm rừng về thưởng thức. 

Sau bữa trưa đã bụng, buổi chiều chúng tôi có quyết định là lên trên đỉnh muối xem hoàng hôn. Đúng là núi rừng không phụ công người. Tuy không có biển mây nhưng cảnh hùng vĩ và  cảnh mặt trời ẩn mình xuống những ngọn núi cũng làm cho người cảm giác thích thú đến khó tả. Vào thời điểm này chúng tôi có thể nhìn thấy cả mặt trăng và mặt trời 

Quá trình chuẩn bị bữa tối. Bữa tối nay sẽ có món thịt lợn nướng. Quá đủ cho một chuyến đi, và đây là lý do tại sao tôi nói chuyến đi trek sang chảnh. Mặc dù mệt nhưng tôi vẫn muốn thưởng thức bữa tối thú vị này 

Trại chúng tôi dựng quanh bếp củi để tối đốt củi sưởi ấm.

Đêm thứ 2 trên đỉnh muối không rét như đêm thứ nhất ở lưng chừng núi. Một phần vì nhiệt độ đã tăng lên, một phần sau một đêm nghỉ ngơi sức khoẻ chúng tôi đã phục hồi 1 phần, một phần vì bếp củi được đốt suốt đêm

Sáng sớm hôm sau cũng như sáng thứ nhất, đến tầm 4h cái lạnh xuống sâu, ra ngồi bếp củi thì ấm hơn trong lều. Đến 5h sáng chúng tôi hành trình lên đỉnh muối. Đỉnh để ngắm biển mây cách không xa so với nơi cắm trại nghỉ. Khi đi lên thì trời vẫn còn tối. Chúng tôi quyết tâm phục kích ánh sáng đầu tiên trên đỉnh Muối. Và hơn cả kì vọng, cả chuyến đi tôi chỉ chờ mong giây phút này, giây phút làm cho tôi không nghĩ mình chính mắt mình sẽ nhìn thấy cảnh tượng này. Tôi rất gần mây, tôi có thể nhìn thấy núi, tôi cảm giác như chính tay mình được chạm vào mây, cảm giác muốn nhảy bay khỏi đỉnh muối và lao mình xuống biển mây kia. Đó là cảm giác thật tuyệt với và sẽ chẳng bao giờ quên được. Không ai có thể cầm lòng được với cảnh đẹp nơi đây, có thể gọi là chốn bồng lai cũng vẫn đúng.

Và tất nhiên chúng tôi còn trẻ, chúng tôi muốn ghi lại những khoản khắc tuyệt vời ở nơi đây để nhớ mãi.

Read More →

1/22/2015 11:25:00 PM

home, travel