, bir süredir öğrendiğim en ilginç organizasyonel uygulamadır. Bugün FAST Agile'ın ne olduğunu paylaşıyorum ve denemeye değer olup olmadığını araştırıyorum. TL;DR? Oldukça ilgi çekici ama yine de deneysel. FAST çevik FAST Agile nedir? çevik bir yazılım çeşididir. FAST, çok büyük ekipler içinde kendi kendini organize etmeye odaklanır. Bu büyük takımlara Kolektif denir. Birkaç kişiden 150 kişiye kadar olabilirler [1]. FAST Agile, Kolektif haftada iki kez toplanır. Toplantıda: . Ekip üyeleri ne kadar ilerleme kaydettiklerini gösterir ve anlatır . En iyi projelerle ilgili bağlam sağlarlar. İş tamamlandıkça veya öncelikler değiştikçe yeni öncelikler ortaya koyarlar. Ve genellikle öncelikleri görsel bir şekilde, bir duvarda veya sanal bir eşdeğerde gösterirler. Ürün lideri vizyonu yineler ve yönü belirler ve daha küçük ekiplere ayrılır. Kolektif içindeki kişiler, en öncelikli işi teslim etmek için kendi kendini organize eder FAST agile'ın en ilginç kısmı bu kendi kendini organize eden ekiplerdir, o yüzden onları biraz daha ayrıntılı olarak açıklayalım. Her toplantıda insanlar ekiplere liderlik etmek için gönüllü olur ve insanlar da bu ekiplere katılmak için gönüllü olur. Birisi bir ekibi yönetmeye gönüllü olduğunda öne çıkıp şöyle der: "[En iyi projelerden biri] üzerinde çalışacağım". İnsanlar daha sonra oluşturulan ekiplere katılarak o alanda çalışırlar. Minimum takım büyüklüğü ikidir, bu nedenle ekibi oluşturmak için insanların "ayaklarıyla oy vermeleri" gerekir. Oluşturulan ekipler ürünün ortaya koyduğu öncelikler etrafında olmalıdır. Örneğin, dağıtım hattının iyileştirilmesi veya bazı kesintili hizmetlerin izlenmesinin iyileştirilmesi etrafında bir ekip oluşturulabilir. Olumsuz Haftada bir saat toplantı dışında insanlar zamanlarının çoğunu kendi seçtikleri, kendi organize ettikleri ekiplerde geçiriyorlar. Teorik olarak haftada iki kez takım değiştirebilirsiniz. Ancak pratikte insanlar kiminle çalışmaktan hoşlandıklarını buluyorlar ve ekipler başlıyor. ilk aydan sonra yerleşmeye İnsanların iş ihtiyaçları değiştikçe veya farklı alanlarda uzmanlığa ihtiyaç duyulduğunda hareket edebilecekleri kadar akışkan kalırlar. Ekiplerin taşınması beklenen ve az çaba gerektiren bir değişikliktir. Yani bu, Kolektif toplantılar sırasında, insanların kendi takımlarını yeniden oluşturduğu bir kalıp olduğu, ancak kompozisyonun hayal edebileceğiniz kadar değişmediği anlamına geliyor. Hataların ve çağrının nasıl ele alındığı gibi birçok başka ayrıntı var. Bu konuların bir kısmını daha sonra ele alacağım. Ancak FAST Agile'ın temel özü, projeler üzerinde daha büyük bir Kolektif içinde çalışan, kendi kendini seçen ekiplerdir. Toplu toplantılar yapılandırılmıştır ve işin ihtiyaçları hakkında bağlam sağlamaya ve bu önceliklere göre ilerlemeyi aktarmaya odaklanmıştır. Farklılıkların özeti FAST, günümüzde çoğu çevik yazılım kuruluşunun çalışma biçiminden çok farklıdır. Benim gördüğüm farklar şöyle: (SCRUM, Kanban veya "Hafif Çevik") Yaygın uygulama HIZLI Çevik Toplantı yoğunluğu Orta ila Yüksek Şirketten şirkete değişir, ancak genellikle günlük toplantılar, demolar, hazırlıklar, tahminler, retrolar vb.). Düşük Haftada iki yarım saatlik toplantılar. Diğerleri isteğe göre. Ölçeklendirme yeteneği Ölçeklendirme birimi ekiptir. Ekipleri (ve sorumluluk alanlarını) büyütmek, bölmek ve oluşturmak, yönetimin ana odak noktasıdır. İş öncelikleri değiştikçe önceliklerdeki değişimi yansıtacak şekilde yeniden yapılanma gerektirir. Ölçeklendirme birimi Kolektiftir. Pratik olarak konuşursak, iş yollarının sayısı yaygın uygulamaya benzer şekilde ölçeklenecektir. Ancak insanları eklemek ve iş akışlarını değiştirmek daha akıcı ve kendi kendini organize eden bir yöntemdir. "Çok küçük" veya "çok büyük" ekiplerle daha az zorluk yaşanır. Ekiplerin sürdürülebilirliği ve ekiplerin sorumluluk alanlarıyla eşleştirilmesi konusunda daha az endişe. Çok büyük şirketlerde test edilmemiştir ancak teorik olarak sağlam görünmektedir. Kod sahipliği ve uzmanlık uyumu Dünyayı bireylerin uzmanlaşabilecekleri bölümlere ayırmaya yardımcı olan katı kod sahipliği. İnsanlar kendi alanlarında çalıştıkları için teşviklerin iyi uyumlaştırılması. Zorluklar, her ekibin kendi kod tabanını koruyabilmesini ve çalıştırabilmesini sağlamaktır. Sorumlulukların taşınması acı verici olma eğilimindedir. İş önceliklerinin değiştirilmesi sıklıkla yeniden yapılanmalarla sonuçlanır. Uygulamalar merkezi olmayan ve parçalı olabilir, ancak bu durum zorluklara neden olabilir. Örneğin ekiplerin kendi programlama dillerini seçmelerine, farklı çalışma yöntemleri ve farklı kodlama stilleri seçmelerine izin verebilirsiniz. Paylaşılan kod sahipliği. İyi standartlar, yetenekli ekip veya iyi inceleme uygulamaları gerektirir. Öncelikleri değiştirmek daha az zordur. Kolektif sınırları değiştirmediğiniz sürece yeniden yapılanmalar neredeyse yok denecek kadar azdır. (Yeniden yapılanmalarda yönetime ne kadar zaman harcandığını bir düşünün!) Uygulamaların daha standart hale getirilmesi gerekiyor, yoksa sorun yaşarsınız. Uygulamaları standartlaştırmak iyi bir şeydir, dolayısıyla teşvikler doğru yerdedir, ancak başarısızlık modu muhtemelen daha kötüdür. Mimari desenler İdeal mimari mikro hizmetlerdir. Büyük monolitlerin iyi hesaba katılması gerekir. Genellikle mikro hizmet ortamlarının dışında dağınıktır. FAST'ın mimari konusunda daha agnostik olmasını beklerdim. Monolitik kod tabanları veya mikro hizmet ortamlarıyla çalışmalıdır. Ve bir karışımla. Mikro hizmet ortamlarına geçişi daha kademeli hale getirmeliyiz. Kullanıma sunma modelleri Sıkı kod sahipliği, hangi ekibin neye sahip olduğuna ilişkin kuruluş çapında bir tasarım gerektirir. Bu değişikliklerin uygulanması her zaman büyük bir başarıdır. Yıkıcı, büyük yeniden yapılanmalar gerektirir. Kademeli olarak yapılabilir. Bir veya iki ekiple başlayabilir ve işe yararsa yavaş yavaş ek ekipler ekleyebilirsiniz. Yeniden yapılanmalar seyrek olmalıdır. Kollektif düzeyde hâlâ gerçekleşecek, ancak bunun daha az sıklıkta olması gerekiyor. Hizalama mekanizmaları İnsanları uyumlu hale getirmek için genellikle OKR'leri, herkesin katıldığı toplantıları ve yazılı iletişimi kullanın. Toplu toplantılar, haftada iki kez, hedefleri güçlendirdiğiniz ve ekip için bağlamı belirlediğiniz yerleşik bir Tüm Eller toplantısıdır. Eğer liderlik bu toplantıyı ciddiye alırsa, bu çok yüksek bir avantaj gibi görünüyor. İşçi tutma Uygulamalar eziyet ve yukarıdan aşağıya yüksek kontrol ortamlarından, ve işlerine sürekli olarak değer katan yüksek performanslı ekiplere kadar değişebilir. Bu nedenle, elde tutma miktarı şirkete göre önemli ölçüde değişecektir. , özellik fabrikasında iş bağlamlarını ve müşterilerini anlayan Yaygın çevik uygulamalara benzer şekilde uygulamaların değişebileceğini düşünüyorum. Ancak FAST, uyumlu olduğundan çalışanların elde tutulmasına uygundur. Çalışanlar kiminle çalışacaklarını, ne üzerinde çalışacaklarını seçebilir ve yaptıkları işin önemli olduğu konusunda destek alabilirler. Bunun daha iyi bir genel memnuniyetle sonuçlanmasını beklerdim. Zorluklardan biri politika olabilir. Kendi kendini yöneten gruplar bazen çatışmalarla yeterince iyi başa çıkamıyor, bu da geri tepebiliyor. içsel motivasyonla Gördüğünüz gibi FAST, günümüzde çoğu şirketin yaptığından çok farklı bir yaklaşım. Peki takaslar nelerdir? Gördüğüm kadarıyla bunlar FAST Agile'ın ödünleşimleri: FAST daha iyi organizasyonel ölçeklenebilirlik sunabilir FAST artımlı olarak denenebilir FAST daha az yeniden düzenlemeyle sonuçlanacaktır FAST, değişen önceliklere yanıt vermeyi kolaylaştırır FAST, içsel motivasyon ve elde tutma açısından daha iyi olabilir Ancak… Birçok ortam FAST ile uyumlu değildir Öz yönetimi yönetmeniz gerekebilir HIZLI çok çalışma gerektirir FAST materyalleri jargonla doludur Bunların her birini sırasıyla tartışacağız. FAST daha iyi organizasyonel ölçeklenebilirlik sunabilir Kuruluşları ölçeklendirdiğinizde bunu genellikle onları "yatay olarak" ölçeklendirerek yaparsınız. Organizasyonu birer birer ekip olarak büyütürsünüz. Bu ekiplerin her biri ürünün bir dilimine sahiptir ve çoğu zaman ürün ekiplerini daha etkili hale getiren bir platform organizasyonuna sahip olursunuz. Kişi sayısı arttıkça organizasyonun karmaşıklığı da artar. Mühendislikte on kişiniz varsa hepsi birbiriyle iletişim kurabilir. Mühendislikteki yüz kişinin hepsi birbiriyle konuşamaz. Ve kod temeli hiçbir bireyin kafasına sığmaz. Yani bu karmaşıklığı ekiplere ayırırsınız ve her ekibin odaklanabileceği bir alan olur. FAST ilginçtir çünkü organizasyonları “dikey” olarak ölçeklendirme girişimidir. FAST, daha fazla takım eklemek yerine Kolektifler adı verilen oluşturmaya çalışır. Kolektifler hala koda sahiptir ancak Kolektif içindeki kendi kendini organize eden ekipler bu koda sahip değildir. Ve yine de iletişimi bölümlere ayırmanız gerekiyor. Ancak ekipler daha dinamik ve sürekli gelişiyor. Ekipleri yeniden yapılanma yoluyla yeniden şekillendirmek yerine, çalışma şeklinizin sürekli ve beklenen bir parçasıdır. daha büyük takımlar Ekip büyüklüğü birçok mühendislik başkanı için tanıdık bir konudur. Ekipler ne kadar büyük olmalı? FAST iddialarının nasıl daha iyi ölçeklendiğini anlamamıza yardımcı olması için bu konuyu biraz daha derinlemesine inceleyelim. Ekipler ne kadar büyük olmalı? Mühendislikten Sorumlu Başkan Yardımcısı'nın yanında zaman geçirdiğinizde, ara sıra mühendislik ekibinin büyüklüğü konusu gündeme gelecektir. Küçük takımlar için argümanlar ve büyük takımlar için argümanlar duyacaksınız. Her iki tarafın da haklı yönleri var. Küçük ekiplerin avantajları Ekip içinde daha az koordinasyon ve iletişim yükü. Sonuç olarak hızlı hareket edebilir. Daha az iş akışı, odaklanmanın ve sonuç üretmenin daha kolay olmasını sağlar. Yönetilmesi daha kolay. Büyük ekiplerin avantajları Daha düz organizasyon. 150 mühendisin yer aldığı bir mühendislik organizasyonunda 3-4 yönetici ve 10 kişilik ekipler bulunacaktır. Beş kişilik ekiplerle 6-8 direktör ve 1-2 Başkan Yardımcısı olacak. Bir organizasyondaki karışıklık nereden geliyor? Muhtemelen liderlik, yani büyük ekipler kafa karışıklığını azaltabilir. Daha fazla dayanıklılık. Birisi tatile çıkabilir ve ekip gayet iyi bir şekilde yoluna devam edebilir. Yani küçük ekipler kendi ekipleri içinde harikadır, ancak daha az idealdir çünkü onlardan çok sayıda vardır ve bu da organizasyonel karmaşıklığı artırır. Daha büyük ekipler genel organizasyonel karmaşıklık açısından daha iyidir, ancak her ekibin içindeki performans açısından daha az idealdir. Birçok liderin benimsediği yaklaşım, daha az iş akışına odaklanan büyük ekipler oluşturmaktır. Bu, dahili ekibin karmaşıklığını azaltır ve aynı zamanda organizasyonel karmaşıklığı da azaltır. FAST'ı, gülünç derecede büyük ekipler aracılığıyla daha da büyük organizasyonel basitliğe ulaşmaya çalışan bir yaklaşım olarak görebilirsiniz. Kendi kendine toplanan küçük ekiplere sahip olmanın avantajlarından da yararlanmaya çalıştı. Organizasyonları ölçeklendirmek zorlu bir iştir Danışmanlık işimin büyük bir kısmı kuruluşların ölçekle başa çıkmasına yardımcı oluyor. Organizasyonların karşılaştığı ölçeklendirme zorluklarının çeşitli aşamaları vardır. İlk bariyer tipik olarak 15-25 mühendis işaretindedir. Bu, amipinizin çok büyüdüğü ve bölünmesi gerektiği zamandır. Bu tür sorunları görüyorsunuz: İletişim kanalları etkisiz hale gelir. Mühendislik, teslimat ve/veya kalite sorunları yaşamaya başlar. Yöneticiler veya liderler bunalmış hissediyorlar. Daha fazla insan eklemek durumu iyileştirmek yerine daha da kötüleştirecektir. Ve ikinci bir engel de altmış mühendis civarında. Bu noktada çok daha fazla sorunu görmeye başlarsınız: koordinasyon Ekipler arası projeler nadiren başarılı olur. Ürün çalışması platform ekiplerini batırır veya tam tersi. Büyük girişimleri tamamlayamama. Zeki insanların organizasyonel karmaşıklıktaki bu adım adım değişiklikleri yönlendirmede defalarca başarısız olduklarını gördüm. Benim önsezim, karmaşıklıktaki bu adım sırası artışlarının, ek bir yönetim katmanı eklediğinizde karşılık geldiği yönündedir. Büyüyen mühendislik organizasyonları gerçek bir beceridir. Organizasyonların ve insanların nasıl çalıştığına dair derinlemesine bir anlayış gerektirir. Şunun gibi şeyler öğrenirsiniz: İnsan gruplarının birlikte çalışmasını sağlayacak . koordinasyon modelleri ile işlevsel olarak tasarlanmış ekipler. Akış uyumlu ekipler İş öncelikleri değiştikçe insanları değiştireceğiniz ve kod yazacağınız yeniden düzenlemelerin nasıl yapılacağı. Ürünlerin, ürün yatırımıyla örtüşen teknik sorumluluk alanlarına nasıl bölüneceği. Ekipler etrafında iletişim kanallarının kurulması. Ürününüzü etkili bir şekilde desteklemek için çağrı ve güvenilirlik programlarının kurulması. Karmaşıklıkla mücadele etmek için platform organizasyonları ve geliştirici deneyimi girişimleri kurmak. Vesaire. Bu uzmanlığa sahip kişileriniz olsa bile, yönetim ekibinizin ölçeklendirmeyle baş etmesi çok fazla çaba gerektirir. Dolayısıyla, FAST daha iyi ölçeklenebilirse, yönetim ekibinizin başka bir şeye odaklanma potansiyelinin büyük bir kısmını açığa çıkaracaksınız. Ayrıca, adım sırası değişiklikleriniz çok daha az sıklıkta gerçekleştiğinden, kuruluşunuzun yönetimini çok daha kolay hale getirme potansiyeline sahip olabilirsiniz. FAST çevikliği etrafında bir düşünce deneyi Ekip boyutunu hayal edin. Beş ya da on kişiden oluşan ekipler yerine, etkili yirmi kişilik ekipleriniz olsa nasıl olurdu? Yoksa altmış kişilik ekipler mi? ölçeklendirebileceğinizi Görünüşte bu gülünç bir teklif. Bu kadar büyük takımlar etkili olmuyor. On iki kişilik ekipler bile zorlayıcıdır. Bazen yirmi veya otuz kişiye rapor veren kişilerin özgeçmişlerini görüyorum. İlk tepkim onların berbat bir şirkette çalıştıklarını düşünmek oldu. Bu kadar çok sayıda doğrudan rapora sahip olmak “organizasyonel bir koku”dur. FAST Agile'ın temel önermesi, bu daha büyük Kolektif içerisine kendi kendini organize etmeyi ve kendi kendini seçen ekipleri eklerseniz, ekiplerinizi daha ölçeklendirebilmenizdir. Her takım (FAST onları Kolektif olarak adlandırır) çok daha büyük olabilir. Ve daha sonra insanların her gün birlikte çalıştığı ekipler bu Kolektifler içerisinde kendiliğinden bir araya gelir. yatay olarak Eğer daha büyük Kolektifler etkili olsaydı, organizasyonel karmaşıklığı önemli ölçüde azaltırlardı. Tipik bir yazılım başlangıcı, sorumluluk alanlarına bölünmek zorunda kalmadan yıllar sürebilir. Kod tabanının her ekibin sahip olduğu alanlara titizlikle bölünmesine gerek yoktur. Bu, yöneticilerin ürüne ve ekiplere odaklanmak için kullanabileceği yönetim süresinden önemli ölçüde tasarruf sağlayacaktır. Yani test etmemiz gereken temel şey şu: Kendi kendine toplanma ve kendi kendini organize etme, daha küçük, tasarlanmış ekipler kadar etkili bir çalışma yolu sunuyor mu? Eğer öyleyse, organizasyonları ölçeklendirmede potansiyel olarak çok daha iyi olan organizasyonları ölçeklendirmenin bir yolunu sunacaktır. Neden bu kadar? Altı kişilik ekiplerle büyüyen bir organizasyonu, altmış kişilik "ekipler/Kolektifler" ile ölçeklenen bir organizasyonla karşılaştıralım. Bu argümanın içine yerleştirilmiş pek çok varsayım var ve siz de bu varsayımda bazı boşluklar açabilirsiniz. Ancak bunu yapsanız bile FAST, esasen daha büyük bir organizasyon biriminin ürün ve kod tabanı alanına sahip olmasına izin verir. FAST yeni olduğundan şu anda FAST ekiplerinin geleneksel çevik ekipler kadar etkili çalışıp çalışmadığına dair çok fazla kanıt yok. Ama bu sorunun cevabının evet olduğundan şüpheleniyorum. Buna inanmak için birkaç nedenim var. Her şeyden önce Jim Shore'un bu konudaki ilk deneyimi oldukça olumluydu ve kendisi güvendiğim biri. FAST konusunda iyimser olmamın ikinci nedeni, kendi kendini organize eden büyük insan gruplarıyla bazı deneyimlerim olması. Ve ne kadar iyi çalıştığına şaşırdım. Küçük şirketlerde elbette çok fazla kendi kendine örgütlenme görürsünüz. Ancak şirketler büyüdükçe her şeyi standartlaştırıyorsunuz ve ekipler dışında kendi kendini organize etmeyi ortadan kaldırıyorsunuz. Ancak parçası olduğum en ilginç deneylerden biri New Relic'teki büyük ölçekli bir öz-örgütlenme etkinliğiydi. Tüm ekiplerimizi yeniden tasarladık ve elli yazılım ekibindeki herkesten hangi ekibin parçası olmak istediklerini seçmelerini istedik. Her takımın ihtiyaç duyduğu beceriler konusunda kısıtlamalarımız vardı ve herkesin sahip olması gereken becerileri tanımlamıştık. Herkesin, hatta biz organizatörlerin bile beklediğinden çok daha başarılı oldu. Her ne kadar jüri bu konuda görüş belirtmese de benim önsezim bu uygulamanın doğru bağlamlarda çok fazla potansiyele sahip olduğu yönünde. FAST artımlı olarak denenebilir FAST materyallerinde bundan bahsedilmiyor, ancak FAST ile ilgili ilginç olarak dikkatimi çeken şey, onu aşamalı olarak deneyebilmenizdir. FAST Agile'ı bir deneme olarak bir takıma uygulayabilir ve ardından zamanla ek takımları yutacağınız bir blob yaklaşımını kullanabilirsiniz. Eğer işler yolunda giderse ilave takımları yutmaya devam edin. Olmazsa deneyi iptal edin. FAST daha az yeniden düzenlemeyle sonuçlanacaktır Değişim organizasyonlarda olur. Öncelikler değişiyor, insanlar ayrılıyor, ürünün alanları beklenmedik bir şekilde büyüyor. Önceki teknik kararlar sizi ısırır ve ek iş yapmanız gerekir. Yatırım gerektiren yeni fırsatlar ortaya çıkıyor. Bütün bunların kuruluşunuzun yapısı üzerinde etkisi vardır. Her birinin kendi sahiplik alanları olan bir takım ekipleriniz var. Bu değişiklik meydana geldikçe, elinizden gelenin en iyisini yapmak için zaman içinde organizasyonunuzu yeniden düzenlersiniz. Bu yeniden düzenleme işlemleri "yeniden yapılanmalardır" ve büyüyen organizasyonlarda sıklıkla gerçekleşebilir! FAST ile yeniden düzenlemelerin çok daha az sıklıkta olması gerekir. Yeniden düzenleme birimi o kadar büyüktür ki, bunu o kadar sık yapmanıza gerek yoktur. Bunun potansiyel bir dezavantajı, tanımlanmış sorumluluk alanlarına sahip ekiplerinizin olmamasıdır. Dolayısıyla sorumluluğun dağılmasına ve kötü korunan ortak kodlara sahip olabilirsiniz. (Bu konuya biraz sonra değineceğiz) FAST, değişen önceliklere yanıt vermeyi kolaylaştırır Geleneksel olarak yapılandırılmış ekiplerde öncelikler değiştiğinde, işi yapacak ekipleriniz olur. Bu ekip yapısı yeni öncelikleri desteklemiyorsa organizasyonunuzu yeniden düzenlemeniz gerekir. FAST için öncelikteki değişiklikler daha akıcı ve süreklidir. Sorumluluklar Kolektifin içinde olduğu sürece ekipler kendilerini iş etrafında organize ederler ve bu sanki başka bir gün gibidir. Toplu toplantı yapısı aynı zamanda değişen öncelikleri daha az dramatik hale getiriyor. Esasen haftada iki kez yerleşik Tüm Eller'e sahipsiniz. Toplu toplantılarda sürekli olarak bağlamı paylaşabilir ve ekibinizi müşterileriniz ve pazar hakkında eğitebilirsiniz. Bu, ekibinizin daha iyi uyum içinde kalmasına yardımcı olacaktır. Bu yaklaşımı Üç Aylık OKR'ler gibi bir şeyle karşılaştırdığımda, daha akıcı görünüyor ve insanları hizalamada daha iyi bir iş çıkaracakmış gibi görünüyor. Ürün liderinin sürekli olarak bağlamı ve öncelikleri paylaşması için kararlı bir çaba göstermesi gerekir. Ancak parçası olduğum en iyi takımların bazılarında bu şekilde hareket eden bir ürün lideri vardı, bu yüzden bunun iyi harcanmış bir zaman olduğundan şüpheleniyorum. FAST, içsel motivasyon ve elde tutma açısından daha iyi olabilir Pek çok ekip, süreçlerinin insanları kontrol etmeye yönelik araçlar olarak tasarlandığını hissedebilir. Ve sanki bir montaj hattında çalışıyormuş gibi hissedebilirsiniz. FAST, kendi kendini organize etmeyi tasarımının temel bir bileşeni olarak benimser. Bu o kadar temel ki, kendi kendine örgütlenme olmadan işe yaramaz. Yönetim için tamamen farklı bir araç seti gerektirir ve çoğunlukla (tamamen olmasa da) yukarıdan aşağıya, hiyerarşik yaklaşımlarla uyumsuzdur. Daniel Pink, ünlü bir şekilde özetledi: içsel motivasyonun üç yönünü – Uyum yerine bağlılığı artıran, kendi kendini yönetme arzusu. Özerklik – Daha iyi becerilere sahip olma dürtüsü. Ustalık – Anlamı olan ve önemli olan bir şeyi yapma arzusu. Amaca değer vermeden yalnızca kâra odaklanan işletmeler, kötü müşteri hizmetleri ve mutsuz çalışanlarla sonuçlanacaktır. Amaç FAST ile işinizi kendi başınıza yönetebilir ve özerklik hissetmenize yardımcı olabilirsiniz. Becerilerinizi geliştiren, ustalık duygusuna ulaşan çalışmalara odaklanmayı seçebilirsiniz. Ayrıca, işinizin iş için önemli olan şeylerle nasıl bağlantılı olduğu size sürekli olarak hatırlatılır ve bu da bir amaç duygusu hissetmenize yardımcı olur. Bu nedenle garanti edilmese de, FAST uygulayan kuruluşların yüksek elde tutma oranları elde etme potansiyelini görüyorum. Kendi kendine örgütlenme aynı zamanda insanlardan oluşan bir topluluğun birlikte daha iyi çalışmasını sağlayacak bazı kullanışlı sinyaller de sağlar. "Pislik yöneticisi" tipindeki kişi, davranışlarının hoş karşılanmadığına dair bir sinyal alır. Nasıl? Bir ekibe liderlik etmek için öne çıkarlar ve yapmak istedikleri işi söylerler. Eğer ekibine kimse katılmazsa iş gerçekleşmez ve ekip oluşmaz (Takımlarda en az iki veya üç kişi bulunur veya oluşmaz). Kendi kendini organize etme aynı zamanda insanların, diğer şirketlerde dikkat çekmeyen, işin acı verici yönleriyle başa çıkmalarına da olanak tanır. Örneğin, test paketi berbatsa, birisi öne çıkıp bu sorunu çözen bir ekibe liderlik edebilir. Açıkça iş önceliği olmayan işleri yapmak son derece mantıklıdır. Ama bu ortada ve gerçekleşmesi için başkalarının da katılması gerekiyor. Bu, sanki bir gibi hissetmenizi önlemeye yardımcı olabilir. özellik fabrikasındaymışsınız Son olarak, her gün birlikte çalıştığınız kişileri seçebiliyorsunuz. Geçmişte kendi kendini organize eden ekipleri gördüğümde bu beklenmedik bir faydaydı: İnsanlar birlikte çalışmak istedikleri insanlarla çalışmayı seçtiler. Ve bu takımlar beklediğimden çok daha güçlüydü. Tüm bunların dengeleneceği şey, insanların FAST ile deneyimleyeceği yeni acılardır. Zorluklardan biri resmi olmayan güç dinamikleri veya potansiyel politikalarla ilgili olabilir. Birçok ortam FAST ile uyumlu değildir FAST çok yeni olduğundan uygulanması daha risklidir. HIZLI her durumda mantıklı olmayacaktır. Ve daha pek çok bilinmeyen var. Bunu deneysel bir yaklaşım olarak düşünmek en iyisidir. FAST'ı denemek için en uygun ortamlar hangileridir? Peki FAST'tan nerede kaçınmalısınız? Şirketinizin bu listedeki nitelikleri ne kadar fazlaysa, FAST'a o kadar uygun olur: Yönetim yeniliği ve denemelerine ilgi. Yüksek güven, düşük korku ortamları. Ya da en azından liderlikte komuta ve kontrolden kaçınma arzusu. Sürecin iyi bir rehberi veya kolaylaştırıcısı. Etkili bir Toplu toplantıyı yürütebilecek, süreci kurabilecek, değerlendirebilecek ve aktif olarak yönetebilecek biri. Örgütsel dinamikleri ve gruplar halindeki insanların birlikte nasıl çalıştığını anlayan biri. (Bunun için beni işe alabilirsin). Önceliklerde orta ila yüksek oranda değişim. Öncelikler değişmiyorsa HIZLI daha az kullanışlıdır. İşbirlikçi, kendi kendini yöneten, yüksek performanslı ve sürekli öğrenen bir ekip. Önceliklerini belirleyebilen bir liderlik ekibi. Her Toplu toplantıda öncelikler ve iş bağlamı hakkında konuşabilecek bir ürün lideriniz var. Ve etkili bir şekilde iletişim kurabilirler. Bu özellikler ne kadar az doğruysa, FAST'ta o kadar çok ters rüzgarla karşılaşırsınız. Bunun için mükemmel bir ortamda olmanıza gerek olduğunu düşünmüyorum. Bazı açılardan, bu şeyler olmayı istemenin aslında bu şeyler olmaktan daha önemli olduğunu düşünüyorum. Belki de en önemli başarı faktörü, liderliğin buna yer açma konusunda kararlı olmasıdır. Öz yönetimi yönetmeniz gerekebilir Kendi kendini organize eden sistemler etkili bir şekilde çalışabilir. Ama özgür değiller. Daha çok bir topluluğu yönetmeye benziyorlar. Doğru davranışı teşvik etmek için kısıtlamalar ve araçlar oluşturmanız gerekecektir. Ve işlerin yolunda gitmediğinden emin olmak için dikkatlice izlemeniz ve yönetmeniz gerekecek. Herhangi bir kuruluşun kötü aktörleri veya o topluluğun çıkarlarıyla uyumlu olmayan kişileri olabilir. Bir keresinde bir mühendisle konuştuğumu ve bana (şaka yapmıyorum) işverenleri için değer üretme zorunlulukları olmadığını düşündüklerini söylediğini hatırlıyorum. Bazı mühendisler, kendilerini çalıştıran şirket için iyi olan şeylerden ziyade, becerilerini geliştirecek veya onları daha değerli bir çalışan haline getirecek şeylere odaklanmak isteyebilir. FAST ile bir insan yönetmek için kayıt oluyorsunuz. topluluğunu Geleneksel durumlarda hiyerarşi bundan kimin sorumlu olduğunu açıkça ortaya koyar. FAST'ta çatışmayı önlemenin ve "üyelerin bunu çözmesine izin vermenin" kolay olacağından şüpheleniyorum. Bu, gayri resmi güç ağlarının bir tür hakim olmasına neden olabilir. Eğer FAST kullanıyorsanız, bu benim korunacağım bir şeydir. yapısızlık zulmüne Diğer uç nokta ise, grubun sorunları çözmesine izin vermemek ve yönetimin bu sorunu tamamen halletmesini sağlamaktır. Bu zararlı da olabilir. aynı zamanda Dolayısıyla FAST, iyi bir kolaylaştırma, dikkatli gözlem ve ara sıra müdahale gerektirecektir. HIZLI çok çalışma gerektirir FAST ile deneme yapmak istememenizin en büyük nedeni, FAST'ta çok fazla gizli işin bulunmasıdır. Alışılmadık bir çalışma şekline doğru, kuruluşunuzda çok fazla değişiklik yapılmasını gerektirir. FAST'ı yeni bir bilgisayar programlama dilinde çalışmaya benzetebilirsiniz. Yeni dil umut verici görünüyor çünkü o kadar çok yeni ergonomik özelliğe sahip ki, daha önce gördüğünüz her şeyden çok daha iyi görünüyor. Ancak bu yeni dilde yazılmış çerçeveleriniz ve kitaplıklarınız yok. Bu yüzden çoğunu kendiniz inşa etmeniz gerekecek. Yani FAST'ın en büyük dezavantajı köklü bir uygulama olmamasıdır. FAST'ın çalışma şekli ile geleneksel uygulamalar arasındaki uyumsuzluklarla başa çıkmak için birçok şeyi telafi etmeniz gerekecek. İşte bazı örnekler: Performans yönetimi nasıl çalışır? Geleneksel takımlarda, işi denetleyen ve bireylere koçluk yapan bir yöneticiniz vardır. Performans değerlendirmeleriniz var ve birisi uygun değilse yönetici müdahale edebilir. Performans değerlendirmelerinde sorunlar olsa da çoğu insan bunların nasıl çalıştığını ve organizasyonda bir amaca hizmet ettiğini anlıyor. FAST takımlarında performans incelemesi yapmanın aslında belirgin bir yolu yoktur. Kişinin yöneticisi onun ne yaptığını veya nasıl çalıştığını biliyor mu? “Takımları” bile değerlendiremezsiniz çünkü bunlar geçicidir. Bu nedenle performans yönetimi kavramının yeniden keşfedilmesi gerekiyor. Bu her ne kadar iyi bir fikir olsa da, düşünmeyi ve icat etmeyi gerektiren bir şeydir. FAST'ta mühendislik yöneticilerinin rolü nedir? Bir mühendislik yöneticisi rolünü yapılandırmanın birçok yolu vardır. Genel olarak bulunmasını öneriyorum çünkü bu onları güç farkının sorun yaratacağı bir alana koymadan ekibiyle yan yana çalışmalarını sağlar. Mühendislik yöneticisi rolünü tanımlamanın pek çok geçerli yolu vardır, ancak ben buna yönelme eğilimindeyim. proje yönetiminden sorumlu mühendislik yöneticisinin FAST'ta mühendislik yöneticisinin rolü daha az açıktır. Uzun ömürlü ekipleriniz yok, dolayısıyla mühendislik yöneticisinin kendilerine doğrudan bağlı olanlarla yan yana çalışması daha zor. Kendi kendine oluşturulan ekiplere mühendislik yöneticilerinin liderlik etmesini sağlayabilirsiniz. Veya onların saf insan yöneticileri olmalarını sağlayabilirsiniz. Ya da onların oyuncu-antrenör olmalarını sağlayabilirsiniz. Bunların hepsinin değiş tokuşları ve oldukça büyük dezavantajları var. FAST, mühendislik yönetimine olan ihtiyacı azaltıyor gibi görünüyor. Hala işe alacak, performans yönetimi yapacak ve süreci denetleyecek insanlara ihtiyacınız var. Ama belki geleneksel bir organizasyondaki kadar değil? Bir disiplin olarak yönetime değer vermedikleri için birçok kuruluşun acı çektiğini gördüm. Ancak FAST organizasyonlarının daha az yönetime ihtiyaç duyduğunu tahmin ediyorum. Bunun işe yarayıp yaramayacağını gerçekten merak ediyorum ve FAST'ı deneyen kuruluşlardan bilgi almak istiyorum. Yönetim konusunda ne yapıyorsunuz? Sahiplik alanları olmadan kod kalitesini nasıl sağlayacaksınız? Kod sahipliği, kod kalitesini yüksek tutmak için doğal teşvikler sağlar. Bu sizin çıkarınızadır, çünkü gelecekteki benliğiniz mevcut kodunuz üzerinde çalışmak zorundadır. Paylaşılan kod sahipliği durumunda, kod kalitesini sağlamak için daha fazla çaba harcamanız gerekir. Benim tavsiyem gerekli bir uygulama olarak eşleştirme veya mobbing olacaktır. Kod kalıpları için daha güçlü standartlara da ihtiyacınız olacak. Kod astarına ihtiyacınız olacak. Ve bir çeşit mimari karar almaya ihtiyacınız olacak. Ön uç kodunuzun durumu nasıl ele aldığına ilişkin yirmi modele sahip olmak istemezsiniz. Bunlar çoğu yazılım kuruluşunda karşılaşacağınız sorunlardır, ancak FAST kullanan bir kuruluşta çok daha acil olacaktır. Pek çok kuruluşun gereğinden az yatırım yaptığı şeylerden biri de etkili yazılım tasarım modelleriyle ilgili eğitim ve iletişimdir. Ve herkesin hangi yaklaşımların ne zaman kullanılacağı konusunda aynı fikirde olmasını sağlayacak konuşmalar. Bunlar muhtemelen bir FAST organizasyonunda daha da önemlidir. Paylaşılan kod sahipliği, bazı emsalleri olan bir uygulamadır. HIZLI ile devam ederseniz, bu konuda nasıl başarılı olabileceğinizi araştırmak için zaman harcamaya değer. Birden fazla Kolektifte ve Kolektif sınırlarının aşılmasında ne olur? Kolektif sınırları aşan işler esasen FAST'ta tanımsızdır. Yüksek derecede koordinasyon gerektiren büyük girişimler de FAST tarafından yeterince belirtilmemiştir. Dolayısıyla bu durumlara çözüm bulmanız gerekir. FAST kullanan birden fazla Kolektife sahip olacak kadar büyük herhangi bir kuruluş, Kolektifler arası projelerle karşılaşacaktır. Bu sorunları ele alma kalıpları, daha küçük ölçekte çözümleme şeklinize benzer veya benzer olacaktır. Ancak bildiğim kadarıyla burası büyük ölçüde keşfedilmemiş bir bölge. Bu nedenle, ortaya çıktıklarında bu sorunları çözmek için bazı kullanmanız gerekecek. Bu bir icat eylemi olacak. koordinasyon modellerini FAST çağrı üzerine nasıl davranır? Çağrı sırasında özel olarak bahsedilmiyor. Bu yüzden bununla başa çıkmak için bir plan icat etmeniz gerekecek. FAST kılavuzunda Geleneksel ekiplerde çağrı üzerine standart tavsiye, her ekibin kendi operasyonlarından sorumlu olmasıdır. Ve ekipteki herkesin görev başında olmasını sağlamak. Bu, yükün çok kötü olmaması için en az dört kişiden oluşan ekiplerinizin olması gerektiği anlamına gelir. Buradaki düşünce, ekiplerin iş ürünleri için çağrıda bulunmasının onları güvenilirliği artırmaya teşvik etmesidir. Bu, iyi bir çağrı programlarına sahip olmalarına yardımcı olur. FAST ile katmanları olan bir çağrı üzerine rotasyon oluşturabilirsiniz (bu runbook'u takip edin ve sorunu çözmezse üst kademeye iletin). Ve kimin neyi destekleyebileceğinin bir haritasını açıkça saklamanız gerekecek. Bu, takımlarınızla eşleşmeyecektir. Bunu yapmak çok zor olmasa da geleneksel çağrı uygulamalarına göre daha az yaygındır ve yönetimin dikkatini gerektirir. Hataları düzeltmeye ve üst kademelere destek sağlamaya ne dersiniz? FAST'ın "Özellik Sorumlusu" adı verilen isteğe bağlı bir rolü vardır. Belirli bir özellik konusunda bir nevi uzmandırlar ve paydaşlar için bu özellik etrafında iletişim noktasıdırlar. Bu özellik üzerinde sürekli çalışmaları gerekmemektedir ancak bu özelliği sürekli olarak anlamaları gerekmektedir. Çağrı sırasında olduğu gibi, özelliklerin bu özellikler konusunda uzmanlığa sahip kişilerle eşleştirilmesine ihtiyacınız olacak. Bu hem hatalar hem de destek yükseltmeleri açısından önemli olacaktır. Ayrıca bunu çağrı üzerine de birleştirebilirsiniz. Sorunları doğru kişilere önceliklendirmenin bir yoluna ihtiyacınız olacak. Ayrıca uzmanlığın bir veya iki kişiyle sınırlandırıldığı durumlarda bilgi boşluklarını dolduracak bir mekanizmaya sahip olduğunuzdan da emin olmanız gerekir. Karar vermeniz gereken şeylerden biri, hataları düzeltme politikanızdır. Diğer özelliklerin çalışmasını yavaşlatarak bunların her zaman düzeltilmesini mi istiyorsunuz? Hatalar, onları tanıtan kişi tarafından mı düzeltildi, yoksa başka bir plan mı istiyorsunuz? Peki hataların tetiklenmesinden kimin sorumlu olduğunu nasıl belirleyeceksiniz? Muhtemelen bir çeşit mu? rotasyon Destek yükseltmeleri de biraz çaba gerektirecektir. İrtibat noktası, bir bölgenin Özellik Sorumlusu'dur. Peki ya Özellik Komiseri tatildeyse? Muhtemelen her alan hakkında birden fazla kişinin bilgi sahibi olmasını istersiniz. Peki ya destek sorusu çalışma gerektirmeye başlarsa? İşi sadece siz mi yapıyorsunuz yoksa merkezi önceliklere mi aktarıyorsunuz? Bunların hiçbiri çözülmesi zor sorunlar değil, ancak bunlar yönetim işidir. Ve yaptığınız her şeyde odaklanma ve tepki verme arasında dengeler olacaktır. Güvenilirlik olayları ve geçmişe dönük olay incelemeleri ne olacak? FAST olayların nasıl ele alınacağını tanımlamaz. Çağrı düzeniniz büyük ölçüde olayların nasıl ele alınacağını belirleyecek ve muhtemelen durumu düzeltmek için nasıl düzeltileceğini bilen kişileri de içerecektir. FAST, olayların geriye dönük olarak nasıl ele alınacağını açıklamaz. Aşağıdakine benzer bir şey yapmanızı tavsiye ederim: Bir sonraki Kolektif toplantıdan önce meydana gelecek bir olayı geriye dönük olarak planlayın. Retrospektifin amaçlarından biri, olaya neden olan şeyin olasılığını veya ciddiyetini azaltacak yapılabilecek birkaç çalışmayı belirlemek olacaktır. Bir diğeri ise olaydan öğrenebileceğiniz her şeyi öğrenmek olacaktır. Olayın hemen ardından yapılan Toplu toplantıda öğrendiklerimizi paylaşacak ve ayrıca bir sonraki döngü için retrospektifte belirlenen bazı işlerin yapılmasını otomatik olarak önceliklendirecektim. New Relic'te FAST kullanmıyorduk ancak benzer bir politikamız vardı. Biz buna “Olayları Tekrarlamayın” (DRI) adını verdik. Güvenilirlik açısından şimdiye kadar yaptığımız en iyi şeylerden biriydi. Kural, DRI çalışmasının otomatik olarak diğer önceliklerden daha önemli olmasıydı. Bu nedenle, bir olay her zaman ya kapsamın azalmasına ya da son teslim tarihinin ertelenmesine neden oluyordu. Tasarımcılar FAST'ta nasıl çalışır? Birçok tasarımcının karşılaştığı zorluk, mühendislik ekibiyle çalışmaya veya mühendislik ekibinin önünde iş yapmaya odaklanmaktır. Veya her iki yönde de çalışmasını sağlayın. Her iki çalışma şekli için de güçlü argümanlar duyacaksınız. FAST bunun nasıl çalışması gerektiğini belirtmez, dolayısıyla kendiniz karar vermeniz gerekir. Tasarımcılar üzerinde çalışacak ekiplere kaydoluyor mu? Yoksa önceden çalışan ve insanların kendilerinden bir şeye ihtiyacı olduğunda olarak hareket eden bir hizmet kuruluşu mu? Karar vermeniz gerekecek. Muhtemelen tasarımcıların kaydolmasını ve ekiplerin bir parçası olmasını isterim, ancak yine bu, FAST'ı benimserken vermeniz gereken karar türlerinin bir örneğidir. danışman Ürün yöneticileri FAST'ta nasıl çalışır? FAST'taki ürün rolü çoğunlukla öncelikleri belirlemek ve öncelikleri iletmektir. Bunun dışındaki çalışmalar hakkında FAST kılavuzunda gerçekten açıklanmayan pek çok şey var. FAST kılavuzundaki varsayım, ürün yöneticilerinin ilham verip iletişim kurduğu ve ardından mühendislerin özellikler üzerinde çalıştığı yönünde görünüyor. Yapabildiğiniz ölçüde mühendislerin müşterilerle konuşmasını ve çalıştıkları ürün alanında uzmanlık kazanmalarını sağlarım. İdeal olarak işi onlar yapar, müşterilere gösterir ve onlardan geri bildirim alırlar. . Ürün yöneticilerinin bunu kolaylaştırmasını sağlamak ve mühendislerin bunu etkili bir şekilde yapma becerilerini geliştirmek, işlerinin değerli bir parçası olabilir. Bu modelde çok fazla esneklik var. Tipik ürün-mühendislik aktarımını gerçekleştirebilir veya müşterilerinizle birlikte alanı keşfetmelerini ve problem çözmelerini sağlayabilirsiniz. Gördüğünüz gibi FAST'ta birçok boşluk var. Gerisini problem çözmeniz gerekecek. FAST materyalleri jargonla doludur FAST web sitesini ve kılavuzunu kafa karıştırıcı bulabilirsiniz. FAST Agile'ın altınına ulaşmak için birçok jargon ve sinir bozucu terminolojide gezinmeniz gerekecek. Örnek olarak, uygulamayı tanımlamaya çalışan FAST Agile'ın berbat tanımı aşağıda verilmiştir: FAST Kılavuzunun 2.12 versiyonundaki “Akışkan Ölçekleme Teknolojisi Nedir? Akışkan Ölçeklendirme Teknolojisi, insanları iş çevresinde organize etmek için hafif, anlaşılması kolay ve ustalaşması basit bir yöntem oluşturmak için Açık Alan Teknolojisi ile Açık Tahsis'i birleştirir; bu ölçeklenir. FAST, Fluid Scaling Technology'nin kısaltmasıdır. Çevik için Akışkan Ölçeklendirme Teknolojisi HIZLI Çeviktir.” Bu yüzden. Kötü. Ve bu oldukça temsili bir durum. Kolektiflere, Değer Döngülerine, Açık Teknolojiye, Deniz Mavisi dönüşümüne, Y Teorisine vs. pek çok referans göreceksiniz. Bunların hepsi hiçbir açıklama olmadan sunuluyor ve açıklansa bile aslında faydası olmayacak. Çevik teorisyenlerden oluşan niş bir kitleye hitap ediyorlar ve kullanışlılıktan ziyade ilişkilendirmeye odaklanıyorlar. Çözüm Peki bu bizi nereye bırakıyor? FAST çevikliği denemeye değer mi? Bunun cevabının evet olduğuna inanıyorum, ancak dikkatli ve doğru bağlamlarda. Bireysel takımlar içinde bununla oynayabilirsiniz. Ve eğer liderlik desteğiniz varsa, bunu daha büyük organizasyonlarda yavaş yavaş deneyin. Eğer deneme yaparsanız lütfen benimle paylaşın. Kuruluşunuzda bunu yaygınlaştırma konusunda yardıma ihtiyacınız varsa benimle iletişime geçin. Size ya doğrudan yardım edeceğim ya da sizi yardım edebilecek diğer kişilerle buluşturacağım. Teşekkür ederim Bu yazının ilk versiyonları… gerçekten kötüydü. Eleştirileri için ve teşekkür etmek istiyorum. Her ikisi de gönderiyle ilgili bazı önemli sorunlara dikkat çekti ve bu da beni geri adım atmaya ve yaklaşımımı yeniden düşünmeye yöneltti. Ve yazının kendi bölümlerine dahil ettiğim bazı mükemmel noktalara değindiler. Sonunda yazının çoğunu yeniden yazdım ve sonuçtan çok daha mutlu oldum. Teşekkür ederim! Seth'in var ve Davy (benim gibi) yapıyor. Seth Falcon Davy Stevenson'a mühendislik liderliği üzerine göz atmaya değer bir haber bülteni startup danışmanlığı ve koçluk beni FAST agile ile tanıştırdı. Bununla ilgili deneyimleri hakkında bazı var. Birkaç kez buluştuk ve FAST'ın sonuçlarını ve uygulanmasını tartıştık. Jim yazarıdır. Jim Shore mükemmel konuşmaları , Çevik Gelişim Sanatı kitabının Resim tarafından yüklendi Kanenori Pixabay'a Dipnotlar 150 kişinin bir Kolektif için muhtemelen hantal olduğuna inanıyorum. Altmış kişinin daha iyi bir maksimum boyut olduğundan şüpheleniyorum. da yayınlandı. Burada
