Lean разработка на софтуер

Стегнатата разработка на софтуер (Lean software development (LSD)) представлява адаптиране на принципите и похватите на стегнатото производство и стегнатото ИТ (lean IT) за приложение в сферата на софтуерното инженерство. Възприела основните принципи на системата за производство на Тойота, поддръжниците на стегнатата разработка постепенно се оформят като група сред привържениците на гъвкавите методологии.

Произход

Терминът стегната разработка на софтуер произлиза от едноименната книга на Mary Poppendieck и Tom Poppendieck. Книгата представя традиционните принципи на стегнатото производство в модифицирана форма, както и набор от 22 инструмента, като ги сравнява с гъвкавите практики. Участието на семейство Poppendieck в общността на гъвкавите методологии, включително докладите на няколко конференции по гъвкави методологии за разработка на софтуер, допринася за по-широкото възприемане на нововъведените концепции сред привържениците на гъвкавите методологии.

Принципи

Стегнатата разработка на софтуер може да се обобщи в няколко принципа, много близки като концепция до принципите на стегнатото производство:

Отърви се от излишното
Подобри научаването
Решавай възможно най-късно
Доставяй възможно най-бързо
Упълномощи екипа
Създай цялостност
Гледай общата картина

Отърви се от излишното

Всичко, което не допринася полза за клиента, се счита за излишно, за отпадък (muda). Това включва:

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

За да бъдат елиминирани излишъците, те трябва да бъдат идентифицирани. Ако някоя от дейностите може да бъде избегната или резултатът може да бъде постигнат и без нея, тя е излишна. Код, написан донякъде и изоставен в хода на процеса на разработка на софтуера, е излишък. Допълнителни процеси и функционалности, които не се използват често от потребителите, е излишък. Изчакване на други дейности, екипи или процеси е излишък. Дефектите и ниското качество са излишък. Мениджмънт нива, които не добавят реална стойност, са излишък. За да се отличат и разпознаят излишъците, се използва техниката на value stream mapping. Втората стъпка е да се идентифицират източниците на излишъци и да се елиминират. Тези стъпки би следвало да се повтарят итеративно дотогава, докато дори процеси и процедури, които привидно изглеждат съществени, бъдат идентифицирани и премахнати.

Подобри научаването

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

Процесът на учене допълнително се ускорява от кратки итерационни цикли – всеки последван от рефакторизация и интеграционно тестване. Интензификацията на обратната връзка чрез кратки сесии с потребителите помага за определянето на актуалната фаза на разработка и калибриране на усилията за бъдещи подобрения. По време на тези кратки сесии както представителите на потребителите, така и екипите от разработчици научават повече за конкретния проблем и идентифицират възможни решения за бъдещо развитие. По този начин самите потребители разбират по-добре своите нужди, базирано на резултатите от усилията на разработчиците до момента, а разработчиците научават как по-добре да удовлетворят нуждите на потребителите. Друга полза от непрекъснатата комуникация и процес на учене между разработчиците и потребителите е разработката, при която се набляга на обсъждането на комуникирането на ограниченията на планираното решение (set-based development), а не на възможните решения, като по този начин се стимулира раждането на решението чрез диалог с потребителя.

Решавай възможно най-късно

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

Гъвкавата методология за разработка на софтуер предвижда предоставянето на възможностите на потребителите по-рано в процеса на разработка, като по този начин критичните решения се отлагат за по-късен етап, след като потребителите са осъзнали своите нужди в по-пълна степен. Това позволява и по-късна адаптация към промени и предотвратява скъпите по-ранни решения, зависими единствено от технологиите. Това далеч не означава, че не трябва да бъде извършвано никакво планиране. Напротив, планиране трябва да има и то да бъде насочено към различните варианти и към адаптирането към моментната ситуация, както и изясняване на неясните ситуации чрез изготвянето на схеми за бърза реакция. Оценяването на различни опции е ефективно дотолкова, доколкото е осъзнато, че те имат своята цена, но предоставят необходимата гъвкавост за по-късно вземане на решение.

