#7КориснихЦитат. Чистий Agile

• Усі рухи в галузі програмного забезпечення йдуть передбачуваним шляхом. Спочатку захоплені прихильники в меншості, ще одна меншина — захоплені недоброзичливці, а переважна більшість належить до тих, кому байдуже. Багато рухів помирають або, принаймні, ніколи не переходять до наступної фази. Пригадайте аспект-орієнтоване програмування, логічне програмування чи CRC-карти. Однак деякі перетинають прірву і стають надзвичайно популярними та дискусійними. Деяким навіть удається залишити протиріччя позаду і просто стати частиною сучасної думки. Прикладом цього можна вважати об’єктно-орієнтоване (ОО) мислення. Це стосується й Agile.
• Коли розпочався Agile? Імовірно, понад 50 000 років тому, коли люди вперше вирішили співпрацювати заради досягнення спільної мети. Ідея постановки невеликих проміжних цілей і вимірювання просування після досягнення кожної з них є достатньо інтуїтивно зрозумілою й настільки практичною.
• Як керувати проєктом із розробки програмного забезпечення? Протягом багатьох років існувала безліч підходів, більшість із них досить невдалі. Надії та молитви популярні серед тих менеджерів, які вважають, що долею програмних проєктів керують боги. Ті, хто в це не вірить, часто покладаються на мотиваційні методики, наприклад установлення строків із покаранням батогами, ланцюгами, розпеченою олією та світлинами людей, що піднімаються на скелі, та чайок, які літають над океаном
•  Agile — це комплекс методів, який допомагає розробникам та менеджерам здійснювати прагматичне управління проєктами. Однак таке управління не досягається автоматично, і немає гарантії, що менеджери приймуть належні рішення. Дійсно, цілком можливо працювати в рамках Agile, але водночас абсолютно неправильно керувати проєктом і довести його до провалу.
• Найважливіша мета під час використання Agile полягає в триманні цих двох діаграм на виду. Одна з рушійних сил розробки програмного забезпечення під час використання Agile — це надання даних, необхідних менеджерам для вирішення проблеми розподілу коефіцієнтів за правилом хреста та доведення проєкту до кращого з можливих результатів.
• Звичайно, деякі речі є очевидними. Ми повинні оцінювати проєкт та робити базові прогнози техніко-економічних та людських ресурсів. Нам слід бути впевненими, що графік є досяжним. Це найменше, на що наша компанія могла б очікувати від нас. Хай би що йменувалося словом «аналіз», саме його ми збиралися здійснювати наступні два місяці.
• Етап проєктування програмного забезпечення для нас зрозуміліший. Він полягає в розділенні проєкту на модулі й створенні інтерфейсів між ними. Тут також розглядаємо, скільки команд потрібно і як вони між собою мають бути пов’язані. Загалом, від нас очікують удосконалення графіка, щоб скласти здійсненний план реалізації.