software making as graph | правенето на софтуер като граф

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

После, идват войните Пъргава методология с/у Водопадна/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 лет - есть что програмированието _должно пойти в руки бизнес-аналитиков, так-как разработчики (в настоящем смисле) толко делают инструменты/языики, которыми аналитики програмируют. Или, иными словами, приблизить (основную часть) разрабатывания к приложной сфере, ближе к действительности. А то - смотри где мы сейчас, выражаем человеские настроения в джаву и байты...

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