Вот и пришла мода на Agile. Новый тренд утверждает работать по agile это круто и выгодно для всех сторон. Однако стоит ли все воспринимать однозначно в черном или белом свете. Существует ряд проблем которые не зависят от выбранной методики, и к сожалению повлиять на них исполнитель не всегда может.
Реальность такова:
1) Заказчик всегда хочет знать, во сколько ему обойдется проект до начала проекта. Если он не хочет этого знать, то он делает проект не за свои деньги, и вряд ли имеет финансовый интерес.
2) Редкий заказчик умеет адекватно ставить задачи и приоритеты, поэтому, скорее всего, придется это делать вам самим.
3) Редкий заказчик понимает, что такое риски и готов их обсуждать, большинство из них живет в идеальном мире, где все происходит как только они этого захотят и где нет проблем. Поэтому и используются практики заложить буфер побольше и сроки подлиньше.
5) ЮнитТесты как правило удорожают проект, что не всегда оправдано.
6) Отсутствие документации по проекту это всегда недостаток, а не достоинство.
7) Постоянная доступность заказчика возможна в редких проектах, даже если заказчик доступен, хватает ли у него квалификации отвечать на вопросы, достаточно ли он компетентен в своей же области?
8) Парное программирование это круто? — если бы это было так, однажды попробовав, все бы писали в парах.
Уверен, что есть люди, опыт которых опровергает данные утверждения. Буду рад любым аргументированным комментариям.
Всем привет! Меня зовут Денис Журавлёв. Рад поделиться полезной информацией об управлении проектами с передовой.
Электропочта для связи: denis @ pm.by
Согласен с половиной кроме: 1, 2, 3 и 7. Это рынок услуг, заказчику главное видить цель\продукт\прибыль, соответственно иметь компетентность или расставлять приоритеты это уже ваша работа.
>> 6) Отсутствие документации по проекту
А при чём тут Agile? Он совсем не предполагает «забивание» на документацию
>> 5) ЮнитТесты как правило удорожают проект
Программисты как правило ламеры, а не профи. Поэтому не умеют использовать подход Test First и не используют Continuous Integration. Поэтому почему-то всегда выклянчивают дополнительное время у заказчика на эту активность. А также на какой-то мифический (для заказчика) рефакторинг :)
В 1 и 2 вообще трудно поверить. Нормальные челы из бизнеса прекрасно знают, что такое риски и вполне способны работать с ситуациями, когда цена проекта точно неизвестна. можно работать с оптимистическими \ пессимистическими оценками и т.п.
Отличная статья, спасибо!
Случайно нашел заметку.
Денис, а ты по Agile работал? :)
Юрий, а что есть интересные предложения?
Просто ты говоришь, что это не работает. Мне вот интересно, ты по нему работал? :)
Мы ж тут на Рейторовской конференции делали лайв-дискуссию на тему внедрения Agile в эпамовском окружении. А когда я был в Киеве, то мне рассказывали как они там у себя со скрамом работают — вообще круто.
Поэтому все возможно.
Парное программирование эффективно при решении проблемы, затыка. Но не эффективно при работе над рутинными задачами.
За последний месяц мне пришлось 3 или 4 раза работать в паре – результат потрясающий. Тот редкий случай когда 1+1 > 2
Думаю что для каждого инструмента свой случай.
По поводу Юнит тестов – нужен балланс.
Пару месяцев назад они здорово мне сэкономили время (а мое время довольно дорогое для клиента). Создавал новую реализацию интерфейса для использования S3 сервиса Амазон. Юнит тест написанный когда-то давно помог быстро выявить ошибки.
Еще, мне кажется, юнит тесты не удорожают разработку если используется TDD, Поскольку в этом случае с юнит теста все начинается он становится неотъемлемой частью разработки и мышления.
Так категорично я не говорю :) Я утверждаю лишь пару вещей:
1) существует ряд проблем которые иногда не дают исспользовать agile методологии на полную мощность, и часто повлиять на это исполнителю очень сложно, отчего они и вырождаются во что-то водопадоподобное.
2) Сегодня продвинутые sales-person под брэндом Agile продаются лекарства от всего, в то время как agile лечит несколько конкретных «болезней», и в случае если больной имеет желание вылечится.
Тезис о том, что болезни не лечатся если больной не имеет на это желание — справделив.
Но Agile и итерационные процессы в целом решают ряд вопросов внутри разработчика. Я не видел ни одного заказчика, который был бы против итерационной разработки, но заказчиков которые не хотят ждать 10ть месяцев до первого билда — сколько угодно.