Michael Jordan liệu có trở thành huyền thoại bóng rổ nếu không có tư duy phát triển? Cùng xem lại cách người đàn ông này nói về thành công: " Tôi đã ném hụt hơn 9000 cú ném trong sự nghiệp của mình. Tôi đã thua 500 trận đấu. 26 lần tôi đã được tin tưởng giao cho cú ném quyết định chiến thắng và đã ném hụt...Tôi thất bai hết lần này tới lần khác trong cuộc đời tôi!

VÀ ĐÓ LÀ LÝ DO TÔI ĐÃ THÀNH CÔNG.

Quản lý rủi ro trong dự án Agile (Scrum) là câu hỏi nhiều người gặp phải trong quá trình tìm hiểu về Agile và Scrum. Ở bài viết này mình sẽ chia sẻ về nội dung này để mọi người có thêm góc nhìn.

1. Đặc điểm quản lý rủi ro trong dự án Agile/Scrum.
2. Thực hành quản lý rủi ro trong Agile.
3. Có thể sử dụng 2 phương pháp quản lý rủi ro cùng nhau không.
4. Tổng kết.

Phần 1: Đặc điểm của quản lý rủi ro trong dự án áp dụng Agile và Scrum

Đầu tiên, xin quay lại với tuyên ngôn Agile:

Cá nhân và tương tác hơn là quy trình và công cụ.
Phần mềm chạy tốt hơn là tài liệu đầy đủ.
Cộng tác với khách hàng hơn là đàm phán hợp đồng.
Phản hồi với thay đổi hơn là tuân theo kế hoạch.
Mặc dù những điều ở bên phải vẫn còn giá trị, nhưng chúng tôi đề cao những điều ở bên trái. Xem thêm

Với sự hiểu biết về Agile và Scrum, bạn dễ dàng nhận thấy việc quản lý rủi ro trong dự án áp dụng Agile/Scrum được thể hiện ở các đặc điểm của Agile hay trong các sự kiện của Scrum Framework.

– Lặp và tăng trưởng: Scrum chia “dự án” thành các giai đoạn – sprint kéo dài từ 1-4 tuần. Kết quả của mỗi sprint là một phần tăng trưởng có thể sử dụng được (tuỳ thuộc định nghĩa hoàn thành, phần tăng trưởng này có thể deploy hoặc không). Việc theo dõi thường xuyên và liên tục được phần tăng trưởng này giúp khách hàng tiếp cận được kết quả sản phẩm sớm hơn và đưa ra các phản hồi. Việc này giúp tránh lãng phí nguồn lực, thời gian và chi phí. Việc theo dõi kết quả của nhóm phát triển thường xuyên cũng giúp PO (SM) nhận định được năng suất thực tế của nhóm. Từ đó đưa ra các chiến lược để tối ưu hoá được năng suất lao động. Xem thêm

Hồi mới tập tễnh đi dạy, mình có một số anh chị đồng nghiệp thỉnh thoảng lại chê sinh viên dốt khiến cho kết quả học tập của lớp kém. Và bởi vì sinh viên dốt, cho nên Giảng viên có làm gì thì cũng không thể khá lên được, thành ra cuối cùng Giảng viên không làm gì cả.

Mình cũng hay tiếp xúc với sinh viên, của nhiều trường khác nhau, cũng nghe nhiều bạn chê học trong trường chán, chê thầy dạy khó hiểu. Và bởi vì nhà trường kém cho nên không học được, chứ đâu phải lỗi của mỗi sinh viên, thành ra học không tốt cũng là chuyện hợp lí. Xem thêm

Bìa sách có gạch nối từ A tới Y có lẽ cũng là cách chơi chữ của tác giả cùng với tên sách – Agile từ A tới Y (chưa tới Z). Nội dung sách gồm 3 phần rõ ràng: Agile, tổ chức, cá nhân. Các nội dung trong sách thì mình cũng đọc, góp nhặt từ nhiều nơi, tuy vậy cũng học hỏi được rất nhiều thứ từ cách nhìn nhận của tác giả và … 1 số thứ chưa biết 😀

Về Agile – phần 1, tác giả có 2 chương đầu nói về thực trạng của việc phát triển phần mềm và đưa ra câu hỏi tu từ: “Liệu Agile có phải là giải pháp?”. Phần này mĩnh sẽ note lại trong 1 bài viết khác bới nó khá dài và có nhiều câu chuyện để cùng bàn luận mổ xẻ. Lướt tiếp phần 1 điều mình thích là ở chương 5 phần kĩ thuật và công cụ, phần này có đề cập tới database versioning và branch strategy làm mình khá tâm đắc. Thực sự với mỗi team làm phần mềm, đây là 2 thứ cực kì quan trọng và đáng giá để nghiên cứu và đưa nó vào quy trình, nhất là khi team bạn làm Agile (Scrum). Tư tưởng ở đây cho việc database versioning là coi database như một version của code, commit kèm theo source. Luôn có script update database và restore database đi cùng nhau cho 1 version, điều này khiến CSDL của bạn được đảm bảo, có truy vết và luôn ở trạng thái có thể backup được lại phiên bản ổn định. Branch strategy với tư tưởng forward-intergration (tích hợp trước) giúp việc đảm bảo luôn có sự ổn định ở branch develop là 1 ý tưởng hay có thể áp dụng ngay lập tức cho nhóm của bạn. Xem thêm

