Agile для внутренней разработки
Комментарии
В избранное
Подписаться на ответы
Сортировка:
Древо развёрнутое
Свернуть все
ууу ... сколько много "умных слов". Сразили.
Все, о чем тут расписано определяется "устаревшим" понятием "экстремальное программирование". Только напридумывали новые технологии и методологии. А суть осталась там же.
зы. Презентация конечно труд еще тот. Снимаю шляпу за оформление.
Software Engineering
Все, о чем тут расписано определяется "устаревшим" понятием "экстремальное программирование". Только напридумывали новые технологии и методологии. А суть осталась там же.
зы. Презентация конечно труд еще тот. Снимаю шляпу за оформление.
Тема важная. Для меня самое интересное в статье : как не делать лишнюю работу.
Есть просьба использовать русские слова вместо слэнга.
Либо в начале статьи писать словарик. Лично мне было бы более понятно.
Есть просьба использовать русские слова вместо слэнга.
Либо в начале статьи писать словарик. Лично мне было бы более понятно.
А при каких размерах проектов стоит применять подобнве технологии?
Например, у меня часто есть проекты на 200-300 часов срок исполнения от 2 нед до месяца. Разработчиков от 2 до 6. Список задач составлен, бюджет задачи в среднем 4-5 часов ( отчеты, печ.формы, мелкие механизмы)
Есть ли время на большое количество показов?
Например, у меня часто есть проекты на 200-300 часов срок исполнения от 2 нед до месяца. Разработчиков от 2 до 6. Список задач составлен, бюджет задачи в среднем 4-5 часов ( отчеты, печ.формы, мелкие механизмы)
Есть ли время на большое количество показов?
А для этого достаточно делать регулярные показы заказчику. Это могут быть даже не показы, нам просто нужна качественная грамотная обратная связь.
И вот тут нас ждет засада: мне некогда, решите сами, я в этом ничего не понимаю, вы меня не понимаете, давайте каждый будет выполнять свою работу, мне за это не платят, семь взаимно перпендикулярных зеленых линий из которых 3 красного цвета....
Нужное подчеркнуть, отсутствующее добавить
Много картинок, много пыщь-пыщь, всё очень красиво, наглядно, увлекательно, и как всегда на практике заканчивается полным уродством, провалом и жестью немерянной. Любимый приём всех этих многознатцев-консультантов от эйджила - напустить пыль в глаза, очаровать сладкими сказками, как всё будет круто, потом сгрести бабла и сбежать. А реальный проект потом имеет только проблемы.
Я б за попытку распространять все эти agil'ы, особенно применительно к разработке 1С, сажал бы как за вредительство и мошенничество.
Я б за попытку распространять все эти agil'ы, особенно применительно к разработке 1С, сажал бы как за вредительство и мошенничество.
(11) Никакую. Мы методологиями не заморачиваемся, мы работаем. Дело делаем. Конфигурации создаём, доработки выполняем. Некогда нам, знаете ли, дурью маяться.
К наступлению авралов, частоте факапов, проблемам с клиентами итд - наличие либо отсутствие упомянутой "методологии" и прочей заумной хрени не имеет, как показывает опыт, ни-ка-ко-го отношения.
То же экстремальное, допустим, случается, но от него, по здравому размышлению, ничего бы не спасло. Ибо бизнес захотел всё готовое позавчера, и точка, и плевать ему на все спринты, канбаны, эйджилы и прочая)
К наступлению авралов, частоте факапов, проблемам с клиентами итд - наличие либо отсутствие упомянутой "методологии" и прочей заумной хрени не имеет, как показывает опыт, ни-ка-ко-го отношения.
То же экстремальное, допустим, случается, но от него, по здравому размышлению, ничего бы не спасло. Ибо бизнес захотел всё готовое позавчера, и точка, и плевать ему на все спринты, канбаны, эйджилы и прочая)
(12)
Та и не должен бизнес об этом знать. Точнее, желание бизнеса готового на вчера не должно встречать "у нас же спринт" или что-то подобное. Бизнес захотел - делаем. Добавляем новые задачи в спринт и делаем. Эджайл именно так и говорит: "Готовность к изменениям важнее следования первоначальному плану"
Методологиями не заморачиваются, методологиями следуют. Ни один проект не может существовать без управления. А значит, или вы не ведёте проектную деятельность (что мало вероятно при разработках конфигураций) или ведёте, но вы не в курсе.
Ибо бизнес захотел всё готовое позавчера, и точка, и плевать ему на все спринты, канбаны, эйджилы и прочая
Та и не должен бизнес об этом знать. Точнее, желание бизнеса готового на вчера не должно встречать "у нас же спринт" или что-то подобное. Бизнес захотел - делаем. Добавляем новые задачи в спринт и делаем. Эджайл именно так и говорит: "Готовность к изменениям важнее следования первоначальному плану"
Методологиями не заморачиваются, методологиями следуют. Ни один проект не может существовать без управления. А значит, или вы не ведёте проектную деятельность (что мало вероятно при разработках конфигураций) или ведёте, но вы не в курсе.