Çevik Projeleri Müşterilerin Genişletilmiş Dağıtılmış Ekibi Olarak Nasıl Çalıştırırız

Computer Economics tarafından yakın zamanda yayınlanan bir raporda, 2018/19 döneminde, uygulama geliştirme sürecinin, dünya çapındaki kuruluşların %56'sının geliştirme gereksinimlerini dış kaynaktan temin etmesiyle, maksimum dış kaynak kullanımı fırsatına tanık olan süreç olarak ortaya çıktığı tespit edildi.

Mobil uygulama geliştirme ihtiyaçlarının dış kaynak kullanımına yönelik bu artan talebin arkasındaki neden her zaman olduğu gibi aynı olmuştur – Kendi ülke geliştiricilerini istihdam ederse, ana işe daha fazla odaklanmaya ve daha iyi hizmet kalitesine izin verirse, ödenmesi gerekenden daha düşük maliyet.

Bununla birlikte, uygulama geliştirme endüstrisinde dış kaynak kullanımının merkezi bir yer almasına rağmen, müşterilerin yazılım geliştirme projelerini kendi coğrafi ülkeleri dışında dış kaynaktan temin etmeyi planladıklarında gösterdikleri bazı ortak endişeler olduğunu bulduk.

Bu makalede, Appinventiv'in dağıtılmış çevik geliştirme döngüsünü kullanarak açık deniz müşterileri ile nasıl çalıştığını inceleyeceğiz .

Ancak, müşterilerimizin dağıtılmış ekibi olarak nasıl çalıştığımızı ve onların genişletilmiş şirket içi teknoloji ekibi haline gelmemizi sağlayacak kadar kusursuz bir şekilde nasıl çalıştığımızı anlatacağımız kısma geçmeden önce, Dağıtılmış Çevik Ekibin ne anlama geldiğini bilmek bile önemlidir.

Dağıtılmış Çevik Ekip Deyince Neyi Kastediyoruz?  

Dağıtılmış ekip, bir şehirde bir ofis alanı veya hatta iki ofis alanı yerine iki veya daha fazla ekibin birden fazla coğrafi konumda işlev gördüğü olayı açıklamak için kullanılan bir kavramdır.
Dağıtılmış çevik ekip, sorunsuz bir şekilde etkileşim kurmak ve aynı hedef doğrultusunda birlikte çalışmak için dijital teknolojilere güvenir: Zamanında proje teslimi.

İşletmeler Neden Mobil Uygulama Geliştirme Dağıtılmış Ekibine Yatırım Yapıyor?

İşletmeleri dağıtılmış ekiplere yatırım yapmaya iten çeşitli nedenler vardır ve bunlar arasında şunlar sayılabilir:

1. Ülkelerinde yetenekli geliştiricilerin kıtlığı
2. Ekip oluşturmaya yönelik bir yatırım yapılmadan önce pazarı test etme ihtiyacı
3. Uygulamayı ölçeklendirme sırasında artırılabilen ve ihtiyaç sona erdiğinde çözülebilen esnek ekibin avantajından yararlanmak.

Tanım ve ihtiyaç artık dikkate alındığında, şimdi Appinventiv ekibinin müşterilerimizin dağıtılmış bir ekibi olarak nasıl çalıştığına bakalım. Ancak oraya atlamadan önce, tipik dağıtılmış çevik ekip yapımızın neye benzediğine hızlıca bakalım –

Dağıtılmış Çevik Geliştirmeye Appinventiv Yaklaşım  

Çoğu zaman, müşterinin FTE'leri ile yakın bağlantı içinde çalışmamızı gerektiren bir proje alırız. Bu gibi durumlarda işlerimiz arasına bin kilometrelik mesafelerin girmesine izin vermememiz ve gelişim sürecinde gerçek zamanlı olarak değişiklik yapıp aksiyon alabilmemiz çok önemli hale geliyor.

Sıfır iletişim gecikmesi ve yanlış anlama olmadan zamanında teslimatı nasıl sağladığımız, cevabı Dağıtılmış Çevik Metodoloji'de bulunan bir sorudur .

Hem küçük hem de büyük ölçekli işletmelere uygun, dağıtılmış çevik en iyi uygulamaları takip etmek, tamamen farklı bir zaman dilimine sahip başka bir coğrafi konumda oturan bir ekiple birlikte çalışmak zorunda kaldığımızda çok kullanışlı oluyor.

