Bạn sẽ thêm gì vào Danh sách kiểm tra dự án phát triển phần mềm này? [đóng cửa]


14

Tôi là một fan hâm mộ lớn của danh sách kiểm tra. Có Danh sách kiểm tra du lịch , Danh sách kiểm tra di chuyển và thậm chí là Danh sách kiểm tra Scrum .

Bối cảnh : bạn đã được một tập đoàn lớn thuê và giao nhiệm vụ thiết lập toàn bộ môi trường phát triển phần mềm, quy trình, nhóm, v.v. Bạn có "carte blush". Bạn sẽ chịu trách nhiệm cho việc tạo ra các mức tăng hoạt động của phần mềm. Quy mô dự án: 2000 man / ngày.

Những mục bạn sẽ thêm vào danh sách kiểm tra sau (cố ý nhỏ và không đầy đủ):

  • Cài đặt máy chủ tích hợp liên tục
  • Viết một DoD
  • Viết một hướng dẫn mã hóa một trang
  • Tạo một sản phẩm tồn đọng
  • Cài đặt hệ thống theo dõi lỗi
  • Lịch trình thời gian mặt thường xuyên

Câu trả lời:


10

* 1.) Nói chuyện với các nhà phát triển để xem những gì họ thực sự cần! *

2.) Điều tra một giải pháp để đưa ra nhiều môi trường thực sự nhanh chóng (nghĩ các trường hợp đám mây công cộng hoặc riêng tư hoặc các máy ảo cũ lỗi thời nếu bạn không tuân thủ từ thông dụng)

3.) Kiểm soát nguồn / phiên bản

4.) Hệ thống đánh giá mã (Crucbile / Fisheye làm ví dụ)

5.) Tường Kanban (hoặc một cái gì đó tương tự)

6.) Giao thức giao tiếp (trò chuyện thời gian thực là một điểm cộng lớn), wiki cũng khuyến khích sự hợp tác. Điều này cũng bao gồm các mối quan hệ công chúng trong nội bộ - bạn sẽ tham gia với chủ doanh nghiệp, nhân viên hỗ trợ công nghệ và các nhóm khác như thế nào?

7.) Bảng trắng điện tử

8.) Môi trường thoải mái cho các nhà phát triển (ghế dài, bàn, khu vực thư giãn, WiFi tốt, v.v.)

9.) Cà phê tuyệt vời !!!


cofee tạo ra sự khác biệt :) + 1
RBA

bảng trắng điện tử bạn sử dụng là gì?

@Pierre 303 - In ra kết quả của phiên bảng trắng a (ảnh chất lượng cao sẽ thực hiện cùng một mẹo tôi đoán).
Martijn Verburg

8
  • Thiết lập chuỗi công cụ - IDE, máy chủ CI, máy chủ chất lượng mã, kiểm soát nguồn, máy chủ web, cơ sở dữ liệu, theo dõi vấn đề, v.v.
  • Sao lưu - Mỗi người trong nhóm có vai trò gì? Những quy trình / mô-đun nào anh ta 'sở hữu' và ai là người dự phòng của anh ta?
  • (Chấp nhận người dùng) Thiết lập môi trường thử nghiệm - Không chỉ tích hợp liên tục w. kiểm tra đơn vị, nhưng kiểm tra tích hợp để bao gồm những điều thực sự tồi tệ, nhiều nền tảng, máy chủ ứng dụng, VM, v.v.
  • Thiết lập kiểm tra hiệu suất - Càng sớm càng tốt, vì bạn sẽ cần dữ liệu lịch sử để trả lời "Với tính năng / cột mốc nào mà hiệu suất giảm quá tệ?"
  • (Người dùng cuối) Phác thảo tài liệu - Điều gì sẽ có trong tài liệu? Loại tài liệu nào là cần thiết?
  • Kênh tiếp thị - Các cột mốc nội bộ và phát hành bên ngoài được công bố như thế nào? Bạn có một cái tên hay cho phần mềm, logo, màu sắc, từ ngữ, v.v.?
  • Truyền thông nội bộ - Làm thế nào để các đồng nghiệp từ các đội khác sẽ được thông báo về những thay đổi? Làm thế nào là hợp tác được thực hiện? Wiki? Quyền truy cập?
  • Đảm bảo chất lượng con người & quy trình - Ai sẽ kiểm tra những gì, tần suất và với tiêu chí gì?
  • Quá trình phát hành - Khi nào, bao lâu, như thế nào, ai đang làm việc đó, ai đang nhận được bản phát hành, v.v.
  • Quản lý rủi ro - Kịch bản trường hợp xấu nhất (từ một dự án mgmt POV và từ một POV thời gian chạy, ví dụ: 'khách hàng đang mất tiền vì phần mềm bị lỗi tại mô-đun X, kế hoạch dự phòng là gì?)
  • Bảo vệ môi trường phát triển cốt lõi, ví dụ ảo hóa nó để ký quỹ
  • Địa điểm cho các cuộc họp chính thức và không chính thức
  • Đào tạo hoặc giới thiệu cho tất cả mọi người, vì vậy họ biết tất cả các thiết lập là gì, mỗi phần là gì và cách họ sử dụng nó.
  • Xác định người chăm sóc và cung cấp cho anh ta tất cả mọi thứ (ví dụ như quyền) mà anh ta cần thực sự quan tâm khi mọi thứ trở nên tồi tệ

+1 để sao lưu và đào tạo
Liviu T.

sao lưu, mặc dù tôi nghĩ rằng một số trong số này là vô cùng.
BlackICE

5

Nhận xét về hậu quả - Vì bạn đang làm việc trên các khối, tôi sẽ lên lịch đánh giá từ một đến hai giờ (tùy theo quy mô nhóm) để gặp mặt trực tiếp (nếu có thể), nơi mọi người đi xung quanh và nói điều gì đã được thực hiện đúng, điều gì đã được thực hiện có thể được thực hiện tốt hơn, và những gì không cần thiết. Có thể học hỏi từ những sai lầm của bạn trong quá trình phát triển sớm có nghĩa là bạn có thể tránh thực hiện chúng sau này khi bạn không có nhiều thời gian để làm việc.


4

Hãy bắt đầu với việc thuê một đội ngũ chuyên gia giỏi cho dự án của bạn. Trong một ứng dụng kinh doanh thông thường, bạn sẽ cần phải thuê một nhà phát triển cơ sở dữ liệu và một dba, một người QA, một quản trị viên hệ thống, một nhà phân tích kinh doanh, nhà phát triển ứng dụng, một chuyên gia UI và nhóm lãnh đạo tối thiểu. DBA, Quản trị hệ thống, các nhà phân tích kinh doanh và QA nên ở trong một chuỗi báo cáo riêng biệt từ nhóm phát triển. Chuyên gia cơ sở dữ liệu phát triển nên báo cáo cho lãnh đạo kỹ thuật giống như các nhà phát triển ứng dụng và chuyên gia UI.

Thiết lập không gian văn phòng. Văn phòng tư nhân là tuyệt vời nếu bạn có thể có được chúng (tôi chúc bạn gặp nhiều may mắn với điều này), nhưng ở mức tối thiểu bạn cần bàn, điện thoại, máy tính, bảng trắng và một vài phòng hội nghị chuyên dụng. Hãy chắc chắn rằng có một nơi để nghỉ trưa, tủ lạnh, nước ngọt, đồ ăn nhẹ và cà phê có sẵn. Nước ngọt và cà phê miễn phí thậm chí còn tốt hơn.

Thiết lập máy chủ dev / qa / staging và prod cho cả ứng dụng và cơ sở dữ liệu. Cơ sở dữ liệu không nên nằm trên cùng một máy chủ với các ứng dụng. Tùy thuộc vào quy mô và phạm vi của dự án, bạn có thể cần nhiều máy chủ hoặc SAN, vv cho mỗi môi trường.

Ngay sau khi máy chủ được thiết lập, hãy lên lịch sao lưu tệp sytem, ​​cơ sở dữ liệu và nhật ký giao dịch cơ sở dữ liệu. Làm điều này ngay ngày đầu tiên mọi thứ được thiết lập. Thuê một công ty như Iron Mountain để sao lưu hàng tuần.

Thiết lập một hệ thống kiểm soát nguồn và tạo một tài liệu mô tả cách sử dụng nó. Đừng quên nhấn mạnh rằng TẤT CẢ các thay đổi cấu trúc cơ sở dữ liệu và chèn dữ liệu cho các bảng loại tra cứu sẽ nằm trong các tập lệnh trong kiểm soát nguồn. Điều này sẽ làm cho việc triển khai dễ dàng hơn.

Mua phần mềm thương mại hoặc tải xuống phần mềm nguồn mở cho bộ công cụ bạn quyết định sử dụng với giấy phép cho tất cả người dùng thích hợp.

Mua máy phát triển đang la hét nhanh và có hai màn hình. Mua ít nhất một máy người dùng thử nghiệm đang rên rỉ chậm và điển hình cho những gì người dùng sẽ có trên máy tính để bàn của họ.

Huấn luyện các nhà phát triển mới của bạn theo cách bạn muốn mọi thứ được thực hiện. Nếu bạn có một nhóm đủ lớn để có một số nhà phát triển cơ sở, thì hãy lên lịch đào tạo thêm cho họ và bao gồm thời gian trong kế hoạch dự án của bạn. Giám sát đàn em rất chặt chẽ trong ít nhất ba tháng. Giám sát tất cả nhân viên mới trong tháng đầu tiên. Loại bỏ các nhà phát triển gỗ chết và lừa đảo càng sớm càng tốt.

Xác định những gì cần phải được thực hiện theo thứ tự (đường dẫn quan trọng). Không chỉ định các nhiệm vụ ở cuối đường dẫn quan trọng cho đến khi các nhiệm vụ mà chúng phụ thuộc hoàn thành.

Tạo kế hoạch kiểm tra và yêu cầu.

Thiết lập các cuộc họp tiến độ thường xuyên theo lịch trình với khách hàng. Họ xứng đáng được biết những gì bạn đang làm và những rào cản là gì. Đừng thất bại khi nói với họ khi mọi thứ sẽ muộn. Nếu bạn còn ba tuần nữa mới đến hạn chót và bạn đã biết bạn sẽ bỏ lỡ nó, thâm hụt đó sẽ không biến mất một cách kỳ diệu trước khi bạn phải nói với khách hàng. Đảm bảo rằng khách hàng biết rằng các yêu cầu được thêm có nghĩa là chi phí và thời gian được thêm vào và mọi yêu cầu được thêm sẽ phải bỏ các nhiệm vụ khác hoặc thời hạn sẽ thay đổi theo số giờ trong các nhiệm vụ mới. Làm rõ điều này ngay từ đầu sẽ tiết kiệm rất nhiều đau đớn và giờ làm thêm và chi phí vượt mức mà nhóm của bạn hấp thụ chứ không phải khách hàng.

Thiết lập môi trường để kiểm tra hiệu suất, không chỉ tốc độ của một người dùng, mà là nơi bạn có thể kiểm tra số lượng người dùng đồng thời dự kiến. Đừng chờ đợi để làm thử nghiệm này cho đến ngày trước khi bạn đi vào hoạt động.

Trong kế hoạch dự án, giả sử QA sẽ tìm ra lỗi và họ sẽ mất thời gian để sửa. Không lên lịch QA chỉ một ngày vào cuối.

Tạo dữ liệu thử nghiệm có kích thước gần bằng kích thước bạn nghĩ cơ sở dữ liệu sẽ có. Làm cho tất cả các nhà phát triển kiểm tra mã của họ dựa trên cơ sở dữ liệu có kích thước này. Không cho phép các nhà phát triển chỉ phát triển dựa trên cơ sở dữ liệu nhỏ trên máy cá nhân của họ. Đây là một nguyên nhân thường xuyên của mã hoạt động tốt cho đến khi nó được sản xuất.

Kế hoạch thưởng vào ngân sách. Nó hạ bệ mọi người khi họ làm việc hết hàng tháng và chỉ những người quản lý mới nhận được tiền thưởng. Cũng nói cảm ơn bạn thường xuyên và bằng văn bản.

Bạn có thể cần một hệ thống quản lý dự án hoặc ít nhất là thiết lập bảng tính để theo dõi những gì bạn cần theo dõi. Khi thực hiện kế hoạch dự án, giả sử không quá sáu giờ một người trong kế hoạch của bạn. Điều này giúp giải thích cho thời gian sẽ không dành cho dự án, chẳng hạn như kỳ nghỉ, thời gian ốm, ngày nghỉ, cuộc họp nhân sự, đánh giá hiệu suất, v.v. Nếu bạn biết dự án đang trong giai đoạn không có sẵn cao (giả sử một dự án chạy từ ngày 1 tháng 1 - ngày 1 tháng 1 tại Hoa Kỳ), bạn có thể cần phải có thêm các khoản phụ cấp để có thêm thời gian nghỉ phép và nghỉ lễ. Thật không công bằng khi hy vọng rằng các nhà phát triển sẽ từ bỏ kỳ nghỉ và ngày nghỉ của họ và không ai có thể dự đoán khi nào những việc như thời gian ốm, nhiệm vụ bồi thẩm đoàn, thời gian mất người thân sẽ xảy ra. Giả sử họ sẽ xảy ra với nhóm của bạn trong dự án này.


Tôi nghĩ rằng máy người dùng thử nên "rên rỉ chậm", không phải "la hét chậm";) danh sách rất hay.
BlackICE

