Agile Product Development Processes

kun perinteisiin mekaanisiin tuotteisiin sisällytetään enemmän elektronisia laitteita ja ohjelmistoja, valmistajat etsivät parempia tapoja integroida suunnittelutoimintoja eri tieteenalojen kesken. Tämän seurauksena monet suunnittelu-ja kehittämiskäytännöt vaihtuvat. Yksi tällainen aloite, Ketterä tuotekehitys, liittyy ketterien menetelmien soveltamiseen mekaaniseen suunnitteluun, sähkösuunnitteluun ja laajempaan tuotekehitykseen.

Defining Agile for Hardware

hyvä paikka alkaa ymmärtää, miten ketteriä menetelmiä sovelletaan tuotekehitykseen on Wikipedian merkintä ketterästä ohjelmistokehityksestä.

Ketterä ohjelmistokehitys on iteratiiviseen ja inkrementaaliseen kehitykseen perustuva ohjelmistokehitysmenetelmien ryhmä, jossa vaatimukset ja ratkaisut kehittyvät itseorganisoituvien, poikkitoiminnallisten tiimien yhteistyön kautta. Se edistää adaptiivista suunnittelua, evolutiivista kehitystä ja toteutusta sekä aikaraitiotettua iteratiivista lähestymistapaa ja kannustaa nopeaan ja joustavaan reagointiin muutokseen. Se on käsitteellinen viitekehys, joka edistää ennakoitua vuorovaikutusta koko kehityskaaren ajan.

lähde: Wikipedia-merkintä ketterästä ohjelmistokehityksestä

mielenkiintoista on, että nämä ominaisuudet ovat suorassa ristiriidassa perinteisten tuotekehitysmenetelmien kanssa, kuten monet ohjelmistokehitysmenetelmät kymmenen vuotta sitten. Tuotteiden vaatimukset jäädytetään usein jo varhain. Insinööriorganisaatiot ovat usein jämerästi jäsenneltyjä ja niillä on selkeät auktoriteettirajat. Kehitysaikataulut laaditaan usein paljon etukäteen.

silti Ketterä ohjelmistokehitys on saavuttanut laajaa menestystä. Nykyään useimmat ohjelmistokehitysorganisaatiot käyttävät joitakin muunnelmia tästä kehyksestä. Mutta sen sovellettavuus tuotekehitykseen vaatii jonkin verran käännöstä. Alla olevassa taulukossa 1 vasemmassa sarakkeessa on Agile manifestin perusperiaatteet ketterän ohjelmistokehityksen Wikipedia-merkintää kohden. Oikeassa sarakkeessa näkyy näiden periaatteiden kääntyminen ketteräksi Tuotekehitykseksi.

ketterän manifestin periaatteet	vastaava ketterässä tuotekehityksessä
yksilöt ja vuorovaikutus prosessien ja työkalujen yli. yksilöt ja vuorovaikutukset: ketterässä kehityksessä itseorganisoituminen ja motivaatio ovat tärkeitä, kuten myös yhteissijoittamisen ja pariohjelmoinnin kaltaiset vuorovaikutukset.	yhteistyö ja ongelmanratkaisu ovat tärkeämpiä kuin tietyn prosessin tai menettelyn noudattaminen. Koska mekatroniset kysymykset kattavat tieteenaloja, insinöörien täytyy järjestäytyä parhaisiin tiimeihin. Lisäksi näillä ryhmillä olisi oltava valtuudet käsitellä ja ratkaista kysymyksiä.
Working software over comprehensive Dokumentation. Working software: Working software on hyödyllisempää ja tervetulleempaa kuin pelkkä asiakirjojen esittäminen asiakkaille kokouksissa.	toimivat prototyypit, sekä fyysiset että digitaaliset, ovat tärkeämpiä kuin TEKNISET tuotokset, jotka lopulta luovutetaan suunnittelun julkistamisen yhteydessä. Painopisteen tulisi olla suorituskykyä ja muita ominaisuuksia koskevien vaatimusten täyttämisessä.
asiakasyhteistyö yli sopimusneuvottelujen. asiakasyhteistyö: vaatimuksia ei voida täysin kerätä ohjelmistokehityssyklin alussa, joten jatkuva asiakkaan/sidosryhmien osallistuminen on erittäin tärkeää.	asiakkaan tai vastaavan sisäisen edustajan on oltava tiiviisti mukana kehitysprosessissa. Koska kysymyksiä tulee esiin kerta toisensa jälkeen mekatronisten tuotteiden suunnittelun aikana, matkan varrella on oltava todentamis-ja validointivaiheita. Tämä johtaa mekatronisten vaatimusten tarkentumiseen kehitysprosessin aikana.
vastaaminen muutokseen suunnitelman mukaan. muutokseen vastaaminen: Ketterä Kehitys keskittyy nopeaan reagointiin muutokseen ja jatkuvaan kehitykseen.	olisi korostettava organisaation kykyä vastata kehityskysymyksiin sen kykyä noudattaa tiettyä prosessia tai menettelyä. Organisaation tulisikin kyetä vastaamaan mekatronisen kehityksen kysymyksiin ketterästi ja joustavasti.

