Vízesés vagy agilis rímel inkább a webes projektekre? Mikor válts?
Vízesés vagy agilis módszertant használtok?
Vagyis előre jól lespecifikáljátok a projekteket és aztán úgy effektíve egy az egyben elkészítitek? Vagy inkább csak a bétát készítetek el papír szerint aztán folyamatosan, 2-4 hetente fejlesztetek hozzá mindig, és erről rész megállapodások születnek?
Tudom, hogy kisebb projekteknél érdemes nyílván lespecifikálni és elkészíteni egy az egyben, nagyobb projectek esetében, pedig inkább béta és azt fejlesztjük továb. De szerinted, hol a határ mikor érdemes váltani? Egyáltalán mi alapján döntessz/nél módszertan mellett és honnan tudod, hogy jól döntöttél?:-)
■ Vagyis előre jól lespecifikáljátok a projekteket és aztán úgy effektíve egy az egyben elkészítitek? Vagy inkább csak a bétát készítetek el papír szerint aztán folyamatosan, 2-4 hetente fejlesztetek hozzá mindig, és erről rész megállapodások születnek?
Tudom, hogy kisebb projekteknél érdemes nyílván lespecifikálni és elkészíteni egy az egyben, nagyobb projectek esetében, pedig inkább béta és azt fejlesztjük továb. De szerinted, hol a határ mikor érdemes váltani? Egyáltalán mi alapján döntessz/nél módszertan mellett és honnan tudod, hogy jól döntöttél?:-)
Webes projekteknél egy előre
A magam részéről kb 60-70% spec a többi meg menet közben alakul mind saját mind külsős projektek esetén.
A nagyobb és kisebb meg nagyon relatív. Mondjuk valami amit le tudok programozni 1 nap alatt az kb 8 perc specifikációt igényel.
Üzleti modell
És mennyibe fog kerülni a projekt?
Mert erre csak az a válasz létezik szerintem, hogy megeggyezhetünk egy x összegben lefejelesztünk egy bétát, aztán onnantól a fejlesztések x órát vesznek igénybe.
Ennek viszont az a hátránya, hogy a cégvezetők nem igazán szeretik az ilyen bizonytalan költségeket, arról nem is beszélve, hogy az órabérbe dolgoztat és nem tudja ellenőrizni effektíve mennyi a valós ideje egy fejlesztésnek mivel nem ért hozzá.
Cégvezetők
Ha azt mondom neked, hogy kell egy autó, aminek legyen 1.4-es motorja, és négy kereke, és mennyibe kerül, arra mit mondasz? :)
Az árajánlat mindig egy nehéz
Kíváncsi vagyok arra, hogy
Ez reális probléma? A
hányat írtál már eddig?
Mire válaszoltál? Én nem azt
???
A specifikáció. Talán ott van
Igen, ritkán van, hogy az
„és ugye azért nem kell
Ezt majd a szerződés eldönti.
???
Hát nehéz, ez itt most
(Egyébként a 7-es hsz-t én nem úgy parafrazálnám, hogy "ok, csak piszkosul nehéz ilyet készíteni", de most ez lényegtelen.???)
Tehát még egyszer, amikor én
Érthető-e már?
nem
Kér a user egy X funkciót. Te értesz alatta X1-et (mert tudod, hogy X-et általában így oldják meg), pedig ő X2-re gondolt (mert ő máshol épp ilyen formában találkozott vele). Ajánlatot adsz X1-re, aztán már menet közben jön elő, hogy ő X2-t szeretne (ami mondjuk több idő elkészíteni). Erről beszélt Tolmi. Hogyan véded ezt ki "korrekt" ajánlattal, hogy ha azt nem előzi meg egy kellően részletes követelmény specifikáció? És ilyenek elég gyakran elő tundak fordulni még akkor is, ha elég komoly munkát öltek bele az igényfelmérésbe.
Eredeti kérdésre nem válaszoltál.
Hát ha én ajánlatot adok
A "korrekt" szót immár másodszor, idézőjellel használod, én nem használtam, ez elírás, ugye?
Az X1 az egy konkrét (és persze "korrekt") ajánlat. Ha ő fejlesztés közben X2-vel hozakodik elő, akkor, mint a 4-es hozzászólásban rrd írja, meg kell állapodni, az egy szerződésen kívüli helyzet. A specifikáció azért van, hogy tisztázza a fejlesztő felelősségi körét, és ahhoz mérten kell konkrétnak is lennie. Specifikáción kívüli paraméterekért a fejlesztőt nem terheli felelősség, tehát az nem az ő problémája.
Milyen eredeti kérdésre nem válaszoltam?
más domainben mozogtok
Ritkább eset: volt szerencsém nemrégi egy pakisztáni outsource cucchoz, jó párszor visszadobtuk a cuccot, mert tök alap (számomra) hibák voltak benne, átláthatatlan vacak volt az egész kód. Nem hiszem, hogy ilyesmi pontok bekerülnek az ajánlatba, de ha épp hozzáértő a megrendelő, akkor ebből is lehetnek gondok.
Nem, te X-re adsz
Ok, tehát az előbb az „Ajánlatot adsz X1-re” is elírás volt (nem volt evidens).
Szerintem itt ilyenkor általában valakinek egyértelműen igaza van, és az nagy valószínűséggel te vagy, mert te szakértő vagy, és jobban ismered, mi a szakmában a "common sense".
Ez azért egy kicsit más eset, itt két programozó ad-vesz kódot, és minőségbeli elvárások vannak. Azokat tényleg nem lehet ajánlatba írni. Ilyenbe én is belefutottam, és kényes helyzet is keletkezett, de még mindig világosan eldönthető volt, kinek mi a felelőssége.
De egyébként ilyen konfliktusok, értelmezési problémák nyilvánvalóan előfordulhatnak, mint mindenhol, a jogban is, ezt én nem vitatom. A 6-os hozzászólásomat tessék az 5-ösre adott válaszként értelmezni, ahol egyértelmű, hogy mi mit jelent. Tehát igazából egyetértünk, azt leszámítva, hogy amit ti problémának tekintetek, azt én nem, de lehet, hogy csak a wannabe ügyvéd beszél belőlem, vagy túl optimista vagyok. És még egyszer, nem is az a jellemző, hogy az ügyfél nem specifikált paramétereket kér számon, hanem sokkal többet számít neki a hibátlanság. A hiba meg ugye nem paraméter. A pakisztáni eseted jól mutatja, hogy az igazi probléma, hogy két szakmabeli közt nehezebb eldönteni, hogy mi a hiba. (Mert ami neked alaphiba volt, az neki működött.) Ez egy fejlesztő és egy nem fejlesztő közt nem kérdés (valami vagy működik, vagy nem).
Rengeteget.
x -> x1
Kiváncsi vagyok működik-e másnál is?
Példával mondom talán könnyebb, mondjuk egy közösségi oldal, amit elkészítesz az ügyfélnek alapdolgokat tudja híreket kezeljen, statikus tartalmak, admin editor,alap design király:-)
Ezzel már az ügyfél el tud indulni. Ezt a megoldást szállítod neki x összegért.
Ezt követően már ős is látja milyen lehetőségek vannak a rendszerben és így 2-3 hetente fejlesztgetni kezditek folyamatosan a rendszert.
Ezzel ő nyer mivel azt a kapja, amit akar amiért fizet és csak kisebb összegekben nyúl mellé.
Te nyersz mert elégedettebb ügyfelet kapsz, 2-3 hetente előre tudsz tervezni ÉS az egyedi fejlesztések díját jól megemelheted és az ügyfélnek még mindig jobb így, ha többet is fizet a legvégén, mivel a rendszer már közben dolgozik neki és termeli a hasznot.:-)
Na ez szerintem működik bár csak fél éve alkalmazom, ti próbáltátok?
Jó tudom kell hozzá egy jó értékesítői véna is azért:-)
Attól függ, milyen ügyféllel
Ha viszont gond van, pl betörnek a szerverre akkor te vagy a hibás. Szóval abból kiindulni, hogy a megrendelőnek mennyire tetszenek a funkciók nem feltétlenül elegendő.