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

Поэтому жрецов ссылаем в отдаленные храмы, а прагматичным, образованным, находчивым и трудолюбивым везде почёт =)

S>начальник смеется, и обещает, что "все еще наладится".

99% начальник хочет наладить процесс и взял человека, который понимает, зачем это нужно (может ещё и дополнительно установку ему дал).

Не удивлюсь, если те кто не захочет "вписаться" в предлагаемый процесс скоро отправятся искать работу.

Тут уже писали комментарий, что зря человек начал всех поучать не завоевав авторитет — полностью согласен.

Хотя есть устойчивое ощущение, что он так с шашкой на ваш балаган накинулся именно после собеседования с начальником, на котором получил карт-бланш.

Здравствуйте, slonopotam75, Вы писали:

S>Уж мы и намекали товарищу, что у нас не Майкрософт, и начальнику говорили, чтобы его куда-нибудь подальше от нас убрал — все бесполезно. Товарищ молчит, как рыба об лед, начальник смеется, и обещает, что "все еще наладится".

Начальник прав. Тут главное правильно расставить приоритеты: на первом месте успешное выполнение работы, на втором качество, на третьем — испытание новых модных технологий.

О чем идет речь? Если «я могу так же как вы, но знаю как еще лучше» — тогда вы его лучше послушайте. Если «я знаю как лучше вас, хотя реально получается хуже» — тогда вы его успокаиваете показыванием записей о его успехах в стиле:

1 декабря. Гению поставлена задача X. Предположительно должно занять неделю.
14 декабря. Гений обещал закончить завтра.
21 декабря. Гений закончил. Нужно кое-что поправить.
23 декабря. Поправил.
13 января. Петя исправил баг в модуле X.
15 января. Программа упала у заказчика на глазах. Баг был в модуле X — гений исправил.
...еще 10 багов...
2 февраля. Вася потратил 3 дня на поиск неуловимого краша, и нашел баг в модуле X.

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

Здравствуйте, Кодёнок, Вы писали:

Кё>О чем идет речь? Если «я могу так же как вы, но знаю как еще лучше» — тогда вы его лучше послушайте. Если «я знаю как лучше вас, хотя реально получается хуже» — тогда вы его успокаиваете показыванием записей о его успехах в стиле:
Кё>

Кё>1 декабря. Гению поставлена задача X. Предположительно должно занять неделю.
Кё>14 декабря. Гений обещал закончить завтра.
Кё>21 декабря. Гений закончил. Нужно кое-что поправить.
Кё>23 декабря. Поправил.
Кё>13 января. Петя исправил баг в модуле X.
Кё>15 января. Программа упала у заказчика на глазах. Баг был в модуле X — гений исправил.
Кё>...еще 10 багов...
Кё>2 февраля. Вася потратил 3 дня на поиск неуловимого краша, и нашел баг в модуле X.

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

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

Здравствуйте, Marduk, Вы писали:

M>Вот поэтому к пожеланию использовать баг-трекеры все-таки стоит прислушиваться. Вот те записи, что вы описали чудесно бы могли храниться именно там. А уже срез по работе отдельно взятого человека — это уже вопрос правильно подобранных фильтров.

Я имел ввиду делать это в дополнение к трекеру. Трекер не соберет достаточно информации воедино, не отразит тот факт, что сроки оттягивались 3 раза, не отразит того, что десяток других багов косвенно завязан на некачественное выполнение одной конкретной задачи.

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

Здравствуйте, MescalitoPeyot, Вы писали:

MP>Какая-то у вас своеобразная "разработка реального софта". Я честно говоря еще не встречал фирм без трекера и контроля версий.

Это ты сильно оторван от местечковой действительности

Кё>Я имел ввиду делать это в дополнение к трекеру. Трекер не соберет достаточно информации воедино, не отразит тот факт, что сроки оттягивались 3 раза

Ну трэкер трэкеру рознь.

Есть Редмайн — в нём есть Estimated time, там есть история изменения всех полей, в том числе и Estimated time.
Дополнительно можно установить модуль учёта потраченного времени.

