Aracılığıyla paylaş

Yazılım geliştirme ve yönetimi resmileştirmeye yönelik öneriler

  • Makale

Bu Azure Well-Architected Framework Operasyonel Mükemmellik denetim listesi önerisi için geçerlidir:

OE:03 Yazılım fikri ve planlama süreçlerini resmileştirin. Yerleşik sektör ve kuruluş standartlarından çizim yapma. Ortak, önceliklendirilmiş kapsam ve yeterince ayrıntılı belirtimler kullanın. Sonuçlara bağlı olarak, planlama sürecinizde sürekli iyileştirmeler sağlayın.

Bu kılavuzda, yazılım geliştirme uygulamalarının belirlenmiş standartlara uygun olarak yönetilmesine yönelik öneriler açıklanmaktadır. Ekibinizin yüksek kaliteli yazılım üretme becerisi, geliştirme planlamasına yönelik yapılandırılmış, işbirliğine dayalı bir yaklaşıma dayanır. Ürün sahipleri ve yöneticileri, geliştiricilerin bir geliştirme döngüsünde herhangi bir zamanda yaptıkları işleri net bir şekilde anlamalı ve paydaşlara ifade edebilmelidir. Buna karşılık, geliştiricilerin iyi yazılmış özellikler, kullanıcı hikayeleri ve kabul ölçütleri aracılığıyla geliştirme döngüsünün hedeflerini anlaması gerekir. Belirlenmiş standartlar geliştirme uygulamalarının nasıl gerçekleştirilmesi gerektiğini tanımlar ve iş yükü ekibinin etkili bir şekilde işbirliği yapmasına olanak tanıyarak hedefler ve beklentiler üzerindeki karışıklık riskini azaltır.

Temel tasarım stratejileri

Ürün sahiplerinin, proje yöneticilerinin ve geliştiricilerin her sprint'in hedeflerini anlamasını ve proje katılımcılarına tutarlı kalite sunmasını sağlamaya yardımcı olmak için yazılım geliştirme uygulamalarınızı resmileştirin. Geliştirme uygulamalarıyla ilgili yönergeleri gözden geçirmek için sürekli tümleştirme kılavuzuna bakın.

Geliştirme planlaması standartları

  • İşbirliği: İş yükünde önerilen değişiklikleri tanımlama süreci işbirliğine dayalı bir çalışma olmalıdır. İş yükündeki değişikliklerin çoğu birden çok işlevi ve/veya bileşeni etkiler; bu nedenle mümkün olduğunca çok iş yükü ekibi üyesinin dahil edilmesi önemli noktaların kaçırılmamasını ve herkesin kendi etki alanı üzerindeki etkisinin farkında olmasını sağlamaya yardımcı olur. İşbirliği ayrıca değişikliğin kapsamını ve değişikliği gerçekleştirmek için gereken görevlerin iyi tanımlanmış iş öğelerine nasıl bölüneceğinin açık bir şekilde tanımlanmasına yardımcı olur. Etki alanları arasında uzmanlığı olan daha büyük bir grup, gerekli çaba için deneyim destekli tahminler sağlayabilir.

  • Araçlar: Çevik, Scrum ve Kanban panoları gibi yerleşik, sektörde kanıtlanmış araçları ve süreçleri kullanın. Kendi araçlarınızı ve süreçlerinizi geliştirmek, iş yükünüz üzerinde harcanabilecek zaman ve geliştirme döngülerini alma konusunda önemli bir çalışmadır. En deneyimli DevOps mühendisleri ve ürün sahipleri bu tür araçlar ve süreçler hakkında bilgi sahibidir, bu nedenle bunları benimsemedeki öğrenme eğrisi en düşük düzeyde olmalıdır. Benzer şekilde, yeni işe alımlar için katılım süreci de standart araç ve süreçlerin kullanılmasından da yararlanacaktır çünkü aynı araçlara ve süreçlere zaten maruz kalma olasılığı yüksektir.

