ÁghyBlog

Amikor múlt hónapban részt vettem az MVP Global Summit-on, próbáltam nem(csak) az élmény oldaláról megfogni a dolgot. Utazok tizenx órát, eljutok a “fellegvárba” - igen, ez nagy élmény, tényleg életreszóló. De azt gondolom, ha az ember MVP lesz, nem szabad hátrdőlnie és passzívan élvezni a kilátást, hanem üljön be a pilótafülkébe, és ad astra! MVP-ként ugyanis számos szakmai lehetőség nyílik meg előttünk: persze ezeket először is tudni kell észrevenni, mert nem maguktól kopogtatnak az ajtónkon. És ha észrevettük, elkezdhetünk élni velük - és itt most nem arra gondolok, hogy mekkora élmény például a TechNet csoporttal reggelizni, hanem arra, hogy ebből bizony kézzelfogható együttműködések is születhetnek: cikkírás, technical review, stb. Hasonló a Karthik Ravindrannal történő találkozásom, vagy a Product Group napi szintű “beszivárgása” az életembe az elmúlt hetek során.

Lehet persze, hogy “fiatal, dekoratív lányként” könnyű dolgom van. De én elsősorban nem női MVP-nek érzem magam, hanem SharePoint Server MVP-nek. Ezt erősíti bennem a többi SP MVP, a Product Group, stb. is. Ha sikerült eljutnod a pilótafülkéig, és Te vezeted a saját rakétádat, már csak egy dolog számít: jó irányba, megfelelő sebességgel haladsz-e. A szkafanderben úgysem látszik, ki vagy, csak az, mit csinálsz…

Na de visszatérve a TechNet rakétához. Kinti idő szerint péntek délután Rob Silver pulikálta SharePoint Governance cikkeit a TechNet-en:

“Governance is the set of policies, roles, responsibilities, and processes that you establish in your enterprise to guide, direct, and control how it uses technologies to accomplish business goals. To strike the right balance between the needs of the SharePoint users in your enterprise and the IT professionals who deploy and operate SharePoint Server, we recommend that you form a governance body that includes representatives of all stakeholders in the SharePoint deployment. This body can then create and enforce rules that govern the use of SharePoint.”

A sorozat négy cikkből áll, sorrendben a következők:

• What is governance?:  alapfogalmak, definíciók, s a két kulcs meghatározása: IT szolgáltatás és információ-architektúra.
• Establishing and governing a SharePoint service: ez a cikk leírja egy SharePoint-hostoló IT szolgáltatás tipikus felépítését, sikertényezőket határoz meg, és példaként bemutat egy háromrétegű szolgáltatást.
• Implementing and governing information architecture: meghatározza, mi az információ-architektúra, és egy esettanulmányon keresztül szemlélteti is azt.
• Governance features in Office SharePoint Server 2007: áttekintést nyújt számos MOSS 2007 szolgáltatásról, melyek megoldást kínálnak a fent meghatározott problémákra.

Összességében az mondható el Rob írásairól, hogy alapos, mélyen átgondolt cikkek, melyeket mindenképp érdemes elolvasni és megfontolni, ha az ember hasonló szakterületen mozog.

A Microsoft Magyarország új, intenzív képzéssorozatot indít jelenlegi és leendő architecktek, vezető fejlesztők számára, melynek célja az architekturális tudás megalapozása és kibővítése.

Az Architect Academy tervezett tematikája a következő:

• fejlesztési módszertanok és eszközök
• design patterns
• fejlesztőeszközök: alkalmazás-életciklus kezelés (ALM), TFS+VSTS+EPM (2 alkalom)
• alkalmazásplatform: .NET, WCF/WF/WPF/CS
• alkalmazásplatform: dinamikus rendszerek (DSI)
• alkalmazásplatform: alkalmazás-integráció, ESB/ISB
• alkalmazásplatform: SharePoint, OBA
• alkalmazásplatform: üzleti intelligencia (BI)
• felhasználói élmény (UX)

Jómagam abban a szerencsés helyzetben vagyok, hogy előadóként adhatom át tudásom legjavát a résztvevőknek. Valószínűleg nem meglepő, hogy a SharePoint + OBA témát kaptam a szervezőktől. A pontos részleteket még nem árulhatom el, de feszegetjük majd a SharePoint mint platform kérdéskörét, lesz szó Workflow-ról, InfoPath Forms Services-ről, BDC-ről, stb. - és természetesen OBÁról.

