Что мне думается.
Я думаю, что нормальное течение работы программиста хаотично.
Если я работаю над программой, то обычно я работаю не над каким-то одним модулем. И совсем редко - над областью объёмом менее, чем 100 строк.
Если выразиться образно, то работа всегда ведется по некоторому фронту. Реализация какой-то одной вещи приводит к изменениям во многих соседних местах.
Обычно, предметная область, над которой я работаю, мне более-менее неизвестна, известен лишь её размер, да и то, приблизительно. Поэтому я начинаю работу с, так сказать, ядра, постепенно расширяя охваченную территорию. Охват территории в целом и отдельных её "районов" в частности не будет стопроцентным очень долгое время. Для любого из районов охват будет зависеть от охвата соседей и тд по цепочке.
К тому же, предметная область имеет обыкновение расширяться.
При планировании программы цели представляются некоторыми дискретными величинами, цель либо достигнута, либо нет. А исходя из рассуждений чуть выше, существует лишь процент охвата территории цели.
С повышением процента охвата площади, наше знание кристаллизуется и вероятность появления изменений в описании какого-то участка предметной области падает. Она падает ещё сильнее, если параллельно увеличивается охват соседних областей.
И сразу к рациональному предложению: а что, если при планировании использовать не факт достижения цели, а вероятность (и объём) появления изменений в представлениях/знаниях о некоторой части предметной области?
Теперь, для придания всему этому наукообразности, я попытаюсь ввести расстояния.
(все это грубо)
Если два "района" не связаны между собой (число связей какого-то рода 0), то расстояние между ними равно бесконечности. Чем больше число связей, тем ближе "районы." "Расстояние" между "районами" равно Rij=1/Nсвязей. В более сложном варианте Rij=1/Σk=1..Nwijk.
"Районы" предметной области образуют направленный граф, дуги которого содержат расстояния. Граф неправлен потому, что связи неравнозначны, клиент, например, может пользоваться не всеми возможностями сервера. Расстояния между двумя напрямую несвязанными районами можно считать суммой расстояний. Это хорошо совпадает с повседневным опытом - часть программы может влиять на несвязанную с ней напрямую, если "посредник" сильно связан с обеими.
Знания о районе характеризуются Ki∈[0..1] - "knowledge," "степень знания."
Чем больше знания, тем меньше вероятность изменений: Pki=1-Ki.
Вероятность внесения изменений по связям: Pri=1-∏j=1..N[(1-Pkj)e(σ/2)Rij2]. Вероятность тем больше, чем ближе связанные компоненты и чем больше их собственная проработка.
Общая вероятность получения изменений: Pci=1-(1-Pki)(1-Pri).
У нас есть скорость повышения проработки, она экспоненциально приближает проработанность района предметной области: Ki(t)=1-Ki(0)e-αit. Скорость αi зависит от задачи и разработчика.
По идее, любое изменение в каком-либо районе ведёт к увеличению его площади и, соответственно, к уменьшению его проработанности Ki. Это связано с вероятностью изменений, но как это связать, я ещё, пока, не решил.
(все это грубо, ещё раз повторю)
Через некоторое время, после установления Ki(0), связей (и из них расстояний) и скоростей проработки αi, мы сможем получить оценки. В основном, временные - пессимистичную, ожидаемую и оптимистичную оценки времени выполнения.
Это что касается планирования. Но нужно же ещё и контролировать.
Контроль осуществляется через опрос программистов на предмет их оценки (в процентах) проработки их области ответственности. Если произошло снижение оценки по отношению к ожидаемой, необходимо выяснить, что произошло - может быть, открылась новая область или человек болеет.
Дополнительный контроль проводится, допустим, по автоматическим тестам самим руководителем или тестерами - третьей стороной, так сказать.
Что для меня важно в этой системе: она не делит этапы на планирование, разработку и тестирование/отладку. Все идет плавно, поскольку никакое планирование невозможно без хоть какой-нибудь проработки, а умеренное тестирование необходимо для постепенного контроля как качества, так и прогресса. Единственная формальность в этом процессе - это периодический опрос разработчиков на предмет готовности системы. Более их ничто не отвлекает от работы, во-первых, и налицо доверие к ним - во-вторых.
Что ещё важно - пользующийся этой системой должен разбираться в предметной области, хотя бы постепенно вникая в неё вместе с разработчиками. Иначе он не сможет оценить степень связности районов.
Вот как-то так.
Если я работаю над программой, то обычно я работаю не над каким-то одним модулем. И совсем редко - над областью объёмом менее, чем 100 строк.
Если выразиться образно, то работа всегда ведется по некоторому фронту. Реализация какой-то одной вещи приводит к изменениям во многих соседних местах.
Обычно, предметная область, над которой я работаю, мне более-менее неизвестна, известен лишь её размер, да и то, приблизительно. Поэтому я начинаю работу с, так сказать, ядра, постепенно расширяя охваченную территорию. Охват территории в целом и отдельных её "районов" в частности не будет стопроцентным очень долгое время. Для любого из районов охват будет зависеть от охвата соседей и тд по цепочке.
К тому же, предметная область имеет обыкновение расширяться.
При планировании программы цели представляются некоторыми дискретными величинами, цель либо достигнута, либо нет. А исходя из рассуждений чуть выше, существует лишь процент охвата территории цели.
С повышением процента охвата площади, наше знание кристаллизуется и вероятность появления изменений в описании какого-то участка предметной области падает. Она падает ещё сильнее, если параллельно увеличивается охват соседних областей.
И сразу к рациональному предложению: а что, если при планировании использовать не факт достижения цели, а вероятность (и объём) появления изменений в представлениях/знаниях о некоторой части предметной области?
Теперь, для придания всему этому наукообразности, я попытаюсь ввести расстояния.
(все это грубо)
Если два "района" не связаны между собой (число связей какого-то рода 0), то расстояние между ними равно бесконечности. Чем больше число связей, тем ближе "районы." "Расстояние" между "районами" равно Rij=1/Nсвязей. В более сложном варианте Rij=1/Σk=1..Nwijk.
"Районы" предметной области образуют направленный граф, дуги которого содержат расстояния. Граф неправлен потому, что связи неравнозначны, клиент, например, может пользоваться не всеми возможностями сервера. Расстояния между двумя напрямую несвязанными районами можно считать суммой расстояний. Это хорошо совпадает с повседневным опытом - часть программы может влиять на несвязанную с ней напрямую, если "посредник" сильно связан с обеими.
Знания о районе характеризуются Ki∈[0..1] - "knowledge," "степень знания."
Чем больше знания, тем меньше вероятность изменений: Pki=1-Ki.
Вероятность внесения изменений по связям: Pri=1-∏j=1..N[(1-Pkj)e(σ/2)Rij2]. Вероятность тем больше, чем ближе связанные компоненты и чем больше их собственная проработка.
Общая вероятность получения изменений: Pci=1-(1-Pki)(1-Pri).
У нас есть скорость повышения проработки, она экспоненциально приближает проработанность района предметной области: Ki(t)=1-Ki(0)e-αit. Скорость αi зависит от задачи и разработчика.
По идее, любое изменение в каком-либо районе ведёт к увеличению его площади и, соответственно, к уменьшению его проработанности Ki. Это связано с вероятностью изменений, но как это связать, я ещё, пока, не решил.
(все это грубо, ещё раз повторю)
Через некоторое время, после установления Ki(0), связей (и из них расстояний) и скоростей проработки αi, мы сможем получить оценки. В основном, временные - пессимистичную, ожидаемую и оптимистичную оценки времени выполнения.
Это что касается планирования. Но нужно же ещё и контролировать.
Контроль осуществляется через опрос программистов на предмет их оценки (в процентах) проработки их области ответственности. Если произошло снижение оценки по отношению к ожидаемой, необходимо выяснить, что произошло - может быть, открылась новая область или человек болеет.
Дополнительный контроль проводится, допустим, по автоматическим тестам самим руководителем или тестерами - третьей стороной, так сказать.
Что для меня важно в этой системе: она не делит этапы на планирование, разработку и тестирование/отладку. Все идет плавно, поскольку никакое планирование невозможно без хоть какой-нибудь проработки, а умеренное тестирование необходимо для постепенного контроля как качества, так и прогресса. Единственная формальность в этом процессе - это периодический опрос разработчиков на предмет готовности системы. Более их ничто не отвлекает от работы, во-первых, и налицо доверие к ним - во-вторых.
Что ещё важно - пользующийся этой системой должен разбираться в предметной области, хотя бы постепенно вникая в неё вместе с разработчиками. Иначе он не сможет оценить степень связности районов.
Вот как-то так.