Пришиваем хвост: нужен ли Эджайл в 1С или глупости это всё?..

12.03.21

Управление проектом - Agile

Коллеги, приглашаем поучаствовать в опросе - Agile в проектах внедрения 1С: реально работает или это миф? Интересен практический опыт!..

Вместо предисловия:

- Чистосердечное признание: когда я в статье (в данном случае в тесте) вижу такие слова как product owner, бэклог, технический проект, бизнес процесс, agile - чувствую себя колхозником. Я конечно понимаю смысл этих слов, мне нравятся новые слова, легко найти их смысл в интернете, но в нашей франчайзи такое не используют вообще… В связи с этим у меня вопрос. Вы действительно используете в своей организации эти слова и эти методики? =) И как? Повышает эффективность?

- Большинству франчайзи будет достаточно выучить одного переводчика с агильского

(Из дискуссии на форуме Инфостарта)


К некоторому моему удивлению, на Инфостарте не затихают дискуссии про то, Agile - это правда работающий подход, или это про чувство собственной важности? Способ более эффективно работать или оправдание собственной некомпетентности? Ну и соответственно, традиционно ломаются копья про то, нужен ли Agile в 1С, или это всё глупости…  
В очередной раз расскажу свои пять копеек по этому вопросу. Про то, что такое Agile подход, когда он работает, а когда нет, я уже много раз писала. Можно почитать подробности в публикациях: Почему Agile превращается в Тяп-ляп. Кто виноват и что делать? , Что такое Agile mindset или, говоря по-русски, пронырливый образ мысли и так далее.
Тех, кому интересно эту тему рассмотреть более подробно - приглашаю ко мне на курс по Agile, который стартует 25 марта 2021. А за неделю до него, 17 марта мы поговорим про метод, близкий к  Agile (но строго говоря к нему не относящийся) - про Канбан

 


Что мы будем понимать под Agile?

(Несколько абзацев для тех, кто в танке. Ну, и для того, чтобы сверить часы - а то бывает, что любой бардак называют словом "Agile")


Agile -  это подход к управлению проектами, предполагающий выполнение работы маленькими кусочками, с уточнением содержания по мере получения обратной связи от заказчика. За счет движения “короткими перебежками” и короткой “петли обратной связи” можно получить результат, который в большей степени оказывается полезным заказчику. Для работы по “гибким методологиям” существует большое число инструментов, техник и методов.  Например,бэклог продукта, Канбан-доски, дорожные карты продукта вместо диаграмм Ганта,  карты пользовательских историй, покер планирования и многое другое. 

При этом важно помнить, что Agile - это подход, который стоит применять для проектов, связанных с высокой неопределенностью требований (не очень понятно на старте, что мы хотим получить в результате), и высокой технической неопределенностью (не очень понятно на старте, как мы будем это делать).  Если всё понятно как делать, внедрение стандартное, все требования в начале уже известны - необходимости городить Agile нет. 
Потому что работать по Agile совсем не так просто, как полагают те, кто бодро делает заявления в стиле “Мы не документируем - у нас Agile”!..  
Работа по Agile требует более высокой компетентности и самоорганизованности членов команды, требует от представителей заказчика готовности быть в контакте с командой проекта и регулярно обсуждать проблемы и запросы, требует определенного уровня доверия и готовности к сотрудничеству.
Не все попытки внедрить Agile оказываются успешными. Но - если получается - то, черт возьми - оно работает и оказывается продуктивным!!! Просто надо помнить, что чудес не бывает, и Agile трансформация, как правило, занимает несколько лет. 

 

"Фишки" Agile, полезные в проектах 1С

 

А здесь я хочу рассказать про то, какие фишки и инструменты Agile по моему опыту и по моим представлениям самые полезные. Ожидаю, что читатели статьи про многое из упомянутого ниже воскликнут: “ё-моё, а мы тоже это используем, а ни про какой ваш “Ажаль” слыхом не слыхивали!”. Это логично (мало того, нелогичным было бы обратное). Потому что если инструмент полезный и работающий, очевидно, что многие разные умные люди независимо приходят к его использованию. Просто называют разными словами. Следует ли из этого, что Agile - бессмысленный? Нет, конечно. Плюсы разных фреймворков и методов Agile в том, что они представляют собой не просто хаотичный набор инструментов, а некоторую технологию, которой можно обучаться, которую можно внедрить, и применять на практике. Впрочем, мы немного отвлеклись. Итак, самые полезные на мой взгляд, фишки Agile:

 
Регулярные встречи. 

Самые распространенные встречи Agile: 

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

Во многих командах нет практики регулярных встреч, особенно встреч с команды разработки с бизнес-заказчиками. А те, у кого такая практика есть, могут подтвердить, что оно улучшает взаимопонимание.  
Ё-моё, в этом есть некоторая магия, это удивительно - но это работает, когда мы заставляем людей встречаться!..  Казалось бы, зачем нужна летучка - ведь итак каждый член команды может подойти к тимлиду и сказать “у меня есть проблема”... Но - не подходят, блин!.. По тысяче разных причин…  И каждый знает свои планы и обязанности, зачем уточнять их на летучке? Но когда знаешь, что на следующем стенд-ап совещании нужно будет рассказать команде, что ты сделал за вчерашний день - это мобилизует доделать кусок…  Есть Agile-подход, используемый для обучения - называется EduScrum. Изначально его придумали для проектной работы в школах, но сейчас применяется много где - в том числе, насколько я понимаю, в Корпоративном Университете Сбербанка. Но расскажу я сейчас про школьников. Так вот, суть метода в том, что участников делят по командам, каждая команда получает исследовательское задание (например, по естественным наукам: выясните, сколько меди в этом телефоне), сама распределяет задания, определяет направления движения и сдает работу. Так вот, в командах участвуют нормальные школьники, и многие из них, естественно, совершенно не прочь пофилонить. И в отсутствие надзора строгого учителя и страха двойки команда может забить на эти ваши дурацкие исследования, и просто приятно провести время на уроке. А потом наступает время общей встречи, и каждая команда рассказывает, что она сделала. Тем, кто валял дурака сказать, естественно, нечего. И учитель на этом месте настаивает, чтобы представитель команды вышел и так и сказал - мы ничего не сделали. Так вот, удивительным образом, после того как на фоне других команд команда лентяев разок-другой признается “мы ничего не сделали”, они волшебным образом - без всякого страха двоек и требований от учителя - начинают что-то делать, так как им самим становится некомфортно. В общем, встречи и здесь работают, да.


Короткая петля обратной связи.

Это такое специальное “эджайльское” словосочетание. Для тех, кому требуется “перевод с агильского”, поясню - в сложных проектах нам трудно быть до конца уверенными, что наши представления о том, как надо что-то делать - верные. Поэтому мы проверяем наши предположения, пробуем, а потом смотрим, что получилось и корректируем. Этот принцип применяется повсеместно: мы что-то моделируем, делаем прототипы. Мы даем заказчикам “поиграться”, “покрутить в руках” какие-то функции, чтобы они убедились, удобно ли им. Мы предлагаем пройти по шагам описанный бизнес-процесс от начала и до конца, чтобы убедиться, что таки по нему можно работать. Мы выпускаем один модуль в ОПЭ, чтобы на его примере понять, что нужно переделать в других модулях. И так далее… 
Честно скажем, эту идею - собирать обратную связь и на ней учиться - придумали задолго до Agile. Внимательные наблюдатели легко узнают в ней уже набивший оскомину (но от этого не ставший хуже работать) цикл Деминга-Шухарта: Plan-Do-Check-Act. Особенность Agile - что мы пытаемся сделать этот цикл как можно короче. Один из лозунгов - Ошибайся чаще, ошибайся безопасно (fail fast fail safe в оригинале. Или, как его иногда пародируют: fail fast - be agile).
Я уверена, что все внедренцы, читающие эту статью в тот или иной момент сталкивались с ситуациями (или сталкиваются с ними постоянно), когда первоначальная версия реализации того или иного функционала оказывалась нежизнеспособной. И вместо того, чтобы говорить “ничего не знаю, так было написано в ТЗ, а мы не при чем” или “как жаль, что у нас такой некомпетентный специалист задачу делал, давайте его оштрафуем или уволим”, Agile признает, что такое случается сплошь и рядом и предлагает минимизировать убытки. Как раз при помощи той самой короткой петли обратной связи.


Канбан-доски.

Это инструмент, который я настоятельно рекомендую всем, кто еще не использует. Если про Канбан-метод еще можно ломать копья, нужен он или нет (кстати, на момент написания статьи я планирую через неделю провести вебинар про Канбан-метод - присоединяйтесь), то про Канбан-доски таких вопросов не возникает. 
Чтобы все задачи были зафиксированы, и “работа не проваливалась в трещины”. Чтобы можно было всю информацию о задаче привязывать к одной сущности. Чтобы доска делилась не на три абстрактные колонки “Надо сделать - В работе - Готово”, а на ней был подробно расписан бизнес-процесс, от постановки до тестирования.

 

На этом, пожалуй, пока остановлюсь.
И, чтобы статья не искажала действительность, добавлю еще несколько пунктов про то, когда Agile не идет на пользу:

 

Когда Agile не идет на пользу:

  • Когда нет физической возможности. Мы можем рассуждать, что Agile в данной ситуации полезен. Но если бизнес-заказчик не готов к гибкости по срокам и бюджету и настаивает на детальном ТЗ на старте, а представители заказчика не готовы к тесному сотрудничеству с командой разработки - наши рассуждения врядли смогут изменить ситуацию. 
     
  • Когда коробочное внедрение, все просто и понятно. Agile дороже и сложнее, чем работа "по Водопаду". Так зачем огород городить, если и так понятно, что делать - бери лопату и копай!

- Не надо усложнять сущности без надобности! Не надо!

- Не буду-не буду Оккам!!! Только бритву убери...

(Анекдот)

  • Когда пытаются лень и некомпетентность оправдывать Agile. Если в команде нет дисциплины и компетентности, то, честно скажем, никакой подход не спасет. Может показаться, что при помощи Agile удобнее скрывать лень и некомпетентность, но на мой взгляд все обстоит строго наоборот. Да, в работе по Водопаду команда на старте демонстрирует способность нарисовать красивый план. Но дальше работа происходит "в черном ящике" и до самого конца нельзя убедиться в работоспособности решения. А при работе по Agile команда каждую итерацию (спринт) выныривает из черного ящика и предлагает попробовать на практике промежуточный результат. На эту тему есть красивый образ про дельфина, который регулярно выпрыгивает на поверхность, и подводную лодку, про которую пока она не всплыла вообще ничего достоверно не известно - как у нее дела и куда она приплывет на самом деле? Риски в случае с дельфинами, согласитесь, куда меньше.   
  • Когда нет открытости. Когда одна сторона пытается “наколоть” другую. 

— Александр, такой вопрос: как нам повысить уровень доверия в отношениях с заказчиком? 
— А что сейчас не так с уровнем доверия?
— Ну, у нас есть команда, есть менеджер. И мы хотим, чтобы заказчик доверял команде и общался только с менеджером. А он лезет напрямую к инженерам...

— А чем это плохо? Человек сразу получает ответы на свои вопросы, быстрые коммуникации и все такое.
— Понимаете... Мы ему джуниор-инженеров продаем как синьор-инженеров... И нам не хотелось бы, чтобы он обнаружил этот факт.    (Из книги Александра Орлова "Джедайские техники конструктивного общения")

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


Это были общие рассуждения, основанные на моем опыте и опыте моего окружения. А теперь - вопрос к сообществу.

Ответьте, пожалуйста, на вопросы опроса

Коллеги, интересен ваш реальный опыт про применение Agile в проектах 1С. Ответьте, пожалуйста, на вопросы опроса. В качестве благодарности за участие в опросе - пришлем промокод на скидку в 25% на курс по Agile.  

На вводном открытом вебинаре 25 марта  - подведем итоги. Мне вот тоже любопытно будет познакомиться с результатами.
 

См. также

Agile Бесплатно (free)

В статье рассмотрены практики, применяемые при разработке по методологии Agile.

13.05.2024    3547    0    Dimbayyyy    9    

11

Лидерство Личная эффективность Agile Анализ потребностей и поиск решений Бесплатно (free)

В семнадцатом выпуске второго сезона подкаста Радио “Аналитик“ обсудили, что из себя представляет модель Кеневин, чем и в каких ситуациях она может быть полезна тем, кто работает в сфере ИТ и не только.

19.04.2024    586    0    Radio_Analyst    0    

5

Agile Бесплатно (free)

Agile в ИТ встречается все чаще, и об адаптации гибких технологий под проекты 1С задумываются многие. Расскажем о ключевых инструментах и точках приложения усилий для успешного внедрения Scrum при разработке в 1С.

28.07.2023    2524    0    olegminkov    4    

7

Agile Руководитель проекта Россия Бесплатно (free)

Продукт команды №7, 6 поток (курс Марии Темчиной «Управление ИТ-проектами. Agile. Практический курс Agile-лидера»)

13.06.2023    1498    8    dimbasbear    1    

2

Agile Бесплатно (free)

На конференции Infostart Event 2021 Post-Apocalypse выступил директор практики БИТ:ERP компании Первый БИТ Глеб Стальной. В ходе доклада он рассмотрел трансформацию проектного подхода в продуктовый, рассказал про имплементацию «современных» практик DevOps и продемонстрировал инструменты для разработки, взаимодействия с бизнесом и клиентами, применяемые в его команде.

27.02.2023    2558    0    glebushka    2    

14

Agile Бизнес-аналитик Руководитель проекта Бесплатно (free)

Это один из вопросов, которые мне задают довольно часто. Ну да, Эджайл, Скрам, технологии, методологии,  красивые слова. Но где вы видели это в реальности в 1С внедрениях????

06.12.2021    4322    0    MariaTemchina    49    

13

Agile Бесплатно (free)

Есть сообщество в Facebook'е и Инстаграм, которое публикует жизненные комиксы про внедрение гибких технологий на практике - Comic Agile.

01.04.2021    3874    0    MariaTemchina    18    

16

Agile Руководитель проекта Бесплатно (free)

Как знает большинство старожилов Инфостарта, я люблю устраивать разного рода онлайн-обсуждения. И эта статья написана как раз по итогам такого рода вебинара-дискуссии. 

16.02.2021    5597    0    MariaTemchina    45    

33

Есть ли у меня опыт реализации проектов по Agile?


Да, есть опыт руководства (20.27%, 15 голосов)
20.27%
Да, есть опыт участия (43.24%, 32 голосов)
43.24%
Я наблюдал со стороны, как работают коллеги (8.11%, 6 голосов)
8.11%
Мне подробно рассказывали, как это происходит (6.76%, 5 голосов)
6.76%
Нет, нет опыта (21.62%, 16 голосов)
21.62%

Какие признаки Agile были в этих проектах? Почему я считаю, что это были Agile проекты? (можно выбирать несколько вариантов)


Мероприятия Agile (ежедневные летучки, демонстрации Заказчику, ретроспективы) (73.44%, 47 голосов)
73.44%
Частые релизы (62.5%, 40 голосов)
62.5%
Канбан-доски с задачами (54.69%, 35 голосов)
54.69%
Отсутствие четкого содержания проекта на старте (54.69%, 35 голосов)
54.69%
Самоорганизующиеся команды (32.81%, 21 голосов)
32.81%
Хаотичная работа (23.44%, 15 голосов)
23.44%
Это называлось словом Скрам (23.44%, 15 голосов)
23.44%
Отсутствие плана (18.75%, 12 голосов)
18.75%

По моему опыту, проекты реализуемые по Agile чаще успешны или проваливаются?


Практически всегда успешны (2.94%, 2 голосов)
2.94%
Чаще всего успешны (29.41%, 20 голосов)
29.41%
Бывает и так и так (57.35%, 39 голосов)
57.35%
Чаще всего провальны (10.29%, 7 голосов)
10.29%
Практически всегда провальны (0%, 0 голосов)
0%

Как я считаю, почему провалившиеся проекты проваливались?


Из-за применения Agile. По “классическим” методам проекты ждал бы успех (7.14%, 5 голосов)
7.14%
Независимо от применения Agile. Проекты были провальными изначально (28.57%, 20 голосов)
28.57%
Команда была некомпетентной (28.57%, 20 голосов)
28.57%
Нет подходящего варианта, напишу свою версию в комментариях (11.43%, 8 голосов)
11.43%
У меня не было опыта провальных проектов по Agile (24.29%, 17 голосов)
24.29%

Как я считаю, за счет чего успешные проекты были успешными?


Благодаря применению Agile. По “классическим” методам проекты ждал бы провал (18.57%, 13 голосов)
18.57%
Независимо от применения Agile. Команда была сильной, проект продуманным (58.57%, 41 голосов)
58.57%
Нет подходящего варианта, напишу свою версию в комментариях (7.14%, 5 голосов)
7.14%
У меня не было опыта успешных проектов по Agile (15.71%, 11 голосов)
15.71%

Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. ls600 12.03.21 09:51 Сейчас в теме
Краткая история Agile

Гибкий подход начинает своё существование где-то с первой половины XX века (хотя, есть мнение, что что-то на него похожее было и раньше). Примерно в 30-х физик Уолтер Шухарт применяет итеративный подход Plan-Do-Study-Act, которым делится со своим учеником Ульямом Демингом (сейчас мы знаем этот подход к управлению, как Цикл Деминга). После окончания Второй мировой, компания Toyota (та самая, где придумали Lean, Kanban и много чего ещё, связанного с Agile) нанимает Деминга обучить своих менеджеров.