Mobil uygulama geliştirme sürecimizde uyguladığımız Dağıtılmış Çevik Geliştirme Yöntemine bir göz atalım.

Tüm ekip üyelerini birbirimizle tanıştırdıktan ve proje yönetim yazılımı ile işbirliği yaptıktan sonra asıl iş başlıyor.

Günlük çevik saldırı metodolojisi sürecini formüle ediyoruz . Geleneksel anlamda Scrum, her katılımcının görevlerinin durumunu paylaştığı ve ekibe bir sonraki yapacakları görevler hakkında bilgi verdiği 15 dakikalık yüz yüze toplantı gerektirse de, yarı yarıya olduğunda aynı süreci takip etmek neredeyse imkansızdır. ekibin bir kısmı başka bir zaman diliminde başka bir coğrafi ülkede oturuyor.

Scrum'da yüz yüze etkileşimin özünü canlı tutmak için yaptığımız şey, proje üzerinde çalışan ekipteki herkes için uygun olan, belirli bir zamanda bir video görüşmesi yapmaktır. Ekran paylaşımının yardımıyla Agile Scrum Master'ımız , Trello veya Jira gibi araçlar yardımıyla sanal sprint biriktirme listesi üzerinden çalışır ve her ekip üyesinin projenin nereye gittiği konusunda bir güncelleme yapmasına olanak tanır.

Deneyimlediğimiz şey, tüm ekip üyelerine kolay erişilebilir ve güncellenebilir bir görev takip platformuna erişim vermenin çok önemli olduğudur. Ayrıca, herkesin güncellemeleri paylaşması veya iki scrum zaman aralığı arasında şüphelerini sorması için Skype veya Slack gibi bir iletişim platformu kullanmayı vurguluyoruz.

Günlük çeviklik ve scrum süreci için takip ettiğimiz bir diğer yaklaşım da her farklı scrum için bir scrum master atamamızdır. Bu nedenle, her bireysel ekip, bir scrum yöneticisi ve ürün sahibi ile ayrı bir scrum ekibi olarak çalışır – Scrum of Scrums olarak da bilinen bir süreç.

Bunda, tüm scrum temsilcileri, scrum'da aşağıdaki sorulara yanıt verir:

• Son Scrum of Scrums'tan bu yana ekibin tamamladığı çalışma
• Çalışma ekibi bir sonraki Scrum of Scrums toplantısından önce yapmayı planlıyor.
• Takımın karşı karşıya olduğu mevcut engelleyici
• Başka bir Scrum takımına yol açabilecek engelleyici.

Yöntem, proje üzerinde çalışan tüm ana bireylerin birbirleriyle doğrudan etkileşime girmesini sağlar; bu, her zaman başlatma aşamasından başlatma dönemine kadar kendini adama ile sonuçlanır. Bu, herkesin söz hakkı olduğu tüm ekipler arasında açık, net ve şeffaf bir iletişim sağlar.
Scrum of scrum dışındaki süreç, tipik Agile metodolojisi kapsamında izlediğimiz ile aynıdır.
Ancak ekibimiz ile müşterilerimizin ekibi arasındaki mesafenin kilometrelerce uzakta olması ve yine de mümkün olduğunca sorunsuz çalışmamız gerektiği gerçeği, Distributed Agile'ın benimsenmesiyle elde ettiğimiz bir dizi öğrenmeyi beraberinde getirdi. Bu öğrenmelerin neler olduğuna bir göz atalım –

Dağıtılmış Çevik Geliştirme Süreci Üzerinde Çalışarak Çizdiğimiz Öğrenmeler

1. Dağıtılmış ekibin oluşturulması Bir Süreç Değil, Bir Kültür İnşa Etmektir

Dağıtılmış ekipler için çevik yaklaşımı altında çalışan bir projenin başarısını tanımlayan şey, ekip üyelerinin ne kadar yetenekli olduklarına değil, birlikte ne kadar iyi çalışabildiklerine, birlikte çalıştıkları sahiplik duygusuna ve nihayetinde nasıl çalıştıklarına bağlıdır. Projenin hedefi ile yakından bağlantılıdırlar – süreç oluşumuyla değil, kültürle gelen bir şey.

