Vừa mới khởi động chương trình Balance 1.0 tại cơ quan của mình. Kể từ ngày biết Scrum, agile đến giờ, mình đã thuyết trình và nói chuyện nhiều về các giá trị trong công việc, nhưng đây là lần đầu tiên mình thực sự có hành động và bài bản để tiến tới cái mà ai cũng mong muốn: work-life balance. Trong lòng thấy rất phấn khởi 
Trong bài trước (http://www.hanoiscrum.net/hnscrum/learning/102) tôi đã giới thiệu “User Story là gì”. Hiểu được và thao tác được với user story thì mới mong lập kế hoạch hiệu quả được .
Lập kế hoạch tức là phải phác thảo ra được lượng nỗ lực và nguồn lực cần thiết bỏ ra trong khoảng thời gian nhất định để đạt được mục đích. Để làm được việc lập kế hoạch thì chắc chắn phải ước lượng. Nhưng ước lượng là một bài toán khó, vì đòi hỏi đoán trước tương lai. Bản chất từ “ước lượng” đã hàm ý việc không thể đòi hỏi tính chính xác 100% trong các giá trị được đưa ra. Tuy vậy, về tính “hữu ích” và thực tế, chúng ta luôn phải tìm kiếm một phương pháp ước lượng đáng tin cậy.
Trong bài “Tại sao point lại tốt hơn giờ?” (http://www.hanoiscrum.net/hnscrum/resource/109), Jeff Sutherland đã chỉ ra ưu điểm của user story point. Bài này muốn đóng góp thêm vài ý.
1. User Story point là gì?
Đó là đại lượng chỉ độ lớn tương đối của các user story trong cùng một dự án. Trong một phiên hoạch định trước Sprint, nhóm phát triển dùng Scrum Poker để đánh giá độ lớn bé các story này, và ghi các giá trị đó lên mỗi user story card.
Ví dụ ta phải làm một hệ thống có ba user story như sau:
u1. là khách hàng, tôi muốn đăng nhập vào hệ thống để xem trạng thái cua đơn hàng đã đặt.
u2. là khách hàng, tôi muốn lựa chọn các sản phẩm mong muốn vào giỏ hàng để đặt mua
u3. là khách hàng, tôi muốn hủy một đơn hàng khi đã đặt
u1 được gán là 3 điểm (point), u2 là 8, u3 là 4 tức là độ lớn của toàn bộ dự án là 15 điểm. Nỗ lực cần bỏ ra để thực hiện u3 tương đương u1, u2 gấp đôi u1. Ở đây dấu “=” có nghĩa là “khoảng ấy”, cỡ ấy chứ không hàm ý là “bằng”.
2. Độ lớn của các story có thể thay đổi theo thời gian
Do nhóm đã trưởng thành qua thời gian, hiểu biếu về hệ thống thay đổi, và có thể PO thay đổi yêu cầu v.v., nên phải tái ước lượng. Vì thế u3 có thể được đánh giá lại sau sprint 1 là 6 thay vì 4 như cũ vì có vẻ việc hủy một đơn hàng không đơn giản là nhấn nút “Hủy” mà còn phải tính tới các chính sách khác chưa được tính tới tại thời điểm ước lượng lần một. Vì thế sau phiên “làm mịn” các story, thì độ lớn của từng story thay đổi.
Nhưng ..
3. Story point là đơn vị cố định. Nó là atomic.
Không có chuyện một point ở Sprint 2 thì bằng một nửa point ở Sprint 1. Chỉ có việc u3 ở Sprint 2 có thể được ước lượng lại ở Sprint 2 là tăng lên 6 points.
Tất cả các point đều phải quy chiếu về cái gì đó làm mẫu. Ví dụ, lúc đầu, tất cả các story u2, u3, .. đều được mang ra so sánh với u1. Thì đến Sprint 3,story Un cũng phải đem ra so sánh với u1. Nếu không tham chiếu đến “tiêu chuẩn”, thì khái niệm “point” không có giá trị gì trong hoạch định dài hạn cả.
Agile Estimation (Ước lượng Linh hoạt):
1. Lấy ra một cặp story (ví dụ: u1 và u3) tương đối dễ hiểu đối với cả nhóm (hiểu cả nghiệp vụ lẫn các công việc để thực hiện hai story này); story thứ hai có độ lớn gấp đôi story kia.
2. Gán u1 số điểm là 3, u3 là 8. Hai story này để tham chiếu cho toàn bộ quá trình ước lượng các story còn lại.
3. Chơi Scrum Poker để đánh giá độ lớn các story còn lại.
Việc so sánh độ lớn của một story u3 ở Sprint 1 với Sprint 2 là không có ý nghĩa gì cả. Cái này nó biến động liên tục. Vì nó không có nghĩa nên không nên đem ra so sánh để làm gì.
4. Velocity (tốc độ) là gì?
Là số point burn được trong một Sprint.
Velocity có thể thay đổi theo thời gian. Thường là tăng.
Với giả định là các ước lượng user story point ban đầu là đáng tin thì có vẻ như velocity sẽ tăng dần do nhóm ngày càng làm việc tốt hơn, hiểu sản phẩm hơn, nắm vững công nghệ đặc thù của bài toán đó hơn v.v.
Khái niệm gia tốc có thể được tính đến khi nhóm scrum ở mức trưởng thành cao. Khi đó tốc độ tăng tiến đều và đoán được thông qua một đại lượng cố định. V2=aV1. Tuy vậy, giá trị này không phải lúc nào cũng có nghĩa.
5. Velocity có giá trị đối với việc hoạch định sản phẩm và phát hành
Giả sử nhóm là cố định. Hiệu suất của nhóm được đo bằng velocity. Giá trị này hoàn toàn tiên lượng được trong ngắn hạn.
Giả sử Sprint 1 burn được 30 point, Sprint 2 được 35 point, thì có vẻ như Sprint 3 nhóm sẽ burn được ít nhất là 35 point. Điều này là tin được, vì theo (4), nhóm sẽ làm việc ở Sprint 3 không kém hơn so với Sprint trước.
Chuyện tiên lượng này không hề bị ảnh hưởng của sự ước lượng lại tại đầu Sprint (khi đó u3 có thể đã có độ lớn bằng gấp đôi so với ước lượng lần trước). Vì sau khi làm mịn, độ lớn lại được quy ra point, và point này là lại quy về point so với thời điểm ban đầu (so với u1).
Do vậỵ Product Owner hoàn toàn có thể đoán được thời điểm một feature nào đó sẽ có (để quảng cáo, bán hàng, v.v.) cũng như phác ra một kế hoạch release khả thi.
6. Velocity không phải là công cụ đo performance của các nhân
Mặc dù ta có thể làm như vậy, và thực tế nhiều người làm như thế. Trong một nhóm có thể có quy ước “ghi công” cho ai đó khi hoàn thành một feature. Khi đó cuối Sprint ta biết được ai burn được bao nhiêu để lập “bảng thành tích” rồi “tính lương” 
.
Một số dự án đặc thù có thể cho phép cách làm như vậy. Nhưng đại thể, agile không khuyến khích cách làm như vậy. Agile vốn khuyến khích tương tác, cộng tác, sở hữu tập thể thì không có lí gì lại đi đo thành tích cá nhân dựa trên số point burn được của từng cá nhân. Cái này là scrumbut.
7. Quy đổi ra giờ
Cuối cùng thì ai cũng hỏi vậy tương đương Point-Giờ thế nào? Vì cái làm việc theo giờ thì dễ hình dung hơn về độ lớn của dự án. Chứ point “ảo” quá! Quy ra person-month hộ tôi cái!!! 
Chỉ có mối tương quan point-giờ trong phạm vi dự án mà thôi do point là chỉ là đơn vị có giá trị trong nội bộ một dự án. Point trong dự án này không bằng point trong dự án khác (do quy chiếu khác nhau).
Cách quy đổi khá dễ: nếu nhóm năm người burn được 30 point trong 1 sprint 1 tháng, thì rõ ràng là một point bằng năm person-month rồi. Tuy nhiên bản thân độ đo user story point đã đủ tốt rồi, nếu không phải trường hợp vạn bất đắc dĩ, không việc gì phải dùng thêm một độ đo khác vốn cực kì bất ổn là person-month (cái này thì sách nói nhiều rồi).
8. Dùng point cho story, nhưng dùng “giờ” cho task
Khi PO quyết định nhóm phải burn 30 point trong Sprint tới với các story được chọn lựa thì việc của nhóm là phải break down các Story kia thành ra các task với ước lượng ra “giờ” để điền vào Sprint Backlog. Trong trường hợp này, nhóm lại quên khái niệm point đi (thực ra khái niệm này có nghĩa với PO hơn là với dev), để tập trung việc burn được bao nhiêu productive hours.
Sự nhầm lẫn hay xảy ra khi nhóm vẫn dùng Scrum Poker để ước lượng các task nhưng lại nghĩ là mình ước lượng các story. Để tránh nhầm lẫn nầy, không nên để hai phiên làm việc release planning (đánh giá story) liền với Sprint Planning (chẻ nhỏ story).
Sách Lean Startup có dạy rằng “fail fast” tức là hãy bắt tay vào việc và sẵn sàng đón nhận thất bại càng sớm càng tốt. Không phải đợi tới một năm thử nghiệm với bao nhiêu đầu tư, nguồn lực và hy vọng để rồi nhận ra mình sai lầm. Trong thế giới biến động không ngừng, sự tiên lượng dường như
rất xa xỉ bởi sự phức tạp vượt quá tầm hiểu biết và kiểm soát của con người. Vì vậy cách thông minh hơn là đừng có tiên đoán cái gì xa quá, mà hãy tự tin mà “chập chững” bước đi; ta có thể ngã nhưng đứng dậy ngay được. Và hãy mong đợi những cú ngã như vậy.
Anh bạn quý mến phương Nam của tôi đã có hơn một năm rưỡi chuyển đổi thành công sang Agile cũng có chia sẻ kinh nghiệm “xương máu” như vậy:
1. Trong suy nghĩ, luôn cho phép mọi người mắc sai lầm, và cả chính mình nữa
2. Trong hành động, phải bắt tay vào ngay, không đợi đến khi bạn có đủ thông tin mới làm việc.
Sự khác biệt trong tiếp cận của Agile nói chung chính là ở chỗ này: thực tiễn sẽ dạy ta thông tin ta cần biết, cái ta cần phải làm. Và để biết được điều đó thì chỉ có một cách duy nhất là bắt tay vào thực tiễn và chấp nhận sai lầm. Và thông minh hơn nếu như ta có cách giảm thiểu rủi ro và thiệt hại (nếu có) của sai lầm ấy. Cách đó chính là việc “do small” – làm cái nhỏ thôi, và nhích lên từng bước một. Thất bại là mẹ của thành công. Sao lại phải sợ thất bại nhỉ !?
Việc làm chủ một công nghệ không thể nào diễn ra trong một sớm một chiều. Nghịch lý là trong thời đại ngày nay, doanh nghiệp lại thường không có đủ thời gian để tham gia các chương trình đào tạo đầy đủ trong thời gian dài.
Người Nhật đã có một giải pháp hiệu quả để giải quyết cái nghịch lý đó. Phương án này có tên Shu-Ha-Ri.
Shu tức là giai đoạn ta tiếp thu theo hướng tuân thủ và sao chép để nắm bắt được nguyên gốc kĩ thuật. Khi học kĩ năng, về cơ bản Shu tức là bắt chước. So với khung hình thành kĩ năng của Dreyfus, thì Shu giúp chúng ta bước qua Novice đến với Advanced Beginner.
Ha là giai đoạn khi ta thuộc bài đôi chút, có thể sửa đi cho phù hợp với bối cảnh. Ta có thể gọi là “tùy chỉnh cho tối ưu”. Nhưng về cơ bản ta vẫn giữ những khung kĩ thuật cũ. Đối chiếu với Dreyfus, Ha giúp ta bước qua từ Begineer đến với Competent (được việc).
Ri là khi chúng ta đã thuần thục, mọi thứ trở thành “da thịt”, hành động nhạy bén, tự nhiên. Là lúc ta có quyền quên đi các hướng dẫn ban đầu để hành động như thế “tự nhiên”, “trực giác”. Đối chiếu với khung của Dreyfus, đây là lúc chúng ta đạt được “Proficient” và “Expert”. Lúc chúng ta thực sự tinh thông.
Từ Shu qua Ha đến Ri, đối với một kĩ năng nhỏ cần vài chục giờ đồng hồ luyện tập chú tâm; đối với những bộ kĩ năng nghề nghiệp, chúng ta có thể phải mất hàng năm trời.
Trong đào tạo tại doanh nghiệp. Khâu đào tạo cơ bản trong thời gian đầu sẽ khởi động quá trình lĩnh hội kiến thức; huấn luyện tiếp theo (coaching) trong công việc sẽ giúp lý thuyết được ‘nhúng’ vào thực tiễn, tạo ra đời sống của mình; tư vấn (mentoring, consulting) thời gian sau đó sẽ nâng cao hiệu quả áp dụng công nghệ, làm chủ thực sự công nghệ đó.
Có lẽ cần phải sớm Việt hóa bài giảng này để mọi người bắt đầu nhanh hơn với Scrum:
Start Scrum Now
Scrum và agile vận hành theo thực nghiệm (empirical), lấy thực tiễn công việc làm trọng. Ken Schwaber nói “hãy nhìn cuộc sống như là nó đang là” để làm việc, và Scrum đơn giản là vậy.
Để có được sự thành công trong thực tiễn, Nonaka (được Jeff Sutherland gọi là ông nội của Scrum, là một trong những nhà lí thuyết về quản trị hiện đại có ảnh hưởng nhất thế kỉ 20) chỉ ra cần có sự khôn ngoan được gọi là phronesis (một số người khác dùng tiếng Anh là practical wisdom, trong tiếng Việt được dịch ra là minh triết, tuy vậy, trong phạm vi bài này tôi chọn cách diễn dịch nôm na) – sự khôn ngoan thực tiễn. Đó chính là khả năng quyết định và hành động tốt nhất trong một tình huống cụ thể để đạt được lợi ích chung. Một nhóm Scrum, với người lãnh đạo đặc biệt là Scrum Master, phải có được sự khôn ngoan này thì mới có khả năng vận hành tốt cơ chế tự tổ chức (self-organizing) và tự quản (self-managing).
Để phát triển phronesis, cần phải biết cấu thành của nó, chúng gồm:
Scrum Master phải phát triển phronesis của chính mình cũng như cả nhóm và tổ chức. Scrum Master phải là một wise leader. Đó là thông điệp của buổi nói chuyện vừa rồi tại Hanoi Scrum:
Scrum Master: from thinking to actions
Thời gian qua có nhiều người hỏi tôi về việc học Scrum và thi các chứng chỉ liên quan đến nó. Dưới đây là tổng hợp các bước mà một người học Scrum có thể tham khảo để nhanh chóng đạt được khả năng ứng dụng Scrum vào công việc của mình. Tôi tạm gọi nó là “Lộ trình Scrum”. “Scrum works for idiots” (Schwaber), bạn có thể bắt đầu ngay lộ trình này.
Road a head
1. Tìm hiểu Scrum là gì
Bạn có thể bắt đầu rất nhanh với các cắt nghĩa ngắn gọn trên một trang giấy với bài viết “What is Scrum?“, hoặc bài viết “Scrum là gì?“, để có được cảm giác về Scrum và rất nhiều câu hỏi.
2. Đọc kĩ và hiểu cặn kẽ các tài liệu nhập môn
Việc đọc và hiểu Scrum sẽ giúp ta nắm được các vấn đề cốt lõi và sớm tránh được các lỗi thường gặp không đáng có. Tuy nhiên, làm Scrum bạn không cần đọc quá nhiều. Hiện nay có hai tài liệu nhập môn quan trọng được dùng cho hầu hết các khóa đào tạo cơ bản về Scrum. Đó là “Scrum Guide” do chính tác giả Scrum cập nhật liên tục – đây là tài liệu chính quy về các thuật ngữ trong Scrum; và Scrum Primer với các hướng dẫn thực hành chi tiết hơn. Cả hai tài liệu này đã được Việt hóa. Bạn có thể tải về và đọc theo các liên kết dưới đây:
Một cuốn sách khác với rất nhiều chi tiết về hướng dẫn thực hành cũng đã được HanoiScrum biên dịch, cuốn “Scrum và XP từ những chiến hào”, bạn có thể đọc nhanh để tìm kiếm các phương pháp thực hành tốt khi áp dụng Scrum.
Trong quá trình tự đọc, bạn có thể cần dùng Google rất nhiều để tìm hiểu thêm về các câu hỏi chưa được trả lời. Bên cạnh đó, bạn có thể tham khảo nhiều bài viết hướng dẫn, kinh nghiệm quý trên các trang “chính thống” về Scrum như www.scrumalliange.org hay www.agilealliance.org. Hanoi Scrum (www.hanoiscrum.net) đang có nhiều nỗ lực Việt hóa các tài liệu học tập agile và Scrum, sẽ là nguồn dữ liệu quan trọng cho người học.
Nếu đọc xong các cuốn sách này, khí thế hừng hực và muốn bắt tay ngay vào thực hành thì .. cứ làm luôn! Scrum cho phép bạn học hỏi và tiến bộ qua thực tiễn công việc (empirical) hơn là qua sách vở. Vì thế học Scrum qua công việc là cách làm … rất scrum :). Đừng chờ đợi đến lúc hiểu hết về Scrum mới bắt tay vào làm, điều đó là không thực sự cần thiết.
3. Tham gia một khóa học chính quy về Scrum, thi và trở thành thành viên của cộng đồng
Kiểm tra các khóa học trên Hiệp hội chính thức của cộng đồng sử dụng Scrum: http://www.scrumalliance.org/pages/scrum_certification hoặc http://courses.scrum.org/. Các khóa học này thường là đắt đỏ (trên USD700), và vì vậy bạn nên đặt mục tiêu rõ ràng trước khi quyết định trả tiền.
Ở Việt Nam, bạn có thể tìm học tại Tp. Hồ Chí Minh và Hà Nội.
Bên cạnh các khóa học chính quy trên, hiện nay nhóm Hanoi Scrum có tổ chức khóa học ngắn “Scrum Foundation” cho người mới bắt đầu. Bạn có thể đăng kí để học, miễn phí và chất lượng không quá tồi 😉
Ngay cả khi bạn đã thực hành Scrum một thời gian, việc tham gia các khóa học này vẫn mang lại nhiều giá trị. Bạn có cơ hội chuẩn hóa lại các hiểu biết của mình, đối chiếu và so sánh với những đồng nghiệp ở nơi khác, và học từ họ những kinh nghiệm quý báu. Qua các khóa học này, bạn cũng có thể thiết lập các mối quan hệ bằng hữu lâu dài và có giá trị.
4. Thực hành Scrum và chia sẻ với Scrum Buddies trong phạm vi địa phương hoặc toàn cầu
Nhiều người cho rằng, học thông qua cộng đồng là cách học tốt nhất, thực tế nhất; đặc biệt là cho người đang đi làm.
Nếu bạn đã học ít nhất một khóa học chính thức của ScrumAlliance.org thì bạn sẽ là thành viên của Hiệp hội này của cộng đồng, có tài khoản trên trang web và sẵn sàng chia sẻ kinh nghiệm với đồng nghiệp toàn cầu.
Tại Việt Nam, có hai nhóm tích cực với nhiều hoạt động (hằng tháng, thường niên) ở Tp. HCM (www.agilevietnam.org), và Hà Nội (www.hanoiscrum.net). Thông qua các nhóm thảo luận trên Facebook (/hanoiscrum; /agilevietnam), LinkedIn, và các sự kiện offline hằng tháng, bạn có cơ hội gặp gỡ, chia sẻ và trao đổi cùng nhiều người trong ngành phần mềm (CEO, PM, Developer, Tester, Scrum Master, Sinh Viên v.v.). Tại HCM bạn sẽ có cơ hội diện kiến Ken Schwaber qua Skype. Ông đã thực hiện một số buổi nói chuyện đầu tiên trong các sự kiện hằng tháng của Agile forum Vietnam, và sẽ tiếp tục có các hoạt động cộng tác tiếp theo. AgileVietnam và HanoiScrum sẽ tiếp tục tổ chức Agile Tour và các sự kiện “lớn” khác để cộng đồng có thể học hỏi và chia sẻ với nhau.
Bạn nên tới các sự kiện hằng tháng của các nhóm này để học tập, chia sẻ và xây dựng cộng đồng. Thông qua đó phát triển năng lực Scrum và agile của mình. Nếu bạn ở Đà Nẵng, Cần Thơ v.v. – những nơi chưa có nhóm sinh hoạt thì có thể tự mình thành lập một nhóm như vậy. Nếu bạn băn khoăn về cách tổ chức, tôi có thể chia sẻ kinh nghiệm với bạn.
5. Chọn cho mình một role ưa thích và sống cùng: Scrum Master, Product Owner, Scrum Developer, Scrum Professional hoặc Scrum Trainer.
Mỗi công việc đều đòi hỏi thời gian để thành thục, vì thế bạn cần đầu tư cho công việc bạn chọn lựa. Có thể sẽ mất thời gian vài năm để thuần thục role đó.
Với mỗi người, Scrum là một thứ gì đó riêng biệt: framework, công cụ hay là một lối làm việc – lối sống. Bạn hãy tự tìm hiểu và cảm nhận nhé.
Hôm rồi tôi có viếng thăm một trung tâm dịch vụ sửa chữa ô tô, và rất ấn tượng với sự gọn gàng ngăn nắp của họ. Việc thực hành 5S của họ đã có kết quả rất tốt. Tôi đã kịp chụp lại một số hình ảnh để giữ làm tư liệu một bài học về Lean. Bạn có thể nhấn vào ảnh dưới đây để mở cả album:
 |
| Lean@QualityServiceCenter |
