Scrum: Đơn giản, nhưng không dễ

Bản dịch tiếng Việt của sách The Scrum Field Guide, tác giả Mitch Lacey. Được dịch bởi nhóm tình nguyện Agile Vietnam tháng 10–2015.

Nhóm dịch chương 1: Phan Duy Khánh, Nguyễn Vũ Hưng

Scrum rất dễ bị hiểu sai. Nó là một trong những khung làm việc dễ hiểu nhất nhưng cũng là một trong những khung làm việc khó nhất để thực hiện tốt. Tôi nói “thực hiện tốt” vì sự đơn giản vốn có của Scrum có thể khiến chúng ta nghĩ rằng nó rất dễ dàng để thực hiện, trong khi thực tế có thể mất nhiều năm để làm tốt điều đó. Scrum dường như đi ngược lại tất cả những gì chúng ta đã học được trong nhiều năm khi phát triển phần mềm theo Mô hình thác nước. Lý do là chúng ta cần thời gian để bỏ đi những thói quen xấu và điều chỉnh mình phù hợp với thực tế.

Trong phần phụ lục của cuốn sách này tôi giải thích về cơ chế của Scrum. Nếu bạn không quen thuộc với Scrum và hiểu cách Scrum hoạt động, tôi đề nghị hãy bắt đầu tại đây. Nếu bạn đã có một nền tảng về Scrum, bạn sẽ hiểu được cơ chế hoạt động của Scrum khá đơn giản. Vì vậy, trên thực tế, nhiều người nhầm tưởng họ “hiểu Scrum như lòng bàn tay” và tin rằng có thể ngay lập tức điều chỉnh Scrum để phù hợp hơn với thực trạng. Thường thì họ sẽ gặp vấn đề, và cần sự giúp đỡ, đó chính là mục tiêu của quyển sách này.

Câu chuyện dưới đây kể về tình huống mà mọi thứ trở nên khó khăn hơn rất nhiều khi thực hiện Scrum mà không có sự hiểu biết và nền tảng vững chắc về các điểm cốt lõi của Agile, những thứ làm cho Scrum đạt hiệu quả.

Câu Chuyện

Jeff là một huấn luyện viên Agile đang giúp đỡ nhóm thực thi Scrum trong một công ty phần mềm lớn. Một hôm, anh nhận được một email từ Suzy, quản lý cấp cao trong bộ phận của công ty anh: “Jeff, tôi cần anh giúp đỡ. Chúng tôi đã và đang làm Scrum được khoảng sáu tháng mà chất lượng mã nguồn của chúng tôi không được cải thiện theo cách tôi muốn. Tôi nghĩ chúng tôi cần anh để chia sẻ với chúng tôi về phương pháp lập trình đôi. Thứ hai tuần sau là bắt đầu tuần lên kế hoạch của chúng tôi. Anh có thể đến chứ?”

Jeff chỉnh lại tư thế ngồi. Nói về phương pháp lập trình đôi tương đối đơn giản. Anh ta có thể đi cùng Julie, bạn anh ta, vốn là một lập trình viên tài năng và là một người thực hành thành thạo Agile. Hoàn toàn không có vấn đề gì. Tuy nhiên, có mấy từ trong email liên tục lặp lại trong đầu Jeff. Tuần lên kế hoạch? Scrum đặt ra hai cuộc họp trong một Sprint và mỗi cuộc họp không được quá bốn giờ. Và nhóm này thực hiện đến một tuần? Một cái gì đó đã nói cho anh ta biết rằng họ sẽ có nhiều việc để làm hơn là chỉ nói về lập trình đôi. Tới ngày thứ hai hôm đó chắc hẳn sẽ rất thú vị.

Ngày thứ hai, Jeff và Julie đến nơi và thấy Suzy cùng nhóm tám người của cô đã chờ sẵn trong phòng họp. Sau khi Suzy giới thiệu ngắn gọn, Jeff và Julie giới thiệu bản thân và bắt đầu hỏi về chất lượng mã nguồn mà Suzy đã đề cập.

Trưởng nhóm kiểm thử, Mike bắt đầu trước “Lý do mà mã nguồn của chúng tôi chất lượng kém là vì chúng tôi không có thời gian để kiểm tra. Các lập trình viên viết mã nguồn tới tận ngày cuối cùng trong thời gian Sprint bốn tuần. Lập trình và kiểm thử trong Sprint vốn nên được thực hiện cùng lúc. Tuy nhiên việc kiểm thử của chúng tôi được thực hiện ngay cuối Sprint hoặc phải chuyển qua Sprint tích hợp.”

Julie cắt ngang: “Xin lỗi, Mike, anh đang nói đến Sprint tích hợp?” Cô nhìn Suzy, người đang gật đầu.

“Ồ. Tôi đã không giải thích về những cải tiến à?” Suzy nói. “Hãy xem, chúng tôi biết rằng Scrum đòi hỏi phát hành sau mỗi bốn tuần, nhưng điều đó là không thể đối với tính chất công việc mà chúng tôi đang làm. Ý tôi là trước khi thử Scrum, chúng tôi đã cố gắng để bàn giao hàng quý và đó thực sự là một thảm họa! Vì vậy những điều chúng tôi đã làm là thay đổi Scrum để phù hợp với quy trình và thực trạng của chúng tôi.” Suzy đi đến tấm bảng và bắt đầu viết.

“Đầu tiên, chúng tôi có tuần lên kế hoạch cho Sprint, sau đó là bốn tuần Sprint thực tế, tại đó các lập trình viên viết mã nguồn và các kiểm thử viên kiểm thử nhiều trường hợp. Sau đó, chúng tôi làm công việc tích hợp của mình, tiếp đến chúng tôi triển khai. Tất nhiên, tôi cũng thường thêm vào một tuần dự trù cho những thứ phát sinh.” Suzy nói.

Khi Suzy vừa nói xong, cô ấy cũng vừa viết kín chiếc bảng trắng.

·Tuần 1: Lập kế hoạch

·Tuần 2–5: Lập trình viên lập trình: Kiểm thử viên viết những tình huống và thực hiện kiểm tra sơ bộ

·Tuần 6–7: Tích hợp

·Tuần 8: Triển khai lên trang web thật

.Tuần 9: Tuần dự trù, nếu cần

Jeff và Julie nhìn nhau, rồi cả hai nhìn Suzy. Những thành viên còn lại của nhóm nhìn có vẻ ngao ngán. Jeff đi vào vấn đề trọng tâm, “Suzy, kế hoạch Sprint của bạn thực sự dài tám hay chín tuần sao?”

“Đúng vậy,” Suzy nói. “Có thể anh sẽ ngạc nhiên. Tôi biết nó không phải là cách hay nhưng nó phù hợp với chúng tôi. Tôi nghĩ chúng tôi có thể cần thêm một tuần nữa, bạn biết đấy, để viết các thông số kỹ thuật và các kế hoạch kiểm thử. Chúng tôi đang gặp khó khăn với việc làm cho chúng ăn khớp với nhau. Hiện tại, chúng tôi làm điều đó trong tuần dự trù, nhưng tôi thực sự ghét cái tiến độ chậm chạp như thế này.”

“Được, chúng ta sẽ quay lại chủ đề này,” Julie nói. Cô nhìn Jeff, anh giơ tay lên như thể muốn nói gì đó, “Cô tính sẽ làm gì?” Julie tiếp tục, “Mike, anh nói rằng anh không có thời gian để kiểm định lại.”

Wyatt nói lớn trước khi Mike kịp trả lời, “Đừng nghe Mike. Họ có nhiều thời gian để kiểm tra. Chỉ có chúng tôi mới là những người không bao giờ có đủ thời gian. Chúng tôi cố gắng lập trình được càng nhiều càng tốt mỗi Sprint. Vậy nếu chúng tôi dành thời gian cả bốn tuần cho việc lập trình thì sao? Đó là tất cả những gì đang diễn ra.” Wyatt nhìn Mike và tiếp tục, “Kể từ khi chúng ta bắt đầu sử dụng Scrum tất cả những gì anh và các kiểm thử viên khác làm là phàn nàn rằng không có thời gian. Có lẽ Scrum là vấn đề.”

Jeff và Julie liếc nhìn nhau.

Suzy xen vào thất vọng. Và tôi có thể thấy rằng Wyatt và Mike cũng đang thất vọng. Tôi có thể làm rõ điều này một chút với cả nhóm không? Xem thử tôi có thể tìm được gốc rễ của vấn đề hay không?” Suzy gật đầu nhiệt tình.

Jeff bắt đầu với câu hỏi đánh giá tiêu chuẩn đầu tiên của mình. “Được rồi. Cả Scrum và Extreme Programming (XP) đều yêu cầu cần có các cập nhật hà, “Cả nhóm, thôi nào, chúng ta không tới đây để phàn nàn về Scrum. Chúng ta ở đây để nâng cao chất lượng mã nguồn.” Cô dừng lại và hít một hơi thật sâu. “Tôi đã nói điều này trong sáu tháng,” cô nói với Jeff và Julie với một ánh nhìn kêu gọi hỗ trợ.

