Занадто багато контролю над версіями та відстеження помилок накладних витрат за зміну?

Я працюю в місці, яке є божевільним для CVS та Bugzilla-гайками.

1. З кожного випуску стільки гілок, що їх неможливо порахувати. Усі постійно автоматично зливаються.

2. У цій роботі немає плинності . Все відчуває фіксацію . Потрібно 25 кроків навіть для простої речі. Це не так, як бути на заводській лінії виробництва: це як створити завод сам щодня.

Приклад ситуації:

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

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

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

Чи є момент, коли процес стає на шляху і стає самоціллю? Це навіть інженерія?

Чи є момент, коли процес стає на шляху і стає самоціллю?

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

Ось чому спритні стартапи з жменькою хороших інженерів можуть обіграти великі, створені корпорації, працівники яких витрачають 95% своєї енергії на процес та звітування. Деякі приклади колись маленьких стартапів, які колись перемогли своїх конкурентів та / або створили абсолютно нові ринки:

• Яблуко (Apple I був створений 1 інженером, там було 3 чоловіки в компанії тоді).
• Google (створено спочатку двома програмістами).
• Facebook ( спочатку 1- ма зусилля).
• Microsoft ( 2-а компанія 1975 року).

Можна з легкістю сказати, що це просто люди, що випадають, екстремальні винятки, і щоб зробити щось серйозне, вам краще бути великою корпорацією. Але список продовжується. І далі. Це ніяково довго. Майже кожна сьогодні велика корпорація починалася як гаражний магазин, який робив щось незвичне. Щось дивне. Вони робили це неправильно. Як ви думаєте, вони робили це відповідно до процесу?

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

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

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

Якщо ви опинитесь у компанії, яка, здається, у цьому аспекті минула точку неповернення, ви можете або вирішити себе "не піклуватися" про свою роботу (що саме зробили більшість, хто залишився), або вирвати пекло з цілою душею :)

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

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

У всіх інших ситуаціях накладні витрати знищать бізнес. Час рухатись далі.

Це питання дійсно містить два питання, які потрібно вирішити окремо:

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

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

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

Але якщо ви коли-небудь бачили компанію між цими фазами - навіть компанію з яскравим талановитим ІТ-персоналом, - ви зрозумієте, яка небезпека не мати процесу або мати процес напівзростання. Розумієте, спілкування між персоналом страждає від проблеми комбінаторного вибуху ; як тільки ви досягнете рівня близько 6-10 розробників в одній команді, основною причиною основних або критичних дефектів є не дефіцит таланту чи ноу-хау, а швидше відсутність спілкування.

Аліса запитує вранці в понеділок і вирішує, що це добре робити реконструктивну операцію в багажнику, тому що ніхто інший не працює над цією частиною. Боб приїжджає через годину, повернувшись зі своєї відпустки і сповнений енергії, і вирішує, що збирається реалізувати нову головну особливість саме в цій самій області, і навіщо турбуватися з гілкою, оскільки ніхто ніколи не торкається цього коду? Тож Аліса розплачується тим "технічним боргом", Боб реалізує свою вбивчу функцію, яка працює на задніх пальниках 6 місяців, і коли вони нарешті перевіряють свій код (звичайно перед тим, як закрити час у п’ятницю, звичайно!), Весь Команда повинна залишитися позаду і спробувати пережити кошмарне пекло конфліктів, які продовжують жити як помилки та регресії протягом наступних двох тижнів.

Аліса та Боб обидва чудово справились із завданнями кодування, але вони обоє почали з поганого рішення ("що найгіршого, що може статися?"). Керівник команди або керівник проекту переносить їх через смерть і забиває контрольний список, щоб запобігти цьому повторення:

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

Б'юсь об заклад, що багатьом із нас цей "процес" просто здається здоровим глуздом. Це стара шапка. Але чи знали ви, що багато менших команд цього не роблять? Команда з двома людьми може взагалі не заважати контролю над джерелами. Кого хвилює? Це, чесно кажучи, не потрібно. Проблеми починають виникати лише тоді, коли команда зростає, але процес цього не відбувається.

