metaclass: (Default)
metaclass ([personal profile] metaclass) wrote2012-09-25 09:22 am

О какие вакансии

http://crew.taucraft.com/

Ведущий дотнет разработчик, от 2.5 к$
Краткая характеристика:
Думает объектами и выделяет абстракции из вакуума.
Кодирует вслепую на C# и помнит 10 шорткатов решарпера.
Способен в одиночку решить любую задачу, но может делать это и в паре.
Предсказывает будущее и знает, что появится в .NET 5.0.
Не помнит, как писать код без юнит тестов.
Понимает монады и может объяснить другим, что это такое.

Эти же люди снимают офис в трилистнике в самой высокой точке Минска. Антенну бы у них на окно впихнуть

Денех мало и решарпер я не использую, т.к. он меня огорчает.
Впрочем, я все равно не подойду - я ретроград и до сих пор использую 2008 студию и 3.5 дотнет, потому что монады и абстракции от смены языков и инструментов не изменяются. Ну и в agile и прочий баззворд я не верю.

[identity profile] eleon.livejournal.com 2012-09-25 08:58 am (UTC)(link)
Правда. Плохи, просто ужасающе плохи и нерезультативны. У меня есть уже много кейсов postmortem и антикризисного управления в командах, в которых эти принципы декларировались, а вот отзыв об успехе только один - у Taucraft.

[identity profile] blackyblack.livejournal.com 2012-09-25 09:03 am (UTC)(link)
Всё дружно вспомнили Тоёту.
Лично у меня те процессы вызвали чувство глубокого удовлетворения: ничего лишнего, хорошая организация, мобильность в командах. Развалить, пожалуй, можно, если есть в команде конкретный вредитель, но в целом, процессы сильно эффективнее скрама и уже тем более водопада.

[identity profile] eleon.livejournal.com 2012-09-25 09:41 am (UTC)(link)
Тоёта - и есть Lean :)
А вот с повторяемостью очень часто вопросы.

[identity profile] 9zloy.livejournal.com 2012-09-25 09:04 am (UTC)(link)
Я не знаю, как в местных реалиях, на западе положительных примеров вагон и маленькая тележка. И вообще что с чем сравнивать? Какие у вас есть положительные кейсы других процессов?

[identity profile] eleon.livejournal.com 2012-09-25 09:36 am (UTC)(link)
На западе, на самом деле, положительных примеров внедрения примерно столько же, сколько и на востоке. Просто количественная оценка проще.

Управление проектом или портфелем проектов, в данном контексте разница некритична - это немаленькая область знаний, которую часто сводят к попытке воспроизведения по внешним проявлениям. За бортом часто остается планирование (подменяется рисованием графиков в MS Project или рассказами о том, что в скраме не нужно планировать), управление изменениями (подменяется "плановыми овертаймами" или, опять же, рассказами о том, что "поместим в бэклог"), управление рисками (об этой области многие вообще не в курсе и считают, что риск это "не попадем в срок"), оперативный анализ деятельности (а вместо него команду заставляют писать таймрепорты и отчеты) и многие другие вещи. Зато отлично оттачиваются навыки давления на команду, оправдания за факапы и мастерский ануслизинг вышестоящему менеджменту.
Потому вопрос не в сравнении "чего-то с чем-то", а в сравнении "используется управленческий подход (не важно, какой) или карго-культ". Если подход - то за внешними проявлениями, наподобие саморганизации команд, отсутствии выделенного ПМа и т.п. стоит масса неозвученных принципов, которые просто не важны для обычного разработчика. Если карго-культ, то за этими принципами нет вообще ничего и процесс неуправляем.

===Какие у вас есть положительные кейсы других процессов?===
CCPM, DBR (известны под общим названием "Система Голдратта" или "Теория ограничений"). Scrum, хотя я его не люблю.

[identity profile] 9zloy.livejournal.com 2012-09-25 10:04 am (UTC)(link)
Я нигде не видел статей или кейсов, где бы подробно и красиво описывали, как они внедряли TOC. Все удачные примеры я читал в книжках по производству (цеха, заводы, фабрики). Никогда не слышал, чтобы это успешно применяли в разработке софта. Я прочитал книжки по этой теме, но почти ничего про софт. Может подкинете?

Critical Chain - по мне это устаревшая методология, которая опять же вряд ли работает в большинстве софтверных проектов.

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

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


[identity profile] eleon.livejournal.com 2012-09-25 11:55 am (UTC)(link)
Кейсы по ТОС вообще редкое явление, не говоря уж о применении к IT-сфере. Свои я не публикую (мне лень писать), чужие могу поискать, но позже, если не забуду :) Постучитесь в скайп pavel.ozolin

===Critical Chain - по мне это устаревшая методология, которая опять же вряд ли работает в большинстве софтверных проектов.===
Почему же? На мой взгляд она великолепно подходить для IT-проектов.

Ошибки в планировании и адаптация плана - это не тольок для IT постоянная головная боль, это характерно для всего R&D. Для таких случаев есть прекрасные методы, наподобие rolling wave planning, использование буферов и тому подобные методы. Scrum, кстати, тоже устанавливает жесткие сроки, в виде фиксированных дат релизов :)