Бывает ли Agile в проектах 1С?

06.12.21

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

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

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


Маленький спойлер для тех, кто не успеет дочитать до конца: в четверг 9 декабря в 12:00 пройдет открытый мастер-класс “Как представить Заказчику проект по Agile, чтобы он на него согласился?” как раз в рамках обсуждения темы “А бывает ли Agile в 1С?”. Присоединяйтесь, пообщаемся вживую! Желательно с микрофоном.


Сразу два уточнения:


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

Во-вторых, бывает, что под лозунгом “мы работаем по Agile” люди пытаются скрыть недостаток профессионализма. “Мы не документируем, у нас Agile”... “Зачем нужно продумывать архитектуру, будем всё планировать по ходу” - такие заявления показывают, что применяемый подход ближе к “Do&Fix” или “Тяп-ляп”, чем собственно к Agile.  В действительности, при запуске любого проекта разработки или внедрения, несомненно, нужно нарисовать примерную дорожную карту продукта (или проекта). Нюанс в том, что она, во-первых, будет без мелких деталей, а во-вторых, может существенно корректироваться в процессе. 


Вкратце - про что мы вообще говорим - что такое Agile подходы?

 

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

  • Небольшую кросс-функциональную самоорганизующуюся команду, которая работает над продуктом
  • Отсутствие подробного ТЗ на старте и уточнение требований в процессе работы
  • Частые поставки готового продукта
  • Тесное сотрудничество заказчиков и исполнителей
  • Корректировки по итогам обратной связи


Звучит привлекательно, но из второго и пятого пунктов (черт, опять этот пятый пункт) следует то, что на старте проекта по Agile крайне сложно определить это объем, стоимость и продолжительность.  И именно в этом и заключается основной затык: заказчик удивленно поднимает брови и спрашивает у исполнителя: “А как мы можем с вами договориться на проект, если вы не можете внятно сказать, что вы сделаете и сколько это будет стоить???”


Итак, как же можно запустить проект с высокой степенью неопределенности?
Рассмотрим несколько ситуаций по мере возрастания сложности.

 

Ситуация №1, простая. Внутренний проект (в не очень бюрократизированной компании)

 

Изначально Agile-подходы (в первую очередь Скрам) и создавались для внутренних проектов. Когда у нас нет контракта с внешним подрядчиком, когда у нас в любом случае есть команда ИТ-специалистов на зарплате, договориться с лицами принимающими решения чаще всего оказывается не так уж сложно. 
Достаточно описать ситуацию: 
Бизнес жалуется на отсутствие четкой системы работы с клиентами, что приводит к косякам, потерям клиентов, сложности контроля. Есть такая-то бизнес-проблема. Для ее решения предлагается внедрить и кастомизировать CRM-систему. Высокий уровень неопределенности не позволяет обозначить объем работ на старте. Мы как профессионалы, понимаем, что в текущей ситуации писать подробное ТЗ - просто потеря времени, и можем объяснить почему. Поэтому мы предлагаем работать по Agile (если это слово еще не является ругательным в компании),  у нас есть вот такая дорожная карта, и будем уточнять требования по ходу, чтобы выдать именно нужный результат.  Когда будет готово мы точно сказать не можем, но будем держать всех в курсе работы. 
Кстати, буквально недавно читала регламент по проектному управлению в крупной окологосударственной банковской структуре. И там черным по белому было написано - что если ИТ-проекты не предполагают привлечения подрядчиков, то их рекомендуется делать по Скрам. Так что лед в этом направлении двигается все быстрее и быстрее... 

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

 