В следующие годы во многих компаниях придумывают свои методики гибкого управления: Scrum, XP, FDD и так далее. Но про «agile» никто не говорит до 2001 года, пока 17 разработчиков, практикующих методики гибкого управления, не собираются вместе и не составляют Манифест гибкой разработки программного обеспечения (Manifesto for Agile Software Development или просто Agile Manifesto). Здесь и возникает понятие «agile», вокруг которого сегодня столько разговоров.
nekit_rdx; rpgshnik; RustIG; +3 Ответить
2. user633533_encantado 11 12.03.21 10:07 Сейчас в теме
Видел реализацию одного проекта по этой методике , не 1С. Я принимал там участие со стороны заказчика, писал модули взаимодействия из 1С для этого продукта.
Кончилось все большой потерей денег и увольнением одного из ключевых руководителей.
3. ishelper 12.03.21 10:38 Сейчас в теме
Пришиваем хвост
Лишь бы это не оказался такой хвост, который не надо пришивать: https://bash.im/quote/464504
4. starik-2005 3060 12.03.21 10:41 Сейчас в теме
1. А если у меня есть опыт внедрения, руководства, фассилитации, работы в команде со спринтом, ... - что выбирать? )))
2. А что значит "какие признаки были"? Эджайл работает только в комплексе. Да, любой элемент может добавить энергии системе, но система без онтологии - она не будет работать так, как надо. У Маска фэльконы падали раз дохрена, но после перестали падать от слова "совсем", теперь та же штука со старшипом, а наши "уважаемые" "специалисты" рассказывают, что это "игра".
3. А что такое "проект" на эджайле? Что вообще в голове РПшников под словом "проект" понимается и как это вообще к эджайлу относится? На мой взгляд, эджайл - это средство разработки и развития продукта, а не просто какой-то проект внедрения ЕРП, например. ЕРП не нужно разрабатывать, а внедрение - это инцидентный процесс, который все ломятся завернуть в гибкую методологию, как будто это продукт. В действительности для внедрения какой-нить ЕРП нужно понять прежде всего, что 1С - это просто хранилище событий. Вот нужно сделать так, чтобы все события собирались системой и все данные событий присутствовали. Тут программирование не нужно вообще - есть доп.реквизиты, свойства и т.д. После классификации и разбора событий нужно завернуть их в процессы. В ЕРП есть куча АРМ, которые нужно обогатить собираемыми аспектами регистрируемых событий. Дальше отчетность, которую вообще лучше в ЕРП не собирать - только оперативную на бух.регистре. Вот вам пул задач, которые можно замунуть в спринты, разделив по командам )если их больше одной, в чем я, лично, сомневаюсь - и какой там эджайл?).
4. Ну уж точно не из-за эджайла что-то там "проваливается". Я вообще не понимаю, как можно сделать так, что проект "провалился". Это, имхо, бред. Если эджайл ради эджайла, то и проекта нет, т.к. никто не знает, что нужно заказчику (который и подавно не знает, ио он ЕРП внедряет, потому что слышал, что там есть бюджетирование и планирование, которое отлично и без косяков ведется в экселе за почти "так". Проект проваливается из-за отсутствия аналитика, который понимает, что нужно. А как этот аналитик будет работать - вообще никак к делу не относится.
5. Ну так обратно - проекты успешны тогда, и только тогда, когда на проекте есть люди, которые понимают, что нужно делать. Это бывает не часто, эджайл тут ни при чем. Он просто помогает вернуться к развилке, если пошли не туда (в отличие от водопадов, например, которые не "игра" якобы - просто распил бабла). В этом его преимущество. Но если нет того, кто сможет защитить свою позицию и доказать, что "мы идем не туда", то и эджайл не поможет дурачкам и дурочкам.
nekit_rdx; Birby; Артано; FatPanzer; AlenaR; CheBurator; ProfBT; +7 Ответить
5. Maxisussr 12.03.21 10:48 Сейчас в теме
(4)
провалился". Это, имхо, бред. Если эджайл ради эджайла, то и проекта нет, т.к. никто не знает, что нужно заказчику (который и подавно не знает, ио он ЕРП внедряет, потому что слышал, что там есть бюджетирование и планирование, которое отлично и без косяков ведется в экселе за почти "так". Проект проваливается из-за отсутствия аналитика, который понимает, что нужно. А как этот аналитик будет работать - вообще никак к делу не относится.


Наверное, под провалом понимается
- выпадание из бюджета более чем на 200%
- срыв намеченных сроков более чем в 2 раза,
- либо же в принципе невозможность реализовать проект (команда некомпетентна, но этого наверное просто компенсируется сроками)

Чтобы понять - провал это или нет - нужно расставить цели изначально. Т.е. к 01.01.2021 все должны работать в новой системе, с 01.01.2022 (не позже) - сдавать отчетность из новой системы и т.п. Все же 99% имеют какую-то цель, срок.
Я лично немного не понимаю, считается ли это "правильным" Agile , если есть какие-то сроки и цели, но без них - никуда.
22. starik-2005 3060 12.03.21 12:01 Сейчас в теме
(5) В принципе, эджайл определяет цель, как направление. Цели - они постоянно меняются, т.к. меняется бизнес-среда, конъюнктура, даже состав управления. В любой момент может выявиться какая-нибудь потребность новая, которая приведет к переработке процессов, добавлению хранимых и значимых аспектов в события. Может обнаружится системная ошибка раннего этапа (архитектурная, методологическая, управленческая) - все это потребует изменения вектора. В эджайле можно корректировать вектор, в эджайле есть ретроспективный анализ и прочие моменты, которые позволяют пересобрать систему заново, работать с ошибками.ю как с еще одним ресурсом. Всего этого зачастую лишены более жесткие подходы, а использовать в них элементы ретроспективы - это риск переработки проекта целиком, т.к. тех.задание - это продукт проектной деятельности, и без него сложно что-то начать перерабатывать в негибкой методологии.
44. RustIG 1720 13.03.21 09:04 Сейчас в теме
(5)
Чтобы понять - провал это или нет - нужно расставить цели изначально. Т.е. к 01.01.2021 все должны работать в новой системе, с 01.01.2022 (не позже) - сдавать отчетность из новой системы и т.п. Все же 99% имеют какую-то цель, срок.
Я лично немного не понимаю, считается ли это "правильным" Agile , если есть какие-то сроки и цели,


искусственно созданные сроки...

как часто любят их озвучивать сверху.....
как часто непрофессионально их озвучивают снизу.....

провал не минуем.... а может статься, что-то кто-то из исполнителей ночами доведет до ума задачи и сдвинет проект, и свалится в хроническую болезнь...но в рапорте для учредителей об этом не будет ни слова....
45. RustIG 1720 13.03.21 09:10 Сейчас в теме
(4) смешали компетенции и культуру ведения проекта...

эджайл - это правила игры, правила движения по дорожной карте проекта (по аналогии с ПДД - правилами дорожными движениями),

есть ПДД, а есть отдельный элемент - это навык практического вождения .... сравнивать их бессмысленно...

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

.
50. starik-2005 3060 13.03.21 12:56 Сейчас в теме
(45) так вот в том у многих и проблема, что они пытаются правилами вырулить проект при плохой команде. Разберитесь как-нить с CMM и CMMi - это уровень зрелости процессов и путь его совершенствования. Да, сильная команда с плохими процессами будет эффективней слабой команды с хорошими процессами, а эджайл - это лишь элемент хороших процессов, совокупность коих куда шире гибких методологий.

Пример: боинг со своим пилотируемым кораблем и спейзикс с драгоном - процессы везде супер, но команда боинга явно хуже.
69. Артано 766 14.03.21 14:34 Сейчас в теме
(50) Могбы согласиться, но хотел бы уточнения. Что понимается под сильной командой? Сплоченный коллектив профи? Или рандомный набор хороших специалистов? Просто в первом случае, у команды и будет получаться тот же самый эджайл, но без сопутствующих ритуалов.
74. starik-2005 3060 16.03.21 12:18 Сейчас в теме
(69)
Сплоченный коллектив профи? Или рандомный набор хороших специалистов?
Хорошая команда - это хорошие компетенции, гну и без особого желания друг друга убить, конечно )))

Для того, чтобы "эджайл" появился в сплоченном коллективе, нужно, чтобы коллектив про это хотя бы знал что-то и хотел узнать больше. В скраме есть скрам-мастера, которые постоянно попинывают команды (у меня друг работал в Сбертехе - очень сильно этому сопротивлялись некоторые РП, потом в Альфе - там это было принято на ура, пока туда не зашла "водопадная" команда из Бина, сейчас в Кроне вропде бы - там тоже все ок). Но суть всего этого "безобразия" - постоянная поддержка фокуса. В даже очень хорошо работающей и сплоченной команде фокус иногда разбегается, а "оптические оси" "протирать" некому.
85. Leon75 17.12.21 21:27 Сейчас в теме
(4)
Я вообще не понимаю, как можно сделать так, что проект "провалился". Это, имхо, бред.

А Вы часто видели проекты в JIRA с техническим названием "Road to Hell"?
86. starik-2005 3060 18.12.21 02:28 Сейчас в теме
6. ProfBT 12.03.21 11:00 Сейчас в теме
Добрый день!
Пишу свои варианты в комментариях)
Успех проекта зависит не от методологии, людей, работающих над проектом или еще какого-то одного фактора. Успех зависит от совокупности факторов и возможностей лидов увидеть правильный состав этой совокупности.
Важно видеть, как можно работать с этим заказчиком, готов ли он к той или иной методологии. Важно донести до него плюсы той или иной методологии применительно к текущему проекту. Понять заинтересованность заказчика в проекте. Для чего проект? - Реальная необходимость, блажь или повод потратить бюджет.
Далее нужно выбрать подходящие инструменты. Чтобы проект двигался, но при этом чтобы его не задавило бюрократическим БТР-ом.
Если все вышеописанное сделано правильно, то теперь ключевую роль будет играть команда и взаимодействие внутри нее и с заказчиком.
7. DitriX 2098 12.03.21 11:00 Сейчас в теме
Опять очередная чушь про эджайл подходы.
Вы тогда в статье укажите, что вы говорите только про часть эджайла. Ту, которая про людей. А то у вас тут и половины эджайла не описано. Причём самой главной половины.
Без нее - эджайл это просто про встречи людей с заказчиком и внутри команды.
А с ней - оказывается что эджайл становится органической частю команды,и вытекает сам по себе.
И вот если бы вы начали с нее, то у разработчиков бы и вопросов не было. ИМХО
morin; Yashazz; +2 Ответить
9. RustIG 1720 12.03.21 11:16 Сейчас в теме
(7) Дмитрий , какие у вас вопросы? Какие вопросы у разработчиков?
Тема эджайл неисчерпаема.
Одними ответами на вопросы - тут не обойтись.
11. DitriX 2098 12.03.21 11:19 Сейчас в теме
(9)тема вполне исчерпаема. Если аджайл не цель, а следствие.
12. RustIG 1720 12.03.21 11:25 Сейчас в теме
(11) Я не понимаю наш диалог когда такими терминами начинаем говорить про эджайл: цель или следствие? быть или не быть? вот в чем вопрос....

