Что такое Agile mindset или, говоря по-русски, пронырливый образ мысли

Публикация № 898271

Методология - Управление проектом

47
Мне понравился встретившийся на просторах интернета перевод английского слова agile на русский – не как «гибкий», а как «пронырливый». В этом что-то есть – управлять проектом за счет пронырливых методов и пронырливости проектной команды. В этой статье я расскажу про то, почему для управления современными проектами необходимо быть пронырливым, а также как это выглядит в реальных командах по внедрению.

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

  • 6-ую версию PMBOK, где в каждом разделе рассказывается про методы и инструменты гибкой методологии управления проектами.
  • Введение в Agile – Agile Guide.
  • И книгу, направленную на создание в голове руководителей проектов того, что  PMI называет Agile mindset (гибкий образ мысли) – «PMI-ACP Exam Prep: A Course in a Book for Passing the PMI Agile Certified Practitioner (PMI-ACP) Exam». 

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

  • на идеях и предложениях от адептов проектного управления PMI, изложенных в вышеупомянутой литературе;
  • на практическом опыте приложения указанных выше идей и принципов к российским ИТ-проектам и проектам внедрения 1С, в частности.

 

Откуда вообще появился подход Agile? Почему нам приходится быть «пронырливыми»?

Майк Гриффитс, автор третьей из упомянутых в начале статьи книг PMI, выделяет следующие принципиальные различия между производственной работой (industrial work) и работой в информационной сфере (knowledge work):

Разные подходы к работе

 

Предложение «на подумать»: 
Отметьте, какими чертами из упомянутых выше характеризуются задачи, которые вы решаете. 
Посчитав, с какой стороны больше «плюсиков», вы сможете понять, она ближе к «производственной» или «информационной» эпохе. Поделитесь вашим ответом в комментариях, любопытно!
Мой личный ответ был примерно такой: когда мы говорим про задачи сопровождения продукта 1С – большая часть «плюсиков» оказывается в левой колонке. А когда речь идет про внедрение нового продукта, особенно не типового – сразу перемещаемся в правую колонку. Потому что левой колонки оказывается недостаточно. То есть классические подходы перестают работать, и приходится проявлять ту самую «пронырливость». 

 

12 принципов Agile-манифеста

Итак, Agile родился как желание более эффективно выполнять «информационную работу». И для того, чтобы применять его на практике, нужно не просто регламентировать стэндап-совещания, канбан-доски и прочие атрибуты. Нужно суметь изменить взаимоотношения внутри команды и с заказчиками и сформировать тот самый «образ мысли Agile», о котором я веду сегодня речь. В чем же он заключается? Для этого давайте вернемся к истокам, к документам, которые придумал Agile Alliance, отцы-основатели гибкого подхода.
Манифест Agile я уже подробно разбирала в предыдущих статьях Можно ли объять необъятное или чем Agile отличается от водопада? и Почему Agile превращается в Тяп-ляп. Кто виноват и что делать?. Здесь я не буду повторяться и перечислю 12 принципов Agile-манифеста, а также дополню их комментариями по реализации на практике, иначе не интересно.


1.      Самое важное – удовлетворить потребности заказчика, регулярно и непрерывно поставляя необходимые ему продукты.

Антипример: «Мы собрали с заказчика требования, полная ерунда, но это его проблемы – все зафиксировано в контракте, и к нам не может быть никаких претензий».
Пример Agile: «Совещаемся с заказчиком в процессе работы, уточняя при необходимости требования, демонстрируя промежуточный результат (лучше не в текстовом описании, а в  виде конкретных решений, которые можно "потрогать")».

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

Антипример: Одна поставка в конце.
Пример Agile: В идеале – у нас несколько маленьких поставок, каждая с частью функционала, которые уже можно запускать в работу. Если невозможны промежуточные релизы, то используем моделирование и даем заказчику «поиграть» с будущим интерфейсом и протестировать в условиях, максимально приближенных к боевым.

3.      Разработчики и представители бизнеса должны ежедневно сотрудничать от начала до конца проекта.

Антипример: Без комментариев.
Пример Agile: Придумываем, как мотивировать представителей заказчика к постоянному участию в проекте. Универсального и простого решения тут быть не может, в моей практике работают: человеческие дружеские отношения, упоминание в контракте, налаженное расписание, распоряжения высшего руководства, завязка KPI заказчика на успех проекта, приглашение заказчика в ресторан (ваши варианты в комментариях).


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

Комментарий: Меня всегда восхищает этот принцип. Честно скажу, встречать с радостью получается... с трудом. Скорее, принимать как данность.
Антипример: Ситуация, когда одна сторона старательно прижимает другую к стенке. Например, заказчик настаивает на том, чтобы все переделать, «а иначе не подпишем акты». Или исполнитель, который не соглашается ударить лишний раз пальцем о палец под лозунгом «в контракте этого нет, мы этого делать не будем». Не люблю в такой ситуации обвинять одну сторону и обелять другую, просто можно констатировать, что люди «не договорились».
Пример Agile: При грамотно выстроенной системе допсоглашений, если из-за изменений требований исполнителю приходится делать двойную (тройную, четверную и так далее) работу, то она оплачивается, поскольку допсоглашение подписывается по каждой итерации отдельно. 

5.      Выполняйте проекты, привлекая мотивированных личностей. Создайте этим людям условия, дайте, что им необходимо, а затем доверьтесь – работа будет сделана.

Прокомментирую этот принцип в комплекте с еще одним, забегая вперед по списку: 

11.    Самые лучшие требования, архитектурные и технические решения рождаются у самоуправляемых команд.

Комментарий: PMBOK ссылается на концепцию X и Y Дугласа Макгрегора.
Макгрегор исследовал связь производительности труда работников с тем, насколько им передают ответственность. Часть менеджеров (их он назван руководители X), были уверены что: 

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

А другая часть менеджеров (руководители Y), напротив, считала что: 

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

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

Пример и антипример: Моя практика наблюдения за руководством проектами внедрения с точки зрения модели X и Y говорит о следующем: 

  • Инициативные и здравые сотрудники от «микроменеджмента» (то есть попытки руководить каждым их шагом) портятся и увольняются. Когда им даешь инициативу – система работает лучше. 
  • Бывает такое, что ленивые и бестолковые сотрудники, когда перестаешь их жестко контролировать, а предлагаешь проявлять инициативу, пытаются сесть на шею, то есть перестают что-либо делать. Для меня это, скорее, повод с сотрудником расстаться, чем переходить с модели Y на модель X. 

(Вообще, тема мотивации сотрудников/коллег/заинтересованных сторон – благодатная и бесконечная. Возможно, надо на эту тему написать отдельную статью с примерами удачных и провальных инструментов).

6.      Личное общение – самый эффективный и результативный способ обмена информацией как внутри команды, так и с окружающим миром.

Комментарий: Автор семейства методологий Crystal (фреймворк внутри семейства Agile) Алистер Кокбёрн ввел специальное понятие «осмотическая коммуникация» (от слова «осмос» – проникновение через непрочные стенки). Имеется в виду, что когда люди, работающие над проектом, физически находятся в одном помещении, то информация «фоном» витает в воздухе, и все окружающие невольно оказываются в теме. Что повышает общую продуктивность работы: когда ваши коллеги обсуждают вслух проблему, имеющую отношение к проекту, вы можете принять решение, пропустить беседу мимо ушей или послушать «вполуха» и, тем самым, расширить свое представление о происходящем.
Пример Agile: Мой опыт знакомства с проектами внедрения показывает, что когда представители заказчика и исполнители работают физически в одном помещении, то эффективность работы возрастает. Заодно заказчику наглядно видно, что исполнитель занят делом. У этого могут быть свои недостатки – например, повышается шанс, что сотрудника «схантят» в организацию исполнителя, и он перейдет к ним работать. Или, например, исполнителю сложнее скрывать от заказчика, что члены команды работают над несколькими проектами одновременно. Но речь не об этом.


