stanford-oval/wikipedia huggingface dataset:
Joyce DiDonato
Kayıtlar > Konserler

Antonio Vivaldi: The Complete Sacred Music
Mendelssohn: A Midsummer Nights Dream
Mozart: The Last Concerto 1791
Rossini: Stabat Mater,
Homecoming: The Kansas City Symphony Presents Joyce DiDonato
Kayıtlar > Resitaller

Amor e gelosia: Handel Operatic Duets
The Deepest Desire
Joyce DiDonato: Songs by Fauré, Hahn and Head · Arias by Rossini and Handel
¡Pasión!
Furore – Mad Scenes from Handel Operas
Colbran, the Muse
Diva, Divo
Drama Queens
Stella di Napoli
here/after.
Joyce & Tony: Live at Wigmore Hall,
In War & Peace: Harmony through music 2016 yılında çıktı, Erato.
Kayıtlar > Diğerleri

William Barnewitz: Long Road Home
Plácido Domingo's Operalia '98: A Tribute to Passion and Soul,
OpenGL

OpenCL ile karıştırılmamalıdır.
| --- | --- |


Geliştirici(ler): Khronos Group
Güncel sürüm: 4.6  31 Temmuz 2017
Geliştirme durumu: Aktif
İşletim sistemi: Platform bağımsız
Tür: API
Lisans: Birden fazla
Resmî sitesi: www.opengl.org
OpenGL (İngilizce: Open Graphics Library, Türkçe: Açık Grafik Kütüphanesi), gelişmiş donanım desteğini kullanarak hem iki hem de üç boyutlu grafikleri ekrana çizmek için kullanılan ücretsiz bir grafik uygulama geliştirme arabirimidir. Windows, Linux, MacOS ve Solaris gibi birçok işletim sisteminde yaygın olarak ve Playstation 3 başta olmak üzere bazı oyun konsollarınca desteklenir. Donanım tarafında ise SGI, ATI, Nvidia veya Intel gibi büyük üreticiler her ekran kartında OpenGL desteği sunar.
1992 yılında ilk taslağı yaratılmış olan bu standart, günümüzde 4.6 sürümüne ulaşmıştır ve 700 üzerinde fonksiyona sahiptir. Çoklu platform desteği içeren uygulamalar ve özellikle de deneysel ve bilimsel araçlarda açık arayla önde ve standart olarak kullanılmakta olan platform OpenGL'dir.
OpenGL'in özellikleri > Taşınabilirdir

Bu kitaplık işletim sisteminden ve işletim sisteminin çalıştığı platformdan bağımsızdır. Nasıl ki ekrana yazı yazmak kullanıcıdan veri almak ANSI C'de işletim sisteminden ve platformdan bağımsız olarak kütüphane tarafından printf() ve scanf() gibi işlevlerle standartlaştırılmış ve hangi işletim sistemiyle çalışırsanız çalışın bu iki işlev aynı işi yapıyorsa, OpenGL kitaplığıda ekrana grafik çizmeyi standartlaştırmıştır. OpenGL sayesinde grafik kartının modeli veya işlemcinin mimarisi gibi donanımsal etkenlerden bağımsız programlama yapılır. Aynı zamanda işletim sisteminden de bağımsız programlama yapılır. Kolay kullanım ve bu "taşınabilirlik" özellikleri nedeniyle OpenGL popüler bir araç olmuştur.
OpenGL'in özellikleri > Platform bağımsızdır

OpenGL kullanan bir programı işletim sisteminizde çalıştırmanız için öncelikle işletim sisteminizde programın çalışırken kullanacağı işlevleri içeren kitaplığın bulunması gerekir, bu kitaplıkların genel adı "runtime-library", Türkçesi çalışma anı kitaplığıdır.
OpenGL çalışma anı kitaplığı Linux, Unix, Mac OS, OS/2, Windows 95/98/NT/2000, OPENStep ve BeOS işletim sistemlerinde halihazırda mevcuttur. Windows işletim sistemi ailesinde standart olarak gelir. Yani OpenGL kullanan bir programı çalıştırmak için bir çaba harcamazsınız.
OpenGL'in özellikleri > Pencere yöneticisinden bağımsızdır

