Задача состоит в том, чтобы один бэклог автоматически трансформировать в один Гантт.
Именно такая операция невозможна.
В этом примере меденжер должен перерисовать изначальный Гантт, перенеся или разорвав приостановленную задачу. Тоесть один беклог отображается на несколько Гантт диаграмм.
Здесь рассматривается логика приложения. Представте, что мы находимся на странице плана итерации в режиме беклог. Что мы должны увидеть, если на этой странице пользователь нажимает кнопку «Gantt»?
Не получится просто ему показать одну Гантт диаграмму. Ему таких диграмм нужно сгенерировать столько, сколько рабочих дней показано в одном бэклоге. Поскольку в Скраме каждый день мы все планируем заново.
Если я правильно вас понял, предлагается зафиксировать длительность задачи… Тогда в нашем случае мы получим на 6й день 6*8 / 16 = 300%… не работает…
Во время спринта делается каждодневная оценка оставшегося времени по задаче. И некоторые задачи могут улетать за их первую оценку, сделанную во время планирования спринта. Это жизнь.
Вот несколько примеров, чтобы выйти на общую точку понимания:
задача сделана раньше плана:
план — 24. Отчеты — 24 12 0
задача совпала с планом:
план — 24. Отчеты — 24 16 8 0
задача не вписалась в план:
план — 24. Отчеты — 24 28 20 12 4 0
обычно такое случается, если находятся непредвиденные проблеммы с логикой или архитектурой.
hours_left и required_left — мне кажется одно и то-же.
Давайте посчитаем. Пусть первая (плановая) оценка задачи — 16 часов.
Разработчик рапортовал такие оценки: 12 8 8 8 8 8 0. Тоесть, например он был переключен на другую задачу. Посмотрим какой процент получается на Гантте на 6й день: 6*8/(6*8 + 8) — это 86%.
Чтобы этот эффект не наблюдался, мы должны каждый день перерисовывать Гантт.
Можно обыграть как отдельную «причину» также обоснование включения рефакторинга в беклог итерации (Пример в подходе Скрам).
Если продукт долго растет, в нем накапливаются косяки, в том числе архитектурные. Наступает момент конфликта, когда программисты понимают, что следующий прирост функционала нельзя строить на плохом фундаменте, но Владелец продукта (Product Owner) требует все время итерации потратить на новые функциональные фичи.
Здесь очень кстати сделать обзор кода и соорудить хорошо оформленный документ, описать драматичные моменты… Помогает договориться.
Мне пришлось однажды участвовать в наборе программистов в новую команду. Поделюсь опытом, может вам будет интересно.
Тогда мы решили воспользоваться такой структурой
1. логика
Примеры точно не могу вспомнить, но задачи были похожи на загадки с черными и белыми шариками, обезьянками и клетками и т.д. Что-то похожее недавно промелькнуло на Хабре про вопросы к претендентам в компанию Гугл. Там еще был вопрос — почему люки на улице круглые. У нас было что-то похожее, но проще.
2. алгоритмика
Здесь идут задачки, похожие на вашу. Я вспомнил свой пример — нужно было за 15 минут написать карточную игру «Дурак» для игры между человеком и компьютером.
Успешное прохождение такого теста подразумевало умение концентрироваться на главном, умение строить очень простые модели и реально оценивать время, ну и конечно, алгоритмику. В итоге, например, один из программистов написал на Руби программку с консольным UI. Она умела тасовать колоду, раздавать карты и простое кейс-меню для хода.
3. профессионализм
Здесь проводилось классическое интервью типа вопросы-ответы по языку программирования, фреймворкам, паттернам, тонким делам типа рефлексии и тридов
К сожалению не все так просто… В большинстве случаев заказчик на старте проекта имеет только набор идей того, что он хочет получить в результате проекта. Нету магической книги, из которой вы могли бы взять задачи, «разбить их, и имплементировать в стройной архитектуре». Описанная вами картина больше напоминает работу программиста над своим личным небольшим проектом.
Ну вот, например, составили вы чудный план исследований, взяв за основу некоторую модель явления.
Во время проведения исследований вышла статья в физ-реве о том, что данная модель плохая и нужно использовать другую. Другая модель требует создание другой лабораторной установки. План нужно менять.
Я пытался построить простую работающую модель. На самом деле, для некоторых проектов, наверное, придется схему интеграции 2х протоколов усложнять. Возможно, нужно будет добавить повторяющиеся фазы типа детерминант — эмпирика — детерминант, которые будут поддерживать каркас для длительных проектов.
Согласен, эти проблемы существуют и, наверное, являются общими для всех компаний, которые вводят Agile процессы в легаси структуру. Тут вопрос в выходе на новые горизонты рынка — нужно сохранить клиентов, которые привыкли к детерминантному процессу, и привлечь новых, кто ищет интерактив и готов идти по эмпирическому процессу.
>>… может иногда казаться что некоторые вещи делаются для галочки — для бухгалтерии, для бумажки и так далее. Но эти вещи важны и не понимание причин их побуждающих может привести к срыву проекта, финансовым потерям и так далее. На самом деле в них своя достаточно жесткая логика — минимизация рисков, поддержка коммуникаций и в целом достижение целей проекта, которые состоят не только в продукте, а в основном в удовлетворении нужд заказчика, частью которого есть продукт.
Именно, я набил эту шишку, когда увлекся Скрам и убедил своего топ менеджера, что мы обойдемся вообще без артефактов детерминантного процесса и все проведем по модели *постоянное общение + частые оценки + 2-недельные итерации с презентациями*. Тот проект мы завалили…
Нельзя игнорировать *легаси* или исторически сложившийся массив связей между людьми, возглавляющими фирму и их клиентурой.
Поэтому я предлагаю «панцирь» процесса строить и поддерживать в детерминантном подходе, а внутренности — в эмпирическом.
>>Спускаясь с теоретизирования, люди — разные. Одному может быть до фени те пять копеек что будут доплачены за доп.фичу по сравнению с ее выгодой, а другому для этого нужно согласовать изменение бюджета по 20-ти инстанциям и пофиг что от нее будет лучше и денег больше. Это нельзя не учитывать.
Я не претендую на универсальное решение проблемы. У нас — а это небольшая команда из 35 разработчиков — стратегия сработала (по крайней мере один раз). Но вполне возможно, что она не годится для компаний-флагманов рынка с командами в 200 или 400 человек.
Не могу с вами согласиться. Как может быть детерминированным процесс, построенный на серии черных ящиков?
Возможно, вы имели ввиду микро-планы — такие как план расчетов методом Монте-Карло какой-нибудь мат. модели. Я имел ввиду макро-план — синтезировать новую керамику, устойчивую к перепадам температур и т.д. То есть планы, которые включают длительные промежутки времени и предполагают открытия новых эффектов.
>>В описанной ситуации с изменениями фич нет ничего с чем не справился CMM. Просто нужно соответствующее управление изменениями в скопе проекта. При этом правда нужно ПМ-у активно поработать.
На мой взгляд, попытки объединить оба протокола под одной крышей уже велись, да и будут продолжаться. Возьмем хоть RUP. Тяжелый итерационный процесс, который позволяет жанглировать фичами. Он идеален для CMMI. Но вот не прижился…
Может это прозвучит слишком пафосно, но я хотел сказать, что смешивать эти протоколы Не Надо. Как с вечным двигателем… Люди тратили свои жизни на постройку тысяч механизмов, которые должны были бы работать вечно. Но в физике есть жестокий закон сохранения энергии. Имеет смысл направить усилия в другом направлении…
>>Отодвигать решение проблемы с классической тройкой время-деньги-обьем на этап завершения нехорошо
Тут отодвигать такое решение не приходится, поскольку мы принципиально убираем из разработки понятие Большого Плана. Согласующая итерация проводится больше «для бухгалтерии». По замыслу, в этот момент уже довольный клиент бегает по презентациям и во всю использует продукт. На согласовующей итерации подчищаются баги и доделываются очень низкоприоритетные фичи, которые не вносят существенных искажений в понятие «объем».
>> заказчик может думать что начальные деньги и сроки классный ПМ сопряг с новыми фичами, а контора верить в то что дополнительный обьем и увеличенные сроки будут финансово поддержаны спонсором проекта
А вот это действительно самый опасный момент. Безусловно, все, и особенно клиент должны понимать условия игры. Мы клиенту предоставляем супер-сервис, но он морально и технически должен быть готов к нему. Если клиент делегирует все принятие решений на вас, не проявляет интерес к ранним версиям системы, то здесь лучше сразу идти по Водопаду.
>>В целом имхо это просто разделение уровней — есть управленческий, где ПМ и его руководство с заказчиком, и выполняющий, где ПМ же, исполнители и представитель заказчика же. Они вполне могут иметь разные процессы, наиболее удобные участникам. Главное что бы работало.
Я почти с вами согласен :)
Я бы только слово «могут» заменил на «должны». Это и есть главный *месседж*, который я хотел отправить.
Я так понимаю, что у вас претензии к фразе: «революционных архитектурных решений — таких, как MVC и паттерны Фоулера».
Я не собираюсь спорить на тему «cтарые или новые» MVC и слоистый паттерн. Статья в общем, о другом. Вы можете в этом месте вставить любую *новую архитектурную революцию* на ваш вкус и читать статью дальше.
Я не вижу тут противоречия на самом деле. Заказчик решил вкинуть мегафичу? На здоровье! Но при этом он, конечно, должен знать правила игры. Эта мегафича подвинет другие — с меньшим приоритетом. Заказчик может выбрать один из вариантов — либо бюджет увеличивается на вес оценки этой фичи — либо другим фичам не повезло в этот раз — они выходят за скоуп.
Действительно, Скрам процесс может получить CMMI 3. Но это потолок. Уровни 4 и 5 получить нельзя, поскольку полный набор требований CMMI разработан из предположения детерминантного процесса.
P.S. Термин тим лид я использовал для обозначения члена команды, который выполняет задачи «локального» менеджера (для 2-5 разрботчиков) и одновременно выполняет задачи по кодингу.
Когда я был тим лидом, меня очень напрягали оценки задач, которые приходили сверху. Сейчас я менеджер проектов, и в мои обязанности входит построение и поддержка правильного Процесса Разработки.
Статья действительно больше для менеджеров проектов, но, надеюсь, вопросы, которые обсуждаются, волнуют и тим лидов.
Кроме того, каждый тим лид со временем становится менеджером проектов как правило. :)
>>«политика порой играет более важную роль в проекте, чем ...»
Согласен. Особенно это ощущаю, работая в оффшорных проектах, где коммуникации существенно усложнены.
Данный пост был пробой. Я получил очень богатый фидбек. И вам спасибо за ссылку. Буду пытаться систематизировать материал и выходить на предложения по процессу разработки.
Это может привести к интересным идеям — например к чему-то типа Гантт 2.0. Где график Гантта как-то совмещен с каждодневными оценками.
А с тем что «совремнный» Гантт — больше «форма планирования», согласен
Именно такая операция невозможна.
В этом примере меденжер должен перерисовать изначальный Гантт, перенеся или разорвав приостановленную задачу. Тоесть один беклог отображается на несколько Гантт диаграмм.
Здесь рассматривается логика приложения. Представте, что мы находимся на странице плана итерации в режиме беклог. Что мы должны увидеть, если на этой странице пользователь нажимает кнопку «Gantt»?
Не получится просто ему показать одну Гантт диаграмму. Ему таких диграмм нужно сгенерировать столько, сколько рабочих дней показано в одном бэклоге. Поскольку в Скраме каждый день мы все планируем заново.
Во время спринта делается каждодневная оценка оставшегося времени по задаче. И некоторые задачи могут улетать за их первую оценку, сделанную во время планирования спринта. Это жизнь.
Вот несколько примеров, чтобы выйти на общую точку понимания:
задача сделана раньше плана:
план — 24. Отчеты — 24 12 0
задача совпала с планом:
план — 24. Отчеты — 24 16 8 0
задача не вписалась в план:
план — 24. Отчеты — 24 28 20 12 4 0
обычно такое случается, если находятся непредвиденные проблеммы с логикой или архитектурой.
Давайте посчитаем. Пусть первая (плановая) оценка задачи — 16 часов.
Разработчик рапортовал такие оценки: 12 8 8 8 8 8 0. Тоесть, например он был переключен на другую задачу. Посмотрим какой процент получается на Гантте на 6й день: 6*8/(6*8 + 8) — это 86%.
Чтобы этот эффект не наблюдался, мы должны каждый день перерисовывать Гантт.
Если продукт долго растет, в нем накапливаются косяки, в том числе архитектурные. Наступает момент конфликта, когда программисты понимают, что следующий прирост функционала нельзя строить на плохом фундаменте, но Владелец продукта (Product Owner) требует все время итерации потратить на новые функциональные фичи.
Здесь очень кстати сделать обзор кода и соорудить хорошо оформленный документ, описать драматичные моменты… Помогает договориться.
Тогда мы решили воспользоваться такой структурой
1. логика
Примеры точно не могу вспомнить, но задачи были похожи на загадки с черными и белыми шариками, обезьянками и клетками и т.д. Что-то похожее недавно промелькнуло на Хабре про вопросы к претендентам в компанию Гугл. Там еще был вопрос — почему люки на улице круглые. У нас было что-то похожее, но проще.
2. алгоритмика
Здесь идут задачки, похожие на вашу. Я вспомнил свой пример — нужно было за 15 минут написать карточную игру «Дурак» для игры между человеком и компьютером.
Успешное прохождение такого теста подразумевало умение концентрироваться на главном, умение строить очень простые модели и реально оценивать время, ну и конечно, алгоритмику. В итоге, например, один из программистов написал на Руби программку с консольным UI. Она умела тасовать колоду, раздавать карты и простое кейс-меню для хода.
3. профессионализм
Здесь проводилось классическое интервью типа вопросы-ответы по языку программирования, фреймворкам, паттернам, тонким делам типа рефлексии и тридов
Во время проведения исследований вышла статья в физ-реве о том, что данная модель плохая и нужно использовать другую. Другая модель требует создание другой лабораторной установки. План нужно менять.
Так где тут детерминантность?
Это не простой вопрос… Нужно подумать…
Спасибо за комментарий.
Именно, я набил эту шишку, когда увлекся Скрам и убедил своего топ менеджера, что мы обойдемся вообще без артефактов детерминантного процесса и все проведем по модели *постоянное общение + частые оценки + 2-недельные итерации с презентациями*. Тот проект мы завалили…
Нельзя игнорировать *легаси* или исторически сложившийся массив связей между людьми, возглавляющими фирму и их клиентурой.
Поэтому я предлагаю «панцирь» процесса строить и поддерживать в детерминантном подходе, а внутренности — в эмпирическом.
>>Спускаясь с теоретизирования, люди — разные. Одному может быть до фени те пять копеек что будут доплачены за доп.фичу по сравнению с ее выгодой, а другому для этого нужно согласовать изменение бюджета по 20-ти инстанциям и пофиг что от нее будет лучше и денег больше. Это нельзя не учитывать.
Я не претендую на универсальное решение проблемы. У нас — а это небольшая команда из 35 разработчиков — стратегия сработала (по крайней мере один раз). Но вполне возможно, что она не годится для компаний-флагманов рынка с командами в 200 или 400 человек.
Возможно, вы имели ввиду микро-планы — такие как план расчетов методом Монте-Карло какой-нибудь мат. модели. Я имел ввиду макро-план — синтезировать новую керамику, устойчивую к перепадам температур и т.д. То есть планы, которые включают длительные промежутки времени и предполагают открытия новых эффектов.
На мой взгляд, попытки объединить оба протокола под одной крышей уже велись, да и будут продолжаться. Возьмем хоть RUP. Тяжелый итерационный процесс, который позволяет жанглировать фичами. Он идеален для CMMI. Но вот не прижился…
Может это прозвучит слишком пафосно, но я хотел сказать, что смешивать эти протоколы Не Надо. Как с вечным двигателем… Люди тратили свои жизни на постройку тысяч механизмов, которые должны были бы работать вечно. Но в физике есть жестокий закон сохранения энергии. Имеет смысл направить усилия в другом направлении…
>>Отодвигать решение проблемы с классической тройкой время-деньги-обьем на этап завершения нехорошо
Тут отодвигать такое решение не приходится, поскольку мы принципиально убираем из разработки понятие Большого Плана. Согласующая итерация проводится больше «для бухгалтерии». По замыслу, в этот момент уже довольный клиент бегает по презентациям и во всю использует продукт. На согласовующей итерации подчищаются баги и доделываются очень низкоприоритетные фичи, которые не вносят существенных искажений в понятие «объем».
>> заказчик может думать что начальные деньги и сроки классный ПМ сопряг с новыми фичами, а контора верить в то что дополнительный обьем и увеличенные сроки будут финансово поддержаны спонсором проекта
А вот это действительно самый опасный момент. Безусловно, все, и особенно клиент должны понимать условия игры. Мы клиенту предоставляем супер-сервис, но он морально и технически должен быть готов к нему. Если клиент делегирует все принятие решений на вас, не проявляет интерес к ранним версиям системы, то здесь лучше сразу идти по Водопаду.
>>В целом имхо это просто разделение уровней — есть управленческий, где ПМ и его руководство с заказчиком, и выполняющий, где ПМ же, исполнители и представитель заказчика же. Они вполне могут иметь разные процессы, наиболее удобные участникам. Главное что бы работало.
Я почти с вами согласен :)
Я бы только слово «могут» заменил на «должны». Это и есть главный *месседж*, который я хотел отправить.
Спасибо за ваш комментарий.
Я не собираюсь спорить на тему «cтарые или новые» MVC и слоистый паттерн. Статья в общем, о другом. Вы можете в этом месте вставить любую *новую архитектурную революцию* на ваш вкус и читать статью дальше.
Действительно, Скрам процесс может получить CMMI 3. Но это потолок. Уровни 4 и 5 получить нельзя, поскольку полный набор требований CMMI разработан из предположения детерминантного процесса.
Кстати, вот в этой книге (по секрету — я нашел ее CHM в сети) — Agile Project Management with Scrum by Ken Schwaber ISBN:073561993x Microsoft Press © 2004. — применению Скрам для CMMI посвящен небольшой раздел.
Статья действительно больше для менеджеров проектов, но, надеюсь, вопросы, которые обсуждаются, волнуют и тим лидов.
Кроме того, каждый тим лид со временем становится менеджером проектов как правило. :)
Согласен. Особенно это ощущаю, работая в оффшорных проектах, где коммуникации существенно усложнены.
Данный пост был пробой. Я получил очень богатый фидбек. И вам спасибо за ссылку. Буду пытаться систематизировать материал и выходить на предложения по процессу разработки.
Я не обсуждал интеллект людей которые работают в ООН.
Вообще, я предлагаю закрыть политические темы. Тема топика сложная и изначально я собирался ее рассматривать в разрезе проблем управления проектами.