Комментарии 389
У качества и скорости есть свои весовые коэффициенты — вот вам первый артефакт вашей матмодели
Кстати, что это за зверь — матмодель ПО?
«Делать как надо» — кому надо? кто сказал, что так надо?
Понятно, что в чем-то по сути вы правы, но вы безапелляционно вводите это в абсолют.
Всё здесь написанное нужно читать на контрасте с т.н. аджайл-манифестом, на который дана ссылка в предисловии.
Можно назвать манифестом оборзевшего разработчика ))
(признаю, что иногда использую подобные принципы, чтобы приструнить наглеющих заказчиков)
вы безапелляционно вводите это в абсолют
И вы. Но кто же прав?
Я ничего не ввожу. Использую то, что удобней и правильней, при этом оценка «правильности» и мера использования проходит по множеству факторов, а не просто безапелляционно «Качество важнее скорости»
Откройте уже первую ссылку из этой публикации, и читайте обе страницы параллельно.
Высказать в комментах мнение, что оно абсолютно не приложимо к реальной жизни — мое право.
Эджайл-манифест имеет право на жизнь. Ваш — нет.
¯\_(ツ)_/¯
Это вы точно мне хотели ответить? Если да, то я не понял.
Первая строка — цитата моего оппонента, если что.
но вы безапелляционно вводите это в абсолют
Что «это» и где именно вы увидели возведение «этого» в абсолют?
Я вот ничего подобного не заметил. Все описано ровно также как и в аджайл манифесте и его концепциях.
И точно так же, как в аджайле, есть здравое зерно, но не все сходится с реальностью…
Попробуйте сунуться с этими принципами к следующему вашему заказчику/работодателю.
Попробуйте просто их применить для своего личного проекта.
Не будет этого, кроме как на простых школьных работах.
Никогда не сможет разработчик все просчитать на стадии дизайна, даже если требования не будут изменяться. Всё равно нужна подвижность и динамика.
Я вот нигде не увидел фраз «все просчитать на стадии дизайна».
Черным по белому написано, что при изменении тербований просто запускается полный цикл продумывания изменений.
И именно так я всегда старался и делать.
Вы серьезно этого ждете? Вот прямо серьезно серьезно?
Можете продолжать балаболить.
Манифест, это не жесткие правила. Не догмы.
Это идеи которыми люди руководствуются при работе над проектами.
В аджайле есть несколько разных фреймворков, типа скрама и канбана, которые не одно и то же, но тем не менее руководствуются манифестом.
Так и этот манифест в разных ситуациях может выливаться в разные действия.
Если ты этого не понимаешь, то земля тебе пухом)
это выглядит как шутка, которая затянуласьНу почему же. Agile для меня это просто одна из форм организации процесса разработки. Ваш манифест легко вписывается, по крайней мере именно так я и работаю.
Концепция важнее новых требованийСообственно почему я и присутствую на backlog refinement. У меня спрашивают story points и я чесно говорю, если задача не вписывается, что придется менять для реализации и насколько это сложно. Часто задача сразу же упрощается под существующую архитектуру, откладывается (создается spike — чтобы уточнить сложность) или от задачи вообще отказываются.
Качество важнее скоростиМаленькая предистория. Работал с одним программистом без agile, он делал все быстро и меня не спрашивал. В результате получилось разделение отвественностей: только он знал свой код. Потом он ушел… и грянул гром… там было все плохо… Теперь мы используем agile и code review, любой программист может поддерживать любую часть проекта (нет «черных ящиков» — инкапсулированного кода, не понятного для всех). На этапе ревью код балансируется, чтобы уменьшить технический долг (меньше извините гавнокода). Вроде бы работает, требует больше времени на разработку, зато жизнь после релиза проще.
Делать как надо важнее, чем делать как просятМоя фирма нанимала программиста, а не обезьянку, которая умеет печатать. Я не дурак (вроде) и могу думать, в том числе решать проблемы. Любая из назначенных задач — это полностью мой выбор как решать. Впрочем есть другой нюанс — у меня свое «узкое» видение решений, которое может быть не совсем оптимальным для конечного пользователя. Тут нужен балланс, «как важнее» — это весьма субьективная трактовка.
Теперь мы используем agile и code review, любой программист может поддерживать любую часть проекта...
Аджайл с этим никак не связан. Почти любой программист может поддерживать почти любую часть проекта тогда, когда соблюдается техпроцесс. То есть: обзор кода, тестирование и документирование.
жизнь после релиза проще
Истинно так.
требует больше времени на разработку
А вот это только на ранних этапах. Когда всё встаёт на рельсы, всё только быстрее.
как важнее
Либо я неправильно понял, либо вы неправильно прочитали. У меня не "как важнее", а "как надо".
Почти любой программист может поддерживать почти любую часть проекта тогда, когда соблюдается техпроцессТут вы прям в точку попали. Документация практически отсутствовала. Тесты — больная тема до сих пор… Я просто хотел сказать, что введение одного лишь code review в процесс разработки существенно улучшило ситуацию с «качеством» кода, хотя и уменьшило скорость.
У меня не «как важнее», а «как надо»Моя опечатка, врочем смысл не особо меняется. Что значит как надо? Как красивее впишется в архитектуру? Это скорее «как проще» для вас. А пользователю программы это может быть не удобно. И нужно искать балланс, такое решение, которое и впишется в архитектуру, и не будет неудобной кнопкой где-нибудь далеко, до которой еще и добираться через несколько кликов (был случай).
Code review это никак не часть agile
Скрум в принципе пропагандирует «быструю» разработку, но пока что не было большой проблемы иногда потратить больше времени на какую-то задачу, чем планировалось. Опять же, нужен баланс, нельзя тупо рвать вперед. Да, в текущем спринте ты будешь молодец, и даже пройдешь ревью, умалчивая о нюансах и, как следствие, о техническом долге. А потом кто-то будет расхлебывать кашу, воюя с твоей нерешенной проблемой.
С другой стороны никто не будет ждать, пока ты пишешь свой «идеальный» код. Потому нужно искать компромис, но все же с упором на качество, не по максимуму, но хотя бы,
чтобы твоя совесть сказала «теперь хорошо, расслабься».
Все основные методологии повышения качества кода, были придуманы задолго до scrum-а и прочего. В том числе и методология коротких итераций в разработке.
Отсюда я делаю вывод, что scrum/agile больше всего преследуют коммерческие интересы конкретной группы лиц в проекте.
И заметьте, я нигде не говорю, что это плохо. Я вообще не сторонник «черно-белой парадигмы». Но то, что эта группа лиц частенько использует эти возможности в целях «замыливания» или скрытия истинного положения дел в проекте — это факт. Отсюда возникают такие публикации как эта.
Неудачно сделанная работа по продажам или планированию не должна
и тут навстречу программисту идут со своим манифестом жесткие маркетолог и продажник.
И у них написано в манифесте:
«1. Только продажник может определить удачно или нет сделана работа по продажам.
2. Если кому-то кажется что неудачно — смотри п.1.
3. Продажи превыше всего, в жопу философствующих программистов — их дело — быдлокодить в срок и недорого.»
И тут ломается функционал прода. Тот же топ требует хотфикс, тестеры говорят — у нас регресс займёт 8 часов, мы не успеваем! Им отвечают — фиг с ним, у нас баг на проде, релизим! И релиз хотфикса ломает уже другой функционал, но гораздо больше и критичнее.
После этого начинается свара программистов и тестеров, тимлид рвёт седеющие волосы, всем весело.
У программистов виноваты тестеры — сидят, нифига не делают, у тестеров один ответ — а мы предупреждали.
В сухом итоге виноват PM :)
И тут ломается функционал прода. Тот же топ требует хотфикс, …
… и идёт лесом. Вместо хотфикса делается откат на предыдущую стабильную версию, и работа возвращается в штатное русло. В ответ на любые претензии ответ один: всю ответственность на себя взял вот тот топ, разговаривайте с ним. Претензии от этого топа не принимаются — мы предупредили что "не готово"? Ты не поверил и захотел убедиться? Ты убедился.
Хуже, если подход к разработке не подразумевает возможности быстро откатиться на предыдущую версию. В этом случае алгоритм должен быть такой: прод остаётся поломанным пока хотфикс не будет готов по штатному процессу, с 8-ю часами на регрессию, документирование, и всё остальное, что обычно делается. Если топа это не устраивает — он может снова взять на себя всю ответственность, и мы поломаем прод ещё раз. Дальше алгоритм возвращается в начало.
Если компания, в целом, адекватная — после этого случая мы данного топа больше никогда рядом с разработчиками не увидим. Если нет — уволят всю команду (и это хорошо, чем раньше уволишься из неадекватной компании — тем лучше). :)
Наличие CI/CD ещё не даёт гарантию возможности отката. Чтобы проект можно было спокойно откатывать нужно ещё как минимум реализовать (и тестировать!) автоматизированные миграции БД не только "вперёд", но и "назад".
Бэкап обязателен в любом случае — некоторые миграции деструктивны (напр. удаление колонки из SQL-таблицы) и единственный способ их откатить это восстановить бэкап.
Что касается новых данных — не так часто выполняются деструктивные миграции, так что в большинстве случаев новые данные не проблема, а в оставшихся случаях лучше иметь возможность откатиться с потерей последних данных чем не иметь такой возможности в принципе.
Всё верно, но на практике это означает постоянную поддержку в текущей версии приложения двух версий схемы БД. Это банально дорого для большинства проектов.
Разумеется, здесь каждый будет решать по себе, серебряных пуль не завезли.
Хотя вцелом не понравилось. Манифест это же про декларацию конкретных ценностей. Тут скорее какие-то мечты относительно того как достигать ценностей, причем безотносительно каких именно, что уже вцелом провал. «делать как надо» это не ценность (кому надо и что надо?). «качество» это сомнительная ценность, тут отсекаются все сколько-нибудь образованные менеджеры, которые знают про треугольник качество-время-бюджет. И что собраются делать со своим манифестом «жесткие программисты» при отсутствии образованых менеджеров? «концепция» вообще не может быть ценностью для программиста, программа может быть написана только по конкретным требованиям (о чем кстати потом и пишется, но логический переход к ценности некой «концепции» опущен, хотя весьма неочевиден).
Автору хорошо бы почитать хотя бы краткие методички о менеджменте, бизнесе (что-нибудь из бережливого производства для понимания природы изменчивости), инженерии (требования, архитектура, валидация для понимания как сейчас учитывается изменчивость) а потом переработать манифест в соответствии с последними достижениями. Мир уже давно страдает от описанных проблем, но простых решений нет, поэтому и безобразия много — делать «хорошо» нужно учиться.
Аджайл-манифест читали? Какие конкретные ценности там декларируются?
… писали они его для программистов...
Неважно, что ты делал, важно, что ты сделал. Они могли хотеть писать его для программистов, но, увы, написали не для них.
А я утверждаю, что это вы не до конца прочувствовали суть происходящего. Один из нас точно неправ.
Вы вот про это я так понимаю:
1. Люди и взаимодействие важнее процессов и инструментов
2. Работающий продукт важнее исчерпывающей документации
3. Сотрудничество с заказчиком важнее согласования условий контракта
4. Готовность к изменениям важнее следования первоначальному плану
Да, это гораздо более конкретно, люди попытались вычленить то, что по их мнению приносит пользу конечному заказчику и минимизирует работу производственной системы.
Успех этого манифеста заключается в том, что он весьма неплохо мапится на конкретные объекты и процессы реального мира, например многим знакомо, что после фиксации требований и начала работы, заказчика могут послать лесом и в результате выкатить продукт который ему уже не нужен, а оплачивать надо. Присутствуют нужные объекты, субъекты, контекст некоторой бизнес ситуации.
А в случае автора про «качество важнее скорости», кто объект, кто субъект, какая бизнес ситуация, на каком этапе и почему качество вдруг становится важнее скорости, даже на бытовом уровне мы далеко не всегда выбираем качество предпочитая цену. Нужен контекст и более конкретная формулировка боли.
Модель разработки «it’s done when it’s done» подходит крайне ограниченному набору ПО в исключительно редкой ситуации наличия у компании «неограниченных» ресурсов. Во всех остальных случаях определяющую роль играет время вывода на рынок новой функциональности с приемлемым качеством.
Agile-подход как совокупность практик позволяет добиться баланса между скоростью вывода на рынок, качеством продукта и качеством исходного кода. Ваш же манифест вряд ли приведёт к чему-то отличному от «задрачивания на код».
… вы ни-че-го не понимаете во взаимосвязи процесса разработки ПО с другими процессами внутри компании, а также со внешними факторами, влияющими на неё.
Я думаю иначе.
Agile-подход как совокупность практик позволяет добиться баланса между скоростью вывода на рынок, качеством продукта и качеством исходного кода.
Аджайл-подход превозносит интересы одного круга лиц над интересами другого круга лиц.
Не перехожу на личности, но между строк читается незрелость вас как инженера.
Незрелость проявляется в том, что я призываю отстаивать свои интересы?
Незрелость проявляется в том, что я призываю отстаивать свои интересы?Незрелость проявляется в том, что вы используете придуманные вами термины — «матмодель ПО».
Отсюда сразу же следует, что вы не знаете, что такое математическая модель, и каким образом происходит создание архитектуры программной системы. И фантазируете на ходу, приставляя одно умное слово к другому.
Это неуважение к тем людям, которые знают эти термины.
Ваш «манифест» — однобокий взгляд, не демонстрирующий понимания, в отличие от авторов agile, которые искали практики, учитывающие интересы и потребности обеих сторон.
// никогда не думал, что буду защищать agile от нападок программиста
А что касается незрелости — я уже написал. Вы — максималист, это даже между строк читать не нужно.
Ничего личного. Просто надо побольше профессионального опыта приобрести, и побывать за пределами уютной IDE-шки.
определяющую роль играет время вывода на рынок новой функциональности с приемлемым качеством
совершенно не оправданна. Множество раз я наблюдал, как т.н. «бизнес» давит «нужно скорее, быстрее, давайте-давайте, очень все ждут», по итогу выкатывается решение с тем самым «приемлемым качеством», которое по факту обозначает огрехи в проектировании, костыли, говнокод и все прочие падучие, а в ретроспективе оказывается, что этот функционал ждали годами, и никто не умер. И если бы прождали еще месяц, то тоже никто бы не умер. И это был тот самый месяц, которого не хватило что бы выкатить нормальное решение, которое позволит себя расширять и менять. А все пляски с саблями обусловлены единственно тем, что кто-то — мы знаем кто! — пообещал, назвал сроки, завысил ожидания и возбудил аппетит. И как раз аджайл такой подход провоцирует. Поэтому все же иногда бывает разумно упереться рогом, и заявлять, что готово будет тогда, когда будет готово. Естественно этого никто не потерпит, и придется идти на компромисс, но этот компромисс будет уже более компромиссным, чем если бы рогом не упираться, а только кивать головой. В общем иногда баланс можно достичь только будучи не гибким и упертым бараном.
НО ЭТО НЕ отменяет важность time to market. Да, очень много продуктов имеет красивую обертку, но ужасное подкапотное пространство. Но это реальность большинства проектов. Продукт нужно запускать быстрее, а после запуска и в случае успеха уже от СТО зависит, какое качество будет у кода.
Продукт нужно запускать быстрее...
Кому нужно? Почему? Чем это обосновано, кроме "рынка"?
Кому нужно? Почему? Чем это обосновано, кроме «рынка»?
Это нужно бизнесу, потому что ROI и window of opportunity. Это обосновывается исключительно потребностями рынка, потому что, сюрприз, продукты выпускаются с целью зарабатывания денег, и должны решать проблемы рынка.
ROI и window of opportunity
Я вас не понимаю. Пожалуйста, вернитесь к нам, простым русским ванькам.
P.S. Я не Владимир. Не понимаю, откуда это взялось.
Ваня, оба термина без проблем гуглятся, не стесняйтесь пользоваться поисковиками: Окупаемость инвестиций, Window of opportunity.
P.S. Я знаю, как Вас зовут (на гитхабе посмотрел), просто не удержался от стёба в ответ на "простым русским ванькам", простите. :)
Дело не в том, что я могу или не могу что-либо наяндексить, и не в том, что я что-то знаю или не знаю.
Дело в том, что, когда собеседник внезапно начинает сыпать аббревиатурами и иностранными словами, можно смело начинать "ставить диагноз".
— почему эти два термина являются ответом на вопрос, кем, почему и чем обоснована необходимость выпуска достаточно качественных продуктов в определенный срок и бюджет
— зачем нужна методология, которая решает эти проблемы
то вести конструктивный разговор с вами невозможно.
Спокойнее. Просто вы привыкли, что вам все верят на слово. Но так вышло, что сегодня это не работает.
Ролевая игра.
Я — программист.
Вы — наниматель.
Пожалуйста, смотивируйте меня броситься соблюдать сроки, если я знаю, что мне требуется на проект три месяца, а "рынок требует" выпустить его через два.
Извините, что вмешиваюсь в ваши ролевые игры, но это не сложно:
- Дмитрий, если Вы пришли в нашу компанию для того, чтобы получать два месяца зарплату за бесполезную деятельность по написанию кода, который никогда не будет запущен — пожалуйста, напишите заявление по собственному прямо сейчас, и успехов Вам найти работу в компании, которой надо то же самое, что и Вам.
- Если Вы хотите сделать что-то полезное, то учитывайте, что вне зависимости от качества и функционала продукта он окажется бесполезен, если мы не выпустим его на рынок через два месяца.
- Если Вы уверены, что запланированный функционал с необходимым качеством невозможно выпустить через два месяца — давайте вместе согласуем альтернативу, урезанную по функционалу и/или качеству, которую реально выпустить через два месяца, и которая будет всё ещё достаточно полезной, чтобы у нас был реальный шанс получить достаточно средств для продолжения разработки этого продукта.
- Если Вы не видите возможных альтернатив, и считаете поставленную задачу невыполнимой — пишите заявление по собственному, наша компания либо закроется на два месяца раньше (если никаких вариантов вовремя сделать продукт действительно нет), либо мы наймём другого разработчика, который такие варианты сможет найти.
Это всё сразу, или это варианты?
Вообще, на этом месте игру нужно уже заканчивать, потому что сразу же пошло именно то, ради борьбы с чем мы тут собрались: хамское давление с нарушением ТК.
Следующее действие — звонок в трудовую инспекцию.
Номер статьи? И не сомневайтесь, суд будет выигран, и будет выплачена зарплата за всё время "простоя", а также за нанесение морального вреда. Изучите статистику на этот счёт.
Наконец-то, ну наконец-то вы проявили свою истинную сущность. Менеджерский произвол, о котором тут и идёт речь. Спасибо за наглядную иллюстрацию, Антон.
Вы в общем тоже проявили вполне свою сущность. Вы не заинтересованы работать. Все что вас интересует, это паразитирование на ТК и имитация бурной деятельности за счет работодателя. Это кстати зафиксировано в первом принципе вашего манифеста.
Вам предложили целую кучу вариантов, но вы сразу начали шантаж трудовой инспекцией. Т.е. вас не устроил не один из вариантов. Вы априори считаете что вы всегда правы, а работодатель это такой детский садик, где должны платить деньги просто за то что у вас корочка «программист». О чем можно с вами договариваться?
Это пошаговый алгоритм ведения диалога — по сути, да, варианты. Если эти варианты Вас не устраивают — не вопрос, предлагайте свои, у меня, как у нанимателя, нет цели ограничить Вас этими конкретными вариантами, моя цель выпустить продукт на рынок через два месяца чтобы заработать денег на продолжение разработки продукта, и любые варианты, ведущие к этой цели, я готов рассмотреть.
А в чём именно нарушение ТК, просто любопытно? Если Вы не можете выполнить ту работу, за которую я готов платить — значит либо это невозможная работа, либо просто для этой работы нужен другой исполнитель. В любом случае, если другой работы конкретно для Вас у меня нет, то Вы — уволены. Или ТК запрещает мне Вас увольнять? Я-ж не говорю "чтоб завтра ноги твоей не было в офисе, и зарплату за предыдущий месяц мы тоже не выплатим" — уволим по ТК, две недели или какие там в России правила, суть ведь вовсе не в этом.
Что до хамского давления — простите??? Где Вы усмотрели хамство? Мне нужно выполнить конкретную работу, я ищу под эту работу исполнителя, готов согласовывать с исполнителем разные варианты как её можно сделать… Если исполнитель не в состоянии сделать эту работу мы просто отказываемся от его услуг и ищем другого исполнителя, либо отказываемся от идеи реализовать именно этот продукт. Что тут можно было найти хамского…
Игра окончена, Алексей. Я "попал" в какую-то быдлоконтору.
Разумеется, хамство — это просить уволиться по собственному. Разумеется, ТК запрещает увольнять сотрудника, обладающего подходящей квалификацией. Единственное, что можно предложить — это увольнение по соглашению сторон с выплатой выходного пособия за три месяца.
Единственно верным был вариант №3, но почему-то он не был главным и единственным. А главным оказался шантаж. Вот, собственно, и иллюстрация к основной теме нашего разговора.
Александр. :)
Я же не настоящий сварщикнаниматель, я не знаю как нужно увольнять по вашему ТК, но, уверяю, увольнение с нарушением закона мной не подразумевалось. Я вообще не уверен, что меня увольняли хоть раз в жизни, вроде бы нет, так что у меня мало опыта в том, как это правильно оформляется.
Вариант №3 не был единственным просто потому, что жизнь штука сложная, и вариантов всегда больше одного. И нет, если Вам показалось, что какие-то из этих вариантов главнее других — то Вам просто показалось.
Шантажа среди вариантов не было вообще, есть работа, и либо Вы можете её сделать, либо нет — у меня нет цели как-то Вас шантажировать, уговаривать или упрашивать, моя цель — получить продукт через 2 месяца, и это единственное, что меня волнует в этот момент. Выберете третий вариант — супер, мне он тоже подходит больше других, потому что остальные подразумевают срочный поиск другого исполнителя, а время поджимает. Выберете не третий — Ваше право, я не могу принуждать Вас делать работу, которой Вы не считаете для себя возможным заниматься, у нас ведь не рабство.
Между прочим, я лично не раз отказывался от работы по четвёртому варианту, и никогда это не было проблемой ни для меня, ни для нанимателя. Просто в моём случае речь идёт о фрилансе, так что формально это не было увольнением, я просто отказывался браться за работу, которой не считал для себя возможным заниматься (и да, это нередко было связано с тем, что заказчику был нужен говнокод, и я даже нередко с ним соглашался, что да, здесь и сейчас ему нужен именно говнокод, просто я не собирался участвовать в его написании — но были и другие варианты, например утилиты для рассылки спама я тоже отказывался писать, из моральных соображений — хотя чисто в техническом плане задача интересная). Более того, мой отказ ещё ни разу не послужил помехой продолжить сотрудничество с теми же заказчиками, как только у них появлялась для меня работа, которой я был готов заниматься.
Ладно, ночь уже, пора заканчивать это развлечение. Я так понимаю, Вы эту ролевую игру слили (придирки к форме оформления увольнения не могут являться осмысленным ответом, или Вам есть что ответить по сути вопроса)?
Вы как-то упускаете из виду, что в данный момент компании нужен не "разработчик PHP", а "разработчик который может реализовать этот проект за два месяца". Если текущий это сделать не в состоянии — значит его квалификация не соответствует требованиям этой позиции. Опять же, я без понятия как это нужно оформлять юридически, но, очевидно, если компании нужен сеньор, то у неё есть возможность не допустить мидла на эту позицию. Равно как и если ей нужен рок-стар вместо обычного сеньора, то компания сможет убрать из штата позицию "старший разработчик" и заменить её позицией "ведущий разработчик" или ещё как-то, чтобы иметь легальные основания доказать, что текущий разработчик ей действительно сейчас не подходит.
Я — программист.
Вы — наниматель.
Вы эту ролевую игру слилиСогласен, позиция izvolov в предложенной им же игре слабее чем у Вас… но, просто он выбрал заранее проигрышный вариант игры, где его же 3й постулат манифеста «Делать как надо важнее, чем делать как просят» — заведомо не выполняется, т.к. наниматель волен ставить перед подчиненным любые задачи и требовать их выполнение в любые сроки, подчиненному остается либо согласиться и пахать в 3 смены, либо уволиться.
Правильная ролевая игра выглядит так:
Я — программист.
Вы — менеджер.
Т.е. тут нет иерархии отношения начальник -> подчиненный, здесь обе стороны равноправны и должны договариваться чтобы согласовать проект.
И тогда нам открывается скрытый пятый вариант:
5. Если Вы как менеджер ставите заведомо не выполнимую задачу (разработать продукт Х за время Т), то я могу дать Вам встречное предложение — отказаться от разработки продукта Х за время Т, а поработать головой и придумать другой продукт Y, который можно разработать за реальное время Т2.
Чувствуете разницу? :)
Это не менеджер заставляет программиста работать (писать плохой код и потом в сверхурочные его править), а программист заставляет работать менеджера (придумывать продукты реализуемые в реальные сроки).
Даже если контора обанкротится через 2 месяца, то виноват будет не программист, который сделал плохой продут, а менеджер, который не придумал тот продукт, который спасет контору.
в нормальной ситуации ваш вариант в целом равнозначен вышеупомянутому варианту №3
Даже если контора обанкротится через 2 месяца, то виноват будетВиновата будет команда, не сумевшая предложить и реализовать вменяемую альтернативу.
в нормальной ситуации ваш вариант в целом равнозначен вышеупомянутому варианту №3Нет, это как раз альтернативное развитие ситуации в случае отсутствия консенсуса при варианте 3, вместо дальнейшего варианта 4 (увольнение программиста), мы рассматриваем вариант 5 (увольнение менеджера).
Если удается договориться на варианте 3, то это идеальная ситуация, когда и волки сыты и овцы целы, но обычно в 90% случаях так не получается, потому что если новые требования к продукту не требуют кардинальной переделки существующей архитектуры или инструментов, то с реализацией в «нормальном» режиме проблем нет, мы просто ограничиваем ф-ционал, чтобы уложиться в срок, а если требуют – то тут никакое ограничение ф-ционала не возможно, так как нет базового фундамента на котором вообще его строить, а для «правильной» разработки этого фундамента требуется заведомо больше времени чем выделено.
кто-то вполне может быть сокращен.Именно так.
Если менеджер не соглашается на вариант 5, то у руководителя конторы появляется дилемма, зависящая от его идеологии:
- Либо уволить «жёсткого» программиста (если руководитель адепт AGILE)
- Либо уволить менеджера (если руководитель адепт ANTI-AGILE)
Причина увольнения проста – с точки зрения выбранной идеологии либо тот, либо другой «плохо работает» и третьего не дано.
Виновата будет командаГрупповая ответственность — это отсутствие ответственности. В нашей игре реально плохо работать (некомпетентными) могут быть как программист, так и менеджер, но главный виновник, конечно, это руководитель конторы, который набрал команду и не смог организовать правильно её работу, и возможно, самое главное — выбрал неверную идеологию. А судьей является рынок, на котором будет или не будет получена прибыль.
- «Команда» — группа людей, поставленная заниматься конкретной задачей
- «Виновата» — не смогли найти решение, удовлетворяющее поставленным целям
В реальности, невозможность прийти к решению в команде всегда будет эскалирована на уровень выше, и, почти всегда, там будет принято решение, которое команде надо будет имплементировать.
но главный виновник, конечно, это руководитель конторы
Часто вижу такое утверждение. Наверное, это какое-то желание хоть в чем-то иметь возможность обвинить «руководителя конторы». На практике, никакого чувства вины там нет. Есть риск, есть награда. Получилось — отлично, всем хорошо (команде в том числе), не получилось — надо что-то корректировать и предпринимать дальше.
Надеюсь, понятно объяснил.
Это распространенное заблуждение — так реагировать на фразу «виновата команда» )Да нет, если кто-то в чем-то виновен, это значит, что именно он (его действия) стали причиной негативных событий. А вы путаете причину и следствие, определяя «виновата» — как «не смогли найти решение». Виновата — это значит, команда стала причиной, того что решение не найдено. Понятие вины подразумевает, несение ответственности за эту вину, и как ни банально, утверждение «виновата команда» — это перекладывание ответственности с конкретных виновников на некую «группу людей».
«Команда» — группа людей, поставленная заниматься конкретной задачей
«Виновата» — не смогли найти решение, удовлетворяющее поставленным целям
Часто вижу такое утверждение. Наверное, это какое-то желание хоть в чем-то иметь возможность обвинить «руководителя конторы». На практике, никакого чувства вины там нет.Ну, по себе людей не судят… Я когда писал «главный виновник, конечно, это руководитель конторы» имел в виду, что именно он является главной причиной того, что контора не получит прибыли/обонкротится и объяснил почему это именно так, про чувство вины у руководителя конторы — это вы уже нафантазировали, не знаю из каких соображений )
А вы путаете причину и следствие, определяя «виновата» — как «не смогли найти решение». Виновата — это значит, команда стала причиной, того что решение не найдено.
Команду поставили на задачу, дали ответственность и полномочия, а она не справилась. Задача не сделана, «виновата» команда — в случае сферического проекта в вакууме.
В целом, вы пишете про ответственность руководителя команды — с этим я не спорю. Но командная работа — на то она и командная. Вместе боролись, вместе прое^W не справились.
- При увольнении по соглашению сторон нет обязательных выплат. Предложить можно соглашение и без выходных пособий. Практика с выплатой выходного пособия сложилась, скорее, как альтернатива сокращению.
- В крупной организации могут не уволить, а поставить в разработку второстепенного (не mission-critical) продукта, скорее всего "приговоренного в декомиссу" в течение 3-5 лет. Особо нагружать не будут, повышать не будут, поощрять не будут, развития не будет. Всё по ТК. Если хватит глупости досидеть до end-of-life продукта, то дадут такой же, хм, перспективный. BTW, иногда (очень иногда) у упёртых жёстких одиночек (за счет недогруза задачами и от скуки) хватает сил переработать архитектуру такого legacy до весьма неплохого уровня. Это как бы почти win-win, но реально win для конторы и потраченные годы жизни на тупиковый проект, выгорание и ЗП ниже рынка.
- В небольших организациях такой опции нет, но зато могут себе позволить тщательнее отбирать новичков. Ну или придётся страдать.
- В стартапах часто на входе сразу говорят, что либо мы делаем продукт, который можно продать "к исходу сентября", либо бабло тупо кончается. И, да, за оставшиеся N месяцев, скорее всего, придётся 3 раза переписать продукт, потому что всплывают внезапные изменения.
Извиняюсь, что вмешиваюсь, но мне очень интересно узнать что может быть за программный продукт, который был бы полезен, будучи выпущенным за 2 месяца, но полностью бесполезным, будучи выпущенным за 3?
Честно.
Откуда берётся такая цифра, и насколько она, на самом деле, оправдана — я уже отвечал ниже.
А вообще разработка ПО для топовых моделей, да под новый процессор — ад. Работа месяцами по 14-16 часов в сутки с одним выходным в неделю- норма. Процессор НИКОГДА не появляется вовремя. Отладка идёт на уровне «абы явно не глючило»
Например ПО для выставки, которая будет проходить в течение трёх дней ровно через два месяца
Я понимаю случай с ПО для выставки, когда надо продемонстрировать хоть что-то и это лучше, чем ничего.
Но вот в случае с топовым телефоном не очень согласен. Если считать, что программист прав (agile подразумевает ответственную самоорганизующуюся и квалифицированную комманду)- и нужный софт делается за три месяца, то на рынок выведется очередной говнотелефон с глючным софтом, который повлечет за собой провальные масштабы продаж. Кто это считает?
Ну и вообще с точки зрения общества лучше бы, чтобы таких продуктов поменялось поменьше, но бизнес стремится к другому.
- В играх: новогодние, хеллоуиновые и прочие события. Специальный квест по поиску Санты нафиг не нужен в марте.
- В финансовой сфере: вся регуляторная часть. И прямо (к дате X должны быть внедрены фичи A и B) и косвенно (декларации НДФЛ интересны только с января по март). Похожая ситуация, когда внешний крупный вендор сообщил об изменении протоколов или снятии с поддержки текущего решения: тоже есть дедлайн на который повлиять невозможно.
- В рознице с сезонными пиками (Milfgard же писал): если автоматизация склада/логистики/розницы не сделана, то считай, что торопились зря и на этих праздниках попали и на оплату разработки и на разгребание без автоматизации. Может быть фатально.
- При заказанной и оплаченной рекламной кампании: если заказанная доработка критична для пропускной способности бизнеса. Реклама пойдёт, клиенты придут и… Ой.
- На самом деле похоже работают многие зависимости разработки от внешних контрактов: достроят завод, запустят в серию прибор и т.д. и т.п.
- Образование: Если не успеть разработать курс/продукт к началу учебного года, то придётся отложить как минимум на семестр.
- Безопасность: если есть архитектурная дыра и договоренности с white hat на 3 месяца до full disclosure.
Вы где-то между строк вычитали предложение работать сверхурочно? Вам показалось, я ничего такого не подразумевал.
Вариант поработать больше нормы есть всегда, и иногда он действительно может быть одним из решений проблемы со сроками, но это штука стрёмная, с кучей побочных эффектов, и может использоваться только по обоюдному согласию.
Это обосновано тем, что если выйти на рынок слишком поздно, то продукт окажется никому не нужен (или нужен в недостаточной степени, чтобы доходы позволили продолжать его разработку), бизнес закроется, разработчиков уволят. Я такое наблюдал лично ранее, и наблюдаю прямо сейчас на текущем проекте (собственно, именно по этой причине я треплюсь весь день на хабре вместо того, чтобы работать).
Если Вы имели в виду то, что зачастую менеджеры сильно преувеличивают критичность выхода на рынок именно через два месяца, а не, например, через пол года — то это правда. Они сами зачастую нифига не знают наверняка, паникуют и перестраховываются. Но! Именно они являются экспертами в этой области (бизнеса и рынка) — по крайней мере формально, и других экспертов всё-равно нет. Поэтому разработчикам ничего не остаётся, как принимать их оценку time to market, и исходить из неё, даже если она некорректная. Менеджерам ровно так же приходится принимать мнение разработчиков про разные фреймворки/ЯП/рефакторинг, даже если квалификации разработчиков недостаточно и они несут полную чушь — пока в команде нет других, более квалифицированных, приходится верить этим.
Если Вам кажется, что закрытие бизнеса (из-за срыва time to market) не является проблемой разработчиков, то у меня вопрос: какой смысл без спешки писать качественный код, если этот качественный код будет выброшен вместе с бизнесом ещё до того, как его увидят реальные пользователи? Может кому-то нравится, когда его работу выбрасывают, но мне — не очень. И качество кода важно только тогда, когда этим кодом кто-то пользуется.
При этом, через месяца 2-3 в игру стало можно играть без консоли разработчика, но слишком поздно.
Все понемногу привыкли к маразму с платными бета-тестами, называемыми ранним доступом, перезапусками невзлетевшего и прочими прелестями, кстати, довольно похожими на аджайловские «минимально рабочие продукты» и т. д.
Ну так мы имеем классическую диллему проект-менеджмента — либо страдает качество, либо сроки, либо стоимость. Нельзя оптимизировать сразу все три параметра.
И Agile в этом смысле поможет ровно настолько, насколько умна и опытна команда разработчиков. Т.е. жизнь бизнеса начинает зависеть не от менеджмента, а от разработчиков. Попытка переложить ответственность, наверное.
Иногда гибкость разработчика является дополнительной ценностью, которая продается или обменивается на взаимную лояльность.
Устраиваясь на наемную работу за деньги, я ставлю во главу угла деньги, потому что получать удовольствие от программирования я могу и без найма.
А деньги нам дает бизнес. Иногда, чтоб бизнес получил деньги, надо идти на компромиссы, иногда на неприятные. Agile дает нам возможность взаимодействия с теми, кто дает нам деньги и ставит во главу угла продукт, каким он нужен бизнесу. А ваш манифест просто ставит во главу устройство программного обеспечения в том виде, который нравится вам.
Хорошо крутить носом перед работодателем и заказчиком, когда на одно резюме десять вакансий. А если бы было иначе?
А вы никогда не думали что наемный работник всегда будет на одной стороне, а работодатель на другой?
Нет, не думал. Ведь наличие денег у работника определяется наличием денег у работодателя. Работнику не очень то выгодно банкротство работодателя, ведь так?
Убедить вас в том что ценности работодателя это и ваши ценности тоже (хотя это не так).
Простите, но разве получение денег не является общей ценностью для всех людей, которые вступают в трудовые отношения? Конечно, наемник хочет себе побольше денег, а работодатель себе. Но ценности то общие.
Просто наемный работник отказывается от результатов своей работы в пользу работодателя, в связи с чем резко падает мотивация к этой самой работе.
Хм, очень спорный момент. Работодатель ведь не просто отнимает результаты труда. Работодатель покупает их. Соответственно если у работника нет мотивации давать результат, то у работодателя нет мотивации платить деньги. Это с вашей точки зрения справедливо?
</сарказм
Ведь наличие денег у работника определяется наличием денег у работодателя. Работнику не очень то выгодно банкротство работодателя, ведь так?
«Стокгольмский синдром»?
Нет, это из другой оперы: не будь мудаком.
Понятное дело, что наёмный работник не обязан лезть из кожи вон ради развития бизнеса своего работодателя. Но и игнорировать интересы того, кто тебя нанял заниматься вполне определённой работой за деньги, на что ты сам добровольно согласился при найме — это тоже некорректно.
Адекватный работодатель отдает себе отчет в том, что работнику, конечно, банкротство не выгодно, но в большинстве случаев не фатально. Если работодатель не дает работнику ощутить удовлетворение от собственного труда, то такой работодатель сам себе злобный буратино — хуже фрустрированного работника только разочарованная жена.
Я никогда не сталкивался с работодателями, которые бы стремились лишить разработчиков удовлетворения от собственного труда. Никому из работодателей просто не было до этого никакого дела — они нанимают разработчиков для вполне определённых задач, среди которых получение удовлетворения от собственного труда не числится.
Мы сами должны уметь организовать свою работу так, чтобы и задачи работодателя выполнять, и удовлетворение от работы получать. Если не получается — надо либо учится это делать, либо менять работу. Ждать, что работодатель будет бегать вокруг разработчиков с охами и ахами, и каждый день интересоваться, получаем ли мы удовлетворение от работы, и чем он может помочь если мы вдруг его перестали получать — даже не знаю, как это назвать, слово "наивно" как-то слабо смотрится в этом контексте.
Да, работодатель обычно заинтересован в поддержании хорошего психологического климата в коллективе, но не надо совсем уж наглеть, считая что он должен нам сопли подбирать и утешать, если наша игрушка поломалась. В конце концов между работодателем и мамой есть разница — работодатель считает нас взрослыми, и относится соответственно.
Ждать, что работодатель будет бегать вокруг разработчиков с охами и ахами...
О том и публикация, что надо не ждать, а идти и разговаривать. А если понадобится — требовать. Права — они такие. Пока не потребуешь — не отдадут.
Добиваться соблюдения своих прав — это одно. Но не надо записывать меня в сторонники этого "манифеста". Есть немало ситуаций, в которых изложенные в нём идеи абсолютно корректны. Немало — это примерно 10-20%. Следованием этим идеям в остальных случаях будет только создавать проблемы, а не решать их.
Стандартный пример — разработка прототипа. Категорически несовместима вообще ни с чем из этого манифеста. Я лично просто стараюсь в разработке прототипов не участвовать вообще, потому что да, конкретно у меня удовлетворение от работы при этом обычно заменяется отвращением. Но если я соглашаюсь писать прототип — я не буду ставить качество превыше скорости, как бы мне этого не хотелось, потому что прототипу качество не требуется, а трата кучи времени на ненужные этому проекту вещи является либо признаком недостаточной квалификации, либо осознанным саботажем.
Стандартный пример — разработка прототипа. Категорически несовместима вообще ни с чем из этого манифеста.
Я вообще-то мимокрокодил, но поясните, пожалуйста, что вы этим хотите сказать? Потому что имхо не просто совместимо, а ну как иначе-то?
Концепция важнее новых требований — да. Если взялись разрабатывать автомобиль, то на выходе должен быть автомобиль, а не летающая субмарина.
Качество важнее скорости — да. Прототип автомобиля должен ездить, и пока он не ездит работа не закончена — жесткие сроки на невозможны.
Делать как надо важнее, чем делать как просят — да. Если заказчик требует установить руль под капотом, то следует игнорировать эти требования.
На всякий случай уточню очевидное: всё нижесказанное подразумевает, что прототип работоспособен, хотя бы в минимально-достаточном объёме.
Концепция важнее новых требований — нет. Мы прототип делаем, а не автомобиль. Разница в том, что когда мы делаем автомобиль — у нас есть концепция, и мы знаем, что хотим получить. А когда мы делаем прототип, мы его делаем как раз потому, что сформировавшейся концепции пока ещё толком нет, и что конкретно мы хотим получить мы ещё сами толком не знаем.
Качество важнее скорости — нет. Понятно, что прототип должен работать, никто не говорит, что его качество не имеет значения вообще. Но оно ни в коем случае не важнее скорости — т.е. выбор между (необязательным, потому что кое-как оно и без этого работает) улучшением качества и (тоже необязательным, потому что при необходимости можно и чуть позже релизнуть) увеличением скорости всегда делается в пользу скорости.
Делать как надо важнее, чем делать как просят — нет. Если заказчик требует установить руль под капотом, то для таких экспериментов прототипы и нужны, мало ли, может он знает какой-то секрет, и такое местоположение руля окажется уникальной киллер-фичей.
Я-то всю сознательную трудовую жизнь считаю, что концепция вырабатывается (и объясняется исполнителю!) еще до начала работы руками. Прототип начинают делать после того, как определились с концепцией. Т.е. «автомобиль с рулем под капотом», с учетом вашей поправки, это и есть концепция = условие задачи = «как надо». Если разработчик понимает, что заказчику нужна киллер-фича, то результат будет такой, какой нужен заказчику. А если разработчик не понимает смысла того, что от него требуют, то результата может не быть вовсе (руль будет где просили, но авто ехать перестанет, например).
С другой стороны, сержантский метод руководства («отставить разговорчики и выполнять приказ!») тоже вполне эффективен. Разве что слабо применим, когда от исполнителя требуется думать головой.
И еще одно разночтение: Качество кода важнее скорости его написания. Я всеми руками за то, чтобы разработка велась максимально быстро, но не в ущерб же качеству кода! А то как в анекдоте: «Я печатаю со скоростью 600 знаков в минуту. Тааакая фигня получается!»
Хорошо, что Вы что-то поняли. Плохо, что я, наоборот, запутался: объясните тогда, пожалуйста, как при Вашем подходе отличается разработка прототипа проекта от разработки самого проекта? Или они у Вас не отличаются никак — для разработки обоих должна быть заранее определена концепция, код пишем одинаково качественно (и, соответственно, с одинаковой скоростью), если новые изменения противоречат архитектуре мы её перепроектируем, сопровождаем код тестами и документацией… всё верно?
Если новые пожелания заказчика противоречат готовой архитектуре, то заказчику следует подробно разъяснить проблему. Хорошо проинформированный заказчик обычно не склонен ломать несущие стены.
В данном контексте я рассматриваю проект и продукт как синонимы. Прототип проекта/продукта — это нечто, что выглядит похожим на требуемый проект/продукт, но не предназначено для использования реальными пользователями. Прототип разрабатывается для того, чтобы заказчик смог "пощупать" проект/продукт задолго до момента, когда реально выпустить полноценный проект/продукт. И причина, по которой заказчику дают его "пощупать" — чтобы он мог сообщить о необходимости сломать несколько несущих стен на этом, раннем этапе разработки, когда стены полноценного проекта/продукта ещё никто не возводил. Мне действительно необходимо разъяснять что такое прототипы и зачем они нужны, или Вы всё-таки ответите на вопрос?
В этом наше с вами ключевое/концептуальное различие, и именно поэтому лезть дальше в дебри терминологии смысла нет.
:) А что, по-вашему, происходит, когда прототип накидали, пощупали, и решили что концепцию надо подправить? Эта новая концепция сразу уходит в разработку приложения? (Подсказка: нет.) Мы начинаем писать новый прототип для проверки новой концепции? (Подсказка: не совсем.) Ура! Вы угадали (надеюсь)! Мы быстро-грязно фиксим первый прототип под изменения концепции. И потом ещё не раз повторяем этот цикл. В полном соответствии с заветами не самого приятного варианта аджайла.
На самом деле быстро-грязная итеративная разработка прототипа — это ещё фигня, по сравнению с попыткой затащить прототип в прод, как только он начинает напоминать желаемое. Вот эта тенденция — реально беда, и чтобы этого не допускать иногда приходится прилагать реально героические усилия и даже опускаться до шантажа (мой любимый: "не вопрос, выкатим в прод, но лично я никаких багов/тасков по этому прототипу делать не буду, для меня он уже умер, как и положено хорошему прототипу").
Нет, не думал. Ведь наличие денег у работника определяется наличием денег у работодателя. Работнику не очень то выгодно банкротство работодателя, ведь так?
Эти вещи совсем слабо связанные. Кому то выгодно чтобы предприятие закрылось. Можно получить компенсацию и найти работу получше. Кому то все равно т.к. работник хочет уйти на другую работу. С другой стороны обратное тоже не верно. Если у работодателя деньги есть он не обязательно ими делится с работником например делая разного рода вычеты (а иногда даже нарушая трудовой договор). Не надо думать что все поголовно сидят и трясутся за свое рабочее место.
Простите, но разве получение денег не является общей ценностью для всех людей, которые вступают в трудовые отношения? Конечно, наемник хочет себе побольше денег, а работодатель себе. Но ценности то общие.
Тоже не совсем верно. Люди вступают в трудовые отношения чтобы обеспечить свое существование. Многие люди при достижении определенного уровня доходов с радостью бы их поменяли на более интересную и общественно значимую работу. Оттуда и разница в ценностях. До уровня базового содержания они у всех одинаковые. А потом начинают расходится.
Хм, очень спорный момент. Работодатель ведь не просто отнимает результаты труда. Работодатель покупает их. Соответственно если у работника нет мотивации давать результат, то у работодателя нет мотивации платить деньги.
У работника есть мотивация давать результат, но только приемлемый результат, а не отличный результат. А так как в областях типа ИТ очень трудно выставить формализованные критерии к качеству результата то проще пытаться замотивировать работника давать отличный результат. Именно про это тимбилдинг, аджайл и прочие мотивационные методики.
Это с вашей точки зрения справедливо?
С моей точки зрения справедлива совсем иная ситуация. но это уже выходит за рамки обсуждения статьи.
Эти вещи совсем слабо связанные. Кому то выгодно чтобы предприятие закрылось. Можно получить компенсацию и найти работу получше.
А будет ли работа лучше, если у нового работодателя не будет денег? Взгляните на картину целиком, мы ведь говорим концептуально, а не об одном специфическом примере.
Тоже не совсем верно. Люди вступают в трудовые отношения чтобы обеспечить свое существование. Многие люди при достижении определенного уровня доходов с радостью бы их поменяли на более интересную и общественно значимую работу.
У бизнеса ценности тоже могут меняться при достижении определенного уровня. Но прежде чем заявлять, что нечто не является верным — перечитайте еще раз.
Трудовые отношения — это отношения ради денег и никак иначе. Для человека, который вступает в трудовые отношения деньги являются ценностью.
Что станет с ценностями человека, если количество зарабатываемых денег снизится в пять раз? Наверное они снова поднимутся в иерархии ценностей.
С моей точки зрения справедлива совсем иная ситуация. но это уже выходит за рамки обсуждения статьи.
Я подореваю у вас коммунистические взгляды?
А будет ли работа лучше, если у нового работодателя не будет денег? Взгляните на картину целиком, мы ведь говорим концептуально, а не об одном специфическом примере.
А что будет если ни у кого не будет денег чтобы платить зарплату? вот тогда мы все с голоду и умрем.
У бизнеса ценности тоже могут меняться при достижении определенного уровня. Но прежде чем заявлять, что нечто не является верным — перечитайте еще раз.
У бизнеса ценности меняться не могут. Там только одна ценность это зарабатывание денег. Иначе бизнес быстро перестанет быть. Не путайте личность бизнесмена и его бизнес. Да и опять же ценности даже великих изобретателей (без шуток) быстро превращаются в жутко ретроградный луддизм при намёке на то что бизнес может перестать быть
А что будет если ни у кого не будет денег чтобы платить зарплату? вот тогда мы все с голоду и умрем.
Да, такое уже бывапо в истории.
У бизнеса ценности меняться не могут. Там только одна ценность это зарабатывание денег. Иначе бизнес быстро перестанет быть. Не путайте личность бизнесмена и его бизнес.
Конечно я имел в виду работодателя, человека.
А: Наличие смеха определяется наличием комической ситуации. (истинно)
Б: Наличие комической ситуации однозначно определяет только наличие комической ситуации. (тоже истинно)
Оба высказывания истинны, но высказывание Б никак не противоречит высказыванию А.
Над чем смеялись-то?
Условия бывают необходимыми, а бывают достаточными.
Наличие денег у работодателя не является достаточным, зато является необходимым условием наличия денег у работника.
Я все таки настаиваю на том, что программист должен знать логику.
(хотя и не думаю, что оно будет существовать всегда)
Так о том и речь. Вся история человечества пронизана уменьшением разрыва в правах разных классов населения. В пределе этот разрыв должен исчезнуть, исчезнуть он может только если убрать основу расслоения. Основой расслоения сейчас является частная собственность на производственные предприятия, землю и ресурсы.
Задача работника — выполнять работу качественно и в срок. А не идеально, и когда получится.
Речь не про «идеально» речь про одну из базовых потребностей человека гордится своим трудом. Для большинства людей их труд это основа их жизни и времяпрепровождения. Большую часть сознательной жизни человек сейчас проводит на работе. И каждому хочется понимать что он проводит это время там не бесцельно. Не просто работая за еду, а еще и выполняя общественно полезное дело. И в угоду быстрому(!) заработку прибыли приносится эта потребность. При быстром заработке обычно никакой речи о общественно полезной работе не идет.
По моему собственному опыту речь уже идет даже не о «сделать хоть как-нибудь». А сделать так чтобы пустить пыль в глаза потребителям продукта.
Как я понял этот манифест указывает своей целью выпуск качественного ПО.
И да манифест явно указывает на известные всем проблемы.
Однако видно, что сам автор явно еще не разобрался, что в 95% случаев программист даже близко не понимает проблемы бизнеса.
Так что мой ему совет, для начала найди работу как постановщик задач, затем как внедренец (хорошо бы еще побывать в роли хозяина/заказчика ПО). И вот тогда у тебя будут знания по всем ролям и после этого манифест будет куда более полным.
… недостаток личного профессионального опыта работы в хорошей команде, либо неумение свой опыт обобщить, либо общая озлобленность...
У меня здесь три основных оппонента, каждый из них имеет специфический опыт. Возможно, в чём-то они даже правы. Каждый имеет право на своё мнение. Не так ли? И я тоже могу перечислить набор эпитетов, характеризующих их с моей точки зрения. Но предпочёл бы всё-таки аргументацию.
Но предпочёл бы всё-таки аргументацию.
Я вам в своей ветке комментариев всё аргументировал, а вы в каждом ответе отмахиваетесь общими утверждениями.
Что-то совсем уже тошнит от «проектов» с которыми последнее (и не последнее) время приходится сталкиваться, как там все внутри…
Слышали такое выражение?
Для этого недостаточно задекларировать эти, в общем-то, имеющие право на существование принципы.
Вообще-то… :) есть и такая теория, что да, рождаются. По крайней мере из старших классов школы уже выходят либо сеньорами, либо мидлами. Поясню — для меня разница между ними определяется психикой, а не опытом или зарплатой.
Сеньорам комфортно работать с задачами, которые они не знают, как решать. Они в состоянии, что называется, "решить проблему". Любую. Просто берут на себя ответственность, разбираются в вопросе, и решают. Сеньоры часто не знают или не помнят мелкие детали устройства конкретных фреймворков, но зато они хорошо понимают принципы устройства этих фреймворков и могут быстро найти решение проблемы на незнакомом им фреймворке, которое не в состоянии найти мидл, вроде бы хорошо знающий данный фреймворк. (Вместо "фреймворк" здесь можно подставить что угодно — ЯП, ОС, утилита, сетевой протокол, ….)
Мидлы же предпочитают работать в знакомых условиях, писать типовые задачи на одном и том же, хорошо им знакомом ЯП, с использованием фреймворка, который они детально изучили… и не очень любят переучиваться на использование новых инструментов и подходов — хотя и делают это довольно регулярно, в IT без этого не выживешь.
Так что когда я вижу джуна, то обычно быстро определяю его как джуниор-сеньора или джуниор-мидла — смотря по его психотипу.
Стоит ещё добавить, что я не считаю сеньоров более "крутыми", чем мидлы. Крепкий мидл знает используемые им инструменты намного глубже, чем когда-либо их узнает сеньор. Я не считаю, что зарплата мидла обязательно должна быть ниже зарплаты сеньора — и мидлы и сеньоры бывают очень разные, и пользу проекту приносят тоже разную. Я считаю, что среднему проекту мидлов обычно нужно больше, чем сеньоров. В общем, мидлы для меня не являются разработчиками "второго сорта". Люди разные важны, люди разные нужны — всё зависит от задачи.
Сложившаяся же практика, когда мидл — это синоним менее квалифицированного разработчика, чем сеньор, и для многих просто карьерная ступенька между джуниором и сеньором, вызвана несколькими причинами.
Первая — мидлы менее охотно изучают новое, поэтому медленнее учатся, и, соответственно, их квалификация растёт медленнее.
Вторая — все сеньоры проходят этап, на котором приносимая их неуёмным любопытством изучать новое польза заметно компенсируется наносимым этим же любопытством вредом, и по факту, обучаясь быстрее и охотнее, в этот период они приносят примерно столько же пользы для проекта, сколько и мидл, знающий заметно меньше, но зато применяющий свои знания более уместно (ну, или просто менее разрушительно, это как посмотреть). С точки зрения менеджера, сеньоры на этом этапе мало отличаются от мидлов, поэтому их обычно называют мидлами и платят как мидлам.
Именно вышеописанное, на мой взгляд, объясняет, почему некоторые мидлы "вырастают" в сеньоров, а другие — нет: потому что те, которые вырастают, изначально были сеньорами, просто неопытными.
Помните что сказал Кристобаль Хозевич Хунта? «Бессмыслица — искать решение, если оно и так есть», в то время как настоящей проблемой будет — «как поступать с задачей, которая решения не имеет».
А прекрасное описание „сеньора“ — Чапаев из „Практикантки“ Каменистого.
Не помню, надо бы перечитать. Помнится, когда-то было жаль, что он эту серию не продолжил.
у нас в компании с легкой руки СТО одно время было понятие «перспективный джуниор». туда относились все кандидаты, которые имели менее 8 лет опыта работы в необходимом для проекта стеке, но показали хорошие знания в фундаментальны вещах из computer science (алгоримты и сложность, структуры данных, многопоточность и параллельная разработка — обуславливалось особенностями проекта, Big Data и highload).
возможно, «перспективный джуниор» звучит обидно, но после нескольких лет работы с командой, где средний стаж составлял 10 лет
в дополнениек вышеуказанным требованиям, понимаешь, что вот это — действительно senior.
Уйдите дальше русскоязычного перевода этого манифеста. Почитайте вообще кто эти все люди (https://agilemanifesto.org/authors.html). Потому что доводы описанные выше звучат ну просто смехотворно. В оригинальном манифесте на каждый пункт чуть ли не книга написана, а часто и не одна. И в кучах источников в подробностях раскрыта суть каждой фразы. А тут что? Отсутсвует даже базовое понимание Agile манифеста и практик которые за ним стоят.
Только после этого, набравшись опыта, наломавши дров, создавши и убивши не один и не два проекта, они сформулировали этот манифест.
Автор же пришел и просто сказал (даже не удосужившись вникнуть в манифест): Весь ваш опыт — фигня. Все что вы предлагаете — отстой. Вот вам мой манифест.
И кстати говоря, я бы на Вашем месте не только не пытался «взывать к авторитету» авторов манифеста Agile, но и не пытался бы переходить от обсуждения идей к обсуждению личностей и засыпать автора статьи уничижительными эпитетами вроде «юношеский максимализм» и «разработчики со стажем большим чем возраст автора». Давайте тогда ещё шутки про мам шутить, чтобы показать свой высокий интеллект.
Если уж так нравится воззвание к авторитету и особенно к возрасту, то с автором имею честь быть знакомым лично, и он будет постарше, чем мой дорогой оппонент. Что, видимо, должно заставить почувствовать жуткую неполноценность, ведь он старше, и пороха, вестимо, больше нюхал!
к обсуждению личностей и засыпать автора статьи уничижительными эпитетами вроде «юношеский максимализм» и «разработчики со стажем большим чем возраст автора».
Эти эпитеты у меня родились именно потому, что мнение автора ассоциируется у меня с собирательным образом многих программистов (в основном мало опытных) которых я на своем пути встречал. Личности я не обсуждаю. Я не знаю лично автора, его возраста, его опыта, я сужу исключительно по высказываниям и исходя из личного опыта подобного общения.
Если его это лично задело, да так, что вы как знакомый пришли его поддержать и указать мне на мою некорректность да еще ткнуть меня тем что я по сравнению с ним щегол малолетний.
Приношу искренние извинения автору.
Если уж так нравится воззвание к авторитету и особенно к возрасту, то с автором имею честь быть знакомым лично, и он будет постарше, чем мой дорогой оппонент. Что, видимо, должно заставить почувствовать жуткую неполноценность, ведь он старше, и пороха, вестимо, больше нюхал!
Что касается возраста, я воззываю к опыту и вкладу. Вы отличаете возраст от опыта?
Возраст не имеет ровным счетом ни какого значения. А опыт и вклад в отрасль безусловно имеет.
Какой опыт автор данного манифеста может противопоставить авторам Agile манифеста? Пока что я не увидел ни одного весомого аргумента.
Пусть автор покажет свои статьи, свои книги, свой код, свои научные изыскания. Хоть что нибудь кроме IMHO и откровенного троллинга? Не говорите только что троллинг — это такая высокоинтеллектуальная сатира.
Что, видимо, должно заставить почувствовать жуткую неполноценность, ведь он старше, и пороха, вестимо, больше нюхал!
Готов ознакомится с его достижениями, дайте пожалуйста ссылки. Если автор действительно нюхнул пороха, я готов почувствовать свою неполноценность.
Но пока что, все что я вижу, это то, что у нас с автором просто абсолютно разная система профессиональных ценностей, не смотря на то что и он и я программисты. И если моя система ценностей построена по мимо собственного опыта еще и на опыте индустрии (или как вы говорите «авторитетов»), то на чем построена система ценностей автора, кроме imho я понять пока не могу
Опять же напирание на авторитет. Мало того, что это шаблонная ошибка аргументации, так ещё и вот о чём стоит задуматься: если авторы этого манифеста занимают высокие управленческие должности, это говорит о них как о хороших управленцах, но ничего не говорит о них как о программистах.
P.S.: Вот это просто пушка, тут всё: и обида на сатиру, и «сперва добейся», и очередное воззвание к авторитету (они же книги писали!), и калька/перевирание моего указания на «интеллектуальность» аргументов:
Пусть автор покажет свои статьи, свои книги, свой код, свои научные изыскания. Хоть что нибудь кроме IMHO и откровенного троллинга? Не говорите только что троллинг — это такая высокоинтеллектуальная сатира.
Троллинг — это когда пытаются вызвать такую реакцию, как у Вас. Тут никто не пытался, все хотели по-доброму посмеяться, что и сделало большинство комментаторов. Заодно находя в шутке долю истины. Но нет, кому-то просто жизненно необходимо развести срач. И кто ещё здесь троллит?
Вы как мои эмоции прочли? Вы экстрасенс? Мне, как и вам не чем заняться вечером, вот и все. Завтра я проснусь с утра и пойду кататься на горных лыжах, после обеда сяду программировать и забуду про этот ваш манифест и весь этот пост и спор… :) Я абсолютно равнодушен и спокоен, поверьте. Я даже не одного плюсика/минусика не ткнул за всю беседу :)
programming-motherfucker.com — вот к слову более удачная шутка и отличный манифест.… и еще там 6 отличных книг. Сразу видно, автор знает о чем шутит ;)
«Манифест» не про то, что «не буду себя связывать обязательствами, буду делать что хочу, по своему капризу». «Манифест» про другое. Про то, что есть определенные технологические требования (ограничения), которые должны соблюдаться. Что на это надо обратить сугубое внимание, ибо из-за фетиша «БИЗНЕС», часто происходит наоборот. В угоду «удовлетворения капризов 'бизнеса'» часто страдает качество продукта.
И, действительно, не понятны эти «эджайлы». Например, то, что надо на совещаниях не «лить воду», быть конкретными и не затягивать эти совещания, так при чем тут «эджайл»? Это ведь при любом техпроцессе, в любой отрасли, является просто деловой этикой. Зачем тут придумывать «проводить мининги сугубо строго стоя?».
Другая сторона. Вовсе не обязательно рассматривать эту статью, как противопоставление «программисты» <-> «менеджеры». Ее можно рассматривать, против самих «программистов». Только против тех, кто жертвует качеством продукта.
Могу с уверенностью сказать, подходы и методы которые в них описаны работают. Принципы которые там высказаны работают. Возьмем те же SOLID принципы (Принципы которые должен знать каждый Junior вышедший из ВУЗа). Вы же не станете утверждать что они глупы и не имеют практического смысла?
Эндрю Танненбаум, Денис Ритчи, Брайан Керниган, Линус Торвальдс в конце концов. Вы серьезно считаете всех этих людей самозванцами или как? Я не могу понять.
Вас не смущает что Хоккинг не летал в космос? Вас не смущает что Братья Райт не построили ни одного аэробуса?
Объясните почему меня должно что-то в этих людях смущать? Если я прочел их труды и использую описанные в них подходы на практике. Причем до некоторых вещей я дошел еще до ознакомления с их трудами.
Что плохого в том, чтобы перенимать опыт лучших представителей отрасли? Если не у них, у кого вы предлагаете учиться? Или может вы предлагаете отбросить все что было сделано или написано до и изобретать все с нуля? И так каждый раз? Во всех областях?
Я вообще посыл автора и его манифеста вижу реально как то вот так:
«Так называемый» Деннис Ритчи, изобрел «так называемый» язык Си. И многие его приняли. Но лично для меня это выглядит как шутка, которая затянулась.
Компьютеры исполняют исключительно машинный код, а все эти ваши Си изобретены самозванцами и они уничижают права одной группы (компьютеров) по отношению к другой группе (людям)
Даже если в их книгах есть здравые мысли (а они там есть, я читал),
Назовите конкретно, какие книги вы читали, и какие конкретно практики не применимы или приводят к большим проблемам?
И когда человек зарабатывает деньги не кодом, а конференциями, возникают обоснованные сомнения в их, скажем так, близости к реальной разработке.
Это вы решили что они кодом ни когда не зарабатывали? Большинство из них начинали свою карьеру программистов в 70-80-тые. А их пик карьеры как разработчиков приходится на 80-90тые. Или для вас авторитетом является только тот кто всю жизнь на должности миддла просидел?
А при чем тут эти люди? Они создали Agile Manifesto? Они как раз намного больше сделали, чем наговорили, в отличие от.
Вы заблуждаетесь, просто эти люди создавали инструменты для разработчиков. Поэтому их работу вам видно. А те кто сформировал Agile создавали продукты и программы для бизнеса. Но и те и другие являются признанными во всем мире профессионалами. И те и другие сделали огромный вклад в индустрию. Просто в разные ее области. А мы сейчас тут говорим как раз о разработке и бизнесе.
Потому что сомнение, а не доверие, является признаком разума.
Хорошо. По вашей логике: — Я что-то сомневаюсь что вы вообще программист и имеете какой то отношение к IT. Мне кажется вы в своей жизни вообще ни одной программы не написали. Ведь я их нигде не видел. И показать вам нечего.
С чего вы взяли, что они лучшие?
Их вклад в индустрию признается IT сообществом в лице сотен тысяч профессионалов а так же в лице крупных технологических компаний таких как IBM, Intel, Microsoft и т.д.
Что они сделали? По сравнению с перечисленными выше Торвальдсом и компанией — ничего.
Это смешно. Компания людей выше в комментарии, она про технологии. Поэтому их работу видно. Компания из Agile манифеста — про программистов в бизнесе. Это не умоляет ни как того что они сделали для индустрии. Сотни тысяч разработчиков каждый день пользуются архитектурными и другими паттернами которые они сформулировали, пишут тесты в соответсвии с методологиям которые они разработали, проектируют программы в соответсвии с принципами которые они предложили, выпускают успешные продукты в соответсвии с методиками которые они предложили. Причем многие из них об этом даже не подозревают, потому что информацию черпали не из первоисточника а из перепечаток, статей, и т.д. и т.п.
Считать их по умолчанию непререкаемыми авторитетами на основании того, что какое-то число кого-то там их «признало», они написали кучу книг и бла-бла, до такой степени, что приводить их в дискуссии как ad hominem — это хреново.
Что касается меня лично, то я считаю их авторитетами, потому что я прочел ряд их книг и осмыслил их критически, после чего применил знания на практике. Я убедился в том, что методики этих ребят работают и помогают делать продукты.
Именно поэтому я нахожусь в числе кого-то там кто их «признал». С чего вы взяли что я их признал «по умолчанию», просто потому что их признали остальные я ума не приложу. Вы сами себе выдумали это? Вам не приходит в голову что эти «какое-то число кого-то там», так же читали их книги, критически их осмысливали и применяли подходы на практике? Другие «кто-то там» нанимали их на работу и видели их результаты. И так далее.
Если есть способ сделать как то так чтобы вас начали признавать «по умолчанию», расскажите его пожалуйста?
Я говорю, что такие люди зарабатывают на жизнь не программированием, а написанием книг и выступлениями. Стоит хотя бы задуматься: а не оторвались ли эти дяди от реальности, пока ездили по конференциям?
Откуда такие выводы? Kent Beck например работает сейчас в Facebook… И да, мне вас искренне жаль, если ваш потолок в карьере — рядовой Senior разработчик. Потому что все что выше (в любой ветке развития IT специалиста будь то менеджерская ветвь или техническая) в любом отношении предполагает что 80% времени вы будете отнюдь не код писать. Если верить вашим взглядам, любой разработчик доросший до уровня выше Senior, через пару тройку лет теряет связь с реальностью. Но вот реальность такова, что этим потерянным людям ни чего не мешает создавать и выпускать успешные продукты, в отличие от рядовых программистов которые пишут код ради кода и меняют работу каждые пол года при этом не выростая никуда по карьерной лестнице.
Ну, вот например я вырос, и уже много лет трачу значительную часть времени не на код, а на общение, обучение и написание документов. Тем не менее, я согласен с тем, что если код не писать, причём минимум 30% времени, то любой крутой архитектор/principal за 4-5 лет превращается в тыкву. Если работать на более менеджерской и менее технической позиции вроде PM/CTO, то без написания кода вполне реально сохранить квалификацию для своей должности, но нормальным разработчиком при этом быть перестаёшь.
Кстати странно получается. Вы сейчас зарабатываете жизнь не программированием, при этом говорите о том, что приведенные выше люди далеки от реальности потому что зарабатывают не программированием? :D Очень логично. Но вы же один из этих людей так или иначе. Из тех зазнавшихся дядек что оторвались от реальности.
Я зарабатываю тем, что помогаю заказчикам решить их проблему, а вовсе не программированием.
Иногда для этого требуется побыть бизнес-аналитиком и помочь заказчику понять, что проблему нужно решать вообще не разработкой изначально заказанного софта, а как-то иначе. Почти всегда архитектором, спроектировать необходимую систему, разработать API и написать про всё это кучу документов. Почти всегда тимлидом, техлидом или простым сеньором, занимаясь обучением, ревью, или написанием значительной части проекта самостоятельно. Иногда даже немного девопсом, потому что мне для комфортной работы нужен надёжный и быстрый конвейер CI/CD и безопасно настроенные сервера, и не всегда есть кому это поручить. Совсем редко проджект менеджером, как-то раз даже продакт овнером — но это уже не совсем "моё", предпочитаю чтобы этим занимался кто-то другой.
Так что я вижу очень многие этапы разработки лично. И я вижу, как регулярное написание кода помогает сохранять и развивать навыки архитектора. И вижу, как длительное отсутствие написания кода делает разрабатываемые архитектуры оторванными от реальности и создающими проблемы, вместо того, чтобы их решать (меня это тоже касается напрямую, потому что хотя я и пишу постоянно код, я не делаю это на всех ЯП/фреймворках/платформах, которые когда-то знал, и качество проектирования архитектуры под эти, неиспользуемые мной, технологии — с годами падает катастрофически).
Если у Вас мечта вырасти в архитектора или принципала, с надеждой после этого перестать лично писать код — у меня для Вас плохая новость: через несколько лет наслаждения такой жизнью у Вас от высокой квалификации останется только память о ней и неимоверные понты, которые будут сильно мешать найти новую работу, после того, как Вы вылетите со старой.
Более того, беспокоиться об этом Вам нужно лично, потому что нанимателю до этих проблем дела обычно нет, и заполучив крутого архитектора наниматель, как правило, недальновидно предпочитает нагрузить его на 100% работой с архитектурой и документами, не оставляя времени на написание кода — так что если самому не выбивать возможность регулярно писать код, её обычно и не будет.
И Agile подходы, а так же рекомендации тех людей о которых идет речь мне в этом больше помогают, чем мешают. При чем и когда я пишу код и когда работаю с людьми. Не все там идеально, да. Но я и не говорил нигде что Agile идеален.
Спорили Вы не со мной. Я просто влез прокомментировать что "Если верить вашим взглядам, любой разработчик доросший до уровня выше Senior, через пару тройку лет теряет связь с реальностью." не такая уж и глупость, и нередко такое действительно происходит.
А! До меня, похоже, дошло, на что Вы так резко отреагировали. На "… но нормальным разработчиком при этом быть перестаёшь", да?
В случае PM/CTO я не вижу в этом ничего плохого, и упомянул это исключительно потому, что многие крутые разработчики действительно любят писать код, но ещё они любят зарплату по-больше и должность по-круче. И им кажется, что они могут быть PM/CTO, и при этом продолжать писать код, поскольку им нравится писать код. Так вот — это им только кажется, на практике это совмещать практически нереально (если не брать мелкий стартап, где 2-3 разработчика и один из них, по совместительству, ещё и CTO — пока стартап мелкий CTO ещё будет писать код, но как только команда вырастет времени на это уже не останется).
Продукты в которых они так или иначе поучаствовали вы используете чуть ли не каждый день, потому что их привлекают к работе мировые лидеры IT отрасли. Продуктами этих компаний вы каждый день пользуетесь.
Читайте больше книг IT тематики, а не Википедию и низкопробные статьи в интернете. Там информации куда больше. Если бы вы их читали, вы бы знали в каких компаниях эти люди работали, код каких продуктов писали и т.д.
Иногда складывается ощущение что я веду дискуссию с плоскоземельщиками. Потому что доводы они приводят именно такие «Я не видел что она круглая, а все что описано в официальных источниках — заговор». То что вы чего то не видели говорит только об уровне осведомленности.
Вот эта ваша выборочность она на мой взгляд как раз говорит о том, что вы просто об одних людях «слышали» и приняли на веру их авторитет, а о других не слышали и поэтому ставите их авторитет под сомнение.
А реальность такова, что и те и другие сделали огромный вклад. И работы и тех и других используются повсеместно. Просто об одних вы слышали а о других нет.
Для многих программистов в особенности у нас в СНГ Стив Джобс и Билл Гейтс гениальные программисты :D А о том кто такой Денис Ритчи или Дональд Кнут они вообще не знают… Если они о таких мастодонтах не знают ничего, откуда из знать о Фаулере, Бэке или Мартине (Они все таки более узкие спецы).
Код они писали еще до того как многие из нас родились, а многие познакомились с компьютерами. Вас это настораживает?
Разумеется, настораживает. Во времена их активности именно в качестве кодеров многие современные подходы находились на стадии теоретических изысканий — следовательно, не были применимы к их опыту написания кода.
Некто может как никто другой в мире уметь обрабатывать дерево киянкой и долотом, но обязаны ли мы поэтому считать его непререкаемым авторитетом в современной столярной мастерской? А если учесть что этот мастер в последний раз работал с деревом десять с гаком лет назад, а потом "профессионально вырос" до руководства другими людьми?
Во времена их активности именно в качестве кодеров многие современные подходы находились на стадии теоретических изысканий — следовательно, не были применимы к их опыту написания кода.
А кто эти современные подходы собственно сформулировал и первым применил на практике? Я вам отвечу. Они и сформулировали, они и применили. А потом формализовали в виде книг и статей, чтобы менее опытные программисты не переизобретали велосипеды…
Каждый профессионал в своей жизни проходит через несколько стадий:
1) Обучение
2) Наработка опыта
3) Передача опыта следующим поколениям
Все эти люди находятся на стадии №3. Вот и все. Вы можете им не доверять, вы можете их отрицать, вы можете переизобретать велосипеды заново. Объективной реальности это не изменит.
Некто может как никто другой в мире уметь обрабатывать дерево киянкой и долотом, но обязаны ли мы поэтому считать его непререкаемым авторитетом в современной столярной мастерской? А если учесть что этот мастер в последний раз работал с деревом десять с гаком лет назад, а потом «профессионально вырос» до руководства другими людьми?
С чего вы взяли что они всю жизнь обрабатывали дерево киянкой и долотом? Они как раз таки изобрели и формализовали ЧПУ станки, и теперь продвигают их в массы попутно осмысливая их и дорабатывая (А киянку и долото они давно положили на полку). Вы в это же время отсекаете весь их опыт и продолжаете обрабатывать дерево киянкой и долотом, которые по дешевке купили на распродаже…
По Agile сформулированному Бобом Мартином работают куча передовых IT компаний среди которых Apple, Google, Intel, IMB, etc.
Паттерны Enterprise приложений Фаулера используют в разработке корпорации и банки по всему миру.
Подходы TDD разработанные Кентом Бэком используют множество компаний где важно качество продукта и его стабильность.
Вы можете называть этих людей самозванцами и ставить под сомнение их подходы сколько угодно, это не отменит объективной реальности, хотите вы в нее верить или нет.
Разработать матмодель ПО;А если ПО основано на эвристических алгоритмах? ;)
Раньше я думал, что таких людей мотивирует «обучение за счет компании», когда в каждый новый проект вкладывается как можно больше хайповых технологий и методик. Гвозди забиваются микроскопами, бюджеты и сроки раздуваются на порядки, зато в резюме появляются новые строчки изученных технологий. Казалось бы, теперь у тебя отличное резюме, можешь «двигаться дальше», в более крутую компанию. Но нет, «жёсткие программисты» продолжают сидеть на месте и саботировать проект за проектом.
Но самое страшное то, что они выступают с докладами на крупных конференциях и с гордостью рассказывают о своих «достижениях», распространяя хайп.
Если без ТЗ, вчера и бесплатно — то это проблема бизнеса и «бюджеты и сроки раздуваются на порядки»
Если программисты постоянно не укладываются во вменяемые ТЗ без форс-мажоров и предрелизных правок типа «завтра сдача лифта, сделайте, что он не только вверх-вниз ездил, но и вбок, это же несложно. Ну а ТЗ? возьмите на вертикальный лифт и просто поверните, там одинаково» — меняйте программистов.
PS простите, но ни разу не видел, чтоб на крупных конференциях вставал руководитель компании и говорил «докладчик растяпа и хайпожор, всё сделал плохо, бизнес страдает и его выгнали как кота на улицу. Не верьте его словам»
Описанную вами ситуацию на конференциях тоже не встречал ни разу. Как минимум, потому что она неэтична. Ну и вроде как не принято в IT «выгнонять как кота на улицу». Даже если принято решение расстаться, все равно обычно стараются расстаться миром.
Второй говорил Командиру в полёте —
''Я зачитал Руководство до дыр!
Но, чтоб я ни делал, Вы только орёте!''
''Ты делай как надо!''- Сказал Командир…
Горькая правда жизни в том, что подавляющее большинство имеющегося ПО не нужно было даже начинать разрабатывать, не говоря уже о качественной разработке. А около того ПО, что действительно нужно, уже есть регулятор от государства и УК.
Кроме того, адептов Сразу Всё Делать Правильно я видел много и в т.ч. в зеркале, это не работает. Человечество едет на костылях которую тысячу лет совершенно не из-за нехватки манифестов, а из-за нехввтки кадров. Костыли в потребном количестве можем производить, а чуть поинтереснее — люди кончаются.
Поэтому совершенно без издёвки предлагаю Вам заняться важными штуками, где от косяков могут люди погибнуть, и где думать поэтому надо сильно до. Больше хороших штук появляется от запиливания хороших штук, а не от запиливания хороших манифестов.
Практически со всем согласен. Однако, призыв тут не "Сразу Всё Делать Правильно", а совсем другой.
А agile тут мог навлечь на себя гнев автора по причине того, что его основные концепции некоторые товарищи используют как проститутку, в угоду своим корыстным целям и/или непрофессионализму.
Цирк с понями можно устроить из произвольного манифеста, не только из agile. Agile вообще нормальный, если себя в руках держать, а не буквально понимать, что там написано. Только ведь в таких условиях всё нормальное.
А вот архитектура, вот ее «хорошесть» — определяется более просто, Архитектура — это субстанция, которая завязана на «бизнес-процессы», которые в свою очередь могут очень быстро меняться, а могут годами быть жестко регламентированными (например законодательством). Поэтому, я считаю, что «хорошая архитектура», это прежде всего та, которая построена на хорошем и глубоком анализе бизнес-процессов.
Помните «метод бумажных карточек ограниченного размера»? Помните «сформулируйте, свои пожелания короткими предложениями не больше 5 слов?» Нудно долго итеративно…
А сейчас ведь как модно, быстро пара совещаний, копи-пасте с другого проекта, 2..3 «фреймоворка-на-слуху» на выбор… коммерческое предложение и вперед шашки наголо, пока бизнес не передумал.
Расскажите этот манифест своим конкурентам, которые начнут продавать свой продукт пока вы делаете мат. модель. А на вырученные деньги потом купят Вас и Вы им уже сделаете как надо.
В описанной гипотетической ситуации инженер как работал, так и продолжает работать. Ничего не изменилось.
Кто-то сверху кого-то купил. Но откуда следует, что нужно бороться именно за этого конкретного нанимателя? Может, тот, который перекупит, будет лучше?
Ну, тогда, глупо сравнивать сей манифест с гибким. Ибо agile таки про то, как сделать хорошо типовому бизнесу а не Вам лично или какому-то гипотетическому инженеру в вакууме.
Кто будет нанимать такие команды, которые призывает творить вышеупомянутый манифест? Такие клиенты есть и сейчас(оружие массового поражения, космос, ядерная энергетика, некоторые научные изыскания), когда итеративная модель не подходит, все всё сразу делают хорошо ибо ошибка в проде стоит ощутимо дороже промедления. И за хорошие деньги. Почему лично Вы или Я не попали в ряды таких инженеров, это явно не вопрос разработки каких-то манифестов.
Кто будет нанимать такие команды
Кто будет нанимать работника, который, видите ли, требует соблюдения ТК? Никому такой не нужен. Лентяй неблагодарный.
Даже не знаю как можно ответить на такое передёргивание. Аналогия как минимум странная.
Вместо этого, попробую ещё раз раскрыть свою мысль, хотя, я был бы рад ошибаться.
Есть вещи которые нужно сделать быстро и можно улучшить потом. Это повысит их ценность. 90% разработки ПО крутится вокруг таких вещей. Это просто факт, кто вторым вышел на рынок — проигрывает в большинстве случаев. А 9 женщин не родят ребёнка за месяц©.
Именно по-этому вводятся понятия минимального жизнеспособного продукта и итеративных подходов к разработке.
Если внимательно прочитать статью, то будет видно, что соблюдение технологии ставится на первый план. А соблюдение технологии — это простой и понятный код, полное тестирование и развёрнутая документация.
Технология для строительства АЭС, загородного дома и деревенского туалета — это три разных технологии.
С точки зрения манифеста не очень согласен. Эти технологии, как и технология проведения аудита или сдачи бухгалтерской отчетности, имеют очень много общего — у них есть известные этапы работ, продолжительность и очередность которых может быть определена достаточно точно еще на этапе планирования проекта. Грубо говоря — фундамент, стены, крыша, а не сначала крыша, потом фундамент, потом стены.
А вот этапы разработки планировать гораздо сложнее. Зачастую изначально очень трудно оценить не только продолжительность каждого этапа, а вообще какие этапы нужны, чтобы разработать тот или иной продукт.
А все потому, что АЭС, дома и туалеты человечество строило не раз и имеет достаточно большой опыт, а вот разработка — она всегда новая.
Какой процент софта разрабатывается реально с нуля? Особенно, как вы говорите, «человечеством», так-то для студента каждая программа — что-то новое. Давайте возьмем как пример самую распространенную область — веб приложения и корпоративное ПО. Что там нового? Взял фреймворк, написал поверх него бизнес логику, протестировал, задеплоил на продакшен. Бизнес логика разная? Ну так и один и тот же дом, в зависимости от местоположения, будет различаться — где-то утеплить сильнее, где-то фундамент изменить и тд.
Понравилось. Как то напоминает этот манифест: http://programming-motherfucker.com/
В некоторых ситуациях ваши правила только помешают. В том что вы называете мат. моделью в первую очередь надо определить срок эксплуатации ПО, выгоду от оптимизации с помощью него, потери от усилий на разработку. Нет смысла пилить с заделами на будущее то, что уже не пригодится через три месяца. Учитывать «технические» моменты реальной жизни надо, если короче. Бюрократия в государстве ведь тоже оборотная сторона принципов, направленных на лучшее. Но в итоге всех бесит и раздражает
Углубитесь в историю. Этот манифест был сформирован людьми которые работали в отрасли во время ее зарождения. Этот манифест не подходит для команд с низкой квалификацией.
Модель водопада как раз таки была изобретена в ответ на появление огромного кол-ва молодых программистов на рынке, которые понятия не имеют как делать проекты и которыми отрасли пришлось учится как то управлять.
Agile модель работает только тогда, когда в команде большинство составляют уже сложившиеся профессионалы
Agile там закончился с появлением Falcon 9 FT. Точно также не видно Agile с капсулами Dragon.
Я думаю, что нет. Смысл Agile для Falcon был в том, что Маску срочно нужен был продукт, на котором он мог бы запускать спутники, чтобы зарабатывать деньги на дальнейшую разработку. Поэтому и летали ракеты с полезными нагрузками, хотя это были фактически недоделки.
А с BFR уже так торопиться нет смысла — рабочая лошадка есть, летает и приносит деньги. Поэтому вряд-ли мы увидим BFR 1.0, 1.1 и т.д.
Вы говорите о фреймворке Cynefin, а не об agile, а непосредственно agile применим, как правило, в «запутанном» домене, не в «хаосе».
Но применение этого фреймворка для определения методологии разработки и решении о применении agile (замечательного, но не универсального подхода) весьма полезно. Возможно с пропуска этого шага зачастую и начинается внедрение неподходящего к ситуации agile-а, вызывающего, в дальнейшем, бурю негодования у разработчиков.
en.wikipedia.org/wiki/Cynefin_framework
Многие программисты порой забывают за что их ценит бизнес (подсказка: не за совершенный код).
В принципе описан обычный манифест программиста для встраиваемых систем. Так что хотите заделаться жестким программистом — идите в embedded.
¯\_(ツ)_/¯
Еще раз повторюсь, Agile не отменяет ни проектирования, ни фиксации требований, ни управления рисками ни контроля качества.
И да, то что у нас в России продают под видом Agile, им не является.
Здесь обсуждают манифест, знание о котором у людей сложилось исключительно из основных тезисов манифеста и додумывания всего остального, а так же опираясь исключителньно на свой негативный опыт взаимодействия с менеджерами и заказчиками.
При этом вообще не углубляясь в суть манифеста, в то, почему он был сформулирован, для каких целей, когда, зачем, и так далее.
Agile был сформулирован IT ИНЖЕНЕРАМИ и УЧЕНЫМИ в области CS.
Мол, так все работает и нечего туда лезть?
Нет, отсылка следующая: — Сперва разберитесь в вопросе, после давайте обсудим.
В этом обсуждении я оставил несколько аргументированных комментариев, и несколько эмоциональных, поддавшись на троллинг автора.
1. Не вижу критики Agile. Как предложенный «манифест» решает проблему сдачи качественного продукта за предсказуемый срок и бюджет? Если он не решает, то он не нужен, или нужен, но не в такой форме подачи.
2. Какие конкретно предложения из «манифеста» предназначены для решения проблемы предсказуемости выхода обновлений продуктов? Если никакие, то он не нужен или нужен, но не в такой форме подачи.
Вот и всё)
Где я отсылаю к авторитетам?
Очевидно, имелся в виду ваш "соратник".
Как предложенный «манифест» решает проблему сдачи качественного продукта за предсказуемый срок и бюджет? Если он не решает, то он не нужен, или нужен, но не в такой форме подачи.
Как agile-«манифест» решает проблему сдачи качественного продукта за предсказуемый срок и бюджет? Если он не решает, то он не нужен, или нужен, но не в такой форме подачи.
Какие конкретно предложения из «манифеста» предназначены для решения проблемы предсказуемости выхода обновлений продуктов? Если никакие, то он не нужен или нужен, но не в такой форме подачи.
Какие конкретно предложения из agile-«манифеста» предназначены для решения проблемы предсказуемости выхода обновлений продуктов? Если никакие, то он не нужен или нужен, но не в такой форме подачи.
Вот и всё)
А он и не решает.
Так, значит, он не нужен?
Может вы наконец ответите хотя бы на один вопрос, вам заданный?
Да как-то не привык отвечать на риторические вопросы.
Разумеется, "мой" манифест не решает проблему сдачи качественного продукта.
А какую проблему решает agile-манифест?
По-моему, это бессмысленный разговор.
Ну так а какую проблему решает аджайл-манифест? Его же зачем-то выложили в интернет.
1) Регулярная и ранняя поставка ценного программного обеспечения.
2) Обеспечение заказчику конкурентного преимущества
3) Выпуск продукта с периодичностью от пары недель до пары месяцев.
4) Налаживание устойчивого процесса разработки.
5) Повышение гибкости проекта.
Ничего из перечисленного манифест не решает. Это решает только правильно поставленный конкретный техпроцесс в конкретной команде.
Ничего из перечисленного манифест не решает.
Решает, с помощью Agile методологий и…
Это решает только правильно поставленный конкретный техпроцесс в конкретной команде.
И вот список некоторых из них...:
1) Adaptive software development (ASD)
2) Agile modeling
3) Agile unified process (AUP)
4) Disciplined agile delivery
5) Dynamic systems development method (DSDM)
6) Extreme programming (XP)
7) Feature-driven development (FDD)
8) Lean software development
9) Kanban
10) Rapid application development (RAD)
11) Scrum
12) Scrumban
Во-первых, не всё, что здесь перечислено, является полноценным техпроцессом.
Во-вторых, речь шла про манифест. Не нужно соскакивать с темы.
Иногда это намного важней всяких продуктов и сроков
Я вам предлагаю сперва разобраться в вопросе. Потому что на мой взгляд вы обсуждаете манифест не имея ни малейшего представления о том, какие на самом деле идеи в нем заложены. Если вы хотите реально конкретных ответов на поставленные вопросы, откройте книги авторов манифеста и почитайте их.
В них написано и как решить проблемы сдачи качественного продукта в установленный срок и как решить проблему предсказуемости выхода обновлений и даже о том, как разрабатывать архитектуру приложений которые стабильно работают и адаптируются к изменениям требований. Все эти книги и их авторов легко найти в интернете.
Приведу простой пример. Я думаю вам точно известны SOLID принципы. Так вот их сформулировал один из авторов и главных вдохновителей Agile манифеста. Вы же не станете утверждать теперь, что SOLID — чушь и не работает?
Я не отсылаю вас к авторитетам.
Позвольте! У меня все ходы записаны:
Я бы посоветовал автору просто ознакомится с биографиями и опытом людей которые сформулировали Agile манифест…
https://habr.com/post/431064/#comment_19415788
Потому что на мой взгляд вы обсуждаете манифест не имея ни малейшего представления о том, какие на самом деле идеи в нем заложены.
Но вы ведь тоже обсуждаете "мой" манифест не имея ни малейшего представления о том, какие на самом деле идеи в нём заложены.
Обсуждайте. Только в рамках приличия, пожалуйста.
Все эти книги и их авторов легко найти в интернете.
Я даже читал некоторые из них, и даже со многим согласен. Значит ли это, что я должен соглашаться со всем, что будут говорить эти авторы в будущем?
Вы же не станете утверждать теперь, что SOLID — чушь и не работает?
Нет, не стану. См. выше.
Позвольте! У меня все ходы записаны:
Уделали… Мой посыл отсылки к «авторитетам» как раз в том что мне кажется вы не совсем правильно поняли данный манифест (А может и не хотели понять).
Просто Agile как раз таки решает некоторые из тех проблем которые вы затронули в своем манифесте.
Ваш манифест больше похож на манифест разработчика которого достали «эффективные менеджеры».
Но проблема в том что Agile тут не при чем. И эти менеджеры понятия не имеют что такое Agile и не следуют тем методологиям которые наследуют данную философию.
По-видимому, это разговор бесконечен, потому что не существует никаких исследований на тему того, что аджайл либо "улучшает", либо "ухуджает" разработку ПО.
Многие люди считают, что аджайл (обобщённый) работает, потому что лично у них всё получилось. Но тут как с гомеопатией. Многие утверждают, что лично им помогло, но механизма воздействия предъявить не могут.
Ваш манифест больше похож на манифест разработчика которого достали «эффективные менеджеры».
Не допускаете мысль, что, наоборот, просто вам сильно повезло, вопреки аджайлу?
И эти менеджеры понятия не имеют что такое Agile и не следуют тем методологиям которые наследуют данную философию.
О том и речь, что эта "философия", независимо от того, какие цели изначально преследовали или не преследовали авторы, направлена на перекос в сторону интересов одной из сторон. А внедряет эту "философию" именно та стороны, в чью сторону идёт перекос. Хорошо ли это? А вот здесь, видимо, у разных сторон ответ свой.
По-видимому, это разговор бесконечен, потому что не существует никаких исследований на тему того, что аджайл либо «улучшает», либо «ухуджает» разработку ПО.
Вообще то существуют. Не про обобщенную философию кончено, но про конкретные методики. И как правило с цифрами и метриками.
Не допускаете мысль, что, наоборот, просто вам сильно повезло, вопреки аджайлу?
А почему мне повезло? Потому что я не работаю с эффективными менеджерами?
О том и речь, что эта «философия», независимо от того, какие цели изначально преследовали или не преследовали авторы, направлена на перекос в сторону интересов одной из сторон. А внедряет эту «философию» именно та стороны, в чью сторону идёт перекос. Хорошо ли это? А вот здесь, видимо, у разных сторон ответ свой.
Да, здесь есть проблема, потому что внедрять ее должны разработчики, которые понимают о чем она, а не менеджеры которые вообще ни чего не понимают в разработке ПО.
И нет в ней нет перекоса, даже если это не очевидно. Более того, чтобы избежать заблуждения о том что существует перекос, Agile был дополнен создателями другим манифестом.
Вот он:
manifesto.softwarecraftsmanship.org
Working software over comprehensive documentation
К.О.: потому что бизнесу нужно именно working software.
Customer collaboration over contract negotiation
К.О.: потому что согласование контракта с ТЗ со всеми мелочами может занять больше времени, чем есть на вывод продукта на рынок.
Responding to change over following a plan
То есть, если рынок изменился, и план больше не актуален, вы предлагаете все равно продолжать его придерживаться? )
Другими словами — давайте сделаем грязно, но быстро или чисто, но долго. В продуктах, чей жизненный цикл не превышает пару лет, допустимо первое. Продукты, чей жизненный цикл от 5 лет и более, требует второе. Вот поэтому в Software agile и любят.
Если первое — и не согласовать что конкретно мы должны сделать, сколько у заказчика есть итераций на согласование дизайна, сколько у заказчика есть время на приемку каждой фичи/итерации, и не включить в контракт что именно мы должны по нему выполнить, то можно встрять на конкретные деньги. Сколько раз уже видел примеры до чего доводит принцип «лишь бы продать».
А вот если просто продать гребцов на конкретный срок — то тут уже заказчик может хоть десять пивотов устроить за свой счет, на здоровье. Но заказчик тоже не дурак — он посмотрит конечно на накаченные бицепсы и хорошие зубы разработчиков, но ему то нужен выполненный продукт. Потому продавать живой товар обычно сложней.
А мы согласуем контракт на разработку продукта, или продажу разработчиков по time&materials?Мне кажется, вы путаете теплое с мягким. Я этот принцип понимаю так: чем тратить время на согласование ТЗ, детальной оценки трудозатрат, сроков и стоимости, и существенных, да и несущественных условий контракта, лучше взять гибкий контракт (T&M — хороший пример) и начать работу, разибраясь в деталях по мере продвижения.
У заказчика обычно ограниченный бюджет, потому продать ему гибкий контракт намного сложней. В этом случае риски также уходят на заказчика, к чему заказчики готовы еще меньше.
Customer collaboration over contract negotiation — это хорошо для крупных американских корпоративных клиентов, где услуги поддержки/разработки проданы на год вперед, и дальше уже делаем максимально хорошо заказчику на выданный бюджет. В условиях же большинства проектов маленьких галер это только доставляет проблемы как заказчику, так и исполнителю
// не называйте место своей работы галерой. слава б-гу, сейчас нигде нет рабства, и вы вольны встать и уйти в любой момент.
«Внезапно» один из авторов Agile манифеста (Stephen J. Mellor), как раз в свое время специализировался на по embedded и realtime системах, и работал в том числе в CERN. А сейчас является CTO в Industrial Internet Consortium который был создан копаниями AT&T, Cisco, General Electric, IBM и Intel
«Внезапно» Но он же не придумывал Agile для embedded и real-time? Причем здесь его предыдущая специализация?
На стройке ходят в касках. Почему? Потому что этого требует техника безопасности.
Почему?
Что-то мне подсказывает, что для того, чтобы снизить травматичность на производстве.
Ещё и доказывать надо, что «лучше» — действительно лучше. С этим у меня всегда были проблемы, т.к. не особо красноречив и впадаю в ступор при необходимости объяснять очевидные вещи. При чём немалая часть людей всё понимает, но им просто всё равно или банально лень.
А потом, когда натыкаемся на очередные грабли и самое время сказать «а я же говорил!» и прочитать лекцию про технический долг — никто уже и не помнит как так получилось. Такие проблемы воспринимаются как данность, об их причинах никто не думает — некогда.
К сожалению, единственный способ решить эту проблему — качать софт-скилы. Чтобы писать хорошо код вполне можно обойтись техническими навыками, но вот объяснить коллеге почему код нужно писать именно так — это уже работа с людьми (и не смотрите что вроде он тоже программист, это не поможет), и она требует совсем других навыков, не технических. Хорошая новость в том, что софт-скилы всё-равно пригодятся, без них сложно стать действительно хорошим сеньором, и тем более тимлидом, архитектором или CTO.
Погодите, так это была не ирония? Я, наверное, по аджайлу быстренько прочитал вступление, и дальше думал, что вы так изящно троллите неповоротливых программистов.
Вот Мартин Фаулер про «Agile 2018», очень интересное выступление, где он обозначает текущие проблемы Agile, которые авторы оригинального agile манифеста «даже не представляли» (problems that we original manifesto authors didn't imagine) и ставит следующие цели:
1. Борьба с псевдо-agile (dealing with faux-agile)
2. Важность технической стороны (the lack of recognition of the importance of technical excellence)
3. Продуктовый, а не проектный подход (get rid of software projects and use a product-oriented view)
martinfowler.com/articles/agile-aus-2018.html
Вот Роберт Мартин и куча подписавшихся людей с Craftsmanship Manifesto:
1. Well-crafted software
2. Steadily adding value
3. A community of professionals
4. Productive partnerships
manifesto.softwarecraftsmanship.org
Это я к тому, что текущая статья не противоречит Agile :)
Краткие итоги обсуждения.
Два из трёх основных противников этого манифеста стали бы шантажировать увольнением инженера, который говорит, что работа не делается в тот срок, который спущен "сверху". Третий же, судя по комментариям, с ними солидарен.
… если Вы пришли в нашу компанию для того, чтобы получать два месяца зарплату за бесполезную деятельность по написанию кода, который никогда не будет запущен — пожалуйста, напишите заявление по собственному прямо сейчас...
powerman
Следующее действие — увольнение по инициативе работодателя и можете идти с этим в суд. :)
DexterHD
Что и требовалось доказать.
Сработает только если все люди одновременно перестанут воровать, будут крайне осуждать или да же серьезно наказывать вплоть до смерти, Потом вообще запретят об этом говорить, что бы искоренить само понятие и так же нарушивших выпиливать из общества. И уже тогда через несколько поколений воровства не будет.
Призыв делать качественно и продуманно в разрез быстро и как придется не несет ничего плохого. Утопичен, но порицать тут не за что.
Это то же будет работа, только другое отношение к ней.
Перепутал местами ссылки. Первая ведёт на вторую цитату, а вторая — на первую.
Два из трёх основных противников этого манифеста стали бы шантажировать увольнением инженера, который говорит, что работа не делается в тот срок, который спущен «сверху».
Наглая ложь и подмена понятий. Я нигде не утверждал, что я бы уволил кого-то из-за срыва сроков спущенных «сверху». Я лично на работе ни когда не говорю «Да», срокам спущенным сверху, если они противоречат моей экспертной оценке. При этом, мне это не мешает работать по Agile и сдавать продукт в срок. А вам мешает. Мы сразу бежите в трудовую инспекцию и проставлять минусы в комменты :D
Глупо обвинять меня во лжи, когда весь текст перед глазами.
Наглая ложь и подмена понятий. Я нигде не утверждал, что я бы уволил кого-то из-за срыва сроков спущенных «сверху». Я лично на работе ни когда не говорю «Да», срокам спущенным сверху, если они противоречат моей экспертной оценке. При этом, мне это не мешает работать по Agile и сдавать продукт в срок.
Полностью согласен, у меня ровно так же.
Я никогда не соглашаюсь писать говнокод, и редко когда соглашаюсь участвовать в разработке проекта, сроки которого не позволяют сделать его достаточно качественно (по моим личным меркам).
Но я не вижу ничего некорректного в том, чтобы наниматель, которому нужны такие проекты, поручил их не мне, а тем разработчикам, которые готовы делать то, что нужно нанимателю. Мне кажется странным принуждать нанимателя платить мне за то, что я буду делать не то, что ему нужно, а то, что я считаю правильным. Зачем создавать этот конфликт на пустом месте, если всем будет только лучше, если я просто уйду на тот проект, в котором потребности нанимателя и мои личные не содержат принципиальных противоречий?
Есть сайты, которые делают SEOшники — они в топе, но их нереально читать. Есть сайты, которые делают дизайнеры: они красивые, но не функциональные и на дне выдачи. И есть сайты которые делают программеры. Как правило, для программеров.
Если вы не спец с мировым уровнем разработки, то не стоит использовать данный манифест — лучше станьте отшельником или создайте общину, делающую проекты для себя.
Здесь крутятся одни из самых больших денежных объемов, которые не зависят от наличия природных ресурсов, влиятельных лоббистов в правительстве, даже границ государств.
Фармакология и еще с десяток направлений имеющих больший объем денежного оборота.
В целом — да, пока ты вспоминаешь где ширинка, другой уводит девушку к себе.
Все зависит от поставленных задач.
Твердо и уверенно можно вести только личные проекты, хотя основательного и логичного подхода не хватает.
Видел 2 конторы которые торопясь сами себя закопали: тут костыль, тут как быстрее, а не как лучше, и тут «времянка». А потом все это как снежный ком обрастает и в один момент разваливается.
И люди боролись за количество отработанных задач.
Каково вам например увидеть в коде запрос к базе из 5 связанных таблиц, но в котором тем не менее 2 десятка полей вызываются отдельным подзапросом?
А все потому что так добавить вывод поля мелким подзапросом занимает 5 минут, а построить запрос что бы учитывал необходимость добавления доп. полей и условий — 30 минут. Ну так что бы и логика прослеживалась, и связь, и ресурсов много не жрал.
В итоге, утрированно, 2 цифры в отчет выводятся 15 минут…
2. Не создают продукты те, кто над ними не работает
3. Работайте над продуктами
- Почему концепция важнее новых требований? Откуда это следует? Создавая систему, мы постоянно ставим эксперименты, которые влияют на концепцию. И что такое концепция вообще в вашем определении?
- Почему качество важнее скорости?
- Делать как надо? Это как именно? Полагаясь на что? На интуицию? На звезды? На физику параллельной вселенной?
- Почему наивысшим приоритетом для нас является плодотворная и продуктивная работа программиста? А как же пользователи с их проблемами? Программист работает для себя или для пользователей?
- Какой уровень качества необходим? Кто это решает? Как именно?
- Как быть начинающим разработчикам? Они еще не профессионалы, как им работать вообще?
- Что такое качественный продукт?
- Для какого софта можно разработать матмодель? Что такое матмодель для игры Packman? Что такое матмодель для движка Habr?
- Почему мы должны ориентироваться на каски строителей и хирургов?
- Что такое хороший техпроцесс?
- КОНТРОЛЬНЫЙ: Что такое качество?
Да и скорей это относиться к корпоративному ПО или крупным проектам.
Прототип стартапа хоть на коленке делай.
1. Потому что да же мелкие проекты должны иметь ТЗ. Если нет ТЗ — получается каша, и не видно конечной цели. Если проект чуть крупнее и есть сроки -то потом с тебя же и спросят почему проект не закончен, и попробуй объяснить что ты отклонялся от ТЗ из-за вдохновения Васи-Пети и их новых идей.
2. Узнаешь когда заведешь себе девушку. Может шутка грубовата.
Но суть в исключении ошибок по невнимательности и выбора неверных подходов, которые повлияют на стоимость дальнейшей разработки. Например отсутствие масштабируемости.
3. На технологии и нормы. Без костылей.
6. Тщательней готовится, читать документацию. Разбивать этапы разработки на подзадачи и изучать способы их реализаций.
9. Потому что это аналогия.
10. Когда предусмотрел всё или почти всё и любой этап от идеи до релиза идет по отлаженным рельсам. А сход с них — форс-мажор, а не правило.
В целом, если критично относиться к данной мысли изложенной автором, то 70% статей хабра можно удалять за ненадобностью, т.к. они как раз и расписывают как надо или как стоит делать, и как будет лучше/качественней/продуктивней/производительней.
А то получается на «говнокод» мы плюемся, а не плодить его отказываемся.
1. Даже с ТЗ подавляющее большинство проектов получается с задержками по времени, с большим количеством багов и с 0 пользой для клиентов. ТЗ не является ответом
2. У меня жена и двое детей. Иногда надо быстро, пока дети не проснулись.
3. Что такое норма? Что такое технология? Что такое костыль? Пожалуйста, эти абстрактные ответы оставляйте при себе. Нормы не существует.
9. Аналогии не всегда работают, не так ли?
10. Это бывает только никогда. Вернее, только при разработке очень простых и понятных система. Например, сайта для индивидуального предпринимателя Иванова.
Рекомендую начать углубляться в детали и понизить градус абстракции.
2. в вашем случае расценивайте «быстрее быстрого. Дети спали до утра, а вы закончили через 2 минуты.» Выбор неверных подходов, которые повлияют на стоимость дальнейшей разработки. — Позовите «тещу» посидеть с детьми.
3. Костыль — временное решение. Но ничего нет более постоянного чем временного. Я думаю все понимают что это, но на примере:
Это когда в 1С в отчетности ты в макете прописываешь подписантов, потому что надо вот сейчас, и забиваешь на реализацию механизма вывода подписантов из справочников ответственных лиц.
Нормы — это парадигмы в том же ООП, паттерны в проектировании. Понимание сущностей, явное объявление переменных и корректное комментирование кода, это все то же норма. Общепринятая практика устоявшаяся на многолетнем опыте.
9. Не всегда, но применимы в общих чертах и имеют место быть. Все зависит от подхода.
10. Если подобные процессы налажены то и сложные системы становятся простыми и понятными как сайт для ИП Иванова. Сейчас инструментов для ведения этих процессов предостаточно.
Насчёт качества это как с ездой на самолёте если вести правильно то избегает катастрофы, при погоне за скоростью перенагружаешь элементы и теряешь много ресурсов и качества.
Делать зависит от выбора способа решения этот манифест лишь создаёт набор рекомендаций для упрощения разработки и только указывать какие способы работы лучше выбрать.
На этапе выбора концепции создаётся основа решения проблемы и этот манифест принуждает к лучшему исследовании проблемы клиента путем переговоров про необходимость различных функций и для правильности подбирают концепцию для современного и качественного решения по принципу sancta simplicity, уберая фантазии клиента.
И как следствие при высокой эффективности разработки находиться правильное решение проблемы.
Разумеется нет идеального манифеста.
В связке с концепцией можно создать систему оценки качества и выполнения, и тогда учитываются особенности предметной области проекта.
Начинающие как и всегда будут по разному пытается применять разные методологии, эти манифесты подсказывают принципы разран при этом давая часть опыта для избежания проблем.
Качественный продукт -тот который определил клиент и команда, методология лишь указывает принцип того что работа должна быть выполнена правильно и качественно.
Матмодель позволяет без реализации проверить реальность работы ПО, то есть экономит время отладки, а также даёт ПО лучшую возможность анализа. Но в некоторых приложениях необходимо лишь сделать обычную UML модель и проанализировать матметодами (мое мнение весьма не компетентно)
Перегрузка лубого рабочего уменьшает его эффективность, а в результате увеличивает критическую цепь проекта.
Хороший техпроцесс это эффективность, качество и интуитивное понимание выполнения проекта, но тут интуитивное заменяется система оценивания
Качество определяется концепцией и эффективностью решения
Автор упускает довольно много важных деталей разработки ПО:
1 — высокую неопределенность
2 — психологию пользователей, которые редко знают, чего хотят
3 — сложность создания систем (особенно в группе, особенно в большой группе)
4 — невозможность формализации системы. ТЕМ БОЛЕЕ на уровне матмодели.
5 — экспериментальный характер процесса разработки.
Основная задача — увеличить скорость накопления знаний. Это следует делать увеличением количества экспериментов, ускорением экспериментов и постоянным взаимодействием с пользователями системы. Agile хотя бы делает к этому шаг, автор текущей статьи отпрыгивает назад шагов на 15
Но для того же хабра часть этой модели будет например расчет рейтинга комментариев и постов, условия привязки этих самых постов к авторам, проверки на валидность той же почты при регистрации. Количество постов в «Что обсуждают» и расчет периодов.
В отношении сайтов это редко, практически никогда не рассчитывают заранее. Хотя может предполагаемую нагрузку для выбора хостинга, объемы информации для выбора хранилища. Затраты, объемы рекламы. Может не точный, но приблизительный расчет ведется.
А Пакман… в геймдеве сплошь и рядом математические модели — баланс, подсчет очков, условия возникновения событий и т.д.
Если разбирать Аджаил принципы то там вполне себе кроется основательный подход на стадии проектирования, иначе никак.
Релиз ПО с ошибками — это не работающее ПО и там и там.
Пересмотр архитектуры под новые требования — это не отказ от внесения изменений.
Анализ, самоорганизация, минимизация лишней работы — все то же самое что у автора поста.
Только другими словами.
По-моему что-то такое уже давно было.
http://macode.ru/
На ум пришла одна аналогия, объясняющая как мне кажется, причины таких бурных споров. Вот возьмем большое производство. Там обязательно есть НИОКР (в том или ином виде), назовем его отделом «перспективных исследований», есть конвейер где монотонно согласно строгому ТЗ собирается из деталей готовый продукт, есть худо-бедно собственное производство таких деталей, где ТЗ меняются, редко но всеж меняются.
В отделе «перспективных и не очень» исследований большая свобода, есть время поизучать и поставить эксперименты.
В отделе производства деталей работают высококлассные токари и мастера инструментальщики, которые могут сами придумать (или технолог поможет) и изготовить оправку/приблуду для сборки изделия на конвейере, могут выточить нужные детали с точностью, большей чем можно купить у поставщика.
На конвейере… ну кароче обычные «галеры» этот конвейер.
Вот в случае с программированием, во всех этих отделах, работает как правило один и тот же человек. Отсюда такие разнополярные мнения и возникают.
Аббревиатура ФФФ означает fix time, fix budget, flex scope. Мы работаем с фиксированными сроками и бюджетом, а функциональность оставляем гибкой (по согласованию с заказчиком)
Из этой методологии выводятся другие две.
Fix time, fix scope, flex Budget
Fix Scope, Fix Budget, flex Time.
Это не новая методология, а частный выбор из стандартного треугольника проект-менеджмента
вполне возможно, что и автору статьи и некоторым другим пользователям может быть интересна и такая интерпретация, которая может подойти для частных случаев или простых проектов. а то мне кажется странным совет комрада DexterHD — прочитать по одной книге основных автором манифеста Agile — это большая трата ресурсов, а тут таки одна страничка и куча ответов на конкретные вопросы по работе с заказчиками.
наверное, мне самому это чтение было интересно в первую очередь потому, что тут есть понимание интересов бизнеса и идёт поиск новых (на то время) подходов, чтобы их учитывать — ход мыслей и логика описаны хорошо, возможно это поможет кому-то ещё разобраться в том зачем в принципе могут быть нужны всякие эджайлы.
дисклеймер: я сам не разработчик, а больше системный администратор, но и с разработчиками сталкиваюсь регулярно. то есть уровень про который со мной предметно можно разговаривать — это небольшие команды и проекты :)
К гадалке не ходи, отдел тестирования и пользователи всё так же будут выявлять ошибки. Программисты, работающие по сему манифесту, будут их вкладывать в мат. модель и исправлять, ну или корректировать мат. модель и исправлять. А служба поддержки всё так же будет еженедельно собирать готовые и оттестированые, на данный момент, исправления и отсылать пользователям.
1. Какие именно интересы одного круга лиц agile превозносит над интересами другого, да и о каких конкретно кругах тут идет речь?
2. Какие ваши права как программиста ущемляются agile-манифестом (и/или вытекающими из него методологиями)?
Чем дальше от сердца бизнеса тем более солидарны с идеей манифеста.
По ходу движения к руководителям начинается настоящая истерика, у некоторых полное отрицание.
Я бы согласился со второй группой людей но… Напоминает людей которые завели свой маленький бизнес на рекламе в интернете после чего стали апостолами удаления адблока из своей жизни и жизни других людей только потому что это им выгодно по их мнению.
Мое мнение что инженерный ум не совместим с продажным но «целое больше, чем сумма его частей» и те кто найдут компромис не потеряв себя как программиста, маркетолога и тд пойдут дальше в бизнесе основанном на технологическом продукте.
Выше по ветке читал обсуждение про ТК из которого могу сделать вывод что ситуация в РФ гораздо мягче к девелоперам. Если бы я на любой из своих работ попробовал подойти к начальству и потребовать выполнения манифеста именно такими словами, то меня бы уволили к херам за то, что порчу коллективу мир розовых поней. В смысле, за несоблюдение трудовой этики. Или для улучшения диверсити внутри команды. Или просто дали бы доработать год до истечения контракта после чего выяснилось бы что продлить его совершенно случайно не могут. В общем, способов бортануть борзого сотрудника тут гораздо больше чем с ТК РФ. Но это так, прискаска.
На первой работе, несмотря на декларируемый эджайл (практикам которого мы практически не следовали), работали мы практически по этому манифесту. Наша команда сперва пилила набор утилит для тестирования, потом перенесли это в один фреймворк, который кое-как внедрили на всей фирме, и под конец наш синьёр с менеджером загорались мыслью выпустить этакий универсальный фреймворк для совсем крутой автоматизации тестов в мире CI/CD с использованием всех лучших практик, что бы он стал этаким стандартом вроде Netflix OSS для облачных решений. И вот тут-то всё и стухло.
Я был студентом-разработчиком, который по меркам немецких уровней имеет даже более низкий ранг чем джуниор с улицы. Пока два синьёра то по-одиночке, то парно разрабатывали ключевые принципы своей платформы, писали и внедряли этажи в своем фундаменте да оборачивали всё в тесты, а менеджер генерировал доклады того «как всё будет», на меня повесили всё остальное, что было не так интересно главным программистам — поддержка старой версии фреймворка и попытка внедрения новых фич, которые нужны уже сейчас конкретным командам. Поскольку мне не особо доверяли трогать бэкенд, то новые фичи создавались системами костылей на фронтенде. Изредка мне доверяли написать какой-то прототип, посмотрев на который синьеры говорили: «отлично, только не так и неправильно, но всё равно спасибо, пойдем внедрять это у себя и теперь уже правильно». Как же именно правильно мне так и не показывали. Осознавая ненужность своей работы я сидел с жутким выгоранием и работал только последний день перед еженедельном митингом чтоб отчитаться «прикрутил костыль, на остальное нужно больше времени». Самое смешное, что по результату мой труд никак не отличался от труда опытных синьёров которые из раза в раз докладывали «по прежнему пишем тесты!». Пару раз в это пытался вмешаться старший менеджер поверх нашего, стараясь напомнить комманде что вообще-то мы должны прибыль фирме приносить и как же так, где результаты, на что старший программист просто отрезал что-то вроде «Качество!» с чем никто никак не мог спорить. Ирония в том, что это самое качество финального продукта, гарантировать которое и было изначальной задачей нашего отдела (и про которое под конец уже все забыли за проектированием своего внутреннего продукта), стало под конец сильно падать, что повлекло изменения внутри команды. Но это уже другая история, которая связана не только с нами.
А вот уйдя с прошлой работы я после долгих колебаний пошел в работать банк. Боялся, что тут будет нечего делать, что технологии старые, что я не смогу, как мечтал на прошлой работе, пилить распределенные облачные сервисы на самых новых языках программирования в самых современных фреймворках. В банке же почти весь первый месяц занимался тем, что получал права доступа к базам данных и слушал обязательные тренинги, на которых нам вдалбливали, что банк работал 200 лет до твоего рождения (большую часть — вообще без всяких компьютеров) и собирается проработать ещё столько же задолго после того как ты умрешь. Единственный смысл банка — приносить прибыль, и платить тебе твою зарплату — это непостредственный убыток, так что будь добр — отработай так, чтоб прибыли было больше чем расходов.
Работа идет по самым жестким agile методикам, но при этом я понимаю, что такой свободы на прошлой фирме у меня никогда не было. Ежедневные стендапы, работа исключительно на бизнес-клиентов, и еженедельные отчеты от стэйкхолдеров позволяют не потерять перспективу того, что и для кого ты делаешь. И при этом дает вполне себе защищенность от от неадекватных запросов на переделки — если ты можешь аргументированно объяснить что и почему могут ухудшить/поломать изменившиеся запросы, то требования завернут, так ещё и благодарность тебе выпишут за бдительность. В начале работы я сумел убедительно доказать, что именно и как мы можем улучшить, к моим словам прислушились и мне дали зеленый свет. Это и есть то самое качество во главе, которое задекларировал автор этого манифеста, которое мы вполне себе нормально получаем при agile методологии.
TL; DR: На своем опыте я убедился, что следование ценностям, задекларированным в этом манифесте не гарантирует ни качественных продуктов, ни адекватной рабочей атмосферы, если коллектив состоит из программистов разных уровней. К тому же он по определению дистанцирует и противопоставляет заказчиков/руководство программистам, что не способствует здоровой атмосфере. В то же время правильно поставленный agile решает, в том числе, и те проблемы, которыми был озабочен автор этого манифеста.
Ещё одна мысль. На прошлой работе в один момент старшие программисты заинтересовались прикрутить машинное обучение к одному из основных компонентов (fuzzy тестирование с production данными) своего фреймворка. Поскольку задача была слишком большой для обычного прототипа, мне её поручили сделать как бакалаврскую в университете. Для сбора данных мне потребовался тот самый компонент, а поскольку закрытый коммерческий код выносить с предприятия было нельзя, я, с разрешения работодателя, сделал свой open source аналог. Что бы повторить главную киллер-фичу фреймворка (над которым на тот момент работали уже почти год) мне потребовались сутки. Ещё пара дней ушла бы на то, чтоб переписать работу с сокетами на С — просто для скорости, и возможно потребовалась бы неделя чтоб прикрутить слив данных с распределенных инстанцев в одну базу что бы поддерживать параллелизирование. Таким образом за месяц я мог бы выкатить кривую и косую (я совершенно не обманываю себя о том, какого качества код я произвожу относительно опытных senior developer-ов), но рабочую версию, дающую тот же функционал, что и продукт, который разрабатывается уже полтора года но так ещё и не был никуда выпущен. Разумеется, я не собираюсь этого делать, но информация о фреймворке выкладывалась в открытую сеть в виде презентаций (которые я и пересказал тут, что бы гарантировать, что я не не ломать NDA) и если бы продукт представлял реальную выгоду — у потенциальных конкурентов было бы более чем достаточно времени что бы выпустить свою версию, захватить и поделить рынок, пока команда спецов делает всё «правильно».
Пойдёт.
> Качество важнее скорости
Надо развернуть, в чём измеряется качество и в чём скорость? Без внятных определений очередная философская херня натянутая на инженерную дисциплину.
> Делать как надо важнее, чем делать как просят
Как надо кому? Просят кто?
Программист — художник, созидатель, одиночка, самодостаточный профессионал.
Программисту не нужна шелуха, якоря и балласт в виде — общества, коллектива, помощников, коуч-тренеров, офисов.
Для программирования нет ни чего хуже — графиков работы, сроков, режимов, собраний, листочков на досках, пустых встреч, общения с заказчиком.
Идеальный заказчик — это: а) программист, б) внимательный к деталям и уравновешенный человек, личность в первую очередь (не пройдоха, хапуга, экономщик, быстро-быстро, стартапер и прочая требуха)
Программисты всех стран соединяйтесь!) и отстаивайте свои права на осмысленный труд и право на решение реальных, полезных обществу, задач. Мы должны прекратить бесконечное воплощение в жизнь «гениальных бизнес идей» эффективных менеджеров;)
У заказчика нет цели сделать качественный продукт, потому что затраты на качество — это увеличение издержек, ему нужно минимально возможное качество, при котором продукт купят максимальное количество раз. В идеале — продавать воздух, в реальности — что-то близкое к этому. Средство для достижения — исполнители, в первую очередь сейлзы.
У исполнителя иногда есть цель сделать качественный продукт (чисто экзистенциальная — не зря жизнь прожил, добавил в мир чего-то полезного, а не очередной трэш, ну или там закрыть другие психологические потребности), часто — заработать денег, почти всегда — не потерять деньги на выполнении лишней работы за свой счет. Качество кода — это в основном про последнюю цель.
Манифест жёсткого программиста