OpenGL kullanılarak yazılmış programlar, Win32, MacOS ve X-Window pencere yöneticilerinde sorunsuz çalışırlar.
OpenGL'in özellikleri > Birçok programlama dilinde kullanılabilir

Ada, C, C++, C# (SharpGL adı verilen sınıflar sayesinde), Fortran, Python, Perl ve Java programlama dilleri kullanılarak OpenGL kitaplığından faydalanılabilir.
Ekran kartı uyumluluk durumları

| DirectX Versiyonu | Shader Model | OpenGL karşılığı |
| --- | --- | --- |
| DirectX 11 | Pixel Shader 5.0 | OpenGL 4.0 |
| DirectX 10.1 | Pixel Shader 4.1 | OpenGL 3.x |
| DirectX 10 | Pixel Shader 4.0 | OpenGL 3.0 |
| DirectX 9c | Pixel Shader 3.0 | OpenGL 2.1 |
| DirectX 9 | Pixel Shader 2.0 | OpenGL 2.0 |
| DirectX 8.1 | Pixel Shader 1.3 & 1.4 | OpenGL 1.x |
| DirectX 8 | Pixel Shader 1.1 | OpenGL 1.4 |
| DirectX 7 | Pixel Shader 1.0 | OpenGL 1.2 |
Kirpi Sonic video oyunları listesi

.
{{Video oyunu serisi bilgi kutusu
|başlık = Kirpi Sonic
|italic title = no
|resim = SonicSeriesLogo.png
|yapımcı =
Sonic Team
Sega
Dimps
Traveller's Tales
Sumo Digital
Hardlight
Aspect
BioWare
Gameloft
|yayımcı = Sega
|tür =
Platform
Yarış
Aksiyon
Dövüş
Parti
Rol yapma
Spor
|yan ürün = Sonic Boom (dizi)
|yaratıcı =
Naoto Ohshima
Yuji Naka
Hirokazu Yasuhara
|sanatçı =
| platform =
Liste
Android
Arcade
Game Boy Advance
GameCube
iOS
Cep telefonu
Java ME
Microsoft Windows
N-Gage
Neo Geo Pocket Color
Nintendo DS
Nintendo 3DS
Nintendo Switch
Palm OS
PlayStation 2
PlayStation 3
PlayStation 4
PlayStation 5
PlayStation Portable
PlayStation Vita
Sega Genesis
Sega Game Gear
Sega Mega-CD
Sega Saturn
Sega Dreamcast
Sega Master System
Sega 32X
Sega Pico
Leapster
LeapFrog Didj
Wii
Wii U
Xbox
Xbox 360
Xbox One
Xbox Series X/S
Kirpi Sonic, bir video oyunu serisidir. Serideki oyunlar, Sega, Sonic Team, Dimps, SIMS Co., Ltd., BioWare ve Sumo Digital tarafından geliştirilip Sega tarafından yayımlanmıştır. Seri 1991 yılında Mega Drive (Kuzey Amerika'daki adı Sega Genesis'dir) oyun konsolu için yayımlanan Kirpi Sonic ile oyun dünyasına giriş yapmıştır. İlk başlarda çoğu Kirpi Sonic oyunu, platform oyunu olarak, Sega Genesis'ten Sega Dreamcast'in piyasaya sürüldüğü tarihe kadar sadece Sega ev ve el konsolları için yayımlanmıştır. Bununla birlikte, orijinal oyunlardan bazıları, daha yeni üçüncü taraf ev konsollarına çeşitli şirketler tarafından geliştirmeler eklenerek port edildi. Seri 2011 Mart'ı itibarıyla hem platform oyunları hem de yan ürünler birlikte hesaplandığında dünya çapında toplamda 89 milyon kopya sattı.
Serinin en popüler oyunları platform türünde olmakla birlikte; serinin yarış, aksiyon, dövüş, parti, rol yapma ve spor gibi farklı türlerde de oyunları mevcuttur. Her oyun, serinin baş kahramanı antropomorfik mavi bir kirpi olan Kirpi Sonic'e odaklanır. Ayrıca seride, Doctor Ivo "Eggman" Robotnik, Miles "Tails" Prower, Ekidne Knuckles, Amy Rose, Kirpi Shadow ve Chao yaratıkları gibi çok sayıda karakter de mevcuttur.
Arcade oyunları

| İsim | Ayrıntılar |
| --- | --- |
Waku Waku Sonic Patrol Car Orijinal çıkış tarihleri: JP: Aralık 1991: İşletim sistemleri için çıkış tarihleri: 1991 – Arcade
Waku Waku Sonic Patrol Car Orijinal çıkış tarihleri: JP: Aralık 1991:     
SegaSonic the Hedgehog Orijinal çıkış tarihleri: JP: Ekim 1993: İşletim sistemleri için çıkış tarihleri: 1993 – Arcade
SegaSonic the Hedgehog Orijinal çıkış tarihleri: JP: Ekim 1993: Notlar: Sonic the Hedgehog Arcade olarak da bilinir.  İztopu kullanılarak kontrol edilen bir platform oyunudur.  Oyunda üç oynanabilir karakter mevcuttur: Sonic, yeni bir karakter olan Armadillo Mighty (daha sonra Knuckles Chaotix ile Sonic Mania Plus oyunlarında yeniden görünecektir) ve yine yeni bir karakter olan Uçan Sincap Ray (cameo dışında Sonic Mania Plus ile Sonic Mania'nın geliştirilmiş sürümüne kadar serinin hiçbir oyununda yeniden görünmemiştir).  Sonic Team bu oyunu Sonic Gems Collection'a eklemeyi düşünmüş; ancak iztopu kontrol şeması bunu imkansız kılmıştır.    
SegaSonic Cosmo Fighter Galaxy Patrol Orijinal çıkış tarihleri: JP: 1993: İşletim sistemleri için çıkış tarihleri: 1993 – Arcade
SegaSonic Cosmo Fighter Galaxy Patrol Orijinal çıkış tarihleri: JP: 1993:     
SegaSonic Popcorn Shop Orijinal çıkış tarihi: JP: 1993: İşletim sistemleri için çıkış tarihleri: 1993 – Arcade
SegaSonic Popcorn Shop Orijinal çıkış tarihi: JP: 1993: Notlar: Patlamış mısır satış makinesinin üzerindeki bir arcade mini oyunudur.  Sonic, döndürme kolu ile kontrol edilmektedir.    
Sonic the Fighters Orijinal çıkış tarihleri: JP: Haziran 1996 KA: Temmuz 1996: İşletim sistemleri için çıkış tarihleri: 1996 – Arcade 2005 – PlayStation 2, GameCube 2012 – PlayStation Network, Xbox Live Arcade
Sonic the Fighters Orijinal çıkış tarihleri: JP: Haziran 1996 KA: Temmuz 1996: Notlar: Sega AM2 tarafından geliştirilmiştir.    
Sonic Athletics Orijinal çıkış tarih(ler)i: JP: 25 Nisan 2013: İşletim sistemleri için çıkış tarihleri: 2013 – Arcade
Sonic Athletics Orijinal çıkış tarih(ler)i: JP: 25 Nisan 2013: Notlar: Koşu bandı ile kontrol edilen bir exergamedir.
Eğitici oyunlar

| İsim | Ayrıntılar |
| --- | --- |
Sonic the Hedgehog's Gameworld Orijinal çıkış tarihleri: JP: Ağustos 1994 KA: Kasım 1996: İşletim sistemleri için çıkış tarihleri: 1994 – Sega Pico
Sonic the Hedgehog's Gameworld Orijinal çıkış tarihleri: JP: Ağustos 1994 KA: Kasım 1996:     
Tails and the Music Maker Orijinal çıkış tarihi: KA: Eylül 1994: İşletim sistemleri için çıkış tarihleri: 1994 – Sega Pico
Tails and the Music Maker Orijinal çıkış tarihi: KA: Eylül 1994:     
Sonic's Schoolhouse Orijinal çıkış tarihi: KA: 18 Ekim 1996: İşletim sistemleri için çıkış tarihleri: 1996 – Windows
Sonic's Schoolhouse Orijinal çıkış tarihi: KA: 18 Ekim 1996:
İptal edilen oyunlar

| İsim | Ayrıntılar |
| --- | --- |
Kirpi Sonic İptal edilme tarihi: 1991: İşletim sistemleri için tahmin edilen çıkış tarihi: 1991 – Amiga
Kirpi Sonic İptal edilme tarihi: 1991: Notlar: Mega Drive için yayımlanan Kirpi Sonic oyununun iptal edilen Amiga portudur.    
Sonic's Edusoft İptal edilme tarihi: 1991: İşletim sistemleri için tahmin edilen çıkış tarihi: 1991 – Master System
Sonic's Edusoft İptal edilme tarihi: 1991: Notlar: Tiertex Design Studios tarafından geliştirilen eğitici bir oyundu.    
SegaSonic Bros. İptal edilme tarihi: 1992: İşletim sistemleri için tahmin edilen çıkış tarihi: 1992 – Arcade
SegaSonic Bros. İptal edilme tarihi: 1992: Notlar: 1992 yılında başarısız yerelleştirme testi.  Oyuncuların farklı renkteki Sonic'leri (mavi,kırmızı,sarı) yöneteceği bir yapboz oyunuydu.  Fukio Mitsuji tarafından geliştirilmiştir.    
Sister Sonic İptal edilme tarihi: 1993: İşletim sistemleri için tahmin edilen çıkış tarihi: 1993 – Sega Mega-CD
Sister Sonic İptal edilme tarihi: 1993: Notlar: Popful Mail oyununun yerelleştirme denemesiydi.    
Sonic Jr. İptal edilme tarihi: 1994: İşletim sistemleri için tahmin edilen çıkış tarihi: 1994 – Sega Pico
Sonic Jr. İptal edilme tarihi: 1994: Notlar: Sonic'in daha genç halinin yer aldığı eğitici bir oyundu.    
Sonic Crackers İptal edilme tarihi: 1994: İşletim sistemleri için tahmin edilen çıkış tarihi: 1994 – Mega Drive/Genesis
Sonic Crackers İptal edilme tarihi: 1994: Notlar: "Sonic Studium" ve "Sonic Stadium" olarak da bilinir. Nihai olarak Knuckles' Chaotix adıyla geliştirilip yayımlanmıştır.    
Sonic X-treme İptal edilme tarihi: 1997: İşletim sistemleri için tahmin edilen çıkış tarihi: 1997 – Sega Saturn
Sonic X-treme İptal edilme tarihi: 1997:     
Sonic Extreme İptal edilme tarihi: 2002: İşletim sistemleri için tahmin edilen çıkış tarihi: 2002 – Xbox
Sonic Extreme İptal edilme tarihi: 2002:     
Sonic DS İptal edilme tarihi: 2004: İşletim sistemleri için tahmin edilen çıkış tarihi: 2004 – Nintendo DS
Sonic DS İptal edilme tarihi: 2004:
Kolektif şirket

Kolektif şirket, Türk Ticaret Kanununa göre Kolektif Şirket "Ticari bir işletmeyi, bir ticaret unvanı altında işletmek amacıyla gercek kişiler arasında kurulan ve ortakların hiçbirinin sorumluluğu şirket alacaklarına karşı sınırlanmamış olan şirkettir. Pek yaygın olmayan bir şirket türüdür. Ortakların kişisel emek ve gayretlerinin önem kazandığı ticari işletmeler bakımından düşünülebilecek bir türdür. Bununla birlikte şirkete ortak olan kişilerin, şirketin borçlarından ötürü tüm mal varlıkları ile sorumlu olmaları, sınırlı sorumluluğun hakim olduğu limited ve anonim şirketlere karşı kolektif şirketlerin en zayıf noktasını teşkil etmektedir. Benzer ihtiyaçlara cevap veren kolektif ve limited şirketlerin kurulma oranlarına bakıldığında, kolektif şirketin ticaret hayatında tercih edilmeyen bir tür olduğu sonucuna varılmaktadır. Gerçekten de, Türkiye İstatistik Kurumu'nun 2007 yılı Ekim ayı verilerine bakıldığında kurulan 4126 şirketin sadece 1 tanesinin kolektif, buna karşın 3666 tanesinin limited şirket olduğu görülmektedir. Bütün şirket tipleri içerisinde tüzel kişilerin ortak olarak yer alamayacağı tek şirket türü kolektif şirketlerdir.
Kolektif şirket, özellikle küçük ve orta çapta perakende, yarı toptancı ticaret işletmeleri ile, orta çapta işletmeler için uygundur. Asgari bir sermaye koyma zorunluluğu da yoktur. Kolektif şirket ortakları birbirine güveni olan kimseler arasında kurulur. İşletme masrafı sermaye şirketlerine kıyasla oldukça düşüktür. Vergi açısından da kurumlar vergisine değil, gelir vergisine tabidir.
Yapıları komandit şirketlere benzemekle birlikte, kolektif şirketlerde yalnız gerçek kişiler hissedar olabilir. Asgari sermaye gereksinimi olmayıp hissedarların sorumluluğu hisseleri oranında sınırlıdır. Hissedarların sorumluluk ve yükümlülükleri Şirket Kuruluş Sözleşmesi ile belirlenir.
Scrum

Scrum Süreci
Scrum (engl. "itişip kakışma“), yazılım geliştirme ve yazılım Mühendisliği'nde bir uygulama geliştirme çerçevesidir. Proje yönetimi'nde karmaşık bir ortamda ürünleri geliştirmek, sunmak ve sürdürmek için Çevik yazılım geliştirme felsefesini benimseyen bir çerçevedir. "Hamleci yaklaşım" şeklinde bir çeviri önerilmiştir. Bu geliştirme çerçevesinin temel özelliği gözlemci, geliştirmeci ve tekrara dayalı olmasıdır. Birçok modern yazılım projesinin oldukça karmaşık olduğu ve en baştan tümünü planlamanın zor olacağı şeklindeki bir varsayımdan hareket eder. Bu karmaşıklığı üç ilke ile azaltmaya çalışır.
Şeffaflık: Projedeki ilerlemeler ve sorunlar günlük olarak tutulur ve herkes tarafından izlenebilir olması sağlanır.
Gözlem: Ürünün parçaları ya da fonksiyonları düzenli aralıklarla teslim edilir ve değerlendirilir.
Uyumlanma: Ürün için gereksinimler en baştan bir defalığına belirlenmez, bilakis her teslimat tekrar değerlendirilir ve duruma göre uyarlamalar yapılır.
Amaç başlangıçta hayal edilen ve tasarlanana uyan bir ürünün, hızlı, ucuz ve kaliteli şekilde üretilmesidir. Tasarlanan ürünün gerçekleştirilmesi, müşteri/kullanıcı tarafından mümkün olduğunca detaylı şekilde hazırlanmış bir talepler listesinin aşama aşama gerçekleştirilmesi biçiminde yapılmaz. Bunun yerine müşteri/kullanıcı tarafından istenilen ve tanımlanan işlevler, iki ya da dört haftalık "Sprint" adı verilen dönemler içerisinde geliştirilir ve yeniden gözden geçirilir. Bu kullanıcı bazlı gereksinim tanımı Kullanıcı Hikayesi olarak nitelenir ve özellikler defterinde yer alır. Her Sprint sonunda yazılımın fonksiyonel bir parçası bitmiş ve müşteriye teslim edilebilir bir durumda olur. Scrum Çevik yazılım geliştirme prensiplerini hayata geçiren bir yöntemdir.
Scrum karmaşık projelerin yönetimi için bir çatıdır (Çatı anlayışı bitmiş bir program değil, yazılımın bir çerçevesidir).
Tarihsel Temelleri

Scrum Ken Schwaber ve Jeff Sutherland tarafından 1990'ların başında geliştirildi ve temel fikirleri Schwaber (Schwaber 2004) tarafından ortaya konmuştur.
Scrum proje rolleri:
Ürün Sahibi (Product Owner)
Takım (Team)
Scrum Ustası (ScrumMaster)
ve özellikle "geleneksel" "proje yöneticisi" rolü bulunmaz.
Proje rollerinin görevlerine ek olarak Scrum proje akışını Sprint (en fazla dört hafta süren) anlayışıyla düzenler.
Ken Schwaber, Jeff Sutherland ve diğerleri tarafından formüle edilen Çevik manifesto (Agile 2001) çevik yazılım geliştirme değerleri Scrumda vücut bulur:
Çevik Yazılım Geliştirme Manifestosu'na göre;
1) Süreçler ve araçlardan ziyade, bireyler ve etkileşimler,
2) Kapsamlı dokümantasyondan ziyade, çalışan yazılım,
3) Sözleşme pazarlıklarından ziyade, müşteri ile işbirliği,
4) Bir plana bağlı kalmaktan ziyade, değişime cevap vermek,
daha değerlidir...
Roller