для тема неисчерпаема - учиться можно всю жизнь - от проекта к проекту, от человека к человеку, от технологии к технологии... была бы тема исчерпаема, не было бы подобных курсов https://kogio.ru/knowledge/project/
19. DitriX 2098 12.03.21 11:47 Сейчас в теме
(12) все, простите, посыпаю голову пеплом.
В русском сегменете половина статей про agile и все что с ним связано - написано именно в стиле управленческого подхода. Теперь я понимаю - почему я ни разу не мог понять русских внедренцев аджайла. Но при этом - с англоговорящими, мы были на одной волне.
Все, я сливаюсь. В споре нет никакой необходимости.

И я теперь понимаю этих бедных разработчиков, которых заставляют вот по этим методикам работать :(
user768000; +1 Ответить
10. RustIG 1720 12.03.21 11:17 Сейчас в теме
(7) у большинства элементарно нет культуры вести проекты. Научился в школе программировать и побежали программировать другу-бизнесмену.
Я учился у Марии, и смею заявить, что Мария прививает ту самую культуру вести проекты, переговоры.
14. DitriX 2098 12.03.21 11:27 Сейчас в теме
(10)вот за что я и говорил. У вас не верный подход. Вы хотите идти от управляющего, который руководит разработчиками и вот он не справляется, давайте его научим.
Подход, как мне кажется - в корне не верный.

Или надо от исполнителей и сделать так, что бы они не дали возможности работать по другому никому. А они это сделают, если это им будет удобно, если будут минимизированы человеческие факторы, если руководство не идиоты, которым пофиг на цикл и они могу его нарушить в любой момент.

И вот потом только рождается эджайл.
Сажать зерно в не подготовленной почве - бред. А на это никто не обращает внимание. А почему? а потомучто аджайл мастера - не технари от слова вообще. Мы привыкли что на все внедрения нужен программист и внедренец. Чаще может справится просто программист. Но внедренец без программиста - врядли пойдёт настраивать что то сложне кассы. А в аджайле - люди не подкованные в технике - идут советовать компании внедрять технологии, из которых больше моловины - это техническая составляющая. И при этом они или в ней ничего не понимают, или ничего не говорят.
tolyan_ekb; Birby; +2 Ответить
18. RustIG 1720 12.03.21 11:45 Сейчас в теме
(14)
а потомучто аджайл мастера - не технари от слова вообще. Мы привыкли что на все внедрения нужен программист и внедренец. Чаще может справится просто программист. Но внедренец без программиста - врядли пойдёт настраивать что то сложне кассы. А в аджайле - люди не подкованные в технике - идут советовать компании внедрять технологии, из которых больше моловины - это техническая составляющая. И при этом они или в ней ничего не понимают, или ничего не говорят.


все верно Дмитрий, и Мария думаю с вами согласится, что на наших 1с проектах нужен человек 1с-ный с опытом и знанием предметной области, архитектуры решений, а не просто мастер по эджайл.
8. RustIG 1720 12.03.21 11:14 Сейчас в теме
Для тех , кто сомневается:

Забудьте про эджайл. Представьте, что его нет. И спорить вам больше не о чем будет.

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

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

Назвали эджайл. По русски - гибкость.
Это просто альтернатива.

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

Чтобы уйти от подобных рисков в строиельстве, в разработке ИТ стали применять подобный подход.
Параллельно стали появляться инструменты: канбан-доска и многое другое.

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

Со временем инструментарий эджайл будет доступен всем с мобильного телефона (трелло к примеру)....
В общем, пора остыть от споров.
54. Dragonim 140 13.03.21 13:29 Сейчас в теме
(8) Если я правильно понял ваш комментарий, то желание применять эджайл на проекте должно исходить от заказчика. Я вас правильно понял?
13. Torin 782 12.03.21 11:25 Сейчас в теме
Почему так много заимствованных иностранных слов? Есть ГОСТ Р ИСО 9001-2015 ( Система менеджмента качества ) есть пункт 8.2 и 8.3 .. если компания придерживается требований СМК и не важно какая сфера ИТ или обработка металла, то проблем нету.. так как все описано прописано и каждый сотрудник знает что как зачем и почему! А если не придерживается требований ? ... то 15 минутки в день превращаются в митинги!
15. RustIG 1720 12.03.21 11:28 Сейчас в теме
(13) у фирмы 1с для партнеров есть свой стандарт технология быстрого внедрения - вроде так называется.... и все равно много провальных проектов.... для меня - так стоит не вспоминать о всяких гостах, но знать о них следует.... для меня в эджайле важно - иметь культуру вести проекты - от задачи к задаче - видеть картину в целом - быть не только программистом, но и архитектором, уметь донести и согласовать все затраты, риски с Заказчиком, предвидеть самому все риски - это в гостах есть?
16. Torin 782 12.03.21 11:34 Сейчас в теме
(15)
видеть картину в целом - быть не только программистом, но и архитектором, уметь донести и согласовать все затраты, риски с Заказчиком, предвидеть самому все риски - это в гостах есть?


"Организация должна применять средства управления процессом проектирования и разработки для обеспечения уверенности в том, что:

a) результаты, которые должны быть достигнуты, определены;

b) проведены анализы для оценивания способности результатов проектирования и разработки выполнить требования;"
и так далее
17. RustIG 1720 12.03.21 11:43 Сейчас в теме
(16)
применять средства управления процессом проектирования и разработки

о каких средствах идет речь? это вы цитируете ГОСТ?
мы с вами ситуацию по рынку представляем одинаково?
я селфмейд - меня никто гостам не учил, пришел в бизнес 1с с улицы....
делаю проекты...учусь всему полезному. считаю курс Марии - одним из полезных.
Есть еще полно технических курсов - тоже полезны для работы....

Откуда столько споров?
Я впервые о программе Трелло услышал от Марии.
До меня 1с-ники - старшее поколение - вообще делали проекты без средств правления процессом проектирования и разработки - один блокнот в руках и диск ИТС в кармане....
21. Torin 782 12.03.21 11:58 Сейчас в теме
(17)
считаю курс Марии - одним из полезных.
Есть еще полно технических курсов - тоже полезны для работы....
- я не говорил что они бесполезны :)
(17)
До меня 1с-ники - старшее поколение - вообще делали проекты без средств правления процессом проектирования и разработки - один блокнот в руках и диск ИТС в кармане....

Я вам рекомендую фильм посмотреть "Обычный месяц" 1976 года !
Leon75; RustIG; +2 Ответить
24. RustIG 1720 12.03.21 12:16 Сейчас в теме
(21)
"Обычный месяц" 1976 года

спасибо)
посмотрю
46. RustIG 1720 13.03.21 09:20 Сейчас в теме
(21) https://ru.wikipedia.org/wiki/%D0%9E%D0%B1%D1%8B%D1%87%D0%BD%D1%8B%D0%B9_%D0%BC%D­0%B5%D1%81%D1%8F%D1%86

"Главный инженер приборостроительного завода Греков ищет выход из тяжёлого положения, сложившегося на заводе: подводят поставщики — приходится прибегать к штурмовщине, нарушается технология, страдает качество. Институт проблем управления производством, в который Греков обращается за помощью, предлагает внедрить на заводе новую, ещё не испытанную систему автоматизированного управления. Греков соглашается, хотя коллеги, все как один, считают, что он выбрал для этого не самое удобное время. "

Стоит посмотреть :)
20. CheBurator 3126 12.03.21 11:51 Сейчас в теме
"Предложили и начали использовать кусочки - итерации - шаг за шагом, оценивая бюджет-сроки-ресурсы, по сути ставя в известность Заказчика по факту."
- это хорошо конда покупаемое состоит из кучки самостоятельных самоценных мелочей.
а если? - заказчика не интересует стоимостиь колес, кузова и коробки передач. а также сроки их изготовления. Заказчику нужен автомобиль. Аджайл хорошо там где заказчик согласен платить за ПРОЦЕСС.
.
имхо.
VladimirMelnychenko; Torin; +2 Ответить
25. RustIG 1720 12.03.21 12:20 Сейчас в теме
(20) там где есть послепродажное сопровождение, я бы уточнил так...
для вашего примера покупка автомобиля - для одних коробочное решение с тарифом Базовый комплект, или Премиум-пакет...
а для кого-то нужен рестайлинг по своим эскизам + усилитель двигателя поставить, чтоб гонять по дорогам....и тут уже начинаются переговоры, согласования, тесты и пробы, и возможно очередной рестайлинг....

