• Бесплатная электронная книга по гибким методологиям разработки
    0
    По другим форматам и платформам думал, в планах есть. Посмотрим пока, каким тиражом книга разойдется :)
  • Как преодолеть традиционные проблемы при внедрении Agile
    0
    Я на хабре наверное опубликую, как только вопрос сдвинется с места ;)
  • Как преодолеть традиционные проблемы при внедрении Agile
    +1
    Есть инсайд, что такие договора могут появиться после НГ :)
  • Как преодолеть традиционные проблемы при внедрении Agile
    0
    Я собственно и написал, что в теории беклог продукта самым, что ни есть, волшебным образом появляется у владельца продукта :) На практике необходимы определенные усилия и трудозатраты.

    Про сторимаппинг из опыта могу сказать следующее (именно практические вещи):
    — у команды улучшается видение целей и содержания проекта;
    — у команды улучшается мотивация к успешному завершению проекта;
    — выявляются целы «пласты» функционала, про который обычно забывают;
    — четче и прозрачней расставляются приоритеты и планируются релизы;

    Про мотивацию вопрос очень сложный и, безусловно, надо сочетать как материальные способы, так и нематериальные. Ваш кэп :)
  • Проблемы при внедрении Agile
    0
    Начал писать комментарий, а получился пост. Вообще темы интересные подняты :)
  • Заметки по следам Whale Rider
    0
    Надеюсь видео выложат в открытый доступ, потому что без самого доклада презентации, конечно, смотрятся вяловато.
  • Заметки по следам Whale Rider
    +1
    Ответ будет «В процессе» :)
  • Заметки по следам Whale Rider
    0
    Процентов на 80% совпал выбор лучших докладов. Я бы еще парочку добавил. И про кулуары согласен, самое интересное было между докладами, ну и в самом конце еще :)
  • Особенности применения Scrum в заказной разработке
    0
    По поводу fixed cost: опять же можно отлично использовать внутри скрам, конечно, все бенефиты скрама вы в итоге не получите.
  • Особенности применения Scrum в заказной разработке
    +1
    Я бы еще добавил, что через пару спринтов, можно уже давать оценки по завершению проекта на основе реальной скорости команды и скорости добавления новых фич. Просто называете этот период «прототипирование» или «предварительное проектирование» и затем уже идет «разработка проекта».
  • Особенности применения Scrum в заказной разработке
    +1
    Проблема в том, что в классическом управлении изменениями требований дополнительно в бюджет закладываются не только риски, которые появляются при новых требованиях, но и уже сделанные промахи исполнителя. В итоге получается, что цена проекта вроде бы небольшая, а любое изменение — очень дорогое.
  • Особенности применения Scrum в заказной разработке
    +1
    Длинные митинги и их большое количество — это не скрам, а некачественная работа скрам-мастера :) Скрам — это гибкая методология с жестким таймбоксингом…
  • Особенности применения Scrum в заказной разработке
    0
    А какие аспекты конкретно интересуют? У меня есть желание еще написать на данную тему…
  • Эффект наблюдателя
    0
    Я почему спросил: когда руководитель проекта сам оценивает задачи и раздает их девелоперам, у него не очень много времени на стратегические задачи…
  • Эффект наблюдателя
    0
    И где я это «подметил»? :) Название означает, что благодаря таким наблюдениям, можно внести нежелательные последствия в работу команды.
    Метрики обычно используются не для «премировать и штрафовать», а для повышения эффективности работы команды, в том числе и при помощи их анализа.
  • Эффект наблюдателя
    0
    Я как метафору использовал :) А вот какой метафорой может быть корпускуляно-волновой дуализм пока слабо представляю :)
  • Эффект наблюдателя
    0
    Похожая история в одной из ссылок из поста: local.joelonsoftware.com/wiki/Измерения_продуктивности
  • Эффект наблюдателя
    –1
    Если эта тема вам не близка, можно просто не читать :) А то получается, ежики плакали, но продолжали есть кактус :)
  • Эффект наблюдателя
    0
    Работает?
  • Эффект наблюдателя
    0
    Скорее статья о том, как не надо использовать метрики для «наказаний» :)
  • Эффект наблюдателя
    +1
    Как раз они будут руководство нецелесообразностью, а метриками (кол-во багов одному идет в минус, другому в плюс). В итоге могут потерять несколько часов (и не только своих), вместо того, чтобы прийти к консенсусу за минуту :)
  • Эффект наблюдателя
    0
    Собственно, у меня пост про командные метрики. Индивидуальные метрики еще более опасными могут быть :)
  • Эффект наблюдателя
    0
    А при такой схеме «не выгодно» ли забивать на мелкие баги, а искать только баги с большим весом? :)
  • Эффект наблюдателя
    0
    В спецификации написано с большой буквы, а в корпоративной политике с маленькой…
  • Эффект наблюдателя
    +1
    Абсолютно согласен. Могу добавить только то, что по системам/субсистемам есть очень много интересных мыслей у Гольдрата.
  • Эффект наблюдателя
    +1
    Как раз смысл в том, что у метрик есть побочные эффекты, которые не так очевидны. И их можно не увидеть до внедрения.
    А вариант того, что команда не знает метрик, по которым оценивается их эффективность, на мой вгляд не очень хорош, как раз тем, что команда не получает фидбека и не понимает, насколько эффективно она работает.
  • Эффект наблюдателя
    0
    Пример из жизни: на сайте (или в диалоговом окне) слово «Вы» написано с большой буквы. Дефект? :)
  • Эффект наблюдателя
    +2
    Там важное уточнение: … необходимо много условностей (схожие задачи, наличие стандартов кодирования, например, максимальная длина метода, отсутствие дублирования, рефакторинг и так далее), но все же метрика достаточно точная… если не использовать ее как оценку производительности.
  • Управлять IT-проектами — как играть в регби
    +2
    У нас сегодня после праздников одна команда скрамилась, как сборная Новой Зеландии вначале ролика…
  • Чем отличаются настоящие тестировщики от поддельных?
    0
    Хорошая статья и очень интересные ссылки. Я бы еще добавил про управление качеством статистическими методами…
  • Надо ли тратить время на проектирование?
    +6
    Почему-то никто не пишет про самое главное — про итеративность. Сегодня большинство компаний используют итеративные методологии, поэтому умение распределять проектирование по итерациям (люблю слово «размазывать») является очень важным.
    То что описал предыдущий автор — это классический пример антипаттерна «паралич анализа» (http://sourcemaking.com/antipatterns/analysis-paralysis). Бороться с ним очень просто: жестко таймбоксите нулевой спринт, требования готовьте в виде беклога (сверху подробного расписанные ЮС, снизу — эпики), архитектуру прорабатывайте сверху (не ныряйте глубоко), вовлекайте заказчика и общайтись с ним, если делаете прототипы — распределите их по спринтам, но с опережением разработчиков на один спринт.
    Вообще если стоит такая проблема, используйте таймбоксинг везде, либо возьмите целиком готовую методологию Scrum. Есть желание написать статью, но нет времени, да и доклад делал на эту тему: ekt.agiledays.ru/ (Использование ICONIX для анализа требований в Scrum)
  • Конференция для разработчиков в Оренбурге
    0
    Скорее всего соберемся по .NET или PHP ближе к концу октября.
  • Конференция для разработчиков в Оренбурге
    0
    Спасибо :) Постараемся время как-то поудобнее выбрать :)
  • Конференция для разработчиков в Оренбурге
    +1
    Вань, к сожалению, организаторы некоторое время тянули с помещением :(
  • Конференция для разработчиков в Оренбурге
    0
    Мы проводим такие «небольшие» конференции достаточно часто (по 4-6 часов общей длительности), чтобы публика не успела устать :)
  • Конференция для разработчиков в Оренбурге
    +1
    Обычно проводим по субботам, в этот раз проводим не у себя в офисе… замечание учтем :)
  • Конференция для разработчиков в Оренбурге
    0
    Помню прошлый твой доклад собрал больше всех «плюсиков» и вопросов было больше всего :)
  • Google Apps: опыт использования
    0
    В нашем департаменте человек 30.
  • Google Apps: опыт использования
    0
    Да, внутренняя разработка: в Google Calendar ставились событие для админов и отправлялось СМС. Получилось своебразное дополнение к системе мониторинга с автоматическим оповещением и логом событий.
  • Ура! Мы готовы встречать участников Agiledays 2010 Санкт-Петербург
    +1
    А какие игры будешь показывать на своем тренинге?