Phát triển nhanh

"Chào, Amigo!"

"Chào, Bilaabo!"

"Hôm nay tôi sẽ nói với các bạn về cách các chương trình thường được phát triển."

"Vào thế kỷ 20, khi CNTT hiện đại còn sơ khai, mọi người dường như nghĩ rằng lập trình giống như xây dựng hoặc sản xuất."

"Mọi thứ thường diễn ra như thế này:"

" Khách hàng sẽ giải thích loại chương trình mà anh ta cần - nó nên làm gì và làm như thế nào."

" Các nhà phân tích kinh doanh sẽ lắng nghe anh ấy và lập một danh sách đầy đủ các yêu cầu của chương trình dựa trên những gì anh ấy nói."

"Sau đó, các nhà quản lý dự án sẽ chia các yêu cầu này thành các nhiệm vụ và cũng sẽ xác định lập trình viên nào sẽ thực hiện nhiệm vụ nào và theo thứ tự nào."

"Sau đó, các lập trình viên sẽ bắt đầu làm việc. Đôi khi họ sẽ làm việc vài năm(!)."

"Khi họ hoàn thành, chương trình đã được trao cho những người thử nghiệm."

"Những người thử nghiệm sẽ xem xét từng yêu cầu của chương trình để xác minh rằng chúng đã được triển khai và chương trình hoạt động như dự kiến."

"Nếu có gì đó không ổn, người kiểm tra sẽ ghi lại các lỗi và gửi chúng cho các lập trình viên."

"Sau đó, các lập trình viên sẽ sửa lỗi và gửi lại chương trình đã sửa cho người kiểm tra. Và chu kỳ sẽ lặp lại."

"Khi các lỗi chính đã được khắc phục, chương trình đã được trao cho khách hàng."

"Đó thực sự là cách mọi thứ diễn ra sao?"

"Chà, tất nhiên, tôi đã đơn giản hóa rất nhiều, nhưng điều đó khá gần với cách mọi thứ đã được thực hiện."

"Và một dự án thực sự có thể mất một năm rưỡi đến hai năm để hoàn thành?"

"Đôi khi nếu quá trình phát triển của một dự án thực sự kéo dài, họ sẽ chia nó thành các bản phát hành riêng biệt. Cứ sau 3-6 tháng, các nhà phát triển phải tạo một phần chức năng cụ thể của chương trình, kiểm tra nó, sửa tất cả các lỗi của nó và hiển thị nó cho người dùng. khách hàng."

"Đầu tiên, để anh ấy có thể chia sẻ ấn tượng của mình. Và thứ hai, và quan trọng hơn, để anh ấy tiếp tục trả tiền cho sự phát triển của chương trình."

"Tiếp tục trả tiền?"

"Hồi đó, quá trình phát triển thường mất nhiều thời gian hơn 2-3 lần so với kế hoạch. Và bởi vì các lập trình viên thường được trả lương theo giờ, nên chương trình trở nên đắt gấp 2-3 lần. Hơn nữa, lợi ích cũng giảm đi. Rốt cuộc, ngày nay khách hàng muốn gì với giá 100.000 đô la có thể không cần thiết trong 3 năm - đặc biệt là với mức giá gấp ba lần."

"Khách hàng có thường xuyên từ chối thanh toán không?"

"Phải. Sau đó, họ bắt đầu thêm hình phạt vào hợp đồng, nhưng điều này không cải thiện được tình hình. Việc phát triển phần mềm cứ kéo dài mãi. Và không ai có thể làm bất cứ điều gì cho dù họ có muốn."

"Nhưng tại sao?"

"Chà, đầu tiên, có quá ít thông tin được biết đến trong giai đoạn lập kế hoạch. Thông thường, ngay từ đầu, không ai có thể đoán trước được các vấn đề mà các lập trình viên sẽ gặp phải."

"Nhưng các lập trình viên có kinh nghiệm lẽ ra phải có thể thấy trước mọi thứ, phải không?"

"Bạn có thể thấy rằng lập trình là một nghề độc đáo."

"Một công nhân bình thường thường làm đi làm lại một công việc. Thợ đồng hồ làm đồng hồ, đầu bếp nấu ăn, giáo viên dạy học, bác sĩ chữa bệnh, v.v."

"Mỗi người trong số những chuyên gia này về cơ bản làm cùng một việc ngày này qua ngày khác. Kết quả là họ bắt đầu ngày càng làm tốt hơn công việc của mình."

"Trong lập trình, cách tiếp cận là khác. Ngay khi một lập trình viên đối mặt với cùng một nhiệm vụ hàng ngày, anh ta sẽ viết một hàm, mô-đun hoặc chương trình để thực hiện nó và không bao giờ quay lại với nó nữa."

"Mỗi lập trình viên thường giải quyết mỗi nhiệm vụ một lần trong đời."

"Một cái gì đó giống như các nhà khoa học hoặc kỹ sư thiết kế phát minh ra mọi thứ."

"À. Chà, vai trò quan trọng nhất trong một dự án là gì?"

"Hmm, tôi nên trả lời thế nào đây. Thật dễ dàng để nói điều gì là quan trọng nhất, nhưng xác định điều ít quan trọng nhất thì rất khó."

" Công việc chính của người kiểm tra ( Q uality  A ssurance, QA )  là theo dõi trạng thái của chương trình và báo cáo lỗi kịp thời. Người kiểm tra càng phát hiện ra lỗi sớm thì càng có thể sửa được nhiều lỗi.  Người kiểm tra giỏi ảnh hưởng đến chất lượng sản phẩm nhiều hơn một lập trình viên giỏi sẽ làm được ."

