?

Log in

От автора

Данный блог ориентирован на менеджеров проектов, аналитиков и консультантов, занимающихся внедрением информационных систем. Я стараюсь собирать различную информацию, затрагивающую управлением проектами, бизнес аналитику и консалтинг.
Если Вам понравились материалы, буду рад видеть Вас в друзьях. Также Вы можете задавать вопросы и я постараюсь на них ответить максимально развернуто.

Надеюсь информация будет полезна для Вас. Приятного просмотра.

С Уважением, Джафаров Дмитрий

Мои акаунты:
Facebook: http://www.facebook.com/d.dzhafarov
LinkedIn: http://ru.linkedin.com/pub/dmitry-dzhafarov/35/b44/858
Skype: Djafaroff
Instagram: djafaroff

Tags:

От автора

Данный блог ориентирован в первую очередь на менеджеров проектов, аналитиков и консультантов, занимающихся внедрением CRM систем. Я стараюсь собирать различную информацию, затрагивающую управлением проектами, бизнес аналитику и консалтинг, а также некоторые интересные вопросы настройки системы без программирования. Блог  НЕ рассматривает вопросы программирования. Если Вас интересуют вопросы разработки, рекомендую общеизвестный ресурс www.mmcrm.ru.

Если Вам понравились материалы, буду рад видеть Вас в друзьях. Также Вы можете задавать вопросы и я постараюсь на них ответить максимально развернуто.

Надеюсь информация будет полезна для Вас. Приятного просмотра.

С уважением, Джафаров Дмитрий
Руководитель IT проектов

Опубликовал очередное обсуждение интересного кейса на тему завышенных исполнителем оценкок в моем профессиональном сообществе на LinkedIn.

В этот раз открыты вопросы:

Как быть в этой ситуации ПМу? Каким образом убедиться в корректности или опровергнуть оценку, предоставленную компетентным исполнителем? Надо ли ПМу обладать компетенцией в предметной области, позволяющей делать оценки?

Присоединяйтесь к обсуждению.

Недавно обсуждали с коллегами разницу между этими терминами. Как ни странно четких критериев для сравнения этих понятий не нашлось. Я придерживаюсь следующего представления:

Метод - совокупность шагов, действий, которые необходимо предпринять, чтобы решить определённую задачу или достичь определённой цели.

Методика - совокупность методов для достижения поставленной цели.

Методология - наука, обобщающая методики в рамках единой и общей цели.

Опубликовал очередной кейс. В этот раз обсуждается тема прессинга проектных менеджеров.

Дискуссия очень интересная. Рекомендую почитать.
Попали руководитель проекта (ПиЭм) и сейлз в глухую тайгу. Надо чем-то питаться. ПиЭм соорудил ловушку, поймал белку, белку съели. На следующий день опять нужна еда. ПиЭм говорит сэйлзу - теперь твоя очередь. Сэйлз ушёл в тайгу и целый день его нет. Тут раздаётся крик, рёв, треск веток, выбегает сэйлз, а за ним голодный тигр. Сэйлз на дерево и кричит: "в общем, я клиента привёл, так что теперь твоя работа!".

Источник: http://lnkd.in/sEfkUy

Меньше года назад я начал развивать сообщество в социальной сети LinkedIn, посвященное проектному управлению. Я руководствовался одной простой идей – созданное сообщество – место для дискуссий на различные злободневные темы. И одним простым правилом – вежливость участников по отношению друг к другу. Эта идея была активно подхвачена пользователями и теперь спустя почти год группа насчитывает более 1000 участников, которые активно участвуют в интересных дискуссиях.
На меня группа оказала и продолжает оказывать достаточно сильное влияние. Я получаю много интересных советов и свежих идей. Я наблюдаю как современные тенденции делят сообщество на 2 лагеря консерваторов, придерживающихся waterfall подхода и прогрессивистов, предпочитающих гибкий подход. Я имею возможность получить мнение профессионалов, которое может быть очень полезным, а также много интересных контактов с интересными людьми.
Спасибо всем кто участвует в группе.


P.S. Для перехода в группу нажми ссылку.
Коллеги, добрый день. По ряду причин я должен использовать Use case для описания реализации проекта по разработке большой системы. К сожалению, до настоящего момента у меня не было опыта использования Use case для проектов, реализуемых по Scrum. Основная проблема с которой я столкнулся – что считать Product backlog Item (PBI) и как трассировать по отношению к Use case (UC)? Ниже представлены мои рассуждение. Буду признателен за критику, совет и помощь.

User story vs Use case

Первый вопрос, который надо было решить - использовать User story или Use case. После некоторых размышлений на тему, а также после прочтения книги Алистера Коберна «Современные методы описания функциональных требований к системам», книгу Майка Кона «Пользовательские истории» и статьи на эту тему я пришел к некоторым выводам:

1. User story нам не подходят т.к. сложно понять поведение большой системы через формат записи User story.
2. User story не обладают механизмами таксономии и их сложно группировать по каким то признакам. В результате возникает груда записей, которым логически мало связаны друг с другом. В этом плане возможности Use case значительно выше и позволяют построить логически связанное описание. Очевидно, что без иерархии нам не обойтись.
3. При этом оказалось, что без User story не сделать Use case т.к. нужен первоначальный драйвер, который позволит быстро их подготовить. После подготовки Use case их можно было выкинуть.
4. Отличие хорошо написанных user story от хорошо написанных use case не велико. Формально Use case имеет более глубокую детализацию, что неплохо, когда в проекте работает больше 6 разработчиков и сложные заказчики. Об этом говориться в книгах обоих авторов, приведенных выше.

Цель, которую мы приследуем - нам нужен логичный, обозримый и целостный формат описания системы, а также взаимодействия с внешними системами. В связи с этим нами было принято решение использовать Use case.