Nếu phải chọn một hành động quan trọng nhất trước khi bắt tay làm bất cứ một công việc nào, bạn sẽ chọn hành động gì? Tôi đã hỏi rất nhiều người và câu trả lời tôi thường nhận được là lập kế hoạch. Thật đáng tiếc, đó không phải là câu trả lời tốt. Lập kế hoạch chỉ nên là hành động đứng thứ hai bởi nó phải nhường chỗ cho hành động định nghĩa công việc. An bắt đầu việc học tiếng Anh bằng cách lên một lịch trình chi tiết về việc đăng ký một khoá học, dành mỗi thời gian cuối tuần để luyện tập thêm; sau 6 tháng thực hiện kế hoạch hoàn hảo, An có thể đọc và viết các tài liệu bằng tiếng Anh, song An vẫn thấy thất vọng vì khả năng giao tiếp của mình. Một kế hoạch hoàn hảo cùng những nỗ lực tuyệt vời đã được An thực hiện nhưng không mang lại hiệu quả như An mong đợi; chỉ vì An đã bỏ đi hành động đầu tiên, và cũng là hành động quan trọng nhất, định nghĩa hoàn thành cho việc học tiếng Anh. Xem thêm

Câu hỏi:
Làm sản phẩm nó nên áp dụng Scrum không?

Vấn đề gặp phải:

Tình hình là công ty mình đang chuyển đổi sang mô hình scrum cho việc phát triển sản phẩm. Nó khá là khó khăn khi mà các tính năng phải chia nhỏ hết mức để có thể hoàn thành Sprint Goal. Nhưng chính vì chia nhỏ ra như vậy mà End User không được có trải nghiệm tốt nhất khi tính năng không hoàn thiện 100% (vì chia nhỏ cho từng sprint). 2 tuần để làm 1 số tính năng mà còn phải fix production bug cũ + thêm không đánh giá được hết ảnh hưởng nền chuyện không hoàn thành Sprint Goal là chuyện thường xảy ra. Có cách nào khắc phục được không. Xem thêm

1. Khi nào thì branch off
2. Khi nào thì merge 1 branch vào 1 branch khác?

Gitflow

– master: branch chính, luôn ở trạng thái deploy-ready (có thể deploy), tức là đạt sự ổn định cao. Branch master chỉ được merge vào từ branch develop.
– develop: branch phục vụ việc phát triển. Chừng nào một commit còn tồn tại trên branch develop mà không được merge vào branch master, chức năng đó đang trong quá trình phát triển và chưa đạt sự ổn định để deploy. Xem thêm

 
Công việc hàng ngày

• Mục tiêu rõ ràng (những kỳ vọng và quy định phải rõ ràng, và mục tiêu có thể đạt được, phù hợp với kĩ năng và khả năng của mỗi người).
• Tập trung và có trọng điểm, tập trung cao độ vào một lĩnh vực nhất định cần được chú ý.
• Không có cảm giác tự ti, đề cao hành động và nhận thức.
• Phản hồi trực tiếp và ngay lập tức (nhanh chóng nhìn thấy các thành công và thất bại của một chuỗi hoạt động, nhờ thế có thể điều chỉnh hành vi nếu cần thiết).
• Cân bằng giữa cấp độ khả năng và thử thách (hoạt động đưa ra không quá khó cũng không quá dễ).
• Mỗi người đều có khả năng tự kiểm soát trong mỗi tình huống hay hoạt động.
• Mỗi hoạt động đều hiển nhiên đem lại kết quả, vì thế không cần quá nhiều cố gắng trong hành động.
Xem thêm

Chúng ta biết rằng Scrum và Kanban là 2 phương pháp làm việc theo nguyên lý Agile. Scrum là phù hợp nhất cho sản phẩm và các dự án phát triển. Kanban là tốt nhất cho việc hỗ trợ sản xuất. Chúng ta sử dụng Scrumban – sự kiết hợp giữa các tính năng tốt nhất của 2 framework này cho các dự án bảo trì.
Ngày nay Scrumban trở nên phổ biến trong các ngành dịch vụ, nơi chúng ta có các dự án phát triển và bảo trì. Xem thêm