Я пока ни разу не повёлся на "тут проще с нуля переписать" :) Может зря? Но ты попробуй обоснуй бизнесу, почему половины команды надо увести на новый проект, который будет делать ровно то же, что и текущий но с другими багами и может быть быстрее))

Я пока ни разу не повёлся на "тут проще с нуля переписать" :) Может зря? Но ты попробуй обоснуй бизнесу, почему половины команды надо увести на новый проект, который будет делать ровно то же, что и текущий но с другими багами и может быть быстрее))

И правильно )

и правильно

Есть такие монолиты, которые вообще трогать нельзя

Особенно в мире PHP :)

Решение бизнес принимает )

Роберт Мартин в Clean Coder описал красочно. Бизнес не может принять решение что разработчику нужно поступать не профессионально.

если команда видит единственный выход - переписать, то это незрелая непрофессиональная команда

Ща мы тут сядем, подумаем и напишем с нуля все правильно и без багов )

Проходили, знаем ))

Так вы эксперты

Просто я думаю переписывать с нуля кроме тешить самолюбие разработчиков от нового проекта, ни к чему хорошему не приведёт. Ибо будут те же проблемы с багами первое время, потом может меньше, но все же. Плюс наверняка забудут кучу костылей)) И все будет раьоиат не так

И тут работает правило 20 / 80.

Роберт Мартин в Clean Coder описал красочно. Бизнес не может принять решение что разработчику нужно поступать не профессионально.

Дима не об этом. Решение писать или нет тесты действительно лежит на бизнесе, как это ни парадоксально. если бизнесу скорость важнее качества, то так тому и быть. если разработчик будет упираться и писать тесты, то он убъет бизнес

Просто я думаю переписывать с нуля кроме тешить самолюбие разработчиков от нового проекта, ни к чему хорошему не приведёт. Ибо будут те же проблемы с багами первое время, потом может меньше, но все же. Плюс наверняка забудут кучу костылей)) И все будет раьоиат не так

Да. В старой системе баги худо бедно известны

но если написание тестов обосновано с точки зрения бизнеса - тогда ответственность команды за ними следить, холить, лелеять

Воркараунды есть

Мы в одной компании делали проект типа версия 2.0, но там был проект с нуля такой же, но пару принципиально новых бизнес вещей, пожтому бизнес дал добро

Результат - один хрен, все тоже самое, зато код красивый и архитектура радуется ) не стыдно показать

;))

Дима не об этом. Решение писать или нет тесты действительно лежит на бизнесе, как это ни парадоксально. если бизнесу скорость важнее качества, то так тому и быть. если разработчик будет упираться и писать тесты, то он убъет бизнес

У Дяди Боба достаточно экстремальная позиция. Код находится под ответственностью разработчика и ему решать как его писать. Бизнес может убеждать, но решение должно быть за разработчиком.

я тоже так раньше думал :)

А как же самоорганизация? Доверие? Одна же команда. Бизнесу нужно получить ценность, пусть мы, как команда, сами решим как будем писать код, а не закреплять это решение жёстко в процессе.

не поверишь, но даже самоорганизация команды - это выбор бизнеса :) некоторым видам бизнеса самоорганизация не только не полезна, а даже вредна

если бизнес таков, что самоорганизующаяся команда приносит ему пользу, то скорее всего и от тестов тоже будет польза. хотя не всегда, это все-таки независимые друг от друга критерии качества

не поверишь, но даже самоорганизация команды - это выбор бизнеса :) некоторым видам бизнеса самоорганизация не только не полезна, а даже вредна

Верю, даже согласен полностью) Но если мы говорим о профессионалах, то не нужно за них решать как им делать свою работу.

В каких видах бизнеса самоорганизация вредна? Я думал, это больше от процесса зависит, а не от вида бизнеса :)

а процесс от чего зависит?

не уверен, что от вида бизнеса

скорее, от опыта и знаний руководства