Várhatóan nagy lesz az érdeklődés, de még lehet jelentkezni.

Az OBA struktúrát sokan sokféleképpen értelmezik. Legegyszerűbben úgy lehet összefoglalni, hogy a meglévő, de testreszabott kliens alkalmazásokból, egy vagy több LOB (Line-of-Business) alkalmazásból, valamint egy köztes szerverből (többnyire MOSS) áll. Architekturális szempontból nagyrészt SOA megközelítésről van szó, ahol a kliensek és a háttér-rendszerek közé saját szolgáltatás-réte(ke)t építünk.

Az OBA Patternek célja, hogy architekturális segítséget adjon a tervezés és a fejlesztés során. Mindez nagyon fontos lehet számunkra, hiszen az OBA alkalmazások általában rendkívül összetettek, bonyolult háttér-architektúrával és kiforrott üzleti logikával. Itt is, mint oly sok területen rendkívüli hangsúlyt kap a tervezés, az architektúra megálmodása, kitalálása - hiszen ezen áll vagy bukik az alkalmazás későbbi sikere.

Steve Fox szerint hét különböző alap-patternt különböztetünk meg, melyek közül néhány tartalmaz sub-patterneket is. Az alábbi táblázat ezek rövidd összefoglalását tartalmazza: 

Ma este ritka alkalom volt: barátnőmmel (ő dupla kisgyermekes anyuka) koncertre mentünk, apukák otthon a gyerkőcökkel. Komolyzenét elég gyakran hallgatok, amikor dolgozom, ám egyáltalán nem vagyok műértőnek nevezhető - ellentétben a barátnőmmel. Az ellentétek ellenére mindketten élveztük a koncertet, de nálam (sajnos) előjött a szokásos reflex: ha komolyzene, akkor munka. Az agyam rögtön el is kezdett dolgozni: fejben összeraktam egy tréninganyagot, s gondolatban befejeztem egy cikket, melyet már másfél napja szerkesztek. Az a baj ilyenkor, hogy mennyiségileg (majdnem) kész lenne a cikk, ám nem érzem, hogy kerek, egész, így pedig nem szeretem publikálni. De most már legalább a fejemben megvan a vége is, ez nagy előrelépés ahhoz, hogy reggelre kint legyen (itt a titok: a Financial Services OBA Component Library II. részét írom).

A másik, amin elméláztam a koncert alatt, az a hangverseny és az IT projektek hasonlósága. Na ez is veszélyes, tudom… Talán pihennem kellene?… Szóval adott a zeneszerző, akit párhuzamba állíthatunk az architekttel: kitalál, megtervez, komponál valamit - amit ezután a zenekar eljátszik, a fejlesztőcsapat pedig megvalósít. Igen ám, de a zenekarnak ott a karmester - a fejlesztőknek pedig ott a projekt menedzser! És ami az egészet széppé teszi: a ma esti karmester jól láthatóan élvezte a koncertet! Amit ő maga vezényelt! Egyrészt irányította, vezényelte a zenészeket, másrészt a zene vezérelte őt magát!

Annyira szép volt…

Te mennyire élvezed a saját projektjeidet?… Csak vezényelsz, vagy magával ragad, és agilis módon reagálsz egy-egy elsietett vagy hamiskás(nak tűnő) hangra?…

Mindig is érdekes kérdés/probléma, ha az ügyfél számára nemcsak szállítanunk kell egy kész SharePoint-megoldást, hanem nulláról megtervezni s felépíteni is az architektúrát. Persze annak is megvannak a szépségei, ha egy már bevezetett szerverre/farmra kell újabb komponenseket készítenünk, de most nem erre szeretnék kitérni, hanem a teljesen zöldmezős projektekre.

Tegyük fel tehát, hogy az ügyfél még nem rendelkezik SharePointtal, s a mi feladatunk a fizikai és logikai architektúra megtervezése is.

Első lépés természetesen az üzleti igények felmérése: funkcionálisan mit szeretne az ügyfél. Mit szeretne most, s mik a tervei a jövőre nézve.

Emellett fontos a várható terhelést is figyelembe venni. Néhány példa:

• Telephelyek száma
• Felhasználók várható száma
• Intranetes vagy internetes környezet kiépítése a cél?
• Várható adatmennyiség (tárolt dokumentumok száma, átlagos mérete, stb.)
• Várható terhelés: elérés/nap, lekérések száma/látogatás, stb.
• A fenti (és egyéb) mutatók várható növekménye

Ezen adatok birtokában már elindulhatunk a tervezés útján. De vajon milyen eszközeink vannak, ha nem csupán “hasraütésszerűen” szeretnénk hardvereket vásárolni? Először is, a saját tapasztalat ebben az esetben is előnyt jelent. Ha van viszonyítási alapunk, sokat segíthet, egyrészt a tervezésben, másrészt a becslés pontosításában is.

Másodszor pedig rendelkezésünkre állnak különféle eszközök, melyek segítenek a döntésben. Nagyon fontos azonban arra figyelni, hogy ne alapozzunk döntéseket csakis és kizárólag ezen eszközök ajánlataira! Két ilyen “capacity planning” eszközt szeretnék megemlíteni:

• System Center Capacity Planner: https://connect.microsoft.com/programdetails.aspx?ProgramDetailsID=1602
• HP ProLiant Sizer for Microsoft Office SharePoint Server 2007: http://h71019.www7.hp.com/activeanswers/Secure/548230-0-0-0-121.html

Mindkét eszközről elmondható, hogy nagy segítség a becslés során, ám óvatosan kell bánni az általuk adott eredményekkel. A SCCP például mininálisan 2 db. Web Front-End szervert ajánl egy háttér SQL kiszolgálóval, sőt ami ennél is megrázóbb: a memóriaigény becslését nem végzi el, fix értékekkel dolgozik: SQL 16GB, WFE 8GB… Így például 1 felhasználós, minimális terhelésnek (10GB content database) kitett farm is 3 kiszolgálóból áll, 16GB illetve 8GB memóriával…

 Másik limit az eszköz béta verziójában, hogy 100e felhasználó és 2TB adatmennyiség jelenti a felső korlátot számára, ennél magasabb értékekkel nem tud számolni.

Így ha valóban éles becsléseket szeretnénk alapozni ezekre az eszközökre, nem árt odafigyelni. Egyrészt építeni korábbi tapasztalatainkra, másrészt összevetni a két eszköz értékeit egymással (lehetőség szerint harmadik, negyedik forrásból származó értékekkel/ajánlásokkal is). Eddigi tapasztalataink azt mutatják, hogy ezek az eszközök iránytűként szolgálhatnak, de térképet nem adnak a kezünkbe…

Office 2007 alatt valamennyi dokumentumtulajdonság megjeleníthető az úgynevezett Document Information Panelen (DIP), vagyis egy információs sávon pl. a Word fejlécében.

Ez a DIP tulajdonképpen egy InfoPath űrlap, amely szabadon módosítható, szerveroldalon, SharePoint alatt az egyes tartalomtípusokhoz rendelhető. Más lehet tehát az Information Panel egy szerződés, más egy ajánlat, ismét más egy specifikáció esetében…

Ez már önmagában is igen erős “fegyver” lehet a kezünkben, ám még ennél is tovább visz az út: a DIP több lapra is osztható, így nemcsak a szerver- és kliensoldali tulajdonságokat vehetjük külön lapra, s nemcsak módosíthatjuk ezeket. Arra is van lehetőségünk, hogy saját lapokat is definiáljunk…

A részletek bővebben itt, a SharePoint Klub cikkében olvashatók.

Érdekes, izgalmas fába vágtuk a fejszénket. Egy ingyenes online “iskolát” indítottunk, mellyel célunk a SharePoint 2007 lehetőségeinek és funkcionalitásának bemutatása. Innen a név is: MOSSkola.

A dolog lényege, hogy a beiratkozott MOSSkolisták heti 1-2 alkalommal e-mailben kapják meg a következő “leckét”. Természetesen mindenki a saját beiratkozásától számított időzítésben, tehát az sem marad le semmiről, aki csak ezután jelentkezik! A leckéket mi magunk állítjuk össze, tapasztalataink és ismereteink alapján a SharePoint világáról. A tematika vázlatosan:

• Csoportmunka, kommunikáció
• WSS 3.0 és MOSS 2007 funkcionalitás, összehasonlítás
• Dokumentumkezelés
• Listák, speciális listatípusok
• Blog
• Wiki
• Alertek, rss
• SharePoint Keresés (WSS és MOSS)
• Workflow lehetőségek, megoldások
• Excel Services
• BDC (Business Data Catalog)
• InfoPath Forms Services
• Report center, KPI
• Record center
• Web Content Management
• Fejlesztések, egyedi igények megvalósítása

Minden érdeklődőt szeretettel várunk! Bővebb információ nálam, jelentkezés pedig weboldalunkon.

Nem tudom, számotokra mennyire lesz érdekes ez az írás, én mindenesetre nagyon fel vagyok most pörögve, úgyhogy muszáj kicsit vernem a billentyűzetet

A projekt röviden: államigazgatás, intranet, szoros integráció más rendszerekkel. A SharePoint részben adatgazda, részben külső interfészekről kapja az adatokat. Az “alap”szolgáltatások mellett szükség van néhány olyan “csavarra” is, melyek széppé teszik a feladatot (s remélem, a megoldást is…). A sokrétegű, szolgáltatásorientált architektúráról sokat nem árulhatok el, de ez tipikusan olyan feladat, amiért érdemes volt ezt a szakmát választani…

Jön az ügyfél, aki még szinte maga sem tudja, mi a problémája, csak érzi, hogy valamit meg kellene oldani. S két-három beszélgetés után eljutsz oda, hogy jön a szikra, amitől berobbannak a fogaskerekek, megvilágosodsz, s elindul a lavina. Összeáll, egy az egész, szép. Nagyon szép. Messze nem rutinfeladat, s pont ezért sikerélmény is jár vele. Már a gondolatért is, a kompozícióért, az architektúráért.

S olyan jó látni, amikor az ügyfél szeme is felcsillan…

Közben azon is folyamatosan gondolkozom, amit Smulovics Péter kérdezett a vidcastban: még mindig nem tudom megmondani, mitől lesz egy architektúra “ághys”. Érzem, de nem tudom megfogalmazni. Tudom, melyik az a terv, amit szívvel-lélekkel csinálok, s valahol büszke is vagyok rá - s melyik az, amit csinálok, mert projekt, mert kell… Nyilván a belső “kényszer” motiváció sokkal erősebb tud lenni.

De olyan jó látni, amikor az ügyfél szeme felcsillan, s örül annak, amit kitaláltam!…

Az egyik kedvenc eszközöm tervezéskor, egy-egy architektúra kialakításakor. Alapvetően papír-típusú ember vagyok, vagyis imádok rajzolgatni, ide-oda húzkodni a felhőket, vastagon, színesen, stb. Aztán amikor kész, összeállt a kép, felviszem a gépre, letisztázom, mások által is emészthető formába hozom.

A MindMap eszközök gyakorlatilag ugyanezt az élményt nyújtják, azzal a különbséggel, hogy átrendezéskor nem firkálni, satírozni kell, hanem egérrel egyszerűen áthúzzuk, átszínezzük, átnevezzük stb. Egyedül a tinta hiányzik az ember kezéről…

Rég voltam egy eszközbe ennyire szerelmes Ráadásul egy-egy bonyolultabb architektúra ugyanúgy “olvashatatlan”, átláthatatlan marad mások számára, mint ha kézzel firkálnék tele egy fél füzetet a gondolataimmal

Adott az ügyfél, saját(os) igényeivel. Adottak a fejlesztők, akik megvalósítják a feladatot. S vagy Te, aki az interfészt jelented közöttük. Az ügyfél rád zúdítja összes óhaját-sóhaját, Te ezeket lefordítod “emberi” nyelvre, s továbbítod a fejlesztők felé. Összehangolod az ő munkájukat, elkészíted a feladatleosztást, kicsit “rabszolgahajcsárként” pátyolgatod őket. Amit elkészítenek, továbbítod az ügyfél felé, szakmailag is Te felelsz értük és a munkájukért.

Magyarul Te vagy az interfész, akinek az információtovábbításon felül feladata annak konvertálása is.

Sőt, továbbmegyek. A Te feladatot az ügyfél “simogatása” is, és a fejlesztők lelkének ápolása is. Úgyhogy amellett, hogy végzed a technikai feladatod, emberileg is értened kell a két oldalt. Szép feladat

