Projektu izstrādes stils Jānis Rubļevskis (koko) / 24.10.2006. 07:00 / #Datori / 7 komentāri

Kamēr dzeru kafiju, izdomāju ilgi kultivēto sāpi izteikt arī jums, mani mīļie, mazie draudziņi!

Stāsts būtībā nebūs par maniem tiešajiem pienākumiem. Stāsts būs par to, ka biežāk tiešie pienākumi aprobežojas tikai ar kādiem 30% no kopējā darba apjoma, kas noved pie nesaprašanās daudzu iesaistīto pušu starpā. Bet nu par visu pēc kārtas.

Programmatūras izstrādes procesam jābūt rūpīgi noteiktam un sadalītam dažādās pakāpēs, izmantojot dažādus programmatūras izstrādes modeļus, piemēram, visvienkāršāko, taču laika gaitā par ļoti labu atzīto Ūdenskrituma modeli. Var jau izmantot arī citus modeļus. Pamatā modeļa izvēle ir atkarīga no firmā pieņemtajiem standartiem un izstrādājamā produkta tipa, kā arī termiņiem.

Konkrētajā gadījumā pieņemsim, ka mums ir visai abstrakts projekts - uzstaisīt programmiņu, kas lietotāja datnes novieto uz servera un ļauj arī tās atgūt atpakaļ, izmantojot autorizēšanos.

Tālāk stāstīšu pa posmiem, vienlaicīgi pastāstot no viedokļa, kā būtu labi un kā ir patiesībā.

1) Pirmais posms mazam projektam varētu būt tikšanās ar pasūtītāju. To darītu marketinga menedžeris vai kaut kas tamlīdzīgs. Noskaidrotu aptuvenos pasūtītāja priekšstatus, pastāstītu aptuveno situāciju vispār tirgū un uzzinātu visus par un pret un vai vispār sadarbosimies. Šis posms daudz maz vienmēr ir bijis līmenī - vienmēr var atrast klientu, kam kaut ko vajag un kas ir gatavs maksāt.

2) Otrais posms - detalizētas specifikācijas izveidošana. Šajā posmā tad beidzot vajadzētu iestaistīt sistēmas analītiķi. Mazās firmās pirmo posmu, sistēmas analītiķa darbu un projekta vadītāja darbu varētu pat apvienot šī viena persona, kurai tad par to visu būtu arī visvairāk jāmaksā. Šajā [otrajā] posmā analītiķim neskaitāmas reizes jātiekās ar klientu, jāpiedāvā savi risinājumi, jāuzklausa klienta viedoklis un jāanalizē. Pēc kārtējās analīzes atkal tikšanās ar klientu un atkal analīze. Kad klients pilnībā ir apmierināts ar šo analīzi un neskaitāmām lapām specifikācijas, kas ietver gan procesu aprakstus, gan ievaddatus, gan izvaddatus, gan sistēmas funkcionālās, gan nefunkcionālās prasības, tad abpusēji tiek parakstīts, ka pēc šīs specifikācijas tiek veidota programma.

Diemžēl mūsu apstākļos lielākoties mazajos uzņēmumos ar klientu sākotnējā stadijā satiekās tikai 2 vai 3 reizes, lai noskaidrotu, ka vajag projektu, lai iedotu tāmi un, lai parakstītu līgumu par šī unikālā projekta izstrādi.

3) Trešajā posmā analītiķim jāsadarbojas ar dizaineri, kas pēc specifikācijas izstrādā dizainu. Pēc skiču izstrādes dizaineris kopā ar analītiķi atkal satiekās ar pasūtītāju un viņi tur meņģējas tik ilgi, kamēr visi ir apmierināti.

Mūsdienās vispirms top dizains un dizains arī nereti top izmantots kā specifikācija (tiesa gan te jau ir tā problēma, ka bildītē nav rakstīts, ka konkrētie dati var saturēt tikai 100 simbolus vai tamlīdzīgi).

4) Posms - analītiķis tagad dodās pie programmētāja, iedod detalizētu specifikāciju, iedod saskarni un saskarnes aprakstu (labākajā gadījumā pie attiecīgām tehnoloģijām tiek iedota jau arī izveidota saskarne, kuru vienkārši jāapšuj ar kodu).

Kas ir mums? Mums vienkārši tiek iedots dizains un pateikts - tev jāuztaisa datu apmaiņas sistēma. Var sūtīt failus un var dabūt failus. Cilvēkam ir jāielogojas. Te tev būs dizains. Un tev vajag, lai dati glabājas uz linux, bet pieeja no Windows.