Итак, усложняем ситуацию. Руководство хочет точно планировать бюджет на квартал и на год (и его можно понять). Здесь у нас есть два варианта тактики. 
Бюджетирование не проекта, а портфеля.  Допустим, в организации есть несколько портфелей проектов (критические проекты “для выживания”, проекты развития, стратегические проекты и т. п.), каждый привязан к своей стратегической цели, и на каждый определяется сумма расходов. В начале года Инвестиционный комитет определяет сумму затрат на портфель проектов развития ИТ (или даже более узко - проектов развития 1С). Фактически, здесь речь идет в основном про затраты на зарплату ИТ-специалистов и амортизацию оборудования - то есть мы договариваемся, например, что вот эти 8 специалистов 50% своего рабочего времени занимаются проектами развития. Ура, бюджет у нас есть!.. Мы даже готовы примерно обрисовать план, какие именно проекты внедрения и доработки мы успеем реализовать в рамках этого портфеля за год. Но - ключевое слово “примерно”. Также как и в прошлом примере, мы честно предупреждаем, что мы работаем по Agie, и точный объем работ, также как и точные сроки каждого проекта мы сможем уточнить уже по ходу. Но пусть это не пугает наш уважаемый Инвестиционный комитет!
Потому что, во-первых, у нас есть четкий бюджет - мы знаем, сколько денег мы потратим на развитие.
Во-вторых, мы уверены, что это будут наиболее актуальные перспективные направления развития, потому что мы будем работать в тесном контакте с бизнес-заказчиками.
В-третьих, мы будем регулярно представлять Инвестиционному комитету результаты, чтобы он был уверен в том, что мы двигаемся правильно.
Ну и, в-четвертых, если уважаемый Инвестиционный комитет настаивает, мы можем заявить итоговые KPI по итогам портфеля - например, рост удовлетворенности клиентов, уменьшение числа ошибок, повышение производительности системы и так далее. Мы еще не до конца знаем, что именно мы сделаем для достижения поставленных целей (потому что, как вы помните, в рамках Agile мы строим гипотезы и проводим эксперименты), но нам в любом случае понятно, куда надо стремиться.


Ситуация №3, опять простая. “Согласие на Agile от безысходности”.

 

Организация может сколько угодно не хотеть или не мочь работать по Agile (ограничения 44-ого ФЗ, корпоративные регламенты, необходимость проведения тендера с детализированным ТЗ и так далее). Но очень часто, увы, ситуация оказывается безвыходной: проект по Водопаду был заявлен, подробное ТЗ написано, проект запущен, реализован, его результат получен… И оказался совершенно бесполезен. Потому что либо заказчик в начале проекта не мог написать реалистичные требования, либо ситуация за время проекта изменилась настолько, что цели в настоящий момент уже совершенно другие.  И вот, как показывает практика внедренцев, на этом месте сколь угодно упертые изначально заказчики оказываются куда сговорчивее. Если людям действительно нужен результат (а если проект и так был “для галочки” - то всё и так в порядке - “галочку” можно с чистой совестью поставить), то они найдут возможность работать гибкими методами, что с внутренним подразделением, что с внешними подрядчиками.  Многие внедренцы как раз и признают, что работать по Agile хорошо получается с заказчиками, у которых только что всё провалилось по Водопаду. И залог успеха здесь не только в том, что Agile позволяет более гибко решать проблемы, а еще и в том, что заказчик после проваленного проекта - это уже немного другой заказчик, чем был до. Мне очень понравилась фраза, высказанная в рамках дискуссии на форуме Инфостарта (я даже взяла ее в заголовок одного из докладов) - “Agile - это спасательный круг для проектов, утонувших в Водопаде”. Если речь идет про внешний проект - то технически взаимодействие в таком случае обычно оформляется как договор сопровождения, так как в такой ситуации нет обязательных правил про тендер с фиксированными на старте условиями. 

 

Ситуация №4, чуть посложнее. Внешние проекты: типовое внедрение при помощи 1С:Технологии быстрого результата.

 