вообще примеры эджайла лучше обсуждать на более сложных продуктах - например в строительстве - ну любой проект - архисложный
27. CheBurator 3126 12.03.21 13:24 Сейчас в теме
(25) именно. все так и есть. когда автомобиль покупается чтобы ездить - это одно. чтобы его тюнинговать а потом ездить - это другое. но даже при тюнинге есть условие - мне пофиг как вы будете делать тюнинг, частями или скопом. тюнинговый - должен разгоняться до 100 за 3 сек. ВСЁ. я покупаю РЕЗУЛЬТАТ. причем нафиг весь этот тюнинг д.б. сделан к началу гонки. понятно что тут снова трыкутнык -скорость-качество-стоимость. Я готов платить за процесс - с неясным конечным результатом, неясным сроком окончания процесса, с неясным бюджетом - ЕСЛИ МЕНЯ НИЧТО НЕ ЖМЕТ. тогда да, я (заказчик) могу дотачивать, улучшать, добавлять фичи. потому что меня - НЕ ЖМЕТ. мой мелкий опыт показывает что заказчика ВСЕГДА ЧТОТО жмет. Сроки, деньги, итд. У когото опыт побольше, может им посчастливилось делать проекты, где было комфортно...
29. CheBurator 3126 12.03.21 13:32 Сейчас в теме
(25) тот кто покупает авто с последующим тюнингом стопудово уже имеет то на чем он ездит сейчас. поэтому может позволить "аджайлный тюнинг". а если покупает авто с тюнингом, но четко знает что через две недели текущий авто развалится, то услвоие на тюнинг будет простое - вот вам две недели - аджальте как вам угодно, но через две недели - у меня рабочее авто д.б. которое умеет ездить. будет стоять регулируемое антикрыло - зашибись вот вам деньги на антикрыло! (производитель ВАСЯ), к антикрылу - электронная система управления/вклдючения антикрыла - зашибись, вот вам деньги (Производитель ПЕТЯ). К сроку готвоности - если не будет Вася+Петя - хрен с ним, обойдусь без антикрыла, но деньги вы мне вернете И ЗА ВАСЮ, И ЗА ПЕТЮ, а крыло или систему управления - оставбье себе, мне половинка нафиг не нужна, потом впилите на очередной адажйлпроект другому люителю тюнига.
.
как-то так в моем понимании аджайла как заказчика.
30. RustIG 1720 12.03.21 15:35 Сейчас в теме
(29) все это разговоры, не более того...учиться лучше на больших проектах....меня например вдохновляют истории о крупных проектах Евгения Кагановича (APT-Group)... До сих пор для меня это человек -загадка...Как он умудряется писать такие статьи?
Которые расширяют не только кругозор, но раскрывают масштабы проектного управления....Понимаешь, что мы мелко плаваем....
31. CheBurator 3126 12.03.21 16:24 Сейчас в теме
(30) это да.
.
пока ничего не понятно мне что есть минимальный временной интервал на котором результаты аджайла принимаются как самостоятельная ценность. вот есть офигенный проект. пилится по этапам. каждый этап если он успешно завершен - имеет самостоятельную ценность и даже если проект не завершен - результат этапа уже дает плюс Заказчику и заказчик с этим согласен.
.
а вот если этап не завершен - имеет то что сделано внутри незавершенного этапа ценность для Заказчика? если да - ТО ЧЕМ ЭТО ОПРЕДЕЛЯЕТСЯ? чем это будет подтверждаться в юридических проблемах/спорах? пусть внутри этапа куча всякой аджайлности, спринтованости, канбаности и прочих технологий и инструментов. Но тогда любой несогласованный ранее в ТП/ТЗ чих который МЫ заказчик и исполнитель согласились сделать - должен обвешиваться кучей бумажной бюрократии. будет ли это полезно в рамках приенения инструментов гибкой разработки? очень сомневаюсь.
.
всякими гибки метолдиками хорошо делать когда деньги НЕ ТВОИ - проинвестировали тебя - ваяй! может что-то получится...
34. DitriX 2098 12.03.21 20:31 Сейчас в теме
(31) Это то, о чем я говорил выше - аджайл, это следсвие внедренных технологий и практик. Структуризация их. А не наоборот. И вот когда внутри компании все есть для аджайла - он приходит сам собой, и от него потом не отвертеться.
А когда приходят на производство, на завод, который еще не ввели в эксплуатацию, и где не знают, что по тех процессу будет раньше - засыпаться мука, или вода, и какая вода будет. А тут приходит аджайл - и такой, все, теперь мы делаем гибкое планирование. теперь у нас будут итерации, мы будем делать тесто, мы будем опрашивать заказчика, менять состав, делать, менять , делать, спрашивать и т.д.

А тут технолог такой сидит, и типо - стопэээ. А что раньше делать? Сыпать муку, или лить воду? И все, вот тут аджайл и говорит, типо - ну нам пофиг, вы главное тесто делайте. Вот в этом и ошибка всех аджайл мастеров, в ковычках.

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

Поэтому когда я прихожу внедрять технологии внутри компании, и мне говорят что у них аджайл, то я их поправляю, что если бы у них был аджайл, у них бы уже были все те практики, которые мы им внедряем. А сейчас - у них просто канбан, и управленчиская воля. Вот и все проблемы.
35. RustIG 1720 12.03.21 22:42 Сейчас в теме
(34)
Сыпать муку, или лить воду?

Обычно Заказчики просят посчитать проект в рублях и в сроках на оба варианта:
"Почитайте нам оба варианта, пришлите КП, мы с вами свяжемся..."
Это тот случай, когда я сталкиваюсь на проектах с классическим подходм, иногда его называют водопадом...Такое используешься на тендерах. И консультанты и внедренцы с командой разработчиков становятся заложниками таких условий...

Эджайл предполагает несколько моментов - например один из которых это регулярные встречи с Заказчиком.... Как только вы переходите на регулярные встречи, показываете еженедельно, или раз в две недели, что уже сделано, корректируете совместно курс, это уже не водопадная модель....

А ТЗ есть в обоих вариантах - что при водопаде, что при эджайле - только объем ТЗ и горизонт планирования работ сильно отличаются в разных подходах....

Дмитрий, найдите Евгения Кагановича (APT-Group) - прочитайте любой его проект....
Что водопад , что эджайл - ни один подход не застрахован от непредвиденных ситуаций, о которых пишет Евгений....
И как говорит Насиб Талеб - наша задача не спрогнозировать успех, а снизить к минимум риски потерь при возникновении непредвиденных ситуаций.... В этом смысле эджайл более спасительный подход....

Хотя не все проекты стартуют по эджайл....Чаще это смешанный тип... Но регулярность встреч всегда на пользу , как бы вы это не называли....
37. CheBurator 3126 13.03.21 00:46 Сейчас в теме
(35)
Как только вы переходите на регулярные встречи, показываете еженедельно, или раз в две недели, что уже сделано, корректируете совместно курс, это уже не водопадная модель....

пофиг как часто встречаются. это не дает ответа на вопрос - кто будет платить за невыполненный вовремя проект у которого есть вполне четкая дата и вполне четкий бюджет. ну встречаемся 2 раза в неделю. ну понимаем что трындец, не уложимся в сроки\бюджеты хоть проаджалься сверху донизу. ни сроков ни бюджета - мы подвигать так ощутимо чтобы уложиться ни заказчик ни исполнитель не могут. Аджал тут поможеттолько раньше понять что трындец. и все.
.
если - заказчик\исполнитель могу произволно двигать сроки\бюджеты вместе или по отдельности - то и проблем бы не было.
42. RustIG 1720 13.03.21 08:17 Сейчас в теме
(37)
кто будет платить за невыполненный вовремя проект у которого есть вполне четкая дата и вполне четкий бюджет


Если в договоре прописаны даты и санкции, то я, к счастью для себя , в такие проекты не лезу - здоровье дороже...

В моем плане прописаны этапы, длительность каждого этапа, а когда стартанет каждый этап не прописан и когда закончится тоже не прописано. Потому что это зависит не только от меня, но и от Заказчика - а он сам точно не знает...
38. CheBurator 3126 13.03.21 00:51 Сейчас в теме
(35)
Хотя не все проекты стартуют по эджайл....Чаще это смешанный тип... Но регулярность встреч всегда на пользу , как бы вы это не называли....

- это да, против этого не попрешь.
.
большая от этого польз? ну вот есть РП, команда. они работают на своего ДЯДЮ. дядя им платит зп. откажутся они от проекта даже при частых встречах? придут к своему руководству - мы вот тут обнаружили что приближается жпс. надо увеличивать либо человекорурс, дядя: - фиг вам, бюджет денег и ресурсов утрясен на проект. и что дальше делать в рамках аджайлного подхода?
.
все это мне непонятно одно - я так и не увидел более-менее четких критериев, которые позволяют мне придти к заказчику, посмотретьи сказать - проект с фиксированным сроком и фиксированным бюджетом не взлетит. Что мне скажет исполнитель на предложение а давате типа без сроков и бюджета поработаем, будем чаще встречаться..?
43. RustIG 1720 13.03.21 08:22 Сейчас в теме
(38) по эджайлу есть книги в открытом доступе в интернете на русском языке - там много рабочих примеров. Прошу что-нибудь прочиать, каждая книга от 120 - до 200 страниц может быть.... Я не смогу ответить на все ваши вопросы.... Вы можете применять технологию эджайл, не подозревая об этом, потому что у вас накоплен опыт.
Читая книгу, вы будете часто думать, что вы это используете однако....В конце прочтения решите что вы все делаете правильно в своей работе...И у вас останется ощущение тотальной завершенности и даже умиротворенности...
40. DitriX 2098 13.03.21 01:11 Сейчас в теме
(35) вы про теплое, а я про зеленое :)
Вобщем я кажется понял где затык, вы же все это сейчас говорите про компании, которые не имеют отношения к разработке софта. В таком случае - полностью вас поддерживаю.

Если же вы хотите сделать это в IT компаниях, а наложить аджайл на выпуск софта, например, то я сочувствую тем компаниям.
Так как для IT компаний есть более современный и правильный подход. Но, его, без знания технологий - внедрить не получится. А аджайл мастеров то много, вот и топят за свое.

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