7.     Самый верный показатель прогресса — работающий продукт.

Пример Agile: Если вы исправно выдаете работающий продукт в конце каждой итерации (или нескольких итераций), то это лучше всего позволяет победить страхи заказчиков вроде «за что мы им платим, если неизвестно, сколько это будет стоить».
Антипример: В проектах внедрения 1С очень часто множество небольших поставок невозможно. То есть в теории возможно, но никому не нужно – клиент все-равно будет работать со старым продуктом, пока какая-то критическая масса функционала не будет реализована. Часто в такой ситуации приходится применять так называемые гибридные методы – например, WaterScrumFall.

8.      Agile процессы настраивают на стабильный темп разработки, что дает возможность инвесторам, разработчикам и пользователям всегда работать в постоянном ритме.

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

9.      Постоянное внимание к повышению мастерства и хороший дизайн повышают гибкость проекта.

Комментарий: Никто, я думаю, не станет спорить с тем, что «лучше быть богатым и здоровым, чем бедным и больным». В смысле, что лучше быть внимательным к повышению мастерства, и хорошо продумывать то, что мы делаем. Тем не менее, не у всех получается. Сталкиваясь в рамках своей профессиональной деятельности с разными командами разработки, я задумываюсь над вопросом, почему кто-то может? Мои версии примерно следующие:
Почему некоторые команды уделяют внимание хорошему дизайну?

  • Потому что могут себе это позволить (а не находятся непрерывно в ситуации жесткого дедлайна, когда выдохнуть некогда, а все сроки сгорели еще вчера).
  • Потому что есть внешний контроль. Например, практика code review – анализа кода. Она требует больших затрат, ибо приходится работать двум людям там, где вполне может справиться один. Зато позволяет поймать больше багов сразу, повышает самодисциплину разработчиков, взаимозаменяемость специалистов. Люди, конечно, могут сами себя мотивировать хорошо работать, но когда кроме внутренних мотиваторов есть еще и внешние, то всё работает лучше. 
  • Потому что есть выстроенная система. Когда организация находится на начальном уровне зрелости, проект внедрения вытягивается в условиях ограниченного бюджета за счет титанических усилий разработчика и аналитика – тут не до грамотной архитектуры. 

10.    Простота – искусство воздержаться от лишней работы – основа Agile.


Делаем, в первую очередь, то, что представляет для заказчика ценность. Подробнее про ценность для заказчика я собираюсь рассказать в следующей статье, а пока просто вспомню часто цитируемое исследование про частоту использования фич:

Как часто используются фичи?

Идея водопада заключается в том, чтобы реализовать все фичи единым махом (как нужные, так и не очень). Идея инкрементального управления проектом – что, в первую очередь, делаются те фичи, которые используются всегда и часто, и уже потом все остальные. Идея Agile в том, чтобы остановить проект после выполнения куска «всегда и часто», и переключиться на другие, более ценные проекты.

12.    Каждый раз в конце заранее определенного интервала времени команда размышляет, как повысить результативность своей работы, и затем вносит коррективы в процессы.

Комментарий: В этом месте как раз кроется один из способов отличить Agile от «Тяп-ляп». Это – наличие в команде рефлексии, что можно сделать лучше и где можно совершенствоваться. И применение итогов этой рефлексии на практике!

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

 

Коллеги, буду рада вашему опыту по теме. Каким образом в проектах внедрения получается проявлять «пронырливость»? Где не получается, а хотелось бы? Какими находками хочется поделиться?

47

Специальные предложения

Комментарии
Избранное Подписка Сортировка: Древо
1. genayo 04.09.18 19:24 Сейчас в теме
Agile - это стильно, модно, молодёжно https://habr.com/post/422123/
2. pm74 132 05.09.18 08:17 Сейчас в теме
что меня всегда восхищает в американцах - так это способность делать деньги из ничего , буквально из воздуха .
простую мысль " делите большие задачи на маленькие " назвать Agile , раскрутить это до некого подобия философии и даже " образа мышления ", используя при этом много красивых и непонятных слов

зы. прошу пардона у адептов Agile , возможно я таки еще не дорос
LordKim; tormozit; Gilev.Vyacheslav; Aphanas; +4 Ответить
3. Сурикат 264 05.09.18 09:11 Сейчас в теме
(2)

Agile немного не про разбиение задач на маленькие.
Agile про то, когда мы задачи формулируем.

И сейчас возможно идеи, предложенные Agile, кажутся очевидными, но когда он появился это была небольшая революция.
MariaTemchina; +1 Ответить
5. MariaTemchina 837 05.09.18 10:16 Сейчас в теме
(3)
И сейчас возможно идеи, предложенные Agile, кажутся очевидными, но когда он появился это была небольшая революция.

Да и сейчас, честно скажем, многие до сих пор впадают в ступор от предложений работать "по-гибкому": "как это в начале нет полного ТЗ? как это мы не знаем полную стоимость/функционал внедрения? как это постоянная тесная работа заказчиков с командой проекта?"
13. pro-rok 250 05.09.18 14:25 Сейчас в теме
(5) Мария, Вы все очень красиво описываете, да и я с Вами согласен, что это очень удобный и эффективный механизм, как бы его там не называли. Но теперь от Вас нужна статья "Как донести до клиента что нужно внедрять по гибкой технологии". Буквально сегодня от меня требовали стоимость внедрения ERP "под ключ" на основании двух страниц требований к системе. Как быть? Все вопросы одни и те же сколько нужно времени и денег? Предлагаю подготовить ТЗ-проект внедрения, без общей стоимости и рубля дать не хотят. А я им тут давай заливать гибкие технологии, частые поставки результатов, тесная работа.Не не катит.
CheBurator; +1 Ответить
23. MariaTemchina 837 05.09.18 16:25 Сейчас в теме
(13)
Но теперь от Вас нужна статья "Как донести до клиента что нужно внедрять по гибкой технологии"


pro-rok - это тема, надо будет создать ))).

В двух словах, опыт мой и моих коллег:

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

Разумеется, не всех заказчиков можно убедить работать по такой схеме. Да и не всех нужно...
29. Крококот 06.09.18 05:51 Сейчас в теме
(23)
Заказчики бывают разные, но все хотят быстрый результат

Несомненно. Но прежде результата хотят ещё и того, чтобы было понятно что за результат они получат, в какие сроки и за какие деньги. Надо отметить, что желание вполне себе разумное

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

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

Обещание сделать поставку с первым куском функционала позволяет замять тему "сколько будет стоить всё целиком"

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

Вообще ваши статьи для меня весьма интересны. Вы правильно описываете недостатки водопада и я с ними в общем и целом согласен.
Но вот agile... пока представляется мне в виде какой-то хрустальной мечты, которая не выдерживает столкновения с чугунным основанием реальности. Потому что непонятно где найти высококвалифицированных и высокомотивированных сотрудников (это я о пункте 11) и где найти всецело доверяющих тебе и платежеспособных клиентов.
CheBurator; +1 Ответить
31. genayo 06.09.18 08:20 Сейчас в теме
(29) Agile - это не про 1С. Вот и весь сказ.
34. Крококот 06.09.18 09:06 Сейчас в теме
(31)
Проблема в том, что водопад тоже подходит далеко не всегда. Претензии, высказываемые к нему вполне себе оправданы.
35. genayo 06.09.18 09:58 Сейчас в теме
32. MariaTemchina 837 06.09.18 08:39 Сейчас в теме
(29)
Редко бывает так, чтобы результат оказался совсем не нужен.
Поэтому чаще результат просто "дорабатывают напильником" до некоего работоспособного состояния.
Как минимум потому, что полный провал проекта по водопаду признавать не хочет никто, в том числе и "ответственные лица со стороны заказчика", на которых лежит значительная доля вины с точки зрения высшего руководства заказчика.

