началоstartначало ~ софтуерът-и-азsoftware-and-iсофтуер-и-я ~ биографияcv/resumeбиография ~ библиотекаlibraryбиблиотека ~ снимкиphotosфотографии ~ детскиkids'детские ~     български/.bg     русский/.ru     english

Пра­ве­не­то на соф­ту­ер ка­то граф във вре­ме/прос­т­ран­с­т­во­то, и ро­ли­те Software process as a graph in time/space, and roles Соф­ту­ерный про­цесс как граф во вре­мя-прос­т­ран­с­т­ве, и ро­ли

На­пос­ле­дък мно­го се го­во­ри за Пър­га­ва-ме­то­до­ло­гия и "зло­у­пот­ре­ба" с нея... Ами, "Пър­га­ви­на­та" е ка­то зен-бу­диз­ма (виж в биб­ли­о­те­ка­та). Не е ре­ли­гия, и не е па­на­цея, а на­чин на жи­вот. Не ста­ва въп­рос за до­кар­ва­не на вън­шен вид, ста­ва въп­рос за съ­дър­жа­ни­е­то. Ако не ид­ва от­вът­ре - т.е. се раз­г­леж­да ка­то спи­съ­ци и пра­ви­ла и от­мя­та­не по точ­ки - ня­ма ни­как­ва пол­за. И ня­ма сми­съл да се спаз­ва бук­вал­но - пол­з­вай то­ва ко­е­то те ке­фи. Но имай пред­вид че вед­на­га лъс­ва _всич­ко_дру­го_ ко­е­то не е на­ред.

Пос­ле, ид­ват вой­ни­те Пър­га­ва ме­то­до­ло­гия с/у Во­до­пад­на/CMMI и пр. Спо­ред мен, про­це­сът на пра­ве­не на соф­ту­ер тряб­ва да се раз­г­леж­да ка­то граф, във вре­ме­то (ко­га) и прос­т­ран­с­т­во­то (как­во, и _кой_). Раз­ни­те ме­то­до­ло­гии го иде­а­ли­зи­рат ка­то спе­ци­фи­чен вид граф, т.е. на­со­чен, еди­нич­на на­чу­пе­на ли­ния, спи­ра­ла и т.н... и пос­ле очак­ват/при­е­мат че то­ва е един­с­т­ве­но­то и е при­ло­жи­мо в/у це­лия граф. Ко­е­то прос­то не е вяр­но, пар­че­та­та (чо­век/вре­ме/де­тайл) мо­же да са от раз­ли­чен вид, ня­ма ЕДИН-ЕДИН­С­Т­ВЕН на­чин. Ед­на от­вер­ка мо­же да се дър­жи по мно­го на­чи­ни, до­ри със зъ­би, на­ли? Вся­ко от­дел­но пар­че от гра­фа мо­же да при­ли­ча на не­що из­вес­т­но, и то­га­ва съ­от­вет­на­та ме­то­до­ло­гия е при­ло­жи­ма към не­го. По-къс­но, съ­що­то пар­че - или дру­го пар­че по съ­що­то вре­ме - или до­ри друг чо­век за съ­що­то не­що - мо­же да е дру­га ме­то­до­ло­гия, да­же ня­кол­ко ед­нов­ре­мен­но.

Раз­би­ра се то­ва ще из­г­леж­да ка­то пъ­лен ха­ос, ако се очак­ва всич­ко да пас­ва на един и същ ка­лъп (кол­ко­то и сло­жен да е той). И съ­що та­ка, да се уп­рав­ля­ва и сле­ди по­доб­на "ка­ша" не е въз­мож­но от ЕДИН чо­век - но ако все­ки учас­т­ник си по­лу­чи пар­че­то ка­то своя соб­с­т­ве­ност, ста­ва. Все­ки чо­век си има соб­с­т­вен стил, кул­ту­ра, ... и соб­с­т­ве­ни про­це­си, под­хо­ди... Е, все­ки тряб­ва да е об­ра­зо­ван да знае всич­ки на­чи­ни да се дър­жи от­вер­ка, и да е дос­та­тъч­но са­мо-дис­цип­ли­ни­ран да ги след­ва.

