Есть у меня забавная, но, увы, абсолютно не осуществимая идея.
Представим себе, что у нас есть достаточно большой проект (ну скажем на 9 месяцев, на пару десятков человек). Такой, вполне настоящий проект.
Во время его исполнения, люди должны записывать, над чем они работали, чтобы в конце проекта можно было посмотреть, сколько времени(денег) ушло
на анализ требований, архитектуру, разработку, отладку, митинги, тестирование, документацию, построение инфраструктуры для проекта и т.п.
Уже эта статистика само по себе дело интересное, но в целом, похожие данные можно таки найти и сейчас (не в этом идея). Да кстати, еще заметка, само собой разумеющееся,
что для разных проектов и команд, соотношения куда ушло время будет очень разным (но это так, к делу относится мало).
Что мы делаем дальше, по окончанию проекта, это стираем все артефакты (код, документацию, баг треккер, систему контроля версий, whiteboard’ы). В общем стираем ВСЕ, кроме
памяти людей и заставляем их выполнить еще раз проект, снова записывая время. И это повторяется, пока числа не стабилизируются.
И вот, что мне было бы ОЧЕНЬ интересно поглядеть график. По вертикали — время потраченное на каждую часть, по горизонтали номер повторения. Что-то типа вот такого:
В основном, интересно поглядеть, что ужимается хорошо, что ужимается плохо. Опять же, такой график дает хорошее представление о том во сколько раз проект делается менее эффективно, чем потенциальное идеальное исполнение этого проекта. Ну и плюс, интересно, не возникнут ли флуктуации, когда X-ое исполнение займет больше, чем X-1 (что по идее не должно происходить). Пожалуй еще интересно из флуктуаций, если вдруг какая-то часть резко уменьшиться после достаточно долгого (в течении нескольких повторений) нахождения на одном уровне.
Ну и второй график, который интересно было бы глянуть, все то же самое, только не просто стираются все артефакты, но еще и меняются все люди на проекте, кроме самого главного.
а на что может повлиять анализ? вот к примеру такая статистика уже есть
Честно скажу — не знаю. Вероятнее всего ничего она не даст, кроме удовлетворения мое любопытства.
С другой стороны, вполне может быть, поглядя на график можно будет сказать… «хм, а вот это интересно… может эффект X можно как-то использовать».
Я бы предположил, что такая статистика может собираться в рамках итеративных аджайл проектов — в средине одной фазы девелопмента тип работ может быть достаточно подобным, и уменьшение времени индицировало бы увеличение опытности команды в предметной области.
С другой стороны, в каждой проекте есть вариабельность, и я бы предположил, что в некоторых областях вариабелность сделает такие сравнения слабо осмысленными.
На самом деле инфа подобная есть. Очень часто евангелисты ит-платформ её имеют (когда задача — делаем всё точно также, но на RoR). Поделятся они конечно, только если им будет выгодно, но всё же.
Ну, все же это не та информация о которой я говорил.
В той о которой говорят евангелисты — основной упор на сравнение технологий, плюс они чаще всего выбирают самый удобный пример (например написание блога на RoR).
Чего нету
а) Одних и тех же людей
б) Нескольких повторений
в) Разумно большого проекта
г) Разбивки по времени, что на что ушло
Таки да, любопытная, и абсолютно неосуществимая идея.
К тому же польза от графиков графиков появляется только в предположении, что в результате всегда получится одно и тоже. Но это ведь далеко не факт.
По пути развития возникает немеряно «вилок» где можно выбрать одно или другое ( а то и выбирать из десятков вариантов ) на которые можно свернуть. Без логов, «только по памяти» все такие развилки сложно восстановить, а свернув в одном месте можно выйти на результат совсем с другой стороны ( или даже вообще не выйти 🙂 ). И нужно большущее количество таких суперитераций, чтобы сначала добиться стабильного результата, а потом иметь возможность что-то оптимизировать.
Но, да, понаблюдать со стороны за днём ( или месяцем, а то и годом 😉 ) сурка для целой команды — было бы любопытно.
Кстати. Мне почему-то пришли в голову мысли о конвейере на реальном производстве. Там ведь примерно так и происходит сам процесс производства ( сделать, оптимизировать, повторить ). Другой вопрос, что там оптимизация происходит как раз за счёт накопления и анализа артефактов и это наверное уже немного другая тема.
Насчет «вилок» согласен. Но я думаю 3-4 итерации должны более менее стабилизировать все. Крупные решения уже будут обработаны много раз.
Хотя безусловно интересно, то что, кому-то может прийти идея как сделать все проще и на пятой итерации, вдруг время на разработку например упадет в 2 раза.
Насчет конвейера — хорошая аналогия. Честно говоря, она мне в голову не пришла. Но в целом, это именно и есть IT конвейер. В жизни одинаковый проекты(детали) делать не получается, а тут именно это и есть постановка задачи.
Проведение даже одного (не говоря уже о большем числе) повторения этого эксперимента на живых разработчиках негуманно 🙂
Попробуйте сами поставить себя на их место.
Та да… Думаю где-то к 2-3 повторению начнутся суициды 😉