8 принципів планування розробки, які спрощують життя
Скажімо прямо, українській людині планувати важко. Люди в Україні сильні імпровізацією та вмінням збиратися в критичний момент, видаючи разючі результати. Але життя показує, що команда програмістів на подібній ідеології не поїде. Героїчні зусилля одночасно не зможуть компенсувати пофігізм в інший.
Команди розробників допускають такі помилки під час планування створення ПЗ.
1. Планувати терміни мають програмісти, а не менеджери
Часта помилка, коли керівник проекту, який не розуміє належним чином обсяг і специфіку завдань, встановлює терміни проекту не відповідно до досвіду, можливостей та компетенцій команди, а спираючись на власні уявлення, бажання чи запити клієнта. Програмістам у подібних групах не позаздриш. Розбіжності запланованих та реальних термінів становить 40-80%. Атмосфера в колективі створюється гнітюча і відбиває бажання працювати. Проблеми йдуть одна за одною, а винними виставляються безпосередні розробники.
2. Необхідно заздалегідь визначати приблизні терміни здачі всього проекту та реальний час вирішення задачі
Відпускати процеси на самоплив ні в якому разі не можна. Ігнорування процедури планування призводить до розхлябаності, низької мотивації розробників у попередні періоди дедлайну, до нерозуміння командою, що робити, кудирухатися і що потрібно отримати у результаті. В об'єднаннях, де приблизні терміни здачі проекту не визначаються, бажано замислитися над тим, що подібний хаос до добра не доведе.
3. Проект розбивайте на дрібні етапи з чіткими цілями та обов'язковим обговоренням результатів
Застосування принципу необхідне протидії закону Паркінсона, визначальному, що загальний обсяг роботи буде збільшуватися, щоб заповнити все виділений працювати час. Дотримуючись поради, можна уникнути бажання старанно працювати лише незадовго до терміну здачі проекту. Розбивка процесу досягнення глобальної мети на контрольні періоди з необхідністю виконання конкретних завдань протягом тижня – двох дозволить використовувати робочий потенціал команди максимум. При зазначеному підході підтримується високий рівень мотивації та працездатності розробників протягом усього періоду створення ПЗ та збільшується ймовірність досягнення бажаних цілей.
4. Члени команди повинні максимально щільно взаємодіяти один з одним
5. Включайте резерв часу для покриття форс-мажору, нових вимог замовника, відпусток та свят, на інтеграцію та тестування
На початковому етапі планування не можна передбачити всі ситуації. Тому потрібно зарезервувати час про запас, щоб команді не довелося поспішати і, як наслідок, робити помилки. Не варто ігнорувати необхідність налагодження та доведення програмного забезпечення до рівня стабільної роботи та прийнятної кількості багів. Випуск сирого продукту через жорстку економію часу не розумний. Методологія Agile передбачає мінливість зовнішніх умов та необхідність швидкої та безболісної адаптації до них.
6. Не можна поспішати, порушувати план та зменшувати час розробки ПЗ
Часта помилка менеджерів,які думають, що програмісти зможуть потягнути будь-які терміни. По-перше, команда демотивується, саботує процес праці або пише заяви за власним бажанням. По-друге, різке прискорення робочих операцій виснажує ресурси організму та психіки людини, веде до професійного вигоряння. По-третє, завищений темп призводить до збільшення кількості помилок у коді. На налагодження та виправлення у майбутньому знадобиться значно більше часу, ніж вдасться заощадити подібним чином.
7. Документуйте планування за допомогою відповідного таск-менеджера
Вибір конкретної програми є питанням смаку. Плани слід фіксувати. Потрібна наочність як розробників, так клієнтів, зберігаючи можливість внесення змін. Це дозволяє покращити взаєморозуміння команди розробників, менеджменту та клієнта. Знижується кількість суперечок щодо трактування робочих дій. Чіткість формулювання плану допоможе уникнути двоякого тлумачення.
8. Розставляйте пріоритети завданням та концентруйтеся на головному
Намагайтеся насамперед реалізовувати найважливіший функціонал. Майте на увазі, що якимись фічами в процесі розробки доведеться пожертвувати, так само як і реалізацію частини ідей. А розставити пріоритети можна виключно через спілкування та обмін думками.