Сподіваюсь ви маєте рацію :)
В принципе вы описали стандартный процесс гавношлепства так знакомый каждому гребцу на галере. И каким боком тут вообще гибкая разработка ПО? И без Жиры конечно никуда.
В принципі, я описав стандартний процес розробки :)
Это как не интересоваться планированием и ходом постройки собственного дома бригадой строителей и требовать как можно быстрей выполнить все работы. Очень дальновидно. Хотя если дом не для себя строите, а как подрядчик, то и хер с ним.
Під «деталями технічної частини» малося на увазі покриття тестами/дотримання стандартів програмування/технічний борг і т.д. зазвичай бізнес цим не цікавиться так само як і ви не стоїте над будівельною бригадою і не перевіряєте співвідношення піску до цементу :)
Это описание классического гавнокодера, а не программиста. А где же этика и профессионализм? Или в вашей компании практикуют пытки? Так это запрещено конвенцией ООН. Чесслово, не инженеры пошли, а кикие-то мамкины кодошлеперы. Постоянный и беспощадный рефакторинг на проекте залог его успеха.
Приведу приклад. Зазвичай розробка нової фічі у мене починається з протипування і якщо фіча горить бо ПМи провели дослідження і їм от навчора це треба, а прототип виглядає повністю робочим або це тестова фіча яка невідомо чи взлетить і потрібно розробити прототип для того ж дослідження то часу не так багато на роздуми про етику і професіоналізм бо як ви влучно підмітили для бізнесу потрібно робочий софт... Скажу так, на рівні прототипу там не завжди пахне етикою і професіоналізмом :)
Да не нужно его оптимизировать. Для бизнеса нужен работающий софт, производящий профит.
До речі, мені приходилось проєктувати з нуля декілька таких працюючих проєктів так як технічний борг був настільки великим, що рефактор зайняв би 70% роботи. Клієнти самі приходили і казали «ось є старий ми хочемо з нуля новий».
Як чоловік який деякий час проживший в Дніпрі, можу сказати, що він створений для того щоб спитись і повіситись.
Львів порівняно з ним Сан Франциско.
:D
Про 100500 джерел не знаю, перевіряв маршрути по яким сам ходив джерел взагалі немає.
Зазвичай в таких аппках для мене більш цінні ПОІ, лінії висот, а також не маркован стежки. Для цього я зазвичай використовую mtbmap.cz , він на базі openstreetmaps. Крутіших мап для карпат я поки не знайшов. До речі, в мене нормально так підвисає аппка.
футбольна команда з дітей складалась. Але це було в горах. Єдина ще історія про дітей які потрапили в надзвичайну ситуацію в
Питання виживання якраз стояло. Ви випускаєте їх з вигляду. Коли вони летіли ніхто ще не знав, що вони розіб’ються, і ніхто не знав як буде далі. Що і нормально. Після катастрофи першим ділом мабуть в них стояло питання фрутів яке дуже швидко вирішилось тому, що їх було вдосталь. Я не бачу просто протиріч. В проектному менеджменті також приймаються тактичні рішення, це яскраво видно коли вилазять баги на проді і ніхто тоді не думає про стратегію, і це правильно, і краще зробити як небудь фікс аби робило ніж філософствувати про стратегії. Але в проектному менеджменті ситуації з багами більше винятки ніж звичайний режим роботи. Я веду до того що, в принципі, людям властиво гіперболізувати або недооцінювати проблеми тим чи іншим методом і питання та там же одну функцію написати нафіга нам городити тут якусь нормальну архітектуру це обумвлено тим що люди недооцінюють задач через що в майбутньому вилазять проблеми хоча ніяких надзвичайних ситуацій немає і можна спокійно сісти і подумати над вирішенням задачі.
Це він мабуть про катастрофу в Андах
І отут я зрозумів, що ПМ прийняв тактичне рішення тобто ситуативне,
Та, можливо я не до кінця правильно висловлююсь. Я якраз про такі ситуативні рішення які в майбутньому вилазять боком.
І після цього всього
ПМ: фіг тобі, а не підняття зарплати — ти баги плодиш!
Через рік я буду думати точнісінько так як і зараз. Ви мабуть не до кінця зрозуміли допис. Я якраз закликаю розробляти проекти за допомогою поширених шаблонів з використанням найкращого досвіду тому, що нехтування ними може призвести до тимчасового прискорення процесу, але до великих проблем в подальшому.
Ну ви не путайте орган з пальцем, виживання і робота над проектом це дві кардинально разні ситуації в яких я бував. При надзвичайних ситуаціях в преш чергу мають прийматись тактичні рішення, але від цього забувати про стратегічні це вірна смерть. Навіть в цьому романі дітей спасли тому, що бочали дим від вогню. При розробці проектів ситуація зовсім інша. Всьому має бути своє місце і у всьому має бути баланс.
Я просто тут це залишу))
scontent.flwo3-1.fna.fbcdn.net/...34e47aa7e98d2&oe=5EEE0523
А ваша історія реальна. Якось був в такій ситуації
Надмірне захоплення, будь чим може вбити проект. Навіть захоплення пошуком стратегічних рішень) Тому все має бути вміру)
Просто є каста недоторканих) на яких все тримається) Все як і у всіх)
Просто привід щоб звільнити))) Не зійшлися поглядами з лідом)))
В тому випадку ми завжди нили що то стара архітектура і вона г*вно. Тому і конало)
так і було тому всі і зрозумінням поставились і просто поржали)))
Но при этом вера в то, что дев действительно сделает «нормально» остается только верой.
Нижче якраз писали про довіру ПМа до девів. Вона повинна бути бо без неї команда вже не команда.
гда на новую фичу другой дев скажет, что предыдущая архитектора отстой
Обовязково скаже! Тоді б не потрібно було такого поняття як рефакторінг. Саме головне що він зможе тільки сидіти і нити, що стара архітектура відстій привносячи ще більше багів.
Перед публікацією статті редактори ДОУ її вичитують і розставляють коми в потрібних місцях ;)