Як би ви представляли свій прогрес у розробці програмного забезпечення своїм зацікавленим сторонам?

Ми використовуємо bugzilla для відстеження помилок та запитів на функції, а також вимагаємо від розробників запису в окремі нотатки до випуску, якщо вони закінчать кодування функції. Стара мода, я знаю.

Одна з проблем, що виникають із вищезгаданою домовленістю, полягає в тому, що, хоча вона чудово працює для програмного забезпечення, яке ми вже продаємо, воно є абсолютно марним, коли йдеться про відстеження прогресу нового проекту розробки програмного забезпечення. Причина полягає в тому, що в момент розробки нового програмного забезпечення ми не можемо, а точніше, не можемо використовувати bugzilla для відстеження функцій просто тому, що bugzilla не підходить для представлення складної складності залежності функції (Для завершення нового Програмне забезпечення, є просто занадто багато функцій для кодування, і ми просто не відчуваємо, як розміщувати їх у баггіллі, і навіть якби ми це зробили, ми не мали можливості знати, від яких функцій залежить, і ми не зможемо все одно отримати точний прогноз дати доставки).

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

Як би ви представляли свій прогрес у розробці програмного забезпечення своїм зацікавленим сторонам?

Зробіть це спритний спосіб: демонструйте рано та демонструйте часто.

Ніщо не перемагає вісцеральне відчуття насправді його використання, щоб дати відчуття прогресу.

Відмова: Я ніколи раніше не використовував Bugzilla, тому не впевнений у його можливостях управління проектами (хоча Bugzilla: Управління проектами з Bugzilla виглядає добре).

Це питання звучить як результат недостатньої дисципліни. Ви повинні використовувати програмне забезпечення для управління проектами для планування та підзвітності за витрачений час та зусилля. Будь-яке програмне забезпечення для управління проектами (мене вразили Джира та Редмін ) має функціонал для розподілу завдань до рівня, щоб ви могли дати точну (~ годин) оцінку кожному завданню.

Звідси справа про те, щоб бути дисциплінованими та заповнювати деталі завдання. Це забезпечить огляд у вигляді діаграми ганта (Redmine) або діаграми прогону проектів (Jira), яка дає миттєву оцінку прогресу вашого проекту.

Зрештою, це просто надання оцінки часу (що робиться шляхом розбиття завдань для досягнення максимальної точності), а потім, коли починається розробка, порівнюючи прогрес із початковими (або переглянутими) оцінками.

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

Багато програмного забезпечення для PPM може бути надмірним для невеликих команд, відстеження декількох проектів, присвоєння ресурсів, предметів контролю якості та ін. "Ми виконали 92 з 127 функцій, і, за нашими оцінками, буде зроблено кодування та тестування на два тижні достроково." Всі плескають.