Применение Agile-технологий в проектах 1С

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

Agile – это одна из методик ведения проектов. О ее практическом применении в проектах 1С пойдет речь в статье.

Что такое Agile?

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

Что такое спринт? Это некий отрезок времени, за который надо получить определённый результат. Мы можем не получить всю систему в целом, но определенный результат  должны показать. Причем это результат, который принимает заказчик.

Особенности заключения контрактов типа Agile

Отличительный момент проектов Agile – отсутствие перспектив на постановку технического задания и получения в целом какого-то решения. Здесь нет такого, что сначала мы пишем полгода техническое задание, потом 2 года программируем, а потом показываем заказчику продукт. Все сводится к тому, что мы определяем общие с заказчиком цели, которые хотим достигнуть. В договоры наша компания даже добавляет такой раздел, как «Цели», и прежде чем идти в проект, мы их прописываем.

Важно понимать, что цели из разряда «получить новую платформу» или «автоматизировать» – это не цели. Цели должны быть сформулированы конкретно. Например, получение структуры себестоимости или отчета по себестоимости с визуальным представлением. Это цель. Заказчик понимает, что когда он увидит такую-то формочку, пусть она даже в экселе нарисована, это достижение цели, это то, что нужно принимать. Какая-то обработка – это тоже может быть целью. Поэтому цели должны быть четко расставлены и должны быть визуальными/ощутимыми.

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

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

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

Проектирование по Agile

В этой системе нет такого этапа, как постановка технического задания. Мы против этого этапа, потому что фактически онзаканчивается тонной макулатуры, которая потом мало применяется. Чаще всего с постановкой ТЗ приходится сталкиваться при работе по госконтрактам, когда техническое задание необходимо и является неотъемлемой частью.

Тем не менее, этап проектирования в Agile есть, от него никуда не уйти. Он представляет собой следующее: в 1С проектах на 99% всегда решение строится на базе другого готового решения. Если управленческий учет – это ERP или управление торговлей, есть много отраслевых решений. Это понятно на этапе предварительных переговоров с заказчиком. Наш проект строится на уже готовых решениях. На предпроектных работах мы берем готовую систему и наполняем ее рабочими данными – это входит в состав предпроектных работ. Если мы переходим с существующей системы, мы заранее будем готовить конвертацию, и будем заполнять сразу реальными данными. И все проектирование сводится не к получению какого-то документа, а к построению системы и ее запуску.

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

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

Оценка работы

Спроектированный состав работ имеет вид задач, списка. Встает вопрос, как все это оценить. Методик оценки много, они разные и интересные. Где-то сидит эксперт, который говорит, сколько часов это займет, умножает их на стоимость нормо-часа. В другом месте сидит менеджер, который понимает, сколько можно «скормить» заказчику. В третьем придуман еще какой-то способ.

В нашей компании пользуются технологией, которая называется Agile Planning Poker. Ее, кстати, можно использовать в самых разных ситуациях, она применима не только для оценки, и не только в Agile.

Как работает эта технология? У каждого программиста, у каждого участника команды есть такая колода карт с цифрами. Рассчитываем, сколько часов именно на разработку необходимо потратить. Программисты берут карты рубашкой вверх и потом вскрывают их. Если количество часов не будет отличаться больше чем на 10-20 процентов, берётся максимальная оценка. Если один дал 2 часа, а другой – 10 часов, это значит, что оценка сильно отличается. Тогда начинается обсуждение, потому что вполне вероятно, что прав тот человек, который дал большую оценку, поскольку он понимает, что потребуется больше времени. Может быть и наоборот: тот, кто дал больше часов, чего-то не понимает, потому что уже где-то есть готовое решение, которое можно скачать и все быстро сделать. После обсуждения идет переоценка.

То есть мы получаем некий корсет прямых затратпрограммистов. Еще одно преимущество этой технологии в том, что команда сама дала оценку. Если оценили в 10 часов, а потратили 200 часов, обвинить какого-то одного человека будет очень сложно. Ребята вместе оценивали и смотрели на задачу.

Составление сметы

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

Формирование плана-графика

Планировать в Agile на длительный период никакого смысла нет.

Тем не менее, есть два вида плана. Первый – план движения по проекту, очень укрупненный. Дается только для того, чтобы дисциплинировать заказчика и подрядчика. Мы понимаем, какой у нас вектор, куда идем, поэтому все дается в укрупненном плане. Допустим, до сентября должны запустить продажи, в ноябре – закупки, и т.д.

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

Спринт содержит в себе определённый состав задач на 1-2 недели, максимум на 4 недели. Спринт менять нежелательно, это список задач, которые фиксируются, и изменять их неправильно. У нас, например, к спринтам привязана система мотивации, и команда прекрасно понимает, что все поставленные задачи надо выполнить за короткий промежуток времени.

Но даже за 1-2 недели может что-то произойти. Может поменяться руководитель проекта, например. Тогда спринт может быть перепланирован.

Собираем хорошую команду

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

У нас должна быть проектная команда от заказчика. Если ее нет, то, скорее всего, ваш проект Agile завершится неудачей. Мы должны видеть и понимать тех людей, которые отвечают за приемку работ. Это должен быть владелец продукта, это может быть заказчик, может быть исполнитель или третье контактное лицо, которое понимает четко, что мы должны получить в итоге. Этот человек может поставить приоритеты, может закрыть или перенаправить проект. Ответственные люди со стороны заказчика, которые будут отвечать за приемку работ, должны быть обязательно.

Еще одна обязательная фигура – ведущий программист или, как его еще называют, архитектор. Это специалист проектной команды. Специфика Agile проектов в том, что команда исполнителя должна быть в очень тесном контакте с заказчиком. Любой продукт, который делается по технологии Agile, должен делаться совместно с заказчиком. Тестирование интерфейса, разработка – все совместно с ним. Идеальный Agile продукт – когда исполнитель сидит на территории заказчика.

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

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

Как происходит закрытие спринта?

Есть такое понятие, как митинги или летучки. Они проводятся с определённой частотой – желательно каждый день или раз в два дня.

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

Цели митинга:

  • разобрать новые задачи;
  • распределить, кто и что делает;
  • разобраться с зависшими стикерами, которые остались в процессе.

Идеальное время проведения митинга – не более 10-15 минут. Если митинг затягивается, что-то идет не так. Если полчаса или час – это уже нелепое совещание по непонятному вопросу. Если появилась какая-то проблема, которая требует обсуждения на проекте, например, техническая сложность, тогда надо отдельно садиться и обсуждать.

Очень важно – проектная команда должна быть разношёрстной. Не должно быть такого, что один отвечает толькоза конвертацию, другой – только за интерфейсы, третий – знает только SCD. Должна быть взаимозаменяемость, и очень важно контролировать, чтобы специалисту доставались всегда разные задачи. Да, он потратит на это больше времени, но если один человек уйдет в отпуск или уволится, всегда будет тот, кто сможет его заменить. Он будет реально в теме, будет понимать, что происходит в проекте и на техническом уровне. Это очень важно.

Самый прекрасный митинг – это когда на нем присутствует заказчик. Пусть не каждый день, но 1-2 раза в неделю он должен быть. Заказчик будет видеть, как идет процесс, он сможет оперативно и динамически влиять. Он также будет видеть, что есть какой-то результат, и команде будет удобно. Это могут быть встречи по скайпу, необязательно приезжать, но приглашать и настаивать на участии заказчика необходимо.

Как сдается спринт?

Спринт – это не просто набор незавершённого решения. Мы там что-то наделали, и это получился результат. Это определенный и совершенно конкретный результат, например, завершенный какой-то образ, какая-то обработка или  половина обработки, где будет одна закладка и какая-то форма.

Спринт обязательно подлежит сдаче и оплате. И с заказчиком это согласовывается еще на стадии обсуждения и проектирования.

Как же мы сдаем работы? Кто является ключевыми фигурами?

Мы выделяем три ключевые роли со стороны заказчика:

  1. Лицо, которое будет эксплуатировать, конечный пользователь или его руководитель. Контакт с этими людьми должен быть постоянным.
  2. Лицо, которое отвечает за приемку работ. Когда вы беретесь за какую-то часть работы, важно понимать, как и кем она будет приниматься. С этим лицом надо контактировать хотя бы раз в 1-2 недели, потому что спринт надо сдавать ему, этот человек будет подписывать акт о выполнении этапа работ.
  3. Лицо, которое платит. Это может быть инвестор, акционер, человек, деньги которого непосредственно тратятся. Он может быть далек от проекта, но очень важно с ним поддерживать связь, пусть даже кофе попить. Ведь когда он платит, ему важно понимать, за что он платит. И на этом этапе всегда важно поддержать контакт. Зашли раз в полмесяца/месяц, рассказали, как идут дела на проекте. Обязательно надо сделать акцент на результат, что получили – подсистему, документ. Быстро и коротко. Чтобы человек знал, куда идут его деньги.

Учет рабочего времени

Поскольку мы говорим про 1С, а это сфера, где работают программисты и консультанты, нашим продуктом является наше время. Есть то время, которое мы получили при планировании задач, – это так называемое инвойсное время, инвойсные часы. И есть то, которое фактически потрачено.

Бывает, что оценили задачу в 10 часов, а потратили на нее 200 часов. Очень важно разобраться, почему это произошло: мы недооценили или эффективность сотрудников слишком низкая. Тайм-менеджмент в нашей компании сводится с детализацией отчетов до 15 минут. Мы заполняем ежедневно отчеты и понимаем, чем занимался человек. Кроме того, у нас есть отчеты по эффективности, которые позволяют оценить и каждый проект, и каждого сотрудника.

Мотивация в проектах Agile

Существует множество способов мотивации. Но программисты – не продавцы, мотивировать полной сдельщиной их не получается. У них мотивация внутри, они должны понимать, зачем что-то делают. Кроме того, если им интересно – они делают, неинтересно – не делают.

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

Что такое план – это количество часов, закрываемых за календарный месяц по проектам или оценкам. Этот план зависит от количества рабочих часов в месяце и градации специалиста. Например, специалист 4 категории из 180 часов должен отработать 80 или 40 часов, а программист первой категории – например, 120.

Исходя из планов и отчетов сотрудников, мы можем посчитатьфактически отработанное время. Есть непосредственно окладная часть – она привязана к категории и составляет примерно 60% дохода. Остальная часть строится, исходя из закрытых часов. Если сотрудник выполняет план или перевыполняет, он получает премиальную часть. Таким образом, вся команда замотивирована и работает не только на процесс, но и на закрытие максимального количества задач за адекватное время.

В нашей компании еще есть схема мотивации, завязанная на своевременное закрытие спринтов. Таким образом, мы закрыли 2 проблемы: 1 – работоспособность и эффективность людей, которые понимают, на что они работают, а 2 – соблюдение сроков, которые очень часто срываются.

Гарантийные работы

Гарантийные работы есть непосредственно как у самой проектной команды, так и достаются ей в наследие. Что с ними делать? При нашей схеме разработки и мотивации делать гарантийные работы неинтересно никому, потому что за них не платят. Одно дело – баги, которые пришли к нам в результате наших деяний, а другое  – которые пришли от прошлых команд программистов, которые, возможно, у нас даже не работают уже. Такие работы скидываются обычно на какого-нибудь новичка.

Но мы решили сделать иначе. Мы включили баги всех спринтов в состав спринта. Это такой же стикер. Если спринт не закрыт полностью, команда не получает ничего.

Кроме того, в нашей компании есть планы по гарантии. То есть каждый сотрудник должен, помимо плана по инвойсным часам, выполнять еще гарантийные работы. Допустим,  Вася должен сделать 40 гарантийных часов и столько же Петя. Если они этого не сделают, это скажется на окладной части. Таким образом, сотрудник замотивирован решать и делать гарантийные работы.

Достоинства и недостатки технологии Agile

Достоинства:

  • Минимальный риск за счет поэтапной приемки.

Цена риска – всегда один спринт. Когда мы делаем по какому-то договору большой проект по ТЗ, мы понимаем, что если вдруг не сдадим работы, что-то поменяется, заказчик обанкротится, появится новый руководитель, нам деньги не заплатят, и проект завалится. В нашем случае всегда цена риска – один спринт. Мы можем его оценить в денежном эквиваленте. Например, если наш риск 200 тысяч рублей, то мы точно знаем, что больше мы не потеряем. Многие компании любят брать аванс – 50% и дальше работать, делать проект, а по его окончании – получают вторую часть. Но если будут какие-то перемены, то они потеряют именно 50%. У нас риск минимизирован. Главное понимать конкретную сумму, и быть готовым к такой потере.

  • Прозрачный результат для всех сторон.

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

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

  • Минимальные сроки.

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

  • Нацеленность команды на результат.