Jeff gật đầu. “Tôi thấy rằng bạn đang ng ngày. Trong Scrum là những cuộc họp về Scrum hàng ngày. Bạn đánh giá các cuộc họp Scrum hàng ngày như thế nào ?” Jeff hỏi cả nhóm.

Mike cười. “Cuộc họp hàng ngày? Bạn đang giỡn hả? Chúng tôi không có thời gian cho những thứ đó. Chúng tôi gặp nhau hai lần một tuần trong một giờ. Chỉ vậy thôi cũng đủ tồi tệ rồi.”

“OK, Mike. Kể cho tôi nghe về các cuộc họp đi.” Jeff nói.

“Vâng, phần đầu trong mỗi cuộc họp đều tương tự nhau. Các lập trình viên cho biết họ đang làm các nhiệm vụ hiện tại, và chúng tôi nói về việc xây dựng các test case. Cập nhật những nội dung, tin tức quan trọng. Sau đó, chúng tôi lướt qua các danh sách và phân tích nguyên nhân gốc rễ ví dụ “lỗi này là theo thiết kế” và “chúng ta sẽ sửa trong các Sprint tiếp theo”. Tất nhiên, chúng tôi không bao giờ sửa chúng. Đó chỉ là một mớ bòng bong.” Mike nói.

Khi thấy Suzy trở nên tức giận, Jeff đã cho cô cơ hội để lên tiếng.

“Cảm ơn, Mike. Suzy, cô nghĩ sao? ?” Jeff hỏi.

“Mike đã đúng ở một điểm. Các cuộc họp hàng ngày sẽ không thích hợp với chúng tôi. Chúng tôi phải tiến hành cuộc họp trong những ngày khác. Lịch trình của tôi quá bận rộn để họp hằng ngày, và một số thành viên còn đang bận các dự án khác. Tôi biết cách làm này không phải là một điều lý tưởng, nhưng đó là những gì chúng tôi cần làm. Điều làm tôi khó chịu là nhóm và tôi không thể thống nhất được với nhau về việc họp hai lần một tuần, vì họ nghĩ rằng hai lần là quá nhiều. Bạn nghe cách Mike nói chuyện vừa rồi đấy. Tất cả họ đều phàn nàn về các cuộc họp, lịch trình, và thiếu thời gian! Nhưng tôi lại chẳng thể làm cách nào khác vì thực tế là cấp quản lý thúc giục chúng tôi bàn giao sản phẩm thường xuyên hơn. Thêm vào đó, như vẫn nói với họ, đó là dự án của tôi. Tôi lên kế hoạch, và tôi thiết lập đội hình. Nói với họ, Jeff. Tôi là một ScrumMaster. Họ cần phải làm theo những gì tôi nói, phải không?”, Suzy yêu cầu.

Jeff nhún vai không hứa hẹn và tặc lưỡi. Anh nhận ra rằng rất ít người hiểu về Scrum. Anh liếc nhìn Julie ngụ ý với cô rằng họ không hiểu về Scrum. Julie khẽ gật đầu đồng ý. Jeff tiếp tục phần đánh giá.

“OK, tôi hiểu rồi. Hãy dừng lại một chút và tập trung vào vấn đề chính của chúng ta ở đây. Dường như có một vấn đề tiềm ẩn là những cuộc họp hàng ngày không thường xuyên, không hiệu quả, và quá dài. Chúng ta có thể khắc phục điều đó. Rồi, bây giờ hãy tạm đặt vấn đề này qua một bên và hãy tư duy ở cấp độ cao hơn. Nói cho tôi biết điều gì đưa bạn đến với Sprint tám tuần.”

Wyatt thẳng thắn nói. “Tôi đã làm việc ở đây hơn mười năm và tin tôi đi, tôi thường thấy tất cả các xu hướng ngắn hạn. Chúng đến và đi. Nhưng lần này tôi thực sự tin tưởng rằng Scrum có thể sẽ tạo ra sự khác biệt. Thật là một câu chuyện khôi hài! Toàn bộ điều này bắt đầu bởi vì ban quản lý đã thúc giục chúng tôi để phát hành nhanh hơn. Chúng tôi đã chuyển được thời gian phát hành từ hàng năm xuống hàng quý — để tôi nói bạn nghe, việc này quả là khó khăn nhưng chúng tôi vẫn đang tiến hành. Nhưng điều đó vẫn chưa đủ nhanh đối với ban quản lý, đúng không?” Wyatt dừng lại và nhìn xung quanh phòng để xác nhận.

Ông tiếp tục: “Vì vậy, Suzy và tôi đã ngồi lại vào giờ ăn trưa và có cuộc gặp với một đồng nghiệp của tôi, một người ở bộ phận khác. Anh ta nói với chúng tôi nhóm của anh đã sử dụng Scrum và làm thế nào họ phát hành sau mỗi bốn tuần và giúp nhóm vui vẻ ra sao. Anh ta cho biết chất lượng của họ đã vượt qua mức mong đợi. Đội ngũ quản lý đã chưa từng được vui vẻ như vậy trong nhiều năm trời và khách hàng thực sự rất hài lòng. Bạn biết không, anh chàng này rất giống tôi, một người luôn hoài nghi. Vì vậy, tôi nghĩ, nếu anh ta nói nó hoạt động thì nó sẽ hoạt động. Suzy và tôi đã dành cả buổi chiều với anh ta để học hỏi mọi thứ về Scrum. Tưởng chừng đơn giản, nhưng lại có không ít vấn đề. Đầu tiên đó là những cuộc họp hàng ngày. Ai mà họp được hàng ngày cơ chứ? Họ chỉ nên gặp nhau hai lần một tuần để sửa những phần đơn giản. Sau đó, rõ ràng một chu kỳ bốn tuần không phù hợp với chúng tôi — sau tất cả, chúng tôi chỉ có thể thực hiện một chu kỳ theo quý, vì vậy chúng tôi quyết định tăng gấp đôi nó lên tám tuần. Từ đó, chúng tôi đã phá vỡ quy trình làm việc của chúng tôi xuống thành tám tuần. Nó chỉ là vấn đề thu hẹp lại tất cả mọi thứ xuống. Sau khi tất cả, Scrum chỉ là một mô hình phát triển tăng dần khác”.

Jeff và Julie lại liếc nhìn nhau.

Wyatt tiếp tục, “Tôi hiểu ý các bạn. Nhưng tôi muốn nói rằng, hơn ai hết chúng tôi hiểu nhóm và sản phẩm của mình. Scrum nguyên bản không thể nào phù hợp với chúng tôi. Vì vậy, như những nhóm phần mềm khác, chúng tôi đã chỉnh nó cho phù hợp với nhu cầu của mình. Để nó phù hợp với cách vận hành trong quá khứ.”

“Phải,” Suzy khẳng định. “Theo tôi Scrum chỉ là một cách để các nhà quản lý dự án quản lý công việc, chỉ ngắn hơn thôi.”

Jeff ngồi xuống . Các câu hỏi đánh giá mà anh đã chuẩn bị không được thiết kế cho một tình huống như thế này. Anh không biết phải nói gì vào thời điểm này. Julie góp ý, “Bạn có thống nhất về định nghĩa hoàn thành công việc không, Wyatt?”

“Chắc chắn rồi, chúng tôi có chứ. Chúng tôi có cuộc họp đánh giá thiết kế sau tuần đầu tiên. Rồi vào cuối tuần thứ năm, chúng tôi có mốc phải hoàn thành lập trình. Vào cuối quá trình tích hợp, chúng tôi kiểm thử và quá trình tích hợp hoàn thành. Khi chúng tôi đạt được các mốc quan trọng, chúng tôi phát hành đến các trang web thực. Điều đó không khó hiểu tí nào,” Wyatt nói.

“Không, nó đơn giản. Tôi hiểu,” Julie trấn an. “Vậy là, cả nhóm, Wyatt, Mike, và Suzy đã giải thích quy trình của các bạn. Theo tôi hiểu, nhóm các bạn có họp hàng ngày hai lần một tuần, theo Sprint tám hoặc chín tuần, và có mốc kiểm tra tại một số giai đoạn quan trọng để biết về những gì nhóm đã làm. Nó chạy như thế nào? Mọi người vui chứ? Chất lượng mã nguồn có tốt hơn nhiều không?” Julie hỏi.

“Ừm, cũng không tệ”, Wyatt nói.

“Không tệ?” Suzy nói. “Kinh khủng mới đúng chứ.”

“Vâng, nó không phải là lỗi của chúng tôi làm nó khủng khiếp! Chúng tôi đã cố gắng kiểm tra, nhưng, như tôi đã nói, vấn đề là không có thời gian!” Mike như hét lên. Mọi người còn lại của nhóm nhìn chằm chằm vào bàn. Họ không tham gia vào cuộc chiến này.

“Tôi không đổ lỗi cho bạn, Mike, mặc dù tôi có thể làm điều đó. Vấn đề thực sự ở đây là Scrum”, Wyatt nói. “Đó là một hệ thống ngu ngốc và hoạt động không hiệu quả.”