De hogyan is néz ki egy ilyen “interfészfunkció”?

Azt hiszem, a kommunikáció választott és elfogadott formáját tekintve is lépést kell tartanunk a korral. Régebben két (három) dologra hivatkozhattunk: személyes megbeszélések, telefonbeszélgetés, e-mail. A hivatalos megbeszélésekről nyilván készült valamiféle jegyzőkönyv (ugye?), az e-mail önmagában is írásos, a telefonon megbeszélt dolgokat azonban általában senki nem rögzítette semmilyen formában.
Napjainkra (úgy érzem) ez megváltozott, egyre többen ismerik fel a különféle messenger programok előnyeit. Amellett, hogy használatuk ingyenes (az internet hozzáférést ma már adottnak tekinthetjük), a beszélgetést rögzíthetjük (history), így az visszakereshetővé válik, egyértelművé téve, pontosan mi és hogyan hangzott el.

Megvan tehát a kommunikációs interfész az ügyfél-Te-fejlesztők háromszögben. Most már “csak” ki kellene használni azt, hogy tartalommal is megtöltsük a projektet.

1.) Ügyfél -> Fejlesztők irány:

Az ügyfél többnyire szóban, jobb esetben írásban, de mindenképp “szabadszöveges” formában fogalmazza meg igényeit. A fejlesztők számára ez általában nem elég egzakt, ezért le kell “fordítani” az ő nyelvükre. Ez általában valamilyen szabványos, egyezményes jelölésmódot feltételez (pl. UML), melynek segítségével pontosan definiáljuk az üzleti folyamatokat, adatokat, összefüggéseket, hierarchiákat, stb. Ez a “dobozrajzolgatás” lépése.

2.) Fejlesztők -> Fejlesztők irány:

Bizony, ilyenre is szükség van. A projekt indulásakor jó esetben válogathatsz, kikkel szeretnél/érdemes együtt dolgozni. Rosszabb esetben kész “készletből” gazdálkodhatsz. Mindkét esetben érdemes végiggondolni néhány dolgot:

• Melyik fejlesztőnek mik az erősségei? Hogyan lehetne ezeket kihasználni?
• Melyik fejlesztőnek mik a gyengeségei? Hogyan lehetne ezek hatását minimalizálni?
• Dolgoztak-e már együtt az adott fejlesztők? Hogyan tudnak közösen dolgozni? Mennyire kell “fogni a kezüket”?
• Milyen lehetséges konfliktusforrásokat ismerünk előre? Hogyan lehet azokat kezelni?
• Hogyan kommunikálnak egymással a fejlesztők?
• Hogyan kommunikálnak Veled a fejlesztők? Mennyire fogod átlátni, mikor mi történik, s mennyire dolgoznak “zárt ajtók” mögött? Mennyire szeretnéd/akarod ezt szabályozni? (Nyilván itt annak is nagy szerepe van, hogy helyileg egy helyen ültök-e, vagy pl. távmunkában dolgoznak a fejlesztők.)
• Hogyan kezeled a projekt során felhalmozott tudást? Hagyod “szublimálni”, vagy folyamatosan építesz és építtetetsz egy céges tudásbázist?
• stb. stb. stb.

3.) Fejlesztők -> Ügyfél irány:

A kész (rész)terméket át kell adni az Ügyfélnek. Őt nem érdekli, ki, hogyan, mikor végezte el a feladatot, számára egy dolog fontos: határidőre, minőségi megoldást kapjon. És ezért Te felelsz! Függetlenül attól, hogy ki hibázott, ha probléma lép fel, az a Te sarad, nem háríthatsz. Általában jogilag sem, de etikailag semmiképp.

Fontos tehát, hogy (ha teheted) csak olyan emberekkel dolgozz együtt, akikben, és akiknek a munkájában megbízol. Mindig legyen tartalékidő és -erőforrás a becslésekben, hiszen váratlan fordulatok mindig bekövetkezhetnek. S többnyire be is következnek… Annak idején, amikor legelső projektbecslésemet készítettem, ezt az utasítást kaptam az akkori főnökömtől: “Számold át, gondold végig… S amikor kigondoltál egy számot, annak a kétszeresét áruld el nekem…” - Nyilván amikor az ember már tapasztaltabb, ennyire nem sarkított a helyzet, de soha ne centizzünk ki semmit!

