И еще один огрех — при создании 3й ветки перекидывает ее вправо от рут ноды. Чтобы обхитрить, приходится создавать пустую ветку — и уже потом к ней крепить все остальные.
Mind42 в этом смысле меня порадовал — там даже изображения можно атачить. С другой стороны — довольно бедный набор икон. Также не хватило возможности обьединять ветки рассуждений.
Одно радует как пользователя — количество сервисов растет, как идейного программиста — возможность запустить свой стартап все еще есть и в этом сегменте.
Элемент принятия решений на самом присуствует в этом подходе, особенно если ММ строится одновременно двумя (или более) людьми.
Пример исследования возможности миграции RoR приложения здесь кстати показателен. Во время исследования несколько раз пришлось принимать решения: идти с Ruby или Python? Насколько серьезна платформа JRuby и ее экосистема на GAE? и т.д. В этих случаях безусловно присуствовали альтернативные ветви и по ним шла дискуссия, сопоставлялся вес той или ветви.
Идею поста по динамике принятия решения я поддерживаю. В данном посте я сосредоточился на инструментарии и идеях вокруг концепции ММ по представлению данных, это верно.
Да и у нас не все так гладко :). Разработка софта — это не конвейер. В него вовлечено много умных и хитрых людей. А что делают умные и хитрые люди с правилами ;)? На ровном месте всегда может возникнуть конфликт…
По поводу Agile vs Waterfall (ВФ) можно говорить часами. Мне кажется что самое главное — это то, что в Agile заказчик участвует в проекте (входит в команду если хотите), а в ВФ — нет.
С точки зрения менеджера и команды, вообще, ВФ *ПРОЩЕ* — и его проще организовать и поддерживать. Если мы исключаем клиента из схемы потоков, все радикально упрощается.
Agile на мой взгляд — это более сложный, более дорогой сервис для клиента чем ВФ. Платинум сервис (или как там маркетинговые люди говорят)… Это как пересесть на самолет после автомобиля. Понятно что заказчик должен быть готов к такому сервису и понимать что вокруг него происходит и что хотят все эти люди от него.
Что же получает заказчик в Agile — он видит как его продукт *растет*. Он может сказать что здесь нужно чтото убрать а там — добавить. В ВФ все происходит как в старом фильме про графа Калиостро: молодой барин загадал увидеть Лауру, а как скинули покрывало — там оказалась подружка фокусника :). Но деваться то некуда — все уже подписано.
Извините за пространные рассуждения, просто мне хотелось синхронизировать картинку которую мы видим в этом вопросе. По сути… мне кажется что критерием выбора между Agile и ВФ есть не длина проекта — она может быть любой — а принцип включать или не включать заказчика в процесс.
Что касается нашей истории — то мы конечно работали и иногда работаем в ВФ (по договоренности с заказчиком). Пробовали также Скрам, но не прижилось — слишком много этикета. Поэтому построили свою адаптацию Agile, как впрочем и многие другие команды вроде нашей.
В: 1) Как видно из примера, драфты страниц сайта рисует project owner. Каким образом в этом процессе задействован дизайнер? Он подключается уже после согласования всех страниц и рисует дизайн по драфтам?
О: У нас так сложилось так что дизайнер работает на отдельном потоке. Его задача — нарисовать и согласовать с заказчиком главную страницу сервиса и несколько второстепенных — чтобы задать look&feel всего проекта. В то-же время в задачу дизайнера не входит рисование всех страниц сервиса. Программисты должны экстраполировать дизайн на их страницы. Разумеется если у них возникают вопросы пор деталям дизайна — они обсуждаются с дизайнером отдельно.
Макеты могут отличаться от дизайна по layout. Программист по макету создает функционал UI, но layout подбирает по дизайну.
Например если в макете главное меню находится в верхней части станицы, а на дизайне оно лежит под большим банером — программист должен его положить под банер (но пункты меню по составу точно соответствуют макету).
По времени дизайнер начинает работу увидев первый макет домашней страницы. Дальше его фантазию никто не сдерживает. Но он должен получить от заказчика добро на один из вариантов.
В: 2) Каким образом вам удалось затащить в волну заказчика? :) Что делать, если заказчик отказывается общаться любыми другими способами как по телефону, электронной почте, личных встречах?
О: Да это сложный момент. Но здесь владелец проекта проводит откровенный разговор с заказчиком, объясняя насколько важно участвовать во всех деталях во время разработки проекта. Приводятся *плохие* примеры которые случились с *плохими* клиентами.
Если же клиент несмотря ни на что явно делегирует принятие решений в команду, его просят подписать *страшную* бумагу о том, что он не будет иметь никаких претензий к финальному продукту если его функционал соответствует Спецификации. То есть по существу проект переключается в Ватерфолл. Архитектурная итерация расширяется и в ней создается спек, состоящий из макетов и тест кейсов. Однако, подчеркну, что этот случай мы рассматриваем как плохой вариант и стараемся клиента склонить к нормальному Agile процессу, возможно с подключением с его стороны ИТ-консультанта.
В: 3) Окончательный аппрув, что вот эта страница/фича должна выглядеть вот так дает заказчик? Что делать, если заказчик срывает срок согласования страницы/фичи?
О: Драфт требований пишется на следующую итерацию. Клиент имеет достаточно времени на его inputs и он в курсе, что, если на момент старта Спринта он не успевает отреагировать на предложения и вопросы, то включается правило делегирования принятия решения в команду.
Да, Волна только начинает свое движение. Есть много мест которые нужно развивать… Например очень не хватает «фирменного» Drawing гаджета. Также хотелось бы иметь возможность тонких настроек — например не разрешать редактировать определенные сообщения в волне. Очень не хватает конвертеров из Волны (всей я имею ввиду) в pdf, doc и рисунок. Пригодилась бы очень система версионности Волны, нотификаций в еmail, элементов VOIP.
В целом Волна — серезный шаг вперед для коммуникаций. Думаю *ребята* еще не раз нас удивят…
Вики — отличный инструмент для инженерных артефактов или тест кейсов.
Для сбора требований на мой взгляд нам нужно что-то другое. Мы должны создать некоторое виртуальное пространство со свойствами чата, онлайн доски для набросок и т.д. Здесь решающим фактором за Волну именно для меня является синхронность общения плюс сокращение времени на формирование вопроса — обозначения к какой части системы идет вопрос, его бекграуда.
С другой стороны я не призываю в волну записывать, скажем, тест кейсы. Здесь лучше Вики. Или какая-то система менеджмента документов с версиями.
Пока мы наблюдаем даже излишнюю активность. Идет небольшая партизанская цветовая война между сейлс и технарями. Сейлс норовят по малейшему поводу проект отметить красным. Технари методично возвращают желтый или зеленый. Надо подумать над тюнингом правил…
Скорее всего вы пытаетесь работать в том-же документе который я расшарил по ссылке в посте. На нем выставлены ограничения на только-чтение чтобы этот док не превратился в общую песочницу.
Вам нужно выполнить «File\Make a copy» из меню, дать копии новое имя и Вы становитесь владельцем Вашего экземпляра документа в Вашем спейсе Гугл Доков.
Для перетаскивания надо кликнуть на липучке проекта — появится его рамка. За рамку его можно перетаскивать по «доске». Если нужно модифицировать текст или цвет — на той-же рамке выбираем Drawing\Edit и редактируем. Если нужно удалить — Drawing\Delete.
Согласен. Безусловно GoogleDocs API — мощный механизм, предназначенный для программиста.
Говоря о макросах я имел ввиду более высокоуровневый подход, который позволяет строить алгоритмы на выходя из spreadsheet. Например — записать последовательность шагов а потом ее воспроизводить.
К сожалению во всех 3х проектах которые я знаю нету полно-функционального драг-н-дропа по подобию MS Project. В ganttzilla можно например драг-н-дропом рисовать связи между задачами — но не более того. Все остальное реализовано через стандартные сэттингс-формы.
Да, ситуация знакома… Тяжело советовать без детального понимания ситуации… Может какие-то из следующих идей Вам помогут? Надеюсь…
Вы отстаете от плана итерации или общего оценочного плана? Если от оценочного то это не очень серьезная методическая проблема. Если заказчик пошел с вами Agile, то он должен был быть готов к такому повороту. Если отстаете от итерационного плана — то главное дожить до следующей итерации — там вы сможете подкорректировать оценочную скорость команды.
Если возникли проблемы с интеграцией из-за недостаточно детальной информации о протоколах от заказчика, то можно это просто попробовать обсудить с ним и сделать так называемый рескоуп — растянуть соответствующие части оценочного плана.
Также можно подумать об оптимизации архитектуры Вашей программной системы. Например вынести протоколы из хардкода в настройки или скрипты. Может быть Вам пора также сделать рефакторинг? Если система долго росла — код нужно «перетряхнуть». Мы заметили что после рефакторинга у нас был серьезный прирост производительности разработки.
Да, верно, довольно часто бывает что «внутренняя» задача затягивается. Давайте посмотрим что у нас есть из «оружия» на этот случай.
Во первых на нашей стороне статистика. Когда делается оценка функционала который мы включаем в итерацию, она делается крупными прикидками — мы получаем некоторые средние оценки для задач. Если задача задерживается внутри итерации процентов на 15-20%, это вполне вероятно может быть компенсировано следующей задачей, которая потребует на 15-20% меньше времени.
Оружие по-мощнее — дережирование (orchestration) — на более сложный случай. Принцип действия основан на факте что любая (практически) ситуация с задачами и ресурсами может быть оптимизирована на основании лучшего понимания деталей в момент их реализации. Пожалуй всегда можно «Васю-поменять-на- Колю,-а-задачу-Васи-передать-Тане,-поскольку-она-работает-в-том-же-наборе-классов». То есть простой перестановкой людей и задач можно выйти из ситуации средней сложности.
На этом популярные инструменты заканчиваются. Если все плохо и оба буфера не сработали — у нас есть сверхурочные часы, и (простите братья программисты), субботы… Это запрещенное оружие, но если других вариантов нет… Из того-же класса добавление экстра-ресурсов или замена людей на проекте. К сожалению и это мы проходили…
На большом митинге в начале итерации обсуждается весь функциональный беклог что дает общее понимание задач итерации каждому разработчику. Затем раздаются первые задачи с вершины беклога программистам. При этом каждый программист получает список тест кейсов для его задачи.
Формально выдача задачи отражается на Гантте итерации в виде подсоедиения ресурса к задаче.
Прогресс выполнения также отражается непосредственно на этом Гантте. Если менеджер или тим лид хочет отследить детально этот прогресс, он кликает на задаче и видит ее микроблог со всеми постами программиста.
Хотя огрехов в юзабилити у этого инструмента хватает — например для того чтобы убрать иконку нужно на ней кликнуть правой клавишей мышки :)
Также не сразу понял как менять порядок веток — нужно начать драг-н-дроп — и появится тень-тарджет.
Одно радует как пользователя — количество сервисов растет, как идейного программиста — возможность запустить свой стартап все еще есть и в этом сегменте.
Пример исследования возможности миграции RoR приложения здесь кстати показателен. Во время исследования несколько раз пришлось принимать решения: идти с Ruby или Python? Насколько серьезна платформа JRuby и ее экосистема на GAE? и т.д. В этих случаях безусловно присуствовали альтернативные ветви и по ним шла дискуссия, сопоставлялся вес той или ветви.
Идею поста по динамике принятия решения я поддерживаю. В данном посте я сосредоточился на инструментарии и идеях вокруг концепции ММ по представлению данных, это верно.
По поводу Agile vs Waterfall (ВФ) можно говорить часами. Мне кажется что самое главное — это то, что в Agile заказчик участвует в проекте (входит в команду если хотите), а в ВФ — нет.
С точки зрения менеджера и команды, вообще, ВФ *ПРОЩЕ* — и его проще организовать и поддерживать. Если мы исключаем клиента из схемы потоков, все радикально упрощается.
Agile на мой взгляд — это более сложный, более дорогой сервис для клиента чем ВФ. Платинум сервис (или как там маркетинговые люди говорят)… Это как пересесть на самолет после автомобиля. Понятно что заказчик должен быть готов к такому сервису и понимать что вокруг него происходит и что хотят все эти люди от него.
Что же получает заказчик в Agile — он видит как его продукт *растет*. Он может сказать что здесь нужно чтото убрать а там — добавить. В ВФ все происходит как в старом фильме про графа Калиостро: молодой барин загадал увидеть Лауру, а как скинули покрывало — там оказалась подружка фокусника :). Но деваться то некуда — все уже подписано.
Извините за пространные рассуждения, просто мне хотелось синхронизировать картинку которую мы видим в этом вопросе. По сути… мне кажется что критерием выбора между Agile и ВФ есть не длина проекта — она может быть любой — а принцип включать или не включать заказчика в процесс.
Что касается нашей истории — то мы конечно работали и иногда работаем в ВФ (по договоренности с заказчиком). Пробовали также Скрам, но не прижилось — слишком много этикета. Поэтому построили свою адаптацию Agile, как впрочем и многие другие команды вроде нашей.
В: 1) Как видно из примера, драфты страниц сайта рисует project owner. Каким образом в этом процессе задействован дизайнер? Он подключается уже после согласования всех страниц и рисует дизайн по драфтам?
О: У нас так сложилось так что дизайнер работает на отдельном потоке. Его задача — нарисовать и согласовать с заказчиком главную страницу сервиса и несколько второстепенных — чтобы задать look&feel всего проекта. В то-же время в задачу дизайнера не входит рисование всех страниц сервиса. Программисты должны экстраполировать дизайн на их страницы. Разумеется если у них возникают вопросы пор деталям дизайна — они обсуждаются с дизайнером отдельно.
Макеты могут отличаться от дизайна по layout. Программист по макету создает функционал UI, но layout подбирает по дизайну.
Например если в макете главное меню находится в верхней части станицы, а на дизайне оно лежит под большим банером — программист должен его положить под банер (но пункты меню по составу точно соответствуют макету).
По времени дизайнер начинает работу увидев первый макет домашней страницы. Дальше его фантазию никто не сдерживает. Но он должен получить от заказчика добро на один из вариантов.
В: 2) Каким образом вам удалось затащить в волну заказчика? :) Что делать, если заказчик отказывается общаться любыми другими способами как по телефону, электронной почте, личных встречах?
О: Да это сложный момент. Но здесь владелец проекта проводит откровенный разговор с заказчиком, объясняя насколько важно участвовать во всех деталях во время разработки проекта. Приводятся *плохие* примеры которые случились с *плохими* клиентами.
Если же клиент несмотря ни на что явно делегирует принятие решений в команду, его просят подписать *страшную* бумагу о том, что он не будет иметь никаких претензий к финальному продукту если его функционал соответствует Спецификации. То есть по существу проект переключается в Ватерфолл. Архитектурная итерация расширяется и в ней создается спек, состоящий из макетов и тест кейсов. Однако, подчеркну, что этот случай мы рассматриваем как плохой вариант и стараемся клиента склонить к нормальному Agile процессу, возможно с подключением с его стороны ИТ-консультанта.
В: 3) Окончательный аппрув, что вот эта страница/фича должна выглядеть вот так дает заказчик? Что делать, если заказчик срывает срок согласования страницы/фичи?
О: Драфт требований пишется на следующую итерацию. Клиент имеет достаточно времени на его inputs и он в курсе, что, если на момент старта Спринта он не успевает отреагировать на предложения и вопросы, то включается правило делегирования принятия решения в команду.
В целом Волна — серезный шаг вперед для коммуникаций. Думаю *ребята* еще не раз нас удивят…
Для сбора требований на мой взгляд нам нужно что-то другое. Мы должны создать некоторое виртуальное пространство со свойствами чата, онлайн доски для набросок и т.д. Здесь решающим фактором за Волну именно для меня является синхронность общения плюс сокращение времени на формирование вопроса — обозначения к какой части системы идет вопрос, его бекграуда.
С другой стороны я не призываю в волну записывать, скажем, тест кейсы. Здесь лучше Вики. Или какая-то система менеджмента документов с версиями.
Пока мы наблюдаем даже излишнюю активность. Идет небольшая партизанская цветовая война между сейлс и технарями. Сейлс норовят по малейшему поводу проект отметить красным. Технари методично возвращают желтый или зеленый. Надо подумать над тюнингом правил…
Вам нужно выполнить «File\Make a copy» из меню, дать копии новое имя и Вы становитесь владельцем Вашего экземпляра документа в Вашем спейсе Гугл Доков.
Для перетаскивания надо кликнуть на липучке проекта — появится его рамка. За рамку его можно перетаскивать по «доске». Если нужно модифицировать текст или цвет — на той-же рамке выбираем Drawing\Edit и редактируем. Если нужно удалить — Drawing\Delete.
Говоря о макросах я имел ввиду более высокоуровневый подход, который позволяет строить алгоритмы на выходя из spreadsheet. Например — записать последовательность шагов а потом ее воспроизводить.
За ссылку — спасибо. Хорошее интро.
Можете еще взглянуть на openproj.org/openproj — но это десктоп…
Вот что можно сделать еще, так это рисовать в OpenProj а шарить онлайн инструментами.
Вы отстаете от плана итерации или общего оценочного плана? Если от оценочного то это не очень серьезная методическая проблема. Если заказчик пошел с вами Agile, то он должен был быть готов к такому повороту. Если отстаете от итерационного плана — то главное дожить до следующей итерации — там вы сможете подкорректировать оценочную скорость команды.
Если возникли проблемы с интеграцией из-за недостаточно детальной информации о протоколах от заказчика, то можно это просто попробовать обсудить с ним и сделать так называемый рескоуп — растянуть соответствующие части оценочного плана.
Также можно подумать об оптимизации архитектуры Вашей программной системы. Например вынести протоколы из хардкода в настройки или скрипты. Может быть Вам пора также сделать рефакторинг? Если система долго росла — код нужно «перетряхнуть». Мы заметили что после рефакторинга у нас был серьезный прирост производительности разработки.
Еще есть подобные сервисы www.amiproject.com и gantter.com
Да, верно, довольно часто бывает что «внутренняя» задача затягивается. Давайте посмотрим что у нас есть из «оружия» на этот случай.
Во первых на нашей стороне статистика. Когда делается оценка функционала который мы включаем в итерацию, она делается крупными прикидками — мы получаем некоторые средние оценки для задач. Если задача задерживается внутри итерации процентов на 15-20%, это вполне вероятно может быть компенсировано следующей задачей, которая потребует на 15-20% меньше времени.
Оружие по-мощнее — дережирование (orchestration) — на более сложный случай. Принцип действия основан на факте что любая (практически) ситуация с задачами и ресурсами может быть оптимизирована на основании лучшего понимания деталей в момент их реализации. Пожалуй всегда можно «Васю-поменять-на- Колю,-а-задачу-Васи-передать-Тане,-поскольку-она-работает-в-том-же-наборе-классов». То есть простой перестановкой людей и задач можно выйти из ситуации средней сложности.
На этом популярные инструменты заканчиваются. Если все плохо и оба буфера не сработали — у нас есть сверхурочные часы, и (простите братья программисты), субботы… Это запрещенное оружие, но если других вариантов нет… Из того-же класса добавление экстра-ресурсов или замена людей на проекте. К сожалению и это мы проходили…
Если возникнут вопросы — задавайте…
Формально выдача задачи отражается на Гантте итерации в виде подсоедиения ресурса к задаче.
Прогресс выполнения также отражается непосредственно на этом Гантте. Если менеджер или тим лид хочет отследить детально этот прогресс, он кликает на задаче и видит ее микроблог со всеми постами программиста.