Команда видит короткий спринт. У них нет долгосрочной перспективы, например, через два года закрыть проект. И вообще, что значит «проект закрыт»? Когда заканчивается один этап, начинается другой. Или идет развитие системы, перестроение. Заказчики, у которых мы работали несколько лет назад, до сих пор системы развивают, делают новые блоки. В некоторых ситуациях заказчики спрашивают, когда ваша система заработает? Она никогда не заработает, потому что исполнитель все время ее дорабатывает. Иначе компания закроется, бизнеса больше не будет. Всегда будут придумываться новые блоки, новые процессы, новые виды. В нашем случае короткая итерация, команда видит, как закрывается итерация, и получает результат.

Недостатки:

  • Отсутствие бюджета на полный проект.

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

  • Расход времени на проведение митингов.

Митинги, которые проводятся ежедневно, собирают всю команду. Даже если брать митинг длительностью 15 минут плюс кофе-брэйк, все равно команда тратит время. Иногда неэффективно. Трата времени есть, если например, сидим, объясняем задачу для одного человека, а слушают еще 4. Но в то же время это является плюсом, потому что члены команды взаимозаменяемы.

Резюме

Очень важно помнить: в Agile мы работаем на результат, а не на процесс. Результат виден с первых ступеней, и вся работа исполнителя завязана на то, чтобы как можно плотнее сотрудничать с заказчиком и быстро получить результат.

***************

Данная статья написана на основе доклада, представленного автором на конференции Infostart в 2016 году. Приглашаем вас на новую конференцию INFOSTART EVENT 2017 COMMUNITY.

См. также

Комментарии
1. Решитко Дмитрий (grumagargler) 327 25.07.17 23:44 Сейчас в теме
Четко изложено, спасибо. Наверное выскажу непопулярное мнение, но всегда остается устойчивое ощущение, что подавляющее большинство тех, кто занимается внедрениями на платформе 1С с какими-либо доработками, уже последние лет 20+ именно по аджайлу и работают, еще со времен когда Казачков желтые книжки только начинал писать. Есть ТЗ или нет, дело вкуса можно сказать, но внедрять 1С без тесного взаимодействия с заказчиком, писать что-то год, а потом ставить ну не такая уж частая практика. Работа на месте у заказчика – так это вообще привилегия 1С-программистов, во всяком случае, до относительно недавнего времени, когда внедренец-программист еще был устойчивым образом. Другими словами, аджайл это здорово, но ведь мы вроде этим и так уже очень давно занимаемся…
TreeDogNight; корум; theEmperor; Yakud3a; kuntashov; itriot11; Bobak; zGainer; danik05ru@mail.ru; smit1c; dabu-dabu; 9-pm; ifal; +13 Ответить
5. Никита Грызлов (nixel) 282 26.07.17 10:19 Сейчас в теме
(1) не путайте, пожалуйста, нормальный аджайл с практиками программирования и тот ужас, что происходит в мире 1с)
Yasen; neikist; d4rkmesa; SelikhovVV; +4 Ответить
12. d4rkmesa (d4rkmesa) 26.07.17 19:56 Сейчас в теме
(5) Это точно, какие там спринты по 2-3 недели, ну разве что в проектной команде на ERP. По большей части часто все происходит "на коленке", задачи в лучшем случае фиксируются в редмайне или каком-то аналоге канбан-доски. Переиначивая поговорку, "каков приход таков и поп".
7. Олег Симоненко (nk25) 26.07.17 13:00 Сейчас в теме
(1)
на платформе 1С с какими-либо доработками, уже последние лет 20+ именно по аджайлу и работают
- как сейчас помню конец 90-х крупный банк, большая система , внедрение с доработками, оплата по этапам, команда от заказчика , команда от разработчика и далее по тексту . Но это была не 1с , а Agile-scrum и прочих слов не использовали.

Первый раз попалась заметка без упора на канбан, скрамбан , берндаун, фикси,спринт,фича . И это радует.
2. Данил Абдулгафаров (diso) 136 26.07.17 07:19 Сейчас в теме
По-моему это организация запрещенная в России ))))
корум; SerLeon; RSConsulting; Sheff; Yakud3a; +5 Ответить
3. Антон Степанов (Stepa86) 883 26.07.17 07:58 Сейчас в теме
Agile это методология, он говорит лишь о приоритетах в разработке, но совершенно не говорит про то, как работать и что делать.

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

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

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

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

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