Скажем так, полный провал внедренческих проектов по системам управления проектами, Workflow-системам и т. п. я, увы, видела. Когда внедряют, но не используют. Видела провал, когда 1С:УПП не получалось использовать для задач управленческого учета, только "для галочки" (из-за специфики бизнес-процессов заказчика). Формально результат проекта принят, но бизнес-ценности нет.
Во-первых, первый кусок функционала тоже не бесплатный (я правильно понимаю?), и о его цене, сроках и содержанию клиент будет живо интересоваться.

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

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

В этом случае можно назвать полную сумму, а конкретный функционал, который туда войдет уточнять по ходу.
Или, другой вариант из моей практики - размытые границы окончания внедрения и сопровождения. То есть руководство готово к тому, что поддержка ERP-системы обходится в месяц в сумму в определенных пределах. И "допиливание" некритичного функционала в таком формате и происходит.
36. pro-rok 250 06.09.18 10:24 Сейчас в теме
(32)
В этом случае можно назвать полную сумму, а конкретный функционал, который туда войдет уточнять по ходу.
Можем промахнуться со стоимостью или необходимо в изначальную цену закладывать все возможные риски.
И "допиливание" некритичного функционала
с не критичным согласен, а как быть с критичным?.

Дано: предприятие. Цель: запустить ERP с января 2019.
Соответственно нужно к этому сроку выполнить:
проектирование по отдельности(Agile) или все сразу(Водопад)
доработки
Обучение персонала
Перенос данных
Тут все критично, можно конечно "мелочевку" скинуть на период эксплуатации, но и то не все. На подобных проектах весь некритичный функционал всегда относиться на "потом".

Мое личное мнение от водопада никуда не уйдем, слишком много предприятия в свое время обжигалось на проектах внедрения, которые растягивались на неопределенный срок и бюджет, и заканчивались как говорит автор ТЯП-ЛЯП. Собственник бизнеса или руководитель хочет четко понимать объем финансирования и результат в конце. И тут рождается мысль, а что если совместить водопад и Agile, может получиться как раз та модель которая необходима для нашей суровой реальности. Про это нужно статью написать, Мария, как Вы считаете?
4. MariaTemchina 837 05.09.18 10:14 Сейчас в теме
(2)
что меня всегда восхищает в американцах - так это способность делать деньги из ничего ... используя при этом много красивых и непонятных слов

Да ладно, что вы всё про американцев! Наши тоже так умеют! Превратить какую-то идею в философию. Нашим даже проще - можно не придумывать красивые и непонятные слова, а взять из английского языка...
6. pm74 132 05.09.18 11:03 Сейчас в теме
(4)
взять из английского языка...
это обязательно . В английском одно слово зачастую и глагол и существительное и прилагательное , что очень удобно .

Agile software development - звучит красиво ,

Проворная разработка программ - ну , не очень ...

если выдумать новую методику , например когда нужно кодить стоя на голове , ее
лучше назвать Upside down software development
LordKim; Rain88; Vlad_2008; ducks01; MariaTemchina; +5 Ответить
7. Aphanas 136 05.09.18 11:04 Сейчас в теме
Остается только вопрос - кто за всё это заплатит?

Повысить результативность? Да легко! Хоть до космических пределов.
Ресурсов давайте побольше раз в сто.

ЗЫ: И времени.
8. MariaTemchina 837 05.09.18 11:25 Сейчас в теме
(7)
Повысить результативность? Да легко! Хоть до космических пределов. Ресурсов давайте побольше раз в сто.

Если вы получите в сто раз больше ресурсов и сделаете больше в 50 раз - тут нельзя говорить про рост результативности ;-)))
9. sahn 05.09.18 12:10 Сейчас в теме
Все смешалось, кони, люди... Цели, задачи, реализация - в котел, добавить личных мотиваций по вкусу... Результат в тумане. Дао пути, реализация как суть, как процесс... Хочешь стать по настоящему богатым человеком - придумай религию... Слава Богу самолеты по методике Agile не строят, поскольку паровозы не летают. Если проект не укладывается в голове, не формализуется - то и не взлетает. Идя на поводу заказчика, его хотелок, диаметрально противополжных в подразделениях предприятия приходим к успешному внедрению? Сунь Цзы принесет больше результата, нежели Agile IMHO.
strange2007; Gilev.Vyacheslav; +2 Ответить
12. MariaTemchina 837 05.09.18 13:37 Сейчас в теме
(9) /Ушла читать Сунь Цзы/ .