И здесь, опять же, легко проверить, что это бывает на практике. Мы работаем с применением 1С:ТБР, многие другие компании работают с применением 1С:ТБР. Довольные заказчики пишут хвалебные отзывы про 1С:ТБР. 
В чем суть Технологии быстрого результата в двух словах? 
Поставка функционала небольшими работающими кусочками (одна итерация - не дольше 1 месяца)
Подписывается договор на каждый блок, и по итогам каждый кусочек актируется заказчиком и работа оплачивается сразу.
Тесное сотрудничество заказчиков и исполнителей в процессе, возможность у заказчика контролировать исполнителя благодаря прозрачности, максимально упрощенная процедура согласования изменений.
Есть готовый набор шаблонов документации, простой и понятный, ничего лишнего.

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

 

Ситуация №5. Ещё сложнее. Предстоит делать сложное внедрение по Agile: объем непонятен, но заказчику нужно четко определить бюджет.

 

Здесь сразу надо оговорить один момент. Одним из условий работы по Agile должно быть наличие достаточно высокого уровня доверия между заказчиками и исполнителями. Без доверия не стоит и начинать.  Доверие не складывается в одночасье, к нему нужны некоторые предпосылки. 

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

Только в таких условиях возможна стратегия, которую Стивен Кови в своей книге “Семь навыков высокоэффективных людей” назвал “Выиграл-выграл” (в противоположность стратегии “Выиграл-Проиграл”. Вернее, даже не так. “Выиграл-выиграл или не связывайся” - когда мы не идем на сотрудничество если видим, что партнер не поддерживает такую стратегию.
Кстати, на своих курсах по управлению проектами я обычно предлагаю участникам поиграть в игру по Дилемме заключенного. Очень хорошо промывает мозги на тему, почему люди в разных ситуациях ведут себя так, а не иначе...

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

В этих условиях высоки шансы договориться на то, что я в своей статье Контракты в Agile называла “перевернутым проектным треугольником”: когда в контракте фиксируются сроки и стоимость проекта, но жестко не фиксируется функционал (обычно примерно в формате размытого ТЗ). При этом исполнитель может озвучить заказчику примерно следующее:
Давайте подпишем с вами контракт на полгода на кастомизацию под вас Комплексной автоматизации 2. За это время мы гарантированно сможем сделать MVP (Minimum Viable Product - минимальный жизнеспособный продукт) и нарастить его наиболее ценным функционалом (даже если пока не до конца понятно, что именно будет для вас ценным). Так как проект сложный, мы с вами понимаем, что на старте невозможно четко описать итоговый функционал. Мы понимаем, что многие требования будут появляться у вас уже в процессе работы, в процессе тестирования первых модулей. Обращаем ваше внимание, что риски с вашей стороны минимальны - так как мы в начале каждого месяца (недели, двух недель) будем обсуждать с вами, какие именно функции для вас наиболее приоритетны на данном этапе. Вы сможете сразу начать пользоваться уже внедренным функционалом, если что-то пойдет не так - всегда сможете разорвать контракт (хотя мы уверены, что этого не понадобится).


Как-то так. Я описала основные ситуации, с которыми приходилось сталкиваться. Кому интереснее поговорить об этом подробнее - приходите на мастер-класс 9 января
Ну, а кому интересно разобраться еще подробнее - приходите на мои курсы на Инфостарте )))

До встречи на Инфостарте!

См. также.

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

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

13.05.2024    3342    0    Dimbayyyy    9    

10

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

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

19.04.2024    519    0    Radio_Analyst    0    

5

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

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

28.07.2023    2452    0    olegminkov    4    

7

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

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

13.06.2023    1468    8    dimbasbear    1    

2

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

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

27.02.2023    2500    0    glebushka    2    

13

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

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

01.04.2021    3821    0    MariaTemchina    18    

16

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

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

12.03.2021    8426    0    MariaTemchina    86    

27

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

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

16.02.2021    5526    0    MariaTemchina    45    

