[Javalist] RegExp probléma: nem aposztrófok közé zártak felismerése

[Tamás Viktor]

"nem érdekli (és nem is kell érdekelje) az ügyfelet,"
Láttam pár projektet emiatt földbe állni.

Fel kell mérni az ügyfél igényeit. Ehhez nem feltétlenül kell "odamenni" és
"megkérdezni", (mert lehet megfigyelni és mérni is - lean) de legtöbb
esetben nem árt a kétirányú egészséges kommunikáció. Sőt:

Scrum-nál egyenesen az a szokás, hogy az ügyfél beültet egy embert a
fejlesztőcsapat közelébe, hogy bármikor elérhető legyen, ha kérdés van. Ez
elég jól működik, az ő neve a Product Owner.



2013/12/10 Ákos Gábriel <akos.gabriel at i-logic.hu>

> Ez az ami rohadtul nem érdekli (és nem is kell érdekelje) az ügyfelet,
> megrendelőként komolytalan cégnek gondolnám aki ilyen döntést akar
> meghozatni velem.
> Úgy érezném, hogy rám akarja tolni a döntés felelősségét.
>
> Hozza meg a döntést ő, viselje ennek következményeit.
>
> Üdv,
> Ákos
>
> 2013.12.10. dátummal, 8:52 időpontban Tamás Viktor <viktor.tamas at gmail.com>
> írta:
>
> Nem kell hogy az ügyfél explicit ,meghatározzon technológiát.
> Új keretrendszereket több időbe (=pénzbe) telhet megtanulni (neadjisten
> lefejleszteni), de van az a helyzet amikor mégis érdemes belevágni. De nem
> jó, ha ezt a fejlesztők döntik el egyedül.
> Van amelyik keretrendszer vagy technológia bizonyos feladatokra
> optimálisabb.
> Beszélhetnék még a nyílt forráskódú vagy fizetős komponensekről. Nyílt
> forráskódon belül a GPL-ről...
>
> Ha azért hoz be valaki új technológiát mert érdekesnek, trendinek tartja,
> meg akarja tanulni, az gáz.
>
> Példa, webes technológiáknál egy bizonyos feladatra Javascript, Sencha
> lenne optimális, mert gyors válaszidőket ad és kevés terhelést tesz a
> szerverre, tehát jól skálázható. De meg kellene tanítani minden fejlesztőt
> rendesen Javascriptben programozni, ami elég sokba kerül, vagy
> fogalmazhatnék úgy, hogy kezdetben nagyon lassú lesz a fejlesztés. Java-ban
> mindenki tud programozni az adott cégben, Wicket-et megtanítani sokkal
> kisebb erőfeszítés, de ez nagyobb terhelést tesz a szerverre, tehát nem
> lesz annyira skálázható. Valakinek ezt esetleg meg kell beszélnie az
> ügyféllel, hogy mi neki a fontosabb, megér-e neki több pénzt az
> optimálisabb megoldás, vagy nem érdekli ez az aspektus. A végén ebből lesz
> a technológiai döntés, üzleti alapokkal.
>
>
> 2013/12/9 Böszörményi Péter <zmblevlist at gmail.com>
>
>> Ostoba vagyok. Nagyon. Kerlek magyarazd el. Ertem, hogy esetleg a
>> kuncsaft meghatarozhat egy technologiat (mar pedig en hibernatet
>> akarok latni a rendszerben, es kesz!), de ugy gondolod, hogyha a
>> kumcsaft nem hataroz meg kifejezett kovetelmenyeket ezzel
>> kapcsolatban, akkor oda kell menni hozza, es megkerdezni: Tessek
>> mondani, mit hasznaljunk? Spring MVC, vagy JSF?
>>
>> 2013/12/9 Peter Verhas <peter.verhas at gmail.com>:
>> > Ennyi.
>> >
>> >
>> >
>> > On H, dec. 9, 2013 at 3:13 du., Tamás Viktor
>> > <viktor.tamas at gmail.com="mailto:viktor.tamas at gmail.com">> wrote:
>> >>
>> >> Profit-orientált környezetben, végső soron minden technológiai
>> döntésnek
>> >> is üzleti okai kell hogy legyenek.
>> >>
>> >>
>> >
>> > _______________________________________________
>> > Javalist mailing list
>> > Javalist at lists.javaforum.hu
>> > http://lists.javaforum.hu/mailman/listinfo/javalist
>> >
>>
>>
>>
>> --
>> Üdvözlettel,
>> Böszörményi Péter
>> _______________________________________________
>> Javalist mailing list
>> Javalist at lists.javaforum.hu
>> http://lists.javaforum.hu/mailman/listinfo/javalist
>>
>
> _______________________________________________
> Javalist mailing list
> Javalist at lists.javaforum.hu
> http://lists.javaforum.hu/mailman/listinfo/javalist
>
>
>
> _______________________________________________
> Javalist mailing list
> Javalist at lists.javaforum.hu
> http://lists.javaforum.hu/mailman/listinfo/javalist
>
>
--------- következő rész ---------
Egy csatolt HTML állomány át lett konvertálva...
URL: <http://lists.javaforum.hu/pipermail/javalist/attachments/20131210/82fb7b6a/attachment.html>