5) Piektajā posmā ir pabeigta sistēma. Tā ir arī praktiski notestēta un tiek dota izvērtēšanai. Pēc attiecīgas vienošanās, ja specifikācijā tas neko radikālu nemaina, tiek ieviestas arī nelielas izmaiņas. Un atkal saskarsme starp pasūtītāju un uzņēmumu ir analītiķis. Pēc tā seko dokumentu parakstīšana un īsā laikā viss ir uzbliezts uz URRĀ.

Rezumē: Nevis programmētāji mums ir deficīts. Deficīts ir tieši sistēmas analītiķi, jo sistēmas izstrādē 2/3 daļas aizņem analīze, un tikai 1/3 programmēšana. Realitāte ir tāda, ka programmētājam jākļūst par analītiķi. Programmētājam nereti arī jākļūst par dizaineri. Un lielākās problēmas ir tādas, ka programmētājs nav radīts tam, lai runātu ar klientu, kas beigās noved pie gatava produkta 10 un vairāk reizes.

Tagad ar to pašu piemēru mēģināšu to visu paskaidrot:

Pirmajā [kā vajadzētu būt] gadījumā: pie programmas atrādīšanas, tā ir gandrīz gatava un tur radikālas izmaiņas nevar tik ieviestas.

Otrajā gadījumā: pirmā atrādīšanas reize. Atnāk pasūtītājs. Rādam programmu, kur cilvēks var ierakstīt paroli un nosūtīt uz serveri datus. Tā pat var dabūt atpakaļ. Tomēr pasūtītāju tas neapmierina. Tā jau sanāk, ka visi tiek pie visu datiem. Vajag, lai būtu katram lietotājam sava mapīte, kas nozīmē, ka mums nebūs viena parole, bet būs daudz lietotāju ar daudzām parolēm, kas nozīmē, ka strādāsim vēl kādu laiku.

Nākamā reize - o - kruta - ir lietotāji, bet saglabājas viss vienā mapē. Mums tak baigi jāmeklē - jāparedz iespēja pievienot un dzēst mapes, jāparedz iespēja kārtot pēc datumiem utt... Un atkal notiek pārstrāde...

Beigās sanāk tā, ka neatmaksājas programmētājam to visu darīt n-tās reizes. Viņam tas projekts piebesīs un nekad pasūtītājs nebūs apmierināts. Lētāk ir nolīgt sistēmas analītiķi un nemocīt nabaga programmētāju ar darbiem, kas nebūt nav jādara viņam

P.S. Tas viss tikai no manas personīgās pieredzes un gūtās izglītības. Ja kaut kas nepatīk, tad, lūdzu, argumentēti izsakiet savu viedokli komentāros.


Komentāri:

kubiks @ 24.10.2006. 14:25

Nu, ja runājam par "normāliem" projektiem, tad tur testu inženieris ir pilnīgi normāls amats ar savām zināšanām, dokumentiem, metodēm, rīkiem, konferencēm utt. Viņi tad arī uzdod visus tos jautājumus. Bet tas viss, savukārt maksā naudiņu.

Bet projektu vadītājam arī kaut kāda teikšana taču ir. Ja klients beigās nav apmierināts, tad vainīgais nedabūs prēmiju. Var taču viņus (pogrammētājus) sūtīt kaut kādos kursos vai norīkot gudrāko no viņiem, lai sagatavo lekciju pārējiem un par to iedod piemaksu.

(Tas tā. Mani vajā hronisks naivums.)

koko @ 24.10.2006. 14:09

Neiet jau runa par normālu projektu...
Testētājs? Kas ir testētājs? Labākajā gadījumā patestē kāds cits programmētājs, ja viņam ir brīvs brīdis, kura parasti nava...
Un pie piemēra nepiesienies - tas ir tā diezgan pārspīlēts :)

kubiks @ 24.10.2006. 14:05

"Kas ir mums? Mums vienkārši tiek iedots dizains un pateikts - tev jāuztaisa datu apmaiņas sistēma. Var sūtīt failus un var dabūt failus. Cilvēkam ir jāielogojas. Te tev būs dizains. Un tev vajag, lai dati glabājas uz linux, bet pieeja no Windows."

