Chuyển đến nội dung chính

Mô hình phát triển nhanh (agile) bắt người trong trong cuộc phải hành động!

Trong khoa học sắp xếp công việc ở một tổ chức, nếu sắp xếp theo từng khâu làm việc tuần tự bạn sẽ đạt hiệu quả cao và năng suất hơn. Do đó trong các công ty phần mềm việc tổ chức khoa học bắt đầu từ tổ chức lại công việc cho nhân lực bên trong, vì  vậy ta thấy có chức danh trong một công ty như: CEO, CFO, HR, Project manager, Developer, tester... Việc sắp xếp lại tổ chức hoạt động giúp nó hoạt động hiệu quả hơn. Trong mỗi dự án làm việc với khách hàng lại có một quy trình sản xuất khác nhau theo từng khâu: Quản lý dự án> BA > Code > Test ... (Giống như các khâu bình thường như trong ngành may mặt, sản xuất, kỹ nghệ...)

Bằng khái niệm: cộng tác hơn khi phát triển phần mềm để bỏ bớt những hoạt động dư thừa trong quy trình phát triển phần mềm kể trên gọi là Agile - Model. Và những bản thể của mô hình này là: Scrum, XP, Kanban. Agile (Nhanh gọn) nhằm bỏ bớt sự thừa thải của việc: làm tài liệu, chạy theo kế hoạch, làm việc mà không chú ý tới người dùng. Trong bài viết này không nói tới hiệu quả của làm Agile, bài này nói về sự bị động của người trong cuộc.

Dễ dàng mà thấy nếu bạn trong một dự án Scrum bạn sẽ bị lột trần và đập nát tính cách của mình. Bạn thích tĩnh lặng? vào dự án thì có người sẽ chất vấn bạn, bạn đang làm gì trong dự án, chức năng nào, có vấn đề gì không trong đó, muốn giúp không?... nhiều câu hỏi sẽ làm bạn sầu não nếu bạn là một con sâu thích gặm lá một mình, việc gì sẽ xảy ra nếu bạn thuộc dạng người ít nói? - Vào dự án Agile bạn sẽ khác đi!

Nếu không làm theo bạn sẽ bị chính dự án đẩy ra ngoài và như một kẻ thua cuộc đi dạo quanh dự án. Agile cần bạn nhanh và quyết liệt, nếu không dự án không trôi chảy. Bằng việc đưa ra câu hỏi cho người dùng, dự án sẽ cho bạn nhiều backlog (yêu cầu),  và việc chọn backlog để làm trong 2 tuần làm cho bạn nóng nhất có thể, và không có nhiều thời gian để chần chứ. Tester sẽ test trong một tuần, developer sẽ làm việc trong một tuần đầu và cho ra hiệu suất nhanh nhất, trong tuần thứ 2 sẽ cộng tác với tester để fix bug.

Khi mọi việc trễ nải, Agile thúc bạn với roi điện, PM là người sẽ cho bạn chọn backlog dễ làm để giảm thiểu rủi ro xuống, nếu không bạn sẽ rớt xuống đáy Agile.

Tóm lại: Mô hình phát triển nhanh (agile) bắt người trong trong cuộc phải hành động liên tục! Nên đã vào một đội Agile, xin hãy nhớ, chạy, chạy và chạy!


Nhận xét

Bài đăng phổ biến từ blog này

Hướng dẫn test negative (Test tiêu cực, test không hợp lệ, test ngược ...)

Hướng dẫn test negative Link tham khảo: Guru99.com Test tiêu cực - Dịch chuối quá - nên mình quyết định dùng từ gốc là: Negative testing. Bài hướng dẫn sẽ gồm các phần sau: Định nghĩa - Negative testing là gì. (What) Negative testing có quan trọng không? (Is) Làm như thế nào? (How) Ưu và nhược điểm! (Pros. & cons.) Định nghĩa negative testing! Để đảm bảo hệ thống chạy trơn tru và ổn định, chúng ta chỉ test những trường hợp bình thường và hợp lệ là chưa đủ. Vì vậy, để đảm bảo hệ thống chạy có thể xử lý được những trường hợp ngoại lệ ta cần test thêm những ngữ cảnh không hợp lệ! (negative testing). Làm được việc này thì hệ thống sẽ có kinh nghiệm xử lý khi các ngữ cảnh này xảy ra bất thường. ví dụ:  Thực tế đời sống: Xe buýt chở được 20 người. Ta cho 20 người cho xe chở bình thường. Nhưng chuyện gì sẽ xảy ra nếu nó chở 21 hoặc 30 người? Xe bị đổ, nghiêng, lún, lái khó ...=> Đây là negative case. Phần mềm: Email field có thể chứa đến 50 ký tự => Đ...

Hướng dẫn cơ bản về chẩn đoán mã lỗi OBD 2 trên ô tô

OBD2 - DTCs    1) Diagnostic Trouble Code (DTC) là gì? DTC hay còn gọi là mã lỗi là những mã được lưu trữ trong máy tính của xe hơi. Mỗi xe hơi hiện đại từ 1994 trở đi đều được trang bị một hộp đen có chứa máy tính, máy tính này có nhiệm vụ chẩn đoán tình trạng hiện tại của xe nhằm đảm bảo xe được vận hành an toàn không gây nguy hiểm cho người sử dụng (Ví dụ: nếu máy tính này phát hiện thắng xe đang có lỗi nó sẽ cảnh báo và không cho người dùng sử dụng xe). Mỗi mã được lưu trữ mang một ý nghĩa nhất định và chỉ ra nơi đang gặp vấn đề trong xe. Kỹ sư ô tô dựa vào đó để tìm và sửa lỗi. Mã lỗi này có thể đọc được bằng cách dùng thiết bị đọc mã lỗi do các bên thứ ba phát hành. Hiện tại trên thị trường có rất nhiều loại thiết bị đọc mã lỗi với các tính năng khác nhau. 2) DTC có đáng tin cậy không? Câu trả lời là: Có và không! Có vì nó chỉ ra những mã lỗi một cách dã chiến nhất theo ý hiểu của máy tính (Cá nhân tôi gọi là ngu ngốc). Ví dụ: nếu một bộ phận cảm biến nà...

Bảy nguyên tắc cơ bản của Kiểm thử phần mềm

Nội dung: nói và diễn giải về bảy nguyên tắc cơ bản trong testing software. Bài này là bài lý thuyết bổ sung và tester phải nắm được nằm lòng các nguyên tắc này! Bảy nguyên tắc (như khẩu huyết trong võ công): Kiểm thử tất cả mọi trường hợp là không thể được. ( EXHAUSTIVE testing is not possible ). Giải thích như sau: Một form có textbox cho phép nhập từ 1 -> 1.000.000.000.000. Nếu để kiểm thử nhập liệu cho textbox này ta phải kiểm thử 1k tỷ lần. Mỗi thao tác nhập cho là 1 giây, và phép toán kiểm tra nhập liệu là 0.1 giây nữa thì ta phải mất xấp xỉ 1k tỷ giây là khoảng 31k năm để thực thi nó. Đời người chỉ khoảng một trăm năm, vậy phải mất cả mấy nghìn đời để thực thi kiểm tra một textbox mà chưa kể đến nhiều đối tượng khác cho nên mới nói điều này là không thể làm được! (Chi phí nuôi nghìn người và giá trị bỏ ra là không xứng). Để xử lý thì ta: dùng kỹ thuật phân vùng tương đương, Phân nhánh nghiệp vụ, chia lớp xử lý... (Sẽ nói chi tiết sau). Kiểm thử là chỉ ra sai sót đang có ...