Agile — это круто? Проверьте исходные предположения!

life-sport-rugby

Вот и пришла мода на Agile. Новый тренд утверждает работать по agile это круто и выгодно для всех сторон. Однако стоит ли все воспринимать однозначно в черном или белом свете. Существует ряд проблем которые не зависят от выбранной методики, и к сожалению повлиять на них исполнитель не всегда может.

Реальность такова:

1) Заказчик всегда хочет знать, во сколько ему обойдется проект до начала проекта. Если он не хочет этого знать, то он делает проект не за свои деньги, и вряд ли имеет финансовый интерес.

2) Редкий заказчик умеет адекватно ставить задачи и приоритеты, поэтому, скорее всего, придется это делать вам самим.

3) Редкий заказчик понимает, что такое риски и готов их обсуждать, большинство из них живет в идеальном мире, где все происходит как только они этого захотят и где нет проблем. Поэтому и используются практики заложить буфер побольше и сроки подлиньше.

5) ЮнитТесты как правило удорожают проект, что не всегда оправдано.

6) Отсутствие документации по проекту это всегда недостаток, а не достоинство.

7) Постоянная доступность заказчика возможна в редких проектах, даже если заказчик доступен, хватает ли у него квалификации отвечать на вопросы, достаточно ли он компетентен в своей же области?

8) Парное программирование это круто? — если бы это было так, однажды попробовав, все бы писали в парах.

Уверен, что есть люди, опыт которых опровергает данные утверждения. Буду рад любым аргументированным комментариям.

10 Comments

  1. Согласен с половиной кроме: 1, 2, 3 и 7. Это рынок услуг, заказчику главное видить цель\продукт\прибыль, соответственно иметь компетентность или расставлять приоритеты это уже ваша работа.

  2. >> 6) Отсутствие документации по проекту
    А при чём тут Agile? Он совсем не предполагает «забивание» на документацию

    >> 5) ЮнитТесты как правило удорожают проект
    Программисты как правило ламеры, а не профи. Поэтому не умеют использовать подход Test First и не используют Continuous Integration. Поэтому почему-то всегда выклянчивают дополнительное время у заказчика на эту активность. А также на какой-то мифический (для заказчика) рефакторинг :)

    В 1 и 2 вообще трудно поверить. Нормальные челы из бизнеса прекрасно знают, что такое риски и вполне способны работать с ситуациями, когда цена проекта точно неизвестна. можно работать с оптимистическими \ пессимистическими оценками и т.п.

  3. Просто ты говоришь, что это не работает. Мне вот интересно, ты по нему работал? :)
    Мы ж тут на Рейторовской конференции делали лайв-дискуссию на тему внедрения Agile в эпамовском окружении. А когда я был в Киеве, то мне рассказывали как они там у себя со скрамом работают — вообще круто.
    Поэтому все возможно.

  4. Парное программирование эффективно при решении проблемы, затыка. Но не эффективно при работе над рутинными задачами.

    За последний месяц мне пришлось 3 или 4 раза работать в паре — результат потрясающий. Тот редкий случай когда 1+1 > 2

    Думаю что для каждого инструмента свой случай.

  5. По поводу Юнит тестов — нужен балланс.

    Пару месяцев назад они здорово мне сэкономили время (а мое время довольно дорогое для клиента). Создавал новую реализацию интерфейса для использования S3 сервиса Амазон. Юнит тест написанный когда-то давно помог быстро выявить ошибки.

    Еще, мне кажется, юнит тесты не удорожают разработку если используется TDD, Поскольку в этом случае с юнит теста все начинается он становится неотъемлемой частью разработки и мышления.

  6. Так категорично я не говорю :) Я утверждаю лишь пару вещей:

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

    2) Сегодня продвинутые sales-person под брэндом Agile продаются лекарства от всего, в то время как agile лечит несколько конкретных «болезней», и в случае если больной имеет желание вылечится.

  7. Тезис о том, что болезни не лечатся если больной не имеет на это желание — справделив.
    Но Agile и итерационные процессы в целом решают ряд вопросов внутри разработчика. Я не видел ни одного заказчика, который был бы против итерационной разработки, но заказчиков которые не хотят ждать 10ть месяцев до первого билда — сколько угодно.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *