agile planning with microsoft team foundation server
Цей підручник пояснює, як виконувати Agile Planning за допомогою Microsoft TFS, що допоможе менеджерам проектів планувати та відстежувати роботу між своїми командами:
Серед різних статей, опублікованих у SoftwareTestingHelp.com на DevOps, ми бачили кілька хороших статей про DevOps з точки зору Безперервної інтеграції та Безперервної доставки за допомогою Microsoft TFS, AWS і, звичайно, інструментів з відкритим кодом, таких як Ansible.
Однією з передумов для DevOps є певний сильний процес, такий як AGILE, який вносить спритність у весь процес SDLC, де фокус полягає у тому, щоб випускати програмне забезпечення вчасно, з більш короткими циклами випуску та швидким зворотним зв'язком. Так би мовити, рухливий процес зосереджується головним чином на швидкості.
Що ви дізнаєтесь:
Agile Planning за допомогою Microsoft TFS 2017
Перш ніж переглядати різні розділи цієї статті, було б добре ознайомитися з деякими з них важливі термінології, що використовуються в Agile. Ці термінології будуть використані у цій статті.
Передумови: Microsoft TFS 2017
Створіть проект команди TFS за допомогою шаблону процесу SCRUM
Спочатку ми створимо проект команди TFS за допомогою шаблону SCRUM, виконавши вказані нижче дії.
Увійдіть до Microsoft TFS 2017 і натисніть Новий проект.
Введіть назву проекту та виберіть Scrum як шаблон. Натисніть на Створити.
Після створення проекту додайте учасників до проекту, натиснувши на + значок.
Створення відставання товару
Оскільки ви знаєте, що Microsoft TFS - це інтегрований інструмент ALM, який допомагає створювати робочі елементи, виконувати планування проектів, створювати визначення збірки та випуски з функцією виконання ручного тестування.
Перед будь-яким Agile-плануванням нам слід розпочати з визначення Спринти що є заздалегідь визначеним терміном для роботи. Натисніть на Налаштування -> Робота а потім визначити спринти з датами початку та закінчення.
Виберіть Спринт та встановіть дати початку та закінчення.
Тут ми зосередимося на створенні робочих предметів, які стануть невід’ємною частиною Agile-планування. Тож давайте почнемо із створення відставання продукту, яке містить пріоритетний список усіх функцій, які будуть частиною вашої програми чи продукту.
Власник продукту підтримує це відставання і за допомогою команди сутичок вирішує доцільність роботи в конкретному спринті.
Щоб створити відставання товару з У меню робочого розділу виберіть Відставання.
Клацніть на New, введіть заголовок для елемента відставання та натисніть Додати .
Елемент відставання товару додається до відставання. У теоретичному розумінні ви можете розглядати елемент відставання товару як історію користувача або запит на зміну. Зазвичай вони розкладаються в декількох завданнях розробників та тестових випадках.
мережеві пристрої та їх шари osi
Ви також можете замовити замовлення на основі пріоритету. Просто перетягніть робочі елементи зверху або знизу.
Відкрийте робочий предмет і додайте зусиль. Тут зусилля можуть відповідати потребам проекту або сюжетів, або днів, або годин. Оцінка зусиль буде додана після того, як елемент розкладеться на завдання. Призначити власник у розділі «Призначено» та встановіть для «Держава» значення Затверджено для розвитку. Натисніть на Зберегти та закрити.
Потім призначте елемент для Sprint 1, перетягнувши до Sprint 1.
Шлях ітерації змінює елемент на Sprint1, як показано на зображенні нижче.
Коли ми переміщуємо елемент до Готово Держава, швидкість, яка визначає загальну кількість сюжетних очок, яку команда скраму досягає в спринті, відображається натисканням на верхній правій таблиці швидкості.
Отже, підсумовуючи, можна сказати, що команда виконала 8 сюжетних балів у Спринті 1, як показано на графіку швидкості вище.
Планування потужності
Для кожного Спринту ми можемо визначити кількість годин, які кожен член буде працювати для проекту, якому призначено. Перегляд ємності для кожного спринту визначає це. Цей погляд також охоплює діяльність, над якою працює кожен учасник, наприклад, Дизайн або Розробка, Звітність тощо.
Клацніть на відповідний Sprint. У цьому випадку відкрийте Спринт 1 і перейдіть до Перегляд ємності . Оновіть, як показано нижче.
На наведеному вище скріншоті, оскільки користувач Dev1 працює лише 4 години на день протягом спринту, який триває 2 тижні, тобто 10 робочих днів. Робота, призначена показує, що йому призначено завдання, для виконання якого потрібно 8 годин із 40 годин у спринтерському періоді 2 тижні. Це розраховується як 4 (години на день) * 10 (2 тижні) = 40 годин.
Подібний розрахунок проводиться для користувача Dev2.
Створення завдань
Оскільки тепер у нас визначено елемент відставання продукту або історію користувача, а також заплановано потужність для кожного користувача в проекті, тепер ми можемо розбити його на завдання розробника. На робочому екрані натисніть на Спринт 1 а потім натисніть Додати знак завдання + для елемента відставання товару.
ліве зовнішнє з'єднання проти ліве з'єднання
Призначте його розробнику та введіть значення в годин для решти робочого поля. Клацніть на Зберегти та закрити.
Створене завдання пов’язане з елементом відставання товару.
Тут поле Решта роботи - це кількість годин, що залишилось на виконання завдання. Оскільки у наведеному вище прикладі ми встановили для поля 8 годин, і припустимо, що розробник наприкінці дня провів лише 2 години роботи над завданням, тоді поле, що залишилося, буде оновлено до 6. Ви можете зробити це 0, коли роботи більше немає, або якщо залишається 1 година або менше роботи або десь між 0 та 1 годиною.
На основі цього значення TFS може створити загальну діаграму спринту, яка є однією з дуже корисних метрик в Agile. Вищевказаний процес стосується шаблону SCRUM і не містить поля Оригінальна оцінка в робочому елементі Завдання.
Якщо проект команди TFS налаштовано за допомогою шаблону процесу Agile або CMMI, тоді є можливість ввести поле Original Estimate.
Щоб додати поле Оригінальна оцінка ( Microsoft.VSTS.Scheduling.OriginalEstimate ) у типі робочого елемента Завдання, використовуючи шаблон процесу SCRUM, його потрібно додати як спеціальне поле. Ви можете використовувати witadmin exportwitd , що є опцією командного рядка. Додайте поле в експортованому файлі XML та імпортуйте його назад до командного проекту.
Майбутні спринти
Елемент відставання товару або історію користувача також можна запланувати на майбутнє, перетягуючи елемент до будь-якого іншого майбутнього спринту.
Використання дошки завдань
Оскільки план спринту діє, ми тепер можемо бачити хід виконання кожного завдання із подання панелі завдань. Отже, панель завдань забезпечує візуальний потік завдань та їх статус. Отже, під час кожної сутичкової зустрічі ви можете переглянути статус кожного завдання, призначеного учасникам.
Ви також можете переглянути підсумок загальної роботи, що залишилася виконати.
Дуже важливо стежити за станом та прогресом, і це можна зробити за допомогою дошки завдань. Клацніть на Вид дошки для Спринту.
Ця дошка є дуже корисним видом і може бути використана для цілей звітності під час щоденних зборів.
до) Якщо розробники з призначеними завданнями почали працювати над завданнями, ви можете перемістити їх із Робити держава до В процесі стан просто перетягуванням.
б) Змініть залишок робочого часу завдання для користувача Dev2 з 8 на 5 годин, що залишились. Тоді години роботи, що виконуються, буде відповідно оновлено.
в) Діаграма вибуху, натиснувши на верхній правий кут, автоматично оновлюється.
г) Тепер закрийте завдання, призначене Dev2, перетягніть його в Готово держава. Час роботи, що залишився для цього завдання, автоматично зменшується до 0, а діаграма вибуху також оновлюється.
Огляд спринту та ретроспектива
Що ж, робота закінчена зараз, і термін спринту закінчився. Чи думає команда, що настав час розслабитися чи відпочити? Абсолютно велике НІ. Зараз настав час обговорити дуже важливу частину життєвого циклу SCRUM, яка є оглядом та ретроспективою.
Огляд Sprint фокусується на результатах, перегляньте елементи відставання готового продукту та надайте демонстраційну програму для клієнтів. Крім того, дуже важливо обговорити, які елементи відставання товару не було зроблено і чому, а головне зібрати відгуки від клієнтів та спланувати їх на майбутні спринти. Огляд спринту зазвичай проводиться між власником продукту, командою розробників та клієнтами.
Ретроспектива спринту фокусується на таких аспектах процесу, як те, що пройшло добре, а що ні? Тож вам також потрібно буде отримати відгук про процес та людей. Оскільки це дуже важливий аспект життєвого циклу Agile, ви можете дізнатись більше ретроспективи.
Отже, дуже можливо, що в кожному спринті можуть бути незавершені роботи. У цьому сценарії перемістіть PBI / Tasks до відставання продукту або до наступного спринту, який вирішить власник продукту.
Але поки що ми зберігаємо огляди та ретроспективи? Ви можете зберегти їх як частину обговорення робочого завдання або створити новий робочий елемент, щоб мати ретроспективні пункти дій та відгуки.
Висновок
У цій статті ми бачили, як Microsoft Team Foundation Server як інструмент ALM забезпечує швидкий та акуратний спосіб розпочати роботу над вашим додатком після процесу Agile Scrum.
Ми повинні переконатися, що всі команди, які слідують процесу Agile SCRUM, повинні визначити та створити такі аспекти, щоб правильно планувати та керувати роботою своєї команди.
- Використовуйте відповідний шаблон процесу SCRUM у Microsoft TFS
- Створюйте відставання продуктів
- Вказівка розкладу спринту та наповнення команди
- Вибір елементів для відставання у спринті
- Розкладання історій PBI чи користувачів на завдання
- Використовуйте діаграми Burndown для відстеження прогресу
- Дуже важливо використовувати панель завдань для моніторингу прогресу
- Нарешті, проведіть ефективний огляд спринту та ретроспективу
Рекомендована література
- Як стати хорошим наставником команди, тренером і справжнім захисником команд у спритному світі тестування? - Натхнення
- Термінологія Agile And Scrum: Словник понять Agile / Scrum
- Як полегшити рухливий процес оцінки за допомогою планування покеру
- Сучасні принципи тестування для гнучкої методології тестування
- Самодостатні команди Scrum: як створити самодостатню команду?
- Спритні ретроспективні зустрічі - чому це необхідно та деякі цікаві способи їх проведення
- 4 кроки до розробки гнучкого мислення для тестування для успішного переходу до гнучкого процесу
- ISTQB Foundation Формат іспиту та вказівки з вирішення робіт