Подкаст на тему "Роли в Agile команде"
Участники:
Алексей Кривицкий, Асхат Уразбаев, Денис Миллер, Кирилл Медведев
Обсуждалось:
"Fixed-price" проекты являются обычной практикой в IT или как результат фиксированной стоимости конкурсной предлагаемой цены, или как результат бюджетных давлений внутренних проектов разработки ПО. Давайте проэкзаменируем проблемы, присущие каждой из этих практик. Во-первых, сложная задача с BRUF в том, что вы не можете точно определить наперед, чего хотят люди, потому что по существу они сами этого не знают. Людям хорошо удается указать свое намерение и потом, когда им показывают что-то вроде прототипа UI или реального работающего кода, они могут указать, что им не нравится, и что могло бы им подойти вместо этого. Повторяя этот процесс, мы можем придти к тому, что им действительно нужно, но это означает, что мы будем развиваться, удаляясь от начального требования, на котором базировалась смета. Такие «смены требований» (на самом деле меняется наше понимание требований), в свою очередь, приводят проектную команду к риску выйти за рамки бюджета. В результате, вы можете иметь точную смету чего-то, чего люди не хотят, или неточную смету чего-то, что они действительно хотят. Во-вторых, много процессов «управления изменениями» сделаны для того, чтобы организаторам дела было тяжело передумать, что уменьшило бы вероятность изменения требований, которые могли бы вынудить вас выйти за рамки бюджета. Изменениями не управляют, их предотвращают. Эти процессы предотвращения изменений увеличивают вероятность того, что система будет построена в соответствии со спецификацией, но уменьшают вероятность того, что система действительно будет отображать настоящие потребности организаторов дела. В результате, большое количество денег оказывается потраченным на то, чтобы построить функциональность, которую организаторы на самом деле не хотят, и не на то, на что они действительно хотят. В-третьих, BDUF также оказывается сомнительным на практике. При детальной разработке дизайна на ранней стадии проекта вам приходиться принимать серьезные решения, тогда как владеете наименьшим количеством информации. К примеру, в течение первого месяца проекта вы знаете намного меньше, чем на 10-й месяц проекта. И как только эти решения приняты, вы вынуждены придерживаться их из-за всей той тяжелой работы, которая уже проделана. Еще хуже то, что если вы неправильно поняли требования, с которых надо начать (а это часто случается), то не имеет значения, насколько хорошо разрабатывается дизайн, так как он по-прежнему неправильный, потому что основан на неправильных требованиях. В-четвертых, BRUF и BDUF – это два аспекта последовательного жизненного цикла; последовательные жизненные циклы, на поверку, предлагают мало контрольных точек организаторам и таким образом увеличивают общий риск проекта. Не смотря на то, что организаторы обычно активно участвуют в начале при BRUF, их роль часто очень уменьшается к моменту тестирования для одобрения пользователем в конце проекта (допуская, что время позволяет). Время от времени, может производиться обзор, где они просматривают отчеты о состоянии проекта и техническую документацию, которые предоставляются, являя собой выполненную стоимость, но по большому счету основная часть процесса разработки ПО для организаторов похожа на черный ящик. Они не знают почти до самого конца проекта, получат ли они что-либо ценное в обмен на свое инвестирование в IT. К сожалению, многие из так называемых точных смет на практике в любом случае оказываются не такими уж точными. Вне зависимости от того, насколько подробны требования и спецификации дизайна, всегда существуют некоторая неопределенность. Команды разработчиков, чтобы уменьшить риск, раздувают свою смету до той точки, когда она все еще приемлема для организаторов и вместе с тем предоставляет некоторый резервный запас для любого неправильного подсчета. В сущности, так или иначе, команда разработчиков подвергает организатора такому же объему финансового риска проекта, эффективно ликвидируя исходную цель наличия fixed-price проекта. В действительности, проекты часто выходят за рамки бюджета. И это случается гораздо чаще, чем то, что не организаторы дела платят часть или всю сумму излишка, чтобы получить желаемую систему у провайдера IT. К сожалению, подобные ошибки заставляют людей еще жестче настаивать на точной предварительной смете в следующий раз. И таким образом мы, кажется, никогда не сможем уйти с бегущей дорожки fixed-price. Альтернативой fixed-price проектам, конечно же, являются variable-priced проекты. На практике гораздо легче уменьшить финансовый риск на variable-priced проектах со стробированным инвестированием, основанном на промежуточных поставках (идеально работающее ПО). Этот подход предусматривает хорошее взаимоотношение между организаторами дела и IT так же, как и активное участие организатора в проекте. Если вы хотите гарантировать ценность вашей инвестиции в IT, то вам следует управлять вашей инвестицией в IT вплотную. Fixed-price проекты IT не подходят разработчикам, работающим на проекте, потому как это побуждает к неясному поведению, которое ставит вашу работу под риск при длительном сроке. Так же fixed-price проекты не подходят организаторам дела, так как они, кажется, увеличивают риск вместо уменьшения его, как это было обещано. Пришло время переосмыслить наш подход к финансированию проектов в сфере IT. Из Dr Dobb's, автор Скотт Амблер.
Я помещаю термин «fixed-price» в кавычки, потому что проекты часто выходят за рамки бюджета, но ради обсуждения давайте проигнорируем эту противную маленькую часть реальности. Организации часто предпочитают fixed-price проекты в попытке уменьшить свой финансовый риск. К сожалению, кажется, что на практике происходит совершенно противоположное.
По-видимому, все об этом знают, но почему-то мы не можем выбраться из этой канавы. В этом месяце я обсуждаю вопросы, окружающие fixed-price проекты IT, в надежде мотивировать вас удалиться от этой сомнительной практики.
Из Dr Dobb's, автор Скотт Амблер.
Фундаментальной проблемой fixed-price проектов является то, что они побуждают вас выполнять очень сомнительные вещи, которые неизменно приводят к убыткам. Чтобы разработать точную смету, вам надо понимать требования, которые вам следует учитывать, и архитектуру, которую вы собираетесь строить. Чем больше потребность в точности в вашей смете, тем больше потребность в максимально подробной информации. Как результат давления разработать точную изначальную смету, типично вы вынуждены принимать следующее:
Перевел Павел Юров для scrum.com.ua под редакцией Алексея Кривицкого.
Хороший способ проверить, использует ли ваша команда доску для того, чтобы по настоящему управлять своей работой - это посмотреть на их ежедневный митинг (daily standup).
Команда, которая использует визуальный менеджемент для управления своей работой, всегда проводит ежедневное собрание стоя напротив доски
Оно выглядит так:
или так?
Во время ежедневного собрания вы сообщаете свежую информацию о своей работе членам вашей команды. Как та работа, которая была закончена накануне, так и та, которая все еще находится в процессе, обе должны быть ясно и четко отражены на доске. Имеет смысл обращаться к доске только тогда, когда вы говорите. Это будет легче для вас так же, как и для членов команды. Это также помогает визуально поместить в контекст то, о чем вы говорите.
Существует очень простое указание для того, чтобы убедиться, что вы не забудете поговорить о чем-то важном каждый день: проводите ежедневное собрание стоя напротив доски и проверяйте, чтобы все задания в средней колонке ("выполняется", "in progress") были обсуждены.
Из Visual management, автор Перевел Павел Юров для scrum.com.ua под редакцией Алексея Кривицкого.
Визуальный менеджмент заключается не только в том, чтобы иметь визуальные элементы. То, как вы их используете, важно в равной степени. Плохой процесс может сделать хорошую идею бесполезной. А некоторые тривиальные идеи, с хорошим процессом за ними, могут дать интересные результаты. Можете ли вы быстро обнаружить ярлыки DONE?
Ярлык состояния DONE - это идея, относящаяся к процессу. Это креативный способ визуализировать поток, дать командам время отпраздновать свои достижения, и обеспечить выравнивание и общение команды; и это все ежедневно.
Концепция проста. В течение дня члены команды работают над задачами, которые находятся в колонке "in progress" (выполняется) на доске задач. Когда они заканчивают задачу, вместо того, чтобы немедленно перенести ее в колонку "Finished" (Закончено), они клеят на нее ярлык DONE. И там он остается до конца дня, провозглашая на весь мир, что команда завершила некоторую работу. Это часть о потоке: бросив быстрый взгляд в конце дня на доску вы можете "видеть поток", поискав глазами ярлыки DONE. Чем больше голубого, тем больше поток. Это нравится менеджерам и Product Owners.
Празднование наступает во время ежедневного собрания стоя. На собрании команда перемещает все свои ярлыки DONE в колонку Закончено, устраивая маленький ежедневный момент гордости. Естественно, говорить и переносить ярлык должен человек, который закончил задачу.
Что насчет выравнивания и общения? Перенося все ярлыки DONE на ежедневном собрании вы, по существу, обеспечиваете то, что все в команде осведомлены о том, кто и что заканчивает. Фактически, так появилась эта идея. Члены команды переносили задачи в колонку Закончено в течение дня, и потом на ежедневном собрании они могли забыть рассказать об этом. Имея много задач в колонке "Закончено" становилось тяжело запомнить, которые из них были новыми, а не вчерашними. И поверьте мне, если у вас много однодневных задач, то это случится, особенно с наиболее производительными девелоперами, которые делают много вещей.
Идея заключалась в том, чтобы придумать понятный каждому процесс, который бы гарантировал, что люди буду говорить обо всем, что они закончили накануне без особого усилися с их стороны. Это сработало, и многим понравилось.
Итак, основное указание для использования ярлыка DONE следующее:
Другая любопытная вещь, которую я обнаружил, состоит в том, что иногда члены команды забывают говорить о чем-то, что они закончили накануне, даже если оно находится в колонке "Выполняется" и на нем есть ярлык DONE. Но в таком случае это легко обнаруживается: если после ежедневного собрания все еще остаются ярлыки DONE, то они либо забыли сказать об этом, либо задача была сделана членом команды, который отсутствует в этот день (в подобном случае, если этот человек не уехал в отпуск, то команды ждут его возвращения, чтобы не присваивать его достижения).
По правде говоря - без какой-либо особенной причины. Я случайно выбрал приятный цвет. Но потом я узнал, что в японской культуре голубой цвет обозначет "хороший", - это придало ей какое-то значение.
(Для интереса: я узнал это в очень длинной беседе с Кошуке Кавагучи, автором Hudson CI engine. Хадсон показывает голубой экран вместо зеленого экрана, когда конструкция в порядке.)
Голубой цвет также очень хорошо контрастирует с желтым, что позволяет легко визуализировать законченные задачи издалека, как это видно на картинке вверху. Но для голубого цвета нет никакой специальной причины и я видел, что некотрые команды предпочитают использовать зеленый цвет для ярлыка DONE.
Экспериментируйте!
Из Visual management, автор Перевел Павел Юров для scrum.com.ua под редакцией Алексея Кривицкого.
Автор: Игорь Тамащук
Много бумаги исписано и и мегабайтов перекачано в процессе, когда одни пытаются понять, что же такое Scrum, а другие пытаются это объяснить. Главное достоинство Scrum в этом смысле заключается в том, что для того, чтобы начать его применять не нужно многого – бери готовые несложные правила, минимум артефактов, и колесики закрутились. Но понимание глубокой сути этого процесса наступает далеко не сразу.
Как известно, центром любого scrum-проекта является product backlog. Это место, куда product owner записывает свои пожелания, оценивая их значимость и вместе с командой планирует итерации. Казалось бы, что может быть проще? Но чем же этот подход оказался лучше других? Чем он отличается, скажем, от случая, когда заказчик просто заводит тикеты, например, в JIRA? Что делает этот проект столь эффективным?
Читать дальше...