А то, что у вас есть отличия от классики - чуть чуть другое распределение ролей, добавление мотивации, сдача работ и прочее - это прекрасно, это значит, что вы адаптировали процесс под себя, а не тупо внедрили то, что прочитали в книжке и используете, не понимая зачем это все.
Ta_Da; TreeDogNight; корум; Lemoi; ivanov660; neikist; sanjabor; newdigger; kolya_tlt; MGraf; dabu-dabu; +11 Ответить
4. Миколка Ровенко (rovenko.n) 26.07.17 09:40 Сейчас в теме
Хорошая статья. Единственный момент - "ТЗ - это тонны макулатуры" - этот момент очень часто становится камнем преткновения с Заказчиком.
Расскажу на примере:
Перед запуском проекта было четко указано - мы собираем требования с пользователей, потому что они потом будут пользоваться системой. Заказчик кивнул, но на этот момент внимания не обратил. В результате при демонстрации реализованного функционала всё было отлично по пунктам по Эджайлу, но при реализации всей разработки оказалось, что сбор требований производился не с тех людей. А у нас есть ТЗ, на котором стоит подпись Заказчика. Потому ответственность не наша.
TreeDogNight; +1 Ответить
6. Вячеслав Алпатов (DonAlPatino) 24 26.07.17 10:38 Сейчас в теме
Хорошо, что тут не хабр. Съели бы за незнание терминологии. Хоть бы wikipedia посмотрели прежде чем презентацию делать и на infostart с ней выступать. Тема старая и разжеванная. При том что действительно мир 1С многие элементы agile давно использует, только об этом не знает :-)
То что вы написали - это Scrum. НО за "scrum master = руководитель проекта" agile специалисты убивают медленной и мучительной смертью, т.к. она всю идею скрама отправляет в утиль.
Что бы не повторяться - на хабре много правильных и полезных статей по этой теме. Лучше читать там... А то выглядит как "наш бардак мы назовем красивым словом agile и пойдем с этим по жизни".
Yasen; Lemoi; neikist; Циник; SelikhovVV; +5 Ответить
8. Sergey Andreev (starik-2005) 1191 26.07.17 13:18 Сейчас в теме
9. Дамир Закиров (Dzenn) 74 26.07.17 15:46 Сейчас в теме
Тошниловка ваши аджайлы. Обычный здравый смысл под заморским словом.
rovenko.n; Ta_Da; корум; Yashazz; +4 Ответить
10. Павел Одинцов (Darklight) 26.07.17 17:42 Сейчас в теме
Пожалуй главные недостатки методологии, с точки зрения заказчика, в её сути:
1. Нет общего бюджета - заказчик не знает во в сколько ему это всё обойдётся и сколько денег ему нужно готовить в единицу отчётного времени. Это очень сильно напрягает большинство заказчиков. Конечно кое-какие оперативное планирование затрат умелые финансисты организовать смогут, и даже можно сделать прогнозную оценку для составления стратегического годового или многолетнего бюджета. Но всё это лишь создаст проекту сильные ограничивающие рамки, которые будут его тормозить и снижать эффективность.
2. Сдача блоков мелкими частями хороша лишь когда система потихоньку дорабатывается и развивается. А когда заказчику нужен переход от одной системы к другой (что чаще всего и происходит), то такой подход уже не годится - заказчик попросту не сможет работать в системе, решённой на 1%, 5%, 30%, даже в системе решённой на 60-80-90% от имевшегося старого функционала эффективно работать (даже по сравнение с тем "убожеством", что было заказчика ранее, практически нереально. Это так же будет очень сильно напрягать заказчика и фактически сведёт сдачу частей проекта как "сферической лошадей в вакууме" : да увидели как оно должно быть, да пощупали на тестовых данных, но эксплуатировать не можем - т.к. есть много зависимостей с другими блоками и, главное, много нереализованного функционала (даже не входящего сданные спринты), без которого вообще эксплуатировать систему нельзя.
Ta_Da; корум; sansys; cesar; miavolas; +5 Ответить
11. Алексей Драчков (Bassgood) 651 26.07.17 19:00 Сейчас в теме
(10) Судь идеи заключается не в сдаче частей функционала системы именно в эксплуатацию, а по крайней мере в их демонстрации заказчику, что эти части проекта уже готовы и могут работать как автономные блоки (пускай и не полностью), которые далее уже будут связываться в единую систему, это дает возможность услышать от заказчика его оценку хотя бы той части проекта, которая уже реализована, и принять на ее основании корректирующие действия, при этом устанив все недочеты в этом блоке еще до начала работ со следующими блоками системы, которые завязаны на него.
Во всяком случае, это лучше чем узнать мнение заказчика о реализованном функционале только по окончанию работ над всеми блоками программы.
newdigger; +1 Ответить
14. Павел Одинцов (Darklight) 27.07.17 10:29 Сейчас в теме
(11) Для этого испокон веков существуют пилотные решения, а так же черновые наброски макетов рабочих форм, agile и спринты здесь не причём!
16. Алексей Драчков (Bassgood) 651 27.07.17 10:49 Сейчас в теме
(14) И как вы будете демонстрировать заказчику работу этого чернового макета? То что есть макеты рабочих форм это хорошо, но это только цель, которую требуется достичь, заказчик не может их "пощупать" на "живых" данных, для этого и предлагается последовательная реализация этих макетов друг за другом (на каждом спринте по n-макетов) и демонстрация их заказчику, чтобы он мог видеть результаты работы команды "вживую", а не только на бумаге (не только после реализации всех макетов).
13. Sergey Andreev (starik-2005) 1191 27.07.17 10:27 Сейчас в теме
(10)
Пожалуй главные недостатки методологии, с точки зрения заказчика, в её сути:
Пожалуй кто-то ничего не знает про CMM и CMMi. Если компания находится на уровне развития 1, то Agile скорее навредит, чем поможет. А если на уровне 5, то без Agiled в принципе туда даже подняться невозможно.

Пока в обычном планировании как происходит? Берется некоторая оценка, умножается на некоторое число ("три", например). Потом руководители проектов начинают неистовую борьбу за ресурсы (программистов, кодеров, консультантов, аналитиков, ...), потом им удается добиться маржинальности, сэкономив ресурсы, ибо оценку предельно завысили. И иногда эти товарищи даже ISO имеют внутри в виде стандарта, как некоего сферического в вакууме коня.
15. Павел Одинцов (Darklight) 27.07.17 10:34 Сейчас в теме
(13) И много ли компаний в России (из числа не пришедших с запада или востока) вышли за пределы хотя бы 2-го уровня развития (про остальной мир судить не буду). Для большинства Российский реалий Agile больше провален, чем является спасительной соломенкой. Менталитет не правильный.
17. Sergey Andreev (starik-2005) 1191 27.07.17 11:36 Сейчас в теме
(15)
Для большинства Российский реалий Agile больше провален
Вы не ту проблему видите. Вот у меня был реальный опыт, когда я с руководителем отдела внедрили Jira и начали работать со спринтами. Реально производительность труда повысилась только от того, что не нужно было метаться между задачами - распланировали на неделю и отвлекаемся только на "аварии". Но у нас уже был внедрен стандарт ISO 9К + инцедентный подход (ITIL 2) по всей конторе целиком.

А проблема тут в другом - нет желания развиваться. Отчасти тут виновато отсутствие конкуренции в ИТ-разработке, ибо желающих получить ИТ-продукт больше, чем тех, кто его производит/внедряет/поддерживает. Ну и лень - куда без нее? Поэтому тот, кто сейчас возмущается различными новыми походами, будет оставаться на достигнутом уровне своей эффективности, медленно деградируя из-за возрастных изменений организма.
18. Павел Одинцов (Darklight) 27.07.17 12:24 Сейчас в теме
(17) Я, не возмущаюсь. Я говорю, что внедрять эти новые подходы очень тяжело в российскиз реалиях. И больше всего успех их внедрения и применения зависит не от того, насколько ими проникнется ИТ структура, а на сколько ими проникнется бизнес заказчиков.
19. Павел Власов (cesar) 7 27.07.17 12:56 Сейчас в теме
(17) У вас был проект создания и внедрения новой системы c понедельным планированием задач в JIRA или развитие и сопровождение существующих систем? Эти процессы имеют отличия.
20. Sergey Andreev (starik-2005) 1191 27.07.17 14:56 Сейчас в теме
(19)
У вас был проект создания и внедрения новой системы c понедельным планированием задач в JIRA или развитие и сопровождение существующих систем?
У нас было два уровня: инциденты в Itilium и спринты в Jira. был человек, который раскидывал инциденты, часть из них становилась задачами в Jira, а часть отправлялась на HD. Дальше относительно ресурсов либо происходило вытеснение из спринта имеющихся задач новыми (более приоритетными), либо новые задачи оставались в пуле задач, дожидаясь следующего спринта. Таким образом достигалась и прозрачность, и контроль. Сюда же можно было засунуть мотивацию за закрытие спринта в полном объеме.

Если кто-то думает, что он сможет внедрить Agile для поддержки и развития функционала продукта без работы с инцидентами - он глубоко ошибается. А инциденты - это и то, из чего впоследствии может появиться задача. В итоге если просто взять методологию с длинным спринтом и не предусмотреть процесс вытеснения задач более приоритетными, то эффективность такого внедрения будет низкой (если вообще будет). Поэтому или короткие спринты, или длинные, но с профицитом ресурсов команды в 20% для закрытия критических инцидентов.
24. Павел Власов (cesar) 7 27.07.17 19:13 Сейчас в теме
(20) А инциденты в Итиле и спринты в Jira были по задачам проекта создания и внедрения новой системы или это было доработка и сопровождение существующих систем? Были ли признаки проектной деятельности или это была поддержка?
25. Sergey Andreev (starik-2005) 1191 27.07.17 20:55 Сейчас в теме
(24) Это была как поддержка, так и создание нового совершенно функционала. Попытки использования MS Project и прочее были, но дальше сферической диаграммы Ганта дело не шло. Попытки ARIS тоже ни к чему не привели, т.к. просто никто не стал с этим разбираться. А вот Jira и спринты получилось достаточно быстро воткнуть в процессы и разработки, и поддержки.
21. Яков Коган (Yashazz) 2138 27.07.17 16:44 Сейчас в теме
Когда в самой 1С внедрили эту, простихосспади. хрень, качество продукта резко пошло вниз. Качество всего: и поддержки имеющихся компонент платформы, и создания новых, и их взаимодействия, и документирования, и исправления ошибок. Практика - критерий истины)
23. Алексей Драчков (Bassgood) 651 27.07.17 18:17 Сейчас в теме
(21) Вы уверены, что это связано именно с этим? Как долго это продлилось, они больше не используют ее?
Откуда у Вас такая информация, поделитесь, если не сложно?
27. Яков Коган (Yashazz) 2138 28.07.17 09:46 Сейчас в теме
(23) Имена называть не буду, просто судьба свела с человеком, работавшим там и видевшим всё непосредственно. Говорю с его слов. Текущее положение дел уже не знаю, но, судя количеству косяков в новых релизах, существенно лучше не стало.
29. Александр alex_2h2008 (alex_sh2008) 5 28.07.17 09:57 Сейчас в теме
(27)А причем здесь методики Agile?
33. Яков Коган (Yashazz) 2138 28.07.17 19:35 Сейчас в теме
(29) а притом, что "вся эта фигня" резко усилилась после внедрения Agile в 1С. Я не делаю прямой логической связи между этими фактами, а равно и допускаю, что внедрение пошло не совсем штатно, но...

