Comments 13
Это все хорошо, но у большинства клиентов есть бюджет и сроки и они хотят работать именно в пределах некой Fixed Price.
Поэтому клиенты продолжают начинать с вопроса: когда конкретно будет готов продукт и сколько он будет стоить?
Лучше бы написали статью, о том как объяснить таким клиентам, что Agile со всеми его неопределенностями это круче чем «водопад» к конкретному сроку по Fixed Price.
Поэтому клиенты продолжают начинать с вопроса: когда конкретно будет готов продукт и сколько он будет стоить?
Лучше бы написали статью, о том как объяснить таким клиентам, что Agile со всеми его неопределенностями это круче чем «водопад» к конкретному сроку по Fixed Price.
Мы живём в эру интернета, вы могли бы самостоятельно нагуглить интересующий вас материал…
По указанной вами ссылке находится текст про некие доверительные отношения между заказчиком и исполнителем-одиночкой. Причем судя по всему этот исполнитель-одиночка делает весьма простые вещи, не имеющие отношения к серьезным «командным» проектам.
В том тексте вообще не упоминается Agile.
В том тексте вообще не упоминается Agile.
Вот цитата из той статьи:
Но суть не в этом. Люди потратили время, написали статью, а вы жалуетесь, мол это мне неинтересно, лучше бы написали на тему, как убедить заказчика, что гибкая методология лучше Fixed Price. Ну неинтересно — закройте статью и занимайтесь своими делами дальше. Никому неинтересно, что вам неинтересно. Ладно, вам дали ссылку на тот материал, о котором вы просили. Вместо благодарности опять жалобы: дескать, мне это неинтересно, я хотел (но никому об этом не сказал) почитать про взаимодействие заказчика и большой команды разработчиков. И такое сплошь и рядом на хабре. В ваших же интересах признать, что мир не вращается вокруг вас и что лучше самому заниматься исполнением своих желаний, а не канючить у окружающих, тем более что в данном случае нужно всего-то набрать пару слов в поисковике. Хотя, конечно, это ваша жизнь, живите как хотите. Это был просто добрый совет от случайного прохожего.
Если вы назвали фиксированную цену и даже написали детальное техзадание, вам придется на каждом шагу бороться с ним, доказывая, что вот этого в задании не было! С почасовой оплатой вы можете сказать «ок, давайте я оценю, во сколько это вам обойдется» — а там пусть клиент сам решает, стоит ли оно того.По какой методологии, по вашему мнению, работает автор? Вы можете назвать хотя бы одно место в статье, которое применимо к отношениям между заказчиком и исполнителем-одиночкой и неприменимы к отношениям с небольшой командой разработчиков?
Но суть не в этом. Люди потратили время, написали статью, а вы жалуетесь, мол это мне неинтересно, лучше бы написали на тему, как убедить заказчика, что гибкая методология лучше Fixed Price. Ну неинтересно — закройте статью и занимайтесь своими делами дальше. Никому неинтересно, что вам неинтересно. Ладно, вам дали ссылку на тот материал, о котором вы просили. Вместо благодарности опять жалобы: дескать, мне это неинтересно, я хотел (но никому об этом не сказал) почитать про взаимодействие заказчика и большой команды разработчиков. И такое сплошь и рядом на хабре. В ваших же интересах признать, что мир не вращается вокруг вас и что лучше самому заниматься исполнением своих желаний, а не канючить у окружающих, тем более что в данном случае нужно всего-то набрать пару слов в поисковике. Хотя, конечно, это ваша жизнь, живите как хотите. Это был просто добрый совет от случайного прохожего.
А где список задач, в которых гибкие методологии неприменимы? Надеюсь, они не считаются серебряной пулей?
Если кратко, то гибкие методологии придуманы для продуктов (мы не знаем на самом деле куда идем, нужно постоянно получать отклик рынка и менять направление движения), посредственно подходят для проектов (заказ сделать что-то в срок и объем) и не годятся для процессов (ака поддержка принтеров в рабочем состоянии).
Почему это не годится для процессов? В частности Kanban как раз довольно часто для саппорта применяется.
Гибкие методологии работают в условиях отсутствия лучших практик. В поддержке же они есть, их нужно накапливать и повторно использовать. Можно применять инструмент не по назначению, но это не даст лучший результат.
Для процессов есть ITIL и стандарты ISO. В ITIL подробно расписано как строить процессы.
Для процессов есть ITIL и стандарты ISO. В ITIL подробно расписано как строить процессы.
Почему бы и нет? То что в Rocket Science ещё не применялся Agile, это не значит что там он работать не будет.
На первом месте стендапы. В России, даже если компания полностью зафейлила внедрение, использование и адаптацию Agile, обычно все равно остаются стендапы. Если у вас не получается их использовать, значит, у вас совсем не организованная команда. Практика простая: каждый день в определенное время команда собирается и синхронизирует свою деятельность.
Прочитав вот это родил несколько вопросов по Agile.
Допустим, есть 6 команд по 5 человек, которые работают над разными частями продукта.
Это порождает вопросы:
1) Когда и кем должны быть согласованы интерфейсы их модулей? Поясню: зело сомнительно, что собрав в одной комнате тридцать человек можно заставить их о чём-то договориться.
2) Когда проводится интеграционное тестирование?
3) Кто фиксит глобальные косяки продукта, выявленные на этапе интеграционного тестирования или внедрения?
По последнему вопросу: каждая группа будет валить друг на друга, не желая рефакторить или переделывать свою часть кода. Как из этой ситуации выйти?
Последний вопрос: когда и кем определяются задачи для групп и зоны их ответственности?
Повторюсь: 30 и более разработчиков в одной комнате — балаган и ничего более.
Если масштабировать этот процесс на 200 — 250 человек, то как вообще быть..?
Если кратко, то не особо это масштабируется. В классическом Скраме есть ограничение на размер команды, но не описано что делать с кучей команд.
Часто делают и описывают примерно так: проект разбивается на микропроекты (сейчас модно называть микросервисами). Внутри них agile, независимые поставки. Взаимодействие между командами определяется иерархией владельцев продуктов/сервисов (с позиции бизнеса) и иерархией архитекторов (с технической позиции). Сюда же можно добавить еще дизайнеров (если в этих сервисах отдельные UI) и других аналитиков. С точки зрения Scrum архитектор (и др.) внутри команды PO. Как уже архитекторы и PO синхронизируют несколько сотен микросервисов — отдельная история вне Scrum.
> 1) Когда и кем должны быть согласованы интерфейсы их модулей? Поясню: зело сомнительно, что собрав в одной комнате тридцать человек можно заставить их о чём-то договориться.
Интерфейс приходит как часть ТЗ. Делается командой PO (архитекторами в ней).
> 2) Когда проводится интеграционное тестирование?
Идеально всегда, по мере готовности сервисов каждый сервис тестирует интеграцию с другими, которые он использует. Это в теорию микросервисов.
> 3) Кто фиксит глобальные косяки продукта, выявленные на этапе интеграционного тестирования или внедрения? По последнему вопросу: каждая группа будет валить друг на друга, не желая рефакторить или переделывать свою часть кода. Как из этой ситуации выйти?
Самый Главный Архитектор решает где и как исправлять. Исправляет соотв. команда.
Дополнительно можно почитать http://agileatlas.org/articles/item/large-scale-scrum-more-with-less и https://www.scrumalliance.org/community/articles/2013/june/scrum-of-scrums-running-agile-on-large-projects.
Часто делают и описывают примерно так: проект разбивается на микропроекты (сейчас модно называть микросервисами). Внутри них agile, независимые поставки. Взаимодействие между командами определяется иерархией владельцев продуктов/сервисов (с позиции бизнеса) и иерархией архитекторов (с технической позиции). Сюда же можно добавить еще дизайнеров (если в этих сервисах отдельные UI) и других аналитиков. С точки зрения Scrum архитектор (и др.) внутри команды PO. Как уже архитекторы и PO синхронизируют несколько сотен микросервисов — отдельная история вне Scrum.
> 1) Когда и кем должны быть согласованы интерфейсы их модулей? Поясню: зело сомнительно, что собрав в одной комнате тридцать человек можно заставить их о чём-то договориться.
Интерфейс приходит как часть ТЗ. Делается командой PO (архитекторами в ней).
> 2) Когда проводится интеграционное тестирование?
Идеально всегда, по мере готовности сервисов каждый сервис тестирует интеграцию с другими, которые он использует. Это в теорию микросервисов.
> 3) Кто фиксит глобальные косяки продукта, выявленные на этапе интеграционного тестирования или внедрения? По последнему вопросу: каждая группа будет валить друг на друга, не желая рефакторить или переделывать свою часть кода. Как из этой ситуации выйти?
Самый Главный Архитектор решает где и как исправлять. Исправляет соотв. команда.
Дополнительно можно почитать http://agileatlas.org/articles/item/large-scale-scrum-more-with-less и https://www.scrumalliance.org/community/articles/2013/june/scrum-of-scrums-running-agile-on-large-projects.
Sign up to leave a comment.
Мастер-класс Бориса Вольфсона. Основы Agile