Ortak geliştirme idaresi

Etkin bir ortak geliştirme idaresi çerçevesi belirlemek, oluşturucu tanımlı projelerde ve füzyon takımlarında tutarlılığı ve tekrarlanabilirliği sağlamanın önemli bir parçasıdır. Bu makalede, bir idare akış çizelgesi tanımlamaya yönelik bir yaklaşım açıklanmaktadır.

Uçtan uca süreci tanımlama

Aşağıdaki süreci bir örnek olarak kullanabilir ve kuruluşunuzun en iyi uygulamalarına göre özelleştirebilirsiniz. Gerekli sonuca ulaştığınız sürece her adımı tamamlamanız gerekmez.

Kapsama özellik ekleme

Kapsamlar, genel deneyimi destekleyen özellikler ekleyerek projenizi planlamanıza olanak sağlar. Kapsam, takımın uymayı amaçladığı genel yol haritasını da sağlar.

Kapsama yeni bir özellik eklerken hedef, genel kapsamı tanımlamak olur. Sonra her bir özellik, kod geliştirme çalışmalarını destekleyen iş değerini, taslak hikaye başlıklarını, kapsamı ve veri modeli değişikliklerini tanımlar.

Ayrıca, işle ilgili kritik bir özellik eklerken, testinizi otomatikleştirmek için tüm kritik senaryoları belirlemeniz önerilir. Özelliklerinizi ekledikten sonra, Kapsam İşbirliği Toplantınızı planlayabilirsiniz.

Kapsam işbirliği toplantısı

Bu toplantının odak noktası, her önerilen yeni özelliği gözden geçirme ve iki kez aynı çalışmanın tekrarlanmasını önlemek için bu işlevselliği zaten sağlayan mevcut uygulamalar, senaryolar ve veri modelleri olup olmadığını kontrol etme ile sınırlıdır. Bu toplantı aynı zamanda diğer uygulamalardaki etkileri tartışma fırsatı sağlar. Son olarak, bu özelliğin bir Deneyim İncelemesi gerektirip gerektirmediğini denetlemeniz gerekir.

Kapsama öyküler ve film şeridi ekleme

Kapsam işbirliği toplantısından sonra, özelliğin altına herhangi bir taslak kullanıcı hikayesi başlığı eklenebilir. Bu noktada, ayrıntılar gerekmez ve kullanıcı hikayesinin durumu "Yeni"dir. Hikayeleri kapsam veya pano görünümünde görüntüleyebilirsiniz.

Aşağıdaki şekilde, kapsama eklenmiş olan örnek kullanıcı hikayesi gösterilmektedir.

Bu aşamada, iş akışına ve uygulamaya göre çalışmaları düzenleyerek kaliteyi korumak çok önemlidir. Bu yaklaşım, ilgili çalışma öğelerinin bir arada tutulmasına yardımcı olur ve her çalışma akışında uzmanların her bir uygulamadaki işlevsellik ve veri kullanımı hakkında ayrıntılı bilgi sahibi olmasını ve bunları geliştirmesini sağlar.

Deneyim incelemesi

Deneyim İncelemeleri, son kullanıcı deneyimine odaklanır ve takımınızın en iyi uygulamaları izlediğinden emin olmanızı sağlar. Bu tutarlılık, tüm uygulamalarınızın son kullanıcılar ve destek takımları için güvenilir ve yinelenebilir bir deneyim sunmasını sağlar.

Hikaye ayrıntıları ekleme

Tipik bir kullanıcı hikayesi eklemek için aşağıdaki bilgiler gereklidir:

