Dijital buluşla benimsemeyi güçlendirme

  • Makale

İnovasyonun nihai testi, buluşunuza müşteri tepkisi vermektir. Hipotez doğru mu? Müşteriler çözümü kullanıyor mu? İstenen kullanıcı yüzdesinin gereksinimlerini karşılayacak şekilde ölçeklendirilebilir mi? En önemlisi, geri dönüp duruyorlar mı? En düşük uygulanabilir ürün (MVP) çözümü dağıtılana kadar bu soruların hiçbiri sorulamaz.

Bu makalede, sürekli tümleştirme ve sürekli dağıtım (CI/CD) işlem hattı araçlarıyla benimsemeyi güçlendirmeye odaklanacağız. Sürekli tümleştirme, güncelleştirilmiş tek bir projeye sahip olmak için kodun günde birden çok kez otomatikleştirilmesidir. Sürekli dağıtım, bu işlevlerin gün boyunca otomatik olarak teslim edilmesidir.

Benimsemeyi etkileyen CI/CD uyuşmalarını azaltma

Benimsemenin önündeki bazı engeller teknoloji ve süreçlerin birleşimiyle en aza indirgenebilir. CI/CD veya DevOps işlemleri hakkında bilgi sahibi olan okuyucular için aşağıdaki CI/CD işlem hattı işlemleri tanıdık olacaktır. Bu makale, bulut benimseme ekipleri için yenilik ve geri bildirim döngülerini destekleyen bir başlangıç noktası oluşturur. Bu başlangıç noktası, ürünler ve takımlar olgunlaştıkça daha güçlü CI/CD veya DevOps yaklaşımlarını teşvik edebilir.

Müşteri etkisini ölçme bölümünde açıklandığı gibi, hipotezlerin olumlu doğrulanması için yineleme ve belirleme gerekir. Bu CI/CD makalesi, yeniliği yavaşlatan teknik ani artışları en aza indirmeyi amaçlarken, en iyi yöntemleri yerinde tuttuğunuzdan emin olmayı amaçlar. Bunun yapılması, mevcut müşteri ihtiyaçlarını karşılarken ekibin gelecekteki başarıya yönelik tasarımına yardımcı olur.

Benimsemeyi ve dijital buluşu güçlendirme: Olgunluk modeli

Yenilik metodolojisinin birincil hedefi müşteri ortaklıkları oluşturmak ve pazar yeniliklerine yol açan geri bildirim döngülerini hızlandırmaktır. Aşağıdaki görüntüde ve bölümlerde bu metodolojiyi destekleyen ilk uygulamalar açıklanmaktadır.

Benimseme olgunluk modelini güçlendirmeyi gösteren diyagram.

Teknik ani artışları en aza indirmek için, bu ilkeler genelinde olgunluğun başlangıçta düşük olacağını varsayalım. Hipotezler daha ayrıntılı hale geldikçe ölçeklenebilen araçlara ve süreçlere hizalayarak önceden plan yapın. Azure'da GitHub ve Azure DevOps , küçük ekiplerin çok az sürtüşmeye başlamasına olanak tanır. Bu ekipler, ölçek çözümleri üzerinde işbirliği yapan ve yüzlerce müşteri hipotezini test eden binlerce geliştiriciyi içerecek şekilde büyüyebilir. Bu makalenin geri kalanında, bu ilkeler genelinde benimsemeyi güçlendirmeye yönelik "büyük planlama, küçük bir başlangıç" yaklaşımı gösterilmektedir.

Paylaşılan çözüm

Müşteri etkisini ölçme bölümünde açıklandığı gibi, hipotezlerin olumlu doğrulanması için yineleme ve belirleme gerekir. Herhangi bir yenilik döngüsü sırasında kazanmadan çok daha fazla hatayla karşılaşacaksınız. Bu beklenen bir durumdur. Ancak müşterinin ihtiyacı, hipotezi ve çözümü büyük ölçekte uyumlu hale geldiğinde dünya hızla değişir.

Dijital buluşları ve yenilikleri ölçeklendirdiğinizde, çözüm için paylaşılan kod tabanından daha değerli bir araç yoktur. Ne yazık ki, hangi yinelemenin veya hangi MVP'nin kazanan kombinasyonu getireceğini tahmin etmenin güvenilir bir yolu yoktur. Bu nedenle, paylaşılan bir kod tabanı veya depo oluşturmak için hiçbir zaman çok erken değildir. Bu, gecikmemesi gereken tek teknik ani artıştır . Ekip çeşitli MVP çözümlerinde yinelenirken, paylaşılan bir depo kolay işbirliği ve hızlandırılmış geliştirme sağlar. Çözümde yapılan değişiklikler öğrenme ölçümlerini aşağı sürüklediğinde, sürüm denetimi çözümün daha önceki ve daha etkili bir sürümüne geri dönmenizi sağlar.

