Кратки начини, бързи решения

Лекото разработване на софтуер става все по-важно през последните години. Въпреки това не е достатъчно само да се използва постно разработване на софтуер в екипа за разработка; изискванията и процесът на концепция също трябва да бъдат организирани „постно“. Д-р В тази статия от две части Matthias Eberspächer описва изпитана организационна структура, която дава възможност за концепция за по-лек софтуер. В първата част той представя двата най-важни органа на тази организация.

съдържание

  1. Какво е и откъде идва "Lean"?
  2. Организацията на проекта
  3. Основният екип (KT)
  4. Притежателите на мандати (MT)
  5. перспектива
  6. литература

начини

субекти

Поредица от статии

  1. Централни органи и техните задачи
  2. Допълнителни роли и препоръки за практиката

Лекото разработване на софтуер става все по-важно през последните години. Въпреки това не е достатъчно само да се използва постно разработване на софтуер в екипа за разработка; изискванията и процесът на концепция също трябва да бъдат организирани „постно“. Д-р В тази статия от две части Matthias Eberspächer описва изпитана организационна структура, която дава възможност за концепция за по-лек софтуер. В първата част той представя двата най-важни органа на тази организация.

съдържание

  1. Какво е и откъде идва "Lean"?
  2. Организацията на проекта
  3. Основният екип (KT)
  4. Притежателите на мандати (MT)
  5. перспектива
  6. литература

Toyota показа пътя: Днес автомобилите се произвеждат „постно“. Производството не се извършва "на склад", а по поръчка; доставят се само частите, които се инсталират незабавно. Но може ли софтуерът да бъде програмиран по същия начин, както се произвеждат автомобилите? Да, можеш! Целта на постното разработване на софтуер е да се сведе до минимум времето за изпълнение от заявката до пускането в експлоатация на готовия софтуер. Въпреки това не е достатъчно само да се използва Lean Software Development в екипа за разработка: Изискванията и процесът на концепция също трябва да бъдат организирани „Lean“. От решаващо значение за успеха тук е създаването и поддържането на равномерно „привличане на клиенти“, което позволява ефективно разработване на постно софтуер.

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

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

Имам много добър опит с проектния подход и организация, представени в моите проекти. Идеята, която стои зад този подход, е приложима не само за проекти, които се изпълняват изключително в съответствие със стройни принципи, но също така и за проекти, при които последващото изпълнение на концепциите се извършва съгласно други гъвкави или дори традиционни модели на процеса (например водопад) . Мотивацията за лек подход при управлението и концепцията на изискванията е, разбира се, още по-голяма, ако останалата част от изпълнението на проекта е гъвкава и стройна. Представената тук методология има за цел да служи като предложение да използвате за себе си стройна организация на проекти и да я доразвиете.

Предимства на подхода

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

За да се илюстрира тази полза, сравнението на планирания обхват на изпълнение с обхвата на действително обработените услуги за интервал на планиране (обикновено една година) е информативно: Това показва, че извършените разработки годишно са били около два пъти по-високи от първоначално планираните. С други думи: С наличния капацитет за техническата концепция, около два пъти повече теми могат да бъдат осмислени от планираното. Планирането на тези проекти се основаваше основно на емпирични стойности от традиционните проекти: Колко теми могат да постигнат достатъчна техническа концептуална зрялост за изпълнение в рамките на една година? Разбира се, от това число не може да се изведе, че представената тук процедура е два пъти по-добра от например модела на водопада; това обаче е ясна индикация, че работата с постни концепции може да бъде много по-ефективна от традиционните процедурни модели.

Типичната среда за проекти, в която се прилага този подход, бяха проекти за (по-нататъшно) развитие и/или консолидиране на съществуващите ИТ пейзажи при автомобилните производители. Силните страни на процедурата са показани по-специално, когато изискванията, които трябва да бъдат изпълнени, все още не са напълно готови за техническа концепция, а само на „ниво на заглавието“, напр. бяха известни само приблизително под формата на списък с теми в таблица на Excel. За да се определи бюджет и времева рамка, с която екипът на проекта може да работи, целите на проекта/бизнеса винаги са били ясно формулирани („SMART“) и е налице структура на разбивка на работата с дефинирани заглавия на работния пакет.

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

Какво е и откъде идва "Lean"?

„Lean“ идва от производствената система на Toyota (TPS), която се фокусира върху оптимизирането на организационните процеси. Най-известната концепция на TPS е синхронизираното с търсенето производство („точно навреме“): Само частите се изпращат на ...