1. Başlık: <persona> (kişi) olarak, <impact/priority/value> (etki/öncelik/değer) için <do something> (şunu yapabilirim)
2. Açıklama : Açıklama, aşağıdakiler gibi belirli temel detayları içerir (ancak bunlarla sınırlı değildir):
   • İstenen sonucu özetleyen senaryonun kısa açıklaması
   • Anlatım: Kullanıcıların gezinmek ve senaryoyu tamamlamak için yapması gereken eylemleri açıklar
   • Alternatif anlatım: Kullanıcıların aynı sonuca ulaşabileceği diğer yolları açıklar
   • Tasarım Notları: Varlık, alanlar, görünümler, örnek ekranlar ve kullanıcı hikayesiyle ilişkilendirilmiş iş kurallarını kaydeder
   • Etkilenen Güvenlik Rolleri: Kullanıcı hikayesinden etkilenen veya bu hikayeyle ilgili olan tüm güvenlik rollerini listeler.

Tüm bu ayrıntıları ekledikten sonra, kullanıcı hikayesinin durumunu "İncelemeye Hazır" olarak değiştirirsiniz. Çoğu durumda, özellik takımı ve iş takımı (mümkünse) kullanıcı hikayelerini gözden geçirir.

Hikaye incelemesi

Hikaye İncelemeleri, tüm ayrıntıların öyküde bulunduğundan ve belirsizlik olmadığından emin olmak için genellikle füzyon takımında gerçekleştirilir. Tüm incelemeler tamamlandıktan sonra kullanıcı hikayesini bir takım üyesine atamanız önerilir. Geliştirme süreci sırasında takımınızın işbirliğine devam etmesi, genel hedeflerinizi elde etmek için büyük önem taşır.

Görev ve test çalışmaları ekleme

Hikayeleri gözden geçirdikten sonra, takım üyeleri Azure DevOps'ta görevler oluşturur. Görevlerin ve test çalışmalarının eklenmesine yönelik genel süreç aşağıdaki gibidir:

1. Sprint kapsamı açın. Alternatif olarak, yeni bir sprint oluşturun.
2. Mevcut iş öğelerini sprint'e ekleyin. Sprint içinde görünmeyen çalışma öğelerini önceden eklediyseniz, alan ve yineleme yollarını denetlemeniz gerekir. İlgili iş öğelerine hiçbir ana öğeden alınmamış görev atamayı unutmayın.
3. Kapsam öğelerine görevler ekleyin. Sprint'iniz tarafından atanan kapsam öğesi yoksa bu işlemi hemen yapın. Sprint başlangıç ve bitiş tarihlerini de ayarlayın.
4. Görev formunu doldurun. Pratik bir kural olarak görevlerin tamamlanması bir günden uzun sürmemelidir. Bu zaman ölçeğinden daha büyük olan görevler bölünmelidir.
5. Herhangi bir ana öğeye ait olmayan görevleri izleyin veya bütünleştirin. Ana öğeye bağlı olmayan görevleri diğer görevler gibi izleyebilir ya da bunları ana öğeye bağlamak için mevcut bir kapsam öğesine sürükleyebilirsiniz.

Görev ve test çalışmaları ekledikten sonra, sprint kapasitesini ayarlama işlemine başlayabilirsiniz.

Görev ekleme hakkında daha fazla bilgi için sprint planlama desteği için Kapsam öğelerine görev ekleme makalesine bakın.

Çözüm hazırlama

Başarılı bir ortak gelişmeye yönelik önemli bir görünüş, yapılandırılmış bir yayımlama yönetim işlemidir. Çözümler, uygulama yaşam döngüsü yönetimi (ALM) uygulamaya yönelik çözümlerdir; çözümler verme ve alma yoluyla faaliyetleri ortamlar arasında dağıtmak için de kullanılır. Bir bileşen, uygulamanızda kullanılan bir yapıtı ve potansiyel olarak özelleştirebileceğiniz bir şey temsil eder. Bir çözüme dahil edilecek tablolar, sütunlar, tuval uygulamaları ve model temelli uygulamalar, Power Automate akışları, sohbet botları, grafikler ve eklentiler gibi herşey bir bileşendir.

Dağıtımlar

