Як моделювати людину, машину, заходи та процес у світі DevOps?


17

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

Однак щоразу, коли я моделюю процес (наприклад, життєвий цикл квитка підтримки), я намагаюся це врахувати.

Мої робочі процеси зазвичай включають:

  • Допомога на першій лінії
  • Техніка / Розробка / Більше технічної допомоги команді
  • Огляд коду
  • Тестування
  • УАТ
  • Розгортання

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

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

Відповіді:


6

Те, про що вони говорять, - це Kaizen 5M (Людина, машина, матеріал, метод, вимірювання). Це підхід до постійного вдосконалення на кожній станції в процесі, і пані є можливими точками вдосконалення, до яких виникає відповідне питання (5Q). Іноді середовище додається для 6-го, як у цьому процесі, який пояснює, як побудувати питання за допомогою діаграми Ісікава . Це майже все необхідне в TPS / Lean Manufacturing . Але поліпшення не в використанні, вони в поліпшенні якості. Ви ніколи не прагнете до використання, оскільки це є контрпродуктивним для пропускної здатності системи .

Важливо розуміти, що Людина, Машина, Матеріал, Метод та Вимірювання не розділяються легко. Іноді Машина, Матеріал та Вимірювання збираються на одній стороні разом, а людина та метод - з іншого. Оскільки ви можете замінити людину та метод на цій робочій станції.

Що стосується розробки програмного забезпечення, у вас є програмне забезпечення (машина), випуски (матеріал), якість / прийняття коду (вимірювання), людина (програміст) та метод (процес розробки). Людина тренується на машині та ознайомлюється з нею, з матеріалом, над яким працює, розуміє необхідні вимірювання, засвоює процес. Всі вони живуть у мозку людини, і тому їх легко не відокремити. Зміна методу можлива лише в тому випадку, якщо Людина ще не повністю її усвідомила, інакше змінити Людина і Метод стає простіше. Також машина, матеріал та вимірювання часто пов'язані між собою за допомогою автоматизації та конфігурації. Ось чому вони малюються на протилежних сторонах діаграми.

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

Ви не хочете оптимізувати окремі станції вашого процесу (Замовник-> Підтримка-> Розробка-> Огляд-> Тестування-> Прийняття користувача-> Розгортання-> Клієнт), але вам потрібно моделювати переходи між цими робочими станціями. , їх залежності та контролювати рух у процесі роботи (WIP) через систему. Зазвичай за допомогою програмного забезпечення для відстеження випусків (або системи Kanban), що еквівалентно відстеженню матеріалів у виробництві. Там, де WIP накопичується перед робочою станцією у вашому критичному ланцюговому процесі, ви знайдете вузьке місце і саме там ви хочете оптимізувати за допомогою Kaizan (5 Мс, 5Q)

Зауважте: я додав Клієнта як на початку, так і в кінці вашого процесу, оскільки кожен ланцюжок вартості повинен починатись і закінчуватися у Замовника, інакше він не представляє цінності для компанії.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.