"Vì vậy, tôi muốn nói với bạn về Agile và Scrum ."
"Vào đầu thế kỷ 21, cách mọi người nghĩ về lập trình đã bị đảo lộn."
"Mọi người đều tin rằng kế hoạch dài hạn không hiệu quả, vì vậy họ quyết định từ bỏ nó hoàn toàn."
"Làm thế nào mà họ làm điều đó?"
"Đây là cách."
"Họ đã phát minh ra phương pháp quản lý dự án linh hoạt nhất có thể."
Dưới đây là những ý tưởng chính đằng sau sự phát triển linh hoạt :"
- con người và giao tiếp quan trọng hơn các quy trình và công cụ;
- một sản phẩm đang hoạt động quan trọng hơn tài liệu đầy đủ;
- cộng tác với khách hàng quan trọng hơn việc đáp ứng các điều khoản của hợp đồng;
- sẵn sàng thay đổi quan trọng hơn là bám sát vào kế hoạch ban đầu.
Dưới đây là các nguyên tắc phát triển nhanh chóng:
- làm hài lòng khách hàng bằng cách cung cấp phần mềm có giá trị sớm và liên tục;
- hoan nghênh những thay đổi về yêu cầu ngay cả khi kết thúc quá trình phát triển (điều này có thể làm tăng khả năng cạnh tranh của sản phẩm cuối cùng);
- cung cấp phần mềm hoạt động thường xuyên (hàng tháng hoặc hàng tuần hoặc thường xuyên hơn);
- giao tiếp chặt chẽ hàng ngày giữa khách hàng và nhà phát triển trong toàn bộ dự án;
- dự án được thực hiện bởi những cá nhân có động lực, những người được cung cấp các điều kiện làm việc, hỗ trợ và tin tưởng cần thiết;
- phương pháp ưa thích để truyền đạt thông tin là một cuộc trò chuyện cá nhân (mặt đối mặt);
- phần mềm làm việc là thước đo tiến độ tốt nhất;
- các nhà tài trợ, nhà phát triển và người dùng sẽ có thể duy trì tốc độ không đổi trong một khoảng thời gian không xác định;
- tập trung liên tục vào việc cải thiện kỹ thuật xuất sắc và thiết kế thân thiện với người dùng;
- đơn giản là nghệ thuật không làm việc thừa;
- các yêu cầu kỹ thuật, thiết kế và kiến trúc tốt nhất đến từ một nhóm tự tổ chức;
- thích nghi liên tục với những hoàn cảnh thay đổi.
"Vấn đề chính với phát triển phần mềm là ở bất kỳ giai đoạn nào, không ai trong số những người tham gia có thông tin đầy đủ về những việc cần làm."
“Khách hàng có thể cho bạn biết anh ấy hình dung chương trình như thế nào, nhưng anh ấy sẽ bỏ qua một số thứ hoặc coi đó là điều hiển nhiên.”
"Người quản lý thường phải dịch các yêu cầu từ biệt ngữ lập trình sang ngôn ngữ của khách hàng và ngược lại."
"Có quá nhiều điều không chắc chắn."
"Thông thường, yêu cầu của khách hàng là như thế này: làm theo cách nào đó, sau đó chỉ cho tôi - nếu tôi không thích, thì bạn có thể làm lại."
"Uh... thật kinh khủng."
"Theo mô hình mới, các lập trình viên không còn phát triển sản phẩm hay chương trình nữa. Thay vào đó, họ đang triển khai chức năng mà khách hàng cần."
"Có gì khác biệt?"
"Chà, giả sử rằng việc phát triển chương trình trước đây mất một năm. Và sáu tháng trôi qua trước khi có bất cứ thứ gì để xem xét. Nó giống như việc xây dựng một ngôi nhà lớn: đầu tiên, bạn đào hố móng, sau đó đổ móng, xây tường, lợp mái, trang trí, v.v."
"Nhưng bây giờ các lập trình viên cố gắng phát hành chức năng cần thiết càng sớm càng tốt. Điều này sẽ giống như việc xây dựng một túp lều trước tiên, sau đó là một ngôi nhà di động, sau đó là một ngôi nhà nhỏ và chỉ sau đó là một ngôi nhà lớn—theo từng đợt."
"Xem xét rằng khách hàng có thể không biết chính xác những gì anh ta muốn, thì đây là một cách tiếp cận rất hợp lý."
"Giả sử khách hàng muốn một nhà nghỉ săn bắn lớn."
"Các nhà phát triển xây cho anh ấy một ngôi nhà nhỏ. Anh ấy sống trong đó một mùa đông. Sau đó, anh ấy quyết định rằng mình không thích những ngôi nhà bằng gỗ. Hãy làm một ngôi nhà bằng gạch."
"Anh ấy sống gần hồ trong một mùa hè, nhưng những con muỗi đã ăn tươi nuốt sống anh ấy. Anh ấy đã nghe đâu đó rằng hồ rất mát, vì vậy anh ấy muốn có một cái hồ. Nhưng bây giờ anh ấy không muốn có một cái hồ. Và nó sẽ dễ dàng hơn để xây dựng ngôi nhà theo cách này: không có hồ có nghĩa là không có mối đe dọa lũ lụt, và bạn có thể xây dựng ngôi nhà trên mặt đất thay vì nhà sàn, sẽ nhanh hơn 25%."
"Một phép so sánh thú vị. Khách hàng có thực sự thay đổi yêu cầu của họ thường xuyên không?"
"Vâng, nhưng vấn đề không phải là khách hàng."
"Đầu tiên, rất khó để tưởng tượng mọi thứ sẽ diễn ra như thế nào trong tương lai. Người quản lý, người kiểm tra và lập trình viên đều làm điều này. Họ cũng thay đổi suy nghĩ tùy thuộc vào cách mọi thứ diễn ra."
"Thứ hai, không phải yêu cầu của khách hàng mới là điều quan trọng nhất sao? Xét cho cùng , mục đích của tất cả công việc này là tạo ra thứ mà khách hàng cần , chứ không phải thứ mà anh ta nói ban đầu là tạo ra ."
"Thật vậy, nó từng hoạt động như thế này: các nhà phân tích kinh doanh sẽ lập danh sách tất cả các yêu cầu. Họ sẽ đưa danh sách này vào hợp đồng, ký tên và chỉ làm việc theo danh sách."
"Nếu danh sách thiếu thứ gì đó mà khách hàng thực sự cần nhưng đã quên, sẽ không ai làm gì được."
"Tôi hiểu rồi. Làm theo kế hoạch sẽ dễ dàng hơn, nhưng không phải mọi thứ đều có thể được thực hiện theo kế hoạch!"
"Chính xác."
"Đó là lý do tại sao các phương pháp phát triển nhanh được phát minh."
"Và hôm nay tôi sẽ kể cho bạn nghe về Scrum — phổ biến nhất trong số đó.
"Tính năng chính của Scrum là phân chia quá trình phát triển dự án thành các lần lặp lại nhỏ — thường kéo dài từ 2-4 tuần. Mỗi lần lặp lại được gọi là một lần chạy nước rút."
"Khi bắt đầu chạy nước rút, một cuộc họp lập kế hoạch chạy nước rút được tổ chức. Nó kéo dài 3-4 giờ."
"Cuối cùng, có một cuộc biểu tình của tất cả các nhiệm vụ đã hoàn thành."
"Đây là cách mọi thứ thường hoạt động:"
"Trước lần chạy nước rút đầu tiên, khách hàng (hoặc đại diện của khách hàng) lập một danh sách các yêu cầu, tức là tập hợp những điều mà chương trình có thể thực hiện. Những yêu cầu này thường được gọi là câu chuyện của người dùng và khách hàng thường là được gọi là chủ sở hữu sản phẩm ."
"Anh ấy được gọi là chủ sở hữu sản phẩm , bởi vì sản phẩm được viết cho anh ấy. Anh ấy, và một mình anh ấy, xác định danh sách các yêu cầu — cái gì, khi nào và theo thứ tự nào."
"Ngoài ra, chủ sở hữu sản phẩm thường chỉ định mức độ ưu tiên của nhiệm vụ. Nhiệm vụ có mức độ ưu tiên cao nhất sẽ được thực hiện trước. Toàn bộ danh sách các yêu cầu còn được gọi là sản phẩm tồn đọng ."
"Khi bắt đầu chạy nước rút, mọi người tập trung cho một cuộc họp. Scrum Master , thường là thành viên của nhóm, thường dẫn dắt cuộc họp. Mục tiêu của cuộc họp là chọn các nhiệm vụ ( câu chuyện của người dùng ) cho lần chạy nước rút hiện tại (lặp lại quá trình phát triển). "
"Đầu tiên, nhóm chỉ định cho mỗi nhiệm vụ một ước tính sơ bộ trong ngày công trừu tượng, còn được gọi là điểm câu chuyện. Sau đó, nhóm quyết định họ sẽ có bao nhiêu nhiệm vụ để hoàn thành trong giai đoạn nước rút."
"Một lần nữa, chính nhóm quyết định có bao nhiêu nhiệm vụ mà họ sẽ có thời gian để hoàn thành trong giai đoạn nước rút."
"Giả sử chủ sở hữu sản phẩm mong muốn nhóm chọn 7 nhiệm vụ đầu tiên nhưng nhóm chỉ chọn 5, sau đó nhiệm vụ 6 và 7 được hoãn lại cho lần chạy nước rút tiếp theo. Nếu điều đó không phù hợp với chủ sở hữu sản phẩm, anh ấy có thể nâng mức độ ưu tiên của các nhiệm vụ 6 và 7 để đảm bảo rằng chúng được chọn, nhưng sau đó một số nhiệm vụ khác sẽ bị loại khỏi Sprint."
" Scrum master cũng có thể đề xuất chia một số nhiệm vụ thành những nhiệm vụ nhỏ hơn và đặt các mức độ ưu tiên khác nhau cho chúng để khiến chủ sở hữu sản phẩm hài lòng nhất có thể."
"Đó là điểm chính của cuộc họp: các nhiệm vụ có thể được thay đổi và phân chia, các ưu tiên có thể được thay đổi, v.v. Đây là công việc không thể nhìn thấy ngay từ đầu nhưng mang lại rất nhiều giá trị."
"Hiểu rồi. Nó giống như lái một chiếc ô tô. Ngay cả khi ban đầu bạn tin rằng mình chỉ cần đi thẳng, nhưng thực tế là bạn cần phải liên tục tránh ổ gà, rẽ phải và rẽ trái, vượt qua người khác hoặc để họ vượt qua bạn."
"Ừ, đại loại như vậy."
"Danh sách các nhiệm vụ được chọn cho lần chạy nước rút được gọi là hồ sơ tồn đọng của lần chạy nước rút ."
"Các lập trình viên quyết định ai sẽ làm gì, và chỉ sau đó họ mới bắt tay vào làm việc." Để nâng cao hiệu quả, Scrum gợi ý rằng nên tổ chức một cuộc họp kéo dài 5-15 phút mỗi ngày để mọi người có thể nói với nhau những gì họ đã làm ngày hôm qua và những gì họ đang làm. sẽ làm ngày hôm nay."
"Làm việc theo nhóm. Tôi có thể tôn trọng điều đó!"
"Để dễ hình dung hơn, bạn nên hiển thị trạng thái chạy nước rút hiện tại trên một bảng đặc biệt:"
"Lưu ý ba cột bên trái."
"Tên nhiệm vụ viết tắt được viết trên các ghi chú dán. Và các ghi chú dán này được đặt trong các cột khác nhau tùy thuộc vào trạng thái của chúng (đã lên kế hoạch, đang thực hiện, đã hoàn thành)."
"Ở bên phải, bạn có thể thấy biểu đồ burndown . Đối với mỗi ngày, biểu đồ này liệt kê các nhiệm vụ vẫn chưa hoàn thành. Lý tưởng nhất là số lượng nhiệm vụ chưa hoàn thành giảm xuống 0 trong giai đoạn chạy nước rút."
"Khi Sprint kết thúc, scrum-master đưa ra một bản demo để hiển thị danh sách mọi thứ đã được hoàn thành."
"Sau đó, anh ấy tổ chức một cuộc họp cải tiến nước rút, cũng kéo dài vài giờ. Trong cuộc họp này, những người tham gia thường cố gắng tìm hiểu xem điều gì đã diễn ra tốt đẹp và điều gì (và bằng cách nào) có thể được thực hiện tốt hơn."
"Thông thường sau 2-3 lần chạy nước rút, bạn có thể xác định và loại bỏ các vấn đề chính khiến nhóm không hoạt động hiệu quả hơn. Điều này dẫn đến năng suất cao hơn mà không làm tăng khối lượng công việc của nhóm. Điều này không thể thực hiện được trước thời đại của các phương pháp nhanh. "
"Đôi khi, một cuộc họp chuẩn bị cũng được tổ chức trong suốt Sprint. Mục đích là để lập kế hoạch cho Sprint tiếp theo. Những người tham gia thường làm rõ các ưu tiên nhiệm vụ trong cuộc họp này. Họ cũng có thể chia một số nhiệm vụ thành nhiều phần và/hoặc thêm nhiệm vụ mới vào product backlog . "
"Chà, về cơ bản đó là tất cả những gì tôi có. Đây chỉ là phần tổng quan. Không thể giải thích tất cả chỉ trong vài từ, nhưng bạn có thể đọc một bài viết hay về chủ đề này tại đây:"
GO TO FULL VERSION