| началоstart ~ софтуерът-и-азsoftware-and-i ~ биография/cvcv/resume ~ библиотекаlibrary ~ снимкиphotos ~ детскиkids' ~ | български/.bg english |
превод Свилен Добрев, 2008
Речник
Роли / Roles:
Свойства / Properties:
други термини:
Четейки как Кристално-Ясно работи, възникват два въпроса:
Тази част описва седем свойства, установени при най-добрите отбори. Кристално-Ясно изисква първите три. По-добрите отбори използват останалите четири свойства за да отидат още по-навътре в сигурната зона. Всички свойства освен Осмотично Общуване важат за проекти от всякаква големина.
Едва наскоро се усетих, че най-добрите съветници/ консултанти си водят записки за свойствата на даден проект, а не за следваните процедури. Те се интересуват от здравето на проекта: "имат ли мисия и план? Често ли издават резултати? Поръчителят (sponsor) и разните експертни потребители в непосредствена връзка ли са с отбора?"
Като следствие, и встрани от начина по който обикновено се описват методологии, аз карам Кристално-Ясните отбори да се прицелят в ключовите свойства на проекта. Да се "Работи Кристално-Ясно" става постигане на свойства, а не следване на процедури. Две са причините за това изместване от процедури към свойства:
Семейството Кристални методологии се съсредоточава върху трите свойства Чести Издания, Непосредствено Общуване и Размислящо Подобряване, защото те трябва присъстват във всякакви проекти. Кристално-Ясно ползва предимствата на малкия отбор и близостта, за да подсили Непосредствено Общуване в по-мощното Осмотично Общуване. Освен това, опитните разработчици ще забележат, че всички свойства описани в тази глава, са приложими към всеки проект, не само при малки отбори.
Описвайки Кристално-Ясно като набор от свойства се надявам да стигна до усещането за проекта. Повечето описания на методологии пропускат много важното усещане, което отделя успешния отбор от неуспешния. Кристално-Ясният отбор измерва състоянието си чрез настроението вътре в отбора, а схемите на общуване наглася според честотата на изданията. Именоването на свойствата също дава на отбора лесно запомнящи се фрази за оценка на състоянието си: "Не сме правили наскоро никакво Размислящо Подобряване... " "Може ли да имаме повече Лесен достъп до опитни потребители....". Имената помагат на хората да правят диагноза и да обсъждат начини за оправяне на текущата ситуацията.
Първото и най-важно свойство на всеки проект, голям или малък, пъргав или не, е това да се издава работещ, тестван код към потребителите на всеки няколко месеца. Предимствата са толкова много, че е учудващо че не го правят всички:
Всичките тези предимства идват само от едно свойство, Чести Издания. През моите проучвания аз не съм срещал периоди по-дълги от 4 месеца които да дават такава сигурност. 2 месеца е още по сигурно. Отбори, правещи мрежови (web) системи, може да издават и седмично.
Издавали ли сте работещ, тестван и употребяем код на вашите
потребители поне 2 пъти последните 6 месеца?
* * *
Какво обаче значи "издаване"?
Понякога означава че софтуерът се внедрява при всички потребители, при всяка стъпка/итерация. Това е практично при web-внедряван софтуер, или когато групата потребители е сравнително малка.
Когато потребителите не могат да приемат / да си позволят толкова чести обновявания, отбора се оказва в затруднение. Ако те издават системата по-често, ще досаждат на потребителите. Ако не издават системата често, може да пропуснат някой истински проблем в сглобяването (integration) или внедряването. И ще разберат за него твърде късно - при истинското внедряване.
Най-добрата стратегия в този случай е да се намери някой приятелски настроен потребител, който няма нищо против да пробва софтуера, от учтивост или от любопитство. Внедрете само на неговото работно място. Това позволява на отбора да изпробва внедряването и да получи полезна обратна връзка / впечатления поне от един потребител.
Ако не можете да намерите такъв приятелски потребител, поне направете пълно сглобяване и проба, все едно че имате такъв. Така остават възможни само грешки при внедряването.
* * *
Термините сглобяване/интеграция, стъпка/итерация, преглед от потребителя и издание се смесват напоследък. Те имат различно влияние върху разработката и затова трябва да се разглеждат поотделно.
Често сглобяване/интеграция трябва да е правило - да става всеки час, ден, или поне седмично. Добрите отбори сега имат непрестанно работещи автоматизирани процедури за построяване-и-тестване, така че да няма повече от 30 минути от прилаганете на някоя промяна в хранилището до получаване на резултатите от Автоматизирания Тест. Самото сглобяване на системата обаче не прави една стъпка/итерация, тъй-като сглобяване се прави след като един или няколко души завършат някаква малка част от задание. Терминът стъпка/итерация се отнася към целия отбор, който цялостно завършва част от работата, сглобява системата, докладва за резултата нагоре по управленската верига, провежда периодичното си Размислящо Подобряване (иска ми се да е така), и много важно, получава емоционален завършек от изпълнената задача. Този завършек е важен, защото задава някакъв емоционален ритъм, нещо важно за нас като човешки същества.
По принцип, една стъпка може да е един час, а може да е тримесечие. На практика обикновено са между 2 седмици и 2 месеца.
Крайния срок на стъпката обикновено се счита за непреместваем, т.нар. "пакетиране на времето" ("time boxing"). Хората изпитват естествено изкушение да удължават стъпката, когато отбора изостава. Това се оказва грешен/вреден начин, тъй-като води до все по-дълги разтягания на стъпката, рискувайки плана и демотивирайки отбора. Много управители развалят даден отбор като разтягат до безкрайност стъпката, лишавайки отбора от радостта и празнуването при завършването.
По-добре е да се застопори крайната дата, и да се издаде каквото има завършено дотогава, в края на времевия пакет. По този начин, отборът научава какво може да свърши за толкова време, информация полезна за планирането, и получава своята Предварителна Победа (Early Victory).
Стъпките с непроменяема/еднаква? дължина позволяват на отбора да измери бързината с която се движи - скоростта на проекта. Те дават този ритъм на проекта, който хората описват като "биене на сърцето".
Някои заключват изискванията по време на стъпка или време-пакет. Това оставя отбора на мира докато разработва, и сигурността че няма да сменят посоката и могат да завършат поне нещо. Веднъж се срещнах с една групичка, които пробваха XP (eXtreme Programming/Програмиране до Крайност), като Клиентът им не искаше те да успеят: той си сменяше изискванията на всеки няколко дена, така че след няколко стъпки отборът все още не бе успял да завърши нито една точка от заданието. В подобна враждебна среда са много важни и заключването на изискванията, и спокойствието. Иначе такова заключване рядко се налага в една "прилично-държаща се" среда.
Резултатите от стъпката може да се издават а може и да не се издават. Колко често се издава софтуерът на истинските потребители, е тема за обсъждане от целия отбор заедно със поръчителя. Може да се окаже полезно да издават след всяка стъпка, или на няколко стъпки, а може да издава на определени календарни дати.
Чести издания значи издаване на софтуера на потребителите, а не просто да се правят стъпки. Веднъж посетих един отбор по доста нервен проект, които бяха правили стъпки ежемесечно почти цяла година, без да имат нито едно издание. Хората бяха твърде изнервени, защото клиентът не беше виждал какво бяха правили цялата година! Това е нарушение на правилото Чести издания.
Ако отборът не може да издаде към всичките си потребители веднъж на няколко месеца, тогава става належащо да се извърши преглед от потребител . Отборът трябва да си уреди да бъде посетен от потребители, които да видят софтуера в действие, или поне един потребител да го инсталира и пробва. Наблюдава се тясна връзка между неизвършването на такива прегледи от потребител, и крайния провал на проекта, когато потребителите най-накрая - но вече твърде късно - открият че софтуерът не им върши работа.
Най-добри резултати се получават при прилагане и на цялостно пакетиране, и на внедряване. Инсталирайте системата в условия максимално близки до истинските.
Откритието което съвсем ме изненада, беше че един проект може да обърне съдбата си от катастрофален провал във успех, ако се съберат заедно, изредят какво работи И какво не работи, обсъдят какво може да работи по-добре, и направят тези промени в следващата стъпка. Иначе казано, размисли и подобри. Няма нужда отборът да губи много време за тази работа - става и един час на всеки няколко седмици или месец. Дори само заделянето на време от ежедневната лудница за да се помисли какво би работило по-добре, вече е ефективно.
Събирали ли сте се поне веднъж последните три месеца за половин или цял час
(или половин ден), за да си сравните записките, да помислите, да обсъдите работните
навици в групата ви, да откриете какво ви ускорява и какво ви забавя, и какво
може да подобрите?
* * *
Проектът, който ме изненада така, беше "Ингрид" (Ingrid) (описан в Оцеляване при Обектно-Ориентирани проекти / Surviving OO Projects ). В края на първата стъпка - която трябваше да е дълга 4 месеца, но я бяха удължавали - те бяха много изостанали от разписанието, с нисък дух, и със, както смятаха, неприемливa архитектура/ модел. Но всъщност изненадващото беше какво направиха - пуснаха 23 от 24-те програмисти по клиентската част да се върнат по старите си работни места, наеха 23-ма нови човека, промениха структурата на отбора и на управлението, платиха няколко седмици обучение на програмистите, и започнаха отначало, с изискването новата група да пре-направи наново каквото беше направила старата и да продължи нататък.
В края на втората стъпка, те пак бяха изостанали от разписанието, но имаха проект/архитектура която да държи, и структурата на отбора и програмистите бяха работоспособни. Те проведоха отново обсъждаща среща, направиха още промени, и продължиха.
Когато беседвах с тях, бяха в четвъртата си стъпка, изпреварили разписанието и убедени в правилността на архитектурата и начина си на работа.
След тази среща, аз забелязах, че повечето от посещаваните от мен проекти бяха започнали трудно, или дори катастрофално. Това бе толкова общовалидно, че започнах да го очаквам, почти да го приветствам: От тази първа катастрофа идват всички видове нови и важни информации относно работната среда на проекта, които може да са смъртоносни, но скрити.
В проекта Уинифред (Winifred) успяхме в края на първия тримесечен цикъл да направим т.нар. "дъвково" издание (системата едва беше слепена като със софтуерния еквивалент на дъвка). Обаче, ние издавахме нещо на всеки три месеца, по-добро и все по-добро с времето, докато накрая издадохме договореното навреме.
След всяко издание, неколцина от нас се събирахме заедно. Отбелязвахме какво не работеше и обсъждахме начини да го оправим. Пробвахме нови стратегии докато намерим тези които работят. Чести Издания и Размислящо Подобряване станаха критични фактори за успеха ни, както са и за много други проекти.
* * *
Хората, технологията и заданието се променят докато трае един проект. Установените обичаи в отбора също трябва да се променят, за да си съответсват.
Хората в отбора знаят най-добре какво най-подхожда на положението им, и затова Кристално-Ясно оставя толкова много подробности неустановени - да си ги довърши отборът. Механизмът Размислящо Подобряване дава възможност да се правят тези нагаждания.
На няколко седмици, веднъж месечно, или два пъти в рамките на всеки пореден цикъл на издаване, хората се събират на среща за размисъл (reflection workshop) или разбор на миналата стъпка (iteration retrospective), за да обсъдят как вървят нещата. Те отбеляват кои обичаи / правила ще оставят и кои ще искат да променят в следващия период, и окачват тези два списъка на видно място да ги гледат всички докато работят в следващата стъпка.
Каквато и да е честотата и формата на срещите и ползвания метод, успешните отбори правят такива разисквания периодично и пробват нови идеи. Отборите може да опитат, по един или друг начин: програмиране по двойки, тестване на модули, разработка-според-тестовете, разполагане в една стая и в няколко стаи, различни степени на включване на клиента в работата, и дори различни дължини на стъпките/ периодите. Всичките тези вариации са възможни в рамките на Кристално-Ясно.
За да се каже че се използва Кристално-Ясно, не е нужно хоата да продължават с първоначалните си правила и обичаи. Всъщност, очаква се те да пробват нови идеи. В една среща на Кристална група, хората обсъждат какво са изпробвали и какво мислят за тези опити, и как са развили работните си обичаи. Даден отбор може да смени честотата на срещите от веднъж на 2 към веднъж на 4 седмици, друг пък да замени формата, който описвам във следващата глава, със пряко обсъждане на кой-какво цени по време на разработката.
Аз обичам да ползвам Срещата за Размисъл (Reflection Workshop), както е описана в главата Методи (Techniques). Книгата "Разбори на проекти" на Норм Керт (Norm Kerth, "Project Retrospectives"), предлага разширен формат, заедно с много други дейности, които да се пробват по време на срещата. Подробностите около начина на провеждане на такава среща не са изобщо толкова важни в сравнение с факта, че отбора прави такава.
Осмотично Общуване означава че информацията тече в рамките на фоновото чуване на участниците в отбора, така че те поемат засягащата ги информация като че ли чрез осмоза. Обикновено това се постига като се разположат в една и съща стая. И когато някой зададе въпрос, другите в стаята може да се включат или да се изключат, допринасяйки в разговора или продължавайки работата си. Няколко човека са споделили опита си, много подобен на този:
Имахме 4 човека работещи по двойки. Шефа влезе и попита нещо партньора ми. Аз започнах да отговарям, но сбърках името на модула. Нанси която праграмираше с Нейл, ме поправи, без Нейл дори да забележи че е казала нещо или че някой нещо е питал.
При Осмотично Общуване въпросите и отговорите текат естествено и със изненадващо малко смущаване на отбора.
Осмотично Общуване Чести Издания спомагат за бърза и богата
обратна връзка, така че проектът може да работи с минимум друга
(инфра)структура. Ето защо тези две свойства са изредени първи.
Може ли за 30 секунди или по-малко въпросът ти да достигне до ушите на човека който може да знае отговора? Дочуваш ли нещо засягащо те от разговори между другите в отбора поне веднъж на няколко дни?
* * * *
Осмотично Общуване е това което малките отбори могат да постигнат като по-мощна версия на Непосредствено Общуване, свойство от същината на цялото семейство Кристални методологии. Осмотично Общуване прави ниска цената на общуването и висока силата на обратната връзка, така че грешките се поправят изключително скоро и знанието се разпространява бързо. Хората научават приоритетите в проекта, и кой човек каква информация държи. Те научават нови умения - програмни, проектантски, тестови или пък как се борави с даден инструмент. Те прехващат и поправят малки грешки преди да са прераснали в големи такива.
Въпреки че Осмотично Общуване е ценно за големи проекти, е по-много трудно да се постигне при нарастване на големината на отбора.
Трудно е да се симулира Осмотично Общуване без да са хората в една стая, съседни стаи със 2-3ма във всяка може да даде много от предимствата. Херинг (Herring 1999) съобщава за използване на високо-скоростна вътрешна мрежа с камери, микрофони и разговорни сесии за обмяна на въпроси и код, като начин за симулация на една стая (до известна степен). При добра технология отборите могат да постигнат някакво приближение на Непосредствено Общуване, но все още не съм видял да се постигне Осмотично Общуване по друг начин освен чрез физическо съседство на хората от отбора.
* * *
Обсъждането на Осмотично Общуване неминуемо води до обсъждане на схеми на офиси и разположение на мебелите.
Кристално-Ясно изисква хората да са много близо един до друг така че да дочуват полезна информация и да получават отговорите си бързо. Очевидния начин за това е да се сложат всички в една стая ("бойна зала"), многократно доказано като изключително ефективно (Радикално Съжителство / Radical Colocation).
фиг. 2-1. Осмотично Общуване (от Томакс /Tomax)
Много хора, които имат собствени стаи / офиси, се съпротивляват на преместването в общо групово пространство. Обаче, понякога може да се превърнат лимоните в лимонада (така да се каже), чрез такъв един ход:
Ръководството каза на Лиза, че отделът и трябва да намали офис-площта която заема. Това значи че трябва да се откажат от отделните лични стаи/офиси. Тя предложи на хората си да работят заедно и да си проектират собствено работното пространство, с 3-до-5 човека за всяка обща площ. Групите си сложиха по-малко квадратни метри около работните маси, за да могат да си заделят място за столове, диван, или в някои случаи, дори техни си стаи за събрания.
Следващите картинки показват какво измислиха една от групите. Забележете че въпреки по-малкото площ от преди, се получиха по-дълги зрителни линии/ полета, и място за разговори с кресла.
фиг. 2-2. Разположение на мебелите (от Лиза Хватум / Lise Hvatum)
фиг. 2-3. Снимка на същия офис
Фигура 2-4 показва малката стая за срещи, която една от групите сложиха в края на общия им офис. Те я ползваха за да разговарят без да пречат на някой, който още програмира, и също си държаха на стената плана и бележки по архитектурата.
фиг. 2-4. работна стая на групата, долепена към общия офис (от Лиза Хватум)
Групата на Лиза имаха обичайните офисни маси: вдлъбнати, направени така за да се напъха дълбокия екран с кинескоп (CRT) в ъгъла. Този вид маси обаче пречат на един пъргав отбор, защото е трудно втори или трети човек да гледа същия екран. Бойната стая на фигура 2-1 може да изглежда не много очарователна, но сега има полза от тези грозни маси - хората могат да се съберат около някой екран, може да се работи по двойки. По тази причина пъргавите отбори предпочитат прави маси, или дори изпъкнали към пишещия на клавиатурата.
Ако ще подреждате работна бойна-зала, във всички случаи уредете да има и друго място, където хората да могат да отидат да разпуснат или да четат личната си поща. Това дава възможност на хората да се съсредоточат когато влизат в общата работна зона, и да почустват някакво облекчение като излязат от там. Такава подредба/ спогодба се нарича "пещери и обща част" ("caves and common" arrangement).
фиг. 2-5. място за обсъждания на групата (от Дарин Къминс / Darin Cummins)
Един отбор получи разрешение да подреди общо място за обсъждания със кресла и диван (фиг. 2-5). На стената пред креслата стои вечно-присъстващата бяла дъска с устройство за заснемане на нарисуваното. Тук отборът се оттегля за да провежда обсъжданията на архитектура, планиране или срещи за размисъл.
Пъргава Разработка на софтуер, Кобърн 2003 (Agile Software Development, Cockburn 2003) съдържа допълнителна информация за "конвекцията и теченията" на информационния поток в една група, Осмотично Общуване, ползата от съжителство на едно място, и примерни схеми на офиси.
* * *
Осмотично Общуване създава и опасности, най-често шум и поток от въпроси към най-опитния разработчик. Хората обикновено се само-регулират, изисквайки по-малко празни приказки и повече уважение към времето за мислене.
Опитът да се "защити" водещия програмист чрез негова собствена стая обикновено дава обратен резултат. Този човек наистина трябва да седи в средата на отбора. Водещият програмист обикновено е експертът в технологиите, в приложната област, и най-добрия програмист, и като такъв ще се радва на голямо търсене. Ако се отдели настрана, по-младите разработчици ще пропуснат шанса да развият добри работни навици, да пораснат в разбурането си за приложната област и технологиите, и ще правят грешки които иначе биха били хващани бързо. В края на краищата, Това ще струва на проекта повече отколкото ще е ползата от спокойствие за Водещия Програмист. Слагането на Водещия Програмист в същата стая като останалия отбор е стратегия, наречена Експерт на едно ухо разстояние (Expert in Earshot), описана в (Cockburn URL-EiE). Това е особен случай на Осмотично Общуване.
Но дори и най-успешното свойство е неподходящо при дадени условия. Осмотично Общуване не изключение. Ако водещия програмист се претовари до такава степен и е толкова често прекъсван, че не може да се придвижи напред по нищо от своята работа, той се нуждае от работно място без никакви прекъсвания и ограничено общуване с отбора, Фуния на Тишината (Cone of Silence) както го наричам. Много водещи програмисти ползват часовете след работа, от 18 вечерта до 2 през нощта като тяхна Фуния на Тишината, но ще е по-добре за всички участници, ако подобна Фуния на Тишината може да се уреди в рамките на нормалното работно време. Фуния на Тишината като стратегия е обяснена подробно в (Cockburn URL-CoS).
Лична Безопасност означава да можеш кажеш когато нещо те тормози, без страх от наказание. Можа да включва да кажеш на шефа че планът е нереелен, на колежката си че проекта и се нуждае от значително подобряване, или просто да кажеш на колегата да се къпе по-често. Личната Безопасност е важна, защото със нея отборът можбе да разкрива и поправя слабостите си. Без нея, хората ще си мълчат, и слабостите ще продължат да развалят отбора.
Лична Безопасност е една ранна стъпка към Доверие. Доверие, което включва да дадеш на някой друг власт над тебе, с присъщия риск от щети в личен план, е степента до която се чувстваш приятно давайки тази власт на другия. Някои хора имат доверие на другите ей-така по подразбиране, и чакат да бъдат уязвени за го оттеглят. Други не са склонни да се доверяват на другите, и чакат първо да видят доказателство че няма да бъдат наранени, за да се доверят. Наличието на доверие е в тясна статистическа връзка с производителността на отбора (Коста /Costa 2002).
Различните начини по които човек може да бъде наранен водят до различни форми на доверие и недоверие (Тилер /Tyler 1996). Човек, който не е открит / прям / почтен, може да лъже и да скрива. Човек, който не е компетентен или не е надежден няма да си свърши работата. Човек, който не го е еня за другите, може да действа в техен ущърб, включително издаване на вътрешна информация.
Съответно, излагайки се на тези разнообразни възможни вреди, се получават различни форми на доверие. Не е реалистично нито нужно да се иска от хората във проекта да си имат доверие във всичките му форми. Важно е хората да могат да говорят открито и да действат свободно - нужно е да си имат доверие относно увреждащи действия или измама/ предателство.
Когато човек види че другите няма да го измамят или да му навредят поради информацията която той разкрива, той ще разкрива информация още по-свободно, което ще ускори работата по проекта. Затова, постигането на свойството Лична Безопасност е критично.
Можеш ли да кажеш на шефа си, че си сбъркал в преценката с повече от 50%, или че току що си получил примамливо предложение за работа? Можеш ли да не се съгласиш с него относно плана, на събрание на отбора? Могат ли хората да излязат от дълъг спор за моделите на единия и/или другия със приятелско несъгласие?
* * * *
За да се установяви доверие, е нужно да се участва в ситуация, където има някоя от тези опасности, и да се види, че другите няма да те наранят. Казано с други думи, за да се изгради доверие, трябва да има излагане (на опасност).
Има три особени излагания, приложими при разработката на софтуер:
Опитните водачи излагат отбора си (и себе си) на тези ситуации достатъчно рано, и показват бързо и истинно, че не само от това не произтича нараняване, но че Водачът и отборът като цяло подкрепя този човек.
Една водачка на проект веднъж ми каза че когато нов човек се присъедини към нейния отбор, тя го посещава лично за да обсъжда как върви работата му, изчаквайки неминуемия момент когато той трябва да си признае, че не не направил или не знае нещо.
Това е решаващия миг за нея, защото докато той не изложи/разкрие своя слабост, тя не може да му покаже, че ще го покрие или че ще му намери помощ. Тя знаеше че няма да получи нито надеждна информация, нито пълно съдействие, докато той не разбере правилно, че разкриването на собствена грешка или слабост всъщност ще доведе до получване на помощ. Тя каза, че някои хора разбират това от първия път, други се нуждаят от неколкократни доказателства, преди да се отпуснат и открият.
Друг водач на проект разказа как се получило взаимно сцепление и безопасност в отбора, след като работили заедно по решаването на една трудна задача. Решавайки проблема заедно, те научили няколко неща:
Доверието се повишава при Чести Издания. Когато софтуерът бъде издаден, хората отчитат кой си е свършил частта от работата и кой се е скатавал, кой е казал истината, кой е навредил или предпазил кого, и на кого, въпреки лекомислените маниери, може да се има доверие по какви показатели. При Лична Безопасност, всички говорят открито от сърце по време на събиранията за Размислящо Подобряване.
* * *
Лична Безопасност върви ръка за ръка с дружелюбието (човек да е добряк), т.е. желанието да слушаш доброжелателно. Проектът ще страда ако който и да е в отбора престане да слуша доброжелателно, или загуби склонност да препредава възможно важна информация. Освен от личните качества, напредването на проекта зависи от скоростта на придвижване на информацията между хората (ако щеш, "мисловни метри в минута" / "meme-meters per minute").
Обикновено един в отбора дава пример за дружелюбие. В големи проекти е от решаващо значение това да е ръководителят / управляващият. При Кристално-Ясни проекти може да е който и да е от отбора. Стига да няма някакви особени причини действащи против, дружелюбието се разпространява бързо и отборът се чувства по-спокойно при обмяната на информация бързо. Личната Безопасност и дружелюбието заедно спомагат за постигане на Сътрудничество отвъд Границите на организацията (Collaboration across Organizational Boundaries), установяване на общите жизнени пътища за проекта. За мен, дружелюбието е значителен управленски елемент в даден проект, в частност като доказателство за Лична Безопасност.
След като Лична Безопасност и дружелюбието бъдат установени, се получава полезна, игрова динамика. Хората може да се състезават един с друг. Те могат да спорят на висок глас, дори до сбиване, без да го вземат навътре. В случай когато някой обаче го вземе навътре (лично), те ще изгладят отношенията си и ще започнат на чисто.
Внимавайте обаче да не бъркате Лична Безопасност със учтивост/вежливост. Някои отбори изглеждат като че имат Лична Безопасност, но всъщност те само учтиви, защото не искат да показват несъгласие. Скривайки неразбирателствата си със учтивост и помиряване, те не могат да открият и поправят налични грешки. Това накрая уврежда проекта, както случая с прекаленото-дружелюбие описано в (Кобърн 2002 /Cockburn 2002).
Има доста литература по въпроса за доверието, може да намерите нещо подхподящо за вашия случай. Виж Хофман (Hohmann 1997), Кармер (Karmer 1996), Коста (Costa), и Адамс (Adams).
Фокусиране е първо, да знаеш по какво да работиш, и после
да имаш време и спокойствие да работиш по него. Знанието по какво да
се работи идва от общуване относно целта, посоката и приоритетите, и
обикновено идва от Главния Поръчител. Времето и спокойствието
идват от работната среда, в която хората не биват "отвличани" от
текущата им задача и не биват занимавани с други, несъвместими неща.
Знаят ли всички в отбора какви са двете най-важни неща, по които да работят? Имат ли гарантирани поне два последователни дни и два часа без прекъсване всеки ден, за да работи по тези неща?
* * * *
Дори и при най-добри намерения, разработчиците ще работят по неща носещи приложна бизнес-стойност само по случайност, ако не им се каже кое точно носи бизнес-стойност. Това е работа на Главния Поръчител, започваща от учредяването на проекта и продължаваща през целия проект - да каже ясно на всички какви са приоритетите на организацията.
Вицепрезидентът на една компания от 50 човека седна една нощ, подреди по важност 70-те висящи инициативи, и на следния ден обяви резултата на всички ръководители. После обиколи всички разработчици и се увери че всеки от тях знае за собствените си две най-важни неща.
Един Водещ Програмист, каза че държал мисията на проекта и приоритетите закачени на стената, и редовно ги споменавал.
Но не е достатъчно просто да се знае какво е важно. Разработчиците редовно се оплакват, че събранията, заявките да се направи демо-версия и исканията да се оправят разни грешки в движение им пречат да се занимават с работата си. На човек отнема средно 20 минути и значително количество мисловна енергия, за да си възстанови нишката на мисълта след някое такова прекъсване. Ако прекъсванията са 3-4 пъти на ден, нерядко човекът просто се мотае между тях, чувствайки излишно да се зарови в нишката на мисълта си, само за да бъде прекъснат пак по средата.
Хора които работят по 2 или 3 проекта едновременно редовно съобщават че не могат да напреднат по нито един от тях. Изглежда че средно отнема около час и половина за да превключи нишката на мисълта си от един проект на друг.
Сред опитните ръководители на проекти които съм разпитвал, има пълно единомислие, че един човек може да поеме най-много проект и половина, и все още да е ефективен. Когато се добави трети проект, разработчикът става неефективен и по трите. Направете разликата с неопитните ръководители/управители, който подценяват цената на превключването между проекти, и възлагат на хората да работят по 3 до 5 проекта едновременнно. Веднъж имаше един който му бяха дали 17 проекта! Можеш да си представиш че едва е имал време да докладва по разните събрания как няма напредък по никой фронт.
Лечението е лесно, въпреки че може да е неприятно... Поръчителят трябва да каже ясно кои проекти и кой техни части са от първа важност, за всеки човек, и да направи така, че първите две неща в списъка на всеки са със значително по-висок приоритет от всички останали.
Отборът трябва да приеме някакви правила които да осигуряват време за Фокусиране на участниците. Едно такова правило, е че ако даден човек започне да работи по даден проект, трябва да му се гарантира поне два пълни дни без да превключва към друг проект. Това хем позволява да се прави някакво превключване между проекти, хем гарантира на човека достатъчно време да направи нещо по всеки, вместо всичкото време да отива за пренастройване и засилване, само за да се превключи пак.
Следващо правило може да се определят разсейващите прекъсвания. Моят опит показва че в общия случай не е много полезно да се натикат всички прекъсвания в нещо толкова спретнато като "само сутрин" или "само от 1 до 3 следобед". Естеството на прекъсванията е да възникват спонтанно, и да са много важни. Това което може да направи отборът, е да съ направи 2-часов прозорец в който прекъсванията са забранени. Има много малко прекъсвания които не могат да почакат 2 часа. Някои отбори избират времето от 10 до обяд, и в този интервал са забранени всякакви събрания, телефонни обаждания и демонстрации.
Имайки 2 часа на ден гарантирано време за фокусиране, и поне два дни последователно по един и същ проект, разработчик който иначе бива непрекъснато разсейван, ще има 4 пълни часа свършена работа седмично. Един разработчик беше приел такъв подход и съобщи че за няколко седмици свършил повече работа, отколкото за предните няколко месеца.
Постоянния достъп до опитни потребител(и) дава на отбора:
Изследователите Кейл и Кармел (Keil 95, Carmel) публикуваха резултати, показващи колко критично е наличието на пряка връзка с опитни потребители. Проучвайки ръководители, които са работили и със и без достъп до истински потребители, те пишат че: " . . . в 11 от 14 сравнявани по двойки случая, по-успешният проект е имал по-голям брой връзки отколкото по-малко успешния проект. . . . Тази разлика се оказа статистически значима при сдвоен t-test (p < 0.01)."
Този резултат ги е довел до следната препоръка: "Намалете зависимостта си от непреки (опосредствени) връзки." С други думи, доберете се до истински достъп то истински потребители.
Средно отнема ли ти по-малко от три дни от момента
на възникване на даден въпрос относно системата до получаване на
отговор от опитни потребители? Можеш ли да получиш отговор за няколко
часа?
* * * *
Добре де, а колко потребители, и по колко време?
Дори един час на седмица достъп до истиниски и опитен потребител е изключително ценен. Колкото повече часове има потребител достъпен на отбора, толкова повече предимства може да се извлекат от тази близост. Първият час, обаче, е най-съществен.
Друго важно нещо е колко време отива докато се получи отговор на даден въпрос. Ако въпросът не получи отговор за 3 дни, програмистите няй-вероятно ще сложат в кода каквото се сетят за най-подходящо, и може да забравят да проверят отново това си решение когато имат на разположение потребители. Затова, през седмицата трябва да имат поне телефонен достъп до оиптен потребител.
Ето трите начина за достъп до потребител, които най-често съм видял:
Кейл и Кармел назовават и други видове връзки с потребители, като: подпомагане на отбора (facilitated teams), изготвяне на прототипи на потребителски интерфейс, беседи (interviews), тестове /изпитания, форуми / периодични издания (bulletin boards), лаборатории по употребяемост (usability labs), изучаване чрез наблюдаване (observational study), и групи по интереси (focus groups). Поглеждайки в интернет намерих доста компании занимаващи се с намиране на "пациенти" (subjects) и изпитване на софтуер с истински потребители.
За мен има разлика между опитен потребители и business експерт, защото обикновено това са разлчни хора. Бизнес-експертът познава нормите в приложната сфера, включително кои са твърди и кои се променят, и зависимостите между тях. Потребителите обикновено не знаят това. Но опитния потребител знае кой действия са чести и кои са редки, какви съкращения/ преки пътища ще са нужни (shortcuts), какви данни не няма нужда да се въвеждат, и каква информация трябва да се вижда едновременно на едно място. Бизнес-експертът няма как да знае това, тъй-като може да се получи само от непрекъсната ежедневна употреба.
Разработващият отбор трябва да има Бизнес Експерт (виж
Роли, глава 5). Този човек може да е поръчителят, или опитния
потребител, или водещият програмист. Такъв човек почти винаги има във
всеки проект, и затова не подчертавам нуждата му. Опитния
Потребител, обаче, обикновено липсва - за зло на проекта - поради
което толкова много говоря за него. Лесният достъп до Опитни
Потребители е като спасително въже за отбора, а също и голямо
конкурентно предимство. Много вероятно е да се окаже от съдбовна
важност за успеха на един малък отбор.
* * * *
"Добре, имаме потребителите - какво да правим с тях?"
Трябва да научиш какво искат, за какво техните поръчители/платци са готови да плащат, как изглеждат техните по-особени начини на употреба - бързи или редки-но-важни, и дали не сте пропуснали нещо съществено. Имаш нужда от потребителите преди, по време и след проектирането.
Преди да сте навлезли твърде много в проектирането на системата, трябва да се определят ролите-потребители, за които поръчителите считат че е най-важно да бъде настроено приложението. Това са ролите на фокус. Системата ще предлага различни "индивидуалности", (напр. бърза и ефективна, или приятелска и сърдечна) за всяка различна роля. Проектантите ще наблегнат на една или друга индивидуалност, и трябва да сте сигурни че се набляга на най-важните.
Методът описан в следващата глава, Проектиране на взаимодействието по същество (Essential Interaction Design) е един начин да се установят ролите на фокус и индивидуалностите които трябва да се разработят. Привлекателното в този метод за работни срещи е, че може да се събере неонходимата информация сао за няколко дни.
По време на проектирането, ще имате нужда да бъде отговорено на много манлки въпросчета. Затова и е нужен Лесен достъп до Опитни Потребители непрекъснато, както е описано тук.
След проектирането, когато вече мислиш че е готово, отново ти трябват потребителите, да оценят резултатите ти. Ако системата ще отиде при няколко местни потребители, просто ги покани за пробна сесия. Ако, обаче, имате голям брой географски разпръснати потребители, цената за такава оценка се качва. Не познавам някакви ефективни методи за такъв случай. Методи за оценка на употребяемост има от десетилетия (клиентски фокус-групи (customer focus groups) и проби за употребяемост (usability samples) като основни примери). Напоследъх открих че има цяла индустрия за тестване на употребяемост.
Преди да свърша с това свойство, ще те помоля да прочетеш отново последните абзаци от Чести Издания, където описвам неприятностите произлизащи от липсата на обратна връзка от истински потребители. Дори отбори, които правят всичко друго нужно за пъргава разработка, се оказват пред катастрофа в края ако пренебрегнат тази обратна връзка по време на проекта.
Елементите, които изтъквам в това свойство, са толкова основополагащи, че ми е неудобно да ги споменавам въобще. Нека да ги разгледаме поотделно и заедно.
Автоматизирано Тестване (Automated Testing). Отборите могат да издава успешно и ползвайли ръчни тестове, така че това не може да се счита за критичен фактор за успеха. Обаче, всеки от питаните програмисти, който веднъж е минал към автоматични тестове, се кълнеше никога вече да не работи без тях. Което е просто поразително.
Причината за това най-вероятно е свързана с подобреното качество-на-живота. През седмицата те поправят парчета код, знаейки че могат бързо да проверят дали не са счупили нещо друго без да искат. Когато го подкарат в петък, могат да си отидат в къщи спокойно, знаейки че в понеделник ще могат да забележат ако някой го е счупил през почивните дни - просто пускат тестовете в понеделник сутринта. Тестовете им дават свобода на движението през деня, и спокойствие през нощта.
Управление на конфигурациите (Configuration Management). Системата за Управление на конфигурациите позволява на хората да съхраняват в нея нещата си асинхронно, да се отказват от промените, да пакетират дадена конкретна конфигурация за издаване, и да се върнат към тази конфигурация по-късно ако възникне беля. Тя дава на разработчиците да правят кода поотделно и заедно. Това неотклонно се споменава от отборите като най-критичния инструмент след компилатора.
Често сглобяване (Frequent Integration). Много отбори сглобяват системата няколко пъти на ден. Ако не могат да си го позволят, сглобяват веднъж дневно, или в най-лошия случай, през ден. Колкото по-често сглобяват, толкова по-бързо се откриват грешки, по-малко допълнителни грешки се трупат, по пресни са мислите им, и по малко е кода който трябва да се претърсва за недоразумението.
Най-добрите отбори комбинират всичките три във Непрекъснато
Сглобяване-с-тест (Continuous Integration-with-Test). Така хващат
грешки на ниво сглобяване в рамките на няколко минути.
Може ли да пуснеш тестовете на системата до края, без да трябва да присъстваш физически?
Всичките ви разработчици слагат ли написания код в системата за управление на конфигурациите (хранилище - configuration management system) ?
Слагат ли полезен коментар към всяко качване?
Системата сглобява ли се поне веднъж на седмица?
* * * *
Колко често трябва да е Честото сглобяване ? Няма единствен отговор на този въпрос, също като на въпроса колко да е дълга една стъпка.
Един водещ програмист ми каза че не е бил в състояние да накара който и да е от отбора да пуска сглобяване повече от 3 пъти седмично. Той не се чувсташе спокойно в това положение, но то беше достатъчно за този проект. Отборът правеше едномесечни стъпки, и имаше Осмотично Общуване, Размислящо Подобряване, Управление на Конфигурациите и известно Автоматизирано Тестване. наличието на всичките тези свойства правеше честотата на Честото сглобяване не толкова важна.
Най-напредничавите отбори ползват накаква машина за построяване-и-тестване, която да сглобява и тества нонстоп (забележка: простото наличие на такава машина не е достатъчно... разработчиците трябва да публикуват/качват промените си в хранилището няколко пъти на ден!) Машината публикува резултата от тестовете в някаква страница, която разработчиците държат отворена през цялото време. Един международно-разпределен отбор (очевидно не ползващ Кристално-Ясно!) съобщи че такава една машина позволява на разработчиците да са в течение на промените в кода, което до известна степен облекчава разположението им в различни времеви пояси/зони.
Пробвайте разни честоти на сглобяване, и намерете темпото което е
подходящо за отбора. Включете това като част от Размислящото
Подобряване. За повече по темата управление на конфигурациите, виж
Configuration Management Principles and Practice (Hass 2002)
Configuration Management Patterns (Appleton and Berczuk 2002),
Pragmatic Version Control using CVS by the "Pragmatic
Programmers" (Thomas 2003). Може да трябва да наемете консултант да
настрои системата и да обучи отбора как да я ползва.
* * *
Автоматизирано Тестване значи че човекът може да пусне тестовете да вървят, и да си отиде, без да има нужда да се намесва или да гледа екраните, и после като се върне да намери резултатите да го чакат. Никакви човешки очи или пръсти не са намесени в този процес. Всички отделни наборите тестове на всеки от разработчиците може да се комбинират в един голям, който да се пуска - ако трябва - през почивните дни (и пак без да има нужда от очи или пръсти).
Веднага възникват три въпроса:
Освен тестовете за употребяемост, които няй-добре се правят от хора извън проекта, аз намирам за най-обсъждани 3 нива на тестване:
Хората с които беседвам са възторжени от последните два вида Автоматизирано Тестване. Автоматизираните модулни тестове дават на програмистите да проверят дали техния код не се е счупил случайно от някоя промяна - докато добавят нов или поправят стар код (преработка / refactoring). Приемните тестове без потребителски интерфейс правят същото върху вече сглобената система, и са неизменни при много промени във вътрешностите на системата. Въпреки че са горещо препоръчвани, рядко срещам отбор да ги ползва, поради това че изискват в архитектурно отношение внимателно да са отделени потребителския интерфейс от функционалността. Това разделение се препоръчва от десетилетия, но малко успяват да го постигнат.
Автоматизираните тестове през потребителски-интерфейс не са от силно-препоръчваните, защото трудно се автоматизират и трябва да се преправят при всяка промяна в интерфейса. Тази трудност прави още по наложително отборът да направи архитектура, позволяваща приемни тестове без потребителски-интерфейс.
Модулните тестове на един програмист трябва да свършват за секунди, не минути. Като са толкова бързи, той няма да изгуби нишката на мисълта си докато ги чака, което всъщност значи че ще си прави труда да ги пуска докато работи. Ако тестовете отнемат няколко минути, едва ли ще ги пусне наново след промяна само от няколко реда.
Тестовете може да траят повече когато качва промените си в хранилището на системата за Управление на конфигурациите. В този момент той е завършил един цялостен цикъл от дейности, и може да си позволи да се разходи малко докато траят тестовете.
Приемните тестове може да отнемат дълго време, ако се налага. Пиша това изречение умишлено: причината да отнемат много време трябва да е защото са много или има специфична времева последователност за изпробване, а не защото са калпаво направени. Пак да кажа, ако тестовете вървят бързо, те ще бъдат пускани по-често. За някои системи се налага приемните тестовете да се пускат през нощта или почивните дни.
Кристално-Ясно не указва кога се пишат тестовете. По традиция програмистите и изпитателите пишат тестовете след като кода, който се тества, е написан. И пак по традиция, нямат много останала енергия/желание да пишат тестове. Отчасти поради това, все повече разработчици възприемат разработка-водена-от-тестове (test-driven development) (Beck 200???).
Най-добрия известен ми начин да се започне с Автоматизирано Тестване е да намерите съответната версия на X-unit (където X е езика на който пишете), тестова инфраструктура, измислена от Кент Бек (Kent Beck). Има JUnit за Java, CppUnit за C++, и т.н. за какво ли не. След това прочетете Проектиране водено от Тестове / Test-Driven Design (Beck 2002???) or Astel??
Има httpUnit и FIT (Framework for Integrated Tests, Ward Cunningham - Инфраструктура за интегрирани тестове, Уард Кънингам), които помагат за приемни тестове без потребителски интерфейс. Първата е за тестване на потоци от HTML за уеб-системи, втората позволява на бизнес-експерта да си направи собствени набор тестове без да знае програмиране. Много отбори позват електронни таблици където бизнес-експертите да въвеждат сценариите на тези функционални тестове.
За съжаление няма добри книги за това как да се проектира система, така че приемното тестване без потребителски интерефейс да е лесно. (Плумтрий / Plumtree 2004???). В Макинтош имаше идея за скрипт/език за интерфейси, и в MS Офис има някакъв вграден език. Като цяло обаче, това занимание е почти изчезнало и се ползва само от ограничен брой изтъкнати разработчици. Малкото хора които познавам и биха могли да напишат такива книги са твърде заети с програмиране.
* * *
I end this section with a small testimonial to test-driven development that I hope will sway one or two readers. Thanks to David Brady for this note:
Yesterday I wrote a function that takes a variable argument, like printf(). That function decomposes the list arguments, and drops the whole mess onto a function pointer. The pointer points to a function on either the console message sink object or a kernel-side memory buffer message sink object. (This is just basic inheritance, but it's all gooky because I'm writing it in C.)
Anyway, in the past I would expect a problem of that complexity to stall me for an indefinite amount of time while I tried to debug all the bizarre and fascinating things that can go wrong with a setup like that.
It took me less than an hour to write the test and the code using test-first.
My test was pretty simple, but coming up with it was probably the hardest part of the whole process. I finally decided that if my function returned the correct number of characters written (same as printf), that I would infer that the function was working.
With the test in place, I had an incredible amount of focus. I knew what I had to make the code do, and there was no need to wander around aimlessly in the code trying to support every possible case. No, it was just "get this test to run". When I had the test running, I was surprised to realize that I was indeed finished. There wasn't anything extra to add; I was actually done!
I usually cut 350-400 lines of production-grade code on a good day. Yesterday I didn't feel like I had a particularly good day, but I cut 184 test LOC and 529 production LOC, pLOC that I *know* works, because the tests tell me so, pLOC that includes one of the top-10 trickiest things I've ever done in C (that went from "no idea" to "fully functional" in under 60 minutes).
Wow. I'm sold. Test infection. Give it a warm, damp place to start, and it'll do the rest...
David Brady
Evidence: Collaboration across Organizational
Boundaries
There is a side-effect from attending to Лична Безопасност, amicability within the team, and Easy Access to Expert Users: it becomes natural to include other stakeholders into the project, as well.
Géry Derbier, working with the French postal service (La Poste) to build software to run a new facility to handle all the mail going into and out of northern France, reported on his use of Crystal. With 25 people, his was a project in the Crystal Yellow category. However, he knew the principles of the Crystal methodologies family, particularly the "stretch to fit" principle, and therefore chose to extend Crystal Clear to his larger setting wherever possible.
We discussed his project, and at one point covered their project's linkage to the integration testing team located 30 km away and to the business and usage expert working for La Poste. I asked questions of the sort: "How often did that person visit the team? How did he feel about that? How did his manager feel about his coming over so often?" Géry's answers were, for both external groups: "One day a week; comfortable; happy to be involved so early."
After our discussion, I realized that Géry had built the additional safety into his project of Collaboration Across Organizational Boundaries. His project was happily linked into both the customer and integration environments with a colleague on each end. La Poste's contract measured and paid according to integrated test results every few months (the Frequent Delivery). The La Post executives got software delivered in growing increments and paid accordingly. Géry's bosses, who had no previous experience with incremental delivery, were happy about this also, since they saw regular delivery turn into regular payments. Géry had a support structure on all sides.
Collaboration Across Organizational Boundaries is not a given result on any project. It results from working with honesty amicability and integrity within and outside the team. It is hard to achieve if the team does not itself have Personal Safety and to a lesser extent, Frequent Delivery. I consider the presence of good collaboration across organizational boundaries as partial evidence that some of the top-seven safety properties are being achieved.
Reflection on the Properties
I don't believe that any prescribed procedures exists that can assure that projects land in the safety zone every time. Nor, with the exception of incremental development, do I show up on a project with any particular set of rules in hand, even though I have my favorites. This is why Crystal Clear is built around critical properties instead of specification of procedures.
A Crystal team works to set the seven properties into place, using whatever group conventions, techniques and standards fit their situation. The conventions may vary by project and by month. New techniques get invented with each new technology (and usually go out of style again a few years later). These seven properties, on the other hand, have been applied on good projects for decades.
My intention with Crystal is to not invade the natural workings of individuals on the project where possible, and to allow the most possible variation across different teams, while still getting those diverse projects into the safety zone. To allow variation, I must remove constraints. Removing constraints means finding broader mechanisms that provide a safety net. The ones I choose to rely on are these:
People are by nature good at looking around and communicating.
They take initiative when provided with information.
They do better in an environment that is safe with respect to personal emotional safety, and particularly freedom from personal attacks.
They do their best work if they can satisfy their need for contribution, accomplishment, and pride-in-work.
The Crystal Clear safety net is built on those things. Лична Безопасност gives people the personal courage to share whatever they discover. Осмотично Общуване gives them the greatest chance to discover important information from each other, and does so with very low communication cost. Reflective Improvement gives them a channel to apply feedback to their working process. Easy Access to Expert Users gives them the opportunity to quickly discover relevant information from the user(s). Frequent Delivery creates feedback to the system's requirements and the development process. The technical development environment including Automated Tests, Configuration Management & Frequent Integration allows people to safely make changes to the system. synchronize the multiple minds that are in motion at the same time, and get feedback on the system's intermediate stages quickly. Фокус allows the team to spend their energy well on the most important things.
Ron Jeffries once characterized Crystal Clear as, "Bring a few developers together in peace, love and harmony, shipping code every other month, and good software will emerge." He is close.
* * *
You should be asking at this point, "But what is special in all this about small projects? Shouldn't all project teams set these properties in place?"
The answer -- with two side notes -- is, "Of course." The properties that make up a small-team project successful should be very similar to making any project successful, but optimized for the small-project situation.
The first note is that the properties are easier to reach on a small project: Лична Безопасност is easier, since the people interact with each other more often and come to know each other sooner. The feedback loops are much smaller, and the rest of the properties follow accordingly.
The second note is that Осмотично Общуване, which lives from background hearing and communication along lines-of-sight, really only works with small teams. Larger team will set up Осмотично Общуване within subteams and Close Communication across subteams.
1 Thanks to Victoria Einarsson in Sweden.
2 Thanks to Kay Johanssen for this distinction.
3 On Google, for examples, see Computers > Human-Computer Interaction > Companies and Consultants > Usability Testing.
4 www.CruiseControl.???
5 Google even has a category for it: Computers > Human-Computer Interaction > Companies and Consultants > Usability Testing.
6 www.fit.org??? and www.fitnesse.org??? respectively.
7 See http://www.mactech.com/articles/develop/issue_24/according.html for an article by Cal Simone.
Детски нещаKids' things
* книжкиbooks
* творения:легоcreations:lego
БиблиотекаLibrary
* снимкиphotos
* хайкуhaiku
* водолет / e-foilwaterfly / e-foil
* обиКолелоroundaBike
* направи самdo it yourself
софтуерът-и-азsoftware-and-i
* био/cvcv
>> #OpenToWork <<
| '2008-2024 ~ началоstart ~ софтуерът-и-азsoftware-and-i ~ биография/cvcv/resume ~ библиотекаlibrary ~ снимкиphotos ~ детскиkids' ~ | az()svilendobrev _ com |