2 Използвани съкращения и символи

32
Тъй като разработката на софтуер винаги е свързанa с известна доза неизвестност, по-добри резултати биха се получили отлагайки решението колкото е възможно повече, така че то да може да бъде базирано на факти, а не на несигурни предположения и очаквания. Колкото по-комплексна е една система, толкова повече гъвкавост и възможности за промени трябва да бъдат предвидени в нея, предоставяйки възможности за отлагане на важни и съществени конкретни ангажименти за реализация. Итеративният подход застъпва точно този принцип – възможността за адаптиране към промени и поправяне на грешки, което би могло да бъде много скъпо, ако необходимостта бъде открита едва след официалното излизане на системата.
Гъвкавата методология за разработка на софтуер предвижда предоставянето на възможностите на потребителите по-рано в процеса на разработка, като по този начин критичните решения се отлагат за по-късен етап, след като потребителите са осъзнали своите нужди в по-пълна степен. Това позволява и по-късна адаптация към промени и предотвратява скъпите по-ранни решения, зависими единствено от технологиите. Това далеч не означава, че не трябва да бъде извършвано никакво планиране. Напротив, планиране трябва да има и то да бъде насочено към различните варианти и към адаптирането към моментната ситуация, както и изясняване на неясните ситуации чрез изготвянето на схеми за бърза реакция. Оценяването на различни опции е ефективно дотолкова, доколкото е осъзнато, че те имат своята цена, но предоставят необходимата гъвкавост за по-късно вземане на решение.
- Доставяй възможно най-бързо
В ерата на бързо развитие на технологиите, оцелява не най-голямото, а най-бързото.
Колкото по-скоро бъде доставен един продукт без съществени дефекти, толкова по-скоро може да бъде получена обратна връзка и да бъде взета предвид в следващата итерация.
Колкото по-кратки са итерациите, толкова по-добро е научаването и комуникацията вътре в екипа. Без необходимата скорост, решенията не могат да бъдат отлагани.
Скоростта осигурява изпълнението на актуалните нужди на потребителя, а не на това, което им е било необходимо вчера. Това им дава възможност да отложат вземането на решение за това от какво наистина имат нужда докато придобият повече и по-добро познание. Потребителите ценят бързото получаване на качествен продукт.

33
Идеологията за продукция тъкмо навреме може да бъде приложена към разработката на софтуер, отчитайки специфичните изисквания и среда. Това се постига чрез представяне на необходимия резултат и даване на възможност на екипа да се самоорганизира и разпредели задачите така, че необходимият за дадена итерация да бъде постигнат. В началото, потребителят предоставя необходимите входящи изисквания. Те могат да бъдат оформени и съвсем просто, като малки карти или истории, като разработчиците оценяват времето, необходимо за имплементацията на всяка карта. Така организацията на работата се превръща в саморазвиваща се система – всяка сутрин по време на работна среща всеки член на екипа прави равносметка на свършеното през вчерашния ден, какво предстои да бъде направено през днешния и утрешния и получава необходима информация от своите колеги или от потребителя. Това изисква прозрачност на процеса, което е от полза и за комуникацията в екипа.
- Упълномощи екипа
Традиционното вярване в повечето фирми относно вземането на решения е, че мениджърите казват на работниците как да свършат своята работа. В Work-Out техниката ролите са обърнати – мениджърите се учат как да слушат разработчиците, за да могат да обяснят по-добре какви действия да бъдат предприети, както и да изкажат предложения за подобрения. Стегнатият подход подкрепя афоризма "намерете добри хора и ги оставете да си вършат сами работата", окуражава напредъка, улавя грешките и премахва пречките, но не управлява на микрониво.
Друго погрешно убеждение е разглеждането на хората като ресурси. Хората могат да бъдат средства от гледна точка на статистическа таблица, но в разработката на софтуер, както и във всяка организационна дейност, хората се нуждаят от нещо повече от списък от задачи и от уверението, че няма да бъдат безпокоени по време на извършването им. Хората се нуждаят от мотивация и по-висока цел, за която да работят
– цел в рамките реалността, с уверението, че екипът може да избира собствените си приноси. На разработчиците трябва бъде даден достъп до клиента; ръководителят на екипа трябва да осигурява подкрепа и помощ в трудни ситуации, както и да гарантира, че скептицизмът не съсипва духа на екипа.
- Създай цялостност

34
Клиентът трябва да има цялостен опит със системата – това е така нареченият възприеман интегритет: как системата се рекламира, доставя, инсталира, достъпва, колко интуитивна е употребата ѝ, каква е цената ѝ и доколко добре решава проблеми.
Концептуалната цялост означава, че отделните компоненти на системата работят добре заедно, като едно цяло, с баланс между гъвкавост, възможност за поддръжка, ефективност и отзивчивост. Това може да се постигне чрез разбиране на сферата на проблема и решаването му в същото време, не последователно. Необходимата информация се получава на малки части – не в един огромен документ, за предпочитане е комуникацията лице в лице, а не писмената документация. Потокът на информация трябва да бъде постоянен и в двете посоки – от клиент към разработчиците и обратно, избягвайки по този начин голямото стресиращо количество информация след дълга разработка в изолация.
Един от най-добрите начини за постигане на цялостна архитектура е преработка на код. Тъй като се добавят все повече функции към първоначалната версия код, толкова по-трудно става добавянето на по-нататъшни подобрения. Чрез преработка на код се запазва простотата, яснотата, минималното количество функции в кода. Повторенията в кода са знаци за некачествено написани проекти и трябва да бъдат избягвани. Пълният и автоматичен процес на разработка трябва да бъде придружен от пълен набор от автоматизирани тестове от разработчици и клиенти, които притежават същата версия, синхронизация и семантика като текущото състояние на системата. Накрая интегритетът трябва да бъде проверен чрез цялостен тест, който да подсигури, че система прави това, което клиентът очаква от нея. Автоматизираните тестове се считат също за част от производствения процес, затова, ако не добавят стойност, те са излишни.
Автоматизираното тестване не трябва да бъде цел само по себе си, а по-скоро средство за намаляване на дефектите.
- Гледай общата картина
Софтуерните системи в днешно време не са просто сбор от части, а също така и продукт от техните взаимодействия. В софтуера са склонни да се натрупват дефекти през процеса на разработка – чрез разбиване на големите задачи на по-малки и чрез стандартизиране на различните етапи на разработка, първопричините за дефектите трябва да бъдат открити и премахнати. Колкото по-голяма е системата, толкова повече

35 организации участват в разработката ѝ и толкова повече нейни части са разработени от различни екипи, тогава толкова по-важно е да има добре дефинирани връзки между различните доставчици, за да се получи система с гладко взаимодействие на компонентите. При по-дълъг период на разработка, силната мрежа от подизпълнители е много по-полезна, отколкото краткосрочното оптимизиране на печалбата, което не дава възможност за дългосрочни взаимоотношения.
Lean подходът трябва да бъде добре разбиран от всички членове на даден проект, преди да се приложи в конкретна, реална ситуация. "Мисли мащабно, действай на дребно, проваляй се бързо, учи бързо" – тези лозунги обобщават значението на разбирането на сферата и пригодността на въвеждането на lean принципи през целия процес на разработка на софтуер. Само когато всички lean принципи се прилагат заедно, в съчетание с добро разбиране за работната среда, има основа за успех в разработката на софтуер.

Изтегляне 0.67 Mb.

Сподели с приятели: