Чи повинен розробник приймати оцінку завантаженості, виконану макросом Excel?

12

У новому проекті друг мав писати тести, коли час, необхідний для їх написання, обчислювався макросом Excel, написаним його менеджером, який не розробляє.

За таких обставин чи повинен розробник взяти на себе відповідальність написати та запустити тести у розрахунковий час? Чи достовірні результати цих тестів?

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

project-management productivity testing

— Нельстар
джерело

7

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

— Девід Шварц

2

@David Прийняття оцінки зазвичай стосується перегляду оцінок та забезпечення консенсусу. Наприклад, якщо використовується інструмент параметричного оцінювання, інженери проектів переглядають ці дані для забезпечення узгодженості, можливо, використовуючи другу методологію, таку як Wideband Delphi.

— Томас Оуенс

12

Здається, щось, що слід надіслати Скотту Адамсу для мультфільму Ділберта.

— MetalMikester

1

Поки є огляд. У мене цього конкретного прикладу не було.

— Nelstaar

5

Пам'ятайте: оцінка, зобов'язання, мета та план досягнення цілі - це чотири різні речі. Переконайтеся, що всім зрозуміло, що це за речі, і які з цих чотирьох речей є Excel.

— nlawalker

14

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

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

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

— Петер Тьорк
джерело

7

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

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

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

— Стів
джерело

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

— Nelstaar

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

— Nelstaar

1

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

— maple_shaft

1

@maple_shaft: Ось чому вони називають це оцінкою - не очікується, що вона буде (або не повинна бути) точною. Незалежно від того, чи оцінюєте ви, використовуючи деякі обчислення в Excel, або за допомогою олівця та паперу, це не має значення. Використання Excel для оцінок має набагато більше сенсу, ніж деякі інші "методи", які я бачив під час використання ...

— Треб

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

— Томас Оуенс

5

Напевно, НІ.

Невелика програма, навіть велика, складна програма, не може оцінити, скільки часу займе будь-яке завдання програмування. Дивіться Математичні обмеження в оцінці програмного забезпечення для причин. Більш довгий, рецензований папір, великі обмеження на оцінку програмного забезпечення також доступний.

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

— Брюс Едігер
джерело

1

Я ще не читав ці документи (все ще), але параметричні методи широко використовуються для оцінки програмних проектів у межах 15% протягом понад 20 років, вважаючи, що вхідні дані є дійсними. Крім того, спільні методи, такі як широкополосний Delphi, можуть (і були використані) для підтвердження точності параметричних моделей. Див. Економіка програмного забезпечення (Boehm) для обговорення параметричних методів та застосування широкосмугових Delphi для програмних проектів (як з, так і без пареметричних моделей).

— Thomas Owens

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

— Данк

1

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

— Брюс Едігер

1

@Bruce: Використовуючи формули (включаючи електронні таблиці Excel) для оцінки проекту з успіхом, я, безумовно, можу стверджувати, що ні Томас, ні менеджер, ні я не обов’язково обманюємо себе. Як я вже зазначив, кожне окреме завдання буде різнитися, але впродовж проекту вони, як правило, вирівнюються. Я виявив, що використання формул (розроблених і модифікованих з часом) було набагато точнішим, ніж оцінки окремих розробників. Як правило, розробники надмірно оптимістичні чи надмірно песимістичні. Звичайно, формули працюють лише тоді, коли даються розумні дані, вміння - це, безумовно, фактор.

— Данк

Я прочитав ці документи минулої ночі. Вони суперечать понад 40 років доказів в управлінні проектами і понад 30 років доказів в управлінні проектами програмного забезпечення. Дивіться iiasa.ac.at/Admin/PUB/Documents/RM-75-071.pdf та sunset.usc.edu/csse/research/COCOMOII/cocomo_main.html

— Thomas Owens

4

Тьфу!

Це гігантський «запах роботи». Це неймовірне мікроуправління.

Якщо вони не можуть довіряти своїм співробітникам, щоб дати оцінку, що ще їм не довіряють?

— унц
джерело

1

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

— Данк

@Dunk - на мою думку, мікро-менеджмент у цій галузі в розробці програмного забезпечення - це "запах роботи", і я не хотів би працювати там.

— ozz

1

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

— Данк

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

— ozz

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

— Данк

3

Абсолютно НІ.

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

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

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

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

— кленовий вал
джерело

1

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

— rjzii

1

@Rob, Ви забуваєте ключовий момент, який зробив ОП, про те, що вони дотримуються цих оцінок (припускається суворо, тому що попередній розробник у згаданій команді "не хотів вважатись за оцінку" і був призначений заново). У моделях оцінювання немає нічого поганого, але вони повинні бути орієнтовною настановою і нічого не "заважати розробникам", що я, на жаль, бачив, що управління робить багато людей.

— maple_shaft