@david, tôi thích đề xuất của bạn và đã thay đổi nó trong văn bản.
HLGEM

Câu trả lời tuyệt vời - điểm đạn hoặc tên phần có thể giúp một chút.
JBRWilkinson

3

Một số điều tôi không thấy trong câu hỏi và câu trả lời tiếp theo:

  • Kế hoạch khắc phục thảm họa. Làm thế nào bạn sao lưu các hộp dev, dàn dựng, thử nghiệm vv? Có phải mọi nhà phát triển đều có những gì họ cần để làm việc ở nhà vào ngày tuyết rơi không thường xuyên? Vân vân.

  • Kế hoạch đào tạo. Có bao nhiêu tuần trong năm đào tạo để các nhà phát triển của bạn cần phải giữ sắc nét? Có ai theo dõi nó không? (Một bảng tính có thể đủ cho hầu hết các nhóm.) Có cơ chế để họ báo cáo (gửi email cho ai đó nói rằng họ đã xem 2 giờ webcast về "bất cứ điều gì" có lẽ là đủ) và để quản lý lên kế hoạch - ví dụ như chúng ta nên gửi cho ai hội nghị năm nay.

  • một vị trí công cụ. Đây có phải là "chúng tôi cung cấp cho bạn tất cả đăng ký MSDN không, vui lòng không cài đặt bất cứ thứ gì khác trên máy công việc của bạn" hoặc "chúng tôi muốn mã của bạn nhưng chúng tôi không quan tâm bạn sử dụng gì để chỉnh sửa, biên dịch và kiểm tra nó " địa điểm đẹp. Lập và ghi lại quyết định.

  • ALM tích hợp nhiều như bạn có thể chịu được hoặc đủ khả năng. Thông thường lý do cho "sự không phù hợp trở kháng", mục nhập kép, công cụ chồng chéo và tích hợp ứng dụng ghế xoay là hệ thống phát triển bởi các bit và miếng. Bắt đầu từ đầu, bạn muốn chứng minh rằng người của bạn có thể ở trong một công cụ duy nhất trong suốt chu kỳ. Không gõ mã trong X, biên dịch bằng Y, thử nghiệm với Z, thay đổi trạng thái của mục / nhiệm vụ công việc với A, báo cáo thời gian của họ dành cho B, nói với người đang chờ đợi rằng họ có thể tiếp tục với C, cố gắng tìm ra làm gì tiếp theo với D, định hướng tiến bộ tổng thể với E, v.v.