Kod depolarını yönetmek için en yaygın olarak benimsenen CI/CD aracı, yalnızca birkaç adımda paylaşılan bir kod deposu oluşturmanıza olanak tanıyan GitHub'dır. Ayrıca, Azure DevOps'un Azure Reposözelliği git veyaTFVC deposu oluşturmak için kullanılabilir.

Geri bildirim döngüleri

Müşteriyi çözümün bir parçası yapmak, yenilik döngüleri sırasında müşteri ortaklıkları oluşturmanın anahtarıdır. Bu, kısmen müşteri etkisini ölçerek gerçekleştirilir. Müşteriyle konuşmalar ve doğrudan test gerektirir. Her ikisi de etkili bir şekilde yönetilmesi gereken geri bildirim oluşturur.

Her geri bildirim noktası, müşterinin ihtiyacı için olası bir çözümdür. Daha da önemlisi, doğrudan müşteri geri bildirimlerinin her bir parçası iş ortaklığının geliştirilmesine yönelik bir fırsatı temsil eder. Geri bildirim bunu bir MVP çözümüne dönüştürüyorsa bunu müşteriyle birlikte kutlayın. Bazı geri bildirimler eyleme dönüştürülemez olsa bile, geri bildirimin önceliklerini kaldırma kararıyla şeffaf olmak bir büyüme zihniyetini ve sürekli öğrenmeye odaklanmayı gösterir.

Azure DevOps, geri bildirim isteme, sağlama ve yönetme yollarını içerir. Bu araçlar, ekibin eyleme geçebilmesi ve şeffaf bir geri bildirim döngüsünün hizmetinde izleme sunabilmesi için geri bildirimleri merkezi hale getirmektedir.

Sürekli tümleştirme

Sürekli tümleştirme, güncelleştirilmiş tek bir projeye sahip olmak için kodun günde birden çok kez otomatikleştirilmesidir. Benimsemeler ölçeklendikçe ve bir hipotez büyük ölçekte gerçek yeniliklere yaklaştıkça, test edilecek küçük hipotezlerin sayısı hızla artma eğilimindedir. Doğru geri bildirim döngüleri ve sorunsuz benimseme süreçleri için bu hipotezlerin tümleştirilmesi ve yeniliğin ardındaki birincil hipotezi desteklemesi önemlidir. Bu, yenilik yapmak ve büyümek için hızlı bir şekilde hareket etmenizi gerektirir ve bu da çekirdek hipotez varyasyonlarını test etmek için birden çok geliştirici gerektirir. Daha sonraki aşama geliştirme çalışmaları için, her biri paylaşılan bir çözüme yönelik olarak birden fazla geliştirici ekibine bile ihtiyacınız olabilir. Sürekli tümleştirme, tüm hareketli parçaların yönetimine yönelik ilk adımdır.

Sürekli tümleştirmede kod değişiklikleri genellikle ana dalda birleştirilir. Otomatik derleme ve test işlemleri, ana daldaki kodun her zaman üretim kalitesi olmasını sağlar. Bu, geliştiricilerin doğru ve güvenilir geri bildirim döngüleri sağlayan paylaşılan çözümler geliştirmek için birlikte çalışmasını sağlar.

Azure DevOps ve Azure Pipelines , GitHub'da veya diğer depolarda yalnızca birkaç adımda sürekli tümleştirme özellikleri sağlar. Daha fazla bilgi için bkz. Sürekli tümleştirme nedir? veya sürekli tümleştirme uygulamalı laboratuvarını deneyin. Azure DevOps aracılığıyla CI/CD işlem hatlarınızın oluşturulmasını hızlandırabilen çözüm mimarileri mevcuttur.

Güvenilir test etme özelliği

Herhangi bir çözümdeki kusurlar hatalı pozitifler veya hatalı negatifler oluşturabilir. Beklenmeyen hatalar, kullanıcı benimseme ölçümlerinin kolayca yanlış yorumlanmasına neden olabilir. Ayrıca müşterilerden hipotezinizin testini doğru şekilde temsil etmeyen olumsuz geri bildirimler de oluşturabilirler.

Bir MVP çözümünün erken yinelemeleri sırasında hata olması beklenir. Erken benimseyenler bile onları çok fazla çabalasalar iyi olur. Erken sürümlerde, kabul testi genellikle yok olur. Ancak, empatiyle inşanın bir yönü, ihtiyacın ve hipotezin doğrulanmasıyla ilgilidir. Her ikisi de kod düzeyinde birim testleri ve dağıtımdan önce el ile kabul testleri aracılığıyla tamamlanabilir. Bunlar birlikte testlerde bazı güvenilirlik araçları sağlar. İyi tanımlanmış bir derleme, birim ve kabul testleri serisini otomatikleştirmeye çalışmanız gerekir. Bunlar, hipotezde ve sonuçta elde edilen çözümde daha ince ayarlamalarla ilgili güvenilir ölçümler sağlar.

