Ме­то­до­ло­гия и раз­ра­бот­ка на соф­ту­ер­ни сис­те­ми -
от хо­ра, за хо­ра. Пър­га­во.

Methodology and development of software systems -
by people, for people. Agile.

Ме­то­до­ло­гия и раз­ра­бот­ка соф­ту­ерных сис­тем -
людь­ми, для лю­дей. Про­вор­но.

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

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

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

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

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 at end of recommended readings). 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, and all the "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.

• Кри­за? Как­ва кри­за? или ефи­кас­но­то пра­ве­не на ефек­ти­вен соф­ту­ер 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 Слу­ги аз имам шест на брой от стран­но ес­тес­т­во. На­ри­чат се: За­що, Как, Кой, Ко­га, Къ­де, Как­во. Ръ­ди­ард Кип­линг Есть у ме­ня шес­тер­ка слуг, Про­ворных, удалых. Зо­вут их: Как и По­че­му, Кто, Что, Ког­да и Где. Редьярд Кип­линг

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

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 playing 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. ..."

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

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

• "Крис­тал­но-Яс­на - Дви­же­на-от-хо­ра Ме­то­до­ло­гия за мал­ки от­бо­ри, включ­ва­ща Се­дем­те свойс­т­ва на Ефек­тив­ни­те соф­ту­ер­ни про­ек­ти", 1998-2004, Алис­тар Ко­бърн "Crystal Clear - A Human-Powered Methodology For Small Teams, including The Seven Properties of Effective Software Projects", 1998-2004, Alistair Cockburn "Крис­таль­но-Яс­ная - Дви­жи­мая-лю­дя­ми Ме­то­до­ло­гия для малых ко­ман­дах, вклю­чая Семь свойс­т­ва Ефек­тив­них соф­ту­ерных про­ек­тов", 1998-2004, Алис­тар Ко­бърн
  Пол­з­вам та­зи ме­то­до­ло­гия от 4-5 го­ди­ни. При­ли­ча на Скрум, има си и мал­ко те­о­рия, ка­то най-млад­ша от се­мейс­т­во­то Крис­тал­ни ме­то­до­ло­гии. Об­що-ин­те­рес­ни­те час­ти са 1,2, и 9 (как­во и за­що); ос­та­на­ло­то са под­роб­ни обяс­не­ния (как) i am using this methodology for 4-5 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 detailed explanations (how) Я упот­реб­ляю эту ме­то­до­ло­гию уже 4-5 лет. На­по­доб­ля­ет Скрум, име­ет и нем­нож­ко те­о­рии, яв­ля­ясь млад­шей из семьи Крис­таль­них ме­то­до­ло­гий. Час­ти об­ще­го ин­те­ре­са - 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 сте­пе­ни нез­на­ния
• Back to the roots... a lecture by E.W.Dijkstra Об­рат­но към ко­ре­ни­те... лек­ция от Е.Дийк­с­т­ра Об­рат­но к кор­ням... лек­ция Э.Дийк­с­т­ра - 1988: On the cruelty of really teaching computing science; (За жес­то­кост­та на­ис­ти­на да обу­ча­ваш по из­чис­ли­тел­ни на­у­ки) (О жес­то­кос­ти во­ис­ти­не обу­чать в вычис­ли­тель­них на­у­ках)

  The "How to program if you cannot" science... Read and think... 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...

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

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

• Software as knowledge medium, and effects thereof - Phillip Armour: Соф­ту­е­рът ка­то но­си­тел на зна­ние, и про­из­ти­ча­щи­те пос­лед­с­т­вия - Фи­лип Ар­мур: Соф­ту­ер как но­си­тель зна­ния, и выте­ка­ю­щие пос­лед­с­т­вия - Фил­лип Ар­мур:

  ... 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.

  • 5 orders of ignorance - CACM'2000 5 сте­пе­ни на нез­на­ние - CACM'2000 5 сте­пе­ни нез­на­ния - CACM'2000
  • Some of the Realities of Software Project Estimation Ня­кои ис­ти­ни за Оцен­ка­та на Соф­ту­ер­ни про­ек­ти Не­ко­тор­ые ис­тины об Оцен­ке Соф­ту­ер­них про­ек­тов
  • The Laws of Software Process: A New Model for the Production and Management of Software, 2003; (За­ко­ни­те на соф­ту­ер­ния про­цес: Нов мо­дел за про­из­вод­с­т­во и уп­рав­ле­ние на соф­ту­ер) (За­коны соф­ту­ер­но­го про­цес­са: Но­вая мо­дель про­из­вод­с­т­ва и уп­рав­ле­ния соф­ту­е­ра)

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

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

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

    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."

    which in my opinion means that, programmers must be able to learn (and maybe teach) - should learn that and/or be taught to it. All else are tools supporting that activity.

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

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

    что по мо­е­му зна­чить что, прог­ра­мис­там на­до уметь учить (и мо­жеть быть обу­чать) - на­до им на­у­чить­ся то­го и/или их на­у­чить. Все дру­гое - толь­ко ин­с­т­ру­менты, вос­по­ма­га­щие эту де­я­тель­ност.
• PHILOSOPHY OF SOFTWARE; (Фи­ло­со­фи­я­та на соф­ту­е­ра) (Фи­ло­со­фия соф­ту­е­ра) , 1996

  още не­що за раз­ми­съл...

  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."

  which in my opinion means that, programmers must be able to learn (and maybe teach) - should learn that and/or be taught to it. All else are tools supporting that activity.

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

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

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