HTML

ITÉlet

Egy multinacionális cégnél dolgozó informatikai manager szakmai blogja. Észrevételek, tapasztalatok szoftver fejlesztésről, vezetésről, managementről és hatékonyságról itthoni és külföldi példákon keresztül. Az informatikáról másképp...

Utolsó kommentek

  • 232323: Szóval managernek jó lenni, akkor dől a nagy lé, felelősség meg számonkérés sehol. Krém. (2019.10.31. 15:24) Kirúgják-e a menedzsert ha hibázik?
  • Simon Géza: "A következő forradalmi áttörés, nagy dobás, ami megint tőzsdei felfutáshoz vezet, az nem valamilyen informatikai dolog lesz, hanem egészen más." Ha a generic AI nem informatikai, akkor igazad van.... (2018.02.19. 07:01) Az IT jövője
  • pggp: @AnyTink: Köszi, de én csak egy blog olvasó vagyok, aki jól tudja használni a keresőt ;-) (2017.10.17. 07:19) Milyen volt hazaköltözni?
  • AnyTink: @pggp: :) Gratulálok a család bővüléséhez és a sikeres 'hazatelepedéshez'. Mi most gondolkodunk a hazaköltözésen és jó olvasni mások élményéről! Köszönöm az írásod :) (2017.10.16. 18:49) Milyen volt hazaköltözni?
  • pggp: Tulajdonképpen igen, alakult valami: akocsis.com "2017 április, Dália eloször Szentesen" ;-) (2017.06.06. 21:51) Milyen volt hazaköltözni?
  • Utolsó 20

Alapvető különbségek az elmélet és a gyakorlat között.

Alapvető különbségek az elmélet és a gyakorlat között.

A különféle szoftverfejlesztési módszertanok célja az, hogy keretet adjanak a szoftverfejlesztésnek, a szoftverfejlesztés „mérnöki” oldalának. A módszertani keret egyszerű folyamatokra és lépésekre bontja a munkát, amit a programozók könnyedén elsajátíthatnak és követhetnek a szoftverfejlesztés során.

A módszertanok kizárólag azzal a tankönyvszagú feltételezéssel indítanak, hogy van az ügyfél és van a szoftverfejlesztő. Az ügyfél valamilyen új funkciót akar, a szoftverfejlesztő pedig a módszertant követve megvalósítja azt.

Ez így elméletben, tankönyvben, a táblára felrajzolva egyszerű és világos.

A hiba ott van, hogy a világ már nem ilyen. 10-15 évvel ezelőtt ilyen volt, de azóta sok idő telt el, sok változás történt. Manapság már nem esik be az utcáról az „ügyfél”, hogy szüksége lenne egy könyvelési szoftverre, vagy hogy fejlesszünk ki egy egyedi nyilvántartási rendszert.
A fejlesztési folyamat sem kétszereplős, hanem további szereplők jelentek meg: projektvezetők, auditorok, üzemeltetési osztály, PMO, minőségbiztosítás, Enterprise Architect, beszerzés, sőt ott van a jogi osztály is.

Az nem változott, hogy a történet két legfontosabb szereplője továbbra is az ügyfél és a programozó, viszont a többi szereplő befolyása a szoftverfejlesztésre nagyobb lett, olyannyira, hogy képesek azt akár teljesen megváltoztatni.

Mondok erre a változásra egy példát!
Az Enron gigacsődjére válaszol az amerikai felügyeletek kidolgozták a SOX előírást. A SOX alapvetően nem informatikai előírás, viszont indirekt módon óriási hatása van a szoftverfejlesztésre. A tőzsdén szereplő cégek ugyanis nem kezelhetik szoftvereik és adatbázisaikat akárhogyan, hanem csak úgy, hogy az adatok helyessége és hitelessége bizonyítható legyen. Különben a könyvelés nem tekinthető megbízhatónak, a tőzsdei jelentés nem megbízható – és a cég nem szerepelhet a tőzsdén.
Vagyis: szoftvert nem lehet akárhogyan fejleszteni. A szoftverfejlesztés többé nem a programozó magánügye.

Fontos változás, hogy míg 10-15 éve a technológiai kérdések jelentették a programozás kihívásait (a projekt akkor indult el, ha műszakilag megvalósítható volt), addig ma már az üzleti érték (a projekt akkor indul el, ha megfelelő a ROI).

A ROI említésével átléptünk a pénzügyi területre, és ha már itt vagyunk, nem árt jobban szétnézni. Változott-e a szoftverfejlesztések pénzügyi kerete? Nagyon is sokat!

Az informatika aranykorában, amikor a fejlesztési módszertanok születtek, a pénz gyakorlatilag számolatlanul ömlött az iparágba – az ügyfelek bármit, bármilyen rossz szoftvert is kifizettek, hiszen az még mindig jobb volt, mint ceruzával kockás füzetbe dolgozni.
Innen nagyot fordult a világ. Ahogyan az IT kezdett csodavilág helyett egyre inkább betagozódni a hagyományos iparágak közé, az IT szolgáltatások pedig megtalálták a helyüket a többi vállalati szolgáltatás mellett, a pénzcsapot is elzárták. Ma már nem lehet akármilyen szoftvert eladni, és a jól fizető IT-s álláshoz nem elég, ha elolvasunk 2 könyvet a JAVA programozásról.
Manapság már minden egyes IT fejlesztésért meg kell harcolni, számszerűleg be kell bizonyítani, hogy megéri azt a befektetést. Mivel pénz nélkül nincs fejlesztés, ezért a szoftverfejlesztés alkalmazkodni kénytelen ezekhez a keretekhez és kényszerekhez.

Rámutatnék a kontrasztokra:
A 20. században alkotott fejlesztési módszertanok célja az volt, hogy a szoftverfejlesztési káoszból rendet teremtsenek, és hogy az IT irányt mutasson.
A 21. században azonban a szoftver fejlesztésnek a körülményekhez való alkalmazkodás jelenti a kihívásokat, az IT vezető szerepből kiszolgáló/támogató szerepbe került, és emiatt a 20. századi módszerek egyre jobban döcögnek.

Most egy vargabetűvel visszatérnék a cikk elején említett szoftverfejlesztési alaphelyzethez – amiről a tankönyvek és a módszertanok hibásan azt írják, hogy az ügyféllel és a fejlesztési igénnyel kezdődik. Nem, a szoftverfejlesztés nem itt kezdődik, hanem sokkal hamarabb, és megpróbálom összeszedni a tipikus alapeseteket:

Megrendelő + kkv beszállító

Klasszikus alaphelyzet: a megrendelőnek (tipikusan multi vagy állami cég) szüksége van egy új szoftverre és/vagy új funkcióra. Ehhez megtalálta a kkv informatikai céget, mint beszállítót.
Együttműködésük a beszerzési folyamattal kezdődik, majd a sikeres tender után jön a szerződéskötés, na és ekkor kezdődhet el a tényleges műszaki munka.
Fontos észrevenni, hogy mire a programozók a feladat közelbe kerülnek, addigra a játékszabályokat kőbe vésték (a pályázat és a szerződés megírásakor).


Alapvető eltérés az elméleti modellhez képest:
- Van egy pre-sales folyamat, ami ugyan nem szoftverfejlesztés, de meghatározza azt. Célszerű lenne az elméleti modellekbe ezt is beépíteni, illetve a programozókat erre megtanítani.
- Amikor a tényleges munka elkezdődik, akkor nem csak az ügyfél, a programozó és a követelmények jelentik a kiindulási alapot, hanem létezik egy „megállapodás” a munka körülményeit illetően (szerződés, pályázati anyag, elkötelezettségek, feltételrendszer, stb). A programozónak tudnia kell e megállapodás mentén haladva dolgozni, jó lenne, ha a felsőoktatási rendszer erre felkészítené őket.

Outsourcing

Tipikusan egy nagyvállalat (vagy állami cég) megállapodása egy nagy IT szolgáltatóval, ahol is az IT szolgáltató egy keretmegállapodáson keresztül végez szoftverfejlesztési feladatokat partnerének. Sok projektről, sok csapatról, sok ügyfélről és sok programozóról beszélünk. Tipikusan az ügyfelek és a programozók földrajzilag egymástól távol vannak.

Alapvető eltérések az elméleti modellhez képest:
- Az ügyfél és a programozók közötti kommunikációs kihívások – amit jó lenne a programozóknak megtanítani, és módszertan szintjén kezelni.
- Kulturális különbségek. Szerencsére a felsőoktatási intézmények maguk is multikulturális együttműködésekre törekednek. A módszertanoknak olyan eljárásokat kell javasolniuk, amik alkalmasak különböző kulturális háttérből érkező csapattagok együttműködésére.
- Egy nagy szervezet dolgozik együtt egy másikkal, ahol folyamatok, policy-k és KPI-ok vannak. A programozó idejének nagyobb részét adminisztráció fogja jelenteni. Hasznos lenne ezeket már az iskolapadban megismerni (industry best practice).
- Módszertani változás, hogy a két fő szereplőn kívül megnövekszik a QA és az audit szerepe – gyakorlatilag az ő igényeik is legalább olyan fontosak, mint az ügyfélé.
- Szétválik az üzemeltetés és a fejlesztés – az Üzemeltetés is egy ügyfél, és beleszólásuk van a fejlesztésbe.

Belső fejlesztés

A programozó és az ügyfél is ugyanazon cég alkalmazottai, ugyanazon a lokáción vannak. Sok egymást követő, gyakorlatilag folyamatos fejlesztési munkáról van szó. A programozó és a felhasználók egyenrangúak, sőt a programozóval szemben elvárás, hogy ismerje az üzleti oldalt, beszélje annak nyelvét, sőt tanácsot tudjon adni üzleti problémák megoldására.

Alapvető eltérések az elméleti modellhez képest:
- A fejlesztés célja nem a műszaki tökéletesség, hanem az üzleti érték, üzleti előny megteremtése. Érdemes lenne ezt a szemléletet az egyetemen bemutatni, illetve módszertan szintjén kimondani.
- A fejlesztés folyamatos és hosszútávú, ezért a fontos szempont a fenntarthatóság, az üzemeltethetőség és a továbbfejleszthetőség. Módszertan szintjén kellene ezekkel foglalkozni.
- A fejlesztő aktívan részt vesz az igények azonosításában, kvázi tanácsadóként dolgozik.
- A folyamatos fejlesztés azt jelenti, hogy egy cégtelen ciklusban pörgünk: amint lezárul az előző fejlesztés, kezdődik a másik.

Kutatás-fejlesztés, termék fejlesztés

A fejlesztő nem szolgáltatást nyújt az üzlet részére, hanem terméket fejleszt, amit a cég aztán eladhat ügyfeleinek. Olyan megoldásokat, technikákat kell alkalmazni és kitalálni, amit esetleg előtte még senki más nem tett. Lehet, hogy a megoldás nem lesz teljesen bolondbiztos, de fontos hogy minél hamarabb elkészüljön, és az ügyelek számára előnyös legyen, ami előny miatt a terméket megveszik.

Alapvető eltérések az elméleti modellhez képest:
- Time-to-market mint cél.
- Adminisztráció helyett műszaki megoldások.
- Az tényleges „ügyfél” nem egy konkrét személy, hanem egy piaci szegmens.

(Megjegyzem, hogy az esetek 90%-ában a szoftver szolgáltatás, és nem termék. Lásd „Software as a Service” koncepció. És a programozó nem terméket fejleszt, hanem szolgáltatást nyújt. Kivételek vannak, nagyon is sok.)

Az alapesetek taglalásánál elég jól látszik, hogy a szoftverfejlesztés sokszereplős, és az adott projekttől, az adott cégtől múlik, hogy a hangsúlyok hol vannak. Sajnos a módszertanok kizárólag a programozóval foglalkoznak, kizárólag az ő szemszögéből világítják meg a folyamatot. Ez még azokra az agilis módszertanokra is igaz, amelyek saját állításuk szerint ügyfélközpontúak. Mert ezeknek a fejlesztéseknek is a legnagyobb gátja maga az ügyfél…

