Cẩm Nang Scrum là một cuốn sách giúp bạn làm chủ “Phương pháp năng suất và sáng tạo gấp đôi” được các tác giả Dương Trọng Tấn, Nguyễn Việt Khoa, Phạm Anh Đới, Nguyễn Khắc Nhật (Học viện Agile) biên soạn. Hồng đã có cơ hội đọc và nghiên cứu vì vậy trong bài viết này Hồng sẽ giới thiệu đến các bạn đọc đồng thời nêu lên cảm nhận sau khi đọc quyển sách này. Hi vọng bài viết này có thể mang đến cái nhìn tổng quát cho những ai đang quan tâm đến mô hình Agile – Scrum để vận dụng trong công việc một cách hiệu quả.
Cuốn sách này cũng sẽ phù hợp với những người làm chủ doanh nghiệp, quản lý đặc biệt hữu ích với những công ty công nghệ.
Mục lục của Cẩm Nang Scrum gồm 9 phần:
- Khung tư duy cho thế giới sáng tạo và biến động
- Nhóm hiệu quả cao
- Cách thức mới để tổ chức mọi việc
- Các sự kiện Scrum
- Các tạo tác và công cụ
- Scrum trong tổ chức
- Scrum phân tán
- Scrum với quy mô lớn
- Các chủ đề nâng cao
Một số nội dung ấn tượng và nổi bật trong Cẩm Nang Scrum Hồng sẽ tóm tắt bên dưới:
Sau một thập kỷ rưỡi ra đời, Agile đã cải thiện được kết quả làm việc đáng kể và tạo nên thành công của rất nhiều dự án.
Trong báo cáo của CHAOS, cho thấy tỷ lệ thành công của các dự án sử dụng phương pháp Agile đều thành công cao hơn Waterfall chiếm tỷ lệ 39% và 11%. Trong đó, các dự án Lớn Agile chiếm 18% cao gấp 6 lần so với Waterfall chỉ 3%. Đối với các dự án vừa, Agile có tỷ lệ thành công cao gấp 4 lần 27% so với 7% so với Waterfall. Đối với dự án nhỏ, tỷ lệ thành công của Agile là 58% còn Waterfall là 44%. Ngược lại, tỷ lệ thất bại của Agile cũng thấp hơn Waterfall nhiều lần. Điều này cho thấy tiềm năng của phương pháp Agile trong việc tăng năng suất, quyết định thành công cho các dự án là rất cao.
Tuyên ngôn phát triển phần mềm linh hoạt
12 nguyên lý phía sau tuyên ngôn Agile
- Ưu tiên cao nhất là thỏa mãn khách hàng thông qua chuyển giao sớm và liên tục các phần mềm có giá trị.
- Chào đón việc thay đổi yêu cầu, thậm chí rất muộn trong quá trình phát triển.
- Thường xuyên chuyển giao phần mềm chạy tốt đến cho khách hàng (Vài tuần đến vài tháng), ưu tiên khoảng thời gian ngắn nhất.
- Nhà kinh doanh và Nhà phát triển phải làm việc cùng nhau hằng ngày trong suốt dự án.
- Xây dựng dự án xung quanh những cá nhân có động lực. Cung cấp môi trường và sự hỗ trợ cần thiết. Tin tưởng để hoàn thành công việc
- Hội thoại trực tiếp là phương pháp truyền thông tin hiệu quả nhất.
- Phần mềm chạy tốt là thước đo chính của tiến độ.
- Các quy trình linh hoạt thúc đẩy phát triển bền vững.
- Liên tục quan tâm đến các kỹ thuật và thiết kế tốt để gia tăng linh hoạt.
- Sự đơn giản – nghệ thuật tối đa hóa lượng công việc chưa xong – là căn bản
- Các kiến trúc tốt nhất, yêu cầu tốt nhất sẽ được làm ra bởi các nhóm tự tổ chức.
- Nhóm phát triển sẽ thường xuyên suy nghĩ làm sao để hiệu quả hơn, sau đó điều chỉnh và thay đổi hành vi của mình cho phù hợp.
Agile là gì? Phát triển Linh hoạt (Agile Development, gọi tắt là Agile) là một thuật ngữ có nguồn gốc từ Truyền Ngôn Phát triển Phần mềm Linh Hoạt (The Manifesto for Agile Software Development).
Các phương pháp Agile được thực tế chứng minh là công cụ mạnh của các cá nhân, tổ chức trong việc đổi mới, sáng tạo, làm nên những sản phẩm chất lượng cao, đột phá, cũng như gia tăng hiệu quả hoạt động và năng lực cạnh tranh và phát triển văn hóa của tổ chức. Cùng với Tư duy Tinh gọn (Lean Thinking), Khởi nghiệp Tinh gọn (Lean Startup) và Tư duy Thiết kế (Design Thinking), Agile vẫn đang tiếp tục tạo nên những làn sóng thay đổi lớn trên thế giới.
Scrum là gì?
Scrum “là một khung làm việc để phát triển bền vững các sản phẩm phức tạp”. Scrum có phải Agile không? Scrum là một phương pháp Agile phổ biến nhất, nhưng không phải là Agile. Agile định nghĩa những giá trị cốt lõi và định hướng, Scrum là một phương pháp cụ thể chia sẻ những nguyên tắc đó.
Tại sao chọn Agile? Nền kinh tế sáng tạo, biến động yêu cầu cá nhân tổ chức đạt được năng lực linh hoạt (Agility) cao độ để thích ứng dẫn đầu cuộc cạnh tranh. Agile là nền tảng để đạt được năng lực linh hoạt và đạt được lợi thế cạnh tranh bền vững. Agile sẽ giúp doanh nghiệp phát triển hiệu quả hơn, năng suất hơn, đổi mới sáng tạo hơn.
Chúng ta phải bắt đầu từ đâu để áp dụng Agile cho doanh nghiệp?
- CÁ NHÂN: Áp dụng kỹ thuật cơ bản của Personal Kanban + Tư duy Agile => nâng cao năng suất, làm việc hiệu quả, kiểm soát tốt Stress.
- DEV: Kỹ thuật lập trình Agile cơ bản như TDD, Pair-programming => Nâng cao chất lượng phần mềm => Nghệ nhân phần mềm (Software Craftsman)
- NHÓM: Tổ chức lại công việc, nâng cao hiệu quả giao tiếp và hiệu suất nhóm.
- CÔNG TY: Tổ chức công việc, quy trình nghiệp vụ (Scrum), Lean giảm chi phí, nâng cao hiệu quả, tối ưu nguồn lực, nâng cao năng lực cạnh tranh bền vững.
Agile Mindset
1. Mục tiêu của công việc là làm khách hàng sung sướng (Delight customers). Mọi hành động đều hướng tới, bắt đầu, xoay quanh khách hàng
2. Phải giảm nhỏ phạm vi công việc (Descaling works), trao nhiều quyền hơn, tăng tính tự trị cho các nhóm nhỏ và cá nhân. Mục tiêu chính là tăng khả năng sáng tạo, thúc đẩy động lực làm việc.
3. Dùng dữ liệu thực tiễn (Evidence-based – Dựa trên bằng chứng) từ các chu trình phản hồi ngắn (Short-feedback cycle) để ra quyết định và liên tục cải tiến.
4. Tạo dựng văn hóa nuôi dưỡng và phát triển. Mọi cá nhân đều có cơ hội học hỏi qua thực hành, những thử thách, những lần thất bại từ đó trưởng thành hơn.
5. Luôn duy trì khả năng thích nghi cao, chào đón mọi thay đổi, chủ động tạo dựng và dẫn dắt sự thay đổi để đạt được kết quả cuối cùng.
3 trụ cột của Scrum
MINH BẠCH (Transparency) là thông tin minh bạch thông suốt. Các thông tin: Tầm nhìn, Yêu cầu, Tiến độ, Khúc mắc về rào cản,… Các vai trò khác nhau có đủ thông tin cần thiết tiến hành các quyết định có giá trị. Các công cụ và cuộc họp đảm bảo thông tin được minh bạch cho các bên.
THANH TRA (Inspection) là thanh tra liên tục. Phát hiện các vấn đề và giải pháp để thông tin đa dạng hữu ích đến các bên. Truy xét kỹ càng và liên tục là cơ chế khởi đầu cho việc thích nghi và cải tiến.
THÍCH NGHI (Adaptation) là dựa trên các thông tin minh bạch hóa từ quá trình thanh tra và làm việc, Scrum phản hồi các thay đổi một cách tích cực. Các nỗ lực minh bạch và thanh tra đều hướng tới hành động thích ứng nhanh chóng và hiệu quả.
5 giá trị của Scrum
DŨNG CẢM: Để dám nói ra vấn đề và chấp nhận nhiều rủi ro khi thay đổi, cam kết cần là người dũng cảm. Những giá trị khác không thể có nếu KHÔNG PHẢI LÀ NGƯỜI DŨNG CẢM.
TẬP TRUNG: Tập trung vào công việc trong Sprint và mục tiêu của Sprint. ĐÃ CAM KẾT THÌ CẦN HOÀN THÀNH
CAM KẾT: Mỗi thành viên cam kết những điều mình làm + công việc tại buổi Planning. Liên tục cả tiến để trở thành cá nhân, nhóm, tổ chức TỐT HƠN. Thay đổi bao giờ cũng khó khăn, chỉ có sự CAM KẾT MỚI CÓ THỂ LÀM ĐƯỢC.
CỞI MỞ: Việc phát triển sản phẩm rất phức tạp. Một cá nhân không thể có cái nhìn là hiểu được tất cả mọi vấn đề, cần rõ ràng minh bạch => Mọi người cần CỞI MỞ, KHÔNG CHE GIẤU THÔNG TIN.
TÔN TRỌNG: Khi thiếu tôn trọng mọi người KHÓ THÀNH THẬT trong chia sẻ. Không có tôn trọng KHÓ CÓ SỰ CỞI MỞ.
VD: Một người không biết một điều gì đó và đi hỏi người khác, người trả lời thay vì mong muốn giúp đỡ để người hỏi trở nên tốt hơn độc lập hơn mà lại phàn nàn đánh giá thì lần sau người hỏi sẽ khó cởi mở và nói sự thật được. Ngược lại nếu không biết mà lại không hỏi thì dẫn đến hậu quả khôn lường.
Sprint – Trái tim của Scrum: Cách phát triển truyền thống, các công việc được làm tuần tự, nên có rất nhiều rủi ro, lãng phí được phát hiện muộn.
Tất cả những công việc phải làm để hoàn thành một hoặc một nhóm tính năng & chức năng được đưa vào một Sprint. Một Sprint không phải là một chu trình mini-waterfall truyền thống, mọi công việc được làm đồng thời với nhau.
Định nghĩa hoàn thành trong Scrum:
Xây dựng Định nghĩa Hoàn thành cho từng cấp độ khác nhau: Các ví dụ về Định nghĩa Hoàn Thành được đề cập ở trên là áp dụng cho các User story để được công nhận là đạt trạng thái sẵn sàng chuyển giao. Tuy nhiên, trên thực tế thì Định nghĩa Hoàn Thành có thể được áp dụng cho những cấp độ khác nữa, chẳng hạn như đối với các User story để quy định trạng thái sẵn sàng để đưa vào phát triển, đối với các công việc trong Sprint và đối với các phiên bản phát hành.
Định nghĩa Hoàn thành dành cho User Story: Đối với các User story, chúng ta có thể xây dựng Định Nghĩa Hoàn Thành để quy định trạng thái của một User story được công nhận là sẵn sàng để đưa vào phát triển trong một Sprint. Loại Định Nghĩa Hoàn Thành này dành cho User story còn được gọi là Định nghĩa sẵn sàng.
- User story đã được ước tính
- Có danh sách các tiêu chí chấp nhận
- User story là duy nhất
- Có đính kèm tài liệu phù hợp (chẳng hạn như: bản mẫu, dữ liệu,…)
- Giá trị ước tính ban đầu không nhiều hơn 5 điểm
Theo Jean Tabaka’ có 11 Nguyên nhân thất bại của Scrum
1. Sử dụng không hiệu quả hoạt động cải tiến
2. Không có khả năng lôi kéo tất cả mọi người cùng
điều hành tham gia vào lập kế hoạch
3. Không chú ý tới cơ sở hạ tầng cần thiết
4. ScrumMaster tồi
5. Product Owner không giữ được sự nhất quán
6. Khôi phục lại khuôn mẫu trước đây
7. Chỉ quan tâm tới “cam kết sổ sách” từ phía quản lý
8. Nhóm thiếu thẩm quyền và khả năng ra quyết định
9. Không Có người chịu trách nhiệm truyền đạt khi
tiến hành làm việc phân tán
10. Văn hóa của tổ chức không hỗ trợ việc học tập
11. Từ chối chấp nhận một cách gay gắt
7 Đòn bẩy để thay đổi tư duy
- LÝ LUẬN (Reason): Dùng lý lẽ để thuyết phục bao gồm việc trình bày các thông tin về ý tưởng bao gồm cả mặt tốt và xấu.
- NGHIÊN CỨU (Research): Thu thập các bằng chứng khoa học, các con số thông tin liên quan đến ý tưởng => Thuyết phục thay đổi.
- CỘNG HƯỞNG (Resonance): Tạo mối liên kết với người được thuyết phục. Sự cộng hưởng đến từ mối quan hệ cá nhân, sự đáng tin cậy, cảm giác tôn trọng, thông qua giao tiếp, tương tác, ẩn dụ,… => Thay đổi trong nhận thức => CÔNG CỤ MẠNH NHẤT ĐỂ THAY ĐỔI TƯ DUY
- DIỄN ĐẠT THEO NHIỀU CÁCH (Representational Redescriptions): Đa dạng hóa cách diễn giải như văn bản, đồ họa, âm thanh, hình ảnh, biểu đồ, chuyện kể => Tiếp thu dễ dàng, thuận tiện, gần gũi.
- TÀI NGUYÊN – PHẦN THƯỞNG (Resource And Rewards): Thưởng những người tiếp nhận ý tưởng mới
- CÁC SỰ KIỆN THỰC TẾ (Real world events): Liên hệ các sự kiện thực tế với ý tưởng mới để thay đổi nhận thức các vấn đề đang tiếp cận.
- SỰ CHỐNG CỰ (Resistance): Nhìn ra những yếu tố cản trở và phản đối chính yếu đối với các ý tưởng tháo gỡ từng cái một. Nhiều sự cản trở đến từ những lối tư duy theo quán tính, trình độ hiểu biết hoặc quy tắc ràng buộc quá khắt khe => Cản trở khả năng tiếp thu ý tưởng mới.
- THAY ĐỔI TƯ DUY đóng vai trò lớn mang tính quyết định đến sự thành công của một nhóm, một tổ chức.
- CHỈ CHĂM LO PHƯƠNG PHÁP KỸ THUẬT mà KHÔNG TÍNH TỚI PHẦN TƯ DUY. Thay đổi trong cách nghĩ, hành vi và năng lực => Khó đạt được văn hóa Scrum ở mức cao độ.
Đo lường và đánh giá hiệu suất trong Scrum
Tùy tổ chức bộ công cụ đo đếm là khác nhau. Có thể bao gồm: Năng suất (Lượng công việc hoàn thành qua mỗi Sprint); Giá trị (Giá trị kinh tế cho mỗi nhóm); Chất lượng (Tỉ lệ lỗi hoặc lượng thời gian ngắt dịch vụ); Phát triển bền vững (Chỉ số hạnh phúc); Những thay đổi cách đánh giá hiệu suất nhân viên cần được tính đến.
Theo Agile People gợi ý một số hội thoại đánh giá nhân viên kiểu mới:
- Cuộc hội thoại cởi mở không đánh giá (Non-judgment)
- Để người khác cung cấp thêm thông tin, hiệu suất của nhân viên đó bên cạnh quản lý trực tiếp. – Không trực tiếp liên hệ, giữ hiệu suất với thưởng phạt trong quá trình hội thoại
- Hội thoại nhiều lần
- Tập trung cải thiện hiệu suất trong tương lai, không tập trung đánh giá hiệu suất trong quá khứ
- Nhân viên cùng lựa chọn cách hội thoại
- Nhân viên tự đánh giá không gọi là buổi đánh giá hiệu suất mà gọi là buổi hội thoại cải tiến. Cần đánh giá cao nỗ lực và sự trưởng thành.
Đánh giá hiệu suất của nhân viên dựa vào hoàn thành mục tiêu nhóm và mục tiêu cá nhân. Văn hóa Agile: Sự tự chủ (Autonomy), Phát triển năng lực (Mastery), Mục đích công việc (Purpose)
Giao tiếp hiệu quả hơn trong Scrum
Là một mục tiêu quan trọng để đánh giá sự thành công. Không chỉ tiếp nhận thông tin qua báo cáo, mà còn qua sắc mặt, không khí làm việc > Cảm nhận những vấn đề tiềm ẩn
Việc nhìn thấy nhau, giao tiếp trực tiếp > Tăng tính gắn kết và gia cố tình đồng đội.
Xây dựng niềm tin trong Scrum
Niềm tin là động lực quan trọng để tạo dựng nên sự thành công của một nhóm, dự án, công ty.
Niềm tin đến từ giây phút chuyên nghiệp, thiện cảm từ ngày đầu của dự án khi các thành viên trao đổi với nhau rõ ràng yêu cầu tầm nhìn và bối cảnh của dự án cũng như các ràng buộc tiêu chuẩn và lưu ý khi làm việc trong dự án.
Giao tiếp tích cực và chuyên nghiệp trong giai đoạn đầu là yếu tố then chốt quan trọng nhất.
NIỀM TIN ĐẾN TỪ CAM KẾT LÀM VIỆC, SỰ ĐÚNG HẸN, CHUYỂN GIAO SẢN PHẨM, THÔNG TIN HỖ TRỢ KỊP THỜI CÁC VẤN ĐỀ GẶP PHẢI
Quản lý yêu cầu người dùng với User Story: Scrum không quy định cụ thể kỹ thuật, hình thức thể hiện các yêu cầu. User story là kỹ thuật được sử dụng phổ biến nhất hiện nay.
User Story là một bản tóm tắt nhu cầu của người dùng được viết bởi khách hàng/đại diện khách hàng/những người hiếu nghiệp vụ và biết được tốt nhất những nhu cầu của mình với sản phẩm. Không đơn thuần là công cụ mô tả, mà là công cụ giao tiếp và chất kết dính trong quá trình làm việc. Scrum quy định Product Owner (PO) sở hữu các Story nhưng đó không phải là việc của riêng PO mà đôi khi là chung của một nhóm nghiên cứu phát triển sản phẩm.
Điểm mạnh của User Story
User Story được ưa chuộng bởi:
- Ngắn gọn, sử dụng ngôn ngữ gần gũi với người dùng. KHÔNG PHẢI LÀ BẢN MÔ TẢ ĐẦY ĐỦ VỀ TÍNH NĂNG/CHỨC NĂNG SẢN PHẨM. Chủ yếu liệt kê các tính năng đó.
- User Story là một nửa của việc mô tả tính năng người dùng (Nửa được viết ra) một nửa khác là thảo luận tính năng đó.
Tính ngắn gọn của User Story có 2 lợi ích chính:
- Nhóm không mất nhiều thời gian cho việc phải viết quá chi tiết những yêu cầu của sản phẩm ngay từ đầu (cách truyền thống). Chỉ cần mô tả đủ các chức năng CHÍNH để bắt đầu làm việc.
- Tăng giao tiếp thường xuyên giữa các bên, nhất là PO và nhóm phát triển.
Đây là cách tốt nhất HẠN CHẾ NHỮNG HIỂU LẦM khi mô tả yêu cầu sản phẩm.
Ngôn ngữ đời thường, giúp những người không am hiểu về kỹ thuật (Khách hàng, người dùng) có thể hiểu được mong muốn của mình. Cách truyền thống, tài liệu viết chi tiết nhiều yếu tố kỹ thuật, khó cho việc giao tiếp giữa các bên
Làm rõ một User Story: Làm rõ User Story thực hiện thường xuyên (Thường do PO đảm nhiệm) và cũng có thể có sự tham gia của nhóm phát triển và các bên liên quan. Có thể tổ chức các phiên làm mịn Product Backlog để thực hiện việc này.
Ai là người làm ra User Story
PO – Quản lý Product Backlog và tất cả những US trong đó, không có nghĩa là PO là người biết toàn bộ tất cả những US.
- Trường hợp lý tưởng, người dùng thực sự tham gia viết US.
- Trường hợp khác PO đại diện người dùng nhưng luôn việt US với vai trò người dùng, không phải vai trò của PO.
- Trong tất cả các trường hợp, tất cả các thành viên của nhóm phát triển có thể tham gia viết US. Đặc biệt, với nhóm phát triển sản phẩm khởi nghiệp cũng là những người đưa ra ý tưởng về sản phẩm, am hiểu tầm nhìn về sản phẩm.
> User Story đóng vai trò vô cùng quan trọng trong việc mô tả tính năng của sản phẩm.
INUEST – Các tiêu chuẩn cho một US tốt
INDEPENDENT (Độc lập): Hạn chế sự phụ thuộc giữa các US => Nhóm dễ dàng lựa chọn thứ tự triển khai.
NEGOTIABLE (Đàm phán được): US không phải là bản mô tả chi tiết chặt chẽ tính năng của sản phẩm. Thảo luận và đàm phán là cách hiểu đúng nhu cầu thực tế và đưa ra điều chỉnh hợp lý.
VALUABLE (Đáng giá): US có giá trị người dùng (không phải đối với những người khác). Cách thể hiện giá trị US tốt nhất là viết đầy đủ ý nghĩa (“Là tôi muốn…để…”) nhiều nhóm bỏ qua vế quan trọng sau “để…”
ESTIMABLE (Ước tính được): Không cần phải ước tính chính xác nhưng có 1 giá trị ước tính để lập kế hoạch. US cần cung cấp đủ các thông tin cần thiết mới có thể ước tính được.
SIZED APPROPRIATELY (Kích thước phù hợp): US sắp được đưa vào sản xuất cần có kích thước nhỏ (đồng nghĩa với việc được mô tả rõ ràng hơn).
TESTABLE (Kiểm thử được): US đạt tiêu chí kiểm thử có nghĩa là có đủ chi tiết cần thiết để hiểu đúng và làm đúng. Kiểm thử là cách đạt được sự đồng thuận giữa nhóm phát triển, P0 và các bên liên quan.
Đánh giá cá nhân về thực tiễn Áp dụng Agile – Scrum trong công ty Start up Công nghệ.
Trong vai trò là Product Owner cũng là người quản trị doanh nghiệp, Hồng đã cùng với đội ngũ IT của mình áp dụng Scrum trong suốt hành trình tạo lập các sản phẩm công nghệ cho doanh nghiệp như Website, App Mobile, hệ thống quản lý… Việc áp dụng Scrum đúng cách đã giúp cho hiệu suất làm việc của đội ngũ BA, IT tăng lên gấp nhiều lần. Đa phần các Sprint đều thành công ngoài mong đợi. Sản phẩm công nghệ hoàn chỉnh đúng hạn và có sự đóng góp ý kiến của cả tập thể. Điều này được Hồng đánh giá cao về cả tinh thần làm việc, hiệu năng của sản phẩm và lợi ích dành cho doanh nghiệp. Các sản phẩm công nghệ Hồng và đội ngũ IT đã làm nên sẽ được Hồng giới thiệu thông qua kênh Youtube chính thống của Hồng trong thời gian sớm nhất.
Đây là món quà tri ân của Hồng dành cho đội ngũ, kỷ niệm đồng hành, cố gắng và cống hiến để làm ra những sản phẩm công nghệ có giá trị.
Các nội dung trong bài viết này được tóm tắt từ “Cẩm Nang Scrum”. Các hình vẽ, mô hình đã được biên soạn và vẽ lại phát triển từ nội dung của Cẩm nang. Nội dung này đã được Hồng tóm lượt chia sẻ với đội ngũ IT của mình trong một buổi chia sẻ để giải quyết những mâu thuẫn trong quá trình làm việc của Team kỹ thuật.
Note: Vui lòng đọc kỹ yêu cầu về Bản Quyền trước khi sao chép hoặc trích dẫn nội dung và hình ảnh của Blog.
Nguyen Xuan Hong 
Trả lời