Scrum Süreç-Modeli net olarak üç çeşit rolü tanır: Ürün Sahibi, Takım ve Scrum Master.
Roller > Etkileşim

Scrum Ustası: Takımı korumak ve yardımcı olmak. Ürün sahibine yardımcı olmak.
Ürün Sahibi: Kullanıcı hikâyelerinin ayrıntılarını takım ile konuşmak. Dış rollerdekiler ile "Kullanıcı Hikâyeleri"ni belirlemek.
Geliştiriciler: Gereksinimlerin nasıl yapılacağını belirlemek ve standart kalite çerçevesinde (Bitti Tanımı) geliştirmek.
Roller > Ürün Sahibi (Product Owner)

Ürün Sahibi stratejik ürün geliştirmeden sorumludur. Sorumluluğu net bir ürün vizyonunun Tasarımı, iletişimi, özelliklerin tanımı ve önceliklendirme, teslim edilen sprintin işlevselliği ve kabul edilebilir olup olmadığına karar verme ve şirketin ekonomik faydasına uygun ürün tasarımı ve ana amaçları belirler. Yalnızca o teslimat, işlevsellik ve maliyet gibi kararlardan sorumludur.
Ürün Sahibi ürün özelliklerinin tanımlaması işlemini Ürün Gereksinimini (Product Backlog) kullanır ve yazılım Takımı ile birlikte çalışarak kullanıcı hikâyelerini (User Stories) taşır ve kullanıcı bazlı işlevsellikleri ifade eder. Aldığı kararlar bağlayıcıdır ve iptal edilemez.
Ürün Sahibi ya da proje sorumlusu son kullanıcının bakış açısını üstlenir ve yazılım gelişimini kontrol edip yazılımcılar için hazır bulunur. XP metodunun tersine projenin tek sorumlusudur 'yolculuk nereye' (Pichler 2008) .
Görevleri: Gereksinim Yönetimi, Yayın Yönetimi (Release) ve iletişim.
Roller > Geliştirme Takımı

