Hirdetés

  2. Fórumok
  3. Szoftverfejlesztés
  4. Programozás topic
  5. (kiemelt téma)
Keresés

Új hozzászólás Aktív témák

  • #17127 Drizzt nagyúr coco2 #17123
    Új Válasz #17127
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    Drizzt

    nagyúr

    válasz coco2 #17123 üzenetére

    "Szóval jön az ügyfél a kész munka után, és 20ezer számra sorolja, hogy de ezt ő nem így gondolta, meg azt nem úgy mondta, meg hogy de hiszen egyértelmű volt hogyan kellett volna csinálni, és társai. Gyakorlatilag a beleidet kidolgoztad a lehetetlen határidő tartására, elméletben viszont kárt okoztál a cégnek a "hozzá nem értéseddel", mert semmit sem csináltál meg "úgy, ahogyan az ügyfél kérte", csak "elpocsékoltad az időt"."

    Nem így kell ezt elképzelni. Ez nem azt jelenti, hogy a határidőkor látja először a business azt, hogy mi készül el, hanem első adandó alkalommal. Pl. egy hónapos határidő esetén már az első héten lehet neki mutatni valamit, s onnantól ki fog derülni, hogy tényleg ezt az irányt kell-e csinálni. Ilyenkor még teljesen más irányba is el lehet menni, bőven van idő. Nyilván ehhez partner kell, hogy legyen a business is. A business meg örül, hogy olyan kérdések merülnek fel minél hamarabb, amik az ő fejében magától meg sem fordultak volna.
    Visszatérve a #17116-os kérdésre:
    "Csak hogy értsétek, nálunk vannak olyan emberek, akiknek a feladata az lenne, hogy az ügyfél ötleteit átfordítja nekünk, ami alapján tudnánk becslést adni, de amit én kapok abba kb több a kép, mint a normális leírás, szóval pl egy számlázó programanàl annyi lenne leírva, hogy készít egy számlát a számla gomb, de hogy mit ellenőriz, hogy számoljon stb azt nem írják le. Szóval több a kérdés utána mint a válasz. Jó lenne megreformàlni, de nem tudom hogy lenne ez a legjobb."
    Erre agile képzéseken azt szokták javasolni, hogy legyen valamilyen definition of ready. Azaz meg kell határozni, hogy milyen feltételek esetén van tényleg olyan állapotban egy task, hogy el lehessen rajta kezdeni a munkát. Ha nem elég jó a kidolgozás ahhoz, hogy becsülni lehessen, akkor meg kell mondani, hogy csak nagy szórással tudsz becsülni rá, vagy még egyenesebb, ha tényleg megmondod, hogy ezen infók alapján nem tudsz rá egyáltalán becsülni. Másik agile-os módszer, hogy egy spike-ot csinál rá az ember, ami arról szól, hogy feltérképezitek, hogy mit is kell csinálni valójában. Ha azt gondolod, hogy valami szerinted nem becsülhető/elkezdhető állapotban van, akkor azzal kell beszélned, aki azt gondolta, hogy abban van. Elmondani, hogy szerinted miért nem elég az infó.

  • #17124 emvy félisten coco2 #17123
    Új Válasz #17124
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    emvy

    félisten

    válasz coco2 #17123 üzenetére

    Pont ilyen szituaciokra valo az 'agilis' fejlesztes, aminek nem az a lenyege, hogy standup van, meg sprint planning, hanem az, hogy vegig tisztaban vagyunk azzal, hogy a fejlesztok es a kliens fejeben nem pont ugyanaz van, es pont emiatt folyamatosan konzultalunk az ugyfellel, hogy ne a vegen deruljon ki, hogy rossz iranyba mentunk.

Új hozzászólás Aktív témák