Denge: Çevik metodolojisi fazla açıklayıcıysa çok katı hale gelebilir. İyi tanımlanmış standartlar ve yenilikler arasında bir denge elde etmek için çaba gösterin.

  • Dağıtım: Büyük seyrek dağıtımlar yerine sık kullanılan küçük, yinelemeli dağıtımlar kullanmayı planlayın. Bu yaklaşımın kullanılması, kullanıcı hikayelerini ve iş öğelerini proje yönetimi açısından yönetilebilir tutmaya ve dağıtımlar başarısız olduğunda büyük ölçekli sorun riskini azaltmaya yardımcı olur.

  • Terimler: Test, belgeler ve erişilebilirlik özellikleri gibi destekleyici işlevlerin başarıyla tamamlandığından emin olmak için tamamlanmış geliştirme döngüleri tanımınızı standartlaştırın.

  • İletişim: Ürün sahipleri ve proje yöneticilerinin gelecek sürümleri dahili ve harici olarak tanıtmalarına yönelik standart protokolleri tanımlayın. Örneğin, gelecek sürümler hakkında dış taraflara yönelik iletişimler için bir standart ayarlayabilirsiniz. Standart, iletişimin yayından iki hafta önce gönderilmesini ve yayından 24 saat önce bir anımsatıcı gönderilmesini gerektirebilir.

  • Kullanıcı hikayeleri: Kullanıcı hikayeleri için bir şablonu standartlaştırma. Her kullanıcı hikayesinin, son kullanıcının perspektifinden yazılmış ayrı bir çalışma birimi olduğundan emin olun. İyi yazılmış kullanıcı hikayeleri aşağıdaki özelliklere sahip olmalıdır:

    • Her kullanıcı hikayesi birbirinden tamamen bağımsız olmalıdır. Kullanıcı hikayelerini birbirinden bağımsız tutmak, çakışan işlerle karışıklığı önler ve ekibin belirli bir kullanıcı hikayesi üzerinde çalışmanın diğer kullanıcılar üzerindeki çalışmaya bağlı olup olmadığını anlamasına yardımcı olur ve bu da zamanlama ve öncelik belirleme konusunda yardımcı olur.

    • Her kullanıcı hikayesi tartışılabilir. Hem son kullanıcı hem de iş yükü ekibi üyelerinin perspektifleri, kısa bir süre içinde gerçekleştirilebilecek gerçekçi kullanıcı hikayelerini yakalamak için gereklidir.

    • Kullanıcı hikayeleri son kullanıcı için değerlidir. Son kullanıcının perspektifinden kullanıcı hikayeleri yazdığınızda, görmekle ilgilendiği ve deneyimlerine değer katacak değişiklikleri yakalarsınız. Kullanıcı hikayesi iş öğelerine ayrılmış olarak bu odağın tutulması, her dağıtımın gelişmiş bir deneyim sağladığından emin olunmasını sağlar.

    • Bir kullanıcı hikayesi için gereken çaba yüksek düzeyde güven ile tahmin edilebilir. Belirli bir kullanıcı hikayesi için gereken saatleri yakın bir şekilde tahmin edebilmeden planlama zor olur ve eksik son tarihler artarak planlanan diğer çalışmalarda art arda etkilere neden olabilir.

    • İyi yazılmış kullanıcı hikayeleri küçük olduğundan birkaç hafta içinde tamamlanabilir. Daha küçük kapsamlı hikayeler, tahmin edilebilir ve yönetilebilir kalmalarına yardımcı olur ve iş öğelerinin ulaşılabilir kalmasına yardımcı olur.

    • Kullanıcı hikayeleri test edilebilir olmalıdır. Bir özelliğin teslim edildiğini test edebilmeden, son kullanıcı hedefe ulaşıldığına güvenemez. Belirli bir kullanıcı hikayesi için henüz bir test yazılmamış olsa bile, özelliğin teslimini kanıtlamak için testin nasıl geliştirilebileceğini net bir şekilde anlamanız gerekir.

  • Kabul ölçütleri: Bir şablonu kabul ölçütleri için standartlaştırma. Kabul ölçütlerinin özellikle kullanıcı hikayesiyle ilişkili olduğundan ve bir veya daha fazla kabul testi kullanılarak açıkça kanıtlanabilir olduğundan emin olun.

  • İzleme: Geliştirme işleminin izlenebilir olduğundan emin olun. Üretim iş yükünüzün durumunu ve ilişkili kodu kalite güvencesi testine, kabul ölçütlerine, kullanıcı hikayelerine ve özelliklere kadar net bir şekilde izlemeniz gerekir. Ayrıntılı izleme, örneğin sağlık hizmetleri gibi bazı durumlarda da yasal bir gereksinim olabilir.

  • Gözden geçirme: Geliştirme döngüleri geçmişe dönük değerlendirmeler ve otopsiler aracılığıyla geliştirme uygulamalarınızın iç denetimlerini düzenli olarak gerçekleştirin. Süreç yansıması suçsuz olmalı ve iyileştirme olarak uygulanabilecek öğrenmeye odaklanmalıdır. Ekibin, kullanıcı hikayesinin ve görevlerinin gerekli görevleri tanımlamada ne kadar etkili olduğunu ve zaman tahminlerinin doğruluğuna yansıtmasını sağlayın.

  • Raporlar: Değişikliklere odaklanan yararlı ölçümler sağlayan proje katılımcıları için raporları standartlaştırın. Değişikliğe odaklanmak, ürün hızlandırmayı ve yavaşlama durumunu izlemenizi sağlar. Yararlı ölçümler şunlardaki değişiklikleri içerebilir:

    • Benimsemenin aylık büyüme oranı.

    • Performans.

    • Eğitim zamanı.

    • Olayların sıklığı.

    Raporlama, kişilerin çalışmalarını değerlendirmek için bir araç olarak kullanılmamalıdır, bu nedenle her mühendis için hikaye noktaları veya kod satırları gibi ölçümlerden kaçının.

Azure kolaylaştırma

Azure Boards, ekiplerin geliştirme sürecinin tamamında çalışmayı planlamasını, izlemesini ve tartışmasını sağlayan web tabanlı bir hizmettir. Çevik tabanlı geliştirme uygulamaları için çok uygundur.

GitHub Projeleri , projeleri düzenleyebilen ve GitHub'daki sorunları ve çekme isteklerini kullanarak tümleştirilebilen özelleştirilebilir bir proje yönetim aracıdır.

Operasyonel Mükemmellik denetim listesi

Önerilerin tamamına bakın.

Operasyonel Mükemmellik denetim listesi