Scrum Master görevleri tahsis edebilir mi?

Projemizde scrum'u takip ediyoruz. Scrum ustasının çoğu kez görevleri bizim için ayırdığını görüyorum. Ancak scrum kitaplarından okudum ki scrum tam tersine çalışıyor ('çekme' yaklaşımı) ve ekip üyeleri görevleri veya özellikleri alıyor. Scrum master görevleri atamak doğru bir yaklaşım mıdır yoksa çevik ideolojiye aykırı mıdır?

Scrum hakkındaki Wikipedia Makalesine göre , Sprint görevleri ScrumMaster tarafından atanmaz:

Sprint biriktirme listesindeki görevler hiçbir zaman atanmaz; bunun yerine, görevler belirlenen önceliklere ve ekip üyesi becerilerine göre gerektiğinde ekip üyeleri tarafından kaydedilir. Bu, ekibin kendi kendine organizasyonunu ve geliştirici katılımını teşvik eder.

Ayrıca, ScrumMaster'ın tanımı, insanların Scrum sürecinin kurallarına uymasını sağlamaktan sorumlu kişi olmasıdır.

ScrumMaster Scrum işleminden sorumlu kişi, doğru kullanıldığından emin olmak ve faydalarını en üst düzeye çıkarmak.

ScrumMaster basit ve basit görevler atamaz. Ekip kendi kendini organize ediyor ve ekip tarafından neyin kararlaştırıldığı konusunda kimin çalıştığına karar veriyor.

Bu gerçek Scrum. Bununla birlikte, birçok kuruluş bunun varyasyonlarını kullanabilir.

Bu şekilde çalışması gerekiyordu, ancak teoride harika çalışan her şeyde olduğu gibi ... her zaman işe yaramaz.

Dışarıdan bağımlılıklar, müşteri istekleri ve sürücüler var. Bazı şeylerin herkesin üzerinde çalışmak istediği süslü widget üzerinde çalışabilmeniz için yapılması gerekiyor.

İçerden gelen temel geliştirici yetenekleri var. Bazı şeyler zor ve bazı insanlar daha iyi. Elbette, sonsuz bir zaman çizelgesi içinde çalışırken, sadece çözmenize izin verebilirim; ama bir şey yapılması gerektiğinde, en hızlı şekilde ve en iyisi olmak için en iyi şekilde yerleştirilmiş kişiye tayin etmek, işi alan kişidir.

Ve sonra Scrum Master'ı ve / veya söylenmeden kendi ayakkabılarını bağlayamayan geliştiricileri kontrol etmek gibi kişilik sorunları var. Mesela ekibim her ikisine de sahip. Böyle durumlarda herkesin Scrum hakkındaki bu küçük gerçeği görmezden gelmesi daha iyi çalışır.

Başka bir deyişle, sadece bunu yapma çünkü süreç diyor. Neyin işe yaradığını yapın. Gerisini vidalayın.

Tabii ki, insan varlığının başka bir temel gerçeği de var .... belki Scrum Master'ın gerçekte kim olduğunu bilmiyorsunuzdur. Belki de o unvanı taşıyan kişi değildir. Belki sende yok.

Asla.

Scrum bu konuda tamamen açık. Geliştirme Ekibi, bir grup olarak, Sprint biriktirme listesindeki öğeleri tamamlamaktan sorumludur. Ayrıca, gelişimi nasıl gerçekleştireceklerini tamamen kontrol ediyorlar ve kimsenin bunu nasıl yapacağını söylemesine izin verilmiyor.

Antrenör olarak Scrum Master'ın, Takımın Sprint hedeflerini herhangi bir nedenden dolayı kaçırma tehlikesi içinde olduğunu gördüğünde bunu belirtmede bir rolü vardır. Ama sonra onlarla nasıl başa çıkacaklarını anlamalarını ve sonra kendi yollarından çıkmalarını istemesi gerekiyor.

Başka bir yaklaşım, Ekibin Sprint'i tamamlamasına, sonuç eksikliğinden sorumlu tutmasına ve daha sonra Sprint Retrospektifinde tartışılmasına izin vermek olabilir.

Herhangi bir ideoloji gibi, kural kitabının atılması veya dikkatlice göz ardı edilmesi gereken zamanlar vardır.

Neyin uygun göründüğüne dair bazı kararlar verin. Birisinin fiili bir proje yöneticisi haline gelmesine dikkat edin - ya da daha kötüsü, insanları belirli şeyleri yapmaya zorbalık yapın.

Dikte ile görev tahsisi (X yapmanız gerekir) ve tartışma ve anlaşmaya göre tahsis arasında büyük bir fark vardır. Bazen anlaşma ılık olabilir.

Sonra tekrar, belki takımın yönetmeye ihtiyacı vardır ... bilmek zor.

Bununla birlikte, süreci kıpır kıpır ya da yargılanmak zorunda kalmadan mektuba takip etmeniz konusunda ısrar eden herhangi bir işlemden endişe ediyorum. Böyle bir süreç düşünmenin yerini alır.

Bence, scummaster bunu yapmamalı, ekip üyeleri kendileri görev almalılar. Scrummaster yönetimi sadece ekibimizde olduğu gibi yapıyorsa sorun görülmüyor. Scrum master'ımız kağıt scrum kartının excel dosyasıyla senkronize kalmasını sağlar. Scrum ustasının rolü, işinizi engellemeden yapabilmenizi sağladığımız kolaylaştırıcı bir rol olmalıdır. Çalışma şeklimiz bu. Scrummaster'ınızın bunu neden yaptığını biliyor musunuz? Eski olmaktan korkan bir proje yöneticisi mi? Ekibin kendileri görev üstlenmeyeceğinden korkuyor mu? Retrospektif sırasında bunu tartışmak iyi bir fikir olabilir.

Her iki ortamda da bir scrum ustasıyım (görevleri bireylere ittiğim ve bireylerin görevleri çektiği yer).

Push ekibi, geliştirme kaynakları birbirinin yerine geçemezdi. Windows İstemci çalışması Windows geliştiricisine, web çalışması da web geliştiricisine gitmek zorunda kaldı. Böylece planlama oturumları sırasında görevleri kaynaklara aktarabildim. Ayrıca ne zaman itmeyi bırakacağımı bilmek için bireysel kapasite planlaması yapabildim.

Çekme yöntemi, herhangi bir görevin herhangi bir kaynak tarafından alınabileceği bir ekipte iyi çalıştı. Ancak, planlama oturumu sırasında bireysel kapasite planlaması yapamadım, bunun yerine yeterli zamanın ne zaman yeterli olduğunu bilmek için ortalama hıza bağlı kalmalıydım. (Hız hakkında iyi bir fikrimiz olmadan ~ 3-4 sprint aldık).

Bir rastladım ilginç makalesinde itin vs Çekme artıları / eksileri özetleyen.