Bileşenler, karmaşıklık ve takım hızını esas alarak tamamlanması için birden çok Sprint'i alabilir. Görevlerin tamamlanması için bileşenler geliştirme ortamındaki çözüme eklenmelidir. Ardından, çözümler test edildikten sonra bir üretim ortamına alınır. Uçtan uca test yapmak için tek bir sınama ortamı tutmanızı ve üretime geçmeden önce çözüm dağıtımını denemeniz önerilir.

Power Platform ortamları

Ortamlar kuruluşunuzun ticari verilerini, uygulamalarını depolamak, yönetmek ve paylaşmak için kullanılan bir alanlardır. Farklı rollere, güvenlik gereksinimlerine veya hedef kitlelere sahip olabilen uygulamaları ayırmak için kapsayıcı işlevi de görürler.

Kuruluşunuzda her takımın kendi çözümlerini geliştirmekte olduğu çok sunuculu bir Fusion kurulumu varsa, Sprint 'ler ve sürümlerin süresini koordine etmek önemlidir. Sprint'ler proje zaman çizelgesi boyunca tutarlı bir uzunluk olmak zorunda değildir ve her bir grubun tercihlerine göre takımlar arasındaki süreye göre farklılık gösterebilir. Ancak, sürüm temposu tüm takımlar arasındaki en kısa Sprint süresinden daha az olamaz.

Kaynak denetimi

Azure DevOps gibi bir kaynak kodu denetim sistemi kullanabilirsiniz. Azure DevOps, iş planlamak, kod geliştirmede işbirliği yapmak ve uygulamaları oluşturmak ve dağıtmak için destek takımları için geliştirici servisleri sağlar.

Uygulamalarınızı ve özelleştirmelerinizi içeren geliştirme ortamınızdan bir çözümü verin, çözümünüzü paketten çıkarma yapın ve bileşenleri kaynak denetimi sisteminde depolayın.

Gelişmiş konu: Çekme isteği (PR) incelemeleri

Yalnızca etkin olan ve gözden geçirilmiş ve onaylanmış hikayeler için PR oluşturmanız gerekir. Azure Boards'ta takımınız için Scrum uygulamalarını izleme makalesinde belirtilen sprint ve geliştirme yönergelerine uyarak çözüm sürümü oluşturma işleminin doğru yapıldığından emin olmalısınız. PR'den gelen test sonuçları oluşturulan işlevselliği anlatan ekran görüntüleri veya videolar olabilir.

PR idare işlemini otomatikleştirmek, çözüm sürümleri gibi temel denetimlerin el ile gözden geçirilmesi gerekmeden kod kalitesinin sağlanmasına yardımcı olur.

Şablonlar ve standartlaştırma

Şablonlar ve standartlaştırma, takım içinde tutarlılığı artırmaya yardımcı olarak verimliliği sağlar. Ekleme görevleri, öykü gözden geçirme sunuları veya kullanıcı öykülerini, özellikleri, hataları veya— görevleri tanımlarken zamandan tasarruf etmeye yardımcı olan ve ekiplere rehberlik sağlayan iş öğesi şablonları olsun, ekip operasyonlarının— tüm yönleri standartlaştırma ve basitleştirmeden yararlanır.

Etkin destek modeli uygulama

Etkin destek modeli, önceki bölümde bir destek matrisi oluşturma hakkında vurgulandığı şekilde dağıtımdan sonra uygulamanın uzun süreli başarısı için gereklidir. Hatalar ve kesintiler kaçınılmaz olduğundan, takımın bu durumlarla ilgili olarak yapılandırılmış bir yaklaşımı olması ve destek matrisinin gerekli çerçeveyi sağlaması çok önemlidir.

Servis düzeyi sözleşmesi oluşturma

Tüm destek modellerinin temel etkenlerinden biri, servis düzeyi sözleşmesinin (SLA) tanımıdır. SLA, takımın aşağıdaki öğeleri kapsayan bölümlerle hazırladığı resmi bir belge olmalıdır:

• Kesintiler: Hangi hizmet kesintisi düzeyinin kabul edilebilir olduğu, kimin bilgilendirilmesi gerektiği, yapılması gereken eylemler, servis devamının onaylanması ve yinelenmesini önleyen eylemler. Takımın kullandığı tüm otomatik sınama yordamları, beklenen kesinti toleransına ve geçerli SLA'ya uygun olmalıdır.
• Hatalar: Bildirim yapabilecek kişiler, önem düzeylerinin atanması, sınıflandırma, algılamayla ilgili eylemler, hatanın giderilmesinden sorumlu olan kişi ve tamamlama.
• Görev aktarımları: Görev aktarma düzeyleri, düzeylere personel atama, her düzeydeki sorumluluklar, her düzeyin dağıtım listeleri vb.

SLA, takımın belge portalında depolanmalıdır ve gerektiğinde güncelleştirilmelidir.

Uygulama desteği sunma

SLA'da belirtilen uygulama desteğini sunmanın en iyi yaklaşımı, çözümü yaratan takımın çözümü desteklemekten de sorumlu olmasıdır. Bu sistemin yararları şunlardır:

1. Uygulamayı oluşturan kişiler bunu desteklemeleri gerektiğini bildiklerinden, daha iyi kalitede geliştirmeyi teşvik eder.
2. Oluşturucular, uygulamayı daha iyi bilediklerinden, üçüncü taraf takımdan daha hızlı hataları bulabilir ve düzeltebilir.
3. Kritik öneme sahip olabilecek yazılımların başka bir gruba düzeltilmesi söz konusu grup için moral bozucu ve zaman kaybı olabilir. Uygulama oluşturma, geliştirme ve dağıtımının diğer aşamalarında olduğu gibi füzyon takımı gerektiğinde yardım için BT ile işbirliği yapmalıdır.

Uygulama memnuniyetini ve kullanılabilirliğini izleme

Destek çalışmalarının son kısmı, dağıtılan uygulamanın memnuniyet ve kullanılabilirliğini izleme ve değerlendirmedir. Burada anket ve formlar gibi geleneksel yöntemlerin yanı sıra metrikler de faydalıdır. Uygulama kullanımını izleme hakkında daha fazla bilgi için Power Apps için Yönetici Analizleri başlıklı makaleye bakın.

Son olarak, müşteriler yayımlanmış bir uygulamayı kullanmıyorsa söz konusu uygulama amacına hizmet etmiyordur. Düzenli inceleme toplantılarında bu memnuniyet ve kullanılabilirlik ölçümleri denetlenebilir. Böylece, uygulamanın güncelleştirilmiş sürümünü oluşturup dağıtmak üzere kapsama hikaye ekleyen veya kapsamdakileri değiştiren olumlu bir geri bildirim döngüsü oluşturulur.

Özet

Power Apps gibi hiç kod kullanılmayan veya az kod kullanılan araçların geliştirilmesi iş teknoloji uzmanlarının veya oluşturucuların uygulama oluşturmasına, geliştirmesine ve dağıtmasına yönelik seçenekleri geliştirdi. Bu geliştirme, bir ürün sahibini, alan uzmanını, profesyonel geliştiriciyi ve bir yöneticiyi içeren bir füzyon takımı ortamında en iyi şekilde sonuç verir.

Füzyon takımlarında çevik ve scrum geliştirme yaklaşımları, daha hızlı uygulama geliştirme sağlar ve işletmede önemli bir fark yaratan özelliklerin yer aldığı başarılı bir dağıtım olasılığını artırır. Füzyon takımınız bu en iyi uygulamaları, yönergeleri ve önerileri uygulayarak Power Apps'i kuruluşunuzun dijital dönüşümde karşılaştığı zorluklar için kullanılabilir.