Тъй че всич­ки­те те­зи "вой­ни"... са са­мо мър­зел/не­же­ла­ние да се при­е­ме че НЯ­МА-един­с­т­вен-сре­бъ­рен-кур­шум, да се на­у­чат всич­ки на­чи­ни, и най-ве­че, да се пре­да­де (мес­т­ния) кон­т­рол на са­ми­те из­вър­ши­те­ли.


За ро­ли­те на учас­т­ни­ци­те... Във из­вес­тен сми­съл, във вре­ме­то, ако един раз­ра­бот­чик ра­бо­ти по н-та­та ите­ра­ция, не­го­ва­та трой­ка (ми­на­ло-се­га-бъ­де­ще) е при­мер­но (н-1,н,н+1), до­ка­то биз­нес ана­ли­ти­кът е по­не ед­на стъп­ка нап­ред, а мо­же да гле­да и на­зад - напр. (н-2,н+1,н+5). Ар­хи­тек­тът съ­що мо­же да е със ши­рок об­х­ват, напр. (н-1,н,н+3)... Е, то­ва е прос­то при­мер, за един на­низ от (пар­че­та)ра­бо­та; в дейс­т­ви­тел­ност има мно­го ниш­ки (спо­ред фун­к­ци­о­нал­ност­та или др.), с раз­лич­на по­зи­ция и об­х­ват за вся­ка, и раз­де­ля­не­то на пар­че­та­та мо­же да не е тол­ко­ва яс­но.

За да е въз­мож­но всич­ко­то то­ва, мо­е­то ре­ше­ние бе­ше да се пре­мес­тят биз­нес-ана­ли­ти­ци­те при от­бо­ра раз­ра­бот­чи­ци, та­ка че всич­ки са на "ед­но ухо" раз­с­то­я­ние. То­ва пре­диз­вик­ва дос­та раз­бър­к­ва­не в на­ча­ло­то, и мо­же да е не лъ­жи­ца за все­ки­го... но ра­бо­ти доб­ре.

Мо­е­то виж­да­не - ве­че над 10 го­ди­ни - е че прог­ра­ми­ра­не­то _тряб­ва да се да­де в ръ­це­те на биз­нес-ана­ли­ти­ци­те, ка­то раз­ра­бот­чи­ци­те (в се­гаш­ния сми­съл) са­мо пра­вят ин­с­т­ру­мен­ти­те/ези­ци­те, с ко­и­то ана­ли­ти­ци­те прог­ра­ми­рат. Или, с дру­ги ду­ми, приб­ли­жа­ва­не на (ос­нов­на­та част от) раз­ра­бот­ва­не­то към при­лож­на­та сфе­ра, по-бли­зо до дейс­т­ви­тел­ност­та. Ина­че - виж къ­де сме се­га, из­ра­зя­ва­ме чо­веш­ки нас­т­ро­е­ния ка­то джа­ва и бай­то­ве...

Recently there's a lot of talk about Agile methodology and its "misuse"... Well, "Agile" is like zen-buddhism (see in the library). It's not a religion, and not a silver bullet, but a way of life. It's not a facade to keep, it's about contents. If it's not in the heart - i.e. is only taken by lists and rules and checkboxes - there's no use. And there's no point sticking blindly to it - pick whatever makes u tick. But have in mind that it makes _all_other_ deficiencies come to light.

Then come the agile vs waterfall/cmmi/whatever wars. IMO, the process of making software has to be viewed as a graph, both in time (when) and space (what and _who_). Different metodologies idealize it to be specific kind of graph, e.g. directed, single multi-point-line, spiralling, whatever... and then expect/assume it's the only one, in whole graph. Which is not correct, pieces (person/time/feature) can be of different kind, there's no ONE-and-ONLY way. A screwdriver can be held in numeriious ways in different situations, even with teeth, no? Any particular piece of the overall "graph" can look like some known kind, and then a methodology is applicable to-that-part. Later, for same part - or at same time for another part, or even another person for same piece - it may be another methodology, or even several at same time.

Of course that may look as total chaos, if one expects everything to fit into _same_ brick-shape (regardless how complex the brick is). And of course managing such a "mess" is impossible by ONE man - but when each participant is given their piece, as ownership, it's okay. Each person has his own style, culture, etc... and own processes, approaches... Well, everyone has to be educated to know all the ways to handle a screwdriver, and to be self-disciplined enough to follow them.

So all these "wars"... are only lazyness/reluctance to accept the NO-single-silver-bullet, learn all the ways, and most of all, leave (local-piece-) control to the actual doers.


As of different participant' roles.. Timewise, in a sense, while a developer works on n-th iteration, hir triplet (past,present,future) is (n-1,n,n+1), while business-analyst is at least one lookahead, and might be more than one look behind - say (n-2,n+1,n+5). The architect might also be with wider span, like (n-2, n, n+3)... Of course this is just example, and for one particular discrete thread, in reality there are many threads (e.g. feature-wise or else), with different positioning and spans in each thread, and discretization is not that clear.

In order to allow all this to happen, my solution was to move the BA into the development team, so everyone is at one ear-shot. This causes some initial turmoil - and may not be everyone's spoon, but has been working well...

My vision - more than 10 years already - is that programming _has to be in the hands of BAs, with developers (in current sense) just making the tools/languages for the BAs to program with. Or in other words - to move the (gut of) development closer to the applicational field, closer to the reality. Else - see where we are now, expressing human attitudes in java and bytes...

В пос­лед­нее вре­мя очень мно­го го­во­рит­ся о "Про­вор­ной-ме­то­до­ло­ги­ей" и о "зло­у­пот­реб­ле­ни­ем" с ней... Ну, "Про­вор­ность" как зен-бу­дизм (см. в кон­це ре­ко­мен­ду­емых чте­ний). Это не ре­ли­гия, и не па­на­цея, а спо­соб жиз­ни. Это не воп­рос внеш­не­го ви­да, а воп­рос о со­дер­жа­ни­ем. Ес­ли не при­хо­дит из­нут­ри - т.е. рассмaтри­ва­ет­ся толь­ко как спис­ки и пра­ви­ла да точ­ки - ни­ка­кой пользы не бу­дет. И не­за­чем при­ме­нять бук­валь­но - бе­ри то что нра­вит­ся. Но имей вви­ду что сра­зу уви­дит­ся _все_дру­гое_ что не ра­бо­та­ет.

По­том идут войны - Про­вор­ность и Во­до­пад/CMMI и пр. По мо­е­му, про­цесс де­ла­ния соф­ту­е­ра нуж­но рас­смат­р­ы­вать как граф, во вре­ме­ни (ког­да) и в прос­т­ран­с­т­ве (что, и _кто_). Раз­н­ые ме­то­до­ло­гии иде­а­ли­зи­ру­ют его как ка­кой-ли­бо один спе­ци­фичный вид граф, т.е. на­со­ченный, од­на ло­ман­ная, спи­раль и т.д... и по­том ждут/при­ни­ма­ют что это толь­ко то и мож­но при­ла­гать к все­му гра­фу. Что прос­то не так, раз­н­ые кус­ки (че­ло­век/вре­мя/де­таль) мо­гут быть раз­но­го ви­да, нет ОД­НО­ГО-и-ТОЛЬ­КО-ОД­НО­ГО спо­со­ба. От­вер­т­ку мож­но дер­жать мно­ги­ми спо­со­ба­ми, да­же зу­ба­ми, нет? Каждый ку­сок гра­фа мо­жет быть по­хож на чем-то из­вестным, и тог­да съ­от­вет­с­т­ву­ю­щая ме­то­до­ло­гия при­ло­жи­ма к ним. Поз­же, той же ку­сок - или дру­гой ку­сок в тем же вре­ме­нем - или да­же дру­гой че­ло­век для то­го же кус­ка - мож­но ра­бо­тать дру­гой ме­то­до­ло­ги­ей, да­же нес­коль­ко од­нов­ре­мен­но.

