“обмежує всі проєкти й накладає обмеження згідно з правилом хреста. Добре, швидко, дешево, готово. Оберіть будь-які три складники, які вам подобаються. Але четвертий ви подужати не зможете.”
“Agile — це комплекс методів, який допомагає розробникам та менеджерам здійснювати прагматичне управління проєктами.”
“Agile — це насамперед підхід, орієнтований на зворотний звʼязок. Кожен тиждень, день, година та хвилина визначаються результатами попереднього тижня, дня, години та хвилини, і потім уносяться відповідні корективи. Це застосовується як до окремих програмістів, так і до управління всією командою. Без даних важко належно керувати проєктом’”
“Аналіз можна розуміти як розбиття проєкту на структурні елементи (декомпозиція). Або ж як виявлення та розробку вимог. Можна як створення базової моделі даних або обʼєктної моделі тощо…”
“Етап проєктування програмного забезпечення для нас зрозумілі-ший. Він полягає в розділенні проєкту на модулі й створенні інтерфейсів між ними.”
“Аналіз та проєктування не працюють у парі як показники результативності. У них немає однозначних критеріїв завершеності.”
“Спринт — термін, який використовують у Scrum. Мені він не подобається, бо має на увазі, що потрібно мчати стрімголов. Проект із розробки програмного забезпечення — марафон, а хто на марафоні вдається до спринту?”
“Головна мета Agile - позбутися марних надій. Ми практикуємо Agile, щоб знищити надію, перш ніж вона спричинить «смерть» проєкту. Надія вбиває проєкт. Це те, що змушує команду з розробки програмного забезпечення вводити в оману менеджерів щодо її реального просування вперед. Коли менеджер запитує команду: «Як ідуть справи?», то в самому запитанні вже жевріє надія на відповідь «Дуже добре». Надія — дуже поганий спосіб управління програмним проєктом. A Agile — це спосіб забезпечити своєчасну й безперервну дозу холодної, суворої реальності навзамін надії.”
“Менеджери керують програмними проєктами, збираючи дані, а потім ухвалюють на їх основі найкращі рішення з можливих. Agile виробляє дані. Багато даних. Менеджери використовують їх, щоб привести проєкт до найкращого можливого результату.”
“Закон Брукса стверджує: «Додавання робочої сили до проєкту, здача якого затягується, затримує його ще більше». [Brooks, Jr., F. P. 1995 [1975]. The Mythical Man-Month. Reading, MA: Addison-Wesley.]”
“Для цієї книжки я дібрав методи екстремального програмування, оскільки з усіх методологій Agile воно є найкращим, найвизна-ченішим, найповнішим та найменш заплутаним. Практично всі інші процеси Agile є підмножиною або варіацією екстремального програмування.”
“Beck, K. 2000. Extreme Programming Explained: Embrace Change. Boston, MA: Addison- Wesley. Існує й друге видання, датоване 2005 роком, але перше — моє улюблене, і я вважаю саме його кінцевим варіантом.”
“акцент Agile на тестуванні, рефакторингу, простоті дизайну та відгуках клієнтів — це очевидний лікувальний засіб від продукування поганого коду.”
“Ступінь легкості впровадження змін у програмне забезпечення вказує на те, наскільки сама команда заважає створенню ефективного програмного забезпечення. Клієнти, користувачі та менеджери очікують, що програмне забезпечення буде легко змінити, а вартість таких змін буде невеликою та пропорційною.”
“У Біллі про права клієнта сказано, що він має право: 1) ознайомитися із загальним планом і знати, що, коли й за які гроші можна буде отримати; 2) отримати максимально можливе з кожної ітерації; 3) бачити прогрес у робочій системі, отримати належно про- тестовану систему; 4) змінити свою думку щодо розробки, поміняти функціональність і пріоритети, не маючи непомірних витрат; 5) отримувати відомості щодо змін у графіку робіт, аби вчасно скоротити обсяг робіт і встигнути до необхідної дати: скасувати проєкт у будь-який час і отримати корисний робочий код, який виправдовуватиме інвестиції, зроблені до моменту скасування.”
“У Біллі про права розробника сказано, що він має право: 1) знати, що від нього хочуть, а також отримати чіткі декларації поставлених пріоритетів; 2) завжди виконувати роботу якісно; 3) просити та отримувати допомогу від колег, керівництва та клієнтів; 4) здійснювати власне оцінювання та оновлювати його відповідно до поточної ситуації; 5) брати на себе відповідальність, а не чекати, поки на нього покладуть зайві обовʼязки.”
“Agile не процес. Agile не тренд. Agile не просто набір правил. Це, найвірогідніше, сукупність прав, очікувань та методів, яка складає основу професійної етики.”
“Триваріантна оцінка. Один із методів, який досить добре підходить для виконання великих завдань, — це триваріантна оцінка. Такі оцінки складаються з трьох позицій: найкраща, номінальна (допустима) й найгірша. Ці позиції вказують на довірчий інтервал. Найгірша оцінка - показник часу, протягом якого ви відчуваєте себе на 95% упевненими, що завдання буде виконано. Допустима має лише 50 % довіри, а найкраща — лише 5 %. Наприклад, я на 95 % упевнений, що завдання буде виконано протягом трьох тижнів. Я лише на 50 % упевнений, що його буде завершено за два тижні. І я лише на 5% упевнений, що завдання буде завершено протягом одного тижня. Є ще один спосіб поглянути на це. Якщо взяти 100 подібних за-вдань, то пʼять із них буде виконано протягом тижня, 50 — двох тижнів, а 95 — протягом трьох тижнів.”
“можу порекомендувати вивчити техніку оцінювання та аналізу програм і проєктів (PERT) [https://en.wikipedia.org/wiki/Program_evaluation_and_review_technique]”
“Історія користувача - це скорочений опис функцій програми, розказаний з погляду користувача.”
“оцінювання відбувається не за часовими пара-метрами, а за складністю виконання. Одиниці складності історії мають бути лінійними. Картка з оцінкою 2 повинна вимагати приблизно половини зусиль картки з оцінкою 4. Однак лінійність не повинна бути ідеальною.”
“час спланувати першу ітерацію. Перший крок - зустріч, присвячена її плануванню. Ця зустріч повинна тривати одну двадцяту всієї ітерації. Тобто для двотижневої ітерації зустріч має тривати близько пів дня. На зустріч, присвячену плануванню ітерації, має зʼявитися вся команда, тобто програмісти, тестувальники, керівник проєкту, а також зацікавлені сторони. Останні мають попередньо прочитати оцінювані історії та відсортувати їх у порядку цінності для свого бізнесу.”
“Важливо усвідомити, що швидкість не є обовʼязком. Команда не обіцяє виконати 30 одиниць за час ітерації. Вона навіть не обіцяє зробити спробу в цьому напрямку. Це не що інше, як здогадка про те, скільки одиниць за найкращого розвитку подій буде завершено до кінця ітерації. Таке передбачення не дуже точне.”
“квадранти використовуються для розрахунку рентабельності інвестицій (ROI). Це неформальний підхід, і математика тут не потрібна. Зацікавлені сторони просто дивляться на картку й роблять висновки на основі цінності та складності історії.”
“Мета ітерації - генерувати дані для менеджерів.”
“Користувацькі історії — це прості висловлювання, застосовувані нами як нагадування про функції. Ми намагаємося не занотовувати занадто багато подробиць, коли пишемо історію, бо знаємо, що ці деталі, імовірно, зміняться. Подробиці записують пізніше, але у формі приймальних тестів,”
“Історії мають відповідати критеріям якості, закладеним в абревіатурі INVEST.”
“Незалежність (І — Independent). Історії користувачів незалежні одна від одної. Це означає, що їх не потрібно реалізовувати в якомусь конкретному порядку. До прикладу, після входу в систему не потрібно одразу реалізовувати функцію виходу. Це нежорстка вимога, бо цілком можуть існувати історії, які залежать від інших, котрі потребують першочергової реалізації.”
“Придатність для обговорення (N - Negotiable). Це ще одна причина, чому ми не записуємо всі деталі. Ми хочемо, щоб вони стали предметом обговорення розробників та замовників.”
“Наприклад, клієнти можуть попросити створити дивовижний інтерфейс із функцією перетягування. Розробники ж можуть порекомендувати щось простіше, з прапорцями, пояснивши, що в такому разі його розробка буде значно дешевшою. Такі обговорення важливі, оскільки вони є чи не єдиним способом надати клієнтам уявлення про управління вартістю розробки програмного забезпечення.”
“Цінність (V - Valuable). Цінність історії для замовника повинна бути чітко окресленою й вимірюваною.”
“Рефакторинг ніколи не вважають історією. І архітектуру також. Та й наведення ладу в коді. Історія — це завжди те, що містить у собі цінність для клієнта.”
“історія пройде крізь усі рівні системи. Вона може частково містити трохи графічного інтерфейсу, проміжного програмного забезпечення, баз даних тощо. Сприйміть історію як тонкий вертикальний зріз крізь горизонтальні прошарки системи.”
“Піддається оцінці (Е — Estimable). Користувацька історія повинна бути достатно конкретною, щоб розробники могли її оцінити.”
“Малий обсяг (S — Small). Користувацька історія не повинна бути великою, щоб бути реалізованою одним або кількома розробниками за одну ітерацію.”
“Не слід давати можливість одній історії домінувати в роботі всієї команди протягом цілої ітерації. Ітерація повинна містити приблизно стільки ж історій, скільки розробників є в команді. Якщо в команді 8 розробників, то кожна ітерація повинна містити приблизно від 6 до 12 історій. Однак ви ж не хочете заплутатися у вирішенні цього питання. Це більше рекомендація, аніж правило.”
“Придатність для тестування (Т - Testable). Клієнт повинен мати можливість обрати тести, які підтвердять, що історію завершено.”
“Зазвичай ці тести пишуть спеціалісти з перевірки якості (QA-спеціалісти), вони будуть автоматизовані та використовуватимуться для перевірки того, чи завершено історію.”
“Grenning, J. W. 2002. Planning Poker or how to avoid analysis paralysis while release planning. Доступ за адресою https://wingman-sw.com/articles/planning-poker”
“Розбиття історій — трохи цікавіше заняття, оскільки вам потрібно дотримуватися критеріїв INVEST. Як простий приклад розбиття історії розглянемо вхід (залогування). Якщо ми побажаємо розділити його на більш дрібні історії, то можна створити такі: вхід без пароля, вхід з однією спробою, дозволити кілька спроб уведення пароля та забули пароль.”
“Метою кожної ітерації є отримання даних шляхом виконання істо-рій. Команда повинна зосереджуватися на історіях, а не на завданнях, які лежать в їхніх межах. Набагато краще зробити 80 % історій, ніж кожну історію на 80 %. Зосередьтеся на доведенні історій до завершення.”
“У менеджерів та ведучих буде спокуса призначати програмістам історії. Та цього слід уникати. Набагато краще дозволити програмістам самим між собою домовлятися.”
“Якщо спеціалісти з контролю якості ще не почали писати автоматизовані приймальні тести, то щойно завершиться зустріч із приводу планування ітерації, уже час починати. Тести для історій, які заплановано виконати серед перших, слід підготувати якнайраніше. Завершені історії не мусять чекати, коли приймальні тести будуть нарешті готові.”
“Написання приймального тесту повинно проходити швидко. Ми очікуємо, що всі вони будуть готові до середини ітерації. Якщо не всі приймальні тести буде створено до середини, то деяким розробникам слід припинити роботу над історіями й почати працювати над приймальними тестами.”
“Якщо спеціалісти з контролю якості продовжують провалювати написання тестів до середини кожної ітерації, то, імовірно, співвідношення інженерів з контролю якості та розробників неправильне.”
“Коли історія пройшла приймальні тести, її можна вважати завершеною.”
“Кожна ітерація закінчується короткою демонстрацією нових історій для зацікавлених сторін. Ця зустріч повинна тривати не більше однієї двох годин, залежно від розміру ітерації.”
“Найкраще, якщо самі зацікавлені сторони перевірять роботу системи, аби розробники не спокушалися можливістю приховувати те, що не працює.”
“Графік швидкості говорить нам про те, наскільки добре керують командою. Графік швидкості буде доволі спотвореним, особливо під час перших ітерацій, оскільки команда ще зʼясовуватиме основи проєкту. Але після кількох ітерацій неточності повинні знизитися до рів-ня, який би дозволив визначити середню швидкість робіт.”
“Ми не розраховуємо, що команда буде прискорюватися або ж уповільнюватися протягом тривалого часу.”
“Якщо ми бачимо зростання на графіку, це навряд чи означає, що команда реально почала швидше просуватися у виконанні роботи. Це, імовірніше, означає, що керівник проєкту чинить тиск на команду, спонукаючи її йти швидше. Коли цей тиск зростатиме, команда несвідомо зміщуватиме значення своїх оцінок, удаючи, що їй удається просуватися швидше. Це просте знецінення. Одиниці — це валюта, і команда знецінює їх, потрапляючи під зовнішній тиск. Повернімося до цієї команди наступного року і побачимо, що за ітерацію вони отримають мільйони балів. Напрошуються висновки, що швидкість — це спосіб вимірювання, а не мета. Теорія управління радить: не тисніть на те, що вимірюєте.”
“Спадання швидкості. Якщо графік швидкостей показує стійкий негативний ріст, то найбільш вірогідною причиною є якість коду. Команда, імовірно, застосовує недостатньо рефакторинга, і код починає псуватися. Одна з причин того, чому команди не в змозі здійснити рефакторинг: вони пишуть недостатньо модульних тестів, тому й бояться, що рефакторинг порушить те, що раніше працювало. Боротьба зі страхом перед змінами є головною метою управління командою, і все це зводиться до дисципліни тестування.”
“Швидкість спадає, а от тиск на команду зростає. Це знецінює одиниці складності. За роздуванням одиниць може ховатися падіння швидкості виконання проєкту.”
“Еталонна історія. Одним зі способів уникнути знецінення є постійне порівняння історій з початковою еталонною, стандартом, за яким будуть оцінюватися інші історії. Памʼятайте, що вхід був нашою первинною еталонною історією, і вона оцінювалася 3 одиницями. Якщо нова історія, наприклад виправити помилку в пункті меню, отримує оцінку 10, то стає зрозуміло, що в хід пішло знецінення.”
“То що таке специфікація? Специфікація, по суті, є тестом.”
“Коли тестування переноситься на кінець, уся відповідальність за затримки падає на плечі спеціалістів із контролю якості.”
“У Scrum клієнта називають власником продукту. Це людина (або група), яка обирає історії, установлює пріоритети та надає своєчасний зворотний зв’язок.”
“Коли цілісна команда ділить між собою один простір, може статися магія.”
“Коли члени команди перебувають у межах одного простору, робота йде рівномірніше.”
“Коли члени команди працюють з дому, то все ж спостерігається значна нестача невербального спілкування. Безтурботні розмови трапляються набагато рідше.”
“програмний проєкт — це марафон, а не спринт чи серія спринтів. Щоб виграти, потрібно правильно розподілити сили. Якщо ви стрибаєте через перешкоди й женете на всіх парах, у вас вичерпається енергія задовго до фінішної прямої.”
“Понаднормова робота - це не спосіб проявити свою відданість роботодавцю. Вона лишень свідчить про те, що плануєте ви погано, що погоджуєтесь із термінами, з якими погоджуватися не повинні, що роздаєте обіцянки, які не мали б давати, що ви керований чорнороб, а не професіонал. Це не означає, що працювати понаднормово завжди погано або що ніколи не варто так робити. Існують помʼякшувальні обставини, у яких єдиним виходом є понаднормова робота. Але вони повинні виникати вкрай рідко. І вам необхідно добре усвідомити, що цей понаднормовий робочий день, імовірно, коштуватиме вам дорожче, аніж час, який ви заощадите за графіком.”
“Визначте, скільки годин сну потребує ваш організм, а потім надайте цим годинам найвищий пріоритет. Сон упродовж цих годин повністю окупиться. Маю правило: перша недоспана година коштує мені дві години денної роботи. Друга недоспана година коштує мені ще чотири години продуктивної роботи. І звичайно, про продуктивність можна забути узагалі, якщо я недоспав три години.”
“на стендап-зустрічах дозволяється говорити лише розробникам. Менеджери та інші співробітники можуть слухати, але втручатися не повинні.”
“Подвійна бухгалтерія. Бухгалтери мають алгоритм дії, винайдений 1000 років тому. І на- зивається він подвійна бухгалтерія». Кожна транзакція, яку вони проводять, вноситься до книги двічі: уперше як кредит на один рахунок, а вдруге як дебет — на інший. Ці рахунки зрештою зливаються в єдиний документ, який називається баланс, де від суми активів віднімається сума боргових зобовʼязань та власного капіталу. Така різниця повинна дорівнювати нулю. Якщо вона не дорівнює нулю, то десь допущено помилку?.”
“Керована тестами розробка — це аналогічна бухгалтерській практика для програмістів. Кожна дія повторюється двічі: спершу пишуть тест, а потім виробничий код, який зможе цей тест пройти. Ці дві дії взаємодоповнюють одна одну, як активи й пасиви. Коли ці дві дії виконуються разом, то зрештою отримуємо нульовий результат: жодний тест не провалено.”
“Ці два напрямки — ведення подвійної бухгалтерії та керована тестами розробка — рівнозначні. Вони обидва виконують ту саму функцію - запобігати помилкам у критично важливих документах, де кожен символ повинен бути правильним.”
“Керовану тестами розробку можна описати трьома простими пра- вилами. 1) Не пишіть готовий код, доки спершу не буде написано тест, який не вдасться пройти саме завдяки відсутності виробничого коду. 2) Не пишіть тестів більше, ніж це необхідно для провалу. Збій під час компіляції також уважається провалом. 3) Не пишіть коду більше, ніж достатньо для проходження тесту, який до цього завершився провалом.”
“Покриття тестами трохи більше за 90 %, імовірно, буде достатнім і справді досяжним.”
“Застереження. Повнота тесту — це показник для команди, а не для менеджерів. Менеджери навряд чи в курсі, що саме він означає. Менеджери не повинні використовувати цей показник як напрямок дій або ціль. Команда має використовувати його виключно для інформування про свою стратегію тестування.”
“Коли у вас є повний набір тестів, ви втрачаєте страх здійснити зміни в коді. Утрачаєте страх очищення коду. Отже, ви таки почистите код. Ви будете тримати систему акуратною та впорядкованою. Ви збережете структуру системи незмінною. Ви не створите масу кодового перегною, яка затягне команду в депресію низької продуктивності та спричинить подальші невдачі. Ось чому ми застосовуємо керовану тестами розробку. Ми практикуємо її, бо вона дає нам сміливість підтримувати код чистим і впорядкованим. Сміливість діяти як професіонали.”
“Рефакторинг - це метод удосконалення структури коду без зміни поведінки, визначеної тестами. Інакше кажучи, ми змінюємо імена, класи, функції та вирази, не провалюючи жодного тесту. Ми вдосконалюємо структуру системи, не впливаючи на і поведінку.”
“рефакторинг — безперервний, а не виконуваний періодично й за планом процес. Ми не створюємо великого роз-гардіяшу день у день, а потім не заходимося його очищувати. Краще вже зробити зовсім невеликий безлад, на хвилину-дві, а потім цю маленьку плутанину прибрати. Слово рефакторинг ніколи не повинно зʼявлятися в графіку робіт. Це не той різновид діяльності, який виконується плановано. Ми не резервуємо час на рефакторинг, бо це лишень частина нашого похвилинного й погодинного підходу до написання програмного забезпечення.”
“Правила простого проєктування Кента Бека. 1. Пройдіть всі тести. 2. Розкрийте наміри. 3. Видаліть продубльовані елементи. 4. Скоротіть кількість елементів.”
“Завдання простого проєктування - зберегти проєктну вагу коду якомога меншою.”
“Складність програмного проєкту варіює від досить простого до надзвичайно складного. Що складніша конструкція, то більшим є когнітивне навантаження на програмістів. Це навантаження - проєктна вага. Що більша вага цієї конструкції, то більше часу й сил потрібно програмістам для осягнення системи й управління нею.”
“Досягнення балансу складності структури та функцій — мета простого проєктування. Застосовуючи цей метод, програмісти постійно перепроєктовують конструкцію системи, аби забезпечити її врівноваженість відповідно до вимог, а отже, підтримувати максимальну продуктивність.”
“Парне програмування — це діяльність двох програмістів, спрямована на вирішення однієї проблеми. Вони можуть працювати разом на одній машині, зі спільним екраном, клавіатурою та мишкою. Або на двох підключених компʼютерах, споглядаючи той самий код і керуючи ним. Останній варіант чудово працює завдяки програмам, які забезпечують спільний доступ до екрана.”
“Часом програмісти, котрі працюють у парі, виконують різні ролі. Один може бути водієм, а інший — штурманом. У водія — клавіатура та миша, штурман більше часу відводить на перегляд коду на екрані й дає рекомендації. Інший варіант розподілу ролей полягає в тому, що один програміст пише тест, а інший має його пройти та написати наступний тест — для першого програміста. Іноді цей метод називають пінг-понг.”
“Ніхто не формує пари. Вони утворюються й розпадаються відповідно до бажань програмістів. Менеджери не мають утручатися, створюючи графіки чи матриці спільної роботи.”
“Провідні програмісти - сеньйори - мають потурбуватися, щоб якомога частіше працювати в парі з молодшими - джунами, а не з такими ж досвідченими, як вони самі.”
“Мета полягає в поширенні та обміні знаннями, а не в їхньому одноосібному накопиченні.”
“Важко виміряти витрати на парне програмування. Найбільш пряма витрата — це те, що над виконанням одного завдання працюють двоє людей. Здається очевидним, що на це витрачаються не подвійні зусилля, проте, імовірно, якісь витрати є. Різні дослідження показали, що прямі витрати можуть становити близько 15 %. Інакше кажучи, знадобиться 115 програмістів, які працюють у парі, аби виконати роботу, котру зроблять 100 осіб (без аналізу коду). Примітивний розрахунок дозволив би припустити, що втрати команди, яка працює в парі 50 % часу, будуть менші за 8 %. З іншого боку, якщо робота в парі замінює огляд коду, то, найвірогідніше, зниження продуктивності взагалі не відбудеться. Тоді ми повинні врахувати переваги взаємного навчання та обміну знаннями. Такі переваги неможливо порахувати, але вони, схоже, є значними.”
“ніколи-ніколи не просіть дозволу на роботу в парі. Або на тестування. Чи на рефакторинг. Або… Ви тут фахівець. І вам вирішувати.”
“Цінності Agile… Кент Бек назвав чотири цінності Agile. Це сміливість, комунікація, зворотний звʼязок та простота.”
“Сміливість. Перша цінність — сміливість, або, інакше кажучи, розумний ступінь ризику. Члени команди Agile не настільки зосереджені на політичних заходах безпеки, аби жертвувати якістю та можливостями. Вони усвідомлюють, що найкращий спосіб керувати проєктом із розробки програмного забезпечення в довгостроковій перспективі - проявляти певний ступінь агресії.”
“Віра в те, що якість та дисципліна підвищують швидкість, смілива, оскільки їй постійно будуть кидати виклик впливові, але наївні колеги, котрі поспішають.”
“Комунікація. Ми цінуємо пряму та часту комунікацію, що застосовує перехресні канали зв’язку. Члени команди Agile хочуть поговорити одне з одним. Програмісти, замовники, тестувальники та менеджери хочуть сидіти поруч і часто комунікувати між собою, і не лише в робочому контексті. Не лише електронною поштою, у чатах та за допомогою службових листів. Вони поціновують неформальне міжособистісне спілкування.”
“Команда, члени якої сидять разом і підтримують тісне спілкування, може творити дива.”
“Зворотний зв’язок. Практично всі напрямки Agile, які ми вивчали, спрямовано на забезпечення швидкого зворотного звʼязку для людей, які приймають важливі рішення.”
“Простота. Наступна цінність Agile — це простота, інакше кажучи, прямота, чесність.”
“Коли ви визнаєте проблему, але мовчки дозволяєте собі перекласти її розв’язання на когось іншого, то поводитеся нечесно. Коли ви пристаєте на вимоги менеджера чи замовника, усвідомлюючи катастрофічність наслідків, ви чините нечесно.”
“Простота — це прямота, прямота в коді та безпосередність і чесність у спілкуванні та вчинках.”
“Зберігайте простоту коду. Створіть у команді атмосферу простої взаємодії”
“рух Agile, — це проблема роботи невеликих команд розробників. Ми не знали, як ефективно організувати відносно невелику групу програмістів задля досягнення їхньої ефективності. І саме цю проблему вирішив Agile. Важливо розуміти, що ця проблема стосувалася розробки програмного забезпечення, а не самої невеликої команди.”
“У 2010 році Ліса повністю описала власний підхід до коучингу у своїй книжці Coaching Agile Teams. [Adkins, L. 2010. Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition. Boston, MA: Addison-Wesley.]”
“Одна з цінних навичок коуча — це вміння проводити ефективне опитування, одним із призначень якого є «постановка запитань, які призводять до відкриттів, осяянь, зацікавленості та дій».”
“Прямувати до великого, зосереджуватися на малому”
“У нас зʼявилися списки невиконаних завдань та користувацькі історії замість документів із вимогами. У нас були дошки та діаграми згоряння завдань замість діаграм Ганта. Ми мали стікери, які щоранку рухали відповідно до нашого просування в процесі роботи. У стікерах відчувалася потужна енергетика — те, що викликало глибоку психологічну залежність. Вони ніби репрезентували нашу приналежність до Agile. Що більше стікерів у нас було на стінах, то більший звʼязок із Agile ми відчували. Ми стали командою Scrum, а не будівельною бригадою.”
“Компанії ще недостатньо дозріли, аби зрозуміти, що технічні проблеми насправді є бізнес-проблемами.”
“Майстерно продумане програмне забезпечення означає добре розроблений і протестований код. Це код, який ми не боїмося змінювати і який дозволяє бізнесу швидко реагувати на зміни. Це гнучкий і надійний код.”
“Ідеологія — це система ідей та ідеалів. Методологія ж — це система методів і практик. Ідеологія визначає ідеали, на які слід орієнтуватися. Для досягнення цих ідеалів можна використовувати одну або кілька методологій. Вони є засобом для досягнення мети.”
“Highsmith, J. 2009. Agile Project Management: Creating Innovative Products, 2nd ed. Boston, MA: Addison-Wesley, 85”
“Поширеною помилкою в спільнотах Agile і майстрів розробки є надання переваги методам перед цінностями, які покладено в основу методів.”
“Розробники не повинні випрошувати дозвіл на написання тестів. Вони не повинні мати окремі завдання для проведення одиничних тестів або рефакторингу. У них не має бути окремих завдань, аби реалізувати функціонал. Такі технічні заходи необхідно враховувати в процесі розробки будь-якої функції. Вони не є факультативними. Менеджери та розробники мусять обговорювати лише те, що й коли буде випущено, а не в який спосіб.”
“Розмови між розробниками та бізнесом повинні вестися про те, чому, що і коли відбуватиметься, а не присвячуватися питанню як.”
“Майстерність просуває ідею розробки програмного забезпечення як професії. Існує різниця між роботою та професією. Робота — це те, що ми робимо, але це не частина нашої сутності. З іншого боку, професія — частина нашої особистості.”
“Професія — це те, у що ми вкладаємо гроші. Це те, у чому ми хочемо покращити свої вміння. Ми хочемо здобути більше навичок і мати довготривалу та повноцінну карʼєру.”
“професія. Це щось додаткове, що приносить нам задоволення і доповнює нашу особистість. Професія наповнює сенсом наше життя.”
“Ці основи — цінності, принципи й методи, зазначені в книжці Extreme Programming Explained Кента Бека. Ці основи - мотива-ція, прийоми та методи з книжки в Refactoring? Мартіна Фаулера. Їх було викладено Бучем, ДеМарко, Юрдоном, Константином, Пейдж- Джонсом та Лістером. [1) Beck, K. 2000. Extreme Programming Explained: Embrace Change. Boston, MA: Addison-Wesley. 2) Fowler, M. 2019. Refactoring: Improving the Design of Existing Code, 2nd ed. Boston, MA: Addison - Wesley.]”
#1 Додаток для Швидкочитання (promo)