2. Yalnızca SMART Projeleri Başarılı Olur

Bir proje, ofis bir yana, aynı ülkede bile olmayan bir ekip tarafından tamamlanması gerektiğinde, proje için belirlediğiniz hedeflerin SMART - Spesifik, Ölçülebilir, Ulaşılabilir, Gerçekçi ve Zamana uygun olması çok önemlidir. -çerçeveli, konsepte t.

3. Çevrimiçi İşbirliği Araçlarına Alternatif Yok

Size maliyeti ne olursa olsun, gerçek zamanlı ve minimumdan sıfıra kadar gecikmeye sahip çevrimiçi işbirliği araçlarına güvenmek zorunda kalacaksınız. Online proje yönetimi ve iletişim platformlarının sonuçlandırılması açısından da hiçbir şekilde gevşeklik yapamazsınız. Teknik olarak gereksinimlerinizi karşılayabilecek kapasitede olduklarından emin olmanız gerekir.

Dağıtılmış bir ekip olarak kapsamlı çalışma deneyimimizden edindiğimiz bilgileri gördükten sonra, süreç sırasında karşılaştığımız bazı zorluklara ve bunları güvenilir bir Dağıtılmış Çevik Uygulama olmak için nasıl çözdüğümüze bakmanın zamanı geldi. Geliştirme Şirketi .

Dağıtılmış Çevik Geliştirme Yaklaşımıyla İlgili Zorluklar ve Bunları Nasıl Çözüyoruz

1. Kültür Farkı

Genellikle dağıtılmış çevik yazılım geliştirme yaklaşımı, farklı kültürel geçmişlerden gelen ekiplerle çalışmayı gerektirir. Bu farklılık, farklı değerler ve konuşma şekli nedeniyle sürtünmeye neden olur.
Çözümümüz: İlk birkaç gün müşterinin ekibiyle çok yakın çalışıyoruz, böylece onların satır aralarına ve bağlamlarına alışıyoruz.

2. Saat Dilimlerinde Bir Fark

Dağıtılmış çevik metodolojinin püf noktası, farklı coğrafi uluslardan çalışan ekiplerdir. Böyle bir durumda zaman farkından dolayı iletişim kopukluğu oluşması çok sık rastlanan bir durumdur.
Çözümümüz: Dağıtılmış bir ekip için çevik kavramını özüne kadar takip ediyoruz. Tüm uluslardan ekiplerin hazır ve aktif olduğu bir zamanı düzeltiriz. Tam odaklanma ve dikkati elde etmek için ekip arkadaşlarımızdan iyi uykular ve dikkatli olmaları için scrum gününde ofis saatlerini değiştirmelerini istiyoruz.

3. Ortak Bir 'Büyük Resim' Fikrinin Eksikliği

Coğrafi konum, çalışma yapısı ve politikalardaki farklılık nedeniyle, mobil uygulamanın nihai amacı olan Büyük Resim fikrinde bir tutarsızlık olabilir. Bu farklılık, bazı ekip üyelerinin ilgisiz kalmasına ve diğerlerinin daha yüksek bir ilgi göstermesine neden olabilir.
Çözümümüz: Proje başlangıcında bir vizyon oluşturma toplantısı ve her saldırıda bir hatırlatma, böylece herkes aynı amaç için çalışıyor.

4. Kod Sahipliğinin Yokluğu

Kolektif kod sahipliğinin olmaması, hiç kimsenin kodun sahibi olmadığı, kodun tüm takıma ait olduğu ve böylece bir şeyler ters gittiğinde suçlama oyunu başladığı anlamına gelir.
Çözümümüz: Bir kod üzerinde kimin çalıştığını, ne zaman ve etkisini kontrol etmek için bir sürüm kontrol sistemi uyguluyoruz. Bu şekilde, resimde tam bir şeffaflık ve dürüstlük var.

İşte bu, Appinventiv'de nasıl dünyanın her yerine ait dağıtılmış bir müşteri ekibi haline geldiğimizin hikayesidir.
Dağıtılmış çevik yazılım geliştirme seviyenizi nasıl yükselteceğinizi tartışmak ister misiniz? Mobil uygulama stratejistlerimizle iletişime geçin.