33
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. IssakN 45 06.12.21 13:10 Сейчас в теме
Да согласен Agile применим в 1С. Так и ведем разработку на проекте, конечно с некоторыми отличия от написанного в статье. Пришли сами эволюционно к совмещенному подходу Agile + Waterfall. Хотя сейчас это само собой уже разумеющимся.
MariaTemchina; +1 Ответить
3. MariaTemchina 1618 06.12.21 15:52 Сейчас в теме
(1) Да, на мой взгляд тоже гибридные подходы - самые живучие и самые универсальные. И за ними будущее ))).
Надо будет про это отдельную статью написать.
2. Константин С. 668 06.12.21 13:18 Сейчас в теме
Ну да, Эджайл, Скрам, технологии, методологии, красивые слова. Но где вы видели это в реальности в 1С внедрениях????

не важно как это все называется, главное уметь это применять в работе. И не мешало процессу.
IssakN; Torin; +2 Ответить
4. MariaTemchina 1618 06.12.21 15:53 Сейчас в теме
(2) Кстати, да. У меня часто бывает, что я рассказываю какие-то инструменты и техники, а слушатели в ответ "О! Так мы это давно уже делаем, отлично работает!.. Теперь будем знать, как это называется... "

До разумных вещей многие люди доходят разными путями. Хотя в любом случае ценно, когда технология явно описана.
5. Yashazz 4758 06.12.21 16:52 Сейчас в теме
Я спрошу ещё на этапе чтения заголовка публикации: а что такое "проект 1С"? Сие явление очень по-разному трактуется сотрудниками сферы. У некоторых автоматизация ларька - уже проект, а у некоторых и написание конфы либо перепиливание до неузнаваемости - "текущая" автоматизация либо вообще, простихосспади, "адаптация" или "внедрение продукта". Проект - в вашем понимании - какой он, каковы признаки? Что/кто на нём минимально должны быть?
FatPanzer; +1 Ответить
6. FatPanzer 06.12.21 19:23 Сейчас в теме
(5) А еще интересно - можно ли назвать проектом полный переход одного из крупнейших налогоплательщиков РФ с 7.7 на ERP (многофилиального с развитой иностранной сетью, прямым производством в Китае и проч)?
Применим ли тут Agile с его "историями пользователей" и "владельцами продукта"?

А то пришел тут к нам один со своими спринтами...
8. 1c-intelligence 12812 06.12.21 20:38 Сейчас в теме
(6) главная фишка эджайла - все и так по нему живут, сами того не осознавая.

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

Как бы детально и качественно не были написаны требования в ТЗ, всё равно в оконцове придёт "юзер" и расскажет свою "стори" (с которой, собственно, и писал ТЗ "аналитик").

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

Так что, если вы давно и серьёзно занимаетесь проектами автоматизации на 1С, можете гнать в шею всех эджайл-проповедников, чего бы они там вам не пытались продать. Вы и есть эджайл.

Эджайл - это делать то, что нужно, там, где вы находитесь, с тем, что имеете.
Maxim_Zuev; tindir; evgd02; rovenko.n; Asmody; korppinen; Drivingblind; MariaTemchina; Petr54-ru; Yashazz; +10 Ответить
13. RustIG 1690 07.12.21 09:25 Сейчас в теме
(8) а мне понравился тренинг - я многому научился в плане управления работой - оно теперь сидит в подкорке, но если попросите рассказать , что там хорошего, то не смогу описать.... это как сходить в поход и рассказывать о нем - и тем более слушать про него (еще дальше становишься)
MariaTemchina; +1 Ответить
17. 1c-intelligence 12812 07.12.21 09:57 Сейчас в теме
(13) ну, если тренер хороший, то тренинг на любую тему понравится.
Главное ведь - тамада хороший и конкурсы интересные.
tindir; Yashazz; +2 Ответить
18. RustIG 1690 07.12.21 10:10 Сейчас в теме
(17) я в конкурсах с тамадой не участвую. не в моем характере.
19. 1c-intelligence 12812 07.12.21 10:29 Сейчас в теме
(18) но на тренинги ходите... Какая-то неувязка
20. RustIG 1690 07.12.21 11:41 Сейчас в теме
(19) неувязка в вашей системе координат.
в моей системе координат - все норм - неувязок нет.
27. 1c-intelligence 12812 07.12.21 13:12 Сейчас в теме
(20) в моей неувязок полно. Как только начинает казаться, что всё увязалось - создаю неувязки искусственно.
Иначе где взять мотив для увязки.
user914179; +1 Ответить
28. RustIG 1690 07.12.21 13:19 Сейчас в теме
29. 1c-intelligence 12812 07.12.21 13:29 Сейчас в теме
47. Dem0 27.12.21 10:57 Сейчас в теме
(29)
всё как Сократ учил

Если солдату нечем заняться - оторви ему рукав. Пускай сидит и пришивает?! =)
48. 1c-intelligence 12812 27.12.21 11:06 Сейчас в теме
23. MariaTemchina 1618 07.12.21 12:55 Сейчас в теме
(8) Про то, что по эджайл все и так живут - согласна. А вот про то, что если вы давно работаете, значит вам точно учиться ничему не надо, ни с чьим опытом знакомиться не надо, вы и так всё знаете - не согласна. Очень часто привычные способы и ошибки переходят из проекта в проект, и не посмотрев со стороны не получается понять, что вообще можно по-другому...
26. 1c-intelligence 12812 07.12.21 13:11 Сейчас в теме
(23) я вроде не говорил, что учиться не надо.
Говорил, что надо гнать в шею проповедников.
40. Yashazz 4758 08.12.21 12:43 Сейчас в теме
(26) а это проповедники так лихо умеют чужие слова в выгодную себе форму выкручивать. Жонглировать словами, делать умный вид на пустом месте, перевирать - и на всём этом, через проповеди свои, грести бабло.
44. 1c-intelligence 12812 08.12.21 14:12 Сейчас в теме
(40) работа такая. Спроси конюха, что он думает о программистах 1С - столько же плохих слов напишет.
46. tindir 16.12.21 09:56 Сейчас в теме
(8) Спасибо! А я то думал, кто у меня началнег...а он фасилитик-рефлексированный!
Очень жду от вас "мемуары".
15. RustIG 1690 07.12.21 09:32 Сейчас в теме
(6)
можно ли назвать проектом полный переход одного из крупнейших налогоплательщиков РФ с 7.7 на ERP

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

эджайл - это не только гибкость в бюджете за счет функционала и целей, гибкость в сроках за счет функционала и целей, это один баланс во всех сферах жизни - знаете, когда говорят про баланс в жизни, начинают рисовать круг, делить его на сектора - тут финансы, тут здоровье, тут семья и т.д.
и попробуй объяснить в одном абзаце, что такое баланс, начнешь рассказывать про семью, углубишься, а с тебя спросят про финансы, начнешь пр офинансы рассказывать - а тебя спросят про здоровье...
и так никогда не расскажешь про баланс...
эджайл - это тоже круг из разных секторов....
один из секторов - это постоянно на каждом спринте выделять из всех задач при всех ограничениях минимум вэлью продукт - его и делать....
22. MariaTemchina 1618 07.12.21 12:53 Сейчас в теме
(6)
Проектом назвать можно. Или программой проектов. Применим ли тут Agile в чистом виде - не уверена, не готова ставить диагноз по юзерпику.
Но гибридные методы точно применимы.
49. bzs1 15.12.22 18:11 Сейчас в теме
(5)проект по классике - это создание какого-то уникального продукта/функционала за ограниченный срок
7. axelerleo 343 06.12.21 20:37 Сейчас в теме
А у нас на проекте внутренней автоматизации, я вот даже и не знаю, аджайл у нас или скрам, или какое-то еще вумное название :)
Спринты у нас есть. Бюджет проекта и дорожная карта, проектные комитеты тож есть. Причем стоимость в бОльшей части случаев оценивается точно (+/- 30% закладывают на риски)
Кроссбраузернаяфункциональная команда тож вроде на месте.
Но у нас зачастую до старта разработки (на большинство задач) аналитики пишут документацию, которая потом согласуется с внутренними заказчиками, и уже потом это идет в разработку.
Тестирование ведется по этой же документации, но всяких юзер стори и простихоспаде gherkin-ов у нас пока нет.
Вот и вопрос - это аджайл, или что-то другое?:)
24. MariaTemchina 1618 07.12.21 12:58 Сейчас в теме
(17)
(7) У вас явно есть элементы Agile.
Ключевые признаки Agile на мой взгляд, я упоминала в статье:
Независимая команда
Частые поставки
Тесное взаимодействие с заказчиком и частая обратная связь
Создание ТЗ в процессе.

