Nhóm Scrum có hai đặc điểm cực kì quan trọng là: tự tổ chức (self-organizing) và liên chức năng (cross-functional). Về tự tổ chức, tự quản, tự định hướng thì dễ hiểu, nhưng thế nào là “liên chức năng”? Bài này mong muốn chỉ ra  một số hiểu lầm thường gặp, cũng như đào sâu thêm về khái niệm này trong phạm vi Scrum Framework để người học và thực hành Scrum đỡ bị rơi vào các nghịch lí khi cố gắng đối lập Scrum với những gì hiện có.

Có người bảo “cá nhân trong nhóm liên chức năng biết làm tất cả mọi việc, trong nhóm Scrum không có ai là tester hết, không cần designer trong nhóm Scrum nữa, chỉ có developer thôi”.

Có người lại bảo “nhóm liên chức năng có nghĩa là ai cũng có thể làm được việc thay thế người khác, không cần phân vai rõ ràng, một người có vấn đề sẽ không ảnh hưởng đến cả nhóm”.

Có người thì cao hứng phát biểu “một nhóm mà liên chức năng thì siêu năng suất”.

Những nhận định trên trên đều không ổn, và chúng là các điển hình về các ngộ nhận khi đề cập đến nhóm Scrum.

Vậy nhóm liên chức năng là gì?

Đây không phải là khái niệm mới mẻ gì, và về cơ bản nó chưa có nhiều thay đổi trong cách định nghĩa: đó là một nhóm bao gồm nhiều cá nhân với các chuyên môn khác nhau được kết hợp lại cùng làm việc hướng tới một mục tiêu chung.

Trong đội dự án, các cá nhân có thể đến từ nhiều phòng ban chức năng khác nhau, cũng có thể xuất phát từ bên ngoài (khách hàng, các cá nhân có liên quan, chuyên gia tư vấn v.v.). Nhưng khi đã thành một đội (team), thì các cá nhân làm việc tập trung cho đội như là một đơn vị (unit) để hoàn tất mục tiêu chung.  Bên trong nhóm liên chức năng không có các nhóm nhỏ khác. Ví dụ: một Nhóm Scrum “Alpha” được thành lập với một Product Owner, một Scrum Master, 2 Tester, 5 Developer, 1 Architect, 1 UX Designer sẽ không phân chia chức năng thành các nhóm nhỏ khác như nhóm Testing (2 người), nhóm Developement (5 người) … nữa, mà chỉ có một nhóm duy nhất “Alpha” với các cá nhân có các chuyên môn khác nhau, hợp thành một đội thống nhất để làm việc hướng tới sản phẩm cần phát triển. Trong cách nói của Ken và Jeff, tester hay analyst … đều là developer, họ là nhà phát triển nhưng có chuyên môn đặc thù là kiểm thử hay phân tích; developer trong trường hợp này không có ý nghĩa là coder\programer. Việc xóa nhòa các title này có mục đích là để gom mọi người vào một mục tiêu chung, không phân biệt “nhãn mác” (title): phát triển phần mềm.

Khác với nhóm liên chức năng, nhóm chức năng (functional team) thường chỉ phụ trách một loại công việc đặc thù. Ví dụ, phòng thiết kế thì không code, phòng test thì không có ai design. Công việc của nhóm chức năng thường có tính cô lập cao.

Có phải cứ “liên chức năng” thì nhóm sẽ năng suất hay không?

Hỏi cách khác, liệu cứ thành lập một nhóm Scrum với cách tổ chức liên chức năng như thế, thì nhóm sẽ ngay tức khắc sẽ gia tăng năng suất lao động?

Rõ là không dễ dàng như thế rồi.

Liên chức năng chỉ là một “cấu hình” trong các cách thức cấu tạo nhóm làm việc. Và cách cấu hình này cho phép hình thành một đội độc lập với đầy đủ các chuyên môn cần thiết để hoàn tất công việc, dưới dạng một ‘business unit’ ở mức tối giản. Sự độc lập này tạo điều kiện cho nhóm ra các quyết định kịp thời, chính xác và nhanh chóng mà không bị phụ thuộc các đơn vị khác. Ví như trong cách thức tổ chức các nhóm chức năng (functional teams), một công việc phải đi qua nhiều công đoạn, mỗi công đoạn lại do các nhóm [với các chức năng] khác nhau đảm nhiệm, và vì thế sự phụ thuộc (dependency) gia tăng, khiến cho sự linh hoạt giảm xuống, và có nguy cơ làm giảm sự hiệu quả cũng như năng suất của nhóm.

Về mặt lí thuyết, với cấu hình “liên chức năng”, Nhóm Scrum có khả năng trở thành một “work cell” và có được “luồng một sản phẩm” (thuật ngữ của Lean), từ đó vừa gia tăng năng suất, vừa gia tăng chất lượng sản phẩm; đồng thời tạo điều kiện để vận hành “hệ thống kéo” (cũng thuật ngữ Lean), giúp loại bỏ các lãng phí không cần thiết, tối ưu hóa giá trị.

Nhưng một nhóm bất kì đều phải trải qua các giai đoạn Hình thành>Bão tố>Ổn định>Hiệu suất>Thoái trào (theo Tuckman). Có nghĩa là nó không thể đạt được hiệu quả ngay khi mới thành lập được.

Mặt khác, về “hiệu suất”, Katzenbach và Smith chỉ ra rằng một nhóm phải mất khá nhiều nỗ lực mới đạt được thành quả thực sự. Nó sẽ phải trải qua các trạng thái  như là một “nhúm” các cá nhân rời rạc, cho tới khi trở thành một nhóm thực sự, rồi mới phát huy hiệu quả cao.

Đường cong Hiệu suất Nhóm, ảnh: Đại học Michigan.

