Я же сказал, что из двух разработчиков одного, более мотивированного, оставили на задачах, с которыми он может справиться.
Я что-то не нашел про это — я видел что менеджеров и разработчиков «проредили» без указания численности команд.
В итоге оказалось, как я понял, вместо «менять команду разработчиков» — заменить одного разработчика из двух и какое-то количество менеджеров.
Я не думаю, что прокол Яндекс вышел из-ща недостаточно квалифицированных разработчиков, судя по данному описанию и тому, что я знаю про набор людей туда. Про большинство случаев тоже не согласен, думаю, при адекватном менеджементе увольнять надо либо откровенных раздолбаев либо, если проект маленький и подмастерья не нужны, явно низкоквалифицировнных товарищей (тут, правда, возникает вопроса откуда они взялись после собеседования и испытательного срока).
Дык может каких-то программистов и надо менять, но сразу всю команду?
Я бы менял только недостаточно мотивированных. Обычно люди любят делать свою работу хорошо. Если они ее так не делают, чаще причина в плохой организации.
Можно конечно поменять всех, если за воротами стоит толпа более сильных работников за те же деньги, но как правило, по моему опыту, большая часть в результате останется той же квалификации.
Надо просто чтобы было один или несколько девелоперов с ключевыми компетенциями и хорошую организацию, чтобы остальные не портили приложения, а улучшали и сами учились в процессе.
Может аджайла а может и нет. Правктически в любом процессе есть какие-то вещи относящиеся к качеству, интересно как они были внедрены (code review, test automation, ретроспективы, обучение и прочее). Неужели разработчики злонамеренно делали некачественный код?
околоаджайловские представления о прекрасном
Это часто типа «я не буду писать документацию и проходить формальное ревью, так как этого нет в аджайле и не буду писать юнит тесты так как этого нет RUP»
да, я понял это просто хотелось бы напомнить о клевой возможности скачать и установить софт под виндой одной командой. Кстати, придумать жизненный и короткий пример применения — особый вид искусства. Я например автоматил некую нерасширямую оболочку на AutoHotKey, и присамтривался в те времена к pywinauto, но что-то не сложилось
Хотелось бы побольше узнать про миграции данных. Допустим у вас есть несколько клиентов на версиях 1.0 2.0 3.0
1) Есть ли какой-нибудь способ миграции данных клиента 1.0 на 4.0 кроме последовательных миграций на промежуточные версии
2) Если между соседними релизами было несколько последовательных зависимых друг от друга миграций, есть ли способ миграции клиента напрямую на релиз без прогона всего промежуточного. Есть ли инструменты, которые это облегчают?
100% гарантию не может дать никто. Тесты просто повышают вероятность. В конкретном случае видно, что разработчики были в курсе, что что-то не так, но выпустили версию.
Думаю, в большой компании есть несколько уровней которые что-то друг другу общали к определенному сроку. И каждому из уровней неудобно докладывать наверх о том, что качество такое, что лучше не выпускать отсюда и спешка.
Я что-то не нашел про это — я видел что менеджеров и разработчиков «проредили» без указания численности команд.
В итоге оказалось, как я понял, вместо «менять команду разработчиков» — заменить одного разработчика из двух и какое-то количество менеджеров.
Я не думаю, что прокол Яндекс вышел из-ща недостаточно квалифицированных разработчиков, судя по данному описанию и тому, что я знаю про набор людей туда. Про большинство случаев тоже не согласен, думаю, при адекватном менеджементе увольнять надо либо откровенных раздолбаев либо, если проект маленький и подмастерья не нужны, явно низкоквалифицировнных товарищей (тут, правда, возникает вопроса откуда они взялись после собеседования и испытательного срока).
Я бы менял только недостаточно мотивированных. Обычно люди любят делать свою работу хорошо. Если они ее так не делают, чаще причина в плохой организации.
Можно конечно поменять всех, если за воротами стоит толпа более сильных работников за те же деньги, но как правило, по моему опыту, большая часть в результате останется той же квалификации.
Надо просто чтобы было один или несколько девелоперов с ключевыми компетенциями и хорошую организацию, чтобы остальные не портили приложения, а улучшали и сами учились в процессе.
Кстати, какие грехи были у программистов?
Это часто типа «я не буду писать документацию и проходить формальное ревью, так как этого нет в аджайле и не буду писать юнит тесты так как этого нет RUP»
cinst 7zip
1) Есть ли какой-нибудь способ миграции данных клиента 1.0 на 4.0 кроме последовательных миграций на промежуточные версии
2) Если между соседними релизами было несколько последовательных зависимых друг от друга миграций, есть ли способ миграции клиента напрямую на релиз без прогона всего промежуточного. Есть ли инструменты, которые это облегчают?
Какой процесс разработки был внедрен?
Надо менять организацию процесса, разработчики вполне могут быть и нормальные, просто на них идет давление по срокам, а по качеству не идет