Приношу извинения — недопонял, что Вы как раз для веба это и допускаете)
Под «клиентом» имею в виду в любом случае вызывающий удаленный код — даже Веб — это клиент-сервер. Ну и _теоретически_ принципы сохраняются и для более толстого клиента, но на практике много разных вынужденных отклонений, конечно.
А так с Вашим решением вполне согласен, только вопрос: Вы создаете специфические QueryObject для специфических методов API, или же, например, fetch-стратегии через конфиг привязываете к методам API и нужные передаете в более общие QueryObject?
Ведь веб-клиент ну очень сильно подталкивает выполнять очень полезный принцип — «No Distributed Objects».
То есть просто данные клиенту нужно передавать.
Тогда ключ — в продуманном API:
— хочет клиент просто пользователя — передаем ему пользователя, группы — как id;
— хочет всех пользователей со всеми группами — передаем всех пользователей и все группы.
Да, клиент при этом сам увязывает объекты по переданным id, при необходимости сам реализует lazy load (если, например, AJAX работает). Но это и правильно: только клиент знает, что в какой момент ему понадобится.
Заказываем на аутсорсинг айфон-приложение. ТЗ пишем сами — только функциональное. Подрядчики его принимают, начинаем разработку.
Во время разработки iOS обновляется с 3.x до 4.0-4.2, выходит iPhone 3GS, iPad. Выпущенное приложение начинает критически глючить на новых устройствах и версиях ОС.
Пользователи жалуются на баги, мы воспринимаем это как баги — соответственно, не закрываем проект, пока не получим стабильную работу на всех версиях. Подрядчики получают новую работу за те же деньги, не вошедшую в первоначальный расчет, заказчик недоволен подрядчиками, пользователи недовольны продуктом (а это дороже, чем экономия на «бесплатной» работе подрядчика).
Как надо было: подрядчику продумать типовые нефункциональные требования, учесть, что глюки на новых версиях — норма (о них предупреждает сама Apple и заранее выпускает беты для проверки приложений), учесть это в ТЗ — оговорить поддерживаемые версии, оговорить условия поддержки новых версий).
Что бы получилось: у обеих сторон (прежде всего, у подрядчиков) в нужный момент сработал бы сигнал о задачах по поддержке новых версий платформы, делались они бы в штатном режиме (при любой договоренности об оплате), подрядчики бы не попали на дополнительный объем, мы бы не думали, что у подрядчиков столько косяков, пользователи бы не думали, что в продукте столько косяков — мы бы предупреждали о поддерживаемых версиях.
ТЗ должен писать исполнитель (по начальной постановке, составленной совместно):
1. аналогия с постановкой задачи сотруднику: прежде всего убедиться, что тот все правильно понял. железный вариант — сотрудник сам повторяет формулировку задачи, а руководитель при необходимости придирается. Так и ТЗ — детальную постановку задачи — пишет подрядчик, а заказчик придирается: придраться легче, чем сделать самому — волшебное правило начальника, и по небольшому проценту выявленных проблем можно судить о качестве подрядчика в целом
2. в ТЗ нужно прописывать и нефункциональные требования — их лучше знает и может определить исполнитель (и здесь опыт предыдущих проектов как раз работает): от времени отклика до системных требований / поддерживаемых версий платформы / гарантийного периода / сроках реакции заказчика /… еще много…
3. так давно и работают профессионалы, тем более на больших проектах и в отраслях, где цена ошибки постановки задачи еще выше — есть целые проектные институты.
4. Несколько лет личного опыта: на стороне исполнителя избегал больших проблем, написав предварительно ТЗ, а на стороне заказчика влетал в проблемы, по привычке написав ТЗ сам, но уже не так детально (исполнители влетали еще сильнее, но от этого радости мало).
НО! В прикладных IT-проектах вредно в ТЗ закладывать все функциональные требования — они меняются либо неизвестны изначально. А вот нефункциональные, сквозные — как раз стоит, чтобы соблюдать/проверять на всех этапах проекта или осознанно менять.
Поздравляю!
Алексей, Николай, очень рад за вас лично!
Кстати, теперь соседи, сможем лично пообщаться — есть интересные темы для технических дискуссий ;)
cucumber — в первую очередь для модульного / интеграционного тестирования без UI.
geb заточен под тестирование на уровне UI, то есть либо функционального (приемочного) тестирования полного среза приложения, либо UI-слоя с заглушками для остальных слоев.
easyfinance.ru выпустил свой клиент под iphone — itunes.apple.com/ru/app/easyfinance-ru/id390461066?mt=8
+ автономная работа с полным редактированием счетов и категорий в отличие от многих аналогов
+ очень удобный и быстрый ввод «на лету»
1. для любителей математики и абстракций: пусть S — стоимость работы, H — цена единицы ресурса (в данном случае — часа работы исполнителя), P — «средняя производительность» ресурса, V — номинальный объем работы, K — «коэффициент расхода» для конкретного ресурса (во сколько раз для данной работы возрастает расход выбранного ресурса), D — «относительная сложность» работы, T — количество ресурсов, необходимое для выполнения работы
Очевидно:
S = H * T, T = K * V, P = P (H), K = K(P, D) => S = H(P) * K(P) * V
В упрощенном «идеальном» случае: P ~ H (P пропорциональна H), K ~ D, D ~ 1 / P, =>
S ~ (P) * (1/P) * V = V — не зависит от K,
т.е. за сложность не платим.
— 2. Еще банальности (сорри, приближенные формулы уже лениво писать, и можно разные варианты — суть не меняется) — для реального случая и «ресурсов»-людей:
1) при правильном выборе (из множества «непереоцененных» ресурсов) производительность ресурса растет быстрее его стоимости => более дорогой специалист сделает в результате работу дешевле
2) в работе всегда есть потери — текучка, простои и т.п., снижение которых происходит медленнее роста производительности => невыгодно на относительно простую работу направлять относительно дорогого исполнителя;
3) еще скрытые потери — затраты на менеджмент и обслуживание ресурса (в основном, из-за п.2) => можно сэкономить, отдавая на аутсорсинг (если менеджмент аутсорсинга менее затратен); но возрастают риски + нет ресурса для той самой текучки
4) люди — «ресурс» привередливый, и чем дороже, тем привередливее: на относительно простую (скучную) работу придется привлекать завышенными ставками
лениво удалять все эти перлы — авось пригодится кому.
назвал ответственному оценку для «типовой» задачи (1).
Возник ряд форс-мажоров (2),
с которыми исполнитель справился (3),
затратив на порядок больше ресурсов (4).
В ходе работы он ответственному о проблемах не сообщал (5),
а тот, видя перерасход ресурсов, не пытался узнать причину (6).
+ возможно, не был оговорен сам срок сдачи работы ответственному (7) — контрольная точка.
(1) предварительно оценивай любую задачу — лучше сначала называй срок на оценку;
(2) форс-мажоры могут возникнуть всегда, независимо от наличия оценки — при форс-мажоре обязательно проведи переоценку, и глубже — с большей уверенностью, даже если с меньшей точностью (!)
(3) мог и не справиться, и это была бы не только проблема исполнителя — о форс-мажоре сообщи ответственному
(4) форс-мажор может открыть варианты, о которых ты не знаешь — например, овчинка уже не стоит выделки, или результат уже не нужен, а исполнитель видит ограниченный набор решений — при форс-мажоре переоцени и… сообщи ответственному
(5) см. (3), (4)!
(6) менеджер, отвечай за ресурсы — держи руку на пульсе
(7) менеджер, расставляй контрольные точки
В дискуссии (особенно со стороны «технарей») прослеживается такая позиция: «языком молоть» приходится либо с начальником, либо с пользователем, заказчиком и т.п. — короче, не с технарем. Хотя по факту-то «технари» больше всего общаются с «технарями». И разве нужно при таком общении ораторское мастерство?
Ответ: да! и элементарно для того, чтобы
1) хотя бы не мешать собеседнику правильно воспринимать Ваши безупречно логичные аргументы — ведь и технарь, и банкир, и менеджер — люди, с одними и теми же недостатками/особенностями восприятия, только технари, получается, еще менее восприимчивы
2) не мешать себе воспринимать собеседника, особенно если он говорить не умеет — несмотря на его зажимы и т.д. и т.п.
3) уметь не воспринимать давление, оказываемое «чистым» краснобайством, не подкрепленным логикой
Кратко: уметь говорить нужно, чтобы: 1) не мешать себе говорить, 2) не мешать собеседнику слушать, 3) отделять зерна от плевел (кстати, и в своей речи тоже)
Вот и получаем, что для технаря устная (а часто и письменная) речь критична (редко программист работает сам по себе), но при этом слабо прокачана.
поставил музыкальный будильник, на всякий случай обычный зверский будильник поставил на +2 минуты
— проснулся под музыку, назвал 1-2-3 — уже чувствую, что просыпаюсь, но вылезать совсем не хочется;
— полежал, поморгал — все остальное забыл;
— услышал, как зашевелился резервный будильник, встал без проблем;
— открыл эту страничку, проделал 1-8 — вроде как проснулся, но еще зеваю; в глазах — песок, все-таки лег во 2-м часу;
— пошел в душ, пока дошел — песок исчез: спасибо зарядке для глаз;
— после душа спать уже не хочется, сделал легкую зарядку — все, проснулся, тело перестало быть деревянным, мозг чистый, куча энергии, аппетит.
Какие для себя сделал дополнения:
1) рядом с постелью класть теплую одежду, чтобы натянуть еще под одеялом :) — очень не люблю с утра в холод вылезать, особенно под открытым окном. Сначала научусь вставать по-человечески, а потом уже мб к холоду привыкать
2) выучить последовательность разминки до вставания;
3) сначала делать зарядку, потом — в душ: организм вполне проснувшийся, после разминки можно интенсивнее поподтягиваться, отжаться, пресс покачать — тогда после душа совсем свежесть остается
извиняюсь за многа букав)
подумал, пока писал предыдущий пост: имеет больше смысла отталкиваться от типа создаваемого продукта, как, например, это делает Джоэл — www.joelonsoftware.com/articles/FiveWorlds.html. Возможно, кто-то не согласится с классификацией. Но даже по ней видно, что проекты из первого и второго миров как раз подходят под Agile в целом — изменчивая внешняя среда, возможно, отсутствие полной дорожной карты проекта.
Вообще, гораздо проще понять, куда подходит/не подходит Agile, чем сформулировать критерии выбора внутри Agile, не опускаясь в личные предпочтения. Хотя, если XP брать как жестко заданный набор практик, можно понять, где его нельзя использовать) Скрам же все-таки проще, менее детализирован — в этом его «прелесть»
довольно интересный вопрос, хоть и выводящий за пределы привычной сфре скрама — в каких непрограммистских/неайтишных проектах его можно применять. Я на такой вопрос не могу ответить с достаточной долей уверенности.
если брать айти — интересно рассмотреть проекты с «внутренним» заказчиком. например, в проектах разработки и внедрения внутрикорпоративного продукта. Как правило, такие проекты затрагивают не одно подразделение, соответственно, много руководителей так или иначе участвует в проекте или пытается на него влиять. Тут, по моему мнению и опыту, скрам позволяет максимально защитить и команду проекта, и сам проект от множества векторов влияния, продиктованных, к тому же, самыми разнообразными причинами. Но для этого (опять же по опыту), очень сплоченно должны действовать куратор и руководитель проекта (т.е. Product Owner и Scrum Master) — им вместе придется стандартные совещания начальства стараться сделать максимально продуктивными для ведения баклога проекта, и вместе же придется отстаивать такие вещи, как неприкосновенность плана текущего спринта. Кроме того, могут быть проблемы, если участники команды структурно находятся в разных подразделениях — соответственно, над ними, кроме руководителя проекта, есть еще линейные руководители, опять же имеющие свою точку зрения на проект, не всегда совпадающую с утвержденным баклогом (такая ситуация может быть в айтишных фирмах). Другие интересные варианты проектов с «внутренним» заказчиком — разработка принципиально нового продукта/разработка продукта, уже имеющего аналоги, в т.ч. новой версии существующего продукта. Отличаются, по моему, в первую очередь агрессивностью внешней среды — во втором случае добавляются такие факторы давления, как ожидания/претензии существующих пользователей, учет проекта в планах продаж, соответственно, различные публичные обещания руководства, маркетологов и т.п. Первый случай — это, фактически, стартап, т.е. проект, не встраивающийся в существующий рынок, а пытающийся этот рынок изменить/перевернуть/создать новый, и не имеющий описанной «наследственности» — существующих пользователей и т.п. Несмотря на то, что проекты а ля стартапы имеют тенденцию сильно меняться в ходе своего развития, все-таки постоянного сильного давления на них нет. К проектам первого типа скрам, по-моему, вообще очень хорошо подходит — позволяет двигаться даже без четкой дорожной карты. К проектам второго, в принципе, не хуже — опять же, внешняя среда очень изменчива.
проекты с внутренним заказчиком интересны прежде всего потому, что они заведомо рассчитаны на «продолжение» — после формального запуска проекта так или иначе его нужно продолжать разрабатывать, и, обычно, силами той же команды. То есть у них заведомо есть установка — сделать успешный продукт. В то время как в проектах «для дяди» основная цель — сделать продукт, которым будет доволен заказчик (успешно сдать продукт). А некоторая разница между этими целями есть)
Важный момент: под разработчиками Вы понимаете программистов/проектировщиков/архитекторов или всех членов команды? потому что говорить, что скрам отдает на откуп программистам какую-либо задачу, обычно не свойственную им, например, аналитику, — неверно в принципе: скрам позволяет команде самой задавать распределение задач, но происходит это в соответствии в том числе с компетенцией. И даже если, скажем, программист занимается аналитикой — это не потому, что скрам ему ее на откуп отдал, а потому, что программист в данном спринте играет еще и роль аналитика, т.к. команда нашла его достаточно компетентным. Т.е. все равно аналитикой занимается аналитик.
Возвращаясь к статье: обсуждать методологию адекватно могут только те, кто, вне зависимости от специализации, достаточно опытен, чтобы вообще осознавать суть и назначение методологий. Обсуждать же пригодность методологии к тем или иным видам проектов, по-моему, вообще могут только люди, опытные в УП — менеджеры проектов да ведущие разработчики. А для таких людей статья, в принципе, ничего полезного не несет — возможно, хватило бы просто вопроса? Все равно в статье вопрос не задан более развернуто, чем в названии ))
Спасибо.
Собственно, остается вопрос: цель этой статьи? И, конечно, когда будет раскрыта собственно тема статьи? Пока что есть только некое описание трех методологий, но тема выбора не затронута
невероятная профанация — такое ощущение, что автор далек от управления проектами. Это, наверное, плохо и, возможно, невежливо, но копаться в тексте и расписывать каждое некорректное место не буду — не стоит того. Просто, наткнувшись на фразу «Лет десять назад самые мудрые из нас, набрались смелости и приняли другое решение, и постулировали иные принципы.» — типа, водопад, это плохо, а итеративная/спиральная разработка лучше? Очевидно же, что для разных проектов подходят разные методологии. И есть, и долго еще будет большое количество проектов, для которых подходит только «водопад», пусть даже с большими затратами. После пары таких высказываний и откровенно небрежных выводов нет желания что-либо пытаться улучшить в этой статье. Соответственно, такие высказывания заставляют задуматься: то ли Автор так не уважает читателей, что позволяет себе писать откровенную ерунду, то ли он сам в этом слабо разбирается.
поэтому вопрос, который с первых строк возник — для чего Автор написал эту статью? он столкнулся с соответствующей проблемой и решил обсудить ее? или что-то для себя понял и решил просветить начинающих? другой вариант? поэтому и интересно, какое отношение сам Автор имеет к УП? (несмотря на первый «негативный» абзац, это не попытка перехода на личности — вопрос возник сразу же, при прочтении вступления — всегда лучше воспринимаю статью, если понимаю мотивацию автора, или хотя бы то, что он за нее выдает).
А по теме: рекомендую еще статью Бергманна Quality Assurance Tools For PHP — там описана целая система инструментов, включая и phpcs.
Под «клиентом» имею в виду в любом случае вызывающий удаленный код — даже Веб — это клиент-сервер. Ну и _теоретически_ принципы сохраняются и для более толстого клиента, но на практике много разных вынужденных отклонений, конечно.
А так с Вашим решением вполне согласен, только вопрос: Вы создаете специфические QueryObject для специфических методов API, или же, например, fetch-стратегии через конфиг привязываете к методам API и нужные передаете в более общие QueryObject?
Ведь веб-клиент ну очень сильно подталкивает выполнять очень полезный принцип — «No Distributed Objects».
То есть просто данные клиенту нужно передавать.
Тогда ключ — в продуманном API:
— хочет клиент просто пользователя — передаем ему пользователя, группы — как id;
— хочет всех пользователей со всеми группами — передаем всех пользователей и все группы.
Да, клиент при этом сам увязывает объекты по переданным id, при необходимости сам реализует lazy load (если, например, AJAX работает). Но это и правильно: только клиент знает, что в какой момент ему понадобится.
Заказываем на аутсорсинг айфон-приложение. ТЗ пишем сами — только функциональное. Подрядчики его принимают, начинаем разработку.
Во время разработки iOS обновляется с 3.x до 4.0-4.2, выходит iPhone 3GS, iPad. Выпущенное приложение начинает критически глючить на новых устройствах и версиях ОС.
Пользователи жалуются на баги, мы воспринимаем это как баги — соответственно, не закрываем проект, пока не получим стабильную работу на всех версиях. Подрядчики получают новую работу за те же деньги, не вошедшую в первоначальный расчет, заказчик недоволен подрядчиками, пользователи недовольны продуктом (а это дороже, чем экономия на «бесплатной» работе подрядчика).
Как надо было: подрядчику продумать типовые нефункциональные требования, учесть, что глюки на новых версиях — норма (о них предупреждает сама Apple и заранее выпускает беты для проверки приложений), учесть это в ТЗ — оговорить поддерживаемые версии, оговорить условия поддержки новых версий).
Что бы получилось: у обеих сторон (прежде всего, у подрядчиков) в нужный момент сработал бы сигнал о задачах по поддержке новых версий платформы, делались они бы в штатном режиме (при любой договоренности об оплате), подрядчики бы не попали на дополнительный объем, мы бы не думали, что у подрядчиков столько косяков, пользователи бы не думали, что в продукте столько косяков — мы бы предупреждали о поддерживаемых версиях.
1. аналогия с постановкой задачи сотруднику: прежде всего убедиться, что тот все правильно понял. железный вариант — сотрудник сам повторяет формулировку задачи, а руководитель при необходимости придирается. Так и ТЗ — детальную постановку задачи — пишет подрядчик, а заказчик придирается: придраться легче, чем сделать самому — волшебное правило начальника, и по небольшому проценту выявленных проблем можно судить о качестве подрядчика в целом
2. в ТЗ нужно прописывать и нефункциональные требования — их лучше знает и может определить исполнитель (и здесь опыт предыдущих проектов как раз работает): от времени отклика до системных требований / поддерживаемых версий платформы / гарантийного периода / сроках реакции заказчика /… еще много…
3. так давно и работают профессионалы, тем более на больших проектах и в отраслях, где цена ошибки постановки задачи еще выше — есть целые проектные институты.
4. Несколько лет личного опыта: на стороне исполнителя избегал больших проблем, написав предварительно ТЗ, а на стороне заказчика влетал в проблемы, по привычке написав ТЗ сам, но уже не так детально (исполнители влетали еще сильнее, но от этого радости мало).
НО! В прикладных IT-проектах вредно в ТЗ закладывать все функциональные требования — они меняются либо неизвестны изначально. А вот нефункциональные, сквозные — как раз стоит, чтобы соблюдать/проверять на всех этапах проекта или осознанно менять.
<без_лишней_скромности>эх, комментарий-то содержательнее поста...</блс>
Алексей, Николай, очень рад за вас лично!
Кстати, теперь соседи, сможем лично пообщаться — есть интересные темы для технических дискуссий ;)
Антон Белоусов, EasyFinance.ru
Различия — в уровнях:
cucumber — в первую очередь для модульного / интеграционного тестирования без UI.
geb заточен под тестирование на уровне UI, то есть либо функционального (приемочного) тестирования полного среза приложения, либо UI-слоя с заглушками для остальных слоев.
+ автономная работа с полным редактированием счетов и категорий в отличие от многих аналогов
+ очень удобный и быстрый ввод «на лету»
1. для любителей математики и абстракций: пусть S — стоимость работы, H — цена единицы ресурса (в данном случае — часа работы исполнителя), P — «средняя производительность» ресурса, V — номинальный объем работы, K — «коэффициент расхода» для конкретного ресурса (во сколько раз для данной работы возрастает расход выбранного ресурса), D — «относительная сложность» работы, T — количество ресурсов, необходимое для выполнения работы
Очевидно:
S = H * T, T = K * V, P = P (H), K = K(P, D) => S = H(P) * K(P) * V
В упрощенном «идеальном» случае: P ~ H (P пропорциональна H), K ~ D, D ~ 1 / P, =>
S ~ (P) * (1/P) * V = V — не зависит от K,
т.е. за сложность не платим.
— 2. Еще банальности (сорри, приближенные формулы уже лениво писать, и можно разные варианты — суть не меняется) — для реального случая и «ресурсов»-людей:
1) при правильном выборе (из множества «непереоцененных» ресурсов) производительность ресурса растет быстрее его стоимости => более дорогой специалист сделает в результате работу дешевле
2) в работе всегда есть потери — текучка, простои и т.п., снижение которых происходит медленнее роста производительности => невыгодно на относительно простую работу направлять относительно дорогого исполнителя;
3) еще скрытые потери — затраты на менеджмент и обслуживание ресурса (в основном, из-за п.2) => можно сэкономить, отдавая на аутсорсинг (если менеджмент аутсорсинга менее затратен); но возрастают риски + нет ресурса для той самой текучки
4) люди — «ресурс» привередливый, и чем дороже, тем привередливее: на относительно простую (скучную) работу придется привлекать завышенными ставками
лениво удалять все эти перлы — авось пригодится кому.
назвал ответственному оценку для «типовой» задачи (1).
Возник ряд форс-мажоров (2),
с которыми исполнитель справился (3),
затратив на порядок больше ресурсов (4).
В ходе работы он ответственному о проблемах не сообщал (5),
а тот, видя перерасход ресурсов, не пытался узнать причину (6).
+ возможно, не был оговорен сам срок сдачи работы ответственному (7) — контрольная точка.
(1) предварительно оценивай любую задачу — лучше сначала называй срок на оценку;
(2) форс-мажоры могут возникнуть всегда, независимо от наличия оценки — при форс-мажоре обязательно проведи переоценку, и глубже — с большей уверенностью, даже если с меньшей точностью (!)
(3) мог и не справиться, и это была бы не только проблема исполнителя — о форс-мажоре сообщи ответственному
(4) форс-мажор может открыть варианты, о которых ты не знаешь — например, овчинка уже не стоит выделки, или результат уже не нужен, а исполнитель видит ограниченный набор решений — при форс-мажоре переоцени и… сообщи ответственному
(5) см. (3), (4)!
(6) менеджер, отвечай за ресурсы — держи руку на пульсе
(7) менеджер, расставляй контрольные точки
Ответ: да! и элементарно для того, чтобы
1) хотя бы не мешать собеседнику правильно воспринимать Ваши безупречно логичные аргументы — ведь и технарь, и банкир, и менеджер — люди, с одними и теми же недостатками/особенностями восприятия, только технари, получается, еще менее восприимчивы
2) не мешать себе воспринимать собеседника, особенно если он говорить не умеет — несмотря на его зажимы и т.д. и т.п.
3) уметь не воспринимать давление, оказываемое «чистым» краснобайством, не подкрепленным логикой
Кратко: уметь говорить нужно, чтобы: 1) не мешать себе говорить, 2) не мешать собеседнику слушать, 3) отделять зерна от плевел (кстати, и в своей речи тоже)
Вот и получаем, что для технаря устная (а часто и письменная) речь критична (редко программист работает сам по себе), но при этом слабо прокачана.
поставил музыкальный будильник, на всякий случай обычный зверский будильник поставил на +2 минуты
— проснулся под музыку, назвал 1-2-3 — уже чувствую, что просыпаюсь, но вылезать совсем не хочется;
— полежал, поморгал — все остальное забыл;
— услышал, как зашевелился резервный будильник, встал без проблем;
— открыл эту страничку, проделал 1-8 — вроде как проснулся, но еще зеваю; в глазах — песок, все-таки лег во 2-м часу;
— пошел в душ, пока дошел — песок исчез: спасибо зарядке для глаз;
— после душа спать уже не хочется, сделал легкую зарядку — все, проснулся, тело перестало быть деревянным, мозг чистый, куча энергии, аппетит.
Какие для себя сделал дополнения:
1) рядом с постелью класть теплую одежду, чтобы натянуть еще под одеялом :) — очень не люблю с утра в холод вылезать, особенно под открытым окном. Сначала научусь вставать по-человечески, а потом уже мб к холоду привыкать
2) выучить последовательность разминки до вставания;
3) сначала делать зарядку, потом — в душ: организм вполне проснувшийся, после разминки можно интенсивнее поподтягиваться, отжаться, пресс покачать — тогда после душа совсем свежесть остается
подумал, пока писал предыдущий пост: имеет больше смысла отталкиваться от типа создаваемого продукта, как, например, это делает Джоэл — www.joelonsoftware.com/articles/FiveWorlds.html. Возможно, кто-то не согласится с классификацией. Но даже по ней видно, что проекты из первого и второго миров как раз подходят под Agile в целом — изменчивая внешняя среда, возможно, отсутствие полной дорожной карты проекта.
Вообще, гораздо проще понять, куда подходит/не подходит Agile, чем сформулировать критерии выбора внутри Agile, не опускаясь в личные предпочтения. Хотя, если XP брать как жестко заданный набор практик, можно понять, где его нельзя использовать) Скрам же все-таки проще, менее детализирован — в этом его «прелесть»
довольно интересный вопрос, хоть и выводящий за пределы привычной сфре скрама — в каких непрограммистских/неайтишных проектах его можно применять. Я на такой вопрос не могу ответить с достаточной долей уверенности.
если брать айти — интересно рассмотреть проекты с «внутренним» заказчиком. например, в проектах разработки и внедрения внутрикорпоративного продукта. Как правило, такие проекты затрагивают не одно подразделение, соответственно, много руководителей так или иначе участвует в проекте или пытается на него влиять. Тут, по моему мнению и опыту, скрам позволяет максимально защитить и команду проекта, и сам проект от множества векторов влияния, продиктованных, к тому же, самыми разнообразными причинами. Но для этого (опять же по опыту), очень сплоченно должны действовать куратор и руководитель проекта (т.е. Product Owner и Scrum Master) — им вместе придется стандартные совещания начальства стараться сделать максимально продуктивными для ведения баклога проекта, и вместе же придется отстаивать такие вещи, как неприкосновенность плана текущего спринта. Кроме того, могут быть проблемы, если участники команды структурно находятся в разных подразделениях — соответственно, над ними, кроме руководителя проекта, есть еще линейные руководители, опять же имеющие свою точку зрения на проект, не всегда совпадающую с утвержденным баклогом (такая ситуация может быть в айтишных фирмах). Другие интересные варианты проектов с «внутренним» заказчиком — разработка принципиально нового продукта/разработка продукта, уже имеющего аналоги, в т.ч. новой версии существующего продукта. Отличаются, по моему, в первую очередь агрессивностью внешней среды — во втором случае добавляются такие факторы давления, как ожидания/претензии существующих пользователей, учет проекта в планах продаж, соответственно, различные публичные обещания руководства, маркетологов и т.п. Первый случай — это, фактически, стартап, т.е. проект, не встраивающийся в существующий рынок, а пытающийся этот рынок изменить/перевернуть/создать новый, и не имеющий описанной «наследственности» — существующих пользователей и т.п. Несмотря на то, что проекты а ля стартапы имеют тенденцию сильно меняться в ходе своего развития, все-таки постоянного сильного давления на них нет. К проектам первого типа скрам, по-моему, вообще очень хорошо подходит — позволяет двигаться даже без четкой дорожной карты. К проектам второго, в принципе, не хуже — опять же, внешняя среда очень изменчива.
проекты с внутренним заказчиком интересны прежде всего потому, что они заведомо рассчитаны на «продолжение» — после формального запуска проекта так или иначе его нужно продолжать разрабатывать, и, обычно, силами той же команды. То есть у них заведомо есть установка — сделать успешный продукт. В то время как в проектах «для дяди» основная цель — сделать продукт, которым будет доволен заказчик (успешно сдать продукт). А некоторая разница между этими целями есть)
Важный момент: под разработчиками Вы понимаете программистов/проектировщиков/архитекторов или всех членов команды? потому что говорить, что скрам отдает на откуп программистам какую-либо задачу, обычно не свойственную им, например, аналитику, — неверно в принципе: скрам позволяет команде самой задавать распределение задач, но происходит это в соответствии в том числе с компетенцией. И даже если, скажем, программист занимается аналитикой — это не потому, что скрам ему ее на откуп отдал, а потому, что программист в данном спринте играет еще и роль аналитика, т.к. команда нашла его достаточно компетентным. Т.е. все равно аналитикой занимается аналитик.
Возвращаясь к статье: обсуждать методологию адекватно могут только те, кто, вне зависимости от специализации, достаточно опытен, чтобы вообще осознавать суть и назначение методологий. Обсуждать же пригодность методологии к тем или иным видам проектов, по-моему, вообще могут только люди, опытные в УП — менеджеры проектов да ведущие разработчики. А для таких людей статья, в принципе, ничего полезного не несет — возможно, хватило бы просто вопроса? Все равно в статье вопрос не задан более развернуто, чем в названии ))
Собственно, остается вопрос: цель этой статьи? И, конечно, когда будет раскрыта собственно тема статьи? Пока что есть только некое описание трех методологий, но тема выбора не затронута
поэтому вопрос, который с первых строк возник — для чего Автор написал эту статью? он столкнулся с соответствующей проблемой и решил обсудить ее? или что-то для себя понял и решил просветить начинающих? другой вариант? поэтому и интересно, какое отношение сам Автор имеет к УП? (несмотря на первый «негативный» абзац, это не попытка перехода на личности — вопрос возник сразу же, при прочтении вступления — всегда лучше воспринимаю статью, если понимаю мотивацию автора, или хотя бы то, что он за нее выдает).