S ha sikerül időben átadni mindent, s az ügyfél is elégedett? Akkor lehet ünnepelni egy kicsit. S az ünneplés után lehet folytatni a munkát…

Hosszú idők óta foglalkozol egy adott dologgal: legyen az szakmai téma, hobbi vagy bármi más, lényegtelen. Nálad milyen lépcsőfokai vannak a tanulásnak?

Én először is, megtalálom az adott dolgot (vagy az talál meg engem), s nekiállok megismerkedni vele. Valahogy így: “Helló, Ághy vagyok.” - “Örvendek, SharePoint személyesen.” Kóstolgatjuk egymást. Egyre több részletét megismerem, de a kép még nem áll össze. Mint amikor nekiállsz kirakni egy hatalmas puzzle-t, de még nem tudod, mit ábrázol a kép. Körvonalazódik egy-egy momentum, de az egész még csak nem is sejlik előtted.

Egyszer csak megtalálsz egy fontos elemet. Majd még egyet. Még egyet… S hirtelen összeáll az EGÉSZ. Vannak még hézagok, az összes darab még nem került a helyére, de már látod a képet. Micsoda érzés!

Én ekkor érem el általában azt a pontot, amikor már éjjel sem tudok aludni, annyira foglalkoztat a téma, s félálomban ugrik be egy-egy részlet, hogy hova is kellene elhelyeznem, vagy mihez kezdjek vele. Néha még fel is kelek az éjszaka közepén, hogy kipróbáljam - máskor csak másnap reggel állok neki. Ezek a legjobb ötleteim általában…

Ismerős?

Ma találtam egy cikket, amelyben egy mondat nagyon megfogott, az írás fő tartalmától teljesen függetlenül:

“With such an aggressive timeline, planning was incredibly important.“

Vajon a cégek/fejlesztők hány százaléka gondolkodik így? Sajnos én elsősorban pont az ellenkezőjével szoktam találkozni: kevés az idő? Akkor uccu neki, essünk bele! Fejlesszünk azonnal, gondolkodás nélkül! Tervezés? Időpazarlás! Dolgozzunk inkább, doksigyártás helyett…

Pedig a tervezés sokkal több, mint esőerdőirtás vagy dobozrajzolgatás…

A napokban sokat gondolkoztam azon, hogy vajon hogyan is lehetne megfogalmazni a kérdést egy igen egyszerű kérdésre: miért van szükség tervezésre projektjeink során? A válasz továbbra is legalább olyan nehéz, mint amilyen könnyűnek tűnik, de eszembe jutott egy hasonlat.

Homokvárat építeni mindenki tud. Ilyet vagy olyat, de tud. Lehet, hogy egyszerű lesz. Talán lesznek benne alagutak. Körülötte “várárok”. Annak idején gyermekkori barátnőmmel “kertet” építettünk a vár köré faágakból, virágokból, sőt időnként még be is népesítettük katicabogarakkal Az öcséink zászlót tűztek a tetejére, utakat, hidat építettek. Ezt még nem hívom tervezésnek, bár ez nyilvánvalóan vita tárgya lehet.

A házépítés már más kérdés - itt jön képbe a tervezés, az architektúra. Lehet elképzelésem arról, milyen házat szeretnék. Tudhatom a szobák számát, elrendezését, a konyha tájolását vagy álmaim fürdőkádjának méretét. De ahhoz már nem értek, hogy ennek megvalósításához mi kell. Nem tudom, milyen falat építsek, statikailag hogyan lesz stabil a házam. Nem tudom azt sem, gépészetileg milyen megoldások kellenek, sőt: milyen megoldások állnak rendelkezésemre. Sok-sok olyan dolog, melyeket tudatosan vagy nem, de használok, mégsem értek hozzá. Jó esetben észre sem veszem ezeket a dolgokat.
Ehhez már kell a tervezés. Kell a jó architektúra - ami engem, mint “ügyfelet” kiszolgál, elégedett leszek, de nem kell foglalkoznom vele.

Ez a különbség. Szerintem.

