Ператварыце вынік у ініцыятыву

Апішыце вынік да крокаў

Выдуманаму сэрвісу абсталявання патрэбна самаабслугоўванне супрацоўнікаў. Карысны запыт фармулюе вынік: «Аўтэнтыфікаваны супрацоўнік можа стварыць запыт і бачыць толькі ўласныя запыты».

Растлумачце, чаму гэта важна: цяпер кіраўнікі ўводзяць запыты за супрацоўнікаў. Вызначце абсяг: стварэнне запытаў, паказ стану, праверкі доступу і доказы гэтых паводзін. Выключыце аўтаматычныя закупкі і змены правіла ўхвалення кіраўніком.

Не прадпісвайце праўкі файлаў да вывучэння рэпазіторыя. Ініцыятыва фіксуе задуму; дэталёвае планаванне ператварае яе ў крокі рэалізацыі.

Праверце вынік запыту

Taiga выкарыстоўвае запыт і кантэкст прадукту, каб стварыць ініцыятыву або ўпарадкаваны набор ініцыятыў. Новая праца трапляе ў Backlog. Большы запыт можа патрабаваць некалькіх змен, якія можна праверыць незалежна.

Прачытайце згенераваны канчатковы стан, Why і Scope. Праверце, што неабходныя паводзіны захаваны, а выключэнні ўлічаны. Калі наяўная ініцыятыва ўжо ахоплівае запыт, Taiga можа назваць яе замест стварэння дубліката.

Запыт, заблакаваны апублікаванай палітыкай, патрабуе працэдуры прыняцця рашэнняў, вызначанай гэтай палітыкай. Прачытайце тлумачэнне і вырашыце канфлікт праз гэтую працэдуру. Не перапісвайце запыт толькі дзеля таго, каб схаваць забароненае дзеянне.

Разглядайце дошку як паслядоўнасць выканання

Taiga працуе з адной ініцыятывай прадукту за раз, уключаючы планаванне. Яна пачынае наступную ініцыятыву ў чарзе пасля merge бягучага pull request. Яна не перамяшчае элементы з Backlog або Todo ў Queue аўтаматычна.

Размяшчэнне ў чарзе мае значэнне. Яно адмяняе чаканне незавершаных залежнасцей. Перад пастаноўкай самаабслугоўвання супрацоўнікаў у чаргу пацвердзіце, што аснова ідэнтыфікацыі існуе або што выбраны абсяг належным чынам яе стварае.

Праверце дэталёвы план

Планавальнік чытае рэпазіторый, дакументы прадукту, палітыкі, інструкцыі і кантэкст разгортвання. Праверце план паводле фактычнага выніку для карыстальніка і асяроддзя.

Для сэрвісу абсталявання праверце тры выпадкі доступу. Супрацоўнік бачыць свой запыт. Іншы супрацоўнік не можа яго бачыць. Кіраўнік захоўвае задуманы доступ для разгляду. Уключыце міграцыю даных і эксплуатацыйныя наступствы, калі рэалізацыя іх змяняе.

Калі Build on its own by default выключана, завершаны план чакае вашага рашэння. Approve запускае рэалізацыю ад імя чалавека, які ўхваляе план, з улікам яго дазволаў. Reject выкарыстоўвае ваш водгук для паўторнага планавання. Ініцыятыва можа мець уласную наладу.

Выкарыстоўвайце адпаведны запіс для наступнага рашэння

Планы маюць версіі. Запуск фіксуе, які план ён выконваў. Калі задуманы падыход змяняецца, праверце ініцыятыву і адпаведнае дзеянне паўторнага планавання. Каб вывучыць папярэднюю спробу, выкарыстоўвайце запуск.

Рэалізацыя, змерджаны pull request і выпуск у production — розныя станы. Па меры працы захоўвайце бачнымі доказы прыёмкі і адказнасць за разгортванне. Працягвайце з наладамі аўтаномнасці.