Yazılım ekibinin görevi ürün sahibinin taleplerine ve sıralamasına uygun ürünün işlevselliğini sağlamak ve belirlenen kalite standartlarına uymak koşuluyla ürünü teslim etmektir. Ne kadar ve hangi işlevlerin sprinte dahil olacağına kendileri karar verirler.
Scrumda geliştirme takımı bir ekip olarak algılanır ve iyi ya da kötü sonuçlar takım elemanlarına çıkartılmaz bilakis takımı bir birim olarak algılar. Bir takım 5-9 kişiden oluşur.
Ek olarak yazılım takımı kullanıcı hikâyelerinin çerçevesini tahmin edebilir ama kural olarak da bir günü geçmemelidir.
Scrum takım içinde rol dağılımıyla ilgilenmez. Belirtildiği gibi Scrum bir yönetim metodudur. Tabii ki bütün roller ya da daha doğrusu yetenekler başarılı bir proje gelişimi için hazır olmak zorundadır.
Bir takımda olması gereken özellikleri iki başlık altında ifade edebiliriz:
1) Kendi kendine organize ve küçük
2) Multidisipliner ve özerk
Roller > Scrum Yöneticisi (Scrum Master)

Scrum Ustası Scrum'un başarılı olmasını sağlamaktan sorumludur. Bunu başarmak için Yazılım Takımı ile birlikte calışır ama takıma tabii olmaz.
Scrum kurallarını bildirir, uyumu kontrol eder ve toplantı moderatörlüğünü yapıp Scrum sürecindeki düzensizlikler ile ilgilenir.
İş aracı olarak engel-birikimini (Impediment Backlog) takımın önündeki engelleri kaldırmak için kullanır ve bu anlamda sorumluluk taşır.
Olası engeller: Takım içindeki iletişim eksikliği, kişisel çelişkiler, takım ve ürün sahibi arasındaki iletişim, dış kaynaklı rahatsızlıkların (ek işlevler gibi) giderilmesi.
Scrum ustası yazılım takımına karşı yürütme yetkisi vardır ancak şeflik yetkisi yoktur bu anlamda ne hüküm verebilir ne de disiplin kovuşturması yapabilir (Servant Leaders > Hizmetkar Liderlik).
Scrum ustasının kim olacağının belirlenmesinin en ideal yolu yazılım takımı tarafından seçilmesidir. Pratikte bu pek mümkün olmayabilir .Çünkü iş yapan firmalar Scrum takımının Scrum metodolojisine tam uyum sağlamaları için Scrum konusunda deneyimli bir personeli proje başında belirleyebilir.
Eğer Scrum birinci etabını geçtikten sonra, Scrum ustasının rolü değişiklik yöneticisi (Change-Manager) olarak algılanır.
Özet olarak Scrum ustası (Change Agent): Süreçten sorumlu, takımın arkadaşı ve yardımcısı, sürecin doğruluğunun denetleyicisi, takım ile birebir bağlantılı ve Takımın yanında çalışır.
Görevi:
) Scrumu uygulamak ve ürün sahibi ile yazılım takımına destek olmak.
) Engelleri kaldırmak (örnek; rol sahipleri arasındaki çelişkiler) ve süreçteki sapmaları düzenlemek.
) Takıma hizmet etmek ve meslektaş bir yönetim tarzı ile yönetmek.
Roller > Kullanıcı (User)

