Кратки начини, брзи одлуки

Развојот на посно софтвер стана сè поважен во последните неколку години. Сепак, не е доволно да се користи развој на чист софтвер само во тимот за развој, барањата и процесот на зачнување, исто така, мора да бидат организирани „посно“. Д-р Во оваа статија од два дела, Матијас Еберспекер опишува испробана организациска структура што овозможува концепт на чист софтвер. Во првиот дел тој ги воведува двете најважни тела на оваа организација.

содржина

Што е и од каде потекнува „Lean“?
Организацијата на проектот
Главниот тим (КТ)
Носители на мандатот (МТ)
изгледи
литература

предмети

Серија на написи

Централните тела и нивните задачи
Понатамошни улоги и препораки за вежбање

Развојот на посно софтвер стана сè поважен во последните неколку години. Сепак, не е доволно да се користи развој на чист софтвер само во тимот за развој, барањата и процесот на зачнување, исто така, мора да бидат организирани „посно“. Д-р Во оваа статија од два дела, Матијас Еберспекер опишува испробана организациска структура што овозможува концепт на чист софтвер. Во првиот дел, тој ги воведува двете најважни тела на оваа организација.

содржина

Што е и од каде потекнува „Lean“?
Организацијата на проектот
Главниот тим (КТ)
Носители на мандатот (МТ)
изгледи
литература

Тојота го покажа патот: Денес автомобилите се произведуваат „посни“. Производството не се врши „на залиха“, туку по нарачка, се испорачуваат само деловите што се инсталираат веднаш. Но, дали софтверот може да се програмира на ист начин како што се прават автомобилите? Да ти можеш! Целта на развојот на чистиот софтвер е да се минимизира водечкото време од барањето до пуштање во работа на готовиот софтвер. Сепак, не е доволно да се користи само развојот на Lean Software во тимот за развој: Барањата и процесот на зачнување, исто така, мора да бидат организирани "Lean". Критично за успехот тука е воспоставувањето и одржувањето на рамномерно „повлекување на клиентите“, што е она што го прави возможен ефикасниот развој на чист софтвер.

Овој напис во два дела се фокусира токму на интерфејсот помеѓу корисниците и тимот за развој. Тоа покажува како проектните раководители и клиентите идеално го поставуваат проектниот тим за чист проект, како процесот на барање и зачнување се контролира на слаб начин и што треба да се разгледа. Дури и ако првото искуство со овој пристап беше стекнато во софтверски проекти кај производители на автомобили, нема ништо во начинот на примена на концептите опишани овде на други видови развојни проекти и индустрии.

Првиот дел опишува што стои зад чистото управување и кои апликации на посни концепти постојат во развојот на софтвер. Опишана е организација за структура на проект, што овозможува посно концепт на софтвер и детално се опишани најважниот комитет - основниот тим - и најважната улога - улогата на носителите на мандатот. Вториот дел го комплетира описот на одделните комитети и улоги, на пример, менаџерот на проектот и го објаснува процесот на проектот користејќи практичен пример. Написот завршува со препораки што произлегоа од искуството со овој пристап во проектите.

Имав многу добри искуства со пристапот на проектот и организацијата претставена во моите проекти. Идејата зад овој пристап не е применлива само за проекти кои се изведуваат исклучиво според посно принципи, туку и за проекти во кои последователната имплементација на концептите се одвива според други агилни, па дури и традиционални модели на процеси (на пр. Водопад) . Мотивацијата за слаб пристап во управувањето со барањата и концепцијата е секако поголема доколку остатокот од спроведувањето на проектот е агилен и слаб. Методологијата презентирана овде има за цел да послужи како предлог за употреба и развој на посно организирана проектна програма за себе.

Предности на пристапот

Предностите на постапката прикажана во овој напис влегуваат во игра само со доволен обем на проектот: Времетраењето треба да биде повеќе од шест месеци, а тимот на проектот треба да вклучува најмалку десет вработени во проектот со полно работно време. Инаку, напорите вклучени во поставувањето и воспоставувањето на проектната организација, вклучително и обука на проектниот персонал, ги надминуваат придобивките од постапката.

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

Типичното опкружување на проектот во кое се применуваше овој пристап беа проекти за (понатамошен) развој и/или консолидација на постојните ИТ пејзажи кај производителите на автомобили. Предностите на постапката беа особено очигледни кога барањата што треба да се спроведат сè уште не беа целосно подготвени за технички концепт, но беа познати само на „ниво на наслов“, т.е. само грубо во форма на список на теми во табелата во Excel. Со цел да се утврдат буџетот и временската рамка со кои проектниот тим може да работи, целите на проектот/деловните активности секогаш беа јасно формулирани („СМАРТ“) и беше достапна структура за разградување на работата со дефинирани наслови на работниот пакет.

Перформансите на индивидуалните работни пакети секогаш може да се пресечат во доволно мали, независни големини на многу. Ова е важен предуслов бидејќи тоа е единствениот начин да се постигне краток, па дури и временски распоред на проектот. Внатрешни вработени во специјалистичките и ИТ одделенијата, како и надворешни консултанти и добавувачи од даватели на ИТ услуги беа достапни за имплементација на проектот со фазите на техничко замислување, ИТ концепција, имплементација, тестови за интеграција и прифаќање и пуштање во работа.

Што е и од каде потекнува „Lean“?

„Lean“ потекнува од системот за производство на Toyota (TPS), кој се фокусира на оптимизирање на организациските процеси. Најпознат концепт на TPS е синхронизирано производство побарувачка („точно навреме“): само деловите се испраќаат до ...