Запрос о способности Rally моделировать различные виды деятельности, необходимые для обеспечения гибкости всей организации

Question

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

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

Другими словами, когда организация и образ мышления готовы к переменам, первостепенное значение приобретает отсутствие борьбы с инструментами.

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

Основываясь на своем опыте в консалтинге и обучении программным организациям, как гибким, так и другим, я сформулировал набор потребностей, которым должен соответствовать хороший гибкий инструмент. Для меня наиболее важным требованием является гибкость инструмента для моделирования всего комплекса действий, которые отнимают время у людей. Поскольку внепроектные действия могут занимать до 50% времени разработчиков, я вижу "простое ванильное гибкое управление проектами" с невыполненным заданием по продукту, выпуску и итерации как лишь часть того, что должен справиться хороший инструмент,

Хотя такие функции, как вложения, интеграция управления версиями, права доступа и т. Д., Могут быть полезны, нехватка всех действий, представленных в инструменте (с достаточной точностью, конечно), затрудняет реальные изменения.

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

Инструменты, которые я, основываясь на некотором поиске в Google, выбрал для "первой волны" моей оценки, это VersionOne, Rally, Jira+Greenhopper, Agilefant (с открытым исходным кодом) и IceScrum (с открытым исходным кодом / freemium). В ближайшем будущем вы можете найти этот же пост или, по крайней мере, похожий пост на их форумах.

Картинка ниже подводит итог моей концепции оценки; три первых (более простых!) случая также дополнительно объясняются ниже; Хотя в этих организациях не так уж много людей, они, на мой взгляд, хорошо подводят итог практическим задачам. Остальные случаи я разберу в письменной форме, если понадобится.

< >]

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

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

Эксперт-фрилансер (1 человек)

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

"Tech adm", "Customer support", "Sales & biz adm" и "General adm" - это непрерывные действия, что означает, что даты начала и окончания проекта, как в проекте, не имеют большого значения. В этих действиях новые истории и задачи появляются по мере необходимости, при этом определенные истории и / или задачи периодически повторяются.

На основании всех этих проектных и внепроектных мероприятий эксперт-фрилансер должен оценить, какие истории и задачи наиболее важны для "прямо сейчас", а какие можно оставить на потом. В оптимальном случае инструмент будет иметь единое представление, которое объединяет все Истории и Задачи из всех текущих действий, рабочую нагрузку, которую они несут, и оставляет Внештатному Эксперту окончательный выбор того, какие задачи решать в первую очередь.

Как бы вы предложили внештатному эксперту смоделировать его работу в своем инструменте?

Микроорганизация (3 человека)

Микроорганизация из трех человек состоит из двух технических специалистов и основателя / генерального директора. Технический дуэт заботится о разработке продукта (с основателем / генеральным директором, являющимся владельцем продукта), который проводится в виде двухнедельных спринтов, каждый из которых заканчивается небольшим публичным выпуском. Истории извлекаются из журнала невыполненных работ основного выпуска, который должен выходить ежеквартально, и в дополнение к этому списку выпусков владелец продукта постоянно выделяет следующий предстоящий выпуск в отдельном журнале отставаний. Таким образом, портфель продуктов содержит все идеи функций (и т. Д.), Которые пока не считаются важными для включения в текущий или следующий выпуск.

Консалтинг осуществляется в виде проектов, причем некоторые консалтинговые проекты состоят из итераций, согласованных с заказчиком, в то время как другие консалтинговые проекты не имеют итераций. Все консалтинговые проекты выполняются одним ответственным лицом.

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

За исключением этого, все другие виды деятельности (Tech adm, General adm, а также Sales), аналогично вышеописанному фриланс-эксперту для одного человека, представляют собой "непрерывные действия", в которых время от времени появляются истории и задачи, а также как периодически.

Как бы вы предложили Микроорганизации смоделировать их деятельность в своем инструменте?

Очень маленькая организация (7 человек)

В очень маленькой организации из семи человек есть две "команды": техническая команда из пяти человек и деловой дуэт из двух человек. Tech adm, General adm, как в случае с микроорганизацией.

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

Один из членов делового дуэта обладает техническими возможностями (как и первоначальный программист продукта), а также как владелец продукта, похожего на Scrum, для разработки Продукта, что рассматривается аналогично описанному выше случаю Микроорганизации. Другой, более высокопоставленный член сети бизнес-дуэтов с очень хорошими связями не следит за ходом разработки продукта так пристально (а многие пользовательские истории уровня итерации имеют для него мало значения), он нуждается в том, чтобы осуществлять продажи эффективно (что он в противном случае очень хорошо умеет!), чтобы быть в курсе развития больших функций, которым способствуют истории уровня итерации.

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

Как бы вы предложили Очень Маленькой Организации смоделировать их деятельность в вашем инструменте?

Answer 1

Спасибо за совет!

На самом деле, поскольку у Rally нет форума сообщества пользователей, я получил предложение от их службы поддержки пользователей публиковать сообщения в SO и отмечать его как Rally.

Сам я тоже не уверен, что кто-нибудь ответит, но стоит попробовать. Другим способом было бы отправить это непосредственно в службу поддержки.

В любом случае, вот ссылки на форумы других производителей инструментов, на которые я публиковал; только два, так как фильтр спама мешает мне публиковать больше:-)

IceScrum: http://forum.icescrum.org/viewtopic.php?f=17&t=1557&p=4414

Джира + Гринхоппер: https://answers.atlassian.com/questions/80206/an-inquiry-about-jira-greenhopper-s-capability-to-model-different-kinds-of-activities-for-achieving-organization-wide-agile

Answer 2

Я управляю командами инженеров в том, что было бы описано в вопросе как "большая организация". Мы занимаемся Agile уже четыре года.

Я хочу оспорить одно предположение, которое делают многие люди: "Потому что внепроектные мероприятия могут занимать до 50% времени разработчиков". Если инженеры организации проводят где-то почти половину своего времени в административном управлении, существует огромное препятствие, которое Scrum Master и руководство должны устранить. Это должно быть около 0%.

Инженеры должны разрабатывать, тестировать, кодировать. Если они занимаются чем-то другим, организация должна развивать культуру внимания. В моей организации ни один инженер не тратит время на инструмент управления проектами. В настоящее время мы используем Rally, но это не имеет отношения к инженерам, потому что его используют только владелец продукта, Scrum Master и менеджеры.

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