Tôi làm việc cho một công ty nhỏ. Bộ phận phát triển phần mềm của công ty trước khi tôi được thuê bao gồm một anh chàng làm việc quá sức tự học. Bây giờ tôi đã viết phần mềm cho công ty được vài năm, tôi đã được giao nhiệm vụ thiết lập các thực tiễn phát triển phần mềm chính thức cho toàn công ty. Chúng tôi hiện không có hướng dẫn, ngoài

Viết mã, kiểm tra nó, đặt nó trong một tệp .zip và gửi nó cho khách hàng. Điểm thưởng cho TDD và kiểm soát phiên bản.

Sếp của tôi muốn tôi viết một cuốn sổ tay phát triển phần mềm xác định các quy trình, giao thức, công cụ và hướng dẫn chung mà chúng tôi sử dụng để hoàn thành công việc. Nói cách khác, anh ta muốn có một cuốn sách "Đây là những gì chúng tôi làm ở đây" để giúp nhân viên mới làm quen với cách chúng tôi làm việc cũng như giúp sếp của tôi hiểu những gì tay sai của anh ta đang làm và cách họ làm nó

Theo cách tôi nhìn thấy, tôi đang đặt một nền tảng và nó cần được thực hiện đúng. Làm thế nào bạn sẽ đi về việc chọn chủ đề cho một cuốn sổ tay như vậy?Bạn có thể cung cấp một số chủ đề ví dụ?

Lưu ý bên lề: Nếu có vấn đề, chúng tôi chủ yếu là một cửa hàng Microsoft .NET. Và chúng tôi đang xem xét các thực tiễn nhanh như XP và Scrum, nhưng chúng tôi có thể phải sửa đổi rất nhiều để chúng hoạt động trong công ty của chúng tôi.

Tôi sẽ chia nó thành các phần như

• Nhân viên hiện tại - tên và chức danh (lý tưởng với hình ảnh)
• Các ứng dụng, đăng nhập vào chúng, dữ liệu cần biết và yêu cầu cấp phép đã được gửi
• Dấu trang đến các trang web công ty và các trang web bên ngoài quan trọng liên quan đến doanh nghiệp
• Các ứng dụng mà công ty sử dụng cho comms, email, đặt phòng hội nghị, chia sẻ màn hình
• Thủ tục cho các hoạt động liên quan đến công ty như biên lai chi phí, đặt chỗ du lịch
• Thiết lập máy phát triển. Mô tả quá trình thiết lập một máy phát triển mới một cách chi tiết. Điều này thường là 'dự kiến' chỉ mất một ngày, nhưng thường mất 3-5 ngày trong thực tế.
• Quá trình phát triển, cách thức làm việc được theo dõi, phân công và cập nhật và những công cụ nào được sử dụng.
• Làm thế nào để kiểm tra, những gì để kiểm tra, khi nào kiểm tra, nơi để kiểm tra.
• Các tiêu chuẩn mã hóa bao gồm các quy ước đặt tên tệp và các tiêu chuẩn cụ thể về ngôn ngữ.
• Làm thế nào để xử lý lỗi, nơi để ghi lại chúng, làm thế nào để sửa lỗi.
• quá trình triển khai, những điều quan trọng cần biết để thúc đẩy sản xuất.
• Làm thế nào để tài liệu, những gì để tài liệu, khi nào tài liệu.
• Trong đó công cụ 'là', ví dụ: vị trí cho Mã, Dữ liệu, Tiêu chuẩn, Tài liệu, Liên kết và các tài sản khác.

Làm cho nó thành mô-đun cũng sẽ cho phép bạn hoặc người khác cập nhật các phần riêng biệt, ví dụ như tên và vị trí của nhân viên sẽ thay đổi thường xuyên khi mọi người đến và đi.

Đối với mỗi phần tôi sẽ cố gắng viết nó theo quan điểm của 'người mới'. Quan trọng nhất sẽ là đảm bảo nó thực sự có ý nghĩa với một người mới. Sếp của bạn rõ ràng không phải là người phù hợp để xem xét điều này vì ông không phải là đối tượng dự định. Anh ấy là quyền muốn nó, chỉ cần đảm bảo những nội dung không kết thúc được thử nghiệm bởi anh ấy. Ngoài ra, cả một "người mới" đều chỉ có "1 tuần" là một người mới ... và chỉ có một quan điểm. Vì vậy, có khả năng (và được khuyến nghị) rằng tài liệu sẽ được tinh chỉnh với mỗi nhân viên mới. Trên thực tế, đó cũng là một nhiệm vụ khá tốt để chỉ định chúng cho tuần đầu tiên của họ, tức là "Cập nhật hướng dẫn cho người mới".

Đối với Agile / SCRUM:

Phần khó nhất khi làm Agile và SCRUM là 'thực sự' làm việc đó.

Để đọc tôi sẽ bắt đầu tại http://agilemanifesto.org/ và đi từ đó.

Tôi cũng sẽ đọc http://www.halfarsedagilemanifesto.org/ nổi tiếng về việc bạn thực sự phải nắm lấy tất cả các khía cạnh để nó hoạt động. Nếu bạn phải sửa đổi nhiều Agile cho các tổ chức của mình, có khả năng mọi người muốn có lợi ích - mà không sử dụng các quy trình chính xác. Thực tế này nên được trình bày để tránh bất kỳ sự nửa vời.

Có vẻ như bạn sẽ phải giới thiệu một số thực hành trước khi bạn ghi lại chúng!

a) Kiểm soát nguồn - làm thế nào để bạn lưu trữ các nguồn của mình và kiểm soát sửa đổi

b) Quản lý và theo dõi phát hành - làm thế nào để bạn xây dựng, đánh số bản phát hành, so sánh một ứng cử viên phát hành hiện tại với bản phát hành trước

c) Quản lý sự cố - làm thế nào để bạn theo dõi các lỗi trong bản phát hành của mình.

Đây là những điều khá cơ bản nhưng chúng có thể mất rất nhiều thời gian (và có thể tốn tiền) để thực hiện.

Các chủ đề mà tôi sẽ đưa vào sổ tay của nhà phát triển:

• Vai trò / vị trí trong bộ phận và trách nhiệm tương ứng của họ
• Yêu cầu phần mềm máy của nhà phát triển (tức là môi trường phát triển bắt buộc)
• Nơi và cách truy cập kho lưu trữ mã nguồn
• Các công cụ phát triển đang được sử dụng (ví dụ IDE)
• Kiểu mã hóa / tiêu chuẩn
• Tiêu chuẩn tài liệu
• Quá trình kiểm tra
• Xây dựng quy trình
• Quy trình triển khai
• Hỗ trợ và quản lý vấn đề quy trình
• Nơi nhận phiên bản cập nhật nhất của cẩm nang này

Hãy nhớ rằng sổ tay này chỉ nên chứa các mục cụ thể để phát triển, chứ không phải thông tin toàn công ty (cần có trong sổ tay nhân viên).

Sử dụng kiểm soát nguồn

• Những công cụ kiểm soát nguồn bạn đang sử dụng.
• Cú pháp của các lệnh / công cụ phổ biến trong IDE.
• Chiến lược phân nhánh / hợp nhất.
• Đơn vị của một cam kết nên là gì? Bao lâu là quá dài để có một tập tin kiểm tra / không cam kết?
• Mức độ "quyên góp" nào cho một cam kết / đăng ký biểu thị? Biên dịch? Bài kiểm tra đơn vị vượt qua? Đã đánh giá?
• Những gì được dự kiến ​​sẽ được bao gồm trong các ghi chú cho một cam kết / đăng ký.
• Thủ tục rollback.