Если чего-то из этого у вас нет - не берусь утверждать, что вам оно обязательно нужно )).
Как известно - работает - не трогай )))
axelerleo; +1 Ответить
9. Vo-Va 803 06.12.21 21:41 Сейчас в теме
Достаточно не писать ТЗ и будет тебе Agile.
rovenko.n; ITSun; terrorion; myoker; bilex; morin; Yashazz; +7 Ответить
11. Yashazz 4758 06.12.21 21:57 Сейчас в теме
(9) Гениально. Краткость - воистину С.Т.
14. TimurD 6 07.12.21 09:28 Сейчас в теме
(9) В разработке (пусть небольшого функционала) программисту приходиться все нюансы (или большую их часть) описывать в коде, т.е. предусматривать различные варианты поведения алгоритмов и пр. И зачастую бывает так, что ИТ не уточняет все требования (не пишет ТЗ, не рассказывает заказчику что конкретно они собираются делать), и в итоге разработанный функционал работает не верно. Заказчик изначально не верно высказал свои хотелки, ИТ не так все понял, или на переправе заказчик "коней поменяли" - тут уже не важно, виноваты ИТ во всех бедах. А конкретно программист(ы), т.к. это они че то там накодили, а у нас прибыль падает. Дальше начинаются корпоративные дрязги и обвинения всех и вся во всех смертных грехах. А все почему? ТЗ не было, хоть какого-нибудь. ТЗ частично защищает от таких случаев, т.к. на вопрос "Почему эта кнопка делает вот так", можно ответить, что работа кнопки было расписана в ТЗ, заказчик согласился с этим, когда согласовывал ТЗ.
Я считаю, в более менее средних конторах (с оборотом от 100 млн деревянных в год) нужно в большинство задачах писать ТЗ. Иначе всегда программисты будут виноваты. Постоянно с этим сталкиваюсь.
С другой стороны если это достаточно мелкий бизнес (небольшой интернет магазин), то там редко нужно расписывать ТЗ, т.к. банально квалификации заказчика не хватит, чтобы ответить на все вопросы. Просто делаем красиво...
30. MariaTemchina 1618 07.12.21 13:44 Сейчас в теме
(14) Тимур, так ТЗ нужно обязательно, согласна с вами. Просто писать его целиком на старте бесполезно - как раз из-за непонимания заказчика, что ему надо, и из-за смены коней на переправе. Agile как раз предлагает писать и уточнять ТЗ по кусочками, и сверять часы с заказчиком каждый спринт. Это существенно уменьшает последующие претензии к ИТшникам, проверено на практике.
33. TimurD 6 07.12.21 14:35 Сейчас в теме
(30) Как писали в комментах выше - лучше комбинировать:
- Если небольшие доработки, то лучше ТЗ написать (если работ более чем на рабочий день), чтобы все вопросы и ответы были на "бумаге", и в проде не было сюрпризов. Но это не панацея, везде нужно следовать золотой середине.
- Проект лучше делать по водопаду. Т.е. должна быть конечная точка, достигнув которой мы можем сказать, что проект выполнен. Дальше поддержка, Эйджайлы и пр. Иначе заказчик на шею сядет (с фиксированным бюджетом). Или если у нас почасовая... Agile это золотое дно.

