Do każ­dej po­trze­by pod­cho­dzi­my in­dy­wi­du­al­nie, roz­wa­ża­jąc wszyst­kie moż­li­we roz­wią­za­nia – po­czy­na­jąc od bra­ku pod­ję­cia zmian (ta­ką moż­li­wość na­le­ży za­wsze prze­my­śleć!), przez roz­wią­za­nia po­ło­wicz­ne, wy­ko­rzy­sta­nie go­to­wych sys­te­mów, koń­cząc na bu­do­wie de­dy­ko­wa­ne­go sys­te­mu.

Na­szym głów­nym ce­lem jest przy­nie­sie­nie opła­cal­no­ści przed­się­wzię­cia któ­ra owo­cu­je dłu­go­let­nią współ­pra­cą. Nie wy­my­śla­my na si­łę po­trzeb bu­do­wy roz­wią­za­nia któ­re się nie opła­cą.

Po­zy­ska­nie do­kład­nych wy­ma­gań jest jed­nym z klu­czo­wych wa­run­ków uda­ne­go pro­jek­tu IT. Brak pre­cy­zji i zro­zu­mie­nia in­ten­cji użyt­kow­ni­ka sys­te­mu skut­ku­je mar­no­traw­stwem cza­su i fun­du­szy, dla­te­go ca­ły czas do­sko­na­li­my nasz warsz­tat in­ży­nie­rii wy­ma­gań.

W za­leż­no­ści od cha­rak­te­ru i fa­zy pro­jek­tu sto­su­je­my:

• do­ku­men­to­wa­nie wy­ma­gań w po­sta­ci User Sto­rie­s/Use Ca­se,
• me­to­dę ICONIX: mo­de­lo­wa­nie za po­mo­cą dia­gra­mów prze­pły­wu da­nych mię­dzy funk­cja­mi (Ro­bust­ness dia­gram),
• sz­ki­ce in­ter­fej­su (mock-ups/wi­re­fra­mes) oraz do­kład­ne pro­to­ty­py (osta­tecz­ny wy­gląd sys­te­mu).

Ma­jąc wie­dzę na te­mat do­stęp­nych tech­no­lo­gii pro­gra­mi­stycz­nych oraz roz­wią­zań go­to­wych, je­ste­śmy w sta­nie do­ko­nać ana­li­zy opła­cal­no­ści wdro­że­nia ist­nie­ją­ce­go sys­te­mu w sto­sun­ku do bu­do­wy no­we­go opro­gra­mo­wa­nia.

Ze­bra­nie szcze­gó­ło­wych wy­ma­gań i przy­go­to­wa­nie do­bre­go pro­jek­tu ar­chi­tek­tu­ry roz­wią­za­nia po­win­ny za­gwa­ran­to­wać bez­pro­ble­mo­wą re­ali­za­cję na czas, bez do­dat­ko­wych nie­spo­dzia­nek i kosz­tów.

Nie­ste­ty to uto­pia. Świat in­ży­nie­rii opro­gra­mo­wa­nia do­szedł do wnio­sku, że trze­ba po­go­dzić się z tym, że wy­ma­ga­nia mo­gą się zmie­niać w trak­cie tr­wa­nia pro­jek­tu i na­le­ży wy­pra­co­wać no­we me­to­dy pra­cy. Na­wet naj­le­piej udo­ku­men­to­wa­ne wy­ma­ga­nia nie gwa­ran­tu­ją, że opi­sa­ne funk­cje rze­czy­wi­ście bę­dą uży­tecz­ne w re­al­nej pra­cy.

Na­sze do­świad­cze­nie rów­nież po­twier­dza za­sad­ność uży­wa­nia me­to­dyk zwin­nych (Agi­le). W za­leż­no­ści od cha­rak­te­ru pro­jek­tu sto­su­je­my me­to­dykę SCRUM lub XPrin­ce. Świa­do­mie do­bie­ra­my tech­ni­ki opi­sa­ne w tych me­to­dykach aby za­pew­nić po­żą­da­ny po­ziom kon­tro­li pro­jek­tu.

Krót­kie okre­sy do­star­cza­nia ko­lej­nych funk­cji po­zwa­la­ją na spraw­dze­nie ich uży­tecz­no­ści w re­al­nych wa­run­kach pra­cy oraz wpro­wa­dze­nia zmian gdy zaj­dzie ta­ka po­trze­ba.