Hiệu suất hay không do nhiều nguyên nhân cấu thành. Hiệu suất thường là cái cuối cùng trong tất cả các nỗ lực, mà “cấu hình nhóm” là một trong các nỗ lực như vậy. Nếu coi “cấu hình nhóm” là phần “cứng”, thì còn nhiều yếu tố nữa quyết định nhóm có “hiệu suất” không, chính là các phần “mềm” của nhóm: cách vận hành nhóm, quy tắc, phương pháp, sự lãnh đạo v.v. Trong Scrum, các yếu tố “mềm” này được phân bố rải rác trong chính sách trao quyền để nhóm “tự tổ chức” (self-organizing), “tự quản” (self-managing), “tự định hướng” (self-directed); trong các phân bố vai trò trong nhóm (ai lãnh đạo việc gì, ai phụ trách việc gì); các quy tắc và công cụ cộng tác (các burndown chart, backlogs, events, metrics); cho đến nguyên lí và cơ chế đảm bảo sự minh bạch trong làm việc v.v. Tất cả các yếu tố đó kết hợp nhuần nhuyễn với “cấu hình” mới tạo nên một nhóm cộng tác chặt chẽ, mau trưởng thành, sớm đạt được trạng thái năng suất cao. Lấy ví dụ, việc một nhóm liên chức năng được trao quyền tự tổ chức sẽ phát huy được sự chủ động, giảm thiểu phụ thuộc vào bên ngoài (hay bên trên); cũng do một nhóm liên chức năng đã có đủ các kĩ năng cần thiết để giải quyết vấn đề nên hoàn toàn có thể trao quyền cho nó để tự nó phát huy năng lực tập thể giải quyết vấn đề theo cách tốt nhất; nhờ đó sự liên chức năng kết hợp với sự tự quản, tự tổ chức có thể thúc đẩy các sáng kiến từ dưới lên (bottom-up), trực tiếp, nhanh chóng và chính xác. Khi đó, lãnh đạo\quản lí  thực hiện công việc chủ yếu là xúc tiến quá trình cộng tác nhóm và tự quản của nhóm thông qua đảm bảo quy trình, loại bỏ trở ngại, thiết lập và duy trì môi trường thuận lợi, thúc đẩy tiến trình thanh tra-thích nghi, v.v. chứ không còn bám sát từng đầu công việc nữa. Việc này đã được quy định chặt chẽ trong “mô tả công việc” của từng vai trò (Scrum Master, Product Owner, DevTeam) rồi.

Thế còn chuyện “liên chức năng thì không bị ảnh hưởng bởi xáo trộn cá nhân”? Chuyện một cá nhân ra đi mà nhóm không có xáo trộn chỉ là ảo tưởng. Chỉ có robot mới có thể đáp ứng được yêu cầu đó. Theo hướng đó thì chỉ việc đề cao quy trình, quản lí thật chặt đầu công việc của member theo lối “công nhân” tay chân, giao cho các công việc cố định, xếp vào các vị trí và công đoạn được mô tả rõ ràng  Việc này khả thi ở chỗ khác, chứ tuyệt nhiên khó hiệu quả ở đội phát triển phần mềm vốn có bản chất phức tạp, và rất đa dạng trong từng công việc. Hơn thế nữa, việc gán chuyện “không xáo trộn” như vậy cho nhóm liên chức năng còn phản lại nguyên lí của Agile: “Cá nhân và tương tác hơn là quy trình và công cụ”. Cá nhân là tiền đề của nhóm, là nơi quyết định thành bại của nhóm. Nhưng cá nhân ấy là cá nhân đặt trong nhóm cộng tác, với các đòi hỏi cao về các “tương tác” có chất lượng thì mới giải phóng được năng lực của chính các cá nhân ấy. Còn “quy trình” chỉ là cái hỗ trợ cho việc phát huy năng lực của cả nhóm. Nhóm làm việc bao giờ cũng hướng tới sự gắn kết cao độ, càng gắn kết thì lại càng dễ bị xáo trộn bởi sự thay đổi của cá nhân trong nhóm. Nhóm liên chức năng có thể có một ưu điểm trong việc hỗ trợ nhau trong công việc (do đòi hỏi cộng tác chặt chẽ, sự minh bạch trong công việc, cũng như đó là một nhóm-học-tập liên tục), nên có thể giảm thiểu rủi ro của việc mất đi “chuyên gia”, nhưng việc xáo trộn, thậm chí sốc, là không thể tránh khỏi.

Cuối cùng, có phải trong Nhóm Scrum không còn tester, không còn QA nữa, mà chỉ còn developer? developer phải là dân “xịn” biết test ngon, biết code giỏi, biết design khéo? Cũng là ảo tưởng nốt! Và ảo tưởng này xuất hiện đơn giản là xuất phát từ việc hiểu nhầm khái niệm “cross-functionality” như đã nói ở bên trên.

Cá nhân và tương tác hơn là quy trình và công cụ;

Khả năng tự học hơn là điểm số và bằng cấp;

Cộng tác đa phương hơn là tuân thủ khế ước;

Phản hồi với thay đổi hơn là tuân thủ kế hoạch.

Trong khi các điều bên phải vẫn còn nguyên giá trị, chúng tôi ưu tiên hơn cho các điểm ở bên trái.

***

In English:

Individuals and interactions over processes and tools;

Ability of self-directed learning over measurement and certification;

Stakeholder collaboration over constant contract;

Responding to change over following a plan.

That is, while there is value in the items on the right, we value the items on the left more.

Viết riêng cho các GV đồng nghiệp ở FAT.

Tuần vừa rồi tôi có thực hiện một buổi seminar tương đối thú vị về project-based learning để cùng các giảng viên thảo luận về các ngóc ngách của việc huấn luyện các lập trình viên non tay nghề, bằng việc cho họ trải nghiệm thực tế phát triển phần mềm một cách gần gũi và tiêu chuẩn thông qua các “dự án”. Thực tế đây là một reflection về quá trình chuyển đổi phương pháp luận, một số vấn đề, giải pháp và cải tiến liên quan. Tuy nhiên có một điều tôi vẫn muốn nói thêm về một số vấn đề mang tính “lịch sử”, có lẽ đây cũng là dữ liệu bổ ích nên tôi chép lại nội dung đó ra đây.

Đầu năm 2009, tôi có được giao nhiệm vụ tái thiết lại phương pháp luận triển khai môn dự án (Project) cho sinh viên năm cuối tai các trung tâm  tại Hà Nội do một số vấn đề tồn tại dai dẳng trong quá trình triển khai môn học thú vị này suốt nhiều năm trước. Đơn cử một vài mắc mớ như:

• Các giảng viên hầu như không thống nhất trong phương pháp luận, mỗi người mỗi phách trong hướng dẫn sinh viên thực hiện dự án cũng như đánh giá kết quả. Phần nhiều do sự đa dạng về phương pháp và nền tảng của các giảng viên (người xuất thân từ công ty làm phần mềm khác nhau, người xuất thân từ trường học); lại thiếu tài liệu hướng dẫn chi tiết.
• Mô hình waterfall như mô tả “phương pháp” lúc đó gần như không có hiệu lực trong thực tiễn. Mặc cho đây là cách tiếp cận dễ hiểu, và … dễ dạy, cái “quy trình” ấy gần như không bao giờ hiện diện trong thực tế. Theo mô hình này, sinh viên phải phân tích chi tiết bài toán, thiết kế rồi mới code và test; từng bước một.  Nhưng thường thì sản phẩm cuối cùng rất ít khi khớp với mô tả trong SRS lúc ban đầu. Điều này rất dễ lí giải vì vấn đề đặt ra trong các project thường phức tạp nên sinh viên chỉ có thể hiểu thấu đáo trong quá trình hoàn thiện sản phẩm, chứ không thể ngay lúc đầu planning. Do vậy thực tế này dẫn đến hầu hết các documentation chỉ mang tính “báo cáo”, làm cho đầy đủ quy trình chứ ít khi phản ảnh những gì thực sự đang có trong sản phẩm. Một số giảng viên nhìn ra vấn đề đó từ sớm và có nhiều nỗ lực để làm “chính xác hóa” cái mớ tài liệu ấy bằng các cơ chế review liên tục, trợ giúp kĩ thuật về viết lách, OOAD v.v.; nhưng kết quả chỉ tốt hơn chút đỉnh, chứ không giải quyết được nguồn ngọn vấn đề.
• Học trò cuối cùng vẫn không hiểu được thế nào là “quy trình phát triển phần mềm”, không thực sự làm chủ được một quy trình do thực tế không được trải nghiệm một quy trình nào cả. Sách dạy waterfall, thầy ép theo waterfall, nhưng thực tế sinh viên luôn thực hiện theo một “cách khác”. Ví dụ như: đọc xong đề tài, thay vì viết SRS, phân tích các use case, rồi thảo luận các class diagram, sequence diagrame (SV quan niệm đó chỉ là các “tài liệu để báo cáo”-không hơn) v.v., thì sinh viên sẽ thực hiện theo trình tự kiểu như: tạo GUI, làm DB, rồi sau đó vừa làm vừa viết “tài liệu”; hoặc theo một cách khác nữa  cũng phổ biến không kém: đọc đề bài > phân tích rất sơ sài> làm DB > code > tài liệu.
• Không có một môi trường thực sự  cho việc cộng tác nhóm phát triển do thiếu đầu tư vào công cụ bên cạnh quy trình.

Đứng trước bài tập khó nhằn này, tôi đã cố gắng tìm kiếm một mô hình làm dự án phù hợp với đối tượng và vấn đề đặc thù tại trung tâm. Một phương pháp được đề xuất phải thỏa mãn một số tiêu chí cơ bản như:

• Thực dụng và khả thi: nó phải thực sự thực thi (khả thi) được, thống nhất giữa phương pháp luận và thực tiễn. Để khả thi, nó phải dễ hiểu, và dễ làm.
• Hướng ngoại: tức nó phải tương thích với một quy trình ở “ngoài kia” (“các công ty”), thay vì tự mình đề xuất theo sách vở. Điều này hữu ích trong động viên bản thân sinh viên, vì họ cảm thấy có được cái cảm giác trải nghiệm một quy trình thật trong một môi trường phát triển phần mềm đầy đủ.
• Có tính giáo dục: dù gì thì mục đích của dự án ở đây cũng là để sinh viên được trải nghiệm và học hỏi các kĩ năng cần thiết trong phát triển phần mềm, không phải để sản xuất phần mềm. Nó phải đưa sinh viên tới các ngóc ngách, đối mặt với các thử thách cần thiết để học được các kĩ năng cần thiết cho việc hành nghề của họ.

Lúc ấy có vài gợi ý: 1.cải tiến waterfall với các practices và tài liệu hóa đầy đủ việc hướng dẫn triển khai môn học; 2. Scrum  (khi đó tại trung tâm tôi cũng đã run hai dự án dùng Scrum: một với nhóm giảng viên, một với nhóm sinh viên); 3. Sử dụng tư tưởng iterative và RUP best practices với các tài liệu trợ giúp đầy đủ; 4. CMMI .

Do lúc đó tôi bị áp lực phải đưa nội dung OOAD vào chương trình (do chương trình chính quy thiếu sót mục này), nên tôi đã lựa chọn phương án (3). Các sự thay đổi quan trọng là:

• Định nghĩa quy trình phát triển phần mềm với định hướng Iterative, RUP-based approaches.
• Viết tài liệu hướng dẫn triển khai project cho các giảng viên, cùng với các lecture notes, evaluation form tương ứng và cả case study dưới dạng “showcase” để giảng viên dễ hình dung.
• Làm template cho các artifacts (plan, SRS, use case spec templates, design template, verification checklist v.v.) để định hướng cũng như trợ giúp cả sinh viên lẫn giảng viên hướng dẫn dễ dàng cộng tác cũng như quản lí. Lúc này các tài liệu không còn là “tài liệu báo cáo” thuần túy, mà là các artifacts trong quá trình phát triển, nó động và hữu ích.
• Cài đặt hệ quản trị dự án (PMS) với cái lõi Redmine và SVN server, kèm theo các test server cho từng kì để thiết lập môi trường cộng tác chuyên nghiệp.
• Vậy là xong phương pháp luận, tài liệu triển khai, quy trình và công cụ. Tôi đã có buổi báo cáo với các group leader để thảo luận về phương pháp mới. Sau một vài ý kiến góp ý nho nhỏ, tôi mang nội dung quy trình mới ra thảo luận với hầu hết các giảng viên trong khuôn khổ một seminar. Đồng thuận tuyệt đối. Bước đầu như thế là thuận lợi.

Tuy vậy, khó khăn chỉ phát sinh lúc ta thực sự bắt tay vào công việc chứ thường chưa phải là lúc chuẩn bị.  Hơn một năm triển khai mang lại những tín hiệu không vui mừng lắm. Bên cạnh một số report thuận lợi từ các giảng viên có kinh nghiệm và cộng tác chặt chẽ với người đề xướng phương pháp, còn ra thì hầu hết vẫn không cải thiện triệt để. Các vấn đề được đề cập ở đầu bài viết này vẫn hiện hữu như những cái gai chọc thẳng vào mắt.