Звичайно, оптимізація процесів схожа на оптимізацію продуктивності; випливає зворотна експоненціальна крива. Контрольний список, наведений вище, може усунути 80% дефектів, але після його втілення ви виявите, що на якісь інші речі припадає решта 80% дефектів. У нашому вигаданому, але знайомому прикладі це можуть бути помилки збирання через наявність різних середовищ збирання, що, в свою чергу, пояснюється тим, що немає стандартного обладнання та розробники використовують бібліотеки з відкритим кодом, які оновлюються кожні 2 тижні.

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

Цикл продовжується і продовжується. Кожна «політика», яку ви бачите, як правило, була створена для вирішення реальної проблеми. Як Йоел Спольський писав ще в 2000 році (на зовсім іншу тему ви пам’ятаєте, але все-таки актуальною):

Коли ви заходите в ресторан і бачите табличку, на якій написано "Не дозволено собак", ви можете подумати, що цей знак є суто привабливим: містер Ресторан не любить собак навколо, тому, коли він побудував ресторан, він поставив цей знак.

Якби це було все, що відбувалося, також був би знак "Без змій"; зрештою, змій ніхто не любить. І знак "Без слонів", бо вони розбивають стільці, коли сідають.

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

Це так само в більшості (я не скажу всіх) програмних команд: Політика на зразок "Вам потрібно додати тестовий випадок для кожного виправлення помилок" майже незмінно вказує на те, що в команди історично виникли проблеми з регресіями. Регресії - ще одна з тих проблем, які найчастіше зумовлені розривом спілкування, а не некомпетентністю. Поки ви розумієте політику, ви, можливо, зможете скористатися законними ярликами (наприклад, мені довелося виправити 6 невеликих помилок, але всі вони були в одній і тій же функції, тому я можу фактично просто написати один тестовий випадок для всіх 9 з них).

Це пояснює, чому процеси відбуваються, але це не вся історія. Інша половина:

Чому процес так важко слідкувати?

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

Наприклад, в оригінальному запитанні я бачу кілька проблем:

• Система контролю ревізії (CVS) застаріла за сьогоднішніми стандартами. Для нових проектів його майже повністю витіснив підрив (SVN), який сам по собі швидко затьмарюється розподіленими системами, такими як Mercurial (Hg). Перехід на Hg зробить розгалуження та злиття набагато простішим, і навіть у моєму гіпотетичному прикладі вище, щоденна потреба у виконанні стане набагато менш болісною. Код навіть не потрібно компілювати, оскільки сховище локальне; - насправді розробники лазерів могли навіть автоматизувати цей крок, якщо хотіли, встановивши сценарій виходу з системи, щоб автоматично здійснювати зміни до локального сховища.

• Не витрачалося часу на автоматизацію процесу на віртуальній машині. Весь процес отримання, налаштування та завантаження джерела / бібліотек на віртуальну машину може бути 100% автоматизованим. Це може бути процес без нагляду, який ви десь запускаєте на центральному сервері, коли ви працюєте над виправленням помилок на вашій локальній машині (і використовуєте VM лише для забезпечення чистої збірки).

• З іншого боку, у певному масштабі рішення VM на розробника починає ставати дурним, і вам просто слід мати сервер постійної інтеграції. Ось тут і реальні переваги продуктивності, оскільки це (здебільшого) звільняє окремих розробників від того, щоб взагалі турбуватися про нарощування. Не потрібно турбуватися про налаштування чистих віртуальних машин, оскільки сервер збирання завжди чистий.

• Формулювання запитання ("тестовий випадок з усіма кроками") означає, що триває певне ручне тестування. Це, знову ж таки, може працювати для невеликих команд з відносно низьким навантаженням, але в більшому масштабі взагалі не має сенсу. Регресійні тести можуть і повинні бути автоматизовані; немає "кроків", просто клас або метод, доданий до набору тестів / інтеграції.

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

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

Якщо розробники витратили тиждень на відстеження свого часу на всі завдання, що не кодують, то ви могли б легко додати його, показати керівництву, що (наприклад) нульовий капітал, 100-годинна інвестиція в оновлення до Mercurial буде усуньте до 10 людино-годин на вирішення конфліктів злиття, тоді це виплата за 10 тижнів, і вони майже напевно погодиться на це. Ця ж ідея з серверами збірки (CI) або кращим відстеженням помилок.

