Pull to refresh
10
Karma
0
Rating
Denis Miller @denis_miller

User

  • Followers 3
  • Following 3

Паттерны проектирования (design patterns) — agilepod #13

О! Спасибо за искренность. Чтобы улучшиться, мог бы сказать где и что было не очень внятно?

5 вещей после Scrum (летучки)

Здорово! Ходил я вокруг да около этой фразы. Что-то резало глаз, но не мог понять что. Большое спасибо! Хорошая идея для взрыва мозга.

Нарушаете ли вы авторское право используя изображения Google Maps?

Интересно, заставила задуматься. Сейчас в суде тоже спор по поводу авторских прав у меня. Пару идей подкинули! Спасибо — +1.

5 вещей после Scrum (летучки)

Спасибо за подсказки. Не понял, как делать перевод как перевод?

5 вещей после Scrum (летучки)

Корректировочка. Вопрос написан с большой идеологической ошибкой. Правильный вариант таблетки:
Взять за шкирку лида и заставить его задавать ТЕБЕ 5 раз вопрос „почему?“

5 вещей после Scrum (летучки)

Могу выписать такую таблетку по этой ситуации: «Взять за шкирку лида и заставить его задавать 5 раз вопрос „почему?“. Пусть мучается и всё узнаёт, что следует ему знать.»

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

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

Re: Способы оценки эффективности работника

Совершенно согласен.

Лечить нужно голову (в данном контексте, я подразумеваю руководителя команды). Автор неоднократно подчеркивает — ищу суперменов. А инструмент поиска — отсеивать неудачников прекрываясь абстрактными понятиями «оценки производительности».

Re: Способы оценки эффективности работника

Предлагаю отличать процесс разработки в ИТ от глобальных изменений.

То что, кто-то выдаёт меньше кода говорит лишь о пробелах знаний в контекте проекта. И совершенно никак не характеризуют личность. Оценка производительности — это попытка посчитать личность, а отсюда — привет мотивации, так как в команде кто-то будет лучше, кто-то хуже. Мы создаём оценкой «внутренний», совершенно невидимый и неосозноваемый конфликт на ровном месте. Кстати, крики оппонентов, что такого конфликта нет лишь доказывает, что этот конфликт очень скрыт. И не каждый его просто так расскроет во враждебной для себя команде (где меряют и потом ещё и начинают давить — мол повышай производительность).

Можно это интерпретировать как «сам дурак» (что часто делается) и плюс навешать ярлык «мы оценили твою эффективность — ты лузер». А можно задаться вопросом — почему? В ИТ за десятилетия выработаны разнообразные практики как улучшать культуру разработки, которая приводит к выравниванию производительности инженеров в любом проекте. Конечно, некоторые навыки требуют практики, чтобы их получить — но это стратегичекий шаг и здравствуй ситуационный менеджмент, коучинг, менторство, парное программирование и Agile.

Re: Способы оценки эффективности работника

Не работника лечить нужно через «оценку эффективности», а процесс. Если много ошибок — значить среда создана соответствующая. И не руки рубить нужно — а голову лечить :)

Способы оценки эффективности работника

На эту тему туча информации есть у HR отделов. Правда на российском ИТ-рынке эта тема ещё пока в зародыше.
Кратко оценка происходит через
1) должностные инструкции — которые регулярно пересматриваются и являются договором между фирмой и работником — выполняются они или нет
2) профессиональный профиль — это очень большая тема ранжировки навыков и по ней отслеживают уровень и эффективность
3) компетенции — профилево-независимые навыки

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

Но самое главное в этом. Что есть самый главный хак — быть contributor'ом в систему/фирму, а остальное приложится :) что это означает? Это означает — интересовать об ожиданиях фирмы по отношению к себе, стремиться 100% их оправдать. Как механизм роста — это расширение своего impact («влияние»… по русски оттенок получается не очень). Но это тоже тема отдельного разговора.

Вот в общем, где-то так. Книг не знаю, ссылок тоже. Только на опыте. Если интересно, могу поднять эту тему в «аджайл подкасте» (agilepod.ru), если интресно — можно обсудить (стучитесь — skype:denis_miller)

Видео. Живой пример с TDD

Стучись в скайп — denis_miller

С подключением тебя будет 2 пары противоборствующих программистов!!! Мы сейчас с Денисом здесь agilepod.ru/?p=115 устроили разбор полётов. И явно не находим общих точек соприкосновения. Он так же как и ты не очень разделил наше решение.

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

Зато можно просто потрындеть — хотя это менее полезно.

Видео. Живой пример с TDD

Ой, есть с чем поспорить. Ням-ням.
Подключишься к обсуждениям в студии?

Видео. Живой пример с TDD

Понял. Прогнался во время монтажа :(
Буду делать только в моно.

Адреналиновые наркоманы. Командные паттерны (2/17)

ой, спасибо — подправлю.

Управление проектами: PRINCE2 – PRojects In Controlled Environments

В Agile, если в продукте сделано только «А», то это можно использовать сразу после поставки и получать прибыль. Даже если проект закроют. В этом координальное отличие Аджайл от других процессов так же. Для примера с велосипедом Аджайлисты первым делом заделали бы колесо без спиц, и возможно велик бы походил на тележку. Но которую можно уже прям сейчас использовать. Когда продукт начал использоваться его начнут развивать, добавляя «Б» (второе колесо и возможно добавят спицы и покрышку на колеса).

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

Адреналиновые наркоманы — секреты командного поведения (1/17)

сначала так и думал сделать, но тут 4 файла. поэтому объединил в простой пост с сылками

Управление проектами: PRINCE2 – PRojects In Controlled Environments

Странно, почему PRINCE2 ставят на одну ступеньку с Agile. Ключевой фактор в Agile не строгость процессам и артефактам (backlog и т.п.), а ориентация на человеческий фактор и командное взаимодействие. Кстати, почему-то многие, кто сравнивает Agile с другими методологиями намеренно пропускают эту ключевую составляющую Agile.

Почему человеческий фактор — важная составляющая? Ответ простой — у аджайлист всего лишь 4 убеждения, которые отличают его от других работников умственного труда. И слова «коммуникация», «индвидуальность» и «взаимодействие» как раз в ядре этой методологии заложены.

Подробнее я писал в Agile = 4 + 12

Пост-советский вотерфол или новый Аджал

согласен про применимость… мне тоже все это подозрительно… но я не теряю надежды достать из него/них полезное. не глупые люди ведь придумали это все дело, грех не воспользоваться результатами.

Кстати, аджайл датируется 2001 годом, а вот Lean уходит в средневековье 20 века :)

PS. Открыл.
1

Information

Rating
Does not participate
Location
Россия
Date of birth
Registered
Activity