Личности xor Процес

Този пост дълго време вися в черновите, беше многократно преправян, но в крайна сметка реших, че няма нужда да го оставям да се вмирисва като стари чорапи под леглото…

(За тези, които не знаят, xor оператора връща true само когато едно от условията е вярно)

  • Ако разполагаш с личности, трябва ли да спазваш процес?
  • Формализацията на действията няма ли ненужно да ограничи и попречи на хората?
  • Кое да сложим първо? Членовете на екипа с уникалните им качества, или да заковем на стената процес с роли, в търсене на хора, които да натикаме в предварително дефинирани стереотипи?

И другата гледна точка:

  • Процеса не страда ли от хора, готови да действат “не по правилата”?
  • Кой в крайна сметка и при какви обстоятелства има право да взима решението да пренебрегне това, което пише в дебелите книги?
  • И в крайна сметка дали предвидимите резултати в дългосрочен план не са по-важни от риска да се “импровизира”?

6 Коментара по “Личности xor Процес”

  1. Емил:

    Някой методи, като extreme (agile) programming, приемат “действието не по правилата”, доколкото това е в рамките на допuстимото, т.е. те смятат, че работата по строго определена схема пречи на талантливите, в случая програмисти, да покажат пълните си възможности и приемат импровизацията (нагаждането) по-време-на-изпълнение, смятайки, че така се постигат по добри резултати. Разбира се отклонението от основните концепции не може да е голямо. Аз съм склонен да се съглася с тях, макар, че съм далече от опита който ще ми позволи да преценя сам дали е така.

  2. Боби:

    Аз ще вмъкна само по последното - какво значи “дългосрочен” план и какво значи “предвидими” резултати? В уеб средата на две години се очаква да правиш яки рокади из сайта или постоянно да си в процес на преправяне.

    Предвидим резултат ми звучи като прогноза за времето или като гледане на кафе. Ми да, може и да стане, може и да не стане… Ама на нас ни се иска да стане. Ако импровизацията помага това нещо да стане - юруш! Ако пък строгите правила не дават да се разсейваш и пак да стане нещото - напреж!

    В крайна сметка за мен това е основната функция на правилата - да подсещат “бе къде си тръгнал, я са осъзнай класово”! А не да стискат в желязна хватка.

    От друга страна, понеже съм патил от 3 различни екипа за “разработка на игри”, сбрани от такива видни индивидуалисти, каквито описваш, мисля, че характера е нещо важно, ама ако го няма нужния елемент Дебела Сопа в лицето на проджект мениджъра, става туй, дето баба ми му вика “разпасана команда”.

  3. Боби:

    Ибахти как влачи тука скрола, не е истина… Не, истина е!

  4. nick:

    по принцип правилата могат и трябва да се нарушават, но чак след като си ги научил, разбрал, спазил. и естествено, когато си убеден, че наистина има смисъл от нарушаването им. :)

  5. Петьо:

    Ето няколко полезни връзки по темата за процеса, неговата директна интеграция с екипа и и нструментите, и за това как ms се стремят да избегнат “Ограниченията” налагани от традиционните методологии:
    MSF v4.0 and Agile development

    An Integrated Approach to Agile or Formal Software Development Process

    Intro to Microsoft Solution Framework 4.0 and the Visual Studio Team System

    И накрая малко информация относно концепцията Visual Studio Team System

  6. Grimwolf:

    В крайна сметка се оказа, че QSF-а е приложим само за големи корпорации от по няколко хиляди човека. За едно типично българско фирме, пък било то и някое от “големите”, просто не си заслужава. Поне за мен QSF не се оказа връхтъ на слъдоледтъ.

Коментирай