О какие вакансии
http://crew.taucraft.com/
Ведущий дотнет разработчик, от 2.5 к$
Краткая характеристика:
Думает объектами и выделяет абстракции из вакуума.
Кодирует вслепую на C# и помнит 10 шорткатов решарпера.
Способен в одиночку решить любую задачу, но может делать это и в паре.
Предсказывает будущее и знает, что появится в .NET 5.0.
Не помнит, как писать код без юнит тестов.
Понимает монады и может объяснить другим, что это такое.
Эти же люди снимают офис в трилистнике в самой высокой точке Минска.Антенну бы у них на окно впихнуть
Денех мало и решарпер я не использую, т.к. он меня огорчает.
Впрочем, я все равно не подойду - я ретроград и до сих пор использую 2008 студию и 3.5 дотнет, потому что монады и абстракции от смены языков и инструментов не изменяются. Ну и в agile и прочий баззворд я не верю.
Ведущий дотнет разработчик, от 2.5 к$
Краткая характеристика:
Думает объектами и выделяет абстракции из вакуума.
Кодирует вслепую на C# и помнит 10 шорткатов решарпера.
Способен в одиночку решить любую задачу, но может делать это и в паре.
Предсказывает будущее и знает, что появится в .NET 5.0.
Не помнит, как писать код без юнит тестов.
Понимает монады и может объяснить другим, что это такое.
Эти же люди снимают офис в трилистнике в самой высокой точке Минска.
Денех мало и решарпер я не использую, т.к. он меня огорчает.
Впрочем, я все равно не подойду - я ретроград и до сих пор использую 2008 студию и 3.5 дотнет, потому что монады и абстракции от смены языков и инструментов не изменяются. Ну и в agile и прочий баззворд я не верю.
no subject
no subject
Лично у меня те процессы вызвали чувство глубокого удовлетворения: ничего лишнего, хорошая организация, мобильность в командах. Развалить, пожалуй, можно, если есть в команде конкретный вредитель, но в целом, процессы сильно эффективнее скрама и уже тем более водопада.
no subject
А вот с повторяемостью очень часто вопросы.
no subject
no subject
Управление проектом или портфелем проектов, в данном контексте разница некритична - это немаленькая область знаний, которую часто сводят к попытке воспроизведения по внешним проявлениям. За бортом часто остается планирование (подменяется рисованием графиков в MS Project или рассказами о том, что в скраме не нужно планировать), управление изменениями (подменяется "плановыми овертаймами" или, опять же, рассказами о том, что "поместим в бэклог"), управление рисками (об этой области многие вообще не в курсе и считают, что риск это "не попадем в срок"), оперативный анализ деятельности (а вместо него команду заставляют писать таймрепорты и отчеты) и многие другие вещи. Зато отлично оттачиваются навыки давления на команду, оправдания за факапы и мастерский ануслизинг вышестоящему менеджменту.
Потому вопрос не в сравнении "чего-то с чем-то", а в сравнении "используется управленческий подход (не важно, какой) или карго-культ". Если подход - то за внешними проявлениями, наподобие саморганизации команд, отсутствии выделенного ПМа и т.п. стоит масса неозвученных принципов, которые просто не важны для обычного разработчика. Если карго-культ, то за этими принципами нет вообще ничего и процесс неуправляем.
===Какие у вас есть положительные кейсы других процессов?===
CCPM, DBR (известны под общим названием "Система Голдратта" или "Теория ограничений"). Scrum, хотя я его не люблю.
no subject
Critical Chain - по мне это устаревшая методология, которая опять же вряд ли работает в большинстве софтверных проектов.
Для меня разработка софта - это обучение. Поэтому, если мы делаем что-то новое, невозможно предсказать сроки с приемлемой ошибкой, невозможно предсказать объем работ. Планировать конечно надо, но и надо быть готовым выбросить текущий план к черту через два месяца и сделать новый, а потом и его выбросить. Планирование - это просто дорожная карта, по которой мы идем. Любой жесткий срок - и до свидания качество решений.
Так что я верю в квалифицированных людей, творческие условия работы без жестких рамок, самоорганизацию на основе общего видения. Моя задача - донести видение до людей и не мешать им выполнять свою работу хорошо.
no subject
===Critical Chain - по мне это устаревшая методология, которая опять же вряд ли работает в большинстве софтверных проектов.===
Почему же? На мой взгляд она великолепно подходить для IT-проектов.
Ошибки в планировании и адаптация плана - это не тольок для IT постоянная головная боль, это характерно для всего R&D. Для таких случаев есть прекрасные методы, наподобие rolling wave planning, использование буферов и тому подобные методы. Scrum, кстати, тоже устанавливает жесткие сроки, в виде фиксированных дат релизов :)