"Tại sao lập trình viên không thể kiểm tra chương trình của chính họ. Rốt cuộc, họ không biết rõ hơn người kiểm tra cái gì hiệu quả và không hiệu quả sao?"

"Một lập trình viên giỏi đơn giản là không có khả năng trở thành một người kiểm thử giỏi. Một lập trình viên biết chương trình hoạt động thực sự tốt như thế nào, vì vậy anh ta hoặc cô ta luôn sử dụng nó theo một cách nhất định. Trái ngược với những người dùng thông thường sử dụng chương trình theo bất kỳ cách nào họ muốn. "

"Ngoài ra, người kiểm tra không kiểm tra những gì chưa hoạt động. Người kiểm tra kiểm tra chức năng hoặc các phần của chương trình mà lập trình viên nói là đã hoạt động gần như hoàn hảo."

"Và khi người thử nghiệm tìm thấy vô số lỗi trong chức năng đó và lập trình viên sửa chúng, thì sản phẩm thực sự sẽ tiến gần hơn đến sự hoàn hảo."

" Nhiệm vụ chính của một lập trình viên ( S oftware  D eveloper  E ngineer,  D eveloper ,  SDE ) là triển khai chức năng mới. Hay nói một cách đơn giản hơn là thực hiện các nhiệm vụ được giao cho họ. Khi lập trình viên được giao nhiệm vụ với các tính năng mới , họ thực hiện chúng. Khi họ được chỉ định lỗi, họ sẽ sửa lỗi."

"Nhưng đôi khi có nhiều nhiệm vụ khó khăn hơn, chẳng hạn như đưa ra kiến ​​trúc cho chương trình hoặc các phần của chương trình. Kiến trúc được đề xuất càng tốt thì càng dễ hoàn thành công việc trong tương lai."

“Vấn đề là kiến ​​trúc cần phải được chọn ngay từ đầu, nhưng phải đến khi bạn đang ở giữa quá trình phát triển thì mới biết rõ liệu bạn có chọn đúng kiến ​​trúc hay không.”

"Ngoài ra, nếu kiến ​​trúc thành công và chương trình trở nên tuyệt vời, thì khách hàng có thể sẽ muốn sử dụng nó làm cơ sở cho các phiên bản mới của chương trình."

"Đây là những gì tôi đang nhận được."

"Dù bạn chọn kiến ​​trúc nào, sẽ luôn có một loạt các thay đổi, bổ sung và các tính năng mới mà kiến ​​trúc không tính đến."

"Đây là một ví dụ tốt."

"Một khách hàng yêu cầu bạn xây một tòa nhà 5 tầng, vì vậy bạn thiết kế kiến ​​trúc và xây dựng ngôi nhà."

"Sau đó, khách hàng yêu cầu thêm một câu chuyện khác, rồi một câu chuyện khác, v.v."

"Nhưng các bức tường của tầng một không được thiết kế để chịu được trọng lượng lớn như vậy, và nền móng cũng vậy. Vì vậy, mọi thứ phải được làm lại."

“Nhưng sau khi tòa nhà 5 tầng xây xong, nếu khách hàng ngay lập tức quyết định muốn tòa nhà 50 tầng thì sao?”

"Sẽ dễ dàng hơn nếu phá hủy cấu trúc hiện có và xây dựng lại mọi thứ từ đầu..."

"Nhưng tôi có một lời khuyên cho bạn về kiến ​​trúc."

"Kiến trúc của ứng dụng trước hết phải linh hoạt, có nghĩa là bạn sẽ không phải bắt đầu lại từ đầu nếu quyết định làm lại một nửa ứng dụng. Loại kiến ​​trúc này thường được gọi là linh hoạt và mô-đun . "

" Công việc chính của người quản lý dự án là đưa ra quyết định. Người quản lý dự án là người nhìn thấy bức tranh toàn cảnh và đưa ra quyết định dựa trên quan điểm đó."

"Giả sử rằng trong quá trình phát triển, rõ ràng là một nhiệm vụ nhất định sẽ không được hoàn thành theo kế hoạch. Khi đó, người quản lý dự án có thể:"

" a)  cố gắng thương lượng với khách hàng để sửa đổi nhiệm vụ"

" b)  phân bổ nhiều thời gian hơn cho nhiệm vụ"

" c)  mang lại nhiều lập trình viên có kinh nghiệm hơn từ các dự án khác."

"Và còn nhiều khả năng khác."

"Mỗi lựa chọn đều yêu cầu bạn phải hy sinh một thứ gì đó, và công việc của người quản lý là giảm thiểu tổng thiệt hại từ những hy sinh này. "

"Ví dụ, giả sử các đối thủ đánh cắp lập trình viên chính bằng cách trả cho anh ta số tiền gấp đôi."

"Người quản lý dự án có thể:"

" a)  không làm gì cả. Lập trình viên sẽ rời đi và dự án có thể sẽ bị tụt lại phía sau và bị phạt."

" b)  tăng lương gấp đôi. Sau đó, mọi người khác trong nhóm cũng sẽ muốn tăng lương. Nếu bạn cho tất cả họ nhiều tiền hơn, thì chi phí của dự án sẽ tăng lên và nó có thể trở nên không có lãi."

" c)  một số tùy chọn khác mà bạn nghĩ ra."

"Tôi hiểu rồi."

"Với một người quản lý dự án tồi, một nhóm tốt thường kéo dài dự án, nhưng không phải lúc nào cũng vậy."

"Một người quản lý giỏi với một nhóm các lập trình viên trung bình hầu như sẽ luôn hoàn thành một dự án nhanh hơn một người quản lý tồi với một nhóm các lập trình viên xuất sắc."

"Tôi hiểu rồi."

"Được, chúng ta nghỉ ngơi một lát, rồi chúng ta tiếp tục."