(30) а я тоже нажимал. А вот вишь, не было этого. Прямо волшебный Undo случился.

Ладно, не будем особо оффтопить. Мне вот интересно, есть ли хоть один случай внедрения именно так, как завещали отцы-основатели оного, и знает ли кто-то вообще, "что имел в виду автор"?
34. Александр alex_2h2008 (alex_sh2008) 5 28.07.17 21:53 Сейчас в теме
(33)
а притом, что "вся эта фигня" резко усилилась после внедрения Agile в 1С

По мне дак эта вся "фигня" усилилась после того как правительство, при закрыло окошко для иностранных производителей ПО, 1С так же как и другие разработчики начали нагонять функционал своих продуктов до уровня иностранного ПО, что бы занять места в госсекторе. А там где скорость там и снижение качества.

как завещали отцы-основатели оного, и знает ли кто-то вообще, "что имел в виду автор"?

Ну вообще то прародитель этих методик вышел из СССР в частности ЦК КПСС, назывались они не Agile конечно, но основа была взята от туда и модернизована для управления циклом разработки программного обеспечения, для взаимодействия множества команд.
26. Sergey Andreev (starik-2005) 1191 27.07.17 20:56 Сейчас в теме
(21)
Когда в самой 1С внедрили эту, простихосспади. хрень, качество продукта резко пошло вниз.
А когда это. прастихоспади, оно вообще было вверху? Сейчас 8.3 очень даже неплохо работает. Что не так?
28. Яков Коган (Yashazz) 2138 28.07.17 09:50 Сейчас в теме
(26) 8.2.19 вполне себе стабильно работает. А вот с 8.3.Х вообще не угадаешь. Пишу это я давеча код в 8.3, сохраняю, а он мне нечто вроде "При редактировании модуля произошла ошибка" - переоткрываю модуль - бац, работу последнего получаса как корова языком слизнула. Это вообще как называется? Это называется "Agile, при котором каждая рабочая группа спешит зарелизить свой кусок, а дальше трава не расти".
rovenko.n; +1 Ответить
30. Алексей Драчков (Bassgood) 651 28.07.17 10:45 Сейчас в теме
(28)
бац, работу последнего получаса как корова языком слизнула