Szokásos felállás: Megrendelő, Fővállalkozó, Alvállalkozó. Tipikus projekt-felállás, nem? A pénteki Architektúra Fórumon hangzott el a kérdés: a követelményspecifikáció vajon cél, vagy eszköz?
Cél, ha mérföldkőként tekintünk rá: el kell érni ahhoz, hogy az ügyféltől az első adag pénzt megkapjuk.
Eszköz, ha azt látjuk benne, hogy később, a projekt megvalósítása során mekkora szükségünk lesz rá.

De vajon mi történik akkor, ha nincsenek előre rögzítve a követelmények?
A Megrendelő tudja, mit szeretne. A Fővállalkozónak van egy elképzelése a megvalósítás hogyanjáról. Az Alvállalkozó pedig legjobb tudomása szerint igyekszik teljesíteni, amit elvárnak tőle. De követelményspecifikáció híján ő maga sem tudja, mi ez. S ahogy ez tudatosul benne, úgy indul a lavina… Mert persze mindez újabb és újabb problémák kapcsán lesz egyre világosabb.
A Fővállalkozó által biztosított technikai háttérrel gondok vannak, az Alvállalkozó nem tudja rendesen végezni a dolgát. - Ez vajon kinek a hibája? Nyilván az Alvállalkozó az, akire a legkönnyebb rákenni: nem tudta áthidalni ezeket a problémákat. A Fővállalkozó mossa kezeit.
A Megrendelő is elégedetlen: nem azt, és nem olyan minőségben kapja, ahogyan szeretné. Ki a hibás? Nyilván ismét az Alvállakozó, aki a fent említett technikai nehézségek miatt belebukik a demóba. Az természetesen nem érdekli a Megrendelőt, hogy miért. A Fővállalkozónak pedig csak jól jön, hogy az ő neve fel sem merül a felelősségrevonás során.

Mi marad az Alvállalkozónak? Semmi. Egy elégedetlen Megrendelő, aki kommunikálni csak a Fővállalkozóval hajlandó - és egy Fővállalkozó, akinek nyilván az az érdeke, hogy a Megrendelő vele kávézzon jövő héten is.

Ez lesz a követelményspecifikáció hiányából… S most vajon a cél vagy az eszköz nem volt megfelelő?

Márciusban linkeltem ide egy cikket a SharePoint 2007 telepítéséről, most egy speciális aspektusát írnám körül, hiszen a tanfolyamokon ez újra és újra visszatérő kérdés. Mégpedig a farm és a stand-alone telepítés.

Kezdjük az “egyszerűbb” esettel: stand-alone. Ha ezt az opciót választjuk, abban a meglepetésben lesz részünk, hogy a telepítő gyakorlatilag semmit nem kérdez, hanem egyszerűen felkúszik a MOSS, és kész. Nincs adatbázisszerver-érdeklődés, semmi. Megy és kész. De hol vannak ekkor az adatok? Mi is történik pontosan?
Nos, a MOSS úgy értelmezi, hogy ha stand-alone, akkor minden az ő feladata, s ezt szépen le is zongorázza: felpakol egy SQL Server 2005 Express-t, beállítja a szükséges config és content adatbázisokat, stb. Működik, fejlesztői környezetnek jó lehet, éles rendszer esetén azonban számolnunk kell az SQL Express korlátaival…

Ahhoz, hogy saját, meglévő SQL 2005 szerverünket konfigurálhassuk be a SharePoint 2007 alá, bizony farmot kell telepítenünk. Első ránézésre furcsa lehet, ha fizikailag egy gépen van minden (DC, SQL, MOSS), de próbáljunk logikailag, a SharePoint fejével gondolkozni (micsoda képzavar! ) - az ő szempontjából az SQL server egy “kívülálló”. Akkor is, ha ugyanazon a vason ülnek. Ugyanígy “kívülálló” a domain controller, az SMTP, stb. is. Lényegtelen, hogy fizikailag hol vannak. Nem számít.
Logikailag más szerver, és kész.
Ezért kell a farm telepítést választanunk. Ekkor van lehetőségünk annak konfigurálására, hogy hol lesz az adatbázis, milyen SMTP szervert fogunk használni, stb. Akkor is, ha ezek elérése (IP cím) megegyezik a MOSS-éval.

Természetesen ez utóbbi esetben van lehetőségünk a későbbiekben arra is, hogy az egyes funkciókat átpakoljuk más szerver(ek)re (vagy már alaphelyzetben is így állítsuk be), így a farm tényleg farm lehet…

