Як жорсткі терміни і тиск на графік впливають на ТСО та час доставки?

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

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

Будь-які посилання на інженерну літературу з програмного забезпечення будуть вдячні.

Причиною номер однієї з планових перевищеннях є плановий тиск.

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

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

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

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

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

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

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

Чим більше тиск для планування у вас, тим довший термін доставки і більше TCO?

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

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

Планування справа наліво наліво.

Хтось із керівників завжди думає, що це Стів Джобс із його відомою зоною спотворення реальності. Поки хтось у розробці продуктів не навчає їх, нетехнічні менеджери можуть часто мати уявлення про складання графіку, яке є таким же складним, як ранній французький фільм "Le voyage dans la lune" ("Подорож на Місяць") для ракетної науки.

Проблема існує вже деякий час. Фред Брукс говорить про оцінку без кишок у " Міфічному людині-місяці" . Баррі Бум про це говорить у своїх пропозиціях щодо теорії- підходу до управління. Зовсім недавно Стів Макконнелл (автор « Кодексу завершений» ) приводить у фокус концепцію принципового питання переговорів у «Як захистити непопулярний розклад» .

Agile підштовхує сферу проектів до місця, де воно добре видно. Agile Manifesto закликає до «співпраці з клієнтами за контрактом переговорів». Це також, я сподіваюся, дає можливість людям, які притягуються до відповідальності. Гра планування дозволяє уникнути нетехнічних зацікавлених сторін, які змушують розробників обіцянки, які вони давали давно, які були перегнані змінами в вимогах або новими відкриттями.

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

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

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

Ліцензія Creative Commons - див. Http://en.wikipedia.org/wiki/File:Scrum_process.svg

Вам не потрібна інженерна література. Концептуальна ймовірність та статистика, з нижнього рівня, - все, що вам потрібно.

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

Ймовірність 101: p (підрив або точно влучення) + p (перевищення) = 100%.

Графік, заснований на оцінці, має точно такі ж характеристики.

Ви не можете повністю усунути невизначеність. ЗАВЖДИ буде деяка ймовірність перевищення. Це може бути мало, ймовірність того, що Іран завдасть удару по офісній будівлі, але він все ще є. Найкраще, що ви можете зробити, це подивитися на ВСЕ, і зменшити невизначеність максимально. Після того, як ви це зробите, у вас буде, якщо пощастить, графік з невеликою невизначеністю та 50% -ною ймовірністю з кожного боку.

Тепер подумайте над тим: Якщо ви втягнете графік, вірогідність того, що ви будете підривати або точно потрапляти до розкладу, зменшується. Загальна сума все ж має становити 100%. Куди йде ця ймовірність? Відповідь, це переходить у ймовірність перевищення.

Відділ загальної динаміки / Форт-Ворт навчився цього важкого шляху. Вони зробили свою первісну оцінку розвитку F-16C / D і відправили її в харчовий ланцюг. Хтось вище довільно відрізав рік від цього і відправив це у ВВС. Як результат, GD / FW запізнився на рік на льотні випробування, і ВВС НЕ були задоволені. (Зауважте, що "запізнення на рік" було відповідно до оновленого розкладу, тобто початковий графік був ПРАВИЛЬНО НА ЦІЛІ.)

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

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

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

Існує безліч факторів, які впливають на визначення досить доброго.

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

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

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

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