чи є якийсь елегантний спосіб проаналізувати процес інженера?

Існує безліч настроїв, що вимірювати комісії недоцільно.

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

• перегляд моделей
• Робота IDE (попередня комісія)
• Час простою
• багатозадачність

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

В особистому зауваженні я вважаю, що роздуми над власною «метрикою» можуть бути цінними незалежно від (або за їх відсутності) використання цих даних для оцінки ефективності. IE - необ’єктивний спосіб задуматися про ваші звички. Але це питання обговорення поза межами Q&A.

Не впевнений, чи вважаєте ви це елегантним, але Уоттс Хамфрі написав цілу книгу під назвою «Програмне забезпечення персонального програмного забезпечення», яка стосувалася вимірювання вашої власної продуктивності. Він окреслив показники для введення даних, таких як час у вашому столі та перебої, час, витрачений на роботу над різними видами життєвого циклу програмного забезпечення, дефекти на кількість коду. Існує технічний звіт, який дає коротку версію за адресою:

http://www.sei.cmu.edu/library/abstracts/reports/00tr022.cfm

Якщо ви хочете подивитися на щось на зразок якості коду розробника, Chidamber & Kemerer запропонували кілька показників для об'єктно-орієнтованого коду.

Метрики для об'єктно-орієнтованого коду

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

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

Метрики, що виникають у контексті оглядів коду

Дефекти можна класифікувати за багатьма критеріями:

• тяжкість: (основна, незначна, косметична, розслідувати / невідома),
• тип (логіка, помилка друку, написання, порушення кодування стандартів тощо),
• походження / фазове стримування (вимоги, дизайн, код тощо).

Також передбачені показники підготовки та перевірки (час на рецензента, час на рядок коду) та щільність дефектів (за KLOC (тис. Рядків коду), за хвилину часу інспектора / рецензента).

Позначення цих значень на контрольних діаграмах може показати нам, чи знаходимося ми в межах процесу (наприклад, команда, яка перевіряє 200 рядків коду, яка не виявляє дефектів у групі, яка в середньому становить двадцять п’ять дефектів на KLOC, може бути несправною).

Інші показники

Інші показники, які можуть допомогти, включають ці для

• зароблене значення, щоб допомогти відкалібрувати оцінку
• швидкість для тих, хто використовує Scrum або Kanban .
• Робота Pareto , Juran , Demming , Ishikawa та інших з якості та промислової інженерії дещо переноситься на розробку програмного забезпечення з трохи уяви.

Обмеження аналізу

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

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

      Sweet is the lore which Nature brings;
      Our meddling intellect
      Mis-shapes the beauteous forms of things:--
      We murder to dissect.

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

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

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

http://en.wikipedia.org/wiki/Seven_Basic_Tools_of_Quality

Мені подобається контрольна схема.

http://en.wikipedia.org/wiki/Control_chart

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

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

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

Старе бачив, що ми вимірюємо, те, що ми робимо, може призвести до нападу на проблему, виходячи з того, що ви визначаєте як обмежуючий фактор

або декілька факторів у порядку пріоритетності на основі діаграми Парето.

http://en.wikipedia.org/wiki/Pareto_chart