Qua thảo luận chi tiết và phản tỉnh tôi hiểu ra rằng tài liệu đầy đủ không giúp được mấy, việc training cũng sẽ không có tác dụng gì nhiều khi mà cái approach ngay từ đầu đã không đúng. Cái bọn tôi cần là một cách tiếp cận đơn giản, xuyên suốt, có khả năng thích nghi và tùy biến cao. Một phần do sự phức tạp trong việc triển khai đồng loạt, một phần do sự biến động không đoán được trong kĩ năng của sinh viên từng thời kì, việc cố định một quy trình cứng nhắc không có khả năng thích nghi sẽ dẫn đến hiệu lực kém và khó kiểm soát. Nhất là khi một quy trình đó lại đòi hỏi kĩ năng đặc thù tương đối toàn diện ở một đội ngũ thực thi (sinh viên) ít kĩ năng (vì họ đang luyện mà). Cách tiếp cận kiểu RUP hay waterfall đó đòi hỏi sinh viên phải “‘phân thân” do yêu cầu chuyên môn hóa (manager, architect, designer, coder, tester), và đòi hỏi nó phải “đạt” tại tất cả các kĩ năng đó (vì nếu không đạt phần design thì lấy gì mà code?) để đi đến đích là một sản phẩm đem đi bảo vệ trước hội đồng. Cách tiếp cận engineering như vậy về cơ bản là đổ vỡ ngay từ đầu, xét theo khía cạnh khả thi. Thế nên, dù nỗ lực nhiều nhưng kết quả không thể nói là hài lòng được.

Năm 2011 cũng là năm tôi có cơ hội để nhìn nhận sâu sắc hơn về agile và Scrum nhờ vào các hoạt động diện rộng cũng như chuyên sâu để tìm lời giải cho mình: tham gia khóa học của Scrum Alliance để hệ thống hóa những hiểu biết về Scrum, gặp gỡ các employers để hiểu requirement về developers, khởi xướng HanoiScrum, cộng tác chặt chẽ với AgileVietnam và tham gia AgileTour  để học hỏi từ cộng đồng chuyên nghiệp, thành lập ScrumLab để đi sâu vào các ngóc ngách thực hành Scrum\XP và thử nghiệm trên các đối tượng khác nhau; tiếp tục đọc, thử nghiệm và thuyết trình và huấn luyện Agile, TDD, Simple Design, Testing, Scrum v.v. Những trải nghiệm đa dạng đó không chỉ tiếp thêm sinh lực cho công cuộc phổ biến agile\Scrum ra cộng đồng cùng với các bạn cùng chí hướng, mà còn tạo thêm niềm tin và xung lực mạnh mẽ cho phép tôi mạnh tay đề xuất tiếp cận mới cho các môn project tại các trung tâm: phải linh hoạt hóa triệt để công tác giáo dục. Và project là xuất phát điểm.

Lần “nâng cấp” về phương pháp luận này có mấy điểm mấu chốt:

• Đặt Project-Based Learning và Experimental Learning làm nền tảng giáo dục cho việc triển khai các khóa học project. Cần phải có lý thuyết giáo dục dẫn đường, vì đây là một nhiệm vụ giáo dục.
• Tái thiết các mục tiêu cốt lõi của các khóa học Project của từng kì, theo hướng rèn luyên khả năng tích hợp các kĩ năng thành phần (component skills) quan trọng đối với software developer. Định hướng hoạt động theo objective-oriented (huấn luyện, thực hành, đánh giá dựa vào mục tiêu).
• Tái thiết quy trình với cái lõi là agile\Scrum
• Đề cao tính thích nghi, tương tác, liên tục học hỏi và cải tiến trong thực tiễn triển khai. Liên tục cập nhật các tài liệu, best practices quan trọng.
• Tiếp tục hoàn thiện môi trường phát triển, nhấn mạnh các khâu phân vai, hạ tầng, và công cụ cho luyện tập.

Tiến trình này được khởi xướng được hơn nửa năm, và vẫn đang trong quá trình học hỏi (thực tế là đang rất lộn xộn). Nhưng tôi tin tưởng hướng tiếp cận mới rất đúng đắn, phù hợp với thực tiễn và xu thế chung. Hơn thế nữa, qua các thực tiễn sử dụng tư duy linh hoạt vào hoạt động không thuộc lĩnh vực phát triển phần mềm (như cung cấp dịch vụ, marketing, giáo dục chẳng hạn) được báo cáo tại Scrum Alliance, Agile Conference thì các giá trị agile rất phù hợp với các nguyên lý căn bản của giáo dục hiện đại như  tính cá nhân hóa, tính tương tác, tính thích nghi, tính tùy biến, sự phát triển bền vững v.v. Có thể nói các giá trị và nguyên lí agile hỗ trợ thúc đẩy mạnh mẽ  hiệu quả của các tiến trình giáo dục.

Cỗ xe tiếp tục lăn bánh, và tôi đang háo hức mong đợi các kết quả tốt vượt bậc từ phía triển khai. Đây quả là chặng đường thử thách và thú vị.

TPS – Toyota Production System- là kinh điển quản lí, xây dựng tổ chức trường tồn. Chính nó tạo nên và khuếch trương Tư duy Tinh gọn (Lean Thinking), Sản xuất Tinh gọn (Lean Manufacturing). Giờ đây Lean đã có ở mọi nơi: khởi sự, phát triển sản phẩm (đủ loại hình), dịch vụ. Dưới đây là tóm tắt 14 nguyên lí của nó:

Nguyên lí #1: Ra các quyết định quản lí dựa trên một triết lí dài hạn, dù phải hy sinh những mục tiêu ngắn hạn

• Trang bị một ý thức về mục tiêu có tính triết lí để thay thể bất kì một hình thức ra quyết định ngắn nhạn nào. Làm việc, phát triển và lèo lái theo mục đích chung lớn lao hơn là chỉ kiếm tiền.
• Tạo ra giá trị cho khách hàng, cho cộng đồng và cho nền kinh tế. Đó là khởi điểm.
• Có trách nhiệm

Nguyên lí #2: Tạo ra một chuối quy trình liên tục làm bộc lộ sai sót

• Tái thiết các quy trình nghiệp vụ để đạt được một luồng liên tục  có giá trị gia tăng cao. Triệt tiêu thời gian chết trong các quy trình.
• Liên kết các thông tin, nhân sự, chu trình để phát hiện tức thì các trục trặc
• Làm chuỗi giá trị trở nên rõ nét trong văn hóa của công ty, làm chìa khóa cho quy trình cải tiến liên tục và phát triển nhân sự.

Nguyên lí #3: Sử dụng hệ thống kéo để tránh sản xuất quá mức

