- 8 принципов планирования разработки, упрощающих жизнь
- 1. Планировать сроки должны программисты, а не менеджеры
- 2. Необходимо заранее определять примерные сроки сдачи всего проекта и реальное время решения задачи
- 3. Проект разбивайте на мелкие этапы с четкими целями и обязательным обсуждением результатов
- 4. Члены команды должны максимально плотно взаимодействовать друг с другом
- 5. Включайте резерв времени для покрытия форс-мажора, новых требований заказчика, отпусков и праздников, на интеграцию и тестирование
- 6. Нельзя торопиться, нарушать план и уменьшать время разработки ПО
- 7. Документируйте планирование с помощью подходящего таск-менеджера
- 8. Расставляйте приоритеты задачам и концентрируйтесь на главном
- Планирование выполнения процессов программирование
- 3.4.1.3. Задачи алгоритма планирования
8 принципов планирования разработки, упрощающих жизнь
Скажем прямо, русскому человеку планировать тяжело. Люди в России сильны импровизацией и умением собираться в критический момент, выдавая поразительные результаты. Но жизнь показывает, что команда программистов на подобной идеологии далеко не уедет. Героические усилия в одно время не смогут компенсировать пофигизм в другое.
Что общего у зомби-апокалипсиса и разработки ПО? Простые правила помогают пережить и то, и другое
Этап планирования предполагает осознанную и целенаправленную деятельность команды на пути к достижению результата. Определить задачи, разбить на вехи, предвидеть сроки – необходимый шаг на пути воплощения задуманного. Особенно, если дело касается гибкой методологии Agile, которую считаем наилучшей.
Команды разработчиков допускают такие ошибки при планировании создания ПО.
1. Планировать сроки должны программисты, а не менеджеры
Частая ошибка, когда руководитель проекта, не понимающий должным образом объем и специфику задач, устанавливает сроки проекта не в соответствии с опытом, возможностями и компетенциями команды, а опираясь на собственные представления, желания или запросы клиента. Программистам в подобных группах не позавидуешь. Расхождения запланированных и реальных сроков составляет 40-80%. Атмосфера в коллективе создается гнетущая и отбивающая желание работать. Проблемы следуют одна за другой, а виноватыми выставляются непосредственные разработчики.
2. Необходимо заранее определять примерные сроки сдачи всего проекта и реальное время решения задачи
Отпускать процессы на самотек ни в коем случае нельзя. Игнорирование процедуры планирования приводит к расхлябанности, низкой мотивации разработчиков в предшествующие дедлайну периоды, к непониманию командой, что делать, куда двигаться и что нужно получить в итоге. В объединениях, где примерные сроки сдачи проекта не определяются, желательно задуматься о том, что подобный хаос до добра не доведет.
3. Проект разбивайте на мелкие этапы с четкими целями и обязательным обсуждением результатов
Применение принципа необходимо для противодействия закону Паркинсона, определяющему, что общий объём работы всегда будет увеличиваться, чтобы заполнить всё выделенное на работу время. Следуя совету, можно избежать желания усердно трудиться лишь незадолго до срока сдачи проекта. Разбивка процесса достижения глобальной цели на контрольные периоды с необходимостью выполнения конкретных задач в течение недели – двух позволит использовать рабочий потенциал команды по максимуму. При указанном подходе поддерживается высокий уровень мотивации и работоспособности разработчиков на протяжении всего периода создания ПО и увеличивается вероятность достижения желаемых целей.
4. Члены команды должны максимально плотно взаимодействовать друг с другом
Прежде всего повышается сплоченность коллектива и стимулируется оказание взаимопомощи. При недостаточном общении между членами объединения отсутствует «командный дух», обеспечивающий слаженную работу. Совместная продуктивная деятельность удовлетворяет социальные потребности человека в ощущении значимости выполняемого труда. Соблюдение принципа позволяет безболезненно заменить любого члена команды, потому что участники в курсе кто, что и как делает.
5. Включайте резерв времени для покрытия форс-мажора, новых требований заказчика, отпусков и праздников, на интеграцию и тестирование
На первоначальном этапе планирования нельзя предусмотреть все ситуации. Поэтому нужно зарезервировать время про запас, чтобы команде не пришлось торопиться и, как следствие, совершать ошибки. Не стоит игнорировать необходимость отладки и доведения ПО до уровня стабильной работы и приемлемого количества багов. Выпуск сырого продукта из-за жесткой экономии времени не разумен. Методология Agile предполагает изменчивость внешних условий и необходимость быстрой и безболезненной адаптации к ним.
6. Нельзя торопиться, нарушать план и уменьшать время разработки ПО
Частая ошибка менеджеров, думающих, что программисты смогут потянуть любые сроки. Во-первых, команда демотивируется, саботирует процесс труда или пишет заявления по собственному желанию. Во-вторых, резкое ускорение рабочих операций истощает ресурсы организма и психики человека, ведет к профессиональному выгоранию. В-третьих, завышенный темп приводит к увеличению количества ошибок в коде. На отладку и исправление в будущем потребуется значительно больше времени, чем получится сэкономить подобным образом.
7. Документируйте планирование с помощью подходящего таск-менеджера
Выбор конкретной программы является вопрос вкуса. Планы следует фиксировать. Требуется наглядность как для разработчиков, так и для клиентов, сохраняя возможность для внесения изменений. Это позволяет улучшить взаимопонимание команды разработчиков, менеджмента и клиента. Снижается количество споров относительно трактовки рабочих действий. Четкость формулировки плана поможет избежать двоякого толкования.
8. Расставляйте приоритеты задачам и концентрируйтесь на главном
Старайтесь в первую очередь реализовывать наиболее важный функционал. Имейте ввиду, что какими-то фичами в процессе разработки придется пожертвовать, равно как и реализацией части идей. А расставить приоритеты возможно исключительно через общение и обмен мнениями.
А что вы думаете по поводу планирования в разработке ПО? Оставляйте свои комментарии к статье. Мы будем рады услышать ваше мнение.
Планирование выполнения процессов программирование
Евдокимов А.А., Майстренко Н.В., Майстренко А.В.
3.4.1.3. Задачи алгоритма планирования
Для создания алгоритма планирования необходимо представление о конкретной проблеме, которую должен решить выбранный алгоритм. Некоторые задачи зависят от особенностей среды, в которой должен исполняться алгоритм, но также есть и задачи, которые необходимо выполнить в любом случае. Рассмотрим основные задачи алгоритма планирования:
• равнодоступность — предоставление каждому процессу справедливой доли времени центрального процессора;
• принуждение к определенной политике — наблюдение за выполнением уста¬новленной политики;
• баланс — поддержка загруженности всех составных частей системы.
• производительность — выполнение максимального количества заданий в час;
• оборотное время — минимизация времени между представлением задачи и ее завершением;
• использование центрального процессора — поддержка постоянной загружен¬ности процессора.
♦ для интерактивных систем:
• время отклика — быстрый ответ на запросы;
• пропорциональность — оправдание ожиданий пользователя.
♦ для систем реального времени:
• соблюдение предельных сроков — предотвращение потери данных;
• предсказуемость — предотвращение ухудшения качества в мультимедийных системах.
Равнодоступность важна при любых обстоятельствах. Сопоставимые процессы должны получать сопоставимый уровень обслуживания. Также справедливо то, что различные категории процессов могут обрабатываться по-разному. К равнодоступности имеет некоторое отношение и принуждение к системной политике. Если цель локальной политики заключается в том, что процессы, контролирующие выполнение более приоритетных задач, должны возобновлять свою работу сразу же, как только в этом возникнет необходимость, планировщик должен обеспечить осуществление такой политики. Еще одной общей задачей является поддержание максимальной задействованности всех составляющих системы. Если центральный процессор и устройства ввода-вывода смогут быть постоянно задействованы, то будет произведен больший объем работы в секунду, чем при простое каких-нибудь компонентов.
Производительность в пакетных системах — это количество заданий, выпол¬ненных за один час. Оборотное время — это среднестатистическое время от момента передачи задания на выполнение до момента завершения его выполнения. Им измеряется время, затрачиваемое среднестатистическим пользователем на вынужденное ожидание выходных данных. В качестве показателя в пакетных системах также часто используется степень задействования центрального процессора.
Для интерактивных систем наиболее важной задачей является сведение к минимуму времени отклика, то есть времени между выдачей команды и получением результата. В определенной степени к интерактивным системам относится также и задача, которую можно назвать пропорциональностью, связанную с ожиданиями пользователей относительно времени выполнения тех или иных задач. Когда запрос, рассматриваемый как сложный, занимает довольно продолжительное время, пользователь воспринимает это как должное, но когда запрос, считающийся простым, также занимает немало времени, пользователь выражает недовольство. В некоторых случаях планировщик не может повлиять на время отклика, но в других случаях он может это сделать, особенно если задержка обусловлена неверным выбором очередности выполнения процессов.
В отличие от интерактивных систем системы реального времени имеют другие свойства, а значит, и другие задачи планирования. Главным требованием в системах реального времени является соблюдение всех (или большей части) крайних сроков. В некоторых системах реального времени, особенно в мультимедийных системах, существенную роль играет предсказуемость. Планирование процессов должно быть исключительно предсказуемым и постоянным.