Scrum'da 'dış' bağımlılıklar nasıl ele alınır?

Bir sprint için birkaç kullanıcı hikayesi planladıysanız ve bir aday hikaye, ekibinize bir şeyler gönderen bazı harici sağlayıcılara bağımlıysa. Örneğin, sistemlerine yeni bir API çağrısı ekleyen veya sistemlerinde test hesabınızı etkinleştiren bir çevrimiçi hizmet sağlayıcısı vb.

'Yakında' olacağını biliyorsun.

Hikayenizi tamamlamanız için zamanında gerekenleri teslim etmelerini umarak hikayeyi sprint'e ekliyor musunuz veya hazır olacağını bildiğiniz zaman bir sonraki sprint'e kadar bekler misiniz? hikayeye olabildiğince erken başlamamak anlamına gelir.

Birincisi bağımlılık nedeniyle kaybedilen 'kazanılmamış' hikaye noktalarını nasıl ele alırsınız? kısmi kredi (eek!) veya çenesine alın.

Sonuçta, harici sağlayıcının, kullanmanız gereken zamanda kullanabileceğiniz bir şey teslim edeceğinden% 100 emin olup olmadığınıza bağlıdır.

Zamanında teslim edileceğinden emin değilseniz, hikayeyi sprint'e eklemeyin. Ancak, her zaman geçmişte teslim ettikleri için bu sefer teslim edeceklerine dair bir garanti yoktur.

Müşteriye bu bağımlılığın var olduğunu ve çalışmayı zamanlayabilmeniz için API'nın (veya herhangi bir şeyin) kullanılabilir olmasını beklemek zorunda kalacağınızı bilmelisiniz.

Artı tarafta, hikayenin sunabileceğiniz yönleri olabilir - yani bağımlılıkları olabildiğince izole edene kadar daha fazla parçalayın. Bu, tedarikçi çalışmalarını teslim etmeden önce hikayenin bir kısmını yapmanıza izin verebilir.

Yapabileceğiniz şeylerden biri, kodunuz ile üçüncü taraf API arasında bir arayüz oluşturmaktır. Arayüzünüzü kodlayın, böylece projenin geri kalanı devam edebilir ve gerçek API alana kadar örnek verileri döndürmek için bir sahte kullanın. Sonra gerçek API geldiğinde, uygulamanın geri kalanını etkilemeyecek arayüzün arkasındaki kodu değiştirmeniz yeterlidir. Bunu yalnızca API'nın tedarikçisiyle arayüzlerinin değişmeyeceğine (en azından büyük ölçüde değil) katılabilirseniz yapın.

Taahhüdü yapan takımdır. Ekibimizde, harici bir geliştiriciyi beklediğimizi hissedersek (örneğin) hikayeyi almaya istekli olmadığımızı söylemeyi öğrendik. Hikaye almak için uygun bir durumda değil.

Harici kaynaktan geç, beklenmedik veya farklı teslimatın tahminlerinizin ve önceliklerinizin değişebileceği anlamına gelmesi çok iyi bir şans.

Tüm bilgilere sahip olana kadar, takım hikayeyi tamamlayabileceklerini düşünmek için çok saf olmamalıdır. Eğer yapabildiklerini söylerse, geç gelir, beklenen bir formatta gelir ya da hiç gelmezse, herkesi hayal kırıklığına uğrattılar.

Kulağa sert geliyor ama benim fikrimi söylemek istiyorum.

Scrum'da tamamın bir tanımı ve kullanıcı öykülerine hazır bir tanım vardır. Sizinki gibi bir durumda, tüm paydaşların anladığı ve kabul ettiği hazır bir tanım olması önemlidir. Örneğin, hazır tanımınızda bir satır olması çok makul görünüyor:

• Hikaye için gerekli olan tüm harici API'ler teslim edilmeli ve test edilmelidir.

Ürününüze değer katmak için bu API'ya ihtiyacınız varsa, çalışmamızı başlatmak için bu API'ye sahip olana kadar beklemesini mantıklı olan şey. Bu arada ürüne değer katan diğer ABD'leri yapabiliriz, bu ABD'yi sahte uygulamalar ve benzeri ile gerçekten sevmiyorum, müşteri için gerçek bir değer yoksa ABD yoksa, zaman ve kaynak kaybı .

Henüz bilmediğiniz bir şeyi bekliyorsanız yarın teslim edileceğinden% 100 emin olsanız bile planlayamazsınız. Neden? Çünkü bilmiyorsanız, karmaşıklığını bile tahmin edemezsiniz ve tahmin edemezseniz planlayamazsınız.

Dış şirket tarafından izlenmesi gereken bazı "arayüz" / "sözleşme" tanımladıysanız, bunu planlayabilir ve yanınızda servis alaycı oluşturabilirsiniz. Gelişiminiz, dışarıdan teslim edilmesine bağlı olmayacak şekilde sahte hizmeti kullanacaktır. Sahte olarak geliştirilen ve test edilen özellik tamamlanmadığından gerçek hizmetin sunulacağı sprint için hala geliştirme planlanmalıdır - sprint sonunda tamamlandığı düşünülen gerçek servis ile test edilmelidir.

İletişim ve Anlaşmalar

İki sistem metodolojinin kendisi tarafından değil, programcılar tarafından entegre edilmiştir. Bir şirket harici bir sistemi entegre etmeye karar verdiyse, (minimum) 2 işletme arasında bir sözleşme yapılacaktır. Sözleşme entegrasyonun gerçekleşmesini sağlamalıdır . Sonuç olarak, şirketler arasındaki anlaşma, her iki departman arasında teknik bir işbirliği gerektirmiyorsa, sorun kalkınma metodolojisi değildir. Sorun iş metodolojisidir (temel olarak sözleşme) .

Bunu söyledikten sonra, bu vakaların planlanması sırasında bir risk olarak görülmeli ve ekibin hızını bilmediğiniz göz önüne alındığında , bu marjlarla cömert olmanız gerekecektir.

Proje Yöneticisi harici bir ekibe bağımlılığı nasıl yönetebilir?

/pm/1400/how-can-a-project-manager-manage-a-dependency-on-an-external-team

Ekibinize bağlı değilse ve başka görevler yapabiliyorsanız, sadece hazır olduğunuzda almanızı tavsiye ederim. Bir mockup web servisiniz, şemanız, arayüzünüz ve / veya sözleşmeniz olsa bile yine de bölünebilir (Murphy Kanununu hatırlıyor musunuz?).