Agile, Scrum и другие животные
May. 10th, 2016 04:14 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
stanikaПопробую вкратце рассказать о том, чем я занимаюсь на работе.
В самом-самом начале XXI века - в феврале 2001 года - где-то на просторах Северной Америки встретились (не случайно) 17 человек, которые на тот момент занимались разработкой программного обеспечения. Встретились, поговорили и подписали некую важную бумагу, вошедшую в историю под названием Agile Manifesto.
Хотя они так и не сошлись во мнении по многим вопросам, они согласились на том, что
Люди и взаимодействия важнее процессов и инструментов
Работающий продукт важнее исчерпывающей документации
Сотрудничество с заказчиком важнее согласования условий контракта
Готовность к изменениям важнее следования плану.
А еще немного ранее, в самом-самом конце XX века - в 1999 году - уэльсский ученый Дейв Сноуден предложил некую модель, описывающую развитие сложных структур и назвал ее Киневин (Cynefin). Модель рассказывает нам о том, что существуют 4 домена - простой, сложный, запутанный и хаотичный. В простом связь между А и Б - очевидна. Когда собираешь мебель по инструкции ИКЕЯ - это очевидно (по крайней мере должно быть=). Тут любой справится. А вот в сложном домене уже можно строить дома, машины, мосты или управлять этим строительством. Здесь связь между А и Б несомненно существует, но понять ее могут только "избранные", специальные люди, которые изучали этот вопрос - эксперты. Поэтому, когда команда строит мост, у нее есть менеджер проекта, который может заранее построить план и этому плану следовать.
Но часто мы все-таки занимаемся чем-то, что требует от нас постоянной готовности к изменениям. Заказчики пришли и хотят на экране не голубую кнопочку, а розовую. Ребенок, вместо того, чтобы есть ложкой, сует ложку себе в глаз. Связь между А и Б есть, но увидеть ее заранее мы не можем. Нам остается только пробовать, а потом уже на основании экспериментов выстраивать некую стратегию и быть готовыми тут же ее поменять, как только станут известны результаты следующего опыта. Это запутанный домен. Именно в этом домене находятся разработчики программного обеспечения.
А если в офисе что-то взорвалось после неудачного опыта - это вы попали в хаотический домен. Тут только действовать, не пробовать и ждать результатов, а действовать прямо сейчас, в надежде, что это приведет вас обратно в запутанный домен и что-то станет понятно. В хаотическом домене связи между А и Б может вообще не быть. А если она есть - ее никто никогда не узнает.
И вот тут оказалось, что аджайл манифест и аджайл практики прекрасно применимы в запутанном домене в сравнении с "водопадом" - менеджментом проектов, который использовали раньше. Что это такое? Это мы сначала получаем некий запрос от покупателя. Он максимально подробно описывает свои желания. Потом мы все это читаем-читаем и составляем на этом основании план работ. Потом пишем код (наприме). Или делаем дизайн квартиры (очень показательный пример). Сначала все красим. Потом кладем все полы. И так далее. Потом тестируем. Потом наконец показываем заказчику ... а он говорит "Да я вообще не то хотел!" Знакомо?
Как бы это выглядело в аджайл. Заказачик в личной беседе излагает свое мнение на то, что ему наверно хотелось бы. Исполнитель готовит дизайн-макет одной комнаты. Приносит заказчику, тот выдает обратную связь, в дизайн-макет вносятся изменения, и можно делать следующую комнату. Когда дизайн всех комнат согласован, делают полностью одну комнату - показывают заказчику. Ну и опять - обратная связь, исправление ошибок или учет их для продолжения проекта.
Ну, на моей работе мы все-таки разрабатываем программное обеспечение и используем такой аджайл подход, который называется Скрам. Суть его естественно базируется на аджайл ценностях - частые итерации (мы работаем в рамках двух недель), постоянная обратная связь от пользователей, максимально самостоятельная команда и минимум ограничений для самовыражения. В Скраме всего три роли - команда, владелец продукта и скрам мастер (это я, наконец!) Команда программирует, это понятно. Владелец продукта - владеет продуктом, извините =) В общем ВП отвечает за бизнес-ценность. Он общается с покупателями и пользователями, он создает и приоритезирует список дел, он всегда на связи с командой, чтобы объяснять, что и зачем они программируют.
А скрам мастер - он следит за тем, чтобы в команде был настоящий скрам - чтобы выполнялись все роли и все процедуры (из всего пять), он проводит встречи, помогает команде создать дух и настрой (и поддерживать его), реализует взаимодействие команды с другими командами.
Моя команда еще ничего не знала про аджайл и скрам (примерно так же как и вы в начале этого поста), но теперь я уже провела два мастер-класса и завтра наконец мы начнем наш первый полноценный спринт (итерацию - 2 недели). Сессия планирования пугает меня гораздо больше, чем мастер-классы, тем более, что мой Владелец продукта тоже ничего не знает про аджайл, его тоже придется учить и воспитывать.
Но сегодня на МК я услышала самое главное от одного из членов моей команды: Я никогда не думал о ценностях, которые лежат в основе всех этих скрам действий, и сейчас я вижу в этом гораздо больше сути, а не просто навязанные процедуры. Для меня это - признание. И я постараюсь сделать так, чтобы у нас все получилось. Буду держать вас в курсе, если вам интересно =) Спасибо тем, кто дочитал!
Типа продолжение здесь http://stanika.livejournal.com/475425.html
В самом-самом начале XXI века - в феврале 2001 года - где-то на просторах Северной Америки встретились (не случайно) 17 человек, которые на тот момент занимались разработкой программного обеспечения. Встретились, поговорили и подписали некую важную бумагу, вошедшую в историю под названием Agile Manifesto.
Хотя они так и не сошлись во мнении по многим вопросам, они согласились на том, что
Люди и взаимодействия важнее процессов и инструментов
Работающий продукт важнее исчерпывающей документации
Сотрудничество с заказчиком важнее согласования условий контракта
Готовность к изменениям важнее следования плану.
А еще немного ранее, в самом-самом конце XX века - в 1999 году - уэльсский ученый Дейв Сноуден предложил некую модель, описывающую развитие сложных структур и назвал ее Киневин (Cynefin). Модель рассказывает нам о том, что существуют 4 домена - простой, сложный, запутанный и хаотичный. В простом связь между А и Б - очевидна. Когда собираешь мебель по инструкции ИКЕЯ - это очевидно (по крайней мере должно быть=). Тут любой справится. А вот в сложном домене уже можно строить дома, машины, мосты или управлять этим строительством. Здесь связь между А и Б несомненно существует, но понять ее могут только "избранные", специальные люди, которые изучали этот вопрос - эксперты. Поэтому, когда команда строит мост, у нее есть менеджер проекта, который может заранее построить план и этому плану следовать.
Но часто мы все-таки занимаемся чем-то, что требует от нас постоянной готовности к изменениям. Заказчики пришли и хотят на экране не голубую кнопочку, а розовую. Ребенок, вместо того, чтобы есть ложкой, сует ложку себе в глаз. Связь между А и Б есть, но увидеть ее заранее мы не можем. Нам остается только пробовать, а потом уже на основании экспериментов выстраивать некую стратегию и быть готовыми тут же ее поменять, как только станут известны результаты следующего опыта. Это запутанный домен. Именно в этом домене находятся разработчики программного обеспечения.
А если в офисе что-то взорвалось после неудачного опыта - это вы попали в хаотический домен. Тут только действовать, не пробовать и ждать результатов, а действовать прямо сейчас, в надежде, что это приведет вас обратно в запутанный домен и что-то станет понятно. В хаотическом домене связи между А и Б может вообще не быть. А если она есть - ее никто никогда не узнает.
И вот тут оказалось, что аджайл манифест и аджайл практики прекрасно применимы в запутанном домене в сравнении с "водопадом" - менеджментом проектов, который использовали раньше. Что это такое? Это мы сначала получаем некий запрос от покупателя. Он максимально подробно описывает свои желания. Потом мы все это читаем-читаем и составляем на этом основании план работ. Потом пишем код (наприме). Или делаем дизайн квартиры (очень показательный пример). Сначала все красим. Потом кладем все полы. И так далее. Потом тестируем. Потом наконец показываем заказчику ... а он говорит "Да я вообще не то хотел!" Знакомо?
Как бы это выглядело в аджайл. Заказачик в личной беседе излагает свое мнение на то, что ему наверно хотелось бы. Исполнитель готовит дизайн-макет одной комнаты. Приносит заказчику, тот выдает обратную связь, в дизайн-макет вносятся изменения, и можно делать следующую комнату. Когда дизайн всех комнат согласован, делают полностью одну комнату - показывают заказчику. Ну и опять - обратная связь, исправление ошибок или учет их для продолжения проекта.
Ну, на моей работе мы все-таки разрабатываем программное обеспечение и используем такой аджайл подход, который называется Скрам. Суть его естественно базируется на аджайл ценностях - частые итерации (мы работаем в рамках двух недель), постоянная обратная связь от пользователей, максимально самостоятельная команда и минимум ограничений для самовыражения. В Скраме всего три роли - команда, владелец продукта и скрам мастер (это я, наконец!) Команда программирует, это понятно. Владелец продукта - владеет продуктом, извините =) В общем ВП отвечает за бизнес-ценность. Он общается с покупателями и пользователями, он создает и приоритезирует список дел, он всегда на связи с командой, чтобы объяснять, что и зачем они программируют.
А скрам мастер - он следит за тем, чтобы в команде был настоящий скрам - чтобы выполнялись все роли и все процедуры (из всего пять), он проводит встречи, помогает команде создать дух и настрой (и поддерживать его), реализует взаимодействие команды с другими командами.
Моя команда еще ничего не знала про аджайл и скрам (примерно так же как и вы в начале этого поста), но теперь я уже провела два мастер-класса и завтра наконец мы начнем наш первый полноценный спринт (итерацию - 2 недели). Сессия планирования пугает меня гораздо больше, чем мастер-классы, тем более, что мой Владелец продукта тоже ничего не знает про аджайл, его тоже придется учить и воспитывать.
Но сегодня на МК я услышала самое главное от одного из членов моей команды: Я никогда не думал о ценностях, которые лежат в основе всех этих скрам действий, и сейчас я вижу в этом гораздо больше сути, а не просто навязанные процедуры. Для меня это - признание. И я постараюсь сделать так, чтобы у нас все получилось. Буду держать вас в курсе, если вам интересно =) Спасибо тем, кто дочитал!
Типа продолжение здесь http://stanika.livejournal.com/475425.html
no subject
Date: 2016-05-10 03:13 pm (UTC)Читабельный и очень интересный!
no subject
Date: 2016-05-10 06:27 pm (UTC)спасибо! То, что мне хотелось бы услышать =)
no subject
Date: 2016-05-10 05:04 pm (UTC)no subject
Date: 2016-05-10 06:28 pm (UTC)no subject
Date: 2016-05-10 08:37 pm (UTC)no subject
Date: 2016-05-11 07:08 am (UTC)no subject
Date: 2016-05-11 04:30 am (UTC)Хотя если прикинуть, то наша контора, которая в том числе создает софт, в чем-то идет по такому пути, потому что главные потребители софта, т е я и мои девы, находимся в постоянном контакте
no subject
Date: 2016-05-11 07:09 am (UTC)no subject
Date: 2016-05-11 08:18 am (UTC)no subject
Date: 2016-05-11 12:02 pm (UTC)no subject
Date: 2016-05-11 12:04 pm (UTC)no subject
Date: 2016-05-11 12:08 pm (UTC)no subject
Date: 2016-05-11 12:14 pm (UTC)Кто знает конечно, куда может занести
no subject
Date: 2016-05-11 04:41 am (UTC)no subject
Date: 2016-05-11 07:09 am (UTC)no subject
Date: 2016-05-13 09:38 am (UTC)no subject
Date: 2016-05-13 10:04 am (UTC)no subject
Date: 2016-05-15 12:23 pm (UTC)no subject
Date: 2016-06-04 11:42 am (UTC)no subject
Date: 2016-06-04 04:17 pm (UTC)no subject
Date: 2016-06-04 05:29 pm (UTC)no subject
Date: 2016-06-07 09:34 am (UTC)Я тоже про многие профессии не понимаю, и считаю, что мы все должны научиться объяснять. Вокруг меня несколько детей, которым скоро выбирать профиль - и им очень сложно, потому что они не понимают.
Написала новый пост про ежедневную работу, вдруг поможет