Основи здорового глузду

1. В проекту має бути два строки здачі — запланований та бажаний.
2. Ці строки мають бути різними.
3. Бажаний строк має бути ближче запланованого – в цьому секрет успіху.

Туманні специфікації

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

Працювати по-іншому

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

Процес розробки та його покращення

1. Добрий процес розробки та його постійне покращення — цілком пристойні цілі.
2. Але також існують робочі цілі й задачі: добрий працівник сконцентрує увагу як раз на них, навіть якщо ви його про це не просили.
3. Формальні програми, скеровані на покращення існуючого процесу розробки, будуть дорого коштувати коман­ді — в відношенні і часу, і грошей. Навіть окремі зусилля з покращення процесу можуть відкинути команду далеко назад. Щодо можливого підвищення продуктивності, то навіть якщо це й станеться, наврядчи переваги від цього підвищення перекриють затрати.
4. Можна сподіватись отримати позитивний результат від якогось од­ного добре виваженого й ретельно обраного вдосконалення в методиці роботи. В такому випадку воно может компенсувати гроші та час, затрачені на його впровадження.
5. Спроба впровадити більш ніж одне вдосконалення мето­дології — пропаща справа. Програми, скеровані на покащення багатьох прийомів та навиків (наприклад, перехід на наступний рівень СММ), скоріш за все призведуть до того, що строки тільки збільшаться.
6. Небезпека стандартизованого процесу розробки полягає в тому, що за рутиними операціями люди можуть не помітити можливість зекономити час та зусилля в розро­бці проекту.
7. Щодо надміру великих команд, там стандарти­зований процес буде неухильно притримуватись до тих пір, поки він дозволяє всім почуватись при справі (не важливо, з користю для проекту чи ні).

Моделювання процесу розробки

1. Моделюйте свої передбачення та здогади про те, як піде процес роботи.
2. Обговорюйте ці моделі разом з партнером, щоб краще розуміти процес роботи та вносити необхідні виправлення.
3. Передбачайте результати роботи за допомогою моделі.
4. Порівнюйте результати, отримані в процесі моделювання, з реальними.