“Tôi nói lại lần nữa là không phải do điều đó,” Suzy nói. “Đã bao nhiêu lần chúng ta phải tranh cãi về điều này rồi? Chúng ta nói về nó ở mỗi Retrospective.”

“Retrospective?” Wyatt xen vào. “Ý cô là tên cuộc họp khỉ gió kéo dài trong hai ngày? Retrospectives không thay đổi bất cứ điều gì. Scrum không thay đổi bất cứ điều gì. Tôi nói lại lần nữa. Nó chỉ làm thay đổi một điều — nó làm cho tất cả chúng ta đau khổ.”

“Wyatt, đây cũng là ý tưởng của bạn. Tại sao bạn ủng hộ làm Scrum trong khi tất cả các bạn đã đi làm là phá hoại nó?” Suzy nóng nảy hỏi.

Jeff đứng dậy. Đây là thời gian để dừng đặt câu hỏi và nhóm này phải đối mặt với sự thật.

“Hãy nhìn xem, đó không phải lỗi của bất cứ ai và nó cũng không phải là lỗi của Scrum. Đối với tôi, và tôi chắc chắn rằng Julie cũng đồng ý, có vẻ như bạn đang không thực sự làm Scrum. Những gì bạn đang làm là những gì bạn thường thực hiện, chỉ ép nó vào một chu kỳ tám tuần và gọi nó là Scrum.”

Wyatt và Suzy đang trong tư thế sẵn sàng tranh luận, nhưng Julie đưa tay lên để ngăn lại. “Hãy để tôi hỏi một câu hỏi. Điều này là cho toàn nhóm. Wyatt, Suzy, Mike, xin vui lòng không trả lời.” Julie nhìn xuống bàn ở mỗi thành viên trong nhóm trước khi tiếp tục, “Cách làm việc mới làm cho cuộc sống của các bạn khốn khổ hay là nó vốn đã luôn khốn khổ như thế này, nhưng chỉ là không rõ ràng?” Julie hỏi.

Mọi người nhìn xuống, cúi đầu suy nghĩ cẩn trọng.

“Trước đó nó cũng không mấy dễ chịu”, một giọng nói từ phía sau nói.

“Ừ”, một thành viên trong nhóm cho biết. “Tôi chỉ không biết ngày trước công việc khó chịu chừng nào thôi.”

Một sự im lặng bao trùm cả khán phòng, dường như quá trình tự nhận thức bắt đầu lóe lên trong họ.

Wyatt thở dài và nói, “Anh nói đúng. Không có bất kỳ điều gì tốt hơn trước; chỉ là một thứ gì đó không rõ ràng. Chúng tôi chỉ cảm thấy đau đớn mỗi quý. Bây giờ chúng tôi cảm thấy nó mỗi 8 tuần.”

Mike chen vào, “Bạn biết đấy, nhìn lại vào sáu tháng vừa qua, chúng tôi đã phát hiện ra rất nhiều thứ mà chúng tôi có thể và cần phải sửa, nhưng chúng tôi đã không làm bất cứ điều gì. Hoàn toàn không.”

Suzy ngắt lời.

“Mọi người, tôi thực sự mệt mỏi. Chúng ta có thể trì hoãn việc này cho một vài ngày, tập hợp lại vào tuần tới không?” Cô hỏi.

Cả nhóm gật đầu. Họ cũng mệt mỏi rồi.

Suzy rời buổi họp và đã hiểu ra những điều tồi tệ. Cô đã trải qua những ngày cuối tuần và các buổi đầu của tuần tiếp theo suy nghĩ về làm thế nào để mọi thứ tiến triển. Cô mời Jeff và Julie quay lại trong một cuộc họp khác, cô hy vọng sẽ thiết lập một phong thái mới cho nhóm.

“Xin lỗi, tất cả mọi người”, cô nói mở đầu cuộc họp. “Tôi biết mọi việc vẫn khó khăn, nhưng tôi không biết nó tệ đến vậy. Ban đầu tôi nhờ Jeff và Julie giúp chúng ta lập trình đôi bởi vì tôi nghĩ rằng sẽ khắc phục vấn đề chất lượng của chúng ta. Rõ ràng tôi đã mù quáng với nhu cầu thực tế của chúng ta, tôi xin lỗi vì điều đó. Chúng ta đã thực hiện điều này sai hoàn toàn. Không phải Scrum thất bại; mà chúng ta đã thất bại trong việc sử dụng Scrum. Tôi mong tất cả chúng ta có thể bắt đầu lại. Tôi nghĩ Jeff và Julie có thể giúp chúng ta làm điều đó,” Suzy nói.

Wyatt gật đầu và nhìn cả nhóm, “Tôi biết tôi có thể là một kẻ ngớ ngẩn. Tôi đã ở đây lâu như vậy nên đôi khi tôi nghĩ rằng tôi sở hữu nơi này, nhưng không phải thế. Tôi biết tôi có thể làm được tốt hơn. Tôi sẽ ngừng than phiền và coi nó như một cơ hội thực sự để làm việc nghiêm túc, nhưng chỉ với một điều kiện.”

“Đó là gì?” Jeff hỏi.

“Đó là chúng ta làm vì thực tế”, Wyatt nói. “Không tự hiệu chỉnh nữa. Và chúng ta cần một huấn luyện viên, một người có thể chỉ cho chúng ta phải làm gì. Điều này đã không dễ dàng như vẻ bề ngoài của nó.”

Mike nhìn lên. “Tôi cũng có một điều kiện. Chúng ta giải quyết các vấn đề. Thực sự khắc phục chúng, không được đổ lỗi cho nhau.” Anh đưa tay ra với Wyatt. “Hãy xem nghĩ chúng ta có thể làm điều đó không?”

Wyatt nhìn Mike, nhìn tay mình, và sau đó bắt tay với Mike, “Tôi nghĩ chúng ta đã sẵn sàng cho những thách thức, nếu vẫn có sự hỗ trợ của Jeff, vậy đó,” ông chế giễu, nhướn mày nhìn Jeff.

Mọi người đều cười, tiếng cười đầu tiên của cả nhóm trong một khoảng thời gian gần đây. Đây là một khởi đầu tốt. Họ đứng dậy quanh bàn, hào hứng cam kết với nhau để thực hiện Scrum một lần nữa, và lần này là thật. Jeff và Julie rời buổi họp một lát sau đó, cảm giác như họ đã làm được khá nhiều nhưng họ biết rằng họ còn nhiều thứ phải làm.

“Bây giờ anh đang làm gì vậy, Jeff?” Julie hỏi.

“Điều đầu tiên tôi sẽ làm là dạy cho họ Scrum là gì — giá trị của Scrum, khung làm việc, sự đổi thay trong nhận thức, điều mà họ sẽ cần phải trải qua,” Jeff nói.

“Đừng quên chỉ cho họ thấy cách Scrum quản lý rủi ro và giúp xác định các vấn đề như thế nào,” Julie nói.

“Chính xác. Tôi sẽ bắt đầu với những điều cơ bản và làm việc theo cách của mình vượt qua những trở ngại khi chúng xuất hiện. Đây sẽ là một cuộc chiến, nhưng họ có thể làm điều đó. Thất bại là mẹ thành công mà, phải không?”

Scrum

Scrum nhìn thì có vẻ rất căn bản. Nhưng điều mà rất nhiều người không hiểu là để làm nó tốt, bạn phải thay đổi cách phát triển phần mềm từ gốc rễ. Và đó không phải là điều dễ dàng. Bạn sẽ phải chiến đấu. Bạn sẽ gặp phải những trở ngại. Nhóm trong câu chuyện của chúng ta nhận ra điều đó một cách khó khăn, và nếu bạn đã chọn cuốn sách này, bạn cũng sẽ có thể phát hiện ra điều đó. Để hiểu lý do tại sao một thứ đơn giản như vậy có thể trở nên rất khó khăn, chúng ta hãy xem xét kỹ hơn về Scrum.

Scrum là gì?

Jeopardy luôn là một trong những chương trình truyền hình yêu thích của tôi. Tôi vẫn mong muốn rằng các phiên bản phát triển phần mềm của chúng tôi có các chuyên mục như các Phương pháp và các Khung làm việc, nguyên nhân thường gặp của phần mềm thất bại, kỹ sư phần mềm nổi tiếng, hoặc các trích dẫn ngớ ngẩn từ những người thông minh. Tôi có thể nghĩ ra hàng tá câu hỏi cho mỗi thể loại đó, chẳng hạn như, “Ai là người được cho là đã nói: Hãy hòa nhã với những mà bạn cho là dở hơi. Không ai biết trước tương lai và biết đâu một ngày nào đó bạn phải làm việc cho một kẻ như vậy.” Tôi hình dung ra câu hỏi dưới Phương pháp và Khung làm việc sẽ như thế nào, “Được đặt tên theo một thuật ngữ Rugby, đây là 1 khung làm việc sẽ phát hành phần mềm mỗi 2–4 tuần.” Một câu trả lời phổ biến mà nhiều khả năng sẽ được chấp nhận, dưới hình thức của một câu hỏi tất nhiên đó là “Scum… là gì?”.

