MKB Juristen, özel hukuki belgeler hazırlamaktadır
Önemli sözleşmeleri, şartları ve diğer yasal belgeleri kendiniz bir araya getirmek veya kopyalamak en iyisi değildir. Bütçesi kısıtlı girişimcilere özel yasal çözümler, net maliyetler ve pratik açıklamalar sunuyoruz.
- Gümrük sözleşmeleri, şartlar ve koşullar ve yasal belgeler
- Bütçe dostu ve maliyetler konusunda baştan net bilgi veriyor
- Ücretsiz danışmanlık veya herhangi bir yükümlülük gerektirmeyen fiyat teklifi isteyin
Çevik yazılım geliştirme sözleşmesi nedir? Çevik bir metodoloji (Scrum, sprintler) kullanılarak yapılan yazılım geliştirme için bir sözleşmedir; burada kapsam önceden kasıtlı olarak sabitlenmez. Sabit bir fiyata tek bir sabit sonuç yerine, çalışma yöntemi, bütçe, zaman çerçeveleri ve sprint başına kabul edilebilirlik konusunda anlaşılır. Müşteri, teslim edilenlere göre süreç boyunca ayarlamalar yapar. Bu, geliştirme sırasında gereksinimlerin daha da katılaştığı projeler için uygundur, ancak klasik sabit fiyatlı bir sözleşmeden farklı anlaşmalar gerektirir.
Kısa cevap
- Son ürün yerine metodoloji. Tek bir sınırlandırılmış şartname değil, Scrum'ı, sprintleri ve iş birliğini tanımlarsınız.
- Belirli bir kapsam yok. İş listesi ve öncelikler her sprintte değişebilir.
- Bütçe ve zaman çizelgeleri. Genellikle saatlik ücret veya sprint başına ekip ücreti, kararlaştırılan bir azami sınır dahilinde.
- Sprint bazında onay. Müşteri, teslim edilen işi sprint sprint onaylar.
- Fikri mülkiyet, ek işler ve çıkış. Haklar kime geçiyor, maliyet aşımları nasıl ele alınıyor ve sözleşme yarıda nasıl feshediliyor?
Çevik yazılım geliştirme sözleşmesi tam olarak nedir?
Klasik bir yazılım geliştirme sözleşmesinde, yazılımın ne yapması gerektiği, hangi fiyata ve ne zamana kadar teslim edileceği önceden ayrıntılı olarak belirtilir. Tedarikçi yazılımı geliştirir ve teslim eder. Yazılım belirtildiği gibi çalışmazsa, bu onların sorunudur.
Çevik yazılım geliştirme sözleşmesi bunu tersine çevirir. Taraflar, tüm gereksinimlerin önceden bilinmediğini kabul eder. Çalışan yazılım, kısa döngülerde (genellikle bir ila dört haftalık sprintler) teslim edilir, incelenir ve ayarlanır. Bu nedenle sözleşme, öncelikle bu işbirliğinin temel kurallarını belirler: roller, sprint uzunluğu, iş listesinin nasıl önceliklendirileceği ve adım adım nasıl kabul edileceği ve ödeme yapılacağı.
Sözleşmede Scrum ve sprintler
Scrum, en yaygın kullanılan çevik yönetim çerçevesidir. Temel unsurları sözleşmede yansıtılmıştır:
- Ürün sahibi. Genellikle müşteriden olup öncelikleri belirleyen ve ürün birikimini yöneten kişidir. Sözleşmesel olarak önemlidir: Bu kişinin ulaşılabilir olması ve karar alma yetkisine sahip olması gerekir.
- Sprintler. Ekibin belirli bir miktarda iş üstlendiği sabit dönemler. Sprint uzunluğunu ve planlanan sprint sayısını belirleyin.
- Bekleyen işler. İstenen işlevlerin öncelik listesi. Bu değişebilir - zaten amaç da budur.
- Sprint değerlendirmesi. Her sprintin sonunda, müşteri yapılan çalışmaları gözden geçirir.
Belirli bir kapsamı yok, ancak çerçeveler mevcut
Standart bir sözleşmeye kıyasla en önemli fark: katı bir kapsam olmaması. Bu durum bazı müşterileri tedirgin ediyor, çünkü o zaman nerede durduğunuzu nasıl bileceksiniz? Cevap çerçevede yatıyor.
- Bütçe çerçevesi. Sabit bir ücret üzerinden maksimum tutar veya sprint sayısı. Bütçe tükendiği anda, müşteri uzatma kararı verir.
- Zaman Çerçevesi. Tahmini bir bitiş tarihi veya sprint sayısı; zaman kısıtlaması olması durumunda (kalite değil) kapsamın ayarlanacağı konusunda anlaşma sağlanmıştır.
- Minimum gereksinimler. Bazen, müşterinin tamamlanmamış bir ürünle kalmaması için mutlaka dahil edilmesi gereken işlevlerin bir listesi - minimum uygulanabilir ürün - şeklinde olabilir.
Bu sayede, çevik metodolojinin esnekliğini korurken, açık çek imzalamak zorunda kalmazsınız.
Sprint başına kabul sayısı
Sabit fiyatlı bir sözleşmede, ürünün tamamını sonunda bir kerede kabul edersiniz. Çevik yöntemle ise her sprint için ayrı ayrı onay verirsiniz. Bu, riski azaltır: sorunları aylarca beklemek yerine erken keşfedersiniz.
Sözleşmede "kabul edildi"nin ne anlama geldiğini belirtin. Genellikle: teslim edilen işlevsellik, her sprint için önceden kararlaştırılan kabul kriterlerini ( "tamamlanma tanımı") karşılar. Ayrıca bir yanıt süresi belirleyin; örneğin, müşteri on iş günü içinde yanıt vermezse işin kabul edilmiş sayılacağı gibi. Böyle bir süre olmadan, bir proje süresiz olarak askıda kalabilir.
IP, ek çalışma ve çıkış
Sözleşmenin çok yetersiz olması durumunda sıklıkla ortaya çıkan üç sorun:
- Fikri Mülkiyet (IP). Özel yazılımların telif hakkı, otomatik olarak müşteriye değil, yaratıcısına (tedarikçiye) aittir. Müşteri hakları edinmek istiyorsa, bu sözleşmede açıkça belirtilmelidir. Ayrıca, tedarikçiden gelen açık kaynaklı bileşenlere ve mevcut yapı taşlarına da dikkat edin; bunlar için genellikle yalnızca lisans verilir.
- Ek çalışma. Kapsam değiştiği için, "sıradan" ayarlamalar ile gerçek ek çalışma arasındaki çizgiyi tanımlamak zordur. Bütçe çerçevesindeki çalışmaların normal şekilde devam etmesi ve sprint uzatmalarının veya ek bütçenin önceden yazılı olarak onaylanması konusunda mutabık kalınmalıdır.
- Çıkış. Projeyi yarıda kesebileceğiniz için, çıkış düzenlemesi çok önemlidir: bildirim süresi, mevcut sprintin tamamlanması, kaynak kodunun ve dokümantasyonun devredilmesi ve o ana kadar teslim edilen iş için ödeme yapılması.
Hangi projeler için uygundur?
Çevik yöntem, gereksinimlerin süreç içinde netleştiği projeler için uygundur: yeni bir platform, kullanımı henüz kesinleşmemiş bir uygulama veya değişen pazara uyum sağlayan bir yazılım. Sabit gereksinimlere sahip, sıkı bir şekilde tanımlanmış bir görev için (basit bir entegrasyon veya standart bir web sitesi gibi), sabit fiyatlı bir sözleşme genellikle daha basittir.
Örnek: Küçük ve orta ölçekli bir toptancı, müşterileri için bir sipariş kontrol paneli istiyor. Tam özellikler, müşterilerin bunu nasıl kullanacağına bağlıdır. Çevik bir anlaşmayla, tedarikçi önce sipariş sürecini oluşturur, toptancı bunu inceler ve ardından raporlama veya envanter analizinin bir sonraki sprint için değer olup olmadığına karar verir. Bütçe sekiz sprint ile sınırlıdır.
Dürüst tavsiye
Esnekliğe ihtiyacınız varsa ve müşteri olarak aktif katkıda bulunmaya istekliyseniz, çevik yazılım geliştirme sözleşmesi doğru seçimdir. Bütçe ve zaman çizelgeleri, sprint kabulü, fikri mülkiyet devri ve çıkış stratejisinin yazılı olarak belirtildiğinden emin olun; çünkü kapsam kasıtlı olarak açık bırakılmıştır.
Küçük, net tanımlanmış ve sabit gereksinimlere sahip bir projeniz varsa, avukata veya çevik bir sözleşmeye ihtiyacınız yok; basit bir sabit fiyat modeli yeterli olacaktır. Fikri mülkiyet, ek işler veya çıkış konusunda şüpheleriniz varsa veya önemli bir bütçe söz konusuysa, sözleşmeyi bir kez gözden geçirin. Bu, üzerinde anlaşılan hususlar konusunda bir görüş ayrılığı ortaya çıktığı anda kendini amorti edecektir.
Daha fazla bilgi edinmek veya bir sözleşme hazırlatmak mı istiyorsunuz? Çevik yazılım geliştirme sözleşmesini inceleyin, böyle bir sözleşmenin nasıl hazırlanacağını ve hazırlanmasının maliyetini okuyun .
Sıkça Sorulan Sorular
Çevik metodoloji (Scrum, sprintler) kullanılarak yapılan yazılım geliştirme sözleşmesi; kapsamın önceden belirlenmediği bir sözleşmedir. Sabit bir fiyata tek bir nihai ürün yerine, metodolojiyi, bütçeyi, zaman çerçevelerini ve her sprint için kabul edilebilirliği siz tanımlarsınız.
Sabit fiyatlı bir sözleşmede, kapsam, fiyat ve bitiş tarihi önceden belirlenir ve tüm ürünü bir kez kabul edersiniz. Çevik yöntemde ise kapsam gelişir, bütçe çerçevesinde sprint başına veya saat başına ödeme yaparsınız ve sprintleri tek tek kabul edersiniz. Geliştirme sırasında gereksinimler daha da katılaştığında çevik yöntem uygundur.
Her sprintin sonunda, müşteri önceden kararlaştırılmış kabul kriterlerine (tamamlanma tanımı) göre teslim edilen işlevselliği değerlendirir. Projenin aksamamasını sağlamak için, örneğin on iş günü içinde yanıt alınmazsa onay verilmesi gibi bir yanıt süresi belirleyin.
Özel yazılımların telif hakkı, yaratıcısına, yani tedarikçiye aittir. Müşteri hakları devralmak isterse, bu sözleşmede açıkça belirtilmelidir. Tedarikçiden alınan açık kaynaklı ve mevcut yapı taşları için müşteri genellikle yalnızca lisans alır.
Çerçeveler üzerinde anlaşarak: maksimum bütçe veya sabit sayıda sprint, zaman kısıtlıysa kapsamdan (kaliteden değil) ödün verilebilecek gösterge niteliğinde bir zaman dilimi ve isteğe bağlı olarak minimum işlevsellik listesi belirleyebilirsiniz. Bu şekilde, sınırsız maliyetlere katlanmadan esnekliği koruyabilirsiniz.
Evet, sözleşmede çıkış düzenlemesi yer alıyorsa: ihbar süresi, mevcut sprintin tamamlanması, kaynak kodunun ve dokümantasyonun devri ve teslim edilen iş için ödeme. Çevik yöntemle adım adım çalıştığınız için, doğru şekilde düzenlendiği takdirde, sabit fiyatlı bir sözleşmeye göre durmak daha kolaydır.
Gereksinimlerin süreç içinde netleştiği projeler için, örneğin yeni bir platform veya kullanım şekli henüz kesinleşmemiş bir uygulama için, genellikle sabit fiyatlı bir sözleşme daha pratiktir. Sıkıca tanımlanmış, küçük ve sabit gereksinimlere sahip projeler için de bu yöntem uygundur.
