Làm thế nào để đạt được thực hành cá nhân tại các phương pháp phát triển nặng?

Tôi đang làm một công việc mới, nơi dự án cần phải đáp ứng các tiêu chuẩn chất lượng nghiêm ngặt, được ghi chép nhiều, quản lý rất chi tiết, sơ đồ UML và tất cả những điều trái ngược với "mã hóa cao bồi" nơi hầu hết kinh nghiệm làm việc trước đây của tôi . Hãy nghĩ về cách phát triển phần mềm hàng không vũ trụ hoặc thiết bị y tế quy mô lớn.

Tôi rất vui khi rời khỏi sự hỗn loạn của mã hóa cao bồi và tò mò muốn xem các phương pháp kỹ thuật nặng như thế nào. Nhưng làm thế nào người ta có thể nhanh chóng có được kinh nghiệm với các phương pháp nặng?

Bên cạnh đó chỉ đơn giản là trong công việc trong một số tháng / năm, đó là.

Với ngôn ngữ đơn thuần hoặc API mới, người ta có thể hack chương trình kiểm tra đồ chơi, đọc, cố tình mắc lỗi để xem điều gì xảy ra, v.v. Giống như trở nên giỏi đi xe đạp hoặc chơi nhạc cụ, thực hành là điều cần thiết. Thật dễ dàng để nhặt một cây sáo và dành nửa giờ mỗi ngày; không cần phải tham gia một dàn nhạc hay là một nhà tư vấn sáo toàn thời gian. Nhưng làm thế nào để thực hành các hoạt động kỹ thuật phần mềm lớn, phức tạp, liên quan đến các nhóm và phần lớn trong số đó là về giao tiếp và lập kế hoạch, và tránh truyền thông sai và vượt quá giới hạn về lịch trình và ngân sách?

Điều này dường như không thể làm solo. Có cách nào một số ít người có thể mô phỏng kỹ thuật toàn bộ dự án lớn ở quy mô nhỏ trong một thời gian ngắn (một ngày) không?

Có cách nào một số ít người có thể mô phỏng kỹ thuật toàn bộ dự án lớn ở quy mô nhỏ trong một thời gian ngắn (một ngày) không?

Vâng, điều này có thể ở một mức độ nào đó. Khoảng 10 năm trước, tôi đã tham gia một hội thảo tại hội nghị OOP ở Munich, nơi 16 người được giao nhiệm vụ phân tích và thiết kế sơ bộ cho một phần mềm doanh nghiệp nhỏ. Nửa đầu ngày chủ yếu là tìm kiếm một cấu trúc đội để giải quyết nhiệm vụ với 16 người, và nửa sau của ngày tập trung vào giải quyết nhiệm vụ với nhóm này.

Trong phần đầu tiên, chúng tôi được hướng dẫn chia 16 người thành nhóm bốn người. Mỗi nhóm bốn người phải đưa ra các đề xuất cho cấu trúc đội (dưới áp lực thời gian), sau đó, một quy trình bắn ra được áp dụng để đưa ra quyết định cấu trúc đội nào có thể là tốt nhất và nên được sử dụng cho phần thứ hai của hội thảo .

Thật không may, trong khi phần đầu tiên, chúng tôi đã phạm sai lầm khi cố gắng giao cho mỗi người trong số 16 người một công việc trong cấu trúc nhóm dự định. Sai lầm đó dẫn đến sự hỗn loạn trong nửa thứ hai - bởi vì 16 người là quá nhiều để giải quyết một nhiệm vụ như vậy. Một giải pháp hiệu quả có thể là chia 16 người một lần nữa thành các nhóm nhỏ hơn hoặc chọn 3 hoặc 4 người để làm công việc chính, nhưng trong lúc nóng nực, chúng tôi đã bỏ lỡ khi thấy điều này.

Tôi vẫn còn ấn tượng rằng tôi đã học được rất nhiều về các vấn đề điển hình mà người ta có thể gặp phải trong các tổ chức dự án lớn hơn ngày hôm đó. Tôi không biết nơi nào bạn có thể ghé thăm loại hội thảo như vậy ở đâu đó gần bạn, hoặc người cung cấp một thứ như vậy ngày nay, nhưng nếu bạn có cơ hội, tôi rất khuyên bạn nên tham dự nó.

Bắt đầu với một danh sách kiểm tra . (Bạn biết đó là bước đầu tiên, phải không?)
Hãy chắc chắn rằng danh sách kiểm tra liệt kê tất cả các tài liệu tiêu chuẩn cho dự án hiện tại của bạn. I E. Sơ đồ UML, thông số chức năng, thiết kế cấp cao và cấp thấp, v.v ... Kỹ sư hệ thống trong tôi sẽ đề xuất sử dụng RTVM (ma trận xác minh truy xuất nguồn gốc yêu cầu)

Chọn một chương trình mẫu để làm việc trên. Nếu bạn không thể đưa ra một cái, hãy google "mã katas" hoặc xem kho lưu trữ thử thách codejam của Google. Hoặc chỉ cần xây dựng một máy tính. :-)

Xây dựng các đặc tả chức năng cho chương trình mẫu của bạn. Sau đó chuyển sang thiết kế cấp cao, sơ đồ UML, v.v ... Xây dựng nó để đặc tả. Kiểm tra nó Mỗi khi bạn tìm thấy một lỗ hổng đáng kể trong thông số kỹ thuật của bạn (như được xác định bởi thực tiễn công việc hiện tại của bạn), thì bạn cần phải quay lại giai đoạn đó của SDLC và sửa đổi lại trước khi chuyển tiếp.

Đối với vòng đầu tiên của bạn, hãy tiếp tục và giữ cho nó nhỏ. Đạp xe trong suốt quá trình quan trọng hơn là quá mức trong bất kỳ giai đoạn cụ thể nào. Đối với các vòng tiếp theo, hãy thêm các tính năng mà bạn đã bỏ đi. Theo dõi, ghi nhật ký, phân tích hiệu suất, kiểm tra giàn giáo, vv .. Những gì bạn muốn thêm sẽ phụ thuộc vào những gì chủ nhân của bạn mong đợi cho công việc thực sự của bạn.

Sau khi bạn lặp đi lặp lại qua chu trình thiết kế / xây dựng / kiểm tra / lặp lại nhiều lần, bạn sẽ tích lũy được kỹ năng và kinh nghiệm trong các thành phần "hạng nặng" đang làm bạn lo lắng. Các lần lặp cũng sẽ cho bạn thấy sự kết nối giữa các giai đoạn khác nhau và tài liệu được tạo. Bài học quý giá ở đây cho thấy cách thay đổi mã 5 phút có thể có hiệu ứng gợn nhiều giờ ở nơi khác do cập nhật tài liệu và yêu cầu thử nghiệm.

Kinh nghiệm với thực hành "hạng nặng" chỉ đến từ việc làm thực tế. Không có cách nào để thực hành nó một cách hiệu quả. Bạn có thể, tuy nhiên, nghiên cứu nó. Có nhiều trường hợp nghiên cứu và nguồn bạn có thể nghiên cứu và suy ngẫm.

Tuy nhiên, không phải tất cả các thực hành bạn nhìn thấy hoặc nghiên cứu đều nhất thiết phải tích cực. Phát triển phần mềm là một thứ trôi chảy, và những gì có vẻ khó và nghiêm ngặt hôm nay có thể ngớ ngẩn và dư thừa vào ngày mai. Điều này xảy ra cả thông qua các công cụ mới và kinh nghiệm thử nghiệm nảy sinh từ các công ty khởi nghiệp đến các tổ chức bảo thủ hơn.

Về cơ bản, thay đổi và quản lý rủi ro dường như có một hình dạng duy nhất cho mỗi tổ chức. Đặt cược tốt nhất của bạn là giữ một tâm trí cởi mở, nhưng đừng mang quá nhiều giả định từ nhóm này sang nhóm khác.