Я жму Ctrl+S каждые 10 мин своей работы ;)
На самом деле 8.3 развивается намного динамичнее, чем 8.2, со своей стороны каких-либо критических проблем в работе с 8.3 не замечал
31. Кирилл Власов (neikist) 28.07.17 11:06 Сейчас в теме
(30)Полностью согласен. Платформа и так медленно развивается, в 8.3 хоть немного ускорились и возможности добавлять новые стали. Хоть не на 20 лет от мейнстрима отставать будут возможно.
starik-2005; +1 1 Ответить
32. Sergey Andreev (starik-2005) 1191 28.07.17 11:35 Сейчас в теме
(28)
- бац,
У меня такое и на 7.7 было, и на 8.0/1/2/3... Сейчас вот интересная ошибка иногда наблюдается про рассинхронизацию контекста формы на севере и клиенте с какими-то циферками. Ошибок в 1С много - с этим я, лично, не спорю. Но сейчас эти ошибки являются следствием достаточно динамичного развития платформы, которого со времен появления управляемого интерфейса не было: такси (можно по-разному о нем говорить, но мне, лично, нравится), REST/HTTP-сервисы, работа с бинарными данными, мобильная платформа, потоки в памяти - все это нельзя реализовать "бесплатно", за все это платится стабильностью работы решения в целом. Про 8.4 что-то давно не слышно, но там тоже интересные моменты в плане модульности и собственного веб-сервера.

