Ме­то­до­ло­гия и раз­ра­бот­ка на соф­ту­ер - от хо­ра, за хо­ра. Пър­га­во. Methodology and development of software - by people, for people. Agile. Ме­то­до­ло­гия и раз­ра­бот­ка соф­ту­е­ра - от лю­дей, для лю­дей. Про­вор­но.

А жи­во­тът е про­мя­на.

And life is change.

А жизнь есть пе­ре­ме­на.

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

So, i make (software) projects from ideas, people and software. Be it possible or not, and regardless what has to change - software, organisation, people, or me.

Ну, я де­лаю (соф­ту­ер­н­ые) про­екты из идей, лю­дей и соф­та. Были-бы они Воз­мож­н­ы­ми или нет, и не­за­ви­си­мо че­го нуж­но из­ме­нять - соф­ту­ер, ор­га­ни­за­ция, лю­ди или ме­ня.

Идеи ..

Ideas ..

Идеи..

• Garden of personal notions Гра­ди­на на лич­ни­те по­ня­тия Ого­род личных по­ня­тий

  This should be a System that helps you do "routine" activities like remembering, learning and expressing yourself, about your known things.

  То­ва тряб­ва да е Сис­те­ма ко­я­то ти по­ма­га да пра­виш "ру­тин­ни" дей­нос­ти ка­то за­пом­ня­не, на­у­ча­ва­не и се­бе­из­ра­зя­ва­не, от­нос­но поз­на­ти­те ти не­ща.

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

• my software - dbcook, kiosk-demo, hyphenation, Python in bulgarian, and what not мой соф­ту­ер - dbcook, ки­оск-де­мо, срич­коп­ре­на­ся­не, Пи­тон на бъл­гар­с­ки, и как­во ли още не мой софт - dbcook, ки­оск-де­мо, сло­во-пе­ре­нос, Пи­тон на бол­гар­с­ким, и вся­кое ..

мо­то-та, от ав­то­би­ог­ра­фи­я­та ми

motto-s, from my cv/resume

мот­то, из ав­то­би­ог­ра­фии

• На­ме­ри си при­я­тел да бъ­де тво­и­те се­ти­ва.
• Не мо­жеш да нап­ра­виш свес­тен ин­с­т­ру­мент/не­що, ако ни­ко­га не си му бил пот­ре­би­тел.
• Нап­ра­виш ли не­що да мо­гат да го пол­з­ват иди­о­ти, са­мо иди­о­ти ще го пол­з­ват.
• Ези­ци­те са ин­с­т­ру­мен­ти. Ако има под­хо­дя­щи, пол­з­вай ги. Ако ня­ма, нап­ра­ви си!
• Асо­ци­а­ци­и­те са ве­ли­ко не­що - вяр­вай на соб­с­т­ве­ния си (ин­ту­и­ти­вен) нюх.
• Соф­ту­е­рът всъщ­ност е за и от­нос­но хо­ра­та, а не за и от­нос­но ма­ши­ни­те.
• До­ве­ри­е­то е същ­ност­та на пра­ве­не­то на соф­ту­ер. Ма­ши­на­та има 100% до­ве­рие на прог­ра­мис­та... до­ка­то на дру­гия край хо­ра­та изоб­що си ня­мат до­ве­рие. Чо­век тряб­ва да ре­ши къ­де е в та­зи ре­дич­ка - кол­ко до­ве­рие и не­до­ве­рие мо­жеш да по­не­сеш?
• www-Mре­жа­та пра­ви све­тов­но­то се­ло - та­ка че _всич­ко_ и все­ки е на поч­ти-ну­ле­во "раз­с­то­я­ние". Но НИ­КО­ГА ну­ле­во. А по­ня­ко­га чо­век се нуж­дае точ­но от то­ва - ле­ко до­кос­ва­не - или до­бър рит­ник...

• Find a friend to be your senses.
• One can't make a decent tool/thing if never has been an user of it.
• If you make something to be usable by idiots, only idiots will use it.
• Language is a tool. If there is one suitable, use it. If not, make it!
• Association is a great thing - trust your common (intuitional) sense.
• Software is actually about people, not about machines.
• Trust is the essence of making software. The machine trusts the programmer 100%... while at the other end people don't trust each other at all. One has to position hirself in this chain - how much trust and distrust you can handle?
• www-web makes the global village - so _everything_ and everyone is at near-zero "distance". But NEVER zero. And sometimes one needs just that - a warm touch - or good kick...

• Най­ди се­бе дру­га, ко­торый был бы твои ощу­ще­ния.
• Не мо­жешь сде­лать хо­ро­ший ин­с­т­ру­мент/что­то, ес­ли ни­ког­да не был его пот­ре­би­те­лем.
• Ес­ли сде­ла­ешь что­то упот­реб­ля­е­мое иди­о­та­ми, толь­ко иди­оты бу­дут его поль­зо­вать.
• Яз­ы­ки яв­ля­ют­ся ин­с­т­ру­мен­та­ми. Ес­ли есть под­хо­дя­щие, поль­зо­вай их. Ес­ли нет, сде­лай сам!
• Ас­со­ци­а­ция - ве­ли­кая шту­ка. Верь сво­е­му соб­с­т­вен­но­му (ин­ту­и­тив­но­му) но­су.
• В сущ­нос­ти Соф­ту­ер есть для и о лю­дей, а не для и о ма­шин.
• До­ве­рие яв­ля­ет­ся сущ­нос­тью все­го из­го­тов­ле­ния соф­ту­е­ра. Ма­ши­на до­ве­ря­ет прог­ра­мис­ту на 100%... а на дру­гом по­лю­се лю­ди во­об­ще не до­ве­ря­ют друг дру­га. Че­ло­век дол­жен най­ти свое мес­то в этой це­пи - сколь­ко до­ве­рия и не­до­ве­рия ты смо­жеш нес­ти?
• www-Сеть де­ла­ет ми­ро­вую де­рев­ню - так что "рас­сто­я­ние" до _всех_ и до _все­го_ поч­ти-ну­ле­вое. Но НИ­КОГ­ДА ну­ле­вое. А че­ло­век иног­да нуж­да­ет­ся точ­но в этим - лег­кое при­кос­но­ве­ние - или хо­ро­ший пи­нок...