Доставяй възможно най-бързо

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

Идеологията за продукция тъкмо навреме може да бъде приложена към разработката на софтуер, отчитайки специфичните изисквания и среда. Това се постига чрез представяне на необходимия резултат и даване на възможност на екипа да се самоорганизира и разпредели задачите така, че необходимият за дадена iteration да бъде постигнат. В началото, потребителят предоставя необходимите входящи изисквания. Те могат да бъдат оформени и съвсем просто, като малки карти или истории, като разработчиците оценяват времето, необходимо за имплементацията на всяка карта. Така организацията на работата се превръща в саморазвиваща се система – всяка сутрин по време на работна среща всеки член на екипа прави равносметка на свършеното през вчерашния ден, какво предстои да бъде направено през днешния и утрешния и получава необходима информация от своите колеги или от потребителя. Това изисква прозрачност на процеса, което е от полза и за комуникацията в екипа.

Друга ключова идея в системата за производство на Тойота е set-based design. Ако например е необходима нова спирачна система за автомобил, решения за този проблем може да бъдат разработени от три екипа едновременно. Всеки екип изучава проблемната област и разработва потенциално решение. Ако то бъде счетено за неподходящо, разработката му се прекратява. В края на периода оцелелите дизайни се сравняват и един от тях бива избран, евентуално с някои модификации, възприети от другите – прекрасен пример за отлагане на крайното решение до последния възможен момент. Софтуерните разработки също могат да се възползват от подобна практика, за да минимизират риска от пълното предварително планиране.

Упълномощи екипа

Традиционното вярване в повечето фирми относно вземането на решения е, че мениджърите казват на работниците как да свършат своята работа. В Work-Out техниката ролите са обърнати – мениджърите се учат как да слушат разработчиците, за да могат да обяснят по-добре какви действия да бъдат предприети, както и да изкажат предложения за подобрения. Стегнатият подход подкрепя афоризма „намерете добри хора и ги оставете да си вършат сами работата“, окуражава напредъка, улавя грешките и премахва пречките, но не управлява на микро ниво.

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

Създай цялостност

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

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

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

Гледай общата картина

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

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

Практики за стегната разработка на софтуер

Практиките на стегната разработка на софтуер, или, както ги наричат семейство Попендийк „инструменти“, се реализират малко по-различно, отколкото своите еквиваленти в гъвкава методология за разработка на софтуер, но съществуват директни паралели. Примери за такива практики включват:

Някои от инструментите съвсем естествено се съотнасят към гъвкава методология. Workcells например се реализират в гъвкавата методология чрез смесени екипи.

Вижте също

Източници

Yasuhiro Monden (1998), Toyota Production System, An Integrated Approach to Just-In-Time, Third edition, Norcross, GA: Engineering & Management Press, ISBN 0-412-83930-X.
Mary Poppendieck, Tom Poppendieck (2003), "Lean Software Development: An Agile Toolkit", Addison-Wesley Professional, ISBN 0-321-15078-3
Ladas, Corey. Scrumban: Essays on Kanban Systems for Lean Software Development. Modus Cooperandi Press, януари 2008. ISBN 0-578-00214-0.

Външни препратки

Тази страница частично или изцяло представлява превод на страницата Lean_software_development в Уикипедия на английски. Оригиналният текст, както и този превод, са защитени от Лиценза „Криейтив Комънс – Признание – Споделяне на споделеното“, а за съдържание, създадено преди юни 2009 година – от Лиценза за свободна документация на ГНУ. Прегледайте историята на редакциите на оригиналната страница, както и на преводната страница, за да видите списъка на съавторите.

ВАЖНО: Този шаблон се отнася единствено до авторските права върху съдържанието на статията. Добавянето му не отменя изискването да се посочват конкретни източници на твърденията, които да бъдат благонадеждни.