Если серьезно, то у Agile методов есть серьезные ограничения. Не надо строить самолет по методике Agile - в этом Вы, sahn, совершенно правы. Самолет нужно строить по водопаду (см. мою статью https://infostart.ru/public/871965/ ).
А вот, допустим, исследование по методам уменьшения турбулентности для самолета можно проводить по Agile. Предположили, попробовали, провели ретроспективу, попробовали еще раз и т. п.

Про хотелки - тоже всё непросто. Еще раз вспомню мысль про то, что очень часто "заказчик и пользователи считают, что знают, что именно им нужно до тех пор, пока вы не даете то, что они просили". Как раз при Agile, когда вы выдаете модель, прототип, кусочек с тем, что они заказывали - заказчики скорее осознают, что это не то, и сумеют к концу проекта одуматься и переформулировать требования. А в водопаде очень часто мы имеем записанные в ТЗ требования в формате "7 параллельных пересекающихся зеленых линий красного цвета", и никуда от них не уйдем.

P. S. А Сунь Цзы действительно надо будет почитать... Я с ним пока знакома только в переложении Владимира Тарасова, но уже понимаю, что сильный стратег...
16. pm74 132 05.09.18 14:42 Сейчас в теме
(12)[
А вот, допустим, исследование по методам уменьшения турбулентности для самолета можно проводить по Agile. Предположили, попробовали, провели ретроспективу, попробовали еще раз и т. п.

- Друзья 2 последних разбившихся самолёта показали , что наша методика уменьшения турбулентности не сработала. Какие идеи?
-. Может крылья жёлтой краской покрасим.
Gilev.Vyacheslav; MariaTemchina; +2 Ответить
19. Дмитрий Кузнецов 3 05.09.18 15:44 Сейчас в теме
(16) Для этого есть мат.моделирование, испытания в аэродинамической трубе, создание моделей и прототипов. И как правило, если выяснилось, что турбулентность выше расчетной, ни один конструктор не скажет - вот план, через 2 месяца найдем причину и устраним ее. Потому что ее, возможно нельзя устранить на данном этапе развития технологии. В принципе нельзя. Таких случаев в истории авиации тоже не мало.
57. strange2007 134 24.10.18 09:13 Сейчас в теме
(12)
Как раз при Agile, когда вы выдаете модель, прототип, кусочек с тем, что они заказывали - заказчики скорее осознают, что это не то, и сумеют к концу проекта одуматься и переформулировать требования

Либо Вы откровенно не договариваете, либо предоставляете не совсем качественные услуги. Ведь именно поэтому заказчики часто недовольны, что франч сделал как просил заказчик, а потом долгие годы проблем и денежных потерь остаются с заказчиком.
Например, один из наикрутейших франчей, который получал от одной конторы огромные деньги ежемесячно, добавил уникальную кнопку на договоры, при нажатии на которую договор мог становиться либо с покупателем, либо с поставщиком. Всё по методикам (каким, не знаю и знать не хочу, хоть и рекламировали) - Штат бухгалтеров раздут (контролируют плавающие договора и контролёр за контролёрами), программистов орава, все работают, отчитываются результатах...
Ну? Вы ж понимаете, что так нельзя поступать? Вы поймите, это прописные истины и Вы их перечёркиваете: Заказчик никогда не признает ошибку, если от этого зависит голова на его плечах. Люди очень ленивы к изменениям и если привыкли с 1998 года так вести договоры, то и в 2008 году им тоже будет так привычней. Неужели Вы не знаете основу этих познаний заказчика??? Да на любом предприятии есть один или несколько зазнаек, которые точно уверены, что у них уникальные в стране (в мире) бизнес-процессы и только они являются обладателями этих знаний. Это же основы основ всех автоматизаций!
Нет, конечно же это мой хлеб - исправлять предприятия после горе-автоматизаторов, но мне же обидно за нас, за программистов. Эх... агля всё больше и больше отталкивает.
14. Дмитрий Кузнецов 3 05.09.18 14:32 Сейчас в теме
(9) В общем-то, самолеты строили и по Agile. Возьмите историю любого массового боевого самолет второй мировой войны, увидите все это - постоянное изменение требований, расширение функционала, необходимость частых поставок новых модификаций, тесную работу с заказчиком. Неплохо получалось в общем-то. По водопаду тоже строили много чего. Хрестоматийный XB-70 например, или сверхзвуковые пассажирские, судьба которых не впечатляет.
27. 🅵🅾️🆇 05.09.18 18:33 Сейчас в теме
(9) Почти всегда веду разработку в одиночку и по agile. На небольших проектах пока вы получите техзадание, мой пользователь уже будет вовсю использовать готовый продукт.

Да, с минимум документации (а она и не нужна, если есть всего 1 кнопка: "сделать хорошо"), да кое-где с довольно велосипедно-костыльной реализацией, зато получит то, что ему надо, а не то что хотел. И получит гораздо быстрее, приложив минимум усилий (пару раз пощупать, дать фидбэк на словах).
38. acanta 67 06.09.18 12:22 Сейчас в теме
(27) по agile клиент получает не то что ему надо, а то, на что хватает времени и сил у него и у разработчика.
В водопаде - на что хватает денег.
В этих подходах используются разные виды ресурсов, точнее человекоемкость аджайла выше чем материалоемкость/фондоемкость.
Единственный мотив заказчика в пользу аджайла- когда внимание специалистов стоит дешевле чем готовое оборудование с готовой документацией и плановым обучением. Аджайл - это инструмент (проект исследования) для разработки водопада(стандарта), который получат следующие клиенты в следующих проектах. Успех заказчика в аджайл - это побочный эффект, а не цель. Если проект привел к привел к вырождению аджайл в тяп-ляп значит неправильно определены спринты.
10. Olga_aku 05.09.18 13:25 Сейчас в теме
Статья понравилась. Спасибо.
MariaTemchina; +1 Ответить
11. MariaTemchina 837 05.09.18 13:30 Сейчас в теме
(10) Olga_aku - спасибо на тёплом слове.
15. andironenko 630 05.09.18 14:37 Сейчас в теме
У гибких (итеративных) методов работы есть один существенный минус - требуется некий специальный визионер, который видит картину целиком - и не с точки зрения текущего спринта, а с точки зрения того, к чему всё это должно прийти после завершения последнего спринта. И тут возникает концептуальная проблема - а мы не знаем какой у нас будет последний спринт. Мы плывем в потоке текущих задач - максимум что у нас есть - это бэклог, где есть какой общий список задач, но насколько он полон мы не знаем.

То есть тактически Agile великолепен, но совершенно не гарантирует качественного решения в итоге проекта. Живой пример такого проекта - это работающая конфигурация 1С, после 2-3-4 лет эксплуатации, когда она дорабатывается силами своего отдела (такие доработки достаточно близки к идеологии Agile - работа идет небольшими циклами под конкретный запрос конкретного ЛПРа) - за редким исключением ситуация там характеризуется так - "Мы вот тут наворотили в процессе. Криво конечно получилось, сейчас бы сделали по другому, но сейчас проще новую программу поставить с нуля, чем делать на текущей".

Вторая критическая проблема - это продажа таких проектов заказчику при работе в подрядной организации. Заказчики хотят фиксированную стоимость проекта +/- допустимые колебания. Agile этого совершенно не гарантирует.
CheBurator; Gilev.Vyacheslav; +2 Ответить
17. MariaTemchina 837 05.09.18 15:26 Сейчас в теме
(15)
У гибких (итеративных) методов работы есть один существенный минус - требуется некий специальный визионер, который видит картину целиком

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

То есть тактически Agile великолепен, но совершенно не гарантирует качественного решения в итоге проекта.

Качественного решения никто не гарантирует ))). Но на самом деле, вы по существу правы. У Agile есть существенные ограничения, и он подходит далеко не для всех проектов. Скажем, 1С рекомендует применять гибкую методологию 1С:ТБР (технология быстрого результата) только для более-менее типовых внедрений, не сопровождающихся кардинальной переработкой архитектуры. Потому что кардинальную переработку архитектуры лучше планировать целиком, а не по кусочкам.

Вторая критическая проблема - это продажа таких проектов заказчику при работе в подрядной организации. Заказчики хотят фиксированную стоимость проекта +/- допустимые колебания. Agile этого совершенно не гарантирует.

Это проблема, да. Большинство франчайзи, успешно или не успешно пытающиеся внедрять Agile говорят о том, что это сложно. А те, кому удается, отвечают обычно примерно следующее: "Заказчик хочет видеть фиксированную стоимость, но после провала нескольких проектов по водопаду, когда он получает абсолютно ненужный ему результат, скрипя сердце соглашается на Agile".

Как-то так...
45. andironenko 630 07.09.18 11:05 Сейчас в теме
(17)
нам нужен не только при работе по Agile, но и при работе по любой методологии, включая водопад

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

Скажем, 1С рекомендует применять гибкую методологию 1С:ТБР (технология быстрого результата) только для более-менее типовых внедрений


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

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


Старая истина - лучше всего проект внедряет "вторая" команда. Накопленный опыт ошибок в рамках первых попыток - это бесценный опыт - тут уже и заказчик знает что он хочет и сам он гораздо более сговорчив и ставит реалистичные цели. У нас в Раздолье ситуация обратная - много обращений от тех кто внедрял 1С:ERP с использованием гибких методик и где ситуация зашла в тупик - вроде бы всё было хорошо в процессе, но бюджет съели, а систему так и не запустили в эксплуатацию. Задают вопрос - что делать? Мы вынуждены предлагать собирать новый бюджет и звать нас.
50. Vladimir Litvinenko 07.09.18 19:56 Сейчас в теме
(45)
а систему так и не запустили в эксплуатацию

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

В случае если речь идет о скраме, то итеративный инкрементальный подход предполагает готовность продукта к выпуску в конце каждой итерации (спринта) независимо от того, решит продакт-оунер делать релиз или нет. Это фундаментальный принцип. Работа над продуктом в этой концепции - это фактически множество проектов аналогичных водопаду длинной 1-4 недели. Пускай продукт на первой итерации можно использовать только для справочного ведения НСИ, но нужно сделать так, чтобы это было ценно и применимо. На второй итерации можно запустить для оприходования и реализации. Но его действительно можно запустить. Следующая итерация - новый "водопадный" мини-проект в конце которого опять будет "инкремент" - новая версия работоспособного продукта. И оценка качества этого проекта - спринт ревью и ретроспектива. Подготовка к следующему мини-проекту для выпуска следующей жизнеспособной версии продукта.

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


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


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


"Although implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices." - напутствие от авторов ))


Да, подготовка продукта к тому чтобы он был работоспособен и готов к релизу в конце каждой итерации - это дополнительные затраты ресурсов. Его надо всесторонне протестировать к концу каждого спринта, подготовить поставку для релиза в виде cf- или setup- файла. И здесь не получится просто "ускориться в 4 раза". Это плата за снижение рисков и готовность инкремента к релизу. Скорость же затем можно вернуть за счет применения DevOps практик, которые к сожалению в 1С пока слабо развиты.

И конечно, если команда (в смысле бизнеса, а не группы разработчиков) не готова отказаться от идеи оторвать два колеса от автомобиля, или ставит целью исключительно увеличение скорости, а не снижения рисков за счет готовности каждого инкремента к релизу, то лучше просчитанный на полгода вперед водопадный подход. В нем может выручить высокая квалификация специалистов в команде разработки и большой опыт аналогичных крупных проектов.
55. acanta 67 08.09.18 20:32 Сейчас в теме
(50)
А потом как снег на голову оказывается, что проект на новой итерации "неожиданно" потребовал навыков, которых пока нет. "Неожиданно пришла зима".