Vậy, Scrum thực sự là gì? Scrum không phải là một phương pháp hay tập hợp các thực hành kỹ thuật. Thay vào đó, Scrum là một khung làm việc tinh gọn được thiết kế để quản lý phần mềm và phát triển sản phẩm. Ken Schwaber và Jeff Sutherland [Schwaber 01] mô tả về Scrum như sau:

Scrum (danh từ): Một khung làm việc trong đó người ta có thể phát hiện những vấn đề tồn đọng trong khi vẫn đem lại những giá trị lớn nhất một cách hiệu quả và sáng tạo. Scrum mang các đặc tính:

• Tinh gọn,

• Đơn giản dễ hiểu,

• Cực kì khó để thành thạo.

Scrum là một khung làm việc đã được sử dụng để quản lý việc phát triển sản phẩm phức tạp từ những năm 90. Scrum không phải là một quy trình hoặc một kỹ thuật để phát triển sản phẩm; mà hơn thế, Scrum là một khung làm việc mà trong đó bạn có thể ứng dụng nhiều quy trình và kỹ thuật. Scrum làm rõ mức độ hiệu quả tương đối của việc quản lý sản phẩm của bạn cũng như phát triển những ứng dụng mà bạn có thể cải thiện.

Scrum dựa trên một vòng lặp tăng tiến được gọi là Sprint. Mỗi Sprint bắt đầu với một một cuộc họp Kế Hoạch Sprint và kết thúc với việc cho ra một sản phẩm hoàn thiện. Đặc trưng của Scrum là độ phản hồi thông tin cao và sự minh bạch, cả bên trong nhóm và bên ngoài nhóm làm việc. Chu kỳ ngắn và cộng tác tự nhiên làm nó lý tưởng cho các dự án có tính thay đổi nhanh chóng và/hoặc có khả năng đổi yêu cầu rất khẩn cấp.

Scrum được xây dựng trên năm giá trị cốt lõi, ba vai trò khác nhau, ba tạo tác, và ba (hoặc bốn) cuộc họp. Chi tiết về các cơ chế của Scrum có thể tham khảo tại Phụ lục Appendix A, “Khung làm việc Scrum.”

Triển khai Scrum

Trong khi Scrum có thể xuất hiện ở dạng đơn giản để thực hiện, nó đồng thời cũng thực sự là một thách thức. Tại sao? Bởi vì thực hiện nó đòi hỏi nhiều hơn là chỉ đưa các cơ chế đúng vào vị trí và sau đó nhấn nút. Để triển khai Scrum đúng cách thì cần Nhóm sẵn sàng thay đổi sau:

• Phát triển và hiểu đúng những giá trị cốt lõi của Scrum;
• Sẵn sàng thay đổi tư duy;
• Lên kế hoạch cho sự thay đổi và thực thi nó;
• Xử lý tình huống khi có sự cố;
• Tích hợp các kỹ thuật phát triển phần mềm linh hoạt.

Scrum được xây dựng dựa trên các giá trị

Việc sử dụng bất cứ khung làm việc có giá trị nào đều được xây dựng trên các nguyên tắc và giá trị. Ví dụ như các kỹ thuật nguyên bản gốc của Agile — XP, Scrum, DSDM, Crystal, và FDD — cũng như là Kanban và Lean, đều đặt ra các giá trị cốt lõi cho riêng chúng. Những giá trị này hướng dẫn chúng ta, cung cấp sự rõ ràng trong thời gian mơ hồ, và, quan trọng nhất, giúp chúng ta hiểu lý do tại sao chúng ta làm những việc đó. Như bạn đọc câu chuyện ở trên, nhóm này đã thực hiện theo cách vận hành của Scrum, nhưng họ đã không hiểu lý do tại sao cần làm. Những gì họ thiếu là một sự hiểu biết rõ ràng về các giá trị đằng sau khuôn khổ Scrum: tập trung (Focus), tôn trọng (Respect), cam kết (Commitment), sự can đảm (Courage), sẵn sàng đón nhận thay đổi (Openness) [Schwaber 02].

Tập trung (Focus)

“Tập trung” nghĩa là hướng các hoạt động vào một việc, để ý trực tiếp vào điều gì đó. Với Scrum, cả nhóm phải có sự tập trung nếu muốn thực hiện được mọi công việc thuộc loại cần hoàn thành để chuyển giao những chức năng có tiềm năng được phát hành. Tập trung (Focus) có nghĩa là chỉ làm một dự án tại một thời điểm. Nó có thể có nghĩa là cống hiến cho “thời gian nhóm”, nơi mà toàn bộ nhóm không dùng email, tin nhắn, điện thoại di động, và các cuộc họp. Tính Tập trung được làm bất cứ điều gì nó cần để cho phép các nhóm để tập trung vào việc phân phối tay cho toàn bộ độ dài của bất kỳ Sprint nhất định.

Tôn trọng (Respect)

Chúng ta biết rằng sự tôn trọng không có sẵn mà cần nỗ lực mới có thể đạt được. Với Scrum, điều này đặc biệt đúng. Bạn có thể tôn trọng đồng đội của mình hoặc không, nhưng hệ lụy tương đương là dự án có thể thực hiện hoặc bị hủy hoại. Một nhóm Scrum có hiệu xuất cao có đủ tin tưởng và biết chấp nhận nhau mới có thể vượt qua những trở ngại. Họ có niềm tin rằng khi một thành viên trong nhóm gắn kết với nhiệm vụ của mình, thì những người khác sẽ làm theo. Không có sự phân biệt ‘chúng tôi’ với ‘họ’ trong một nhóm Scrum. Trong câu chuyện ở đầu chương này, kiểm thử viên và lập trình viên rõ ràng đã có mâu thuẫn và có ít sự tôn trọng dành cho nhau. Cả nhóm đã may mắn, dù sao đi nữa, trong trường hợp đó mọi người vẫn chưa mất tất cả sự tôn trọng dành cho nhau, điều đó được chứng minh bằng việc họ lại tụ họp cùng với nhau trong phần kết.

Cam kết (Commitment)

Một cam kết là một sự đảm bảo hay lời hứa, một nghĩa vụ phát hành. Không nên xem nhẹ các cam kết, nên cân nhắc kỹ càng nhiều thông tin càng tốt trước khi cam kết một điều gì đó. Thường thì cả nhóm sẽ làm một cam kết với tổ chức và giữa các thành viên với nhau trong mỗi cuộc họp lập kế hoạch Sprint. Vào cuối của kế hoạch Sprint, mỗi thành viên trong nhóm phải có cùng một mức độ hiểu biết về những gì nhóm của anh ta cam kết thực hiện trong thời gian Sprint đó.

Sự can đảm (Courage)

Can đảm là khả năng đối mặt với khó khăn bất chấp mọi nỗi sợ hãi. Giảm bớt những nỗi sợ hãi là một trong những cách tốt nhất của nhóm và các tổ chức có thể giúp các thành viên can đảm hơn. Một nhóm thể hiện được sự hiểu biết về các mặt trong cuộc thảo luận thẳng thắn và của tổ chức đã được chứng minh rằng nhóm đó sẽ tiếp nhận những tin xấu một cách khách quan giúp cho các cá nhân đủ can đảm để nói ra suy nghĩ của mình. Hãy nhớ rằng, khi các nhóm thiếu can đảm để làm những gì họ cảm thấy là đúng, họ sẽ không thể làm đúng.

Đón nhận thay đổi (Openness)

Sự sẵng sàng đón nhận thay đổi cho phép chúng ta tiếp nhận những ý tưởng mới. Không nơi đâu có một nhóm tư duy mở rõ ràng hơn trong Sprint Retrospectives. Sẵn sàng tiếp nhận những ý tưởng mới, nhận thức và cách tư duy giúp chúng ta phát triển thành một tổ chức không ngừng học hỏi và một nhóm làm việc có hiệu suất cao.

Scrum yêu cầu sự thay đổi từ Tư duy

Albert Einstein nói: “Chúng ta không thể giải quyết vấn đề bằng cách sử dụng cùng một loại suy nghĩ mà ta dùng để tạo ra chúng.” Một trong những trở ngại lớn nhất đối với việc áp dụng thành công Scrum, hoặc bất kỳ phương pháp linh hoạt nào cho vấn đề đó, là việc không có khả năng thay đổi tư duy, không có khả năng sử dụng tư duy mới để giải quyết vấn đề. Kết quả là, Scrum và tất cả các ứng dụng phần mềm linh hoạt đòi hỏi một mức độ nhất định một tư duy mở, ít nhất là trong 3–6 tháng đầu tiên. Lúc tôi làm dự án Scrum đầu tiên, tôi mất gần một năm sau đó mới thực sự hiểu về Scrum.

Trong năm đó, tôi biết được rằng Scrum là một công cụ mạnh mẽ nhưng cũng tiềm ẩn nguy hiểm. Bạn đã xem chương trình TV Home Improvement bao giờ chưa? Nhân vật chính, Tim “Thợ sửa” Taylor, người luôn gặp vào rắc rối với công cụ mới khi anh không thực hiện những bước chuẩn bị để đảm bảo an toàn, anh ta bỏ qua những bước đó và sử dụng các thiết bị theo cách không giống ai, hoặc là ôm đồm quá nhiều công việc. Scrum cũng giống như vậy. Nếu không được điều hành theo hướng hoảng đặc biệt là lúc đầu, Scrum có thể làm cho dự án của bạn rất nhanh rơi vào khủng hoảng. Rất nhiều nhóm có những hiểu biết sơ sài về Scrum và tưởng rằng họ đã hiểu; tình huống của họ khác; và họ đã hiểu rõ việc này như lòng bàn tay.

Lời khuyên của tôi là: Tìm hiểu kỹ Scrum trước khi bạn quyết định hiệu chỉnh nó. Sử dụng nó đúng cách, “suy nghĩ sáng tạo vượt ra khỏi các giới hạn”, nếu bạn muốn. Hãy dành thời gian học tập về nó càng nhiều càng tốt. Dành một số ngăn trong đầu của bạn để cho kiến thức này phát triển, để kiến thức ngấm dần như khi ta pha một tách trà. Đối với độc giả về phần mềm của tôi, tôi hay nói rằng, hãy dành một bộ nhớ trống được định vị trong não của bạn rồi cho kiến thức này vào trong đó. Không — tôi nhắc lại, không — cố gắng kết hợp Scrum với các công cụ khác mà bạn quen dùng khi chưa cần thiết; bây giờ chưa phải lúc. Chỉ khi bạn đã làm chủ được một công cụ khi đó bạn có thể học cách sử dụng thành công những cái khác. Hơn hết, có được sức mạnh và kỷ luật để nắm lấy cơ hội, thậm chí (và đặc biệt) khi đầy khó khăn và thử thách. Bạn sẽ ngạc nhiên rằng bạn cần thay đổi Scrum rất ít và bạn cũng sẽ sớm nhận ra rằng tư duy của mình đã đổi mới như thế nào. Bạn có thể nghĩ rằng điều này đi ngược lại với các giá trị đầu tiên của Tuyên Ngôn Agile, tính cá nhân và sự tương tác hơn là quy trình và công cụ. Ngược lại, nó mang tính cá nhân và tương tác cho phép bạn học cách sử dụng Scrum (hoặc áp dụng bất kỳ hệ thống linh hoạt nào khác), tiếp xúc nhiều với nó sẽ giúp bạn có những quyết định sáng suốt.

Scrum hướng tới việc đến đích một cách nhanh nhất, không phải theo một lộ trình đã đặt trước

Lộ trình dài nhất của một dự án được biết đến như là một đường găng, hoặc đường giới hạn, hay đơn giản hơn là lộ trình. Chúng ta xây dựng một kế hoạch xung quanh một đường găng và theo sát kế hoạch đó, từ điểm A tới điểm B. Trên lộ trình này, các tranh cãi và các vấn đề bề nổi như: tranh cãi giữa các bên liên quan khi họ không biết chính xác những gì họ muốn lúc xây dựng kế hoạch, mục tiêu kinh doanh thay đổi cùng với sự thay đổi của sản phẩm trong suốt vòng đời của nó, có dự án ứng phó với các lực lượng bên trong và bên ngoài, chẳng hạn như sự phát hành của đối thủ cạnh tranh, và các chi tiết khác mà thường gặp phải trong quá trình phát triển. Đây là tất cả những điều xảy ra trên hầu hết các dự án; không chỉ riêng đối với các dự án về phần mềm.

Với phương pháp lập kế hoạch truyền thống, khi có những vấn đề phát sinh, chúng ta vẫn buộc phải đi từ A đến B, hi sinh dọc theo lộ trình đó — hi sinh chất lượng, chức năng, và mất dần sự hài lòng của khách hàng. Cuối cùng khi chúng ta đến điểm B, chúng ta bắt đầu phân loại chiến lợi phẩm mà chúng ta đã tích lũy được và bắt đầu xây dựng kế hoạch đi đến C, rồi chúng ta đã phát hiện ra chúng ta không nhất thiết phải đi qua B để tới C, nhưng không thể làm khác đi đơn giản chỉ vì kế hoạch này sẽ không cho phép chúng ta làm vậy (xem Hình 1–1).

Hình 1–1 Phương pháp lên kế hoạch truyền thống (The traditional planning method)

Với Scrum, chúng ta thừa nhận rằng những tranh cãi là sẽ xảy ra — đó là một thực tế của cuộc sống. Thay vì xây dựng kế hoạch hoàn hảo để giảm thiểu càng nhiều các tranh cãi càng tốt, chúng ta chấp nhận thực tế rằng nó sẽ xảy ra và xây dựng cơ chế để xử lý chúng trong suốt dự án, vậy nên mọi người nhận ra được rằng không phải đi vòng qua B; chúng ta có thể đi trực tiếp từ A đến C.

Chúng ta làm điều đó bằng cách cập nhật hàng ngày, hàng tuần, hàng tháng và với những người ở các cấp độ khác nhau (nhóm, quản lý, khách hàng) để đảm bảo chúng ta đang đi đúng hướng và xây dựng các chức năng phù hợp để đạt được mục tiêu dài hạn. Thay vì đặt cược vào một giai đoạn bao gồm tất cả giai đoạn thu thập yêu cầu, chúng tôi cập nhật các yêu cầu theo thời gian, điều chỉnh và tinh chỉnh chúng như thông tin mới phát sinh trong quá trình phát triển. Bởi vì chúng ta có thể làm được điều này, dự án sẽ cho phép những thay đổi với nhu cầu của doanh nghiệp và điều kiện thị trường bên ngoài, cung cấp cho chúng ta con đường ngắn nhất tới thành công (xem Hình 1–2).

Hình 1–2 Phương pháp lên kế hoạch với Scrum

Dù gì đi nữa thành công sẽ không đến mà không kèm theo một số chi phí. Trong mô hình kế hoạch hoàn hảo, chúng ta thường có giả định (mà thường thì những giả định này đều sai) là biết chính xác ngày dự án hoàn thành. Giả định này rất khó bỏ. Trong thực tế, mặc dù, tất cả chúng ta đều biết rằng việc chậm tiến độ hay ngay cả các tính năng (cho dù nó là những tính năng quan trọng nhất hay không) thì một trong hai thứ đó sẽ bị cắt để đảm bảo lộ trình, hoặc chất lượng bị bó buộc vào số lượng chức năng bởi một ngày đã định trước. Kết quả là, những sự đánh đổi đó làm phát sinh các chi phí về thời gian, chất lượng và tiền bạc.

Với Scrum, chúng ta không hứa sẽ cung cấp số lượng các chức năng vào một ngày nhất định. Chúng ta linh động ngày kết thúc hoặc tập hợp các chức năng. Trong một số dự án, chúng ta hứa sẽ cung cấp một số lượng gần đúng các chức năng trong một ngày cố định. Chúng ta làm điều này bằng cách khóa chi phí (những gì khách hàng có thể sẽ chi trả cho mỗi Sprint) và lịch trình (khi nào dự án sẽ kết thúc và sẽ có bao nhiêu Sprint được thực hiện) thanh toán trước. Sau đó chúng ta ước tính có bao nhiêu tính năng chúng ta có thể hoàn thành với những ràng buộc. Bởi vì dự án Scrum luôn làm các công việc có thứ tự ưu tiên cao nhất trước, tính năng mà không hoàn thành vào cuối của dự án là các tính năng ít quan trọng và ít ảnh hưởng tới thành công chung của dự án.

Trong các dự án khác, khi các tính năng quan trọng hơn ngày cố định phải hoàn thành dự án, chúng ta có thể khóa các tính năng, nhưng cho phép ngày (và dẫn đến cả chi phí) dao động. Chúng ta hứa sẽ cung cấp một số chức năng vào một ngày gần đúng, hoặc trong khoảng những ngày nào đó. Khi có thay đổi (các tính năng mới được bổ sung hoặc tính năng yêu cầu được hiểu rõ hơn), khách hàng hiểu rằng anh ta phải lựa chọn giữa việc có được các chức năng trong các thỏa thuận thời gian hoặc kéo dài lịch trình để có được chức năng mong muốn.

Đây là một sự khác biệt lớn so với cách tiếp cận truyền thống, ở đó các tính năng này được đưa lên trước và sau đó các nhóm được yêu cầu ước lượng hạn thời gian hoàn thành và chi phí cần thiết để thực hiện, thường chỉ có các chi phí và giảm thông số ràng buộc về thời gian trong khi được yêu cầu cam kết để thiết lập tính năng tương tự.

Hình 1–3 Tóm tắt những khác biệt giữa hai cách tiếp cận.

Hình 1–3 Sự khác biệt giữa phương thức phát triển phần mềm truyền thống và Scrum

