Пусть будет в коллекции инструментов
https://play.google.com/store/apps/details?id=nikolai.planningpoker
https://play.google.com/store/apps/details?id=nikolai.planningpoker
Показаны сообщения с ярлыком планирование. Показать все сообщения
Показаны сообщения с ярлыком планирование. Показать все сообщения
Как правильно хотеть. Wishlists (преддверии Нового года)
Скоро наступает ночь исполнения желаний. Хотя, исполняться желания, загаданные под бой курантов и звон бокалов, будут весь год :)
Если загадать желание, а потом забыть о нём, то вы даже не узнаете, сбылось ли. А часто будни так заматывают, что реально и приятности забываются.
Поэтому сейчас становятся популярными сервисы "Списков желаний". Это такие странички, на которых можно написать, что хочешь. Некоторые сервисы позволяют открывать часть желаний друзьям - и тогда друзьям проще вам сделать полезный и радостный подарок.
А в целом такой список помогает планировать покупки и радовать себя не столько спонтанно, сколько и тем, что действительно хочется.
Список желаний обычно представляется в виде таблички:
---------------------------------------------------------------------------------------------------------
Что хочу // Где можно взять // Сколько может стоить // Важные характеристики
---------------------------------------------------------------------------------------------------------
Сервисов таких появляется великое множество. Достаточно сделать запрос "вишлист онлайн" или "вишлист приложение". Если не хочется изысков, то можно использовать любым доступные страницы и простые листы.
Ниже приведу пример тех, что мне показались интересными
myWishBoard
Простая регистрация через соц.сеть или емейл, возможность делиться листами с друзьями.
myWishlist
http://mywishlist.ru/
Скорее справочник покупок, в котором можно скромно намекнуть друзьям, что вы для себя присмотрели.
lesterwish
http://lesterwish.com/
Сервис по созданию нескольких список подарков и возможностью для друзей "зарезервировать", какой подарок он подарит.
wishlistr
https://www.wishlistr.com/
Хорош, если вы свободно владеете английским и хотели бы о своих желаниях рассказать иностранным друзьям.
Отличных праздников и желаний !
Если загадать желание, а потом забыть о нём, то вы даже не узнаете, сбылось ли. А часто будни так заматывают, что реально и приятности забываются.
Поэтому сейчас становятся популярными сервисы "Списков желаний". Это такие странички, на которых можно написать, что хочешь. Некоторые сервисы позволяют открывать часть желаний друзьям - и тогда друзьям проще вам сделать полезный и радостный подарок.
А в целом такой список помогает планировать покупки и радовать себя не столько спонтанно, сколько и тем, что действительно хочется.
Список желаний обычно представляется в виде таблички:
---------------------------------------------------------------------------------------------------------
Что хочу // Где можно взять // Сколько может стоить // Важные характеристики
---------------------------------------------------------------------------------------------------------
Сервисов таких появляется великое множество. Достаточно сделать запрос "вишлист онлайн" или "вишлист приложение". Если не хочется изысков, то можно использовать любым доступные страницы и простые листы.
Ниже приведу пример тех, что мне показались интересными
myWishBoard
Простая регистрация через соц.сеть или емейл, возможность делиться листами с друзьями.
myWishlist
http://mywishlist.ru/
Скорее справочник покупок, в котором можно скромно намекнуть друзьям, что вы для себя присмотрели.
lesterwish
http://lesterwish.com/
Сервис по созданию нескольких список подарков и возможностью для друзей "зарезервировать", какой подарок он подарит.
wishlistr
https://www.wishlistr.com/
Хорош, если вы свободно владеете английским и хотели бы о своих желаниях рассказать иностранным друзьям.
Отличных праздников и желаний !
Несколько слов об организации среды разработки в Devprom
Сразу оговорюсь, что это не заказная статья. Я просто полюбила этот продукт и очень хочу, чтобы вы узнали об этом.
Как организовать работу в процессе разработки - этот вопрос занимает многих менеджеров. И нужно зафиксировать и учесть много задач и их статусы, направить потоки, согласовать действия внутри комнады, как принять поток заявок и правильно их распределить, передать заказчику результаты в срок.
Когда мы говорим об обучении аналитиков - да, да, тех, кто мониторит процессы, - им особенно важно попробовать в процессе обучения хороший продукт для организации работ.
Когда с Еленой выбирали инструмент, мы в первую очередь смотрели на популярные - Jiraи схожие. Но у них была серьезная проблема - срок освоения системы занимал около недели. В краткосрочных курсах такого времени не было. Нам нужна была система, которая работает в профессиональных командах гибкой разработки, Но при этом срок освоения в среде у непрофессионала занимает не больше 2 дней.
Мы открыли Devprom совершенно случайно. Открыли и замерли: НАШЛИ! Это была любовь с первого взгляда. Мы провели в Devprom несколько команд, несколько проектов, несколько незабываемых месяцев совместных работ над задачами. Потрясающие радости открытий, когда впервые у команды получалась нормальная красивая кривая Burn down, когда выстраивались грамотные бэклоги спринтов.
Чем понравился Devprom ?
Легкостью в освоении. Он прост, логичен, легко и правильно ложится на процессы Scrum и поддерживает их в динамике.
Нравится забота и подсказки техподдержки. Хорошая проработка теории и практики процессов разработки.
Еще очень понравилось то, что я легко создавала новые роли, необходимые для командной работы. Было удобно даже для представителей Заказчика. При этом настройки помогали так определить полномочия, что представители Заказчика видели именно те артефакты, которые им было необходимо, комментировать, обсуждать, задавать вопросы по проекту, но не нарушать размеренный ход проектирования.
А недавно получила письмо от техподдержки Devprom с благодарностью мне и Елене: "Спасибо за то, что обучаете аналитиков и тем более, используете для этих целей наше ПО. Нам очень приятно!"
И нам приятно :) Что вы делаете хорошую систему управления разработкой!
Как организовать работу в процессе разработки - этот вопрос занимает многих менеджеров. И нужно зафиксировать и учесть много задач и их статусы, направить потоки, согласовать действия внутри комнады, как принять поток заявок и правильно их распределить, передать заказчику результаты в срок.
Когда мы говорим об обучении аналитиков - да, да, тех, кто мониторит процессы, - им особенно важно попробовать в процессе обучения хороший продукт для организации работ.
Когда с Еленой выбирали инструмент, мы в первую очередь смотрели на популярные - Jiraи схожие. Но у них была серьезная проблема - срок освоения системы занимал около недели. В краткосрочных курсах такого времени не было. Нам нужна была система, которая работает в профессиональных командах гибкой разработки, Но при этом срок освоения в среде у непрофессионала занимает не больше 2 дней.
Мы открыли Devprom совершенно случайно. Открыли и замерли: НАШЛИ! Это была любовь с первого взгляда. Мы провели в Devprom несколько команд, несколько проектов, несколько незабываемых месяцев совместных работ над задачами. Потрясающие радости открытий, когда впервые у команды получалась нормальная красивая кривая Burn down, когда выстраивались грамотные бэклоги спринтов.
Чем понравился Devprom ?
Легкостью в освоении. Он прост, логичен, легко и правильно ложится на процессы Scrum и поддерживает их в динамике.
Нравится забота и подсказки техподдержки. Хорошая проработка теории и практики процессов разработки.
Еще очень понравилось то, что я легко создавала новые роли, необходимые для командной работы. Было удобно даже для представителей Заказчика. При этом настройки помогали так определить полномочия, что представители Заказчика видели именно те артефакты, которые им было необходимо, комментировать, обсуждать, задавать вопросы по проекту, но не нарушать размеренный ход проектирования.
А недавно получила письмо от техподдержки Devprom с благодарностью мне и Елене: "Спасибо за то, что обучаете аналитиков и тем более, используете для этих целей наше ПО. Нам очень приятно!"
И нам приятно :) Что вы делаете хорошую систему управления разработкой!
Умейте искать и правильно заимствовать идеи
Иногда кажется, что революционные вещи выдумывают те, кто их презентует. Нет, вы даже не представляете, кто именно предлагает революционные идеи. А не знаете, потому что, когда эти идеи предлагают, они кажутся настолько фантастические, что записывают их только в фантастических романах.
Думаете Стив Джобс один, кто взял у IBA идею с управлением данными кликами по монитору? Конечно, нет! До этого были Xerox, Nokia и многие другие. Но управление пальцами по экрану с удовольствием и за приемлемую цену - это 100% Стив!!!
И кого мы сейчас считаем изобретателем? Правильно! Стива!
К чему веду беседу? Прямое копирование - это, конечно, плохо. Но найти рабочую идею, доработать (часто незначительно) - это правильно. На этом принципе строится экономика. Мы должны принимать лучшее и развивать. Только так мы будем помогать прогрессу.
Узнаете?
Да, это один из рабочих компьютеров 1970х - IBM 2250 Mod 4 display station. Стоила машинка всего $280 000 (это при тех ценах).
Вот даже мануал для машинки есть: http://bitsavers.informatik.uni-stuttgart.de/pdf/ibm/2250/A27-2723-0_2250mod4Descr.pdf
И кого мы сейчас считаем изобретателем? Правильно! Стива!
К чему веду беседу? Прямое копирование - это, конечно, плохо. Но найти рабочую идею, доработать (часто незначительно) - это правильно. На этом принципе строится экономика. Мы должны принимать лучшее и развивать. Только так мы будем помогать прогрессу.
Как быстро оценить бизнес (нишу проекта)
Бизнес-аналитику иногда приходится оценивать варианты реализации того или иного проекта. Можно сделать для себя заготовочку (как в видео) и проводить оценку решений (ниш, бизнеса) за 5-10 минут.
Взято отсюда: https://www.youtube.com/watch?v=7wl-5SxyhOY
Критерии готовности VS Критерии приёмки
Что-то за последнее время я часто возвращаюсь к дискуссии о «Критериях готовности« (done criteria) и их отличии от «Критериев приёмки» (acceptance criteria). И в отдельных командах, с которыми я работаю, и на тренингах, люди поднимают похожие вопросы. Для меня, обычно, это повод написать пост.
Если высказать свою точку зрения коротко, то, как говорят в Одессе: «Это две большие разницы» :-).
О «Критериях готовности» говорят почти всегда, когда рассказывают о внедрении в Scrum. Хотя не всегда вдаются в подробности, и это порождает волну вопросов позже, когда люди начинают пробовать и «примерять» Скрам на себя. В реальности, ответ не такой однозначный в силу того, что русский перевод фраз «Acceptance criteria» и «Done criteria» может звучать очень похоже. Даже Хенрик Книберг (который, кстати, будет на AgileEE 2010) в своей популярной книге “Scrum and XP: from the trenches” был достаточно туманен, и это отразилось в русском переводе книги такой же неоднозначностью.
Конечно, если говорить философски, то и для одной отдельной Истории Пользователя (Фичи, требования, пожелания, какой_там_термин_вы_используете) нужно определить, когда она сделана/готова. Хенрик предлагает называть всё термином «Как продемонстрировать» (How to demo), хотя многие возмущаются, мол, у нас не демонстрируемая функциональность: «мы пишем сервисы» или «API для разработчиков». По схожей причине многие не любят термин «Критерии приёмки» (Acceptance Criteria), так как не у всех выполняется приёмочное тестирование заказчиком. Лично я люблю термин Майка Кона «Условия удовлетворения ожиданий» (Conditions of Satisfaction). Хотя, всё-таки, чаще всего используют Acceptance Criteria – давайте понимать его в широком смысле слова.
«Критерии приёмки» нужны нам для проверки каждой отдельной Истории Пользователя (фичи и т.п.) и подтверждения, что после реализации система работает, как этого хотел заказчик. Такие критерии будут почти уникальные для каждого элемента бэклога (Product Backlog Item) и должны уточняться, перед тем как команда возьмёт тот или иной элемент в итерацию (спринт).
Когда же речь заходит о результатах целой итерации (спринта), то тут уже стоит вопрос о том, что вся новая функциональность не просто сделана, а ещё и потенциально готова к передаче пользователям, ну или хотя бы демонстрации заинтересованным лицам. Вот тут-то на сцену и выходит термин «Критерии готовности» (Done Criteria или Definition of Done). «Критерии готовности» включают в себя ряд действий, которые нужно выполнить для того, чтобы сократить дополнительные действия между тем, когда команда говорит «мы сделали», и заказчик говорит «заверните, я беру». Если между этими двумя моментами вам нужно сделать ещё много телодвижений, то задумайтесь о том, каков же «Definition of Done» в вашей команде :-).
Поскольку почти все шаги «критериев готовности» должны быть выполнены для каждого элемента в бэклоге, то чаще всего говорят о простом проверочном списке. Важно помнить, что эти критерии применяются ко всем элементам бэклога, которые были сделаны в спринте. Хорошо бы спросить об идеях ваших тестировщиков и заказчиков, и тогда вы будете выпускать «потенциально готовый продукт» максимально подходящий к вашей ситуации.
Если у вас команда, которая работает над долгосрочными выпусками стабильной версии (т.н. релизами), то, скорее всего, у вас будут критерии ещё более высокого уровня. Их можно назвать «критерии готовности выпуска» (Definition of Done for a Release). Эти критерии повлияют на планирование всего выпуска, и о них нужно помнить постоянно и не откладывать на последний момент.
Простой мозговой штурм позволит вам сделать список из 3-10 элементов, которого будет более чем достаточно. Такой список пригодится и для планирования итерации и, если есть отдельный список, то и для всего выпуска. Ведь необходимо запланировать ровно столько функциональности, сколько вы успеете сделать согласно всем пунктам проверочного листа с «критериями готовности». Будьте реалистами 
Взято из статьи: http://tim.com.ua/2010/09/definition-of-done-vs-acceptance-criteria/
Ну, и по настоятельной просьбе владельцев сайта со статьей - ссылка на главную страницу
Планирование должно строиться на реальных возможностях
Улыбнула картинка, которую ребята добавили в общий чат. Улыбнула и заставила задуматься: а правильно ли планируется работа в спринтах? И в итоге картинка показалась криком души уставшего БА.
Подписаться на:
Сообщения (Atom)