Kullanıcı ilerideki yazılımın/ürünün kullanıcısıdır. Ürünün nasıl bir perspektif ile kullanılacağı konusunda fikir verir ve gerçek hedef kitlesidir.
Kullanıcı Sprint başlangıcı ve sonucunda ürünü test etme amaçlı yer alır ve geri bilgi akışı (Feedback) sağlar.
) Kullanılabilirlik (Usability) konusunda takıma değerli ipuçları verir
) Takım ve ürün sahibi kullanıcı bilgileri doğrultusunda Sprint-planını uyarlar ve son durum tekrar kullanıcı tarafından test edilir.
Roller > Yönetici (Management)

Yönetici de kullanıcı ve müşteri gibi Scrum ekibine az oranda tabiidir. Ama scrumun yapısal çerçevesini yönetici belirler. Ek olarak da kaynaklar (Ressourcen) oluşturur (yer, alet vs.).
Scrum ustasına destek olur ve mesleki personel organizesi sağlar ve Scrum ekibini dış taleplerden korumak gibi bir sorumluluğu vardır.
Görevi: Projenin çerçevesi ile ilgilenir ve Scrum ustasının proje alanı içerisindeki belirlediği problemlerin çözümü ile ilgilenir.
Roller > Takım ve Etkileşim

Rol dağılımında takım kendi kendini organize eder. Ne Scrum ustası ne de ürün sahibinin takım içinde kimin neyi ne zaman kiminle yapacaklarına dair bir yaptırımı olmaz.
Scrum ustasının vazifesi yalnızca takımın farklı etkenlerlerle rahatsız edilmemesine dikkat etmektir.
Roller > Rollerin istismar riski