Как говорят адвокаты: кормит не успешное, а долгое дело.
41. Yashazz 4758 08.12.21 12:47 Сейчас в теме
(30) Претензии к IT уменьшает умение и желание РП и руководства грамотно себя поставить. ТЗ тут никаким боком. ТЗ может быть идеальное, т.е. по тогдашним желаниям заказчика и тщательно проработанное; а всё одно на полдороге концепция изменится и виноваты будут айтишники (ну, собстно, они всегда во всём виноваты). ТЗ может не быть ваще или состоять из пары общих слов, но если РП умеет быковать и давить, то претензий будет минимум.
Читаю это всё и смешно, право слово. Какие-то идеальные сферические кони в вакууме, плюс умелая игра на нежелании кодера быть виноватым, и вот, вуаля, шаромыжники-пройдохи под личинами "эджайл-проповедников" уже садятся фирме на шею.
21. RustIG 1690 07.12.21 11:43 Сейчас в теме
(9) тяп-ляп + бесплатные работы по изменению уже сделанного
35. Vo-Va 803 07.12.21 16:20 Сейчас в теме
(21) интересно почему надо менять то что уже сделано?. потому что сделано не то что нужно? Так это не проблема ТЗ, а если будет ТЗ, то это не станет тем что нужно, это останется ненужным, просто обяжет клиента заплатить. Вы получите деньги и недовольного клиента. Клиент не виноват, что у исполнителя не хватило компетенций правильно двигаться к результату. Ну а если проблема в том что клиент саботирует процесс, значит его не интересует результат, а значит и клиент он хреновый.

(25) Лет 20 назад, постоянно переписывать ТЗ (или дописывать) тоже бы назвали тяп-ляп). А теперь это Agile) Я конечно говорю не о больших командах. Хотя мне кажется больше дело не в размере команды, а в компетенциях исполнителей. В компетенциях именно такого процесса, постоянного диалога с клиентом, корректировки направления разработки, а иногда и своевременного прекращения, когда понимаешь что движешься в тупик. В любом варианте ТЗ это страховка от недобросовестных исполнителей и клиентов.

Ну а для меня лично, отсутствие ТЗ, это в первую очередь удобство разработки, когда я сосредоточен на результате, и да результатом может быть совсем не то что представлял себе клиент в начале, но это то к чему он пришел в процессе диалога со мной и то что решает его задачи, обычно гораздо лучше чем он сам себе представлял.
36. RustIG 1690 07.12.21 17:25 Сейчас в теме
(35)
Ну а для меня лично, отсутствие ТЗ