2

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

— Nelstaar

@maple_shaft - Не знаючи, які оцінки є, важко сказати, чи були вони необгрунтованими, і тому заперечення щодо їх утримання були дійсними. Якби вони були справедливими оцінками (тобто "Вісім годин, щоб написати Hello World"), тоді немає жодної проблеми, коли вони можуть бути затримані поза філософією.

— rjzii

3

У новому проекті друг мав писати тести, коли час, необхідний для їх написання, обчислювався макросом Excel, написаним його менеджером, який не розробляє.

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

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

За таких обставин чи повинен розробник взяти на себе відповідальність написати та запустити тести у розрахунковий час?

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

Чи достовірні результати цих тестів?

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

— Томас Оуенс
джерело

3

Схоже, ви задаєте два різні питання:

Чи достовірні результати цих тестів?

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

За таких обставин чи повинен розробник взяти на себе відповідальність написати та запустити тести у розрахунковий час?

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

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

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

— rjzii
джерело

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

— Nelstaar

1

@Nelstaar - майже все, що я коли-небудь читав, щодо управління проектами та оцінки, передбачає запущений діалог та налаштування речей, як йде час. Зазвичай найбільш достовірні оцінки мають імовірність, пов’язану з ними, щодо шансів влучити вказану ціль (тобто 90% шанс виконання завдання займає 8 годин).

— rjzii

2

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

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

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

— JeffO
джерело

+1 для надання відгуку під час роботи над завданнями щодо кошторисів.

— rjzii

1

Проста і коротка відповідь:

Вам байдуже, звідки береться оцінка.

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

— Климент Ерреман
джерело

1

Вам слід дбати, звідки береться кошторис. Параметрична модель з дійсними та розумними вхідними даними, генератор випадкових чисел, студент першого курсу інформатики, інженер програмного забезпечення з 5-річним досвідом роботи в області менше 6 місяців та інженер-програміст, який звернувся до менеджера проектів з 25-річним досвідом роботи всі в цій галузі мають різні можливості для ефективного оцінювання. Це також повертається до коментаря, який я висловив стосовно попередньої відповіді про етичну / професійну відповідальність інженера-програмного забезпечення за належне представлення, захист та оскарження оцінок.

— Томас Оуенс

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

— Климент Герреман

Ви погоджуєтесь зі мною, кажучи, що ваша відповідь неправильна? Враховуючи ті ж входи (як робоче навантаження, ресурси, складність тощо), хто так само важливий, як і що. Це зводиться до фактору довіри. Я довіряю COCOMO (який розробляється та підтримується деякими провідними розумами в оцінці витрат на програмне забезпечення) більше, ніж макрос Excel (зроблений особою з обмеженим досвідом та знаннями в оцінці витрат, набагато менше сфери застосування). Це все про велику картину, щоб встановити, наскільки достовірна ця оцінка.

— Томас Оуенс

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

— Клемент Ерреман

Як визначити точність, якщо ви не знаєте, хто оцінив і якими методами користувався? Я міг би дати ті самі дані двом людям - один є студентом першого курсу програмного забезпечення, який зараз проходить перший курс інформатики, а другий - старший інженер з програмним забезпеченням з 15-річним досвідом роботи та 5 в галузі. Обидва використовують однакові методи оцінки (не забувайте - часто вхідні дані також є оцінками). Студент може сказати, що це займе 6 місяців із 95% впевненістю. Старший інженер може сказати, що це займе 15 місяців з 80% впевненістю. Я б більше довіряв старшому інженеру.

— Томас Оуенс

1

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

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

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

— PeterAllenWebb
джерело

-1

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

Я напевно кажу " НІ" . Тому що:

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

Я хочу розпочати новий проект з продажу велосипедів в Інтернеті, і я знаю, що для вас та Джона потрібно три тижні.

— Саїд Неаматі
джерело

5

ОП не згадує про команду свого друга, використовуючи спритні методи. Я не думаю, що гнучкі правила не мають жодного значення для команд, які використовують інші методи (або взагалі відсутні методи). Здоровий глузд повинен, хоча :-) Більше того, очевидно, що не Excel вирішував оцінок, а лише виконував деякий розрахунок на основі деяких (невідомих нам) припущень та даних (кожне з яких може бути правильним чи неправильним) . Якщо я введіть оцінки для даного завдання кожним із членів нашої команди, то встановіть Excel для обчислення середнього з них, чи Excel робить оцінку?

— Péter Török

3

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

— Томас Оуенс

3

-1 - Це не дає відповіді на запитання, має очевидні помилки ("... новітні методи розробки програмного забезпечення є спритними") і, здається, не додає нічого актуального. Я не впевнений, для чого були обґрунтовані чи прийняті відповіді.

— Морган Херлокер

1

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

— StevenV

2

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

— StevenV