Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 27
Статья напоминает мысли капитана очевидности.
Особенно это:
Особенно это:
Мы решили поиграться с новыми технологиями, в которых у нас было мало экспертизы. Нам их порекомендовали. Конечно нам хотелось набраться опыта. Сейчас я думаю, что лучше бы использовал только те технологии, в которых у меня есть опыт.
На старте автор и его кантора решили, что на этом свете чудеса бывают? Неа, чудес не бывает. И не будет. Никогда не будет. Пишите как положено — тогда заработает. Иначе никак.
И это вам еще повезло, что вы хотя бы что-то написали в итоге, что хотя бы как-то работает. На самом деле, если копнуть поглубже — то у вас и половина написанного не работает, и громко падает при сильно громком чихе. Да, именно так.
И самая главная проблема — на старте у вас архитектора не было. А без него — ничего хорошего никогда не будет. То что у вас в итоге абстракции свелись хотя бы как-то, причем далеко от оптимального — это уже чудо…
И это вам еще повезло, что вы хотя бы что-то написали в итоге, что хотя бы как-то работает. На самом деле, если копнуть поглубже — то у вас и половина написанного не работает, и громко падает при сильно громком чихе. Да, именно так.
И самая главная проблема — на старте у вас архитектора не было. А без него — ничего хорошего никогда не будет. То что у вас в итоге абстракции свелись хотя бы как-то, причем далеко от оптимального — это уже чудо…
А такие сферические кони бывают вообще? Что бы изначально многолетний проект сразу спроектировать так, что бы через год ничего не рефакторить? И при этом ТЗ было бы такое, что всё прописано, через год ничего не меняется, заказчик чётко понимает что ему надо, а исполнитель — как этого достигнуть. Имхо такое в стране эльфов только бывает.
Конечно бывают. Про них даже все знают, и вы в том числе. Примеров тому масса. Посмотрите на тот же фреймворк от майкрософта. Неужели вы и вправду думаете, что его кинулись программировать, т.е. раздали задачи и т.д. до того как собрали вменяемую архитектуру? Вы что, правда думаете, что 3000 типов можно скрутить в кучу без предварительного проектирования?) Ну тогда майкрософт и прочие проживают в стране эльфов, не иначе… Ну ладно майкрософт, у них деньги скажете вы) И что с того? А те проекты, которые проектируются максимум десятком человек, и этих проектов действительно много уже — эти тоже имеют финанс как у майкрософта?) Так почему у них все получается в итоге? Может потому, что как раз таки люди изначально понимают что делают, и на чем они это делают, и с привлечением чего? Так такое возможно тогда и только тогда, когда изначально проектируется архитектура, а уже затем по клаве долбят, нет?
Я с фреймворком начал работать, когда он был в стадии 1.0-beta. Сравните его с текущим .net Core, да и хоть 4.7.2. С тех пор было несколько итераций рефакторинга, причём кардинального, ибо первые версии были спроектированы далеко не идеально, плюс требования менялись во времени.
Но и вообще мой поинт не о продуктах для программеров, а о продуктах для конкретных «реальных» заказчиков. Там чудес с начальным проектированием ещё меньше. Редко, когда заказчик сам понимает, что конкретно ему надо. А при неспособности написать грамотное ТЗ, о каком мегаархитекторе, который заранее всё учтёт вообще говорить можно…
Но и вообще мой поинт не о продуктах для программеров, а о продуктах для конкретных «реальных» заказчиков. Там чудес с начальным проектированием ещё меньше. Редко, когда заказчик сам понимает, что конкретно ему надо. А при неспособности написать грамотное ТЗ, о каком мегаархитекторе, который заранее всё учтёт вообще говорить можно…
Сравните его с текущим .net Core, да и хоть 4.7.2. С тех пор было несколько итераций рефакторинга, причём кардинального, ибо первые версии были спроектированы далеко не идеально, плюс требования менялись во времени.Да ничего подобного) Абстракции в общем и целом не изменились. Реализация абстракций конечно поменялась, но реализация абстракций каким образом касается архитектуры?
Но и вообще мой поинт не о продуктах для программеров, а о продуктах для конкретных «реальных» заказчиков.Вы ПО делите на реальное и не реальное? Как это? Фреймворк писался для программистов, и в данном случае заказчики — это программисты. Нет?
Редко, когда заказчик сам понимает, что конкретно ему надо.Такого вообще не бывает. Вы что же, подскажете майкрософту что «вставить» в будущий фреймворк?) И слава тебе хоспаде не подскажете, ибо ну его нафиг, пусть этим вменяемые занимаются, это если по мне.
Но и вообще мой поинт не о продуктах для программеров, а о продуктах для конкретных «реальных» заказчиков. Там чудес с начальным проектированием ещё меньше.А значит и абстракций меньше) Но и эти в общем-то банальные 50 абстракций и 10 базовых типов вы не в состоянии разрулить.
А при неспособности написать грамотное ТЗ, о каком мегаархитекторе, который заранее всё учтёт вообще говорить можно…А вот про это говорилось уже давным давно) Если человек не способен даже «на бумашке» изложить мысли — так это вообще путь вникуда.
Редко, когда заказчик сам понимает, что конкретно ему надо.Так спросите конкретней что заказчику нужно. А как иначе-то? Или снова чудо? Угадывать будете что ему нужно? Ну угадывайте.
Ну и суммарно — что вы написали — не совсем понятно) Ибо что бы вы не писали — суть не изменится. Без вменяемого архитектора никогда ничего не получится. Во всяком случае я таких прецедентов ни разу не видел, что бы на коленке открывшы ВС хоп и скрутили вмиг штук пятьдесят абстракций походя, причем в итоге что бы получилось интуитивно просто и понятно для всех. Вот ни разу не видел.
пс: В некотором смысле первые версии фреймворка и есть МВП. Но даже в МВП архитектура была продумана настолько хорошо, что переписывать с нуля ничего не пришлось.
Вы поработайте ближе к «реальной экономике». Где IT — это не тёплый офис с хипстерами, которые фреймворки пишут, а где программисты — лишь отдел, автоматизирующий реальный бизнес, зарабатывающий деньги на офлайне. Много нового для себя откроете. И про заказчика, с которым достаточно «поговорить», что бы выяснить требования, и про то, что заказчик думает про зажравшихся программистов со всеми их абстракциями и фреймворками.
Да прекрасно работаю, не переживайте) Не так уж и давно делали проектик для такси. Так вот так называемые умельцы «реальной экономики» ничего толком для канторы и сделать не могли. Все падало, глючило и вообще выглядело как кусок гавна))) Более того, каждый кто принимался писать «следующую» версию сей «шыдевры» — просто отбрасывал все написанное и писал с нуля, представляете? Впрочем я такое вижу почти каждый месяц вообще-то… Так вот, когда было дано вменяемое объяснение, что это дорого, что пишется оно очень долго, что просто так на коленке ничего никогда не получится, и когда все это и то что написано выше было объяснено человеку, и человек был поставлен перед выбором — или парься дальше с гавниной и имей прямые убытки, или все же потрать время и получи дорогой и вменяемый продукт — человек проникся и встал на светлую сторону) Собсна ему и было сделано в итоге все как надо, десять лет назад еще… И до сих пор и далее оно будет работать и проблем с этим не будет вообще, ибо проблемам неоткуда браться. Писалось оно долго, это да, примерно насколько помню чуть более полугода. И что?) У человека выбор что ли есть? Нету.
А вы дальше «обслуживайте» придурков, это уже ваш выбор) Вы же готовы стелиться под любого, кто имеет самые мизерные бабки, не так ли? Ну как неразборчивая шлюха при дороге) Только ни вам, ни клиенту это ничего не даст. И смысл тут в том, что клиенту это ничего не даст — это совсем не беда, а вот то что это вам в итоге ничего не дает — это конкретная беда, но вы к сожалению этого не понимаете. Так и будете хреначить пурген абсолютно никому не нужный и смысла не имеющий) Впрочем это ваш выбор же. После ваших поделок все равно придем мы, и абсолютно неспешно под кофеёк в хипстерском офисе сделаем все по-человечески)))
А вы дальше «обслуживайте» придурков, это уже ваш выбор) Вы же готовы стелиться под любого, кто имеет самые мизерные бабки, не так ли? Ну как неразборчивая шлюха при дороге) Только ни вам, ни клиенту это ничего не даст. И смысл тут в том, что клиенту это ничего не даст — это совсем не беда, а вот то что это вам в итоге ничего не дает — это конкретная беда, но вы к сожалению этого не понимаете. Так и будете хреначить пурген абсолютно никому не нужный и смысла не имеющий) Впрочем это ваш выбор же. После ваших поделок все равно придем мы, и абсолютно неспешно под кофеёк в хипстерском офисе сделаем все по-человечески)))
Что бы на React написать приложение которое тяжело поддерживать это еще нужно постараться.
Вы что набирали людей которые вообще в Reactе не разбираются?
Вы что набирали людей которые вообще в Reactе не разбираются?
Из статьи видно, что все их проблемы идут на уровне глубже реакта.
да легко, такие же «профессионалы» без архитектора нам на реакте написали, реакт никак не помогает ограничить действия разработчиков тем он и плох, как хочешь так и пишешь, а «best practice» работают только на низком уровне, глобально всё равно нужен архитектор, который продумает общую картину, а не только отдельные кусочки
Вы многое сделали хорошо (хотя думаете иначе), но наступили на достаточное кол-во граблей.
Если коммент наберет достаточное количество плюсов, то отвечу статей. Если нет, то комментарием дальше.
Если коммент наберет достаточное количество плюсов, то отвечу статей. Если нет, то комментарием дальше.
Не интересно, значит проще без статьи.
Это не первая ошибка. Зачастую это именно верное решение.
Да, нужно понимать, что заранее на будущее нужно заложить время и средства на рефакторинг. Это нормально.
Если бы сразу пилили правильную хорошую надежную инфраструктуру с архитектурой, то ушло бы примерно столько же времени и средств. Почему столько же, а не меньше? Потому что вы еще толком не знаете что конкретно вам потребуется, но заранее будете пилить преждевременную оптимизацию и экономию на спичках.
Ну и вишенкой на торте в данном вопросе — пока вы пилите все сразу правильно, кто-то напишет это быстро и начнет зарабатывать. А потом он наймет вас для того, чтобы все сделать хорошо.
На самом старте это будет гадание на кофейной гуще. Да, нужно помнить об этом, но не следует прямо усердно закладывать в архитектуру — через год у заказчика легко могут поменяться планы.
Да, это не самое лучшее решение. Но вполне жизнеспособное. Кроме того, если бы вы послали архитектора без нужного опыта быстрого старта, то вполне себе вероятно могли бы закопаться в реализации ненужных фич.
Можно, но нужно найти верный сбалансированный темп, а не упарываться на максимальную скорость.
В корне неверно. Agile не про это. Легко может все поменяться и это так же нормально. И да, даже в таком случае можно ритм поддерживать бесконечно.
А чем MVP отличается от продукта? Эта фраза не совсем понятна.
Не принципиально. Хоть удаленный, хоть за соседним столом. Вы сами дальше дали ответ что нудно было ограничивать дизайнера.
Нет. Обычно бывает, что лидер у фронта или фронт в прошлом, или фуллстек.
Тут вы напоролись на добротные такие грабли.
Либо одного фуллстека. А с заказчиком лучше говорить ПМ'у, а не тимлиду.
Обычно это происходит когда все или большинство участников, особенно тимлид, раньше были фрилансерами без опыта командной работы.
А вот это, в отличии от удаленного дизайнера, очень и очень большая ошибка.
Думаю вы уже поняли, что его у вас не было. Вот он как раз и может на удаленке в своем мирке запилить вообще что-то потустороннее.
Самый дорогой != подходящий. Нужно нанимать с подходящим опытом.
Верный вывод. Играть с новыми технологиями нужно тогда, когда есть время, деньги и потребность.
Да, обучение — это так же потребность.
Просто дробите до состояния «это я точно успею за 4 часа» и без зарывания с технические подробности.
Если вас много, то без Scrum on Scrum и подобных техник уже не обойтись.
Можно в самом начале не писать много тестов. Главное научиться писать правильные тесты в минимальном количестве — хотя бы с этого начать.
Я очень часто встречаю людей, которые умеют писать тесты и пишут их, но сами тесты особого профита не дают.
Требуется соблюдать баланс. Берите на спринты задачи из типов: фича, баг, рефакторинг и «ну это надо когда-нибудь сделать».
Задачи последнего типа будут первым делом выкидываться из спринта, если вам прилетит что-то срочное. А если не прилетит, то вы наконец-то это сделаете.
То вам не нужны такие разработчики.
То проверьте, что у вас действительно есть архитектор.
И здесь кроется первая ошибка обошедшаяся в приличную сумму для нашего заказчика. Она звучит так: быстро запилить MVP.
Это не первая ошибка. Зачастую это именно верное решение.
Да, нужно понимать, что заранее на будущее нужно заложить время и средства на рефакторинг. Это нормально.
Если бы сразу пилили правильную хорошую надежную инфраструктуру с архитектурой, то ушло бы примерно столько же времени и средств. Почему столько же, а не меньше? Потому что вы еще толком не знаете что конкретно вам потребуется, но заранее будете пилить преждевременную оптимизацию и экономию на спичках.
Ну и вишенкой на торте в данном вопросе — пока вы пилите все сразу правильно, кто-то напишет это быстро и начнет зарабатывать. А потом он наймет вас для того, чтобы все сделать хорошо.
Оглядываясь назад я с уверенностью могу сказать, что первым делом нужно было взять в рассчет весь функционал который заказчик хотел увидеть в конечном итоге через несколько лет.
На самом старте это будет гадание на кофейной гуще. Да, нужно помнить об этом, но не следует прямо усердно закладывать в архитектуру — через год у заказчика легко могут поменяться планы.
Для того чтобы выиграть тендер наша компания послала разработчиков не имевших опыт в проектировании крупных приложений и надежных расширяемых систем.
Да, это не самое лучшее решение. Но вполне жизнеспособное. Кроме того, если бы вы послали архитектора без нужного опыта быстрого старта, то вполне себе вероятно могли бы закопаться в реализации ненужных фич.
Невозможно поддерживать постоянный темп разработки без увеличения ресурсов команды.
Можно, но нужно найти верный сбалансированный темп, а не упарываться на максимальную скорость.
Принцип Agile «Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно» работает только в случае, если с самого начала были известны и проработаны требования, весь набор функционала, спроектирована надежная и расширяемая архитектура (одним словом, если каждый класс продумывался с учетом конечной функциональности системы) и четко поставлены процессы.
В корне неверно. Agile не про это. Легко может все поменяться и это так же нормально. И да, даже в таком случае можно ритм поддерживать бесконечно.
И это надо было делать в MPV прежде чем пилить продукт.
А чем MVP отличается от продукта? Эта фраза не совсем понятна.
В нашей команде единственный дизайнер был удаленным сотрудником. Это была серьезная ошибка. Удаленный сотрудник всегда живет своей жизнью.
Не принципиально. Хоть удаленный, хоть за соседним столом. Вы сами дальше дали ответ что нудно было ограничивать дизайнера.
А значит лидер у Front End команды должен быть Front End разработчком в прошлом, а не Back End как это бывает всегда.
Нет. Обычно бывает, что лидер у фронта или фронт в прошлом, или фуллстек.
Тут вы напоролись на добротные такие грабли.
Agile должна содержать компетентного лидера по каджому из направлений ее работы (FE, BE). Эти лидеры должны обладать сильными Soft скиллами чтобы донести до заказчика то, что я пытаюсь описать в этой статье. А это очень и очень не просто.
Либо одного фуллстека. А с заказчиком лучше говорить ПМ'у, а не тимлиду.
Когда мы вышли в первый релиз мы поняли что у нас постоянно что-то ломается в самый последный день перед демо.
Обычно это происходит когда все или большинство участников, особенно тимлид, раньше были фрилансерами без опыта командной работы.
У нас был удаленный архитектор.
А вот это, в отличии от удаленного дизайнера, очень и очень большая ошибка.
Думаю вы уже поняли, что его у вас не было. Вот он как раз и может на удаленке в своем мирке запилить вообще что-то потустороннее.
Мы решили что больше мидлов и меньше синьоров выгоднее для проекта. Сейчас мы думаем иначе. Если у вас маленький бюджет, вам необходимо нанимать самых дорогих специалистов.
Самый дорогой != подходящий. Нужно нанимать с подходящим опытом.
Мы решили поиграться с новыми технологиями, в которых у нас было мало экспертизы. Нам их порекомендовали. Конечно нам хотелось набраться опыта. Сейчас я думаю, что лучше бы использовал только те технологии, в которых у меня есть опыт.
Верный вывод. Играть с новыми технологиями нужно тогда, когда есть время, деньги и потребность.
Да, обучение — это так же потребность.
Наши эстимации проходили изнурительно и переходили в нудную техническую полемику как ни крути. Эффективность митингов была минимальной.
Просто дробите до состояния «это я точно успею за 4 часа» и без зарывания с технические подробности.
За что я уважаю нашего PO, так это за то что он решил разделить ее на много мелких и выделить в каждой из них своего мини PO.
Если вас много, то без Scrum on Scrum и подобных техник уже не обойтись.
С самого начала у нас не было времени чтобы писать тесты. Через пол года мы пришли к тому что их все-таки нужно было писать.
Можно в самом начале не писать много тестов. Главное научиться писать правильные тесты в минимальном количестве — хотя бы с этого начать.
Я очень часто встречаю людей, которые умеют писать тесты и пишут их, но сами тесты особого профита не дают.
Не копить технический долг — это утопия. Он всегда будет.
Требуется соблюдать баланс. Берите на спринты задачи из типов: фича, баг, рефакторинг и «ну это надо когда-нибудь сделать».
Задачи последнего типа будут первым делом выкидываться из спринта, если вам прилетит что-то срочное. А если не прилетит, то вы наконец-то это сделаете.
Если ваши разработчики непонимают зачем на FrontEnd нужно знание ООП, то ваш код вряд ли можно будет поддерживать.
То вам не нужны такие разработчики.
Если у вас есть архитектор, скорее всего вам нужен еще один.
То проверьте, что у вас действительно есть архитектор.
Ничего страшного. Со временем придет понимание как «Как не слить освоить 10 миллионов бюджета вашего заказчика играясь с Agile». Это — вершина мастерства.
При чем здесь agile и реакт? Любой проект можно зафакапить с любыми методологиями и технологиями.
Ну, в данном случае, кмк Agile это просто заклинание, которое даже не использовали в соответствии с теорией итерационных моделей. Там, как минимум, подразумевается компетентность всех участников+проектирование от общей концепции к частностям+тестирование. Додуматься до проектирования некоего прототипа в начале, реализовать детали, не тестировать это, а потом обдумывать, верно ли мы выбрали направление — ну это что угодно, но не Agile.
Ну, если только рассматривать это слово как синоним анархии.
Ну, если только рассматривать это слово как синоним анархии.
С чего вы взяли, что MVP предполагает создание первой версии продукта из говна и палок? Это было одной из ключевых ошибок. MVP это не прототип, а полноценное архитектурно сформулированное решение но с минимальным функционалом.
Очень поддерживаю. MVP — это вертикальный срез с абсолютным минимумом фич. Внутренне он при этом должен быть такой, чтоб в дальнейшем вырасти до поддержки всех фич без костылей и подпорок. Если внутренне MVP такой, что «лишь бы демо работало» — это не MVP. Это демо-обманка для заказчика.
Не соглашусь с вами, mvp это минимально жизнеспособный Продукт, вы продуктом называете только написанный вами код, но чаще всего код сам по себе никому не нужен, а нужна ценность. Например, вы хотите зарабатывать деньги на сайте с хорошим уникальным контентом, и для mvp вы просто выберете сайт на wordpress, а когда вы поймете что это то чем стоит дальше заниматься, то перепишете всё на какой-нибудь современный и модный язык. Когда-то давно сайт «Цукерберг позвонит» был на wordpress, и ничего, переписали же. Но это если вы не знаете выстрелит ли идея или нет. Есть иная ситуация, когда у вас есть какой-то бизнес, например вы продаете что-то, и вам нужен свой интернет магазин, и понимаете что у вас он будет так или иначе и есть запас по времени и бюджету, тогда можно себе позволить сделать mvp с твердой основой, именно срезом по функциям и показать какой-то начальный функционал. Вообще ни в той ни в другой ситуации вы не застрахованы от того чтобы выбросить mvp и воспользоваться готовым решением или вообще сменить направление бизнеса.
а нужна ценность
Это именно то, что вкладывается в «абсолютный минимум фич». Минимум — такой объем, при котором проявляется ценность продукта.
Например, вы хотите зарабатывать деньги на сайте с хорошим уникальным контентом, и для mvp вы просто выберете сайт на wordpress, а когда вы поймете что это то чем стоит дальше заниматься, то перепишете всё на какой-нибудь современный и модный язык.
Как это противоречит тому, что написал я?
Если в архитектуру заранее заложено «вордпресс — временный выбор», то всё в порядке. Например, вы не будете делать действий, которые вас слишком сильно привяжут конкретно к вордпрессу.
Прошу прощения, но у вас не scrum команда, и никаких лидов со знанием бекенда и фронтенда вам не нужно, есть лид команды (который team lead) иногда ему можно вообще не разбираться в коде, если умеет думать, а есть ведущий технический специалист, который разбирается лучше всех в каком-то своем направлении (или по всем направлениям, что встречается не так редко), не нужно путать этих двоих, т.к. первый обычно отправляет вас ко второму в случае вопросов. Это то что касается команды, а вот на счёт процессов то если вам как лиду приходится разбираться с планированием ресурсов, то ваш ПО не тянет, в скрам командах не нужны лиды, и менеджеры тоже не нужны, когда они появляются значит вы пытаетесь прикрыть какую-то проблему.
По поводу мвп полностью вас поддерживаю, у такого проекта одна цель (в вашем случае это концепт для получения тендера) а следующая цель уже другая, а именно главная задача которую решает ваш проект. Если это какой-то небольшой или статичный проект, то мвп может иметь продолжение, например система инвентаризации в небольшом офисе, как мвп использовали Гугл таблицы + qr коды, а дальше просто добавили все необходимое и этого было достаточно, т.е. у проекта не появилось кучу требований в процессе. А если проект динамичный и ещё не всё понятно как будет, тогда вам в помощь agile (и лучше закажите тренера) и мвп скорее всего придется выбросить, т.к. у этих двух проектов разная цель.
Проблемы которые вы описали очень типичные (приблизительно 2/3 ИТ проектов проваливаются), и должны решаться командой, а не одним человеком.
Кстати технический долг можно исправлять либо сразу весь либо постепенно, мне нравится второй вариант, т.к. это происходит более контролированно. И скрам в этом отлично помогает, особенно если ваш ПО знает что от него требуется.
Всяческих успехов вам в нашей нелегкой профессии ;)
По поводу мвп полностью вас поддерживаю, у такого проекта одна цель (в вашем случае это концепт для получения тендера) а следующая цель уже другая, а именно главная задача которую решает ваш проект. Если это какой-то небольшой или статичный проект, то мвп может иметь продолжение, например система инвентаризации в небольшом офисе, как мвп использовали Гугл таблицы + qr коды, а дальше просто добавили все необходимое и этого было достаточно, т.е. у проекта не появилось кучу требований в процессе. А если проект динамичный и ещё не всё понятно как будет, тогда вам в помощь agile (и лучше закажите тренера) и мвп скорее всего придется выбросить, т.к. у этих двух проектов разная цель.
Проблемы которые вы описали очень типичные (приблизительно 2/3 ИТ проектов проваливаются), и должны решаться командой, а не одним человеком.
Кстати технический долг можно исправлять либо сразу весь либо постепенно, мне нравится второй вариант, т.к. это происходит более контролированно. И скрам в этом отлично помогает, особенно если ваш ПО знает что от него требуется.
Всяческих успехов вам в нашей нелегкой профессии ;)
Хорошо, что ошибки написали, а вот выводы, мне кажется, не очень получились взвешенные, может стоило после отпуска.
MVP — прототип или не прототип, бывает по-разному, на очень больших или очень непонятных проектах я бы сказал что вполне может быть прототипом, который на выброс на 80-90%.
MVP`ить можно и вотерфоллом, кидать все камни в огород Agile не надо.
По-моему основная проблема кроется в том, что проект некому было грамотно вести, не хватило пары опытных людей чтобы вытянуть.
Не понравилось про смену проекта после MVP, наоборот же, кому лучше продолжать как не тому, кто этот MVP делал, он как раз набил все шишки, новому человеку надо будет вникать заново с рисками переписать MVP, а не написать базу для уже рабочего продукта, наверное, наболело, но встречал я людей любящих делать MVP и убегать, неприятно с ними.
MVP — прототип или не прототип, бывает по-разному, на очень больших или очень непонятных проектах я бы сказал что вполне может быть прототипом, который на выброс на 80-90%.
MVP`ить можно и вотерфоллом, кидать все камни в огород Agile не надо.
По-моему основная проблема кроется в том, что проект некому было грамотно вести, не хватило пары опытных людей чтобы вытянуть.
Не понравилось про смену проекта после MVP, наоборот же, кому лучше продолжать как не тому, кто этот MVP делал, он как раз набил все шишки, новому человеку надо будет вникать заново с рисками переписать MVP, а не написать базу для уже рабочего продукта, наверное, наболело, но встречал я людей любящих делать MVP и убегать, неприятно с ними.
Нет отрицательного результата, есть обратная связь!
Так что у вас есть опыт. :-)
Так что у вас есть опыт. :-)
Хорошая статья, прямо светлое пятно бесценного собственного негативного опыта на фоне переводных новостей и рекламных постов.
Моё мнение о причинах и как этого избежать:
- MVP лучше назвать прототипом и выкинуть сразу после получения контракта. Для ускорения процесса и устранения желания сэкономить, взяв прототип в основу проекта, лучше писать прототип на отдельном языке и технологии для быстрой разработки. рельсах, ангуляре, реакт+js тяп-ляп без стора.
- толпа миддлов должна компенсироваться активным архитектором и жестко поставленным процессом разработки. Включая ревью всех коммитов, автоформаттеры, требования к коду и тестам и т.п.
- Команда не должна пермаментно делать больше функционала, чем она может делать, иначе качество кода закономерно падает. Защищать команду от заказчиков — обязанность тимлида с PM, похоже, они не справились.
Выдохните и наберитесь эмоционального интеллекта. Может вы станете лучшим разработчиком MVP когда сделаете рациональные выводы. И поймёте важность выбора всего от заказчика, до членов команды, инструментов и системы взаимодействия. Затем посмотрите на проект со стороны и подумаете насколько важно спроектировать MVP и конечную цель, создать пошаговый план и адекватное ТЗ и будете следовать ему.
Это как первый блин на сковородке- представьте если бы все люди в мире сдавались перед его величием. Успехов
Это как первый блин на сковородке- представьте если бы все люди в мире сдавались перед его величием. Успехов
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как не слить 10 миллионов бюджета вашего заказчика, играясь с Agile