Аджайл в IT компании применим, если там работает 2-3 взаимозаменяемых разработчика, которые пилят один и тот же продукт, а шаг влево, и все, аджайл становится камнем и все рушится.
23. graphbuh 260 12.03.21 12:08 Сейчас в теме
На самом деле 1С Версии 7.7, 8.0 было воплощением Agile подхода. На ходу можно было слепить решение, закрывающее 80% функционала. Сейчас на это надо в 3 раза больше времени. 1 хороший специалист мог автоматизировать большое предприятие. Код был простой, легкий. Сейчас мы видим отход от тезиса 1С как продукт инженерной мысли в пользу 2 кодера + 10 консультантов + 1 рп это больше денег.
user768000; morin; ccserg; CheBurator; +4 Ответить
26. Torin 782 12.03.21 12:28 Сейчас в теме
(23)
Сейчас мы видим отход от тезиса 1С как продукт инженерной мысли в пользу 2 кодера + 10 консультантов + 1 рп это больше денег.
- не соглашусь с вами .
Посмотрим пример БП3.0 ... сколько в месяц выходить релизов? 4-5 ? а патчей? по 20 штук после выхода релиза!

А ведь это " Типовой продукт" !! "тяп ляп и готово , утром выпустим патч или новую версию"
28. CheBurator 3126 12.03.21 13:26 Сейчас в теме
(26) это всего лишь свидетельствует об отставании разработчиков в методах организации работ по производству продукта. Использование отсталых инструментов возможно. Причина - рынок схавает.
41. DitriX 2098 13.03.21 01:56 Сейчас в теме
(28) Нет, вы что. Это же и есть сам аджайл в чистом виде. Так что 1С в данном случае - это чистый аджайл.
Аджайл в манифесте своем так и говорит - давай быстрее, а на качество пофиг. Давай проще, на документацию забей. Давай выпускай, а там пофиксим.
Аджайл за это и говорит. Так что вот к этому и приходят IT компании, которые следуют аджайлу. Им главное что то выпулять, а потом собирать фидбеки и фиксить.

И именно поэтому - я и гвоорю, что аджайл для айти компаний - это бред. Уже лет 10, применяются другие подходы, которые так раз и нацелены на то, чтобы не было такой дичи.
Т.е. есть уже адекватные практики, которые рожденны были из аджайла, и которые лишены его недостатков.
Поэтому почему до сих пор кто то топит за аджайл для IT - для меня загадка.
И по конференции 1с видно, что они тоже переходят на эти новые практики, что не может не радовать.
CheBurator; +1 Ответить
32. ccserg 64 12.03.21 18:43 Сейчас в теме
любой проект начинается с ТЗ , по ТЗ определяют бюджет , то что вы предлагаете это "выуживание бюджета" на руку разработчику ;)))
CheBurator; +1 Ответить
65. rpgshnik 3746 13.03.21 17:13 Сейчас в теме
(32) но в тоже время свою попу исполнитель не прикроет ТЗ, фраза "а вот это вы не предусмотрели ха-ха-ха" уже не работает в Аджайл
67. ccserg 64 13.03.21 22:44 Сейчас в теме
(65)
Аджайл не отменяет ТЗ ))) любая работа закрывается актом
33. R_Wanderer 12.03.21 18:54 Сейчас в теме
Всем доброго времени!

Agile-манифест
Принципы Agile

Суть подхода достаточно понятно изложена.

Я бы еще большими буквами написал "КОМАНДА ПРОФЕССИОНАЛОВ НАЦЕЛЕННАЯ НА РЕЗУЛЬТАТ"

Сейчас анализируя прошлый опыт, я говорю, да - это работает.
39. CheBurator 3126 13.03.21 00:55 Сейчас в теме
(33) профессионалы работу не ищут. работа сама находит профессионалов и здесь они - профы - диктуют правила игры с заказчиком. прослойка профессионалов - чертовски мала. КОМАНД ПРОЕССИОНАЛОВ - еще меньше. Итог - аджайл от основной массы работающих специалистов-ремесленников чертовски далек. в топку.
63. rpgshnik 3746 13.03.21 17:01 Сейчас в теме
(39) Аджайл это коммунизм в разработке и на внедрениях. А одинесники, особенно старой закалки, по умолчанию все капиталисты. От сюда и не любовь :)
64. user1534961 13.03.21 17:09 Сейчас в теме
(63) Поддерживаю. Одинесники старой закалки пришли на готовые приложения акцесс/фокспро/клиппер/ексель и не понимают, что с нуля начинать можно только коммунизм... А для начала надо выявить эту самую добавленную стоимость 1С.
Например, что снегопат с его предсказанием после точки это логика фокспро/клиппера, в которой указатель спозиционирован на объект и индексы подтягивают любые связи - можно спокойно получать после точки все что захочешь. Я хотела понять, работает ли этот принцип в файловой базе 1С, поскольку в SQL это точно не работает.
36. user1561667 12.03.21 23:55 Сейчас в теме
Эджайл скрам? Фак ю айм рашн. Уяк Уяк и в продакшн.
VOA2009; rpgshnik; +2 Ответить
47. RustIG 1720 13.03.21 09:53 Сейчас в теме
(4), (7), (20)
так уж получилось, что вы, как гуру 1С, не принимаете эджайл. Ваш опыт сталкивается с эджайл, и эджайл проиграет вам в этом споре.

Вот пример: у вас на любую хотелку Заказчика есть сразу ответ в голове - "возможно, не возможно, 10 причин почему невозможно, риски, 10 аргументов как сделать оптимально, быстро и с наилучшими результатами и много еще чего"

У эджайл будет - "ок, зафиксировали, передадим спец-аналитику на анализ требований, оценим трудозатраты, сроки, выберем исполнителя, подготовим тестовый пример (интерфейс), встретимся и обсудим детали...."

Вуаля!

Для новичка в профессии будет все наоборот: Директор говорит надо сделать то-то к завтра. Новичок без опыта думает ему не хватает опыта делать это быстро... И это печально....
По эджайл все выглядит по другому: у каждого специалсита есть своя скорость выработки и решения вопросов/задач, и эджайл скажет, что к завтра этот специалсит ну никак не сделает эту работу... Все!
48. DitriX 2098 13.03.21 10:39 Сейчас в теме
(47) вот тут и есть особенность. Аджайл скажет когда оно будет готово в теории. В такой очень и очень мутной теории.
И даже не будет готово, а просто будет накидан тяп ляп и все. А новый разработчик в команде вообще ничего внятного ответить не сможет, у него вообще никаких ориентиров. Мы же помним - документацию в топку.

Вот это все аджайл и порождает. Всем пофиг на качество. Главное в срок. Нет никаких критериев - кроме срока и формального выполнения условий задач.

А потом мы имеем бухию с десятком тысяч смел кода. Потомучто аджайл это поощраяет.

И ещё раз - я за здравый смысл, а аджайл -это уже давно невесть что стало для it компаний.
Почему?та все просто, аджайл не отвечает ни на какие вопросы,а только их задает, это как религия. Типо если вы сами допетрили,то аджайл вы смогли внедрить, если не дошло до вас, то проблема сугубо ваша.

Мне интересен пример - как аджайл говорит настроить работу отдела разработчиков так, что бы им гибкие практики помогали, причём реально помогали. Как? А никак.
Он говорит - ну вы там типо самооргаеизуйтесь. Шта?

Можете мне привести пример, Статью, видео,та что угодно, где бы рассказывалось как аджайл помог отделу разработки? Думаю что нет. Потомучто аджайл про то, что нам надо каждое утро мусолить табуретки. А не технологии.

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

Ну и как вишенка на торте -аджайл замедляет работу отдела разработчиков,причём существенно замедляет. И не говорить об отвественности разработчков, а только о том. Что ему через неделю надо выплевать софт. Все.
51. nickpugachev 13.03.21 13:08 Сейчас в теме
(48)
Мы же помним - документацию в топку.

В каком месте манифеста вы об этом прочитали?

Вот он весь:
Люди и взаимодействие важнее процессов и инструментов
Работающий продукт важнее исчерпывающей документации
Сотрудничество с заказчиком важнее согласования условий контракта
Готовность к изменениям важнее следования первоначальному плану

То есть, не отрицая важности того, что справа,
мы всё-таки больше ценим то, что слева.

И обратите внимание на последнее предложение

Сам по себе манифест - не руководство. Если обсуждать - то обсуждать конкретные фреймворки и методики.
Какая из методик вас задела? scrum, которого практически не существует в чистом виде?
52. DitriX 2098 13.03.21 13:25 Сейчас в теме
(51)
так вот же он:
Работающий продукт важнее исчерпывающей документации

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

А что если я скажу так, что Работающий продукт, это продукт, который полностью соответствует документации, и работает согласно ей?
Что если для меня - процессы важнее людей, так как их можно массштабировать, и процессы и инструменты могут контролировать людей. И я хочу всегда знать где и что у меня и на каком уровне, просто открыв телефон. А не спрашивать чьего то мнения, которое может быть ошибочным, субъективным, мне могут соврать, меня могут обманывать сотрудники и т.д.
С заказчиком мы начинаем работать тогда, когда согласовали контракт, я плохо себе представляю, как можно начать с кем то работать, если там нет хоть минимального списка условий.

