Як я можу подолати погано структуровану модель розробки програмного забезпечення?


11

Я приєднався до компанії, на якій зараз працюю як свіжий. Через обмежену кількість кваліфікованих людей з розробки програмного забезпечення ГІС, і оскільки я був одним із них, мене безпосередньо прийняли на посаду менеджера проекту.

Я дуже розмовляв з Java та GIS, і я робив самовмотивовані дослідження щодо послуг на основі локації, але не з управління проектами та структурованою розробкою програмного забезпечення. Минув рік після закінчення мого закінчення спеціальності з геології, і протягом попереднього року я працював академіком в університеті.

Завдяки зацікавленості, яку я мав на роботі, з’явилася можливість, і врешті-решт я став відповідальним за відділ Business Intelligence компанії. Компанія повірила в мене. Я сам вивчав питання зберігання даних та концепцій BI і мав успіх у поєднанні ГІС із BI.

Також зараз я працюю з двома розробниками над нашим інструментом BI в C # WPF, де я також граю роль розробника часом (що мені подобається).

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

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


4
Я не впевнений, чи є у вас, але ви обговорювали ситуацію зі своїми безпосередніми колегами?
Fanatic23

Відповіді:


14

У нас була аналогічна проблема (без технічних деталей, звичайно) у компанії, в якій я працюю близько двох років тому.

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

Будуйте повільно (але якнайшвидше: P), стабільно та впевнено.

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

  1. Вивчіть хорошу систему управління версіями та добре засвоїте її. Особисто я б рекомендував git або mercurial. На обох є документація.
  2. Побудуйте міцне ядро на практиці та зразках . Читайте книги, читайте блоги, переглядайте скріншоти із членами команди. Це дасть нове повітря розвитку.
  3. Дізнайтеся TDD / BDD і спробуйте застосувати його в новому коді , а також у старому коді, який ви можете торкнутися під час створення нової функції.
  4. Робіть парне програмування . Дві голови думають краще, ніж одна, а також 4 очі краще, ніж 2 :).
  5. Знайти про останніх і найбільш поширених використовуваних інструментів в суспільстві мови ви в даний час розвивається. Дізнайтеся про них та спробуйте включити деякі з них у проект. Подивіться, як вони будувались та дізнайтеся.
  6. Використовуйте scrum . Ітерації, розповіді, сюжетні точки, перешкоди - все це поняття, з якими слід ознайомитися. Для мене scrum виявився найкращим робочим процесом для розробки та управління програмним забезпеченням. Застосовуйте його та вивчайте досвід кожного дня.
  7. Вчити на прикладі . Більшість розробників-початківців охоче вивчають нові речі, але також деякі з них дуже ледачі. У будь-якому разі покажіть їм нові речі, які ви вивчали та застосовуєте, і, сподіваємось, вони будуть лоскотати їх мізки.

Також, якщо можливо, найміть консультанта лише для того, щоб він міг перевірити процес та дати кращі поради.

Не лінуйтеся і не відволікайте. Просто вчіться на своїх помилках і спробуйте різні підходи. Це лише початок!

Редагувати:

Ось деякі посилання та книги, які я читаю / використовую останнім часом ...

Навчання git: Pro Git

Ось кілька блогів, які я рекомендував би (більшість з них орієнтовані на .NET):

Для книг ви можете ознайомитись зі створення списку суцільного програмування на Amazon. Я також рекомендую:


@Edgar, дуже дякую Це круто, і я думаю, що те, що ви пояснили, буде добре для мене. Оскільки я не бачу іншого способу, дайте мені знати, чи нормально сприймати вашу відповідь як правильну та сліпо дотримуватися її.
пікет

1
@picmate Впевнений чоловік, це ваш дзвінок. Також, працюючи на прикладі, не забудьте похвалити будь-який прогрес розробників.
Едгар Гонсалес

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

1
@picmate насамперед, ці кроки не слід застосовувати окремо. Вони перетинаються один з одним, вони не в якомусь конкретному порядку (за винятком першого). Я надсилаю кілька посилань пізніше дня
Едгар Гонсалес

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

6

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

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

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

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

Установіть контроль версій . Дійсно, для налаштування Git потрібно 5-10 хвилин, ще кілька хвилин, щоб знизити основні операції, і день чи два читання, щоб знизити більш вдосконалені концепції.


1

Хм, не впевнений, чи зустрів я тебе на заході Agile / XP у Торонто - це звучить звично

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

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

Існує (beta) сайт pm.stackexchange.com, орієнтований на управління проектами, ви, можливо, отримаєте корисні поради / підтримку там - але, безумовно, тримайте питання і тут.

Переходимо до технічних речей:

не існує системи контролю версій

Поставте його як основний пріоритет. Я віддаю перевагу централізованим системам на зразок SVN (Subversion) над git / mercurial, тому що вкрадений ноутбук не матиме стільки історії локально. Особливо важливо, якщо щось суперсекретне (наприклад, паролі та ssh-ключі) було зареєстровано помилково. Але, справа смаку. Ніщо не витрачає більше часу, ніж помилки з "ручного контролю версій" - наприклад, повернення коду до того, що ви думаєте, що це було.

Удачі


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

0

Здається, у вас є кілька проблем: 1. Спілкування з нетехнічним вищим керівництвом, щоб вони підтримували вашу програму вдосконалення; та 2. Керування програмою вдосконалення для досягнення успіху.

Найважча частина 1 - це просто пам’ятати, що керівництво найчастіше не цікавиться деталями того, над чим ти працюєш. (Якби вони були, вони б робили це самі, а не передавали вам це!) Це здається, що велика перешкода - це "чому", і ви, можливо, захочете подивитися на CMM 1.1 для опису переваг бізнесу від покращення процесів. програма. Незалежно від того, чи використовуєте ви CMM чи щось інше для покращення свого процесу, для цього обговорення не має значення, лише дані дослідження Карнегі-Меллона, які показують, що більш зрілі організації швидше реалізовують проекти з меншими варіаціями часу доставки.

Досягнення успіху в удосконаленні процесів є багато, всі вони, як правило, дуже довгі. Досвід роботи з CMM показує, що перехід від рівня 1 до 5. може зайняти від 8 до 10 років. Досвід роботи з 6 сигмами показує, що кожна ітерація дає певне вдосконалення, але для усунення більшості потенційних проблем потрібні кілька ітерацій, і до того моменту, як ви досягнете 6 ознак якості, робота робиться зовсім по-іншому, не ризикуючи спробувати замінити все відразу.

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

Ви не виграєте кожен запит про підтримку таким чином, ви, мабуть, отримаєте набагато менше порожніх поглядів і більше виграшів, хоча!

Успіхів, сер!


0

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

Як зазначали інші, вам потрібно:

  • Спробуйте застосувати практику по черзі. Не намагайтеся відразу їх усіх, тому що це переповнить людей.
  • Вам потрібно придумати для цього хороший порядок. Я б почав з контролю версій. Тоді йдіть і з легшими. Як тільки люди почнуть довіряти, що ви приймете хороші рішення, і вони побачать вигоди, вони з більшою ймовірністю приймуть більш ризикові зміни.
  • Побудуйте надійний випадок, чому щось потрібно реалізувати. З 2-3 розробниками, які постійно досягають прогресу, помітного для кінцевих користувачів, важко виправдати, наприклад, прийняття більш детальної методології розробки. Ви будете розглядатись як орієнтований на процес, а не на результат.
  • Майте на увазі, кого потрібно переконати. Чорти? Генеральний директор?
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.