• Cung cấp đúng cái khách hàng cuối cần, đúng thời điểm, đúng số lượng họ mong muốn.
• Tối thiếu hóa khối lượng công việc trong qui trình (Work-In-Progress:WIP)
• Đáp ứng tốt với các thay đổi hằng ngày

Nguyên lí #4: Bình chuẩn hóa lượng công việc

• San bằng sự trồi sụt trong kế hoạch sản xuất
• Dàn đều khối lượng công việc tại tất cả các quy trình nghiệp vụ, thay thế hình thức sản xuất ngừng/chạy

Nguyên lí #5: Xây dựng thói quen biết dừng lại để giải quyết trục trặc, đạt đến chất lượng tốt ngay từ ban đầu

• Chất lượng là động cơ xác định giá trị
• Tự nhận biết trục trặc và tự dừng lại. Tự kiểm lỗi (Self-check) là nền tảng để xây dựng chất lượng.
• Thiết lập hệ thống phụ trợ để nhanh chóng giải quyết trục trặc
• Xây dựng văn hóa biết dừng lại và chậm rãi để có chất lượng ngay từ đầu

Nguyên lí #6: Chuẩn hóa các nghiệp vụ là nền tảng của sự cải tiến liên tục cùng việc giao quyền cho nhân viên

• Sử dụng biện pháp ổn định lặp lại thường xuyên tại mọi khu vực để duy trì khả năng phán đoán, nhịp dộ sản xuất cùng với thông lượng đều đặn của các quy trình. Đây là nền tảng của luồng một sản phẩm (one-piece-flow) và  hệ thống kéo (pull system).
• Tiêu chuẩn hóa các thói quen làm việc tốt. Cải tiến các tiêu chuẩn không ngừng.

Nguyên lí #7: Quản lí trực quan để không có trục trặc nào bị che khuất

• Dùng chỉ dẫn hình ảnh để nhận biết sớm tình trạng công việc
• Thiết kế hệ thống bảng biểu hỗ trợ luồng một sản phẩm và hệ thống kéo
• Rút ngắn báo cáo xuống 1 trang giấy

Nguyên lí #8: Chỉ áp dụng các công nghệ tin cậy, đã được kiểm chứng toàn diện, để phục vụ cho các quy trình và con người của công ty.

• Công nghệ để hỗ trợ chứ không phải thay thế con người
• Kiểm nghiệm cẩn thận trước khi áp dụng
• Khuyến khích xem xét công nghệ mới, nhanh chóng triển khai nếu đã chín muồi

Nguyên lí #9: Phát triển những nhà lãnh đạo, người hiểu thấu đáo công việc, sống cùng triết lí và truyền đạt lại cho người khác

• Phát triển lãnh đạo từ bên trong công ty
• Lãnh đạo phải là hình mẫu cho triết lí và cách thức kinh doanh của công ty
• Lãnh đạo phải am tường nghiệp vụ, là mentor khi cần truyền dạt văn hóa công ty

Nguyên lí #10: Phát triển các cá nhân và tập thể xuất sắc có thể tuân thủ triết lí của công ty

• Tạo dựng văn hóa mạnh và ổn định
• Đào tạo trong khuôn khổ văn hóa công ty
• Sử dụng nhóm liên chức năng để cải thiện chất lượng và năng suất công việc
• Liên tục huấn luyện làm việc nhóm vì mục tiêu chung

Nguyên lí #11: Tôn trọng mạng lưới đối tác và các nhà cung cấp bằng cách thử thách họ và giúp họ cải tiến

• Thử thách đối tác để họ phát triển
• Đặt mục tiêu và hỗ trợ đối tác để đạt mục tiêu

Nguyên lí #12: Đích thân đi đến và xem xét hiện trường để hiểu tường tận tình hình (Genchi Genbutsu)

• Đi đến nguồn gốc vấn đề, đích thân quan sát thực địa. Kể cả lãnh đạo cao cấp.
• Chỉ nghĩ và nói dựa trên dữ liệu thực tiễn đã được kiểm chứng

Nguyên lí #13: Ra quyết định không vội vã thông qua sự đồng thuận và xem xét kĩ lưỡng mọi khả năng, rồi nhanh chóng thực hiện

• Xem xét tất cả các khả năng trước khi quyết định. Khi quyết định rồi thì nhanh chóng thực hiện.
• Quyết định chậm nhất có thể.

Nguyên lí #14: Trở thành một tổ chức học hỏi bằng việc không ngừng tự phê bình và cải tiến liên tục (Kaizen)

• Khi có quy trình ổn định, dùng các công cụ cải tiến liên tục.
• Thiết lập quy trình tối thiểu hóa tồn kho.
• Củng cố tri thức của doanh nghiệp.
• Sử dụng phản tỉnh (hansei, reflection) tại những giai đoạn then chốt để thoải mái nhìn nhận sai sót, tránh lặp lại.
• Học tập thông qua tiêu chuẩn hóa những thói quen làm việc tốt

Dạo này mình quan tâm nhiều đến “nợ kĩ thuật” (technical debt), và đã bộc bạch nhiều lần trong các lần thuyết trình, giảng dạy Scrum, và viết một bài giới thiệu  “Technical Debt” là gì?.

Tối qua, vấn đề này lại được xới lên tại diễn đàn Hanoi Scrum, và thu hút sự chú ý của các cử tọa. Dưới đây là một slide trích trong bài thuyết trình của Mr. Vũ Hưng. Anh chủ yếu quan tâm tới vấn đề “Kiến trúc” khi nghĩ về món nợ này. Tuy vậy những khía cạnh khác về kĩ thuật, đạo đức, quy trình, năng lực đều đã được gợi lên và đưa ra “bàn mổ”. Tranh luận rất sôi nổi.

Nợ kĩ thuật – Trích Mr. Hưng NV

***

Trưa nay ngồi họp Review hoạt động đào tạo Quý vừa rồi, chợt liên tưởng đến “món nợ kĩ thuật” của các nhà trường. Kiểu gì cũng phải có người trả món nợ này. Vậy ai là người sẽ TRẢ: sinh viên, cơ sở đào tạo, xã hội hay người bảo trợ của sinh viên? Nghĩ đến đây chợt rùng mình không dám nghĩ tiếp 🙁

Trong bài báo “Fully Distributed Scrum: The Secret Sauce for Hyperproductive Offshored Development Teams”, các đồng tác giả (Sutherland et al. – 2008, Agile Conference 2008) có đưa ra thống kê đáng lưu ý để đánh giá về hiệu quả của nhóm phát triển của Xebia; đồng thời so sánh với các nhóm khác.

Qua đó ta thấy một đội Scrum cần ít person-month hơn để hoàn thành cùng một khối lượng công việc (tính theo LOC, function points). Trong đó có thể thấy năng suất của một dev trong waterfall là rất thấp (chỉ cho ra được 1.7 FP trong 1 tháng). Nếu tính tỉ lệ, Scrum là siêu năng suất (>700%), không kể đó là Scrum có đội Scrum ngồi chung (Collocated Scrum), hoặc phân tán giữa các châu lục (Distributed team).

Ngoài ra, có hai thông tin quan trọng khác: Một là, dự án được thực hiện không nhỏ: của Xebia là 125 person-month (không quá nhỏ), SirsiDynix là 827 PM. Hai là, đó là các offshored team. Hơn nữa, nhờ kết hợp Scrum và XP, nhóm Xebia đã tạo ra sản phẩm với chất lượng tốt. Họ đạt được 80% code coverage trong các unit test, và phần lớn (>90%) số bug phát hiện ra đã được fix ngay trong các iteration. Và họ dùng Scrum, chứ không phải là waterfall cải biên hay ScrumButt.

Mặc dù có thể vẫn còn đó có các khó khăn, nhưng rõ ràng là dùng Scrum cho các dự án “gia công” lớn với nhân lực phân tán là rất có triển vọng. Bạn đã thử chưa?

Trong lần IPO của Facebook, Mark Zuckerberg đã công bố “Hacker Way” – triết lí của Facebook, và nó được cụ thể hóa bằng Năm giá trị cốt lõi để dẫn đường nhân viên thực hành. Đây là một văn bản đáng chú ý, đặc biệt cho các công ty startup trong lĩnh vực công nghệ. Vì thấy có nhiều tương đồng với các core values của agile, tôi tạm trích dịch ra đây để làm tư liệu:

1. Tập trung vào ảnh hưởng

Nếu chúng tôi muốn có ảnh hưởng lớn nhất, cách tốt nhất để làm việc này là phải chắc chắn rằng ta luôn luôn tập trung giải quyết các vấn đề quan trọng nhất. Nghe có vẻ đơn giản, nhưng chúng tôi nghĩ rằng phần lớn các công ty thực hiện điều này không triệt để và lãng phí rất nhiều thời gian. Chúng tôi hi vọng tất cả mọi người ở Facebook tìm kiếm những vấn đề lớn nhất để giải quyết.

2. Chuyển động nhanh

Chuyển động nhanh giúp chúng tôi xây dựng nhiều thứ hơn và học hỏi nhanh hơn. Tuy nhiên, đối với phần lớn các công ty phát triển rồi, họ sẽ chững lại nhanh vì họ lo sợ mắc phải sai lầm nhiều hơn là quan tâm đến việc họ đang mất đi các cơ hội do chuyển động quá chậm chạp. Chúng tôi có câu: “Chuyển động nhanh và giải quyết nhiều việc”. Nếu bạn không giải quyết được bất cứ việc gì, có thể do không chuyển động đủ nhanh.

3. Táo bạo

Xây dựng những điều lớn lao có nghĩa là phải mạo hiểm. Thực tế này có thể khiến mọi người lo ngại và hạn chế phần lớn các công ty xắn tay vào thực hiện những việc táo bạo mà họ nên làm. Tuy nhiên, trong một thế giới đang thay đổi nhanh chóng, bạn sẽ nắm chắc thất bại nếu bạn không mạo hiểm. Chúng tôi có một câu nói khác: “Điều rủi ro nhất là không mạo hiểm”. Chúng tôi khuyến khích mọi nhân viên ra các quyết định mạo hiểm, ngay cả khi điều đó có nghĩa là đôi khi cũng va phải sai lầm.

4. Cởi mở

Chúng tôi tin tưởng rằng một thế giới mở hơn là một thế giới tốt đẹp hơn bởi vì nhiều người với nhiều thông tin hơn có thể ra các quyết định chắc chắn hơn và có ảnh hưởng lớn hơn. Niềm tin đó cũng được dùng trong vận hành công ty của chúng tôi. Chúng tôi làm việc chăm chỉ để đảm bảo mỗi người ở Facebook tiếp cận với nhiều thông tin nhất có thể về mọi lĩnh vực của công ty do đó họ có thể ra các quyết định chắc chắn nhất và có tác động lớn nhất.

5. Xây dựng giá trị xã hội

Xin nhắc lại một lần nữa, Facebook tồn tại để  làm cho thế giới mở và kết nối hơn, và không chỉ đơn giản là xây dựng một công ty. Chúng tôi kì vọng tất cả mọi người ở Facebook  tập trung hàng ngày vào việc làm thế nào để xây dựng các giá trị thực sự trong tất cả các việc làm của họ.

——

Dưới đây là toàn văn lá thư gửi công chúng của Mark:

LETTER FROM MARK ZUCKERBERG

Facebook was not originally created to be a company. It was built to accomplish a social mission — to make the world more open and connected.

We think it’s important that everyone who invests in Facebook understands what this mission means to us, how we make decisions and why we do the things we do. I will try to outline our approach in this letter.

At Facebook, we’re inspired by technologies that have revolutionized how people spread and consume information. We often talk about inventions like the printing press and the television — by simply making communication more efficient, they led to a complete transformation of many important parts of society. They gave more people a voice. They encouraged progress. They changed the way society was organized. They brought us closer together.

Today, our society has reached another tipping point. We live at a moment when the majority of people in the world have access to the internet or mobile phones — the raw tools necessary to start sharing what they’re thinking, feeling and doing with whomever they want. Facebook aspires to build the services that give people the power to share and help them once again transform many of our core institutions and industries.

There is a huge need and a huge opportunity to get everyone in the world connected, to give everyone a voice and to help transform society for the future. The scale of the technology and infrastructure that must be built is unprecedented, and we believe this is the most important problem we can focus on.

We hope to strengthen how people relate to each other.

Even if our mission sounds big, it starts small — with the relationship between two people.

Personal relationships are the fundamental unit of our society. Relationships are how we discover new ideas, understand our world and ultimately derive long-term happiness.

At Facebook, we build tools to help people connect with the people they want and share what they want, and by doing this we are extending people’s capacity to build and maintain relationships.