Резюме: Команди ще цього не робили, тому що ніхто не переконав керівництво, що це важливо зробити сьогодні . Тож візьміть на себе ініціативу та перетворіть її на рівняння витрат та вигод; з'ясувати, скільки часу витрачається на завдання, які можна було б спростити / автоматизувати з мінімальним ризиком, та обчислити точку беззбитковості та можливу окупність нового інструменту чи техніки. Якщо вони все ще не слухають, то ви вже знаєте, які є ваші інші варіанти.

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

Зверху детальніше виглядає подальше розширення.

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

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

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

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

Так це може бути необхідне зло.

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

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

Але будьте готові захистити свій аргумент, щоб виправдати зміну.

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

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

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

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

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

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

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

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

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

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

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

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

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

Чи є момент, коли процес стає на шляху і стає самоціллю? Це навіть інженерія?

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

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

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

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

Більшість ваших скарг, по суті, виглядає так: "Я не хочу тестувати до, під час або після розробки!" Давайте розбимо ваші кроки, по пункту.

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

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

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

Цікаво. У вас є тестери? Вони повинні робити щось із цього. Я один, і там, де я працюю, ми маємо гідне рішення.

Щодо функціонального дефекту, як ви пояснюєте, наш процес йде так:

1. Я перевіряю на наявність дефекту в машині управління (або повідомив клієнт, або під час мого дослідного тестування, або ж / е)
2. Знайдено / відхилено помилку.
3. Я створюю помилку. Помилки включають:
   • Повна відповідь, від точки встановлення до точки побачення помилки.
   • Посилання на знімок VM (якщо я думаю, що розробнику це знадобиться ... Я знімаю його все одно, на всякий випадок, коли вони цього вимагають).
   • Інформація про систему, будь-які спеціальні настройки, які мені потрібно було зробити.
4. Цей помилка присвоюється розробнику. Поки вони працюють над виправленням:
   • Створіть тестовий випадок
   • Напишіть (або перетворіть) ручний тест в автоматизований тест

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

1. Запустіть автоматизований тестовий випадок та ручну версію (іноді) для підтвердження виправлення.
2. Закрийте помилку.

TL; DR: Якщо у вас немає тестерів, вам знадобляться. Якщо у вас є деякі, вони не 'виконують свою роль'.

Том ДеМарко:

... Моя книга ранньої метрики ... Найбільш цитованим рядком є ​​її перше речення: "Ви не можете контролювати те, що не можете виміряти". Цей рядок містить справжню істину, але мені стає все незручніше з його використанням. У цитаті (і справді в назві книги) чітко зазначається, що контроль є важливим аспектом, можливо, найважливішим у будь-якому проекті програм. Але це не так.

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

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

Інженерія програмного забезпечення: ідея, чий час прийшов і пішов?

"Тоді я створюю гілку для цього єдиного виправлення помилки".

Немає необхідності робити гілку для єдиного виправлення помилки. Спочатку створіть помилку в bugzilla. Ознайомтеся з відділенням випуску. Зробіть виправлення. Виконайте фіксування з повідомленням про фіксацію, що містить номер помилки, який оновлює помилку та позначає її "виправлено, потребує тестування" або "виправлено, перевірено, потребує злиття" відповідним чином, залежно від текстових ключових слів, написаних у повідомленні про фіксацію. База даних про помилки - це ідеальний механізм відстеження всіх внесених змін і чому вони були внесені; звіти можуть бути запущені з бази даних про помилки, щоб отримати цю інформацію.

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

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

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

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

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

CVS або будь-яка система управління конфігурацією непогана. На жаль, спосіб його використання, не знаючи дійсно його мети, заподіює цю своєрідну біль у справі! @ # $ Для всієї організації.

Щоб швидко зрозуміти, що насправді робить Agile, перегляньте книгу "Практики спритного розробника" Венката Субраманіама. Її чудово написано легко зрозумілою мовою.

Бажаю тобі удачі!