Менеджер програмного забезпечення, який змушує розробників займатися управлінням проектами

Я розробник програмного забезпечення, який працює в компанії з вбудованими системами. У нас є керівник проекту, який піклується про загальний графік проекту (включаючи електроенергію, якість, програмне забезпечення та виробництво), отже його графік програмного забезпечення дуже короткий.

У нас також є менеджер програмного забезпечення, який є моїм начальником. Він змушує мене писати та підтримувати графік програмного забезпечення, конструкторські документи (дизайн на високому та низькому рівні), SRS, управління змінами, верифікаційні плани та звіти, управління випусками, огляди та звичайно програмне забезпечення.

У нас є лише один інженер-тест для всієї команди програмного забезпечення (10 членів), і в будь-який момент часу відбувається декілька проектів.

Я витрачаю 80% свого часу на виготовлення цих документів. Мій начальник походить з процесів Process, і вважає, що нам потрібно - це краща документація для вдосконалення програмного забезпечення:

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

Я справді розгублений.

1. Я відповідальний за збереження всіх цих документів? Це по суті відчуває, що я займаюся управлінням програмними програмами, по суті. Я в порядку з технічною документацією, але я вважаю, що планування / планування не повинно здійснюватися розробником.
2. Мені не дуже подобається створювати документи, я хочу вирішити проблеми і написати код. На мій досвід, створення дизайнерських документів лише допомагає в тій мірі, яка ніколи не є рішенням кращого чи швидшого коду.
3. Я відчуваю, що начальству не дуже важливо робити кращі продукти, а лише бути хорошим менеджером в очах керівництва.

Що я можу зробити? Цілий рік я робив 3 місяці фактичного кодування, решту просто витратив на виготовлення документів та очікування звітів про помилки від клієнтів.

Ви схожі на інженера з програмного забезпечення.

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

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

Він вважає, що дизайн є першорядним, кодування - це "просто записування дизайну"

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

це не повинно зайняти занадто багато часу, і "весь код повинен бути записаний до того, як апаратне забезпечення буде готове".

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

Управління проектами неймовірно просто в ідеальному світі. Світ не є досконалим, незалежно від того, наскільки ви хочете, щоб це було таким, що робить реально управління проектами неймовірно складним. Ось чому їм платять великі гроші.

(2) Не розуміє різниці між контролем центральної та розподіленої версії.

Чому він повинен дбати? Як це впливає на віхи? Це не так.

3) Не розуміє код і хоче зрозуміти кожну помилку та запропоноване рішення

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

(4) Вважає, що перевірка повинна здійснюватися розробником, а перевірка - Тестером.

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

Мені не дуже подобається створювати документи, я хочу вирішити проблеми і написати код.

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

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

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

Справа в тому, що найкраща технічна документація - це сам код.

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

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

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

Всі ми хочемо добре виглядати в очах свого старшого. У цьому немає нічого поганого, це людська природа бути самокорисливою. Це факт життя.

Якоюсь мірою я згоден з вашим керівником проекту. Розробка програмного забезпечення виходить далеко за межі функцій кодування. :-)

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

FYI, Atlassion , програмна компанія, має співвідношення 13 розробників на одну особу із забезпечення якості, і більшість тестувань (планування та виконання) проводиться розробниками. Я дізнався про це під час однієї з своїх презентацій на Agile 2012 та наших команд, якими я зараз намагаюся наслідувати цю практику.

Однак я б також обговорив з вашим менеджером проекту, якщо він буде готовий спробувати Scrum як методологію, яка допоможе просунути всю команду вперед. З огляду на ваш опис, я не думаю, що ви використовуєте Scrum.

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

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

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

Крім того, з точки зору суворої діяльності наймання якості контролю дешевше, ніж наймати розробників. Ви зможете покрити більше ґрунту на витрачені гроші, якщо команди мають гарне співвідношення QA / DEV.

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

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

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

Один тестер здається трохи легким, але крім цього, так - ви несете відповідальність за забезпечення документації.

Мій досвід у медичному світі обмежений, але в аерокосмічному / захисному світі у нас є Do-178B (зараз C), який призначає модель життєвого циклу, яка визначає необхідну документацію та рівень тестування (залежно від критичності безпеки [конкретніше, рівень гарантії дизайну] програмного забезпечення), і в автомобільному світі у нас є ISO26262, що робить те саме.

Якщо документація не встановлена, продукт не сертифікується.

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