Вы правы. Причина провала всегда одна - у команды нет компетенций, необходимых для следующего спринта.
26. pm74 132 05.09.18 17:23 Сейчас в теме
(15)
Живой пример такого проекта - это работающая конфигурация 1С, после 2-3-4 лет эксплуатации, когда она дорабатывается силами своего отдела (такие доработки достаточно близки к идеологии Agile - работа идет небольшими циклами под конкретный запрос конкретного ЛПРа) - за редким исключением ситуация там характеризуется так - "Мы вот тут наворотили в процессе. Криво конечно получилось, сейчас бы сделали по другому, но сейчас проще новую программу поставить с нуля, чем делать на текущей".


Абсолютно " в точку". Я еще называю это лоскутной разработкой. Тут пришили , здесь прилепили . В итоге получается "кафтан" почти полностью сделанный из лоскутков , который трудно перекраивать , но зато он сидит по размеру и часто имеет оригинальный фасон.
18. Дмитрий Кузнецов 3 05.09.18 15:38 Сейчас в теме
Когда мы говорим, что "Agile великолепен, но совершенно не гарантирует качественного решения в итоге проекта", имеем ли мы в виду что он не гарантирует решения "В СРАВНЕНИИ С" другими методологиями? Есть ведь известная фраза про демократию, которая не гарантирует качественного управления (но все остальные режимы не гарантируют его как минимум в такой же степени). Насколько реально предсказуемой оказывается работа по водопадному методу, если смотреть постфактум?

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

Может быть, в популярности водопада гораздо больше социально-психологических причин? Легче продать заказчику проект по водопадной модели, а потом в случае выхода за рамки обосновать его (особенно если заказчик меняет требования сам - "вы сами видите, теперь надо переделывать"), чем изначально сказать - один Бог знает, сколько это займет все (пусть это и будет правда).
Vladimir Litvinenko; MariaTemchina; +2 Ответить
46. andironenko 630 07.09.18 11:08 Сейчас в теме
(18)
етодологии применяются к разным ситуациям. При тех уровнях неопределенности, где работают гибкие методологии, водопад не то что был бы дольше или дороже - он был бы невозможен, как невозможно плавать в пустом бассейне. Это тоже может сказываться на качестве сравнения - в


Для ответа на эти вопросы написал эту статью https://infostart.ru/public/898904/
20. Fragster 930 05.09.18 15:55 Сейчас в теме
22. MariaTemchina 837 05.09.18 16:07 Сейчас в теме
(20) Он рядом с 5-ым, я их вместе комментировала.
21. herfis 283 05.09.18 16:05 Сейчас в теме
Смотрю на этот цикл статей и на другие подобные статьи в интернете - имя им легион.
Все правильно, все солидно, все взвешенно и - абсолютно бесполезно.
Ну да - объясняются концепции, если человек вообще ничего про это не слышал.
Но смех в том, что эти концепции можно разъяснить несколькими матерными предложениями. Все остальное - мишура по большей части. Чего сильно не хватает - так это реального практического "мяса".
Деталей хода реальных проектов и описание деталей действий и взаимодействий реальных команд.
Типа "и тут заказчик нам ТЫДЫЩЬ! Бегу к канбану и плачу...". Вот такое я почитал бы.
CheBurator; MariaTemchina; +2 Ответить
24. MariaTemchina 837 05.09.18 16:30 Сейчас в теме
(21) Вообще, и в этой, и в предыдущих статьях, я стараюсь приводить конкретные примеры конкретных внедрений (максимально деперсонифицированные, ибо не хочется ничего лишнего озвучивать)...

Может быть, стоит их описывать более жизненным языком, чтобы было "ТЫДЫЩЬ!" ?...
25. herfis 283 05.09.18 16:41 Сейчас в теме
37. Сурикат 264 06.09.18 10:54 Сейчас в теме
(21)
Для практических демонстрации практического примера в большинстве своем нанимают же консультантов.
Вы же наверняка свои знания тоже не за бесплатно предоставляете?
28. Gilev.Vyacheslav 1836 05.09.18 21:47 Сейчас в теме
все больше убеждаюсь что Agile это религия, и не более того
вы еще дом постройте или операцию больному проведите

прям вижу - больной, какой еще наркоз, а кто согласовывать будет, вот тут разрез побольше сделать?...
30. sahn 06.09.18 07:24 Сейчас в теме
Мария молодец, написала статью, мы почитали, подискутировали. В очередной раз порадовались за буржуинов, эк они красивую обертку в очередной раз создали и ее плодотворно продают. Молодцы. В целом, попытка подтянуть любое внедрение под одну методику, мало перспективно. Модель системы с обратной связью, насколько отличается от парадигмы agile? А применять когда? Каковы граничные условия и ресурсы для выбора данной конкретной методики? Мне лично, этого не хватило в статье. Хорошее описание, вырванное из контекста, попытка обобщения в рамках одной статьи. Все хорошо, но чуть - чуть чего то не хватает... Перчика?. Нет. Исходных данных. Как то так. Ждем продолжения...
33. MariaTemchina 837 06.09.18 08:44 Сейчас в теме
(30)
Модель системы с обратной связью, насколько отличается от парадигмы agile?

Об этом я писала в первой статье. Система с обратной связью, где одна поставка - это итеративная модель. Система с обратной связью где много небольших поставок - это Agile.
https://infostart.ru/public/871965/

А применять когда? Каковы граничные условия и ресурсы для выбора данной конкретной методики?

Нюанс в том, что Agile - это не одна методика, а набор методик. Поэтому четкие границы провести сложно. Это, кстати, неплохо сделала компания 1С в описании одной конкретной методологии 1С:ТБР (технология быстрого результата), которая тоже относится к "семейству" Agile. Они прям SWOT-анализ провели с границами применения (кстати, видео-урок на эту тему лежит в открытом доступе). Там рекомендуют при помощи гибких методов реализовывать внедрения не предполагающие кардинальной переработки архитектуры.
51. andironenko 630 08.09.18 00:26 Сейчас в теме
(30) можно что-то полезное сделать.
(50) А Вы когда такое пишите «в следующий спринт запустить оприходование и реализацию» складывается ощущение что Вы глубокий теоретик.
Вы как будете поддерживать систему где на складе что-то только появляется и исчезает - а где заказы? А что будете делать со взаиморасчетами? Вы в следующий спринт будете чистить регистры от левых движений? Перепривязывать накладные к заказам?
Не боитесь что пользователи побьют за обезьянью работу? А если их (пользователей) пара сотен?
(50)
52. Vladimir Litvinenko 08.09.18 01:29 Сейчас в теме
(51)

как будете поддерживать систему где на складе что-то только появляется и исчезает - а где заказы?


Хм. Например в ERP, УТ 11 заказы включаются и отключаются функциональной опцией. Система изначально предполагает возможность работать без заказов и включать их при внедрении позаказного учета, если он будет необходим. Точно также как возможность включения ордерного учета и потребность в нем на складах не означает необходимости немедленно включать его при внедрении.

Иначе продолжая эту цепочку можно сказать "Реализации, поступления и заказы!? А где же коммерческие предложения и сделки? Вы потом будете привязывать заказы к сделкам?". "А где ордерный учет, вы потом будете связывать ПТУ и ордера?" И так можно до бесконечности пока не будут включены все функциональные опции в ERP ))

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


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

