Чи повинні команди Agile щодня надавати нові функції?

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

Більшість наших дияволів втрачають близько 2 годин на день на зустрічі та інші підприємницькі витрати. Це означає, що в будь-який даний 6-годинний (у кращому випадку) нам потрібно проектувати, записувати, тестувати одиниці, будувати та розгортати (з нотатками до випуску) достатньо коду, щоб створити повну функцію QA, з якою можна грати. Я розумію, що нотатки збирання / розгортання / випуску можуть бути автоматизовані за допомогою належної настройки CI, але ми ще не там.

У нас також є великий офшорний контингент, який пише наш код на стороні сервера, і 12-годинна різниця у часі робить це ще складніше.

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

Це нормальний темп для Agile команд? Навіть якщо нам вдасться здійснити налаштування CI, я не бачу, як ми зможемо підтримувати цей темп і все-таки створити якісне програмне забезпечення.

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

Злочини, які вчиняються в ім'я Agile в ці дні, мене сумують. Багатьом людям важко зробити цей перехід.

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

У моїх командах важлива частина полягає у тому, щоб уникнути скоєння спільного коду репо, який порушено таким чином, що витратить решту часу команди. Лише в цьому сенсі я прагну «щодня надсилати робочий код». Не порушуйте QA. Не блокуйте інших розробників. В ідеалі я ніколи не перевіряю жодних помилок. (ха-ха).

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

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

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

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

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

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

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

Коротка відповідь: Ні . Це просто неможливо здійснити щодня.

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

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

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

Якщо ви робите scrum, ви повинні робити як мінімум 2 тижні спринти, з можливостями розміру приблизно від 0 до 8 днів, щоб закінчити. Власник продукту обіцяє поставити новий, перевірений і перевірений правильний робочий код, який можна буде ввести у виробництво в кінці спринту. (ПРИМІТКА. Вам не потрібно насправді вводити його у виробництво, але мета може бути, якби ви хотіли)

Гарна методологія запропонувала вам встановити сервер CI (Continous Integration), на якому ви автоматизували створення принаймні однієї щоденної збірки робочого програмного забезпечення. Ідея полягає в тому, що ви перевіряєте свій код, як тільки закінчите функцію, щоб вона могла бути в наступному циклі збірки, а потім у руках QA для тестування.

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

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

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

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

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

Це означає, що він не обов'язково містить нові функції. Можливо, кілька незначних виправлень помилок або взагалі нічого.

Теоретично, якщо ви не в змозі щодня надати більше роботи своєму QA, ви повинні або збільшити кількість розробників, або зменшити кількість тестерів. Страшна ідея!

Ваша робота - це зробити справи.

Скажіть QA, що вони отримають щось перевірити, коли це буде зроблено. Вам потрібно пояснити їм, чому.

Думаю, ви заплутані в ідеї "CI". Ви можете відвідати цю чудову статтю Мартіна Фаулера про те, як CI працює на практиці . Це має відповісти на ваше запитання правильно.