Так что завал сроков и неоднократное увеличение временной оценки можно оценить простым (ну почти ж то SQL запросом.

Кё>Я не встречал такой системы для пменеджмента, которая бы позволила эту информацию легко собрать.

Ну значит не искал + многие инструменты можно или допилить, или они хранят нужную информацию, просто нет удобных отчётов — но отчёты можно дописать.

Кё>что десяток других багов косвенно завязан на некачественное выполнение одной конкретной задачи.

У Редмайна есть связи между Issue, так что для багов можно или указать Issue, программирование которой повлекло баг, или (что в разы проще) просто иметь доп. поле, куда прописывать виноватого, если он найден

Здравствуйте, slonopotam75, Вы писали:

S>А, если серьезно, приняли к нам на работу нового кодера. Супермозг, владеет пятью языками программирования. Правда, локалку у себя на машине полдня не может настроить, да еще жалуется, что это не его работа, а системного администратора, понимаешь.
Локалку поднимает админ. Левый человек вообще не может шарить в том, через какое место у вас локалка сделана.

S>Ничего толкового товарищ пока еще не сделал, но уже все уши нам прожужжал про "юнит-тестирование", "аджиле", "управление требованиями", "контроль версий", "трэкеры", "паттерны", и про то, что все у нас в фирме не так, и отлаживаем мы софт при помощи дебаггера вместо того, чтобы писать тесты, и "паттерны" мы не используем, и "тикеты" не "вешаем", и энергия Ци у нас течет не в ту сторону. Короче, такое ощущение, что о том, как разрабатывается реальный софт, человек знает исключительно из добрых детских книжек.
Человек прав. Если у вас этого нет, то этому человеку лучше найти нормальную контору, ибо я подозреваю бардак и хаус в разработке и управлении. И при этом, скорее всего, у вас никто, ни за что не отвечает, удобно, не так ли?

S>Уж мы и намекали товарищу, что у нас не Майкрософт, и начальнику говорили, чтобы его куда-нибудь подальше от нас убрал — все бесполезно. Товарищ молчит, как рыба об лед, начальник смеется, и обещает, что "все еще наладится". Знает ли кто-нибудь гуманный способ перевоспитать этого чудо-кодера, или проще всем отделом скинуться и нанять киллера эконом-класса?

Нужно лечить. Для начала ввести контроль версий и тупую багзиллу. Сделать минимально планирование т.е. хотя бы вести список фич(багов) которые будут в след. релизе. Начинать вводить юнит-тестирование (хотя, лучше модульное тестирование (у вас ведь модульная архитектура?), т.к. юнит-тесты писать уже поздно). Попробовать описать все внешние интерфейсы всех модулейи заморозить их до след. релиза.

Хочу добавить,
работал в конторке, в которой всего это не было + неадекватный менеджмент как итог, они не сдали ничего в продакшен 9по прошествию 2-х лет, ххотя работы там на год было). Что-то есть, но это что-то не стабильное и падает при каждом хорошем чихе.
Вывод, не принебрегайте процеесом.

Здравствуйте, Кодёнок, Вы писали:

Кё>Здравствуйте, Marduk, Вы писали:

M>>Вот поэтому к пожеланию использовать баг-трекеры все-таки стоит прислушиваться. Вот те записи, что вы описали чудесно бы могли храниться именно там. А уже срез по работе отдельно взятого человека — это уже вопрос правильно подобранных фильтров.

Кё>Я имел ввиду делать это в дополнение к трекеру. Трекер не соберет достаточно информации воедино, не отразит тот факт, что сроки оттягивались 3 раза, не отразит того, что десяток других багов косвенно завязан на некачественное выполнение одной конкретной задачи.

Кё>Я не встречал такой системы для пменеджмента, которая бы позволила эту информацию легко собрать.

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

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

Хотя, вполне возможно, что описанный вами подход действует вполне эффективно. Мне с таким сталкиваться не приходилось.

troll detected