И это главный признак того, что они не работали в рамках фреймворка и не применяли его. Итеративный подход конечно может привести к лоскутной автоматизации и костылям. Но это при любой модели может быть, зависит как принятие технических решений построено. BPR как раз минимизирует риск этого. Вот только неработоспособных инкрементов быть не должно. Все же нельзя обвинять машину в том, что она не работает, если ей открутили колеса и сняли двигатель ))
MariaTemchina; +1 Ответить
53. andironenko 630 08.09.18 10:10 Сейчас в теме
(30) можно что-то полезное сделать.
(50) А Вы когда такое пишите «в следующий спринт запустить оприходование и реализацию» складывается ощущение что Вы глубокий теоретик.
Вы как будете поддерживать систему где на складе что-то только появляется и исчезает - а где заказы? А что будете делать со взаиморасчетами? Вы в следующий спринт будете чистить регистры от левых движений? Перепривязывать накладные к заказам?
Не боитесь что пользователи побьют за обезьянью работу? А если их (пользователей) пара сотен?
(52)

Сколько в Вашей практике успешно выполненных проектов с числом пользователей более 100 человек?
54. Vladimir Litvinenko 08.09.18 13:39 Сейчас в теме
(53) Ушел считать и думать как мерянье "у кого больше" и переход на личности относится к вопросу о корректности примеров с командами, которые не работали в рамках фреймворка и не соблюдали его требования, и выводов о неработоспособности подхода на основе этого ))

Напомню, что изначально некоторые ребята также изначально водопад закидали, что сейчас часто приводится как самый яркий пример опасностей водопада. Хотя там проблема не в водопаде, а незаинтересованности участников проекта, эффекте "второй команды внедрения" и большей склонности заказчика к сотрудничеству после первых неудач : Sentinel Project: 5 Lessons Learned
56. andironenko 630 08.09.18 21:35 Сейчас в теме
(54) Здесь нет перехода на личность, здесь вопрос об опыте. Я бы с интересом пообщался с человеком, который имеет реальный опыт комплексной автоматизации предприятий на продуктах класса 1С:ERP с числом рабочих мест от 100. Это та комбинация (комплексность задачи, сложность программного решения, масштаб проекта), которая порождает определенные проблемы, которые в иных случаях просто не встречаются.
Поэтому я задал прямой вопрос - сколько у Вас таких проектов есть, какую часть из них Вы делали с использованием Agile, можно ли посетить одно из этих предприятий, чтобы пообщаться лично с пользователями. Если это действительно работающая практика, то я буду рад пропиарить этот опыт в сообществе - помочь в написании развёрнутой статьи с упором на те проблемы, которые не удаётся решить в водопаде и которые были решены с помощью гибких методов.
У меня действительно есть интерес к такому опыту. И не у одного меня, думаю.
Варианты: писали программу с нуля или внедряли простое решение или внедряли проект на 50 рабочих мест, к сожалению, не интересны - там нет таких проблем.
39. TODD22 18 06.09.18 12:59 Сейчас в теме
Году так в 2009 читал статью по разработке на 1с и там было описан метод "быстрого прототипирования", сделал документ, сделал форму, показал пользователю, получил обратную связь, доработал, показал пользователю, получил обратную снова доработал.... но тогда это модным словом "эйджаил" не называлось ещё....
А сейчас как верно заметили выше придумали очередную религию....

А термин эйджаил в каком году вошёл в обиход?
42. MariaTemchina 837 06.09.18 20:47 Сейчас в теме
(39) Манифест Agile был написан, если мне не изменяет память, в 2001 году. А вообще все эти идеи гораздо старше, конечно. До работающих принципов разные умные люди часто додумываются независимо. Важно это всё описать и сделать возможной передачу опыта...
40. acanta 67 06.09.18 14:44 Сейчас в теме
Уже после "Смертельного марша - руководства по выживанию в безнадежных проектах". Т.е. сначала были проекты провалившиеся по каким-либо объективным причинам. После "разборов полетов" (который сам по себе не имеет смысла, без участников команды) и классификации причин провалов появились проекты безнадежные, в которых таковые причины наличествуют изначально в большой пропорции и участники проекта это осознают. Когда же проектанты научились выживать в условиях безнадежных проектов, встал вопрос о том, а не был ли возможен успех?
Аджайл это удовлетворение потребности человека в успехах, при в целом всеобщей безнадежности. Аджайл призван снизить требования и желания заказчиков до минимального допустимого уровня "на сейчас" и при этом как-нибудь не забыть о "потом".
Без глубокого понимания этой безнадежности, я бы даже сказала физического ощущения - невозможно почувствовать успех, поскольку на каждом отдельном этапе он действительно мизерный.
41. acanta 67 06.09.18 15:28 Сейчас в теме
Если потребность в успехе у клиента и у разработчика уже удовлетворены, то аджайл это не то что можно рекомендовать клиенту. Вариант, когда потребность в успехе удовлетворена только у одной из сторон, приводит к взаимному непониманию. Аджайл - выбор двух неудачников, которые стремятся к успеху.
43. MariaTemchina 837 06.09.18 20:49 Сейчас в теме
(41) acanta - вот не люблю я такой категоричности "выбор двух неудачников"...
Не для всех ситуаций Agile подходит - согласна.
Если требования можно определить на старте и уровень технической определенности высокий - Agile тоже не нужен, согласна.
44. Infector 142 07.09.18 09:55 Сейчас в теме
47. acanta 67 07.09.18 12:45 Сейчас в теме
Т.е.все рекомендации сводятся к одному- не показывать одному исполнителю весь бюджет проекта, а на каждое очередное внедрение "под ключ" выделять максимум половину (или треть или четверть).
48. alex-l19041 8 07.09.18 16:51 Сейчас в теме
Идея Agile в том, чтобы остановить проект после выполнения куска «всегда и часто», и переключиться на другие, более ценные проекты.
- не понятно, "переключиться" - совсем? а остальное доделывать?
49. acanta 67 07.09.18 17:09 Сейчас в теме
Конечно! обязательно доделывать, но только "потом", когда договорная цена на эти доделки поднимется выше любого альтернативного проекта. Из принципа 80/20 можно предположить что в очередной проект включается 20% текущих задач. Это при условии что бэклог проекта обновляется. Следующий проект - 20% из актуального бэклога, которые декомпозируем на спринты и т.д.
Идея водопада - не допустить повышения цен на доделки, доделывание или исправление ошибок всегда бесплатное. Таким образом пик затрат у разработчика в водопаде приходится на окончание проекта.
58. user1124189 06.01.19 22:46 Сейчас в теме
Когда работал в консалтинговой компании, левая колонка весила процентов тридцать, правая - 70. Перешел в самозанятый режим - и левая колонка обнулилась, 100% - в правой.
Оставьте свое сообщение

См. также

Незакрытый проект на 1000 часов 62

Статья no Нет файла Россия Бесплатно (free) Управление проектом

История о незакрытом проекте, о бессонных ночах, о попытках его выгрести, о бесплатной работе, о вселенской боли.

19.09.2019    6929    ogroup    153       

Стратегия выживания в корпоративных войнах 47

Статья no Нет файла Бесплатно (free) Управление проектом

Айтишникам сложно строить карьеру управленца. И все потому, что в их «техническое ДНК» не заложено умение справляться с окружающими их интригами. Однако, поскольку это навык, это можно исправить, считает ИТ-директор в ПАО «Светлана». На конференции Infostart Event 2018 он поделился с коллегами, что и как надо делать, чтобы не погрязнуть в корпоративных интригах и сделать так, чтобы они не мешали выполнению основной работы.

16.09.2019    4099    GSoft    14       

Мастер-класс СППР 39

Статья Программист Руководитель проекта Нет файла Бесплатно (free) Управление проектом СППР

Сергей Наумов, в прошлом разработчик подсистемы бюджетирования в конфигурации «1С:ERP», на мастер-классе конференции INFOSTART EVENT 2018 EDUCATION поделился опытом управления проектами с помощью «1С:Системы проектирования прикладных решений» и показал, как использовать эту программу в работе над разными задачами: для сбора, классификации и хранения требований; для управления разработчиками и консультантами; в качестве системы документирования; в качестве баг-трекера на этапе опытно-промышленной эксплуатации.

30.08.2019    3272    SergeyN    4       

Быстрый старт: минимальный набор автоматизации типовых процессов 21

Статья no Нет файла 1С:Франчайзи, автоматизация бизнеса Бесплатно (free) Управление проектом

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

16.08.2019    3707    Hissin    18       

Как заработать миллион или История успешного сотрудничества 45

Статья Программист Нет файла Бесплатно (free) Управление проектом

Многие мечтают один раз что-то создать, а потом жить на заработанные деньги до конца своих дней. Но миллионерами становятся не все, их единицы. Среди них – разработчик Андрей Карпов. Человек, который сумел за полтора года заработать 2 миллиона рублей чистой прибыли, поделился с гостями конференции Infostart своими секретами.

05.08.2019    4098    karpik666    77       

Бизнес-аналитика с помощью Power BI 65

Статья Руководитель проекта Нет файла Бесплатно (free) Управление проектом

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

11.07.2019    6357    pbazeliuk    18       

Управление проектами по автоматизации бюджетирования 35

Статья Бизнес-аналитик Руководитель проекта Нет файла УУ Финансовый учет и бюджетирование (FRP) Бесплатно (free) Управление проектом

Автоматизация бюджетирования позволяет максимально эффективно планировать ресурсы предприятия и управлять масштабированием компании. Как учесть особенности бюджетирования, встроить его в процессы стратегического планирования, чтобы получить гибкий инструмент управления и аналитики, рассказал Сергей Наумов на конференции INFOSTART EVENT 2018 EDUCATION.

28.06.2019    3194    SergeyN    1       

Внедрение решений: как выполнять все обязательства в срок в условиях ограниченных ресурсов 22

Статья Руководитель проекта Нет файла Бесплатно (free) Управление проектом

Многие менеджеры вынуждены работать в условиях многоклиентской среды с ограниченными ресурсами. И вовремя сдавать проекты в таких условиях сложно. Как добиться того, чтобы поставки делались без нарушений сроков, рассказал гостям и участникам конференции Infostart Event 2018 управляющий партнер BIPULSE.RU Алексей Васильев.

24.06.2019    2671    sbase    9       

Риск - благородное дело!.. Часть первая 31

Статья Бизнес-аналитик Руководитель проекта Нет файла Бесплатно (free) Управление проектом

Несколько рекомендаций по управлению рисками в ИТ-проектах.

18.06.2019    3821    MariaTemchina    8       

Мы в ответе за то, чего вовремя не послали. Матрица ответственности в проектах внедрения 31

Статья Бизнес-аналитик Руководитель проекта Нет файла Бесплатно (free) Управление проектом

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

31.05.2019    4132    MariaTemchina    23       

Как продать проект в 3 раза дороже и нанести клиенту пользу, выполнив не внедрение... 21

Статья Бизнес-аналитик Руководитель проекта Нет файла Бесплатно (free) Управление проектом

Практически все российские компании нуждаются не просто в установке 1С:ERP, 1С:Документооборота или какой-то другой программы, а в масштабных организационных изменениях, но мало кто из заказчиков это понимает. Те, кто занимается 1С, могут помочь бизнесу решить его проблемы, а заодно и продать проект внедрения в несколько раз дороже. Как это сделать, на конференции INFOSTART EVENT 2018 EDUCATION рассказал собственник и директор компании «Корада» Алексей Бояршинов.

27.05.2019    4181    cybrat    9       

Устав писать Устав 31

Статья Бизнес-аналитик Руководитель проекта Нет файла Бесплатно (free) Управление проектом

Ответы на вопросы про то, нужен ли Устав для проектов автоматизации, и если нужен, то зачем?

06.05.2019    4034    MariaTemchina    8       

Как сжать время? 22

Статья no Нет файла 1С:Франчайзи, автоматизация бизнеса Бесплатно (free) Управление проектом Личная эффективность

Как, и зачем измерять задачи в чем-то, помимо часов.

04.05.2019    4705    1c-intelligence    39       

Путь джедая в управлении проектами 1С: умение быть, а не казаться 36

Статья Бизнес-аналитик Руководитель проекта Нет файла Бесплатно (free) Управление проектом

Чем руководитель проекта “на бумаге” отличается от “настоящего” руководителя проекта, умеющего направлять команду и выдавать ценный результат?

15.04.2019    6764    MariaTemchina    15       

Управление ИТ-проектами, базовый курс, 3 поток. Онлайн-курс с 15 мая по 1 июля 2019 16

Курс Бизнес-аналитик Руководитель проекта Нет файла Бесплатно (free) Управление проектом

Отличительная черта курса - органичное сочетание трех вещей: - Теория проектного управления (PMI®+Agile Alliance+Российские ГОСТ+Методологии от 1С)  - Опыт внедрения продуктов 1С (опыт франчайзи и успешных компаний + тренды Infostart Event и Agile Days) - Разбор реальных проблем и рекомендации экспертов по проектам слушателей Мы будем фиксироваться на тех инструментах, которые реально оказываются полезными в практике  руководителей проектов внедрения. 

04.04.2019    9257    infostart    18       

Стыд и Скрам, часть вторая 21

Статья Бизнес-аналитик Руководитель проекта Нет файла Бесплатно (free) Управление проектом

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

14.03.2019    7752    MariaTemchina    47       

20 мыслей об ИТ-проектах. Мысль №2. "С какой стороны подойти к новому проекту?" 38

Статья Руководитель проекта Нет файла Бесплатно (free) Управление проектом

Продолжаем серию статей из цикла “20 мыслей об ИТ-проектах”. Сегодня мы поговорим о том, с какой стороны подойти к новому проекту. Такой вопрос возникал у каждого, кому приходилось выступать в роли руководителя проектов, особенно первый раз. Да и для опытных РП некоторые проекты вызывают аналогичный вопрос.

13.02.2019    4419    chavalah    22       

Стыд и скрам - Чему нас учит Scream Guide 29

Статья Бизнес-аналитик Руководитель проекта Нет файла Бесплатно (free) Управление проектом

Название "Scream Guide" можно вольно перевести на русский как “Вопль ужаса от того, как Scrum применяют на практике”

12.02.2019    6097    MariaTemchina    20       

Бизнес, не горюй 33

Статья no Нет файла Бесплатно (free) Управление проектом

Про цели автоматизации.

04.02.2019    5772    1c-intelligence    64       

Лучший домик для поросенка, или Что нужно знать руководителю проекта внедрения 23

Статья Бизнес-аналитик Руководитель проекта Нет файла Бесплатно (free) Управление проектом

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

31.01.2019    4986    MariaTemchina    0       

Ошибки управленцев: как топ-менеджеров убивает перфекционизм 5

Статья no Нет файла Бесплатно (free) Управление проектом

В преддверии онлайн-конференции «Гнев и слезы руководителя» мы решили заранее познакомить нашу аудиторию со спикерами, причем сделать это через видео-истории. Начнем с видео-приглашения от Миланы Джиджоевой и ее виденья диджитализации рекрутинга в России.

24.01.2019    6139    user809424    11       

Что немцу хорошо, то русскому... Как минимум, небезынтересно. Продолжаем тему Канбан 31

Статья Бизнес-аналитик Руководитель проекта Нет файла Бесплатно (free) Управление проектом

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

14.01.2019    6604    MariaTemchina    13       

20 мыслей об ИТ-проектах. Мысль №1. "О незаменимых людях" 62

Статья no Нет файла Бесплатно (free) Управление проектом

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

10.01.2019    8973    chavalah    123       

Где мы взяли флакон? 38

Статья no Нет файла Бесплатно (free) Управление бизнес-процессами (BPM) Управление проектом

История появления и развития методики

26.12.2018    6197    1c-intelligence    7       

Озарение после прочтения макулатуры по проектному управлению 42

Статья Бизнес-аналитик Руководитель проекта Нет файла Бесплатно (free) Управление проектом

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

