Вам, як програмісту, байдуже, який метод використовує процес розробки?

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

Чи є пріоритетною для вас методологія процесу розробки?

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

Коли ми говоримо про контроль версій, є аргумент, що any version control beats not having anything at allце не так з методами розробки. Методи означають правила, а правила іноді порушуються. Я працював у компаніях, які займаються дійсно густими речами стільки часу, скільки хто може пригадати, незалежно від того, яка проблема, з якою виникла процедура гуфії, минула давно.

Я хочу від компанії:

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

• Докази того, що компанія відкрита до зміни процедур на краще. Мені потрібно зуміти зайти до когось і сказати: "Я розумію, для чого ти робиш [xyz], але є інструмент, який зараз робить для тебе більшу частину цього. Чи можемо ми ним скористатися?"

• Невелика конкуренція може бути хорошою і часто неминучою. Але я уникаю будь-якого магазину, де конкуренція використовується як основний засіб мотивації людей. Якщо ви зашифрували щось, що надсилає кількість рядків, що в день розробляється розробником, на лазерний принтер о 17:00, я не хочу працювати на вас.

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

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

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

Інший гучний "о ні, ніколи більше!" це «Ми сподіваємося , ви будете також встановити кращі практики для нас. У нас є шість мільйонів рядків коду і 21 надомні, ми повинні використовувати в SVN або що - то?» .

Хтось міг повеселитися, розбираючи це. Я не той хлопець :)

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

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

Так, я бачив деякі погані методології, які, думаю, не хотів би повторити. В якості кількох прикладів розглянемо наступне: Чи добре ви будете з ковбойським стилем для команди з десятка розробників, де кожен може використовувати власний контроль над джерелами, умови кодування тощо? Я знаю, що не хотів би. Як щодо де змінити рядок коду, є десяток форм, які потрібно заповнити, і близько 20 підписів, щоб добре змінити виробництво, яке може зайняти кілька тижнів, щоб завершити роботу, коли випуск вищого керівництва може зайняти деякий час? «Що б там не було» залишає речі занадто відкритими для мого розуму, але, можливо, я тут трохи цинічний.

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

Так, наприклад, я не хотів би працювати в компанії, яка робить "ковбойське кодування" , особливо якщо вони недостатньо неосвічені, щоб думати, що вони насправді роблять Agile .

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

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

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