Đây cũng là một sự thay đổi lớn trong tư duy và cũng là lý do mà việc tin tưởng, gắn kết với các giá trị chúng ta đã thảo luận trong chương này là cực kỳ quan trọng.

Scrum có khả năng phát hiện các vấn đề

Scrum làm cho vấn đề hiện ra rõ ràng, những thứ mà được che dấu và bị lãng quên và một số người còn không biết nó tồn tại. Nó cũng cho thấy được nhiều vấn đề mới. Những vấn đề này không chỉ giới hạn ở việc lập trình hoặc làm việc nhóm. Ví dụ, một trong những câu hỏi phổ biến nhất mà tôi nhìn thấy rõ là “Chúng ta nên có chế độ lương thưởng như thế nào?” Hoặc “Phải mất bao lâu để chạy các bộ kiểm thử chấp nhận?” Trong mô hình truyền thống, lập trình viên có thể được thưởng dựa trên việc lập trình xong đúng thời hạn và tại một mức chất lượng nhất định. Vậy sơ đồ này ứng dụng như thế nào cho một nhóm liên chức năng, nơi mà không có những chỉ tiêu đánh giá riêng cho cá nhân hay vị trí chức năng? Những tiêu chuẩn như vậy của tổ chức giống như những thách thức của Scrum, buộc cấp quản lý phải đưa ra lựa chọn khó khăn: giải quyết vấn đề hoặc bỏ qua chúng. Ngược lại,, lợi ích của Scrum cũng làm những hành vi và khuôn mẫu đó xuất hiện rõ ràng và thật khó lơ chúng đi.

Scrum nên được kết hợp với các phương thức phát triển phần mềm khác

