“İşlevler arası takım” aslında nedir? [kapalı]

"Çapraz fonksiyonel ekip" in genel anlamı, hedefe ulaşmak için gereken farklı alanlarda uzmanları bir araya getiren bir ekiptir.

Ancak Agile çapraz işlevselliğinde sadece farklı uzmanları birleştirmek değil, aynı zamanda onları karıştırmak anlamına da geliyor. Henrik Kniberg , çapraz fonksiyonel ekibi şu şekilde tanımlar : "Çapraz fonksiyonel, ekibin bir bütün olarak ürünü oluşturmak için gereken tüm becerilere sahip olduğu ve her ekip üyesinin kendi işlerinden daha fazlasını yapmaya istekli olduğu anlamına gelir."

Ama çizgi nerede çizilir? Gerekirse geliştiricilerden bir yineleme için testçi olmalarını istemek normal midir?

Benim görevim, çok işlevli bir ekibin, bir şirketin farklı işlevlerinden insanları içeren bir ekip olmasıdır: mühendislik, BT, teknik yazı, pazarlama, finans, hukuk, satış, İK, operasyonlar, kalite ve yönetici.

Daha büyük şirketlerde, bu "işlevler" silolara (yönetim hatları) konur, ancak işleri yapmak için genellikle hepsinden birinin zamanına ihtiyacınız vardır.

TDD veya benzeri bir şey yapıyorsanız, evet, tamamen normaldir.

Ancak, genel olarak geliştirici çalışmalarına son verme sorumluluğu aynı geliştiricilerin elinde olmamalıdır.

Çapraz fonksiyonel ekip, farklı alanlardan fonksiyonel uzmanların bir araya gelerek neyin inşa edileceğini tanımlamak ve neyin inşa edilip edilmediğini değerlendirmek için bir araya geldiği ekiptir . Çevik bir ortamda, bu değerlendirmeler sık ​​sık yapılacaktır.

Ancak, alan uzmanları bir projenin belirli bir bölümünün nasıl yapılacağını belirleyecektir . Yazılım geliştiricileri yazılım geliştirecektir. Test kullanıcıları test edecek. Operasyon insanlar yazılımı çalıştıracak vb.

Geliştirme, test ve operasyonların görüşlerine sahip olmak, iyi bir ürünün tanımlanmasında son derece yararlıdır ve burası çapraz fonksiyonel ekiplerin değerinin yattığı yerdir.

İyi bir çapraz fonksiyonel ekip, 'tüm esnafların krikosu' olan insanlara ve aynı zamanda bazılarının ustasına ihtiyaç duyar . Genellikle bir veya iki.

Örneğin, üzerinde çalıştığım kişilerde. C ++ ve birkaç web dilinde uzmanım, ancak bir milyonu biliyorum. Video düzenleme ve 3D medya ve bu tür şeylerin yanı sıra iş ve proje yönetimi konusunda akıcıyım. Büyük projeler üstlenen bu oldukça küçük ekipte, günün çoğunu biraz kodlama yapardım ve bir kısmını sitede grunt çalışması yaparak ve farklı medyaları hazırlayarak geçiririm.

Pek çok proje tüm becerilerimi kullanmıyor, ancak çoğuna güvenmek için bence bu 'çapraz işlevsellik'. Bazı zamanlar gerçekten iyi, verimli bir tasarım, bazen de çok fazla değil.

Bir geliştirici / ağ yöneticisi olmak zorunda olmadığım için şükürler olsun .. bu hiç eğlenceli değil. Bölgemdeki bu küçük işletme ... deli. Ağlarına programcılara güvenen şeyh. İstediğiniz son şey, yönlendirme tablonuzda 'hata ayıklamaya' çalışmamı görmek: P

Aklıma "çapraz fonksiyonel bir ekip" daha çok işi yapmak için bir araya gelen bir grup genelciden ibaret. Bazı insanların sadece bazı görevleri üstlenebileceği bir grup uzmanda meydana gelebilecek bir darboğaz olmadığı için, farklı görev türlerini ele alma çok yönlülüğü.

Evet, bir yineleme için işin yapılması gerekiyorsa geliştiricilerin test uzmanı olması normaldir.

Çapraz fonksiyonel, şirkete bağlı olarak çeşitli anlamlara sahip olabilen bir terim olan bölgeye düşebilir. Bazıları, bir geliştiricinin bir gopher'dan geçici bir CEO'ya kadar herhangi bir şey olabileceği en üst düzey olabilir ve diğerleri, kullanılan farklı geliştiriciler olması için onu daha özel görebilir. Bir geliştiricinin bir zamanlar iş analisti, sistem yöneticisi veya test kullanıcısı olması gerekebilir. Birkaç yıl önce bir işe ve başka bir geliştiriciye yeni başladığımı hatırlıyorum ve bir sürümü ilk görevlerimizden biri olarak test ediyordum, çünkü o zaman sürümü doğru bir şekilde test etmek için test uzmanı sıkıntısı vardı.

Çapraz fonksiyonel bir ekip sadece uzmanlık alanlarıyla değil, aynı zamanda işlerin yapılmasına yönelik tavırla da ilgilidir. Üyeler ayağa kalkıp eldeki görevleri üstlenirler. "Bu benim işim değil".

Proje üzerindeki kısıtlamalar her zaman teknik değildir. Bazen her işte bir uzman işe alma lüksünüz olmaz ve sadece herkesin tercih ettiği alanda çalışmasını istersiniz.

Geliştiricileri asla kodlamadan çıkarmak istemezsiniz, ancak bazı takımlarda yardımcı olamaz. Normal görecelidir.