А вот от менеджера это всё и зависит. Если его нет и вы самоорганизовались — это круто. А если есть менеджер, который не может ничего организовать, но усердно пытается — то провал близок. =)
У нас была физическая доска, к которой надо было бегать через весь отдел и двигать бумажки. Потом перешли на цифровую доску, что не очень-то помогло: на неё вообще все забили сразу почти. Некогда о бумажках думать — работать надо.
В идеале должно было быть так: ежедневный стендап на 15 минут, планирование раз в две недели на день, демо так же, прочие радости и тп. На деле было так: ежедневно час-полтора тратилось на стендап (начинались холивары и обсуждения, которые прекратить очень сложно), два-три дня на планирование с перерывами на работу, до демо так и не дошло дело, на обсуждение всякой ерунды и совещания на тему «как нам обустроить наш эджайл» тратилось по полчаса-часу в день. И плюс ко всему — ужесточённые сроки с обоснованием «ну вы ведь по эджайлу теперь, должны работать продуктивнее, сроки вам урежем». И постоянная беготня с графиками, открыть-закрыть задачу забыли, куда время тратили и тп.
И так два раза по полтора месяца где-то, с перерывом в полгода. В общем, опыт был сугубо отрицательный, особенно плохо это сказывалось на нервной атмосфере в команде — все становились злыми.
У меня был обратный опыт: ввели эджайл, и работа чуть ли не встала, слишком много времени тратилось на болтовню, планирование и учёт времени. Спад производительности был очевидный. Так и бросили это дело. Но потом попробовали ещё раз — с новым менеджером, но тем же успехом.
Да уж, это очень индивидуально. Я, к примеру, больше одной маленькой чашки в день не могу выпить. Первая бодрит, а вот последующие — наоборот, так что работать становится невозможно.
Я не пытаюсь оспорить могущество великого make'а! =)
Просто иногда скриптики действительно удобнее. К примеру, делал я разнообразные тестовые программки, для которых нужен был только один .c файл с main'ом, а на выходе — кучка бинарников. Так вот скрипт мой не только собирал все .c файлы в запускаемые бинарники, но и генерировал новые .c-шники по нужным запросам, открывал редактор и при успешной сборке сразу запускал результат. Пример можно на гитхабе посмотреть: это сишная музыка, для вывода нужен sox.
Собственно, для любого баша автокомплит команд можно прикрутить. Но guess_who задал другой вопрос: есть ли автокомплит для языков программирования. И к башу как таковому этот вопрос не относится: это к vim/emacs и прочему, для которых, кстати, есть соответствующие плагины.
Не спорю, make для больший проектов удобнее, но зато в shell'е можно описать любую хитрую логику сборки, а зависимости легко решаются написанием пары функций.
И так два раза по полтора месяца где-то, с перерывом в полгода. В общем, опыт был сугубо отрицательный, особенно плохо это сказывалось на нервной атмосфере в команде — все становились злыми.
Что здесь сложного?
Вот если бы хотя бы кроссплатформенно — то да, было б интересно.
Идея — супер!
Реализация тоже =)
Про более широкий смысл кодревью я догадываюсь )
Лично я его видел неоднократно, у нас в отделе хотим в ближайшее время ввести.
Собственно, vim — это тоже часть юникса.
Просто иногда скриптики действительно удобнее. К примеру, делал я разнообразные тестовые программки, для которых нужен был только один .c файл с main'ом, а на выходе — кучка бинарников. Так вот скрипт мой не только собирал все .c файлы в запускаемые бинарники, но и генерировал новые .c-шники по нужным запросам, открывал редактор и при успешной сборке сразу запускал результат. Пример можно на гитхабе посмотреть: это сишная музыка, для вывода нужен sox.