Процесс зависит от бизнеса ещё как

если бизнес в зоне Simple cynefin-модели например, то зачем тебе самоорганизация?

Как мы зарабатываем деньги ? Аутсорс или стартап

Или продукт сорсинг

Какие требования к команде?

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

Ещё как процесс зависит от бизнес модели

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

или у тебя сложный домен, который постоянно меняется

ок, даже если взять клон, хотя пример KupiVIP и подобных не очень релевантен. Если этот клон планирует конкурировать с "оригиналом", то конкуренция может быть в том числе и за счет команды, и здесь появляется самоорганизация

не будет он конкурировать. оргинал в США, мы в России

я же говорю - simple модель

в России у KupiVIP могут появиться свои конкуренты-клоны

ты пытаешься вытолкнуть меня из simple в complicated а я туда не хочу )))

когда появятся тогда дело другое

и вот если ты понимаешь что могут появиться другие, то кто первый тот и захватил рынок

проблема, что когда появится, может уже не хватить времени на перестройку :) Можно банальный пример с презентацией Netflix про культуру вспомнить

и если тебе программисты будут рассказывать что тесты это прекрасно, но это будет нам стоить +2 недели, то что ты сделаешь?

опять другой бизнес, не катит..

если для тебя критически важно выпуститься на 2 недели раньше конкурента, ты забьешь на все

потом перепишем с нуля

главное выйти раньше

И отжать рынок

Можно ли сделать самоорагнищующаяся команду из демотвивираонных и уставших разработчиков? Можно ли сделать самоорагнизующаяся команду в бизнесе где нет процессов и хаос такой, что задачи сыпятся как из рога изобилия ибо бизнес каждый день меняется и реорганизуется? (Кстати, а близко ли это к аджайл подходу?)

если для тебя критически важно выпуститься на 2 недели раньше конкурента, ты забьешь на все

а вот можно ли выпуститься за 2 недели и обогнать конкурентов без самоорганизации в команде за счет вотерфолла и жесткого спуска решений сверху? Имхо, будет сильно сложнее

можно

если решение simple, то waterfall быстрее

и эффективнее

И отжать рынок

Тогда mvp быстро кодишь на быстром фреймворке, зачем самоорганизация, достаточно норм постановка задачи с ключевыми моментами и выбранная верная технология

Тогда mvp быстро кодишь на быстром фреймворке, зачем самоорганизация, достаточно норм постановка задачи с ключевыми моментами и выбранная верная технология

Ога

И к тому же требования к команде ниже

Один крутой лид

угадай с чего alisteir cockburn (один из авторов agile manifesto) начинает свой тренинг Advanced Agile? с вопроса “why waterfall is more efficient than agile?”

как раз по этой причине?

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

угадай с чего alisteir cockburn (один из авторов agile manifesto) начинает свой тренинг Advanced Agile? с вопроса “why waterfall is more efficient than agile?”

Интересно начал, аж интересно

угадай с чего alisteir cockburn (один из авторов agile manifesto) начинает свой тренинг Advanced Agile? с вопроса “why waterfall is more efficient than agile?”

Заинтриговал

Может еще чего припомнишь такого парадоксального от больших людей в Agile?

и аудитория набрасывает на флипчарт примеров, почему это так. естественно следом идет второй вопрос - why agile is more efficien than waterfall? ))

иными словами, нет черного и белого. нет универсального работающего решения.

А потом он говорит, что видите какая фигня подумайте над этим и уходит?))

есть разные способы, лучше или хуже подходящие под решение той или иной задачи

не, не так немного ))

Так то да, но водопад наверное все же устарел, тут скорее идет речь про всякие rup и mfp?

То есть еще не аджайл, но довольно строгие методологии

https://twitter.com/totheralistair/status/441399407976513537

пример

refactoring. Nice :)

а, это продолжение карточки там

https://twitter.com/totheralistair/status/443162888505540608

Прибыль это не функция от tdd и самоорганизации