Agile дал, на мой взгляд, достаточно быстрое внедрение интересных кусков кода в платформу (что-то у них даже раньше срока вышло, хотя, обычно, 1С всегда отставала от планов).

А вот по поводу сбоев (что-то при сохранении улетело в никуда), то такое на моей практике и на Borland Pascal 7.0 бывало (и даже на 5.0), не говоря уже о бейсиках на УКНЦ (Электроника МС 0511).
22. Александр Губанов (gubanoff) 44 27.07.17 17:25 Сейчас в теме
35. Николай Терацов (Teratsov) 18 02.08.17 12:20 Сейчас в теме
Так и не понял, о чем вы договариваетесь с Заказчиком на входе в проект и что пишете в договоре. А это интересно. То, что написано в разделе "Особенности заключения контрактов" - идеализация, редкий клиент согласится на проект без бюджета.

Мы у себя делаем так:

1. С клиентом подписывается стандартный проектный договор с плановым бюджетом, единственное отличие - в плане работ работы нарезаются таким образом, чтобы клиент раз в 1-2 месяца получал законченный функционал, решающий проблему клиента. На каждый такой ЭТАП, который заканчивается передачей законченного функционала, с клиентом подписывается допник с фиксированным бюджетом.

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

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

В итоге:
- планируем перед каждой итерацией;
- ретроспективы через одну, после завершения всего описанного в ДС функционала (когда команда свежая, ретро после каждой итерации);
- чекаемся раз в неделю внутренними демонстрациями;
- с клиентом фикс, команда работает по SCRUM;
- клиент получает готовые решения раз в 1-2 месяца, может внести корректировки в требования после первой итерации;
- мы имеем возможность пересогласовывать бюджет следующего ДС, если на предыдущем сработали какие-то риски. Риски в договоре, естественно.
shootnik; Yasen; A_Max; +3 Ответить
Оставьте свое сообщение