Scrum'da klasik "Proje Yöneticisi'nin olmayışı, özellikle deneyimsiz bir Scrum ekibinde, Scrum ustası ya da ürün sahibinin (Product Owner) bu rolü üstlenmesi tehlike yaratır ve takımın Özerklik statüsüne zarar vererek, Scrumda sapmalara yol açar. Bu tehlikeyi azaltmanın yolu Scrum-ustası ve ürün sahibinin bir Scrum-Expert'inden yardım almasıyla sağlanabilir.
Toplantılar > Sprint Planlama Toplantısı 1

Bu toplantıda ürün sahibi kendi yazılım takımına ürün içeriğinde (Product Backlog) kararlaştırılan kullanıcı hikayelerini (User Stories) öncelik sırasına göre belirtir ve gereksinimler takım tarafından netleştirilip yazılı olarak kaydedilir. Kullanıcı da işlevsellik konusunda önemli bilgiler verebilir. Bunun dışında ürün sahibi ve takım sprint içinde olması gereken işlevler ve kriterler üzerinde anlaşırlar (bkz. Definition of Done).
Amaç kullanılabilir yazılım elde etmektir: test edilmiş, entegre olmuş ve kullanıcıya açılmış olmalıdır.
Sprint'in kabul şartları kabul kriterleri (test, işlev, performans) ile etkileşimlidir. Bu tarz kararlar sprint sonucunda net şekilde belirlenir ve belirtilen fonksiyonların gerçekten içerdiklerine bakılır ve incelenir.
Açıklamalar yapıldıktan sonra Scrum ustası takımına gelecek sprint de kaç adet kullanıcı hikayesi olacağını sorar ve tek tek değerlendirilip dış baskı olmadan erişilebilirliğine bakılır. [26]
Süre: 60 dakika Sprint (haftalık)
Toplantılar > Sprint Planlama Toplantısı 2

