7890
правок
Изменения
Новая страница: «Будущее [http://agiledays.ru/members/profile/1892/#report-57 выступление '''14.03 в 12:00''' на AgileDays-2016] '''Agile - то что на…»
Будущее [http://agiledays.ru/members/profile/1892/#report-57 выступление '''14.03 в 12:00''' на AgileDays-2016] '''Agile - то что на самом деле нужно гос.заказчикам!''' в треке Agile в гос. организациях.
Я публикую эту статью, заранее представляя материал доклада. Я надеюсь на предварительное обсуждение с заинтересованными участниками, которое позволит сделать доклад лучше и интереснее, затронув аспекты, о которых я, быть может, не подозреваю.
= Аннотация доклада =
Многие доклады про использование гибких методологий разработки в проектах с государственным заказчиком рассказывают о том, как изолировать команду от заказчика для обеспечения Agile-процесса. Но нужно ли это на самом деле?
Ведь для заказчика, как правило, важно работающее программное обеспечение, а не документация на него, важно сотрудничество, а не контракты, важна готовность команды к изменениям — иными словами, те ценности, что декларирует Agile-манифест. Формальные требования воспринимаются заказчиком как дополнительная нагрузка на внутренние процессы, которые долго и сложно перестраивать. Поэтому секрет долгосрочного успешного сотрудничества — в грамотной адаптации деятельности компании-разработчика к условиям заказчика. За время доклада мы рассмотрим воплощение этого тезиса на конкретных примерах из опыта работы нашей компании с такими заказчиками, как Банк России, Газпромбанк и другими.
= Развернутые тезисы доклада =
Здесь нет разбиения на слайды, а просто развертывается логика рассказа.
# Зачем я делаю этот доклад? - представление доклада и докладчика.
## Когда поднимают тему работы с гос.заказчиком или в формальных проектах, то часто применяют методики, направленные на изоляцию команды от особенностей заказчика, что бы у них был “как бы правильный скрам”.
## Я думаю, что это в принципе неверно. Потому что при этом сохраняется процесс, а ценности и принципы - наоборот, страдают. Вместо заказчика - его суррогат. С ним можно налаживать сотрудничество и получать обратную связь, проводя демонстрации, но она не обеспечит тех функций, которые возложены в замысле
## Правильный подход - наоборот, адаптировать процесс, добиваясь соблюдения ценностей и принципов Agile в тех условиях, в которых разворачивается проект
## Опыт нашей компании говорит о том, что такой подход - работает. При этом Заказчики - достаточно тяжелые и формальные: Банк России (ЦБ), Газпромбанк и другие. Более того, получается именно то, что нужно Заказчику. Я в этих проектах работал аналитиком и архитектором, активно участвуя в ведении проекта.
# Как это работает - общая схема
## Ценности из Agile манифеста. Работающий софт, а не документация; Сотрудничество, а не соблюдение контракта - реально нужно заказчику, разделяются им.
## Принципы поддерживают ценности. Практики - воплощают ценности в жизнь.
## У Заказчика обычно есть налаженный процесс, в рамках которого идут ИТ-проекты. И его надо воспринимать как ограничение, встраиваться.
# Практики организации проекта
## Сценирование проекта на начальной разработке - как серия демонстраций. Minimum Viable Product. Условия заинтересованности для обратной связи.
## Первые демо - у нас, потом выходим на площадку Заказчика, тестовые стенды, обучение пользователей. Да, получается, что участвуют не все члены команды - и надо дополнительно обеспечивать обратную связь.
## Планирование релизов на этапе эксплуатации и доработок - из потребностей Заказчика, бывают релизы к сроку, релизы по функционалу и срочные обновления. И все это надо поддерживать процессно.
## Артефакты, документирующие продукт - это способ согласования. Надо разбираться, как работает заказчик
##* Бывает, что есть формальная документация write-only плюс легкое и неформальное согласование фактического функционала
##* Бывает, что относительно тяжелые документы реально используются, это налаженный способ работы бюрократической структуры
##* Артефакты не отменяют сотрудничества. Наоборот, они являются средством его налаживать. По факту,часть отделов коммуницируют через нас, так им легче.
## О позициях у заказчика и их компетенциях
## Адаптация команды под проект
## Контрактование как обеспечивающий процесс. Есть разные варианты.
##* FixPrice - переменный Scope
##* T&M с обоснованием костинга
##* Контрактование по фичам
# Заключение
[[Категория:Доклады]][[Категория:Люди]]
Я публикую эту статью, заранее представляя материал доклада. Я надеюсь на предварительное обсуждение с заинтересованными участниками, которое позволит сделать доклад лучше и интереснее, затронув аспекты, о которых я, быть может, не подозреваю.
= Аннотация доклада =
Многие доклады про использование гибких методологий разработки в проектах с государственным заказчиком рассказывают о том, как изолировать команду от заказчика для обеспечения Agile-процесса. Но нужно ли это на самом деле?
Ведь для заказчика, как правило, важно работающее программное обеспечение, а не документация на него, важно сотрудничество, а не контракты, важна готовность команды к изменениям — иными словами, те ценности, что декларирует Agile-манифест. Формальные требования воспринимаются заказчиком как дополнительная нагрузка на внутренние процессы, которые долго и сложно перестраивать. Поэтому секрет долгосрочного успешного сотрудничества — в грамотной адаптации деятельности компании-разработчика к условиям заказчика. За время доклада мы рассмотрим воплощение этого тезиса на конкретных примерах из опыта работы нашей компании с такими заказчиками, как Банк России, Газпромбанк и другими.
= Развернутые тезисы доклада =
Здесь нет разбиения на слайды, а просто развертывается логика рассказа.
# Зачем я делаю этот доклад? - представление доклада и докладчика.
## Когда поднимают тему работы с гос.заказчиком или в формальных проектах, то часто применяют методики, направленные на изоляцию команды от особенностей заказчика, что бы у них был “как бы правильный скрам”.
## Я думаю, что это в принципе неверно. Потому что при этом сохраняется процесс, а ценности и принципы - наоборот, страдают. Вместо заказчика - его суррогат. С ним можно налаживать сотрудничество и получать обратную связь, проводя демонстрации, но она не обеспечит тех функций, которые возложены в замысле
## Правильный подход - наоборот, адаптировать процесс, добиваясь соблюдения ценностей и принципов Agile в тех условиях, в которых разворачивается проект
## Опыт нашей компании говорит о том, что такой подход - работает. При этом Заказчики - достаточно тяжелые и формальные: Банк России (ЦБ), Газпромбанк и другие. Более того, получается именно то, что нужно Заказчику. Я в этих проектах работал аналитиком и архитектором, активно участвуя в ведении проекта.
# Как это работает - общая схема
## Ценности из Agile манифеста. Работающий софт, а не документация; Сотрудничество, а не соблюдение контракта - реально нужно заказчику, разделяются им.
## Принципы поддерживают ценности. Практики - воплощают ценности в жизнь.
## У Заказчика обычно есть налаженный процесс, в рамках которого идут ИТ-проекты. И его надо воспринимать как ограничение, встраиваться.
# Практики организации проекта
## Сценирование проекта на начальной разработке - как серия демонстраций. Minimum Viable Product. Условия заинтересованности для обратной связи.
## Первые демо - у нас, потом выходим на площадку Заказчика, тестовые стенды, обучение пользователей. Да, получается, что участвуют не все члены команды - и надо дополнительно обеспечивать обратную связь.
## Планирование релизов на этапе эксплуатации и доработок - из потребностей Заказчика, бывают релизы к сроку, релизы по функционалу и срочные обновления. И все это надо поддерживать процессно.
## Артефакты, документирующие продукт - это способ согласования. Надо разбираться, как работает заказчик
##* Бывает, что есть формальная документация write-only плюс легкое и неформальное согласование фактического функционала
##* Бывает, что относительно тяжелые документы реально используются, это налаженный способ работы бюрократической структуры
##* Артефакты не отменяют сотрудничества. Наоборот, они являются средством его налаживать. По факту,часть отделов коммуницируют через нас, так им легче.
## О позициях у заказчика и их компетенциях
## Адаптация команды под проект
## Контрактование как обеспечивающий процесс. Есть разные варианты.
##* FixPrice - переменный Scope
##* T&M с обоснованием костинга
##* Контрактование по фичам
# Заключение
[[Категория:Доклады]][[Категория:Люди]]