Я працюю в невеликій компанії. До того, як мене прийняли на роботу, компанія, що розробляла програмне забезпечення, складалася з одного хлопця-самоучка, який переймав роботу. Тепер, коли я вже кілька років пишу програмне забезпечення для компанії, мені поставлено завдання встановити офіційні практики розробки програмного забезпечення на всій території компанії. Наразі у нас немає інших керівних принципів, крім

Напишіть код, протестуйте його, помістіть у .zip файл та надішліть його клієнту. Бонусні бали за TDD та контроль версій.

Мій начальник хоче, щоб я написав посібник для розробників програмного забезпечення, в якому визначаються загальні процеси, протоколи, інструменти та вказівки, які ми використовуємо для того, щоб виконати справи. Іншими словами, він хоче книги "Це те, що ми робимо тут", щоб полегшити ознайомлення нового працівника з тим, як ми робимо справи, а також допомогти моєму начальникові зрозуміти, що роблять його службовці та як вони роблять. це.

Як я це бачу, я закладаю фундамент, і це потрібно зробити правильно. Як би ви вирішили вибрати теми для такого посібника? Чи можете ви навести кілька прикладних тем?

Бічна примітка: Якщо це важливо, ми в першу чергу є магазином Microsoft .NET. І ми дивимось на гнучкі практики, такі як XP та Scrum, але, можливо, нам доведеться сильно змінити їх, щоб змусити їх працювати в нашій компанії.

Я би розбив її на такі розділи

• Поточний персонал - імена та назви (в ідеалі з фотографіями)
• Програми, входи до них, дані, про які потрібно знати, та запити на дозвіл, що надсилаються
• Закладки на сайти компанії та ключові зовнішні сайти, що стосуються бізнесу
• Програми, які компанія використовує для комунальних повідомлень, електронної пошти, бронювання конференц-залів, екрану доступу
• Процедури для діяльності, пов'язаної з компанією, такі як витрачання квитанцій, бронювання подорожей
• Налаштування машини для розробників. Детально опишіть процес налаштування нової машини розробників. Зазвичай це «очікується», що це займе лише день, але насправді це займає 3-5 днів.
• Процес розробки, спосіб відстеження, призначення та оновлення роботи та які інструменти використовуються.
• Як тестувати, що тестувати, коли тестувати, де тестувати.
• Стандарти кодування, включаючи умови іменування файлів та специфічні для мови стандарти.
• Як поводитися з помилками, де їх документувати, як іти до їх виправлення.
• процес розгортання, які ключові речі слід знати для виробництва.
• Як документувати, що документувати, коли документувати.
• Якщо "'є", наприклад, розташування (-ів) коду, даних, стандартів, документації, посилань та інших активів.

Якщо зробити його модульним, ви також можете дозволити вам або іншим користувачам оновлювати деталі окремо, наприклад, імена та посади працівників часто змінюватимуться, коли люди прийдуть та йдуть.

Для кожного розділу я б дуже старався написати це з точки зору "новачка". Найважливіше - це переконатися, що він справді має сенс для новачків. Ваш начальник, очевидно, не є правильною людиною, щоб переглядати це, оскільки він не є цільовою аудиторією. Він має рацію хотіти цього, просто переконайтеся , що зміст не закінчується випробовується на нього. Крім того, "новачок" обидва лише "1 тиждень" як новачок ... і має лише одну точку зору. Тому, ймовірно, (і рекомендується) документ буде удосконалено з кожним новим співробітником. Насправді це досить непогана задача також призначити їх на перший тиждень, тобто "Оновити посібник для новачків".

Для Agile / SCRUM:

Найважча частина Agile та SCRUM - це "справді" це робити.

Для читання я б почав з http://agilemanifesto.org/ і пішов би звідти.

Я також прочитав би відомий http://www.halfarsedagilemanifesto.org/, який додає ваги тому, що вам справді потрібно прийняти всі аспекти для його роботи. Якщо вам доведеться сильно змінити Agile для своїх організацій, цілком ймовірно, що люди хочуть переваг - без використання правильних процесів. Цей факт сам по собі повинен бути представлений , щоб відбити будь-яку половину assyness.

Здається, що вам доведеться запровадити деякі практики, перш ніж їх документувати!

a) Контроль над джерелами - як ви зберігаєте свої джерела та здійснюєте контроль за редагуванням

b) Управління та відстеження випусків - як ви створюєте збірку, нумеруєте випуск, порівняйте поточного кандидата на реліз із попереднім випуском

в) Управління проблемами - як відстежувати помилки у своїх випусках.

Це досить основні речі, але вони можуть зайняти багато часу (і, можливо, коштувати грошей) на реалізацію.

Теми, які я б включив у довідник розробника:

• Ролі / посади у відділі та відповідні їм обов'язки
• Вимоги до програмного забезпечення для розробників (тобто необхідне середовище розробки)
• Де і як отримати доступ до сховища вихідного коду
• Використовувані інструменти розробки (наприклад, IDE)
• Стиль / стандарти кодування
• Норми документації
• Процес тестування
• Процес побудови
• Процес розгортання
• Підтримка та управління процесом
• Де отримати найновішу версію цього посібника

Майте на увазі, що цей посібник повинен містити лише елементи, що стосуються розвитку, а не інформацію про компанію (яка повинна міститись у посібнику працівника).

Використання управління джерелами

• Який інструмент управління джерелом ви використовуєте.
• Синтаксис загальних команд / інструментів в IDE.
• Стратегія розгалуження / злиття.
• Якою має бути одиниця комітету? Скільки часу занадто довго, щоб файл перевірявся / не робився?
• Який рівень "готовості" позначає здійснення / реєстрація? Компіляції? Одиничні тести проходять? Переглянули?
• Що, як очікується, буде включено до приміток до комісії / реєстрації.
• Процедури відкату.