Как­во мис­ля ..

What i think ..

Что я ду­маю ..

• Опи­са­ние на ме­то­до­ло­ги­я­та в един мой про­ект Description of methodology in one of my projects Опи­са­ние ме­то­до­ло­гии в од­ном из мо­их про­ек­тов

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

  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.

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

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

  Then come the agile vs waterfall/cmmi 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. single multi-point-line, spiral, 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, so all these "wars"... are because of 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.

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

  По­том, идут вой­ни Про­вор­ной ме­то­до­ло­гии с/у Во­до­пад­ной/CMMI и т.д. По мо­е­му, про­цес соз­да­ния соф­ту­е­ра на­до рас­смат­ри­вать как граф, во вре­ме­ни (ког­да) и в прос­т­ран­с­т­ве (что, и _кто_). Раз­н­ые ме­то­до­ло­гии иде­а­ли­зи­ру­ют его как спе­ци­фичный вид граф, т.е. ори­ен­ти­ро­ванный, од­на ло­ман­ная ли­ния, спи­раль и т.д... и по­том ждут/при­ни­ма­ют что это один­с­т­венный спо­соб и при­ло­жим он по все­му гра­фу. Что прос­то не вер­но, от­дель­н­ые кус­ки (че­ло­век/вре­мя/де­тайль) мо­гут быть раз­н­ы­ми ви­да­ми. Так что все эты "вой­ни"... толь­ко лень/не­же­ла­ние при­нять что НЕТ-один­с­т­вен­ной-се­реб­ря­ной-пу­ли, выу­чить все спо­собы, и тем-бо­лее, пе­ре­дать (местный) кон­т­роль са­мим со­вер­ши­те­лям.

• Кри­за? Как­ва кри­за? или ефи­кас­но­то пра­ве­не на ефек­ти­вен соф­ту­ер Crisis? What crisis? or the efficient making of effective software Кри­зис? Ка­кой кри­зис? или еф­фи­кас­но де­лать еф­фек­тивный соф­ту­ер
• Аут­сор­синг, иш­ле­ме, гло­бал­на раз­ра­бот­ка на соф­ту­ер - из­на­ся­не и раз­п­ре­де­ля­не на ра­бо­та, ге­ог­раф­с­ки или не... пре­диз­ви­ка­тел­с­т­ва на об­щу­ва­не­то Outsourcing, offshoring, global software development - taking out and distributing work, geographically or not... challenges of communication Аут­сор­синг, оф­шо­ринг, гло­бал­ная раз­ра­бот­ка соф­та - выно­сить и рас­п­ре­де­лять ра­бо­ту, ге­ог­раф­с­ки или нет... пре­диз­ви­ка­тель­с­т­ва об­ще­ния
• изис­к­ва­ния, ана­лиз, спе­ци­фи­ка­ция... най-важ­на­та връз­ка, без ко­я­то не мо­же. requirements, analysis, specification... the most important link that can not be missing. тре­бо­ва­ния, ана­лиз, спе­ци­фи­ка­ция... са­мое важ­ное зве­но, без ко­то­ро­го нель­зя.

  А ос­нов­ни­те ин­с­т­ру­мен­ти в пра­ве­не­то на соф­ту­ер са... пра­вил­ни­те въп­ро­си. Би­ли те 3-те ни­ва в слу­чай на упот­ре­ба (use-case: за­що-как­во-как), или ви­да прог­ра­ми­ра­не - про­це­дур­но (как), фун­к­ци­о­нал­но (как­во), при­чи­но-след­с­т­ве­но (за­що), обек­т­но (кой) ... или прос­то­то съм­ня­ва­що се "Да­ли тряб­ва".

  And main tools in software making are... the right questions. Were they the 3 levels in a use-case (why-what-how), or the kind of programming - procedural (how), functional (what), reason-goal (why), object-oriented (who) ... or the simple doubting "Whether it should".

  А ос­нов­н­ые ин­с­т­ру­менты в соз­да­нии соф­ту­е­ра это... пра­виль­н­ые воп­росы. Были бы они 3 уров­ня в слу­чае поль­зо­ва­ния (use-case: по­че­му-что-как), или вид прог­рам­ми­ро­ва­ния - про­це­дур­ное (как), фун­к­ци­о­нал­ное (что), при­чи­но-след­с­т­ве­ное (по­че­му), обек­т­ное (кто) ... или прос­тое сом­не­ва­ю­ще­е­ся "Да-на­до-ли".

  I keep six honest serving-men (They taught me all I knew); Their names are What and Why and When And How and Where and Who. Rudyard Kipling Слу­ги аз имам шест на брой от стран­но ес­тес­т­во. На­ри­чат се: За­що, Как, Кой, Ко­га, Къ­де, Как­во. Ръ­ди­ард Кип­линг Есть у ме­ня шес­тер­ка слуг, Про­ворных, удалых. Зо­вут их: Как и По­че­му, Кто, Что, Ког­да и Где. Редьярд Кип­линг

  Доб­ре е да мо­жеш да си (из­би­ра­тел­но) глу­пав.

  One should be able to be (selectively) stupid.

  Хо­ро­шо чтоб мог быть (выби­ра­тель­но) глупым.

• тес­т­ва­не­то - не­що­то, без ко­е­то не тряб­ва (всъщ­ност ви­на­ги го има... край­ния пот­ре­би­тел) testing - the thing that should not be missing (actually it's always there... end-user) тес­ти­ро­ва­ние - шту­ка, без ко­то­рой не на­до (всущ­нос­ти ее всег­да есть - ко­неч­ний поль­зо­ва­тель)

If you want to do a
  certain thing
  You first have to be a
   certain person.
Once you have become
  that certain person
  you will not care any more
   about doing that certain thing.

       - Dogen

Ако ис­каш да нап­ра­виш
  оп­ре­де­ле­но не­що
  Ти пър­во тряб­ва да ста­неш
   оп­ре­де­лен чо­век.
Вед­нъж ка­то ста­неш
  то­зи оп­ре­де­лен чо­век
  ня­ма да те е гри­жа ве­че
   за пра­ве­не­то на
    оно­ва оп­ре­де­ле­но не­що.

       - До­ген

Ес­ли хо­чеш сде­лать
  че­го-то оп­ре­де­лен­но­го
  Те­бе на­до спервым стать
   оп­ре­де­ленным че­ло­ве­ком.
Ког­да уже бу­дешь
  этим оп­ре­де­ленным че­ло­ве­ком
  ты боль­ше не бу­дешь
   за­бо­тить­ся де­лать
    то­го оп­ре­де­лен­но­го че­го-то.

       - До­ген

Recommended readings Пре­по­ръч­вам за че­те­не Ре­ко­мен­дую для чте­ния

Ето ня­кои не­ща за соф­ту­е­ра, ко­и­то пре­по­ръч­вам ка­то ос­но­во­по­ла­га­щи:

Here some things about software, which i recommend as fundamental:

Вот не­ко­тор­ые ве­щи о соф­ту­е­ре, ко­торых я ре­ко­мен­дую как ос­но­во­по­ла­га­ю­щие:

• Software Engineering book - Ian Sommerville (Соф­ту­ер­но ин­же­нер­с­т­во - Ян Со­мър­вил) (Соф­ту­ер­ное ин­же­нер­с­т­во - Ян Со­мер­виль) - amazon8 - amazon6
  То­ва е Кни­га­та за соф­ту­е­ра ка­то ин­же­нер­на на­у­ка. В нея има всич­ко. За те­ма­та "ста­ри сис­те­ми" (legacy software), виж по-ста­ро­то 6-то из­да­ние (чер­но­то). This is The Book about software as engineering science. There is everything in it. On topic of legacy software, see the older 6th edition (black). Это Кни­га о соф­ту­е­ре как ин­же­нер­ная на­у­ка. В ней есть все. Для темы о "старых сис­тем" (legacy software), смот­ри на ста­рое 6-ое из­да­ние (чер­ное).
• Design patterns book (Erich Gamma et al -- Gang of Four, GOF) (Про­ек­тан­т­с­ки шаб­ло­ни - Ерих Га­ма и др, бан­да­та на че­ти­ри­ма­та) (Про­ек­тан­т­с­кие шаб­лоны - Ерих Гам­ма и др, груп­па че­ти­рех) - wikipedia
  This is a book with important role in software development. It's a bit watered with example code. See wikipedia for a list of the patterns. То­ва е кни­га с мно­го важ­на ро­ля в раз­ра­бот­ка­та на соф­ту­ер. Мал­ко е раз­вод­не­на с при­ме­рен код. Виж уи­ки­пе­дия за спи­съ­ка от шаб­ло­ни/об­раз­ци (patterns). Это кни­га очень важ­ной ро­ли в раз­ра­бот­ке соф­ту­е­ра. Хо­тя там из­лиш­но мно­го при­мер­но­го ко­да. Смот­ри на уи­ки­пе­дия для спис­ка шаб­ло­нов/об­раз­цов (patterns).
• Usability Engineering book - Jakob Nielsen (Из­пол­з­ва­е­мост - Якоб Нил­сен) (Ис­поль­зо­ва­е­мость - Якоб Ниль­сен) - wikipedia
  То­ва е Кни­га­та по те­ма­та Из­пол­з­ва­е­мост. На­со­че­на е към соф­ту­е­ра, но за­ло­же­ни­те прин­ци­пи са об­що­ва­лид­ни за вся­как­ви пот­ре­би­тел­с­ки ин­тер­фей­си (напр. уп­рав­ле­ние на ка­се­то­фон или ав­то­мо­бил). Об­що-ин­те­рес­ни са пър­ви­те ня­кол­ко час­ти. This is the Book about Usability. It is targeted at software but the underlying principles are generally valid for all kinds of user interfaces (e.g. controls of a tapedeck or a car). Of general interest are the first several chapters. Это Кни­га о Ис­поль­зо­ва­е­мос­ти. Пред­наз­на­чен­ная для соф­ту­е­ра, но прин­ципы яв­ля­ют­ся об­що­ва­лид­н­ы­ми для вся­ких пот­ре­би­тель­с­ких ин­тер­фей­сов (напр. уп­рав­ле­ние ра­ди­олы или ав­то­мо­би­ля). Об­що-ин­те­рес­н­ые - пер­в­ые нес­коль­ко час­ти.
• Organisational patterns book - James Coplien, Neil Harrison (Ор­га­ни­за­ци­он­ни шаб­ло­ни - Джеймс Коп­ли­ен, Нийл Ха­ри­сън) (Ор­га­ни­за­ци­он­ние шаб­лоны - Джеймс Коп­ли­ен, Нийл Ха­ри­сон)
  То­ва е "биб­лия" на те­ма ор­га­ни­за­ци­он­на кул­ту­ра и об­щу­ва­не. На­со­че­на е към пра­ве­не на соф­ту­ер, но би би­ла по­лез­на и за дру­ги (твор­чес­ки) дей­нос­ти. От­къ­си: This is a "bible" about organisational culture and communication. It is targeted at software, but can be useful for other (creative) activities. Excerpts: Это "биб­лия" по те­ме ор­га­ни­за­ци­он­ной кул­туры и об­ще­ния. На­со­че­на она к соз­да­нию соф­ту­е­ра, но мог­ла быть по­лез­ной и для дру­гих (твор­чес­ких) де­я­тель­нос­тей. От­р­ы­в­ки:
  • Summary Patlets (нак­рат­ко, всич­ки­те) (ко­ро­че, все)
  • 6.1. Priming The Organization For Change (под­гот­вя­не за Про­мя­на­та) (при­гот­вить­ся к Пе­ре­ме­не)
    ми­ри­ше на про­мя­на... ако се уп­рав­ля­ва чрез кри­зи, или от­бо­рът е пре­го­рял... smells of change... if managed by crises, or the team is overburned... пах­нет пе­ре­ме­ной... ес­ли уп­рав­ля­ють кри­зи­са­ми, или ко­ман­да пе­ре­го­ре­ла...

  ---

• Ма­ни­фест на съв­мес­т­на­та иг­ра - Алис­тар Ко­бърн и др. Cooperative game manifesto - Alistair Cockburn et al Ма­ни­фест сов­мес­т­ной игры - Алис­тар Ко­бърн и др.
  

  " Software development is a series of resource-limited, goal-directed cooperative games of invention and communication. The primary goal of each game is the production and deployment of a software system; the residue of the game is a set of markers to assist the players of the next game. People use markers and props to remind, inspire and inform each other in getting to the next move in the game. The next game is an alteration of the system or the creation of a neighboring system. Each game therefore has as a secondary goal to create an advantageous position for the next game. Since each game is resource-limited, the primary and secondary goals compete for resources. "

  " Раз­ра­бот­ка­та на соф­ту­ер е пос­ле­до­ва­тел­ност от съв­мес­т­ни иг­ри на изоб­ре­тя­ва­не и об­щу­ва­не, с оп­ре­де­ле­на цел, при ог­ра­ни­че­ни ре­сур­си. Ос­нов­на­та цел на вся­ка иг­ра е нап­ра­ва и внед­ря­ва­не на да­де­на соф­ту­ер­на сис­те­ма; след иг­ра­та ос­та­ват на­бор от бе­ляз­ки (мар­ки­ров­ка), ко­и­то да под­по­мог­нат иг­ра­чи­те при след­ва­ща­та иг­ра. Хо­ра­та из­пол­з­ват те­зи бе­ляз­ки за да си на­пом­нят, да се вдъх­но­вя­ват и ос­ве­до­мя­ват един друг по пъ­тя към след­ва­щия ход в иг­ра­та. След­ва­ща­та иг­ра мо­же да е за про­мя­на на соф­ту­е­ра, или за съз­да­ва­не на друг. Та­ка че вся­ка иг­ра има за вто­рич­на цел съз­да­ва­не­то на бла­гоп­ри­ят­ни по­зи­ции за след­ва­ща­та иг­ра. И тъй-ка­то вся­ка иг­ра е ог­ра­ни­че­на от­към ре­сур­си, пър­вич­на­та и вто­рич­на­та цел се над­п­ре­вар­ват за те­зи ре­сур­си. "

  " Раз­ра­бот­ка соф­ту­е­ра пред­с­тав­ля­ет пос­ле­до­ва­тел­ность сов­мес­т­них игр на изоб­ре­те­ние и об­ще­ние, имея оп­ре­де­лен­ной це­ли при ог­ра­ни­чен­них ре­сур­сов. Ос­нов­ная цель каж­дой игры - соз­да­ние и внед­ре­ние ка­кой-то соф­ту­ер­ной сис­темы; ос­та­ток пос­ле игры яв­ля­ет­ся на­бор ме­ток (мар­ки­ров­ка), чтобы по­мочь иг­ро­кам сле­ду­ю­щей игры. Лю­ди ис­поль­зу­ют эти мет­ки и опоры для на­по­ми­на­ния, вдох­нов­ле­ния и ос­ве­дом­ле­ния друг дру­га по пу­ти к сле­ду­ю­ще­му хо­ду в иг­ре. Сле­ду­ю­щая иг­ра мо­жет бить о пе­ре­ме­не той са­мой сис­темы, или о соз­да­нии дру­гой. Так что у каж­дой иг­ре есть вто­рич­ная цель на соз­да­ва­ние бла­гоп­ри­ят­них по­зи­ций для сле­ду­ю­щей игры. И так-как каж­дая иг­ра ог­ра­ни­че­на ре­сур­са­ми, пер­вич­ная и вто­рич­ная це­ли сос­тя­за­ють­ся об этих ре­сур­сах. "

  виж съ­що Раз­ра­бот­ка­та на соф­ту­ер ка­то съв­мес­т­но пи­са­не на по­е­зия

  see also Software development as community poetry writing

  см. то­же Раз­ра­бот­ка соф­ту­е­ра как сов­мес­т­ное пи­са­ние по­е­зии

• Дек­ла­ра­ция на вза­и­мо­за­ви­си­мост­та - Declaration of interdependence - Дек­ла­ра­ция вза­и­мо­за­ви­си­мос­ти -
  

  "We ...

  • increase return on investment by -- making continuous flow of value our focus.
  • deliver reliable results by -- engaging customers in frequent interactions and shared ownership.
  • expect uncertainty and manage for it through -- iterations, anticipation and adaptation.
  • unleash creativity and innovation by -- recognizing that individuals are the ultimate source of value, and creating an environment where they can make a difference.
  • boost performance through -- group accountability for results and shared responsibility for team effectiveness.
  • improve effectiveness and reliability through -- situationally specific strategies, processes and practices. "

  "Ние ...

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

  "Мы...

  • уве­ли­чи­ва­ем воз­в­ра­ща­е­мость ин­вес­ти­ции че­рез -- сос­ре­до­то­чи­ва­ние на неп­рерывный по­ток цен­нос­тей.
  • да­ем на­деж­д­них ре­зуль­та­тов че­рез -- вклю­че­ние кли­ен­та в час­т­ые вза­и­мо­дейс­т­вия и раз­де­ле­ние соб­с­т­ве­нос­ти.
  • ожи­да­ем не­у­ве­рен­ность и справ­ля­ем­ся ей че­рез -- ите­ра­ции, ожи­да­ние и прис­по­соб­ли­ва­ние.
  • да­ем сво­бо­ду со­зи­да­тель­нос­ти и но­вов­ве­де­ни­ям че­рез -- приз­на­ва­ние лич­нос­тях как пер­во­ис­точ­ник цен­нос­тей, и соз­да­ние среды, где они мог­ли раз­вер­т­ы­ват­ся.
  • по­ви­ша­ем про­из­во­ди­тель­ность че­рез -- груп­по­вая от­чет­ность о ре­зуль­та­тах и раз­де­ляя от­го­вор­ность об ефи­кас­нос­ти ко­манды.
  • улуч­ша­ем ефи­кас­ность и на­деж­д­ность че­рез -- спе­ци­фич­н­ые для си­ту­а­ции стра­те­гии, про­цессы и ме­тоды. "

  виж съ­що Ма­ни­фест на Пър­га­вост­та:

  see also Agile manifesto:

  см. то­же Ма­ни­фест Про­вор­носты:

  ... we value:
  Individuals and interactions - over processes and tools;
  Working software - over comprehensive documentation;
  Customer collaboration - over contract negotiation;
  Responding to change - over following a plan;

  ... ние це­ним по­ве­че:
  Лич­нос­ти­те и вза­и­мо­дейс­т­ви­я­та - от­кол­ко­то про­це­си­те и ин­с­т­ру­мен­ти­те;
  Ра­бо­те­щия соф­ту­ер - от­кол­ко­то из­чер­па­тел­на­та до­ку­мен­та­ция;
  Сът­руд­ни­чес­т­во­то с кли­ен­та - от­кол­ко­то пре­до­го­ва­ря­не­то;
  Ре­а­ги­ра­не­то на про­ме­ни­те - от­кол­ко­то след­ва­не­то на пла­на;

  ... мы це­ним боль­ше:
  Лич­нос­ти и вза­и­мо­дейс­т­вия - чем про­цессы и ин­с­т­ру­менты;
  Ра­бо­та­ю­щий соф­ту­ер - чем об­шир­ная до­ку­мен­та­ция;
  Сот­руд­ни­чес­т­во с кли­ен­том - чем пре­до­го­ва­ри­ва­ние;
  Ре­а­ги­ро­вать на пе­ре­мены - чем сле­до­ва­ние пла­на;

• Край на соф­ту­ер­но­то ин­же­нер­с­т­во - за­поч­ват ико­но­ми­чес­ки-съв­мес­т­ни­те иг­ри - Алис­тар Ко­бърн The end of software engineering and the start of economic-cooperative gaming - Alistair Cockburn Ко­нец соф­ту­ер­но­го ин­же­нер­с­т­ва и на­ча­ло эко­но­ми­чес­ки-сов­местных игр - Алис­тар Ко­бърн .
  

  "... This means the speed of the project is proportional to the speed at which information moves between people's heads. Every obstacle to detecting and moving information between heads slows the project. Understanding and attending to this issue is essential to playing the game effectively. ..."

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

  "... Это зна­чит что ско­рость про­ек­та пра­во про­пор­ци­о­наль­на ско­рос­ти пе­ред­ви­же­ния ин­фор­ма­ции меж­ду го­лов лю­дей. Каж­дое пре­пят­с­т­вие об­на­ру­жи­ва­нию и пе­ре­да­чу ин­фор­ма­ции меж­ду го­лов за­мед­ля­ет про­ект. По­ни­ма­ние это­го тре­бо­ва­ния и за­бо­та о нем яв­ля­ет­ся из­к­лю­чи­тель­но важ­ной для ефек­тив­ной иг­ре. ..."

• "Crystal Clear - A Human-Powered Methodology For Small Teams", 1998-2004, Alistair Cockburn incl. The Seven Properties of Effective Software Projects ( Крис­тал­но-Яс­на - Дви­же­на-от-хо­ра Ме­то­до­ло­гия за мал­ки от­бо­ри, вкл. Се­дем­те свойс­т­ва на Ефек­тив­ни­те соф­ту­ер­ни про­ек­ти, Алис­тар Ко­бърн ) ( Крис­таль­но-Яс­ная - Дви­жи­мая-лю­дя­ми Ме­то­до­ло­гия для малых ко­манд, вкл. Семь свойс­т­ва Ефек­тив­них соф­ту­ерных про­ек­тов, Алис­тар Ко­бърн )

  Пол­з­вам та­зи ме­то­до­ло­гия от 5-6 го­ди­ни. При­ли­ча на Скрум, има си и мал­ко те­о­рия, ка­то най-млад­ша от се­мейс­т­во­то Крис­тал­ни ме­то­до­ло­гии. Об­що-ин­те­рес­ни­те час­ти са 1,2 и 9 (как­во и за­що); ос­та­на­ло­то са под­роб­нос­ти (как):

  i am using this methodology for 5-6 years now. It is similar to Scrum, and has some theory to it, being lightest in the family of Crystal methodologies. Chapters of general interest are 1,2 and 9 (what and why); the rest is details (how):

  Я упот­реб­ляю эту ме­то­до­ло­гию уже 5-6 лет. На­по­доб­ля­ет Скрум, име­ет и нем­нож­ко те­о­рии, яв­ля­ясь млад­шей из семьи Крис­таль­них ме­то­до­ло­гий. Час­ти об­ще­го ин­те­ре­са - 1,2 и 9 (что и по­че­му); ос­таль­ное есть под­роб­нос­ти (как):

  • wikipedia ; опи­са­ние overview опи­са­ние ; ос­но­ва и ме­то­ди background and methods ос­но­ва и ме­то­ди
  • част 2: Свойс­т­ва­та, ори­ги­нал chapter 2 - The properties част 2: Свойс­т­ва, ори­ги­нал ; пре­вод на част 2: Свойс­т­ва­та translation of chapter 2 in bulgarian пе­ре­вод 2 час­ти на бол­гар­с­ком
• шу-ха-ри shu-ha-ri шу-ха-ри
  • 3 ни­ва на слу­ша­те­ли­те 3 levels of audience 3 уров­ня слу­ша­те­лей
  • 4 ни­ва на зна­е­не 4 levels of competence 4 уров­ня зна­ния
  • 5 сте­пе­ни на нез­на­ние 5 orders of ignorance 5 сте­пе­ни нез­на­ния

  ---

• Пре­жи­вя­ва­не­то е Всич­ко - Дон Нор­ман It's all about experience - Don Norman Пе­ре­жи­ва­ние есть Все - Дон Нор­ман , Business of software'2009 - ви­део фай­ло­ве video files ви­део файлы
  
  1. This must be watched, whole.
  2. This must be watched, whole.
  3. This must be watched, whole. .. See?
  4. The only real thing (about software) is the taste that's left in your mouth.
  1. То­ва тряб­ва да се гле­да, ця­ло­то.
  2. То­ва тряб­ва да се гле­да, ця­ло­то.
  3. То­ва тряб­ва да се гле­да, ця­ло­то. .. Ви­дя ли?
  4. Един­с­т­ве­но­то важ­но не­що (в соф­ту­е­ра) е вку­са кой­то ос­та­ва в ус­та­та.
  1. Это­го на­до смот­реть, все­го.
  2. Это­го на­до смот­реть, все­го.
  3. Это­го на­до смот­реть, все­го. .. Ви­дел?
  4. Один­с­т­ве­ное важ­ное де­ло (в соф­ту­е­ре) есть вкус ко­торый ос­та­ет­ся во рту.
• Meeting the Spec and Other Software Fables (Да пок­ри­еш изис­к­ва­ни­я­та и Дру­ги соф­ту­ер­ни сю­же­ти) (Выпол­нить спе­ци­фи­ка­цию и Дру­гие соф­ту­ер­н­ые сю­жеты) 1993 Michael Meier (or metaphysics of software quality) Май­къл Ме­йер (или ме­та­фи­зи­ка на соф­ту­ер­но­то ка­чес­т­во) Майкл Ме­йер (или ме­та­фи­зи­ка ка­чес­т­ва соф­ту­е­ра)

  Warm fuzzies... aren't in the spec. But products lacking warm fuzzies will never be considered more than average. Warm fuzzies, guts feelings, are quality. Not the fiscal year bottom line. Happiness isn't technology. Fun has no price tag. The trick is, usualy we do not detect the presence of warm fuzzies, we detect their absence...

  Топ­ло усе­ща­не... ня­ма в спе­ци­фи­ка­ци­я­та. Но из­де­лие не пре­диз­вик­ва­що топ­ло усе­ща­не, ни­ко­га не се счи­та за по­ве­че от пос­ред­с­т­ве­но. Топ­ло­то вът­реш­но усе­ща­не е ка­чес­т­во. Не фи­нан­со­вия ре­зул­тат за го­ди­на­та. Щас­ти­е­то не е в тех­но­ло­ги­я­та. Ке­фът це­на ня­ма. Но­ме­рът е там, че обик­но­ве­но не усе­ща­ме на­ли­чи­е­то на топ­ло чув­с­т­во, но мно­го доб­ре усе­ща­ме лип­са­та му...

  Теп­лое ощу­ще­ние... та­ко­го нет в спе­ци­фи­ка­ции. Но из­де­лие ко­то­рое не вызи­ва­ет теп­лих ощу­ще­ний, не оце­ни­ва­ет­ся боль­ше чем пос­ред­с­т­вен­ное. Теп­л­ые внут­рен­ные ощу­ще­ния и есть ка­чес­т­во. Не фи­нан­со­вий ре­зуль­тат го­да. Счас­тье не в тех­но­ло­гии. У удо­воль­с­т­вия цены нет. Трик в том, что об­ы­ч­но не уз­на­ем на­ли­чие теп­ло­го ощу­ще­ния, но всег­да уз­на­ем ког­да его нет...

• On the cruelty of really teaching computing science; (За жес­то­кост­та на­ис­ти­на да обу­ча­ваш по из­чис­ли­тел­ни на­у­ки) (О жес­то­кос­ти во­ис­ти­не обу­чать в вычис­ли­тель­них на­у­ках) 1988 lecture by E.W.Dijkstra лек­ция от Е.Дийк­с­т­ра лек­ция Э.Дийк­с­т­ра

  The "How to program if you cannot" science... Whether IT (or technology at large) has since progressed even a bit into right direction, or... Are the actual pursued values+outcome the right real one, or a bogus substitute... Whether we learned to tailor the machines to the job or instead, tailor the job to the machines...

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

  На­у­ка "Как прог­ра­ми­ро­вать ес­ли не уме­еш"... Уш­ла ли ВТ (или тех­но­ло­гия во­об­ще) с тех пор хоть нем­нож­ко в пра­виль­ную сто­ро­ну или... Яв­ля­ют­ся ли ис­ком­ые цен­нос­ти+ре­зуль­таты пра­виль­н­ы­ми и сущ­нос­т­н­ы­ми, или пус­той за­мес­ти­тель ка­кой-то... На­у­чи­лись ли мы прис­по­соб­лять ма­шин к ра­бо­ту, или нап­ро­тив, прис­по­соб­ля­ем ра­бо­ту к ма­ши­нам...

• The Laws of Software Process: A New Model for the Production and Management of Software, 2003, Phillip Armour; (За­ко­ни на соф­ту­ер­ния про­цес: Нов мо­дел за про­из­вод­с­т­во и уп­рав­ле­ние на соф­ту­ер, Фи­лип Ар­мур) (За­коны соф­ту­ер­но­го про­цес­са: Но­вая мо­дель про­из­вод­с­т­ва и уп­рав­ле­ния соф­ту­е­ра, Фил­лип Ар­мур)

  Software as knowledge medium, and effects thereof

  Соф­ту­е­рът ка­то но­си­тел на зна­ние, и про­из­ти­ча­щи­те пос­лед­с­т­вия

  Соф­ту­ер как но­си­тель зна­ния, и выте­ка­ю­щие пос­лед­с­т­вия

  ... software is not a product but a medium for storing knowledge, and software development is not a product-producing activity, it is a knowledge-acquiring activity.

  ... the real job is not writing the code, or even building the system - it is acquiring the necessary knowledge to build the system... Code is simply a by-product of this activity. The problem arises when we think the code, rather than the knowledge in the code, is the product.

  ... When we use models and mindsets that are rigid and deterministic to manage an activity that is fluid and variable, it is not surprising that people get disappointed.

  ... соф­ту­е­рът не е про­дукт, а сре­да за съх­ра­не­ние на зна­ния, и раз­ра­бот­ка­та му не е про­из­вод­с­т­во на про­дук­ти, а при­до­би­ва­не на зна­ния.

  ... ис­тин­с­ка­та ра­бо­та не е да се на­пи­ше ко­дът, или до­ри да се пос­т­рои сис­те­ма­та - тя е да се при­до­бие нуж­но­то зна­ние за пос­т­ро­я­ва­не на сис­те­ма­та... Ко­дът е са­мо стра­ни­чен про­дукт от та­зи дей­ност. Бе­ля­та ид­ва ка­то за­поч­нем да си мис­лим, че ко­да е про­дук­та, а не зна­ни­е­то в не­го.

  ... Ка­то се пол­з­ват твър­ди и (пред)оп­ре­де­ле­ни мо­де­ли и пред­с­та­ви, за да се уп­рав­ля­ва дей­ност про­мен­ли­ва и не­яс­на, не е из­не­над­ва­що че хо­ра­та се ра­зо­ча­ро­ват.

  ... соф­ту­ер не про­дукт, а сре­да сoхра­не­ния зна­ний, и его раз­ра­бот­ка не про­из­вод­с­т­во про­дук­тов, а по­лу­че­ние зна­ний.

  ... нас­то­я­щее де­ло не в на­пи­са­ни­ем ко­да, или да­же не в пос­т­ро­е­ни­ем сис­темы - оно в по­лу­че­ния нуж­но­го зна­ния для пос­т­ро­е­ния сис­темы... Код есть прос­то пос­то­рон­ныий про­дукт етой де­я­тель­нос­ти. Бе­да при­хо­дит как нач­нем ду­мать, что код и есть про­дукт, а не зна­ние что в ним.

  ... Ког­да упот­реб­ля­ют­ся твер­д­ые и (пред)оп­ре­де­лен­ные мо­де­ли и пред­с­тав­ле­ния, чтобы уп­рав­лять де­я­тель­нос­ти пе­ре­мен­ной и не­яс­ной, не уди­ви­тель­но что лю­ди огор­ча­ют­ся.

  та­зи кни­га е... фи­ло­соф­с­ка? Все ед­но всич­ко по-го­ре за­ед­но със се­бе­по­доб­ни­те си, на ед­но мяс­то - опит да се пос­та­вят не­ща­та на кра­ка­та им. Нап­ри­мер, виж то­ва след­с­т­вие:

  "... ка­то ця­ло, (соф­ту­ер­ни­те) ин­же­не­ри не _зна­ят_ как да нап­ра­вят сис­те­ми­те ко­и­то се опит­ват да нап­ра­вят; тях­на­та ра­бо­та е да _от­к­ри­ят_ как се пра­ви то­ва."

  т.е., че прог­ра­мис­ти­те тряб­ва да уме­ят да учат (и да обу­ча­ват) - да се на­у­чат на то­ва и/или да бъ­дат на­у­че­ни. Всич­ко дру­го са са­мо ин­с­т­ру­мен­ти, под­по­ма­га­щи та­зи дей­ност.

  this book is... philosophical? Like all the above together with all its peers, in one place - an attempt to put them things with their legs down. For example, see this consequence:

  "... for the most part, (software) engineers do not _know_ how to build the systems they are trying to build; it's their job to _find_ out how to do it."

  i.e. programmers must be able to learn (and teach) - should learn that and/or be taught to it. All else are tools supporting that activity.

  эта кни­га... фи­ло­соф­с­кая? Все рав­но все что выше вмес­те со се­бе­по­доб­н­ы­ми, на од­ном мес­те - поп­ы­т­ка пос­та­вить ве­щи вниз но­га­ми. Нап­ри­мер, см. это след­с­т­вие:

  "... в це­лом, (соф­ту­ер­н­ые) ин­же­неры не _зна­ют_ как пос­т­ро­ить сис­темы ко­тор­ые они пи­та­ют­ся сде­лать; их ра­бо­той яв­ля­ет­ся _от­к­рить_ как это де­ла­ет­ся."

  т.е., прог­ра­мис­там на­до уметь учить (и обу­чать) - на­до им на­у­чить­ся то­го и/или их на­у­чить. Все дру­гое - толь­ко ин­с­т­ру­менты, вос­по­ма­га­щие эту де­я­тель­ност.
  • 5 orders of ignorance - CACM'2000 5 сте­пе­ни на нез­на­ние - CACM'2000 5 сте­пе­ни нез­на­ния - CACM'2000
  • Some of the Realities of Software Project Estimation Ня­кои ис­ти­ни за Оцен­ка­та на Соф­ту­ер­ни про­ек­ти Не­ко­тор­ые ис­тины об Оцен­ке Соф­ту­ер­них про­ек­тов
• PHILOSOPHY OF SOFTWARE (Фи­ло­со­фи­я­та на соф­ту­е­ра) (Фи­ло­со­фия соф­ту­е­ра) 1996 - още не­що за раз­ми­съл... more food for thought... еще че­го-то к раз­миш­ле­нию...
• Ди­на­мич­на те­о­рия за съз­да­ва­не­то на зна­ние (Но­на­ка, 1994) Dynamic theory of knowledge creation (Nonaka, 1994) Ди­на­ми­чес­кая те­о­рия соз­да­ва­нии зна­ния (Но­на­ка, 1994) --

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

  Deep article, about ways of thinking and creation of knowledge and the foundation role of the individual person, and the organisation as medium in this, about the tacit-implicit-unlimited-internal knowledge and explicit-external-coded one, and the importance of their interactions... (and techno-mankind is trying to steer clear of the fact). Also most ideas of the books above... long before them.

  Глу­бо­кая статья; спо­собы миш­ле­ния и соз­да­ва­ния но­во­го зна­ния и ос­но­во­по­ла­га­ю­щая роль от­дель­но­го че­ло­ве­ка, и ор­га­ни­за­ция как сре­да для это­го; не­яв­ное-не­ог­ра­ни­че­ное-внут­рен­ное-зна­ние и яв­ное-внеш­нее-ко­ди­ро­ван­ное зна­ние и важ­ность их вза­и­мо­дейс­т­вий... (а тех­но-че­ло­ве­чес­т­во все ста­ра­ет­ся обой­ти ми­мо это­го фак­та). И идеи с книг выше... мно­го лет за­ра­нее их.

  ---

• ин­те­рес­ни че­ти­ва, мис­лов­ни и ор­га­ни­за­ци­он­ни: interesting readings, thinking and organisational: ин­те­рес­н­ые ве­щи, мис­лов­н­ые и ор­га­ни­за­ци­он­ные: - ме­та­фи­зи­ка на ка­чес­т­во­то/Пир­сиг, на­у­ка ка­то су­ши, TaoTeChing, Пар­кин­сон, из­ме­ре­ния на кул­ту­ри­те, ан­т­ро­по­ло­гия и кул­ту­ра metaphysics of quality/Pirsig, sushi science, TaoTeChing, Parkinson, cultural dimensions, anthropology and culture ме­та­фи­зи­ка ка­чес­т­ва/Пир­сиг, на­у­ка как су­ши, TaoTeChing, Пар­кин­сон, из­ме­ре­ния куль­тур, ан­т­ро­по­ло­гия и куль­ту­ра ...