Ну и т.д. Печально люди застряли в прошлом, это как раньше, фиг знает сколько лет подряд был популярен Git Flow, он был пипец не имоверным, почитайте про него, про его правила и прочее - там черт ногу сломит.
Ему на замену пришел GitHub Flow, который состоит из 4 конкретных, понятных шагов. К чему я - устарел ваш аждайл на всех уровнях, где начинают люди соприкасаться с отделом разработки.
56. nickpugachev 13.03.21 14:38 Сейчас в теме
(52)
Критериев того, что является рабочим продуктом - нет, но инфа о том, что документация не сильно то и важна, приводит к тому, что на нее забивают.


То есть, не отрицая важности того, что справа,
мы всё-таки больше ценим то, что слева.


Так важности документации никто и не отрицает. И забивать на нее нельзя.
Устраивать бардак можно по любой методике и по любым принципам, бардаком оно от этого быть не перестанет.
Ценность документации при отсутствии работающего продукта в конце проекта - какая? Она и в каскадной технологии будет такая же, как и в любой из гибких.

То же касается и взаимодействия с заказчиком. Условия контракта - важны. Но если вы в ходе работы с проектом и взаимодействия с заказчиком пришли к мнению, что нужно что-то менять, выкидывать одни блоки и добавлять другие - это важнее и нужно пересматривать условия контракта вместе с заказчиком. Вы же не будете в этом случае делать блоки, которые не нужны, пиная заказчика платить за них в любом случае?

GitHub Flow хорошая штука, но имеет свою область применения. Так же, как и Git Flow. Все зависит от проекта/продукта, нужно выбирать.

Если внимательно прочитаете и разберетесь с манифестом, то поймете, что вы эти четыре пункта и так соблюдаете скорее всего.
И если прочитаете принципы сами, а не послушаете свист Рабиновича - тоже поймете, что вы их скорее всего применяете.
59. DitriX 2098 13.03.21 15:05 Сейчас в теме
(56)
Если внимательно прочитаете и разберетесь с манифестом, то поймете, что вы эти четыре пункта и так соблюдаете скорее всего.

Увы, и ах. Не соблюдаю, ну кроме гибкости, в какойто мере. Потому что они уже устарели. Причем капитально устарели. Это даже немного обижает, вы реально думаете, что за 20 лет с момента обрисовки аджайла в мире IT ничего не поменялось?
Та блин, когда его создавали - еще даже гита не существовало. А только один гит внес столько изменений и парадигм, что капец.

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

Разработчикам надо другое, это другое уже тоже давно существует. Но все упорно прут этот аджайл, скрам и прочую лабудень...

Вон, пусть уборщица по аджайлу работает. Там вполне легко подсчитать условия работы, легко рассчитать сроки выполнения, можно менять кабинеты, и обсуждать каждый спринт - в каком порядке ей мыть лестницу, сверху вниз, или наоборот. Делать опрос других уборщиц, чтобы выяснить, за сколько времени Марьивановна сможет помыть лестницу. Так как они все взаимозаменяемы, кроме Петровны, у нее спина больная.
Там не нужна документация, и это очень важная професия, оптимизацией которой никто, почему то, не занимается. Даже обидно.
60. nickpugachev 13.03.21 15:31 Сейчас в теме
(59)
Вон, пусть уборщица по аджайлу работает. Там вполне легко подсчитать условия работы, легко рассчитать сроки выполнения, можно менять кабинеты, и обсуждать каждый спринт - в каком порядке ей мыть лестницу, сверху вниз, или наоборот. Делать опрос других уборщиц, чтобы выяснить, за сколько времени Марьивановна сможет помыть лестницу. Так как они все взаимозаменяемы, кроме Петровны, у нее спина больная.

Вот тут как раз лучшие условия для водопада :)
Все очень четко и ничего не поменяется. Если считать помывку лестницы проектом.

Увы, и ах. Не соблюдаю, ну кроме гибкости, в какойто мере.

Не читал, но осуждаю?

Скрам мастер - это не к agile вообще, это к конкретному фреймворку scrum. В чистом виде практически не встречается. У него достаточно узкая область применения. То, что его пихают во все дырки и то что получилось называют скрамом - это да, проблема.

А что насчет XP? Никаких скрам мастеров, Кент Бек в анамнезе и т.д. :)
83. morin 59 17.03.21 08:43 Сейчас в теме
(59) Этот комментарий стоит дороже все статьи!
49. starik-2005 3060 13.03.21 12:51 Сейчас в теме
(47) я вот ни рпзу не против гибкой методологии - она увеличивает скорость разработки, повышает производительность труда, уменьшает ошибки, т.к. процесс более прозрачен со стороны разработчикв

Но сказать, сколько времени у какого разработчика займет решение той или иной задачи - для этого толтко уж точно эджайл не нужен.
58. nickpugachev 13.03.21 14:47 Сейчас в теме
(49)
она увеличивает скорость разработки, повышает производительность труда, уменьшает ошибки

Не увеличивает ни одна из методик agile производительность. По количеству накладных расходов как раз водопад самый оптимальный. Но вот результат, нужный бизнесу, на большом проекте в изменчивой среде получить проще по agile.
Про ошибки тоже спорно. Какие ошибки?
66. starik-2005 3060 13.03.21 20:08 Сейчас в теме
(58) через прозрачность процесса со стороны разработчика и повышаются все те показатели, о которых я говорил. Плюс количество смен контекста в эджайле принято ограничивать троечкой, чего в водопаде в принципе сделать невозможно. Итог - меньше ошибок, выше производительность, выше скорость. Из-за прозрачности (понятности, оцененности) именно со стороны разработчика - тот же покер планирования, когда хорошая команда оценит большинство задач точно, а не приблизительно, ибо аргументы границ рассматриваются - этого тоже ни в одном водопаде нет, там есть сжимание времени вниз и растягивание вверх (разраб говорит, что это три часа, а рп еще пять в уме добавляет). Так что не говорите мне про водопад - это долго, дорого и некачественно.
68. nickpugachev 14.03.21 12:24 Сейчас в теме
(66)
Так вы сравниваете почти идеальный agile с хреновым водопадом. Кто мешает так же точно разбить все задачи в водопаде и нормально оценить их разработчиком? Кто мешает распланировать все заранее и четко? Что касается переключения контекста - его на водопаде быть не должно в принципе. У разработчика есть очередь выполнения задач и он просто их делает одну за другой. Это если мы возьмем такой же идеальный водопад, как и agile.
А вот дополнительные встречи и обсуждения что же мы будем делать дальше - увеличивают расходы в agile. Постоянные переделки, потому что архитектурно промазали десяток спринтов назад - тоже.

Просто нужно выбирать процесс, соответствующий проекту, а не ломиться с одним и тем же в любые проекты. А еще их можно при необходимости совмещать.
75. starik-2005 3060 16.03.21 12:29 Сейчас в теме
(68)
Просто нужно выбирать процесс, соответствующий проекту
Предположу, что в деле автоматизации ларька с помощью коробки процессы вообще неважны. Но процесс планирования и создания всех элементов архитектуры на каждом этапе - это бич водопада, ибо редко достигается компромисс между точностью ТЗ и реальными задачами, в итоге водопад иллюзорно снижает затраты времени на разработку, но явно неиллюзорно увеличивает их на этапе проектирования и последующей поддержки, ибо продукт после водопада будет лишь отдаленно напоминать то, что действительно хочет клиент. Ну а за первым водопадом идет второй (а сколько времени на доделку?), потом третий (опытно-промышленная жксплуатация), потом четвертый (поддержка), потом пятый (смерть продукта и начало работы над совершенно новым), ...
62. rpgshnik 3746 13.03.21 16:57 Сейчас в теме
(47) Почему все говорят об Аджайл как об методологии. Это не верно в корне. Хотя наверное если обобщать все методологии то да можно назвать одним словом... ок)
53. Dragonim 140 13.03.21 13:28 Сейчас в теме
55. user1534961 13.03.21 13:36 Сейчас в теме
Для меня принцип Agile противоречил принципу "Разделяй и властвуй", пропагондируемому руководством нашего отдела.
Как можно использовать аджайл, если все действия программистов должны быть а) одобрены, б) запротоколированы в) архивы должны показывать кто-что делал и в какой момент времени в коде.
В начале карьеры мы обсуждали с коллегами что они предпочитают внедрять - БСП и дописать что требуется (например написать комплексную на базе БСП), или готовую конфигурацию, наполненную функционалом (в данном случае - российскую бухгалтерию и использовать как получится (изменить план счетов и внедрять), комплексной тогда в природе не существовало) .
Мнение коллег было однозначным - кому нужна эта БСП.
Когда я села, изучила БСП и применила ее механизмы в разработке - моим коллегам как ни странно это понравилось (или сделали вид что понравилось из вежливости, поскольку проект в итоге был провален).
Аджайл это инструмент для менеджера, владеющего программированием, как СКД. Если программист не обладает властью и не является ЛПР, а между данными и финансовым результатом есть бизнес-аналитики, постановщики задач и консультанты - то аджайл это просто такое нецензурное слово.
57. nickpugachev 13.03.21 14:43 Сейчас в теме
(55)
Никакой из этих трех пунктов не противоречит agile
rpgshnik; +1 Ответить
61. rpgshnik 3746 13.03.21 15:36 Сейчас в теме
Аджайл это философия, а не методология. Методология это Скрам, которая основана на философии Аджайл. Мне кажется автор нам доносит, что-то не то. И вопросы странные, похоже на рекламу и пиар очередного курса :)
Leon75; morin; +2 Ответить
70. user1534961 14.03.21 14:48 Сейчас в теме
Зачастую под проектом понимаются разные вещи. Проект автоматизации проекта разработки проекта обеспечения это как то не так звучит..
71. booksfill 15.03.21 15:01 Сейчас в теме
1. "Люди и взаимодействие важнее процессов и инструментов"
Есть только один "людь", тот, кто хочет в итоге получить прибыль.
И взаимодействовать он готов только в рамках ROI и т.п.

Мы внедряем процессы, которые дадут прибыль и взаимодействуем с исполнителями заказчика,
"выжимая" из них нужные сведения, и игнорируя хотелки, не приводящие в итоге к результату.
см. замечание к п.2.

2. "Работающий продукт важнее исчерпывающей документации"
Что важнее дышать или есть?
Наверно, дышать, без этого быстрее умрешь. Но для адекватного человека так вопрос не ставится.

Правда после слова "исчерпывающей", такая приятная гибкость в толкованиях намечается ...


3. "Сотрудничество с заказчиком важнее согласования условий контракта"
Вы зачем с заказчиком встречаться планируете? Чтобы все сделать по своему?
Если нет, то "контракт" - это любая договоренность с заказчиком, хоть в рамках ТЗ, хоть после встречи в курилке.
Разумеется, только идеалисты думают, что можно не фиксировать контракт тем или иным образом.

4. "Готовность к изменениям важнее следования первоначальному плану".
Набор обтекаемых фраз.
Что такое "первоначальный план"?
Если это стратегическая задача, то ее изменение суть катастрофа, если это тактические планы то каким надо быть
"успешным мобильным менеджером", чтобы этого не понимать?

P.S.
Я ЗА Agile, "только чтобы по-новому оставалось все по-старому" ((С)Аршин малалан).
Если серьезно, то, по-моему, все споры из-за того, что хорошую технологию часто пытаются применить не там.
Ну и манифест, честно говоря, надо бы писать не по типу священной книги, кою толкуют каждый в свою сторону.
FatPanzer; +1 Ответить
72. axelerleo 343 15.03.21 18:47 Сейчас в теме
Есть опыт в двух организациях работы по эджайлу.
В первой - это была одна видимость. Burndown chart был, ежедневные летучки были, канбан доска была, проджект-менеджер был. А эджайла не было. Потому что не было планирования, и не было нормальных итераций с плановыми релизами. Были пожары, метания от одного к другому, и смутное понимание всей команды, куда все катится.
Во второй компании, где работаю сейчас - это просто сказка! Серьезно, это первая на моей практике компания, где процессы четко отлажены, и планирование - не пустой звук. Случаются конечно и недооценки задач, и небольшие авралы, но они - внезапно! - тоже запланированы)) Точнее, под них зарезервировано время.

Спринты (у нас они называются "Итерации") по 2 недели, в конце спринта - плановый релиз. В начале спринта - ретроспектива. Каждый день с утра - летучка минут на 10.
Задачи ведутся в azure devops, там же - все дашборды, где можно уследить за загруженностью команды, бкэклогом и т.д.
Ретроспективы - в Miro.
Постановки задач и документация - в confluence

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

Схема эта в нашей команде применяется универсально - и к 1С разработке, и к sharepoint порталу, и к MS Project Server, и к корпоративным сайтам.

А уж насколько это можно назвать Agile - это наверное к знатокам терминологии. Вроде - похоже :)
starik-2005; morin; +2 Ответить
73. morin 59 16.03.21 09:25 Сейчас в теме
Напишите нормальное ТЗ, а какой подход к управлению - это дело десятое. В 99.99999 % случаев достаточно обычного task-менеджера.
А то получается, что только не придумают, лишь бы ТЗ не писать. (Поговорка)
76. starik-2005 3060 16.03.21 12:41 Сейчас в теме
(73)
Напишите нормальное ТЗ
А Вы когда-нить видели это "нормальное ТЗ"? Я, например, не видел ни разу. Да, есть с претензией на "нормальность" - толстенное такое ТЗ, даже в Арисе накидана схемка, но это все-равно очень далеко от того продукта, который нужен.

Вот я согласен с одним из авторов (по-моему, это Иван Белобородов - вроде бы так), который писал, что заказчик хочет совсем не то, о чем он говорит и что способен написать на бумаге. Он хочет конкретную задачу решить, и он думает, что для этого ему нужен отчет, окно, поля в нем, три кнопки и т.д., но проблема совсем в другом обычно. Ну не автоматизатор начальник склада, но у него есть свои логистические задачи, он их как-то сформулировал проектной команде (в самом плохом случае - написал), потом получил сто кликов там, где и одного не нужно.

В общем такие вот ТЗ - это бич. Специалистов про процессам очень мало, а большинство 1С-негов (включая консультантов) даже не знают, что такое BPM (ну хоть CRM выучили - и на том спасибо).
77. morin 59 16.03.21 13:17 Сейчас в теме
(76) Да я тоже ТЗ на стикерах 8х8 получаю. И поэтому мне достаточно иметь task-менеджер. Зачем что-то ещё, чем оно мне поможет? Неужели какая-то методология по волшебству легко и просто напишет классное ТЗ и закроит все мои задачи.
79. starik-2005 3060 16.03.21 14:01 Сейчас в теме
(77) так в эджайле ТЗ есть, но это скорее "дорожная карта", описание направления, стратегия. А Ваши стикеры - это уже тактические материалы. Если Вы один - они вполне могут в экселе или даже на бумажках "таскменеджериться", но если вам там больше однгго, задачи связаны, сроки установлены, то кто-то "главный" (которого потом будут "анально стимулировать") должен видеть, где Вы сейчас находитесь и успеваете ли к сроку. Спринт - отличное решение, когда закидывается из пула задач определенное количество в разработку, отбирая по приоритету и имеющемуся ресурсу, потом покер планирования, где разные разработчики указывают время, которое, как они считают, займет такая задача. Потом тех, кто выставил максимальную и минимальную оценку спрашивают, чем это мотивировано (иногда просто кто-то что-то не учитывает и задача кажется сложнее или проще, чем есть на самом деле). Если есть мотивированный ответ, с которым соглашается команда, то время сдвигается к этой границе, а если нет - остается в коридоре средних значений. Потом оцененные задачи раскидываются по разработчикам, остается 20-40% времени на реакцию на проблемы и внеочередные задачи. В итоге руководитель доволен, видит на доске, какая задача делается. Разработчики видят, как деградирует куча - дополнительная мотивация сделать все быстрее и погонять в контру с обеда пятница при закрытом спринте. Ну и если кто тормозит, то освободившиеся занимаются с ним парным программированием.
Фактически, скрам - это тактический механизм в эджайле, формализующий процесс разработки. А сам аэджайл - это совокупность процессов для обеспечения функционирования и развития продукта с невысоким "пенальти" за сам процесс.
82. morin 59 16.03.21 14:25 Сейчас в теме
(79) Я лишь имел ввиду, что в нашей предметной области как раз "тактические материалы" имеют гораздо большее значение, чем некая "дорожная карта". И любой прекрасный с точки зрения стратегии план внедрения, легко тонет из-за локальных просчетов: слишком много зависимостей и от предметной области, и от конкретных людей, которые эту предметную область описывают. А вот с "дорожной картой" как раз проблем не много: как правило, все хорошо представляют проект "в целом". Это статистика, спорить нет смысла.
78. herfis 508 16.03.21 13:36 Сейчас в теме
Аджайл для меня - это короткие итерации планирования и подбития итогов. Которые в силу своей простоты и понятности позволяют экономить время на бюрократии обеспечивая при этом максимальную эффективность разработчиков.
В моем представлении это нормально работает только когда сроки с бюджетом относительно гибкие. То есть чаще всего на разработке собственных продуктов или внутренних продуктов. Тогда можно сэкономить на многостороннем контроле, всего лишь оперативно подправляя и контролируя направление копания землеройных машин (разработчиков) и не заморачиваясь на более сложные контроли и согласования, неизбежные при выполнении внешних проектов.
На внешних проектах возникает много рисков, завязанных на моменты взаимодействия. И как заказчику так и исполнителю приходится прилагать много усилий, чтобы минимизировать риски со СВОЕЙ стороны. Каждый будет тянуть одеяло на себя и натяжение одеяла необходимо плотно контролировать на всех этапах. Когда заказчиком и исполнителем выступает одна контора - натяжение одеяла контролировать уже не нужно и аджайл позволяет существенно сэкономить.
ИМХО, на внешних проектах аджайл тоже допустим, но лишь как вспомогательный инструмент управления проектами. В то время как на собственных проектах он может быть основным инструментом.
80. herfis 508 16.03.21 14:11 Сейчас в теме
В постановке "аджайл в 1С" - лично я смысла не вижу. Потому что не понимаю, в чем принципиальное отличие проектов на 1С от проектов на другом языке. 1С отличается лишь ограничением круга решаемых задач и увеличением скорости разработки в рамках этого круга.
Ну вот пожалуй что 1С в силу невероятной скорости блочной разработки имеет огромный круг практических задач, допускающих революционный подход "тяп-ляп и в продакшн", делающим бессмысленным обсуждение на этом уровне всяких там аджайл vs водопад. Задача будет решена быстрее, чем нарисован план проекта :)
FatPanzer; +1 Ответить
81. morin 59 16.03.21 14:17 Сейчас в теме
(80) Да, тут дело не в языке 1С, а в предметной области: слишком много зависимостей от различных персонажей.
84. RustIG 1720 18.03.21 09:44 Сейчас в теме
примеры применения элементов гибкого подхода https://infostart.ru/1c/articles/402490/
Оставьте свое сообщение