на коротком промежутке времени и когда один разработчик - можно и без ТЗ - вы все помните, ваш заказчик тоже все помнит "что, где и как сделать надо"...............
ТЗ - это любое письменное подтверждение задачи - на ватсап, на почту, но не устно по телефону, а вы потом записали в блокнот....
25. MariaTemchina 1618 07.12.21 12:59 Сейчас в теме
(9) Если просто не писать ТЗ - то будет не Agile, а Тяп-Ляп.
Хотя да, это тоже иногда называют "Agile"...
10. pma_2015 132 06.12.21 21:55 Сейчас в теме
У меня в глазах совсем другая основная ситуация. И вот она как раз про 1С, про ERP. Причина ухода в гибкость проста – нет консультантов, хорошо знающих продукт. Тем более актуальный релиз. Поэтому нужно время для судорожного обучения за счет заказчика. И все эти 5 ситуаций сводятся к одной – там наверху что-то порешали, а вы, ребята в полях, идите и внедряйте.
Лечится эта гибкость созданием настоящих центров компетенции. Но это не кросс-функционально. И это стОит. Поэтому ситуация с ERP сейчас как на фронте. Нужны патроны знаний и опыта, а вместо них политруков привозят. С квадратами Кеневина.
Dem0; evgd02; tolyan_ekb; morin; CheBurator; Yashazz; +6 Ответить
32. MariaTemchina 1618 07.12.21 13:47 Сейчас в теме
(10) Что компетенции важная в первую очередь - не могу не согласиться.
Но когда их в любом случае нет, и в любом случае предстоит учиться - это как раз эффективнее и надёжнее делать по Agile - так мы хотя бы сможем быстрее замечать и исправлять ошибки...
39. pma_2015 132 08.12.21 12:27 Сейчас в теме
(32) Это все равно сбивать температурку. Лечить надо саму заразу гибкости. Каленым железом методик и знаний. Это, знаете, как игра на музыкальном инструменте. Когда мелодию заказчика по слуху подбираешь – это правильная гибкость. А когда за его счет учишься пальцами струны дергать – это самозванство. Просто в методические отделы деньги нужно вкладывать, они же напрямую в проектах не должны пахать. И деньги жмут.
12. morin 58 07.12.21 09:06 Сейчас в теме
Ни разу не встречал ТЗ, в котором жестко и детально фиксируется весь функционал от и до. В enterprise-стеке это не возможно. Да и вообще, слабо представляю и мне не понятно, где это возможно.
Автор, если вы работали по таким ТЗ, напишите где, очень интересно.
31. MariaTemchina 1618 07.12.21 13:45 Сейчас в теме
(12) Я работала в ситуациях, когда делали вид, что подробное ТЗ готово на старте. Например, в свете ограничений тендеров и т.п. Но по факту, согласна с вами, детали всё равно уточнялись на ходу.
16. RustIG 1690 07.12.21 09:55 Сейчас в теме
(5)
Проект - в вашем понимании - какой он, каковы признаки? Что/кто на нём минимально должны быть?


когда дадим формулировку, потом захотим проверить ее на проектах от 500 - 10 000 человек в штате https://consulting.1c.ru/

затем попробуем наложить на проекты реальной автоматизации (см. кейсы) https://1c.ru/realav/index

и в конце захочется сравнить с задачами фрилансера (который без команды один штурмует)
34. MikhailDr 07.12.21 15:54 Сейчас в теме
Мне интереснее бывает ли что-то кроме Agile в проектах 1С (если речь не про внедрение типового продукта исключительно в рамках типового функционала)? Нет, декларировать можно что угодно, но вот так чтобы на старте составили план и он не изменился к концу проекта процентов на 50.
MariaTemchina; +1 Ответить
37. comol 5067 07.12.21 23:43 Сейчас в теме
Почему то вопросы вида "бывает ли Agile в 1С" очень сильно похожи на "существует ли короновирус в России" :)
42. Yashazz 4758 08.12.21 12:49 Сейчас в теме
(37) "Есть ли жизнь на Марсе, нет ли жизни на Марсе... Науке это неизвестно, она пока ещё не в курсе дела..." (с)
38. Asmody 08.12.21 10:12 Сейчас в теме
43. Yashazz 4758 08.12.21 13:38 Сейчас в теме
Я смотрю, на простой вопрос, что такое проект, ответа не последовало. Автор, ау, что такое "проект" в вашем понимании? А то вы так склоняете это слово, столько им оперируете, так хоть распишите для начала.
А то вдруг получится, что у нас не проект, и все эджайлы именно поэтому не удались (а не потому, что они суть хрень по определению)
45. MariaTemchina 1618 08.12.21 14:39 Сейчас в теме
(43) Определение могу дать, не вопрос. Например, такое: Проект - временное предприятие, направленное на
создание уникального продукта, услуги или результата.
А вот про границы проекта - что проект, а что нет - не скажу, в каждой организации они свои. Можно отталкиваться от того, как удобнее чем-то управлять: как проектом или как операционной деятельностью? Если и без Уставов, учета рисков и специальных документов всё и так хорошо работает, то зачем городить огород?
Оставьте свое сообщение