ketterän

käsittelemiin haasteisiin ketterällä tuotekehityksellä on luonnollisesti mielenkiintoisia vaikutuksia. Sen hyväksymisellä vastataan kuitenkin suoraan kahteen jäljempänä esitettyyn haasteeseen.

trendi	haasteeseen vastattu	myönnetty etu
suunnittelutoimintojen Näkyvyysvaltuutuksen	Suunnittelupäälliköiden on johdettava uudet suunnitteluun perustuvat mittarit, joilla mitataan hyvin suunniteltujen tuotteiden edistymistä.	työprototyyppien painottaminen suoritteiden päälle muuttaa johtajien ajattelua toimitukseen perustuviin mittareihin. Tämä painotus asettaa vaiheen määrittelemään uusia muotoiluun perustuvia mittareita.
tuleva sota Insinööriosaajista	Insinöörijohtajien on löydettävä keinoja värvätä Gen-Y-insinöörejä käyttäen muita etuja kuin rahallista korvausta.	Gen-Yerit ovat luonteeltaan yhteistyöhaluisia sukupolvia ja haluavat vaikuttaa välittömästi. Vuorovaikutuksen korostaminen vetoaa niiden luontaisiin taipumuksiin. Mahdollisuus osallistua tähän kehykseen antaa niille mahdollisuuden vaikuttaa välittömästi.

Steps to Pursue Agile

on julkaistu raportteja ja konsultteja, joilla on laajat ohjeet ketterien menetelmien käyttöönotosta. Useimmat näistä ohjaavista periaatteista koskevat kuitenkin ohjelmistokehitysorganisaation tarpeita eikä mekanronisia tuotteita kehittävää insinööriorganisaatiota. Monet vaiheet ovat samanlaisia, mutta on joitakin tärkeitä eroja:

• lisää sidosryhmiä mukaan: Ihmisten näkökulmasta mekatronisen tuotteen kehittäminen edellyttää mekaanisten, sähkö-ja ohjelmistoinsinöörien sekä valmistus -, laatu -, hankinta-ja palveluorganisaatioiden osallistumista. Kyseessä on huomattavasti monipuolisempi tekninen joukko ihmisiä kuin ketterään ohjelmistokehitykseen osallistuvat, joka koostuu pääasiassa ohjelmistokehittäjistä, testauksesta ja muusta. Engineering manager täytyy tunnistaa tämän tarvittavan organisaation monimutkaisuus ja auttaa tiimejä kuin ne itseorganisoituvat.
• Itseorganisoituva Rakenne: Ensisilmäyksellä voisi olettaa, että ketterä tuotekehitys on kaoottista, koska formaaleja prosesseja on organisoitava ja purettava. Mutta vaikka ei ole muodollista prosessia, se ei tarkoita, etteikö Ketterä tuotekehitys olisi jäsenneltyä. Todellisuus on aivan päinvastainen. Tästä rakenteesta huolimatta ollaan kuitenkin siirtymässä pois virallistetusta prosessista. Insinöörijohtajien on mahdollistettava insinööreilleen tämä siirtymävaihe.