És végezetül még egy, nem kevésbé fontos dolog. Vajon melyik fejlesztési módszertan indul ki abból, hogy egy projekt részeként projektmenedzser irányítása alatt, projektmenedzsment módszertant követve kell szoftvert fejleszteni?
Mert ez itt a 21. század, kéremszépen projektszerűen dolgozunk…

Címkék: elmélet gyakorlat módszertan

A bejegyzés trackback címe:

https://akocsis.blog.hu/api/trackback/id/tr385211501

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

Krisztian 2011.03.18. 21:58:27

"...A módszertanok kizárólag azzal a tankönyvszagú feltételezéssel indítanak, hogy van az ügyfél és van a szoftverfejlesztő. Az ügyfél valamilyen új funkciót akar, a szoftverfejlesztő pedig a módszertant követve megvalósítja azt... ...Ez így elméletben, tankönyvben, a táblára felrajzolva egyszerű és világos. A hiba ott van, hogy a világ már nem ilyen. 10-15 évvel ezelőtt ilyen volt, de azóta sok idő telt el, sok változás történt..." A vilag soha sem volt ilyen... :) Az ugyfel vagy tudja, hogy mit szeretne vagy nem... vagy tudja csak nem tudja elmondani... es ennek semmi koze semmilyen modszertanhoz... A modszertanok a legjobb eszkozok a munka latszatanak fentartasahoz... :)

harold 2011.04.03. 20:51:21

Ppffff.. Van egy olyan érzésem, hogy a tisztelt blog irója nem programozó és soha nem is programozott az általa leirt körülmények között. Ha a programozók ugy dolgoznának, ahogy az itt le van irva, akkor soha nem lenne kész semmi! "A programozó idejének nagyobb részét adminisztráció fogja jelenteni." - ilyet nem is tudom hogy lehet gondolni egyáltalán. Réges régen rosz lenne ha igy lenne! Maradok tisztelettel!

Ismeretlen_102125 2011.04.04. 09:46:51

Akkor feltennék egy kérdést. Van egy változáskérelem, valami nagyon egyszerű, max 5 perces munka, beszúrni 1 sort a kódba. Mivel a cég az amerikai tőzsdén szerepel, a fejlesztés meg kell hogy feleljen a SOX auditnak. Van PMO, az ő auditjának is. És van belső minőségbiztosítás, nekik is meg kell felelni. Ahhoz, hogy ez az 1 sor, max 5 perc változtatás élesbe kerüljön, hány dokumentumot kell írni és hány jóváhagyást kell kérni? Összesen az "5 perc munka" bruttó hány perc munka lesz? (megj: a szerző csapata 2010-ben 100%-ban megfelelt a különféle auditokon...)

Ismeretlen_102125 2011.04.04. 09:59:18

A kérdéshez kapcsolódó megjegyzés: azért az gondolom tiszta, hogy miért kell megfelelni az auditon: "Különben a könyvelés nem tekinthető megbízhatónak, a tőzsdei jelentés nem megbízható – és a cég nem szerepelhet a tőzsdén."

Viktor 2011.04.04. 19:58:07

"Összesen az "5 perc munka" bruttó hány perc munka lesz?" 1-2 nap. A két napban már benne van az élesítéssel kapcsolatos adminisztráció is :-) Persze ezeket meg lehet spórolni, ha kisebb cég vagyunk, vagy pl. egy startup, sőt ott kötelező is megspórolni, mert ott az ilyesmi káros is ( ezt nem fizeti ki senki ). De vannak helyek, ahol nem. Dolgoztam már mindkét típusú helyen. :-)

Viktor 2011.04.04. 20:02:10

"Vajon melyik fejlesztési módszertan indul ki abból, hogy egy projekt részeként projektmenedzser irányítása alatt, projektmenedzsment módszertant követve kell szoftvert fejleszteni?" valamilyen vízesés módszertanra gondolnék
süti beállítások módosítása