People sharing more — even if just with their close friends or families — creates a more open culture and leads to a better understanding of the lives and perspectives of others. We believe that this creates a greater number of stronger relationships between people, and that it helps people get exposed to a greater number of diverse perspectives.

By helping people form these connections, we hope to rewire the way people spread and consume information. We think the world’s information infrastructure should resemble the social graph — a network built from the bottom up or peer-to-peer, rather than the monolithic, top-down structure that has existed to date. We also believe that giving people control over what they share is a fundamental principle of this rewiring.

We have already helped more than 800 million people map out more than 100 billion connections so far, and our goal is to help this rewiring accelerate.

We hope to improve how people connect to businesses and the economy.

We think a more open and connected world will help create a stronger economy with more authentic businesses that build better products and services.

As people share more, they have access to more opinions from the people they trust about the products and services they use. This makes it easier to discover the best products and improve the quality and efficiency of their lives.

One result of making it easier to find better products is that businesses will be rewarded for building better products — ones that are personalized and designed around people. We have found that products that are “social by design” tend to be more engaging than their traditional counterparts, and we look forward to seeing more of the world’s products move in this direction.

Our developer platform has already enabled hundreds of thousands of businesses to build higher-quality and more social products. We have seen disruptive new approaches in industries like games, music and news, and we expect to see similar disruption in more industries by new approaches that are social by design.

In addition to building better products, a more open world will also encourage businesses to engage with their customers directly and authentically. More than four million businesses have Pages on Facebook that they use to have a dialogue with their customers. We expect this trend to grow as well.

We hope to change how people relate to their governments and social institutions.

We believe building tools to help people share can bring a more honest and transparent dialogue around government that could lead to more direct empowerment of people, more accountability for officials and better solutions to some of the biggest problems of our time.

By giving people the power to share, we are starting to see people make their voices heard on a different scale from what has historically been possible. These voices will increase in number and volume. They cannot be ignored. Over time, we expect governments will become more responsive to issues and concerns raised directly by all their people rather than through intermediaries controlled by a select few.

Through this process, we believe that leaders will emerge across all countries who are pro-internet and fight for the rights of their people, including the right to share what they want and the right to access all information that people want to share with them.

Finally, as more of the economy moves towards higher-quality products that are personalized, we also expect to see the emergence of new services that are social by design to address the large worldwide problems we face in job creation, education and health care. We look forward to doing what we can to help this progress.

Our Mission and Our Business

As I said above, Facebook was not originally founded to be a company. We’ve always cared primarily about our social mission, the services we’re building and the people who use them. This is a different approach for a public company to take, so I want to explain why I think it works.

I started off by writing the first version of Facebook myself because it was something I wanted to exist. Since then, most of the ideas and code that have gone into Facebook have come from the great people we’ve attracted to our team.

Most great people care primarily about building and being a part of great things, but they also want to make money. Through the process of building a team — and also building a developer community, advertising market and investor base — I’ve developed a deep appreciation for how building a strong company with a strong economic engine and strong growth can be the best way to align many people to solve important problems.

Simply put: we don’t build services to make money; we make money to build better services.

And we think this is a good way to build something. These days I think more and more people want to use services from companies that believe in something beyond simply maximizing profits.

By focusing on our mission and building great services, we believe we will create the most value for our shareholders and partners over the long term — and this in turn will enable us to keep attracting the best people and building more great services. We don’t wake up in the morning with the primary goal of making money, but we understand that the best way to achieve our mission is to build a strong and valuable company.

This is how we think about our IPO as well. We’re going public for our employees and our investors. We made a commitment to them when we gave them equity that we’d work hard to make it worth a lot and make it liquid, and this IPO is fulfilling our commitment. As we become a public company, we’re making a similar commitment to our new investors and we will work just as hard to fulfill it.

The Hacker Way

As part of building a strong company, we work hard at making Facebook the best place for great people to have a big impact on the world and learn from other great people. We have cultivated a unique culture and management approach that we call the Hacker Way.

The word “hacker” has an unfairly negative connotation from being portrayed in the media as people who break into computers. In reality, hacking just means building something quickly or testing the boundaries of what can be done. Like most things, it can be used for good or bad, but the vast majority of hackers I’ve met tend to be idealistic people who want to have a positive impact on the world.

The Hacker Way is an approach to building that involves continuous improvement and iteration. Hackers believe that something can always be better, and that nothing is ever complete. They just have to go fix it — often in the face of people who say it’s impossible or are content with the status quo.

Hackers try to build the best services over the long term by quickly releasing and learning from smaller iterations rather than trying to get everything right all at once. To support this, we have built a testing framework that at any given time can try out thousands of versions of Facebook. We have the words “Done is better than perfect” painted on our walls to remind ourselves to always keep shipping.

Hacking is also an inherently hands-on and active discipline. Instead of debating for days whether a new idea is possible or what the best way to build something is, hackers would rather just prototype something and see what works. There’s a hacker mantra that you’ll hear a lot around Facebook offices: “Code wins arguments.”

Hacker culture is also extremely open and meritocratic. Hackers believe that the best idea and implementation should always win — not the person who is best at lobbying for an idea or the person who manages the most people.

To encourage this approach, every few months we have a hackathon, where everyone builds prototypes for new ideas they have. At the end, the whole team gets together and looks at everything that has been built. Many of our most successful products came out of hackathons, including Timeline, chat, video, our mobile development framework and some of our most important infrastructure like the HipHop compiler.

To make sure all our engineers share this approach, we require all new engineers — even managers whose primary job will not be to write code — to go through a program called Bootcamp where they learn our codebase, our tools and our approach. There are a lot of folks in the industry who manage engineers and don’t want to code themselves, but the type of hands-on people we’re looking for are willing and able to go through Bootcamp.

The examples above all relate to engineering, but we have distilled these principles into five core values for how we run Facebook:

Focus on Impact

If we want to have the biggest impact, the best way to do this is to make sure we always focus on solving the most important problems. It sounds simple, but we think most companies do this poorly and waste a lot of time. We expect everyone at Facebook to be good at finding the biggest problems to work on.

Move Fast

Moving fast enables us to build more things and learn faster. However, as most companies grow, they slow down too much because they’re more afraid of making mistakes than they are of losing opportunities by moving too slowly. We have a saying: “Move fast and break things.” The idea is that if you never break anything, you’re probably not moving fast enough.

Be Bold

Building great things means taking risks. This can be scary and prevents most companies from doing the bold things they should. However, in a world that’s changing so quickly, you’re guaranteed to fail if you don’t take any risks. We have another saying: “The riskiest thing is to take no risks.” We encourage everyone to make bold decisions, even if that means being wrong some of the time.