Azure Test Plans özelliği, el ile veya otomatikleştirilmiş test yürütme sırasında test planları geliştirmek ve çalıştırmak için araçlar sağlar.

Çözüm dağıtımı

Benimsemeyi güçlendirmenin belki de en anlamlı yönü, bir çözümün müşterilere yayınlanmasını kontrol edebilmenizdir. Müşterilere çözüm yayınlamak için bir self servis veya otomatik işlem hattı sağlayarak geri bildirim döngüsünü hızlandırırsınız. Müşterilerin çözümdeki değişikliklerle hızlı bir şekilde etkileşim kurmasına izin vererek onları sürece davet edebilirsiniz. Bu yaklaşım hipotezlerin daha hızlı test edilmesine de neden olarak varsayımları ve olası yeniden çalışmayı azaltır.

Çözüm dağıtımı için çeşitli yöntemler vardır. En yaygın üç seçenek şunlardır:

  • Sürekli dağıtım , kod değişikliklerini otomatik olarak üretime dağıttığı için en gelişmiş yöntemdir. Olgun hipotezleri test eden olgun ekipler için sürekli dağıtım son derece değerli olabilir.
  • Geliştirmenin ilk aşamalarında sürekli teslim daha uygun olabilir. Sürekli teslimde, tüm kod değişiklikleri otomatik olarak üretim benzeri bir ortama dağıtılır. Geliştiriciler, iş karar alıcıları ve ekipte yer alan diğer kişiler, çalışmalarının üretime hazır olduğunu doğrulamak için bu ortamı kullanabilir. Devam eden iş etkinliklerini etkilemeden müşterilerle bir hipotezi test etmek için de bu yöntemi kullanabilirsiniz.
  • El ile dağıtım , sürüm yönetimine en az gelişmiş yaklaşımdır. Adından da anlaşılacağı gibi, ekipten biri en son kod değişikliklerini el ile dağıtır. Bu yaklaşım hataya eğilimli, güvenilir değildir ve deneyimli mühendislerin çoğu tarafından kötü model olarak kabul edilir.

Bir MVP çözümünün ilk yinelenmesi sırasında, önceki değerlendirmeye rağmen el ile dağıtım yaygın bir durumdur. Çözüm son derece akıcı olduğunda ve müşteri geri bildirimi bilinmediğinde, çözümün tamamını (hatta çekirdek hipotezini) sıfırlamada önemli bir risk vardır. El ile dağıtım için genel kural şu şekildedir: müşteri kanıtı yok, dağıtım otomasyonu yok.

Erken yatırım yapmak zaman kaybına yol açabilir. Daha da önemlisi, yayın işlem hattında, ekibi erken bir özete karşı daha dayanıklı hale getiren bağımlılıklar oluşturabilir. İlk birkaç yinelemeden sonra veya müşteri geri bildirimi olası başarıyı önerdiğinde, daha gelişmiş bir dağıtım modelinin hızla benimsenmesi gerekir.

Hipotez doğrulamasının herhangi bir aşamasında, Azure DevOps ve Azure Pipelines sürekli teslim ve sürekli dağıtım özellikleri sağlar. Sürekli teslim hakkında daha fazla bilgi edinin veya uygulamalı laboratuvara göz atın. Çözüm mimarisi, Azure DevOps aracılığıyla CI/CD işlem hatlarınızın oluşturulmasını da hızlandırabilir.

Tümleşik ölçümler

Müşteri etkisini ölçerken, müşterilerin çözümdeki değişikliklere nasıl tepki olduğunu anlamak önemlidir. Telemetri olarak bilinen bu veriler, bir kullanıcının (veya kullanıcı grubunun) çözümle çalışırken gerçekleştirdiği eylemlerle ilgili içgörüler sağlar. Bu verilerden hipotezin nicel doğrulamasını almak kolaydır. Bu ölçümler daha sonra çözümü ayarlamak ve daha ayrıntılı hipotezler oluşturmak için kullanılabilir. Bu daha ince değişiklikler sonraki yinelemelerde ilk çözümün olgunlaşarak benimsemeyi büyük ölçekte tekrarlamalarına yardımcı olur.

Azure'da Azure İzleyici, müşteri deneyimlerinden veri toplamak ve gözden geçirmek için araçlar ve arabirim sağlar. Azure Boards kullanarak kapsamı daraltmak için bu gözlemleri ve içgörüleri uygulayabilirsiniz.

Sonraki adımlar

Benimsemeyi güçlendirmek için gereken CI/CD işlem hattı araçları ve süreçleri hakkında bilgi edindikten sonra, daha gelişmiş bir yenilik uzmanlık alanı olan cihazlarla etkileşim kurma konusunu incelemenin zamanı geldi. Bu disiplin, fiziksel ve dijital deneyimler arasındaki engelleri azaltmaya yardımcı olarak çözümünüzü benimsemeyi daha da kolaylaştırabilir.

Cihazlarla etkileşim kurma