Керування спільною розробкою
Створення ефективної структури керування спільною розробкою є важливою частиною забезпечення узгодженості та повторюваності у визначених авторами проектах і зведених робочих групах. У цій статті описується спосіб визначення блок-схеми керування.
Визначення кінцевого процесу
Наприклад, можна використати наведений нижче процес як приклад і налаштувати його для найкращого використання вашою організацією. Це не потрібно для завершення кожного кроку, поки ви досягнете необхідного результату.
Додавання функцій до невиконаних завдань
Невиконані завдання дають змогу планувати проект, додаючи функції, які надають загальний досвід. Невиконані завдання також забезпечує загальну дорожню карту, яку робоча група збирається виконати.
Під час додавання нової функції до невиконаних завдань ціль полягає в описі загальної області застосування. Потім кожна функція визначає цінність для бізнесу, чернетки заголовків історій, обсяг і зміни моделі даних, які визначають зусилля щодо розробки коду.
Крім того, під час додавання функції, критичної для бізнесу, рекомендовано визначити критично важливі сценарії для автоматизації тестування. Після додавання функцій можна запланувати нараду з узгодження вмісту.
Нарада з питань узгодження вмісту
Основна увага наради має бути обмежена переглядом кожної запропонованої нової функції, а потім перевіркою наявних програм, сценаріїв або моделей даних, які вже надають таку можливість, щоб уникнути повторення зусиль. Ця нарада також дає можливість обговорити вплив на інші програми. Зрештою, слід перевірити, чи потрібен для цієї функції перегляд роботи.
Додавання відгуків і таблиці оцінок до невиконаних завдань
Після наради з питань узгодження даних будь-які чернетки заголовків користувацьких історій можна додати до функції. Наразі відомості не потрібні, а статус користувацької історії «Новий». Історії можна переглядати в невиконаних завданнях або на дошці.
На рисунку нижче показано приклад історії користувача, доданої до невиконаних завдань.
На даний момент дуже важливо підтримувати якість, організовуючи роботу з робочих потоків і програм. Такий підхід допомагає об’єднувати пов’язані робочі елементи та дозволяє фахівцям в кожному робочому потоці розробляти та підтримувати глибоке розуміння функціональних можливостей і використання даних у кожній програмі.
Огляд роботи
Огляд роботи має зосередитися на досвіді кінцевих користувачів і переконатися, що ваша робоча група дотримується передових практик організації. Така узгодженість гарантує, що всі програми забезпечують залежність і повторюваність для кінцевих користувачів і робочих груп підтримки.
Додавання відомостей про історію
Додавання типової історії користувача може містити таку інформацію:
- Заголовок: як <persona>, я можу <do something> для <impact/priority/value>
- Опис: опис містить (хоча і не обмежується) певні ключові відомості, як-от:
- Стислий опис сценарію, який підсумовує бажаний результат
- Розповідь — описує дії, які користувачі вживатимуть для переходу та виконання сценарію
- Альтернативний опис описує інші способи досягнення одного результату користувачами
- Примітки конструювання — записує сутність, поля, подання, екрани макетів і бізнес-правила, пов’язані з історіями користувача
- Ролі безпеки, які зазнали впливу, — список усіх ролей безпеки, які зазнали впливу, та ролі безпеки, що стосуються історії користувача.
Після додавання всіх цих відомостей ви зміните стан користувацької історії га «Готово до розгляду». У більшості випадків функціональна робоча група та бізнес-група функції (якщо застосовується) переглядають користувацькі історії.
Огляд історії
Огляди історій зазвичай відбуваються всередині зведеної робочої групи, щоб переконатися, що в історії вказані всі деталі і немає двозначності. Після завершення всіх оглядів рекомендується передати користувацьку історію члену команди. Забезпечення того, щоб ваша робоча група залишалася узгодженою під час розробки, має важливе значення для досягнення спільних цілей.
Додавання завдань і тестових випадків
Після перегляду історій члени робочої групи створюють завдання у програмі Azure DevOps. Загальний процес додавання завдань і тестових випадків наведено нижче.
- Відкрийте невиконані завдання спринту. Крім того, можна створити новий спринт.
- Додайте наявні робочі елементи до спринту. Якщо ви вже додали робочі елементи, які не відображаються в спринті, слід перевірити їх області та шляхах ітерації. Не забудьте призначити всі непокладені завдання відповідним робочим елементам.
- Додайте завдань до елементів невиконаних завдань. Якщо у вас немає невиконаних завдань, призначених спринту, це слід зробити зараз. Також встановіть дати початку та завершення спринту.
- Заповніть цю форму завдання. Зазвичай, завдання повинні виконуватися не більше доби. Завдання, розмір яких перевищує цей часовий проміжок, потрібно розбити на частини.
- Відстеження або інтеграція непокладених завдань. Можна відстежувати непокладені завдання, як і інші завдання, або перетягнути їх до наявного елемента журналу невиконаних завдань, щоб зробити їх батьківськими.
Після додавання завдань і тестування інцидентів можна встановити виробничу спроможність спринту.
Додаткові відомості про додавання завдань див. у розділі Додавання завдань до журналу невиконаних завдань для підтримки планування спринтів.
Підготовка рішень
Важливим аспектом успішної спільної розробки є структурований процес керування випусками. Рішення — це механізм реалізації керування життєвим циклом програми (ALM); ви використовується рішення для розподілу компонентів між середовищами через експорт і імпорт. Компонент представляє артефакт, що використовується у вашій програмі, і іноді той, що ви можете потенційно налаштувати. Все, що може бути включено до рішення, — це компонент, як-от таблиці, стовпці, компоновані та модельні програми, потоки Power Automate, чатботи, діаграми та компоненти plug-in.
Важливо
Під час планування випусків визначте стратегію керування рішеннями в проекті. Скористайтеся рішеннями для керування проектом, а також легко знаходьте створені компоненти для розподілу в інші середовища.
Розгортання
Залежно від складності та швидкості робочої групи компоненти можуть приймати кілька спринтів. Компоненти слід додавати до рішення в середовищі розробки, коли завдання будуть виконані. Після тестування рішення імпортуються до робочого середовища. Рекомендуємо підтримувати одне тестове середовище для повного тестування та пробного розгортання рішення перед переходом до робочого середовища.
Середовища Power Platform
Середовища — це простір для зберігання, керування та поширення даних вашої бізнес-організації, програм і бізнес-процесів. Вони також служать контейнерами для розділення програм, які можуть мати різні ролі, вимоги до безпеки або цільові аудиторії.
Якщо в організації використовується зведення кількох робочих груп, де кожна команда розробляє свої власні рішення, важливо координувати тривалість спринтів і випусків. Спринти не повинні мати однакову тривалість на часовій шкалі проекту та можуть відрізнятися за тривалістю між робочими групами відповідно до вибору кожної робочої групи. Проте періодичність випуску не може бути меншою, ніж найкоротша тривалість спринту для всіх команд.
Керування вхідним кодом
Розглянути впровадження системи керування вихідним кодом, наприклад Azure DevOps. Azure DevOps надає робочим групам підтримки послуги розробників, щоб планувати роботу, співпрацювати в розробці коду, та створювати та розгортати програми.
Експортуйте рішення з середовища розробки, що містить програми та настроювання, розпакуйте рішення та збережіть компоненти в системі керування вихідним кодом.
Розширений розділ. Відгуки про запит на заповнення (PR)
Ви повинні створювати PR тільки для активних історій, функції яких перевірені та схвалені. Ви повинні переконатися, що керування версіями рішень точне, дотримуючись указівок щодо спринту та розробки, наведених у панелях Azure. Результатами тестування з PR можуть бути знімки екрана або відеозаписи про вбудовані функціональні можливості.
Автоматизація процесу керування PR допомагає забезпечити якість коду, не потребують ручного перегляду базових перевірок, наприклад версій рішень.
Примітка
Скористайтеся інструментом перевірки PR,, щоб автоматизувати процес перевірки запиту на заповнення.
Шаблони та стандартизація
Шаблони та стандартизація забезпечують ефективність підвищення узгодженості в робочій групі. Усі аспекти діяльності— команди, будь то завдання з адаптації, презентації з оглядом історій або шаблони робочих елементів, які допомагають заощадити час і надають рекомендації командам під час визначення історій користувачів, функцій, помилок або завдань—, виграють від стандартизації та спрощення.
Впровадження ефективної моделі підтримки
Ефективна модель підтримки необхідна для тривалого успіху програми після її розгортання, як виділено в попередньому розділі про створення матриці підтримки. Помилки та відключення неминучі, тому дуже важливо, щоб робоча група має структурований підхід до вирішення цих подій, а матриця підтримки забезпечувала необхідну структуру.
Створення угоди про рівень обслуговування
Ключовим фактором для будь-якої моделі підтримки є визначення угоди про рівень обслуговування (SLA). SLA має бути формальним документом, який оформила робоча група з розділами, що покривають наведені елементи:
- Виїзне відключення — який рівень обслуговування є прийнятним, кого інформувати, які дії потрібно виконати, підтвердження відновлення послуги та дії з запобігання повторенню. Усі автоматизовані процедури тестування, які використовує робоча група, повинні відповідати очікуваному допустимому збою та SLA.
- Помилки — хто може повідомляти, призначення рівні тяжкості, класифікацію, дії з визначення, хто відповідає за вирішення та підписання.
- Ескалація — рівні ескалації, призначення персоналу на рівні, обов’язки на кожному рівні, списки розповсюдження для кожного рівня тощо.
SLA слід зберігати на порталі документації робочої групи та за необхідності оновлювати.
Надання підтримки програм
Найкращий підхід до надання підтримки програм, вказаної в SLA полягає в тому, щоб команда, яка створила рішення, також несла відповідальність за його підтримку. Переваги цієї системи
- Вона стимулює кращу якість розробки, оскільки ті, хто створив програму, знали, що це потрібно для її підтримки.
- Автори зможуть знаходити та виправляти помилки швидше, ніж стороння робоча група, тому що вони краще знають програму.
- Передавання виправлення потенційного важливого програмного забезпечення іншій робочій групі може деморалізувати та віднімати багато часу в цій робочій групі. Як і в інших етапах створення, розробки та розгортання програм, зведена робоча група має в разі потреби співпрацює з IT-відділом для отримання допомоги.
Моніторинг задоволення від програми та зручності її використання
Кінцевою частиною зусиль із підтримки є моніторинг і оцінка задоволення та зручності використання розгорнутої програми. Тут знадобляться показники разом із більш традиційними методами, як-от опитування та анкети. Для отримання додаткових відомостей про моніторинг використання програми див. Адміністративну аналітику для Power Apps.
Зрештою, якщо клієнти не використовують опубліковану програму, ця програма не виконує її призначення. Регулярні зустрічі щодо огляду можуть перевірити ці показники задоволеності та зручності використання, щоб створити цикл позитивного зворотного зв'язку, який може змінити чи додати історії до журналу невиконаних завдань для створення та наступного розгортання оновленої версії програми.
Підсумок
Розробка інструментів без коду та з мінімальним кодом, наприклад Power Apps, розширила можливості для бізнес-технологій або розробників для створення, розробки та розгортання програм. Така розробка найкраще працює в середовищі зведеної робочої групи у складі власника продукту, фахівця з доменів, провідного розробника та адміністратора, при цьому ця команда за потреби залучає інші ресурси.
Інтеграція підходів гнучкої розробки і розробки за методом scrum у межах зведених робочих груп призводить до більш швидкої розробки програм і вищої ймовірності успішного розгортання з набором функцій, що має важливе значення для бізнесу. Застосовуючи ці передові практики, вказівки та рекомендації, ваша зведена робоча група зможе використовувати Power Apps для вирішення проблем цифрового перетворення організації.