Be Open

We believe that a more open world is a better world because people with more information can make better decisions and have a greater impact. That goes for running our company as well. We work hard to make sure everyone at Facebook has access to as much information as possible about every part of the company so they can make the best decisions and have the greatest impact.

Build Social Value

Once again, Facebook exists to make the world more open and connected, and not just to build a company. We expect everyone at Facebook to focus every day on how to build real value for the world in everything they do.

Thanks for taking the time to read this letter. We believe that we have an opportunity to have an important impact on the world and build a lasting company in the process. I look forward to building something great together.

Nguồn: ABC News

Mặc dù mùa Euro rơi đúng vào lúc bận rộn, mình cũng đã có một thời gian thú vị, vừa chơi vừa làm. Với những trải nghiệm và quan sát mới.

1. Làm Product Owner (chơi) cho một Android App về bóng đá

Lịch Euro 2012 đã đạt qua mức 5000 lượt cài đặt, top 2 các ứng dụng nội địa về thể loại này. Đó là con số đáng để vui vẻ với một ứng dụng nhỏ xin ra lò chậm và ít đầu tư. Với sự nỗ lực của Tú, Hảo và Minh, ScrumLab đã có thể đưa lên Play Store để mọi người chơi cùng bóng đá.

Vài con số:

Lượt tải: 5 503 Rate: 4.5 Lần phát hành: 4(1.0, 1.0.3, 2.0, 2.1, 2.2) Số bugs:6

Bài học: time-to-market chậm có thể đánh mất đáng kể lợi thế  cạnh tranh, dev cần hiểu rõ ý nghĩa của deadline của Product Owner nếu không mọi nỗ lực của chính devs sẽ chỉ là công dã tràng.

2. Sự lên ngôi của team work và cross-functional

Tây Ban Nha vô đối! Đấy là thông điệp được nhắc đi nhắc lại từ trước, trong và sau giải. Kể cả đối thủ, bình luận viên, vua bóng đá, dân cá độ v.v. đều đồng loạt ca ngợi và thán phục TBN đến … bực bội vì nhàm chán. Chưa bao giờ thế giới lại … đồng thuận cao đến thế trong việc ca ngợi một đội bóng.

TBN là minh chứng hùng hồn cho cái gọi là TEAM hoàn hảo với

• Các cá nhân hoàn hảo (Individuals): tất cả các cầu thủ đều có thể chơi bóng xuất sắc. Họ ẵm phần lớn các giải cá nhân quan trọng nhất của vòng chung kết: vua phá lưới, cầu thủ xuất sắc nhất, hiệu số ghi bàn cao nhất, thủ môn để thủng lưới ít nhất v.v.
• Sự kết dính và phối hợp (interactions) hoàn hảo: lối chơi tiqui-taca thành thục nhuần nhuyễn tôn vinh các giá trị đồng đội, người ghi bàn có thể xuất phát từ bất kì vị trí nào, sự kết dính của một đội khiến đối thủ không biết phải kèm ai, phá ai và phá lối chơi kiểu gì
• Chiến thuật 4-6-0 giáng mạnh vào truyền thống bóng đá với vị trí chưa bao giờ bị nghi ngờ: Tiền đạo. Cuối cùng thì người ta phải công nhận là một đội bóng không tiền đạo vẫn cực mạnh và có thể chiến thắng. Theo Pep (BLV Quang Huy dẫn lời), Tiqui-Taca tức là “chỉ chơi trên  sân của đối thủ”, hóa ra sự phòng ngự lại có thể triển khai chủ yếu ở sân đối phương chứ không phải phần sân nhà, hóa ra tuyến phòng ngự tốt nhất là tiền vệ chứ không phải hậu vệ, hóa ra có tồn tại “một tiền đạo”-gồm-sáu-tiền-vệ với sức công phá mạnh hơn bất kì cá nhân tiền đạo xuất sắc nào. Các giá trị liên-chức-năng (cross-functional) và sức mạnh tập thể lên ngôi như chưa từng như thế!

Hóa ra, cross-functionality không chỉ có trong bóng bầu dục (Rugby), bóng đá cũng không phải ngoại lệ!

Ảnh: UEFA

3. Bug prevention hơn là finding-fixing bugs

TBN có thể đã chiến thắng do có khả năng luôn luôn kiểm soát phần lớn bóng trên sân. Khi bạn không có bóng, đồng nghĩa với việc bạn chẳng thể có cơ hội nào. Bóng phần lớn nằm trên sân đối phương nên việc Casillas (có thể xuất sắc thật) trở thành vua giữ thành cứ như thể hiển nhiên vậy, vì có phải làm gì mấy đâu (thực tế có thể hơi khác một tí). Có thể nói sức mạnh lớn nhất của Tiqui-Taca có thể nằm ở hai điểm đơn giản: giữ bóng nhiều để đỡ phải lo phòng vệ; và, có bóng nhiều thì khả năng có cơ hội cũng sẽ nhiều hơn. TBN thậm chí còn làm được nhiều hơn thế.

Những đêm không ngủ ngáp ngắn ngáp dài đã qua, cuộc sống đã trở lại bình thường; nhưng dư âm của kì Euro có thể sẽ còn lâu mới hết. Thế giới đang ủ mưu phá tiqui-taca. Còn mình thì lại scrumming tiếp 😀

Vậy là cuối cùng, Hanoi Scrum đã hoàn tất việc tổ chức Việt hóa tập tài liệu “Scrum and XP from the trenches” của Henrik Kniberg. Đây là một cuốn open book lạ đời vì nó không giống bất kì một cuốn sách nào khác: không reference, không lí thuyết suông, chỉ kể lại những gì chính Henrik đã làm thành công (hoặc va vấp). Cóp nhặt các tư liệu từ chính các “chiến hào” nên cuốn sách tràn đầy nhựa sống, đầy ắp dữ liệu và rất nhiều ý tưởng.

Cảm ơn các dịch giả, và đặc biệt cảm ơn TS. Hồ Tường Vinh (IFI) đã gợi ý dịch một tác phẩm thú vị cho cộng đồng Agile ở Việt Nam.

Cùng với Scrum Guide, Scrum Primer, “Scrum and XP from the trenches” tạo thành một bộ tư liệu tiếng Việt đầy đủ cả về lí thuyết và hướng dẫn thực hành cho các Scrum Team. Enjoy Scrumming 😉