19.12.2018    6473    MariaTemchina    24       

20 мыслей об ИТ-проектах, или 20 лет спустя. 53

Статья no Нет файла Бесплатно (free) Управление проектом

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

09.12.2018    5941    chavalah    119       

Памятка руководителя: не играйте с деньгами 83

Статья Пользователь Руководитель проекта Нет файла Бесплатно (free) Управление проектом Личная эффективность Управление персоналом (HRM)

Важная статья о персонале из цикла «Памятка руководителя»: здесь я планирую затронуть один из наиболее острых вопросов – деньги. А также развернуто ответить на некоторые комментарий читателей по двум прошлым статьям.

05.12.2018    13242    andironenko    128       

Шаг назад и ... шаг назад (классификация внутренних проектов) 34

Статья Пользователь Руководитель проекта Нет файла Бесплатно (free) Управление проектом

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

03.12.2018    5517    capitan    26       

Белая и пушистая рецензия на Чёрную книгу Скрам 31

Статья Бизнес-аналитик Пользователь Руководитель проекта Нет файла Бесплатно (free) Управление проектом

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

26.11.2018    6715    MariaTemchina    40       

Черная книга Скрам 21

Статья Бизнес-аналитик Пользователь Руководитель проекта Архив с данными Бесплатно (free) Управление проектом

Наблюдения менеджера, разрушившего карьеру бездумным применением Скрам. Рекомендации и предостережения.

26.11.2018    5535    356    Selikhovkin    4       

"Черные страницы Scrum", по версии Ивана Селиховкина 21

Статья no Нет файла Бесплатно (free) Управление проектом

Иван Селиховкин более 12 лет занимается управлением проектами, программами, портфелями. И в статье он расскажет о проблемах использования Scrum, которые могут поставить под угрозу вашу карьеру или ваш проект, если вы неловко неудачно примените этот фреймворк.

23.11.2018    7847    Selikhovkin    8       

Памятка руководителя: Будьте оптимистичным или на крайний случай злым 46

Статья no Нет файла Бесплатно (free) Блоги Управление проектом

Следующая статья из цикла Управление персоналом - в этот раз предлагаю обсудить вопросы психологии управления и подчинения. Для тех, кто начинает читать этот цикл с этой статьи, вот ссылка на прошлый материал https://infostart.ru/public/937923/, в конце статьи будут ссылки на все статьи из серии «Памятка руководителя» - читатели просили. Итак, продолжаем работать с персоналом.

22.11.2018    8907    andironenko    43       

Scrum за 5 минут (заметки) 25

Статья no Нет файла Бесплатно (free) Управление проектом

Первый опыт создания статьи в сообществе. Немного о Scrum и нашем знакомстве.

20.11.2018    5097    leobrn    11       

Создание концепции проекта (project scope statement). Курс по управлению проектами, часть 8 30

Статья Системный администратор Бизнес-аналитик Пользователь Руководитель проекта Нет файла Бесплатно (free) Управление проектом

Что такое концепция проекта? Это понятие, близкое по смыслу к техническому заданию (ТЗ). Одно из определений концепции - детальное, целостное описание работ в удобной для команды форме.

19.11.2018    4945    Selikhovkin    1       

Роевой интеллект (Swarm intelligence) как метод управления проектами (анти-утопия) 35

Статья no Нет файла Бесплатно (free) Управление проектом

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

19.11.2018    6282    capitan    41       

Почему внедрение ERP-системы не приносит пользы бизнесу? 87

Статья Бизнес-аналитик Пользователь Руководитель проекта Нет файла Бесплатно (free) Интеграция Управление проектом

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

15.11.2018    15706    rossoxa    62       

Думать некогда, трясти надо - или что такое ретроспектива в Agile 30

Статья Бизнес-аналитик Пользователь Руководитель проекта Нет файла Бесплатно (free) Управление проектом

12-ый принцип Agile-манифеста, как известно, гласит: "Каждый раз в конце заранее определенного интервала времени команда размышляет, как повысить результативность своей работы, и затем вносит коррективы в процессы." Попробуем разобраться, как это стоит, а как не стоит делать на практике. 

13.11.2018    7288    MariaTemchina    16       

Памятка руководителя: В одиночку здесь не выжить 43

Статья Пользователь Руководитель проекта Нет файла Бесплатно (free) Управление проектом Личная эффективность

Продолжаю цикл материалов, в котором рассказываю о своем опыте работы в качестве директора по ИТ. Этот материал будет посвящен теме управления персоналом.

07.11.2018    9255    andironenko    62       

Приоритизировали, приоритизировали, да не выприоритизировали... 28

Статья Бизнес-аналитик Пользователь Руководитель проекта Нет файла Бесплатно (free) Управление проектом

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

30.10.2018    6110    MariaTemchina    47       

Памятка руководителя: Уволь HRа и найди себе хороших сотрудников 67

Статья Руководитель проекта Нет файла Управление персоналом (HRM) Бесплатно (free) Управление проектом

Продолжаю цикл «Памятка руководителя». Эта статья будет на тему поиска новых сотрудников и одной грубой ошибки при проведении собеседования.

29.10.2018    8909    andironenko    35       

Принцип быстрой автоматизации 22

Статья Программист Нет файла Бесплатно (free) Управление проектом

Как выполняется автоматизация в бизнес-программировании?

29.10.2018    6337    1c-intelligence    19       

Опыт внедрения ESB (интеграционной шины) в ПАО "Газпром нефть" 34

Статья no Нет файла Бесплатно (free) Управление проектом

Харитонов Михаил описывает проект по внедрению интеграционной сервисной шины предприятия (ESB) «2iS:Интеграция» на платформе “1С:Предприятие 8” в компании ПАО «Газпром нефть». Проект уникален тем, что это – первое решение, использующее отечественное ПО в качестве полноценной интеграционной шины для столь крупного заказчика с обширным ИТ-ландшафтом. В статье подробно рассмотрена архитектура решения, способы тестирования и масштабирования.

17.10.2018    7353    Mick2iS    8       

#БезОценок, или Как перестать беспокоиться об оценке проекта, всегда успевать в срок и укладываться в бюджет 32

Статья Пользователь Руководитель проекта Нет файла Бесплатно (free) Управление проектом

Считается, что для планирования и принятия решений по проектам их нужно прогнозировать и оценивать. Александр Белов, генеральный директор и руководитель проектов ГК «Белов и партнеры», рассказывает, почему стоит отказаться от оценок.

11.10.2018    5240    AlexWhite    7       

Профессиональные стандарты в ИТ как инструмент кадровой политики организации 21

Исследование Программист Пользователь Руководитель проекта Нет файла Обучение, бизнес-тренинг, курсы ИТ-компания 1С:Франчайзи, автоматизация бизнеса Россия Бесплатно (free) Управление проектом

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

08.10.2018    7733    39    infostart    4       

Построение высокоэффективной Agile-команды 34

Статья no Нет файла Бесплатно (free) Управление проектом

Меня зовут Асхат Уразбаев, я из компании ScrumTrek. Наша компания помогает внедрять Agile, Scrum, Kanban – гибкие методологии и гибкие подходы. К миру 1С я совсем не принадлежу, но в прошлом я, тем не менее, программист – занимался разработкой на самых разных языках программирования. Помимо основной деятельности у меня было несколько технологических стартапов, в которые я был так или иначе вовлечен. И сегодня мы поговорим о том, как сделать так, чтобы команда была крутой и эффективной.

08.10.2018    5227    askhatu    15       

История одного провала внедрения 1С:ERP 2 по классической технологии. С последующим спасением по Scrum 106

Статья no Нет файла Бесплатно (free) Управление проектом

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

01.10.2018    13349    glebushka    41       

Контракты Agile: как заключать договора в условиях расползания содержания 41

Статья Системный администратор Пользователь Руководитель проекта Нет файла Бесплатно (free) Управление проектом

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

25.09.2018    6828    MariaTemchina    10