Ковбой
  • vfursov

Доклад на Первом международном Форуме студентов и аспирантов по управлению проектами в Москве

Сегодня делал Доклад на Первом международном Форуме студентов и аспирантов по управлению проектами в Москве.
Приехать на форум не удалось, потому презентовал свой доклад в форме вэбинара.
Тема доклада: SCRUM - наиболее удачный путь организации сложных проектов.
Кому интересно, вот здесь можно ознакомиться с полным скриптом сегодняшнего доклада.
  • Current Mood
    accomplished
Лампа
  • gi_ant

Эволюция Продукта. Мысли вынесенные с Agileee.

Вернулся недавно с Agileee
У в компании нас принято после любой конференции делиться с сотрудниками полученной информацией посредством презентации.
Может кого то эта презентация натолкнёт на полезные мысли :)


mindmapCollapse )
escher
  • t_gra

Живой труп, или ригидный Agile

avva написал пост о своём восприятии Agile:

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

Мой ответ:

Кажется, вам встречались в основном “не тру” аджайлисты.

Очень часто различные полезные течения опошлялись последователями N-ого поколения, копирующими лишь внешние признаки, ритуалы, и превращающие полезные паттерны в ригидные правила.

Так, например, раннее христианство отличается от того, что сформировалось в 5-7 веке, когда сформировался канон.

В то время как одним из ключевых принципов Agile на мой взгляд является необходимость модификации и постоянной подстройки процесса под конкретный проект/команду/сложившуюся ситуацию. (inspect and adapt)

Вы правильно заметили, что Agile определён достаточно расплывчато. Это так, потому что фактически каждая команда имеет свой собственный процесс - и он мутирует с течением времени.

Называют эту сущность отдельным словом с тем, чтобы отделить от традиционных/ригидных методологий - водопадной модели, итерационной (с маленькими водопадами в каждой итерации), с одной стороны, и от недисциплинированной, хаотической разработки, с другой.

Ригидный agile (оксюморон) - попытка воспринять какие-то практики как серебряные пули, в то время как agile - это скорее набор пулек из разных плюс общие принципы их использования. А точность каждого конкретного выстрела зависит от конкретного стрелка.

Маркетинговая привлекательность баззвордов, конечно, играют отрицательную роль. Знакомый работал в одной аутсорсинговой конторе и заказчики требовали Agile. В результате был имплементирован некий дубовый процесс, заключающийся главным образом в том, что не было предварительного проектирования. А других практик, которые делают это возможным, внедрено не было. Команды как целостности не было. И главное, не было предусмотрено адаптации процесса (да и некому было это делать и брать за это ответственность - команды же нет, есть отдельные индивидуумы). В результате у знакомого, естественно, сложилось отрицательное мнение об Agile.

У Agile есть две стороны - инженерные практики и практики командной работы/управления. Вы в этом посте затронули только инженерные практики (которые, как я понял, вы любите, если без фанатизма). Интересно, как вы относитесь к неинженерным практикам (Iteration Planning Meeting, Daily Scrum Meeting, Retrospective и т.д.)?

Запись опубликована AgileProductivity. Пожалуйста, оставляйте комментарии там.

escher
  • t_gra

Главарь банды - шесть качеств хорошего скрам-мастера (Майк Кон)

Недавно я понял, что мне необходимо делегировать другим людям полномочия скрам-мастера в своих командах. А самому сосредоточиться на работе Product Owner’а (прокси-продукт-овнера, на самом деле) и коачинге новоиспечённых скрам-мастеров в командах.

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

С целью дать командам информацию о критериях выбора хорошего скрам-мастера, я нашёл и перевёл статью Майка Кона “Главарь банды. Шесть качеств хорошего скрам-мастера.” (Mike Cohn, Six Attibutes of a Good ScrumMaster). Заодно перевёл и комментарии к этой статье, оставленные на сайте ScrumAlliance, которые, на мой взгляд, прекрасно дополняют статью.

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

Представляю его вам:

Leader of the Band

Six Attributes of a Good ScrumMaster

by Mike Cohn | 05 Feb 2007

Главарь банды

Шесть качеств хорошего скрам-мастера

Майк Кон, 5 февраля 2007

перевод – Алексей Тигарев <tigra AT nlp.od.ua>, 11.06.2008

http://nlp.od.ua/

In my last column I asserted that in an ideal world a team would select its own ScrumMaster, but that it isn’t always practical. I promised that my next column would discuss what to look for in a potential ScrumMaster, whether the selection is being made by the team itself or by someone outside the team. In this week’s column, I present six attributes that your next ScrumMaster should demonstrate.

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

Читать запись полностью »

escher
  • t_gra

Традиционные роли и роли в Agile

Недавно ко мне обратился владелец одной компании по поводу работы. Мы пообщались, и он попросил меня ответить на несколько вопросов. На английском.

Вопросы он задал довольно интересные, и ко мне пришло вдохновение. Не в силах остановиться до трёх ночи, я писал сочинение :)

Я решил опубликовать его в виде серии постов.

Итак, первый вопрос, в ответе на который я раскрываю смысл должностей Product Manager, Project Manager и Team Lead, и альтернативную систему координат, принятую в Agile, точнее в Scrum - Team, Product Owner, Scrum Master. А также моё личное отношение к этим ролям.

1. Вы пишете о том, что хотите занимать позицию Project Manager или Team Leader. Какими задачами на Ваш взгляд должен заниматься человек находящийся на этой позиции и как Вы их видите?

I am interested in Product Manager or Project Manager positions actually, as I'm writing in my CV.

Responsibilities of mentioned positions traditionally may include:
(Читать дальше)
escher
  • t_gra

"Гибкая продуктивность" - первая глава готова

Я закончил первую главу моей книги с рабочим названием "Гибкая продуктивность: утройте продуктивность команды программистов, используя гибкие методологии". Скачать можно здесь (нужно знать пароль, он будет у подписчиков, покупателей системы и финалистов онлайн-тренинга). Эту и некоторые из последующих глав книги получат все подписчики рассылки.

Подпишитесь сейчас, чтобы получить ссылку на скачивание файла.

SmartResponder.ru
Ваш e-mail: *
Ваше имя: *
Вот содержание первой главы:
  • Глава 1. Текущее состояние. Традиционные проблемы команд разработчиков.
    • Несоответствие разработанного продукта требованиям и ожиданиям заказчика
    • Типы контрактов при разработке программного обеспечения
    • Проблемы с контрактами Fixed Price
      • Fixed Price без документирования требований
      • Fixed Price с частичным документированием требований
      • Fixed Price с максимально детально документированными требованиями
        • Делаем всё правильно
        • «Водопад» стоит дорого
        • Требования всё равно меняются
        • «Водопад» запросов об изменениях (change requests)
        • Патовая ситуация
      • Изменение требований во время разработки
    • Проблемы с контрактами Time & Materials
      • Гибкость для заказчика
      • Комфорт для исполнителя
      • Злостная оптимизация
      • Неэффективность Time & Materials для заказчика
      • Убытки исполнителя от дополнительных ограничений контракта
      • Проблемы с изменением требований остаются
      • Как продают контракты Time & Materials
    • Трудно хорошо договориться с заказчиком
    • Трудности с закрытием контракта
    • Качество кода
    • Низкое качество продукта
    • Низкая мотивация