Комментарии 12
Почему Agile не помог
начали тиражировать приложение в промышленную эксплуатацию
мы радостно и весело стали переписывать половину интерфейса приложения, так как гайдлайны Apple ничего не понимают о дизайне корпоративных приложений, и нужно было срочно сделать устаревшие формы экранов из iPad на iPhone
Именно поэтому не помог?
Я вообще это не понял, то ли они столкнулись с гайдлайнами то ли с начальником, а фраза про гайдлайны это ирония.
Если "успешно прошли приемо-сдаточные испытание", то значит новое требование начальника про интерфейс это должно быть хорошо, так как это новая работа за новое бабло. Старую итерацию сдали.
Да, фраза про гайдлайны — ирония. Почему не помог — написано в последнем разделе «Выводы или зачем нужна эта статья», если убрать воду, то суть, что agile не всегда работает на больших начальниках, потому что это большие начальники в российской действительности. И новое бабло не всегда можно стрясти за новую работу в отношениях заказчик-исполнитель.
А как именно вы с этим справились? Мне логически кажется, что если кто-то требует изменений сверх утвержденных и принятых требований есть три варианта:
- или не работать с ним
- или он риск берет на себя (судиться по факту того, что утвержденный интерфейс не принимается)
- или брать риск на себя (заряжать побольше сумму на такие фортели изначально)
НЛО прилетело и опубликовало эту надпись здесь
ой а на моём iphone 5 буковки маленькие, срочно переделать!!!».
Для таких кейсов и использкется аджайл. Можно что-то исправить в том, о чем и не думали на старте
Спасибо за комментарий! Проблема проекта была именно в самодурстве, и хотелось поделиться опытом, чтобы «снять розовые очки», так как идеальные методологии не всегда работают.
Agile это набор практик. В данном случае, учитывая ограничения, далеко не все эти практики имели смысл. Учитывая ограничения бюджета, большой скоуп и отсутствие внятных требований тут нет однозначного ответа "что правильно". С позиции аутсорсинговой компании, имхо, надо или отказываться или дожимать на t&m. Если это внутренний продукт то компенсировать очень опытным pm-ом/тимлидом технарем, чтобы мог объективно налёту рубить как загоны всяких начальников так и разрабов оглядываясь на бюджет, сложность, бизнес логику (т.е почти всегда провальная тема)
Спасибо за то что поделились статьей, к сожалению не могу проголосовать, но «неистово плюсую».
И здорово что вы выделили самое главное — как бы то оно ни было — приложение используется, а значит цель достигнута — заказчик получил ценность! Что может быть более Agile?
Единственное я хотел бы прокомментировать несколько моментов с точки зрения человека, который внедрял и внедряет Agile в структуры по сравнению с которыми в РФ по бюрократии
— чистая халява (ага, я тоже думал что «у них-то там никакой бюрократии...» вот, короче, я удивился-то. Я первое время работу со структурами типа областной администрации или Газпрома вспоминал как легчайших период в карьере. :-))
А как работать с рисками недоступности стейкхолдеров, да и в принципе как работать с рисками методологии Agile не учат.
Я не уверен какой именно Agile подход использовала ваша команда, но XP, Scrum, SAFE, LESS, DA очень даже уделяют огромное внимание этому вопросу. И как обходиться с рисками недоступности стейкхолдеров, и что может сделать команда, чтобы их преодолеть.
Мне так кажется что вы совершенно правильно обозначили в статье то место, где что-то пошло не так. 18 релизов ушло только на то, чтобы получить «releasable increment» (который вообще-то должен появляться каждую итерацию) и только в этот момент он стал обладать достаточной бизнес-ценностью чтобы реальные стейкхолдеры заинтересовались его существованием.
Я бы сказал что если мы возьмем Scrum Guide — то его часть «maximization of the value delivered» и «releasable increment» как основа инспекции, прозрачности и адаптации — это очень простые, но часто вызывающие ошибку кусочки мозаики. Scrum тут для примера, в остальных походах есть совершенно аналогичные моменты.
Собственно, мы не заинтересуем stakeholder и не получим от него feedback если
— продукт который мы поставляем в результате итерации приносит хоть чего-то ценного/полезного с точки зрения stakeholders (value!).
— ну и, естественно, если продукт нельзя дать stakeholder'у попользоваться — (relesable!) то и посмотреть и оценить он/она его не смогут.
Это и есть самый первый и непрерывно используемый инструмент управления риском «недоступных stakeholders» в Agile. Постоянная поставка ценности, готовой к использованию — это как раз то, что поддерживает заинтересованность и вовлеченность stakeholders.
Фраза про «не понимающие guidelines» хорошо сюда подтверждает этот момент. В Agile команда должна обладать технической экспертизой и владеть эмпирическим процессом, позволяющим достичь желаемой ценности. Но вот правомочиями определять за заказчика что же является для него ценностью — рекомендация Apple или мнение ФЗ — Agile команду не наделяет.
А еще одно из главных достоинств Agile – это отсутствие бюрократии.
И еще один миф об Agile, примерно такой же как «в Agile нет deadlines и оценок».
Agile Manifest ставит сотрудничество выше контрактов и готовность к вызовам выше плана — но это не означает полного отказа от них. Всего лишь отказ от той части процессов, документации, контракта и плана которые не приносят ценности заказчику. Однако в силу множества причин и документация, и контракт, и план могут быть самостоятельной ценностью для заказчика. А поставка ценности как раз и есть основная цель Agile. :-) Даже такой, бюрократической.
И здорово что вы выделили самое главное — как бы то оно ни было — приложение используется, а значит цель достигнута — заказчик получил ценность! Что может быть более Agile?
Единственное я хотел бы прокомментировать несколько моментов с точки зрения человека, который внедрял и внедряет Agile в структуры по сравнению с которыми в РФ по бюрократии
— чистая халява (ага, я тоже думал что «у них-то там никакой бюрократии...» вот, короче, я удивился-то. Я первое время работу со структурами типа областной администрации или Газпрома вспоминал как легчайших период в карьере. :-))
А как работать с рисками недоступности стейкхолдеров, да и в принципе как работать с рисками методологии Agile не учат.
Я не уверен какой именно Agile подход использовала ваша команда, но XP, Scrum, SAFE, LESS, DA очень даже уделяют огромное внимание этому вопросу. И как обходиться с рисками недоступности стейкхолдеров, и что может сделать команда, чтобы их преодолеть.
Мне так кажется что вы совершенно правильно обозначили в статье то место, где что-то пошло не так. 18 релизов ушло только на то, чтобы получить «releasable increment» (который вообще-то должен появляться каждую итерацию) и только в этот момент он стал обладать достаточной бизнес-ценностью чтобы реальные стейкхолдеры заинтересовались его существованием.
Я бы сказал что если мы возьмем Scrum Guide — то его часть «maximization of the value delivered» и «releasable increment» как основа инспекции, прозрачности и адаптации — это очень простые, но часто вызывающие ошибку кусочки мозаики. Scrum тут для примера, в остальных походах есть совершенно аналогичные моменты.
Собственно, мы не заинтересуем stakeholder и не получим от него feedback если
— продукт который мы поставляем в результате итерации приносит хоть чего-то ценного/полезного с точки зрения stakeholders (value!).
— ну и, естественно, если продукт нельзя дать stakeholder'у попользоваться — (relesable!) то и посмотреть и оценить он/она его не смогут.
Это и есть самый первый и непрерывно используемый инструмент управления риском «недоступных stakeholders» в Agile. Постоянная поставка ценности, готовой к использованию — это как раз то, что поддерживает заинтересованность и вовлеченность stakeholders.
Фраза про «не понимающие guidelines» хорошо сюда подтверждает этот момент. В Agile команда должна обладать технической экспертизой и владеть эмпирическим процессом, позволяющим достичь желаемой ценности. Но вот правомочиями определять за заказчика что же является для него ценностью — рекомендация Apple или мнение ФЗ — Agile команду не наделяет.
А еще одно из главных достоинств Agile – это отсутствие бюрократии.
И еще один миф об Agile, примерно такой же как «в Agile нет deadlines и оценок».
Agile Manifest ставит сотрудничество выше контрактов и готовность к вызовам выше плана — но это не означает полного отказа от них. Всего лишь отказ от той части процессов, документации, контракта и плана которые не приносят ценности заказчику. Однако в силу множества причин и документация, и контракт, и план могут быть самостоятельной ценностью для заказчика. А поставка ценности как раз и есть основная цель Agile. :-) Даже такой, бюрократической.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как мы разрабатывали корпоративное iOS-приложение по Agile, и почему он нас не спас от рисков