MSF? RUP? Saját módszertan? De milyen? Hogyan válasszuk ki, mi “passzol” az adott ügyfélhez? Mi történik/történhet, ha rosszul döntünk?

Két fontos tényező a siker kulcsa: a kiválasztott módszertan kellő ismerete, valamint az ügyfél ismerete. A kettőt a testreszabás köti össze: a kiválasztott módszertan kialakítása az adott ügyfél igényeinek megfelelően.
Az, hogy az ügyfelet mennyire ismerjük, sok tényezőtől függhet. Mióta állunk vele kapcsolatban, mennyire “aktív” ez a kapcsolat? Mi magunk mennyire tudunk egy-egy ember vagy cég “rezdüléseire” odafigyelni, mennyire értjük őt, mennyire olvasunk akár a gondolataiban is? Ő mennyire ismer bennünket?
A módszertan ismerete és testreszabási képessége gyakorlatilag szakmai feladat, mégis számos emberi tényező is befolyásolja. Néha maga az ügyfél is…

Elmesélek egy példát.
Az ügyfél egy viszonylag kis cég, néhány saját fejlesztővel, de szeretne megvalósítani egy központi rendszert, melyet külső emberre bízna. A külsős ember specifikál, heti két napot biztosít az ügyfél számára (tehát nem ül be állandóra az irodába, ez fontos tényező!), s ez jónak is tűnik. Az ügyfél örül, lelkes, túlteng benne a tettvágy.
“Ügyfél” alatt természetesen a megbízó céget értem, de nyilvánvalóan van képviselőjük, aki a külső vállalkozóval egyeztet. Rajta kívül dolgoznak még mások is a cégben, akik értelemszerűen végzik a munkájukat. És itt jön a svédcsavar: az egyik dolgozó elégedetlenkedik teázás/kávézás közben, vagy csak úgy az asztalánál ülve, hogy X dolog még nincs készen.
Az egyik belső fejlesztő ezt meghallja, s egy másik technológiával pikk-pakk megoldja. Kicsit más a megoldás, mint ahogyan a külső fejlesztő eltervezte: nemcsak technológiában, hanem logikailag is. Sebaj, a problémafelvető boldog, a nyomtatóból árad a papír - csak épp ezzel az egész eltervezett koncepció felborult.

Ki a hibás? A külső fejlesztő, aki nem ül bent napi 8-10 órában az ügyfélnél? Az ügyfél képviselője? A belső fejlesztő? Az elégedetlenkedő dolgozó? Miért került a fejlesztés két szék közül a vizesárokba?

Valahol elcsúszott a dolog. Az ügyfél nem tudott szakítani rég bevált szokásaival. Elkényelmesedett: az irodában ülő fejlesztőt a nap bármely pillanatában lehet zargatni, ezt csináld, azt csináld… Hogy ebből mi lesz készen, persze más kérdés.
A külső fejlesztő pedig nem ismerte fel, hogy a hangzatos lelkesedés mögött ott lapul ez a kényelmes monotonitás, melyből talán a legnehezebb kirángatni az ügyfelet.

Az ügyfél gyakran a megváltót látja a beszállítóban. S valamilyen szinten persze az is, hiszen feladata az ügyfél problémáinak megoldása, de ehhez aktívan(!) szükség van az ügyfélre is. Segíts magadon, az Isten a beszállító is megsegít…

A NetAcademia tudástárában nekiálltam összegyűjteni, amit a különféle szoftver-specifikációkról és dokumentációkról tudni illik/érdemes. Itt pedig a Specifikációk, dokumentációk oldalon tematikusan nekiálltam gyűjteni, mit hol találtok.

SDr kérdésére végül nem e-mailben és nem itt válaszolok. Szerintem pont hogy belefér a Tudástárba, ilyenek miatt indítottuk ott ezt a topicot. Íme tehát a válaszom:

“A fejlesztői specifikáció elsődleges feladata leegyszerűsítve az (lenne), hogy hidat létesítsen a megrendelői igények és a majdani ‘kód’ közé. Vagyis hogy a fejlesztők felé közvetítse, pontosan mi is a megoldandó feladat. És igen, ebben benne kell(ene) lennie annak is, hogy miért pont azt a lehetőséget választottuk, milyen szempontrendszer alapján végeztük a tervezést, miket vizsgáltunk meg, stb.“