Scrum là một khung làm việc để quản lý dự án. Như vậy, nó sẽ cho bạn biết làm thế nào để quản lý các dự án của bạn, nhưng không chứa các thực hành kỹ thuật cụ thể cho phép bạn tạo ra phần mềm hoàn thiện mỗi 2–4 tuần. Do đó, bạn cần một cứu tinh cho Scrum: Extreme Programming (XP). Trong khi Scrum và XP có rất nhiều điểm chung (ví dụ, XP có trò chơi lên kế hoạch; Scrum có các cuộc họp lên kế hoạch, XP có một số các ứng dụng thực tiễn khác bổ sung cho Scrum hoàn thiện hơn, chẳng hạn như có thể tiếp tục tích hợp thêm, thử nghiệm trước và lập trình đôi.

Khi dùng Scrum, tự nó sẽ giúp đỡ các nhóm, sự kết hợp giữa Scrum và XP mang lại kết quả vĩ đại. Điều đó không ngụ ý rằng bạn nên nhảy vào thực hành XP trước khi bạn có một nền tảng vững chắc Scrum — hãy cẩn thận về việc đưa ra quá nhiều thay đổi cùng một lúc. Khi nhóm của bạn có nhiều kinh nghiệm với các vai trò, tạo tác, và các cuộc họp của Scrum, họ đã sẵn sàng để bắt đầu tích hợp thực hành XP, nhưng hãy cẩn thận, làm quản lý dự án Agile trong khi ứng dụng các kỹ thuật trong phương thức lập trình thác nước thường là một sự kết hợp không ổn định, nó gây ra nhiều vấn đề hơn là giải quyết chúng. Điều này có thể mất thời gian có khi một ngày, một tuần, hay cả một tháng; tất cả phụ thuộc vào sự sẵn sàng của nhóm với những thay đổi. Tuy nhiên, một khi đã làm quen với XP, điều kỳ diệu sẽ thực sự xảy ra.

Các bước thực hiện XP mà tôi coi là bắt buộc đối với các dự án tôi làm như sau:

• Tiến độ bền vững — một tuần làm việc 40 giờ và luôn làm việc đạt kết quả 85 phần trăm (xem Chương 23, “Tiến độ bền vững,” để biết thêm).

• Quyền sở hữu tập thể về mã nguồn — Toàn bộ cả nhóm hoạt động trên nền mã nguồn tổng thể. Không có chủ sở hữu duy nhất (xem Chương 21, “Khi xảy ra xung đột văn hóa” để biết thêm).

• Lập trình đôi và kiểm thử phát triển định hướng — Cũng được biết đến như là việc kiểm thử trước, có nghĩa là viết đoạn mã cho việc kiểm thử trước khi viết đoạn mã chạy thật với một cách cố tình làm cho bài kiểm thử bị thất bại — báo đỏ, màu xanh lá cây để chỉ ra một kịch bản kiểm thử đạt, và sau đó tái cấu trúc lại để làm cho các mã tốt hơn. Luôn cố làm cho màu xanh lá cây nhiều hơn, không có trường hợp ngoại lệ (xem Chương 19, “Giữ mọi người theo sát với lập trình đôi,” để biết thêm).

• Tích hợp liên tục — CI cho phép chúng ta có được một hình ảnh liên tục rằng hành vi và biểu hiện của mã nền như thế nào. Kiểm tra mã nguồn của bạn, tối thiểu hàng ngày. Phấn đấu sao cho mọi người về nhà trong trạng thái màu xanh mỗi ngày, giống như có mỗi bài kiểm tra trong kiểm thử phát triển định hướng có màu xanh.

• Các tiêu chuẩn với mã nguồn — Thông thường hay bị bỏ qua, nếu mã nguồn không theo tiêu chuẩn sẽ làm phá hủy Quyền sở hữu tập thể về mã nguồn chẳng hạn như mỗi thành viên thực hiện theo phong cách cá nhân của riêng mình. Hãy viết chúng ra, thông báo và treo chúng lên tường để nhắc nhở tất cả mọi người.

• Tái cấu trúc — Khi chúng ta thực hiện thiết kế up-front, cấu trúc được tinh giản (không phải xóa) và hệ thống được phát triển cho ngày hôm nay, các mã phải được tái cấu trúc. Nếu không tái cấu trúc, các yêu cầu đã thay đổi có thể dẫn đến các thiết kế up-front to hơn mức cần thiết mà không phù hợp với nhu cầu kinh doanh.

• Sản phẩm hoàn thiện — cụm từ này “thường xuyên” là nguyên nhân gây đau đầu đối với nhiều nhóm, như một người bạn của tôi Chris Sterling đã viết trong blog của anh ta, đó là một trong những nhân tố Scrum bị lãng quên [STERLING]. Để thực sự đạt được một sản phẩm hoàn thiện, các nhóm cần phải thay đổi không chỉ quy trình quản lý dự án của họ, mà còn cách họ phát triển phần mềm. Nếu không, tất cả các vấn đề được trình bày như trong câu chuyện của chúng ta — chất lượng tồi, không có thời gian để thử nghiệm, và không có khả năng để chuyển giao — vẫn và sẽ xảy ra và đánh chìm dự án. Để mang lại thay đổi thực sự và lâu dài, kết hợp với việc thực hiện XP là cách tốt nhất mà tôi đã nhận ra.

Khi nào Scrum phù hợp với tôi?

Chúng ta đã xác định được rằng triển khai Scrum phức tạp hơn nhiều so với vẻ bề ngoài của nó. Vì vậy, bạn thắc mắc liệu có nên thử Scrum hay không? Điều đó còn tùy trường hợp.

Tôi có một vài người bạn làm việc trong ngành xây dựng. Tôi thường nhờ họ giúp đỡ tôi mỗi khi cần sửa chữa gì đó trong nhà đổi lại tôi mời bữa tối, và họ cũng vui vẻ nhận lời. Một điều tôi chú ý mỗi khi họ tới là rất nhiều các công cụ mà họ đeo ở thắt lưng. Một lần tôi hỏi Joachim rằng anh ấy luôn mang một bộ đồ nghề chuẩn hay anh thay đổi các loại công cụ mang theo tùy vào công việc mà anh sẽ làm. Anh ấy nói với tôi rằng anh luôn mang theo những dụng cụ cơ bản (thước dây, bút chì, kính an toàn), nhưng hầu như những thứ khác thì phụ thuộc vào công việc. Nếu anh ta làm việc liên quan tới xây khung nhà, anh sẽ bỏ vào đai của mình với các công cụ cần thiết cho việc đó. Khi anh phải hoàn thiện phần mộc hoặc ốp lát, anh sử dụng một bộ khác. Đồng thời, bên cạnh các công cụ mà anh đeo trên thắt lưng anh còn luôn mang theo các công cụ khác để trong xe tải. Điều này áp dụng như thế nào với Scrum?

Tôi xem Scrum như một công cụ trong đai công cụ của một người thợ sửa nhà. Đối với bất kỳ nhà thầu tốt nào, anh ta nên sử dụng Scrum khi thấy phù hợp, và có thể không cần áp dụng nó tất cả 100 phần trăm cho mọi công việc. Cũng như chúng ta sẽ không sử dụng một tuốc nơ vít để làm móng tay, tương tự chúng ta không nên sử dụng Scrum cho một dự án không cần thiết. Vậy, khi nào chúng ta nên sử dụng Scrum?

Các dự án phần mềm thường rơi vào bốn vùng khác nhau: đơn giản, phức tạp, phức hợp, và hỗn loạn (xem hình 1–4), được lấy ra từ Chiến lược quản trị của Ralph Stacey và tổ chức Dynamics tái bản lần thứ hai [STACEY]. Dự án đơn giản được thực hiện bằng hiểu biết cơ bản: các dự án tương tự được thực hiện lặp đi lặp lại do đó mọi người thống nhất về những gì cần thiết và công nghệ được hiểu rõ. Dự án đơn giản rất dễ thực hiện và dễ hiểu.

Hình 1–4 Mối quan hệ giữa yêu cầu của dự án, công nghệ, và loại dự án.

Càng đi xa hơn khỏi vùng đơn giản mọi thức trở nên khó khăn hơn. Các yêu cầu của chúng ta, công nghệ của chúng ta — hoặc cả hai — có thể không ổn định như chúng ta hy vọng. Có lẽ mọi người cũng không ai chắc chắn về sản phẩm cuối cùng sẽ trông như thế nào. Có lẽ công nghệ này là mới hoặc chưa được thử nghiệm. Trong vùng này, khu vực phức tạp và phức hợp, chúng ta gặp phải một lượng đáng kể thay đổi. Các dự án ở đây khó thực hiện và khó dự đoán hơn. Khi chúng ta tiến xa hơn vòng phức tạp hướng tới khu vực hỗn loạn, chúng ta bắt đầu gặp phải ẩn số và thực sự không biết đó là gì. Khi các dự án hoặc các công ty đang ở trong trạng thái này, họ nên tập trung vào việc khắc phục những vấn đề đã dẫn họ tới đó thay vì xây dựng hệ thống.

Tất cả điều này có nghĩa là nếu bạn đang ở bất cứ đâu trong vùng đơn giản, bạn sẽ có sự thay đổi trong dự án — thay đổi trong yêu cầu, công nghệ, hoặc cả hai. Tôi đã sử dụng Scrum và XP trên các dự án đơn giản và thường xuyên thấy nhiều chức năng dư thừa và sự áp dụng Scrum/XP là không cần thiết. Tuy nhiên, khi bạn di chuyển ra khỏi vùng đồng thuận và chắc chắn, bạn cần sử dụng Scrum và XP hơn, vì làm như vậy sẽ giúp bạn thích ứng với các yêu cầu kinh doanh thay đổi — một điều mà chắc chắn sẽ xảy ra.

Thay đổi là một việc khó

Mọi thứ về Scrum đều xoay quanh sự thay đổi. Một số người chộp lấy cơ hội thay đổi còn một số người lại tránh nó như bệnh dịch hạch. Cả hai xu hướng này đều hoàn toàn tự nhiên. Trong phần mềm, chúng ta thường tránh những thay đổi không phải vì chúng ta sợ nó, mà vì chúng ta đã có điều kiện để làm đúng ngay lần đầu tiên. Chúng ta thường đánh đồng sự thay đổi thành “lỗi” (“bug”) hoặc tính năng mà chúng ta bị thiếu khi đang phát triển các sản phẩm, yêu cầu thay đổi cho thấy chúng ta đã thất bại theo một cách nào đó. Những điều chúng ta thường không hiểu đó chính là thay đổi thì không thể tránh khỏi. Chúng ta không thể dự đoán tương lai; chúng ta không thể đoán được sự thay đổi của thị trường bất ngờ hoặc sự phát hành mới nhất của đối thủ trước khi chúng xảy ra. Để thành công, chúng ta phải học để làm chủ sự thay đổi. Scrum cho chúng ta những công cụ để làm điều này, nhưng để nó tiến đến nơi mà sự thay đổi được đồng bộ hóa vào quy trình của chúng ta là một hành trình khó khăn.

Nhóm làm việc trong câu chuyện của chúng ta muốn sử dụng Scrum nhưng lại sợ lao vào những thứ không rõ ràng. Họ đã cố gắng, trong vô vọng, để giữ những khuôn mẫu quen thuộc và ngăn chặn sai lầm bằng cách sửa đổi quy trình và bổ sung thêm quy trình lên kế hoạch và Sprint tích hợp. Thay vì thoát khỏi sai lầm, sự hiệu chỉnh lại gây ra vấn đề và làm cho mọi việc tồi tệ hơn nhiều.

Hiểu biết về các phản ứng phổ biến với thay đổi là chìa khóa để ứng dụng Scrum thành công. Virginia Satir là một bác sĩ chuyên khoa gia đình, thông qua các nghiên cứu lâm sàng, xác định một mô hình phổ biến trong cách mọi người trải nghiệm sự thay đổi. Các giai đoạn này bao gồm các hiện trạng cũ, yếu tố ngoại vi xuất hiện, sự hỗn loạn, hội nhập và thực hành, và hiện trạng mới. Những mô hình của hành vi được gọi là giai đoạn Satir của Change [SATIR], được trình bày trong Hình 1–5.

Hình 1–5 Mô hình Satir’s các giai đoạn của sự thay đổi.

Tôi thấy rằng các giai đoạn này tương đối ổn định, không có vấn đề gì về mức độ thay đổi của người tham gia. Mẹ tôi đã cố gắng bỏ hút thuốc khi tôi lớn lên và tôi đã quan sát thấy tiến trình ấy diễn ra tương tự như mô hình Satir này. Tôi cũng đã thấy quá trình tương tự khi quan sát sự những đứa trẻ cố gắng trong lần đầu tiên tập xe đạp. Vậy hãy cùng xem các nhóm Scrum đi qua các giai đoạn như thế nào.

Hiện trạng cũ

Khi một người ở trong tình trạng hiện tại, họ rất thoải mái. Thông thường, mọi người tìm thấy lý do để ở lại trong trạng thái ấy vì đó là thế giới mà họ đã quen thuộc với. Mọi người có xu hướng bỏ qua những nhu cầu thay đổi và chỉ tiếp tục làm điều tương tự, chỉ làm những điều tốt hơn, khó khăn hơn, hoặc siêng năng hơn. Một ví dụ quen thuộc của trạng thái hiện tại là những dự án chết, nơi các nhóm có tư tưởng chủ bại khi phải làm việc nhiều giờ hơn và bất đắc dĩ hy sinh chất lượng để cố gắng đáp ứng thời hạn. Cuối cùng, tất cả mọi người bắt đầu phàn nàn về sự vô ích về niềm tin rằng tất cả có thể được thực hiện tốt nếu chúng ta cứ tiếp tục chăm chỉ hơn và gồng mình mạnh mẽ. Tại thời điểm này, một sự chống đối bắt đầu nhen nhóm, một số ít người chán cách thức đang thực hiện hoặc một cách làm việc mới của các viện quản lý. Đây là điểm mà tại đó một yếu tố ngoại vi xuất hiện.

Yếu tố ngoại vi

Các yếu tố ngoại vi là một thách thức; đó là điều đó sẽ đưa bạn ra khỏi Hiện Trạng Cũ. Trong một số trường hợp, nó có thể là một yếu tố nhỏ, chẳng hạn như sử dụng một số tiêu chuẩn mới cho bản mẫu của một dự án. Trong các trường hợp khác, nó có thể là một cách hoàn toàn mới để làm việc, chẳng hạn như việc triển khai Scrum. Bất kể là nó là gì, một khi yếu tố ngoại lai xuất hiện thì không thể lảng tránh và từ đó hỗn loạn nảy sinh. Điều này thường tạo ra sự sợ hãi cho mọi người. Họ biết sự thay đổi đang đến, nhưng họ chống lại nó bởi vì họ không biết làm thế nào để thay đổi, những gì là điều họ mong đợi, hoặc họ không chắc có đủ khả năng thành công trong “cách mới này” giống như họ đang ở trong trạng thái cũ, hay cách quen thuộc hay không.

Sự hỗn loạn

Sự hỗn loạn đến khi hiện trạng bị gián đoạn bởi các yếu tố ngoại vi. Trong khi mức độ của sự hỗn loạn phụ thuộc vào bản chất của các yếu tố ngoại vi, trong trường hợp có một sự thay đổi quy mô lớn, nó có thể cảm thấy như thể mọi thứ quen thuộc đã biến mất. Ngay cả những người chắc chắn nhất về sự cần thiết của phương pháp mới cũng cảm thấy như bị ép buộc phải thực hiện công việc một cách xa lạ và khó chịu. Mọi người ở trạng thái này thường lo lắng và không chắc chắn và cảm thấy dễ bị tổn thương. Họ sợ phạm phải sai lầm. Kết quả là, lo lắng tích tụ và thể hiện cũng rất khác nhau. Khi nhóm làm việc đi qua giai đoạn này, mọi thứ sẽ tồi tệ trước khi nó trở nên tốt đẹp, nhưng họ thực sự mọi thứ sẽ tốt hơn. Sự kết thúc của sự hỗn loạn đi kèm với việc xác định một ý tưởng biến đổi.

Những ý tưởng chuyển đổi nào sẽ kết thúc sự hỗn loạn mà Scrum ban đầu gặp phải? Nó thay đổi từ nhóm này qua nhóm khác, nhưng đa số chủ đề thường là suy nghĩ chung, “Này, cái hiện tại không tệ lắm. Chúng ta có thể làm được.” Mọi người bắt đầu thấy sự kết nối giữa các yếu tố ngoại vi và cách mọi việc có thể diển ra trong tương lai. Kết quả là, các kết nối được tạo ra.

Hội nhập và thực hành

Bọn trẻ nhà tôi chơi thể thao. Mỗi khi chúng than vãn về giờ tập luyện, tôi nhắc nhở chúng rằng ai đó cũng đang tập luyện lúc này, hãy luyện tập để đánh bại họ khi hai nhóm gặp nhau. Thực hành trong phát triển phần mềm là khá quan trọng. Nếu không có sự luyện tập, các yếu tố ngoại vi sẽ không bao giờ trở nên quen thuộc hay trở thành bản năng thứ hai, hay một thói quen lâu dài.

Như một nhóm bắt đầu tìm hiểu các cách thức và hiểu các nguyên tắc của Scrum, từ đó bắt đầu nhận ra lợi ích của Scrum. Khi những lợi ích này xuất hiện, các thành viên trong nhóm dần dần bắt nhịp với thực tế mới của họ. Sự hỗn loạn dần biến mất khi nhóm di chuyển hướng tới một trạng thái cân bằng mới. Niềm tin, các mối quan hệ, và bản sắc xuất hiện trong nhóm và trong các nhóm làm việc nói chung. Khi mọi người tìm hiểu để làm việc với nhau theo một cách mới, hiệu suất bắt đầu cải thiện, thường xuyên vượt mức so với trước khi thay đổi. Không dùng các mức tăng trước đó như là một dấu hiệu cho thấy nhóm bây giờ là “tốt.” Ngược lại, các nhóm trong giai đoạn này cần bồi dưỡng và chăm sóc nhiều hơn là sau này. Khi thực tế là mọi người đang đạt được sự tự tin trong công việc, họ vẫn có thể cảm thấy dễ bị tổn thương, mặc dù điều đó có thể khó nhận thấy. Sự thành công mới tìm thấy là mong manh và nhạy cảm và cần được đối đãi một cách thích hợp. Tuy nhiên, với mỗi thành công, triển vọng về những gì có thể được thực hiện bắt đầu xuất hiện. Đối với đại đa số, nó có thể có cảm giác như cõi niết bàn; đối với một số ít có thể luôn cảm thấy một chút hỗn loạn.

Hiện trạng mới

Khi các thành viên trong nhóm trở nên có kỹ năng và thoải mái hơn với ý tưởng biến đổi, họ bắt đầu vượt kết quả trước đó của họ. Họ cảm thấy được nghỉ ngơi và có cảm giác hoàn thành xuất phát từ trải qua một sự kiện chuyển đổi với nhau. Giai đoạn này cho phép mọi người khám phá những cách thức mới để cải thiện, để cảm thấy họ có quyền làm cho mọi việc tốt hơn, và làm việc với nhau để tạo ra một tổ chức luôn học hỏi. Sự tự do để tiếp tục thực hành trong một môi trường an toàn là điều then chốt. Cũng giống như trong thể thao, bạn không bao giờ có được thành tích tốt nếu bạn không tập luyện hay không học hỏi những điều mới.

Chìa khóa thành công

Như câu chuyện minh họa của chúng tôi, nhiều nhóm phải vật lộn với việc giai đoạn ban đầu khi triển khai Scrum, không phải vì họ không sẵn sàng hoặc có tư duy đóng, mà vì Scrum đòi hỏi họ phải làm việc theo cách họ cảm thấy khó chịu và không quen thuộc. Các nhân vật trong câu chuyện của chúng ta đã cố gắng giữ cho các yếu tố quen thuộc với họ, nhưng không biết rằng những yếu tố này lại kéo họ xuống và đó chính là rào cản đến thành công của họ. Để có thể ứng dụng Scrum thành công, các nhóm phải bắt đầu từ những điều cơ bản.

Đầu tiên, nhóm phải hiểu nguyên tắc chung của Scrum. Scrum là một khung làm việc để “get it done”. Bởi sự đơn giản của nó, mọi người có xu hướng thay đổi nguyên tắc mà không hiểu được ảnh hưởng ngầm của hành động đó. Điều đó rất nguy hiểm. Cũng như bạn sẽ không nên lái xe nếu như không biết luật giao thông, bạn không nên cố gắng thực hiện Scrum khi không có một thỏa thuận tốt về sự tìm tòi nghiên cứu. Học những nguyên tắc về Scrum cần thời gian. Hãy sử dụng thời gian này để hiểu những nguyên tắc nên ứng dụng thế nào cho bạn, nhóm của bạn và công ty bạn.

Tiếp theo, thành viên nhóm phải học những nguyên lý nền tảng. Nhóm và tổ chức phải hiểu được Scrum làm việc như thế nào. Phải mất thời gian cho việc này thành hiện thực. Như chúng ta đã thấy với mô hình các giai đoạn thay đổi của Satir, chuyển từ biết rõ đến không rõ là một quá trình khó khăn mà đòi hỏi kiên nhẫn và thực hành. Nó cũng giống như tập đi xe đạp. Chúng ta không thể đi tham dự giải đua xe đạp vòng quanh nước Pháp khi chúng ta năm tuổi; chúng ta lắc lư, chao đảo và thường bị ngã. Đó là quá trình luyện tập làm cho chúng ta vững chắc và ổn định. Cho người khác thời gian để học hỏi những gì cơ bản là giúp đỡ họ trong cả quá trình. Hãy đặt mình vào vị trí của người khác và hiểu rằng những cơ chế nền tảng đang được luyện tập, mọi người có thể yếu ớt, hoài nghi, và lo lắng. Những bất an sẽ được khắc phục theo thời gian, nhưng chỉ khắc phục được khi mọi người có thể luyện tập.

Thứ ba, dành thời gian cho Scrum. Học một cách làm việc mới phải mất nhiều thời gian hơn so với việc chỉ cần tham dự một cuộc hội thảo vào cuối tuần. Tôi khám phá ra rằng phần lớn các nhóm Scrum và công ty thực hiện Scrum cần ít nhất ba tháng để tìm hiểu những điều cơ bản để có thể bắt đầu. Một số công ty có thể làm ngắn hơn và một số mất nhiều thời gian hơn, nhưng trung bình, kế hoạch thường từ 3 tới 6 tháng , tùy thuộc vào nhóm đang được chuyển đổi, thay đổi quản lý.

Thứ tư, không áp dụng Scrum giữa chừng. Tôi đã thấy vô số các dự án theo Scrum thất bại, nơi các nhóm thực hiện Scrum ở giữa một chu kỳ phát triển, thường là kết quả của quản lý quyết định rằng Scrum là liều thuốc thần kỳ sẽ giải quyết tất cả các vấn đề của công ty. Quản lý, nhìn thấy những lợi ích tiềm năng đến từ một nhóm có hiệu suất cao, hy vọng nhóm trở thành chuyên gia sử dụng Scrum chỉ qua một đêm. Như bạn có thể tưởng tượng, điều này ném các nhóm vào một tình trạng suy sụp khi họ bị buộc phải làm việc trong một phong cách mới trong khi thời hạn cuối đang tới gần. Sự hỗn loạn tiếp theo gây ra sự chậm trễ sau khi trì hoãn và hy sinh rất nhiều về chất lượng. Tôi khuyên bạn nên thực hiện Scrum vào đầu một dự án mới. Trong khi chờ đợi, bạn có thể tạo một backlog cho việc chuyển đổi về những điều bạn cần có tại chỗ, và làm việc, để đảm bảo việc áp dụng Scrum tốt nhất có thể.

Cuối cùng, hãy chắc chắn dành thời gian cho việc học hỏi một cách liên tục. Thông thường các nhóm bỏ qua Retrospective, họ coi đó là một sự xa xỉ hay một sự lãng phí thời gian. Các nhóm bỏ qua Retrospective, hoặc vận hành mà không áp dụng những gì học được cho Sprint trong tương lai, thường rơi trở lại vào những thói quen cũ. Tại sao? Bởi vì họ không đặt ra thời gian để tìm hiểu. Học tập là một trong những khía cạnh quan trọng của Scrum mà không thể bị hy sinh. Các nhóm không thể tiến tới một trạng thái có hiệu suất cao mà không cần học tập.

Qua tất cả những thử thách kỹ thuật và tâm lý, chỉ cần nhớ là phải gắn bó với Scrum. Học Scrum là không khác so với việc học một thứ gì mới. Sẽ có những lúc lên đỉnh vinh quang cũng có lúc xuống đáy tuyệt vọng. Luôn tự học hỏi và giữ cho tâm hồn rộng mở. Hãy nhớ rằng nếu NASA có thể đưa con người lên mặt trăng với một hệ thống máy tính trong bộ nhớ 32k và 72k thì chúng ta cũng có thể áp dụng Scrum.