Un jūsu programmētājs to tekstu norij un sāk taisīt? Tad jums ir problēmas ar programmeri. Kāpēc viņam nerodas jautājumi? Kāds ir lielākais pieļaujamais sūtāmais faila izmērs? Vai jāvar sūtīt vairākus failus vienlaicīgi vai pa vienam? Kādi ir iespējamie atteikuma iemesli? Vai jābūt iespējai mainīt paroli? Vai failus jāvar arī izdzēst? Ja failu vajag iedot kādam citam, tad kā notiks tiesību deleģēšana? Kā ir jāizkārto faili: stabiņā? tabulā? kā jāsakārto? kādā fontā un fonta izmērā? Vai Windowsam ir jābūt servispakām virsū? Ja programmētājam būs vienalga, ko viņš taisa, galvenais ka tik klabināt taustiņus, tad tāds arī būs rezultāts.

Un vispār normālā projektā ir jābūt arī testētājiem.

koko @ 24.10.2006. 14:04

Protams, lomas var pārklāties un tām ir jāpārklājas, bet jāsaprot arī to, ka programmētājs saprot visu savādāk nekā citi un arī dara kā viņam vieglāk, taču, ja specificēšanā piedalītos ar programmēšanu nesaistīts cilvēks, tad beigās programma iznāktu tada, kas patī lietotājam nevis programmētājam...
Es nedaudz kļūdījos - pie analīzes jāpiesaista arī programmētāju, jo citādi analītiķis visus ieejas izejas datus var arī nemācēt paredzēt.
Kā arī programmētāju jāpiesaista pie dažādu lietu projektēšanas (piemēram, db, saskarne un līdzīgi)

kubiks @ 24.10.2006. 13:49

Uz izstrādājamo sistēmu ir jāskatās caur dažādām brillēm: sistēmanalītiķa, programmētāja, gala lietotāja, projekta vadītāja utt, bet nekur nav teikts, ka katrai lomai ir nepieciešams savs cilvēks. Ir tāda cilvēka psiholoģijas īpatnība, ka viņam grūti iejusties dažādās lomās, tikai viena viņam padosies vislabāk. Bet nedrīkst nokoncentrēties tikai uz savu lomu un uzspļaut pārējiem, jo galu galā sistēma, kuru viņi izstrādā ir viena. Arī programmētājam ir jākomunicē ar klientu, jo sistēmanalītiķis nevar zināt visus sīkumus, kas uzpeld izstrādes gaitā. Sistēmanalītiķim arī ir jātestē sistēma, jo tikai tad viņš redzēs, kā viņa pūkainā ideja strādā vai nestrādā utt. Testētājam ir jāanalizē prasības, jo kļūdas parasti ir tieši neizanalizētajā vai nespecificētajā sistēmas daļā. Testētājam ir jāmāk programmēt, jo tad viņš labāk zinās, kur programmētājs ir pielaidis kļūdas utml. Jo projekts ir mazāks, jo vairāk jārēķinās ar lomu pārklāšanos.

koko @ 24.10.2006. 05:12

Hehe... salīdzināji Agile ar Waterfall :D Nu būtībā doma tāda, ka pārāk bieži neviens nedomā par izstrādes procesu un tā pareizumu, bet tikai par kodēšanu...
Ps... Waterfall modeli var arī modificēt, lai var no katra posma atgriezties iepriekšējos!

tm @ 24.10.2006. 05:07

Tev tas programmētājs izskatās pēc apaļa idiota.
Savukārt analītiķis, pēc nabaga spuldzes.

Lai gan samanīji problēmu, šķiet gribi vainot personālijas, bet faktiski jau pie vainas ir tieši "ūdenskrituma" metodoloģija, kura ir viena no bēdīgākajām izstrādes metodēm pārmērīgā riska dēļ.
Ar šķipsnu sāls vari ieskatīties "agile development" sadaļā - en.wikipedia.org/wiki/Agile

Och, un lietošanas piemēri arī ļoti palīdz (pointless.lv/2006/06/09/lietosanas-piemeru-kickstart)


Nu pasāpini mani - tu jau gribi:

* Visi lauki (izņemot tavu lapu) aizpildāmi obligāti!
E-pasts publiski netiks parādīts.
Zinot vairākumu, komentāros tagi netiek atrādīti kā tagi. Linki automātiski pārveidosies par spiežamiem (cerams).
Bloga īpašnieks patur tiesības ļaunus komentārus dzēst vai pārveidot cilvēkiem patīkamākā formā, bet tajā pašā laikā neatbild par komentāru saturu.