Здравствуйте, avpavlov, Вы писали:

A>99% начальник хочет наладить процесс и взял человека, который понимает, зачем это нужно (может ещё и дополнительно установку ему дал).

Не выдумывай — "...все у нас в фирме не так" не оставляет даже шансов.

A>troll detected
Очень похоже. Человек создал первый раз тему, больше не отписался, но где тут еда для него?

Vi2>"...все у нас в фирме не так"

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

A>>troll detected
L>Очень похоже. Человек создал первый раз тему, больше не отписался, но где тут еда для него?

Еда уже здесь Уж больно драматически описано всё было (для первого сообщения) Сейчас народ схватится насмерть, нужны юнит тесты или нет

Lexxpin пишет:

> A>*troll detected*
> Очень похоже. Человек создал первый раз тему, больше не отписался, но
> где тут еда для него?

Посещаемость ресурса надо поднимать

--
WBR,
Serge.

Здравствуйте, avpavlov, Вы писали:

A>Подозреваю, что это эмоциональная оценка, данная топик стартером, а не реальное утверждение нового сотрудника.

Тем более. С таким подходом он все угробит окончательно.

Хоть товарищ и пропал, позволю пару историй.

Собеседовался в контору на разработчика iPhone. Ни одного вопроса по Objective-C, зато полчаса долбления про методологии, аджайлы и как важно все делать правильно. Я не пошел, явная переоценка важности процессов для конторы которая существует меньше месяца. Через год после собеседования в AppStore только один продукт этой компании, притом совсем не сложный. Год прошел — результатов нет. Народу работало немало. Стартап был основан "опытными менеджерами" из крупной конторы где были отделы по сотне человек. Видимо вместо продуктов получили процессы

Еще одна контора в которой процессы были доведены до маразма — одно из подразделений Luxoft, которое основали опять таки "опытные менеджеры" с подходом очень крупной конторы. Сейчас эта компания не существует, почти всех уволили, ключевых сотрудников перевели обратно в Luxoft.

Я очень положительно отношусь к Agile, если только она не становится инструментом принуждения к 12 часовому рабочему дню. Например если интерация две недели и забита сверх меры, то иногда перед концом итерации народ начинает вкалывать по 12 часов чтобы сделать итерацию в срок и показать что-то инвесторам. Начинают идти коммиты в 3 часа ночи, ночные бдения, наспех сделанное "изделие" появляется на свет. Очень часто апологеты Agile недооценивают важность первоначальной проработки архитектуры, ну не надо в первые дни проекта начинать кодирование, какой бы крутой Agile не был.

Я не против процессов, я против бездумного насаждения процессов ради процессов. Нельзя внедрять процессы и методики если люди не готовы их принять. Всегда надо начинать с малого и внетрять тулзы по одному. Исключение — проект которые делается новой командой собранной с нуля. Меня часто раздражало когда приходя на новое место мне надо изучать новый SCM, новый багтрекер, новый планировщик и трекер задач и т.д. Я очень радуюсь когда узнаю что SCM стоит Subversion или проджект трекер MS Project — просто потому что не надо забивать голову очередной тулзой.

Здравствуйте, slonopotam75, Вы писали:

S>Уж мы и намекали товарищу, что у нас не Майкрософт, и начальнику говорили, чтобы его куда-нибудь подальше от нас убрал — все бесполезно. Товарищ молчит, как рыба об лед, начальник смеется, и обещает, что "все еще наладится". Знает ли кто-нибудь гуманный способ перевоспитать этого чудо-кодера, или проще всем отделом скинуться и нанять киллера эконом-класса?

Только насилием!
1. Завести разговор про юнит-паттерны, перейти на ругань и подраться с ним.
2. Жестко спровоцировать его. Например подойти к нему в плотную и крикнуть — "Эй ты, задрот". Потом начтется драка.
3. Плеснуть ему в лицо чаю и сразу ударить. Далее запинать.
4. Просто отлупить его втроем после работы.

Шучу Слишком мало данных о всех участниках трагикомедии.