Na­si pro­gra­mi­ści ko­cha­ją roz­wią­zy­wać pro­ble­my, po­zna­wać no­we tech­no­lo­gie i an­ga­żo­wać swo­ją kre­atyw­ność w two­rzo­ne przez nas pro­jek­ty. Ma­my świa­do­mość, że na­sza bran­ża zmie­nia się bły­ska­wicz­nie dla­te­go bie­rze­my udział w kon­fe­ren­cjach pro­gra­mi­stycz­nych i spe­cja­li­stycz­nych szko­le­niach aby za­wsze być na bie­żą­co.

Pro­gram któ­ry dzia­ła nie jest jesz­cze wy­znacz­ni­kiem uda­ne­go pro­jek­tu. Ta­kie ce­chy jak bez­a­wa­ryj­ność, ła­twość zmian i roz­wo­ju, ana­li­zo­wal­ność ko­du ode­gra­ją póź­niej du­że zna­cze­nie. Na­szą am­bi­cją jest two­rze­nie do­bre­go ko­du któ­ry speł­nia te wszyst­kie ce­chy.

Sto­su­je­my tech­ni­ki co­de-re­view: prze­gląd ko­du przez in­nych pro­gra­mi­stów przed wdro­że­niem na ser­wer pro­duk­cyj­ny. Nie­zro­zu­mia­ły lub nie­opty­mal­ny kod jest re­fek­to­ry­zo­wa­ny tak dłu­go aż uzy­ska ak­cep­ta­cje przez ze­spół.

Ta in­we­sty­cja cza­su zwra­ca się w po­sta­ci mniej­szej awa­ryj­no­ści oraz bar­dziej ela­stycz­nej pra­cy we­wnątrz ze­spo­łu: Nie ma sy­tu­acji w któ­rej tyl­ko jed­na oso­ba ma wie­dzę na te­mat two­rzo­nej przez nie­go czę­ści opro­gra­mo­wa­nia.

Ko­lej­ną istot­ną tech­ni­ką jest sto­so­wa­nie zauto­ma­ty­zo­wa­nych te­stów re­gre­syj­nych. Każ­de no­we wy­da­nie opro­gra­mo­wa­nia jest au­to­ma­tycz­nie bu­do­wa­ne na ser­werze te­sto­wym (Jen­kins CI) i te­sto­wa­ne przez skryp­ty któ­re sy­mu­lu­ją za­cho­wa­nie użyt­kow­ni­ka. Ja­ka­kol­wiek roz­bież­ność spo­dzie­wa­ne­go re­zul­ta­tu od od­po­wie­dzi wy­ge­ne­ro­wa­nej przez sys­tem skut­ku­je po­wia­do­mie­niem pro­gra­mi­sty któ­ry od­po­wia­da za błęd­ny kod.

Sko­ro zmia­ny w wy­ma­ga­niach są nie­unik­nio­ne to sto­su­je­my ta­ki styl pra­cy któ­ry ogra­ni­czy stra­ty w wy­pad­ku wpro­wa­dze­nia zmian. Kon­tro­lu­je­my ja­kość ko­du w ta­ki spo­sób aby jak naj­szyb­ciej do­star­czyć dzia­ła­ją­ce roz­wią­za­nie, po ak­cep­ta­cji ulep­szyć je­go ja­kość (re­fak­to­ry­za­cja) uni­ka­jąc przy tym ry­zy­ka wpro­wa­dze­nia no­wych błę­dów (te­sty re­gre­syj­ne).

Zbu­do­wa­nie opro­gra­mo­wa­nia to nie ko­niec pro­jek­tu. Przez wdro­że­nie ro­zu­mie­my prze­szko­le­nie i prze­or­ga­ni­zo­wa­nie fir­my klien­ta w ta­ki spo­sób aby efek­tyw­nie z nie­go ko­rzy­stać. Na­szym ce­lem jest nie bu­do­wa pro­duk­tu a osią­gnię­cie po­sta­wio­ne­go ce­lu bi­zne­so­we­go. Opro­gra­mo­wa­nie naj­czę­ściej jest tyl­ko środ­kiem.

Gdy już wszyst­ko funk­cjo­nu­je i przy­no­si zy­ski ofe­ru­je­my dal­sze wspar­cie i roz­wój wdro­żo­ne­go roz­wią­za­nia. Wie­rzy­my, że wie­lo­let­nia współ­pra­ca jest ko­rzyst­na dla obu stron.