2

Tiêu cực hơn người đàn ông-ngày.

Đó là một sự kiện hiếm khi mọi người phân bổ đủ ban đầu.

[Sau đó ... lại phủ nhận lại nhiều hơn nữa ...]


Có quan điểm rằng nhiều ngày hơn phải luôn được đàm phán không phải là điều tôi muốn giới thiệu, tôi muốn cung cấp các ước tính chính xác và đáng tin cậy về thời gian công việc hoặc dự án.
NimChimpsky

@NimChimpsky Gần đây có một cuộc thảo luận về việc liệu khả năng ước tính đáng tin cậy có phải là một huyền thoại trong các dự án máy tính hay không. Trừ khi công việc rất nổi tiếng và không có nghiên cứu, thì thực chất rất khó để dự đoán thời gian. Ngay cả khi bạn có thể dự đoán lịch trình của nhóm của riêng bạn - dự đoán các yếu tố bên ngoài và sự chậm trễ là không thể. Vì vậy, ước tính "chính xác và đáng tin cậy" không phải là thứ mà tôi tin là tồn tại như một vị tướng.
Orble

@ Hoặc họ tồn tại nơi tôi làm việc. Một nhà bán lẻ quốc gia được liệt kê 250 ft ở Anh. Một số dự án đã muộn, nhưng không muộn, và chúng là ngoại lệ.
NimChimpsky

