Як здобути особисту практику в методології розвитку важкої ваги?

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

Я радий залишити хаос ковбойського кодування і мені цікаво бачити, наскільки добре працюють важкі інженерні методи. Але як можна швидко набути досвіду з важкими методами?

Окрім того, що просто на роботі протягом деякої кількості місяців / років, тобто.

За допомогою простої мови або нового API можна зламати програму тестування іграшок, читати, навмисно робити помилки, щоб побачити, що відбувається і т. Д. На кшталт того, щоб стати хорошим у їзді на велосипеді чи на музичному інструменті, практика є важливою. Легко підібрати флейту і щодня проводити півгодини; не потрібно приєднуватися до оркестру або бути штатним консультантом флейти. Але як практикувати великі, складні заходи з розробки програмного забезпечення, залучати команди, і багато з них стосується спілкування та планування, а також уникнення неправильної комунікації та перевищення графіку та обмежень бюджету?

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

Чи існує спосіб, коли невелика кількість людей зможе за короткий час (за один день) імітувати цілий великий проект у невеликому масштабі?

Так, це можливо до певної міри. Близько 10 років тому я взяв участь у семінарі на конференції OOP в Мюнхені, де 16 людей отримали завдання зробити грубий аналіз та розробити програмне забезпечення для малого бізнесу. Перша половина дня в основному полягала в пошуку структури команди для вирішення завдання з 16 людьми, а друга половина дня була зосереджена на вирішенні завдання з цією командою.

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

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

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

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

Виберіть зразок програми для роботи. Якщо ви не можете придумати його, google "коди катав" або перегляньте архів проблем Google Codejam. Або просто побудувати калькулятор. :-)

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

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

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

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

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

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