Ко­неч­но, это бу­дет выгля­деть как аб­со­лютный ха­ос, ес­ли на­де­ят­ся что все пой­деть под один шаб­лон (да сколь­ко и сложным он бил). И так­же, уп­рав­лять и сле­дить по­доб­ной "ка­ши" не­воз­мож­но ОД­НИМ че­ло­ве­ком - но ес­ли все учас­т­ни­ки по­лу­чат свой ку­сок как соб­с­т­ве­ность,... мож­но. У каж­до­го че­ло­ве­ка свой стил, куль­ту­ра, ... и свои про­цессы, под­ходы... Ну да, каждый дол­жен быть об­ра­зо­ванным чтобы вла­дел все­ми спо­со­ба­ми дер­жать от­вер­т­ку, и быть дос­та­точ­но са­мо-дис­цип­ли­ни­ро­ванным сле­до­вать ими.

Так что все эти "вой­ни"... толь­ко лень/не­о­хо­та при­нять что НЕТ-один­с­т­вен­ной-се­реб­рян­ной-пу­ли, на­у­чить всех спо­со­бов, и тем-бо­лее, пе­ре­дать (местный) кон­т­роль самым со­вер­ши­те­лям.


А о разных ро­лях учас­т­ни­ков... В ка­ком-то смис­ле, во вре­ме­ни, ес­ли один раз­ра­бот­чик де­ла­ет н-той ите­ра­ции, его трой­ка (прош­лое-нас­то­я­щее-бу­ду­щее) при­мер­но яв­ля­ет­ся (н-1,н,н+1), так как биз­нес ана­ли­тик бу­дет не ме­нее од­но­го ша­га впе­ред, и мо­жет смот­реть и на­зад, напр. (н-2,н+1,н+5). Ар­хи­тект то­же мо­жет быть с ши­ро­ким об­х­ва­том, напр. (н-1,н,н+3)... Ну, ето прос­то при­мер, один низ из (кус­ков) ра­боты; в дейс­т­ви­тель­нос­ти есть мно­го ни­тей (по фун­к­ци­о­наль­нос­ти или др.), каж­дая с раз­ной по­зи­ци­ей и об­х­ва­том, и раз­де­ле­ние на кус­ки мо­жет быть не так яс­но.

Чтобы все это ста­ло воз­можным, мое ре­ше­ние было пе­ре­мес­тить биз­нес-ана­ли­ти­ки в ко­ман­ду раз­ра­бот­чи­ков, так что все были в рас­сто­я­ние "од­но­го уха". Это при­нес­ло до­воль­но­го мел­ле в на­ча­ле, и мо­жет ока­зать­ся лож­кой не для каж­до­го... но ра­бо­та­ет хо­ро­шо.

Мой взгляд - уже боль­ше 10 лет - есть что прог­ра­ми­ро­ва­ни­е­то _дол­ж­но пой­ти в ру­ки биз­нес-ана­ли­ти­ков, так-как раз­ра­бот­чи­ки (в нас­то­я­щем смис­ле) тол­ко де­ла­ют ин­с­т­ру­менты/яз­ыи­ки, ко­тор­ы­ми ана­ли­ти­ки прог­ра­ми­ру­ют. Или, ин­ы­ми сло­ва­ми, приб­ли­зить (ос­нов­ную часть) раз­ра­бат­ы­ва­ния к при­лож­ной сфе­ре, бли­же к дейс­т­ви­тель­нос­ти. А то - смот­ри где мы сей­час, выра­жа­ем че­ло­вес­кие нас­т­ро­е­ния в джа­ву и байты...


писалка на тефтер | ballpen on notebook

Детски нещаKids' thingsДетские вещи
книжкиbooksкнижки
творения:легоcreations:legoтворения:лего

БиблиотекаLibraryБиблиотека
снимкиphotosфотографии
хайкуhaikuхайку
Коджа кая 2019Kodzha kaia 2019Коджа кая 2019
направи самdo it yourselfсделай сам

софтуерът-и-азsoftware-and-iсофтуер-и-я
биоcvбио

'2008-2019 ~ началоstartначало ~ софтуерът-и-азsoftware-and-iсофтуер-и-я ~ биографияcv/resumeбиография ~ библиотекаlibraryбиблиотека ~ снимкиphotosфотографии ~ детскиkids'детские ~   az()svilendobrev _ com