Что и как?

Второй вопрос, который нам предстояло решить, как описать требования. Мы учли возможность использовать Use case для "Общего понимания", цели которого могут быть достигнуты за несколько шагов, а есть уровень вполне конкретных целей пользователя, которые могут быть описаны в одном кейсе. При этом кейсы могут быть логически связаны друг с другом гиперссылками. В книге Корбена первые представлены "уровнем неба", вторые "уровнем моря". По сути у нас может быть один кейс уровня небо, содержащий несколько кейсов уровня Моря. Реализация кейса уровня неба может быть достигнута через реализацию всех кейсов уровня моря. Нас это вполне устраивает т.к. позволяет достичь поставленной цели - логичный, обозримый и целостный формат описания системы.

Пример (заведомо максимально упрощенный):
==================================
UC_1 Пользователь получает деньги в банкомате
Уровень: небо
Сценарий:
1. Пользователь проходит процедуру авторизации введя пин код и сумму к выдаче.
2. Пользователь завершает операцию, получив деньги и карту.

Примечание: Подчеркивание означает наличие расширения.
==================================

Что бы достигнуть этой цели нужно для начала пройти авторизацию. Мы описываем это в следующем Use case:

==================================
UC_2 Процедура авторизации
Уровень: море
Необходимое условие: Пользователь вставил карту
Сценарий:
1. Система авторизует пользователя.
2. Система запрашивает процессинговый центр разрешение на операцию и разрешение выдачи запрошенной суммы.
3. Система сообщает банкомату результат процедуры авторизации.
==================================

Следующий кейс завершает задачу:

==================================
UC_3 Завершение операции
Уровень: море
Необходимое условие: успешное завершение UC_2 (пользователь авторизован, запрошенная сумма разрешена к выдаче).
Сценарий:
1. Система возвращает карту пользователю.
2. Система осуществляет подсчет купюр и их выдачу.
2. Система обменивается данными с процессинговым центром для фиксации результата выдачи денег.
==================================

Формирование PBL на основании use case

Последний вопрос, на который нам надо было ответить, как сформировать Product backlog (PBL) с использованием представленных выше кейсов. Мы рассмотрели несколько вариантов.
Вариант, который сразу отпал - взять в качестве PBI 1й уровень (UC_1 Пользователь получает деньги в банкомате) нельзя т.к. это однозначно может не уложиться в спринт т.е. слишком эпично и нереализуемо в рамках одного спринта. Далее мы рассмотрели другие варианты:

Вариант 1
В качестве PBI взять UС_2 и UС_3. Получится PBL, содержащий:
1. Процедура авторизации
2. Завершение операции
Плюсы: Простота трассировки. В качестве задач для реализации PBI элемента мы можем использовать шаги кейса. Описание, содержащееся в Use case, достаточно полное для понимания требований и критериев приемки.
Минусы: Задача может быть слишком большая для спринта. При этом этот минус легко нивелировать разбив этот Use case на несколько меньшего размера.

Вариант 2
В качестве PBI взять шаги 2го и 3го use case. Получится PBL, содержащий:
1. Система авторизует пользователя.
2. Система запрашивает разрешение на операцию и размер максимальной суммы выдачи.
3. Система сообщает банкомату результат процедуры авторизации.
4. Система возвращает карту пользователю.
5. Система осуществляет подсчет купюр и их выдачу.
6. Система обменивается данными с процессинговым центром для фиксации результата выдачи денег.
Плюсы: Хорошая атомарность, поддающаяся оценке.
Минусы: Сложно трассировать с конкретным Use case. Сложно отслеживать последовательность реализации (критический путь). С точки зрения невилирования проблем можно использовать таксономию, что может также создать дополнительные сложности.

Вариант 3
Отталкиваяс от имеющихся Use case подготовить свой набор PBI элементов, не связанный наприямую с UC. Получится PBL, содержащий:
1. Процудура авторизации.
2. Взаимодействие с процессинговым центром.
3. Завершение операции.
Плюсы: есть возможность удобного атомарного разделения задач.
Минусы: трассировка элементов PBL с конкретными UC очень сложная.

Взвесив все плюсы и минусы, я пришел к выводу, что лучше использовать 1й вариант и стараться дробить use case до уровня реализации в рамках одного спринта. Таким образом у нас будут Use case общего характера (уровня неба) и use case, подлежащие реализации (уровень моря).

При всей своей любви к гаджетам я не спешу выбрасывать бумажный блокнот. Работая с клиентами, часто требуется что то быстро записать или схематично зарисовать и тут же исправить. После многочисленных проб я понял, что на данный момент нет ничего лучше бумаги.

У меня есть планшет, который работает на виндах. Рисовать пальцем или внешней мышкой схемы, поверьте, нереально. Есть инструментарий распознования введеной вручную информации, но... зачем он? Писать прописью пальцем? Попробуйте и вас ждет разочарование. Вводить текст на планшете с экранной клавиатуры удовольствие тоже очень сомнительное. В результате я остановился на блоконоте. На встречи с клиентами я предпочитаю брать мой любимый блокнот Moleskine формата А4.

У планшета есть будущее, если будет совмещены возможности сенсорного ввода пальцами (как это замечательно получается на устройствах Apple) и ввода информации ручкой (как это сделано на графическом планшете). Если все это будет весить полкило, а работать не меньше 8 часов, я куплю это устройство.

Возможно есть такие устройства - прошу поделиться информацией.

Profile

dzhafarov
Dzhafarov Dmitry

Latest Month

May 2015
S M T W T F S
     12
3456789
10111213141516
17181920212223
24252627282930
31      

Syndicate

RSS Atom
Powered by LiveJournal.com
Designed by Lizzy Enger