Comments 66
> Но в мире есть много задач, в которых никакой Agile не будет работать
Хорошая идея статьи: обзор разных методологий и разные типы проектов — что для чего лучше подходит.
Хорошая идея статьи: обзор разных методологий и разные типы проектов — что для чего лучше подходит.
Есть куча классификаций и, к сожалению, серебренной пули нет. Вот, например, один из способов поклассифицировать проекты и подходы к их реализации.
Esli naberus vremeni i terpeniay napishu...t.k. moay dissertaciay byla kaka raz na etu temy))
SCRUM для постсовка не катит потому что
На самом деле V-model это не обязательно последовательный процесс, выработка требований может происходить вместе с выработкой спецификаций для интеграции — как говорится «разделяй и властвуй». Таким образом повышается приоритет приёмочного и интеграционного тестирования и их спецификации разрабатываются уже на этапе выработки требований.
В таком случае V-model легко адаптировать под простой kanban.
V-model это разработка по спецификациям, и документация ставится выше живых людей. Пока не отработан V-model, и не адаптирован под тот же lean или kanban — смысла в Scrum двигать нет. Люди просто не сработаются и не поймут чего от них хотят, а что вообще реально можно предложить клиентам.
Ставьте контроль качества выше процессов выработки персонала — тогда будет толк.
Ныть то что большая часть постсоветских хомячков пытаются адаптировать методологии разработанные для более здоровых и развитых западных социумов — бесполезно. У нас, да и в Европе, люди слишком больны для того же Scrum'a.
- Все привыкли компенсировать свои личные психологические расстройства,
создавая довольно замысловатые коммуникационные барьеры и рабочие ритуалы с обрядами посвящения.
Эти барьеры приводят к ситуации «обсуждать, а не анализировать; полагать, а не принимать обоснованное решение».
- Руководство и разработчики чаще всего ригидны и не обладают возможностью видения перспективы,
даже банальный анализ существующих подходов и интрументариев является непосильной задачей.
Привет, Golden Hammer. Сайонара, долгосрочная поддержка.
- Зачем разделять разработчиков на тестеров и программистов — высшую и низшую касту племенного сообщества.
У вас по идее должен быть TDD/BDD? Пускай сами для своих же задач пишут тесты…
Вы все же там такие Agile-ные экстремалы с RAD'ом…
- Желание компенсироваться — «быть самым главны и/или самым умным» и подсознательно разделять всех на тех кто нравится, и тех, кто не нравится, порождая грибной менеджмент и поверхностную выработку требований.
Привет, «Грибной менеджмент» и «Охота на ведьм».
- И наконец у вас должен быть готовый продукт в конце каждой итерации,
с последующим эволюционным рефакторингом и добавлением нового функционала…
Если так не получается — вы делаете что-то не так.
На самом деле V-model это не обязательно последовательный процесс, выработка требований может происходить вместе с выработкой спецификаций для интеграции — как говорится «разделяй и властвуй». Таким образом повышается приоритет приёмочного и интеграционного тестирования и их спецификации разрабатываются уже на этапе выработки требований.
В таком случае V-model легко адаптировать под простой kanban.
V-model это разработка по спецификациям, и документация ставится выше живых людей. Пока не отработан V-model, и не адаптирован под тот же lean или kanban — смысла в Scrum двигать нет. Люди просто не сработаются и не поймут чего от них хотят, а что вообще реально можно предложить клиентам.
Ставьте контроль качества выше процессов выработки персонала — тогда будет толк.
Ныть то что большая часть постсоветских хомячков пытаются адаптировать методологии разработанные для более здоровых и развитых западных социумов — бесполезно. У нас, да и в Европе, люди слишком больны для того же Scrum'a.
Это не scrum неправильный, это неправильные программисты! Если бы программисты были правильными, то scrum бы работал.
Советую ознакомится со спецификой компенсаторных процессов шизоидного психотипа личности в рамках коллективов с потребностью постоянной интенсивной оптимизации трудовых процессов. Потом уж судить кто «правильный», а кто «неправильный»…
На самом деле, да, если бы программисты, и руководство, не компенсировалось в рамках рабочих процессов — SCRUM бы работал, но это нереально без аудита со стороны. Либо интенсификация рабочих процессов, и их оптимизации, должна полностью вытеснить возможность какой-либо компенсации, как это было, к примеру, в Яндексе.
На самом деле, да, если бы программисты, и руководство, не компенсировалось в рамках рабочих процессов — SCRUM бы работал, но это нереально без аудита со стороны. Либо интенсификация рабочих процессов, и их оптимизации, должна полностью вытеснить возможность какой-либо компенсации, как это было, к примеру, в Яндексе.
Мой опыт говорит о том, что с Agile часто случается Карго Культ.
Неуверенный в себе начальник требует Agile (или его заставили сверху), никто не понимает зачем это нужно и как это делать, все бегают и машут крыльями (делают итерации и стоят на совещаниях), но самолёт не летит… :(
Неуверенный в себе начальник требует Agile (или его заставили сверху), никто не понимает зачем это нужно и как это делать, все бегают и машут крыльями (делают итерации и стоят на совещаниях), но самолёт не летит… :(
Абсолютно согласен — больные люди кидаются на красивую рекламу.
Большинство аббревиатур используемых в организации труда созданные не менеджерами, а маркетологами что бы можно было продать «священные знания святого бизнеса». Подсознательное желание больных людей делигировать ответственность даже мнимым артефактам является хорошей идей для монетизации.
Если рассматривать организацию работы сотрудников как задачу параллельного программирования со своей синхронизацией, и различными scatter/gather map/reduce операциями — все становится довольно просто.
Большинство аббревиатур используемых в организации труда созданные не менеджерами, а маркетологами что бы можно было продать «священные знания святого бизнеса». Подсознательное желание больных людей делигировать ответственность даже мнимым артефактам является хорошей идей для монетизации.
Если рассматривать организацию работы сотрудников как задачу параллельного программирования со своей синхронизацией, и различными scatter/gather map/reduce операциями — все становится довольно просто.
Самым ярким, конечно же, будет пример написания софта, управляющего космическими аппаратами — ну вот сложно раз две недели демонстрировать заказчикам посадку зонда на комету, получая в ответ замечания, что именно с точки зрения ученых-физиков стоило бы сделать по-другому.
Пример несколько неудачный — можно демонстрировать моделирование посадки в симуляторе, с текущей версией софта.
Но в целом да — та, где критично отсутствие багов, подход «постепенно увеличиваем качество» не сработает в лоб.
Скрам всё же не о «постепенном улучшении качества», а о «постепенном наращивании функционала». И в конце каждой итерации реализованный функционал должен быть именно что того качества, которое требуется. Другое дело, что размер итераций в особо ответственных областях может измеряться не неделями, а месяцами.
Выскажусь со своей колокольни. И вообще, я не менеджер, а разработчик, и, вероятно, во многом ошибаюсь, но всё же… На нескольких проектах был тимлидом.
Agile (как и любая другая методология) никогда не заменит собственно работу. Все с этим вот носятся, как с писаной торбой, вместо того, чтобы просто делать то, что надо. Я лично в гробу видал соответствие всяким там процессам, если у меня ключевой функционал не дописан / сдох после коммита / заказчик немного передумал.
Вот, кстати, про заказчиков. Есть вещи, которые ни в какой Agile не укладываются, и которые менять нельзя. Рюшечками и плюшечками обвешивать проект можно бесконечно, но многие почему-то считают, что в гибкость входит смена технологии, кардинальная смена дизайна на поздних этапах разработки и т.д. Ну а чо, Agile же, правильно? Гибкость там и вот это всё. К сожалению, использование Agile иногда приводит к тому, что кто-то хочет банально сесть на шею, взяться за уши и рулить куда хочется. И такие явления надо пресекать на корню, решительно наплевав на всякое несоответствие любимой методологии.
Это всё к тому, что не надо вообще на методологии зацикливаться. Это не самоцель. Следование всем умным советам из всех умных книжек приведёт только к разочарованию в неплохой, по сути, методологии. Работать надо, а не хернёй страдать.
Agile (как и любая другая методология) никогда не заменит собственно работу. Все с этим вот носятся, как с писаной торбой, вместо того, чтобы просто делать то, что надо. Я лично в гробу видал соответствие всяким там процессам, если у меня ключевой функционал не дописан / сдох после коммита / заказчик немного передумал.
Вот, кстати, про заказчиков. Есть вещи, которые ни в какой Agile не укладываются, и которые менять нельзя. Рюшечками и плюшечками обвешивать проект можно бесконечно, но многие почему-то считают, что в гибкость входит смена технологии, кардинальная смена дизайна на поздних этапах разработки и т.д. Ну а чо, Agile же, правильно? Гибкость там и вот это всё. К сожалению, использование Agile иногда приводит к тому, что кто-то хочет банально сесть на шею, взяться за уши и рулить куда хочется. И такие явления надо пресекать на корню, решительно наплевав на всякое несоответствие любимой методологии.
Это всё к тому, что не надо вообще на методологии зацикливаться. Это не самоцель. Следование всем умным советам из всех умных книжек приведёт только к разочарованию в неплохой, по сути, методологии. Работать надо, а не хернёй страдать.
Люди больны — люди желают компенсировать свои расстройства ставя организацию труда выше самого труда… что-то подходит больше, что-то подходит меньше. Не все Agile методологии одинаково полезны, но начинать нужно с адаптации существующих методологий и выработке новых, а не с попыток интеграции частных случаев, которые возможно в общем случае плохо подходят для больного коллектива.
По-этому заместь того что бы работать, менеджеры тупо копипастят всякую хрень с книжек — потому что она по идее «должна решить все проблемы как это было у одной абстрактной конторы в вакууме которую никто и никогда не видел».
Даже у таких абстрактных контор возникают проблемы и конфликты, и наши менеджеры не умеют их разрешать, вообще не умеют… об извлечении опыта история умалчивает.
имхо. В больном коллективе программист становится менеджером, в здоровом — остаётся программистом.
По-этому заместь того что бы работать, менеджеры тупо копипастят всякую хрень с книжек — потому что она по идее «должна решить все проблемы как это было у одной абстрактной конторы в вакууме которую никто и никогда не видел».
Даже у таких абстрактных контор возникают проблемы и конфликты, и наши менеджеры не умеют их разрешать, вообще не умеют… об извлечении опыта история умалчивает.
имхо. В больном коллективе программист становится менеджером, в здоровом — остаётся программистом.
Расскажите про карьеру идеального менеджера.
У меня среди знакомых «идеальных» нет, но есть очень хорошие. По меркам Москвы их можно с уверенностью назвать идеальными — они умеют внедрять Agile методологии и проводить индивидуальную работу со всеми сотрудниками в рамках коллективa, анализировать социальные связи и предотвращать конфликты, в том числе и с заказчиками.
К сожалению это входит в моё NDA — я не могу называть имён, контор и методов которые были использованы (уже спросил).
К сожалению это входит в моё NDA — я не могу называть имён, контор и методов которые были использованы (уже спросил).
Я вас спросил не про то, могут они быть или нет, а про идеальную карьеру.
Вот был школьник, закончил школу.
…
…
И вот у нас идеальный менеджер, который нравится и компании, и программистам.
Заполните пустоты, пожалуйста.
Я прицепился к " В больном коллективе программист становится менеджером, в здоровом — остаётся программистом. " — и мне стало интересно, откуда в здоровом обществе образуются менеджеры.
Вот был школьник, закончил школу.
…
…
И вот у нас идеальный менеджер, который нравится и компании, и программистам.
Заполните пустоты, пожалуйста.
Я прицепился к " В больном коллективе программист становится менеджером, в здоровом — остаётся программистом. " — и мне стало интересно, откуда в здоровом обществе образуются менеджеры.
Общество нездорово априори, спросите об этом любого психолога, или даже психиатра…
Есть мнение, что психологи и психиатры, такие же паразитирующие на людях сущности, как менеджеры и маркетологи.
Т.е. в знании самой психологии и прочих сопутствующих вещей ничего плохого нет. Так же как и в том же аджайле, самом по себе, ничего плохого нет. Но вот в том как люди применяют эти знания, есть многие беды…
Т.е. в знании самой психологии и прочих сопутствующих вещей ничего плохого нет. Так же как и в том же аджайле, самом по себе, ничего плохого нет. Но вот в том как люди применяют эти знания, есть многие беды…
Я и не отрицаю что есть очень много больних психологов и психиатров которые компенсируют свои расстройства посредством взаимодействия с клиентами — одни примитивные игры, генерализации и проекции…
Да, больные люди пытаются применить абстрактные принципы к реальным процессам без какой-либо адаптации.
Такое встречается вокруг да около.
Да, больные люди пытаются применить абстрактные принципы к реальным процессам без какой-либо адаптации.
Такое встречается вокруг да около.
ИМХО все нужно применять без фанатизма. К примеру, иметь то, что можно показать начальству/заказчику в конце недельного цикла очень даже полезно. Но зарываться в бумагах (был такой опыт), когда из 20 страниц реально полезными оказываются три строчки, а остальное — вода — тоже пользы особой не приносят. Другая крайность, когда нет ни ТЗ, ни четкого видения проекта, зато все дружно что-то делают, а закончив, переделывают заново. Такое оголтелое программирование :)
Писал ТЗ по ГОСТу для автоматизированных систем в 160 страниц для аппаратной рекламной RTB-биржи реального времени на Virtex7 ПЛИСке. В принципе простой перечень пунктов и пустые странички с заголовками — 84 страницы. И ни одной бесполезной или несодержательной строчки, только требования жирным шрифтом должен, не должен, может, не может etc как в любом RFC. Все они стали основой для приёмочных тестов и части пользовательских историй. Хотя основные пользовательские истории были разработаны ещё до выработки требований прототипа устройства…
ТЗ — штука сложная, советую изучить вводную статью.
Я ориентировался по ней, и адаптировал ГОСТ 34.602-89, писал в Latex'е с ESKDx.
ТЗ — штука сложная, советую изучить вводную статью.
Я ориентировался по ней, и адаптировал ГОСТ 34.602-89, писал в Latex'е с ESKDx.
Я же не спорю, что ТЗ может быть полезным :) У меня была задача, при определенных платежах снимать с клиентов комиссию — в одном случае в процентом соотношении, в другом — фиксированную сумму. Для этого прожектменеджером была написана бумага в 20 с лишним страниц! По моему разумению, это слишком. Зато все было по Agile :)
Agile'нец какой-то.
20 страниц при «полном Agile» — это диагноз, противоречит пункту 2.
Пускай почитают внимательно манифест.
Ну и ещё для полного счастья, советую ознакомится с реактивным манифестом.
20 страниц при «полном Agile» — это диагноз, противоречит пункту 2.
Пускай почитают внимательно манифест.
- Люди и взаимодействие важнее процессов и инструментов
- Работающий продукт важнее исчерпывающей документации
- Сотрудничество с заказчиком важнее согласования условий контракта
- Готовность к изменениям важнее следования первоначальному плану
Ну и ещё для полного счастья, советую ознакомится с реактивным манифестом.
Не могу полностью согласиться со статьей, и даже отчасти с комментариями.
Представьте себе геймдев на самообеспечении. То есть, заказчик отсутствует как класс. Российская компания, то есть руководство все эти новомодные скрамы интересуют мало. Отдел состоит из 1 гейм-дизайнера (он же начальник отдела), 2 программистов и нескольких художников. Про scrum в отделе не знает никто (возможно, кроме начальника, который его и ввел, и то я не уверен), но он успешно применяется этим отделом.
Это история из жизни, если что. Происходила на моей первой работе в качестве программиста.
Как это работало. В роли заказчика и скрам-мастера выступал начальник отдела в одном лице. Как заказчик, он сам создавал задачи. Их он получал от вышестоящих начальников, придумывал сам (геймдиз как-никак) и даже опрашивал нас, программистов, на предмет внутренних задач. Кроме того, он оценивал и приоритет задач. В качестве же скрам-мастера он проводил митинги и заставлял сразу обоих программистов оценивать задачи по времени. В начале недели был митинг, на котором мы разбирали задачи на неделю. В конце недели мы отчитывались перед гейм-дизом и самими собой о проделанной работе. За этот период у нас была только пара факапов связанных с оценкой времени.
То есть, scrum можно рассматривать как ролевую игру. Совсем не обязательно иметь реального заказчика, отдельного скрам-мастера и даже ставить в известность руководство. Достаточно, чтобы хотя бы один человек знал, что, как и зачем нужно делать, а остальные ему хотя бы не мешали и просто выполняли свою работу.
Можно, конечно, сказать, что мой пример иллюстрирует фразу
Однако, я хочу акцентировать внимание на том, что управление проектами — процесс творческий, и не нужно слепо следовать инструкциям. Нужно переосмысливать agile под конкретные команды и проекты.
Поэтому к означенным посадке зонда на комету и прошивке телефона agile вполне применим. Просто в роли заказчика будет выступать не реальный заказчик, а, например, начальник отдела или тим-лид.
А вот про поддержку полностью согласен, это не место для скрама, там относительно сложно что-либо планировать.
И еще один тип проектов, где scrum'у точно не место, это хобби-проекты, и, в частности, опенсурс, создаваемый силами сообществ. Там тоже сложно что-либо планировать, так как человек может быть занят чем-то другим или просто ничего не делать, если не хочет.
Представьте себе геймдев на самообеспечении. То есть, заказчик отсутствует как класс. Российская компания, то есть руководство все эти новомодные скрамы интересуют мало. Отдел состоит из 1 гейм-дизайнера (он же начальник отдела), 2 программистов и нескольких художников. Про scrum в отделе не знает никто (возможно, кроме начальника, который его и ввел, и то я не уверен), но он успешно применяется этим отделом.
Это история из жизни, если что. Происходила на моей первой работе в качестве программиста.
Как это работало. В роли заказчика и скрам-мастера выступал начальник отдела в одном лице. Как заказчик, он сам создавал задачи. Их он получал от вышестоящих начальников, придумывал сам (геймдиз как-никак) и даже опрашивал нас, программистов, на предмет внутренних задач. Кроме того, он оценивал и приоритет задач. В качестве же скрам-мастера он проводил митинги и заставлял сразу обоих программистов оценивать задачи по времени. В начале недели был митинг, на котором мы разбирали задачи на неделю. В конце недели мы отчитывались перед гейм-дизом и самими собой о проделанной работе. За этот период у нас была только пара факапов связанных с оценкой времени.
То есть, scrum можно рассматривать как ролевую игру. Совсем не обязательно иметь реального заказчика, отдельного скрам-мастера и даже ставить в известность руководство. Достаточно, чтобы хотя бы один человек знал, что, как и зачем нужно делать, а остальные ему хотя бы не мешали и просто выполняли свою работу.
Можно, конечно, сказать, что мой пример иллюстрирует фразу
При этом совершенно необязательно отказываться от каких-то элементов процесса, которые ассоциируются с Agile, но работают везде.Особенно, если я добавлю, что у нас не было доски для скрама — мы использовали basecamp, и не было ежедневных сборищ, так как команде из трех человек, сидящих рядом, они мало нужны.
Однако, я хочу акцентировать внимание на том, что управление проектами — процесс творческий, и не нужно слепо следовать инструкциям. Нужно переосмысливать agile под конкретные команды и проекты.
Поэтому к означенным посадке зонда на комету и прошивке телефона agile вполне применим. Просто в роли заказчика будет выступать не реальный заказчик, а, например, начальник отдела или тим-лид.
А вот про поддержку полностью согласен, это не место для скрама, там относительно сложно что-либо планировать.
И еще один тип проектов, где scrum'у точно не место, это хобби-проекты, и, в частности, опенсурс, создаваемый силами сообществ. Там тоже сложно что-либо планировать, так как человек может быть занят чем-то другим или просто ничего не делать, если не хочет.
у нас не было доски для скрамаРечь о канбан-доске? :-)
Нет, о scrum-доске. Но, внешне они похожи, только используются немного по-разному :-)
А в чём отличие?
Я не настолько разбирался с канбаном, чтобы рассказать про отличия самостоятельно, но на английском есть описание в этом документе (страница 14).
Однако, есть на русском.
Однако, есть на русском.
Так в чем же тогда разница между этими двумя досками? Да – вот эта маленькая «2» в средней колонке
на Kanban-доске. И всѐ. Эта цифра 2 означает что «в этой колонке может быть не более 2-х элементов
одновременно».
Зачем-то убрали ограничение (а убирать его нет никакого смысла) и вот у нас типа «новая доска» :-)
И еще один тип проектов, где scrum'у точно не место, это хобби-проекты, и, в частности, опенсурс, создаваемый силами сообществ. Там тоже сложно что-либо планировать, так как человек может быть занят чем-то другим или просто ничего не делать, если не хочет.
Практически во всех опен сорсных проектах есть милестоуны, которые в принципе можно считать чем-то вроде скрама. И, как ни странно, сообщество разработчиков им следует более или менее.
А почему «заказчик отсутствует как класс»? ГД — и есть точное воплощение product owner'а, который заинтересован в конечном продукте (игре).
Я оппонирую статье, там под заказчиком понимается именно заказчик. И если заказчику мы не можем каждую неделю демонстрировать посадку спутника на комету, то все, скрам не применим.
И, на мой взгляд, скорее, не геймдиз, а продюсер является product owner'ом в реальности. Геймдиз — человек подневольный. Другое дело, что часто продюсер — это лицо из руководства компании, и скрам ему до лампочки.
И, на мой взгляд, скорее, не геймдиз, а продюсер является product owner'ом в реальности. Геймдиз — человек подневольный. Другое дело, что часто продюсер — это лицо из руководства компании, и скрам ему до лампочки.
Agile и прочий Scrum — это методы управления программистами людьми, далекими от программирования.
В АйТи денег много, вот и ломятся сюда кто попало. А работу-то делать надо. Вот и придумали методологию управления умными людьми людьми недалекими.
На самом деле, если ты в теме, говоришь с программистами на одном языке — рулить проектами легко без всяких скрамов. Говорю это основываясь на своем 8-летнем опыте.
В АйТи денег много, вот и ломятся сюда кто попало. А работу-то делать надо. Вот и придумали методологию управления умными людьми людьми недалекими.
На самом деле, если ты в теме, говоришь с программистами на одном языке — рулить проектами легко без всяких скрамов. Говорю это основываясь на своем 8-летнем опыте.
Опыт временем не меряют, его меряют способностью решать конкретные задачи, и разнообразием уже разрешённых.
Что бы 8 лет сайтики на CMS'ках да простых фреймворках штопать — много мозгу не нужно…
Давайте лучше поговорим как вы контролируете качество вашей продукции, и как вы решаете вопросы долгосрочной поддержки?
В 80% случаев ответ прост — никак.
Что бы 8 лет сайтики на CMS'ках да простых фреймворках штопать — много мозгу не нужно…
Давайте лучше поговорим как вы контролируете качество вашей продукции, и как вы решаете вопросы долгосрочной поддержки?
В 80% случаев ответ прост — никак.
Если вы сайтики на CMS'ках штопаете, то вопросы долгосрочной поддержки вас интересовать не должны :)
Ну большинство «серой массы» эти вопросы действительно интересовать не должны…
А для всех остальных, по минимуму нужно обеспечить постоянное отслеживание версий и обновление всех зависимостей и движков/фреймворков, проводить аудит безопасности всех сторонних решений. имхо Где-то 70% сайтов на Wordpress взламывают как раз таки из-за древности движка и всех его зависимостей.
А для всех остальных, по минимуму нужно обеспечить постоянное отслеживание версий и обновление всех зависимостей и движков/фреймворков, проводить аудит безопасности всех сторонних решений. имхо Где-то 70% сайтов на Wordpress взламывают как раз таки из-за древности движка и всех его зависимостей.
UFO just landed and posted this here
:roflmao: я посмотрю на размер их почты и количество тикетов поддержки, а также на различные дефейсы…
busfactor == 1 неприемлем
busfactor == 1 неприемлем
UFO just landed and posted this here
Ну, а я пытаюсь донести что подобного рода заказчики — примитивные недоразвитые индивиды которым не хватает мозга подумать о том что может быть через год, или если их любимый «выполнятор» заболеет или помрёт… или ему просто станет неинтересно.
Нянчится с такими — себя не уважать.
Главное не «довольность» заказчика, а отсутствие головной боли через N месяцев.
Нянчится с такими — себя не уважать.
Главное не «довольность» заказчика, а отсутствие головной боли через N месяцев.
UFO just landed and posted this here
Я был в разных отралях — начиная от разработки железа и драйверов, заканчивая вэбом, десктопными и мобильными приложениями, SaaS'ами и PaaS'ами. 8 из 10ти проектов делались через одно место, по этому я так скептически ко всему отношусь.
UFO just landed and posted this here
Ничего не мешает писать и выкатывать MVP.
Выкатывать его на рынок с одними лишь приёмочными тестами, получить прибыль и обратную связь от потребителей, а потом внедрять эволюционный рефакторинг и добавлять больше тестов. Хотя профилировать решения нужно в любом случае.
Бюджета в 3000-4000$ обычно достаточно.
У нас так почти не умеют.
Выкатывать его на рынок с одними лишь приёмочными тестами, получить прибыль и обратную связь от потребителей, а потом внедрять эволюционный рефакторинг и добавлять больше тестов. Хотя профилировать решения нужно в любом случае.
Бюджета в 3000-4000$ обычно достаточно.
У нас так почти не умеют.
UFO just landed and posted this here
Поднята дикая тема. О применимости подходов. Ваш местечковый опыт не говорит о применимости концепций в целом.
Вопрос следует рассматривать глубже. Почему Agile вообще появился?? Вот раньше УП в ИТ напоминало УП во многих других отраслях. Agile в виде XP появился в результате необходимости спасти (в Крайслере там или где — неважно) проект.
Еще более глубоко, сильную мысль скажу. Agile это ответ в первую очередь на некомпетентность заказчиков в ИТ-проектировании. Даже банальный waterfall способен завершить в срок в бюджет и с надлежащим качеством (я не скажу процент тех моих проектов лично, которые так произошли, но они были).
Если изначально ясно, что за изменения надо платить, почему бы это не ввести в процесс? Такая логика появилась, и в результате появился Agile (с его манифестом). Развитие ИТ опережало развитие традиционного бизнеса и его моделей в 90-00… Но сейчас этого НЕТ.
Agile — это способ переложить риски. Ввести его в тренд не удается, и не выйдет (имхо конечно), потому что бизнесу не нужна услуга, ему нужен продукт.
Вопрос следует рассматривать глубже. Почему Agile вообще появился?? Вот раньше УП в ИТ напоминало УП во многих других отраслях. Agile в виде XP появился в результате необходимости спасти (в Крайслере там или где — неважно) проект.
Еще более глубоко, сильную мысль скажу. Agile это ответ в первую очередь на некомпетентность заказчиков в ИТ-проектировании. Даже банальный waterfall способен завершить в срок в бюджет и с надлежащим качеством (я не скажу процент тех моих проектов лично, которые так произошли, но они были).
Если изначально ясно, что за изменения надо платить, почему бы это не ввести в процесс? Такая логика появилась, и в результате появился Agile (с его манифестом). Развитие ИТ опережало развитие традиционного бизнеса и его моделей в 90-00… Но сейчас этого НЕТ.
Agile — это способ переложить риски. Ввести его в тренд не удается, и не выйдет (имхо конечно), потому что бизнесу не нужна услуга, ему нужен продукт.
Согласен.
Любому бизнесу в первую очередь нужен продукт, а не методы его производства.
Основные Agile методологии в чистом виде неприменимы к существующим коллективам, и это прискорбно.
Разрабатывать и тестировать новые методологии индивидуально для каждого коллектива, со всеми его особенностями — вот важнейшая задача менеджера в наше время. При этом количество «бумажек» обычно стремится к нулю. Нужно проводить индивидуальную работу с каждым сотрудником и отслеживать социальные связи, в том числе и те которые не относятся к работе. Частенько отдельно нанимают психоаналитиков, я лично знаком с несколькими случаями их работы в рамках средних коллективов (до 100 человек) и в общем-то «мне хватило»…
Agile — это цель, а не средство… методология — средство, а не цель…
Почему-то абстрактные средства все считают универсальными и применимыми к реальным проектам.
Любому бизнесу в первую очередь нужен продукт, а не методы его производства.
Основные Agile методологии в чистом виде неприменимы к существующим коллективам, и это прискорбно.
Разрабатывать и тестировать новые методологии индивидуально для каждого коллектива, со всеми его особенностями — вот важнейшая задача менеджера в наше время. При этом количество «бумажек» обычно стремится к нулю. Нужно проводить индивидуальную работу с каждым сотрудником и отслеживать социальные связи, в том числе и те которые не относятся к работе. Частенько отдельно нанимают психоаналитиков, я лично знаком с несколькими случаями их работы в рамках средних коллективов (до 100 человек) и в общем-то «мне хватило»…
Agile — это цель, а не средство… методология — средство, а не цель…
Почему-то абстрактные средства все считают универсальными и применимыми к реальным проектам.
Некоторое время назад я изучал инновационный менеджмент, потом заметил, что многие подходы, но только уже без объяснения причин и в виде бездушного набора правил внезапно есть agile.
Ещё могу добавить по памяти из последних проектов:
1. У PO нет времени сидеть с вами, выловить его на пару часиков раз в несколько недель большая удача, и он при этом почти всегда чем-то занят кроме вас
2. PO просто увольняется, а проект нужно сдавать новому человеку или его заму, которому явно не до вас.
3. Состав команды не может быть зафиксирован на итерацию. Если у компании есть другие проекты на поддержку, то сотрудников часто приходится перекидывать на баг-фиксинг в других проектах.
1. У PO нет времени сидеть с вами, выловить его на пару часиков раз в несколько недель большая удача, и он при этом почти всегда чем-то занят кроме вас
2. PO просто увольняется, а проект нужно сдавать новому человеку или его заму, которому явно не до вас.
3. Состав команды не может быть зафиксирован на итерацию. Если у компании есть другие проекты на поддержку, то сотрудников часто приходится перекидывать на баг-фиксинг в других проектах.
Текучка персонала — признак "дымохода" и "грибного менеджмента".
Опосля грибного менеджмента приходит «чайка-менеджмент» (seagull management) — пришёл поорал, оставил за собой кучи проектного дерьма, которые потом нужно разгребать персоналу…
Хотя лучше о них, как ни странно, почитать на лурке и поплакать.
Почти все организационные антипаттерны являются признаками компенсаторных процессов у руководства.
Опять же стоит решить вопросы
И все эти проблемы решаются через некоторое время.
Опосля грибного менеджмента приходит «чайка-менеджмент» (seagull management) — пришёл поорал, оставил за собой кучи проектного дерьма, которые потом нужно разгребать персоналу…
Хотя лучше о них, как ни странно, почитать на лурке и поплакать.
Почти все организационные антипаттерны являются признаками компенсаторных процессов у руководства.
Опять же стоит решить вопросы
- Выработки требований
- Контроля качества
- Долгосрочной поддержки
И все эти проблемы решаются через некоторое время.
А как решать такие проблемы, если компания бурно развивается, т.е. меняются бизнес-процессы, меняются команды и т.д.
Смена персонала не признак развития, смена персонала — признак наличия организационных проблем.
Как говорится «крысы бегут с тонущего корабля»…
Я не уверен что у вас там «бизнес процессы» меняются и что они вообще в наличии, скорее нет чёткого позиционирования продукта. В любом случае это нужно обсуждать отдельно, можете отписать в скайп — расcкажу пару душещипательных историй.
Как говорится «крысы бегут с тонущего корабля»…
Я не уверен что у вас там «бизнес процессы» меняются и что они вообще в наличии, скорее нет чёткого позиционирования продукта. В любом случае это нужно обсуждать отдельно, можете отписать в скайп — расcкажу пару душещипательных историй.
по-моему, вся проблема от того, что люди валят в кучу Agile манифест и Agile методологии :)
Agile манифест — это все-таки о том, чем мы мотивируемся, когда принимаем решения :)
Люди и взаимодействие важнее процессов и инструментов. Это не значит, что процессы не важны. Просто не надо отгораживаться от людей процессом и быть открытым к общению :)
Работающий продукт важнее исчерпывающей документации. Это не значит, что документация больше не нужна, потому что у на Agile. Работа никуда не делась, если документация требуется — надо ее делать. Просто лучше сделать продукт таким, чтобы документация ему была не нужна :)
Сотрудничество с заказчиком важнее согласования условий контракта. Это не значит, что нам не нужен контракт. Просто надо выстраивать отношения с заказчиком. Если он будет вам доверять — он не будет пользоваться бумажой и вы разрешите проблемы лично :)
Готовность к изменениям важнее следования первоначальному плану. Это не значит, что нам больше не нужно планировать. Просто мир меняется очень быстро, время жизни плана короткое. Не стоит зацикливаться на нем — он не истина :)
Вообще — все это придумано задолго до АйТи, но мы прогрессивно адаптиуем хорошие практики только сейчас :)
Agile манифест — это все-таки о том, чем мы мотивируемся, когда принимаем решения :)
Люди и взаимодействие важнее процессов и инструментов. Это не значит, что процессы не важны. Просто не надо отгораживаться от людей процессом и быть открытым к общению :)
Работающий продукт важнее исчерпывающей документации. Это не значит, что документация больше не нужна, потому что у на Agile. Работа никуда не делась, если документация требуется — надо ее делать. Просто лучше сделать продукт таким, чтобы документация ему была не нужна :)
Сотрудничество с заказчиком важнее согласования условий контракта. Это не значит, что нам не нужен контракт. Просто надо выстраивать отношения с заказчиком. Если он будет вам доверять — он не будет пользоваться бумажой и вы разрешите проблемы лично :)
Готовность к изменениям важнее следования первоначальному плану. Это не значит, что нам больше не нужно планировать. Просто мир меняется очень быстро, время жизни плана короткое. Не стоит зацикливаться на нем — он не истина :)
Вообще — все это придумано задолго до АйТи, но мы прогрессивно адаптиуем хорошие практики только сейчас :)
Кстати, на счет
все это придумано задолго до АйТи— тут я полностью согласен. Я временами увлекаюсь другими сферами деятельности кроме IT и вижу, что, например, полноценное проектирование происходит прежде чем начинаешь что-то ваять, при чем уровень проектирования и документации, как правило, выше чем это можно увидеть в IT. Из чего можно сделать вывод, что айтишники — ленивые люди с отблеском элитарности на своем ЧСВ, которые к работе подходят зачастую небрежно.
Сначала надо заиметь сильные профессиональные компетенции и опыт решения задач в своей зоне отвественности (программирование, тестирование, управление проектом, спонсорство или управление продуктом) — и только после гибкие процессы в полный рост, хоть бы и Scrum. Тогда все взлетит и облегчает всем жизнь. Точка.
О, Катька, привет :-)
Спасибо большое, в отличие от большинства статей на тему «аджайл» очень конкретная и прямая.
Спасибо за отзыв! Есть еще статья от этого же автора: megamozg.ru/company/dataart/blog/13772
Sign up to leave a comment.
Меня беспокоит Agile, и я хочу об этом поговорить