Sprint-plan 1 de "NE?" ön planda iken, burada "NASIL?" sorusu ön plana çıkar.
Yazılım takımı hangi kullanıcı hikâyelerinin Sprint'e dahil olduğunu bilir ve uygulamanin(teorik) teknik boyutu açıklanır.
Toplantı Takım'ın kendi sorumluluğunda organize edilir.
Genellikle küçük gruplar oluşturulup yapı, test, açık gibi konulara açıklık verilir. Burada beklenen sonuç görevlerin bir günlük süreyi aşmayacak şekilde bitirilmesini kapsar.
Görevler belirlenen kullanıcı hikâyelerinden hareketle duvara ya da beyaz tahtaya (Taskboard) asılır bu sayede hangisinin işlemde ya da sırada olduğu bilinir.
Süre: 60 dakika her Sprint (haftalık) de.
Sprint-plan 1 ve 2 aynı gün içerisinde yapılmalıdır.
Toplantılar > Günlük Scrum (Daily Scrum)

Her iş günü başlamadan evvel 15 dakikalık bilgi paylaşımı için günlük Scrum toplantısı yapılır. Bu görüşmede herhangi bir problem değerlendirilmez, yalnızca 3 tema işlenir: dün ne yaptım, bugün ne yapacağım, beni ne engelliyor. Eger belirtilen görev bir günde bitmesi mümkün değil ise, görev parçalanıp takıma dağıtılır.
Eger 15 dakıka içinde bazı sorular cevap bulamadığı durumlarda Scrum ustası not alıp bir sonraki toplantıya taşır ya da kendisi çözüm üretir.