- Việc lập trình ngày nay gây căng thẳng hơn rất nhiều so với thập niên 90 và đầu những năm 2000
- Khi đó, công việc chỉ trở nên điên cuồng khi gần đến hạn chót, còn những lúc khác thì tương đối yên bình
- Tác giả đã suy nghĩ về lý do khiến mức độ căng thẳng tăng lên trong vài thập kỷ gần đây
- Không phải vì cạnh tranh, thay đổi thị trường hay deadline ngặt nghèo, mà là vì cách làm việc theo sprint
1. Sprint không dừng lại
- Sprint là những hạn chót nối tiếp nhau không có điểm kết thúc
- Mô hình waterfall trước đây gắn với các deadline và sự kiện thực tế
- Sprint là những hạn chót nhân tạo, không có khoảng nghỉ tự nhiên
- Căng thẳng ngắn hạn có thể tốt cho sức khỏe, nhưng căng thẳng dài hạn lại gây hại cho cơ thể
2. Sprint không mang tính tự nguyện
- Điều này khác với việc cả nhóm tự nguyện triển khai code mỗi 2 tuần
- Mọi khía cạnh của sprint đều được quy định sẵn
- Tính tự chủ đóng vai trò quan trọng trong trải nghiệm công việc
- Công việc mang tính ép buộc gây ra căng thẳng và khó chịu
3. Sprint bỏ qua các hoạt động hỗ trợ quan trọng
- Sprint không cung cấp thời gian để chuẩn bị cho công việc tiếp theo
- Muốn thực hiện công việc thì cần có thời gian chuẩn bị
- Sprint cố tách riêng phần chuẩn bị và phần thực thi, nhưng điều này lại gây stress
Scrumpol: Bức tranh thực tế (và còn tệ hơn)
- Phần lớn các cách triển khai Scrum là sự pha trộn giữa waterfall và Scrum
- Những deadline lớn luôn tồn tại ở phía sau
- Khi deadline lớn đến gần, Scrum bị gián đoạn và mức độ căng thẳng tăng lên
Kết luận
- Sprint không có khoảng nghỉ, thiếu tính tự chủ và thiếu thời gian chuẩn bị
- Lập trình viên cần có khả năng kiểm soát công việc và quy trình của mình
- Để làm được điều đó, cần nỗ lực xây dựng các tổ chức có đạo đức hoặc chuyển sang làm freelancer
Tóm tắt của GN⁺
- Bài viết này giải thích lý do vì sao cách làm việc Scrum tạo ra căng thẳng liên tục cho lập trình viên
- Những hạn chót liên tục của sprint, sự thiếu tự chủ và thiếu thời gian chuẩn bị là các nguyên nhân chính
- Cần giúp lập trình viên có thể kiểm soát cách thức làm việc của mình
- Một phương pháp khác có chức năng tương tự là Kanban
8 bình luận
Ngay cả khi thực hiện các dự án như SI, khu vực công, họ cũng liên tục dồn ép theo kiểu phase 1, 2, 3... không có lúc nghỉ. Và ở từng phase riêng lẻ đó lại phát sinh rất nhiều thay đổi. Làm như vậy thì hoàn toàn không thể đạt được mục đích vốn có của scrum là phát triển một cách thành công. Cuối cùng, chỉ có các lập trình viên là kiệt sức trong bầu không khí hỗn loạn, rối ren này.
Mình đang là PM.
Ở những môi trường agile/scrum mà mình cảm thấy vận hành tốt, khi một sprint quan trọng kết thúc thì sẽ có retrospective và được dành thời gian nghỉ ngơi. Cả team phát triển lẫn team hoạch định đều có một khoảng nghỉ trước khi chuẩn bị cho việc tiếp theo.
Còn ở cách vận hành mà mình cảm thấy không đúng như bài viết nói, thì dưới các deadline đổ xuống theo kiểu waterfall, bên trong team sản phẩm vẫn đồng thời chạy theo scrum nên căng thẳng càng chồng chất. Vì bản thân deadline là thứ không thể thay đổi, nên bọn mình cứ phải chạy hàng tuần mà không có cả thời gian để nghỉ hay retrospective, tạo cảm giác như một cuộc chạy không bao giờ kết thúc.
Theo tôi hiểu, mục đích của waterfall là xác định yêu cầu càng sớm càng tốt và vì có sự phụ thuộc giữa các công việc thiết kế - triển khai - kiểm thử nên hãy làm việc theo đúng thứ tự; còn mục đích của agile và sprint là chia nhỏ những việc quá lớn để có thể thiết kế hoặc triển khai trước bằng waterfall rồi thử làm. Cả hai đều có ưu và nhược điểm, nên thay vì theo đuổi phương pháp luận một cách giáo điều thì có lẽ chỉ cần chọn lọc những gì cần thiết cho phù hợp với tình huống. Như bài viết lập luận, cũng cần có thời gian nghỉ ngơi và thời gian chuẩn bị để rà soát kỹ thuật hoặc làm prototype. Dù ai là người quyết định thứ tự công việc, miễn là họ hiểu các yếu tố cản trở và xác định ưu tiên theo đúng dòng chảy của công việc thực tế, thì tôi nghĩ việc có hay không có quyền tự chủ của lập trình viên cũng chưa chắc là vấn đề.
Phải chăng những bài như thế này xuất hiện trên các blog nước ngoài vì ở đó có quá nhiều quản lý không hề có kinh nghiệm phát triển nhưng lại cố áp dụng mù quáng quy trình của các phương pháp phát triển? Cảm giác cứ như đang nhìn thấy xung đột giữa người làm kế hoạch và lập trình viên ở nước mình, khi phía làm kế hoạch hoàn toàn không hiểu công việc thực tế vậy.
Theo luồng công việc thực tế, người có thể quyết định ưu tiên tốt nhất hẳn là chính lập trình viên; vì vậy tôi cho rằng ngay từ cách tiếp cận tước đi tính tự chủ và để người khác làm thay việc đó đã là nguyên nhân gây ra sự tách biệt giữa công việc thực tế và kế hoạch của nhóm.
Nếu bản thân việc quản lý cũng là một lĩnh vực chuyên môn, thì ngay cả với một quản lý không có kinh nghiệm phát triển, khi đối mặt với thời điểm việc quản lý nguồn lực phát triển không còn vận hành tốt, tôi nghĩ câu trả lời cho tình huống đó là người quản lý phải tự thích nghi hoặc ứng phó. Thế nhưng, tôi đã thấy quá nhiều lần trách nhiệm này bị đẩy sang cho những người đóng góp cá nhân...
Đúng là trách nhiệm cuối cùng phải do quản lý gánh vác. Nhưng có lẽ thực tế không phải lúc nào cũng vậy. Cũng giống như một CEO chỉ biết quản trị mà hoàn toàn không hiểu nghiệp vụ của công ty, rồi đôi khi còn khiến công ty lao dốc.
Có quá nhiều PM chỉ biết đá qua đá lại công việc thôi T_T
Ý kiến trên Hacker News
Trích lời Rich Hickey, lập trình viên giải quyết vấn đề không giống vận động viên chạy cự ly ngắn; thay vào đó, họ bị bắn tín hiệu xuất phát mỗi 100 yard để bắt đầu một đợt sprint mới
Đã trở nên ghét các quy trình phần mềm. Nếu đặt quy mô nhóm hợp lý và trao quyền cho lập trình viên để họ đạt mục tiêu, họ vẫn có thể làm tốt mà không cần luồng năng suất kiểu quản lý. Agile và những thứ tương tự tồn tại để nhà quản lý biện minh cho mức lương của mình
Tò mò không rõ ý nghĩa của câu "sprint không mang tính tự nguyện" là gì. Nhóm tự chọn đặc tính của sprint chứ không bị phân ngẫu nhiên. Đây là sự hợp tác giữa lãnh đạo, thành viên nhóm và các bên liên quan ngoài nhóm. Mong ai đó giải thích vì sao Scrum lại quá cứng nhắc
Ngay từ khi Scrum mới xuất hiện, đã thấy việc lập trình viên liên tục chạy sprint là vô lý. Sprint thì phải ngắn và nhanh, rồi sau đó cần nghỉ ngơi. Biến mọi công việc thành sprint là chuyện điên rồ
Scrum trên thực tế thường biến thành thứ tệ hơn là "Scrumpfall". Ban đầu dùng Scrum để giao tiếp trong đội ngũ làm việc từ xa, nhưng dần dần nó biến thành các mục tiêu do marketing dẫn dắt và những sprint đầy căng thẳng. Tình trạng kiệt sức của lập trình viên hiện ra rất rõ
Đầu những năm 2000, các nhóm kỹ sư tự vận hành mà không cần quản lý dự án. Phần mềm khi đó chưa liên kết chặt chẽ như bây giờ và chu kỳ triển khai cũng dài hơn. Hiện nay, với CI/CD và triển khai liên tục, mọi thứ diễn ra rất nhanh. SCRUM gây căng thẳng
Phần lớn cuộc thảo luận có thể tóm gọn thành: "Scrum ở chỗ tôi tệ vì X, Y, Z" và "đó không phải Scrum lý tưởng"
Đã phát triển phần mềm 40 năm và dù dùng phương pháp nào thì vẫn phải chia nhỏ công việc và cho thấy mục tiêu đã được hoàn thành. Với nhóm nhỏ và codebase đơn giản, Kanban có thể là đủ, nhưng với nhóm lớn hoặc giải pháp phức tạp thì vẫn cần báo cáo
Không dùng Agile, Scrum, Standup, v.v. Họp mỗi tuần một lần để sắp xếp lại ưu tiên và theo dõi tiến độ bằng hệ thống ticket. Để lập trình viên làm việc tự chủ. Cần dành nhiều thời gian cho việc viết code hơn là họp hành hay làm báo cáo TPS
Sau khi làm việc ở 8 công ty, cách tiếp cận Shape Up của Basecamp là thành công nhất. Điều quan trọng là hỏi "sẽ đầu tư bao nhiêu thời gian" chứ không phải "mất bao nhiêu ngày". Shape Up cung cấp thời gian hạ nhiệt giữa các chu kỳ 6 tuần và liên tục tạo ra sản phẩm thành công