Короткі шляхи, швидкі рішення

Бережна розробка програмного забезпечення набуває дедалі більшого значення в останні роки. Однак недостатньо використовувати неграмотну розробку програмного забезпечення лише в команді розробників; вимоги та процес концепції також повинні бути організовані "бережливо". Лікар. У цій статті, що складається з двох частин, Маттіас Ебершпяхер описує випробувану організаційну структуру, яка дає змогу створити чітке програмне забезпечення. У першій частині він представляє два найважливіші органи цієї організації.

зміст

Що таке і звідки береться «Худий»?
Організація проекту
Основна команда (KT)
Мандатари (MT)
світогляд
література

предметів

Серія статей

Центральні органи та їх завдання
Подальші ролі та рекомендації для практики

зміст

Що таке і звідки береться «Худий»?
Організація проекту
Основна команда (KT)
Мандатари (MT)
світогляд
література

Toyota показала, як це: Сьогодні машини випускаються "худими". Виробництво здійснюється не "на складі", а під замовлення; доставляються лише деталі, які встановлюються негайно. Але чи можна програмне забезпечення також програмувати так само, як виготовляють машини? Так, ти можеш! Метою щадної розробки програмного забезпечення є мінімізація часу виконання від запиту до введення готового програмного забезпечення в експлуатацію. Однак недостатньо лише використовувати Lean Software Development в команді розробників: вимоги та процес концепції також повинні бути організовані "Lean". Тут найважливішим є успіх у створенні та підтримці рівномірного "спонукання клієнтів", що робить можливим ефективну ощадливу розробку програмного забезпечення.

Ця стаття з двох частин присвячена саме інтерфейсу між користувачами та командою розробників. Показано, як менеджери проектів та клієнти ідеально налаштовують проектну групу для проекту, що відповідає вимогам, як вимоги та процес концепції чітко контролюються та що потрібно враховувати. Навіть якщо перший досвід цієї процедури був накопичений у програмних проектах автовиробників, немає жодної можливості застосувати описані тут концепції до інших типів проектів розвитку та галузей.

У першій частині описується, що стоїть за процесом управління ощадливим процесом і які додатки концепцій ощадливості існують при розробці програмного забезпечення. Описана організація структури проектів, яка дає змогу створити концепцію ощадливого програмного забезпечення, а також докладно описані найважливіший комітет - основна команда - та найважливіша роль - власників мандатів - цієї організації. Друга частина завершує опис окремих комітетів та ролей, наприклад, керівника проекту, та пояснює процес проекту на практичному прикладі. Завершується стаття рекомендаціями, що випливають із досвіду використання такого підходу в проектах.

Я мав дуже хороший досвід з проектним підходом та організацією, представленими в моїх проектах. Ідея цього підходу застосовується не лише до проектів, що виконуються виключно згідно з ощадливими принципами, але і до проектів, в яких подальша реалізація концепцій відбувається згідно з іншими гнучкими або навіть традиційними моделями процесів (наприклад, водоспад) . Мотивація до ощадливого підходу в управлінні вимогами та концепції, безумовно, тим більша, якщо інша частина реалізації проекту є спритною та стрункою. Методологія, представлена тут, має на меті послужити пропозицією використовувати для себе струнку проектну організацію та розвивати її далі.

Переваги підходу

Переваги процедури, показаної в цій статті, вступають у дію лише при достатньому обсязі проекту: Тривалість повинна бути більше шести місяців, а команда проекту повинна включати щонайменше десять штатних працівників проекту. В іншому випадку зусилля, спрямовані на створення та створення проектної організації, включаючи навчання персоналу проекту, перевищують переваги процедури.

Щоб проілюструвати цю перевагу, інформативним є порівняння запланованого обсягу реалізації з обсягом послуг, які фактично обробляються за інтервал планування (як правило, один рік): Це показує, що розробки, що виконуються на рік, були приблизно вдвічі вищими від запланованих спочатку. Іншими словами: маючи потужності, доступні для технічної концепції, можна концептуалізувати приблизно вдвічі більше тем, ніж планувалося. Планування цих проектів, по суті, базувалося на емпіричних цінностях традиційних проектів: Скільки тем може досягти достатньої технічної концептуальної зрілості для реалізації протягом одного року? Звичайно, з цього числа не можна вивести, що представлена тут процедура вдвічі краща, ніж, наприклад, модель водоспаду; однак, це чітке свідчення того, що робота з тонкими концепціями може бути набагато ефективнішою, ніж традиційні процедурні моделі.

Типовим проектним середовищем, в якому застосовувався цей підхід, були проекти для (подальшого) розвитку та/або консолідації існуючих ІТ-ландшафтів у виробників автомобілів. Сильні сторони процедури були особливо очевидні, коли вимоги, що мають бути реалізовані, ще не були повністю готовими до технічної концепції, а були відомі лише на "рівні заголовка", тобто лише приблизно у вигляді списку тем у таблиці Excel. Для того, щоб визначити бюджет і часові рамки, з якими може працювати команда проекту, цілі проекту/бізнесу завжди були чітко сформульовані («SMART») і була доступна структура розподілу робіт із визначеними заголовками робочого пакету.

Ефективність окремих робочих пакетів завжди можна розрізати на досить малі, незалежні розміри партії. Це є важливою передумовою, оскільки це єдиний спосіб досягти коротких і рівних термінів проекту. Для реалізації проекту були доступні внутрішні співробітники спеціалістів та ІТ-відділів, а також зовнішні консультанти та постачальники від постачальників ІТ-послуг з етапами технічної концепції, ІТ-концепції, впровадження, інтеграції та приймально-здавальних випробувань та введення в експлуатацію.

Що таке і звідки береться «Худий»?

"Lean" походить від виробничої системи Toyota (TPS), яка спрямована на оптимізацію організаційних процесів. Найвідоміша концепція TPS - це виробництво, синхронізоване з попитом ("вчасно"): лише деталі надсилаються на ...