@NimChimpsky Có thể có được ước tính tương đối chính xác nếu bạn có toàn quyền kiểm soát tất cả các sản phẩm trong một dự án, không bị chặn bởi các bên ngoài và nhiệm vụ trong tay không cần nghiên cứu. Cung cấp ngân sách của bạn mở rộng để phân tích kỹ lưỡng trước khi ước tính thời gian. Ở hầu hết các công ty, ngân sách không có ở đó để điều tra đầy đủ trước khi bắt đầu.
Orble

@orbled Có thể luôn luôn yêu cầu nhiều thời gian hơn là hoàn toàn tùy ý và hoàn toàn không dựa trên bằng chứng, phân phối, phân tích hoặc ngân sách.
NimChimpsky

2

Xem như tôi đã gặp vấn đề nhất với các thư viện bên thứ 3 và cách sử dụng của họ:

  1. Xác định các thư viện và phiên bản bạn sẽ sử dụng.
  2. Tạo quá trình tích hợp các cập nhật thư viện cho dự án của bạn.
  3. Hãy chắc chắn rằng các nhà phát triển đều có mặt trên các lựa chọn thư viện.
  4. Tạo một kênh có lợi để thảo luận mở về các công nghệ đang được sử dụng.

Tại sao? Tôi không thể cho bạn biết số lần thư viện của bên thứ 3 (độc quyền) gặp phải lỗi nghiêm trọng khiến chúng tôi mất nhiều tuần phát triển vì chúng tôi không có quá trình di chuyển lên hoặc xuống. Hoặc giao dịch với các nhà phát triển nói rằng "bạn đã sử dụng phiên bản nào? Tại sao bạn sử dụng các chức năng được đánh dấu không dùng nữa?"


1

Một chi phí lớn cho các tổ chức là không giao ngân sách cho bảo mật trong suốt vòng đời phát triển, điều này có nghĩa là bảo mật thường kết thúc sau khi thực tế không hiệu quả, bộ hoạt động đắt tiền hoặc các biện pháp kiểm soát được đưa ra quá muộn để làm nhiều việc tốt.

Nhận bảo mật được xây dựng từ kế hoạch dự án ban đầu, với các mốc quan trọng, giống như bạn làm với tất cả các khía cạnh phát triển khác và sử dụng quy trình lặp để cập nhật hướng dẫn bảo mật. Đăng nhập cuối cùng từ bảo mật nên mười là một kiểm tra không ngạc nhiên rằng tất cả các kiểm soát bảo mật đã được thực hiện theo thiết kế.

Nếu không, bạn sẽ kết thúc hoạt động bảo mật sau khi triển khai - nơi có thể tốn gấp 8 - 10 lần (số liệu từ Gartner, IBM và những người khác), sẽ khiến mọi người khó chịu vì chức năng có thể bị ảnh hưởng và có thể quá muộn để ngăn chặn việc khai thác và thiệt hại.


Tôi tò mò, đây có phải là một phần của danh sách kiểm tra thiết lập dự án không? Tôi đã đưa nó vào như một phần của phát triển phần mềm, nhưng tôi không biết về thiết lập dự án. Tôi đã đưa nó vào với các cột mốc dev, nhưng tôi không nghĩ đó là những gì OP đang hỏi, tôi có thể sai.
BlackICE

David - có thể bạn đúng rằng mức độ chi tiết này không nên có, nhưng tôi nghĩ ít nhất nên có một mục hàng để bảo mật. Tốt hơn?
Rory Alsop

1

1. Đưa nó đến đội

Hãy hỏi các lập trình viên!Thực sự, đó là điều quan trọng nhất. Bạn sẽ gặp rất nhiều sự kháng cự nếu các nhà phát triển không trực tiếp tham gia vào thay đổi này. Rốt cuộc, đó là về cách họ làm việc, không phải bạn. Không cần phải nói, nhưng cố gắng ép buộc các phương pháp và công cụ trên người thường gây ra hậu quả khủng khiếp.

2. Kiểm tra và thích nghi

Yêu cầu nhóm tìm ra cách tốt nhất để làm việc, sử dụng kinh nghiệm của bạn để nhẹ nhàng giúp họ đi vào đường đua đã chọn. Sau đó, thường xuyên và hợp tác, hãy nhìn lại cách bạn (họ) đang làm và điều chỉnh quy trình để làm cho nó tốt hơn.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.